http://qs321.pair.com?node_id=816521

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re: ARP Poisoning
by tirwhan (Abbot) on Jan 10, 2010 at 11:15 UTC

    Once again, you post a trivial snippet of destructive code, which serves no practical purpose whatsoever, doesn't work well and is not even generalised enough to be used on other networks. No, this is not a suitable tool for testing the safety of a network, the same way as a sledgehammer is not a good tool for testing the safety of a door lock. No doubt you will reply with protestations that you are a HACKER not a cracker, but what you display in these nodes shows you to be a script kiddie of the most blithely ignorant kind, who has unfortunately chosen Perl to display his ignorance to the world. I, for one, wish you'd stop posting such nonsense and go read a lot of books on network security. Then take a look around on the internet to see what people have already come up with. Then try inventing something new and maybe it'll actually be useful.


    All dogma is stupid.
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: ARP Poisoning
by marto (Cardinal) on Jan 10, 2010 at 11:53 UTC

    Meh, more of this nonsense eh? In addition to the valid points tirwhan made, I'd like to thank you for once again ignoring the posting advice, such as Where should I post X?, which is displayed below the text area input field.

Re: ARP Poisoning
by Your Mother (Archbishop) on Jan 13, 2010 at 17:23 UTC

    FWIW I don't think there is any bad knowledge and I like these posts because I'm curious about the topic and it's difficult to explore on your (well, my) own. I think this sort of thing is more helpful to devs like me, curious and without much understanding of the security issues, than to would be crackers, script-kiddies, etc. The really bad guys already know what they're doing. The good guys can always use more resources and reminders of how important it is to cover all their bases.

      I'm not about to tell you what or what not to like of course, but since there seems to be a little confusion on why I object to this post, I'll try to clarify (and I'll do it in a response to you because it seems obvious now that the OPs reality is too far removed from mine to make sensible communication possible).

      I don't think there is any bad knowledge...The really bad guys already know what they're doing.

      I completely agree with this, that was not the point of my criticism. My point was that the example given does not work very well and is very naive in it's approach to ARP poisoning. As such it is not instructive at all, but merely harmful and misleading.

      To illustrate, I'll give a short overview on how ARP works (I trust you won't object, since you're "curious" :-): a networked computer(A) that wants to send an IP packet to an address on its LAN needs to know the MAC address of the interface (B) which holds that IP address. "A" therefore sends an ARP request to the Ethernet broadcast address (usually FF:FF:FF:FF:FF:FF), this is received by all interfaces on the LAN. The machine hosting "B" responds with a unicast ARP reply sent from it's own MAC address to the MAC address of "A". "A" then stores the MAC-IP pairing in its arp cache and uses it for future communications. Once the arp cache entry expires (the time for this is variable and depends on OS) it first sends an ARP unicast request to the MAC address which previously held this IP. If it doesn't receive an answer it starts again at the beginning. In code (and using Net::ARP, which of course one would never do because the OS does this kind of thing automatically), a sensible ARP exchange would look something like this:

      # "A" has the address 192.168.42.42 and wants to find out the MAC addr +ess corresponding to 192.168.42.100 Net::ARP::send_packet('eth0', # Device '192.168.42.42', # Source IP '192.168.42.100', # Destination IP 'aa:bb:cc:aa:bb:cc', # Source MAC 'ff:ff:ff:ff:ff:ff', # Destinaton MAC 'request'); # ARP operation # "B" has this IP address and responds Net::ARP::send_packet('eth0', # Device '192.168.42.100', # Source IP '192.168.42.42', # Destination IP '00:ee:ff:aa:b1:01', # Source MAC 'aa:bb:cc:aa:bb:cc', # Destinaton MAC 'reply'); # ARP operation # "A" now stores this MAC address in its arp cache, after expiry # it would send a renewal request like this Net::ARP::send_packet('eth0', # Device '192.168.42.42', # Source IP '192.168.42.100', # Destination IP 'aa:bb:cc:aa:bb:cc', # Source MAC '00:ee:ff:aa:b1:01', # Destinaton MAC 'request'); # ARP operation # "B" will reply same as above

      Now, contrast that with the packet the OP is sending in his code (hint: look at the destination hardware address) and I think you'll begin to see what the problem is and how his code makes little sense.

      The above explanation naturally leaves out a lot of detail, and there is actually a mechanism which uses gratuitous ARP packets for rapidly announcing a changed MAC to all participants of a local LAN. This mechanism is the reason why the OPs code does anything at all, but even there he's using the wrong type of packet, so it doesn't work well. Added to that, the timing is all wrong.

      Performing a DOS or MITM attack via ARP spoofing is a real threat, (and a reason one should never transmit unencrypted sensitive information over a network that others can potentially access), but trust me, you don't do it by broadcasting spurious ARP replies every 5 seconds, it's just a little bit more complicated than that. What the OPs code can do under some circumstances is disrupt network communication between certain clients on a LAN, and it does so in a very dumb and easily detectable way. In other words, its only use would be for people who want to copy-paste it and vandalise the network they're on. Also, the code itself is simply copy-pasted from the Net::ARP docs and the documentation is mostly wrong. Does this seem like something you want to see posted on perlmonks again and again ?


      All dogma is stupid.
      A reply falls below the community's threshold of quality. You may see it by logging in.
    A reply falls below the community's threshold of quality. You may see it by logging in.