Re: '(no

[Momchil Velikov <velco@fadata.bg>]

>>>>> "Dimitri" == Dimitri Maziuk <dmaziuk@yola.bmrb.wisc.edu> writes:

Dimitri> In linux.debian.security, you wrote:
>> I am curious if the following is an example of a buffer overflow.  I
>> noticed this in my syslog - and the following day had someone logged in
>> from an IP I'm not aware of.
>> 
>> I changed the passwords - and added an entry to the input chain to block
>> the IP, but am wondering what other things I should do? 
>> 
>> Should I remove /bin/sh for something less obvious as a general
>> protection from buffer overflows?

Dimitri> If you suspect your machine was r00ted, 
Dimitri> 1. Take it off the net _now_.
Dimitri> 2. If you want to do a post-mortem, boot from "known good" CD or plug
Dimitri>    the hd into a "known good" box.
Dimitri> 3. Post mortem or not, wipe everything out (as in "fdisk") and reinstall
Dimitri>    from scratch.

Frankly, this looks a bit too harsh. Of course, it depends on the
importance of the machine and the data on it.

Dimitri> The reason is that the intruder could install hacked versions of utilities
Dimitri> like ps, ls, lsmod etc. that won't show backdoor processes and hacked files,
Dimitri> and/or a kernel module that does the same at OS level. Your logs may have 
Dimitri> been sanitized, too. You cannot trust any program on a r00ted box.
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In theory, yes. In practice, one can (marginally) trust some of the
programs, e.g. is it likely that a rootkit has changed ``tar'' ? Or
``apt-get'' ? Or ``tcsh'' ?

You can use ``tar'' to find out if ``ls'' was changed. Use ``echo'' to
list directories and compare with ``ls'' and ``find''. Use ``tcsh''
builtin ``ls-F''.

I guess there are other means to detect a rootkit, described somewhere
on the web. (Hopefully, mozilla is not cracked to conceive such
information :-)

Regards,
-velco