David, Thanks for your comments. Even I'm not an expert in this area by any means, and am still trying to figure things out. Some of the MFT vendors have already implemented this feature. Not sure how they exactly do it. The basic idea remains same, where the actual service in the internal network initiates one or a few connections to the system in the DMZ (let us call it Proxy for now). These connections stay alive as long as the services in the internal network are alive. These connections possibly could use a proprietary protocol to transmit proprietary commands such as a new connection came from IP x.x.x.x. When this message is sent from the Proxy to the internal system, it could possibly create a new connection to the proxy and mark it as the connection for client x.x.x.x. Any subsequent commands such as LOGIN, DOWNLOAD etc. received by client x.x.x.x would be proxied to the internal server on the pre-established connection for the very same client. Responses from the internal server are proxied back to the original client with or without any modifications. An example where a response modification is necessary is when a data connection need to be established for the FTP service (PASV or PORT commands). Unfortunately, having a dedicated connection for each client as explained above may not scale well. I'm thinking out loud here :). Any other comments/ideas are welcome.
Regards, Sai Pullabhotla On Sun, Dec 20, 2009 at 3:52 PM, David Latorre <[email protected]> wrote: > 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 >> >
