firewalld migration (was: Tumbleweed - Review of the week 2018/03)

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Robert Munteanu
Hi,

> There will not be an automated migration path from an old SuSEfirewall2
> configuration to a firewalld configuration. There is a package
> "susefirewall2-to-firewalld" which contains a utility for converting
> SuSEfirewall2 configurations to firewalld. It's only a supporting tool
> that tries to do the right thing. But it requires manual interaction and
> review of the resulting firewall rules.

Is there a plan or some guidance for packages that drop files in
/etc/sysconfig/SuSEfirewall2.d/services/ ?

$ ls -1 /etc/sysconfig/SuSEfirewall2.d/services/ | grep -v TEMPLATE | wc -l
33

Thanks,

Robert
--
http://robert.muntea.nu/
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Markos Chandras
On 22/01/18 10:34, Robert Munteanu wrote:

> Hi,
>
>> There will not be an automated migration path from an old SuSEfirewall2
>> configuration to a firewalld configuration. There is a package
>> "susefirewall2-to-firewalld" which contains a utility for converting
>> SuSEfirewall2 configurations to firewalld. It's only a supporting tool
>> that tries to do the right thing. But it requires manual interaction and
>> review of the resulting firewall rules.
>
> Is there a plan or some guidance for packages that drop files in
> /etc/sysconfig/SuSEfirewall2.d/services/ ?
>
> $ ls -1 /etc/sysconfig/SuSEfirewall2.d/services/ | grep -v TEMPLATE | wc -l
> 33
>
> Thanks,
>
> Robert
>

firewalld already contains quite a few service files but this wiki page
provides some information on how to package new service files.

https://en.opensuse.org/Firewalld/RPM_Packaging

--
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Robert Munteanu
On Mon, Jan 22, 2018 at 12:46 PM, Markos Chandras <[hidden email]> wrote:

> On 22/01/18 10:34, Robert Munteanu wrote:
>> Hi,
>>
>>> There will not be an automated migration path from an old SuSEfirewall2
>>> configuration to a firewalld configuration. There is a package
>>> "susefirewall2-to-firewalld" which contains a utility for converting
>>> SuSEfirewall2 configurations to firewalld. It's only a supporting tool
>>> that tries to do the right thing. But it requires manual interaction and
>>> review of the resulting firewall rules.
>>
>> Is there a plan or some guidance for packages that drop files in
>> /etc/sysconfig/SuSEfirewall2.d/services/ ?
>>
>> $ ls -1 /etc/sysconfig/SuSEfirewall2.d/services/ | grep -v TEMPLATE | wc -l
>> 33
>>
>> Thanks,
>>
>> Robert
>>
>
> firewalld already contains quite a few service files but this wiki page
> provides some information on how to package new service files.
>
> https://en.opensuse.org/Firewalld/RPM_Packaging

Ack, thanks for the reference.

Robert


--
http://robert.muntea.nu/
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Matthias Gerstner
In reply to this post by Robert Munteanu
Hello,

On Mon, Jan 22, 2018 at 12:34:35PM +0200, Robert Munteanu wrote:
> Is there a plan or some guidance for packages that drop files in
> /etc/sysconfig/SuSEfirewall2.d/services/ ?
>
> $ ls -1 /etc/sysconfig/SuSEfirewall2.d/services/ | grep -v TEMPLATE | wc -l
> 33

With firewalld these files are no longer needed. Firewalld ships builtin
service definitions which can be listed via

    $ firwall-cmd --get-services

You can get the definition of a single service like this

    $ firewall-cmd --info-service=samba-client

These service names can then be used for opening them in a certain zone:

    $ firewall-cmd --add-service=samba-client --zone=internal [--permanent]

You can also find the XML definitions of the services in
/usr/lib/firewalld/services.

I think the SuSEfirewall2 service files should stay around until the
migration to the new default firewall is complete. We can get rid of
these files only after SuSEfirewall2 has been completely removed from
openSUSE. It's unconvenient that these files are spread across many
different packages so it will probably take a while until they're all
cleaned up.

If anybody thinks that a service definition is missing in firewalld then
please tell me so we can see what to do about it. The correct way in
such cases would probably be to contribute suitable files to firewalld
upstream. New firewalld services can also be added dynamically during
runtime. Here is some upstream documentation on adding services:

http://www.firewalld.org/documentation/howto/add-a-service.html

