firewalld-users August 2020

firewalld-users@lists.fedorahosted.org

5 participants
8 discussions

Which Zone is good for a LAMP server?
by Jason Long 02 Sep '20

02 Sep '20

Hello, Is below configuration good for a LAMP server? public (active) target: default icmp-block-inversion: no interfaces: ens192 sources: services: ssh ports: 80/tcp 443/tcp 990/tcp 40000-50000/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: I want to configure Suricata-IDS as IPS mode but the Suricata-IDS document using iptables :(, Can anyone here help me about this goal? https://suricata.readthedocs.io/en/suricata-5.0.3/setting-up-ipsinline-for-… Thank you.

2 5

Re: Adding rich rules for forwarded traffic
by Eric Garver 31 Aug '20

31 Aug '20

On Mon, Aug 31, 2020 at 07:48:45PM +0000, Scott A. Wozny wrote: > Thanks for the reply, Eric. Presently I'm using the 0.6.3-8 version > packaged with CentOS 7 and while the new features look exciting, I'm > staring down a deadline right now and don't have the cycles to build > from source and test. > > At present, it seems firewalld is primarily focused on being a host > firewall to protect services on the host it's running on and while > configuration as a pass-through firewall is possible, configuration > seems to mostly be relegated to interaction with iptables to access > these features. That is correct... until the next release. v0.9.0 will have full support for forward and output filtering. Keep an eye on the blog. :) > I can see why that's so based upon the use cases being mostly driven > by being installed on a Linux server and the preponderence of > standalone (and often GUI configured) network firewalls in the market, > but I'm excited to see further developments of the network / > passthrough firewall feature set for virtualized environments. > > Thanks, > > Scott > > ________________________________ > From: Eric Garver <egarver(a)redhat.com> > Sent: August 31, 2020 8:49 AM > To: Scott A. Wozny <sawozny(a)hotmail.com> > Cc: firewalld-users(a)lists.fedorahosted.org <firewalld-users(a)lists.fedorahosted.org> > Subject: Re: Adding rich rules for forwarded traffic > > On Sun, Aug 30, 2020 at 12:08:12AM -0000, Scott A. Wozny wrote: > > Can --add-rich-rule be used to add rules to the FORWARD chain? > > Not in current releases. I just merged support [1] for this the other > day. As such, it will be in the v0.9.0 release which I will probably > drop within a week. I want to write a blog about it first. > > If you have the time I'd really appreciate some testing on this new > feature. > > [1]: https://github.com/firewalld/firewalld/pull/639 > > > I’ve > > got a multi-interface firewall with an “internet” zone and a > > “webservers” zone. I used nmcli to add the connections to those zones > > and the results of a --list-all-zones shows me the zones have the > > correct interfaces. The OS also knows how to get to the web servers > > from the interface in the internet zone as I can make a port 80 > > connection from a system in the internet segment when firewalld is > > off. So, I turned firewalld on and added a rich rule with this > > command: > > > > sudo firewall-cmd --zone=internet --add-rich-rule='rule family=ipv4 > > service name=http destination address=10.1.4.2 accept' > > > > The rule takes, but I cannot make a connection from a machine on the > > “internet” segment to the 10.1.4.2 server, even though I could when > > firewalld was off. So I took a look at an iptables -S and I see my > > rich rule was added, but to the IN_internet_ALLOW chain: > > > > -A IN_internet_allow -d 10.1.4.2/32 -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT > > > > So, it seemed obvious to me that since the destination was on a > > network off a different interface within the firewall system it should > > have been put in the FWDI_internet_allow chain, but it wasn’t. Did I > > do something wrong or does firewalld not add rich rules to FORWARD > > chains, when appropriate? I can do this with a direct rule if I need > > to, but they’re ugly and I’d rather use the “prettiest” command > > available, when I can. > > > > Also, when writing the rule I tried to use destination ipset=”myipset” > > (which I've previously declared and put 2 addresses in) but got back a > > syntax error. Looking through the man pages it appears that ipset can > > only be used for sources in rich rules. > > You are correct. source only. > > > Am I reading that right and, if so, does anyone have any insight into > > why the restriction? > > I don't think there is any real restriction. Probably only because no > one has added support. But with policy objects (linked above) I'm not > sure it's useful since the policy can define the "destination". > > > I can use multiple rules with IPs and / or arrange my addressing so I > > can use CIDR notation, but ipsets would make the FW ruleset read SO > > much clearer I thought I’d ask here to see if there was a trick I was > > missing. > > rich rules support CIDR notation. > > _______________________________________________ > firewalld-users mailing list -- firewalld-users(a)lists.fedorahosted.org > To unsubscribe send an email to firewalld-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/firewalld-users@lists.fedoraho…

