Managing ARP packets

[Mrkvonic]

Hi,

A few questions, mainly for Stem:

In order to secure and monitor DHCP server / clients on a network mainly against hostname/MAC spoofing, I'm familiar with the following methods:

DHCP snooping, on a switch level (Cisco etc); expensive but good.
ebtables, a firewall a la iptables capable of inspecting layer 2 (ethernet frames); not easy to setup.
arpwatch, for monitoring ip/mac pairs; requires human touch.

I know that iptables or any layer 3 firewall won't work in managing ARP packets, as they run on a layer below.

So, my question is:
Do you know of any other method save the above?
Static ARP assignments work, but only for known clients; what about rogues?
What other way can ARP packets be logged / processed?

Cheers,
Mrk

[Pedro]

Hello Mrk, there's also arptables.
I don't know much about ARP, and what can arptables do and not do against all attacks, but it does filter ARP on the host, same rules logic as iptables.

[Mrkvonic]

Hello,

I was talking about tools for the server. How to detect presence of a rogue server / client on the network. Of course, if you use iptables to allow only udp 67/68 for clients to their specific dhcp server, then the presence of rogue server is not a threat.

But the rogue dhcp server can still go up and be used to steal all those clients without firewall rules or mobile clients (like laptops).

Furthermore, it does not prevent packet sniffing.

The same thing regarding rogue clients. It is possible to use host and pool declarations, combined with the allow, deny statements to limit access, but what if a rogue client manages to successfuly flasify both the host name and the mac address? The server would be none the wiser.

Therefore, I'm asking for entry-level, server-side tool / strategy that would identify these rogues the moment they start broadcasting and isolate them.

It is a difficult question I don't have a smart answer yet. Except the ones I already listed, but they don't feel right ... :)

I know there's dhcp authentication, but it's still not fully implemented, but that sounds like a nice idea.

Anything else?

Mrk

[Mrkvonic]

Hello,
No takers :( ?
Me alone piloting SSN Mrkvonizator??
Mrk

[Pedro]

I'll just bump it once. This is a thread (http://www.authsecu.com/nntp/comp-os-linux-security/31302-comp-os-linux-security-any-reasons-to-filter-arp-packets.htm#31302) mainly for a host, but perhaps it will serve you some good.
There's one poster that brings some light into the matter, Ertugrul Soeylemez, but doesn't elaborate more on what you really want Mrk.
I fear you already know what they're saying.
{QUOTE-> Well, the ARP filter has a very good reason to be. It's ARP poisoning.
This is an attack, which allows you to redirect network traffic as you
like, if the network is not protected against it. This is the case,
when the hosts in the network use dynamic ARP tables.

Now whether you really need the ARP filter depends on the operating
systems used. Given you have operating systems, where static ARP
entries cannot be changed remotely (i.e. not Windows), there is no
reason for ARP filtering. If you don't use static ARP entries, then you
are going to need ARP anyway, so you can't filter it effectively. If
you do, then you don't need it at all.

However, if there is even a single Windows machine in the network, then
I strongly recommend setting up static ARP tables on that host and
filtering any ARP packets from it. Windows allows static ARP entries,
but they are only static in terms of they don't have any timeout and
they (should) survice reboots. They can be overridden remotely.
Unfortunately, Windows doesn't have any ARP filter.

In all cases, use static ARP tables, if possible, to prevent ARP
poisoning. This attack is worse than ARP flooding, because it allows
for MITM attacks easily. Several command line utilities are available
to take over SSH connections and the like.

A much better setup would be one, where you don't rely on consistent ARP
tables at all. For example, use key-based authentication, if possible.
This makes ARP poisoning useless, because there is no MITM attack
against key-based authentication protocols. <-QUOTE}
{QUOTE-> 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. <-QUOTE}