iptables firewall only allows internet traffic if source port of 80 is allowed

Question

I am configuring an iptables firewall, currently just to allow http and https traffic. It is working but under a particularly strange rule - I must allow incoming connections with a source port of 80.

That doesn't make sense to me shouldn't incoming traffic have a destination port of 80?

Below is an example of my config. If I remove the rule that allows incoming traffic on port 80 then I can't access google or anything else, active the rule and it all works. Shouldn't web servers be listening on this port and sending from a random port?

# Set all major commands to DROP by default
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Allow HTTP and HTTPS
# Need to consider limiting to ESTABLISHED, RELATED for OUTPUT
# consider NEW for INPUT
# configure source ports in range 1024:65535

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 80,443 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT

# ping from inside to outside
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

# allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Outbound DNS
iptables -A OUTPUT -p udp -o eth0 --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 -j ACCEPT

# Logging before Drop for troubleshooting
iptables -A INPUT -j LOG
iptables -A INPUT -j LOG

Solution 1

If the web server responded to your request from a random port, then how would your OS know to send that traffic to your browser?

Here's how it works, in general:

1. Your browser wants to make an outgoing connection to a server, so it asks the OS for a socket.
2. Unless the browser is doing something weird, it doesn't care what port the socket it gets is using on your end, so the OS assigns a random free one.
   • For this example I'll use 53904 as our random browser-side port.
3. The browser asks the OS to connect this socket to the server's IP (usually found by DNS) and listening port (usually 80 for plain-text HTTP or 443 for HTTPS; occasionally something else specified in the URL).
   • For this example, we'll assume that you're doing plain-text HTTP via port 80.
4. The OS sends a TCP connection (SYN) request to the destination the browser specified, with the following details: source IP: your network interface's IP; source port: 53904; destination IP: the server's IP; destination port: 80.
5. The TCP request gets routed through the network(s) between you and the server.
   • Network Address Translation (NAT) may change the source IP (to the router's IP) and port (to a random one that the router maps to the original connection it received from you), but won't affect the destination.
   • The router doing the NAT will listen on the new "source" port and translate response traffic into responses to your computer's original request.
   • For simplicity, I won't go into NAT any more in this example; we'll just assume that both your address and the server's are unique publicly-routable IPs.
6. The request arrives at the server's port 80 (or 443 or whatever). The web server process has already told the server's OS that it would like to accept incoming TCP connections on that port.
7. The server's OS creates and sends an acknowledgement (SYN-ACK) in response. It has to have the same details as the incoming packet except that the source and destination are reversed: source IP: the server's IP; source port: 80; destination IP: your IP; destination port: 53904.
8. This response wanders back across the Internet to your computer, where your OS has been listening to see if it gets the SYN-ACK on port 53904 from that IP address.
   • There's also a thing called "sequence numbers" and "acknowledgement numbers" that are used to verify that the connection is the one it's supposed to be and prevent some other computer from faking that it's the server you're trying to talk to.
   • Of course, this protection against faking (spoofing) the server only works if the attacker isn't able to observe/intercept the traffic you are sending. A significant part of SSL/TLS, the thing that adds security to HTTPS, is a more-robust mechanism for authenticating the server.
9. Your OS gets the SYN-ACK and responds with its own ACK, reversing the source and destination again (or just re-using the original source and destination; same thing).
10. The connection now having been acknowledged by both sides, your OS lets your browser know that it can now send data through the socket.
11. The server's OS, now having received your machine's acknowledgement (and verified the sequence numbers), creates a new socket for the web server software to use. This socket is used to communicate traffic for the just-completed TCP connection, and is bound to port 80 on the server's IP and to port 53904 on your IP; it will both receive data on, and send data from, port 80.

From there, the browser and the web server speak HTTP to each other over that TCP channel. I'm not going to get into the details of that, though. This is all just to illustrate why your firewall does need to allow inbound packets that originated from a server's port 80 if you want to be able to get HTTP responses from that server.

Solution 2

You write

..If I remove the rule that allows incoming traffic on port 80 then I can't access google or anything else, active the rule and it all works. Shouldn't web servers be listening on this port and sending from a random port?

No. www.google.com would send from port 80 to your random port.

Similarly, any web server you run wouldn't just listen on port 80, it would send packets with source port of 80.

And of course, your web server wouldn't be communicating with google web server.

And so whoever accesses your web server will have a random port open his end

And when you access Google you have a random port open your end.

Your confusion is in not realising that INPUT is not to do with an "incoming connection" specifically. It is all packets coming in.. including packets coming in from an outgoing connection.

So your server listening on ports 80 and 443

I'm no expert but

I'm going to give a common set up, as described in "towards the perfect ruleset" (or as used by those that point to it)

http://inai.de/documents/Perfect_Ruleset.pdf

-Allow everything out

-Allow in all established and related (related includes new connections from it such as what the old protocol FTP requires - not that you're using FTP. and it includes ICMP errors )

-Allow in all packets to your server ports.

So your policies would be

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

using -m conntrack is and --ctstate is newer than -m state and --state

And besides policies, your rules would be

iptables -A INPUT -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 

iptables -A INPUT -p tcp -m multiport --sports 80,443 -j ACCEPT

Also that style you used and that i've written above keeping with your form, is command line style, but some might say it's more professional to use an iptables script. and a line would read -A input rather than iptables -A input. And iptables-save >file and iptables-restore < file.

Comments

[barlop]

I haven't read your entire answer but your last paragraph has some superfluous information making things far more specific than it should be and opens up a possibility that is might not even make sense. You wrote "your firewall does need to allow inbound packets that originated from a server's port 80... if they are part of a TCP connection that your machine initiated, at least." <-- That's a weird "if" for you to add, since, in what situation would or could a web server initiate a connection to a person's machine, and what would that even mean?