* 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.

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

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)

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

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 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

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. 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

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

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 Fri, 2019-08-30 at 00:38 +0200, Michal Suchánek wrote:

On Thu, 29 Aug 2019 15:24:06 +0000 Martin Wilck 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�����Ǩ�

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

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

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