RE: [loganalysis] Re: Central syslog server best practices?

From: Ogle Ron (Rennes) (OgleRat_private)
Date: Thu Aug 16 2001 - 03:14:54 PDT

  • Next message: Corey Steele: "Re: [loganalysis] Logging standards and such"

    If you are only copying the syslog on a periodic basis from the log server
    to the client machine than this may work.  However this isn't the case in
    most situations.  Normally you would create a tunnel.  The problem with a
    tunnel is that SSH nor IPsec was meant to protect the actual machine once it
    has been compromised.
    
    In your example, I could easily rename a shell program /usr/bin/cat.  The
    other machine has not control over that.
    
    I agree with other emails, that the encryption must be built into the
    service like syslog over SSL for the specific purpose of syslogs.
    
    Ron Ogle
    Thomson multimedia
    Rennes France
    
    > -----Original Message-----
    > From: Jeff King [mailto:peff-loganalat_private]
    > Sent: Thursday, August 16, 2001 4:59 AM
    > To: Ogle Ron (Rennes)
    > Cc: 'Nate Campi'; Greg Broiles; Marlys A Nelson;
    > loganalysisat_private
    > Subject: RE: [loganalysis] Re: Central syslog server best practices?
    > 
    ......
    > The problem you're talking about is authorization. Meaning 
    > that people who
    > set this up do not correctly specify what the entity 
    > authenticated by the SSH
    > key is allowed to do. The only sane thing to authorize for 
    > such a key is
    > "append data to the log". Certainly not a shell login. :)
    > 
    > You can do this fairly easy with OpenSSH by specifying in your
    > authorized_keys file:
    > 
    > from="my.host",command="/usr/bin/cat 
    > >>/var/log/my.host.log",no-port-forwarding,no-X11-forwarding,n
    > o-agent-forwarding,no-pty ssh-dss YOUR_KEY_GOES_HERE
    > 
    > Although as an additional measure, I would suggest that each 
    > logging client
    > get its own unix UID on the server, in case a flaw in SSH (or 
    > cat) is found
    > wherein a client can break out of this sandbox. In that case, 
    > at the very
    > worst you have allowed an attacker to erase logs for the 
    > compromised machine.
    > 
    > -Peff
    > 
    > 
    > 
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: loganalysis-unsubscribeat_private
    For additional commands, e-mail: loganalysis-helpat_private
    



    This archive was generated by hypermail 2b30 : Thu Aug 16 2001 - 09:23:57 PDT