On Thu, 8 Mar 2001, Mike Burger wrote:

> Mikkel, his example shows that he already did chattr -i the file.
>
> lemon:  Make sure that there are no running ftp sessions...it's possible
> that the file can't be removed because it's in use.
>
> On Thu, 8 Mar 2001, Mikkel L. Ellertson wrote:
>
> > On Thu, 8 Mar 2001 [EMAIL PROTECTED] wrote:
> >
> > >     my redhat server was hijacked and the shell commands attributes
> > > were changed,for instances:i loged in as root and do:
> > >
> > > #lsattr /usr/bin/ftp
> > > ----i--- /usr/bin/ftp
> > > #chattr -i /usr/bin/ftp
> > > -------- /usr/bin/ftp
> > >
> > > but i still can not delete the shell command,error like this:"rm:
> > > cannot unlink `ftp': Permission denied
> > >

Some root kits replace several utilities, INCLUDING rm!!!  I know because
I've actually seen one that did.  If, after disconnecting your system from
the network, you have the luxury of a little bit of time to play in order
to investigate what has been done, you MUST get fresh clean copies of
several binaries, including ls, rm, ps, syslogd.  Copy them to your own
directory and run them from there.  (If you have the system still
connected to the network, which shouldn't, but if you do, then copy these
fresh, known clean binaries to obscure names in a user directory or
someplace.  Then the hacker won't know that you're onto him and
observing).  You need a "gold standard" with regards to system utilities.
In general, lsattr should indicate if a file has been secretly replaced
with new Folgers' Chrystals (coffee commercial...), but don't necessarily
assume so.  Also, changes in crontab to make processes run may have been
made.  You cannot trust that system now.

You absolutely must do a fresh, clean, re-install.  Back up your data
somehow first.  (Good reason to have /usr/local and /home as separate
partitions).  Then re-install.  As Mikkel said, you just can never be sure
of what "backdoors" or other such things have been done, nor what
processes are really running (the process names in a ps list don't
necessarily mean that the version you know, trust, and understand, is
running.  You don't know.  However, a clean re-install will give you back
some peace of mind.

The keys to prevention (in order of importance):

tcpwrappers (with /etc/hosts.deny = ALL: ALL, /etc/hosts.allow = ALL:
LOCAL, localhost, x.y.z.  (your machine's subnet, assuming you want to get
to it from other machines on your LAN)

apply package updates as they are announced (subscribe to the redhat
announcement lists so you'll know when a security patch is available)
        up2date is extremely helpful

portsentry (it'll let you know when the port mappers are banging on your
doors)

tripwire (you can tell if anything important has been touched)

don't enable services which you aren't going to use (check in
/etc/inetd.conf or /etc/xinetd.conf and /etc/xinetd.d/*

regulary check /var/log/messages, /var/log/secure and similiar log files.

I have a few documents that may be of help:

http://www-jerry.oit.duke.edu/linux/bluedevil/HOWTO/
        linux_security_howto.html
        how_to_tell_if_hacked.html
        what_to_do_if_hacked.html

Remember:  be ever vigilant, your adversaries (the script kiddies!) never
sleep...

> > >
> >
> > But to be safe, you realy need to back up your data, wipe the disk, and
> > re-install the OS.  The install the updates BEFORE putting the server
> > back online.  Anything else is inviting trouble.  You have no idea what
> > kind of back doors were installed on your system.
> >
> > Mikkel
> >  --

-- 
***************************************************************************
Jerry Winegarden        OIT/Technical Support           Duke University
[EMAIL PROTECTED]            http://www-jerry.oit.duke.edu
***************************************************************************



_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to