Thank you for your answer. You're right, it seems it doesn't match. 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. I'm attaching the capture.
The threshold by now is 10.
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).
When I receive the 11th syn I install the rule (n°106).
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).
But if the packet matches the rule it shouldn't happen, right?!
2013/12/3 Murphy McCauley <murphy.mccau...@gmail.com>
> 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?
>
> 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:
> 1) The packet-in which causes the controller to install the drop rule
> 2) The flow-mod where the controller installs the drop rule
> 3) The packet-in for a spoofed IP connection attempt which you expect to
> have hit the drop rule
>
> 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).
>
> -- Murphy
>
> On Dec 3, 2013, at 2:28 AM, Silvia Fichera <fichera....@gmail.com> wrote:
>
> > Hi all,
> > 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.
> >
> > I've installed the dropping rule leaving the actions list empty in this
> way:
> >
> > actions=[]
> > match=of.ofp_match.from_packet(packet,inport)
> > match.dl_src=SRCmac
> > match.tp_src=None
> > match.nw_src=None
> > #match.tp_dst=None
> > msg=of.ofp_flow_mod(command=of.OFPFC_ADD,
> > idle_timeout=FLOW_IDLE_TIMEOUT,
> > hard_timeout=of.OFP_FLOW_PERMANENT,
> > buffer_id=event.ofp.buffer_id,
> > actions=actions,match=match)
> > event.connection.send(msg.pack())
> > print("Dropping Rule installed")
> >
> > 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.
> >
> > There are any wrong matching?
> >
> > P.S.:
> > When the controller receives syn packet, if numer of syn <threshold, it
> pretends to be the destination host and sent the syn ack packet.
> > If it receives the ack sends a reset, add the src ip in a whitelist and
> install the forwarding rule.
> >
> > Thanks for your help.
> >
> > --
> > Silvia Fichera
>
>
--
Silvia Fichera
Capture
Description: Binary data
