[Firehol-devs] code generation

[Tsaousis, Costa]

To make things more clear I replaced FIREHOL_DEFAULT_CT_HELPERS and
FIREHOL_AUTO_CT_HELPERS options with this:

How to configure conntrack helper assignment?

'kernel'  = the kernel will attempt to match RELATED sockets for all
            conntrack helpers and all traffic matching its predefined rules.
            This is considered a security threat and should be avoided.
            Check: https://home.regit.org/netfilter-en/secure-use-of-helpers/

'firehol' = FireHOL will generate rules in the 'raw' table, using the -j CT
            target of iptables to match the flows of the statements
            the conntrack helpers are used.
            CAUSION: FireHOL generated statements are not NAT aware.
            You should only use this, if you don't NAT traffic that have to
            be seen by conntrack helpers to detect RELATED ports.

'manual'  = You configure conntrack helper assignement manually using
            the 'cthelper' firehol helper.
            In this case, neither the kernel nor FireHOL will do anything
            about conntrack helpers assignement.

# Default: kernel
FIREHOL_CONNTRACK_HELPERS_ASSIGNMENT="kernel"


On Sun, Feb 15, 2015 at 12:23 PM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
> Regarding FIREHOL_AUTO_CT_HELPERS=1 I think the instructions I gave
> previously are wrong.
>
> I advised you to add src/dst to routers when this is enabled.
>
> Well, it turns out that this will not work...
>
> The problem is that in the raw table where this is applied, packets
> are seen outside the NAT. The packets are seen before the NAT for the
> incoming packets and after the NAT for the outgoing packets. If you
> NAT your traffic and you have src/dst IP in your router and interface
> statements which are NAT'd, then FIREHOL_AUTO_CT_HELPERS=1 will not be
> able to match anything for the helpers at the 'raw' table. The same is
> also true of you NAT the server ports. FireHOL will create statements
> to enable the helper that will not match the NATed ports.
>
> So the correct statement is: when you use helpers, for
> FIREHOL_AUTO_CT_HELPERS=1 to match the traffic, you should use src and
> dst IPs in routers and interfaces, as seen on the wire in both
> directions (and in case of routers, use only the IPs that are common
> to both wires). If you NAT ports, FIREHOL_AUTO_CT_HELPERS=1 cannot
> help at all.
>
> So, if you don't usually put src/dst in your interfaces and routers
> and you don't NAT ports, FIREHOL_AUTO_CT_HELPERS=1 will work out of
> the box.
>
> If you do however limit the traffic with src/dst (and you should to
> avoid spoofing) FIREHOL_AUTO_CT_HELPERS=1 will not generate statements
> to match the helper traffic properly.
> In this case, use the cthelper to configure the conntrack helpers manually.
>
> I switched back the default behaviour:
>
> FIREHOL_DEFAULT_CT_HELPERS=1 (default assignment by kernel enabled)
> FIREHOL_AUTO_CT_HELPERS=0 (automatic assignment by FireHOL disabled)
>
> If you plan to use the cthelper, you should set
> FIREHOL_DEFAULT_CT_HELPERS=0 (disable default assignment by kernel).
>
> I updated the cthelper to work also bidirectionally:
>
> cthelper <helper name> in|out|inout [ optional rule parameters ]
>
> In case of 'inout' you should match 'in' and FireHOL will create 'out'.
>
> I also added a warning in cthelper if FIREHOL_DEFAULT_CT_HELPERS=1.
>
> Costa
>
> On Sun, Feb 15, 2015 at 11:22 AM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
>> Phil I agree with all your proposals.
>>
>> Regarding the mms, my mistake, I couldn't find the helper to test it,
>> so I removed it.
>> I now see that it exists in openwrt. I added it back.
>>
>> Costa
>>
>>
>> On Sun, Feb 15, 2015 at 10:55 AM, Phil Whineray <phil at sanewall.org> wrote:
>>> Hi Costa
>>>
>>> When there was no builds for a couple of days I thought perhaps you
>>> were taking a well-deserved break.
>>>
>>> On Sun, Feb 15, 2015 at 03:04:05AM +0200, Tsaousis, Costa wrote:
>>>> To my understanding this commit contains so important changes, new
>>>> features and optimizations, that FireHOL is now at v3 (Phil this is
>>>> your call though).
>>>
>>> It seems the opposite is true! Together, these are some impressive changes.
>>> I agree this must be v3.
>>>
>>> From here I think there are 3 main activities:
>>>  - get as wide testing as possible
>>>  - get the documentation done internally
>>>  - update the website
>>>
>>> Unless you disagree with this approach I will put together a 3.0.0-rc.1
>>> fairly soon (should be today) and announce on the lists and website
>>> to encourage people to start testing.
>>>
>>> I will also see about putting in place a basic unit test structure,
>>> better than the regression one I had which allows us to track when
>>> results change. This seems like an appropriate time, in that I would
>>> like to create a number of test configurations, so recording the
>>> results seems sensible.
>>>
>>> I will also create a v2 branch and a 2.0.1 release to apply a bugfix
>>> when plain iptables statements are used by the user. I hope most
>>> people will jump straight to v3 but any that don't should have that patch.
>>>
>>> Cheers
>>> Phil
>>>
>>> P.S. Final question - the latest changes include this - I don't
>>> understand the removal? If it is intentional then lines 768-769 need
>>> removing from doc/services-db.data so that the code does not expect
>>> to find a helper when building the docs.
>>>
>>> @@ -2091,10 +2169,6 @@ client_microsoft_ds_ports="default"
>>>
>>>  server_mms_ports="tcp/1755 udp/1755"
>>>  client_mms_ports="default"
>>> -helper_mms="mms"
>>> -# this will produce warnings on most distribution
>>> -# because the mms module is not there:
>>> -# ALL_SHOULD_ALSO_RUN="${ALL_SHOULD_ALSO_RUN} mms"