 More
Tools for Network Security Monitoring
Richard Bejtlich
In the April 2004 issue of Sys Admin magazine (http://www.samag.com/documents/s=9102/sam0404d/),
I introduced the Network Security Monitoring (NSM) model and several
open source tools to collect full content, statistical, session,
and alert data. These tools and techniques help analysts in the
collection, analysis, and escalation of indications and warnings
to detect and respond to intrusions. To identify and contain incidents,
NSM focuses more on network audit and situational awareness, and
less on recognizing malicious traffic patterns and alert-centric
intrusion detection methods. Those practicing NSM believe it is
helpful to collect as much network-based evidence as legally and
technically possible. Such collection aids all aspects of the security
process, especially those supporting incident response.
This article introduces several tools to enhance your NSM efforts.
The theme of the tools selected for this article is achieving network
awareness in an independent or "self-reliant" manner. In other words,
these tools help administrators learn more about their network while
passively interpreting network traffic. Given suitable access to
packets via hub, tap, SPAN port, or inline device, these applications
give administrators a better idea of which assets exist in the enterprise
and how they are being used -- all without touching those devices
or supporting infrastructure. In organizations with security and
network administration split among separate and sometimes hostile
groups, it can be difficult for either team to acquire the data
it needs. These tools can help either group attain higher network
situational awareness to support troubleshooting, incident response,
and other tasks.
All of these tools could be deployed to supplement existing proprietary
or open source software. They were tested on FreeBSD 5.3 RELEASE
but will work on other BSDs, Linux, and most likely commercial Unix
variants.
Dhcpdump
Edwin Groothuis wrote dhcpdump (http://www.mavetju.org/unix/dhcpdump-man.php)
to provide an easy means to monitor and interpret Dynamic Host Configuration
Protocol (DHCP) traffic. Many hosts use DHCP after booting to obtain
their IP address, subnet mask, gateway address, DNS servers, and
other information. Logging the actions of hosts that are acquiring
and possibly changing IP addresses is especially helpful when trying
to track down misbehaving or rogue systems. While DHCP logs should
be collected by the DHCP server itself, a suitably-situated tool,
like dhcpdump, offers an independent record of DHCP activity.
The package shipped with FreeBSD installs dhcpdump 1.6. Since
FreeBSD 5.3 offers tcpdump 3.8.3, I recommend installing dhcpdump
1.7 from source code or a newer FreeBSD package. Groothuis wrote
dhcpdump 1.7 to specifically support tcpdump 3.8.3, which ships
with FreeBSD 5.3. Dhcpdump relies on tcpdump to acquire the traffic
it interprets. Run dhcpdump using syntax like the following to watch
traffic collected by tcpdump on interface fxp0:
# tcpdump -lenx -i fxp0 -s 1500 port bootps or port bootpc | dhcpdump
Tcpdump's -lenx option makes output line-buffered, displays
link-level headers, disables name resolution, and prints packets in
hex format. The -i switch specifies fxp0 as the listening interface
while -s denotes a snap length of 1500 bytes. The snap length
is the amount of bytes to collect for each packet. The port bootps
or port bootpc primitive tells tcpdump to collect traffic on ports
67 or 68 (TCP or UDP), respectively. Since DHCP traffic uses UDP,
TCP traffic on those ports is unlikely to be significant.
By piping these packets to dhcpdump, we see output like the following:
tcpdump: listening on fxp0
TIME: 15:42:12.019907
IP: 0.0.0.0.68 (0:30:48:41:f9:56) > 255.255.255.255.67 \
(ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: fd472e21
SECS: 0
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: :00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST)
OPTION: 50 ( 4) Request IP address 10.200.211.99
OPTION: 55 ( 7) Parameter Request List 1 (Subnet mask)
28 (Broadcast address)
2 (Time offset)
3 (Routers)
15 (Domainname)
6 (DNS server)
12 (Host name)
-------------------------------------------------------------
TIME: 15:42:12.023739
IP: .67 (0:f:23:16:68:0) > 10.200.211.99.68 (0:30:48:41:f9:56)
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: fd472e21
SECS: 0
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.200.211.99
SIADDR: 0.0.0.0
GIADDR: 10.200.211.1
CHADDR: 00:30:48:41:f9:56:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 5 (DHCPACK)
OPTION: 58 ( 4) T1 1296000 (2w24h)
OPTION: 59 ( 4) T2 2268000 (3w5d6h)
OPTION: 51 ( 4) IP address leasetime 2592000 (4w2d)
OPTION: 54 ( 4) Server identifier 10.200.1.3
OPTION: 1 ( 4) Subnet mask 255.255.255.0
OPTION: 3 ( 4) Routers 10.200.211.1
OPTION: 15 ( 1) Domainname
OPTION: 6 ( 20) DNS server 10.200.2.10,198.6.1.4,198 \
.6.1.5,198.6.1.3,198.6.1.6
------------------------------------------------------------------
This example shows two DHCP packets. The first is a request by a workstation
with Media Access Control (MAC) address 00:30:48:41:f9:56 to obtain
IP address 10.200.211.99. The workstation's DHCPREQUEST message also
asks for its subnet mask, broadcast address, and five other parameters.
The workstation is a FreeBSD system using dhclient(8), which keeps
a record of the IP addresses it has been previously assigned in
the file /var/db/dhclient.leases:
lease {
interface "fxp0";
fixed-address 10.200.211.99;
option subnet-mask 255.255.255.0;
option dhcp-lease-time 2592000;
option routers 10.200.211.1;
option dhcp-message-type 5;
option dhcp-server-identifier 10.200.1.3;
option domain-name-servers \
10.200.2.10,198.6.1.4,198.6.1.5,198.6.1.3,198.6.1.6;
option dhcp-renewal-time 1296000;
option dhcp-rebinding-time 2268000;
renew 2 2004/11/23 19:37:10;
rebind 2 2004/12/7 02:53:32;
expire 5 2004/12/10 20:53:32;
Windows system behave in a similar fashion, with systems already assigned
an IP via DHCP likely to ask for the same IP in the future.
The second half of the dhcpdump output shows the response by DHCP
server 10.200.1.3. It grants the workstation the IP address it wanted
(10.200.211.99), a renewal time (T1), rebinding time (T2), IP address
lease time, and other parameters. When the renewal time (T1) expires,
the client will try to renew its IP address lease by asking the
server that granted the original lease. If the client cannot renew
using the original DHCP server, it waits for the rebinding time
(T2) to expire and then asks for any available DHCP server to extend
its IP lease. If that also fails, the workstation's lease expires
at the end of its IP address "leasetime" and it must continue seeking
a new IP address.
Both tcpdump and tethereal can interpret DHCP traffic. Tcpdump
is terse:
15:47:51.015103 0.0.0.0.68 > 255.255.255.255.67: xid:0x871fdd1f
vend-rfc1048 DHCP:REQUEST RQ:10.200.211.99 \
PR:SM+BR+TZ+DG+DN+NS+HN [tos 0x10]
15:47:51.019195 10.200.211.1.67 > 10.200.211.99.68: xid:0x871fdd1f
Y:10.200.211.99 G:10.200.211.1 vend-rfc1048 DHCP:ACK RN:1296000
RB:2268000 LT:2592000 SID:10.200.1.3 SM:255.255.255.0 DG:10.200.211.1
DN:"^@" NS:10.200.2.10,198.6.1.4,198.6.1.5,198.6.1.3,198.6.1.6
Tethereal's -V output (not shown here) is easier to interpret,
albeit half of the display is taken by layer 2, 3, and 4 information.
By keeping independent records of DHCP traffic using dhcpdump
(with output redirected to a file), administrators can keep track
of systems as they obtain and release IP addresses on the network.
Passive Asset Detection System
Now that we're keeping track of systems obtaining their IP address,
we turn to seeing which services those hosts offer. Matt Shelton
wrote Passive Asset Detection System (PADS) to passively detect
network assets; it's available from:
http://passive.sourceforge.net
It complements Michal Zalewski's P0f (http://lcamtuf.coredump.cx/p0f.shtml),
which passively identifies operating systems by inspecting TCP traffic.
(I describe P0f in Chapter 6 of my book The Tao of Network Security
Monitoring.) PADS does not determine operating systems, but it
does enumerate services it recognizes. By running PADS at critical
network junctures, an analyst can quietly amass a database of the
services active in the enterprise.
For this article, I tested PADS 1.1.3, installed from source code
on FreeBSD 5.3. The Perl Compatible Regular Expressions (PCRE) library
is required and is available as the pcre package on FreeBSD.
PADS is simple to operate. I recommend specifying the network
for which you want to identify systems. In this example, we tell
PADS to identify services on the 10.0.0.0/8 network. Without this
modifier, PADS will track all services it sees, including those
accessed on the Internet from within the monitored organization.
The following syntax runs PADS in the foreground against the em3
interface, which does not have an IP address assigned:
# pads -i em3 -n 10.0.0.0/8
pads - Passive Asset Detection System
v1.1.3 - 09/30/04
Matt Shelton <matt@mattshelton.com>
[-] Listening on interface em3
[!] ERROR: pcap_lookupnet (em3: no IPv4 address assigned)
[*] Asset Found: Port - 80 / Host - 10.100.101.48 / Service - \
www / Application - Unknown HTTP (HTTP/1.0)
[*] Asset Found: Port - 80 / Host - 10.200.1.28 / Service - \
www / Application - Microsoft-IIS 6.0
[*] Asset Found: Port - 0 / Host - 10.100.209.46 / Service - \
ICMP / Application - ICMP
[*] Asset Found: Port - 445 / Host - 10.100.209.46 / Service - \
smb / Application - Windows SMB
[*] Asset Found: Port - 445 / Host - 10.100.210.4 / Service - \
smb / Application - Windows SMB
[*] Asset Found: Port - 25 / Host - 10.200.1.28 / Service - smtp / \
Application - Microsoft Exchange SMTP 6.0.3790.211 (mail.example.com)
[*] Asset Found: Port - 0 / Host - 10.100.202.70 / Service - \
ICMP / Application - ICMP
[*] Asset Found: Port - 445 / Host - 10.100.202.70 / Service - \
smb / Application - Windows SMB
[*] Asset Found: Port - 1270 / Host - 10.100.101.48 / Service - \
unknown / Application - unknown
This output shows three systems offering the Windows Server Message
Block (SMB) protocol on port 445 TCP, one system offering Microsoft's
mail service on port 25 TCP, and two systems that have replied with
ICMP echo reply packets. Two systems are running Web servers, although
only one was identified as Microsoft IIS 6.0. The final record shows
a system offering an unknown service on port 1270 TCP. PADS watches
for traffic from hosts and records what it sees; it does not watch
outbound traffic initiated by a monitored host. This explains the
ICMP "servers"; these are systems that replied to ICMP echo requests.
PADS can be run as a daemon using the -D switch, in which
case output will not be shown. PADS stores its findings comma-separated
value format in the file assets.csv. The pads-report program processes
the assets.csv file, consolidating what PADS has seen into report
format. For example, here is how two services on 10.200.1.28 are
reported:
------------------------------------------------------------------
IP: 10.200.1.28
Port Service Application
25 smtp Microsoft Exchange SMTP 6.0.3790.211 (mail.example.com)
80 www Microsoft-IIS 6.0
------------------------------------------------------------------
PADS is smart enough to resume recording after it has been interrupted
as it re-processes existing assets.csv files when restarted. PADS
can also be run against packets stored in libpcap format using the
-r switch. PADS is beginning to offer support for loading results
into a database.
Security Analyst Network Connection Profiler
At this point, we know which systems are active and what services
they offer. Tracking all of their actions would be helpful, and
for that we turn to the Security Analyst Network Connection Profiler
(SANCP). John Curry wrote SANCP to collect session and full content
data to support network security monitoring. It can be found at:
http://www.metre.net/sancp.html
A session, also known as a "flow," is a summary of a connection between
two parties. Session data typically consists of the source and destination
IPs and ports of the session, start and end times, protocol, flags
seen (if using TCP), and byte and packet counts for the source and
destination hosts. SANCP is similar to Argus, discussed in my previous
article. Like Argus, SANCP tracks and summarizes TCP sessions, but
also estimates sessions for connectionless protocols like UDP and
ICMP. SANCP also accepts Berkeley Packet Filter syntax to limit the
scope of its collection field of view.
Argus is a powerful application used by many to watch high-speed
links, and I often deploy it as a standalone application. SANCP,
however, offers three features not provided by Argus. First, SANCP
can capture packets as well as session data. I do not address that
here as I do not use SANCP in that manner. Second, SANCP reduces
each observed conversation to a single record. Argus may report
several session records during the life of a session, which adds
to the analyst's workload. Third, when SANCP is paired with Sguil,
SANCP's session records are loaded into a MySQL database. Within
Sguil, an analyst can query using SQL syntax for session data recorded
by SANCP.
Figure 1 shows a query for session records involving IP 192.168.2.5,
with bytes of application data sent by the destination party greater
than zero. Such a query shows conversations where the parties exchanged
application-layer data.
I installed SANCP version 1.6.1 using source code downloaded from
the author's site. For information on integrating SANCP with Sguil
(which requires installing Sguil), I recommend following the directions
in my Sguil Installation Guide (http://sguil.sourceforge.net/sguil_guide_latest.txt).
With SANCP collecting session data, an administrator can keep
track of the actions of every host seen by the monitoring interface
of the sensor. This content-neutral method of gathering network
data is immune to encryption, as SANCP will record encrypted sessions
with no regard to their obfuscated contents. SANCP also collects
session records regardless of the actions of any alert-centric intrusion
detection system. When an IDS fails to bring an event to the attention
of a security administrator, that event is forgotten permanently.
With session data, events are recorded regardless of their hostile
or benign nature. This feature allows security personnel to maintain
situational awareness in the face of new attack methods.
Session data is a powerful way to audit network events. If an
administrator learns of a new bot net that's using port 9000 TCP
to communicate, she could query her session data for all connections
involving that port. She could prune the results by specifying sessions
where application data was passed. Any records involving port 9000
TCP would be indicators of compromise. Once potential victims are
identified, more intensive host-based or network-based investigation
could begin. Once you've started collecting and analyzing session
data, you're sure to wonder how you ever slept peacefully without
it!
Conclusion
This article introduced three tools to improve network situational
awareness: dhcpdump, PADS, and SANCP. Each offers a self-contained
way to extract intelligence from network events. Each extends your
ability to perform Network Security Monitoring to identify and mitigate
intrusions.
Richard Bejtlich is the author of The Tao of Network Security
Monitoring: Beyond Intrusion Detection and co-author of the forthcoming
Real Digital Forensics, both published by Addison-Wesley.
He is technical director for the Monitoring Operations Division
of ManTech's Computer Forensics and Intrusion Analysis group. Richard
also maintains taosecurity.blogspot.com and www.taosecurity.com
and contributes to the Sguil project. |
