Another brick in the (fire)wall (Top 10 list for those who run a firewall)

Well, it's almost firewall review time, so it seemed like a good idea to inflict this stuff on everyone else, so that you can share in the joy (or misery -- take your choice) of the process.

Firewall policies tend to be as varied as the organizations that implement them, but there are several general guidelines that make the process a little more structured and help prevent "rule rot" from setting in too deeply. Most of you probably immediately understood what rule rot was even if you've never heard the term before. For the rest of you though: Rule rot is what happens when new rules, exceptions, objects, etc., are applied to a firewall without first looking at what is already in place to maintain a consistent structure. At some point someone realizes that it's become an unmanageable nightmare.

I'm making the assumption of a GUI interface such as Checkpoint, Juniper, iPolicy and such. If you are using a Pix, router ACL, or other text-/console-driven management method, then you'll have to add comments to the configuration commands in a master document, and keep everything up to date in the master document no matter what!.

Consider this to be the Top 10 things to think about when running a firewall. It's not complete or perfect. But it will save you a lot of time and trouble if kept up. If rule rot has already crept in, then start at step 10 and work backwards.

1) Who wants the rule? What manager and techie are responsible for it? In various places, I've implemented a policy that anyone who wants an exception or new rule needs to provide written approval (e-mail is fine) from a manager at director level or higher. This doesn't represent too great an obstacle, but just enough to keep frivolous requests (and you WILL get frivolous requests) to a minimum, while not interfering with business.

2) For each rule and accompanying objects (name/IP address, etc.): Get and maintain the management and technical name and contact. If possible, put those names in a comment field with the object in the actual configuration itself. If the rule is unique to an individual group, then put the contact information in the rule comment itself.

3) For temporary or test rules (I've seen "temporary" rules that have been in place for years), put an expiration date in the comment field in addition to the contact.

4) Group like services together. All inbound Web servers should be in a single group with the relevant ports (usually 80 and/or 443).

5) Discourage non-standard ports without good reason. "I want to make it less likely for hackers and bots to find my Web page" is not a good reason. We tell those people that we will be happy to perform a Nessus vulnerability scan on their server to see if it meets acceptable minimums. Alternately, we suggest that they implement user IDs and passwords.

6) Discourage "I need all (65,000-odd) ports open because I have no idea what's really required" type of requests. For these, you can create a temporary rule (see #3), and then track the logs with the services in use to see what is actually needed. Then go back and tighten it down.

7) For legitimate non-standard port usage, consider grouping the oddball systems together under a single rule. In one sense, this violates the principle of allowing no access that is not absolutely necessary. But, if you check all relevant systems first (port scan them) and only one responds on TCP/7000 (and the others don't) and only two others (properly) respond only on port 24555, then you may able to group them into an "oddball" rule safely. Just make sure that you recheck all of them every time you add a new non-standard port.

8) Many people will want special inbound access to their desktops. This sort of request can take the form of Telnet, SSH, Remote Desktop/Terminal Server, PCAnywhere, GoToMyPC, Mionet, VNC, LapLink, various databases and probably a whole host of other things. The answer is: "No. Implement a VPN." By the way, for those of you not familiar with it, Mionet is a relative newcomer to the scene. It not only allows remote desktop access, it also allows the user to "share resources" with those of his or her choosing. If this scenario doesn't scare you, you haven't spent enough time in security. By the way, technically speaking, GoToMyPc and Mionet are outbound applications, but the direction of access is inward.

9) Many enterprises simply allow all outbound connections without further restriction. There is very little reason to do this, and lots of reasons not to. First off, the overwhelming majority of traffic these days is HTTP and its partner HTTPS on well-known ports. If policy permits, you can allow SSH, FTP (active and passive), POP3 (dubious, as it can bypass anti-virus protections), SMTP (what's wrong with the regular mail server?), various forms of IM (Instant Messaging, in the forms of AIM, MSN, Yahoo, et al). Peer-to-peer (P2P) file sharing? Not on a bet. The college I help out gets LOTS of e-e-mail from the RIAA (Recording Industry Association of America), DMCA (Digital Millennium Copyright Association) and other copyright-protective trade groups who will provide a polite warning before serving a summons. You don't want your employer to have a "CNN moment." They are not much fun.

10) Having inflicted all of this on you, it's now expected that you will keep it up. Pick your interval (weekly, monthly, quarterly, semi-annually or annually), put it in your (common?) calendar application and review everything. Specifically the following:

• For every object defined, validate that the contact names, numbers and e-mail addresses are still valid. Don't just look at them, call each and every person to make sure they are still part of your organization, haven't changed roles (promotions, moves, etc.) and still have responsibility for the object in question.
• At the same time, verify and validate that the object and/or services to it still exist and are still needed. You might be surprised how many firewall holes I've found for servers that died years ago. Or for departments that got reorganized out of existence.
• For all temporary/test rules, find out if they are still needed.
• Ask the owners of these systems when was the last time the systems were updated for OS, application, antivirus, etc. Ask for a specific date.
• Consider scheduled Nessus scans, but that's out of the scope of this blog.
• Make all comments reflect the new data. I love to keep copies of configurations on my system, or a central server, but if we all get hit by a bus, the only copy of the configuration visible to the rest of the IT organization is the one sitting on the firewall itself. And that is where someone new is going to have to start.