So there's /etc/firewalld/services for custom services but dropping
service files into /usr/lib/firewalld/services seems also to be
supported.

Should many additional service files be needed (what I don't hope) then
we could also think about introducing a separate package that holds all
those custom service files. This would make maintaining them easier from
the firewall perspective. But adds some burden to packagers that need
changes to them.

Regards

Matthias

--
Matthias Gerstner <[hidden email]>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Arjen de Korte
Citeren Matthias Gerstner <[hidden email]>:

> Hello,
>
> On Mon, Jan 22, 2018 at 12:34:35PM +0200, Robert Munteanu wrote:
>> Is there a plan or some guidance for packages that drop files in
>> /etc/sysconfig/SuSEfirewall2.d/services/ ?
>>
>> $ ls -1 /etc/sysconfig/SuSEfirewall2.d/services/ | grep -v TEMPLATE | wc -l
>> 33
>
> With firewalld these files are no longer needed. Firewalld ships builtin
> service definitions which can be listed via
>
>     $ firwall-cmd --get-services
>
> You can get the definition of a single service like this
>
>     $ firewall-cmd --info-service=samba-client
>
> These service names can then be used for opening them in a certain zone:
>
>     $ firewall-cmd --add-service=samba-client --zone=internal [--permanent]
>
> You can also find the XML definitions of the services in
> /usr/lib/firewalld/services.
>
> I think the SuSEfirewall2 service files should stay around until the
> migration to the new default firewall is complete. We can get rid of
> these files only after SuSEfirewall2 has been completely removed from
> openSUSE. It's unconvenient that these files are spread across many
> different packages so it will probably take a while until they're all
> cleaned up.
>
> If anybody thinks that a service definition is missing in firewalld then
> please tell me so we can see what to do about it. The correct way in
> such cases would probably be to contribute suitable files to firewalld
> upstream. New firewalld services can also be added dynamically during
> runtime. Here is some upstream documentation on adding services:
>
> http://www.firewalld.org/documentation/howto/add-a-service.html
>
> So there's /etc/firewalld/services for custom services but dropping
> service files into /usr/lib/firewalld/services seems also to be
> supported.

One thing that seems to be missing in firewalld is the equivalent of  
SuSEfirewall2-custom. I use some modules from the  
xtables-addons-kmp-default package. By nature, these are fragile and  
tend to break occasionally when the kernel changes. Right now, the  
xt_geoip module is present, but broken. When including an iptables  
rule that relies on these modules, this will stop SuSEfirewall2 from  
loading. This has locked me out several times in the past. So I now  
use something like the following to prevent this from happening in  
SuSEfirewall2-custom:

fw_custom_before_port_handling() {
     if modprobe --quiet xt_geoip; then
         iptables -A input_ext -p tcp -m tcp --dport 443 -m geoip  
--source-country NL -j ACCEPT
     else
         iptables -A input_ext -p tcp -m tcp --dport 443 -j ACCEPT
     fi
}

I have not found a similar way of conditional loading of rules,  
depending on the ability to load a module. Did I miss something?

> Should many additional service files be needed (what I don't hope) then
> we could also think about introducing a separate package that holds all
> those custom service files. This would make maintaining them easier from
> the firewall perspective. But adds some burden to packagers that need
> changes to them.
>
> Regards
>
> Matthias



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Markos Chandras
On 23/01/18 20:26, Arjen de Korte wrote:

>
> One thing that seems to be missing in firewalld is the equivalent of
> SuSEfirewall2-custom. I use some modules from the
> xtables-addons-kmp-default package. By nature, these are fragile and
> tend to break occasionally when the kernel changes. Right now, the
> xt_geoip module is present, but broken. When including an iptables rule
> that relies on these modules, this will stop SuSEfirewall2 from loading.
> This has locked me out several times in the past. So I now use something
> like the following to prevent this from happening in SuSEfirewall2-custom:
>
> fw_custom_before_port_handling() {
>     if modprobe --quiet xt_geoip; then
>         iptables -A input_ext -p tcp -m tcp --dport 443 -m geoip
> --source-country NL -j ACCEPT
>     else
>         iptables -A input_ext -p tcp -m tcp --dport 443 -j ACCEPT
>     fi
> }
>
> I have not found a similar way of conditional loading of rules,
> depending on the ability to load a module. Did I miss something?

Perhaps you could possibly extend the shipped firewalld service file
with an ExecStartPost script to do the exact same thing once the
firewalld rules are loaded?

--
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Ludwig Nussel
In reply to this post by Matthias Gerstner
Matthias Gerstner wrote:
> [...]
> I think the SuSEfirewall2 service files should stay around until the
> migration to the new default firewall is complete. We can get rid of
> these files only after SuSEfirewall2 has been completely removed from
> openSUSE. It's unconvenient that these files are spread across many
> different packages so it will probably take a while until they're all
> cleaned up.

Or just drop them and generate SuSEfirewall2 files based on the
firewalld ones if needed. I suppose the information for most
services can't be all that different. Just a collection of ports.
Differences need to be looked at and resolved anyways. Anyone
actively looking into that?

> [...]
> If anybody thinks that a service definition is missing in firewalld then

Just grep ARCHIVES.gz to see what service files exist in the distro,
compare that to what firewalld offers and then create the missing
ones.

> please tell me so we can see what to do about it. The correct way in
> [...]
> Should many additional service files be needed (what I don't hope) then
> we could also think about introducing a separate package that holds all
> those custom service files. This would make maintaining them easier from
> the firewall perspective. But adds some burden to packagers that need
> changes to them.

What is the benefit of centralizing that?
Wouldn't the UI then display hundreds of entries rather than just
offering what is actually on the system?
If we wanted the UI to display 'everything' it could just as well show
/etc/services ;-)

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Matthias Gerstner
In reply to this post by Arjen de Korte
Hello,

> One thing that seems to be missing in firewalld is the equivalent of
> SuSEfirewall2-custom.
[...]
> I have not found a similar way of conditional loading of rules, depending on
> the ability to load a module. Did I miss something?

well you _can_ load custom rules with firewalld, but without any
conditional logic.

Like Markos already suggested you might be able to design a script or
systemd service that runs after firewalld loads and adds such
conditional rules.

Regards

Matthias

--
Matthias Gerstner <[hidden email]>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Matthias Gerstner
In reply to this post by Ludwig Nussel
Hi Ludwig,

On Thu, Jan 25, 2018 at 01:40:33PM +0100, Ludwig Nussel wrote:

> Or just drop them and generate SuSEfirewall2 files based on the
> firewalld ones if needed. I suppose the information for most
> services can't be all that different. Just a collection of ports.
> Differences need to be looked at and resolved anyways. Anyone
> actively looking into that?

that could be possible. But I really wouldn't want to put more effort
than necessary in keeping SuSEfirewall2 working in the migration phase.
Experience with SuSEfirewall2 shows that some difficile corner case will
break as a result and bugs start pouring in ;-)

I'm not quite sure what you mean with "differences need to be looked at
anyways". Basically firewalld users just need to identify the correct
service name (which will often be the same as before in SuSEfirewall2)
and enable it. The service descriptions of firewalld also cover things
like conntrack modules to be loaded for samba-client, for example.

Up until now I've found only one major use case that firewalld does not
cover any more: Setting up the dynamic rules for NFSv3 portmapper ports.
In NFSv4 these aren't needed any more. But for NFSv3 there's no real
solution and users need to either configure static ports for NFS
services or use some scripting approach.

> Just grep ARCHIVES.gz to see what service files exist in the distro,
> compare that to what firewalld offers and then create the missing
> ones.

Where do I find this ARCHIVES.gz?

I can check the missing ones. And if they're needed anymore at all.

> What is the benefit of centralizing that?
> Wouldn't the UI then display hundreds of entries rather than just
> offering what is actually on the system?

Well this is what firewalld more or less already does by shipping 119
service definitions with the default install.

The benefit would be that global changes to service files can be made
in a single package. For example there was/is an issue that many service
files for SuSEfirewall2 wrongly stated "RPC=portmap" instead of
"RPC=portmapper". Fixing that requires a bunch of package updates that
nobody really wants to go for.

But that doesn't mean I'm in strictly in favor for centralizing them.
I'm just opening it up for discussion. Both approaches have their pros
and cons. My hope is, as I initially said, that we won't need any
additional service files at all.

> If we wanted the UI to display 'everything' it could just as well show
> /etc/services ;-)

