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 <[email protected]> wrote:
Well,
Am 26.07.2012 um 21:01 schrieb Jesse Gross <[email protected]>:
On Thu, Jul 26, 2012 at 11:38 AM, Oliver Francke
<[email protected]> 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
[email protected]
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
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
