Welcome to Volume 4, Issue 17 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me. If you like the issue, let us know!
Enjoy, and be safe,
Dave
There are two fundamental ways to begin implementing a security policy. One is to be permissive, as in "that which is not expressly prohibited is permitted". The other is to be restrictive, as in "that which is not expressly permitted is prohibited". Security systems with configurable security policy tend to come "out of the box" with one or the other. Those that are permissive typically have a rule or policy that allows any service or operation. In today's column Fred Avolio explains how ANY policies can prove nefarious.
Happy reading...
[Thanks to Scott Pinzon of WatchGuard Technologies for the suggested topic and title.]
Sit down one day. Look at your firewall ruleset. Is there anything that effectively uses an "any" rule for any part of the configuration? Get rid of it.
Okay, I exaggerate. Let me start over, and let me be more specific. Most of us -- and I wrote "most" rather than "many" -- have porous firewalls. Our firewall rules are too general. I have written on this in the past (http://www.avolio.com/columns/Day8.html, (http://www.avolio.com/columns/onesize.html). I also mention this in the firewalls and "tools and techniques" classes that I teach (http://www.avolio.com/calendar.html). Why am I bringing it up again? Because the problem is so pervasive, the vulnerabilities are so real, and the fix is so simple. I'll keep this brief.
When we set up our firewall security policy, we have in the back of our heads the "Primordial Security Policy." It is a part of our thinking, and perhaps relates to some other basic mindsets inherited from Adam and Eve, in our brains since being kicked out of Eden. It is: Allow anyone "in here" to get out, for anything, but keep people "out there" from getting "in." Everyone reading this will recognize it. Now you have a name for it. Is this a good policy? Well, it is a start. But it is completely inadequate for the security needs of most of us.
The Primordial Security Policy (PSP) is useful as a starting point. It's kind of like our built-in autonomic reflex that causes us to pull our hand away from a flame without going through the bother of thinking the situation through first. The PSP tells us there is something to worry about. The PSP gets our brain's attention, but then our brains have to kick in and say, "that's all well and good, but what is the real worry, and while I am at it are there *other* things I should be concerned about?"
Your firewall of course, will differ in the details, but assuming a generic filter, here are a few suggestions for "next thoughts" for your brain.
1) Everyone knows that a rule that says "PERMIT from ANY OUTSIDE to ANY INSIDE FOR ANY PROTOCOL" is a bad thing. The PSP tells us that. Nearly equally bad is "PERMIT from ANY INSIDE to ANY OUTSIDE for ANY PROTOCOL." Any inside host can launch any attack on any outside host. Any inside host, infected by a "Trojan horse" process, can try to attack any host on the Internet. "But," someone will say, "every inside host has to use outbound e-mail." No, every inside host has to be able to send outbound e-mail, which you should be sending to an internal mail hub. That internal mail hub has to be able to send outbound e-mail. (And, *not* every host inside needs to send Internet-bound e-mail. Every web server? Every file server? I didn't think so.) There are potentially over 65,000 ports to use. Every inside host has to be able to use every one of them? Probably not.
2) What services do only a comparatively few require? Most of your users cannot spell "SSH" or "TELNET." They don't need to be able to use them. But some of your folks might. Don't "PERMIT from ANY INSIDE to ANY OUTSIDE for SSH" (or TELNET). Take the extra time to be more specific.
3) Having done that work, make a pass at being even more specific. Do those few users who require the use of SSH (for example) from inside to outside require it "to ANY OUTSIDE"? Again, probably not. Probably, they require it to a small number of specific outside hosts.
4) Finally, if our firewall is of a kind where the last rule has the last word -- if "any" really means "anything else I've neglected to mention" - - then a firewall rule that says "DENY from ANY to ANY for ANY" is a beautiful thing, indeed.
Fred Avolio has been involved in Internet computing and communication since the early 1980s, working with Internet security systems for over 10 years. He assisted in the creation of the first commercial Internet firewall (DEC SEAL), and helped create the commercial security products division of Trusted Information Systems, which produced TIS's commercial security consulting practice, the TIS Internet Firewall Toolkit, and the Gauntlet firewall. He contributed to the successful IPO of TIS, and its subsequent acquisition. Areas of expertise include firewalls, intrusion detection, cryptography, security management, and electronic mail systems.
If you enjoy Fred's musings, I encourage you to subscribe to his newsletter.