[pox-dev] Install dropping rule

[Murphy McCauley]

On Dec 4, 2013, at 12:25 AM, Silvia Fichera <fichera.sil at 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.mccauley at 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.sil at 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>