[sf-lug] how to whack crackers
jim at well.com
Tue Jan 6 09:33:44 PST 2009
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.
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
More information about the sf-lug