Re: Inbound Default Deny Policy at Internet Border

[Joel Rosenblatt <joel () COLUMBIA EDU>]

This reminds me of a vendor that sells scanning software saying that we should not allow XP SP2 be installed so that 
they can scan ... it is a factual, but
really dumb solution to the problem :-)

As for looking at what machines are doing, we have taken the approach that we don't really care WHAT you do, just HOW 
MUCH you do it.  We have upload and
download limits that are data agnostic (legitimate users can apply for an exemption).  See 
<http://www.columbia.edu/cu/policy/bandwidth.html> for details.  A
side effect of this is that we become aware very quickly of machines that are scanning systems off of our network.  One 
thing we did do is implement a secure
protocol initiative.  All University (read central administration) servers will only accept connections using secure 
protocols (no tcp, ftp, clear text
passwords, etc.) - we did this to cut down on password stealing. We are trying to push non central server to do the 
same thing.

The only ports that we are blocking at the edge are those that are used for windows file sharing - we decided to take 
the hit on this one, since there were so
many people scanning for open shares it was beginning to affect our network - if you really have to share from the 
outside, you can do it through our VPN.

My feeling is that a deny all policy would cause so many people grief that I would never get to leave my office :-)

My 2 cents.

Joel Rosenblatt

Joel Rosenblatt, Senior Security Officer & Windows Specialist, AcIS
Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
http://www.columbia.edu/~joel


--On Monday, May 16, 2005 2:39 PM -0400 stanislav shalunov <shalunov () INTERNET2 EDU> wrote:

> Michael Sinatra <michael () RANCID BERKELEY EDU> writes:
>
> > In response to John's point, I think we'll see most near-term innovation
> > directed toward getting around border blocks, via port-80 tunneling, ssh
> > tunneling, IPv6, and end-to-end IPSEC.  Terry Gray points out that, in
> > such a world, some sites may take the rather bizarre stance of banning
> > end-to-end encryption, so they can inspect traffic.  Sigh.
>
> Scary indeed, but probably too difficult.
>
> Then the overlays will hide steganographically.  In the next round,
> things conducive for steganography would need to be banned (any
> bloated file format is excellent for hiding your encrypted data).
> Then, they'd need to ban videoconferencing (same steganography
> concerns).  Install Faraday cages around the campus.  Search the
> residence halls for pre-Longhorn operating systems.  Deploy hawks to
> intercept pigeons.
>
> I don't believe users will need the pigeons.  I don't think the
> cat-and-mouse game on the net goes very far.  It has, in essence, two
> moves.  Initial position: cat sees mouse and knows what the mouse is
> doing; mouse vaguely knows that a cat might exist, but doesn't care.
> First move: cat tries to catch the mouse.  Second move: mouse goes
> into hiding.  Final position: the cat has no idea where the mouse is
> or what it's doing; mouse keeps the cat in mind and modifies its
> behavior so that to avoid the cat.
>
> This played out to a significant extent for port-based and other
> simple application detection.  Users, until about 2001, were nice
> enough to let us see what they were doing.  So, we installed packet
> shapers, policy managers, managers of policy managers, and other misc
> middleboxes.  Less than a year later, users had applications that
> prevented us from even knowing what it was that they were up to (made
> for a spectacular bulge in the unidentified portion of the backbone
> traffic...).
>
> The default-deny administrative pressure factor is more wasteful than
> port snooping: it requires the overlays to become less efficient, keep
> connections open, sometimes route around through places with better
> connectivity, etc.  But ultimately, all that is doable.  It just means
> overhead and complexity.  Things that will suffer most would be
> high-performance applications...
>
> --
> Stanislav Shalunov              http://www.internet2.edu/~shalunov/
>
> This message is designed to be viewed in boustrophedon.
>
> **********
> Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
> http://www.educause.edu/groups/.



Joel Rosenblatt, Senior Security Officer & Windows Specialist, AcIS
Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
http://www.columbia.edu/~joel

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