We are to yet in sync ;) …
Am 26.07.2012 um 19:21 schrieb Jesse Gross <je...@nicira.com>:
> On Thu, Jul 26, 2012 at 9:40 AM, Oliver Francke <oliver.fran...@filoo.de>
> wrote:
>> Hi,
>>
>> Am 26.07.2012 um 18:07 schrieb Jesse Gross <je...@nicira.com>:
>>
>>> On Thu, Jul 26, 2012 at 8:30 AM, Oliver Francke <oliver.fran...@filoo.de>
>>> wrote:
>>>> Hi Jesse,
>>>>
>>>> Am 26.07.2012 um 17:17 schrieb Jesse Gross <je...@nicira.com>:
>>>>
>>>>> On Thu, Jul 26, 2012 at 2:38 AM, Oliver Francke <oliver.fran...@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@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
