Network Security Hacks [Electronic resources] نسخه متنی

Hack 56 Integrate Windows into Your Syslog Infrastructure

Keep track of all of your Windows hosts the
Unix way.

It''s hard enough to keep tabs
on all the Event Logs for all your Windows hosts,
but it''s even more difficult if your propensities
predispose you to Unix. After all,
Unix systems keep their logs in plain text files that are easily
searchable with common shell commands.
This is a world apart from the binary logs that Windows
keeps in its Event Log.
Wouldn''t it be nice if you could have
your Windows machines work more like the Unix machines that
you''re used to? Someone has already thought of it
and has written a free Windows service that lets us do just that.

Ntsyslog
(http://ntsyslog.sourceforge.net/) is a freely
available service written for Windows that allows you to log to a
remote syslogd.
To set it up, just download and extract the ZIP file, and
then copy the NTSyslogCtrl.exe and
ntsyslog.exe files into your
%SystemRoot%\system32 directory.

To install the service, open up a command prompt and run this:

C:\> ntsyslog -install

To verify that it was installed, open up the Administrative Tools
Control Panel applet and double-click the Services icon. Then scroll around and look for the NTsyslog
service. You should see something
similar to Figure 4-1.

By default, NTsyslog installs itself to run under the Local System
account, which has complete access to the resources of the local
host. This is obviously not the
optimal configuration, since the NTsyslog service needs access to the
Event Log and nothing else. You can
change this by double-clicking the NTsyslog line in the Services
Control Panel applet as shown in Figure 4-1. This will
bring up the Properties dialog for the service.
However, before you do this, you might want to create an
account specifically for the NTsyslog service that has only the
necessary privileges for NTsyslog to run properly. To do this, go back to the Administrative
Tools window and double-click the Computer Management icon. After clicking the Local Users and Groups
icon, you should see something similar to Figure 4-2.

Right-click the Users folder and click New User. You should now see a dialog where you can
enter the information for the new user.
Enter information similar to that shown in Figure 4-3, and make sure you pick a strong password.

Now we need to give our new user the rights it needs to do its
job. Locate the Local Security
Policy icon in the Administrative Tools window and double-click
it. Click the Local Policies folder
in the left pane of the Local Security Settings window, and then
double-click the User Rights Assignment folder in the right pane of
the window. You should now see
something similar to Figure 4-4.

The access right that we are looking for is "Manage
auditing and security log". Locate this in the
Policy list and double-click it. You
should then see a dialog like Figure 4-5.

Click the Add button, select the name of the user from the list, and
then click OK.

We have the account and we''ve given it the proper
access rights, so let''s go back to the Services
window and double-click the NTsyslog service to bring up its
Properties dialog. Click the Log On
tab and you should see something like Figure 4-6.

Click the "This account" radio
button to enable the Browse... button.
Now click the Browse... button and locate and select the
account that you created. Then click
the OK button. You should now see
the account name in the text box to the right of the
"This account" radio
button. Enter the password you set
for the account and confirm it.
After clicking the Apply button, a dialog will appear
confirming that the Log On As A Service right has been granted to the
account. Click the OK button, then
click the General tab in the Properties dialog.
To start the service as the new user that you created,
click the Start button. If you get
an error dialog, you will need to change the ACL for the
ntsyslog.exe file and add Read and Execute
permissions for the new account.

Now we''ll use the included
configuration program to
configure the settings particular to NTsyslog. You can use this to
set up a primary and secondary syslogd to send
messages to, as well as the types of Event Log events to send and
their mappings to syslog facilities and severities. You can also
start and stop the NTsyslog service from this screen. To use the configuration program, run
NTSyslogCtrl.exe.
You should see a window like Figure 4-7.

To start the service, click the Start Service button; to stop the
service, click the Stop Service button.
Clicking the Syslog Daemons button brings up the dialog
shown in Figure 4-8.

Again, this is pretty straightforward.
Just put in the host you want to log to, and if you have a
secondary syslog host, put that in the appropriate field.

The most difficult part of the configuration is setting up the
mappings of the Event Log entry types to the syslog facilities and
severity levels, but even this is fairly easy.
In the drop-down list (as seen in Figure 4-7) you can select between the Application,
Security, and System Event Logs. To
configure one, simply select it in the drop-down list and click the
EventLog button. If you select the
Security log and click the EventLog button, you should see something
similar to Figure 4-9.

To enable the forwarding of a particular type of event, click the
checkbox next to it. Using the
drop-down listboxes, you can also configure the facility and severity
mappings for each type. Since this
is the security log, you should probably pick one of the
security/auth syslog facilities. For
the severity, choose something that sounds similar to the Event Log
type. For example, I selected
(4)security/auth1 and
(6)information for the Information type for the
Security Event Log. You could,
however, pick a facility and severity that''s not
used on any of your Unix servers, and have your
syslogd log all Windows events to a common file
separate from your Unix logs. Of
course, if you''re using
syslog-ng [Hack #59],
you can use any facility you like and filter out your Windows hosts
by IP address.

Once you have it working, try logging in and out a few times using an
incorrect password so that you can see that everything is
working.

If it is, you should see login failure messages similar to this:

Oct 29 17:19:04 plunder security[failure] 529 NT AUTHORITY\\SYSTEM  Logon Failure:  
Reason:Unknown user name or bad password  User Name:
andrew  Domain:PLUNDER  Logon Type:2  
Logon Process:User32    Authentication Package:Negotiate  Workstation Name:PLUNDER

One of the best things about doing this is that now you can use the
wealth and flexibility of Unix log-monitoring tools to help monitor
all your Windows systems.