[sf-lug] how to whack crackers

[jim]

   speakeasy sternly notified me that someone 
reported cracking activity coming from my IP 
address. happened three or four years ago, so 
i knew what to do: turns out it was the same 
break-in method and same general approach to 
mis-using the box. 

   the thing i fear is the rootkit and things 
like them: replacing standard tools with 
look-alikes that include malware components. 
   so far, my approach is to wipe out the 
entire system and rebuild from known-good 
files from scratch. i don't trust the chkrootkit 
program only because it seems likely there's 
be rootkit improvements that elude an older 
chkrootkit program (which i download as source 
and compile and then run). 

   back to the reading and re-reading. 
thanks much! 
jim 



On Mon, 2009-01-05 at 17:05 -0800, Rick Moen wrote:
> 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.
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>