SECURE
LOGGING IN A WINDOWS 2K ENVIRONMENT CONT...
Tiger Shark
from Antionline has kindly given his permission for his tutorial to be
hosted at The Taz.
You can find the original post here:
http://www.antionline.com/showthread.php?s=&threadid=246159
Enjoy
The Log Server: Install Kiwi Syslog Daemon and tell it to both
"display" and "log to file" in the options dialogue after install. Tell
it where you want the logs sent, (that nice big log drive you installed
is a handy place). I use a batch file as follows to turn on and off the
real time logging for diagnostics purposes):-
Net stop <service name> (the default is syslogd)
%path%\syslogd
net start <service name> (again, the default is syslogd)
NOTE: This is necessary because syslog cannot be run twice and will
error out if the service is already running, thus stopping the service
and running the program allows you to see the syslog window with the
log entries scrolling while you test the syslogging from remote
machines. When you close the syslog window the service will restart but
because you told it to display and log to file you should find the log
file is complete, (or darned nearly).
The syslog daemon has the ability to send itself a test message and
this is a good time to do so. If you run the system in it’s ‘real-time"
mode by using the batch file above you will immediately see the message
appear on the screen, then go to the log file itself and make sure that
the message appeared there. If it did then the syslog server is all set
to go.
Install PureSecure on the Log Server. This time it is not the main
sensor, you do not need MySQL and you do not need to run snort. Tell it
to report to the Primary Sensor’s MySQL server. At this point and each
time you do something new to this server ZoneAlarm is going to "whine",
allow the service to act as a server or to trust incoming from the
appropriate machine. Go back to the Primary Server and under the
Configure Integrity Checking section you should see the new server. In
the configure dialogue enter the following lines:-
RED;%system path$\system32;0;Log Server System Files
RED;%path%\autoexec.bat;0; Log Server Autoexec.bat
RED;%path%\config.sys;0; Log Server Config.sys
NOTE: At this point the Primary sensor should be reporting alerts from
the external interface and two systems integrity checking. The
integrity checking will take 30 minutes to "kick in" on each system and
the alerts may need to be "prodded" by sending a noisy scan at the
firewall from outside. If you are not getting this information now is
the time to begin troubleshooting – which is a bit too big of a subject
to go into here.
If you have these three facets reporting correctly to the MySQL server
and thus the PureSecure console then we are good to start adding the
"fancy" parts of the overall system.
Complete the "Real-Time" Integrity Checking:
The Public and the Private Servers: The exact configuration of the
publicly available servers will depend somewhat in your system itself
but the basic folders to watch are the same as we used for the Log
Server. If you are hosting publicly available HTTP or HTTPS then the
wwwroot needs to be monitored too. Be careful to pick on folders where
little or no changes should take place to avoid "falses". Install
PureSecure on all the Public Servers in the same fashion you did for
the Log Server, (not primary sensor, no MySQL or Snort and have it
report to the Primary Sensor’s MySQL database). After each install
check the Integrity Verification in PureSecure to ensure the new server
"turned up", (they usually do, if they don’t go ahead and stop and
restart the Demarc Service on the server you installed on. That usually
fixes it). Assuming it’s there go ahead and add the lines in the
integrity verification to monitor the machine remembering that it takes
30 minutes before the first scan is done.
NOTE: Integrity Checking makes an MD5 signature for every file in the
selected folders which it then regenerates and compares against it’s
database every 30 minutes. This can be several thousand files and can
place a burden on the drive(s). In my experience this can have an
effect on slower servers though, for my part, I prefer the "warm,
fuzzy" feeling I get knowing they are being watched for me over the
relatively small negative impact experienced by the server. In terms of
network performance at this time I have noticed no negative impact
since the Integrity check itself takes place within the server and only
the results appear to be passed across the network.
System monitoring:
Since PureSecure can monitor services we might as well go ahead and use
it. It’s really nice to know that a system is down within 5 minutes of
the failure which is usually before the users start calling. There is a
side benefit to the services monitoring that some may overlook and
decide not to install it. The benefit is that if a cracker realized
that the primary sensor exists and tries to DoS the machine then
running the services monitoring using the Primary Sensor as the monitor
means that the monitoring will most probably be disrupted and you will
be warned within 5 minutes. A check of your "failed" system will show
it to be up and you should start to wonder why and packet sniff the
Primary Sensor….. begin to panic when you see the results.
First you need to list all your assets that are critical to the
network’s function, (routers, firewalls, services run by servers etc).
Then you need to categorize them into groups, (Public Servers, Private
Servers, Routers, Firewalls etc). Under the configuration tab of
PureSecure create the groups and then the individual assets adding them
to the appropriate group as you go. Now you can begin creating the
events. The events configuration tab asks you for the asset, the
service, the port , and the sensor to monitor from with many of the
services being selectable from a drop-down list. So, for example, you
would select your mail server, SMTP and the monitoring sensor as the
Primary Sensor and click go. From this point on, every 5 minutes the
Primary Sensor will go through a complete 3-way handshake and send a
"HELO localhost" to the mail server on port 25. When it receives a "250
OK" from the mail server it is happy. If it doesn’t it pops a red light
at the top of the console along with the server name and the date/time
it failed. % minutes later it will check again. If the service is back
up then it will erase the red light but if you select the Monitoring
tab you can access the history of each server/service which can
sometimes assist you in troubleshooting when a user says they couldn’t
get to the internet last night you may be able to see that the border
router was unavailable for 10 minutes at the same time, (this should
also ring and alarm in your head since routers are not supposed to go
"out for lunch".
Monitoring the Internal Network in Real Time:
The final task in the setting up of the real time monitor is to have
the SA PC sniff the internal network to see what is going on there.
NOTE: This is a single sensor designed to watch traffic going out to
the public network and to see traffic coming in through the firewall
from the public network. It is not a complete solution on a switched
network or a WAN where it can’t see all the traffic. Be fully aware
that a cracker can work away quite happily one switch away hopping from
machine to machine across and SSL connection initiated from the private
network and you won’t know a thing. You have to place additional snort
sensors at various points on your internal network in order to be
warned of such activity. You may chose to have them report to this
"main" system and you may not. It’s a personal choice really since if
it is set up to be properly effective it will probably generate
numerous "falses". I prefer a clear view of the border traffic and the
critical points on my network to give me warning that odd activity is
occurring without the blur that would be created by these additional
systems.
Set up PureSecure on the SA PC. In doing so tell it that it isn’t the
primary sensor, it doesn’t need MySQL but you do want it to run snort
and report to the Primary Sensor’s MySQL. (if WinPcap needs installing
you will be warned. Install it and restart the SA PC before continuing
with the installation). Upon completion check the Primary Sensor under
Configuration - NIDS to ensure it has appeared. For information on the
snort.conf file which you will need to change please see Snort Stuff
later in this document.
At this point you should have the complete "real-time" monitor
configured and operating correctly. The PureSecure console should be
showing you monitored services, integrity verification results and
alerts from the internal and external sensors. I would suggest that you
go through the rules enabled by Snort and comment out, (use the "#" to
comment the lines), all the alerts that do not apply to your operation.
Where alerts refer to services that are allowed to pass through the
firewall I leave them on both sensors and where they would not pass
through I leave them on the external and remove them from the internal
and visca-versa. By doing this you enhance the operation of the sensor
since it doesn’t have to check so much in each packet thus speeding it
up and helping to avoid packet dropping. Since the sensors are on
separate machines a failure of either will still result in the logs
being written, unless of course, the Primary Sensor fails altogether
which is the reason why we send the syslog alerts to a separate
machine. In almost any event you will have complete logs on either the
Log Server or the Primary Sensor.
Capturing the System Event logs
This is a fairly quick and easy part of the system to set up if you
have the syslog server running on the Log Server. You may chose which
assets you wish to centralize the log files of but in my opinion there
are a certain minimum that, without which, you are creating a
potentially self defeating system. Clearly you need to know if your Log
Server, SA PC and your Primary Sensor are attacked. Fairly obviously it
is imperative to see that the Public Machines are well monitored too.
That really covers the direct attacks. What some people may not grasp
is that in order to properly escalate privileges within a network at
some time the AD servers will have to be approached so it is of great
value. Lastly, if your organization has "problem users" be they
"snoopers" or users that just have to seek out those web sites that you
would not wish them to be visiting, (read "malicious code"), it is also
useful to monitor their event logs too. You just can’t be too careful.
With that in mind the systems you chose to monitor are unique to each
organization. On the bright side Snare carries little if any
performance hit on any but the most underpowered workstation so your
servers will not notice it and your users will certainly not unless
they investigate running services.
Simply install Snare on each system to be monitored, enter the
configuration program, point it at the Log Server and tweak the audit
policy of the machine and Snare to capture the information you wish to
see, (Microsoft has minimum recommendations that, in my experience,
show the important information without flooding the logs with worthless
system "chatter"
NOTE: One thing with Snare, BackIIS etc. which can help to make reading
your log files easier is that you can designate what kind of syslog
message category the message is sent, and therefore reported in the
log, they send it’s messages under. I like to send the messages with a
consistent category depending upon which system is sending the message.
For example I send all event log messages under the category
Kernel.Info, all IIS messages go under Daemon.Info etc. Not only does
this consistency make reading voluminous logs easier but also it gives
some nice consistency for when we begin using LineStrip and scripts to
extract data from them.
To test the Snare installation on each machine by logging off and back
on. This should generate logon/logoff event which you should be
auditing. Go to the log file itself to make sure this is generating the
entries you need since, as you get further into this process on a busy
network the entries will fly past too quickly in real time for you to
be sure you are getting what you need.
Original Tutorial
Submitted by nokia for TheTAZZone-TAZForum
Originally posted on March 4th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.