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 dvl...@gmail.com 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 paliwalash...@gmail.com:
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
