Phil Gall wrote: > Greetings, > > We are trying to determine the best replacement for our current IDS. We have > installed the server and multiple clients. So far we are very impressed with > this package! There does seem to be some concern about the plain text .conf > file that holds the data on the client machines. Especially if the file has > the database name, IP and password of the OSSEC server. Currently our IDS > system has its config files encrypted with PGP/GPG keys. Is there a way to > tighten access to the client ossec.conf in a similar manner?
Hello Phil, OSSEC has several countermeasures in place to protect against unauthorized clients. Among them: 1. Replay protection. When messages are sent to the server, OSSEC keeps track of them so as to prevent replay attacks. 2. Host ACLs. The ossec.conf should be protected by file system ACLs such that if a user can access this file, they probably have rooted the box already. On a Unix system, this file should only be readable by root and the ossec user; on a Windows system, the file should only be readable by Administrators and SYSTEM (if I recall correctly). Both of which, if compromised, already mean loss of system integrity. 3. The session is authenticated and encrypted through the use of a symmetric key, which should be located in client.keys. There should be no passwords in either file. And again, this file should be protected with the same ACLs/permissions. Just to clarify #3, this is not an uncommon configuration in either Windows or Unix when symmetric cryptosystems are used. I suppose OSSEC could use an asymmetric system, but I'm not sure what value that would provide. The private key would still have to be available. I don't know if OSSEC does this already, but one suggestion for a new release might be to fail-safe if the permissions on the critical files aren't correct. I would venture to say anything it finds world-writable should cause it to fail to start, as well as world-readable on certain key files. For extremely special situations, there could be a --allow-dangerous-permissions option. The implementation in your current IDS system sounds interesting, but I wonder how much actual security it provides. If the information is encrypted, and the plain text information is used to authenticate the HIDs, then it stands to reason that this has to be decrypted in order to send the authentication information. If that's the case, then the private key has to be available in order to decrypt the file. If that's the case, it's probably protected by ACLs. The private key could be protected in a smart card or cached through an agent, but in my experience I rarely see this level of diligence. Perhaps you could elaborate on how your current IDS works. HTH, Mike
