On Thu, 18 Oct 2001, Nick Vargish wrote: > Our NFR SLR will raise an alert window on an admin's screen if an alarm > condition is matched... And the connection between the admin's console and > the logbox is authenticated and encrypted. If you are routing logs from a > machine that can run the agent software, the transmission of messages from > the host to the logbox can also be encrypted. OK. So that is *as good* but not better than sshing to the logbox. That is, neither can be broken from the network without breaking the strong encryption. However, both are susceptible to attacking the admin workstation (e.g., I could Back Orifice your workstation and trojan the NFR administrator program, or I could steal whatever authentication tokens you use to grab the data). > If the attackers can compromise the admin workstation, you've pretty much > lost already, in terms of actively catching the attack. This is a > very-bad-case scenario... Maybe, maybe not. You can still win by logging in on console to the log box to review the logs. > In the case of the NFR SLR, the attacker would need physical access to the > logbox to compromise the logs stored there. And without an admin password, > she would have to do it with a sledgehammer or a Very Large Magnet. Or a buffer overflow in the NFR appliance. :) The system I've set up similarly robust. It works like this: - logging clients send their log data realtime to the log server - logging clients authenticate themselves to the logging server with a key stored on the client's disk; the key allows exactly one thing to happen, which is that log data may be appended to the log - all log data that is sent is stored, regardless of perceived value - log entries are processed in real time using an "allow known good" strategy -- anything not marked "good" is relayed to the admin - messages to be relayed are sent to a local mail account - admins log in using the local mail account to review the "interesting" log entries (we use IMAP tunneled through ssh for this) - if something merits further attention from the admin, they must log in on console to the log box In the case of an attacker compromising an attacker's workstation, then the "interesting" messages can be hidden. I decided to concede this as it vastly increases the convenience for the admin, without decreasing security too much (mainly from the perspective that the attacker is going through such incredible hoops to prevent their intrusion from being known). However, the logs *cannot* be erased without logging in on console to the box. Additionally, we use the unix filesystem permissions as an additional measure. If there's a bug in the receiving side of the logs and it is compromised (read: arbitrary code execution), you can still only affect logs for the host you broke (assuming that the bug is not an overflow during authentication), since each logging client gets its own UID. If you can find a bug in the reviewing IMAP side (much more likely), you can delete "interesting" mails, but you can't touch the actual persistent storage of the logs (they are owned by different users). -Jeff --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Thu Oct 18 2001 - 13:50:12 PDT