Re: Reboot in output from "last":

From: Tim Haynes (usenet@stirfried.vegetable.org.uk)
Date: 10/25/02 

From: Tim Haynes <usenet@stirfried.vegetable.org.uk>
Date: Fri, 25 Oct 2002 14:24:27 +0100

Carlos Moreno <moreno_at_mochima_dot_com@xx.xxx> writes:

> Hmm, seems like the intent of my question wasn't 100% clear :-)
>
> Yes, I had read your message; precisely that was what prompted me to go
> and check my logs... My question then was "what does exactly mean that
> someone attempted that buffer overflow on my machine?". As in, what is
> the expected outcome of such attempt on an out-of-the-box RedHat 7.3
> system? If they attempt a buffer overflow on some specific point, it must
> be because at some point there was a bug in there, and such bug allowed
> the attacker to gain root control, or maybe gain unprivileged access, or
> maybe just sniff the network connection?? (it all depends on what exactly
> the bug is, and where the bug is).

It does; in this case, there have been quite a few exploits for rpc
services, particularly rpc.statd, that have been remote-root in terms of
severity.

Have a gander at <http://www.ciac.org/ciac/bulletins/l-067.shtml> under
`Damage:'.

<rant>
While I'm passing by, also, discount what that url says about attempting to
find & remove an Adore infection; this is ***. As a golden rule, if
you've been so negligent as to get cracked once, the cracker could've
installed anything - including kernel modules that hide their presence and
that redirect exec() calls to a different file from open() calls (think
about that).
You could be infected by multiple separate worms and only remove one whilst
still doing damage with the other(s); you might also not clean up all the
damage done. It is invariably more cost-efficient in the medium- to
long-term to reinstall from clean media and learn how to tighten your box
properly.

I think security sites putting up "how to remove it" advice is despicably
irresponsible.

</rant>

> So, that was my question: when I see that log message, does it mean that
> someone *hacked into my box*?? Or does it mean that someone tried to hack
> into my box but I can have the peace of mind that they didn't succeed?

Neither. That's why I say it's a heads-up that you have some serious
investigating to be doing to prove one way or another - starting with
chkrootkit to point in favour of clean or cracked status, but doing the
grunt work by hand.

Amongst other things, check for new users in /etc/passwd, strange processes
running, new network socket listeners, misbehaviour of normal commands[0],
validity of packages installed[1], odd files installed in strange places -
e.g. /dev/.lib/ which doesn't exist in the FHS, excessive network activity
such as masses of outgoing SYNs (but never established connections) or UDP
packets or even a rush of outgoing ICMP (e.g. smurf attacks), etc etc.

[0] I've been known to detect a worm infestation by sensing that netstat
didn't support `-p' while I knew damn' well that RH6.2's version of netstat
did.

[1] This is another reason to keep /usr for packages provided by the system
/ your distro, and /usr/local for stuff built from source yourself, and to
*use* package-management toys as well - `rpm -Vva' is your fwend!(TM)

> (yes, I know that either way it's worrisome -- but if I know they did
> succeed in hacking into my box, then it's *much* more worrisome...)

Thing is, with a proper firewall in place and minimal installation
policy[0], the offending packets would not have got anywhere near a running
process - you can kick these things off at firewall level, or let them
bounce off the IP stack (`no process listening on the port' - ie connection
rejected) or you can let a user-space process handle it and say "sorry,
dunno what to do with that" in which case you're relying on something being
an uptodate version with patches, yadda.

And with an IDS (such as AIDE) and nIDS (such as snort), you would have a
much better clue when network attacks were happening, and when critical
files were changing or new things being added.

And with a semi-automated daily update-to-latest-security-fixes cron-job
and policy that at 9am you complete the daily update, you're really
starting to cruise.

[0] no packages you don't need, no socket-listeners you don't need,
firewall blocking all by default...

~Tim 

-- 
   14:10:51 up 21 days, 18:55, 10 users,  load average: 0.10, 0.16, 0.20
piglet@stirfried.vegetable.org.uk |Newton and Adam, lost and found,
http://piglet.is.dreaming.org     |The apple must fall to the ground

Loading