 |
|
| Linux Forum Index » Linux Security » Listening network port security... |
|
Page 1 of 1 |
|
| Author |
Message |
| Kevin Colyar... |
 Posted: Fri Jun 05, 2009 7:11 pm |
|
|
|
Guest
|
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.
Thanks,
Kevin |
|
|
| Back to top |
|
|
|
| Randy Yates... |
| Posted: Sat Jun 06, 2009 1:00 pm |
|
|
|
Guest
|
Kevin Colyar <kevincolyar at (no spam) gmail.com> writes:
Quote: 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.
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 %
%%%% <yates at (no spam) ieee.org> % 'Living' Thing', *A New World Record*, ELO
http://www.digitalsignallabs.com |
|
|
| Back to top |
|
|
|
| C. (http://symcbean.blogspot.com/)... |
| Posted: Mon Jun 08, 2009 2:51 am |
|
|
|
Guest
|
On Jun 6, 6:11 am, Kevin Colyar <kevincol... at (no spam) gmail.com> wrote:
Quote: 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?
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.
Quote: 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.
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)
C. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Thu Dec 03, 2009 5:24 am
|
|