[sf-lug] how to whack crackers

[jim]

backupninja seems to be available for ubuntu 
and is in the universe repository. there seem 
to be bugs and problems with it, though that 
shouldn't necessarily stop me. i'll read up 
more and report. 



On Mon, 2009-01-05 at 18:17 -0800, toya wrote:
> A good tool for backup is 'backupninja' there is a package for debian and
> probably for ubuntu. 
> toya
> 
> 
> Em Mon, Jan 05, 2009 at 05:52:26PM -0800, Rick Moen escreveu:
> > 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.
> > 
> > 
> > _______________________________________________
> > sf-lug mailing list
> > sf-lug at linuxmafia.com
> > http://linuxmafia.com/mailman/listinfo/sf-lug
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>