Network Sniffers

Many IDS understand TCPdump format and can analyze traffic recorded by TCPdump. Solaris has its own sniffer that is installed by default --  snoop.

Actually in most cases it make sense first to write packets on the disk and only then analyze them offline as you can skin the cat in many different ways and n this case you options are not limited to one tool.

IDS like snort are pretty convenient as sniffers for complex situations, especially those that require sophisticated filtering as they have advanced filtering capabilities somewhat more flexible and generally superior then TCPdump or snoop. 

The latest versions of snort have Perl-compatible regular expressions implemented for analyzing the payload and that makes the writing of regex more simple for system administrators who are not exposed to the tool on daily basis.

Old News ;-)

[Dec 22, 2007] freshmeat.net Project details for TCP Re-engineering Tool

TCP Re-engineering Tool monitors and analyzes data transmitted between a client and a server via a TCP connection. It focuses on the data stream (software layer), not on the lower level transmission protocol (as packet sniffers do).

Release focus: Minor security fixes

Changes:
This release fixes a potential buffer overflow in the select loop on some platforms. The Brazilian Portuguese localization was added.

Author:
Rémi Denis-Courmont [contact developer]

 

[Mar 9, 2007] Description of the Port Reporter Parser (PR-Parser) tool

Microsoft's specialized sniffer that can be useful for analysis of network worms, for example Allaple.

When a Microsoft Windows-based computer becomes vulnerable, an attacker typically uses the resources of the Windows-based computer to inflict more damage or to attack other computers. This kind of attack typically involves activities such as starting one or more processes, or using TCP and UDP ports, or both. Unless an attacker hides this activity from the Windows-based computer itself, you can capture and identify this activity. Therefore, looking for indications of this kind of activity can help you determine whether a system is vulnerable.

The Port Reporter tool is a program that can run as a service on a computer that is running Microsoft Windows Server 2003, Microsoft Windows XP, or Microsoft Windows 2000. The Port Reporter service logs TCP and UDP port activity. On Windows Server 2003-based and Windows XP-based computers, the Port Reporter service can log the following information:

• The ports that are used
• The processes that use the port
• Whether a process is a service
• The modules (.dll, .drv, and so on) that a process loads
• The user accounts that start a process

The data that is captured by the Port Reporter service may help you determine whether a computer is vulnerable. The same data is also useful for troubleshooting, for gaining an understanding of a computer's port usage, and for auditing the behavior of a computer.

