#StackBounty: #networking #firewall #mysql Cannot connect mysql on virtual interface 10.0.0.x

Bounty: 100

I have a trouble to connect mysql running on 10.0.0.5 from 10.0.0.4. This is a virtual network created in Hetzner interface. I think mysql is configured correctly according to a documentation.

enter image description here

Backend 10.0.0.4

root@backend:~# mysql -u root --host=10.0.0.5 --protocol=tcp --port=3306
ERROR 2002 (HY000): Can't connect to MySQL server on '10.0.0.5' (115)
root@backend:~# mysql -u literakl --host=10.0.0.5 --protocol=tcp --port=3306 -p
Enter password:
ERROR 2002 (HY000): Can't connect to MySQL server on '10.0.0.5' (115)

root@backend:~# telnet 10.0.0.5 3306
Trying 10.0.0.5...
telnet: Unable to connect to remote host: No route to host

root@backend:~# ssh root@10.0.0.5
The authenticity of host '10.0.0.5 (10.0.0.5)' can't be established.
ECDSA key fingerprint is SHA256:iDrbbDdMK1XKRrb0O3lZ899K/oQmTFtu4ju75h+te0Y.
10.0.0.5

root@backend:~# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=63 time=1.75 ms

root@backend:~# nmap 10.0.0.0/24
Starting Nmap 7.70 ( https://nmap.org ) at 2021-06-30 20:35 CEST
Nmap scan report for 10.0.0.5
Host is up (0.0011s latency).
Not shown: 999 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
Nmap done: 256 IP addresses (5 hosts up) scanned in 150.32 seconds

Secondary 10.0.0.5

root@secondary:~# less /etc/mysql/mariadb.conf.d/50-server.cnf
bind-address            = 0.0.0.0
#skip-networking=1
#skip-bind-address

root@secondary:~# ufw status
Status: active
33060                      ALLOW       10.0.0.4
33061                      ALLOW       10.0.0.4
3306                       ALLOW       10.0.0.4
3306/tcp                   ALLOW       Anywhere
3306/tcp (v6)              ALLOW       Anywhere (v6)

root@secondary:~# netstat -ln | grep mysql
unix  2      [ ACC ]     STREAM     LISTENING     9927594  /run/mysqld/mysqld.sock

root@secondary:~# lsof -i -P -n | grep LISTEN
mysqld    6749 mysql   21u  IPv4 9927593      0t0  TCP *:3306 (LISTEN)

root@secondary:~# telnet 10.0.0.5 3306
Trying 10.0.0.5...
Connected to 10.0.0.5.
5.5.5-10.3.29-MariaDB-0+deb10u1$(u:]H1mysql_native_password

root@secondary:~# ip address
3: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 86:00:00:b8:0d:95 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.5/32 brd 10.0.0.5 scope global dynamic ens10
       valid_lft 54105sec preferred_lft 54105sec
    inet6 fe80::8400:ff:feb8:d95/64 scope link
       valid_lft forever preferred_lft forever

root@secondary:~# mysql -u literakl --host=10.0.0.5 --protocol=tcp --port=3306 -p
Your MariaDB connection id is 37
Server version: 10.3.29-MariaDB-0+deb10u1 Debian 10

MariaDB [(none)]> SELECT User, Host FROM mysql.user;
| User             | Host      |
| literakl         | %         |
| literakl         | localhost |

I wonder, what could be wrong? The port 3306 is open on the secondary service. I have even tried to turn off the firewall on both servers but still no luck. Weird.

Update 1:

root@secondary:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.1.1      0.0.0.0         UG    0      0        0 eth0
10.0.0.0        10.0.0.1        255.255.0.0     UG    0      0        0 ens10
10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 ens10
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker_gwbridge
172.31.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0

root@secondary:~# ip route list
default via 172.31.1.1 dev eth0
10.0.0.0/16 via 10.0.0.1 dev ens10
10.0.0.1 dev ens10 scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1
172.31.1.1 dev eth0 scope link

root@secondary:~# arp -a
? (10.0.0.1) at d2:74:7f:6e:37:e3 [ether] on ens10
? (172.18.0.3) at 02:42:ac:12:00:03 [ether] on docker_gwbridge
? (172.31.1.1) at d2:74:7f:6e:37:e3 [ether] on eth0
11214.your-cloud.host (195.201.66.70) at 2e:bb:61:a6:0f:84 [ether] on eth0


Get this bounty!!!

#StackBounty: #networking #server #iptables #firewall Can't connect to open secure port on Ubuntu

Bounty: 50

I opened the 8443 port on which I run Clickhouse server. I can connect to SSH on 22 port, I can also connect to 8443 via SSH tunnel, however I can’t connect normally to that host. I’m trying to connect from the Windows machine, if that is related anyhow. I even opened outbound port (pretty sure that it is redundant).

I tried to disable firewall and then I was able to connect. What can be wrong?

user@myhost:~/d/clickhouse$ sudo ufw status
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
9440/tcp                   ALLOW       Anywhere                  
8443/tcp                   ALLOW       Anywhere                  
8443                       ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
9440/tcp (v6)              ALLOW       Anywhere (v6)             
8443 (v6)                  ALLOW       Anywhere (v6)             
8443/tcp (v6)              ALLOW       Anywhere (v6)

user@myhost:~/d/clickhouse$ sudo lsof -iTCP -sTCP:LISTEN -P
COMMAND      PID            USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd-r    841 systemd-resolve   13u  IPv4   26021      0t0  TCP localhost:53 (LISTEN)
vsftpd       901            root    3u  IPv6   26299      0t0  TCP *:21 (LISTEN)
sshd        1037            root    3u  IPv4   29181      0t0  TCP *:22 (LISTEN)
sshd        1037            root    4u  IPv6   29183      0t0  TCP *:22 (LISTEN)
docker-pr  86081            root    4u  IPv6  520074      0t0  TCP *:8088 (LISTEN)
docker-pr 287023            root    4u  IPv6 1831110      0t0  TCP *:8086 (LISTEN)
docker-pr 318522            root    4u  IPv6 2109586      0t0  TCP *:9440 (LISTEN)
docker-pr 318537            root    4u  IPv6 2110806      0t0  TCP *:8443 (LISTEN)
node      354955           user   18u  IPv4 2274703      0t0  TCP localhost:34575 (LISTEN)

user@myhost:~/d/clickhouse$ netstat -an | grep "LISTEN "
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:34575         0.0.0.0:*               LISTEN     
tcp6       0      0 :::21                   :::*                    LISTEN     
tcp6       0      0 :::8086                 :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::8088                 :::*                    LISTEN     
tcp6       0      0 :::8443                 :::*                    LISTEN     
tcp6       0      0 :::9440                 :::*                    LISTEN 

UPDATE:

on the server I ran sudo tcpdump -ni eth0 port 8443 and then on client machine I ran nc -zv 192.168.1.58 8443:

user@myhost:~$ sudo tcpdump -ni eth0 port 8443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:05:51.368952 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434934937 ecr 0,nop,wscale 7], length 0
15:05:52.380268 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434935948 ecr 0,nop,wscale 7], length 0
15:05:54.460280 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434938028 ecr 0,nop,wscale 7], length 0
15:05:58.540705 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434942109 ecr 0,nop,wscale 7], length 0
15:06:06.940802 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434950509 ecr 0,nop,wscale 7], length 0
15:06:23.581056 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434967149 ecr 0,nop,wscale 7], length 0
15:06:56.221198 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434999788 ecr 0,nop,wscale 7], length 0

