If you have a 5.0 system exposed to the internet, it's most likely it has been
burgled, unless you've been really aggresive about keeping up with security
fix packages.
I'd recommend you take the system offline, take a full backup, do a fresh load
of Red Hat 5.2, add all the security patch packages (visit www.redhat.com,
click on "support", click on the appropriate "errata" link). Then disable all
the network services you don't actually require, and carefully check the
configuration of those few you do need. Do searches of bugtraq (at
www.geek-girl.com) for holes in the daemons you've left running. When you
think you have things nailed down, start restoring the user data; bring back
the home dirs, review the passwd data by hand. If you have periodic backups,
take a history of when passwords were changed, and don't immediately activate
those accounts whose passwords were changed at all recently; instead contact
their users and make sure they agree with time they last changed their
password for your system.
I don't know what's up with those Malk accounts, but from the additions to
inetd.conf, I'd recommend checking tcpd, in.ftpd, and in.telnetd to make sure
they haven't been replaced with hacked versions. Better, if you want to find
out everything that was done to your system, do an audit; since you're running
a Red Hat release, you can (a) boot off the floppies and CD-ROM in "rescue"
mode, (b) set your PATH and LD_LIBRARY_PATH to run entirely off the CD-ROM,
and (c) invoke the rpm executable off the CD, running with libs off the CD, to
compare checksums in the packages on the CD against checksums of files on your
hard disk. So you _can_ do a reasonably complete audit. You'll also need to
look at all files on the hard disk that aren't documented by packages, which
will include everything in user's home dirs, lots of tmp files and queue files
and log files, and probably a few config files.
It's fun to do that kind of retrospective analysis, but it's faster to just
rebuild known-good on the latest OS. If you've got spare drives, you might
want to hang on to the suspect ones for later analysis while rebuilding on
fresh drives.
-Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
