Re: pam, ssh, user account vulnerability Enrique Perez-Terron <enrio@online.no> wrote:
> So, when I read "thank you rpm -VA", I immediately thought "but how
> can you be so sure!" I have come to the same conclusion as the others,
> you must boot an independent medium that the potential intruder
> has not had any chance to modify, at least not through *this* intrusion.
The Tripwire file-based IDS attempts to provide _some_ protection
against subversion of the IDS itself through a very pervasive
cryptographic signing and verification routine. They _still_ recommend
that you keep the signatures database and other key components on
write-protected media, but even without that it's impressively
tamper-resistant. (Like other such crypto regimes, it only works
properly if you both use it diligently and understand its design and
limitations -- which in its case is quite a chore, indeed.)
> Of course, your observation that the intruder has later failed to
> get in through Michael's account gives some probability that he was
> not that sophisticated after all, but you cannot be sure of that.
Or _more_ sophisticated.
Intruders have a couple of immediate aims, upon breaking into a system:
They want to draw a net of invisibility over their presence (thus,
rootkits), to make it less likely that the administrator and other
legitimate users will notice their presence -- and they want to set up
numerous backdoor methods of re-entry that they can fall back on, if the
legitimate users _do_ notice the intrusion.
Thus, the fact that the "intruder later failed to get in through
Michael's account" could mean he/she (or, more likely, his/her automated
script managing his stable of zombified remote hosts on his/her behalf)
attempted re-entry through Michael's login, failed because you changed
his password, and then immediately crossed _that_ method of entry to the
system off the list, and switched to others in order to lull the admin
back into complacency.
That would be the smart thing a bad guy would do.
The key thing to remember is that, _if_ you decide it's reasonably
likely that a system has been root-compromised, you cannot any longer
trust anything it contains (or does). Changing Michael's password may
have simply reduced the intruder's number of paths into your system to
n-1 for some large value of n.
> There seems to be enough incentives for the croocks to become rather
> professional, and their automated systems are probably responsible
> for the majority of the attacks.
And also remember: _One_ smart, competent author of cracking scripts
can and frequently does sell or give his offerings to thousands of
otherwise inept and brainless intruders. The actual guy who rooted your
system doesn't have to possess Clue One. |