[opensuse-factory] Package firewalld should not yet replace SuSEfirewall2
Now that the date is near when SuSEfirewall2 will be removed I finally looked into what firewalld is offering. My analyses are that firewalld just offers only very basic features. It lacks however more advanced features like rate limiting and control over logging. My conclusion is that SuSEfirewall2 should not yet be replaced by firewalld. First firewalld should at least have the lacking features mentioned above. I don't see any reason why SuSEfirewall2 should currently be replaced. Maintenance on it is minimal, so it could still exits next to firewalld. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-06-25 16:15, Freek de Kruijf wrote:
Now that the date is near when SuSEfirewall2 will be removed I finally looked into what firewalld is offering.
My analyses are that firewalld just offers only very basic features. It lacks however more advanced features like rate limiting and control over logging.
My conclusion is that SuSEfirewall2 should not yet be replaced by firewalld. First firewalld should at least have the lacking features mentioned above.
I don't see any reason why SuSEfirewall2 should currently be replaced. Maintenance on it is minimal, so it could still exits next to firewalld.
I'm only using firewalld in a very limited way, so I cannot provide any empirical data, but there is a "Rich Language" in firewalld to specify some more advanced setups. Check man 5 firewalld.richlanguage It has a `Log` and `Audit` section as well as `Limit`. These sound like what you might be looking for!? Cheers -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Freek de Kruijf <freek@opensuse.org> [06-25-19 10:16]:
Now that the date is near when SuSEfirewall2 will be removed I finally looked into what firewalld is offering.
My analyses are that firewalld just offers only very basic features. It lacks however more advanced features like rate limiting and control over logging.
My conclusion is that SuSEfirewall2 should not yet be replaced by firewalld. First firewalld should at least have the lacking features mentioned above.
I don't see any reason why SuSEfirewall2 should currently be replaced. Maintenance on it is minimal, so it could still exits next to firewalld.
perhaps check out google: firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 0 \ -p tcp --dport 22 -m state --state NEW -m recent --set firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 1 \ -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 30 ---hitcount 4 -j REJECT --reject-with tcp-reset firewall-cmd --reload one example.... -- (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 <paka@opensuse.org> [06-25-19 10:57]:
* Freek de Kruijf <freek@opensuse.org> [06-25-19 10:16]:
Now that the date is near when SuSEfirewall2 will be removed I finally looked into what firewalld is offering.
My analyses are that firewalld just offers only very basic features. It lacks however more advanced features like rate limiting and control over logging.
My conclusion is that SuSEfirewall2 should not yet be replaced by firewalld. First firewalld should at least have the lacking features mentioned above.
I don't see any reason why SuSEfirewall2 should currently be replaced. Maintenance on it is minimal, so it could still exits next to firewalld.
perhaps check out google:
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 0 \ -p tcp --dport 22 -m state --state NEW -m recent --set firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 1 \ -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 30 ---hitcount 4 -j REJECT --reject-with tcp-reset firewall-cmd --reload
and it got wrapped incorrectly :) firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct \ 0 -p tcp --dport 22 -m state --state NEW -m recent --set firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct \ 1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds \ 30 ---hitcount 4 -j REJECT --reject-with tcp-reset firewall-cmd --reload -- (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
Op dinsdag 25 juni 2019 17:00:05 CEST schreef Patrick Shanahan:
* Patrick Shanahan <paka@opensuse.org> [06-25-19 10:57]:
* Freek de Kruijf <freek@opensuse.org> [06-25-19 10:16]:
Now that the date is near when SuSEfirewall2 will be removed I finally looked into what firewalld is offering.
It took some time to get more familiar with firewalld. I have some specific requirements. The firewall log should be available for parsing to report unwanted access to dshield.org. Still I do not understand all the particulars of the elements in firewalld. Even the concept of a zone is still unclear to me. A simple concept is that an interface is connected/belongs to a zone. So in my case the eth0 interface, which is connected to the local network, but is also a server connected to the internet via a router with a NAT firewall should be in the zone external, the default zone. However I would like to make exceptions for the systems in my local network. The question is how to do that. There is a zone trusted or something similar. Should I enter the source addresses of the systems in that local network in such a zone? Furthermore I want services like ssh, smtp, smtps, imaps, etc to be accessible from all over the world, but not imap, only from the local network. I also want ACCEPT messages for these services in the firewall log, but, for ssh, I want to limit access to 3 per minute and also limited logging. Any ideas how to configure firewalld with rich rules? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/08/2019 23.17, Freek de Kruijf wrote:
Op dinsdag 25 juni 2019 17:00:05 CEST schreef Patrick Shanahan:
* Patrick Shanahan <> [06-25-19 10:57]:
* Freek de Kruijf <> [06-25-19 10:16]:
Now that the date is near when SuSEfirewall2 will be removed I finally looked into what firewalld is offering.
It took some time to get more familiar with firewalld. I have some specific requirements. The firewall log should be available for parsing to report unwanted access to dshield.org.
Still I do not understand all the particulars of the elements in firewalld. Even the concept of a zone is still unclear to me. A simple concept is that an interface is connected/belongs to a zone. So in my case the eth0 interface, which is connected to the local network, but is also a server connected to the internet via a router with a NAT firewall should be in the zone external, the default zone.
However I would like to make exceptions for the systems in my local network. The question is how to do that. There is a zone trusted or something similar. Should I enter the source addresses of the systems in that local network in such a zone?
Furthermore I want services like ssh, smtp, smtps, imaps, etc to be accessible from all over the world, but not imap, only from the local network. I also want ACCEPT messages for these services in the firewall log, but, for ssh, I want to limit access to 3 per minute and also limited logging.
Any ideas how to configure firewalld with rich rules?
No. I also have similar questions. I know that I can open ports as I wish, but they become open for all. You can log what happens on the firewall, but I see less options. I guess you choose to attach an interface to a zone, and that defines what ports or services are open or closed by default. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Hi, everything you wanna do can be done with firewalld, and much easier than with susefirewall, even more so because you don't have to worry about IPv4 / IPv6. Let me write up something about what you want to do when it's not half past eleven at night... :) Cheers MH Am Samstag, 24. August 2019, 23:17:11 CEST schrieb Freek de Kruijf:
Op dinsdag 25 juni 2019 17:00:05 CEST schreef Patrick Shanahan:
* Patrick Shanahan <paka@opensuse.org> [06-25-19 10:57]:
* Freek de Kruijf <freek@opensuse.org> [06-25-19 10:16]:
Now that the date is near when SuSEfirewall2 will be removed I finally looked into what firewalld is offering.
It took some time to get more familiar with firewalld. I have some specific requirements. The firewall log should be available for parsing to report unwanted access to dshield.org.
Still I do not understand all the particulars of the elements in firewalld. Even the concept of a zone is still unclear to me. A simple concept is that an interface is connected/belongs to a zone. So in my case the eth0 interface, which is connected to the local network, but is also a server connected to the internet via a router with a NAT firewall should be in the zone external, the default zone.
However I would like to make exceptions for the systems in my local network. The question is how to do that. There is a zone trusted or something similar. Should I enter the source addresses of the systems in that local network in such a zone?
Furthermore I want services like ssh, smtp, smtps, imaps, etc to be accessible from all over the world, but not imap, only from the local network. I also want ACCEPT messages for these services in the firewall log, but, for ssh, I want to limit access to 3 per minute and also limited logging.
Any ideas how to configure firewalld with rich rules?
*Mathias Homann* Mathias.Homann@openSUSE:.org[1] irc: [Lemmy] @ freenode, ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102* -------- [1] mailto:Mathias.Homann@eregion.de -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zaterdag 24 augustus 2019 23:33:25 CEST schreef Mathias Homann:
Hi,
everything you wanna do can be done with firewalld, and much easier than with susefirewall, even more so because you don't have to worry about IPv4 / IPv6.
Let me write up something about what you want to do when it's not half past eleven at night... :)
Cheers MH
Dear Martin, I am patiently awaiting your your write up. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sonntag, 25. August 2019, 14:53:36 CEST schrieb Freek de Kruijf:
Let me write up something about what you want to do when it's not half past eleven at night... :)
Dear Martin, s/Martin/Mathias/ :)
I am patiently awaiting your your write up.
I put it on my blog: https://www.tuxonline.tech/an-introduction-to-firewalld/ Cheers MH -- *Mathias Homann* Mathias.Homann@openSUSE.org[1] telegram: https://telegram.me/lemmy98[2] irc: [lemmy] on freenode and ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 * -------- [1] mailto:Mathias.Homann@eregion.de [2] https://telegram.me/lemmy98 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
One "feature" from SuSEfirewall2 I'd like to see incorporated into firewalld are the logging features that were enabled by default in SuSEfirewall2. Honestly having the ability to see what's being blocked/allowed is of primary importance if one has decided to enabled the firewall on a system, how else can one determine whether it's the firewall that's allowing/blocking a connection or if it's something else like a service not running. This is something I've been wanted to look into but simply haven't had the time. -- Later, Darin On Mon, Aug 26, 2019 at 5:45 AM Mathias Homann <Mathias.Homann@opensuse.org> wrote:
Am Sonntag, 25. August 2019, 14:53:36 CEST schrieb Freek de Kruijf:
Let me write up something about what you want to do when it's not half past eleven at night... :)
Dear Martin, s/Martin/Mathias/ :)
I am patiently awaiting your your write up.
I put it on my blog: https://www.tuxonline.tech/an-introduction-to-firewalld/
Cheers MH -- *Mathias Homann* Mathias.Homann@openSUSE.org[1] telegram: https://telegram.me/lemmy98[2] irc: [lemmy] on freenode and ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
*
-------- [1] mailto:Mathias.Homann@eregion.de [2] https://telegram.me/lemmy98
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/08/2019 18.31, Darin Perusich wrote:
One "feature" from SuSEfirewall2 I'd like to see incorporated into firewalld are the logging features that were enabled by default in SuSEfirewall2. Honestly having the ability to see what's being blocked/allowed is of primary importance if one has decided to enabled the firewall on a system, how else can one determine whether it's the firewall that's allowing/blocking a connection or if it's something else like a service not running. This is something I've been wanted to look into but simply haven't had the time.
firewall-config Menu "options", entry "Change log-denied" -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
That option only logs denied packets, and not allowed packets which is arguably the more important information from an auditing perspective. -- Later, Darin On Mon, Aug 26, 2019 at 5:09 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 26/08/2019 18.31, Darin Perusich wrote:
One "feature" from SuSEfirewall2 I'd like to see incorporated into firewalld are the logging features that were enabled by default in SuSEfirewall2. Honestly having the ability to see what's being blocked/allowed is of primary importance if one has decided to enabled the firewall on a system, how else can one determine whether it's the firewall that's allowing/blocking a connection or if it's something else like a service not running. This is something I've been wanted to look into but simply haven't had the time.
firewall-config
Menu "options", entry "Change log-denied"
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-08-27 14:29, Darin Perusich wrote:
That option only logs denied packets, and not allowed packets which is arguably the more important information from an auditing perspective.
-- Later, Darin
There doesn't seem to be a blanket setting for this, but it can be done using the rich language for rules, see man 5 firewalld.richlanguage There are Audit and Log settings on a per rule (per zone) basis. The RHEL documentation [1] is also fairly comprehensive I think. Cheers [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op dinsdag 27 augustus 2019 14:29:53 CEST schreef Darin Perusich:
That option only logs denied packets, and not allowed packets which is arguably the more important information from an auditing perspective.
-- Later, Darin
Carlos mentioned it already, you can use a rich rule, but not how. Suppose you have just: firewall-cmd --permanent --zone=external --add-service=apache2-ssl to enable https access to your webserver. To log all start connections to this port you need to replace it with: firewall-cmd --permanent --zone=external --add-rich-rule='rule service name="apache2-ssl" log prefix="SOME_TEXT " level="info" limit value="1/m"' You may leave out level and limit. Note the space at the end of the prefix text. Also read the bug report on bugzilla #1147153 with a temporary patch for firewall-cmd to have this prefix text proper in the firewall log. Otherwise parsing the firewall log is more complicated. Similar for other services or ports. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2019-08-26 at 11:45 +0200, Mathias Homann wrote:
I put it on my blog: https://www.tuxonline.tech/an-introduction-to-firewalld/
Thank you. Here come a few remarks.
"A zone in firewalld is a “group” of services"
That's a strange definition. I'd rather define it as a group of *interfaces* that share a certain trust level. The official documentation says "A firewall zone defines the trust level for a connection, interface or source address binding."( https://firewalld.org/documentation/zone/). One thing worth mentioning about zones is that commands normally affect packets *originating* from a given zone (i.e. "--zone=A --add- service=http" allows incoming HTTP traffic from zone "A"). But there's one important exception: the --add-masquerade command (and the "masquerade" rich rule) affects *outgoing* packets for the given zone. I for one didn't realize that immediately, and I found it hard to write a rule saying "masquerade packets going to zone B, but only if they originate from zone A". (*) About your configuration example: rather then using --permanent and finish with "firewall-cmd --reload", I'd prefer applying new rules to the current state (without --permanent), test, and finish with "firewall-cmd --runtime-to-permanent". It's mostly a matter of taste, but it may be easier for beginners because effects of new rules can be examined immediately. Also, there are typos ("--add=service=https") in your example. Rich rules and direct rules: this is where the fun begins, and where the upstream docs are also somewhat sparse. At least I found it non- obvious how to construct new rich rules. So I'd appreciate more information in that section :-) I guess many would appreciate a cheat sheet for "how do I <X> with firewalld", where <X> is something that used to be done with SuSEfirewall2. Regards Martin (*) In case you wonder: the solution that worked for me was adding a rich rule rule family="ipv4" source address="192.168.X.Y/24" masquerade to the rule set of zone "B", where the above address was associated with an interface in zone "A". I did not find a way to express this in terms of zones exclusively.
Am Donnerstag, 29. August 2019, 17:24:06 CEST schrieb Martin Wilck:
About your configuration example: rather then using --permanent and finish with "firewall-cmd --reload", I'd prefer applying new rules to the current state (without --permanent), test, and finish with "firewall-cmd --runtime-to-permanent". It's mostly a matter of taste, but it may be easier for beginners because effects of new rules can be examined immediately. Also, there are typos ("--add=service=https") in your example.
actually: I learned to handle firewalld before the option --runtime-to- permanent existed... Anyway thanks for pointing out the typos :) re: masquerading, rich rules and direct rules: This article's an *introduction* to firewalld, I'm planning on a second one for the advanced topics... Cheers MH -- *Mathias Homann* Mathias.Homann@openSUSE:.org[1] irc: [Lemmy] @ freenode, ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102* -------- [1] mailto:Mathias.Homann@eregion.de -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 29 Aug 2019 15:24:06 +0000 Martin Wilck <Martin.Wilck@suse.com> wrote:
On Mon, 2019-08-26 at 11:45 +0200, Mathias Homann wrote:
(*) In case you wonder: the solution that worked for me was adding a rich rule
rule family="ipv4" source address="192.168.X.Y/24" masquerade
to the rule set of zone "B", where the above address was associated with an interface in zone "A". I did not find a way to express this in terms of zones exclusively.
Or in summary: no, it is not ready. That said, I never tried any serious firewalling with susefirewall2 either. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2019-08-30 at 00:38 +0200, Michal Suchánek wrote:
On Thu, 29 Aug 2019 15:24:06 +0000 Martin Wilck <Martin.Wilck@suse.com> wrote:
On Mon, 2019-08-26 at 11:45 +0200, Mathias Homann wrote: (*) In case you wonder: the solution that worked for me was adding a rich rule
rule family="ipv4" source address="192.168.X.Y/24" masquerade
to the rule set of zone "B", where the above address was associated with an interface in zone "A". I did not find a way to express this in terms of zones exclusively.
Or in summary: no, it is not ready. That said, I never tried any serious firewalling with susefirewall2 either.
What bothers me more is that one of the advertized advantages of firewalld, playing nicely with libvirt's virtual networking, doesn't work for me on openSUSE. I keep typing firewall-cmd commands to fix packet flow between virtual and real networks. I'm probably just missing something... The positive side of it is that firewalld at least enables me to fix this stuff dynamically, without having to disable or reload the complete rule set. Cheers, Martin N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Martin Wilck wrote:
What bothers me more is that one of the advertized advantages of firewalld, playing nicely with libvirt's virtual networking, doesn't work for me on openSUSE. I keep typing firewall-cmd commands to fix packet flow between virtual and real networks. I'm probably just missing something... Could you please give us some examples of your FirewallD commands for LibvirtD guests? How you integrated these FirewallD commands?
Until now, FirewallD works acceptable on my Desktop, but I have trouble with LibvirtD KVM guests, OpenVPN networks, Docker and LXC. And I have trouble with my DLNA client which accesses my MythTV server. (Also with SuSEfirewall2 I had to write custom script rules for DLNA access.) Currently I locked SuSEfirewall2 so that the package management could not remove the package. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2019-09-05 at 10:23 +0200, Bjoern Voigt wrote:
Martin Wilck wrote:
What bothers me more is that one of the advertized advantages of firewalld, playing nicely with libvirt's virtual networking, doesn't work for me on openSUSE. I keep typing firewall-cmd commands to fix packet flow between virtual and real networks. I'm probably just missing something... Could you please give us some examples of your FirewallD commands for LibvirtD guests? How you integrated these FirewallD commands?
Very simple, I have an "internal" zone which basically allows every traffic, and I do something like firewall-cmd --zone=internal --change-interface=virbr0 However, my expectation was that this wouldn't be necessary. https://libvirt.org/firewall.html suggests that it basically should just autmagically work out of the box with a special zone called "libvirt", but for that we'd need firewalld 0.7.0 or newer. Which begs the question why TW is still at firewalld 0.6.3, 3 releases behind upstream. Even the devel project is still at 0.6.4. Martin
Until now, FirewallD works acceptable on my Desktop, but I have trouble with LibvirtD KVM guests, OpenVPN networks, Docker and LXC.
And I have trouble with my DLNA client which accesses my MythTV server. (Also with SuSEfirewall2 I had to write custom script rules for DLNA access.)
Currently I locked SuSEfirewall2 so that the package management could not remove the package.
Greetings, Björn
On Fri, Sep 06, 2019 at 06:18:38AM +0000, Martin Wilck wrote:
Which begs the question why TW is still at firewalld 0.6.3, 3 releases behind upstream. Even the devel project is still at 0.6.4.
I will update firewalld in the next week. Sorry for the inconvenience! Cheers, Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op maandag 26 augustus 2019 11:45:30 CEST schreef Mathias Homann:
Am Sonntag, 25. August 2019, 14:53:36 CEST schrieb Freek de Kruijf:
Let me write up something about what you want to do when it's not half past eleven at night... :)
Dear Martin,
s/Martin/Mathias/ :)
I am patiently awaiting your your write up.
I put it on my blog: https://www.tuxonline.tech/an-introduction-to-firewalld/
Cheers MH
I found a comprehensive article about firewalld on this web page: https://www.linuxjournal.com/content/understanding-firewalld-multi-zone-conf... It explains the flow of packages through the firewall, which was the last thing I did not understand about firewalld. I finally decided to have two zones, internal and external. The zone internal only has local source addresses, the addresses in my local network, 192.../24, fe80::/8 and <ipv6-prefix>/48, which I got from my provider. The zone external contains the only wired interface and is the default zone. The internal zone accepts all the configured services without logging, the external zone accepts a subset of these services, which are accepted by rich rules with sometimes limited logging and sometimes limited accept rate. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op maandag 2 september 2019 10:53:19 CEST schreef Freek de Kruijf:
I finally decided to have two zones, internal and external. The zone internal only has local source addresses, the addresses in my local network, 192.../24, fe80::/8 and <ipv6-prefix>/48, which I got from my provider. The zone external contains the only wired interface and is the default zone.
"fe80::/8" should be "fe80::/16". Just in case my server is bothered with pounding packages from a certain IP address I also use the zone drop firewall-cmd --zone=drop -add-address=<pounding-IP-address> -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2019-09-02 at 10:53 +0200, Freek de Kruijf wrote:
I found a comprehensive article about firewalld on this web page:
https://www.linuxjournal.com/content/understanding-firewalld-multi-zone-conf...
I'm not sure if I'd call it "comprehensive", but it's a well-written introduction. And I liked this: "Firewalld is an under-documented firewall configuration tool with more potential than many people realize". I wouldn't concur that the author's statement that the concept of zones is truly "innovative". SuSEfirewall2 had a very similar concept. To me, the innovative part is mostly that you can easily change the rule set without a full firewall service reload.
I finally decided to have two zones, internal and external.
Don't take it personally, but it seems to me that yours is a rather basic setup :-) Best regards, Martin
participants (10)
-
Bjoern Voigt -
Carlos E. R. -
Christian Neyers -
Darin Perusich -
Freek de Kruijf -
Martin Wilck -
Mathias Homann -
Michal Rostecki -
Michal Suchánek -
Patrick Shanahan