The "wacky" port numbers for the httpd are to keep it off low numbered ports and run as non-root. Any suggestions for something better and how to do it?
Well, I think the only security reason to run an http server on a port other than 80 is to hide it from the general public. Port scanners can get around this hurdle quite easily though. Plus, the fact that you SNAT port 80 to that high number port, as far as I can see, makes it useless. Might as well just run the server on port 80 and save yourself some potential headaches.
ah.. "split dns" cute term... what iptables rules can be put in the firewall to bounce the traffic back? Tried it and failed :(
Split DNS has nothing to do with iptables. Its just telling your DNS server to resolve a host to a different address if the request comes from inside your network. It would be the ideal solution. Just host you http server on port 80, and split your DNS to resolve local requests to the internal IP. Problem solved.
However, if you insist on keeping the high port, you could still DNAT requests for the external IP of your http server back to the internal IP:port. So anything going to port 80 of the external IP address of your webserver thru your firewall is redirected back into your network. Try this:
Assuming: External IP of HTTP Server: 63.63.63.63 Internal IP of HTTP Server: 10.1.1.3 External Port of HTTP Server: 80 Internal Port of HTTP Server: 7777 External interface of your firewall: eth0 Internal interface of your firewall: eth1
iptables -t nat -A PREROUTING -i eth1 -p tcp -d 63.63.63.63 \ --dport 80 -j DNAT --to-destination 10.1.1.3:7777
On 1/30/06, Jeremy Fowler [email protected] wrote:
Well, I think the only security reason to run an http server on a port other than 80 is to hide it from the general public. Port scanners can get around this hurdle quite easily though. Plus, the fact that you SNAT port 80 to that
"Security through obscurity" isn't. The obscurity just makes it difficult for you to administer it. Put the stupid thing on port 80, do the split DNS that serves the internal IP to the internal machines, and if the internal IP must be changed, change it in DNS. What's the big deal?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Monty J. Harder wrote:
On 1/30/06, Jeremy Fowler [email protected] wrote:
Well, I think the only security reason to run an http server on a port other than 80 is to hide it from the general public. Port scanners can get around this hurdle quite easily though. Plus, the fact that you SNAT port 80 to that
"Security through obscurity" isn't. The obscurity just makes it difficult for you to administer it. Put the stupid thing on port 80, do the split DNS that serves the internal IP to the internal machines, and if the internal IP must be changed, change it in DNS. What's the big deal?
The only thing I saw in the original post that would preclude running on port 80 was the desire to run as a non-root user.
This is kind of a moot point, however, as most any distribution will run Apache (or the webserver of your choice) with non-root permissions. The server gets launched as root only so it can start listening on port 80, then immediately drops permissions and runs as a different user (account typically specific to distribution and/or local configuration...debian uses www-data).
- -- Charles Steinkuehler [email protected]
On Monday 30 January 2006 16:32, Charles Steinkuehler wrote:
This is kind of a moot point, however, as most any distribution will run Apache (or the webserver of your choice) with non-root permissions. The server gets launched as root only so it can start listening on port 80, then immediately drops permissions and runs as a different user (account typically specific to distribution and/or local configuration...debian uses www-data).
But there is always a possibility of a bug or exploit prior to dropping root privs... One thing that has always seems missing is the ability to set port "owners"...
On 1/30/06, Luke-Jr [email protected] wrote:
But there is always a possibility of a bug or exploit prior to dropping root privs... One thing that has always seems missing is the ability to set port "owners"...
Huh? Either you set up a daemon to listen on a port directly, or configure inetd to handle it. In either case, you control the userid of the daemon that 'owns' the port.
-
Charles Steinkuehler -
Jeremy Fowler -
Luke-Jr -
Monty J. Harder