On Wed, 15 Aug 2001, Ogle Ron (Rennes) wrote: > What's worse is that these people even use an automatic SSH or SSL > connection directly to the log server. This means that now the hacker has > direct SSH connection right on the log server without having to guess a > password. They do this believing that they are protecting the channel, but > in reality they are hiding all activity of the hacker from any sniffer or > NIDS. I disagree. The benefits of ssh are: authentication - each machine must identify itself to log in to the server; thus, compromising box A means that the attacker gains nothing as far as box B's logs (i.e., it cannot forge logs for box B). confidentiality - breaking box A on the "admin" LAN does not allow the reading of logs on box B 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,no-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 - 08:41:02 PDT