Re: Best way to duplicate HDs
> On Wed, 2 Jan 2002 00:44, Jason Lim wrote:
> > > > The idea being that if there is a virus, a cracker, or hardware
> > > > malfunction
> > >
> > > And if you discover this within 12 hours... Most times you won't.
> >
> > We've got file integrity checkers running on all the servers, and they
run
> > very often (mostly every hour or so) so unless the first thing the
cracker
> > does is to "fix" or disengage the checkers then we SHOULD notice this
> > within the 12 hours... or make that 24 hours to give a bit more
leeway.
>
> The first thing any serious cracker will do is to stop themselves being
> trivially discovered. This means changing the database for the file
> integrity checkers etc. Also if you're running a standard kernel from a
> major distribution then they can have pre-compiled kernel modules ready
to be
> inserted into your kernel. They can prevent the rootkit from being
> discovered (system calls such as readdir() will not show the file names,
> stat() won't stat them, only chdir() and exec() will see them).
>
> To alleviate this risk you need grsecurity or NSA SE-Linux.
>
> At the moment if you want to make your servers more secure in a way that
is
> Debian supported then grsecurity is your best option. It allows you to
> really control what the kernel allows. Run something in a chroot() and
it'll
> NEVER get out. Run all the daemons that are likely to get attacked in
> chroot() environments and the rest of the system will be safe no matter
what
> happens.
>
> Grsecurity allows you to prevent stack-smashing and prevent chroot()
programs
> from calling chroot(), mknod(), ptrace(), and other dangerous system
calls.
> Also it does lots more.
>
> I used to maintain the package, but I have given it up as I'm more
interested
> in SE Linux. The URL is below.
> http://www.earth.li/~noodles/grsec/
>
> Any comparison of amount of time/effort/money vs result will show that
> grsecurity is much better than any of these ideas regarding swapping
hard
> drives etc for improving security.
>
> > Well, as said before, unless the cracker spends a considerable amount
of
> > time learning the setup of the system, going through the cron files,
> > config files, etc. then hopefully there will be enough things set up
that
> > the cracker will be unable to destroy or "fix" everything.
>
> Heh. When setting things up I presume that anyone who can crack my
systems
> knows more about such things than I do. Therefore once they get root I
can't
> beat them or expect to detect them in any small amount of time.
>
> Once they get root it's game over - unless you run SE Linux.
Of course, hackers/crackers are only one thing that needs to be "solved".
Hardware failure, etc. also needs to be taken into consideration. But your
points are very correct, and I will investigate grsecurity as an
additional means to secure the systems. My hopes are only that by
increasing the number of detection methods, backups, etc. that it will
make it harder, not impossible (is it ever impossible?), for a cracker to
cripple/destroy a system.
> > And regarding data loss, so far the most common thing for us is to
have a
> > HD become the point of failure. We've had quite a few CPUs burn out
too
> > (no bad ram yet, lucky...), but nothing except a bad HD has seemed to
> > cause severe data loss.
>
> So RAID is what you need.
Actually your three-disk RAID solution sounded pretty good... I'll look
more carefully into the "standby" mode for a RAID disk and such, and see
how well it would work.
Sigh... and I was hoping for a simple solution like cp /mnt/disk1/*
/mnt/disk2/ :-/
Reply to: