Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

Re: A bit strange ARP queries

Subject: Re: A bit strange ARP queries
Date: Thu, 15 Dec 2005 23:59:17 -0800
Eygene A. Ryabinkin wrote:

 Good day!

Has anyone seen such ARP packets? I am a bit curious, because we have no
strange hardware that will set the target hardware address in the who-has
ARP packet. Are there any attacks that using such packets?
-----
15:29:59.908901 arp who-has the-host-in-question (4:c0:40:1:e0:df) tell the-requester 15:30:00.911228 arp who-has the-host-in-question (57:43:50:10:40:0) tell the-requester 15:30:01.912045 arp who-has the-host-in-question (2e:2f:30:31:32:33) tell the-requester 15:30:02.913314 arp who-has the-host-in-question (2e:2f:30:31:32:33) tell the-requester 15:30:03.915013 arp who-has the-host-in-question (2e:2f:30:31:32:33) tell the-requester 15:30:04.915854 arp who-has the-host-in-question (2e:2f:30:31:32:33) tell the-requester 15:30:25.962925 arp who-has the-host-in-question (2e:2f:30:31:32:33) tell the-requester 15:30:26.966171 arp who-has the-host-in-question (2e:2f:30:31:32:33) tell the-requester 15:30:26.991402 arp reply the-host-in-question is-at 0:d:88:e6:db:dc 15:31:01.025945 arp who-has the-host-in-question (7:1c:c3:0:72:8c) tell the-requester 15:31:01.040650 arp reply the-host-in-question is-at 0:d:88:e6:db:dc 15:32:01.308911 arp who-has the-host-in-question (4:f9:50:10:ff:ff) tell the-requester 15:32:01.319515 arp reply the-host-in-question is-at 0:d:88:e6:db:dc 15:33:01.448065 arp who-has the-host-in-question (0:b0:2:0:25:f) tell the-requester 15:33:02.448924 arp who-has the-host-in-question (2e:2f:30:31:32:33) tell the-requester 15:33:02.573582 arp reply the-host-in-question is-at 0:d:88:e6:db:dc 15:34:00.568785 arp who-has the-host-in-question (0:b0:2:0:25:f) tell the-requester 15:34:01.569537 arp who-has the-host-in-question (2e:2f:30:31:32:33) tell the-requester 15:34:01.625362 arp reply the-host-in-question is-at 0:d:88:e6:db:dc 15:35:00.836038 arp who-has the-host-in-question (0:0:1f:0:a:c7) tell the-requester 15:35:00.956094 arp reply the-host-in-question is-at 0:d:88:e6:db:dc 15:36:12.412916 arp who-has the-host-in-question (94:eb:ed:1a:71:fb) tell the-requester 15:36:12.423227 arp reply the-host-in-question is-at 0:d:88:e6:db:dc
-----
'the-host-in-question' and 'the-requester' are, of course, IP addresses.


Thanks!


I should let the network people on the list answer, but it looks normal "unsolicited" ARP.

Unsolicited ARPing should (and does) happen as a host/device is booting and initializing it's tcpip stack; although, it should broadcast the ARP, in that case.

Anyway, here we see the-host-in-question checking to see whether the ip address it wants to use, is already in use. It appears to be already in use by the host at MAC 00:0d:88:e6:db:dc. If that's the-host-in-question's MAC, then this would be OK.

The other machines should update their ARP tables, if they don't have this ip at that MAC. If this wasn't host-in-question's MAC, I suppose it *could* be an arp poisoining attempt, but it could be simply be an ip conflict.

That's the way, I see it. I'd defer to someone with Networking expeirance, as I have no cisco certification or the like.
.


<Prev in Thread] Current Thread [Next in Thread>