[prev in list] [next in list] [prev in thread] [next in thread] 

List:       secure-shell
Subject:    Re: Securing POP with ssh (was: F-Secure SSH for Windows 1.0 available.)
From:       jimd () antares ! starshine ! org (Jim Dennis)
Date:       1997-03-27 16:16:47
[Download RAW message or body]


In article <5986ef$7hm@Venus.mcs.net> 
  les@MCS.COM (Leslie Mikesell) writes:

> In article <595en6$rcj@nnrp1.news.primenet.com>,
> Bryan Ogawa <bkogawa@primenet.com> wrote:

>>>Of course if they replace the programs that are supposed to be
>>>maintaining security with cheap imitations they can grab what you
>>>type, but someone is likely to notice that.  If you have to keep
>>
>>Er... who?  A non-superuser will probably have no real way of telling.  A
>>decent admin could keep this under his hat for weeks or months, and then
>>if/when someone discovered it, could blame a root compromise.
>
>If there is only one person who knows the root password and he's
>out to get you, I'll agree that you don't have much of a chance.

    How to audit a system with a suspect 'root'!

	Before giving the root account to a new admin --
	install and configure tripwire.  Make a copy  of 
	your tripwire binary (statically linked) and the 
	initial database on a removable medium (such as a 
	floppy) -- one the same or another removable medium
	create a boot (or boot/root) "rescue" disk.  Take the
	media to a remote site and lock it in a safe (or a 
	bank safety deposit box).

	Regularly take the media into the office, shutdown
	and restart the system and run tripwire check.

	Regularly -- in ths context -- is dependant on how
	important all of this is to you.

    Automated real-time logging and auditing of a root held
    account

    	To create a system where all of the activities of 
	root are auditable in an inalterable way -- 
	configure the system such that no su to root is allowd,
	connect another, separate, system as the console to 
	the one you want to protect (through a null modem)
	and ensure that 'root' on this "guard dog" system is 
	not held by the account holder(s) to be monitored.

	Install a custom software package to record and relay
	all terminal/console activity through the "guard dog" to 
	the protected system (something basically like 
	kermit SET TERMINAL ESCAPE DISABLED, LOG SESSION filename
	APPEND -- with with some hardening).

	Extra credit if you put WORM drives in the "guard dog"
	-- physically lock the whole system in a special 
	cabinet, and ensure that there are *no* accounts are 
	given on this machine -- the "guard dog" can be 
	completely transparent -- purely relaying connections
	to the protected system.

	(Note: this arrangement is very rarely necessary -- 
	but the current price of hardware -- and the availability
	of FreeBSD and it's ilk make it a fairly inexpensive option
	-- the expensive part would be having someone periodically
	look through the session logs).
	
>I just think that is a lot less likely than having several people
>who know the root password (at least for machines that have to be
>up around the clock) and several others that handle the backup
>tapes.  And more to the point, the fact that you can defend against
>every possibility doesn't meant that you shouldn't do what you can.
>
>>It's *trivial* to swap out binaries like this on the fly.  There is no way
>>for you to check the contents of the executables you run unless root
>>allows it.  People who aren't even *supposed* to have root (and so
>>therefore run the risk of being found with it, even for a second) do it
>>all the time.  If you have root legitimately... 

	This is an oversimplification.
	Out here in the real world the admin has to answer to 
	layers of management and abide by policies set by 
	management. Management can (and should) set up 
	policies whereby the integrity of their systems is 
	ensured.

	At the very least a root password should be held 
	in escrow by an admin's managers.  This should 
	periodically be spot checked at a random time and
	without announcement.

	Having a consultant paid to periodically come in and
	audit systems is a good policy.  The consultant should
	be chosen in such a way as to ensure that he or she
	has no personal relationships with anyone in the
	organization -- and is not involved in any of the 
	corporate politics.

	I've heard too many stories like:

	"he just stormed out and refused to give us the password 
	back" and "I'm afraid to have you come in and do this 
	audit becuase he may quit on us."  

	These sort of policies should be put in place before 
	an admin is hired -- and practiced throughout the 
	SA's tenure.  When I was an SA I recommended these 
	very measures to my boss (most of which he ignored --
	though he did shove the sealed envelope with the 
	backup root account into a locked desk drawer).

	I recommend that SA's suggest these sorts of things
	to their bosses.  The idea is to reassure everyone
	that you're not irreplaceable.  This will make the 
	work environment much more pleasant.  I've also seen
	far too many organizations where the SA is miserable.

>Is it trivial to alter files without changing their ctimes?  Don't
>most systems where things like this matter have scripts that check
>for changed system files regularly?  (Yes, I know, root can break
>these easily, but it keeps getting less trivial to do it and remain
>undetected).

	You can do quite a bit with simple remote syslogging
	(add the appropriate line to your /etc/syslog.conf).

>>Remember there are many times when it's legitimate to swap binaries.
>Yes, but then it is likely that other people will know about it.

	Any changes to system binaries or libraries should be duly
	noted in the system's README file.

	WHAT!?!  -- you don't have a file named /etc/README.$(hostname)
	-- FOR SHAME!  Create one *right now* (and get fifty backslashes
	with a wet null-modem).

>>Not that I suggest having passwords in plaintext hanging around, mind you. 
>>I'm just saying (like the other poster, I think) that if you don't trust
>>root on both ends, you have to believe that everything you type is
>>trivially compromised. 
>
>Are you sure you would categorize catching a ssh-encrypted password
>as 'trivial'?  I'll agree it is possible.  I don't think I would
>want to pay what it would cost to hire someone to do it.
>
>Les Mikesell
>les@mcs.com
-- 
Jim Dennis,                                info@mail.starshine.org
Proprietor,                          consulting@mail.starshine.org
Starshine Technical Services              http://www.starshine.org

        PGP  1024/2ABF03B1 Jim Dennis <jim@starshine.org>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 

[prev in list] [next in list] [prev in thread] [next in thread]