#StackBounty: #centos #keyboard-layout #vmware-workstation VM boots with wrong keyboard layout

Bounty: 50

I use VMware Workstation Player to run my Linux VMs. Starting from the boot and during GRUB menu, LUKS password entry, and initial user login screen, the keyboard appears to be set to US. This is source of errors when entering passwords as I have a French Swiss keyboard (QWERTZ). The system uses the correct keyboard layout (CH-FR) only after the user has logged in.

How can I set the correct keyboard locale so that it is applied since the boot?

This is the output of localectl on a CentOS 8 Stream VM:

System Locale: LANG=en_US.UTF-8
    VC Keymap: ch-fr
   X11 Layout: us
    X11 Model: pc105+inet
  X11 Options: terminate:ctrl_alt_bksp


Get this bounty!!!

#StackBounty: #centos #openldap #passwd Let openldap users change password with passwd in centos, i broke it

Bounty: 50

Tried to do the above with this tutorial:

https://www.unixguide.net/content/openldap-allow-users-change-their-password-unix-passwd-command

So I created this ldif:

dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to attrs=userPassword by self write by anonymous auth by dn.base="cn=ldapadm,dc=bbb,dc=local" write by * none

add: olcAccess
olcAccess: to * by self write by dn.base="cn=ldapadm,dc=bbb,dc=local" write by * read

Ran the ldapmodify, now no user can log into any client with their password when they could before I ran the above modify.

now attempting to login says permission denied after correct password is entered….what did I break ?? (totally new to openldap)

And as it might be relevant this is how I got my clients connected to my openldap server:

yum install -y openldap-clients nss-pam-ldapd
authconfig --enableldap --enableldapauth --ldapserver=192.168.1.10 --ldapbasedn="dc=bbb,dc=local" --enablemkhomedir --update


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

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