[ovs-discuss] Q. about IP-, MAC-, arp-spoofing

[Oliver Francke]

Hi Jesse,

please take my excuses, as I was far too impatient yesterday.
I have retried the following this morning, and it lasts a couple of 
seconds, until - I think - the former injection of wrong MAC-addresses 
gets a timeout.

Now the following seems to work:

         ovs-ofctl add-flow br0 "in_port="${PORT}" ip idle_timeout=0 
nw_dst=224.0.0.0/24 priority=40000 action=drop"
         ovs-ofctl add-flow br0 "in_port="${PORT}" arp idle_timeout=0 
priority=39500 action=resubmit("${PORT}",2)"
         ovs-ofctl add-flow br0 "in_port="${PORT}" ip idle_timeout=0 
dl_src=00:f1:70:00:38:90 nw_src=192.168.1.30 priority=39000 
action=resubmit("${PORT}",1)"
         ovs-ofctl add-flow br0 "in_port="${PORT}" ip idle_timeout=0 
priority=100 action=drop"
         # Apply default normal:
         ovs-ofctl add-flow br0 "in_port="${PORT}" table=1 priority=100 
action=normal"
         # arp-special:
         ovs-ofctl add-flow br0 "in_port="${PORT}" table=2 priority=200 
arp idle_timeout=0 arp_sha=00:f1:70:00:38:90 nw_src=192.168.1.30 
action=normal"
         ovs-ofctl add-flow br0 "in_port="${PORT}" table=2 priority=100 
idle_timeout=0 action=drop"

while ettercap is running I see some "last packets", after that all is 
quiet, attacking is suppressed. Fine. Works. Great.

Sorry for being impatient, angry about myself to have done it right from 
the beginning :-\

Kind regards,

Oliver.


On 07/26/2012 10:28 PM, Jesse Gross wrote:
> On Thu, Jul 26, 2012 at 1:09 PM, Oliver Francke <Oliver.Francke at filoo.de> wrote:
>> Well,
>>
>> Am 26.07.2012 um 21:01 schrieb Jesse Gross <jesse at nicira.com>:
>>
>>> On Thu, Jul 26, 2012 at 11:38 AM, Oliver Francke
>>> <Oliver.Francke at filoo.de> wrote:
>>>> I think this explains it:
>>>>
>>>> http://www.thegeekstuff.com/2012/01/arp-cache-poisoning/
>>>>
>>>> the packet I'm talking about is the faked arp-reply. Coming from the attacking VM, telling:
>>>> My MAC is <correct>, the IP ( faked) is my IP. Please hand over the packets to me, it's OK.
>>> Yes, the flow that I gave you will prevent this.  I guarantee that OVS
>>> can do it because many other people have done it the way that I
>>> suggested.
>>>
>>> I think you believe that there are two IP source fields in an ARP
>>> packet the way that there are two Ethernet source addresses.  There
>>> are not as an ARP packet is an Ethernet packet but not an IP packet.
>>>
>> I have no wireshark right now on my computer to better visualize, but here is the tcpdump -vv -r from a captured session:
>>
>> 17:03:10.406001 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.30 is-at 00:f1:70:00:38:b0 (oui Unknown), length 28
>> 17:03:10.406078 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 00:f1:70:00:38:b0 (oui Unknown), length 28
>> 17:03:11.416744 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.30 is-at 00:f1:70:00:38:b0 (oui Unknown), length 28
>> 17:03:11.416847 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 00:f1:70:00:38:b0 (oui Unknown), length 28
>>
>> there are no two IP source fields of course, but I'm talking about faking the payload. The evil VM is telling everybody, that - having the IP 192.168.1.32 - even the other IP .30 and the gateway .1 is on it's MAC.
>> In the _header_ if have correct source-MAC and correct source-IP.
> As your own packet capture shows, there is no additional header in an
> ARP packet to contain a "correct" source IP.  None of these packets
> contain the address 192.168.1.32 in any location.
>
> I'm going to stop responding to this thread because I don't know how
> to explain it any more clearly.
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss


-- 

Oliver Francke

filoo GmbH
Moltkestraße 25a
33330 Gütersloh
HRB4355 AG Gütersloh

Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz

Folgen Sie uns auf Twitter: http://twitter.com/filoogmbh