Hi Soumyadeep,
On 18/05/2016 22:58, "soumyadeep.chowdh...@wipro.com" <soumyadeep.chowdh...@wipro.com> wrote: >Hi Daniele, > >Its much cleaner approach. >Thanks for the update. Thanks again for reporting this > >One more question: >Is your latest userconntrack branch merged with ovs-v2.5.0 already ? OVS 2.5.0 has already been released, I think we will back port this. The plan is to merge this on master (I haven't merged this yet) and then it will become part of the next OVS release (2.6) In the meantime this branch contains the v3 (latest) of the patch series I posted for inclusion: https://github.com/ddiproietto/ovs/tree/userconntrack_20160516 Thanks, Daniele > >Regards, >Soumyadeep > >-----Original Message----- >From: Daniele Di Proietto [mailto:diproiet...@vmware.com] >Sent: Tuesday, May 17, 2016 6:31 AM >To: Soumyadeep Chowdhury (Cisco) <soumyadeep.chowdh...@wipro.com>; Subramani >Paramasivam (Cisco) <subramani.paramasi...@wipro.com>; b...@openvswitch.org >Cc: Sourabh Bansal (Cisco) <sourabh.ban...@wipro.com>; Karuppusamy >Marappagounder (NEPC) <karuppusamy.marappagoun...@wipro.com>; Sanjeev Sharma >(Cisco) <sanjeev.sharm...@wipro.com> >Subject: Re: In ovs-userconntrack_20151115 Branch - ICMP Blocked port can be >hacked, if same icmp request id is used while sending the packet from the >blocked side of the firewall. > >** This mail has been sent from an external source ** > >Hi Soumyadeep, > >Something like this is what I meant by "matching request/response types". I've >implemented it on the last commit of my series, here: > >http://openvswitch.org/pipermail/dev/2016-May/071064.html > >The whole series is here: > >http://openvswitch.org/pipermail/dev/2016-May/071050.html (or here: >https://github.com/ddiproietto/ovs/tree/userconntrack_20160516) > >Thanks, > >Daniele > > >On 13/05/2016 04:38, "soumyadeep.chowdh...@wipro.com" ><soumyadeep.chowdh...@wipro.com> wrote: > >>Hi Daniele, >> >>Adding sequence number to the tuple will not solve the issue. As a hacker can >>still track the seq number along with the id (by looking at the icmp echo >>request packet) and send the similar packet back to the firewall, and it can >>pass through. >> >>Instead, >>Firewall needs to be intelligent enough to identify these types of packet as >>an invalid icmp request message. >>Solution can be while processing the packet from reply direction, drop the >>pkt if it is an icmp echo request message. As that is not possible. >> >>From 673c142b9bb0eff341fb7b69c5599388cc73db94 Mon Sep 17 00:00:00 2001 >>From: soumyadeep chowdhury <soumyadeep.chowdh...@wipro.com> >>Date: Thu, 12 May 2016 15:21:23 -0400 >>Subject: [PATCH] Fixed the icmp defect (Where same id packets are >>getting pass from blocked side) >> >>Signed-off-by: soumyadeep chowdhury <soumyadeep.chowdh...@wipro.com> >>Tested-by: Subramani Paramasivam <subramani.paramasi...@wipro.com> >>--- >> ovs/lib/conntrack-other.c | 8 ++++++++ >> 1 file changed, 8 insertions(+), 0 deletions(-) >> >>diff --git a/ovs/lib/conntrack-other.c b/ovs/lib/conntrack-other.c >>index c0d57a2..cbf76c4 100644 >>--- a/ovs/lib/conntrack-other.c >>+++ b/ovs/lib/conntrack-other.c >>@@ -53,6 +53,14 @@ other_conn_update(struct conn *conn_, struct dp_packet >>*pkt OVS_UNUSED, >> bool reply, long long now) { >> struct conn_other *conn = conn_other_cast(conn_); >>+ const struct icmp_header *icmp = (const char *)dp_packet_l4(pkt); >>+ /*If this is a Reply packet but type is ECHO_REQUEST, with same icmp_id, >>that means this is an try for Hack. To avoid it used below condition */ >>+ if ((conn->up.key.nw_proto == IPPROTO_ICMP) >>+ && reply >>+ && (icmp->icmp_type == ICMP_ECHO_REQUEST)) { >>+ >>+ return CT_UPDATE_INVALID; >>+ } >> >> if (reply && conn->state != OTHERS_BIDIR) { >> conn->state = OTHERS_BIDIR; >>-- >> >>Regards, >>Soumyadeep >> >>-----Original Message----- >>From: Daniele Di Proietto [mailto:diproiet...@vmware.com] >>Sent: Friday, May 13, 2016 7:32 AM >>To: Subramani Paramasivam (Cisco) <subramani.paramasi...@wipro.com>; >>b...@openvswitch.org >>Cc: Soumyadeep Chowdhury (Cisco) <soumyadeep.chowdh...@wipro.com>; >>Sourabh Bansal (Cisco) <sourabh.ban...@wipro.com>; Karuppusamy >>Marappagounder (NEPC) <karuppusamy.marappagoun...@wipro.com>; Sanjeev >>Sharma (Cisco) <sanjeev.sharm...@wipro.com> >>Subject: Re: In ovs-userconntrack_20151115 Branch - ICMP Blocked port can be >>hacked, if same icmp request id is used while sending the packet from the >>blocked side of the firewall. >> >>** This mail has been sent from an external source ** >> >>Hi Subramani, >> >>I appreciate the feedback on the userspace connection tracker, thanks >> >>Yes, the ICMP state is identified by the tuple (SRC IP, DST IP, ID). This >>mimics the behaviour of FreeBSD's pf. >> >>I guess I'd be possible to have more intelligence on ICMP connections by >>tracking sequence numbers and matching request/response types (from some >>quick testing I did, I think this is what the Linux connection tracker does). >> This can be implemented in a separate conntrack-icmp module and it will be a >>nice addition to the userspace connection tracker. >> >>I think I would still like to try to merge it with ICMP support as it is, and >>add sequence and type matching later. Obviously contributions are welcome. >> >>What do you think? >> >>Thanks, >> >>Daniele >> >> >>On 10/05/2016 23:44, "subramani.paramasi...@wipro.com" >><subramani.paramasi...@wipro.com> wrote: >> >>> >>>Hello Daniele/All, >>> >>> >>>While testing Userconntrack (Branch - ovs-userconntrack_20151115), we found >>>the following issue. >>> >>> >>> >>>Problem: >>> >>> >>>ICMP Blocked port can be hacked, if same ICMP request id is used while >>>sending the packet from the blocked side of the firewall. >>> >>> >>> >>>Test Setup: >>> >>> >>>Openvswitch Branch - ovs-userconntrack_20151115 DPDK Branch - >>>dpdk-2.2.0 >>> >>> >>>303/1 <-> dpdk0 - port 1 >>>303/3 <-> dpdk1 - port 2 >>> >>> >>>Agilent Configuration: >>> >>> >>>303/1 - 35.35.35.1/24 >>>303/3 - 35.35.35.101/24 >>> >>> >>>Traffic Configuration: >>> >>> >>>303/1 - 35.35.35.1 to 35.35.35.101 - ICMP request packet with id=0 >>>303/3 - 35.35.35.101 to 35.35.35.1 - ICMP request packet with id=0 >>> >>> >>>Firewall Flow Rules: >>> >>> >>>ovs-ofctl del-flows br0 >>>ovs-ofctl add-flow br0 "table=0,priority=1,action=drop" >>>ovs-ofctl add-flow br0 "table=0,priority=10,arp,action=normal" >>>ovs-ofctl add-flow br0 >>>"table=0,priority=100,icmp,ct_state=-trk,action=ct(table=1)" >>>ovs-ofctl add-flow br0 >>>"table=1,in_port=1,icmp,ct_state=+trk+new,action=ct(commit),2" >>>ovs-ofctl add-flow br0 "table=1,in_port=1,icmp,ct_state=+trk+est,action=2" >>>ovs-ofctl add-flow br0 "table=1,in_port=2,icmp,ct_state=+trk+new,action=drop" >>>ovs-ofctl add-flow br0 "table=1,in_port=2,icmp,ct_state=+trk+est,action=1" >>>ovs-ofctl dump-flows br0 >>> >>> >>>Steps to Reproduce: >>> >>> >>> >>>1. With the above configuration, start bidirectional traffic in Agilent. >>>2. Traffic from 303/3 to 303/1 is successful. >>>3. Expecting traffic from 303/3 to 303/1 should not pass through the >>>firewall. >>> >>>Regards, >>> >>>Subramani. >>> >>> >>>________________________________________ >>>From: Subramani Paramasivam (Cisco) >>>Sent: 10 May 2016 12:31:53 >>>To: diproiet...@vmware.com >>>Cc: Soumyadeep Chowdhury (Cisco); Sourabh Bansal (Cisco); Karuppusamy >>>Marappagounder (NEPC) >>>Subject: In ovs-userconntrack_20151115 Branch - ICMP Blocked port can be >>>hacked, if same icmp request id is used while sending the packet from the >>>blocked side of the firewall. >>> >>>Hello Daniele, >>> >>> >>>While testing Userconntrack (Branch - ovs-userconntrack_20151115), we found >>>the following issue. >>> >>> >>>Problem: >>> >>> >>>ICMP Blocked port can be hacked, if same ICMP request id is used while >>>sending the packet from the blocked side of the firewall. >>> >>> >>> >>>Test Setup: >>> >>> >>>Openvswitch Branch - ovs-userconntrack_20151115 DPDK Branch - >>>dpdk-2.2.0 >>> >>> >>>303/1 <-> dpdk0 - port 1 >>>303/3 <-> dpdk1 - port 2 >>> >>> >>>Agilent Configuration: >>> >>> >>>303/1 - 35.35.35.1/24 >>>303/3 - 35.35.35.101/24 >>> >>> >>>Traffic Configuration: >>> >>> >>>303/1 - 35.35.35.1 to 35.35.35.101 - ICMP request packet with id=0 >>>303/3 - 35.35.35.101 to 35.35.35.1 - ICMP request packet with id=0 >>> >>> >>>Firewall Flow Rules: >>> >>> >>>ovs-ofctl del-flows br0 >>>ovs-ofctl add-flow br0 "table=0,priority=1,action=drop" >>>ovs-ofctl add-flow br0 "table=0,priority=10,arp,action=normal" >>>ovs-ofctl add-flow br0 >>>"table=0,priority=100,icmp,ct_state=-trk,action=ct(table=1)" >>>ovs-ofctl add-flow br0 >>>"table=1,in_port=1,icmp,ct_state=+trk+new,action=ct(commit),2" >>>ovs-ofctl add-flow br0 "table=1,in_port=1,icmp,ct_state=+trk+est,action=2" >>>ovs-ofctl add-flow br0 "table=1,in_port=2,icmp,ct_state=+trk+new,action=drop" >>>ovs-ofctl add-flow br0 "table=1,in_port=2,icmp,ct_state=+trk+est,action=1" >>>ovs-ofctl dump-flows br0 >>> >>> >>>Steps to Reproduce: >>> >>> >>> >>>1. With the above configuration, start bidirectional traffic in Agilent. >>>2. Traffic from 303/3 to 303/1 is successful. >>>3. Expecting traffic from 303/3 to 303/1 should not pass through the >>>firewall. >>> >>>Regards, >>> >>>Subramani. >>> >>> >>>The information contained in this electronic message and any >>>attachments to this message are intended for the exclusive use of the >>>addressee(s) and may contain proprietary, confidential or privileged >>>information. If you are not the intended recipient, you should not >>>disseminate, distribute or copy this e-mail. Please notify the sender >>>immediately and destroy all copies of this message and any attachments. >>>WARNING: Computer viruses can be transmitted via email. The recipient >>>should check this email and any attachments for the presence of >>>viruses. The company accepts no liability for any damage caused by any >>>virus transmitted by this email. www.wipro.com >>> >>> >>The information contained in this electronic message and any >>attachments to this message are intended for the exclusive use of the >>addressee(s) and may contain proprietary, confidential or privileged >>information. If you are not the intended recipient, you should not >>disseminate, distribute or copy this e-mail. Please notify the sender >>immediately and destroy all copies of this message and any attachments. >>WARNING: Computer viruses can be transmitted via email. The recipient >>should check this email and any attachments for the presence of >>viruses. The company accepts no liability for any damage caused by any >>virus transmitted by this email. www.wipro.com >The information contained in this electronic message and any attachments to >this message are intended for the exclusive use of the addressee(s) and may >contain proprietary, confidential or privileged information. If you are not >the intended recipient, you should not disseminate, distribute or copy this >e-mail. Please notify the sender immediately and destroy all copies of this >message and any attachments. WARNING: Computer viruses can be transmitted via >email. The recipient should check this email and any attachments for the >presence of viruses. The company accepts no liability for any damage caused by >any virus transmitted by this email. www.wipro.com _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
