Re: chkrootkit has me worried!
hi ya kevin
On Tue, 29 Nov 2005, kevin bailey wrote:
> i have tried out lots of different things on this server and have made the
> mistake of leaving unnecessary services running.
everybody does that, one forgets to "undo the experiment environment"
and restore back to secure mode
> in this case i think that webmin was running the miniserv.pl server and this
> had a security warning issued for the version i had.
any cgi is a bad idea unless you can do sanity checking of what
users can feed it to get unauthorized access
> also - very luckily - no data on the server has been damaged.
- how do you "know" that ??
- can you compare the files against backups on cdrom that shows
no modified changes ??
- one doesn't need to check binaries unless you want to check it
vs fresh installs
- using existing binaries is fine if you have a way to
verify its md5 of the binary and libs and directory tree
( i prefer to check everything.. automatically with scripts )
- fresh installs means you have to configure everything
again from nothing .. maybe 1hr ..maybe 1 day .. maybe 1 week
( i somtimes spend a week to fix up distros from net/cd installs )
> it seems to
> spawn lots of hidden processes and has had to be rebooted to get it under
> control again.
it is typical for the reboot process ( scripts ) to be modified with
trojans and backdoors and other hidden goodies
> main points learnt.
>
> make sure you have snapshot backups going back months.
and saved on say dvd or disks on backup servers that is powered off
never overwrite backups unless you're willing to forgo checking
against that data history dating back that far
- it might be hours, days, weeks, months before you find
that you've been had ..
> regularly run chkrootkit and get the server to email the results to you.
i wouldn't place too much confidence on binaries running on suspect
hacked boxes, even if its for sanity checking, and first pass
notifications of something whacky going on
rebooting and running off standalone cd is better, but it means your
server/services will be offline for the duration
any of these IDS is sorta too late .. telling you're [cr|h]acked
i'd tend to spend the time upfront to harden the server as best
as possible for the time/budget that they or you/we provide for
so we can sleep at nights
> if backing up to another server get that server to pull backups out. on my
> new machines i was pushing out the backups from the primary server - this
> would mean a cracker would then have an easy way in to the backup machine
> because i was using authorized_keys so the backup would run in a script.
i say never use keys to do backups ...
- keys can be stolen ... and if you dont require additional
authentication, you're shot
- if you can do it, play with backups, the [cr|h]acker and do it too
- if you lock things down to one ip# ... its less likely the [cr|h]acker
can get that ip# assigned to themself to play with your boxes
always push backups, since remote machines should NEVER have access to
root-read-only files
- push with secure NFS and ssh ...
pc1# mount backup_pc:/Backup/PC1
pc1# scp " copy all new files to remote backup_pc "
requiring manual authenticaion if you're paranoid
pc1# pgp encrypt that new backup data
pc1# chmod 400 "backup data"
pc1# umount backup_pc:/Backup/PC1
> but mainly only run required services - and check them closely - and don't
> rely on your distro to incorporate every single security patch required for
> your server.
bingo
and there's gazillion different solutions .. most works equally well
for each user .. untill they outgrow it for any numberof reasons,
where being cracked will usually result in some new changes
c ya
alvin
Reply to: