[sf-lug] how to whack crackers

[Rick Moen]

Quoting Asheesh Laroia (asheesh at asheesh.org):

> On Mon, 5 Jan 2009, jim wrote:
> 
> >   i cannot figure out a good backup scheme. the one
> > that copies absolutely everything from certain
> > directories each night is inelegant.
> 
> I disagree; it's magically elegant. Back up the whole filesystem, and then 
> you know that if you lose that filesystem tomorrow you have a copy of it 
> for later. On this point I think Rick and I disagree, but to me, the 
> confidence I get knowing I have the entire filesystem backed up means that 
> I don't ever have to worry about my backups excluding a file I wanted, nor 
> about spending time configuring the backups.  Disks are cheap, and Asheesh 
> worrying is expensive.

Whatever works, really.

I happen to have put in a lot of time getting to know what's on my
system and where everything lives.  Fortunately, Linux systems cooperate
by being very, very consistent about where things go.  The complete list
happens to be, in my server's case:

/root/*                      Root user's home directory
/etc/*                       System configuration files
/usr/lib/cgi-bin/*           CGI scripts (omit PHP binaries)
/var/lib/mysql/*             MySQL database files 
/boot/grub/menu.lst          GRUB bootloader configuration (just 1 file)
/var/spool/exim4/*           Exim and SA-Exim internal files
/var/spool/news/*            NNTP news spool for Leafnode
/var/spool/mail/*            SMTP mail spool
/var/lib/mailman/archives/*  Mailing list archives for Mailman
/var/lib/mailman/data/*      Mailing list state and other data
/var/lib/mailman/lists/*     Mailing list definitions for Mailman
/var/lib/mailman/nntp/*      Mailing list NNTP gateway data
/var/lib/mailman/qfiles/*    Mailing list in-process data
/usr/local/*                 Locally installed files and records
/var/www/*                   Public http, ftp, rsync tree
/home/*                      Non-root users' home trees

Plus, export (to a file in /root) of the package database contents 

   dpkg --get-selections "*" > /root/selections-$(date +%F)

...and partition maps of the two hard drives:

   disk -l /dev/sda > /root/partitions-sda-$(date +%F)  Partition map of sda
   fdisk -l /dev/sdb > /root/partitions-sdb-$(date +%F)  Partition map of sdb

...and a dated snapshot of the all-important /etc tree

   tar cvzf /root/etc-$(date +%F).tar.gz /etc

That's literally everything that cannot be reconstructed (and updated at
the same time) from trusted Debian package contents -- and is a great
deal smaller, quicker to copy, etc.  Important when you backup to
offsite over a congested aDSL link, for example.

Along the lines of "whatever works", if re-copying to backup media the
same basically irrelevant and seldom-changing files in /usr/bin,
/usr/lib, /usr/share, etc., isn't a problem, great.  If the extra time
and room makes it marginal whether you'd bother doing backups at all,
then that's important.

The way you know that you've gotten everything is using the only test
that ever matters for _any_ backup, "whole filesystem" or not:  See if
you can restore a functional machine using it, starting from bare metal.




> Okay, so it's for cleanliness, not security? Then use fail2ban to tidy 
> that up.

If thy logging offend thee, _reduce_ it.  Or, better yet, just ignore what
doesn't matter.

Dunno if this explanation applies, here, but often I see people
scrambling for things like "fail2ban" because they've just installed a
log-analysis tool like logcheck, and are all hot and bothered by the
e-mailed reports, which suggest menacingly that things like dictionary
attacks against sshd are serious threats.  Those people (of whom I
speak) then install blocking software, iptables rules, etc., _solely_ 
to make logcheck's menacing e-mails go away.

The smarter approach is, of course, to just edit logcheck's
configuration to make it cease doing a Chicken Little impression every
time someone rattles the doorknob.