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

[Oliver Francke]

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.

Well, you name it ;)
I would love to inspect the packet, cause I know the offset, where wrong IP-address resides.
Other then that there are things like arpwatch, make static entries… but if OVS is able to do it as an intelligent switch, it'll be great.

Oliver.

Am 26.07.2012 um 19:31 schrieb Oliver Francke <Oliver.Francke at filoo.de>:

> We are to yet in sync ;) …
> 
> Am 26.07.2012 um 19:21 schrieb Jesse Gross <jesse at nicira.com>:
> 
>> On Thu, Jul 26, 2012 at 9:40 AM, Oliver Francke <Oliver.Francke at filoo.de> wrote:
>>> Hi,
>>> 
>>> Am 26.07.2012 um 18:07 schrieb Jesse Gross <jesse at nicira.com>:
>>> 
>>>> On Thu, Jul 26, 2012 at 8:30 AM, Oliver Francke <Oliver.Francke at filoo.de> wrote:
>>>>> Hi Jesse,
>>>>> 
>>>>> Am 26.07.2012 um 17:17 schrieb Jesse Gross <jesse at nicira.com>:
>>>>> 
>>>>>> On Thu, Jul 26, 2012 at 2:38 AM, Oliver Francke <Oliver.Francke at filoo.de> wrote:
>>>>>>> Hi *,
>>>>>>> 
>>>>>>> as there are many guys around here with OVS and qemu-virtualization I think
>>>>>>> it's the right place to ask ;)
>>>>>>> 
>>>>>>> Currently I have some basic rulesets ala:
>>>>>>> 
>>>>>>> # --- 8-< ---
>>>>>>> ovs-ofctl add-flow vmbr0 "in_port="${PORT}" ip idle_timeout=0
>>>>>>> nw_dst=224.0.0.0/24 priority=40000 action=drop"
>>>>>>> ovs-ofctl add-flow vmbr0 "in_port="${PORT}" ip idle_timeout=0 dl_src=${MAC}
>>>>>>> nw_src=${IP} priority=39000 action=resubmit("${PORT}",1)"
>>>>>>> ovs-ofctl add-flow vmbr0 "in_port="${PORT}" ip idle_timeout=0 priority=100
>>>>>>> action=drop"
>>>>>>> 
>>>>>>> ovs-ofctl add-flow vmbr0 "in_port="${PORT}" table=1 priority=100
>>>>>>> action=normal"
>>>>>>> # --- 8-< ---
>>>>>>> 
>>>>>>> that is: drop some broadcasts, allow VM's configured MAC + IP to jump to
>>>>>>> next table, and there place some additional rules, if any.
>>>>>>> 
>>>>>>> This works, I see no more traffic if I do some changing of eth0's
>>>>>>> MAC-address or changing my VM's IP. Fine.
>>>>>>> 
>>>>>>> Now there are evil characters around :-\
>>>>>>> My enemy is arp-poisoning via ettercap or arpspoof. Programs that are
>>>>>>> available in deb-packages.
>>>>>>> 
>>>>>>> Well, what do you do against mangled payload:
>>>>>>> 
>>>>>>> # --- 8-< ---
>>>>>>> Hardware type: Ethernet (0x0001)
>>>>>>> Protocol type: IP (0x0800)
>>>>>>> .
>>>>>>> .
>>>>>>> Sender MAC address: 00:f1:70:00:38:b0 (00:f1:70:00:38:b0)
>>>>>>> Sender IP address: 192.168.1.30 (192.168.1.30)
>>>>>>> # --- 8-< ---
>>>>>>> 
>>>>>>> whereas the senders MAC is correct, and the IP is faked, it's from the VM I
>>>>>>> want to attack.
>>>>>>> 
>>>>>>> Is there any way in OVS to detect via offset/pattern/whatever such a mess?
>>>>> 
>>>>>>> 
>>>>>>> Or administer a static table in OVS with valid MACs <-> IPs?
>>>>>> 
>>>>>> Well you can match on the IPs and MACs in the payload of ARP packets
>>>>>> using flows and drop anything that doesn't hit.
>>>>> 
>>>>> Well sir, I cannot, at least I tried to go through man-pages etc. My plan was to add a flow for all arp-packets, then handle all things in a second table. But I have no idea _how_, hence this mail ;)
>>>>> If its something obvious, excuse my blind 8-)
>>>> 
>>>> ovs-ofctl add-flow BR
>>>> priority=1,in_port=X,arp,dl_src=Y,nw_src=Z,arp_sha=Y,actions=resubmit(TABLE)
>>> 
>>> yeah, done that already. was my first thought, problem continues, as the MAC-address is correct ( matches arp_sha), but the IP is "poisoned" ( wireshark-excerpt above), the evil wants to inject his MAC with IP of target to attack.
>>> Or my thinking is wrong at this point…
>> 
>> To hit a flow you must match all fields so if you specify both MAC and
>> IP and the IP is spoofed then the flow won't match.
>> 
> 
> the snipplet above is the payload. Packet Ethernet-MAC-address is correct, so is packet IP-address ( 192.168.1.32). In the packet itself there is the wrong information ( 192.168.1.30).
> 
> Sorry for any confusion.
> 
> 
>>> So, flow would match, if arp + dl_src + nw_src + arp_sha + arp_source_ip_address are matching, right?
>>> Then action would be normal.
>> 
>> nw_src and arp_source_ip_address are the same thing.  There's only one
>> IP source field in an ARP packet.
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
> 
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss