The sixth session from a two day training course for potential first responders I ran for a large financial services client.

1. Phil Huggins
February 2004

2.  Four major forms:
 Network Signature-based
 Network Anomaly-based
 Host-based
 Protocol Anomaly-based
 Commonly deployed, rarely used well.

3.  Requires tuning to identify which alerts
(signatures) should be generated and how
high to escalate
 Examples:
 Snort
 RealSecure
 Network Flight Recorder (NFR)

4.  A signature-based NIDS examines all network traffic and
compares it to signatures of known attacks
 This model is similar to that of anti-virus Software
 Useful for detecting attempts by scripted attackers
 Less useful for detecting skilled attacks or insider-based
incidents
 Research has shown several ways to avoid detection:
 ADMutate: polymorphic shell-code by K2
 FragRoute: fragments network traffic by Dug Song

5.  Anomaly-based NIDS monitor network traffic in an attempt
to detect normal traffic pattern deviations
 Useful for detecting complex, yet undiscovered attack
methods
 Requires a significant configuration and tuning effort
 Requires time for initial benchmarking
 Difficult to define “NormalTraffic” activities
 Numerous employees check email after a meeting which can look like
a DoS attack to an anomaly-based IDS.

6.  Examples:
 Cisco
 Dragon

7.  Host-based IDS monitors system state for unknown
activities
 Used as a “last line” defence mechanism
 Can assist in post-attack forensics efforts
 Integrity of reported data is not guaranteed after a
successful compromise
 Examples:
 Tripwire
 Dragon Squire

8.  Detection of intruders based onTCP/IP protocol deviations
 Easier to model “correct” behavior than “incorrect”
behavior
 Relatively easier to configure due to deterministicTCP/IP
patterns
 Fewer alerting rules
 Requires higher trained staff for rule maintenance
 Detection examples:
 Detection of overly long UTF-8 characters (Nimda)
 All known FTP attacks break protocol specifications

9.  Will not detect viruses, and attacks
conforming to protocol specifications
 Applications that do not properly implement a
protocol may also trigger alerts
 Examples:
 NFR
 ManHunt

10.  IPS systems are a development of IDS
systems.
 Don’t just alert when an attack occurs, IPS
systems respond automatically to stop the
attack.
 There are two main types:
 Network Intrusion Prevention Systems
 Host Intrusion Prevention Systems

11.  These work inline between the target systems and the
outside world
 Bridging Inline
 Routing Inline
 Network Latency Overhead
 Examples include:
 Hogwash (http://hogwash.sourceforge.net/) a GPL open source NIPS
 Netscreen (http://www.netscreen.com/products/idp) a fast
commercial NIPS appliance
 ISSGuard
(http://www.iss.net/products_services/enterprise_protection/rsnetwor
k/guard.php) commercial NIPS software

12.  Usually implemented as kernel modules to
spot attacks on a system and act as a ‘system
call firewall’.
 Very varied level of security provided. Most
can be circumvented using specific
techniques.
 For the moment, beware of vendors offering
a cross platform product.

13.  Examples include:
 Integrity Protection Driver
(http://www.pedestalsoftware.com/products/intact/resources/index.a
sp)Windows Freeware, Open Source, Unsupported.
 Trushield (http://www.trustcorps.com),Commercial,Very strong on
Linux / Solaris,Windows product not as strong.
 Windows Application Control
(http://www.securewave.com/products/secureexe/index.html)
WindowsCommercial, Some concerns relating to user land
implementation.
 Server Lock for Windows
(http://www.watchguard.com/products/serverlock.asp)Windows
Commercial.

14.  IPS are a new take on an old idea:
 Sidewinder Firewall
 These are very hard to get right, none of these appear to be
mature yet.
 Can severely restrict software actions on a system. Need to
be tested as compatible with any software that they are
planned to protect.
 As far as we know no active blackhat groups are attempting
to defeat these. Window of opportunity to get ahead of the
hackers.
 Consider deploying on highly security- sensitive systems.

15. Host
 Processes
 File system access
 Applications
 Security events
 Registry edits
 Permissions edits
 User management
 Login attempts
 Changes to security
configuration
Network
 Firewall
 Intrusion Detection Systems (IDS)
 VPN gateways
 Routers
 Choke-points
 Dialup gateways
 Servers
 Mail
 DHCP
 Web
 Proxy

16.  Centralized and synchronized logging mechanisms
 Content retention
 Digital notaries and time stamping
 Third party logging and/or storage
 Secure logging software
 IETF Secure Syslog
 IIRC syslog-ng
 Core SDI msyslog

17.  UNIX logging is network oriented
 Applications send messages to a syslog server (which could be on a
different machine or the local machine)
 Each message is given a priority and type
 The syslog server saves the message to files based on its priority and
type and the contents of /etc/syslog.conf
 The log files are plain ASCII and typically stored in /var/log
Jan 01 14:10:29 www.atstake.com apache[117]:
Server started

18.  syslog will add log entries until there is no
more disk space
 Additional tools are needed to rotate logs on a
regular basis
 Log entries are trivial to delete and modify
when one has “root” access.

19.  RRDTool – Display time series data in graphical format.
(http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/index.h
tml)
 Swatch (ftp://ftp.cert.dfn.de/pub/tools/audit/swatch/)
 LogSurfer (http://www.cert.dfn.de/eng/logsurf/)
 NetWitness
(http://www.forensicexplorers.com/software.asp)
 NFR (http://www.nfr.net/products/SLR/)

20.  Windows logging is not-network oriented
 The “Event Logging” service is always running, but can be turned off
 Applications interact with the service using an API, ADVAPI32.DLL
 Three types of logs are stored (Application, Security, System). All are
stored in %SystemRoot%system32
 The format of these logs are binary, “EventViewer” is required to view
them
 The actual text message for Application logs can be stored in the
Registry, only an index is saved in the log

21.  Event logs cannot be modified while the logging service is running
(it has an exclusive lock)
 Except winzapper and clearlogs (which get system access)
 By default on Windows NT andWindows 2000, only system and
application events are logged (no security)
 However,Windows 2003 does log security by default.
 The “Audit Policy” contains a list of actions that can be logged
 “Object Access” only grants the ability to log. Each NTFS file (or
object) must be configured to actually log.
 Auditing policies can also be applied at the domain level
 KnowingWindows Event Codes will help during an incident

22.  Each type can have the Success, Failure, or
both logged.

23.  By default, older events
are deleted when a
maximum file size is
attained (or after a
given number of days)
 This is changed by
selecting Properties in
the EventViewer.

24.  Enable auditing (minimum):
 Logon & logoff
 Policy changes
 Account management
 Adjust maximum log sizes and roll-over policy
 Consider auditing object access to regedit,
*.sam etc.

25.  Microsoft IIS Log Parser 2.0
(http://www.microsoft.com/windows2000/downloads/tools/logparser/default.asp) Good
generic IIS web log analyser.Version 2.1 is part of the IIS 6.0 Resource KitTools.
 Microsoft Dump Event LogTool (Included in Windows 2000 Server Resource Kit
Supplement 1) Command line tool to dump local or remote event logs to a comma
separated text file.
 Microsoft EventCombMT (Included in Security Operations Guide for Windows 2000 Server)
Fast GUI tool for searching event logs of multiple systems. Good for estimating the extent
of an incident.
 Event Archiver (http://www.eventarchiver.com) Automatic event log backup tool with
database support. Useful for regular centralised log analysis.
 ELM Log Manager (http://www.tntsoftware.com/products/ELM3/ELM31/) Windows based
centralised log manager, supportsWindows, Syslog and SNMP sources. Stores data in a
database. Has an extensive range of options for notification.

26.  IIS 6.0 (Windows 2003) supports remote
logging via ODBC to a centralised SQL server.
 Probable performance hit.
 IIS 6.0 also supports a centralised log file for
each of the separate websites hosted on a
single server.
 However this is a binary file and requires a parsing
tool from the IIS 6.0 Resource Kit to read.

27.  Centralised log collection for windows event logs
 Encrypted and compressed on the network
 SQL Server for log repository
 Support for Windows XP, Windows 2003, Windows
2000
 Due for release late in 2003
 Apparently version 2 will integrate with MOM
version 2.

28.  The new centralised enterprise management
solution from Microsoft.
 Supports log / event input from:
 Windows Event Logs
 IIS log files
 Syslog
 SNMPTraps
 SQL ServerTrace Logs
 Any generic single line text log
 Haven’t had a chance to play with it yet but may be
the best centralised logging solution for Microsoft
or mixed Microsoft / UNIX networks.