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
Secure Central Logging and Intrusion Detection Systems
in a Windows 2000/XP Environment.
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.
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.
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.
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:
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 http://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:
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:
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.
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%.]
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 (the default is syslogd)
net start (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.
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”.
The rest here