How do I get a specific text in the firewall log for specified tcp ports in zone public?
Using firewalld version 1.0.1, using rsyslog to collect firewall log messages with standard definition for /var/log/filewall. I have eth0 in zone public. In zone internal I have a number of addresses, mainly local, as sources, a port, and a few services, to allow access to this port and the services from the sources. In zone public I have a few ports to allow access to with o.a.: "firewall-cmd --add-port=8000/tcp --zone=public --permanent". A number of port forwards of other ports to these ports with o.a.: "firewall-cmd --add-forward-port=port=5555:proto=tcp:toport=8000 --permanent". And for all other ports a number of the following rich rules o.a.: firewall-cmd --add-rich-rule='rule port port=5556-7546 protocol=tcp log prefix="SPECIFICTEXT " reject' --zone=public --permanent where ports like 5556 and 7546 are port numbers which cover all other ports from 1 to 65535. When I start tcpdump on eth0 and a specific port in the ones in the rich rules, and connect from an ip address not in the source in internal, I do see packets coming in. However I don't see any message coming in in the firewall log.
How do I get these messages in that log?
When I have the same rich rule in zone internal for a specific range of ports and I connect to such a port from a source in zone internal I do get a log entry in /var/log/firewall.
On 11/9/2021 9:20 AM, Freek de Kruijf wrote:
Using firewalld version 1.0.1
Which OS and back-end? If iptables, try dumping the resulting rules with "iptables -L -v -n" to see what firewalld generated. (You could post the output to a pastebin and share the link here.)
I use openSUSE Tumbleweed and FirewallBackend=nftables. https://pastebin.com/RZ8971Dn contains output of "nft list ruleset" The reason to use nfttables is that iptables got the obsolete tag.
On Tue, Nov 09, 2021 at 05:20:06PM -0000, Freek de Kruijf wrote:
Using firewalld version 1.0.1, using rsyslog to collect firewall log messages with standard definition for /var/log/filewall. I have eth0 in zone public. In zone internal I have a number of addresses, mainly local, as sources, a port, and a few services, to allow access to this port and the services from the sources. In zone public I have a few ports to allow access to with o.a.: "firewall-cmd --add-port=8000/tcp --zone=public --permanent". A number of port forwards of other ports to these ports with o.a.: "firewall-cmd --add-forward-port=port=5555:proto=tcp:toport=8000 --permanent". And for all other ports a number of the following rich rules o.a.: firewall-cmd --add-rich-rule='rule port port=5556-7546 protocol=tcp log prefix="SPECIFICTEXT " reject' --zone=public --permanent where ports like 5556 and 7546 are port numbers which cover all other ports from 1 to 65535. When I start tcpdump on eth0 and a specific port in the ones in the rich rules, and connect from an ip address not in the source in internal, I do see packets coming in. However I don't see any message coming in in the firewall log.
How do I get these messages in that log?
When I have the same rich rule in zone internal for a specific range of ports and I connect to such a port from a source in zone internal I do get a log entry in /var/log/firewall.
The log action goes to the kernel log. Check dmesg.
$ dmesg
It sound like this RFE may be what you want:
There are no firewall messages in dmesg.
I can't use LogDenied in the .conf file because I need to control the prefix text.
On Tue, Nov 09, 2021 at 08:48:57PM -0000, Freek de Kruijf wrote:
There are no firewall messages in dmesg.
I can't use LogDenied in the .conf file because I need to control the prefix text.
Can you verify the log rule is in the firewall backend (nftables)?
# firewall-cmd --zone public --add-rich-rule='rule protocol value=tcp log prefix="FOOBAR: " reject' success
# nft list ruleset |grep -C5 tcp [..] chain filter_IN_public_log { meta l4proto tcp ct state { new, untracked } log prefix "FOOBAR: " }
chain filter_IN_public_deny { meta l4proto tcp ct state { new, untracked } reject }
Here you can see a log rule and a reject rule.
Are you sure the test traffic is ingressing the public zone? It should be received on eth0 based on the details you gave.
Eric.
Op woensdag 10 november 2021 14:57:24 CET schreef Eric Garver:
On Tue, Nov 09, 2021 at 08:48:57PM -0000, Freek de Kruijf wrote:
There are no firewall messages in dmesg.
I can't use LogDenied in the .conf file because I need to control the prefix text.
Can you verify the log rule is in the firewall backend (nftables)?
# firewall-cmd --zone public --add-rich-rule='rule protocol value=tcp log prefix="FOOBAR: " reject' success
# nft list ruleset |grep -C5 tcp [..] chain filter_IN_public_log { meta l4proto tcp ct state { new, untracked } log prefix "FOOBAR: " }
chain filter_IN_public_deny { meta l4proto tcp ct state { new, untracked } reject }Here you can see a log rule and a reject rule.
Are you sure the test traffic is ingressing the public zone? It should be received on eth0 based on the details you gave.
Eric.
I have in nftables for zone internal with source 192.168.178.0/24:
chain filter_IN_internal_log { tcp dport 26-30 ct state { new, untracked } log prefix "SPECIAAL" }
chain filter_IN_internal_deny { tcp dport 26-30 ct state { new, untracked } reject }
I do find entries for this in the firewall log for connections coming from 192.168.178.6.
I have in nftables for zone public for all other sources:
chain filter_IN_public_log { tcp dport 24-79 ct state { new, untracked } log prefix "DSHIELDINPUT " }
chain filter_IN_public_deny { tcp dport 24-79 ct state { new, untracked } reject }
This does not result in entries in the firewall log, although tcpdump shows tcp packets coming in on port 26.
Op woensdag 10 november 2021 14:57:24 CET schreef Eric Garver:
On Tue, Nov 09, 2021 at 08:48:57PM -0000, Freek de Kruijf wrote:
There are no firewall messages in dmesg.
I can't use LogDenied in the .conf file because I need to control the prefix text.
Can you verify the log rule is in the firewall backend (nftables)?
# firewall-cmd --zone public --add-rich-rule='rule protocol value=tcp log prefix="FOOBAR: " reject' success
# nft list ruleset |grep -C5 tcp [..] chain filter_IN_public_log { meta l4proto tcp ct state { new, untracked } log prefix "FOOBAR: " }
chain filter_IN_public_deny { meta l4proto tcp ct state { new, untracked } reject }Here you can see a log rule and a reject rule.
Are you sure the test traffic is ingressing the public zone? It should be received on eth0 based on the details you gave.
Eric.
I repeated the test using iptables as the backend, and got the same result. Entries in the firewall log when packages come from the internal IP address, and nothing when packages come from an external address. tcpdump always shows incoming tcp packages.
On Wed, Nov 10, 2021 at 04:45:52PM +0100, Freek de Kruijf wrote:
Op woensdag 10 november 2021 14:57:24 CET schreef Eric Garver:
On Tue, Nov 09, 2021 at 08:48:57PM -0000, Freek de Kruijf wrote:
There are no firewall messages in dmesg.
I can't use LogDenied in the .conf file because I need to control the prefix text.
Can you verify the log rule is in the firewall backend (nftables)?
# firewall-cmd --zone public --add-rich-rule='rule protocol value=tcp log prefix="FOOBAR: " reject' success
# nft list ruleset |grep -C5 tcp [..] chain filter_IN_public_log { meta l4proto tcp ct state { new, untracked } log prefix "FOOBAR: " }
chain filter_IN_public_deny { meta l4proto tcp ct state { new, untracked } reject }Here you can see a log rule and a reject rule.
Are you sure the test traffic is ingressing the public zone? It should be received on eth0 based on the details you gave.
Eric.
I repeated the test using iptables as the backend, and got the same result. Entries in the firewall log when packages come from the internal IP address, and nothing when packages come from an external address. tcpdump always shows incoming tcp packages.
Are you sure the test traffic is ingressing the public zone? It should be received on eth0 based on the details you gave.
Can you answer this? I expect your test traffic is originating from a different zone. Your original email said you're also using the "internal" zone.
In that case, you need to also open the ports in the internal zone. In firewalld, packets ingress one and only one zone.
Op woensdag 10 november 2021 17:08:19 CET schreef Eric Garver:
On Wed, Nov 10, 2021 at 04:45:52PM +0100, Freek de Kruijf wrote:
Op woensdag 10 november 2021 14:57:24 CET schreef Eric Garver:
Are you sure the test traffic is ingressing the public zone? It should be received on eth0 based on the details you gave.
Can you answer this? I expect your test traffic is originating from a different zone. Your original email said you're also using the "internal" zone.
In that case, you need to also open the ports in the internal zone. In firewalld, packets ingress one and only one zone.
I have the interface in the public zone and I have the source 192.168.178.0/24 in the internal zone. My understanding is that all packets coming in on the interface without a source address mentioned in the internal zone enter the public zone. So these last packets should be processed by the rules in that public zone, which apparently does not happen, at least not the ones that finally get rejected.
Currently I don t have processes listening on the ports that are allowed, so I can t say they enter a process. I will look at that later.
I have the interface in the public zone and I have the source 192.168.178.0/24 in the internal zone. My understanding is that all packets coming in on the interface without a source address mentioned in the internal zone enter the public zone. So these last packets should be processed by the rules in that public zone, which apparently does not happen, at least not the ones that finally get rejected.
Hi,
I'm not a firewalld/nftables expert, but from your description, it seems that you want all TCP traffic addressed to a specified port range to be rejected and logged. If so, then rather add your rich rule(s) to the public zone, how about adding them to the internal zone, whose rules are evaluated prior to public's (according to the article: https://www.linuxjournal.com/content/understanding-firewalld-multi-zone-conf...
Op zaterdag 11 december 2021 11:45:22 CET schreef Andrew Moore:
I have the interface in the public zone and I have the source 192.168.178.0/24
in the internal zone. My understanding is that all
packets coming in on the interface without a source address mentioned in the internal zone enter the public zone. So these last packets should be processed by the rules in that public zone, which apparently does not happen, at least not the ones that finally get rejected.
Hi,
I'm not a firewalld/nftables expert, but from your description, it seems that you want all TCP traffic addressed to a specified port range to be rejected and logged. If so, then rather add your rich rule(s) to the public zone, how about adding them to the internal zone, whose rules are evaluated prior to public's (according to the article: https://www.linuxjournal.com/content/understanding-firewalld-multi-zone-con figurations)?
The problem of not appearing of these messages in the log was caused by a an issue in my router and not with the configuration of the firewall.
In the end I could skip the use of firewalld and use directly nftables.
I needed this for the honeypot software on https://github.com/DShield-ISC/ dshield/ to adapt it for the change to nftables instead of iptables, which is declared obsolete.
firewalld-users@lists.stg.fedorahosted.org
-
Andrew Moore -
Eric Garver -
Freek de Kruijf -
Kenneth Porter