Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Given a typical webserver, with Apache2, common PHP scripts and a DNS server, would it be sufficient from a security perspective to bind administration interfaces like phpmyadmin to localhost and access it via SSH tunnels?

Or could somebody, who knew eg. that phpmyadmin (or any other commonly availible script) is listening at a certain port on localhost easily forge requests that would be executed if no other authentication was present?

  1. In other words: could somebody from somewhere in the internet easily forge a request, so that the webserver would accept it, thinking it originated from 127.0.0.1 if the server is listening on 127.0.0.1 only?
  2. If there were a risk, could it be somehow dealt with on a lower level than the application, eg. by using iptables? The idea being, that if someone found a weakness in a php script or apache, the network would still block this request because it did not arrive via a SSH-tunnel?
share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

... could somebody from somewhere in the internet easily forge a request, so that the webserver would accept it, thinking it originated from 127.0.0.1 if the server is listening on 127.0.0.1 only?

It is possible, but extremely unlikely. Think about it this way: When a process is listening to a port bound to 127.0.0.1, an incoming IP packet will reach the process only if the packet's destination address is 127.0.0.1. Unless your attacker has subverted every router between himself and your server, there's no way such a packet would ever be routed to your server, since 127.0.0.1 is not normally a routable address.

But suppose the unthinkable happens, and a forged packet to 127.0.0.1 arrives at your server. In that case, the packet would have to have arrived over a network interface that is not the loopback interface (lo). Since, by convention, all legitimate packets destined for 127.0.0.0/8 must arrive over the lo interface, it is easy to identify and block forged packets to 127.0.0.0/8 with a simple iptables rule:

-A INPUT -d 127.0.0.0/8 ! -i lo -j DROP 
share|improve this answer
    
Thank you very much. I am going to play around with your suggestion on a test server. Currently trying to find out, if I could "earmark" packets coming to localhost via SSH as opposed to hacked web scripts on the public webserver. Regarding the probability: Well, my servers are located at common low-cost/no-frills providers. With one provider (that did not do much filtering or network security) I already experienced the case that somebody inside the subnet was trying to capture other peoples traffic. –  Martin Jun 18 '12 at 16:36
add comment

If you changed the bind address of a process to 127.0.0.1, this should be enough to prevent any access remotely from any other machine. If you try to connect, you will get connection refused. This will appear (from remote machines perspective) exactly like the process is stopped and the port is closed.

For added security, you can add iptables rule(s) to block these port(s) from remote addresses. This will prevent you from accidentally enabling remote access by changing the configuration (by mistake or after an upgrade).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.