Re: Priorities (was: Bind8 exploit and a deleted partition map)

[Justin Shore <macdaddy () NEO PITTSTATE EDU>]

On 2/15/01 9:11 AM Dustin Mitchell said...

> On Tue, 13 Feb 2001, Crist Clark wrote:
> > Derek Kwan wrote:
> > ...
> > > 2) Keep your software version updated
> >
> > It's tough, but try, try, and have an idea about priorities. Which
> > needs to be fixed by end of the week, which by end of the day, and
> > which needs to be turned off NOW until it is fixed.
>
> I'd like a little more advice on this subject: what are some of the
> factors that should influence this prioritization?  Maybe I can list a
> few; please add/correct:
>
> a) Exposure (e.g. who are your local users, is the machine behind a
>   firewall)

I see this one a a goal, maybe longterm.  This is something you should
work towards.

> b) Existence of a rootkit

This depends on the machine.  If this is a multi-user server or a machine
that is "trusted" by other machines, remove it from the network
immediately and clean it up--change all password, all keys, etc...  If
this is a box that you can do without or it just isn't a terribly
important to you, your users, or your network, leave it up and monitor
it.  Record all traffic in and out of it.  Try to reasonably cover your
own tracks.  In essance you've inadvertantly created a honeypot that's
already been taken over.  If you have the ability to monitor it for all
activity, you might learn something or you might just be able to identify
the master and help all of us out.

> c) Evidence of attempts or scans

Record and archive them.  There isn't a whole lot you can do about them
until somethign happens.  I have reported scans before to UUnet.  They
were specifically and systematically probing our 12 C's (in 2 contiguous
blocks).  Not that it would do any good, I reported it and UUnet dealt
with it from there.  When someone does attempt entry at a later date, you
have the proof that it wasn't just an "accidental" attack or connection
but that they've actually been casing the place for a few weeks.

> d) Breadth of vulnerability (e.g. root shell, DoS, or just breaking the
>   AppleTalk server that only one person uses)

In other words, an advisory just came out and you know that something
you're running is vulnerable, right?  It depends on the daemon and the
vulnerability.  If it's that Bind sploit from a few weeks back
(http://www.cert.org/advisories/CA-2001-02.html) and DNS is important to
you (an ISP, a Unv, basically everyone) than it should become a top
priority.  If a hole has been discovered in daemon XYZ but not known
tools for exploiting it have surfaced yet, you can make it not as high a
priority, but it should still get fixed soon.  These things really depend
on you, your company, the services it provides, the users that it
provides those services to, etc...   Putting something on the back burner
can help you get something more important accomplished during a given
day, but you may get a call that night because that thing you put off
until tomorrow has just been drilled by a night owl.  It's a never ending
process.  It's also called job security. :)

My $.02
  Justin


--
Justin Shore                    Pittsburg State University
Network & Systems Manager       Kelce 157Q
Office of Information Systems   Pittsburg, KS 66762
Voice: (620) 235-4606           Fax: (620) 235-4545
http://www.pittstate.edu/ois/

Warning:  This message has been quadruple Rot13'ed for your protection.