SECURE
LOGGING IN A WINDOWS 2K ENVIRONMENT
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
Secure Central Logging and Intrusion Detection Systems
in a Windows 2000/XP Environment.
Purpose:
This document details the requirements and implementation of a central
logging system and intrusion detection system using freeware/no cost
software for non-profit organizations and thus should be attractive to
more cost conscious organizations also. It concerns itself primarily
with the security and logging of data passing through the perimeter and
the detection of internal activity that might indicate suspicious
activity emanating from the local network.
Assumptions:
This document assumes that the organization is self-hosting relatively
progressive services, (within the realm of non-profit organizations),
available from the public internet. These may include, but not be
limited to, internet mail, web sites, VPN, Terminal Services, Web Based
Email and Domain Name Service, (DNS). It further assumes knowledge of
the ports/services commonly used over the internet, TCP/IP, general
hacking/cracking techniques and the steps taken in attempting to
hack/crack a system, hardening servers and best practices in network
security. It further assumes that the administrator maintains a daily
check for new patches, monitors such resources as BugTraq, AntiOnline
etc. for information regarding new exploits/flaws and mitigates the
risk in whatever way is best suited to his/her organization.
Concepts:
1. In so far as Microsoft Windows 2000/XP does not utilize a native
central logging system such as *nix’s Syslog without the purchase of
expensive third party solutions the task of analyzing logs in even
relatively small organizations is unwieldy and prone to error.
2. In order to make the task of managing and analyzing the many systems
that produce logs that would be of value in the event of attempted or
actual system compromise it is necessary to try to centralize all the
logs into one single file.
3. Knowing that the first task of a malicious person after a successful
compromise is to try to hide their presence it is imperative that the
logs be secure, distributed and properly analyzed on a schedule that
appropriately reflects the risk and the traffic of the monitored
network(s).
4. Security is best served by defense in depth and security logging
should follow the same principle, therefore logging only to syslog
would be a mistake. The installation of PureSecure also allows the use
of a log sent to a MySQL or MSSQL server so utilize that ability as you
see fit.
5. A side benefit of logging to a MySQL/MSSQL server using PureSecure
is that the syslog files will scroll too quickly in a busy shop for one
to watch the output live in Kiwi Syslog Daemon. This secondary logging
through PureSecure adds the extra level of "depth" and allows proper
"real time" viewing of IDS alerts on an intuitive interface.
6. The file format for logging should enable the maximum amount of data
to be kept within the minimum amount of disk space to enable cost
effective archiving and analysis.
7. The minimum logs that should be centralized are firewall logs,
Intrusion Detection System, (IDS) logs, Internet Information Server,
(IIS), logs and critical server/client event logs. With logs of this
nature secured and distributed the information required to track down
the events of interest and mitigate any future or current damage should
be available.
Conventions:
1. Square brackets, ([ ]), indicate the systems I currently use to
operate these systems.
2. NOTE: indicates an area where there may be an issue or that the
information given is specific and does not seem, (easily), to be able
to be got around. For example: BackIIS allows you to specify the
directory to monitor for log events and even writes that information to
the registry but it ignores that and insists on looking to %system
root%\system32\logfiles\exxxxxx.log for it’s logs. No response was
received from the writers of the program so one cannot capture an
Exchange server’s mail logs which appear not to be able to be changed
from a separate subfolder in that folder.
Specific Hardware Requirements:
1. A dedicated PC, (known from here on as the Log Server), preferably
Windows 2000 Server, with a system drive and a large log drive to be
the dedicated log server. The CPU/RAM combination need be little more
than required to run Windows 2000 in an efficient and fast manner,
(this is somewhat a matter of taste and somewhat a matter of the amount
of traffic to be logged). [The log server is AMD 900/256M/20G system
drive/40G log drive/48xCD Writer/Win2k Server Sp3. This machine is a
standalone server, (not a domain member).] This machine is hardened and
further protected by an installation of ZoneAlarm Personal Firewall
with trusts established to the Primary Sensor and the other installed
sensors that will be delineated below. All accounts except the
administrators account should be disabled and the administrator should
be renamed as part of the hardening, (The same should apply to the Log
Server).
2. A dedicated PC, (known from here on as the Primary Sensor), that is
a hardened Windows 2000 Pro. Dual NICs are required since one will
monitor traffic outside the firewall and the other inside. You will
need to place a small hub between your Border router and your firewall
but this can be a 10Mbps hub since your traffic will be limited to your
internet connection speed which should not exceed the hub’s capability.
There should also be a hub inside the firewall that all traffic runs
through, (both inbound and outbound), so that the internal sensors may
be connected here. The internal hub needs to be sufficiently "sized" to
ensure that the sensors NICs can see all the traffic passing that
segment so it may be inadvisable to place a 10 "speed" here when the
remainder of the network runs at 100Mbps. [The primary Sensor is a
PII-233/128/6G/Win 2k Pro SP3. This machine is a standalone
workstation].
3. A non-dedicated server with sufficient drive space to archive the
log files within the domain structure, (known from here on as the
Archive Server). Access to the archived logs is restricted to domain
administrators only.
4. A non dedicated workstation that acts as both an additional sensor
and as the log analysis machine, (from here on known as the Security
Administrator’s PC or SA PC for short). This machine is a domain
member, with access to it’s drives restricted to the security
administrator’s login and password combination.
5. Publicly available servers from here on these servers will be known
as the Public Servers.
6. Non-public servers which are AD servers at primary locations. The
machines will be known as the Private Servers.
7. A hardware firewall capable of transmitting it’s log data into the
internal network in a format that could be captured in text. Ideally
this firewall will natively be able to log to a syslog system.
Specific Software Requirements:
1. Kiwi’s Syslog Daemon is a Win32 syslog service that runs on Windows
NT/2000/NT machines and is available at:
http://www.kiwisyslog.com/software_downloads.htm#syslog
2. PureSecure is an IDS system that runs the Win32 port of Snort,
(www.snort.org), and also includes a file integrity verification system
and a service monitor all in a single package with a usable interface.
The main console can manage numerous sensors and the installation is
quick and easy. PureSecure is available for non commercial use at
www.demarc.com. There is a "professional" version which at the time of
download was $1500 for the main sensor and $99 for each additional
sensor making this a relatively cost effective solution for commercial
enterprises, especially when incorporated in the central logging system
I am discussing.
3. BackLogIIS is a Win32 system that captures IIS logs that are logged
to %system root%\system32\logfiles and forwards them to a syslog
server. It can be located here:
http://www.intersectalliance.com/pr...gIIS/index.html
4. Snare is a Win32 Event log system that captures any event log entry
and forwards it to a syslog server. It is available from:
http://www.intersectalliance.com/pr...dows/index.html
5. LineStrip is a text file line stripper that can manipulate text
files by numerous parameters and dump the output to a new file. It has
a full function command line interface that lends itself well to script
execution. LineStrip can be found at http://www.lexacorp.com.pg/.
6. TXTCollector is a Win32 system that allows you to join all the text
files together in a given directory. This is handy for rejoining the
daily syslog files to get a broader look at an IP’s activity over time
without the tedium of doing it one file at a time. TXTCollector is
available here: http://bluefive.pair.com/free95.htm.
Initial Configuration:
The Primary Sensor: Begin the configuration of the Primary sensor with
the installation of PureSecure. If you do not have WinPcap installed it
will prompt you to install it. Do so, restart the machine and rerun the
installation for PureSecure. Tell the installation program that you
want this to be the primary sensor, (name it what you like). Tell it to
install MySQL and fill out the usernames and passwords as you see fit.
Tell it to install snort firstly on the external sensor. NOTE: The NIC
connected to the external sensor must have all protocols unbound. Go to
Network Neighborhood – Properties – External Connection – Properties
and uncheck all the entries in that dialogue box including TCP/IP,
(WinPcap will place the NIC in promiscuous mode without the need for
any protocols being bound to it. By doing this you place the NIC in
"stealth" mode making it impossible to detect without the cracker
gaining a foothold in it’s collision domain – i.e. On the border router
or the firewall, which, if they can do, means you are already in pretty
deep trouble. When you are asked if you want to allow anonymous access
reply with "NO", (this will mean you can access the console from
anywhere within the LAN but will be required to authenticate with the
administrators login/password combination). You will now need to
configure the IIS server, (steps 36-43), as found in the PureSecure
Installation Documentation found at
http://www.demarc.com/support/docum...n32install.txt. Then open IE,
navigate to http://localhost/demarc/puresecure.exe. Add it to your
favorites, select it in your favorites, right click and send it to the
desktop for quick access.
For information on the snort.conf file which you will need to modify
please see the "Snort Stuff" section at the end of this document.
Under the Configure Integrity checking select this sensor and in the
dialogue enter the following lines where the %system path% and "%path%
are where you have actually installed the files to be checked:-
RED;%system path%\system32;0;Main Sensor System Files
RED;%path%\autoexec.bat;0;Main Sensor Autoexec.bat
RED;%path%\config.sys;0;Main Sensor Config.sys
RED;%path%\wwwroot;1;Main Sensor wwwroot
NOTE: There is a 1 in the wwwroot entry. The options are 1 and 0 with
zero meaning do not check subdirectories and one meaning do check them.
In the case of the system32 folder checking the subfolders will result
in alarms every few seconds but in the case of the wwwroot it will not
since the site is static. It is imperative however that you keep a
watch on the subfolders of the web root.
[This sensor typically consumes 2-8% of CPU with an average in the
region of 4%. I don’t recall ever seeing it exceed 10%.]
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.