On Thu, 25 Jan 2001 [EMAIL PROTECTED] wrote:
> One thing I do not understand is why a manual clean-up is being
> attempted... personally I would never trust a system which had been
> compromised. Why not nab the critical data and start over?
>
> On Thu, 25 Jan 2001, Michael H. Warfield spewed into the bitstream:
> MHW>On Thu, Jan 25, 2001 at 04:48:58AM -0330, Mike Pelley wrote:
> MHW>> Folks,
> MHW>> I'm cleaning up a system that was hacked (curses on wu-ftp!). There are a
> MHW>> number of files that cannot be reverted to their non-hacked form,
> MHW>> specifically, /bin/ps and /bin/netsat. If I try to delete them, for example
Several people have now mentioned that you SHOULD re-install after being
hacked. This is absolutely true.
As an experiment, I left a 6.2 box with a stock installation as a "honey
pot", intended as bait for a script kiddie hacker, so I could look at the
results, both to better recognize a hacked system and to see if I could
learn to manually clean up. I was monitoring this system frequently to
look for hacks. Well, I went to the beach last summer and before I could
get set up to dial into the net and look at the box, the kiddie had gotten
in and covered his tracks. Some of the kits are pretty good. It's hard
to tell at quick glance that some changes have been made. In this case,
as with many kits, system utlities such as ls, ps, rm were replaced with
the kiddie's version, designed to cover his tracks. syslogd was changed,
the old logs were cleared out so no traces can be seen (at least with
things as the kiddie left them). Also, the kiddie left and "egg" in a
very obscure place (in this case /usr/share/...) in a directory he created
with a same extremely similiar to legitimate directories.
lsattr /bin/ps gave ----i--- instead of -------- which is a
tell-tale sign of the hack.
What I did was to immediately move private copies of ls, ps, rm, syslogd,
a few other goodies over from another system that hadn't been hacked, of
course with obscure names (foo.dat for ps or something like that :-) in
my own home directory. I also launched my private copy of syslogd under
a different name and got it to log to a private system log file with an
equally obscure name. Then, I watched to see what this kiddie did with my
system. Launched an irc server among other things.
I started looking at every directory and file on the system - much pain!
Comparing file size, dates, lsattr, etc. That's how I found the system
utilities and the location of the private directory, which wouldn't show
up in ls listings with the hacked ls, of course.
I finally tired of his shenanigans, so I started killing his processes
when I saw them fire up. The funny thing is that, instead of sensing that
he had been found and quitting, he tried to start them again. He even
tried to copy his stuff back to my system after I had removed it (with my
version of rm), but I caught him in the middle of that transfer, too.
Finally, I saw the foolishness of the attempt to keep him out without
re-installing. (If I had started the private syslogd in time, I may have
caught him coming back in, but chances are he didn't come straight in
anyway).
You really do not know all of what has been changed on a system. That is
why you really need to complete re-install the system software. In doing
so, it will wipe out the hidden directories and modified files.
It is very important, IMHO, that when you install a system that you have a
/home in a separate partition from /. You can debate whether you need
more partitions than that (separate /var, /usr, /usr/local ?), but when it
comes time to re-install a hacked (or damaged) system, or to upgrade or
install a new OS, it is important to have your data separated out. The
whole / file system (with /usr, and so forth) will be remade by the
re-install, wiping out /home. That's why you should back /home up first
(and any other data). You may also want to back up /etc, since your
configuration files are there and you can consult these copies to help in
getting your newly re-installed system back to snuff. With /home in a
separate partition, your data does not get wiped by the re-install. Now,
you may still want to do some checking on /home for any stuff left by the
hacker, but the new system won't be affected by stuff in /home.
Now, after re-installing, there are two things that are your very best
friends to prevent this again:
up2date and portsentry
Subscribe to the redhat-watch and/or redhat-announce lists, where RHSA or
RHBA announcements get mailed out. They will tell you when a fix for
newly discovered holes exist. Run up2date (RedHat's utility) to obtain
and install updates for all your software. If you had been current with
updates, it is highly unlikely that you would have been hacked.
Then, if you properly configure tcpwrappers, with
/etc/hosts.deny
ALL: ALL
and /etc/hosts.allow
ALL: LOCAL, x.y.z., u.w., .yourcompany.com
or somesuch explicit list of IP numbers and/or hostnames (or domains)
that can have access,
In addition to properly configuring tcpwrappers, you should run
portsentry, to monitor your ports. It will let you know when the kiddies
are trolling to see what ports you have services running on, where you
might be vulnerable. It will also work to explicitly block the
originating sites from your machine (e.g. adding their IP number to a
route to the network equivalent of the bit bucket (127.0.0.1)).
You can find portsentry on the powertools CD or in the powertools
directories on the RedHat mirrors.
The other recommendation is to turn off all unnecessary services started
by inetd (/etc/inetd.conf in 6.x) or xinetd (/etc/xinetd.conf and
/etc/xinetd.d/* in 7.0). Learn what a service does and how to configure
it securely before you start it up.
I've written a few web pages on the subject, which you may find helpful as
a checklist.
http://www-jerry.oit.duke.edu/linux/bluedevil/HOWTO/what_to_do_if_hacked.html,
how_to_tell_if_hacked.html, linux_security_howto.html
But, after getting your data backed up (tarred up and moved to another
machine), do the re-install!!!
***************************************************************************
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
