On Mon, May 20, 2002 at 08:26:07PM +0200, Maciej Soltysiak wrote: > > And it does this by what? By sniffing the arp replies? If so, that's > > exactly my point. There will be no arp reply to the spoofed IP's... > Well, if you spoof to an address outside your net. > If you spoof from x.y.z.52/24 to x.y.z.53/24, you can see the arp reply.
The arp for what? Let's say x.y.z.52/24 is spoofed and x.y.z.53/24 is being attacked. The first thing happening will be an arp request (which I'm still not sure that the source would be x.y.z.52/24) to figure out x.y.z.53/24's MAC. The reply coming in from x.y.z.53/24 says "you can find x.y.z.53/24 at mac1". Then the actual spoofed packet will be sent to x.y.z.53/24. Now the responses to that packet (whatever they may be) will need to have a valid MAC for the spoofed x.y.z.52/24. So, what happens is that x.y.z.53/24 issues an arp request to figure out x.y.z.52/24's MAC; but nobody rightfully answers. Hence, your arpwatch will never catch the spoofed scenarios. > > That is why i wanted to ask routers of this via snmp, so i am not bound to > arp replies, but the actual MAC/IP pairs comming in. > > I succeeded in asking the routers of this over arpsnmp. > > But i think the table built by the router is created the same way as > arpwatch does :( > Because, when i retrieved the table to a file, > spoofed some packets, and retrieved it once more, it stayed the same. > > The actual reason for my actions here is that, i have had a icmp frag > flood, and i belive it to have been spoofed, as the port on which enormous > activity was recorded did not belong to the machine having the IP, also, > the computer whose IP was used, was operated by someone whose abilities to > do such thing are too little. > > To have a 100% valid proof of this, i would have to log the IP/MAC pairs > during that attacks, but the computer which can do that, is behind the 1st > router, so we get the router's MACs not the originator's. So i thought > that either arpwatch connected to that network, or data taken from the > router (cisco, which does not have the feature to log packets.i think) Oh, yes. Cisco's can log lots of things to almost their own death... Just be very careful by turning on the debugging on a Cisco box which passes relatively lots of traffic. That would kill the router... > would be usefull. Unfortunately it seems it's not. So i am left with a > picture of 99% load on some port during the attack. But that was one port > of hundredes here, so it might have been something else. Didn't you say that the attacks are coming from within the subnet itself. If so, which port is having that kind of load? A switch port? But anyway if that's the case you should be able to id the offending machine by a simple tcpdump at layer 2... Never done that myself but seems do-able at the first sight. Ramin > > Anyway thanks for your thoughts. > > > Ramin > Maciej >