Simply put, yes. But firewalld also adds nice short and long
descriptions in XML ;-)

Regards

Matthias

--
Matthias Gerstner <[hidden email]>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Dominique Leuenberger / DimStar
On Thu, 2018-01-25 at 16:18 +0100, Matthias Gerstner wrote:
>
> Where do I find this ARCHIVES.gz?

http://download.opensuse.org/tumbleweed/repo/oss/ARCHIVES.gz

Cheers,
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Ludwig Nussel
In reply to this post by Matthias Gerstner
Matthias Gerstner wrote:

> On Thu, Jan 25, 2018 at 01:40:33PM +0100, Ludwig Nussel wrote:
>
>> Or just drop them and generate SuSEfirewall2 files based on the
>> firewalld ones if needed. I suppose the information for most
>> services can't be all that different. Just a collection of ports.
>> Differences need to be looked at and resolved anyways. Anyone
>> actively looking into that?
>
> that could be possible. But I really wouldn't want to put more effort
> than necessary in keeping SuSEfirewall2 working in the migration phase.
> Experience with SuSEfirewall2 shows that some difficile corner case will
> break as a result and bugs start pouring in ;-)
>
> I'm not quite sure what you mean with "differences need to be looked at
> anyways".

I mean whether all ports specified in the SuSEfirewall2 configs are
correctly reflected in firewalld conflicts.

