Re: [linux-security] Re: Checking remote servers

[PaZeN <pazen pazen ml org>]

The best and easiest way to Admin Remote Servers is to connect via a call-back
system and admin it using telco lines.  Then you would have relitively little
chance of being attacked via the internet, and all but the best system crackers
know how to subvert call-back (those you can't stop anyways).  There is a
cheaper/easier way to change a write protected filesystem.  This is to use a
ZIP/Jaz disk from iomega (www.iomega.com).  With these disks you can write
protect the disk using a password.  That is what I would do.

PAZEN, AAmaral, pazen pazen ml org 

P A Z E N                                            eMail:pazen pazen ml org
Consulting                                            WWW:http://pazen.ml.org
UNIX (SVR4 & *BSD*), NT,                         C/C++, COBOL, SQL, HTML, XML
* Linux Powered *     "Intelligence is a double edged sword, weild a shotgun"

On Wed, 13 May 1998, Andrew Kuchling wrote:

//PaZeN writes:
//>How many users are going to need access to each system?
//>Where are these users logging in from? (i.e. telnet, dumb terminals, 
//>     xterminals, etc)?
//>What is the single app/daemon that you need to run?
//>What kind of breakin are you most afraid of internel or external?
//
//	The application involves connecting a server machine to a
//controllable microscope; these microscopes would be at fabrication
//sites all over the place.  (Centralizing them is not an option.)
//Users would run client programs that connect to a custom daemon
//written for this application that lets them control the microscope and
//view images; The machines therefore need only run sshd (to let the
//administrator log in) and the custom server; no sendmail, named, ftpd,
//or anything else need be running.
//
//	Users would be connecting over the Internet at large, not
//via a private network, so the servers are vulnerable to the same
//attacks as any Unix system.  Obviously physical security and the
//security of the daemon are also very important, but they're not what
//I'd like to discuss.
//
//	Discussing this with a friend last night, he suggested burning
//a CD-ROM with a live filesystem, and running off the CD.  The hard
//drive would then be only used for storing data files and /tmp; if
//logging is done to another machine, there are no logs to be written
//locally.  That's a very good idea, I think; if the system can be set
//up to boot from the CD-ROM and then mount it as /, that would make
//substituting Trojans very difficult.  Fixing bugs in the system would
//then require burning a new CD and sending it via Fedex, which would be
//highly annoying, but that can probably be tolerable.
//
//Kevin Smith wrote:
//>I would use tripwire... (definately not rpm -Va)...  use tripwire, which
//>you should have on a cdrom, including all of the checksums... all of it
//>on the unmodifiable cdrom... or even store it all locally, and write a
//>script that will ssh into the machine, install a tool to get the checksums
//>or whatever you need... run all the tests on the checksums locally, and
//
//	Hm; what's wrong with 'rpm -Va'?  Obviously, this would have
//to be run against RPMs on the CD, not against the possibly compromised
//database on the hard drive.  Or is it that rpm only has MD5 checksums?
//
//-- 
//A.M. Kuchling			http://starship.skyport.net/crew/amk/
//People marry most happily with their own kind. The trouble lies in the fact
//that people usually marry at an age where they do not really know what their
//own kind is.
//    -- Robertson Davies, _A Voice from the Attic_
//
//-- 
//----------------------------------------------------------------------
//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
//