RE: [linux-security] Checking remote servers

["Gregory S. Youngblood" <zeta tcscs com>]

For the ultimate in paranoid systems that don't change much, you could put a
CD in that is bootable and boot a live file system from it.

Then you could mount your hard drive for storing logs and your data.

Assuming everything but data is on the CD it would make things much more
difficult for a hacker to install and make changes.

This again assumes that user home directories and root directory and all
programs are on a CD.

The only problem is that it makes it impossible for you to make changes to
the system to fix holes or other problems. Of course, as long as you keep
your original system in tact, then updates are as simple burning a new CD
and fedex it to the remote locations, shutdown, change CDs, reboot, and new
system.

I don't know how feasible this is, I haven't done it or even seen it done,
but I have thought about it. And, after seeing the SuSE cd boot it made
realize how feasible it could be.

Greg

-----Original Message-----
From:	Andrew Kuchling [mailto:akuchlin cnri reston va us]
Sent:	Tuesday, May 12, 1998 3:55 PM
To:	linux-security redhat com
Subject:	[linux-security] Checking remote servers

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