>> Just grep ARCHIVES.gz to see what service files exist in the distro,
>> compare that to what firewalld offers and then create the missing
>> ones.
>
> Where do I find this ARCHIVES.gz?

http://download.opensuse.org/tumbleweed/repo/oss/

> I can check the missing ones. And if they're needed anymore at all.
>
>> What is the benefit of centralizing that?
>> Wouldn't the UI then display hundreds of entries rather than just
>> offering what is actually on the system?
>
> Well this is what firewalld more or less already does by shipping 119
> service definitions with the default install.
>
> The benefit would be that global changes to service files can be made
> in a single package. For example there was/is an issue that many service
> files for SuSEfirewall2 wrongly stated "RPC=portmap" instead of
> "RPC=portmapper". Fixing that requires a bunch of package updates that
> nobody really wants to go for.

1. file bugs
2. create an rpmlint check that fails the package after some weeks
    grace period
3. go ahead and fix the remaining packages yourself or file drop
    requests for no longer maintained ones.

> But that doesn't mean I'm in strictly in favor for centralizing them.
> I'm just opening it up for discussion. Both approaches have their pros
> and cons. My hope is, as I initially said, that we won't need any
> additional service files at all.

A matter of how much we care about usability to justify the effort I
guess. The centralized version is certainly cheaper to have.

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Jan Engelhardt-4
In reply to this post by Matthias Gerstner

On Thursday 2018-01-25 15:54, Matthias Gerstner wrote:

>
>> One thing that seems to be missing in firewalld is the equivalent of
>> SuSEfirewall2-custom.
>[...]
>> I have not found a similar way of conditional loading of rules, depending on
>> the ability to load a module. Did I miss something?
>
>well you _can_ load custom rules with firewalld, but without any
>conditional logic.
>Like Markos already suggested you might be able to design a script or
>systemd service that runs after firewalld loads and adds such
>conditional rules.

Hold my beer.

  zypper in xtables-addons-kmp
  iptables -m condition --condition c1 ...
  echo -en '#!/bin/sh\necho 1 >/proc/net/nf_condition/c1\n' >/usr/local/sbin/s1
  chmod a+x /usr/local/sbin/s1
  echo 'install moduleinquestion /usr/local/sbin/s1; modprobe --ignore-install moduleinquestion' >>/etc/modprobe.d/t1.conf
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration (was: Tumbleweed - Review of the week 2018/03)

Arjen de Korte
Citeren Jan Engelhardt <[hidden email]>:

> On Thursday 2018-01-25 15:54, Matthias Gerstner wrote:
>>
>>> One thing that seems to be missing in firewalld is the equivalent of
>>> SuSEfirewall2-custom.
>> [...]
>>> I have not found a similar way of conditional loading of rules,  
>>> depending on
>>> the ability to load a module. Did I miss something?
>>
>> well you _can_ load custom rules with firewalld, but without any
>> conditional logic.
>> Like Markos already suggested you might be able to design a script or
>> systemd service that runs after firewalld loads and adds such
>> conditional rules.
>
> Hold my beer.
>
>   zypper in xtables-addons-kmp
>   iptables -m condition --condition c1 ...
>   echo -en '#!/bin/sh\necho 1 >/proc/net/nf_condition/c1\n'  
> >/usr/local/sbin/s1
>   chmod a+x /usr/local/sbin/s1
>   echo 'install moduleinquestion /usr/local/sbin/s1; modprobe  
> --ignore-install moduleinquestion' >>/etc/modprobe.d/t1.conf

