Hello Sai, I'm no expert here so i cannot give you advice on your solution but ... are you sure you need all of this? I'm thinking it should be possible to meet your security needs in an simpler way. Let's say, application-based firewalls on the dmz machines? (so only the allowed applications can't connect to the network) A more secure way to do this, I guess, could be running the services in VMware, VirtuaBox or any other virtualization software.
Another option could be some kind of VLAN with security ... Anyway , your solution might be completely right depending on your circumstances. It's my understanding that you want a proxy server routing e,g. all the incoming FTPS requests to the actual service inside your private network - this is very easy to implement with MINA if you don't have this 'no new connections from the DMZ' restriction(actually I did), but even if you used any kind of notification system to alert the other end that a new connection should be created I think this might be troublesome ; how do we change FTPServer to indicate that we should create the connection to the 'client' (or proxy) and not the other way? And is it worthy? If you didn't need such a general solution, I guess a JMS server or similar solutions ( I wonder if it's possible to do something like this with XMPP) could work. You would send messages to a local queue (or local endpoint of any kind) that would be read by the machines in the internal network. 2009/12/18 Ashish <[email protected]>: >> >> In fact most of the requests come from external network over the Internet. >> >> The idea is if a hacker makes it into the DMZ, he should not be able >> to open any connections to the internal network. Therefore, the >> firewall sitting between the DMZ and internal network is configured to >> block all incoming connections to the internal network, but allows >> connections to the DMZ from the internal network. As said before, >> systems in the DMZ will not contain any data of any sort, so there is >> not much for the hacker out there. > > Security is very important, but it seems like a situation I want to > host a Web Server, but nobody from > outside can open a connection :-( > There are ways to address security concerns. > >> Here is what I'm thinking... >> >> The Services (FTP/S, SFTP, HTTP/S) in the internal network need to >> know their DMZ gateways/proxies. >> During startup of these services, they initiate a connection or a few >> connections to the DMZ Gateway. These connections can later be used >> for bi-directional communication between the server in the DMZ and the >> actual Service sitting in the internal network. >> When a connection from external client comes in, it is routed to the >> system in the DMZ. At this point, the DMZ already has pre-established >> connection(s) so it can send some messages to the internal network >> such as a new client just connected. Based on the message the DMZ >> sends, the internal network may open one or more connections. > > Here you are talking about Connection pooling from internal network and DMZ > :-) I> > You can actually use this to transfer data between *m* client with *n* > connections where m > n > > The tricky part is you don't want to initiate connection from DMZ. May > be DMZ machine could delegate the > Connection auth check to soemone in internal network, and if auth is > successful allow the connection from Proxy to internal network. > > By any chance, is it a possibility that you allow connect request only > from known IP's to your machine in DMZ? > >> As far as Proxying goes, it is probably going to be a lot easier for >> HTTP/SFTP, but for FTP/FTPS, the data connection handling could become >> tricker. In order to handle the data connection in FTP, this Gateway >> must also filter the packets sent/received. Is that correct? >> >> Hope this all makes sense. I've read somewhere on the Internet that >> this kind of thing can be accomplished with reverse-proxying. Do you >> guys have any idea on what it means and how it can be implemented. I >> appreciate any other ideas that you may come up with. > > Not an expert on this :-( > > Would be interesting to see your product come to life :-) > > thanks > ashish >
