Security Incidents mailing list archives
Re: Priorities (was: Bind8 exploit and a deleted partition map)
From: Justin Shore <macdaddy () NEO PITTSTATE EDU>
Date: Thu, 15 Feb 2001 12:08:49 -0600
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 updatedIt'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.
Current thread:
- Re: Priorities (was: Bind8 exploit and a deleted partition map) Justin Shore (Feb 15)