Listening network port security

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I'm trying to restrict access to a listening port, either a listening
socket server program I write or an ssh tunnel, from one server to
another.  Is there a way to restrict connections to that port by PID
or executable path?

My scenerio:
  I have a database server in my internal network and a web app on
apache in a dmz.  I would like to establish perhaps a reverse ssh
tunnel from the database server to the web server in the dmz and
listen on a port that my web app can use.  However, that leaves my
internal db server vulnerable if my apache box gets owned.

I can't think of a way to restrict communication on that listening
port to just my web app.

Any ideas would be appreciated.


Re: Listening network port security

Quoted text here. Click to load it

Can't you issue an iptables command on your database server machine
to restrict traffic on that port?

I'm just guessing - don't really know how to use iptables.
%  Randy Yates                  % "Rollin' and riding and slippin' and
%% Fuquay-Varina, NC            %  sliding, it's magic."
%%% 919-577-9882                %

Re: Listening network port security

Quoted text here. Click to load it

It'd be incredibly difficult to do this if both client and server
ports were on the same box - on seperate machines......? Forget it.

As you suggest, you could do it with an SSH tunnel - but that creates
a dependancy on the tunnel itself. Using something like stunnel would
mean that your system could reciover more gracefully in the event of
an outage as long as the SSL connection was still initiated from the
same side as the application connection - but not for a reverse
connection. Regardless, all these methods still offer very little
benefit over restricting the listening port to a single IP address.

Quoted text here. Click to load it

If your apache box gets compromised then there's nothing you can do at
the network level to prevent access to the database. SSL, SSH, reverse
port conenctions - none of it will help - but it will make your system
less reliable and more complex - which in itself undermines security.

You could mitigate the effect by doing away with the database
connection across the networks by exposing data access via a
webservice (e.g. SOAP) but obviously there may be a lot of code
changes required for that. Another approach would be to keep a second
database in the same network as the webserver and publish changes out
from the internal database and back again via a controlled manner -
MySQL replication would make this relatively simple but again it
requires lots of code changes.

If you're going to this trouble then you must already have EVERY OTHER
POSSIBLE SECURITY PROBLEM covered? You've got NIDS and HIDS running in
the DMZ, DDOS detection on your firewall? If not, then you'll get a
lot more mileage out of beefing up the security elsewhere than adding
Byzantine complexity to your application stack.

IMHO, the only things worth considering in addition to restriction by
IP address are:
1) a non-reversed tunnel
2) IPSEC (which can be a PITA)
3) encrypted ident

(unless you have a DBMS which supports its own encryption - in which
case using it is equivalent to option 1 but often simpler to setup)


Site Timeline