Linux Security Cookbook [Electronic resources] نسخه متنی

Recipe 9.16 Observing Network Traffic

9.16.1 Problem

You want to watch network traffic
flowing by (or through) your machine.

9.16.2 Solution

Use a packet sniffer such as
tcpdump.^[7]

^[7] In spite of its name,
tcpdump is not restricted to TCP. It can capture
entire packets, including the link-level (Ethernet) headers, IP, UDP,
etc.

To sniff packets and save them in a file:

# tcpdump -w filename [-c count] [-i interface] [-s snap-length] [expression]

To read and display the saved network trace data:

$ tcpdump -r filename [expression]

To select packets related to particular TCP services to or from a
host:

# tcpdump tcp port service [or service] and host server.example.com

For a convenient and powerful GUI, use Ethereal. [Recipe 9.17]

To enable an unconfigured
interface, for a "stealth"
packet sniffer:

# ifconfig interface-name 0.0.0.0 up

To print information about all of your network interfaces with loaded
drivers: [Recipe 3.1]

$ ifconfig -a

9.16.3 Discussion

Is your system under attack? Your firewall is logging unusual
activities, you see lots of half-open connections, and the
performance of your web server is degrading. How can you learn what
is happening so you can take defensive action? Use a
packet sniffer to watch traffic on the
network!

In normal operation, network interfaces are programmed to receive
only the following:

• Unicast packets , addressed to a specific machine




• Multicast packets , targeted to systems that choose to
  subscribe to services like streaming video or sound




• Broadcast packets , for when an appropriate destination is
  not known, or for important information that is probably of interest
  to all machines on the network

The term "unicast" is not an
oxymoron: all packets on networks like Ethernet are in fact sent
(conceptually) to all systems on the network. Each system simply
ignores unicast packets addressed to other machines, or uninteresting
multicast packets.

A packet sniffer puts a network
interface into promiscuous
mode, causing it to receive all packets
on the network, like a wiretap. Almost all network adapters support
this mode nowadays. Linux restricts the use of promiscuous mode to
the superuser, so always run packet-sniffing programs as
root. Whenever you switch
an interface to promiscuous mode, the kernel logs the change, so we
advise running the logger command [Recipe 9.27] to announce your packet-sniffing activities.

If promiscuous mode doesn't seem to be working, and your kernel is sending complaints to the system logger (usually in /var/log/messages) that say: modprobe: can't locate module net-pf-17 then your kernel was built without support for the packet socket protocol, which is required for network sniffers. Rebuild your kernel with the option CONFIG_PACKET=y (or CONFIG_PACKET=m to build a kernel module). Red Hat and SuSE distribute kernels with support for the packet socket protocol enabled, so network sniffers should work.

Network switches complicate this
picture. Unlike less intelligent hubs, switches watch network
traffic, attempt to learn which systems are connected to each network
segment, and then send unicast packets only to ports known to be
connected to the destination systems, which defeats packet sniffing.
However, many network switches support packet sniffing with a
configuration option to send all traffic to designated ports. If you
are running a network sniffer on a switched network, consult the
documentation for your switch.

The primary purpose of network switches is to improve performance, not to enhance security. Packet sniffing is more difficult on a switched network, but not impossible: dsniffRecipe 9.19] is distributed with a collection of tools to demonstrate such attacks. Do not be complacent about the need for secure protocols, just because your systems are connected to switches instead of hubs.

Similarly, routers and gateways pass
traffic to different networks based on the destination address for
each packet. If you want to watch traffic between machines on
different networks, attach your packet sniffer somewhere along the
route between the source and destination.

Packet sniffers tap into the network stack at a low level, and are
therefore immune to restrictions imposed by firewalls. To verify the
correct operation of your firewall, use a packet sniffer to watch the
firewall accept or reject traffic.

Your network interface need not even
be configured in order to watch traffic (it does need to be up,
however). Use the
ifconfig command to enable an unconfigured
interface by setting the IP address to zero:

