Network Security Hacks [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Network Security Hacks [Electronic resources] - نسخه متنی

Andrew Lockhart

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Hack 49 Detect Ethernet Sniffers Remotely

Detect potential spies on your network without
having to trust compromised machines.

Ethernet sniffers are one of the most
powerful tools in your network security arsenal. However, in the
wrong hands they can be one of the biggest threats to the security of
your network. It may be an insider or it could be a malicious
intruder, but, nevertheless, once a system has been detected they
will most likely begin sniffing the local network. This network
reconnaissance will help these
"spies" find their next target, or
simply collect juicy bits of information (such as usernames and
passwords, email, or other sensitive data).

Not too long ago, it was commonly thought that only
shared-medium Ethernet networks were
vulnerable to being sniffed. These networks employed a central hub,
which would rebroadcast every transmitted packet to each port on the
hub. In this type of setup, every frame sent by any network node is
received by every other node on the local network segment. Each
node's network interface then performs a quick check
to see if it is the node that the frame is destined for. If it is
not, the frame is discarded. If it is, the frame is passed up through
the operating system's protocol stack and is
eventually processed by an application. Because of this, sniffing
other systems' traffic on the network was trivial.
After all, since all the traffic was reaching each system, one only
needed to disable the check that the network interface performs, and
the system would have access to the traffic meant for others. This is
usually referred to as putting the network interface into
promiscuous
mode, which usually can be done only by a privileged
user.

Eventually, switched Ethernet networks became prevalent and the
shared-medium aspect no longer applied. Thus, the main facilitator of
sniffing was removed. Unlike hubs, Ethernet switches will only send
traffic to the device that it is destined for. To do this, an
Ethernet switch learns which network device's MAC
address corresponds to what port on the switch as traffic passes
through the switch. When the switch sees an Ethernet frame with a
certain destination MAC address, it will look up which
port on the switch corresponds to it and forward the frame to only
that port. In doing this, the switch effectively creates a virtual
dedicated connection from the sending station to the receiving
station every time an Ethernet frame is transmitted on the network.
Thus, only the machine that the frame was originally intended for is
able to see it. This would be fine, but certain aspects of the
Ethernet specification and the TCP/IP can cause problems.

One problem is that switches can memorize only a limited number of
MAC addresses. The maximum number will often be several orders of
magnitude higher than the number of ports that the switch has, which
allows switches to be connected to each other hierarchically. In
order to do this efficiently, each switch must memorize the MAC
addresses available on the switches to which it is connected. For
example, suppose you have a 24-port switch (switch A) with 23
machines plugged into it, and the 24th
port is occupied by another switch. This other switch (switch B) has
48 ports, with the 47 other ports being occupied by machines. In this
situation, switch A will learn the MAC addresses of the 47 systems on
switch B and associate it with its 24th
port, and switch B will learn the MAC addresses of the 23 systems
connected directly to switch A and associate it with its own
48th port. Even though the average switch
can memorize upwards of several thousand MAC addresses, it is still
possible to overflow the switch's MAC address table
by generating large amounts of traffic with fake MAC addresses. This
tactic is desirable for a malicious user because many switches will
revert to behaving like a hub once their MAC address tables have been
filled. Once this happens, the network is no different than a
shared-medium segment using a hub. A malicious user will then be able
to sniff the network by simply putting her network interface into
promiscuous mode.

Luckily this approach is fairly invasivein order for it to
work, the network will need to be flooded with bogus traffic, which
is something that can be detected passively with tools such
[Hack #31] .
A flood of bogus MAC and IP address pairings would cause Arpwatch to
likewise flood your system logs. As long as you're
good about monitoring your logs, this attack should be fairly easy to
spot. As mentioned in [Hack #31],
Arpwatch is also capable of detecting ARP table poisoning. That makes
it an effective tool for detecting the two most common types of ARP
attacks that are usually precursors to data logging: ARP flooding and
targeted ARP poisoning.

Another way to monitor switched networks is to simply change the MAC
address of the Ethernet card in the system that is going to be used
for sniffing. In Linux and many other Unix and Unix-like operating
systems, this can be done with the
ifconfig command:

# /sbin/ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:E0:81:03:D8:8F
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:11 Base address:0x1c80
# /sbin/ifconfig eth0 hw ether 00:DE:AD:BE:EF:00
# /sbin/ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:DE:AD:BE:EF:00
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:11 Base address:0x1c80

The purpose of doing this is to trick the switch into forwarding the
traffic to two different nodes on the segment. This is sometimes a
hit-or-miss deal, since different switches will behave differently
when there are duplicate MAC addresses in use on the same network.
The switch may forward traffic to both ports, distribute the traffic
unpredictably between them, stop passing traffic altogether, or raise
an error. All of these methods can be detected and stopped with more
expensive managed switches, which allow you to specify what MAC
addresses are allowed on each individual port. This feature is
sometimes called port security.

However, even if attackers choose not to employ these methods, they
can still gather quite a bit of information by just putting the
network interface into promiscuous mode. For example,
broadcast traffic such as DHCP and ARP requests will still be sent to
every port on the switch. This traffic is not as easy to detect,
unless you already have the infrastructure in place to do so.

One tool that can help to detect promiscuous interfaces on both
switched and unswitched networks is
sniffdet (http://sniffdet.sourceforge.net). For a tool
that really only serves a single purpose,
sniffdet is fairly versatile, as it can detect sniffers in
several ways. The main difference between sniffdet
and a tool like Arpwatch is that sniffdet
actively scans for sniffers. That is, if you suspect that
a machine may be running a sniffer, you can simply run
sniffdet and point it at that machine to
determine whether its network device is in promiscuous mode.

To build and install sniffdet, you will first
have to obtain the libnet packet injection library
(http://www.packetfactory.net/projects/libnet/).
Make sure to download the latest 1.0.x versionthe 1.1 versions
of libnet are incompatible with programs written for the 1.0.x
versions.

To compile libnet, unpack the source distribution and go into the
directory that it creates. Then run this command:

$ ./configure && make

After it has finished compiling, become root and type make
install
.

Building sniffdet is a similar affair. Like
libnet, you will need to unpack the source distribution and change to
the directory that it creates. Then, to build and install it, do the
same thing you did for libnet.

sniffdet has several methods for determining
whether a target machine is running a sniffer. However, only two of
the methods that it employs will work with repeatable and predictable
results. These are the ARP and DNS tests.

The ARP test relies on how the sniffing
system's protocol stack deals with ARP queries while
in promiscuous mode. When running this test against a target machine,
sniffdet will send out an ARP query to the
target machine. This request has
fake source and destination MAC addresses but uses the correct IP
addresses of the machine being checked. If the target machine is in
promiscuous mode, the ARP query with the fake MAC address will be
passed up the protocol stack, and the target machine will send a
reply. If the machine is not in promiscuous mode, this ARP query will
be quietly discarded. This method is
effective on both switched and unswitched networks.

Let's look at a sniffdet scan
against sirius (192.168.0.2) from
colossus (192.168.0.64), two machines that are on
the same switched network.

Here are the results of running sniffdet against
sirius:

colossus # sniffdet -i eth0 -t arp sirius
------------------------------------------------------------
Sniffdet Report
Generated on: Wed Dec 31 03:49:28 2003
------------------------------------------------------------
Tests Results for target sirius
------------------------------------------------------------
Test: ARP Test (single host)
Check if target replies a bogus ARP request (with wrong MAC)
Validation: OK
Started on: Wed Dec 31 03:49:08 2003
Finished on: Wed Dec 31 03:49:28 2003
Bytes Sent: 252
Bytes Received: 0
Packets Sent: 6
Packets Received: 0
------------------------------------------------------------
RESULT: NEGATIVE
------------------------------------------------------------
------------------------------------------------------------
Number of valid tests: #1
Number of tests with positive result: #0
------------------------------------------------------------

Now start a sniffer on sirius and run the scan
again:

sirius # tcpdump -i le0 arp
tcpdump: listening on le0
06:58:00.458836 arp who-has sirius.nnc tell colossus.nnc
06:58:00.458952 arp reply sirius.nnc is-at 8:0:20:81:a4:a3
06:58:00.466601 arp who-has sirius.nnc (ff:0:0:0:0:0) tell colossus.nnc
06:58:00.466928 arp reply sirius.nnc is-at 8:0:20:81:a4:a3

Let's look at the results of the scan:

------------------------------------------------------------
Sniffdet Report
Generated on: Wed Dec 31 06:58:01 2003
------------------------------------------------------------
Tests Results for target sirius
------------------------------------------------------------
Test: ARP Test (single host)
Check if target replies a bogus ARP request (with wrong MAC)
Validation: OK
Started on: Wed Dec 31 06:58:00 2003
Finished on: Wed Dec 31 06:58:01 2003
Bytes Sent: 84
Bytes Received: 60
Packets Sent: 2
Packets Received: 1
------------------------------------------------------------
RESULT: POSITIVE
------------------------------------------------------------
------------------------------------------------------------
Number of valid tests: #1
Number of tests with positive result: #1
------------------------------------------------------------

The
DNS test works very well, particularly on
shared-medium networks such as hubs or wireless LANs. However, it
does rely on name resolution being enabled in the sniffer. When
performing DNS tests, sniffdet will send bogus
packets that contain IP addresses that are not in use on the local
network segment. If name resolution is enabled, the sniffer will
attempt to do a reverse lookup in order to determine the hostname
that corresponds to the IP addresses. Since these addresses are not
in use, sniffdet will determine that the target
machine is in promiscuous mode when it sees the DNS queries.

This test can be performed just as the ARP test, but instead of
using -t arp,
use -t dns.


/ 158