Any reasons to filter ARP packets? - Security

This is a discussion on Any reasons to filter ARP packets? - Security ; Hi, I am sorry for the huge delay with the reply. I've been very busy at work, had no time to play Linux. Menno Duursma wrote: > Userfriendly programs (to test this) would be: > http://monkey.org/~dugsong/dsniff/ > http://ettercap.sourceforge.net/ > > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: Any reasons to filter ARP packets?

  1. Re: Any reasons to filter ARP packets?

    Hi,

    I am sorry for the huge delay with the reply. I've been very busy at
    work, had no time to play Linux.

    Menno Duursma wrote:
    > 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/


    Thank you for the links. They are impressing and ... slightly
    depressing.

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


    Thank you. I plan to try arptables this weekend.

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


    The only thing I need to try all these tools is time. I wonder how
    many lives have you spent to get to know about all these programs. :-)

    >
    > Have fun.
    >


    Sure, you too.
    :-)

    --
    Mikhail


  2. Re: Any reasons to filter ARP packets?

    Newsbox wrote:
    > 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.


    Definitely YES.

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


    Yes, I did. I plan to link it from our web-zine.

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


    Thank you for the kind words.

    > Write some more if you choose.


    I need time to check the ideas and try the tools suggested by Menno
    Duursma and Ertugrul Soeylemez. Otherwise I'll become a troll. :-)
    Meanwhile, I can say having a fast connection at home is an eye-opening
    experience for a person who (like me) has a little idea about the
    fundamentals of IP networking.

    Thank you for the stimulating post!

    --
    Mikhail


  3. Re: Any reasons to filter ARP packets?

    Ertugrul Soeylemez wrote:
    > "Mikhail Zotov" (06-04-03 23:21:49):
    > > 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. =)


    You can find the contact address at the bottom of this page:
    http://slackworld.berlios.de/links.html

    > I would just leave all ARP replies enabled.

    ....
    > It is easy for someone to get to your MAC address.


    Hm. How can one get my MAC address if I enable the device with
    "ifconfig $device -arp"?

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


    I am afraid I don't fully understand the point. Do you mean encryption
    in the sense of the GNU Privacy Guard? IIRC, one of the good things
    about it is that one does not have to worry about the way the public
    part of his/her authentication key is distributed.

    Thanks again for the very interesting communication.

    Regards,
    Mikhail


  4. Re: Any reasons to filter ARP packets?

    On Thu, 06 Apr 2006 13:29:41 -0700, Mikhail Zotov wrote:
    [...]
    >
    >> 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.

    >
    > I am afraid I don't fully understand the point. Do you mean encryption
    > in the sense of the GNU Privacy Guard? IIRC, one of the good things
    > about it is that one does not have to worry about the way the public
    > part of his/her authentication key is distributed.
    > [...]


    I am not the expert but maybe I can contribute my user-level
    understanding. MITM is generally more likely on cable and wireless than
    on completely "hard-wired" direct networks, but can occur as long as there
    is even one node in the path that is not under your own direct control.
    That is essentially all external communications.

    The MITM can receive, send and alter anything you exchange with the remote
    host. So if you are counting on encryption to protect your communication
    across a public network, the _only_ secure method of key exchange is to
    put your key on physical media (floppy, CD, memory stick, etc) and
    personally place it in the hand of your correspondent. Anything less will
    not protect you from MITM.

    That is not to say that on-the-fly key negotiated encryption does not have
    value, but just that it will not protect against MITM, at all.


  5. Re: Any reasons to filter ARP packets?

    "Mikhail Zotov" (06-04-06 13:29:41):

    > You can find the contact address at the bottom of this page:
    > http://slackworld.berlios.de/links.html


    Again, thank you. But it will take some time to write it. Maybe two or
    three weeks, as I get time to work on it.


    > > I would just leave all ARP replies enabled.

    > ...
    > > It is easy for someone to get to your MAC address.

    >
    > Hm. How can one get my MAC address if I enable the device with
    > "ifconfig $device -arp"?


    You need to send your MAC address with each packet, otherwise other
    hosts in the network are forced to reply to you via broadcast. Your
    operating system does not want this, and thus sends your MAC address.
    Certainly there are ways to disable that, but that's something you won't
    want to do.

    So getting your MAC address is as simple as sniffing. And we have seen
    that it's possible in all cases.


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

    >
    > I am afraid I don't fully understand the point. Do you mean
    > encryption in the sense of the GNU Privacy Guard? IIRC, one of the
    > good things about it is that one does not have to worry about the way
    > the public part of his/her authentication key is distributed.


    The GnuPG is a collective, universal program for encryption, signatures
    and key management. It does its best to provide message privacy,
    authenticity and integrity, but a few things have to be taken care of by
    the user. This includes key distribution and trust. For example, GnuPG
    does not guarantee that the key-server you use is fully trustful. A
    malicious key-server administrator can do MITM attacks easily by
    replacing keys. Another MITM might sit between you and the key-server.

    And GnuPG is just one example. This holds for all asymmetric
    cryptographic programs out there. You must distribute your key over
    some secure channel, preferably handing it out on a floppy disk, USB
    stick or the like. You get the point.


    Regards.

  6. Re: Any reasons to filter ARP packets?

    Newsbox (06-04-06 17:45:06):

    > I am not the expert but maybe I can contribute my user-level
    > understanding. MITM is generally more likely on cable and wireless
    > than on completely "hard-wired" direct networks, but can occur as long
    > as there is even one node in the path that is not under your own
    > direct control. That is essentially all external communications.


    Theoretically this would be totally correct. So let's assume Alice
    (person A) and Bob (person B) are communicating over a network. As long
    as they have a direct connection, no MITM or sniffing attacks would be
    possible. But unfortunately that's rather seldom. In the real world,
    there are routers and other hosts between Alice and Bob. Every person
    with access to those hosts could intercept the commnuication. Let's
    call this person Eve (evasdropper). She cannot launch MITM attacks, but
    just intercept. Encryption is appropriate here.

    But now let's assume the worst case (which is most likely). Mallory
    (the man in the middle), some user between Alice and Bob, is responsible
    for delivery of packets between the two. He cannot only intercept the
    communication, but also mangle it. He can freely inject forged packets
    without Alice and Bob even noticing that. So far for the terminology.

    Now to the 'hard-wired' direct networks. The big problem here is that
    modern networks of this kind (e.g. ethernets) are switched networks
    (i.e. direct peer-to-peer communication instead of broadcasts). Now
    every single person in that network can act as Mallory, while in other
    kinds of networks only certain people could do that.


    > The MITM can receive, send and alter anything you exchange with the
    > remote host. So if you are counting on encryption to protect your
    > communication across a public network, the _only_ secure method of key
    > exchange is to put your key on physical media (floppy, CD, memory
    > stick, etc) and personally place it in the hand of your correspondent.
    > Anything less will not protect you from MITM.


    That's right. To throw some light over the MITM attack, I will present
    a very realistic MITM scenario:

    As above, Alice and Bob are communicating. Both have a private/public
    key pair. Alice's private key is X and her public key is A. Bob's
    private key is Y and his public key is B. Mallory has full control over
    the channel between Alice and Bob. He has its own key pair, M being
    his private key, and F is public key.

    When Alice sends her public key A to Bob, Mallory replaces it with F, so
    Bob actually receives F instead of A. Bob sends his public key to
    Alice, which again gets replaced by F. Neither Alice nor Bob notice the
    forgery. So now Mallory has A, B, M and F.

    Alice wants to encrypt a message to Bob. But as she did not receive B,
    but F instead, she encrypts it with F. Mallory captures that packet on
    its way and decrypts it, thus being able to read its contents. Because
    he also has B, he encrypts it with that key and forwards it to Bob. Bob
    receives a valid message encrypted with his public key B, so he can
    decrypt it using the corresponding private key Y. This means, he does
    not notice anything weird. And Mallory can not only intercept the
    communication. He can also inject his own packets, because he knows the
    public keys of both Alice and Bob.

    Now Alice and Bob cannot sign their keys, when sending them. Let's
    assume, Alice signs her public key A with her private key X, sending the
    signed packet X(A) to Bob. Mallory receives that signed key, stores A
    and sends Bob a signed version of his own key, M(F). Bob verifies the
    key to be correct. They cannot use hashing algorithms, because Mallory
    can easily replace them, too.

    By the current state of things, Mallory cannot be defeated, unless there
    is some secure channel (e.g. handing out keys personally). Anyway,
    methods are known to detect MITM attacks reliably. One of the methods
    is to use the so-called interlock protocol. But now we are getting
    beyond the scope.


    > That is not to say that on-the-fly key negotiated encryption does not have
    > value, but just that it will not protect against MITM, at all.


    Exactly. Encryption not enough, unless you make sure that traffic
    interception is the best network-oriented attack.


    Regards.

  7. Re: Any reasons to filter ARP packets?

    Ertugrul Soeylemez wrote:
    > "Mikhail Zotov" (06-04-06 13:29:41):
    >
    > > You can find the contact address at the bottom of this page:
    > > http://slackworld.berlios.de/links.html

    >
    > Again, thank you. But it will take some time to write it. Maybe two or
    > three weeks, as I get time to work on it.


    This is perfectly fine. The issue won't be ready sooner than in two or
    three weeks.

    > > > I would just leave all ARP replies enabled.

    > > ...
    > > > It is easy for someone to get to your MAC address.

    > >
    > > Hm. How can one get my MAC address if I enable the device with
    > > "ifconfig $device -arp"?

    >
    > You need to send your MAC address with each packet, otherwise other
    > hosts in the network are forced to reply to you via broadcast. Your
    > operating system does not want this, and thus sends your MAC address.
    > Certainly there are ways to disable that, but that's something you won't
    > want to do.


    It seems I cannot disable "broadcast" and/or "allmulti". Regardless of
    whether I use "-arp" or not, ifconfig returns "Warning: Interface eth0
    still in BROADCAST(ALLMULTI) mode."

    > So getting your MAC address is as simple as sniffing. And we have seen
    > that it's possible in all cases.


    Perhaps, this is even easier. I have disabled "arp" on eth0, and the
    log has been empty for some time. Then, records about new connection
    attempts appeared. I am not quite sure about output of tcpdump but it
    seems information about MAC addresses is provided by the router. Thus,
    sniffing is not needed. Just ask the router. ;-)

    [GnuPG]
    Thank you for the explanation. I think I need to read their docs once
    again.

    Regards,
    Mikhail


  8. Re: Any reasons to filter ARP packets?

    "Mikhail Zotov" (06-04-07 00:58:23):

    > > > Hm. How can one get my MAC address if I enable the device with
    > > > "ifconfig $device -arp"?

    > >
    > > You need to send your MAC address with each packet, otherwise other
    > > hosts in the network are forced to reply to you via broadcast. Your
    > > operating system does not want this, and thus sends your MAC
    > > address. Certainly there are ways to disable that, but that's
    > > something you won't want to do.

    >
    > It seems I cannot disable "broadcast" and/or "allmulti". Regardless of
    > whether I use "-arp" or not, ifconfig returns "Warning: Interface eth0
    > still in BROADCAST(ALLMULTI) mode."


    I don't know, because I have never bothered to do so. My connections
    are encrypted and authentic. =)


    > > So getting your MAC address is as simple as sniffing. And we have
    > > seen that it's possible in all cases.

    >
    > Perhaps, this is even easier. I have disabled "arp" on eth0, and the
    > log has been empty for some time. Then, records about new connection
    > attempts appeared. I am not quite sure about output of tcpdump but it
    > seems information about MAC addresses is provided by the router. Thus,
    > sniffing is not needed. Just ask the router. ;-)


    Yes, as soon as the router gets its hands on your MAC address, it saves
    that relation in an internal list. To prevent broadcasting it needs to
    know, which MAC address is listening on which of its ports. However,
    there is no default way of 'asking' the router. But you can do this
    indirectly, which in turn requires sniffing.


    Regards.

  9. Re: Any reasons to filter ARP packets?

    Ertugrul Soeylemez wrote:
    > "Mikhail Zotov" (06-04-07 00:58:23):
    > > > So getting your MAC address is as simple as sniffing. And we have
    > > > seen that it's possible in all cases.

    > >
    > > Perhaps, this is even easier. I have disabled "arp" on eth0, and the
    > > log has been empty for some time. Then, records about new connection
    > > attempts appeared. I am not quite sure about output of tcpdump but it
    > > seems information about MAC addresses is provided by the router. Thus,
    > > sniffing is not needed. Just ask the router. ;-)

    >
    > Yes, as soon as the router gets its hands on your MAC address, it saves
    > that relation in an internal list. To prevent broadcasting it needs to
    > know, which MAC address is listening on which of its ports. However,
    > there is no default way of 'asking' the router. But you can do this
    > indirectly, which in turn requires sniffing.


    Can't this be done in a simpler way? A program sends some SYN packets
    to *all* hosts in the LAN, e.g., packets addressed to port 1433
    (ms-sql-s) (which appears to be quite common in the LAN). Thus, it
    needs to get to know MAC addresses of *all* hosts in the LAN. It seems
    it is the router that provides this information since my host doesn't
    reply to the requests. This is just a guess but I doubt so many
    windoops winnies in the LAN obtain MAC addresses by sniffing the
    traffic. (BTW, the ISP seems to be running FC).

    Regards,
    Mikhail


  10. Re: Any reasons to filter ARP packets?

    "Mikhail Zotov" (06-04-08 20:49:11):

    > > Yes, as soon as the router gets its hands on your MAC address, it
    > > saves that relation in an internal list. To prevent broadcasting it
    > > needs to know, which MAC address is listening on which of its ports.
    > > However, there is no default way of 'asking' the router. But you
    > > can do this indirectly, which in turn requires sniffing.

    >
    > Can't this be done in a simpler way? A program sends some SYN packets
    > to *all* hosts in the LAN, e.g., packets addressed to port 1433
    > (ms-sql-s) (which appears to be quite common in the LAN). Thus, it
    > needs to get to know MAC addresses of *all* hosts in the LAN. It seems
    > it is the router that provides this information since my host doesn't
    > reply to the requests. This is just a guess but I doubt so many
    > windoops winnies in the LAN obtain MAC addresses by sniffing the
    > traffic. (BTW, the ISP seems to be running FC).


    In that case you are not asking the router, but the host itself. If
    your machine would not reply to that SYN, then the requester wouldn't
    get your MAC address. Remember, if you don't DROP that SYN in your
    netfilter, then your host will reply with an RST packet, revealing your
    MAC address. And there are always ways to get answers from your
    machine. You cannot prevent everything without locking yourself out of
    the network.

    Further remember that the requester doesn't even have to use the
    internet protocol. It can send packets in some unknown protocol, for
    which your machine returns an error packet, again revealing your MAC
    address.


    Regards.

  11. Re: Any reasons to filter ARP packets?

    On Wed, 05 Apr 2006 17:28:55 +0200, Ertugrul Soeylemez wrote:
    > Menno Duursma (06-04-05 11:03:14):

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


    That is why is posted the SRP (RFC2945) links (which you snipped):
    http://srp.stanford.edu/analysis.html

    Apperently there _is_ a OpenSSH SRP patch too though:
    http://srp.stanford.edu/links.html

    Anyways the Heimdal implementation isn't all that hard to configuure IMO.
    (Sorry to say: the MS-AD is even easier, and RH-FC clients sail smooth too).

    > But to be honest, I have not tried it myself, but just read about it.
    > Key auth is enabled by default anyway,


    So is GSSAPI (krb5).

    > you just need to create a key, make it authorized and take it with you.

    ^^^^^^^^^^^^^^^^

    Not many people are actually gonna do that! (They'll enable passwords...)

    --
    -Menno.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2