# ifconfig eth2 0.0.0.0 up

Unconfigured interfaces are useful for dedicated packet-sniffing
machines, because they are hard to detect or attack. Such systems are
often used on untrusted networks exposed to the outside (e.g., right
next to your web servers). Use care when these
"stealth" packet sniffers are also
connected (by normally configured network interfaces) to trusted,
internal networks: for example, disable IP forwarding. [Recipe 2.3]

Promiscuous mode can degrade network performance. Avoid running a packet sniffer for long periods on important, production machines: use a separate, dedicated machine instead.

Almost all Linux packet-sniffing programs use
libpcap , a packet capture library
distributed with tcpdump. As a fortunate
consequence, network trace files share a common format, so you can
use one tool to capture and save packets, and others to display and
analyze the traffic. The
file command recognizes and displays
information about libpcap-format network trace
files:

$ file trace.pcap
trace.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture 
length 96)

Kernels of Version 2.2 or higher can send warnings to the system logger like: tcpdump uses obsolete (PF_INET,SOCK_PACKET) These are harmless, and can be safely ignored. To avoid the warnings, upgrade to a more recent version of libpcap.

To sniff packets and save them in a file, use the tcpdump
-w option:

# tcpdump -w trace.pcap [-c count] [-i interface] [-s snap-length] [expression]

Just kill tcpdump when you are done, or use the
-c option to request a maximum number of packets
to record.

If
your system is connected to multiple networks, use the
-i option to listen on a specific interface (e.g.,
eth2). The ifconfig command prints
information about all of your network interfaces with loaded drivers:
[Recipe 3.1]

$ ifconfig -a

The special interface name "any" denotes all of the interfaces by any program that uses libpcap, but these interfaces are not put into promiscuous mode automatically. Before using tcpdump -i any , use ifconfig to enable promiscuous mode for specific interfaces of interest: # ifconfig interface promisc Remember to disable promiscuous mode when you are done sniffing: # ifconfig interface -promisc Support for the "any" interface is available in kernel Versions 2.2 or later.

Normally, tcpdump saves only the first 68 bytes of each
packet. This snapshot length is good for analysis of low-level
protocols (e.g., TCP or UDP), but for higher-level ones (like HTTP)
use the -s option to request a larger snapshot. To
capture entire packets and track all transmitted data, specify a
snapshot length of zero. Larger snapshots consume dramatically more
disk space, and can impact network performance or even cause packet
loss under heavy load.

By default, tcpdump records all packets
seen on the network. Use a capture filter
expression
to select specific packets: the
criteria can be based on any data in the protocol headers, using a
simple syntax described in the tcpdump(8) manpage. For example, to
record FTP transfers to or from a server:

# tcpdump -w trace.pcap tcp port ftp or ftp-data and host server.example.com

By restricting the kinds of packets you capture, you can reduce the
performance implications and storage requirements of larger
snapshots.

To read and display the saved network trace data, use the
tcpdump -r option:

$ tcpdump -r trace.pcap [
expression ]

Root access is not required to analyze the collected data, since it
is stored in ordinary files. You may want to protect those trace
files, however, if they contain sensitive data.

Use a display filter
expression
to print information only about selected
packets; display filters use the same syntax as capture filters.

The capture and display operations can be combined, without saving
data to a file, if neither the -w nor
-r options are used, but we recommend saving to a
file, because:

• Protocol analysis often requires displaying the data multiple times,
  in different formats, and perhaps using different tools.




• You might want to analyze data captured at some earlier time.




• It is hard to predict selection criteria in advance. Use more
  inclusive filter expressions at capture time, then more
  discriminating ones at display time, when you understand more clearly
  which data is interesting.




• Display operations can be inefficient. Memory is consumed to track
  TCP sequence numbers, for example. Your packet sniffer should be lean
  and mean if you plan to run it for long periods.