I don't think this would give me peace of mind, as condition is also  
part of the xtables-addons-kmp package (just like geoip) and just as  
likely to break in a similar fashion (see bug 1076650).

I expect breakage in Tumbleweed, but even in Leap I have experienced  
several times that modules from xtables-addons-kmp are unavailable  
because of some goof-up in the weak-updates for instance. This has  
locked me out of systems once too many, so I don't trust to load any  
iptables rules depending on them, unless the module actually is  
inserted successfully.

I noticed that yast2-firewall no longer works in non-graphical mode  
and maybe I'm trying to overengineer things. I have a fairly limited  
(but stable) set of iptables rules. When SuSEfirewall2 goes away, I  
could probably also use a couple of rulesets that can be inserted  
through 'iptables-restore' and script whether or not additional rules  
should be loaded.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Matthias Gerstner
In reply to this post by Ludwig Nussel
Hi!

> I mean whether all ports specified in the SuSEfirewall2 configs are
> correctly reflected in firewalld configs
>
> > I can check the missing ones. And if they're needed anymore at all.

I did check all packages that ship service files. There are about 25
packages that don't have matching service definitions in the firewalld
installation. I will take care of opening bugs for them regarding the
migration.

An issue is that in SuSEfirewall2 we have some cases of "grouped"
service definitions like courier-imap which contains all of imap, imaps,
pop3 and pop3s. In firewalld there are no such groups, there are just
the individual imap, imaps, pop3 and pop3s services. The question is
whether we should continue having such groups or rather deal with the
individual service protocols. Any opinions on this?

On another matter: For SLE-15 it was decided to completely drop
SuSEfirewall2 so it won't be available as a legacy package or anything.
Should we take the same approach for Leap-15?

When we start removing SuSEfirewall2 service files from packages then
SuSEfirewall2 will stop functioning correctly on Tumbleweed and
ultimately on Leap-15. There would still be the possiblity to basically
support SuSEfirewall2 for a while before it is completely dropped.

Regards

Matthias

--
Matthias Gerstner <[hidden email]>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Darin Perusich-3
On Tue, Jan 30, 2018 at 12:38 PM, Matthias Gerstner <[hidden email]> wrote:

> Hi!
>
>> I mean whether all ports specified in the SuSEfirewall2 configs are
>> correctly reflected in firewalld configs
>>
>> > I can check the missing ones. And if they're needed anymore at all.
>
> I did check all packages that ship service files. There are about 25
> packages that don't have matching service definitions in the firewalld
> installation. I will take care of opening bugs for them regarding the
> migration.
>
> An issue is that in SuSEfirewall2 we have some cases of "grouped"
> service definitions like courier-imap which contains all of imap, imaps,
> pop3 and pop3s. In firewalld there are no such groups, there are just
> the individual imap, imaps, pop3 and pop3s services. The question is
> whether we should continue having such groups or rather deal with the
> individual service protocols. Any opinions on this?
>
> On another matter: For SLE-15 it was decided to completely drop
> SuSEfirewall2 so it won't be available as a legacy package or anything.
> Should we take the same approach for Leap-15?
>
> When we start removing SuSEfirewall2 service files from packages then
> SuSEfirewall2 will stop functioning correctly on Tumbleweed and
> ultimately on Leap-15. There would still be the possiblity to basically
> support SuSEfirewall2 for a while before it is completely dropped.
>

I've been following this thread halfheartedly but seeing that
SuSEfirewall2 is being completely replaced by firewalld, are there
plans to implement "everything" that SuSEfirewall2 did under the hood,
with firewalld or other mechanisms? I liked how SF2 created the LOG
rules for each services enabled and would hate to see it go away. How
about the more obscure things like loading kernel modules when
FW_KERNEL_SECURITY or FW_LOAD_MODULES are set. What about "yast
firewall", will this be ported? I'm sure there are more, but these are
the few that come to mind.

