Re: [openstack-dev] FWaaS iptables implementation
This applies to iptables-based security group implementation too. It is not specific to FWaaS. Previously we have the similar issue in floating IP association, and it was fixed by clearing related conntrackd entries. I think it is worth investigate for iptables related implementations (both secgroup and fwaas). Akihiro 2015-04-09 7:47 GMT+09:00 Itsuro ODA : > Hi, > > I think Kazuhiro's concern is that if one want to delete an "allow" rule > or change an "allow" rule to "deny" rule, it is not work correctly because > a conntrack entry made by previous communication is not deleted in the > current implementation. > > Thanks, > Itsuto Oda > > On Wed, 8 Apr 2015 11:37:29 -0700 > Rajesh Mohan wrote: > >> Hi Miyashita, >> >> The second rule is 'accept' on state being 'established' or 'related'. In >> case of ICMP, if a request has gone out from inside network, then the reply >> to that will match this rule. A new ICMP message initiated from outside >> will not match this rule. >> >> I hope I understood your question correctly. Let me know if this addresses >> your concern. >> >> Thanks, >> -Rajesh Mohan >> >> >> >> On Mon, Mar 30, 2015 at 1:58 AM, Miyashita, Kazuhiro >> wrote: >> >> > Hi, >> > >> > >> > >> > I want to ask about FWaaS iptables rule implementation. >> > >> > firewall rule are deployed as iptables rules in network node , and ACCEPT >> > target is set at second rule(*). >> > >> > >> > >> > >> > >> > Chain neutron-l3-agent-iv431d7bfbc (1 references) >> > >> > pkts bytes target prot opt in out source >> >destination >> > >> > 0 0 DROP all -- * * 0.0.0.0/0 >> > 0.0.0.0/0 state INVALID >> > >> > 0 0 ACCEPT all -- * * 0.0.0.0/0 >> > 0.0.0.0/0 state RELATED,ESTABLISHED (*) >> > >> > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * >> > 172.16.2.0/231.2.3.4 tcp spts:1025:65535 dpt:80 >> > >> > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * >> > 172.16.6.0/241.2.3.4 tcp spts:1025:65535 dpt:80 >> > >> >0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * >> > 1.2.3.4 172.16.14.0/24 tcp spts:1025:65535 dpt:11051 >> > >> > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * >> > 10.3.0.0/24 1.2.3.4 tcp spts:1025:65535 dpt:22 >> > >> > 0 0 neutron-l3-agent-liD31d7bfbc all -- * * >> > 0.0.0.0/00.0.0.0/0 >> > >> > >> > >> > >> > >> > Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP >> > or other protocol such as UDP/TCP)? >> > >> > >> > >> > This causes some wrong scenario for example... >> > >> > >> > >> > [outside openstack cloud] ---> Firewall(FWaaS) --> [inside openstack cloud] >> > >> > >> > >> > 1) admin create Firewall and create Filrewall rule accepting ICMP request >> > from outside openstack cloud, and >> > >> > 2) ICMP request packets incoming from outside to inside, and >> > >> > 3) someday, admin detects that ICMP rule is security vulnerability and >> > create Firewall rule blocking ICMP request from outside. >> > >> > >> > >> > but ICMP request packets still incoming due to ACCEPT rule(*), because >> > ICMP connection still hit rule at second(*). >> > >> > >> > >> > Thanks. >> > >> > >> > >> > kazuhiro MIYASHITA >> > >> > >> > >> > >> > >> > __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > > > -- > Itsuro ODA > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FWaaS iptables implementation
Hi, I think Kazuhiro's concern is that if one want to delete an "allow" rule or change an "allow" rule to "deny" rule, it is not work correctly because a conntrack entry made by previous communication is not deleted in the current implementation. Thanks, Itsuto Oda On Wed, 8 Apr 2015 11:37:29 -0700 Rajesh Mohan wrote: > Hi Miyashita, > > The second rule is 'accept' on state being 'established' or 'related'. In > case of ICMP, if a request has gone out from inside network, then the reply > to that will match this rule. A new ICMP message initiated from outside > will not match this rule. > > I hope I understood your question correctly. Let me know if this addresses > your concern. > > Thanks, > -Rajesh Mohan > > > > On Mon, Mar 30, 2015 at 1:58 AM, Miyashita, Kazuhiro > wrote: > > > Hi, > > > > > > > > I want to ask about FWaaS iptables rule implementation. > > > > firewall rule are deployed as iptables rules in network node , and ACCEPT > > target is set at second rule(*). > > > > > > > > > > > > Chain neutron-l3-agent-iv431d7bfbc (1 references) > > > > pkts bytes target prot opt in out source > >destination > > > > 0 0 DROP all -- * * 0.0.0.0/0 > > 0.0.0.0/0 state INVALID > > > > 0 0 ACCEPT all -- * * 0.0.0.0/0 > > 0.0.0.0/0 state RELATED,ESTABLISHED (*) > > > > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * > > 172.16.2.0/231.2.3.4 tcp spts:1025:65535 dpt:80 > > > > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * > > 172.16.6.0/241.2.3.4 tcp spts:1025:65535 dpt:80 > > > >0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * > > 1.2.3.4 172.16.14.0/24 tcp spts:1025:65535 dpt:11051 > > > > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * > > 10.3.0.0/24 1.2.3.4 tcp spts:1025:65535 dpt:22 > > > > 0 0 neutron-l3-agent-liD31d7bfbc all -- * * > > 0.0.0.0/00.0.0.0/0 > > > > > > > > > > > > Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP > > or other protocol such as UDP/TCP)? > > > > > > > > This causes some wrong scenario for example... > > > > > > > > [outside openstack cloud] ---> Firewall(FWaaS) --> [inside openstack cloud] > > > > > > > > 1) admin create Firewall and create Filrewall rule accepting ICMP request > > from outside openstack cloud, and > > > > 2) ICMP request packets incoming from outside to inside, and > > > > 3) someday, admin detects that ICMP rule is security vulnerability and > > create Firewall rule blocking ICMP request from outside. > > > > > > > > but ICMP request packets still incoming due to ACCEPT rule(*), because > > ICMP connection still hit rule at second(*). > > > > > > > > Thanks. > > > > > > > > kazuhiro MIYASHITA > > > > > > > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- Itsuro ODA __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FWaaS iptables implementation
Hi Miyashita, The second rule is 'accept' on state being 'established' or 'related'. In case of ICMP, if a request has gone out from inside network, then the reply to that will match this rule. A new ICMP message initiated from outside will not match this rule. I hope I understood your question correctly. Let me know if this addresses your concern. Thanks, -Rajesh Mohan On Mon, Mar 30, 2015 at 1:58 AM, Miyashita, Kazuhiro wrote: > Hi, > > > > I want to ask about FWaaS iptables rule implementation. > > firewall rule are deployed as iptables rules in network node , and ACCEPT > target is set at second rule(*). > > > > > > Chain neutron-l3-agent-iv431d7bfbc (1 references) > > pkts bytes target prot opt in out source >destination > > 0 0 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 state INVALID > > 0 0 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 state RELATED,ESTABLISHED (*) > > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * > 172.16.2.0/231.2.3.4 tcp spts:1025:65535 dpt:80 > > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * > 172.16.6.0/241.2.3.4 tcp spts:1025:65535 dpt:80 > >0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * > 1.2.3.4 172.16.14.0/24 tcp spts:1025:65535 dpt:11051 > > 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * > 10.3.0.0/24 1.2.3.4 tcp spts:1025:65535 dpt:22 > > 0 0 neutron-l3-agent-liD31d7bfbc all -- * * > 0.0.0.0/00.0.0.0/0 > > > > > > Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP > or other protocol such as UDP/TCP)? > > > > This causes some wrong scenario for example... > > > > [outside openstack cloud] ---> Firewall(FWaaS) --> [inside openstack cloud] > > > > 1) admin create Firewall and create Filrewall rule accepting ICMP request > from outside openstack cloud, and > > 2) ICMP request packets incoming from outside to inside, and > > 3) someday, admin detects that ICMP rule is security vulnerability and > create Firewall rule blocking ICMP request from outside. > > > > but ICMP request packets still incoming due to ACCEPT rule(*), because > ICMP connection still hit rule at second(*). > > > > Thanks. > > > > kazuhiro MIYASHITA > > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] FWaaS iptables implementation
Hi, I want to ask about FWaaS iptables rule implementation. firewall rule are deployed as iptables rules in network node , and ACCEPT target is set at second rule(*). Chain neutron-l3-agent-iv431d7bfbc (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 state INVALID 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED (*) 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 172.16.2.0/23 1.2.3.4 tcp spts:1025:65535 dpt:80 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 172.16.6.0/24 1.2.3.4 tcp spts:1025:65535 dpt:80 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 1.2.3.4 172.16.14.0/24 tcp spts:1025:65535 dpt:11051 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 10.3.0.0/24 1.2.3.4 tcp spts:1025:65535 dpt:22 0 0 neutron-l3-agent-liD31d7bfbc all -- * * 0.0.0.0/0 0.0.0.0/0 Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP or other protocol such as UDP/TCP)? This causes some wrong scenario for example... [outside openstack cloud] ---> Firewall(FWaaS) --> [inside openstack cloud] 1) admin create Firewall and create Filrewall rule accepting ICMP request from outside openstack cloud, and 2) ICMP request packets incoming from outside to inside, and 3) someday, admin detects that ICMP rule is security vulnerability and create Firewall rule blocking ICMP request from outside. but ICMP request packets still incoming due to ACCEPT rule(*), because ICMP connection still hit rule at second(*). Thanks. kazuhiro MIYASHITA __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
