Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: ARP Poisoning

by Your Mother (Archbishop)
on Jan 13, 2010 at 17:23 UTC ( #817234=note: print w/replies, xml ) Need Help??


in reply to ARP Poisoning

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.

Replies are listed 'Best First'.
Re^2: ARP Poisoning (somewhat OT)
by tirwhan (Abbot) on Jan 14, 2010 at 12:03 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://817234]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (2)
As of 2022-05-23 23:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (82 votes). Check out past polls.

    Notices?