This is more of an architectural and security question than anything else. I'm trying to determine if a suggested architecture is necessary. Let me explain my configuration.
We have a standard DMZ established that essentially has two firewalls. One that's external facing and the other that connects to the internal LAN. The following describes where each application tier is currently running.
Outside the firewall:
Silverlight Application
In the DMZ:
WCF Service (Business Logic & Data Access Layer)
Inside the LAN:
Database
I'm receiving input that the architecture is not correct. Specifically, it has been suggested that because "a web server is easily hacked" that we should place a relay server inside the DMZ that communicates with another WCF service inside the LAN which will then communicate with the database. The external firewall is currently configured to only allow port 443 (https) to the WCF service. The internal firewall is configured to allow SQL connections from the WCF service in the DMZ.
Ignoring the obvious performance implications, I don't see the security benefit either. I'm going to reserve my judgement of this suggestion to avoid polluting the answers with my bias. Any input is appreciated.
Thanks,
Matt
I do think the remarks made are valid, and in such a case I would probably also try and use as many "defense-in-depth" layers I could possibly come up with.
Plus, the amount of work to achieve this might be less than you're afraid of - if you're on .NET 4 (or can move to it).
You could use the new .NET 4 / WCF 4 routing service to do this quite easily. As an added benefit: you could expose a HTTPS endpoint to the outside world, but on the inside, you could use netTcpBinding (which is a lot faster) to handle internal communications.
Check out how easy it is to set up a .NET 4 routing service:
What's new in WCF4 Routing Service - or: "Look ma: Just one service to talk to!"
Creating Routing Service using WCF 4.0, .NET Framework 4.0 and Visual Studio 2010 RC
Related
Enviroment
Consider the following production environment setup for a web application:
End user --Internet--> web server in DMZ --Firewall--> WCF hosted on app server --> DB Server
Constraint:
Also consider that we cannot change anything from the infrastructure point of view. For example, open ports, change any firewall setting etc.
Problem:
We want to expose the WCF, which is hosted on the app server, to external clients. We are trying to solve this as follows:
End user --Internet--> Router WCF in DMZ --Firewall--> WCF hosted on app server --> DB Server
Please note that we cannot establish a db connection from the DMZ environment where the WCF needs to be hosted so that the external clients can consume it. We have developed a "Router WCF" which passes through all messages to the internal WCF and vice-versa.
This solution adds an unnecessary overhead of serializing and de-serializing data. There must a better and proper way of doing this. We are looking forward to the community for guidance. Thank you.
In DMZ the bibliography tells you: always create an intermediate layer. This means another machine on the internet will be the point of connection and it will proxy the connection back to WCF.
The machine is the web server you seem to mention, that is stupid, has no data, and (to be a proper DMZ) has a firewall between it and all the machines (WCF and the others) it serves that permits only IP:PORTS used on such machines.
In this scenario, usually Apache on the public web server with a URL-rewrite rule (i.e if it is /x/y send it to servera.internal.com:9900 - if it is /x/z send it to serverb.internal.com:9901 etc...) is enough, but there are plenty of solutions of course.
It seems you are doing exactly this, why do you say it is not the proper solution?
DMZs could seem a bit dated as protection mechanism (I agree) but you have to think when servers like your WCF machine had dozens of ports opened, and you wanted to lower the risk of random ports on web-facing machines, a giant attack surface. Nowadays everything can work with couple of ports opened, so it can seem "silly" to do all of this just to forward a TCP port. But it is still valuable as (for example) if servers behind the web server in DMZ do not have internet access, even when WCF is compromised, the attacker cannot use its own reverse shell to deploy what it is nowadays called an APT (yesterday backdoor). The attacker "won't see" his own machine from WCF as the DMZ provides the connection to the external world.
We have a client server application.
My application need to be changed to work via WCF service in order to receive/send data to the database (security demands).
I also need another service which be hosted at the client side and will connect the client to the WCF service on the server side connect with Https.
The WCF service on the server is in PerSession mode.
Most of my work with the server is insert / select queries.
So my design is:
Client ->windows service ->WCF server service(iis7) ->database.
This windows service act as client and as server at the same time.
Act as server: for the Client application.
Act as client for the WCF service which located at the server.
The application needs to support XP and forward operating systems with .net 4.
The windows service will need to connect the WCF service on demand only (when the client application is launched).
I need to decide in which way to implement the client windows service.
I prefer to implement it with WCF hosted service with TCP/IP, but it feels like over kill to do so.
Should I use other IPC implementations? And if so which one?
So, what is the best way to implement this Windows service?
Thanks
I do not fully understand the point why a windows service should be used on the client side in order to communicate with the WCF service. But the question was not about architectural patterns...
So, for inter-process communication I would use NetNamedPipeBinding.
You can find more information on how to decide which binding to use here.
Using a WCF service for inter-process communication does not feel overkill to me at all. Actually WCF services are quite lightweight except the host initialization process, which should not happen frequently in case of a windows service I guess. WCF provides reliability and extensibility in exchange for this tiny inconvenience.
[EDITED]
I just reread you post, and I would like to clarify some details about the hosting. You can host a WCF service in a Windows Service, which is explained here, but not the other way around. Sorry, if I misunderstood your question. And yes, TCP/IP for inter-process communication is definitely an overkill, but NetNamedPipeBinding uses shared memory according to this article, so it should be the fastest way.
i am new in wcf and started learning. i got one confusion like that i create a small wcf service and just do not host it in IIS,console apps or win service but from another apps i can add the service reference of svc file and found it is working. if wcf can work without hosting in any place like "IIS,console apps or win service " then why people would alway host wcf service in IIS,console apps or win service. can anyone tell me the reason.
people use IIS and windows services in general because they are simpler to setup and run more consistently. they can also be hosted more easily on servers where the services can be configured to start automatically, and as usually wcf is used as a server communication method it is usually this that you want to do.
hosting in console applications is generally easier to setup for simple examples for testing purposes, when you want to test your services locally.
Whilst hosting in applications as possible it's a less common scenario to use wcf to communicate between 2 applications on the same machine.
EDIT:
Your original question asked why people always talk about IIS, services etc. The point I was making was that usually wcf is used for web services, and is usually run on a server other than the local machine. Even though it can be used for inter process communication on the same machine this is not the most common use case. This is why you see a lot of examples using IIS and not too many hosting it in a Windows forms app.
I'm writing a server that needs to serve many clients. The traffic is NOT http (but rather some proprietary protocol on top of TCP). I'm not very familiar with commercial web servers such as IIS and Apache. Can anyone tell me if it's possible to write some sort of "extension" to run on top of one of these platforms so that I don't have to write the logic for the sockets? Or perhaps there is another way (not IIS or Apache) of doing it which is better?
My server is generally going to behave as a web service (gets request, queries db, sends response) however there is one scenario in which it stays connected to the client socket and sends updates at a given interval on that socket.
It seems reasonable for it to be a way to do this in a way that I'd only have to write my logic without the general logic of a server. Any ideas?
Thanks!
Good question, and its also good too look to leverage an existing web server - you get scalability and stability, effectively for free.
I've never done this myself, but it should be totally possible in IIS (i recommend v7+ for this, makes it easier).
You can set up a new web site through the administration tool, and assign it a port to listen on - this bit is pretty straight forward. You should set its Binding Type to net.tcp (this is a dropdown in the dialog to add a new website, you can't miss it).
You can then use either modules or handlers to implement the rest of your custom functionality. This article Developing IIS 7.0 Modules and Handlers with the .NET Framework is a good intro to the subject. Most of the doco out there about writing custom handlers and modules is focussed on the HTTP protocol, but there are some snippets floating around for TCP and/or net.tcp (because IIS and Apache are web servers, and web is synonymous with http). Another resource that may be useful is this: Configure Request-Processing for a Web Server (IIS 7)
Alternatively, you may consider changing your approach and do it as a net.tcp WCF service, with this you get the benefits of using IIS, the flexibility of choosing the protocol (can be statically configured, doesn't need to be compiled in), and you don't have to write handlers or modules.
I've got a WCF service on a server on one side of a firewall. I need to access the service from many workstations on the other side of the firewall. The network guys insist that all holes through the firewall are one-to-one so at the mo, I'll have to set up every workstation one by one. There could be loads and it'll get tedious and be prone to errors.
Is it possible to set up a WCF server on this side of the firewall that can in some clever way just act as a proxy to the 'real' WCF service on the other side of the firewall? If so, could you point me to some reference material?
There is a new concept of a WCF Relay service being developed for the Windows Azure "cloud" computing space. That would allow you to create your scenario fairly easily - just host some bits of your service out in the cloud.
See these links for more information:
WCF services hosted on Windows Azure
Software in the cloud: the Relay service
.NET ServiceBus: Hands-On with Relays
or search Google for "WCF Relay Service". There are also a number of new bindings specifically for these WCF scenarios.
Hope this helps.
Marc
UPDATE:
WCF v4 - to be released with .NET 4.0 later this year (2009) will include a RoutingService class which can be used in scenarios like this.
See more info about the WCF4 routing service here:
Content based routing in WCF 4
Routing messages in WCF 4.0
A developer's introduction to WCF .NET 4 Beta 1
I have a few suggestions, maybe one would work in your case:
Place the WCF service outside the firewall. If the WCF service needs to talk to the database, open the database port for the IP address of the machine running the WCF service.
Program or use code generation to create a WCF service that is simply a pass through layer
There may be some functionality in your firewall that allows you to publish an end point