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 _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
