Re: [linux-security] Checking remote servers

[Scott Venier <scott compu-aid com>]

I seem to remember a discussion here a while back about a hacker inserting
a malicious kernel module that modified all the filesystem code to hide
all traces of its presence.  The basic decision was that it comes down to
what would be a reasonable level of protection.  As long as you can come
up with something to protect yourself, you can probably come up with some
way to get around it.  The question becomes, is the exploit worth the
effort it would take to write?  I personally think that putting the
tripwire binary and its database on a PHYSICALLY locked drive is
sufficient.  Of course, you need to make sure that the script that cron
exicutes to run tripwire is check, so a hacker can't simply change the
script to mail a fake report.  Or, to be really sure, ssh in and run the
tripwire verify yourself.

With the number of insecure machines out there, unless you had some REALLY
valuable data, I can't see a hacker going through enough trouble to
rewrite parts of the kernel to cover their tracks.  I think it they would
probably just go find a less secure machine.

Scott

On Tue, 12 May 1998, Andrew Kuchling wrote:

> I'd like to hear some suggestions about securely administering a
> system remotely.  Here's the application: a project is going to
> scatter some server machines around the US.  The server machines will
> be running Linux, with the only network servers being a custom
> application.
> 
> 	Ignoring the separate question of physical security, how can I
> remotely check the system's integrity using Tripwire, 'rpm --verify',
> or some other mechanism?  An obvious first solution is to leave a
> CD-ROM in the machine containing the RPMs (Tripwire database,
> whatever), but a cracker could just put a Trojan version of RPM in
> place.  You could put the RPM binary on the CD too, but then a cracker
> would just have to modify the shell to recognize when the RPM binary
> on the CD is being run, and substitute the Trojan version.  Inserting
> a back door into the kernel's implementation of exec() would handle
> shells, C scripts, and anything else that tries to run that binary.
> Putting RPM on the CD raises the bar, requiring a more sophisticated
> attacker, but it doesn't solve the problem.
> 
> 	If the machine was sitting in front of you, you'd just reboot
> it with a boot floppy, and run a known-good version of RPM from the
> floppy, but that's not an option when the machine's on the other side
> of the country; someone local would have to reboot the machine every
> so often, run the verification, and then reboot again.
> 
> 	(Hmm... a cracker could modify the shutdown scripts to restore
> the original versions of binaries, so the verify would report nothing.
> Perhaps even the check from floppy is no guarantee of anything.)
> 
> 	Any suggestions?
> 
> -- 
> A.M. Kuchling			http://starship.skyport.net/crew/amk/
> Facts were never pleasing to him. He acquired them with reluctance and got rid
> of them with relief. He was never on terms with them until he had stood them
> on their heads.
>     -- J.M. Barrie
> 
> -- 
> ----------------------------------------------------------------------
> Please refer to the information about this list as well as general
> information about Linux security at http://www.aoy.com/Linux/Security.
> ----------------------------------------------------------------------
> 
> To unsubscribe: mail -s unsubscribe test-list-request redhat com < /dev/null
> 

=======================================================================
Scott Venier                                *Consultant for Ingematics,
scott compu-aid com                       A division of Compu-Aid, Inc.
-----------------------------------------------------------------------