Thanks!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Nathan
I'm not sure if this should be reported as a bug, or if there is a fix in
place or if it is even necessary, but with all of my Tumbleweed upgrades, the
Firewalld module was added in Yast but the Firewalld service was not active/
enabled and the SuSEFirewall2 was still active/enabled. Not a big deal for a
user to make the fix, so long as they are informed. I added a Troubleshoot
section to the wiki concerning this issue.

https://en.opensuse.org/Firewalld

Cheers,

--
Nathan Wolf

On Tuesday, 30 January 2018 16:31:15 EST Darin Perusich wrote:
> On Tue, Jan 30, 2018 at 12:38 PM, Matthias Gerstner <[hidden email]>
wrote:

> > Hi!
> >
> >> I mean whether all ports specified in the SuSEfirewall2 configs are
> >> correctly reflected in firewalld configs
> >>
> >> > I can check the missing ones. And if they're needed anymore at all.
> >
> > I did check all packages that ship service files. There are about 25
> > packages that don't have matching service definitions in the firewalld
> > installation. I will take care of opening bugs for them regarding the
> > migration.
> >
> > An issue is that in SuSEfirewall2 we have some cases of "grouped"
> > service definitions like courier-imap which contains all of imap, imaps,
> > pop3 and pop3s. In firewalld there are no such groups, there are just
> > the individual imap, imaps, pop3 and pop3s services. The question is
> > whether we should continue having such groups or rather deal with the
> > individual service protocols. Any opinions on this?
> >
> > On another matter: For SLE-15 it was decided to completely drop
> > SuSEfirewall2 so it won't be available as a legacy package or anything.
> > Should we take the same approach for Leap-15?
> >
> > When we start removing SuSEfirewall2 service files from packages then
> > SuSEfirewall2 will stop functioning correctly on Tumbleweed and
> > ultimately on Leap-15. There would still be the possiblity to basically
> > support SuSEfirewall2 for a while before it is completely dropped.
>
> I've been following this thread halfheartedly but seeing that
> SuSEfirewall2 is being completely replaced by firewalld, are there
> plans to implement "everything" that SuSEfirewall2 did under the hood,
> with firewalld or other mechanisms? I liked how SF2 created the LOG
> rules for each services enabled and would hate to see it go away. How
> about the more obscure things like loading kernel modules when
> FW_KERNEL_SECURITY or FW_LOAD_MODULES are set. What about "yast
> firewall", will this be ported? I'm sure there are more, but these are
> the few that come to mind.
>
> Thanks!




--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Peter Suetterlin-2
Nathan wrote:
> I'm not sure if this should be reported as a bug, or if there is a fix in
> place or if it is even necessary, but with all of my Tumbleweed upgrades, the
> Firewalld module was added in Yast but the Firewalld service was not active/
> enabled and the SuSEFirewall2 was still active/enabled. Not a big deal for a
> user to make the fix, so long as they are informed. I added a Troubleshoot
> section to the wiki concerning this issue.

I noticed that some package in context of samba has a dependency on firewalld.
Maybe you have that, and a recommendation pulled in the yast module, too?

But definitely not a bug - on the contrary I'd call it a bug if installing
firewalld would automatically enable it....
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Matthias Gerstner
In reply to this post by Darin Perusich-3
Hello,

> are there plans to implement "everything" that SuSEfirewall2 did under
> the hood, with firewalld or other mechanisms?

not everything. It's a best effort approach. I would say the aim is to
be able to migrate typical use cases without much troubles.

Not all features that SF2 provides are still relevant today or they
cause complexities that are difficult to manage. firewalld on the other
also provides features that SF2 does not have. A clean and well defined
interface for example.

> I liked how SF2 created the LOG rules for each services enabled and
> would hate to see it go away.

SF2 allowed very complex LOG rule setups. firewalld only allows to
generally log dropped/rejected packets independently of the involved
service. You can still add custom LOG rules.

> How about the more obscure things like loading kernel modules when
> FW_KERNEL_SECURITY or FW_LOAD_MODULES are set.

Regarding KERNEL_SECURITY the kernel has improved much in terms of
default values. SF2 currently only touches three items: log_martians,
accept_source_route and rp_filter. This option also was a source of
confusion in the past, because it didn't respect sysctl configuration.
It's better to perform these settings explicitly via sysctl in the
future.

