Immutable Security

I have been studying Oracle logging for the last couple of weeks. Oracle can log to the SYS.AUD$ table within the database, a flat file, XML file, or it can use the OS logging facility (in Windows this is the event log; in ‘nix, it is syslog).

Preferring ‘nix-based solutions, I downloaded Oracle XE 11g for Linux and configured it for logging to syslog. It wasn’t long before I had logs like this:

Dec 28 22:32:41 localhost Oracle Audit[4958]: ACTION : ‘CONNECT’ DATABASE USER: ‘/’ PRIVILEGE : SYSDBA CLIENT USER: username CLIENT TERMINAL: pts/2 STATUS: 0

At first glance, it looked like a pretty standard syslog message, but after having some issues getting OSSEC to pre-decode it properly, I decided to check the RFC to see if it was technically compliant. Here is the relevant part of RFC 3164.

The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field. Most commonly, the first character of the CONTENT field that signifies the conclusion of the TAG field has been seen to be the left square bracket character (“[“), a colon character (“:”), or a space character. This is explained in more detail in Section 5.3.

Did you spot it? The problem is that Oracle likely intended the string ‘Oracle Audit’ to compromise the TAG field (program or process name); however, the TAG field in this case really is just ‘Oracle’ since it is terminated by a non-alphanumeric character (the space).

So is it compliant? I would have to say yes, but I don’t think it is compliant in the way they intended. Simply removing the string ‘Audit’ in this case would have made a clearly compliant and understandable message.

You set up a centralized logging server. Check. You installed the OSSEC manager to analyze your logs in real-time. Check. You even managed to implement high availability. Good going! Now your ready to start configuring clients. It should be as simple as installing an agent and pointing it to the log server, right? Maybe so, but don’t forget these other important steps to make the most of your logs.

1. Set the time to sync with at least one time source. Three is even better. If you don’t ensure the client has synchronized time, putting an event timeline together after a compromise is going to be that much more difficult. With properly synchronized time, patterns emerge that you might otherwise miss.
2. Set the auditing policy. Unless you tell your system what to audit, there may never be any logs to send to the log server. For a Windows domain, a well configured group policy can ensure consistency across the enterprise. For stand-alone Windows systems, a security template can serve the same purpose. For ‘nix systems, pay special attention to the facility and priorities in syslog.conf
3. Review services which listen on the network. Did someone install WinSSHd on the Windows server you configured for logging? If you only look at the usual three Windows logs, you could be missing important information about potential attacks. Make sure to review the output of “netstat -an” for clues as to what may be offering services on the host. Once identified, configure them for logging.

Finally, it pays to take a few moments to make sure logging is working as intended. Countless administrators and log analysts have been bitten by situations where they try to refer to logs after a breach, only to find they’re not there.

Oh, and about that whole ballet thing from yesterday, well, I have decided that pink is not my color after all. Now that April Fool’s day is over, let’s get back to business. :)