Re: Inbound Default Deny Policy at Internet Border (fwd)

[Willis Marti <wmarti () TAMU EDU>]

> 1. The mission of the University is to create an environment where
> information  can be exchanged freely.
 No, not unless you want to throw away various intellectual property rules.
Most of higher education is about learning, teaching, research. And usually
administrative functions, too. We have some people (students, staff, faculty)
that would like to do things a firewall may inhibit. And we have lots more
people that don't care about about protocol experiments - they just want a
basic utility (they network) to work.

> 2. Deny/All at the border is a short term solution that will cause added
> paperwork whenever someone wants to do some work that requires a mod to
> this  ACL. How long will it take to get an exception? How long does the
> exception  last? Who's authorized to deny/grant the exception? what's the
> due process?  etc.
 We've had a default deny policy since 1992. We've tuned it over the years
and keep tuning it to try to achieve a balance between security and
convenience. It takes about one full time person to administer firewall
requests for ~50,000 hosts, 16,000 staff & faculty, 45,000 students (10,000
on-campus). No paperwork, just email or the web site. Unless a protocol is on
the "bad list", we grant exceptions based on faculty/staff request. As much
as possible, we conduct a vulnerability scan of the host before we do.

> 3. Deny/All places no responsibility on the end user. It send the message
> that  "we" will take the brunt of your bad practices. There is no incentive
> for the  user to change their habits.
 Not if you also look after your internal network. A border firewall is but
one piece of defense that should be integrated into one's overall plan. It's
possible to do _only_ border firewalls; it's also possible to not do border
firewalls or anything else. Neither is a good idea.

> 4. It doesn't do much for internal attacks.
 Still the minority of the automated threat. Besides, if I detect an internal
attack, I can sanction that person.

> Possible solutions:
>
> 1. create a DENY/Small-subset at the border. Things like inbound 445, 137-9.
 We started this way, then found we can't predict all the vulnerabilities
vendors can introduce.

> 2. create a default DENY/ALL for all HOST based firewalls. Let the user
> open  up what's needed. Block pings here if you want. If commercial
> vulnerability  scanners can't scan because of ping blocks, then most of the
> other bad boy  scanners won't either (yeah, I know, good hackers can find
> you). If everyone  blocks pings, the machines that don't are the ones you
> want to take a closer  look and they're easy to find.
 Perhaps this is an issue of scale, but I fin it difficult to see how one
guarantees the configuration and operation of anthing but a small number of
host firewalls in a not very complex environment.

> 3. If a user opens up everything, they'll get hit and hopefully, everyone
> else  will be protected by their default FW rules. The victim's behavior
> will be  modified after a couple of reinstalls.
 When slammer hit the 'net, your system's security didn't matter much if the
bandwidth gets eaten up by worm traffic. Or your mail server gets overloaded
in rejecting all the virus-laden internal mail. It is not possible in today's
academic environment to productively interact with others yet be isolated from
all the effects of their misfortune.

> 4. There is no need for creating more paperwork for exception handling.
> responsibility is where it needs to be ---- at the end user.
 How do you think you can get effective action from all your users -
including the marginally omputer literate that just want email and google?

> As IT people, we forget that we are managing "staplers, typewriters,
> calculators" for real-world people. Dangerous office equipment, mind you,
> but  office equipment to the real world, nonetheless. The more we interfere
> with  the business, the more the business will try to circumvent and that,
> in the  long run, is more dangerous. Why? Because now you have an
> environment where  the outside world (hackers) are trying to set up covert
> channels and the users  are trying to set up covert channels to get around
> your restrictions.
 The (few) covert channels that go up do not cause nearly as much trouble as
would the millions of attacks given unfettered access. My mission is not
killing _all_ worms or finding _all_ rule-breakers. It is keeping the network
available as much as practical for the University community.

Cheers,
 Willis Marti
 Associate Director for Networking
 Computing & Information Services
 Texas A&M University

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