Open Stack

Thanks Itsuro and Akhiro for clarification. I was pretty sure I was missing something when I answered Miyashita.

This is a standard problem with Firewall implementations. When a (finer) rule is added, how do we handle the existing sessions. In commercial products, we give a knob to the administrator. Doing any automatic cleanup comes at a cost. Running all established sessions through rule-lookup is not an option when the system is running at full capacity. Clearing all sessions would impact unrelated connections. What usually works is for the administrator to specify or clear sessions based on the threat.

In the current Fwaas API, we do not have a way to clear established sessions. I do not recommend clearing all sessions or running all sessions to through rule-lookup again. If there is a smarter way to do it in conntrackd (other than clearing all sessions), I am willing to look into that.

Thanks,
-Rajesh Mohan




________________________________________
From: Akihiro Motoki [amotoki at gmail.com]
Sent: Wednesday, April 08, 2015 6:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: 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 <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>

__________________________________________________________________________
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