and nc failed with the message nc: connect to 192.168.1.58 port 8443 (tcp) failed: Connection timed out

The output of sudo ufw status verbose

user@myhost:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  
9440/tcp                   ALLOW IN    Anywhere                  
8443/tcp                   ALLOW IN    Anywhere                  
8443                       ALLOW IN    Anywhere                  
22/tcp (v6)                ALLOW IN    Anywhere (v6)             
9440/tcp (v6)              ALLOW IN    Anywhere (v6)             
8443 (v6)                  ALLOW IN    Anywhere (v6)             
8443/tcp (v6)              ALLOW IN    Anywhere (v6)  

I can connect to service if firewall is disabled:

nc -zv 192.168.1.58 8443 
Connection to 192.168.1.58 8443 port [tcp/*] succeeded!

I can connect to service with IPv4 address if firewall is disabled:
enter image description here


Get this bounty!!!

#StackBounty: #networking #server #iptables #firewall Can't connect to open secure port on Ubuntu

Bounty: 50

I opened the 8443 port on which I run Clickhouse server. I can connect to SSH on 22 port, I can also connect to 8443 via SSH tunnel, however I can’t connect normally to that host. I’m trying to connect from the Windows machine, if that is related anyhow. I even opened outbound port (pretty sure that it is redundant).

I tried to disable firewall and then I was able to connect. What can be wrong?

user@myhost:~/d/clickhouse$ sudo ufw status
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
9440/tcp                   ALLOW       Anywhere                  
8443/tcp                   ALLOW       Anywhere                  
8443                       ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
9440/tcp (v6)              ALLOW       Anywhere (v6)             
8443 (v6)                  ALLOW       Anywhere (v6)             
8443/tcp (v6)              ALLOW       Anywhere (v6)

user@myhost:~/d/clickhouse$ sudo lsof -iTCP -sTCP:LISTEN -P
COMMAND      PID            USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd-r    841 systemd-resolve   13u  IPv4   26021      0t0  TCP localhost:53 (LISTEN)
vsftpd       901            root    3u  IPv6   26299      0t0  TCP *:21 (LISTEN)
sshd        1037            root    3u  IPv4   29181      0t0  TCP *:22 (LISTEN)
sshd        1037            root    4u  IPv6   29183      0t0  TCP *:22 (LISTEN)
docker-pr  86081            root    4u  IPv6  520074      0t0  TCP *:8088 (LISTEN)
docker-pr 287023            root    4u  IPv6 1831110      0t0  TCP *:8086 (LISTEN)
docker-pr 318522            root    4u  IPv6 2109586      0t0  TCP *:9440 (LISTEN)
docker-pr 318537            root    4u  IPv6 2110806      0t0  TCP *:8443 (LISTEN)
node      354955           user   18u  IPv4 2274703      0t0  TCP localhost:34575 (LISTEN)

user@myhost:~/d/clickhouse$ netstat -an | grep "LISTEN "
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:34575         0.0.0.0:*               LISTEN     
tcp6       0      0 :::21                   :::*                    LISTEN     
tcp6       0      0 :::8086                 :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::8088                 :::*                    LISTEN     
tcp6       0      0 :::8443                 :::*                    LISTEN     
tcp6       0      0 :::9440                 :::*                    LISTEN 

UPDATE:

on the server I ran sudo tcpdump -ni eth0 port 8443 and then on client machine I ran nc -zv 192.168.1.58 8443:

user@myhost:~$ sudo tcpdump -ni eth0 port 8443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:05:51.368952 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434934937 ecr 0,nop,wscale 7], length 0
15:05:52.380268 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434935948 ecr 0,nop,wscale 7], length 0
15:05:54.460280 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434938028 ecr 0,nop,wscale 7], length 0
15:05:58.540705 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434942109 ecr 0,nop,wscale 7], length 0
15:06:06.940802 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434950509 ecr 0,nop,wscale 7], length 0
15:06:23.581056 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434967149 ecr 0,nop,wscale 7], length 0
15:06:56.221198 IP 192.168.1.70.59364 > 192.168.1.58.8443: Flags [S], seq 2263747478, win 64240, options [mss 1460,sackOK,TS val 1434999788 ecr 0,nop,wscale 7], length 0

and nc failed with the message nc: connect to 192.168.1.58 port 8443 (tcp) failed: Connection timed out

The output of sudo ufw status verbose

user@myhost:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  
9440/tcp                   ALLOW IN    Anywhere                  
8443/tcp                   ALLOW IN    Anywhere                  
8443                       ALLOW IN    Anywhere                  
22/tcp (v6)                ALLOW IN    Anywhere (v6)             
9440/tcp (v6)              ALLOW IN    Anywhere (v6)             
8443 (v6)                  ALLOW IN    Anywhere (v6)             
8443/tcp (v6)              ALLOW IN    Anywhere (v6)  

I can connect to service if firewall is disabled:

nc -zv 192.168.1.58 8443 
Connection to 192.168.1.58 8443 port [tcp/*] succeeded!

I can connect to service with IPv4 address if firewall is disabled:
enter image description here


Get this bounty!!!

#StackBounty: #networking #centos #firewall #firewalld firewalld rich rules don't drop incoming traffic (CentOS 8 behind a NAT)

Bounty: 50

G’day,

I’ve got a small development server at my office with port 80 and 443 port forwarded from the modem.

To restate the title in the form of a question:

Why doesn’t the firewall drop the incoming traffic from the IPv4 addresses that are listed in the rich rules.

Background:
As you would expect, Bots & Baddies™ are looking for various things that a) don’t exist, and b) would be bad if they they got into if they did exist. So I have a script that pulls IP addresses from Apache logs, which then end up in the firewall after they’ve been curated by me.

However, the firewall isn’t dropping the connections. Addresses that are added on previous days are present in the new rules to be added and the logs again on subsequent days.

Details:
The command that puts in the rich rules is this:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='165.227.87.0/24' reject"

However some rules have extra info:

rule family="ipv4" source address="162.159.244.38" log prefix="Shodan.io" reject

While some are simply:

rule family="ipv4" source address="42.224.165.0/24" reject

(those last two are rules copied from the output of firewall-cmd --list-all)

As shown below, the active zone is public, which isn’t explicitly noted in the rule as I read that without it specified, it applies to the active zone.

While researching this, I realised that I might be in an unusual situation with the Modem port forwarding to the machine, rather than having it in a DMZ or hosted externally. The Apache logs show the internet facing IP addresses for the http/s client machines, and I’ve been assuming that these IPs are the address that presented to the firewall.

(netstat -tn does show a current connection to an external IPv4 address, but I can’t establish if that’s inbound or outbound.)

Warning: ALREADY_ENABLED: rule family='ipv4' source address='201.159.155.0/24' reject was a frequent response until I added logging notes into the rule, now it just happily accepts multiple reject rules for the same subnet.

Since the first time I wrote this question on serverfault.com (and was then told it wasn’t ok to ask this there), I’ve had time to add the aforementioned logging, and have now been been to establish this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 194.195.251.
rule family="ipv4" source address="194.195.251.0/24" log prefix="Sun May 23 21:23:50 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Mon May 24 23:58:51 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Tue May 25 21:25:27 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Wed May 26 21:25:57 UTC 2021" reject

And this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 192.241.196.
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Mon May 24 23:59:25 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Tue May 25 21:26:02 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Wed May 26 21:26:31 UTC 2021" reject

So clearly, this isn’t dropping traffic. (The date/times are the dates added to the firewall.)

In case it’s helpful, here’s the top part of firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  services: cockpit dhcpv6-client http https ssh
  ports: [redacted integer]/tcp [redacted integer]/tcp [redacted integer]-[redacted integer]/udp [redacted integer]-[redacted integer]/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

The rich rules then follow. And because why not, here’s the active zone query:

[user@server ~]# firewall-cmd --get-active-zone
libvirt
  interfaces: virbr0
public
  interfaces: eno1

Other things to note:

  • There is only one Ethernet port on the box.
  • The firewall is reloaded after adding new rules (firewall-cmd --reload)
  • The server reboots every night
  • This server was CentOS Stream, but I converted it to CentOS 8
  • The firewall is active, enabled and functional (firewall-cmd --state returns ‘running’)
  • I’m aware that firewall-cmd --complete-reload exists, but it terminates all connections and that’s not what I need.
  • Some things from the conf file:
    • FirewallBackend=nftables
    • IPv6_rpfilter=yes
    • RFC3964_IPv4=yes

Any ideas?

( List of Rich Rules: https://pastebin.com/qXFMBvqh )

— EDIT —
Under the banner of "This is ridiculous", I put another local IP in the firewall (without –permanent) to test, then ran curl from the CLI. The pre-adding test worked fine, the post-adding test gave me curl: (7) Failed connect to **[redacted]**:80; Connection refused. With that behaving as expected, I cannot work out WHY these other things are not.

Have now turned on official logging (firewall-cmd --set-log-denied=all)

— EDIT 2 —
More info on the scripts in question:

  • The first script parses the Apache logs and establishes a list of IP addresses. Upon that, it puts the firewall-cmd adding commands into a .txt file. (It also looks up Geo-location information, but that’s out of scope here.)
  • The second script reads the .txt file, and executes the firewall-cmd add commands, then runs the firewall reload (--reload)

This allows the .txt file to build up over the weekend if I’m AFK. I inspect the GEO location information prior to running the second script to ensure that any IPs in the same country are more closely inspected to see whether they should be removed from the list.

— EDIT 3 —
Logs shows this:

Jun 21 09:47:42 <SERVER_NAME> kernel: STATE_INVALID_DROP: IN=eno1 OUT= MAC=a8:a1:59:3a:03:14:20:b0:01:c0:a5:26:08:00 SRC=183.158.154.128 DST=<SERVER_INTERNAL_IP> LEN=40 TOS=0x00 PREC=0x00 TTL=44 ID=38952 DF PROTO=TCP SPT=54750 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

There are four of these entries, all at the same millisecond. Interestingly, that IP address is not in the firewall rules at all.


Get this bounty!!!

#StackBounty: #networking #centos #firewall #firewalld firewalld rich rules don't drop incoming traffic (CentOS 8 behind a NAT)

Bounty: 50

G’day,

I’ve got a small development server at my office with port 80 and 443 port forwarded from the modem.

To restate the title in the form of a question:

Why doesn’t the firewall drop the incoming traffic from the IPv4 addresses that are listed in the rich rules.

Background:
As you would expect, Bots & Baddies™ are looking for various things that a) don’t exist, and b) would be bad if they they got into if they did exist. So I have a script that pulls IP addresses from Apache logs, which then end up in the firewall after they’ve been curated by me.

However, the firewall isn’t dropping the connections. Addresses that are added on previous days are present in the new rules to be added and the logs again on subsequent days.

Details:
The command that puts in the rich rules is this:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='165.227.87.0/24' reject"

However some rules have extra info:

rule family="ipv4" source address="162.159.244.38" log prefix="Shodan.io" reject

While some are simply:

rule family="ipv4" source address="42.224.165.0/24" reject

(those last two are rules copied from the output of firewall-cmd --list-all)

As shown below, the active zone is public, which isn’t explicitly noted in the rule as I read that without it specified, it applies to the active zone.

While researching this, I realised that I might be in an unusual situation with the Modem port forwarding to the machine, rather than having it in a DMZ or hosted externally. The Apache logs show the internet facing IP addresses for the http/s client machines, and I’ve been assuming that these IPs are the address that presented to the firewall.

(netstat -tn does show a current connection to an external IPv4 address, but I can’t establish if that’s inbound or outbound.)

Warning: ALREADY_ENABLED: rule family='ipv4' source address='201.159.155.0/24' reject was a frequent response until I added logging notes into the rule, now it just happily accepts multiple reject rules for the same subnet.

Since the first time I wrote this question on serverfault.com (and was then told it wasn’t ok to ask this there), I’ve had time to add the aforementioned logging, and have now been been to establish this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 194.195.251.
rule family="ipv4" source address="194.195.251.0/24" log prefix="Sun May 23 21:23:50 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Mon May 24 23:58:51 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Tue May 25 21:25:27 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Wed May 26 21:25:57 UTC 2021" reject

And this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 192.241.196.
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Mon May 24 23:59:25 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Tue May 25 21:26:02 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Wed May 26 21:26:31 UTC 2021" reject

So clearly, this isn’t dropping traffic. (The date/times are the dates added to the firewall.)

In case it’s helpful, here’s the top part of firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  services: cockpit dhcpv6-client http https ssh
  ports: [redacted integer]/tcp [redacted integer]/tcp [redacted integer]-[redacted integer]/udp [redacted integer]-[redacted integer]/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

The rich rules then follow. And because why not, here’s the active zone query:

[user@server ~]# firewall-cmd --get-active-zone
libvirt
  interfaces: virbr0
public
  interfaces: eno1

Other things to note:

  • There is only one Ethernet port on the box.
  • The firewall is reloaded after adding new rules (firewall-cmd --reload)
  • The server reboots every night
  • This server was CentOS Stream, but I converted it to CentOS 8
  • The firewall is active, enabled and functional (firewall-cmd --state returns ‘running’)
  • I’m aware that firewall-cmd --complete-reload exists, but it terminates all connections and that’s not what I need.
  • Some things from the conf file:
    • FirewallBackend=nftables
    • IPv6_rpfilter=yes
    • RFC3964_IPv4=yes

Any ideas?

( List of Rich Rules: https://pastebin.com/qXFMBvqh )

— EDIT —
Under the banner of "This is ridiculous", I put another local IP in the firewall (without –permanent) to test, then ran curl from the CLI. The pre-adding test worked fine, the post-adding test gave me curl: (7) Failed connect to **[redacted]**:80; Connection refused. With that behaving as expected, I cannot work out WHY these other things are not.

Have now turned on official logging (firewall-cmd --set-log-denied=all)

— EDIT 2 —
More info on the scripts in question:

  • The first script parses the Apache logs and establishes a list of IP addresses. Upon that, it puts the firewall-cmd adding commands into a .txt file. (It also looks up Geo-location information, but that’s out of scope here.)
  • The second script reads the .txt file, and executes the firewall-cmd add commands, then runs the firewall reload (--reload)

This allows the .txt file to build up over the weekend if I’m AFK. I inspect the GEO location information prior to running the second script to ensure that any IPs in the same country are more closely inspected to see whether they should be removed from the list.


Get this bounty!!!

#StackBounty: #networking #centos #firewall #firewalld firewalld rich rules don't drop incoming traffic (CentOS 8 behind a NAT)

Bounty: 50

G’day,

I’ve got a small development server at my office with port 80 and 443 port forwarded from the modem.

To restate the title in the form of a question:

Why doesn’t the firewall drop the incoming traffic from the IPv4 addresses that are listed in the rich rules.

Background:
As you would expect, Bots & Baddies™ are looking for various things that a) don’t exist, and b) would be bad if they they got into if they did exist. So I have a script that pulls IP addresses from Apache logs, which then end up in the firewall after they’ve been curated by me.

However, the firewall isn’t dropping the connections. Addresses that are added on previous days are present in the new rules to be added and the logs again on subsequent days.

Details:
The command that puts in the rich rules is this:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='165.227.87.0/24' reject"

However some rules have extra info:

rule family="ipv4" source address="162.159.244.38" log prefix="Shodan.io" reject

While some are simply:

rule family="ipv4" source address="42.224.165.0/24" reject

(those last two are rules copied from the output of firewall-cmd --list-all)

As shown below, the active zone is public, which isn’t explicitly noted in the rule as I read that without it specified, it applies to the active zone.

While researching this, I realised that I might be in an unusual situation with the Modem port forwarding to the machine, rather than having it in a DMZ or hosted externally. The Apache logs show the internet facing IP addresses for the http/s client machines, and I’ve been assuming that these IPs are the address that presented to the firewall.

(netstat -tn does show a current connection to an external IPv4 address, but I can’t establish if that’s inbound or outbound.)

Warning: ALREADY_ENABLED: rule family='ipv4' source address='201.159.155.0/24' reject was a frequent response until I added logging notes into the rule, now it just happily accepts multiple reject rules for the same subnet.

Since the first time I wrote this question on serverfault.com (and was then told it wasn’t ok to ask this there), I’ve had time to add the aforementioned logging, and have now been been to establish this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 194.195.251.
rule family="ipv4" source address="194.195.251.0/24" log prefix="Sun May 23 21:23:50 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Mon May 24 23:58:51 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Tue May 25 21:25:27 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Wed May 26 21:25:57 UTC 2021" reject

And this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 192.241.196.
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Mon May 24 23:59:25 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Tue May 25 21:26:02 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Wed May 26 21:26:31 UTC 2021" reject

So clearly, this isn’t dropping traffic. (The date/times are the dates added to the firewall.)

In case it’s helpful, here’s the top part of firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  services: cockpit dhcpv6-client http https ssh
  ports: [redacted integer]/tcp [redacted integer]/tcp [redacted integer]-[redacted integer]/udp [redacted integer]-[redacted integer]/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

The rich rules then follow. And because why not, here’s the active zone query:

[user@server ~]# firewall-cmd --get-active-zone
libvirt
  interfaces: virbr0
public
  interfaces: eno1

Other things to note:

  • There is only one Ethernet port on the box.
  • The firewall is reloaded after adding new rules (firewall-cmd --reload)
  • The server reboots every night
  • This server was CentOS Stream, but I converted it to CentOS 8
  • The firewall is active, enabled and functional (firewall-cmd --state returns ‘running’)
  • I’m aware that firewall-cmd --complete-reload exists, but it terminates all connections and that’s not what I need.
  • Some things from the conf file:
    • FirewallBackend=nftables
    • IPv6_rpfilter=yes
    • RFC3964_IPv4=yes

Any ideas?

( List of Rich Rules: https://pastebin.com/qXFMBvqh )

— EDIT —
Under the banner of "This is ridiculous", I put another local IP in the firewall (without –permanent) to test, then ran curl from the CLI. The pre-adding test worked fine, the post-adding test gave me curl: (7) Failed connect to **[redacted]**:80; Connection refused. With that behaving as expected, I cannot work out WHY these other things are not.

Have now turned on official logging (firewall-cmd --set-log-denied=all)

— EDIT 2 —
More info on the scripts in question:

  • The first script parses the Apache logs and establishes a list of IP addresses. Upon that, it puts the firewall-cmd adding commands into a .txt file. (It also looks up Geo-location information, but that’s out of scope here.)
  • The second script reads the .txt file, and executes the firewall-cmd add commands, then runs the firewall reload (--reload)

This allows the .txt file to build up over the weekend if I’m AFK. I inspect the GEO location information prior to running the second script to ensure that any IPs in the same country are more closely inspected to see whether they should be removed from the list.


Get this bounty!!!

#StackBounty: #networking #centos #firewall #firewalld firewalld rich rules don't drop incoming traffic (CentOS 8 behind a NAT)

Bounty: 50

G’day,

I’ve got a small development server at my office with port 80 and 443 port forwarded from the modem.

To restate the title in the form of a question:

Why doesn’t the firewall drop the incoming traffic from the IPv4 addresses that are listed in the rich rules.

Background:
As you would expect, Bots & Baddies™ are looking for various things that a) don’t exist, and b) would be bad if they they got into if they did exist. So I have a script that pulls IP addresses from Apache logs, which then end up in the firewall after they’ve been curated by me.

However, the firewall isn’t dropping the connections. Addresses that are added on previous days are present in the new rules to be added and the logs again on subsequent days.

Details:
The command that puts in the rich rules is this:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='165.227.87.0/24' reject"

However some rules have extra info:

rule family="ipv4" source address="162.159.244.38" log prefix="Shodan.io" reject

While some are simply:

rule family="ipv4" source address="42.224.165.0/24" reject

(those last two are rules copied from the output of firewall-cmd --list-all)

As shown below, the active zone is public, which isn’t explicitly noted in the rule as I read that without it specified, it applies to the active zone.

While researching this, I realised that I might be in an unusual situation with the Modem port forwarding to the machine, rather than having it in a DMZ or hosted externally. The Apache logs show the internet facing IP addresses for the http/s client machines, and I’ve been assuming that these IPs are the address that presented to the firewall.

(netstat -tn does show a current connection to an external IPv4 address, but I can’t establish if that’s inbound or outbound.)

Warning: ALREADY_ENABLED: rule family='ipv4' source address='201.159.155.0/24' reject was a frequent response until I added logging notes into the rule, now it just happily accepts multiple reject rules for the same subnet.

Since the first time I wrote this question on serverfault.com (and was then told it wasn’t ok to ask this there), I’ve had time to add the aforementioned logging, and have now been been to establish this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 194.195.251.
rule family="ipv4" source address="194.195.251.0/24" log prefix="Sun May 23 21:23:50 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Mon May 24 23:58:51 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Tue May 25 21:25:27 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Wed May 26 21:25:57 UTC 2021" reject

And this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 192.241.196.
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Mon May 24 23:59:25 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Tue May 25 21:26:02 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Wed May 26 21:26:31 UTC 2021" reject

So clearly, this isn’t dropping traffic. (The date/times are the dates added to the firewall.)

In case it’s helpful, here’s the top part of firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  services: cockpit dhcpv6-client http https ssh
  ports: [redacted integer]/tcp [redacted integer]/tcp [redacted integer]-[redacted integer]/udp [redacted integer]-[redacted integer]/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

The rich rules then follow. And because why not, here’s the active zone query:

[user@server ~]# firewall-cmd --get-active-zone
libvirt
  interfaces: virbr0
public
  interfaces: eno1

Other things to note:

  • There is only one Ethernet port on the box.
  • The firewall is reloaded after adding new rules (firewall-cmd --reload)
  • The server reboots every night
  • This server was CentOS Stream, but I converted it to CentOS 8
  • The firewall is active, enabled and functional (firewall-cmd --state returns ‘running’)
  • I’m aware that firewall-cmd --complete-reload exists, but it terminates all connections and that’s not what I need.
  • Some things from the conf file:
    • FirewallBackend=nftables
    • IPv6_rpfilter=yes
    • RFC3964_IPv4=yes

Any ideas?

( List of Rich Rules: https://pastebin.com/qXFMBvqh )

— EDIT —
Under the banner of "This is ridiculous", I put another local IP in the firewall (without –permanent) to test, then ran curl from the CLI. The pre-adding test worked fine, the post-adding test gave me curl: (7) Failed connect to **[redacted]**:80; Connection refused. With that behaving as expected, I cannot work out WHY these other things are not.

Have now turned on official logging (firewall-cmd --set-log-denied=all)

— EDIT 2 —
More info on the scripts in question:

  • The first script parses the Apache logs and establishes a list of IP addresses. Upon that, it puts the firewall-cmd adding commands into a .txt file. (It also looks up Geo-location information, but that’s out of scope here.)
  • The second script reads the .txt file, and executes the firewall-cmd add commands, then runs the firewall reload (--reload)

This allows the .txt file to build up over the weekend if I’m AFK. I inspect the GEO location information prior to running the second script to ensure that any IPs in the same country are more closely inspected to see whether they should be removed from the list.


Get this bounty!!!

#StackBounty: #networking #centos #firewall #firewalld firewalld rich rules don't drop incoming traffic (CentOS 8 behind a NAT)

Bounty: 50

G’day,

I’ve got a small development server at my office with port 80 and 443 port forwarded from the modem.

To restate the title in the form of a question:

Why doesn’t the firewall drop the incoming traffic from the IPv4 addresses that are listed in the rich rules.

Background:
As you would expect, Bots & Baddies™ are looking for various things that a) don’t exist, and b) would be bad if they they got into if they did exist. So I have a script that pulls IP addresses from Apache logs, which then end up in the firewall after they’ve been curated by me.

However, the firewall isn’t dropping the connections. Addresses that are added on previous days are present in the new rules to be added and the logs again on subsequent days.

Details:
The command that puts in the rich rules is this:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='165.227.87.0/24' reject"

However some rules have extra info:

rule family="ipv4" source address="162.159.244.38" log prefix="Shodan.io" reject

While some are simply:

rule family="ipv4" source address="42.224.165.0/24" reject

(those last two are rules copied from the output of firewall-cmd --list-all)

As shown below, the active zone is public, which isn’t explicitly noted in the rule as I read that without it specified, it applies to the active zone.

While researching this, I realised that I might be in an unusual situation with the Modem port forwarding to the machine, rather than having it in a DMZ or hosted externally. The Apache logs show the internet facing IP addresses for the http/s client machines, and I’ve been assuming that these IPs are the address that presented to the firewall.

(netstat -tn does show a current connection to an external IPv4 address, but I can’t establish if that’s inbound or outbound.)

Warning: ALREADY_ENABLED: rule family='ipv4' source address='201.159.155.0/24' reject was a frequent response until I added logging notes into the rule, now it just happily accepts multiple reject rules for the same subnet.

Since the first time I wrote this question on serverfault.com (and was then told it wasn’t ok to ask this there), I’ve had time to add the aforementioned logging, and have now been been to establish this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 194.195.251.
rule family="ipv4" source address="194.195.251.0/24" log prefix="Sun May 23 21:23:50 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Mon May 24 23:58:51 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Tue May 25 21:25:27 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Wed May 26 21:25:57 UTC 2021" reject

And this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 192.241.196.
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Mon May 24 23:59:25 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Tue May 25 21:26:02 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Wed May 26 21:26:31 UTC 2021" reject

So clearly, this isn’t dropping traffic. (The date/times are the dates added to the firewall.)

In case it’s helpful, here’s the top part of firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  services: cockpit dhcpv6-client http https ssh
  ports: [redacted integer]/tcp [redacted integer]/tcp [redacted integer]-[redacted integer]/udp [redacted integer]-[redacted integer]/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

The rich rules then follow. And because why not, here’s the active zone query:

[user@server ~]# firewall-cmd --get-active-zone
libvirt
  interfaces: virbr0
public
  interfaces: eno1

Other things to note:

  • There is only one Ethernet port on the box.
  • The firewall is reloaded after adding new rules (firewall-cmd --reload)
  • The server reboots every night
  • This server was CentOS Stream, but I converted it to CentOS 8
  • The firewall is active, enabled and functional (firewall-cmd --state returns ‘running’)
  • I’m aware that firewall-cmd --complete-reload exists, but it terminates all connections and that’s not what I need.
  • Some things from the conf file:
    • FirewallBackend=nftables
    • IPv6_rpfilter=yes
    • RFC3964_IPv4=yes

Any ideas?

( List of Rich Rules: https://pastebin.com/qXFMBvqh )

— EDIT —
Under the banner of "This is ridiculous", I put another local IP in the firewall (without –permanent) to test, then ran curl from the CLI. The pre-adding test worked fine, the post-adding test gave me curl: (7) Failed connect to **[redacted]**:80; Connection refused. With that behaving as expected, I cannot work out WHY these other things are not.

Have now turned on official logging (firewall-cmd --set-log-denied=all)

— EDIT 2 —
More info on the scripts in question:

  • The first script parses the Apache logs and establishes a list of IP addresses. Upon that, it puts the firewall-cmd adding commands into a .txt file. (It also looks up Geo-location information, but that’s out of scope here.)
  • The second script reads the .txt file, and executes the firewall-cmd add commands, then runs the firewall reload (--reload)

This allows the .txt file to build up over the weekend if I’m AFK. I inspect the GEO location information prior to running the second script to ensure that any IPs in the same country are more closely inspected to see whether they should be removed from the list.


Get this bounty!!!

#StackBounty: #networking #centos #firewall #firewalld firewalld rich rules don't drop incoming traffic (CentOS 8 behind a NAT)

Bounty: 50

G’day,

I’ve got a small development server at my office with port 80 and 443 port forwarded from the modem.

To restate the title in the form of a question:

Why doesn’t the firewall drop the incoming traffic from the IPv4 addresses that are listed in the rich rules.

Background:
As you would expect, Bots & Baddies™ are looking for various things that a) don’t exist, and b) would be bad if they they got into if they did exist. So I have a script that pulls IP addresses from Apache logs, which then end up in the firewall after they’ve been curated by me.

However, the firewall isn’t dropping the connections. Addresses that are added on previous days are present in the new rules to be added and the logs again on subsequent days.

Details:
The command that puts in the rich rules is this:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='165.227.87.0/24' reject"

However some rules have extra info:

rule family="ipv4" source address="162.159.244.38" log prefix="Shodan.io" reject

While some are simply:

rule family="ipv4" source address="42.224.165.0/24" reject

(those last two are rules copied from the output of firewall-cmd --list-all)

As shown below, the active zone is public, which isn’t explicitly noted in the rule as I read that without it specified, it applies to the active zone.

While researching this, I realised that I might be in an unusual situation with the Modem port forwarding to the machine, rather than having it in a DMZ or hosted externally. The Apache logs show the internet facing IP addresses for the http/s client machines, and I’ve been assuming that these IPs are the address that presented to the firewall.

(netstat -tn does show a current connection to an external IPv4 address, but I can’t establish if that’s inbound or outbound.)

Warning: ALREADY_ENABLED: rule family='ipv4' source address='201.159.155.0/24' reject was a frequent response until I added logging notes into the rule, now it just happily accepts multiple reject rules for the same subnet.

Since the first time I wrote this question on serverfault.com (and was then told it wasn’t ok to ask this there), I’ve had time to add the aforementioned logging, and have now been been to establish this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 194.195.251.
rule family="ipv4" source address="194.195.251.0/24" log prefix="Sun May 23 21:23:50 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Mon May 24 23:58:51 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Tue May 25 21:25:27 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Wed May 26 21:25:57 UTC 2021" reject

And this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 192.241.196.
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Mon May 24 23:59:25 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Tue May 25 21:26:02 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Wed May 26 21:26:31 UTC 2021" reject

So clearly, this isn’t dropping traffic. (The date/times are the dates added to the firewall.)

In case it’s helpful, here’s the top part of firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  services: cockpit dhcpv6-client http https ssh
  ports: [redacted integer]/tcp [redacted integer]/tcp [redacted integer]-[redacted integer]/udp [redacted integer]-[redacted integer]/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

The rich rules then follow. And because why not, here’s the active zone query:

[user@server ~]# firewall-cmd --get-active-zone
libvirt
  interfaces: virbr0
public
  interfaces: eno1

Other things to note:

  • There is only one Ethernet port on the box.
  • The firewall is reloaded after adding new rules (firewall-cmd --reload)
  • The server reboots every night
  • This server was CentOS Stream, but I converted it to CentOS 8
  • The firewall is active, enabled and functional (firewall-cmd --state returns ‘running’)
  • I’m aware that firewall-cmd --complete-reload exists, but it terminates all connections and that’s not what I need.
  • Some things from the conf file:
    • FirewallBackend=nftables
    • IPv6_rpfilter=yes
    • RFC3964_IPv4=yes

Any ideas?

( List of Rich Rules: https://pastebin.com/qXFMBvqh )

— EDIT —
Under the banner of "This is ridiculous", I put another local IP in the firewall (without –permanent) to test, then ran curl from the CLI. The pre-adding test worked fine, the post-adding test gave me curl: (7) Failed connect to **[redacted]**:80; Connection refused. With that behaving as expected, I cannot work out WHY these other things are not.

Have now turned on official logging (firewall-cmd --set-log-denied=all)

— EDIT 2 —
More info on the scripts in question:

  • The first script parses the Apache logs and establishes a list of IP addresses. Upon that, it puts the firewall-cmd adding commands into a .txt file. (It also looks up Geo-location information, but that’s out of scope here.)
  • The second script reads the .txt file, and executes the firewall-cmd add commands, then runs the firewall reload (--reload)

This allows the .txt file to build up over the weekend if I’m AFK. I inspect the GEO location information prior to running the second script to ensure that any IPs in the same country are more closely inspected to see whether they should be removed from the list.


Get this bounty!!!

#StackBounty: #networking #centos #firewall #firewalld firewalld rich rules don't drop incoming traffic (CentOS 8 behind a NAT)

Bounty: 50

G’day,

I’ve got a small development server at my office with port 80 and 443 port forwarded from the modem.

To restate the title in the form of a question:

Why doesn’t the firewall drop the incoming traffic from the IPv4 addresses that are listed in the rich rules.

Background:
As you would expect, Bots & Baddies™ are looking for various things that a) don’t exist, and b) would be bad if they they got into if they did exist. So I have a script that pulls IP addresses from Apache logs, which then end up in the firewall after they’ve been curated by me.

However, the firewall isn’t dropping the connections. Addresses that are added on previous days are present in the new rules to be added and the logs again on subsequent days.

Details:
The command that puts in the rich rules is this:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='165.227.87.0/24' reject"

However some rules have extra info:

rule family="ipv4" source address="162.159.244.38" log prefix="Shodan.io" reject

While some are simply:

rule family="ipv4" source address="42.224.165.0/24" reject

(those last two are rules copied from the output of firewall-cmd --list-all)

As shown below, the active zone is public, which isn’t explicitly noted in the rule as I read that without it specified, it applies to the active zone.

While researching this, I realised that I might be in an unusual situation with the Modem port forwarding to the machine, rather than having it in a DMZ or hosted externally. The Apache logs show the internet facing IP addresses for the http/s client machines, and I’ve been assuming that these IPs are the address that presented to the firewall.

(netstat -tn does show a current connection to an external IPv4 address, but I can’t establish if that’s inbound or outbound.)

Warning: ALREADY_ENABLED: rule family='ipv4' source address='201.159.155.0/24' reject was a frequent response until I added logging notes into the rule, now it just happily accepts multiple reject rules for the same subnet.

Since the first time I wrote this question on serverfault.com (and was then told it wasn’t ok to ask this there), I’ve had time to add the aforementioned logging, and have now been been to establish this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 194.195.251.
rule family="ipv4" source address="194.195.251.0/24" log prefix="Sun May 23 21:23:50 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Mon May 24 23:58:51 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Tue May 25 21:25:27 UTC 2021" reject
rule family="ipv4" source address="194.195.251.0/24" log prefix="194.195.251.228 - Wed May 26 21:25:57 UTC 2021" reject

And this:

[user@server ~]# firewall-cmd --list-rich-rules | grep 192.241.196.
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Mon May 24 23:59:25 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Tue May 25 21:26:02 UTC 2021" reject
rule family="ipv4" source address="192.241.196.0/24" log prefix="192.241.196.220 - Wed May 26 21:26:31 UTC 2021" reject

So clearly, this isn’t dropping traffic. (The date/times are the dates added to the firewall.)

In case it’s helpful, here’s the top part of firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  services: cockpit dhcpv6-client http https ssh
  ports: [redacted integer]/tcp [redacted integer]/tcp [redacted integer]-[redacted integer]/udp [redacted integer]-[redacted integer]/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

The rich rules then follow. And because why not, here’s the active zone query:

[user@server ~]# firewall-cmd --get-active-zone
libvirt
  interfaces: virbr0
public
  interfaces: eno1

Other things to note:

  • There is only one Ethernet port on the box.
  • The firewall is reloaded after adding new rules (firewall-cmd --reload)
  • The server reboots every night
  • This server was CentOS Stream, but I converted it to CentOS 8
  • The firewall is active, enabled and functional (firewall-cmd --state returns ‘running’)
  • I’m aware that firewall-cmd --complete-reload exists, but it terminates all connections and that’s not what I need.
  • Some things from the conf file:
    • FirewallBackend=nftables
    • IPv6_rpfilter=yes
    • RFC3964_IPv4=yes

Any ideas?

( List of Rich Rules: https://pastebin.com/qXFMBvqh )

— EDIT —
Under the banner of "This is ridiculous", I put another local IP in the firewall (without –permanent) to test, then ran curl from the CLI. The pre-adding test worked fine, the post-adding test gave me curl: (7) Failed connect to **[redacted]**:80; Connection refused. With that behaving as expected, I cannot work out WHY these other things are not.

Have now turned on official logging (firewall-cmd --set-log-denied=all)

— EDIT 2 —
More info on the scripts in question:

  • The first script parses the Apache logs and establishes a list of IP addresses. Upon that, it puts the firewall-cmd adding commands into a .txt file. (It also looks up Geo-location information, but that’s out of scope here.)
  • The second script reads the .txt file, and executes the firewall-cmd add commands, then runs the firewall reload (--reload)

This allows the .txt file to build up over the weekend if I’m AFK. I inspect the GEO location information prior to running the second script to ensure that any IPs in the same country are more closely inspected to see whether they should be removed from the list.


Get this bounty!!!