Help - Search - Members - Calendar
Full Version: AntiSniff - find sniffers on your local network
Suggest A Fix PC Support Forums > Security > Security Tools and Articles > Tools and Utilities - read only
73-997563179
L0pht Heavy Industry has released AntiSniff, a sniffer detection tool that searches for common signs of packet sniffing applications. The tool can help administrators make sure the local network is free of unauthorized network monitoring tools.
By definition, a network sniffer is totally passive. However, shortcomings in the TCP/IP stack of NT and UNIX, makes most workstations behave differently when a sniffer is running.
AntiSniff looks for the following behavior patterns:

Linux Kernel Test
A weakness in the implementation of TCP/IP stack of some Linux kernels is exploited to discover Linux based sniffers.
The Linux kernel checks each IP packet to see if the IP is of the current machine. If it is, it is passed to the stack for processing. The packet is not checked to verify that the network card address of the packet (the 'ethernet' address) is the same as the interface card's address. This is not checked, since the network card should not except incoming packets that do not match its' network address. However, when running a sniffer, the network card is in 'promiscuous mode', which means it accepts all incoming packets - not just packets targeted at the specific machine.
In this test, AntiSniff sends an ICMP 'echo request', but when constructing the packet, the IP address is correct, but the network (Ethernet) address is bogus. If the target answers with an 'echo reply' packet, this means the network card is in promiscuous mode, which means a sniffer is probably running.

NetBSD kernel Test
The test is the same as above, but the IP address is set to a broadcast address.

Windows kernel Test
The test is again similar, but this time the IP address is correct, and the Ethernet address is ff:00:00:00:00:00. This is not a broadcast address, but due to weak implementation of the TCP/IP stack, a windows machine in promiscuous mode will process this packet and return a reply.
It's important to note that this test varies between different network card drivers and network card hardware. There are possibilities of false positives (stations answering to the packet although the interface is not in promiscuous mode), but these are relatively rare cases.

DNS queries
Sniffers capture raw network traffic, so in order for the gathered information to be valuable, there's a need to translate the IP addresses to host names. Therefore, sniffers will perform DNS queries to translate IP addresses of the captured packets. AntiSniff checks for this, by sending fake packets putting a bogus IP address as the destination address of the packet, and watching for DNS queries for that IP address. Machines that perform a query for that IP, are watching packets that weren't sent to them, and therefore are probably in promiscuous mode.

Latency Tests
This is the most interesting test in the series. Machines that listen to all incoming traffic have to process all the information on the network, causing a heavy load on the machine. AntiSniff exploits this fact by measuring the average response time of the machine, then flooding the network with useless traffic and measuring the response time again. A machine that listens for all network traffic, will be busy, therefore it will take it longer to respond. This test is repeated a few times, using different measuring methods to make it more accurate. This test will work on all machines and operating systems, although its' accuracy still needs to be proven.

