1

I have a service (Elasticsearch behind proxy) 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.

-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 -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
0

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.

| improve this answer | |
  • Thanks very helpful! I had a question In the first ruleset also, wont outbound connections still work on ports 443/80? Am i missing something? – dejavu013 Feb 24 '17 at 20:07
  • When you connect outwards, your program picks a random high port to connect from. That random port # will be the incoming packets' destination port. – DerfK Feb 24 '17 at 23:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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