2. How can I defend myself against packet
sniffers
2.1 How can I stop people from sniffing my data?
While you can configure your local network to make sniffing hard, you are pretty much
powerless stopping people from out on the Internet from sniffing your traffic. The best
defense in this case is to encrypt your data, so that while they can sniff it, they cannot
read it. Some techniques are:
SSL
- "Secure Sockets Layer", SSL is built into all popular web browsers and web
servers. It allows encrypted web surfing, and is almost always used in e-commerce when
users enter their credit card information.
This site for Apache SSL describes this: http://www.modssl.org/
PGP and S/MIME
- E-mail can be sniffed in many alternative ways. It passes through corporate firewalls,
which may monitor the traffic. It often gets logged and saved for extended periods of
time. It may get accidentally misdirected, and end up in somebody else's mailbox. The best
way to keep such e-mail secret is to encrypt it. The two common ways of doing this are
with PGP (Pretty Good Privacy) and S/MIME (Secure MIME). PGP can be purchased as an add-on
to many products. S/MIME is built into e-mail programs by Netscape and Microsoft.
ssh
- "Secure Shell", ssh has become the de facto standard for logging into UNIX
machines from the Internet. You should immediately replace telnet with this
service. Numerous other protocols can be tunneled through ssh connections (i.e. file
copy). The product was originally developed by a Finish company http://www.ssh.fi/ but many open-source/freeware
implementations also exist.
VPNs (Virtual Private Networks)
- VPNs provide encrypted traffic across the Internet. However, if a hacker compromises the
end-nodes of a VPN connection, they can still sniff the traffic. A typical scenario is an
end-user who surfs the Internet normally and gets compromised with a Remote Access Trojan
(RAT) that contains a sniffing plug-in. When the user establishes the VPN connection, the
sniffing program is able to see not only the encrypted traffic that can be seen on the
Internet, but also the unencrypted traffic before it gets sent through the stack to the
VPN.
2.2 How can I stop people from sniffing my passwords?
The data-encryption solutions above also provide for secure authentication. There are
other solutions that provide for secure authentication as well:
SMB/CIFS
- In the Windows/SAMBA environment, make sure that you have the older LanManager
authentication turned off. This requires SAMBA v2 or later, WinNT SP3 or later, and so on.
Kerberos v5
- Both Windows 2000 and UNIX provide support for Kerberos authentication. This is one of
the strongest generic mechanisms available. ftp://aeneas.mit.edu/pub/kerberos/doc/KERBEROS.FAQ
smart cards
- There are numerous smart card implementations around providing one-time passwords. These
are often used when connecting remotely, either dial-in or VPN across the Internet.
Stanford SRP (Secure Remote Password)
- Enhancements to Telnet and FTP for UNIX and Windows. http://srp.stanford.edu/srp/
2.3 How can I configure my local network to make sniffing harder?
Replacing your hub with a switch will provide a simple, yet effective defense against
casual sniffing. While this solution is extremely effective in practice (and should be
strongly considered), it shouldn't be relied upon as a complete defense against sniffing.
A switch still creates a "broadcast domain", providing an attacker the ability
to spoof ARP packets.
The easiest such exploit is the "router redirection". ARP queries contain the
correct IP-to-MAC mapping for the sender. In order to reduce ARP traffic, most machines
will cache this information that they read from the query broadcasts. Therefore, a
malicious attacker can redirect nearby machines to forward traffic through it by sending
out regular ARP packets containing the router's IP address mapped to its own MAC address.
All the machines on the local wire will believe the hacker is the router, and therefore
pass their traffic through him/her.
A similar attack would be to DoS a target victim and force it off the network, then
begin using its IP address. If a hacker does this carefully, s/he can inherit connections
already established without dropping them. Windows machines are even so polite that when
they come onto the network and see someone else using their address, they will kindly shut
down their own TCP/IP stacks and allow this to continue. SMB (the Windows file sharing
protocol) is also kind enough to allow predictable identifiers, allowing cr/hackers to
predict enough information to keep the connection going.
Most intrusion detection systems and even network management tools like the Expert
Sniffer(tm) will detect these shenanigans. For example, putting the BlackICE IDS on all
the Windows end-nodes or hooked to a normal port (to receive broadcasts) will alert the
security admin that such things are taking place (but, will generate false positives when
DHCP reassigns addresses. Sigh.)
Most Ethernet adapters allow the MAC address to be manually configured. Thus a hacker
can spoof MAC addresses by reassigning the address on the adapter, or by bypassing the
built-in stack and hand-crafting frames. The hacker must maintain a a constant stream of
outgoing frames in order to convince the auto-learning switch that they are the legitimate
owner of the MAC address.
Many (most??) switches allow MAC addresses to be configured statically in order to
prevent this sort of thing. While it may be a difficult management burden to do this for
all end-nodes, it may prove useful for the router, restricting the hacker to wiretapping
individual end-nodes instead of everyone all at once.
Some switches can be kicked out of "bridging" mode into "repeating"
mode where all frames are broadcast on all ports all the time. This is done by overflowing
the address tables with lots of false MAC addresses. This can be done with a simple
traffic generation phase, or by sending a continual stream of random garbage through the
switch.
2.4 Can I buy adapters that do not support sniffing?
No. The real answer is "yes", there are some older adapters that do not
support promiscuos mode. In particular, the original IBM Token Ring adapters (TROPIC
chipset) were not able to run in promiscuous mode. There are also a few Ethernet where
promiscuous mode is broken, either in the hardware or in the driver. Actually, there are
far more adapters who simply lack the functionality in the driver in order to turn on
promiscuous mode, meaning all programs that attempt to put them into promiscuous mode will
fail even though the hardware supports the mode in theory. If you really must have one,
then call technical support for a sniffing product vendor (such as NAI) and ask them which
cards they DON'T support. For Windows, you might check with Microsoft support to see which
cards do not support NetMon (I remember there are a few, but I can't find the
documentation for it).
Note that in the Intel/Microsoft "PC99" guidelines, promiscuous mode is a
"required" feature.
If this is a concern, it will be cheaper in the long run simply to upgrade to switching
hubs, which basically does the same thing. An Ethernet switch moves the "address
match" upstream, so that the switch does it rather than the adapter.
Finally, it should be noted that most new networks are switched in some fashion.
Even though hackers cannot sniff an entire Ethernet segment, they still install sniffers
on machines in order to see the incoming/outgoing traffic. A non-promiscuous adapter won't
help defend against this.
2.5 How can I detect a packet sniffer?
In theory, it is impossible to detect sniffing programs because they are passive:
they only collect packets, they don't transmit anything. However, in practice it is
sometimes possible to detect sniffing programs. It is similar to how in theory it
is impossible to detect radio/TV receivers, but European countries do it all the time in
order to catch people avoiding the radio/TV tax. A stand-alone packet sniffer doesn't
transmit any packets, but when installed non-standalone on a normal computer, the sniffing
program will often generate traffic. For example, it might send out DNS reverse lookups in
order to find names associated with IP addresses.
Non-standalone packet sniffers are indeed what you want to detect. When
crackers/hackers invade machines, they often install sniffing programs. You want to be
able to detect this happening.
General Overview of Detection Methods
ping method
- Most "packet sniffers" run on normal machines with a normal TCP/IP stack. This
means that if you send a request to these machines, they will respond. The trick is to
send a request to IP address of the machine, but not to its Ethernet adapter.
To
illustrate:
- The machine suspected of running the packet sniffer has an IP address 10.0.0.1, and an
Ethernet address of 00-40-05-A4-79-32.
- You are on the same Ethernet segment as the suspect (remember, the Ethernet is used only
to communicate locally on a segment, not remotely across the Internet).
- You change the MAC address slightly, such as 00-40-05-A4-79-33.
- You transmit an "ICMP Echo Request" (ping) with the IP address and this new
MAC address.
- Remember that NOBODY should see this packet, because as the frame goes down the wire,
each Ethernet adapter matches the MAC address with their own MAC address. If none matches,
then they ignore the frame.
- If you see the response, then the suspect wasn't running this "MAC address
filter" on the card, and is hence sniffing on the wire.
There are ways defending against this. Now that this technique is widely publicized,
newer hackers will enabled a virtual MAC address filter in their code. Many machines
(notably Windows) have MAC filtering in drivers. (There is a hack for Windows: most
drivers just check the first byte, so a MAC address of FF-00-00-00-00-00
looks like FF-FF-FF-FF-FF-FF (the broadcast address which all adapters
accept). However, some adapters implement multicast in such as way that this address will
match as a multicast, which is any address whose first byte is an odd number. Thus, this
can result in false positives).
This technique will usually work on switched/bridged Ethernets. When switches see an
unknown MAC address for the first time, they will "flood" the frame to all
segments.
ping method, part 2
- The ping method can be enhanced in a number of ways:
- Any protocol that generates a response can be used, such as a TCP connection request or
a UDP protocol such as port 7 (echo).
- Any protocol that might generate an error on the target machine might be used. For
example, bad IP header values might be used to generate an ICMP error.
- Sometimes a broadcast address (either a "local broadcast" like 255.255.255.255
or a "directed broadcast" like 10.0.0.255) needs to be used in order to bypass
software IP address filtering. This then encounters another problem in that many machines
do not respond to broadcast requests (responses to broadcasts causes network problems,
such as the 'smurf' hack).
ARP method
- The ARP method is similar to the ping method, but an ARP packet is used instead. An
explanation (in Spanish) is given at http://www.apostols.org/projectz/neped/
which includes a program to do this detection.
The simplest ARP method transmits an ARP
to a non-broadcast address. If a machine responds to such an ARP of its IP address, then
it must be in promiscuous mode.
A variation of this technique takes advantage of the fact that machines
"cache" ARPs. Each ARP contains the complete information of both the sender as
well as the desired target information. In other words, when I send out a single ARP to
the broadcast address, I include my own IP-to-Ethernet address mapping. Everyone else on
the wire remembers this information for the next few minutes. Therefore, you could do
something like sending out a non-broadcast ARP, then a broadcast ping. Anybody who
responds to your ping without ARPing you could only have gotten the MAC address from a
sniffed ARP frame. (To make double-sure, use a different source MAC address in the ping).
DNS method
- Many sniffing programs do automatic reverse-DNS lookups on the IP addresses they see.
Therefore, a promiscuous mode can be detected by watching for the DNS traffic that it
generates.
This method can detect dual-homed machines and can work remotely. You need
to monitor incoming inverse-DNS lookups on the DNS server in your organization. Simply do
a ping sweep throughout the company against machines that are known not to exist. Anybody
doing reverse DNS lookups on those addresses are attempting to lookup the IP addresses
seen in ARP packets, which only sniffing programs do.
This same technique works locally. Configure the detector in promiscuous mode itself,
then send out IP datagrams to bad addresses and watch for the DNS lookups.
One interesting issue with this technique is that hacker-based sniffing programs tend
to resolve IP addresses as soon as they are found, whereas commercial programs tend to
delay resolution until the point where the packet sniffer user views the protocol decodes.
source-route method
- Another technique involves configuring the source-route information inside the IP
header. This can be used to detect packet sniffers on other, nearby segments.
- Create a ping packet, but put a loose-source route to force it by another machine on the
same segment. This machine should have routing disabled, so that it will not in fact
forward it to the target.
- If you get a response, then it is likely the target sniffed the packet off the wire.
- In the response, doublecheck the TTL field to find out if it' came back due to sniffing
(rather than being routed correctly)
Details:
In loose source-routing, an option is added to the IP header. Routers will ignore the
destination IP address and instead forward to the next IP address in the source-route
option. This means when you send the packet, you can say "please send packet to Bob,
but route it through Anne first".
In this scenario, both "Anne" and "Bob" are on the segment. Anne
does not route, and therefore will drop the packet when received. Therefore,
"Bob" will only respond if he has sniffed the packet from the wire.
On the off chance that Anne does indeed route (in which case Bob will respond), then
the TTL field can be used to verify that Bob responded from routing through Anne, or
answering directly.
The decoy method
- Whereas the ping and ARP methods only work on the local network, the decoy method works
everywhere.
Since so many protocols allow "plain text" passwords, and hackers
run sifters looking for those passwords, the decoy method simply satisfies that need. It
consists simply of setting up a client and a serve on either side of the network, which
the client runs a script to logon to the server using Telnet, POP, IMAP, or some other
plain-text protocol. The server is configured with special accounts that have no real
rights, or the server is completely virtual (in which case, the accounts don't really
exist).
Once a hacker sifts the usernames/passwords from the wire, he/she will then attempt to
log on using this information. Standard intrusion detection systems or audit trails can be
configured to log this occurance, alerting the fact that a sniffing hacker has found the
traffic and attempted to use the information.
http://www.zurich.ibm.com/~dac/Prog_RAID98/Full_Papers/sniffer_detector.html/index.htm
host method
- When hackers break into your systems, they will often leave behind wiretap programs
running in the background in order to sniff passwords and user accounts off the wire.
These are often imbedded (as a trojan) in other programs, so the only way to find if
something like this is running is to query the interfaces to see if they are running in
promiscuous mode.
The most technique is to run the program "ifconfig -a". On
my computer (Solaris 2.6) the output looks like:
# ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,MULTICAST> mtu 1500
inet 192.0.2.99 netmask ffffff00 broadcast 192.0.2.255
ether 8:0:20:9c:a2:98
Of course, the first thing a hacker will do is replace the 'ifconfig' program to hide
this. There are other utilities you can download from the net that will query the hardware
directly in order to discover this information, or you could run the 'ifconfig' program
directly from a CD-ROM distribution.
latency method
- This is a more evil method. On one hand, it can significantly degrade network
performance. On the other hand, it can 'blind' packet sniffers by sending too much
traffic.
This method functions by sending huge quantities of network traffic on the
wire. This has no effect on non-promiscuous machines, but has a huge effect on sniffing
machines, especially those parsing application layer protocols for passwords. Simply ping
the machine before the load and during the load and testing the difference in response
time can indicate if the machine is under load.
One problem with this technique is that packets can be delayed simply because of the
load on the wire, which may case timeouts and therefore false positives. On the other
hand, many sniffing programs are "user mode" whereas pings are responded to in
"kernel mode", and are therefore independent of CPU load on a machine, thereby
causing false negatives.
TDR (Time-Domain Reflectometers)
- A TDR is basically RADAR for the wire. It sends a pulse down the wire, then graphs the
reflections that come back. An expert can look at the graph of the response and figure out
if any devices are attached to the wire that shouldn't be. They also roughly tell where,
in terms of distance along the wire, the tap is located.
This can detect hardware
packet sniffers that might be attached to the wire, but which are completely silent
otherwise.
TDRs used to be used a lot in the old days of coax Ethernet in order to detect vampire
taps, but these days with star topologies, they are used very rarely.
There also exist OTDR equipment, but this is really only for the truely paranoid.
hub lights
- You can manually check hub-lights to see if there are any connections you don't expect.
It helps to have labeled cables to figure out where (physically) a packet sniffer might be
located.
SNMP monitoring
- Smart hubs with SNMP management can provide automated monitroning of Ethernet (and
other) hubs. Some management consoles will even let you log connections/disconnections to
all your ports. If you've configured the system with the information where all the cables
terminate, you can sometimes track down where a packet sniffer might be hiding.
Tools to detect packet sniffers
- AntiSniff
- http://www.l0pht.com/antisniff/
The
most comprehensive sniffer-detection tool.
- CPM (Check Promiscuous Mode)
- ftp://coast.cs.purdue.edu/pub/tools/unix/cpm/
A tool from Carnegie-Mellon that checks to see if promiscuous mode is enabled on a UNIX
machine.
- neped
- http://www.apostols.org/projectz/neped/
A tool from The Apostols that detects packet sniffers running on the local segment.
- sentinel
- http://www.packetfactory.net/Projects/sentinel/
Other Sniffing Detection Resources
http://www.securiteam.com/unixfocus/Detecting_sniffers_on_your_network.html
|