Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^2: ARP Poisoning (somewhat OT)

by tirwhan (Abbot)
on Jan 14, 2010 at 12:03 UTC ( #817391=note: print w/replies, xml ) Need Help??

in reply to Re: ARP Poisoning
in thread ARP Poisoning

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 and wants to find out the MAC addr +ess corresponding to Net::ARP::send_packet('eth0', # Device '', # Source IP '', # 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 '', # Source IP '', # 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 '', # Source IP '', # 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.

Replies are listed 'Best First'.
Re^3: ARP Poisoning (somewhat OT)
by hnd (Scribe) on Jan 14, 2010 at 17:34 UTC
    ARP poisoning is the act of broadcasting malicious reply packets and update the ARP caches of the systems on the network, my code does this very happily and in a very legitimate sort of way. i've checked it using the tcpdump sniffer and it does not reveal my own IP and moreover the change in the ARP cache can be seen using the arp -a command i've checked it and it does update the MAC address of the gateway replacing it with my MAC
    i'am worst at what do best and for this gift i fell blessed...
    i found it hard it's hard to find well whatever

      Sigh..all right, I've really run out of patience with you, but to end this off on a semi-helpful note I'll reply briefly. Read this, then read my post above again, think about it, read a book and maybe you'll get it.

      ARP poisoning is the act of broadcasting malicious reply packets
      s/is the act of broadcasting/amongst other things requires sending/;
      my code does this very happily and in a very legitimate sort of way

      No, it does this in the dumbest and least efficient way possible.

      checked it using the tcpdump sniffer

      Hint: tcpdump does not explain the whole packet to you, you won't actually see the ARP payload unless you manually inspect the packet content yourself (it shows you the Ethernet frame data, which is not necessarily the same as the ARP payload).

      it does update the MAC address of the gateway

      Newsflash: just because it works on your router, doesn't mean it'll work on others.

      Oh, and I thought this was your network administrator's router? You know, the one who was so happy you notified him of this "vulnerability"...don't bother replying, I won't.

      All dogma is stupid.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://817391]
[1nickt]: perl -e 'print 1.0' ... output '1'.
[Lady_Aleena]: You could quote it. <c>perl -e 'print "1.0"'>/c> returns 1.0
[Lady_Aleena]: perl -e 'my $var = "1.0"; print $var;' if it is in a variable also returns 1.0, though perl -e 'my $var = 1.0; print $var;' returns 1.
[1nickt]: In my case I can simply pass sprintf '%.1f', 1.0 (to Types::Standard:: Int), but what if you didn;t know the precision of the number you were working with? Seems I must be missing something. Oh well, my test list is complete, mooving on ...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (11)
As of 2017-05-24 18:47 GMT
Find Nodes?
    Voting Booth?