PR-Parser is a tool that parses the logs that the Port Reporter service generates. For additional information about the Port Reporter service, click the following article number to view the article in the Microsoft Knowledge Base: 837243 (http://support.microsoft.com/kb/837243/) Availability and description of the Port Reporter tool The PR-Parser tool provides the following three basic functions:

The PR-Parser tool has a Windows Graphical User Interface (GUI) that makes it easier to review the logs. By using the GUI, you can sort and filter the data in a number of ways. The PR-Parser tool helps you identify and filter the data that you are interested in. The tool provides the following functionalities:

• Identifies processes that you are interested in that are running on a computer
• Tries to identify when a process that uses the name of a legitimate process is run from the wrong folder on a computer
• Identifies the modules, such as .dll and .drv, that are loaded on a computer
• Helps determine the time when the Internet Protocol (IP) addresses, fully qualified domain names (FQDNs), or computer names that you are interested in are communicating with a computer
• Identifies the ports that are used on a computer
• Helps determine when the user accounts are active on a computer

The PR-Parser tool provides some log analysis data also. This data can help you understand the usage of a computer. This data includes the following:

• A ranked list of local Transmission Control Protocol (TCP) port usage
• A ranked list of local process usage
• A ranked list of remote IP address usage
• A ranked list of user context usage
• Svchost.exe service enumeration
• Port usage by hour of the day
• Microsoft Internet Explorer usage by user

editcap - Edit and-or translate the format of capture files

Ethereal Re [Ethereal-users] Installation of 0.9.0 under Solaris 2.8-gcc 3.0

> As this package is related to system/network administration and could be
> abused, it is installed so as to be executable only by root.

On Solaris, you can't capture packets promiscuously unless you're
running as root in any case - and you can't capture packets at all
unless the "/dev" entry for the network device type on which you'd be
capturing packets, e.g. "/dev/hme" or "/dev/ge", is readable and
writable by you, and it's normally readable and writable only by root:

hostname$ uname -sr
SunOS 5.8
hostname$ ls -lL /dev/hme /dev/ge
crw-------   1 root     sys       11, 51 Nov 13 13:28 /dev/ge
crw-------   1 root     sys       11,  7 Nov 13 13:22 /dev/hme

I.e., even if it's publicly executable, all a user can do on Solaris is
read captures somebody's already gotten *and* made readable by that
user.

(By default, that's the case on most systems.  The current CVS, and 3.7
beta, version of the tcpdump man page gives details:

     Reading packets from a network interface  may  require  that
     you have special privileges:

     Under SunOS 3.x or 4.x with
          You must have read access to /dev/nit or /dev/bpf*.

     Under Solaris with DLPI:
          You must have read/write access to the  network  pseudo
          device,  e.g.   /dev/le.   On at least some versions of
          Solaris, however,  this  is  not  sufficient  to  allow
          tcpdump  to  capture in promiscuous mode; on those ver-
          sions of Solaris, you must be root, or tcpdump must  be
          installed  setuid to root, in order to capture in prom-
          iscuous mode.

     Under HP-UX with DLPI:
          You must be root or tcpdump must be installed setuid to
          root.

     Under IRIX with snoop:
          You must be root or tcpdump must be installed setuid to
          root.

     Under Linux:
          You must be root or tcpdump must be installed setuid to
          root.

     Under Ultrix and Digital UNIX:
          Once the super-user has enabled promiscuous-mode opera-
          tion  using  pfconfig(8),  any user may capture network
          traffic with tcpdump.

     Under BSD:
          You must have read access to /dev/bpf*.

     Reading  a  saved  packet  file  doesn't   require   special
     privileges.

The same rules apply to Ethereal and Tethereal, as they use the same
capture mechanism that tcpdump does.)
 

[Feb 01, 2001] On the lookout for dsniff Part 2 Strategies for reducing your network's vulnerability to sniffer attacks by Larry Loeb ([email protected]),

Sniffer programs are a data interception technology that increase the risk of so-called "man-in-the-middle" attacks, and with the recent release of dsniff 2.3, security specialists need to be more aware of it than ever. Part 1 of this series explained how these network probing tools work, and how to recognize an attack. Here, Larry concludes with some tools and strategies for fighting sniffers.

Last time, the Gentle Reader was left with the expectation of finding some advice in this article on fighting sniffers. Because security is -- in Bruce (Applied Cryptography) Schneier's words -- "a process, not a product," please don't think there will be any magic bullets delineated here. There are none (including firewalls). We will talk of tools and strategies, both of which must be used by someone. But just because you're not Bob Vila doesn't mean you can't pick up a hammer and drive in a loose nail. Security chops come with experience. Listening to others' experiences can only make you smarter about what you have to do.

The network anomaly strategy

The first strategy generally used when dealing with any network intrusion event (and a sniffer is an intruder) is to look for anomalous network behavior. Second-order effects from intrusion activity can usually be found in either the kind of packets sent or the number of packets that are running around a network. If we look at the ISO Level 3 (the network layer that controls the forwarding of packets between stations, such as IP), dsniff may leave some telltales that can be used to alert a sysadmin to its presence. To detect this activity, you will want to use a sniffer of your own while you do the sheriff thing and track down the varmint.

There are other sniffers besides dsniff out there. Older ones like NFR and Snoop come to mind. NFR turns the network interface "promiscuous" (accepting all packets, not just the ones addressed to it) like all sniffers do. But NFR is programmable -- that means you can limit what you have to wade through in the traffic to only those particular packets or patterns you want.

1) Understand the attack

Let's think about how dsniff works. We know that dnsspoof forges data after a DNS query. That would imply that the local DNS server would have an increase in "ICMP port unreachables," because its true replies are ignored in favor of the spoofed response. Looking for abnormally high incidences of this condition can be a warning of ongoing spoofing.

2) Identify a signature event

Another indicator at the network level would be an excessive amount of TCP RST packets. The "tcpkill" tool causes this condition when it kills a TCP session to try and get a user to sign on again with a password that can then be sniffed. Flooding of ACK packets may also be evident due to the "tcpnice" tool also used in the spoof.

3) Look for the signature event and handle it

This sort of analysis works for other intrusions besides sniffing. For example, there was a favorite denial of service attack called the "ping of death," which was widely used in the last few years. It can be characterized by extremely lengthy ICMP packets. A sniffer could help defend against this kind of attack by listening for these aberrant ICMP packets, disposing of them before they could overwhelm a server, and hopefully establishing their source. The principle is the same here: Understand the mechanism of the attack, determine a signature event, and then handle it.

Counter-tools

