• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved NGinx deny rules and Firewall (iptables?)

epertinez

New Pleskian
Server operating system version
Ubuntu 18.04.6 LTS
Plesk version and microupdate number
Plesk Obsidian 18.0.52 Actualizació #3
Hi,
I have a problem with a production machine.
My Firewall (Plesk->Extensions->Firewall) tells me that I have to apply the changes. But when I try to it simply halts the machine (or the network, who knows) to the extend that I cannot ping it and I have to hard reset the server for it to work.
I waited some minutes, but It did not wake up.
The server contains a online store, so I cannot happily try things that halt the machine!!

Now... Right now I added some filters that try to block all access from RU, CN, PH,... so it makes sense that the process of setting up iptables with tens of thousands of rules takes its time.
But the server hanged EVEN WHEN i tried to update a VANILLA configuration to itself (yes, I checked and my original configuration was the same that the updated one).

Now IMPORTANT: I have some 15K deny rules in one Nginx configuration of one of my customers.

In fact, I pretend to move those 15K rules to a more general.... reject all traffic from RU, CN,...SO... IF Firewall is going to run, I could get rid of those rules.

Now... here it comes the question:

Does anybody can tell me if Plesk's Nginx is using IPTables to set those Deny rules? I found no place telling it, but that could explain why a Vanilla Firewall config does halt the system when upgrading with very simple rules.
 
Duplicate to Issue - Failed to apply the firewall configuration - [ext-firewall] set to 40 seconds

15K Nginx rules are too many. However, these are not placed into iptables.

For iptables, 15K rules would also be way too many. Instead, these should be defined through "ipsets".

When you use the Plesk geoblocking feature for the Firewall, you do not need to add your own lists to block certain countries. Here is how to do it (enter ISO code(s) into "sources":

I suspect that in your iptables you have some custom rules that are added to a wrong chain, so that when Plesk removes/reinstates a chain, these rules that allow network communication to and from your server are missing, hence you can no longer access the server. It is impossible to tell exactly why it happens without an in-depth examination of the iptables --list output. If you need assistance with it, please open a Plesk support ticket. Staff will be happy to assist: https://support.plesk.com
 
I am trying to create the iptables --list right now but the system has problem locking the xtables.
Another app is currently holding the xtables lock; still -9s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -19s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -29s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -39s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -49s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -59s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -69s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -79s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -89s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -99s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -109s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -119s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -129s 0us time ahead to have a chance to grab the lock...
Another app is currently holding the xtables lock; still -139s 0us time ahead to have a chance to grab the lock...

I'll attach it as soon as I can. Yesterday it take a couple of minutes untill iptables could grab de lock.


Some time ago I created/copied a "hack" to save Fail2Ban banned addreces so I wouldn't lose them between restarts.
It may be that this "hack" has accumulated so many ip's that that becomes a problem now.

I am trying to find this code and see if it has to many ips.
 
Ok,

I think I found the problem...
Some years ago (4 years!) I added a hack to /etc/failban/action.d/iptables-multiport.conf in order to save and reload the bans between restartings:

DISCLAIMER: DON'T DO IT! I ONLY COPY IT HERE FOR REFERENCE, IN CASE SOMEONE ELSE USED THE SAME HACK THAT I DID!!!

Bash:
# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = <iptables> -N f2b-<name>
              <iptables> -A f2b-<name> -j <returntype>
              <iptables> -I <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>
# 202002 Persistent banning of IPs
              cat /etc/fail2ban/ipRecolectaExterna.blacklist | while read IP; do iptables -A INPUT -s $IP -j DROP; done
              cat /etc/fail2ban/ipRecolectaInterna.blacklist | while read IP; do iptables -A INPUT -s $IP -j DROP; done

And

Code:
# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>
            # 202002 Persistent banning of IPs
            echo '<ip>' >> /etc/fail2ban/ipRecolectaInterna.blacklist


This code ads some 15K rules to iptables, and what's worse, once it starts failing, ipRecolectaInterna.blacklist starts to get duplicated ip's, so, at least the action start code should be changed to
Code:
              cat /etc/fail2ban/ipRecolectaInterna.blacklist | sort | uniq | while read IP; do iptables -A INPUT -s $IP -j DROP; done
Adding the pipeline | sort | uniq that asures that all ips are unique.

Anyway, I removed the hack. As soon as I can reboot the server, I will try to update the firewall rules. I'll keep you informed.
 
FOLOW UP: After restarting (and therefore, removing all rules from persistent fail2ban) i have been able to update the firewall without problems.
 
Back
Top