Any reasons to filter ARP packets? - Security

This is a discussion on Any reasons to filter ARP packets? - Security ; Hi, I have read a number of docs devoted to ARP packets and haven't seen a way they can do any harm to a machine (except for the case of arp flooding). Are there any reasons one would like to ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 31

Thread: Any reasons to filter ARP packets?

  1. Any reasons to filter ARP packets?

    Hi,

    I have read a number of docs devoted to ARP packets and haven't seen a
    way they can do any harm to a machine (except for the case of arp
    flooding). Are there any reasons one would like to filter ARP packets
    other than just hiding a machine from (a part of) its LAN neighbours?

    Thanks!

    Mikhail


  2. Re: Any reasons to filter ARP packets?

    Mikhail Zotov wrote:
    > I have read a number of docs devoted to ARP packets and haven't seen a
    > way they can do any harm to a machine (except for the case of arp
    > flooding). Are there any reasons one would like to filter ARP packets
    > other than just hiding a machine from (a part of) its LAN neighbours?


    I've seen setups with completely static ARP entries and arp
    filtering that drops everything from a certain interface.

    That way, you can counter some of the problems of publicly
    available network jacks.

    Regards,
    Tobias

    PS: Of course, for a comprehensive solution in this case, more
    needs to be done.

    --
    You don't need eyes to see, you need vision.

  3. Re: Any reasons to filter ARP packets?

    On 28 Mar 2006, in the Usenet newsgroup comp.os.linux.security, in article
    <1143553434.509660.271180@v46g2000cwv.googlegroups. com>, Mikhail Zotov wrote:

    >I have read a number of docs devoted to ARP packets and haven't seen a
    >way they can do any harm to a machine (except for the case of arp
    >flooding).


    There might be others, but it depends on your setup and your threat model.

    >Are there any reasons one would like to filter ARP packets other than
    >just hiding a machine from (a part of) its LAN neighbours?


    ARP filtering would not hid the system by itself. On broadcast media
    (coax, twisted pairs with hubs, wireless) all traffic is detectable
    anyway. On switched media, the switch has to know all, even if ARP
    is disabled, never mind filtered.

    Packets on Ethernet style networks (includes wireless) are moved using
    MAC addresses. Some O/S monitor traffic and complain if another host is
    detected using "my" MAC address. Look up "ARP spoofing".

    ARP is one of two methods used to translate between IP and MAC addresses.
    On a static network, you can disable ARP by using hard-coded data (ethers
    files), /sbin/arp -s, and /sbin/ifconfig -arp. This may or may not improve
    your security, but is usually a pain in the a$$ to set up and maintain.

    Hardware addresses (and IP itself) is only as secure as your control of
    access to the network, though encryption helps quite a bit. If you are
    concerned about attack mechanisms using ARP or hardware addresses, you
    need to be looking at other problems as well.

    Old guy

  4. Re: Any reasons to filter ARP packets?

    "Mikhail Zotov" (06-03-28 05:43:54):

    > I have read a number of docs devoted to ARP packets and haven't seen a
    > way they can do any harm to a machine (except for the case of arp
    > flooding). Are there any reasons one would like to filter ARP packets
    > other than just hiding a machine from (a part of) its LAN neighbours?


    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.


    Regards.

  5. Re: Any reasons to filter ARP packets?

    Mikhail Zotov wrote:
    > I have read a number of docs devoted to ARP packets and haven't seen a
    > way they can do any harm to a machine (except for the case of arp
    > flooding). Are there any reasons one would like to filter ARP packets
    > other than just hiding a machine from (a part of) its LAN neighbours?


    Gentlemen, I am posting a reply to the post of my own because this is a
    reply to all three posts of yours.

    First of all, thank you for the enlightening answers.

    Let me explain the motivation for my question. This will hopefully
    clarify what I am worrying about.

    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.

    Thanks again for the replies!

    Mikhail


  6. Re: Any reasons to filter ARP packets?

    "Mikhail Zotov" (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.

  7. Re: Any reasons to filter ARP packets?

    Ertugrul Soeylemez wrote:

    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.

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


    Yes, this is the case.

    > They are called ARP flooding and ARP poisoning.


    [ ARP poisoning: ]
    > 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?

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

    > Secondly, add a static ARP entry for 'important' hosts like the router.
    > They are going to have static addresses in most cases.


    Thanks for the idea. Seems to be easy to implement (via arp and
    /etc/ethers).

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

    Regards,
    Mikhail


  8. Re: Any reasons to filter ARP packets?

    On Fri, 31 Mar 2006 04:08:46 -0800, Mikhail Zotov wrote:

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


    Yes.

  9. Re: Any reasons to filter ARP packets?

    "Mikhail Zotov" (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 , 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.

  10. Re: Any reasons to filter ARP packets?

    Ertugrul Soeylemez wrote:
    > "Mikhail Zotov" (06-03-31 04:08:46):
    >
    > > 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 , 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.


    It would be nice :-)
    ....
    > > 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.


    AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
    https, does it?

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


    I created /etc/ethers with MAC addresses of the gateway and a couple of
    other local hosts and added

    arp -f /etc/ethers -i $ext_device
    ifconfig $ext_device -arp

    to the script that starts the network interface. I have noticed no
    difference in operation thus far. In particular, iptables is still
    registering connection attempts. AFAIU, this means other hosts do have
    a way to get to know the MAC address of my network device, right?

    Thank you for the communication!

    Regards,
    Mikhail


  11. Re: Any reasons to filter ARP packets?

    On Sat, 01 Apr 2006 10:05:58 -0800, Mikhail Zotov wrote:
    > Ertugrul Soeylemez wrote:


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

    >
    > AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
    > https, does it?


    SSL/TLS uses pub/priv certificates instead (for service integraty some
    administrators could key the priv-cert for themselfs though) the
    difference between a key and certificate here being identification
    information is contained in the latter and not the former.

    Thus for autentication a cert should be as good as any key (assuming the
    same cipher was used to create them). The general problem is in getting
    the public key/cert to clients (you) savely, as an ISP could manipulate
    the exchange and MITM any session from there on.

    So unless you got the keys/certs via some trusted means...

    [...]
    > I created /etc/ethers with MAC addresses of the gateway and a couple of
    > other local hosts and added
    >
    > arp -f /etc/ethers -i $ext_device
    > ifconfig $ext_device -arp


    Maybe try also:
    ip link set dev $ext_device arp off

    > to the script that starts the network interface. I have noticed no
    > difference in operation thus far. In particular, iptables is still
    > registering connection attempts.


    Idunno, but maybe clear the cache (using the 'arp' command).

    Are they comming from the gateway MAC and out-site IP adresses? If so,
    that might be expected (how else did you post here). Anyways, you could
    try filtering using Netfilter like so:

    # Load needed module
    /sbin/modprobe ipt_mac

    # Set default policy
    /usr/sbin/iptables -P INPUT DROP

    # Allow connections from Media Access Controllers we know about only
    ETHERS=$(grep -v -e '^#' -e '^$' /etc/ethers |awk '{print $1}')
    for MAC in $ETHERS; do
    /usr/sbin/iptables -A INPUT -m mac --mac-source $MAC -j ACCEPT
    done

    (Not tested BTW).

    > AFAIU, this means other hosts do have a way to get to know the MAC
    > address of my network device, right?


    I'd think so, i'd play arround some with 'arping' and 'tcpdump'. (Even
    though i don't see security enhancement in disallowing others seeing you).

    I think some off the sysctl settings are tweakable too, look for arp in:
    /usr/src/linux/Documentation/networking/ip-sysctl.txt

    HTH

    --
    -Menno.


  12. Re: Any reasons to filter ARP packets?

    Hi Menno,

    The thread is becoming more and more interesting :-)

    Menno Duursma wrote:
    > On Sat, 01 Apr 2006 10:05:58 -0800, Mikhail Zotov wrote:
    > > Ertugrul Soeylemez wrote:

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

    > >
    > > AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
    > > https, does it?

    >
    > SSL/TLS uses pub/priv certificates instead (for service integraty some
    > administrators could key the priv-cert for themselfs though) the
    > difference between a key and certificate here being identification
    > information is contained in the latter and not the former.

    ...
    > So unless you got the keys/certs via some trusted means...


    Ah, I see. Thank you.

    > [...]
    > > I created /etc/ethers with MAC addresses of the gateway and a couple of
    > > other local hosts and added
    > >
    > > arp -f /etc/ethers -i $ext_device
    > > ifconfig $ext_device -arp

    >
    > Maybe try also:
    > ip link set dev $ext_device arp off
    >
    > > to the script that starts the network interface. I have noticed no
    > > difference in operation thus far. In particular, iptables is still
    > > registering connection attempts.

    >
    > I dunno, but maybe clear the cache (using the 'arp' command).
    >
    > Are they comming from the gateway MAC and out-site IP adresses? If so,
    > that might be expected (how else did you post here). Anyways, you could


    They are (were) coming from other hosts in the LAN. None of them
    is/was specified in /etc/ethers.

    As for the the cache, I thought it is cleared once an interface is
    down. At least,

    # arp -a

    doesn't show anything in this case. I was probably wrong. After I
    rebooted the machine, I don't observe any connection attempts any more.
    For already an hour now :-) Will be checking more.

    > Anyways, you could
    > try filtering using Netfilter like so:
    >
    > # Load needed module
    > /sbin/modprobe ipt_mac
    >
    > # Set default policy
    > /usr/sbin/iptables -P INPUT DROP
    >
    > # Allow connections from Media Access Controllers we know about only
    > ETHERS=$(grep -v -e '^#' -e '^$' /etc/ethers |awk '{print $1}')
    > for MAC in $ETHERS; do
    > /usr/sbin/iptables -A INPUT -m mac --mac-source $MAC -j ACCEPT
    > done


    I like the idea, thank you. The rules should probably be modified
    slightly because I am not going to ACCEPT all packets originating from
    ISP's router. ;-) Anyway, this gonna be an interesting excercise. :-)

    > > AFAIU, this means other hosts do have a way to get to know the MAC
    > > address of my network device, right?

    >
    > I'd think so, i'd play arround some with 'arping' and 'tcpdump'. (Even
    > though i don't see security enhancement in disallowing others seeing you).
    >
    > I think some off the sysctl settings are tweakable too, look for arp in:
    > /usr/src/linux/Documentation/networking/ip-sysctl.txt


    You can be sure I did :-)

    Thanks for the reply and the ideas!

    Regards,
    Mikhail


  13. Re: Any reasons to filter ARP packets?

    On Sat, 01 Apr 2006 22:34:16 -0800, Mikhail Zotov wrote:
    > Menno Duursma wrote:
    >> On Sat, 01 Apr 2006 10:05:58 -0800, Mikhail Zotov wrote:
    >> > Ertugrul Soeylemez wrote:


    [Snip: encription]

    Userfriendly programs (to test this) would be:
    http://monkey.org/~dugsong/dsniff/
    http://ettercap.sourceforge.net/

    Although a combination for small utilities is more flexible (and fun):
    http://www.phenoelit.de/arpoc/
    http://www.rtfm.com/ssldump/

    Also maybe read this bugtraq post, (and Ethereal dump that traffic):
    http://cert.uni-stuttgart.de/archive.../msg00261.html

    > I like the idea, thank you. The rules should probably be modified
    > slightly because I am not going to ACCEPT all packets originating from
    > ISP's router. ;-) Anyway, this gonna be an interesting excercise. :-)


    Maybe checkout the Arptables for some more filter options from here:
    http://prdownloads.sourceforge.net/e...0.0.3-2.tar.gz

    >> > AFAIU, this means other hosts do have a way to get to know the MAC
    >> > address of my network device, right?

    >>
    >> I'd think so, i'd play arround some with 'arping' and 'tcpdump'. (Even
    >> though i don't see security enhancement in disallowing others seeing you).
    >>
    >> I think some off the sysctl settings are tweakable too, look for arp in:
    >> /usr/src/linux/Documentation/networking/ip-sysctl.txt

    >
    > You can be sure I did :-)
    >
    > Thanks for the reply and the ideas!


    Sure thing. You may want to mess about the netwox in testing too:
    http://www.laurentconstantin.com/en/netw/

    Have fun.

    --
    -Menno.


  14. Re: Any reasons to filter ARP packets?

    "Mikhail Zotov" (06-04-01 10:05:58):

    > > There are lots of good papers covering this topic. My favorite one
    > > can be found at , 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.

    >
    > It would be nice :-)


    I've started working on one now. I hope, it's going to be useful.


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

    >
    > AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
    > https, does it?


    Theoretically yes. The client and server programs have to support it as
    well, though. The server always identifies itself with a certificate,
    but only few clients have the ability to identify themselves, too.

    Now, as Menno Duursma has pointed out, the big problem is the secure
    delivery of the keys/certificates to and from the particular servers.
    Unfortunately, many people (including server administrators) just don't
    care.


    > I created /etc/ethers with MAC addresses of the gateway and a couple
    > of other local hosts and added
    >
    > arp -f /etc/ethers -i $ext_device
    > ifconfig $ext_device -arp
    >
    > to the script that starts the network interface. I have noticed no
    > difference in operation thus far. In particular, iptables is still
    > registering connection attempts. AFAIU, this means other hosts do have
    > a way to get to know the MAC address of my network device, right?


    I guess, you got me wrong here. There is no problem about others
    determining your MAC address, because they are going to do so anyway, as
    long as you don't want to broadcast all packets to all hosts in the
    network. I meant, secure your communications properly, instead of
    relying on ARP filtering. In a network of the size of the one you're
    part of, it would be silly to filter out ARP packets anyway.

    Just add static ARP entries for 'important' hosts, like the router. By
    this, you can defend against MITM attacks for packets from you to the
    router (but not the other way), and sometimes this speeds up
    communication. But you don't gain any further security; especially you
    cannot defend against sniffing in a switched ethernet. The attacker
    always has the ability to do ARP flooding, effectively turning the
    switch into a broadcast device. There is nothing you could do about
    that.


    Regards.

  15. Re: Any reasons to filter ARP packets?

    Ertugrul Soeylemez wrote:
    > "Mikhail Zotov" (06-04-01 10:05:58):
    >
    > > > There are lots of good papers covering this topic. My favorite one

    ....
    > > > Unfortunately, this site seems to be down at the moment. Maybe I
    > > > will write some kind of paper about that topic.

    > >
    > > It would be nice :-)

    >
    > I've started working on one now. I hope, it's going to be useful.


    Great. I know a web-zine that will undoubtedly be glad to publish your
    article:

    http://slackworld.berlios.de/

    It's next issue is in work right now :-)

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

    > >
    > > AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
    > > https, does it?

    >
    > Theoretically yes. The client and server programs have to support it as
    > well, though. The server always identifies itself with a certificate,
    > but only few clients have the ability to identify themselves, too.


    Ah, I see.

    > > I created /etc/ethers with MAC addresses of the gateway and a couple
    > > of other local hosts and added
    > >
    > > arp -f /etc/ethers -i $ext_device
    > > ifconfig $ext_device -arp
    > >
    > > to the script that starts the network interface. I have noticed no
    > > difference in operation thus far. In particular, iptables is still
    > > registering connection attempts. AFAIU, this means other hosts do have
    > > a way to get to know the MAC address of my network device, right?

    >
    > I guess, you got me wrong here. There is no problem about others
    > determining your MAC address, because they are going to do so anyway, as
    > long as you don't want to broadcast all packets to all hosts in the
    > network.


    I've been observing further how these settings influence operation and
    found that "ifconfig device -arp" seems to disable replies about the
    MAC address of the network device. With this setting, I do only
    observe probes originating from a couple of hosts that are likely to
    belong to the ISP. As a drawback, my friends have lost the possibility
    to connect to my machine. Their machines are running windoops and I
    don't know how to tell windoops about the MAC address of my machine. No
    other problems with operation are observed thus far.

    > Just add static ARP entries for 'important' hosts, like the router.


    Yes, I did this. Put them in /etc/ethers. Still I'm going to try
    arpfilter as suggested by Menno Duursma. It seems arpfilter can solve
    the problem with connections originating from a few "friendly" hosts.

    > By this, you can defend against MITM attacks for packets from you to the
    > router (but not the other way), and sometimes this speeds up
    > communication. But you don't gain any further security; especially you
    > cannot defend against sniffing in a switched ethernet. The attacker
    > always has the ability to do ARP flooding, effectively turning the
    > switch into a broadcast device. There is nothing you could do about
    > that.


    Thus one can sniff traffic of whole districts with hundreds of thousand
    people living there. :-(

    Thank you for the communication!

    Mikhail


  16. Re: Any reasons to filter ARP packets?

    On Mon, 03 Apr 2006 23:21:49 -0700, Mikhail Zotov wrote:

    > Ertugrul Soeylemez wrote:
    >> "Mikhail Zotov" (06-04-01 10:05:58):
    >>[...]

    > Thank you for the communication!
    >
    > Mikhail


    He did you right.
    Smart, friendly, informative man.

    You should archive this thread, not just for its content, but as an
    premier example of what what a helpful, knowledgeable thread should look
    like.

    What a nice man, with a strange-sounding (to [parochial] me) name to have
    given such good information. And you, too Mikhail Zotov asked highly
    intelligent questions and understood answers so well.

    As a "low-level" protocol, ARP will always be important to security. As
    more areas (did I recently see Macedonia [name?] and areas of the NW USA
    in the news?) try to adopt wide area wireless access, these exact issues
    will become even more important to thousands and millions of users.

    You both did well. I enjoyed reading your posts. I wish you both well.
    I hope to read some more from you. Both.

    Thanks

    Write some more if you choose.

  17. Re: Any reasons to filter ARP packets?

    "Mikhail Zotov" (06-04-03 23:21:49):

    > > I've started working on one now. I hope, it's going to be useful.

    >
    > Great. I know a web-zine that will undoubtedly be glad to publish
    > your article:
    >
    > http://slackworld.berlios.de/
    >
    > It's next issue is in work right now :-)


    Great information. Thank you. =)


    > > I guess, you got me wrong here. There is no problem about others
    > > determining your MAC address, because they are going to do so
    > > anyway, as long as you don't want to broadcast all packets to all
    > > hosts in the network.

    >
    > I've been observing further how these settings influence operation and
    > found that "ifconfig device -arp" seems to disable replies about the
    > MAC address of the network device. With this setting, I do only
    > observe probes originating from a couple of hosts that are likely to
    > belong to the ISP. As a drawback, my friends have lost the
    > possibility to connect to my machine. Their machines are running
    > windoops and I don't know how to tell windoops about the MAC address
    > of my machine. No other problems with operation are observed thus far.


    I would just leave all ARP replies enabled. You still can add static
    ARP entries for your friends, but there is really no need to disable ARP
    replies for other machines, unless you would like to completely suppress
    communication between you and those hosts. But even then, there are
    much better means of filtering, because ARP filtering cannot prevent
    communication. It is easy for someone to get to your MAC address.

    The very big problem about Windows users is that they effectively cannot
    use static ARP entries. On Windows, a 'static' entry is static in terms
    of surviving a reboot. You can still override it with forged ARP
    replies to that machine. This is something, I have already tested in a
    medium-scale office network. The attack works against every NT version
    of Windows (NT, 2000, XP, 2003). I didn't have the opportunity to test
    it against 95-based Windows versions (95, 98, ME).

    So I have to repeat: Forget ARP filtering; secure your connections
    otherwise, using cryptographic techniques. To prevent sniffing, you
    need encryption. To prevent MITM attacks (which include sniffing), you
    need proper authentication (i.e. key/certificate-based). In other
    words: You need both. Personally I don't use certificates, because
    they are effectively the same as keys, but unlike keys they include
    identity information. There is nothing bad about that, but using keys
    is simpler, and more widely supported (example: SSH cannot handle
    certificates).


    > > Just add static ARP entries for 'important' hosts, like the router.

    >
    > Yes, I did this. Put them in /etc/ethers. Still I'm going to try
    > arpfilter as suggested by Menno Duursma. It seems arpfilter can solve
    > the problem with connections originating from a few "friendly" hosts.


    If it works for you, then it's good and might provide a further layer of
    security by obscurity, making some attacks harder, though not
    impossible. But please remember the above fact that in Windows, there
    are no 'static' ARP entries. An attacker is always able to be the MITM
    (man in the middle) for one side of the communication. You are going to
    use cryptography anyway, making the arpfilter useless.


    > > By this, you can defend against MITM attacks for packets from you to
    > > the router (but not the other way), and sometimes this speeds up
    > > communication. But you don't gain any further security; especially
    > > you cannot defend against sniffing in a switched ethernet. The
    > > attacker always has the ability to do ARP flooding, effectively
    > > turning the switch into a broadcast device. There is nothing you
    > > could do about that.

    >
    > Thus one can sniff traffic of whole districts with hundreds of
    > thousand people living there. :-(


    As long as they are directly connected by some kind of network. This is
    a very old issue. Virtually anyone sitting in front of the
    administration panel of an internet router can sniff all traffic going
    through it. Again, this is old.

    The very big problem about switched ethernet networks is the way hosts
    distribute their MAC addresses. This makes one further and much more
    dangerous attack possible: the MITM attack. That goes beyond sniffing
    and allows to even break and intercept encrypted connections, and/or
    inject forged packets into them.

    The only way to defend against the MITM is key- or cert-based
    authentication. Just to encrypt everything is not enough. And you need
    some secure channel to distribute your key. It's best to meet your
    friends personally and give them a floppy disk. Do not distribute your
    key via internet, because the MITM is waiting there.


    Regards.

  18. Re: Any reasons to filter ARP packets?

    Newsbox (06-04-04 03:18:47):

    > He did you right.
    > Smart, friendly, informative man.
    >
    > You should archive this thread, not just for its content, but as an
    > premier example of what what a helpful, knowledgeable thread should look
    > like.
    >
    > What a nice man, with a strange-sounding (to [parochial] me) name to
    > have given such good information. And you, too Mikhail Zotov asked
    > highly intelligent questions and understood answers so well.


    I guess, you mean me. I live in Germany, but the name is Turkish. I
    don't like it, though. =)


    > As a "low-level" protocol, ARP will always be important to security.
    > As more areas (did I recently see Macedonia [name?] and areas of the
    > NW USA in the news?) try to adopt wide area wireless access, these
    > exact issues will become even more important to thousands and millions
    > of users.


    Proper understanding about everything you use has always been important.
    It is no computer technology or networking issue. To use a saw properly
    you need to understand, how and why it works. Unfortunately, that's
    something most people miss.


    > You both did well. I enjoyed reading your posts. I wish you both
    > well. I hope to read some more from you. Both.


    Thank you. On the other hand, I hope the informations were useful to
    everyone, not only to Mikhail. One reason for me to switch from forums
    to the Usenet was that it's much older and there are much less trolls,
    as well as much more knowledgable people.


    Regards.

  19. Re: Any reasons to filter ARP packets?

    On Tue, 04 Apr 2006 15:00:18 +0200, Ertugrul Soeylemez wrote:
    > "Mikhail Zotov" (06-04-03 23:21:49):


    > The very big problem about Windows users is that they effectively cannot
    > use static ARP entries. On Windows, a 'static' entry is static in terms
    > of surviving a reboot.


    No its not, its 'static' in that it doesn't time-out.

    > You can still override it with forged ARP replies to that machine. This
    > is something, I have already tested in a medium-scale office network.
    > The attack works against every NT version of Windows (NT, 2000, XP,
    > 2003).


    Right... Make that every NT version of MS-Windows up until XP/2003 ? :
    http://seclists.org/lists/vuln-dev/2003/Feb/0032.html

    > I didn't have the opportunity to test it against 95-based Windows
    > versions (95, 98, ME).


    Neither did i (or care to), presumably they acts as NT4 though.

    > So I have to repeat: Forget ARP filtering; secure your connections
    > otherwise, using cryptographic techniques.


    I'd say: don't put all your eggs in one bucket...
    (It sure would be a _great_ improvement if providers DNSSEC thier zones.)

    > To prevent sniffing, you need encryption. To prevent MITM attacks
    > (which include sniffing), you need proper authentication (i.e.
    > key/certificate-based).


    No to prevent MITM, you just need to ensure connection integrity. To make
    sniffing ineffective use encryption. (Autentication is basically just
    identification integrity checking).

    > In other words: You need both. Personally I don't use certificates,
    > because they are effectively the same as keys, but unlike keys they
    > include identity information. There is nothing bad about that, but
    > using keys is simpler, and more widely supported


    I'd think this the other way around (think: HTTPS, IMAPS, FTPS, etc.)

    > (example: SSH cannot handle certificates).


    Sure it can. Probably you mean the OpenSSH implementation doesn't ship
    with support... Well, it can be patched with that:
    http://roumenpetrov.info/openssh/

    >> > Just add static ARP entries for 'important' hosts, like the router.

    >>
    >> Yes, I did this. Put them in /etc/ethers. Still I'm going to try
    >> arpfilter as suggested by Menno Duursma. It seems arpfilter can solve
    >> the problem with connections originating from a few "friendly" hosts.

    >
    > If it works for you, then it's good and might provide a further layer of
    > security by obscurity, making some attacks harder, though not impossible.


    ???

    [...]

    > Just to encrypt everything is not enough. And you need some secure
    > channel to distribute your key. It's best to meet your friends
    > personally and give them a floppy disk. Do not distribute your key via
    > internet, because the MITM is waiting there.


    IME this utterly sucks when traveling (what makes SSH so usefull is the
    'access your boxen from the road' option). Now password autentication
    though can be farly secure whist utilizing something like Kerberos.
    (However one may consider it overkill to configure a KDC for but a few
    Telnet/SSH sessions).

    SRP might be a rather nice solution to this though:
    http://srp.stanford.edu/

    Only (free) SSH server that i know supports it is LSH (v2.0.2):
    http://www.lysator.liu.se/~nisse/archive/

    --
    -Menno.


  20. Re: Any reasons to filter ARP packets?

    Menno Duursma (06-04-05 11:03:14):

    > > The very big problem about Windows users is that they effectively
    > > cannot use static ARP entries. On Windows, a 'static' entry is
    > > static in terms of surviving a reboot.

    >
    > No its not, its 'static' in that it doesn't time-out.


    They also did survive reboots, at least on Win2003.


    > > You can still override it with forged ARP replies to that machine.
    > > This is something, I have already tested in a medium-scale office
    > > network. The attack works against every NT version of Windows (NT,
    > > 2000, XP, 2003).

    >
    > Right... Make that every NT version of MS-Windows up until XP/2003 ? :
    > http://seclists.org/lists/vuln-dev/2003/Feb/0032.html


    My memory might be wrong, but as far as I remember, it worked against
    WinXP as well. I can say for sure, that it works against Win2003 and
    Win2000.


    > > I didn't have the opportunity to test it against 95-based Windows
    > > versions (95, 98, ME).

    >
    > Neither did i (or care to), presumably they acts as NT4 though.


    I wouldn't be surprised, if they used some proprietary protocol for MAC
    address lookup. =)


    > > So I have to repeat: Forget ARP filtering; secure your connections
    > > otherwise, using cryptographic techniques.

    >
    > I'd say: don't put all your eggs in one bucket...
    > (It sure would be a _great_ improvement if providers DNSSEC thier
    > zones.)


    Well, every communication is subject to a number of attacks. From
    (properly) encrypted connections I can say that bruteforce is the best
    attack available for now. That might change for a particular cipher,
    but then you can just switch to another one.


    > > To prevent sniffing, you need encryption. To prevent MITM attacks
    > > (which include sniffing), you need proper authentication (i.e.
    > > key/certificate-based).

    >
    > No to prevent MITM, you just need to ensure connection integrity. To
    > make sniffing ineffective use encryption. (Autentication is basically
    > just identification integrity checking).


    You cannot ensure connection integrity in networks, unless you have
    complete physical control over them, which I assume isn't the case for
    Mikhail. Key-based authentication makes MITM attacks effectively
    impossible, as long as the keys were distributed securely.


    > > In other words: You need both. Personally I don't use
    > > certificates, because they are effectively the same as keys, but
    > > unlike keys they include identity information. There is nothing bad
    > > about that, but using keys is simpler, and more widely supported

    >
    > I'd think this the other way around (think: HTTPS, IMAPS, FTPS, etc.)


    Do you have (cryptographic) client-authentication in HTTPS or IMAPS?
    How many people do use SFTP? I'm talking about protocols, where
    client-authentication is realistic.


    > > (example: SSH cannot handle certificates).

    >
    > Sure it can. Probably you mean the OpenSSH implementation doesn't ship
    > with support... Well, it can be patched with that:
    > http://roumenpetrov.info/openssh/


    Oh well, yes. I thought, at least the libraries were full-featured. I
    was wrong. =)


    > >> > Just add static ARP entries for 'important' hosts, like the
    > >> > router.
    > >>
    > >> Yes, I did this. Put them in /etc/ethers. Still I'm going to try
    > >> arpfilter as suggested by Menno Duursma. It seems arpfilter can
    > >> solve the problem with connections originating from a few
    > >> "friendly" hosts.

    > >
    > > If it works for you, then it's good and might provide a further
    > > layer of security by obscurity, making some attacks harder, though
    > > not impossible.

    >
    > ???


    What I meant was that ARP filtering is just not enough to secure
    communications.


    > > Just to encrypt everything is not enough. And you need some secure
    > > channel to distribute your key. It's best to meet your friends
    > > personally and give them a floppy disk. Do not distribute your key
    > > via internet, because the MITM is waiting there.

    >
    > IME this utterly sucks when traveling (what makes SSH so usefull is
    > the 'access your boxen from the road' option). Now password
    > autentication though can be farly secure whist utilizing something
    > like Kerberos. (However one may consider it overkill to configure a
    > KDC for but a few Telnet/SSH sessions).


    My opinion is that Kerberos is harder to configure than key-based
    authentication. But to be honest, I have not tried it myself, but just
    read about it. Key auth is enabled by default anyway, you just need to
    create a key, make it authorized and take it with you.


    Regards.

+ Reply to Thread
Page 1 of 2 1 2 LastLast