<div dir="ltr"><div><div><div><div><div><div><div><div>Thank you for your answer.<br></div>You're right, it seems it doesn't match.<br><br></div>I've done the capture with wireshark yesterday morning and compare the packet, and it should work, but it doesn't...maybe I'm loosing some details.<br>
</div>I'm attaching the capture.<br><br></div>The threshold by now is 10.<br><br></div>The first syn I receive in the packet n°62, from 10.2.3.88 to 10.0.0.2, I answer via packet_out with the syn ack (n°63). <br><br>
</div>
When I receive the 11th syn I install the rule (n°106).<br><br></div>When the source ip is changed (now it is 10.2.3.8), I receive the syn as a packet in (n°128) and it installs again the rule (n° 130).<br></div>But if the packet matches the rule it shouldn't happen, right?!<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/3 Murphy McCauley <span dir="ltr"><<a href="mailto:murphy.mccauley@gmail.com" target="_blank">murphy.mccauley@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To make sure I understand you correctly, the problem you're seeing is that you're installing an entry which you think should also match spoofed connections, but doesn't seem to be. Is that right?<br>
<br>
The first thing I'd do is look at the OpenFlow traffic between controller and switch in fine detail, probably using Wireshark. Specifically, I would look at three packets:<br>
1) The packet-in which causes the controller to install the drop rule<br>
2) The flow-mod where the controller installs the drop rule<br>
3) The packet-in for a spoofed IP connection attempt which you expect to have hit the drop rule<br>
<br>
I'd begin by checking #3 against #2... doing the matching "by hand", does it match, or not? If not, why not? I'd sanity check by checking #1 against #2. Does *that* match? If not, there's something wrong with the generation of the table entry. If it does, I'd check #3 against #1 to see if there's something different (besides the spoofed IP).<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Murphy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Dec 3, 2013, at 2:28 AM, Silvia Fichera <<a href="mailto:fichera.sil@gmail.com">fichera.sil@gmail.com</a>> wrote:<br>
<br>
> Hi all,<br>
> I'm trying to implement a syn flood protection, so, if the controller receives a syn without ack consider the source a suspect source and I add its mac address, dst mac addr and dst TCP port in a grey list. After receiving a certain numer of syn packet (a threshold) without ack response I wanna drop the incoming syn traffic from the "attacker" identifing it by its mac address.<br>
><br>
> I've installed the dropping rule leaving the actions list empty in this way:<br>
><br>
> actions=[]<br>
> match=of.ofp_match.from_packet(packet,inport)<br>
> match.dl_src=SRCmac<br>
> match.tp_src=None<br>
> match.nw_src=None<br>
> #match.tp_dst=None<br>
> msg=of.ofp_flow_mod(command=of.OFPFC_ADD,<br>
> idle_timeout=FLOW_IDLE_TIMEOUT,<br>
> hard_timeout=of.OFP_FLOW_PERMANENT,<br>
> buffer_id=event.ofp.buffer_id,<br>
> actions=actions,match=match)<br>
> event.connection.send(msg.pack())<br>
> print("Dropping Rule installed")<br>
><br>
> but if the attacker performs ip spoofing and send a syn packet with the new IP my controller install again the rule, also if the srcIP is wildcarded.<br>
><br>
> There are any wrong matching?<br>
><br>
> P.S.:<br>
> When the controller receives syn packet, if numer of syn <threshold, it pretends to be the destination host and sent the syn ack packet.<br>
> If it receives the ack sends a reset, add the src ip in a whitelist and install the forwarding rule.<br>
><br>
> Thanks for your help.<br>
><br>
> --<br>
> Silvia Fichera<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Silvia Fichera
</div>