Fumbling with Iptables

forrie · 08-05-2009, 05:09 PM

I've been having a difficult time trying to get this configuration to work properly. I'm learning iptables, from FreeBSD/PF. I've read tutorials, books, etc, and I can't seem to figure out why this isn't working.

The primary motivation behind this was to to limit access to port 22 (we're getting slammed with dictionary attacks) - but generally, we need the below configuration to work.

With this file, installed in /etc/sysconfig/iptables, people from the outside can get to port 22.

It's possible the sheer amount of time I've spent on this has me overlooking something very simple. So a second, more experienced pair of eyes is needed.

I'd appreciate any feedback.

When I removed the line:

-A RH-Firewall-1-INPUT -i eth0 -j ACCEPT

It seemed to work, but we ended up having troubles with the other ports, so I just reverted to this version.

Thanks!

(obviously, the x's and W's are here for illustrative purposes ;-))

Code:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT 
-A FORWARD -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -i eth0 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -s x.x.x.0/255.255.255.0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -s x.x.x.0/255.255.255.0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -d x.x.x.x -p tcp -m state --state NEW -m tcp --dport XXXX -j ACCEPT 
-A RH-Firewall-1-INPUT -d x.x.x.x -p tcp -m state --state NEW -m tcp --dport XXXX -j ACCEPT 
-A RH-Firewall-1-INPUT -s x.x.x.0/255.255.255.0 -p tcp -m state --state NEW -m tcp --dport 3333 -j ACCEPT 
-A RH-Firewall-1-INPUT -s x.x.x.x -p tcp -m state --state NEW -m tcp --dport VVVV -j ACCEPT 
-A RH-Firewall-1-INPUT -s x.x.x.x -p tcp -m state --state NEW -m tcp --dport WWWW -j ACCEPT 
-A RH-Firewall-1-INPUT -j DROP 
COMMIT

win32sux · 08-05-2009, 05:24 PM

Your objective is to allow inbound connections to port 22 only from certain IPs, right? That eth0 rule would send to ACCEPT any packet which arrives on that interface, thereby making all the other ACCEPT rules redundant as far as that interface is concerned. I'd get rid of that rule, then add some DROP rules after every exception IP rule. Example:

Code:

-A RH-Firewall-1-INPUT -s x.x.x.0/255.255.255.0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -s x.x.x.0/255.255.255.0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j DROP

forrie · 08-05-2009, 05:27 PM

You are correct. I noticed that and when I dropped that rule, suddenly other people couldn't get in (even from the named networks we want to allow).

The other ports are for some video stuff.

Thanks for your help!

forrie · 08-10-2009, 12:25 PM

The rules were auto-created via the system-config-firewall too, or something before me.

If I place an allow rule for each port in the chain, then end it with:

-A RH-Firewall-1-INPUT -j DROP

Shouldn't that take care of the problem. I wouldn't think I'd need to add DROP for each rule in between.

I think removing that -i eth0 rule may solve the problem... but we had some issues with video not rolling before when I made that change.

win32sux · 08-10-2009, 05:14 PM

Quote:

Originally Posted by forrie

The rules were auto-created via the system-config-firewall too, or something before me.

If I place an allow rule for each port in the chain, then end it with:

-A RH-Firewall-1-INPUT -j DROP

Shouldn't that take care of the problem. I wouldn't think I'd need to add DROP for each rule in between.

I think removing that -i eth0 rule may solve the problem... but we had some issues with video not rolling before when I made that change.

Yeah, it's nice to be able to handle everything with ACCEPT rules, and only a DROP rule at the end (or a DROP policy). In the example I posted, the DROP only serves to make sure that any other rules after that don't need to deal with the unauthorized 22/TCP packets. This was due to the symptoms you seemed to be describing (that unauthorized IPs were still able to connect to port 22) being indicative of the 22/TCP packets being sent to ACCEPT by later rules. Since you've replaced the port numbers in the other rules with weird letters, I couldn't really be sure what exactly was going on, so I played it safe.