• Display operations sometimes interfere with capture operations.
  Converting IP addresses to hostnames often involves DNS lookups,
  which can be confusing if you are watching traffic to and from your
  nameservers! Similarly, if you tunnel tcpdump
  output through an SSH connection, that generates additional SSH
  traffic.

Saving formatted output from tcpdump is an even
worse idea. It consumes large amounts of space, is difficult for
other programs to parse, and discards much of the information saved
in the libpcap-format trace file. Use
tcpdump -w to save network traces.

tcpdump prints information about packets in a
terse, protocol-dependent format meticulously described in the
manpage. Suppose a machine 10.6.6.6 is performing a port scan of
another machine, 10.9.9.9, by running nmap
-r.Recipe 9.13] If you use tcpdump to
observe this port scan activity, you'll see
something like this:

# tcpdump -nn
...
23:08:14.980358 10.6.6.6.6180 > 10.9.9.9.20: S 5498218:5498218(0) win 4096 [tos 0x80]
23:08:14.980436 10.9.9.9.20 > 10.6.6.6.6180: R 0:0(0) ack 5498219 win 0 (DF) [tos 0x80]
23:08:14.980795 10.6.6.6.6180 > 10.9.9.9.21: S 5498218:5498218(0) win 4096 [tos 0x80]
23:08:14.980893 10.9.9.9.21 > 10.6.6.6.6180: R 0:0(0) ack 5498219 win 0 (DF) [tos 0x80]
23:08:14.983496 10.6.6.6.6180 > 10.9.9.9.22: S 5498218:5498218(0) win 4096
23:08:14.984488 10.9.9.9.22 > 10.6.6.6.6180: S 3458349:3458349(0) ack 5498219 win 5840 
<mss 1460> (DF)
23:08:14.983907 10.6.6.6.6180 > 10.9.9.9.23: S 5498218:5498218(0) win 4096 [tos 0x80]
23:08:14.984577 10.9.9.9.23 > 10.6.6.6.6180: R 0:0(0) ack 5498219 win 0 (DF) [tos 0x80]
23:08:15.060218 10.6.6.6.6180 > 10.9.9.99.22: R 5498219:5498219(0) win 0 (DF)
23:08:15.067712 10.6.6.6.6180 > 10.9.9.99.24: S 5498218:5498218(0) win 4096
23:08:15.067797 10.9.9.9.24 > 10.6.6.6.6180: R 0:0(0) ack 5498219 win 0 (DF)
23:08:15.068201 10.6.6.6.6180 > 10.9.9.9.25: S 5498218:5498218(0) win 4096 [tos 0x80]
23:08:15.068282 10.9.9.9.25 > 10.6.6.6.6180: R 0:0(0) ack 5498219 win 0 (DF) [tos 0x80]
...

The nmap -r process scans the
ports sequentially. For each closed port, we see an incoming TCP SYN
packet, and a TCP RST reply from the target. An open SSH port (22)
instead elicits a TCP SYN+ACK reply, indicating that a server is
listening: the scanner responds a short time later with a TCP RST
packet (sent out of order) to tear down the half-open SSH connection.
Protocol analysis is especially enlightening when a victim is
confronted by sneakier probes and denial of service attacks that
don't adhere to the usual network protocol rules.

The previous example used -nn to print everything
numerically. The -v option requests additional
details; repeat it (-v -v ...) for increased
verbosity. Timestamps are recorded by the kernel (and saved in
libpcap-format trace files), and you can select a
variety of formats by specifying the -t option one
or more times. Use the -e option to print
link-level (Ethernet) header information.

9.16.4 See Also

ifconfig(8), tcpdump(8), nmap(8). The tcpdump home
page is http://www.tcpdump.org,
and the nmap home page is http://www.insecure.org/nmap.

A good reference on Internet protocols is found at
http://www.protocols.com. Also,
the book

Internet Core Protocols: The Definitive
Guide (O'Reilly) covers similar

material.