Would drop rules at the top of input chain affect other protocols/traffic?

JockVSJock · 08-10-2015, 04:45 PM

Still working on wrapping my brain around IPTables.

However I've noticed this issue. Alot of the rules that I've inherited have DROP rules, say at the beginning of the the INPUT Chain, such as:

Code:

1  0.0.0.0/0.0.0.0/0   port 136 DROP 
2  0.0.0.0/0.0.0.0/0   port 25 DROP
3  ACCEPT rules follow

I'm having issues trying to setup traffic for ports 5500, 5501 and 5502 and I'm wondering if having these two DROP rules for rule #1 and #2 would impact it?

If so, then why?

unSpawn · 08-11-2015, 04:05 PM

Please post complete (but obfuscated if necessary) 'iptables-save' output instead?

JockVSJock · 08-12-2015, 09:48 AM

Quote:

Originally Posted by unSpawn

Please post complete (but obfuscated if necessary) 'iptables-save' output instead?

Here they are, with the last two octets obfuscated. I've bolded the DROP rules for the INPUT Chain. Again, my thinking is that the drop ones should be towards the end of the chain.

Code:

# Generated by iptables-save v1.3.5 on Tue Aug 11 08:23:12 2015
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:INPUT-XXX-SUBNET - [0:0]
:INPUT-XXX-SUBNET - [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -p udplite -j DROP
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -s 143.83.XXX.XX -p tcp -m tcp --dport 8505:8535 -j ACCEPT
-A INPUT -s 143.83.XXX.XX -p tcp -m tcp --dport 8400:8404 -j ACCEPT
-A INPUT -s 143.83.XXX.XX -p tcp -m tcp --dport 8505:8535 -j ACCEPT
-A INPUT -s 143.83.XXX.XX -p tcp -m tcp --dport 8400:8404 -j ACCEPT
-A INPUT -s 143.83.XXX.XX -p tcp -m tcp -j ACCEPT
-A INPUT -s 143.83.XXX.XX -p tcp -m tcp -j ACCEPT
-A INPUT -s 128.XX.XXX.XXX -p tcp -m multiport --ports 80,443,591,8443 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 9898 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 9898 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 1521 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 1521 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 1521 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 1521 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p udp -m udp --dport 514 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 1158 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m multiport --ports 80,443,1158,5501,5502,5503 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 1158 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 5501 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 5502 -j ACCEPT
-A INPUT -s 143.83.XXX.XXX -p tcp -m tcp --dport 5502 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 13 -j DROP
-A INPUT -j INPUT-XXX-SUBNET
-A INPUT -j INPUT-XXX-SUBNET
-A INPUT -j RH-Firewall-1-INPUT
-A INPUT -s 127.0.0.1 -p tcp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j DROP

unSpawn · 08-12-2015, 05:33 PM

Quote:

Originally Posted by JockVSJock

(..) my thinking is that the drop ones should be towards the end of the chain.

0) Rule order seems off as you would usually start with loop back, then ESTABLISHED,RELATED etc, etc.
1) You've got INPUT-XXX-SUBNET targets that aren't used.
2) If these last two .XXX.XXX octets are the same you can combine single port rules with "-m multiport --dports start:end,other,other"
3) You've got a default DROP policy so all you generally speaking would need is explicit ACCEPT rules.
*Also next time please use [CODE][/CODE] tags instead of quote tags, thanks.

JockVSJock · 08-12-2015, 06:45 PM

Quote:

Originally Posted by unSpawn

1) You've got INPUT-XXX-SUBNET targets that aren't used.

Thanks for the feedback, I will start to implement these suggestions.

I don't understand this statement, the previous admin setup chains for two subnets, and there are rules under the INPUT chain that pushes traffic into it. Is this not being used?

Quote:

Originally Posted by unSpawn

2) If these last two .XXX.XXX octets are the same you can combine single port rules with "-m multiport --dports start:end,other,other"

This is one of the problems I face. THe last admin instead of assigning single port rules to say a subnet, this admin was doing it on an ip basis. Of course these ips belong to desktop computers, which are controlled by DHCP and with the changing addresses, this would cause chaos, which I'm still trying to get on top of. However your suggestions are helping with the cleanup process.

unSpawn · 08-14-2015, 06:09 PM

Well I remember inviting you in an earlier thread to post your cleaned up rule set for comments...

JockVSJock · 08-18-2015, 03:11 PM

Quote:

Originally Posted by unSpawn

Well I remember inviting you in an earlier thread to post your cleaned up rule set for comments...

True.

For some reason, where I work is blocking that website, so I found a work around: http://linuxtopia.org/Linux_Firewall...les/index.html

Hopefully I will be submitting a few to critique.