Re: Any reasons to filter ARP packets?
- From: Ertugrul Soeylemez <never@xxxxxxxxxxxxxx>
- Date: Thu, 30 Mar 2006 11:51:08 +0200
"Mikhail Zotov" <muxaul@xxxxxxxx> (06-03-29 09:16:56):
My home Linux machine is connected to a big LAN, which consists of
hundreds and maybe even thousands machines. All machines have IP
addresses from the 10/8 pool. I am running a simple iptables firewall
on my machine but it is useless most of the time because there seems
to be very little threat from (mostly Windows) machines in the LAN.
Packets blocked by the firewall are, as a rule, just Windoops noise.
If I observe probes of different ports on my machine I just call the
ISP and the problem is solved.
At the same time, the network device is open for ARP packets since
filtering of ARP packets is not supported by netfilter. Thus I wanted
to understand whether ARP packets can be used to put anything to my
machine (say, spyware) or get anything from it or just get any type of
access to it. According to the docs I have found so far, this is
impossible because ARP packets don't have place for anything "useful".
By posting my question, I wanted to make sure that my understanding is
correct.
Yes, this is correct. The ARP intentionally doesn't leave any space for
payloads in the packet. However, as every network packet, an ARP packet
has a 'size' field, which can well be set larger than the packet itself
really is. So, you _can_ transmit payload with ARP packets, but they
get just ignored (as long as there isn't some special purpose
application, or some classic network stack bug).
Now to the ARP itself. There are mainly two kinds of attacks via ARP.
They can be launched in every switched ethernet (very likely you are in
one of them). They are called ARP flooding and ARP poisoning.
ARP flooding: As you know, the ARP is used to resolve IP addresses into
MAC addresses. All network hosts and the switch itself keep track of an
internal ARP table containing such resolutions, which have already taken
place. The size of this internal table is limited. Most switches
switch to a hub-like mode, when it gets overflown. This allows an
attacker to easily intercept _any_ traffic in the network.
ARP poisoning: Essentially the goal of this attack is similar, but the
method is quite different. You can always send arbitrarily constructed
ARP packets, and other hosts in the network will honour them. So with
forged ARP packets, you can redirect network traffic to other machines
and let them act as routers. This allows the interception attack
mentioned above, too, but also a few other attacks. By redirecting
network traffic intended for the internet gateway to a non-existent
machine, you can isolate it completely, making internet access
impossible (for a short period of time, until the ARP entries expire).
You can also redirect traffic for other hosts to your machine, and then
act as a router to send them to the real destination.
The latter method allows an attack, which is called the 'man in the
middle' (MITM) attack. With this one, you can not only intercept
network traffic, but even manipulate it. As a funny attack, you could
intercept a chat session and also write forged messages for your victim,
without him noticing this. Now, there is a much more serious MITM
attack. If not set up properly (i.e. in the default configuration), you
can decrypt almost _any_ encrypted connection. Yes, this includes
SSH/SSL connections, so you can very well get access to remote machines
(via SSH) or steal credit card information (via SSL, e.g. via HTTPS).
In other words: The insecurity of the ARP protocol is a major threat in
every switched ethernet. You can overcome this problem by using static
ARP tables. If you use static ARP tables on your host, then outgoing
traffic cannot be intercepted or manipulated anymore. Incoming traffic
from a host using dynamic ARP tables, however, can be. And there is a
case, where static ARP tables are even not possible: When the hosts
have dynamic IP addresses.
There are two ways to defend yourself (but not others) against ARP
poisoning, so that _your_ traffic cannot be intercepted. Don't rely on
the expiration time of ARP entries. You could lower it. Luckily, when
an MITM attack gets out of synchronization (i.e. not _all_ packets get
caught by the attacker), then it is lost in most cases. This way, you
can force a desynchronization sooner or later, and detect the attack.
Secondly, add a static ARP entry for 'important' hosts like the router.
They are going to have static addresses in most cases.
The other way is not to use ARP and MAC addressing at all, effectively
turning your interface to a broadcast interface. That will increase
network traffic, and you can't defend yourself against interception with
this. But it makes an MITM attack impossible. You can turn MAC
addressing on and off, so I recommend doing this for the setup phase of
encrypted connections. After the connection is established, you can
return to normal behaviour.
Regards.
.
- Follow-Ups:
- Re: Any reasons to filter ARP packets?
- From: Mikhail Zotov
- Re: Any reasons to filter ARP packets?
- References:
- Any reasons to filter ARP packets?
- From: Mikhail Zotov
- Re: Any reasons to filter ARP packets?
- From: Mikhail Zotov
- Any reasons to filter ARP packets?
- Prev by Date: Re: serial port permissions changing
- Next by Date: Re: Network Security - Monolithic or Modular?
- Previous by thread: Re: Any reasons to filter ARP packets?
- Next by thread: Re: Any reasons to filter ARP packets?
- Index(es):
Relevant Pages
|
