[nSLUG] my system was cracked!

Dop Ganger nslug at fop.ns.ca
Sat Jun 3 10:27:48 ADT 2006


On Sat, 3 Jun 2006, ricardd at mathstat.dal.ca wrote:

> So, short of hiring a sysadmin, what should I do to protect myself against
> this? I'd like to get a "checklist" of things that I should watch for
> after I reinstall. For example:
>
> - run a firewall

Run a firewall with the default input policy set to drop or deny packets. 
You may also want to set the default policy for output and forward to drop 
or deny, too. Enable logging so you can see what's going on; here's a 
snippet from one of my workstations that's connected directly to the net:

iptables -A OUTPUT -o $EXTETH -m limit --limit 10/minute --limit-burst 10 -j LOG --log-level DEBUG --log-prefix 'AFWO: '
iptables -A OUTPUT -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i $INTETH -j ACCEPT
iptables -A INPUT -i $EXTETH -m limit --limit 10/minute --limit-burst 10 -j LOG --log-level DEBUG --log-prefix 'DFWI: '
iptables -A INPUT -j DROP

> - change the ssh listening port to something other than 22

Also restrict access by IP - if you're only going to connect to your 
laptop from (say) Eastlink, you don't need to allow access from China. 
Don't pick an "obvious" alternate port number like 2222 as those ports are 
being scanned for too - pick a completely random number.

> - use strong passwords for everything (the postgres password was weak)

Was Postgress accessed from the Internet?

> Suggestions, comments?

lsof -ni TCP
lsof -ni UDP

Check the ports that are open and remove packages that you don't need. 
Ubuntu's server install is very good about this - the default install has 
*no* ports open (unlike Debian, which persists in installing portmap and 
nfs-common).

Chroot everything you can. It's not a stellar method, but every obstacle 
you can put in the way of script kiddies is worth it.

Have a separate partition for /tmp and mount it noexec. Note that this 
will cause problems for dpkg as install scripts are executed from /tmp by 
default. If you don't have any applications that use /var/tmp then remove 
it or make it immutable with chattr +i - a lot of rootkits use /var/tmp to 
fire off from.

Take a look at the BSD secure levels LSM (see 
http://www.samag.com/documents/s=9304/sam0409a/0409a.htm for details). One 
of the really nice features is to make the immutable flag *really* 
immutable, so you can chattr -R +i /usr/sbin /usr/bin /sbin and not worry 
about rootkits trying to overwrite /sbin/init - a favourite target. Bear 
in mind that this will break updates unless you disable secure levels and 
remove the immutable bit. BSD secure levels can also let you disable 
network administrative tasks such as binding to a port, thus stopping 
backdoors from running.

Install debsums, and put in a cron job to do debsums -c every night (if 
you leave your laptop running permanently). In addition, install a file 
checksum utility like tripwire or aide. Install logcheck, finetune it to 
remove the junk that gets generated, and read the reports.

Install cron-apt to automatically download updates nightly, and email you 
reports. Install the updates manually once a week, or more often if 
there's a critical update.

Once you've got your laptop reinstalled and set up how you like it, take a 
backup (I use mondo, since it creates a bootable bare metal restore CD). 
That way, if you get rooted again, you can restore fairly quickly once you 
analyse what went wrong (and then you can create a new backup with the 
fixes). Keep your critical data in one place (in your home directory) and 
keep that backed up too. Backing up to remote machines is a good idea - I 
have some data I *really* don't want to lose backed up to several machines 
around the net, including one in Australia, as well as backing it up to 
CD.

Install portsentry. This will automatically drop most script kiddies as 
soon as they start scanning on sensitive ports. Just null route the 
connection (route add -host $1 reject), don't bother with anything else.

Finally, if you leave your laptop running 24/7, you may need to disable 
power saving (hdparm -B 254 /dev/hda). A lot of laptops seem to park the 
drive heads once a minute or so, which will save your data if the laptop 
is dropped, but can wear the landing mechanism relatively quickly (I've 
seen reports of drives dying in 4 or 5 months). Check the load cycle count 
in smartctl, and if it goes up at a constant rate consider disabling power 
saving. Remember to re-enable it if you go onto battery power, using a 
script called by acpid.

Cheers... Dop.

!DSPAM:44818eb7145431928073269!




More information about the nSLUG mailing list