Any reasons to filter ARP packets? - comp.os.linux.security

Message from discussion Any reasons to filter ARP packets?

Ertugrul Soeylemez

View profile

More options Apr 1 2006, 8:19 am

Newsgroups: comp.os.linux.security

From: Ertugrul Soeylemez <ne...@drwxr-xr-x.org>

Date: Sat, 1 Apr 2006 15:19:50 +0200

Local: Sat, Apr 1 2006 8:19 am

Subject: Re: Any reasons to filter ARP packets?

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

"Mikhail Zotov" <mux...@lenta.ru> (06-03-31 04:08:46):

> First, thank you for the comprehensive explanation of the subject. I
> think, it can make a good article on securityfocus or a similar
> site. I wonder why this topic isn't covered in any popular security
> HOWTO.

There are lots of good papers covering this topic. My favorite one can
be found at <http://www.arp-sk.org/>, including experimental command
line utilities for both ARP poisoning and MITM attacks. Unfortunately,
this site seems to be down at the moment. Maybe I will write some kind
of paper about that topic.

> > 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).

> Does this mean in particular that the ISP can decrypt almost any
> encrypted traffic of us, its clients?

Exactly. But if your ISP did this more often, then sooner or later, you
were going to detect it, at least when comparing key fingerprints by
hand.

You can overcome that problem by using key-based authentication, where
no MITM attack is possible.

> > 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.

> Do you mean a sysctl setting? I didn't find a suitable one.

If there is no particular sysctl setting, then you might have to change
some headers in the kernel source. I have not done this myself, because
we have other means securing the network here.

> > The other way is not to use ARP and MAC addressing at all,
> > effectively turning your interface to a broadcast interface.

> I am afraid this is impossible in my case because the ISP relates IP
> addresses of its client machines to their MAC addresses. In other
> words, I expect I won't be able to use the connection if I turn off
> MAC addressing. Anyway, it seems worth trying. :-)

Maybe your ISP is going to do this via ARP. ;)

Regards.

Reply to author Forward