Search code examples
network-programmingtcpiptables

IPTable rules to restrict eth1 access to ports 80 and 443

I have a service listening to customer traffic on ports 80 and 443 of eth1. The servers hosting my service also host other admin/privileged access content on eth0 and localhost

I am trying to setup iptable rules to lock down eth1 on servers which is on same network as clients (block things like ssh through eth1/ accessing internal services running on port 9904 etc.) I also want to make sure that the rules dont forbid regular access to eth1:80 and eth1:443. I have come up with below rules but wanted to review with iptable gurus on possible issues with this rule. 

-A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth1 -j DROP
  • Do the rules above suffice
  • How does above differ from the rules found when googling
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A INPUT -i eth1 -p tcp -j ACCEPT
-A INPUT -i eth1 -j DROP
Solution

  • thanks i got this answered in https://serverfault.com/questions/834534/iptable-rules-to-restrict-eth1-access-to-ports-80-and-443 , adding it here for completeness

    The first set of rules first allow all incoming packets on your ports 80 and 443. Then it drops ALL other incoming packets (except those already accepted).

    The second set of rules first allow all incoming packets on ports 80 and 443. Then it drops incoming connections (excluding 80 and 443 that are already accepted), which are packets with only the SYN flag set. Then it allows all incoming packets.

    The difference here is what happens to your OUTGOING connections. In the first ruleset, if you attempt to connect to another server, any packets that server sends in response will be dropped so you will never receive any data. In the second case, those packets will be allowed since the first packet from the remote server will have both SYN and ACK set and therefore pass the SYN test, and any following packets will not have SYN set at all, and therefore pass the test.

    This has been traditionally done using conntrack which requires the kernel to keep track of every connection in the firewall, with a command like

    -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    that matches the incoming packet either to an existing connection, or a connection related to some other existing connection (eg FTP data connections). If you aren't using FTP or other protocols that use multiple random ports, then the second ruleset achieves basically the same result without the overhead of tracking and inspecting these connections.