Re: [TCLUG:12807] bad day (more details)

[Peter Lukas <peter@math.umn.edu>]

Assuming that you have been tipped, it's too late to preserve any evidence
that can be used to prosecute.  More often than not, compromised machines
are usually "contaminated" by their respective owners, not the intruders
themselves.

Whenever a machine is suspected, it is most important not to touch
anything.  Kick the network cord out of the wall and step away.  After the
fact forensic techniques can vary from person to person, but if you're
interested in legal prosecution, you'll want to proceed very carefully
with your evidence, and seek external help and/or documentation.

Of course, I'm certain that members of the LUG (myself included) would be
happy to volunteer their efforts in troubleshooting this event.  In any
case, depending upon the machine's role on your network, you may want to
consider replacing it with a hot standby box so that your connectivity may
continue.  Inform your user base of the situation, and have them take
whatever reasonable action you see fit (usually a password change, general
"look over your shoulder" advise, etc).  

If you want to pursue revealing the identity of the intruder (or at least
their source of origin), do so after you have taken steps to secure the
immediate hole.  There are a number of additional steps, etc that you can
take from this point on, but far too many to go into detail in this
message.

Peter Lukas

On Mon, 24 Jan 2000, Chris McKinley wrote:

> On Mon, 24 Jan 2000, Timothy Wilson wrote:
> 
> > 
> > The problems seem to have started in the wee hours on Sat. morning when
> > the log says that the system couldn't locate module lo or eth0. A few
> > minutes later I see (thales is the hostname):
> > 
> > thales named[523]: reloading nameserver
> > thales named[523]: Forwarding source address is [0.0.0.0]1836
> > thales named[523]: Ready to answer queries
> > 
> > The same entried appeared approx. 7 min. later.
> 
> If your nameserver does not slave a zone, it was sent SIGHUP.
> 
> > 
> > Then it looks like the system started having problems with handing out
> > DHCP addresses. On Sun. syslogd restarted several times. At about 4 p.m.
> > Sun I see:
> >
> 
> same thing, unless there was a cron job to rotate the logs...
>  
> > thales kernel: lookup_by_indoe: ino 63554 not found in GNUstep
> > thales kenrel: find_fh_dentry: 08:0b, 274438/63554 not found -- need 
> >  full search
> > 
> > Then it seems that /proc started having problems with messages like:
> > 
> > thales kernel: proc_file_unlink: deleting ide/drivers
> > thales kernel: remove_proc_entry: ide/drivers busy, count=1
> > thales kernel: de_put: deferred delete of drivers
> > 
> 
> unlink == rm, so rm /proc/* ?
> 
> > Then I got versions of the same message for all kinds of /proc entries in
> > nfs, fs, eth0, lo, default, all, ipv4, core, vm, kernel, and net. One that
> > caught my eye:
> > 
> > thales kernel: proc_file_unlink: deleting all/log_martians
> > thales remove_proc_entry: all/log_martians busy, count=1
> > 
> > What's a log_martian? After that, the system was pretty much dead. I'd
> > love to hear any comments from anyone.
> > 
> > If it does turn out that my system was cracked, it will be further data to
> > support the notion that system security is a full-time job. I inevitably
> > get caught with insufficient time to maintain this system adequately.
> > 
> 
> it looks like you got 0wn3d by some script kiddie who did not know how to
> cover their tracks, and just trashed the system instead.  What services
> were offered from this box, it looks to me like DNS, DHCP, nfs, anything
> else?  Check the logs for connections on any running service.  If there is
> an "unusual" connection, or lots of connections, ala SATAN or nmap, that
> may be your culprit.  Keep backup copies of everything you can,
> especially logs, as you will need to reinstall from media.
> 
> -Chris
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tclug-list-unsubscribe@mn-linux.org
> For additional commands, e-mail: tclug-list-help@mn-linux.org
> 
>