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

List:       osiris-devel
Subject:    RE: [Osiris-devel]Osiris Auth Scheme
From:       "Bruce Potter" <gdead () shmoo ! com>
Date:       2002-06-23 16:08:40
Message-ID: 012e01c21ad0$41ec4c40$9600a8c0 () duffman
[Download RAW message or body]

This looks great.  Pretty much what I had in mind (but much more
coherent ;)

later

bruce

> -----Original Message-----
> From: osiris-devel-admin@shmoo.com 
> [mailto:osiris-devel-admin@shmoo.com] On Behalf Of Paul Holman
> Sent: Friday, June 21, 2002 5:57 AM
> To: osiris-devel@shmoo.com
> Subject: [Osiris-devel]Osiris Auth Scheme
> 
> 
> Brian and I have discussed the crypto requirements for Osiris 
> 2.0 over 
> the last couple months, and tonight I outlined for him, the general 
> approach that I think we should take.  I won't cover all the 
> supporting 
> data at how we've arrived at this here, but if any part of it 
> concerns 
> or interests you, please feel free to ask me about it.
> 
> There are effectively three components in Osiris 2.0:
> 
> 	osirismd - Osiris Management Daemon
> 	osirisd  - Osiris Daemon (client component for scanning hosts)
> 	osiris   - Command line UI
> 
> Each of these components communicates with the others via the 
> network.  
> The osirismd is meant to run on one or more management hosts, osirisd 
> must be installed on every client you want to scan, and osiris is a 
> feature-complete but not feature-rich reference UI that will 
> someday be 
> supplanted by a full GUI.  Note that communication between 
> components is 
> as such:
> 
> 	osiris <---> osirismd <---> osirisd
> 
> First, I propose that each of these components talk to each 
> other using 
> HTTPS (SSL secured HTTP).  This is very easy to do thanks to OpenSSL.
> 
> Second, I believe the most important thing is for the clients to 
> authenticate the management host.  You don't want them responding to 
> impostors.  So osirismd will have the equivalent of a web 
> server cert, 
> and osirisd instances will only communicate with an osirismd 
> that they 
> trust.
> 
> Third, the osiris UI will also communicate with the osirismd 
> vi HTTPS, 
> authenticating the server's cert.  The osirismd will 
> authenticate these 
> UI users via user/pass over that secured connection.  This 
> should all be 
> viewed as identical to a typical secured browser/web server 
> interaction.  Eventually, osirismd will offer various user management 
> and ACL functions.
> 
> A more detailed description of the procedures follows:
> 
> osirismd - This app needs to implement a feature for generating a 
> keypair.  Ideally, this is performed once per site.  I 
> suggest that we 
> use OpenSSL to generate a keypair and a self-signed server cert, like 
> the snake-oil cert typically generated for an Apache install. 
>  There is 
> no root cert, this cert must be trusted on it's own merits.  
> We can make 
> up our own X.509 extension to indicate that a cert is valid 
> for use with 
> Osiris.  If people wish to integrate with their own PKI, they 
> can swap 
> out this cert for one they generated on their own.  The cert 
> should be 
> stored in $OSIRISHOME/certs and the key in 
> $OSIRISHOME/private.  All the 
> same conventions as Apache should apply, if a user wants to keep the 
> private key encrypted, then a password will be needed when 
> osirismd is 
> started, otherwise it can start anytime.  The osirismd needs it's own 
> user/pass database with ACL support to control which hosts/configs a 
> given user can run.  Personally, I'd like to see this hooked into the 
> operating system's user accounts, just create an "osirisadmin" group 
> that is allowed to login.  The osirismd must have the ability to 
> generate a random session key per host and store hashes of them in 
> $OSIRISHOME/hosts/$HOSTNAME/host.conf.
> 
> osirisd - This application will be installed in various ways, 
> depending 
> on platform and user preference.  The first time it is run, it will 
> allow connections from any osirismd but will save the cert on 
> disk and 
> permission it read only.  All future connections from an 
> osirismd will 
> be authenticated by this cert.  Think of this as an initialization 
> process similar to what you experience with SSH the first time you 
> connect to a new host.  The key fingerprint can be shown in 
> syslog and 
> manually verified.  The client can be reset to it's virgin state by 
> simply deleting this cert from the filesystem.  The osirisd should be 
> built to trust either a cert, or a root.  It should also 
> check for the 
> Osiris extension in the cert.  This cert should be stored in 
> $OSIRISHOME/certs on the client.  Note that no private key or config 
> exists on the client filesystem.  When osirisd starts up, 
> osirismd must 
> connect to it, providing a new symmetric session key and logging an 
> alert that the osirisd instance has been cycled.  The session key is 
> made persistent on the osirismd server, but is stored only in 
> RAM on the 
> osirisd client, this ensures that the server can always tell 
> if osirisd 
> has been cycled.  Additionally, a scan of the osirisd binary, 
> and cert 
> should be added at the beginning of every scan and compared to a 
> reference in $OSIRISHOME/hosts/$HOSTNAME/host.conf on the 
> osirismd host 
> to ensure that the software hasn't been tampered with.  
> Failure to pass 
> this test generates dire log events and any scans performed must be 
> flagged as "untrusted."
> 
> osiris - This app works just like osirisd as described above 
> except that 
> it initiates a connection to osirismd instead of the other 
> way around.  
> It should have the same server cert stored in $OSIRISHOME/certs.  The 
> osiris UI app must provide a facililty for sending username/password 
> credentials to osirismd.
> 
> Please keep in mind that Osiris is a host based intrusion detection 
> tool, so it is paramount for us to identify changes to the 
> client hosts 
> which run osirisd.  At the same time, we don't want to 
> provide a false 
> sense of security by attempting to obscure, inveigle and obfuscate 
> authentication credentials in the client.  This is truly impossible 
> without the aide of tamper-proof crypto devices (Hardware Security 
> Module).  In our scheme, a client is trusted only as long as it is 
> running, and we "do our best" to revalidate it after it is 
> cycled.  We 
> believe the best authentication of the client is going to be the scan 
> history stored on the osirismd machine.  The greatest 
> challenge we can 
> present an attacker is having to spoof an entire osiris scan.
> 
> Thanks, please feel free to talk to me more about this anytime.
> 
> pablos.
> --
> Paul Holman
> The Shmoo Group
> pablos@shmoo.com
> 415.420.3806
> 
> 
> 
> _______________________________________________
> Osiris-devel mailing list
> Osiris-devel@shmoo.com 
> http://www.shmoo.com/mailman/listinfo/osiris-> devel
> 




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