Re: Inbound Default Deny Policy at Internet Border

[Graham Toal <gtoal () UTPA EDU>]

Gary Flynn wrote:

> We're looking at implementing a default deny
> inbound policy at our Internet border this
> summer.
>
> Anyone have any concerns or experiences they
> would like to share?


We instituted a default deny for the majority of ports a couple of years
ago, but left a few key ports open to any address - primarily ssh, http,
https,  ftp, telnet, and M$ remote desktop.

The original change was readily accepted - somewhat to my surprise,
as I had been willing to back down if it hadn't gone well - and we're
now at the stage where I would like to do the same for some of the
remaining ports.

For example we now have ssh on most of the systems which need
console access, and the few left which are telnet only are ones I'd
rather not have facing the public anyway (mostly printers, routers
and switches).  I'm thinking about creating an ssh->telnet gateway for
legitimate access to those devices that only offer telnet, if our
networking guys ask for it.

We also have a legal requirement to have a DMCA notice on
all our web sites, and by switching ports 80 and 443 to deny by
default, we have a mechanism to enforce that policy.  (Caveat:
this is pending approval from above...)

Deny by default has saved us big time on worms (SQL, M$ ports)
and direct-smtp-based email viruses.

I do appreciate the argument that academia has different requirements
from industry, but protecting our infrastructure is common to both.
The way we handle the objection someone raised about 'what if a
student project requires full access' is that we *give that student
project* full access.  But not *every* student in the University on
the offchance that they need it - that way lies a sewer of p2p
file sharing and DMCA takedown notices.

On average we have 1 or 2 requests per month for firewall holes,
and we routinely grant them.  It's actually useful to have this as one
of our checks & balances because frequently the request for a firewall
hole is the first time we hear of a new system, and it gives us an
opportunity to do a risk assessment for our users.

Graham

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