On Dec 4, 2013, at 12:25 AM, Silvia Fichera <fichera....@gmail.com> wrote:
> 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?!
Right. However, #130 is more than 10 seconds after #106, but the flow
corresponding to #106 had a ten second idle timeout. Could it just be that the
flow has timed out? You might want to try:
* Use a long (or no) timeout
* Check the flow table on the switch (either by sending a flow stats request or
just running ovs-dpctl/dpctl to check that your flows are getting installed)
-- Murphy
> 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>
