Re: Inbound Default Deny Policy at Internet Border

[Jeff Wolfe <wolfe () EMS PSU EDU>]

OBbackground: I'm only part of the overall PSU environment, but....

Mark Poepping wrote:

> On this thread, I would be interested to hear more about:
>  1) suggestions for improving either default approach, or

We deployed firewalls with default deny inbound on our network segments
back in 2001. Our implementation process took about 10 months, primarily
because we did our homework on each segment before it was firewalled.

Some of the things we did:

- Profile current network traffic. This allowed us to isolate 90% of the
exceptions and special cases and take care of them before  we turned up
the firewalls, which made things go a lot more smoothly.

- Make friends with the faculty/staff/students. (Someone once told me
getting faculty to do things is like herding cats and they were right..)
We had discussions with those people we identified as being more likely
to have special needs to make sure they understood that we were willing
to work with them. A lot of the problems I've witnessed with bad
firewall environments have a lot to do with communication between the
firewall admin and user. These problems can be avoided if you're careful
about how you word your policy and how you treat your users. A common
quote we used was: "We're not trying to stop you from doing your work,
We're trying to reduce the exposure of our network to attacks."

- Write a clear and concise policy. Make sure it has a method for
granting exceptions. Make sure your Dean or President fully understands
what you're trying to do with the firewall and agrees with you. At least
one of your users will start complaining at the top of your power tree.
It'll go a lot easier on you if your management is already on board with
you before the complaints start.

- Remember that people are lazy. I can't count how many times we got "I
MUST have telnet available through the firewall for critical research.."
After some investigation, the user simply doesn't want to take 10
minutes to learn how to use SSH. (or they figured out how to run eMule
on port 23, but that's a different fish.) Don't be a pushover on
exceptions, make people do at least a minimal amount of work for the
justification. As network admins, we rant and rave about the state of OS
security and this is a perfect opportunity to help your students
understand why they can't take the easy way out when writing network
applications. I can't tell how many copies of _Building Secure Software_
and other books I've recommended to people to help them understand why I
won't approve a firewall exception for their latest project without at
least a minimal explanation of what they're trying to do.

- Have service alternatives. We provide free WWW/Mail/FTP service for
our users. They aren't required to use it, but when they come looking
for exceptions for these sorts of services we gently prod them about why
they're not using the central servers.. Most are just unaware and are
more than happy to use our services.. If they still want an exception,
then we grant it.

- VPN.  Have some way for full access for your users when they're
outside the firewall. This will significantly cut down on the number of
exceptions you need to manage.

>  2) how to manage the inevitable exceptions

We have a database that contains the following, one row per exception:

IP, exception, create date, renewal date, "machine owner", "responsible
admin", OS type, Actual OS, strikes


Most are obvious.. We require that each exception have one or more
"responsible admins".. People who we can call, email or visit at any
time to check up on the machine. The admin is required to make sure the
machine is kept up to date on patches and otherwise follow Best
Practices for the security of their OS. Generally, we require that the
"responsible admin" be an IT staff member. Occasionally we waive that
for special cases, but in general we don't allow grads or faculty to be
the only admin on a machine. Too many people graduate and leave old
machines unattended in corners of labs, where we don't find them until
they're compromised.

The "strikes" field  tracks how many times we've had an incident..

The 2 OS fields are the OS we were told was on the machine and what our
OS fingerprinter thinks is on the machine.

We also query the owner and admin yearly to renew the exception. If they
 take no action, the exception is not renewed.

Overall, this posture has worked very well for us.. If nothing else, it
allows us to spend more time being proactive about security and less
time being reactive.

$0.02

-JEff

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/groups/.