Business case for switching to Linux

[John Van Ostrand]

On Fri, 2006-04-07 at 00:26 -0400, Jason Spiro wrote:
> 2006/4/6, John Van Ostrand <john-Da48MpWaEp0CzWx7n4ubxQ at public.gmane.org>:
> > RPM based systems can be fixed quite easily.
> > Altered files can be found with "rpm -Va" and inspected.
> And I don't know much about it but perhaps Anthony Towns' cruft(8)
> utility can do the same thing for Debian-based distros.
> 
> Correct me if I'm wrong, as I am not a sysadmin...

I don't know what cruft does but rpm -Va validates the installed files
by checksum, size, ctime, perms, etc against what was originally
installed.

> But is this really any easier than reimaging when a large enough
> percentage of files on a large enough number of machines become
> infected or corrupted?

Depends on your user base and the desktops. Not all offices use images.
Sure the large ones do, but imaging can remove setup and other data.

An in-place repair can retain all the customizations and works whether
or not an image was used to deploy the system.

Since most rootkits replace the same binaries the procedure could be as
simple as:

chattr -ias /bin/* /sbin/* /usr/sbin/* /usr/bin/* /etc/*
rpm -ivh --noscripts --force procps... psutils... findutils... etc. etc.

A quick ps check will show the nasty the processes. A find using the
date stamp of the worm executable will locate other files. A removal of
the worm exe will prevent it from starting even if you don't check for
startup code (inittab, cron, profile, etc.)

> Reimaging is easy enough that even junior help-desk workers can do the
> repetitive part of the work, and they probably already know how to do
> it. They are less likely to know how to use other tools like rpm -Va,
> and so would have to be taught.

If an intrusion is detected it should not be left to a help desk junior.
A senior or intermediate admin should diagnose, document, evaluate the
risk, scan for others and give help desk instructions on removal.  This
could be a shell script.

> Plus, I assume rpm -Va does not affect binaries not originally from
> any .rpm which is sitting in /usr/local/stow or in a user's home
> directory.

Correct. Binaries not from an RPM will not get checked. Tripwire can be
used instead, or you can create RPM packages for each custom program.
Seems like if one went to the bother of creating, testing and deploying
images, that one would take the time to create RPMS and deploy with
kickstart.

I'm confused about the concern with a user's home dir. How does a
reimage fix a home dir. It either blows it and the user's data away (if
it's local) or it remains intact and ready to re-infect because it's on
a server.

In my experience it has also been that out-of-date servers are the ones
that are most affected by root kits. They have the exposed services.
They also are not usually deployed by images and often are complex
enough that re-installation would cause too much downtime.

--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml