So now that you’ve deployed some brand spankin’ new Windows 2008 R2 servers you probably want to start gathering some information on their condition and monitor their security. Syslog is a very good way to gather the logs from a large number of servers and direct them to a central site for analysis. In this post we’ll make use of the Snare EventLog Agent to collect events from the Windows Event Log service and forward them to a centralized syslog server. Since the events that are logged to the Event Log do not generally conform to the syslog standard some manipulation of the messages may be necessary on your syslog server.
In this example I will be installing the Snare EventLog Agent on an Active Directory domain controller so that I can monitor logon/logoff failure events that occur with my domain user accounts. My central syslog server will be running on a CentOS Linux host using the syslog daemon rsyslog. There are also many syslog servers available for Windows if you choose to go that route. Kiwi is one with a nice interface but the full featured version is payware. Your choice of a syslog server to collect your messages should be immaterial to this discussion as the configuration steps should be the same with the Snare Agent.
First let’s start by installing the Snare Agent software. You’ll want to download the version for Windows Vista and above here. Logon as administrator on your 2008 R2 server and run the install file.
Proceed with the installation and accept the defaults until you get to the “Snare Auditing” screen.
The Snare Auditing screen allows you to give Snare the access necessary to edit the auditing settings on your server to conform to the objectives that you configure with the agent. I’m generally paranoid about anything too automatic (especially on a domain controller) so I’ll select No. This means that I’ll need to manually specify the auditing settings needed so that events are created in the Event Log. Click Next.
If you want to configure higher security you can select one of the “Yes – with password” options for the Snare web configuration interface. By default the user/password combo is snare/snare. I’ll keep the default, no password is okay for me because the only access to the web interface is permitted on the local machine. Click Next.
Run through the rest of the install keeping the default settings.
Go to Start > All Programs > InterSect Alliance > Snare for Windows. Enter your password if you chose that option.
On the left click Network Configuration.
For the Destination Snare Server enter the hostname or IP address of your syslog server. For Destination Port enter 514 which is the port the syslog server will listen for messages. Choose a SYSLOG Facility and Priority from the drop down lists, remember that your syslog server will need to be configured appropriately for the messages to be received. I will choose the SYSLOG Priority Dynamic, which as I understand it should attempt to translate the event severity in the Event Log to a comparable syslog severity/priority. I’ve noticed some flakeyness with this setting so you may need to specify a single static Priority.
Optionally you can enter a name to override the DNS Name, I chose to override because the DNS Name includes the fully qualified domain name and I’d like to use the shorter hostname. Finally I will check Enable SYSLOG Header, this will fix a few (but not all) of the message formatting issues I mentioned earlier.
Click Change Configuration. Then on the left click Apply the Latest Audit Configuration. Get used to doing this second step, since changes that you make to in the web interface will not be effected until you select this option.
One thing to note is that I experienced problems with the Snare Agent whenever I clicked the Domain Users or Domain Group Members links on the left side. The Snare process would suddenly terminate and I had to restart it manually. This may be simply an effect that I installed Snare on a domain controller, since clicking on the Local entries actually returns results for Domain user/group accounts. Anyway, as long as you avoid clicking these links, the Snare Agent appears to function normally.
On the left click Objectives Configuration.
By default Snare is configured with several rules (objectives) by which it will identify events in the Event Log and forward them as messages to the syslog server. I find that a great volume of log messages are forwarded and I prefer to keep things a little bit simpler and less “noisy”. So I will delete the rules that Snare has by default and will setup my own. Unfortunately I have not found a way to simply disable the objectives, I have found that deleting them is the best way to disable them. You may prefer to make a note of what rules are set up in the event you would later like to include the additional syslog messages.
To delete each objective, click Delete under the Action Required heading in the left column of the yellow table.
Now click Objectives Configuration on the left side and repeat for each objective until they are all deleted.
In the center of the screen click the Add button.
I will keep most of the defaults and leave Logon or Logoff as the event to identify. I’ll change the event type to be captured to Failure Audit to track things such as logon failures with domain accounts to computers and shared folders. If you keep the Success Audit expect the syslog message volume to be larger. Of course the configuration I’m using is pretty basic, but it’s just a starting point. For Select Alert Level I’ll choose Information, this is the event level given to audit events and they won’t be forwarded if you select a higher level. Click the Change Configuration button at the bottom, then click Apply the Latest Audit Configuration on the left.
Configure Group Policy for Audit Failure Events
Since I’m configuring Snare on a domain controller in Active Directory I need to edit a Group Policy to enable logging of audit failures. I’ll edit the Default Domain Controllers Policy GPO since it’s settings take precedence for domain controllers. If you are configuring Snare on a non-domain server or a member server you would edit this setting in the local security policy, the Default Domain Policy GPO, or create a new GPO.
Go to Start > Administrative Tools > Group Policy Management.
In the left pane AD tree open up Forest > Domains > your domain > Group Policy Objects, right click the Default Domain Controllers Policy and click edit.
In the group policy editor on the left open Default Domain Controllers > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies and highlight Audit Policy. Then double click the “Audit account logon events” policy in the right pane.
Add a check mark to Failure, then click OK.
Now refresh the group policy for the domain controllers. Open a command prompt and type:
c:\> gpupdate /force
Close the command prompt once the policies have refreshed.
Now go over to a computer that is a member of the domain and attempt to logon with a domain user account but make sure it is not successful by typing the wrong password.
Back on the domain controller open up the event viewer and open Windows Logs > Security. Assuming this is not a busy server (hopefully this is a test box!) you should see an Audit Failure a few lines down.
Check the event details and scroll down to verify the user and computer that failed pre-authentication matches your details.
Now let’s switch over to our syslog server and verify that the audit failure message was forwarded correctly.
As you’ll notice the message is quite verbose, unfortunately (or fortunately depending on your viewpoint!) beginning with Windows Vista the messages have gotten very detailed. One feature of the rsyslog syslog daemon is that message parsers can be configured to modify these messages and present us with less information.
On my rsyslog server I am running a web console called phpLogCon (now renamed LogAnalyzer) that provides a nice interface through which I can search and view messages on the syslog server. As you can see the newest message received is the audit failure from my invalid logon attempt. I’m not exactly sure why the severity comes up as emergency, this may be a side effect from configuring Snare with the “Dynamic” severity setting.
Well, there you go. Catching those bad guys before they break into your computer systems, ain’t it great! In a future posting I’ll provide details on setting up a syslog server running rsyslog and I’ll walk through configuring the new version of the LogAnalyzer console.
No comments:
Post a Comment