[sf-lug] how to whack crackers

[Rick Moen]

Quoting jim (jim at well.com):

>    no, the cracker did not get root access (not that 
> it matters, as the box and all its files is sitting 
> "over there" in the corner). 

Ah, well, if the intruder just came in and screwed around, that's not a
big problem.  (Annoying, yes.)  Did you discover the intrusion because,
e.g., the user changed / created some Web pages?  Or started generating
lots of mail?  

Although in theory, intruders can have disparate motives, most often
it's because they're spammers or Web site defacers.  Or they're
intending to abuse your machine to participate in massed DDoS attacks
on target sites, or be a passthrough site or advertised public site for
warez, or something like that.

>    i made sure there are no well-known user accounts 
> on The New Box and that as many as possible (e.g. 
> daemon accounts) have /bin/false or some such. 

I used to worry about this.  Turns out that packages pretty much reliably
get this right:  Either the login shell is set to something innocuous
like /bin/false _or_ direct login is disabled, e.g., by prefacing the
password field in /etc/shadow with "!!".  Beware of fooling with login
shells for the per-service users:  Sometimes, there 's a reason why,
e.g., a daemon's shell needs to be set to /bin/sh, but that's harmless
because it's set to have no login in the password files.

>    i cannot figure out a good backup scheme. the one 
> that copies absolutely everything from certain 
> directories each night is inelegant. 

Well, the page I cited earlier
(http://linuxmafia.com/faq/Admin/linuxmafia.com-backup.html) might be a
good place of departure for you, because it lists absolutely everything
that actually _needs_ to be in a full backup of my machine, while
omitting all software.

>    we recognize that the growing /var/log/auth.log file 
> represents doorknob tests, it's unnerving, possibly 
> educational. and the big number of iptables rules seems 
> to have no effect: maybe we've learned that lesson, too. 

Well, you'll need to decide for yourself, but I consider the bots that
check for easily-guessed ssh credentials to be just noise.

>    there's nothing much that's worth defending other than 
> the use of the box itself, but that's worth defending. 

Yes.  One of the points of my "Attacking Linux" article is that 

   Even if your machines don't cause you that order of embarrassment,
   the other risks are equally grim: you can reveal confidential data with
   business and/or personal consequences, lose that data entirely, see it
   corrupted or sabotaged, be involved in wrongful or even criminal
   activity, lose access to your computing resources, and indirectly cause
   harm to your staff and business associates. Your Website can be defaced
   or modified, or visitors might be redirected by sabotaged company DNS
   servers to entirely different sites.



>    i've manually gone over many filesystems on many boxes 
> over the last years looking for directories with funny 
> names beginning with the '.' character and perhaps one 
> or more whitespace characters. it's a tedious job but 
> kind of suits me at times. 

You'll never find _all_ of those.  Too many places.  Might be better to
let an IDS watch for you.  See my article (link in prior post) about
"Constructive Paranoia at the End of 2003".

>    the only threat model that i can make out is that some 
> cracker gets through the sshd door....

Well, one point that you'll want to ponder is:  How?  

If you can anticipate "how", then you can arrange to make that less
easy, and do other things such as think about detection,
damage-reduction, recovery, etc.




> and does something: 
> * puts on a root kit 
> * puts in tools that support a bot net 
> * other (can't think of what) 

These are all possible aftereffects of break-in, but really have nothing
otherwise to do with threat analysis, which concern the vector for entry
and system compromise.