Auditing and Logging

Is auditing and logging enabled on your servers and workstations? I bet many of you answer “yes”. My follow up question to your reply would be “When did you enable it?” That's right folks, basic logging is NOT enabled by default within Windows. This may come as a surprise to some but Windows Event logs are not considered basic auditing and logging. 

 Strap on your tinfoil hats and follow along with this scenario: Imagine that your database server is hacked. You are tasked with finding out what happened. Which files have been modified? Who hacked the machine? How long has it been compromised? Was it an inside job? 

 Lets start with the server itself; Which files have been modified recently? Probably easy enough to figure out by looking at the timestamps. Now, who modified them? What's that? You don't have logging enabled for object access? Or directory access? That's right, it's not enabled by default.

 Perhaps you can narrow down the time frame to somewhere between 2-2:15 AM last Sunday night. So, who logged into the server at that time? What, you don't log successful and failed logons? (again, not enabled by default) You get the picture………

 Another real world example: A colleague was having issues with an Exchange server sending large amounts of spam. Apparently an external entity was using the box as a relay, yet the box was not misconfigured as an open SMTP relay. So what was going on? Basic Exchange logging was useless. After enabling detailed logging, it was discovered that a 3rd party backup utility installed on that server and configured with default credentials was being used to obtain a valid logon and send mail through the box (let this be a lesson about changing default credentials).

 As we can see, logging and auditing is very important. You can utilize it for forensics purposes, to detect anomalies before real problems surface, troubleshooting, and to gain a better understanding of what is going on within your network.

 One of the oldest forms of logging is syslog, from the Unix world. This is an accepted standard and format that *nix machines have used forever. Unix and it's variants are very good when it comes to logging (some may say a bit too anal about it). These machines tend to log all operating system and user related events along with a majority of events generated by any applications running on the machines. Troubleshooting becomes very easy with this detailed level of logging. 

 But, alas, we're not here to talk about *nix machines only. Windows uses the Event Logs to keep track of what's happening with the device. The only pitfall is that even basic events are not logged by default. Successful and failed logons, object access, etc, is not logged. I can't stress how important it is that you develop a policy of enabling this on all of the servers that you build. Here's a good primer on getting started:

Recommendations on what to log

A simple "how to"

 All of this logging tends to rapidly eat up drive space, which is most likely why it is disabled by default in Windows. You will find that the best solution to this is centralized log aggregation (required for regulatory compliance in many industries). Basically, you point all the logs from all of your servers to one log server device. This gives you a central repository for the information and allows you to control access to the logs (an important security consideration) and increase your log retention time (dedicated space for log storage). Most central log servers also have a search interface and some even have a correlation engine that allows you to set up alerts based upon certain thresholds or events. Examples include the Kiwi syslog products, Cisco Mars (more of Cisco-centric product), a simple home-built Linux syslog server, xDefenders ESM appliance (shameless plug), etc.

 There are some issues with central logging in a network environment, not the least of which is the fact that Windows Event Logs are created in a proprietary format that is not directly compatible with the syslog standard. This is not a problem if you have a pure Windows network, don't want to log anything from your firewalls, switches, routers, etc., and are using a central log server that understands the Event Log format. I prefer to not only log my servers, I also want all that juicy information from my other network gear as well. Fortunately there is a solution in the form of products that can convert Event Log to syslog format. The best one by far (in my experience) is the Snare Agent for Windows. This product is free (everybody likes “free”), does a great job of formating the information into the syslog standard, and has a very powerful web-based interface to configure stuff to your heart's delight. The best feature of the Snare Agent is the fact that during the installation process it will ask you if it should enable some basic auditing and logging. Nice!

Get Snare Agent for Windows here

 In summary, enable some basic logging on all of the important devices on your network, implement a central log server, and start to utilize the benefits that logging can provide for you. Some day you'll thank me.

Copyright Todd Hughes 2008

Yahoo releases the Zimbra Desktop

    A while back I wrote an article about an open source alternative to Exchange called Zimbra. Zimbra was acquired by Yahoo recently and it appears that Yahoo is continuing to develop this product. Yahoo released the Yahoo Zimbra Desktop today as a free download. (Be aware, it's rather large.)

    This email/productivity software works in the off-line mode and also has available options for word processing, spreadsheets, task management, and more. The desktop runs as a stand-alone application and uses JAVA to store data locally. Google has been working on something similar, built on the open source “Gears” project, but has yet to release anything.

    The Zimbra Desktop does not run in a browser, it's more like Outlook. A nice feature is that it functions so much like Outlook that even the keyboard shortcuts you're used to using with Outlook will work within the Zimbra application. A few “gotchas” remain though, most notably that it doesn't sync with your contacts/calendar (you have to do a manual export/import) and the IMAP folder sync seems to be a bit funky.

    All in all, it's not a bad first attempt. Take a look at it if you're contemplating an alternative to Outlook. Just keep your fingers crossed that a Microsoft Yahoo buyout doesn't happen; the Zimbra suite is a major competitor to Exchange and we know what would happen to Zimbra if a deal goes through.

 

Squishing Bugs

    It's Saturday morning and I just finished doing my weekly chores around the house. While I wait to swap the wash, I'm updating SSH on my Debian servers. It seems the random number generator within the application was broken, so that when the RSA keys are generated they may not be so “unique”. The fix was very simple; one command in a terminal and the application is updated, new keys generated, and the SSH daemon restarted. For those not comfortable in the shell, most GUI package managers either automatically updated the system or notified the user that an update was available. A simple click and you're safe once again.

    Why do I feel compelled to share this with you? Well, this recent vulnerability with SSH reinforces the fact that even those of us that choose not to use Windows must remain vigilant and keep our systems updated. More importantly, it points out a major difference between FOSS (free and open source software) and proprietary software; there is a marked difference in the way vulnerabilities are handled.

    Open source software is frequently criticized by its pundits as insecure and dangerous due to the very fact that the source code is freely available. The argument is that “since the source code is available, it's very easy for the bad guys to find the flaws”. The counter-argument by the FOSS folks is that “since the source code is available, it's very easy for the community to review and find flaws”. Basically, the code is reviewed by a large number of people on a regular basis which should result in an inherently safer product. Case in point: the vulnerability with the random number generator within SSH was discovered and announced on May 13. Within hours, the open source community had resolved the issue and had an updated version of the software available.

    Lets look at the other side now. Proprietary software does not make the source code available. It is up to the manufacturer of the software to review it for vulnerabilities and patch as necessary. We are left at the mercy of said manufacturers and must assume that the software has been tested and is safe to use. What happens when a user finds a security issue? While there is much debate on how this should be properly handled, the standard procedure is for the discoverer of the bug to notify the manufacturer. At this point the manufacturer will determine if there really is an issue, what (if anything) they are going to do about it, whether they should go public with the disclosure, etc. There is always the possibility that the manufacturer will never let the public know about the vulnerability, not issue a patch, and simply hope no one else discovers the flaw. A more common scenario is that the manufacturer releases an announcement of the flaw in conjunction with a patch, months (sometimes years) after they were initially notified or simply waits until the release of the next version to fix the flaw. This puts users of the software at risk for the whole period between the initial notification by the discovering party and the release of a patch.

    So, which do you prefer, FOSS or proprietary? I'll stick with the stuff that has nothing to hide, thanks.