[nSLUG] my system was cracked!
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
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
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.
More information about the nSLUG