Open Stack

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 <oda at valinux.co.jp>:
> 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 <rajesh.mlists at gmail.com> 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 <miyakz at jp.fujitsu.com>
>> 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/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-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>
> --
> Itsuro ODA <oda at valinux.co.jp>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Akihiro Motoki <amotoki at gmail.com>