Your New Firebox: Day 8
by Fred Avolio, President, Avolio Consulting, Inc.
Your Firebox was installed a week ago. It’s been humming along, red lights flashing, doing its job. You’ve dealt with random glitches due to some needed port or service being erroneously overlooked, and, as far as you can tell from your e-mail and voice mail, everyone is happy.
It’s Monday morning. You pour yourself a cup of coffee on top of last week’s dregs and sit down with the one-page plan you penciled out before going home Friday: “Firebox: Things to Do.”
What? You don’t have a plan? No worries. That’s what this article is about.
Why bother?
No matter who installed your Firebox, there is never enough time during the initial days after an installation to explore everything you want to or should examine. You encountered routing problems, found out about "critical" services that no one knew existed, and basically performed "business requirements" verification the only sure-fire way you can: by just turning the thing on and seeing who complains about malfunctions. You know that you took some shortcuts. You made some last-minute changes, with little thought, just to make things work. Security and usability collided, but you persevered.
Now it’s time for some fine-tuning. You want to make sure you did the installation right and have your firewall configured as best you can to support security and requirements. You want to become one with your new red friend, the Firebox.
Filters and proxies
Start with proxies. This is the Number One area we look at, by design. In a previous LiveSecurity article ("Foundations: What Is a Proxy?"), Steve and Scott explained the superiority of application gateways, or proxies, from a security standpoint. But your initial tendency might have been to take the easier, but less secure, path of using packet filters instead of proxies. So, the first thing to do is to go through each of the filters you set up, and see if there are corresponding proxies you can use instead. Some suggestions:
-
SMTP. I wrote about this before ("Introduction to WatchGuard’s SMTP Proxy"), so I won’t go into detail here. There are many good reasons why you should proxy SMTP, including content-type screening, attachment filtering, header stripping, and spam control. These are all incredible wins. If you do nothing else on this list, proxy SMTP.
-
HTTP. The proxy gives you fine-grained control over HTTP, allowing you to make decisions based on URL, to decide whether to allow Java through your firewall, to screen Web page content type, and more. Definitely look into this, and its WebBlocker capabilities.
-
DNS. Firebox System 5.0 includes WatchGuard’s new DNS proxy. Domain Name Service (DNS) attacks have become prominent enough to appear in the SANS/FBI "Top 20 Vulnerabilities" list (under "BIND weaknesses"). There have been, even recently, vulnerabilities in some popular, widely used DNS server implementations. The DNS proxy protects you from such potential exploits by verifying that a DNS request conforms to established standards and protocols. Since most DNS attacks so far have utilized malformed requests, this proxy prevents an entire class of attack from hurting your network. Possibly, you do not run a DNS server, but in all probability you run at least a caching server inside your network. So, try using the DNS proxy.
As I said in the "Introduction to WatchGuard’s SMTP Proxy," you can put a proxy in place so that logically it stands between only your individual desktop system and the Internet. This allows you to experiment and get it working the way you want before putting it in place for the whole network. Yes, this means you can have, for example, both Filtered-SMTP and SMTP (proxy) configured on one Firebox. (I did this for testing: Filtered-SMTP had "Incoming From" set to "Anywhere," and "To" set to my mailhub, and proxied SMTP had "From" configured to the address of my test machine outside the Firebox.)
Egress filtering
You set up your Firebox with the "Outgoing" filter set to allow packets to go from any internal host to any external host, didn’t you? Yet a basic security axiom is, "that which is not expressly permitted is denied." Okay, technically you followed this, but by setting the "Outgoing" filter in this way, you have said, "I expressly allow ANYTHING that originates on the inside to go anywhere outside." If you are serious about security, you will get rid of this and specify the particular services and ports required to be allowed from inside to out. So, you start with denying all of them. (I mentioned the importance of doing this in my article "One Size Never Fits All," and Dave Piscitello explains further in "Beware of Back Channels.") You don’t have to do this on Day 8, but start thinking about it and planning for it. For example, you’ll certainly want to use the SMB filter and make sure you set "Enable and Deny" in both directions. You’ll thank us for this one day.
Read your logs, Step 1
Aren’t you supposed to do this daily? Well, yes. But on Day 8, you’re going to really get to know your logs. Assuming your site is not under attack, get another cup of coffee, load the logs onto a notebook PC, get to a quiet place away from the telephone, and step through the logs, starting from some random point. (Yes, "random." You won’t look at the entire log. You just want a good-sized sampling.) Do this armed with the LiveSecurity Service bulletins (all accessed from the Learn about Logging page) that explain what the different fields mean. Do you see anything strange? Are there entries you don’t understand? Mark them and move on. The goal is not for you to understand each and every entry that might come along in a million years, but rather to get really familiar with NORMAL on your Firebox, so that ABNORMAL will jump out at you. Also, now during the quiet is a good time to find out what you are unsure of or don’t understand. At least it’s better timing than during or just after a cyber-attack.
Read your logs, Step 2
Run a port scan against your Firebox from the outside. There are some free port scanners as well as commercial scanners. (Look on the Web for nmap, ISS, and CyberCop Scanner. LiveSecurity articles about such resources include "Automated NT Vulnerability Testing," Automating NT Auditing, Affordably," and "Introducing nmap, Scanner of Choice.") Before you do the port scanning, get permission. And never port scan someone else’s system without written permission. It’s considered an aggressive act.
First, you do this to see if your security policy on paper (what you allow and deny) matches how you set up the Firebox the week before. Sometimes we get things wrong; sometimes the Mess Up Elves visit when we’re not around, and break things. Second, you want to ensure that the Firebox notices the scan. All sorts of attempts should show up in the log if you have logging set up correctly.
Day 9
Even if you get all of this done on Day 8, you’ll find that you have to start another “To Do” list on Day 9. You discovered some entries in the log file you didn’t fully understand. When you added the HTTP proxy, automatic downloading of virus definitions stopped working. And what the heck process keeps trying to escape out on port 137?
Though perhaps you did not, in fact, “become one with your Firebox,” the point is, you did get to know it better. You’ll have other opportunities to learn, especially if you invest some time. Scheduling structured time, early on, will give you a jump on the bad guys. (No, I don’t mean your users!) ##
Was this article useful to you? Is there a security topic you want our experts to tackle? Let us know at lsseditor@watchguard.com.
To browse all the LiveSecurity articles, visit the LiveSecurity archive.
Copyright© 2001, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.