lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: kkrueger at outbox.whoi.edu (Karl A. Krueger)
Subject: RE: RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!

hellNbak <hellnbak@...c.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@...i.edu>
Network Security -- Linux/Unix Systems Support -- Etc.
Woods Hole Oceanographic Institution


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