Best Pratice for Troubleshooting IPTables
So the system admin that I took over for has been using Unix/Linux in some for form around 30 years.
Since taking over, I always seem to run into issues when setting up new users to access Linux servers or say installing new software and its trying to scan or access other Linux servers. When talking to my manager, he seems to think that the previous sys admin has the firewall rules too tight and makes it hard to work with. Right now I'm trying to get a balance between useability and security.
So I'm wondering if others can advise on how to troubleshoot on IPTables. I am aware of how to setup logging for IPTables and I'm also reading the book Linux Firewalls to get a better idea, however I wanted to reach out.
thanks
Responses
Hi Christopher,
I have personally found having logging rules prior to any drop rules and then centrally logging this to a log server the best method to determine if traffic is being dropped in your environment. Being able to combine the firewall logs on a central log server/aggregation point makes it easier to troubleshoot the complete flow of traffic.
For a longer term strategy, I have found the Puppet firewall module is excellent for managing iptables. Creating 'firewall profiles' to match application profiles / deployment types makes rule management easier and more predictable for other admins.
Guru
6435 points
"Too tight" typically just means "I don't understand it". Realistically, you should be setting, at the very least, your INPUT filter's default policy to DROP. This is a "secure by default" stance.
That said, if you want your iptables rules to be more self-documenting, adding comments to your rules with the comment module can really assist others in understanding what you've done. For example, to let people know that your port 22 exception is for SSH, you could have something like:
-A INPUT -m tcp -p tcp -m comment --comment "Allow inbound SSH" --dport 22 -j ACCEPT
Makes life a lot easier for someone coming in cold to figure out what's going on.
If you're under the suspicion that there's missing exceptions, you can tack on - as the last rule to INPUT/OUTPUT/FORWARD/etc - a logging rule. The logging rule will only get activated if nothing before it matches.
Note: packet logging isn't generally something you want to leave on "forever" as a host with lots of network activity can overflow their logs.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.