[conspire] Re: [vox] Password NOT stolen at linuxworld

[Rick Moen]

[Posted to LUGOD's vox mailing list concerning Ryan's situation.  I'll be
sending Ryan a copy of this post.]

Quoting ME (dugan at passwall.com):

> If you have no log files, and the box is still running, and you have
> access to mount other filesystem, you can go through proc and copy aps
> loaded into memory to files in case processes were started from files that
> were deleted.  [...]

Note that it's actually an incredibly bad idea to leave a compromised
machine running, generally:  If it has any connection to other networks,
it may be carrying out attacks or other criminal activity -- from your
IP address, which you most definitely don't want.  Even if it's been
yanked from all networks, you are no longer in control of it, and
therefore don't know what it might do at any moment:  Erase all files?
Subtlely corrupt every tenth non-program file?

Unless you have absolutely up-to-the-minute full backups or don't care
about the machine contents, logically your first priority is to reassert 
control over the machine and make safety copies of anything you care
about.  Therefore, the safest recommendation is to _power off_ a
compromised host the moment you're reasonably certain it's been
compromised.  Don't do an orderly shutdown:  Yank the power cord.

Having done that, you get your handy maintenance floppy, LNX-BBC,
Knoppix disk, or what have you, and boot _it_ (rather than your hard
disk/disks).  Mount the contents of your system hard disk(s) read-only.
Make whatever backups you need.  _Then_, you can use Coroner's Toolkit 
or whatever else are your favourite tools -- at your leisure.

> This helps get you some data. The next step I would do (without logs) is
> do md5sums on a few tools like lsof and others and comapre their sigs to
> those of untainted systems, and then use lsof to see what ports are opened
> by what services, and then find versions for those services and check a
> snort db or other places to see if any have knonw/published exploits. [...]

The big problem with the indicated approach is that you simply cannot
trust any results returned from processes running within a compromised
runtime system.  Why?  _Because it's compromised!_  It's amazing how
many people can't seem to get this basic point.

Thus the power-down and switchover to NON-compromised maintenance media
in my suggested approach, above.

Obviously you shouldn't take my word for any of that, Ryan.  I just
suggest thinking carefully about advice such as what's quoted, as
there's a tremendous amount of really, really bad security advice
circulating on LUG mailing lists.  (I wouldn't be the least bit annoyed
at your applying equal skepticism to any security advice from _me_.
In fact, I'd be delighted.  ;->  )