1 0

Adding rich rules for forwarded traffic
by Scott A. Wozny 31 Aug '20

31 Aug '20

Can --add-rich-rule be used to add rules to the FORWARD chain? I’ve got a multi-interface firewall with an “internet” zone and a “webservers” zone. I used nmcli to add the connections to those zones and the results of a --list-all-zones shows me the zones have the correct interfaces. The OS also knows how to get to the web servers from the interface in the internet zone as I can make a port 80 connection from a system in the internet segment when firewalld is off. So, I turned firewalld on and added a rich rule with this command: sudo firewall-cmd --zone=internet --add-rich-rule='rule family=ipv4 service name=http destination address=10.1.4.2 accept' The rule takes, but I cannot make a connection from a machine on the “internet” segment to the 10.1.4.2 server, even though I could when firewalld was off. So I took a look at an iptables -S and I see my rich rule was added, but to the IN_internet_ALLOW chain: -A IN_internet_allow -d 10.1.4.2/32 -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT So, it seemed obvious to me that since the destination was on a network off a different interface within the firewall system it should have been put in the FWDI_internet_allow chain, but it wasn’t. Did I do something wrong or does firewalld not add rich rules to FORWARD chains, when appropriate? I can do this with a direct rule if I need to, but they’re ugly and I’d rather use the “prettiest” command available, when I can. Also, when writing the rule I tried to use destination ipset=”myipset” (which I've previously declared and put 2 addresses in) but got back a syntax error. Looking through the man pages it appears that ipset can only be used for sources in rich rules. Am I reading that right and, if so, does anyone have any insight into why the restriction? I can use multiple rules with IPs and / or arrange my addressing so I can use CIDR notation, but ipsets would make the FW ruleset read SO much clearer I thought I’d ask here to see if there was a trick I was missing. Thanks, Scott

2 2

Re: Firewalld ICMP types
by Kenneth Porter 29 Aug '20

29 Aug '20

--On Saturday, August 29, 2020 7:09 PM +0000 "Scott A. Wozny" <sawozny(a)hotmail.com> wrote: > I'm sure the mechanics behind that are located inside iptables' code, but > I think I have what I need, at this point. It might be in netfilter, the kernel side of the iptables userspace utilities.

1 0

Firewalld ICMP types
by Scott A. Wozny 29 Aug '20

29 Aug '20

Where does firewalld map it's ICMP types located in /usr/lib/firewalld/icmptypes to actual ICMP types like these: https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml. For example, I don't see anything in echo-request.xml indicating it's ICMP type 8, so how does the firewall know when filtering ICMP packets? Thanks, Scott

2 2

Separate rules for decapsulated incoming IPsec ESP packets
by Philip Prindeville 17 Aug '20

17 Aug '20

Hi. I was trying to debug a Strongswan issue involving GRE-over-IPSec (ESP transport mode) and my decapsulated GRE packets were causing ICMP Unreachables (administrative prohibited). Looking at the ICMP, it was for the GRE packet itself. So I got around the problem by doing: # firewall-cmd --permanent --zone=public --add-protocol=gre But this means that my firewall will now accept cleartext GRE, which (in the case of misconfiguration and the packets not being protected via IPSec encryption) is something that I REALLY don’t want to happen. I’ve not dived into the bowels of firewalld (in fact, I’m more versed in iptables than nftables), but I’ve worked on firewalls before (Cisco IOS, Arno’s Internet Firewall, OpenWrt’s firewall3, etc) over the last 20+ years. It seems to me that packets that are decapsulated and then re-injected into the FORWARD or INPUT chains (in iptables) usually are either just ACCEPT’d or else are passed through a separate but similar chain. Would it make sense to do something similar in firewalld? Otherwise, it looks like I need to dig into making some fairly hairy “rich” rules. Has anyone done that either? Thanks, -Philip

2 1

Rewrite these iptables rules into Firewalld.
by Jason Long 10 Aug '20

10 Aug '20

Hello, I want to conver below iptables to the Firewalld rules and I'm thankful if anyone help me: [code] # Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0 -A INPUT -i lo -j ACCEPT -A INPUT -d 127.0.0.0/8 -j REJECT # Accept all established inbound connections -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow all outbound traffic - you can modify this to only allow certain traffic -A OUTPUT -j ACCEPT # Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL). -A INPUT -p tcp --dport 80 -j ACCEPT -A INPUT -p tcp --dport 443 -j ACCEPT # Allow SSH connections # # The -dport number should be the same port number you set in sshd_config # -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT # Allow ping -A INPUT -p icmp -j ACCEPT # Log iptables denied calls -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 # Drop all other inbound - default deny unless explicitly allowed policy -A INPUT -j DROP -A FORWARD -j DROP [/code] Thank you.

2 1

Re rich rules
by D. Hugh Redelmeier 03 Aug '20

03 Aug '20

[Please excuse the lack of threading. I just switched on email subscription and that prevents "reply" from working in the web interface and it won't work with a non-GUI MUA] Thanks Eric. Eric asked: | On Fri, Jul 31, 2020 at 04:11:51PM -0000, D. Hugh Redelmeier wrote: | | > I had tried a couple of different rich rules with negative priority, | > hoping that they would apply before masquerading, but they didn't seem | > to. I might have made some mistakes in formulating the rule. | > | > From output of sudo firewall-cmd --info-zone=external | > services: ... ssh | > masquerade: yes | > rule priority="-10" family="ipv4" destination address="my.net.ip.addr/24" drop | > | > Even with this rule, I could ssh directly into my LAN from outside. | > Should that not have been blocked by my rich rule? | | No - the above will _not_ block SSH outside --> LAN. I suspect it's only | being allowed due to the issue I linked in my last email [1]. What is | your LAN zone? trusted? internal? My LAN is in zone "internal". The issue you linked (a possibly bogus free pass) applies only to "trusted" as far as I can tell from a quick read. | I think misunderstood what you wanted from your original email. More than likely I have a bogus model and thus speak in confusing ways. ================ In a very abstract level, I like firewalld because the configuration is specified in a declarative way. Up to, but not including, rich rules. This should make configuring firewalls simpler, clearer, and less error prone. That puts a responsibility on the firewalld crew. It should not be assumed that users are as sophisticated as iptables users. I think that the clearest idea of masquerading is or should be: - there is a pool of non-routable addresses used on the local system - there is one routable address used to talk to the wide internet - the masquerade multiplexes/demultiplexes traffic from/to a local address to/from the routable address. Almost all naive users would assume that if one of the non-routable addresses were on a packet on the global side, it should be dropped or rejected. My experiments seem to show that this is not happening. From outside my LAN, I could SSH into the LAN (not just the gateway). I tried (unsuccessfully) to implement this policy with a rich rule. ================ My own configuration is quite odd. I've accommodated it for 20 years using iptables and its precursors: - my local address are, in fact, legitimate global addresses - I want to carve up the subnet so that one portion is masqueraded and another portion is not. The masqueraded portion include machines that haven't been hardened. - the split is not 50-50. The natural way to split is the use address ranges. The efficient way is to use overlapping subnets, with priority to the smaller. I don't expect firewalld to cater to my odd case. But it would be nice if happened to be possible.

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

firewalld-users August 2020