Regarding FW_LOAD_MODULES, firewalld is able to load required modules
like nf_conntrack_netbios_ns in a service context. For example if the
samba-client service is enabled then this module will implicitly be
loaded.

> What about "yast firewall", will this be ported? I'm sure there are
> more, but these are the few that come to mind.

The YaST firewall module will be delayed a bit. There will be a time
without a functioning one. As long as you have an X server available you
can use the firewall-config GUI instead.

Generally I'd like to say that you can also contribute to firewalld to
add features that are missing at the moment. I have the impression that
the upstream project is a bit thin on man power at the moment.

Regards

Matthias

--
Matthias Gerstner <[hidden email]>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Darin Perusich-3
On Wed, Jan 31, 2018 at 5:43 AM, Matthias Gerstner <[hidden email]> wrote:
> Hello,
>
>> are there plans to implement "everything" that SuSEfirewall2 did under
>> the hood, with firewalld or other mechanisms?
>
> not everything. It's a best effort approach. I would say the aim is to
> be able to migrate typical use cases without much troubles.

Best effort is certainly practical. I guess my only expectation be
that when enabling a service the same rules be added that SF2 would
add, if possible.

For example, enabling the apache2 service:
- yast firewall services add service=service:apache2 zone=EXT
- LOG tcp  --  anywhere anywhere limit: avg 3/min burst 5 tcp dpt:http
flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options
prefix "SFW2-INext-ACC-TCP "
- ACCEPT tcp --  anywhere anywhere tcp dpt:http

> Not all features that SF2 provides are still relevant today or they
> cause complexities that are difficult to manage. firewalld on the other
> also provides features that SF2 does not have. A clean and well defined
> interface for example.
>
>> I liked how SF2 created the LOG rules for each services enabled and
>> would hate to see it go away.
>
> SF2 allowed very complex LOG rule setups. firewalld only allows to
> generally log dropped/rejected packets independently of the involved
> service. You can still add custom LOG rules.
>
>> How about the more obscure things like loading kernel modules when
>> FW_KERNEL_SECURITY or FW_LOAD_MODULES are set.
>
> Regarding KERNEL_SECURITY the kernel has improved much in terms of
> default values. SF2 currently only touches three items: log_martians,
> accept_source_route and rp_filter. This option also was a source of
> confusion in the past, because it didn't respect sysctl configuration.
> It's better to perform these settings explicitly via sysctl in the
> future.

I agree these should be set via sysctl and it's bitten me in the past.

> Regarding FW_LOAD_MODULES, firewalld is able to load required modules
> like nf_conntrack_netbios_ns in a service context. For example if the
> samba-client service is enabled then this module will implicitly be
> loaded.
>
>> What about "yast firewall", will this be ported? I'm sure there are
>> more, but these are the few that come to mind.
>
> The YaST firewall module will be delayed a bit. There will be a time
> without a functioning one. As long as you have an X server available you
> can use the firewall-config GUI instead.

I'm less concerned about the GUI, I typically only use it to see what
values it would set in /etc/sysconfig/SuSEfirewall2. I'm more
interested in the CLI interface that 'yast firewall' provides, but I
guess that would be replaced by firewall-cmd. I wrote the susefw
Puppet module and that leverages the CLI, but since I'm no longer
using Puppet it'll probably just die a slow death.

> Generally I'd like to say that you can also contribute to firewalld to
> add features that are missing at the moment. I have the impression that
> the upstream project is a bit thin on man power at the moment.
>
> Regards
>
> Matthias
>
> --
> Matthias Gerstner <[hidden email]>
> Dipl.-Wirtsch.-Inf. (FH), Security Engineer
> https://www.suse.com/security
> Telefon: +49 911 740 53 290
> GPG Key ID: 0x14C405C971923553
>
> SUSE Linux GmbH
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: firewalld migration

Matthias Gerstner
Hi,

> I guess my only expectation be that when enabling a service the same
> rules be added that SF2 would add, if possible.

I can't promise anything for the LOG rules.

> I'm more interested in the CLI interface that 'yast firewall'
> provides, but I guess that would be replaced by firewall-cmd.

Actually the 'yast firewall' will still be available. I don't know how
backward compatible the syntax is. I've just tested it and it doesn't
seem very usable yet on Tumbleweed.

Regards

Matthias

signature.asc (836 bytes) Download Attachment