[opensuse-factory] firewalld migration (was: Tumbleweed - Review of the week 2018/03)
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 22, 2018 at 12:46 PM, Markos Chandras <mchandras@suse.de> 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.
Ack, thanks for the reference. Robert -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <matthias.gerstner@suse.de> 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)
Citeren Matthias Gerstner <mgerstner@suse.de>:
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <matthias.gerstner@suse.de> 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)
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Jan Engelhardt <jengelh@inai.de>:
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <matthias.gerstner@suse.de> 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)
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
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <matthias.gerstner@suse.de> 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)
On Tue, Jan 30, 2018 at 12:38 PM, Matthias Gerstner <mgerstner@suse.de> 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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <mgerstner@suse.de> 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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <matthias.gerstner@suse.de> 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)
On Wed, Jan 31, 2018 at 5:43 AM, Matthias Gerstner <mgerstner@suse.de> 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 <matthias.gerstner@suse.de> 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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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 I do not understand why some SuSEfirewall2 service files are dropped (apache2 and apache2-ssl in my case). I currently do not plan to migrate to FirewallD, but also SuSEfirewall2 does not work as expected anymore.
$ SuSEfirewall2 [...] /usr/bin/stat: cannot stat '/etc/sysconfig/SuSEfirewall2.d/services/apache2': No such file or directory Cannot stat file /etc/sysconfig/SuSEfirewall2.d/services/apache2 to be sourced /usr/bin/stat: cannot stat '/usr/share/SuSEfirewall2/services/apache2': No such file or directory Cannot stat file /usr/share/SuSEfirewall2/services/apache2 to be sourced <36>Feb 10 21:46:48 SuSEfirewall2[14527]: Warning: config 'apache2' not available /usr/bin/stat: cannot stat '/etc/sysconfig/SuSEfirewall2.d/services/apache2-ssl': No such file or directory Cannot stat file /etc/sysconfig/SuSEfirewall2.d/services/apache2-ssl to be sourced /usr/bin/stat: cannot stat '/usr/share/SuSEfirewall2/services/apache2-ssl': No such file or directory Cannot stat file /usr/share/SuSEfirewall2/services/apache2-ssl to be sourced <36>Feb 10 21:46:48 SuSEfirewall2[14527]: Warning: config 'apache2-ssl' not available [...] The fix is easy: 1. Remove apache2-ssl and apache from FW_CONFIGURATIONS_EXT in /etc/sysconfig/SuSEfirewall2 2. Add 80 and 443 to FW_SERVICES_EXT_TCP Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Well, not exactly original question, but still questions about migration. I've tried to run YaST2 firewall configuration utility and was disappointed that it was replaced for firewalld configurator. But why remove good-old susefirewall cofigurator? Why not just make separate configurator for firewalld that wouldn't replace susefirewall's yast2 module? Not everyone moved to firewalld from susefirewall, so it'd be good to keep its yast2 module while susefirewall still available. Am I wrong? Second question, firewalld configurator/yast2 module looks really alien comparing to all other yast2 modules which are nicely Qt/breeze themed. And this looks totally different. I suppose it uses GTK and uses not GTK-breeze theme. Why it couldn't follow look of other yast modules? -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
Mykola Krachkovsky wrote:
Hi,
Well, not exactly original question, but still questions about migration.
I've tried to run YaST2 firewall configuration utility and was disappointed that it was replaced for firewalld configurator. But why remove good-old susefirewall cofigurator? Why not just make separate configurator for firewalld that wouldn't replace susefirewall's yast2 module? Not everyone moved to firewalld from susefirewall, so it'd be good to keep its yast2 module while susefirewall still available. Am I wrong?
That does sound like a sensible compromise - keep the YaST2 module for SuSEfirewall2. At least for Leap15. Maybe indicate that it is not supported?
Second question, firewalld configurator/yast2 module looks really alien comparing to all other yast2 modules which are nicely Qt/breeze themed. And this looks totally different. I suppose it uses GTK and uses not GTK-breeze theme. Why it couldn't follow look of other yast modules?
Becaue it isn't a YaST module, it is the native firewalld configuration GUI. -- Per Jessen, Zürich (3.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
субота, 31 березня 2018 р. 11:48:58 EEST Per Jessen написано:
Mykola Krachkovsky wrote:
I've tried to run YaST2 firewall configuration utility and was disappointed that it was replaced for firewalld configurator. But why remove good-old susefirewall cofigurator? Why not just make separate configurator for firewalld that wouldn't replace susefirewall's yast2 module? Not everyone moved to firewalld from susefirewall, so it'd be good to keep its yast2 module while susefirewall still available. Am I wrong?
That does sound like a sensible compromise - keep the YaST2 module for SuSEfirewall2. At least for Leap15. Maybe indicate that it is not supported?
It'd be fine for Tumbleweed too, IMHO. Yes, some mark about deprecation/no more support is nice to have as a warning.
Becaue it isn't a YaST module, it is the native firewalld configuration GUI.
Thanks, it's clear now why it is so alien in UI/UX. Are there any known plans for yast2 module? -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
* Per Jessen <per@computer.org> [03-31-18 04:49]:
Mykola Krachkovsky wrote:
Hi,
Well, not exactly original question, but still questions about migration.
I've tried to run YaST2 firewall configuration utility and was disappointed that it was replaced for firewalld configurator. But why remove good-old susefirewall cofigurator? Why not just make separate configurator for firewalld that wouldn't replace susefirewall's yast2 module? Not everyone moved to firewalld from susefirewall, so it'd be good to keep its yast2 module while susefirewall still available. Am I wrong?
That does sound like a sensible compromise - keep the YaST2 module for SuSEfirewall2. At least for Leap15. Maybe indicate that it is not supported?
and for Tumbleweed ???? or provide some method to change from SUSEFirewall2 to Firewalld. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Patrick Shanahan wrote:
* Per Jessen <per@computer.org> [03-31-18 04:49]:
Mykola Krachkovsky wrote:
Hi,
Well, not exactly original question, but still questions about migration.
I've tried to run YaST2 firewall configuration utility and was disappointed that it was replaced for firewalld configurator. But why remove good-old susefirewall cofigurator? Why not just make separate configurator for firewalld that wouldn't replace susefirewall's yast2 module? Not everyone moved to firewalld from susefirewall, so it'd be good to keep its yast2 module while susefirewall still available. Am I wrong?
That does sound like a sensible compromise - keep the YaST2 module for SuSEfirewall2. At least for Leap15. Maybe indicate that it is not supported?
and for Tumbleweed ????
Certainly, why not Tumbleweed too.
or provide some method to change from SUSEFirewall2 to Firewalld.
There is a conversion script provided, "susefirewall2-to-firewalld". I don't know how well it does. -- Per Jessen, Zürich (5.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (14)
-
Arjen de Korte -
Bjoern Voigt -
Darin Perusich -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Ludwig Nussel -
Markos Chandras -
Matthias Gerstner -
Mykola Krachkovsky -
Nathan -
Patrick Shanahan -
Per Jessen -
Peter Suetterlin -
Robert Munteanu