Fooling AntiSniff
AntiSniff will work against most common sniffing tools, but it's far from being perfect. A few methods were already suggested to 'fool' AntiSniff and stealth the sniffing tools, making them undetectable. It's important to note that a custom made sniffer can listen for incoming traffic and be totally passive. However, the common attack is from legitimate machines on the network, and usually using standard sniffing tools. But even those standard tools can be hidden from AntiSniff:
- Use a modified kernel or IP stack that does not suffer from the mentioned problems (Linux kernel 2.2.10 works correctly and drops incoming packets not destined for this Ethernet address. Sniffers running on this kernel will not be detected by test #1).
- Don't do DNS lookups (most sniffing tools have this feature) - this will pass test #2.
- Stop sniffing when the network traffic exceeds a certain rate, passing test #3.

A sniffer called 'Anti-AntiSniff sniffer' was released just after the release of AntiSniff. This new sniffer uses the above methods to avoid being discovered by AntiSniff or similar utilities. Now we just have to wait for the Anti-Anti-AntiSniff...


Links
AntiSniff is available from l0pht's web site: http://www.l0pht.com/antisniff/. The Anti-AntiSniff sniffer was developed by Mike Perry. A technical paper explaining how to create a receive-only Ethernet NIC (which can make a sniffing computer totally invisible) is available at: http://www.zweknu.org/tech.php3

Interceptor
L0pht Heavy Industry has released AntiSniff, a sniffer detection tool that searches for common signs of packet sniffing applications. The tool can help administrators make sure the local network is free of unauthorized network monitoring tools.
By definition, a network sniffer is totally passive. However, shortcomings in the TCP/IP stack of NT and UNIX, makes most workstations behave differently when a sniffer is running.
AntiSniff looks for the following behavior patterns:

Linux Kernel Test
A weakness in the implementation of TCP/IP stack of some Linux kernels is exploited to discover Linux based sniffers.
The Linux kernel checks each IP packet to see if the IP is of the current machine. If it is, it is passed to the stack for processing. The packet is not checked to verify that the network card address of the packet (the 'ethernet' address) is the same as the interface card's address. This is not checked, since the network card should not except incoming packets that do not match its' network address. However, when running a sniffer, the network card is in 'promiscuous mode', which means it accepts all incoming packets - not just packets targeted at the specific machine.
In this test, AntiSniff sends an ICMP 'echo request', but when constructing the packet, the IP address is correct, but the network (Ethernet) address is bogus. If the target answers with an 'echo reply' packet, this means the network card is in promiscuous mode, which means a sniffer is probably running.

NetBSD kernel Test
The test is the same as above, but the IP address is set to a broadcast address.

Windows kernel Test
The test is again similar, but this time the IP address is correct, and the Ethernet address is ff:00:00:00:00:00. This is not a broadcast address, but due to weak implementation of the TCP/IP stack, a windows machine in promiscuous mode will process this packet and return a reply.
It's important to note that this test varies between different network card drivers and network card hardware. There are possibilities of false positives (stations answering to the packet although the interface is not in promiscuous mode), but these are relatively rare cases.

DNS queries
Sniffers capture raw network traffic, so in order for the gathered information to be valuable, there's a need to translate the IP addresses to host names. Therefore, sniffers will perform DNS queries to translate IP addresses of the captured packets. AntiSniff checks for this, by sending fake packets putting a bogus IP address as the destination address of the packet, and watching for DNS queries for that IP address. Machines that perform a query for that IP, are watching packets that weren't sent to them, and therefore are probably in promiscuous mode.

Latency Tests
This is the most interesting test in the series. Machines that listen to all incoming traffic have to process all the information on the network, causing a heavy load on the machine. AntiSniff exploits this fact by measuring the average response time of the machine, then flooding the network with useless traffic and measuring the response time again. A machine that listens for all network traffic, will be busy, therefore it will take it longer to respond. This test is repeated a few times, using different measuring methods to make it more accurate. This test will work on all machines and operating systems, although its' accuracy still needs to be proven.

Fooling AntiSniff
AntiSniff will work against most common sniffing tools, but it's far from being perfect. A few methods were already suggested to 'fool' AntiSniff and stealth the sniffing tools, making them undetectable. It's important to note that a custom made sniffer can listen for incoming traffic and be totally passive. However, the common attack is from legitimate machines on the network, and usually using standard sniffing tools. But even those standard tools can be hidden from AntiSniff:
- Use a modified kernel or IP stack that does not suffer from the mentioned problems (Linux kernel 2.2.10 works correctly and drops incoming packets not destined for this Ethernet address. Sniffers running on this kernel will not be detected by test #1).
- Don't do DNS lookups (most sniffing tools have this feature) - this will pass test #2.
- Stop sniffing when the network traffic exceeds a certain rate, passing test #3.

A sniffer called 'Anti-AntiSniff sniffer' was released just after the release of AntiSniff. This new sniffer uses the above methods to avoid being discovered by AntiSniff or similar utilities. Now we just have to wait for the Anti-Anti-AntiSniff...


Links
AntiSniff is available from l0pht's web site: http://www.l0pht.com/antisniff/. The Anti-AntiSniff sniffer was developed by Mike Perry. A technical paper explaining how to create a receive-only Ethernet NIC (which can make a sniffing computer totally invisible) is available at: http://www.zweknu.org/tech.php3
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.