Another viable strategy for dealing with a sniffer is the use of analytical counter-tools. For example, LOpht (now masquerading as @stake to the venture cap yuppies, but we'll always think of them as LOpht Heavy Industries) developed a tool called "AntiSniff" that is useful if a system is characterized BEFORE any attack has occurred (see Resources).

AntiSniff measures the packet latency of the current network and compares it to a "known-good" baseline. In this way, it indirectly measures the sniffer receiving packets, delaying them for some ever-so-slight period and then sending them on their way. This can tell you if the network is operating within normal parameters, or has been skewed in some way. The skew can mean that a sniffer is introducing a lag time into the system, as I mentioned. It could also mean the network load is heavier than it was when you ran the baseline.

So, packet latency variance alone is not a foolproof indicator of attack. It may simply mean that you should investigate your network further for any load bottlenecks or datasinks. But that review in and of itself may be a good thing if there are problems, and can at least confirm your current known-good status.

IDS programs

Realizing that latency needs to be coupled with another system parameter, some vendors have incorporated packet analysis routines into their intrusion detection software (IDS) packages. These routines look for patterns in the packet stream that they can identify as hostile from a supplied threat database. The network anomaly strategy (once again -- determine the event by understanding the attack, look for the event, handle the event) is taken to another level here, because you have the target machine trying to self-diagnose any problems by handling its own hostile events. This is similar to what a desktop PC virus program does to a hard disk with a "virus definitions" file, but the IDS' data capture is done from a net packet stream.

IDS programs have been widely touted in the industry as a security prophylactic for networks. My opinion on these is that while the best of them can indeed help deflect some attacks on big networks, they tend to give a false sense of security. Deploying them without fully understanding their limitations may be a Band-Aid response to a deeper problem. IDS use alone can make you blind to the true underlying security problems you really need to solve.

An IDS program will usually first scan all logical system ports to see if they are active and on the system map. This is much like the first move an attacker would try on a target system. In some ways, one must defend against an attacker by thinking like them and thus predicting their moves.

nmap

An attacker's tools will vary, but the current crop would most likely use the nmap port scanner (see Resources) to look for port information remotely. It's a two-year-old program, but it's still the current, widely-available state of the art in such arcana. You can test out nmap for yourself rather simply. Securitywire.com has set up a Web-based example on how nmap works (see Resources). nmap is so widely used because it combines many different scanning attack modes into one wrapper. In an attack, some attackers need speed, others need stealth. In some cases, bypassing firewalls is part of the attack. (Yes, you can indeed bypass firewalls. Just ask Steve Gibson. He does it by masquerading as a "trusted" application in a Trojan horse manner. nmap does it differently.) And don't overlook the fact that the attacker usually wants to scan different protocols (UDP, TCP, ICMP, etc.) to see what comes up where.

nmap (which stands for network mapper, by the way) supports these scan modes:

• Vanilla TCP connect() scanning
• TCP SYN (half open) scanning
• TCP FIN, Xmas, or NULL (stealth) scanning
• TCP ftp proxy (bounce attack) scanning
• SYN/FIN scanning using IP fragments (bypasses some packet filters)
• TCP ACK and Window scanning
• UDP raw ICMP port unreachable scanning
• ICMP scanning (ping-sweep)
• TCP Ping scanning
• Direct (non portmapper) RPC scanning
• Remote OS identification by TCP/IP fingerprinting
• Reverse-ident scanning

An explanation of each of these modes could take up an article by itself, so we'll just note that this list is pretty complete. If one way doesn't get any information, another way might. These kinds of port scans are fairly classic, with the exception of Remote OS Identification by TCP/IP Fingerprinting. It identifies the OS of a target through TCP/IP packet analysis. This form of attack by scanning may yet make some wide ripples in the security pool.

nmap also supports a number of performance and reliability features such as dynamic delay time calculations, packet timeout and retransmission, parallel port scanning, and detection of down hosts via parallel pings. nmap also offers flexible target and port specification, decoy scanning, determination of TCP sequence predictability characteristics, and output to machine-parseable or human-readable log files. Quite the little firecracker, this nmap.

The problem restated

O.K., what to do about these vulnerabilities? How can a CIO defend a network against some of the obvious problems inherent in sending information in the clear over a non-secure network?

Encrypting all network traffic is the most obvious solution. Let them sniff garbage, as it's sometimes called. But this way of doing things can make a network take a performance hit from the added computational and packet overhead that turns out to be unacceptable. Sometimes a solution won't scale well in the balance between usability and security. If encryption's not a viable option in a particular situation, we are then left with having to routinely network information in an understandable form. In the real world, that means vulnerability to a possible sniffer attack.

Developments in Zurich

The IBM Zurich GSAL (Global Security Analysis Lab -- see Resources) has done some thinking about the sniffer problem over the years. They already had all these networks and big computers there compiling a vulnerabilities database, but that didn't take up too much of their time. So they thought about the problem posed by sniffers. They researched and came up with a unique "poisoned bait" strategy that is implemented in a network sensor.

This strategy simulates network traffic using intentionally false information as bait. Any subsequent reuse of this information indicates that a system has been compromised. This method can also help locate an intruder within a network, because not all threats originate externally. Generically, this approach is called a "honeynet." In these, the intruder's actions are observed and logged in a comprehensive and related manner by the system being penetrated. These real-time loggings are then used for later analysis and forecasting.

Another sensor they've developed is a behavior-based approach for intrusion detection. It monitors the behavior of a UNIX system and sends an alert when a deviation from normal behavior occurs. Zurich says that it has broken new ground by applying the Teiresias algorithm, originally used for DNA sequencing, to intrusion detection.

A third prototype, called RID (routing intrusion detection), has been developed primarily by a group in the Zurich Lab's Communications Systems department. The goal of RID is to monitor a network for significant deviations from its normal behavior. An example of routing intrusion is a reachability attack: This occurs when an intruder floods false reachability information in order to hijack calls or to generate a denial-of-service attack.

As a byproduct, RID also provides a means of automatically detecting potential system misconfigurations or errors that may affect overall network operation. This autodiagnostic functionality may well prove to be as useful as the anti-sniffer properties.

Wrapping up

There are no simple solutions when it comes to vulnerabilities in a sniffer attack. Some strategies have been mentioned here, others haven't. But enough are included here to give you a better feel for the types of countermeasures that are possible, and whether or not they fit the problem at hand.

Resources

• An older version of dsniff that has been ported to Windows is available.
   
• Bruce Schneier's Applied Cryptography (Wiley, John & Sons, Incorporated, December 1995, ISBN: 0471117099) is considered by many to be the definitive primer on cryptography concepts.
   
• You can purchase the AntiSniff security monitoring tool (along with that password snarfer lophtcrack 3.0) at the Security Software Technologies site.
   
• The nmap port scanner is frequently used by attackers to look for port information remotely.
   
• Securitywire.com has set up a Web-based example of nmap. (It scans you over the Internet quite nicely.) nmap combines many different scanning attack modes into one wrapper.
   
• In "Remote OS detection via TCP/IP Stack FingerPrinting," nmap's author describes how to glean precious information about a host by querying its TCP/IP stack.
   
• IBM's Global Security Analysis Lab (GSAL) in Zurich has been working to address the sniffer issue on several fronts.

Internet Tool Summaries - CAIDA TOOLS taxonomy measurement

IPTraf
URL: http://cebu.mozcom.com/riker/iptraf/index.html
Contact: Gerard Paul Java
Cost: free under GNU2.0.
Platforms:Linux 2.0 and higher
Comments: curses-based IP LAN monitor that generates network statistics including TCP info, UDP counts, ICMP and OSPF information, Ethernet load info node stats, IP checksum errors and other network-based information.
Review:
Success: compiled cleanly on slackware 3.4. Provides rich set of diagnostics, more post-processing perl scripts than, e.g., tcpdump.
Problems: Only runs on linux tcpdpriv
URL: http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html
Summary: A program for eliminating confidential information from packets collected on a network interface (or, from trace files created using the -w argument to tcpdump). Currently only works on SunOS, Solaris, and FreeBSD systems. While it should port to other systems fairly easily, there have been problems reported. The software is copyrighted by Ipsilon Networks, Inc. (a "BSD-style" copyright)
Avail: free

[June 25, 1999] ngrep 1.31 Jordan Ritter 

ngrep strives to provide most of GNU grep's common features, applying them to the network layer. ngrep a pcap-aware tool that will allow you to specify extended regular expressions to match against data payloads of packets. It currently recognizes TCP and UDP across ethernet, ppp and slip interfaces, and understands bpf filter logic in the same fashion as more common packet sniffing tools like tcpdump and snoop.

home page: http://www.packetfactory.net/ngrep

Recommended Links

• Packet sniffer - Wikipedia, the free encyclopedia
• Sniffing The Complete Toolsbox
• Ethereal, Sniffing the glue that holds the Internet together. (For UNIX and Windows)
• Snort, see  Snort page.
• TCPDump (For UNIX).
• hping security tool - home page
• dsniff, mailsnarf, urlsnarf, & webspy^(1).
• UNIX Logging Utilities List and UNIX IDS List from Packetstorm.
• Windows
  • WinDump
  • Analyzer

Recommended Papers

Ethereal User's Guide

Sniffing (network wiretap, sniffer) FAQ

[PDF] High Performance Audited Traffic Capture Abstract  File Format: PDF/Adobe Acrobat - View as HTML We have successfully used the recorder to capture sustained TCP traffic at 178 Mb/s data rate (193 Mb/s of. actual traffic). ...

[PS] Review - a Tool For Reviewing Tcpdump Packet Logs Steven M. Romig ... File Format: Adobe PostScript - View as Text For TCP traffic the sessions correspond to individual TCP connections. ... through tools such as dial number recorders, and through network traffic logs, ...

[PDF] Building a Time Machine for Efficient Recording and Retrieval of Network Traffic

[PDF] IPmeter White Paper File Format: PDF/Adobe Acrobat - View as HTML
counts for traffic flows and makes them available to data recorders. ... TCP/IP. The suite of communications protocols used to connect hosts on the Internet ...
 Similar pages