RE: RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!

["Karl A. Krueger" <kkrueger () outbox whoi edu>]

hellNbak <hellnbak () nmrc org> wrote:
> On Sun, 26 Jan 2003, Schmehl, Paul L wrote:
> > Try working in a large edu sometime and see how much change you can
> > initiate.  It takes a tough person to stick it out and keep fighting.
> > (I'm not tooting my own horn, but standing up for all edu admins
> > everywhere.)  Some universities are *still* fighting to get the NetBIOS
> > ports closed, for god's sake.  Do you think for one minute that *any*
> > admin in his right mind would *willing* expose those ports to the
> > Internet?  If not, then *why* on earth do you think they're still open?
> > (Because the admins don't have the power to close them.)
>
> If this is truly the case Paul then you have my sympathy.  But I really
> want to say WTF -- they are a freakin educational institution -- you would
> think they know a thing or two.  Perhaps some litigation over being a
> launching point for an attack will straighten things out.

As a security technician for an .edu site that *does* have a default
deny firewall, I'd like to suggest that for such sites it can be a hard
fight but one worth fighting, to approve such a thing.  At WHOI we only
went default-deny this past November, after several years of it being up
in the air, bounced around in idea-space among the more IT-aware of the
scientists and engineers.

The issue for us was similar to that M. Schmehl describes.  Faculty at a
university, or scientists and engineers at a research institution, are
not simply employees of the institution.  They -are- the institution;
their work drives it; their creativity brings in the grants.  In such an
environment, it is utterly inappropriate for the institution's IT staff
to tell them what they may or may not do with the network.  Berating
them for being security-clueless won't help, either.  If you want them
to approve of a default-deny firewall, you need to convince them of
several things:

        1. The security situation on the Internet at large is dangerous
           to their work.  This became obvious to our researchers over
           the past few years, as they found themselves pouring more and
           more of their computer support budgets down the "reinstalling
           cracked systems and recovering data" rathole.

           To the cash-strapped scientist there is a difference between
           problems which are unaesthetic ("ick, I got cracked") and
           problems which are expensive ("ick, I got cracked and had to
           pay out of my grant to have my machine recovered").  
        
        2. Your IT department is -competent- to administer a firewall.
           If you are perceived as unreliable or fanatical, then of
           course they do not want you intervening between them and the
           network they are trying to use.

        3. The firewall will -not- be a power grab for IT; it will give
           them -more- control over what gets to their machines, not
           less.  We implemented this by putting together a simple Web
           application which allows them to request port openings, and
           promising them turnaround within one business day for all
           requests.  The firewall ruleset is built from the database
           behind this Web app.  We ran the Web app, accepting port
           requests, for over a month before the firewall went up, so by
           that time we had a darned good idea of what people were
           doing.

To an independently minded faculty or scientific staff you are not going
to sell the idea of restricting what they are -allowed- to use the
network to do.  You certainly -can- sell the idea of restricting what
-the network- is allowed to do to them, though.

-- 
Karl A. Krueger <kkrueger () whoi edu>
Network Security -- Linux/Unix Systems Support -- Etc.
Woods Hole Oceanographic Institution

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html