If you installed your company firewall months or even years ago, you probably were more focused on just getting the thing in and making it work. Now that you've got some experience and confidence with your firewall, you should take advantage of the slow days of summer to revisit your configuration and see if there is room for a tune-up.
Every firewall is different and has different capabilities, but let's take a look at three common areas that don't get any attention when you're in a hurry -- but which can improve your security and security awareness.
MONITOR AND BLOCK OUTBOUND NETWORK TRAFFIC
Most companies operate on a fairly relaxed basis, with a security policy that follows the "nothing gets in but anyone can go out" model. When you're getting started, this is the fast path to success. Once you're set, though, it's time to revisit this policy. In large enterprises, all outbound traffic is strictly controlled, and typically forced through a proxy server of some sort to provide content filtering and threat mitigation (such as antivirus scanning). You may not need that in a midmarket network, but you probably are letting more traffic out than you should.
The easiest example is outbound SMTP (email traffic). In a typical company, the only system that should be legitimately sending email from the company network is the company's mail server, whether Exchange or some other product. There's rarely any reason to let people inside the network make outbound SMTP connections directly from their desktops or laptops. The biggest reason to block outbound SMTP traffic from end users is to block infected PCs from acting as spam robots. One of the main reasons hackers want to infect PCs is to turn them into robot armies (usually called bots).
If you block outbound SMTP traffic from all but your official email server, you'll help to neutralize the negative effects from infected PCs. And, if you follow my next step, you'll get an early alert when one of the PCs on your network is infected.
Controlling outbound email is the low-hanging fruit, but there are other benefits to being stricter on outbound traffic. Should people be using your internal DNS (domain name system) or NTP (network time protocol) servers? If so, then block that outbound traffic to help enforce proper configuration. Do you have devices such as printers or UPSes that should never be talking to the Internet? Block outbound traffic from that portion of your network, and you'll tighten your security profile.
SYSLOG FILTERS CRITICAL FIREWALL LOG DATA
Firewalls generate tons of data about what's happening on your network, and chances are you aren't looking at any of it. The reason is probably pragmatic: you can't sort out the wheat from the chaff. What's interesting, and what's not? What should you look at and what can you skip?
You have two options here. One is to tune the firewall itself, so that it only tells you about what's interesting. That may work, and it may not --most firewalls, in my experience, have insufficient knobs to limit the logs to the interesting stuff. The other option is to send the traffic to a tool, such as a SYSLOG server or SEM (Security Event Manager), and then further filter the traffic so you only see what is interesting to you.
Telling you to install a SEM is probably counter-productive right now, although SEMs are a great way of filtering your security logs. So I'll suggest putting in a SYSLOG server and then writing filters for the interesting traffic. For example, you don't want to see "denied" traffic incoming to your network, because you have that kind of traffic all day long, there's nothing you can do about it, and it isn't worth looking at. However, you definitely do want to see denied outbound traffic because that indicates a problem, such as an end user who isn't following policy, someone inside your network behaving badly, or an infected system.
In the same vein, look for alerts, such as reaching limits of sessions or memory (typically a sign of an infected system generating massive outbound traffic), denied logins to the firewall from the inside, and any other kind of severe error message your firewall has generated.
The easiest way to trim this traffic is to summarize it all and then start writing filters to drop out the information you know you don't want, such as allowed connections that are following security policy. After a few hours of looking at logs and dropping the uninteresting parts, you'll find that the unusual and worthwhile information pops out at you quite quickly.
RATE LIMITING CONTROLS EXCESSIVE INBOUND, OUTBOUND TRAFFIC
Most firewalls have some sort of denial-of-service protections, also called rate limiting. These features keep track of the velocity of connections through the firewall and can limit future connections when the traffic is excessive. Usually firewalls have different limits for inbound and outbound connections, as well as different types of connections (such as UDP connections, typically for tools such as DNS, or TCP connections, which would be more common in email and Web traffic).
For example, a midmarket company's mail server might see about 1,000,000 incoming (from the Internet) connections a day, counting spam connections, if each of 1,000 employees received 100 messages a day. (Your email server logs should tell you the correct number; I'm just using 1,000,000 as an example.) That's about 10 connections per second. Set your firewall to block more than 20 incoming connections per second and you can both cut down on the amount of spam you get (since spammers often hammer mail servers when they're delivering their evil payloads) and ensure your own mail server doesn't get a sudden burst of mail it can't handle.
Very high outbound connection rates are another potential sign of problems, since infected desktops and laptops often have very high connect rates towards the Internet as they attempt to re-infect or attack other companies. Using the built-in limiting features of your firewall to help block peak connections both inbound and outbound can shield you from inbound attacks and alert you when internal users are misbehaving, whether intentionally or because of a virus infection.
Joel Snyder is a senior partner at Opus One, an IT consulting firm specializing in security and messaging.
Send comments on this technical tip firstname.lastname@example.org.
This was first published in July 2009