|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|Old News||See also||Recommended Books||Recommeded Links||Recommended Papers||pcap library||editcap|
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.
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
This release fixes a potential buffer overflow in the select loop on some platforms. The Brazilian Portuguese localization was added.
Rémi Denis-Courmont [contact developer]
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 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.
- 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
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
> 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
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
(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-
Under HP-UX with DLPI:
You must be root or tcpdump must be installed setuid to
Under IRIX with snoop:
You must be root or tcpdump must be installed setuid to
You must be root or tcpdump must be installed setuid to
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.
You must have read access to /dev/bpf*.
Reading a saved packet file doesn't require special
The same rules apply to Ethereal and Tethereal, as they use the same
capture mechanism that tcpdump does.)
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.
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.
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.
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.
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.
- 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
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.
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
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)
[June 25, 1999]
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
Ethereal User's Guide
Sniffing (network wiretap, sniffer) FAQ[PDF] Microsoft PowerPoint - forensics_module7File Format: PDF/Adobe Acrobat - View as HTML
[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). ...
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
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 ...
Sniffit network traffick sniffer
Promiscuous Ethernet Detector, to check for sniffers on local subnet
Jul 29th 1998, 16:31
stable: 1.4 - devel: none
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2020 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to to buy a cup of coffee for authors of this site|
Last modified: June 10, 2010