Here are some tips for managing your firewalls. Just having a firewall isn’t enough. You have to maintain the firewall. You have to monitor the logs. And you have to track changes made to the firewall.

Michael Farnum took it a step further in his tip-of-the-day by proposing an extra layer of protection for the ports you do allow out of your network, by using a proxy.

As a side note, I’m used to working with firewalls that have an implicit “deny all” at the end of each ACL so I normally start my ACL’s with explicit denys of P2P and IRC, followed by permits of legit traffic. However, he has a good point that to be thorough, end your ACL’s with a clean-up rule of ‘deny all any to any’.

Now on to the tips:

1. Configure NTP
2. Configure egress filtering
3. Build a syslog server to receive logs
4. Use CVS for change control

Configure NTP

For incident response you want to have all your logs showing a consistent time line. To do this you should have all your devices sync time with an NTP server. You can either have all your devices go to public time servers or you can build your own NTP infrastructure. Either way you’re going to be doing the investigator a favor by having all your devices reporting alerts in the same time line.

Use egress filtering

I’m constantly surprised how many shops don’t take advantage of egress filtering. This not only helps reduce the amount of damage done on your network but also helps protect the world from compromised hosts on your network.

A lot of bots use IRC for command and control (C&C). Once a host is compromised and a bot is installed, the bot phones home to the IRC channel. For this reason, I always explicitly block access to the default IRC server ports; TCP:6661-7000. Now when a host on my network gets compromised and tries to phone home to an IRC server using a default port, it won’t succeed and I will likely avoid further compromise.

Build a syslog server to receive all alerts

Monitoring your firewall logs is a basic step in maintaining the firewall. It will help you tune the firewall by identifying blocked ports that legitimately need opened as well as identifying how the bad guys are trying to get in.

There are countless *nix solutions that are very flexible and provide a lot options. I’ve deployed syslog-ng which provides more control of how the logs are written, etc. Its definitely worth checking out.

Once you have all of your firewall logs being sent to the same place you can do some event correlation, automatic log parsing, etc. I once built a crude-but-effective IDS that utilized shell scripts to grep through firewall logs and send email alerts based on firewall alerts. When a host inside was compromised by some new worm that scanned for port XYZ, the firewall logs showed that and we were alerted to the compromised host long before antivirus vendors even named the thing (hmmm, maybe another idea for a security tip).

Using CVS for change control

If you have multiple admin’s monkeying around with your firewall you have to have some sort of change control. One of the things I learned from my CISSP mentor was to use CVS for this. Keep a text file of the changes you make to the firewall along with a brief description and date and check it in to CVS. You can also check in configuration backups and notes to share with the other admins.

Again, there are plenty of *nix solutions out there and loads of free CVS clients (I use a mac for a laptop so its built in, thank you very much).

Another cool thing you can do is set up an SSH tunnel to protect your CVS traffic. Putty works great for this (hmmm, an idea for a future tip?). Just launch putty, connect the SSH tunnel, then push your CVS traffic through it.

For more information about this topic

• No Related Post