Windows 2008 servers have been around for about 10 months now and chances are they have made their way into your IT department. Many among you would be aware of the changes that have been introduced in Vista and Win2k8 servers. There has been a number of changes in the logging infrastructure, the most interesting of the lot is the renumbering of security event ids.
The event ids of Vista and 2008 servers compared to its predecessors generally follow a 'offset by 4096' rule, i.e the good old logon event represented by id 528 is now 4624(4096+528) and so on. However, this offset rule is not a universal change and there are a few gotchas that surface here and there. For example, logon failures in pre-vista systems were represented by a multitude of event ids ranging from 529 to 537(each indicating a specific reason for the failure), this has now been unified to a single event, namely 4625 and a new field 'Failure Reason' has been added to the message under the category 'Failure Information' highlighting the reason. Another example of this is the 'Audit Log Cleared' event. This event is logged with the id 517 in pre-vista machines but is now changed to 1102 with the source being 'EventLog'(this is another change that skipped mention, the 'Source' of the Security log which till now is 'Security' has been refined to a more meaningful field, the security audit events take the source 'Microsoft Windows Security Auditing', while as mentioned audit logs cleared is logged with source 'Eventlog'.)
The following KB article is a handy reference describing the various security and audit based events in Vista and 2008 servers.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;947226
Scrolling down to the "Notes" section at the bottom of the article, you will find information about a useful command line utility 'wevtutil', which when used in the form mentioned in the article(wevtutil gp Microsoft-Windows-Security-Auditing /ge /gm:true) fetches a detailed description of every security based event id.
That just about wraps up this post, oh. . and just one more thing. We have set out a small initiative to get you, the real users of the product, tell us what you want from the product over here. The idea behind this is to listen to what improvements you want and if enough users agree, we will work on it on a priority basis. The whole thing is very much in a nebulous state with no entries yet, we encourage you to use this facility to tell us what you would like.
Until next time, ciao.
Introductions first, my name is Karthik, I am part of Eventlog Analyzer development team. I call myself as ‘The Experimenter’(ok, that is not so cool as the Terminator and its likes, but that’s me), I meddle with the application all day and try to make things better(hopefully ;)).
As you may be aware, ELA 5 has been released and is available for download here. Its taken quite a long time to hatch, but I am sure its worth it. Grab a copy, try it out and email us what what you think about it at our support id. We are all ears.
The two important features in ELA 5(click here for complete feature list) that kept you folks waiting for such a long time were a. SQL Server database support and b. Support for Application Log analysis. In this post I will be talking about the application log support offered by ELA. We often receive requests from users demanding provision for analyzing different logs(other than syslogs and eventlogs) available out there(webserver logs, database logs to name a few), and given that each of these applications follow different logging formats, we had one heck of a challenge ahead us in designing a framework that would fit them all (I wont say that ELA fits in everything, but what we have now is a big step towards it). Besides handling the different log formats, ELA has also been improved to help you find the proverbial needle-in-the-haystack, by introducing better indexing and searching capabilities.
The question one might at this point is “Enuf said. What does it take to analyze the logs I have?” The answer: a couple of configuration files that tell ELA what your logs look like, what you want to index and what you want to see in the application. “So can anybody go out there and write these files?” may be your next question. Well, that’s a tricky one and I would have to say ‘No, not right now, you will need our help’, but I can assure you that we are working on making it as simple as possible.
The current release supports analysis of IIS web server logs, IIS ftp logs and SQL Server error logs. I am sure you will find the default reports offered quite useful, for example, in the case of IIS web server logs there are reports available which detail cross site scripting attacks and sql injection attempts.(While we are on the subject of analyzing web server logs, here is a must read for those of you trying to detect attacks on web applications from log files. And if you feel the list of reports inadequate or if your logs are not supported yet, please let us know. Like i said earlier its just a matter of configuring a couple of files and voila!, your logs are there to be dug through.
So what are we up to next? For starters, we are planning on a short vacation break. We are also pondering on the list of features to take up next. If there is anything on your ELA wishlist that’s missing in the new release, please write to us, we will accommodate them if possible.
Till then, Ciao.
Corp