IP blocking order


I have several IP blocks set for the usual offenders in iptables, yet I keep getting notices from Fail2ban that an
IP in the range if getting blocked. My question is Fail2ban in front of iptables?

In iptables:

Yet I get this:

The IP has just been banned by Fail2Ban after
4 attempts against apache-auth on localhost.

I do not understand why the offending IP is getting as far as to Fail2ban.

Thank you

No, Fail2Ban is not in front of iptables. It sits on the server and looks at specific logs (the ones you tell it to) and the thresholds you set for those services. If, when it parses the logs, finds matches for those rules it alerts you and in some cases will add them to IP tables.

What you have to look for is your order in iptables. It’s top-down. So if your rule to drop that /8 is after another rule that could match/allow anything on that /8 in, it’s going to match first and your rule never hit.


Well that could certainly be my problem!

I have allowed everything on the top section and then the restrictions below those.

I’ll switch them around…

Thank you

Yeah, that is definitely it. Once you move them around you should see those Fail2Ban alerts go away for that space.

Hello, Is there a way with the new responsive firewall to block IP ranges?

Is there still an IPtables file? If so where can I find it?

Thank you

No as it is responsive to the current IP that is making the requests. How would it know what the proper subnet would be for this IP? Nothing tells the system that. If you need to block a subnet then you need to put it in the Blacklist section of the Firewall.

There is the Firewall Blacklist, which I presume supersedes responsive, but I don’t recall ever testing.

It does.

1 Like

I did not realize you can put a range in there. There are server farms in France and Iceland that send us a huge amount of bad traffic. We get them to stop one server at a time with abuse claims, but another server starts in a day or so. They are sending traffic from multiple IPs, all assigned by RIPE. If we can block their RIPE assigned IPs that will be great.

Thank you

1 Like

You need to add IPs to the firewall with a subnet. If you just add an IP with no subnet the system assumes it’s a /32. So you can do and block that entire Class A block.

Do a whois on the offending IP alook for the smallest CIDR or netrange and add that to your iptable by whatever means.

IMO blocking IP addresses or ranges of IP addresses is rarely a useful security technique.

  1. It requires a great deal of administrative effort. You are essentially playing a game of whack-a-mole.
  2. It causes trouble. For example, an associate traveling in Europe fails to connect via mobile data or hotel Wi-Fi.
  3. It is ineffective; a VPN server in your country circumvents it easily.

A proper firewall denies all traffic by default, allowing only authorized traffic to pass. Attacks against PBXes fall into three categories:

  1. Made by automated tools probing every IPv4 address on the internet, looking for vulnerabilities.

  2. Made by an adversary targeting your organization specifically, e.g. a competitor seeking to obtain your customer list or to disrupt your operation.

  3. Made by someone with knowledge specific to your system, e.g. a disgruntled employee or former employee.

Nearly complete defense against (1) is IMO best done by giving your PBX an obscure domain name, e.g. pbx23647.mycompany.com. Incoming SIP packets containing this name are permitted to pass, as are those that are part of an existing dialog; all others are simply dropped. You will never see “server farms in France and Iceland that send us a huge amount of bad traffic”; after the first few packets receive no response at all, they give up and move on to the next sucker. This takes just two iptables entries.

HTTPS requests without the correct domain name receive a dummy self-signed certificate and get a ‘nothing to see here’ response. This is just a few lines of Apache configuration.

SSH is configured to authenticate by RSA key only and reject all attempts to use a password. It should be on a non-standard port so the numerous requests with ‘123456’ and ‘password’ don’t waste server resources and fill your logs.

All packets other than SIP, RTP, HTTP(S), VPN and SSH are dropped.

I’ve run test servers like this for weeks, open to the world, without seeing a single malicious request in any log.

Defense against (2) is more difficult. SIP and web access should be restricted to a short whitelist of authorized addresses (your offices and trunking providers). A branch office or teleworker with a dynamic IP that changes once or twice a year can be accommodated with dynamic DNS. Otherwise, a VPN is a must. 3CX uses a tunnel by default and you rarely see security issues on their forums.

Defense against (3) is extremely difficult, usually fails, and is well beyond my expertise. However, I can assure you that if you are wasting time blocking IP addresses, you are not addressing the relevant issues.

Edit: typo fixed as noted by @dicko in next post.


The attacks come to udp/5060 almost exclusively (but udp/5000 to 5999 and occasionally TCP in the same range are also less often attacked) but [email protected] is NOT a domain name, yet pbx23647.mycompany.com is and a good idea, but you would need to add for chan_sip


somewhere in /etc/asterisk/sip*.conf for that to work. For chan_pjsip there is an equivalence I’m sure.

So, just don’t ever use UDP/5000-5999 , think about only allowing tcp or tls for your clients, It works way more efficiently for soft phones (a battery usage issue) and you are in control here with your clients, TCP/TLS both require a two way connection, UDP doesn’t so is much more easily spoofed.

I don’t see where https is relevant here, but I agree that protecting other services is a good idea against 2.) for 3.) you have to suspect the vector :wink:

Sorry about that. Typo edited.

I was not suggesting putting the domain name check in chan_sip, but in iptables. The main advantage is that the packet is simply dropped. The attacker sees no response at all and after about three packets decides that there is no PBX there and moves on.

I agree that using an obscure port is a huge help, but unfortunately not for people who have already been attacked and can’t easily change their IP address. The reason an obscure port works is that it’s infeasible for an attacker to scan every port on the internet, but scanning all ports on an IP address that is already known to host a PBX is relatively inexpensive.

add port scanning drop rules to your iptables ;-), catch the buggers and add their whole network to the lower level drop rules, no more Iceland or OVP buggers but your clients in Beijing hotels still work

Sadly, it’s important, because FreePBX has a history of vulnerabilities in the web interface that allowed unauthenticated attackers to gain root access to the machine. But even if it were known to be secure, you want to hide the fact that you have a PBX at all; otherwise attackers will scan for other vulnerabilities, or beat on the system guessing passwords.

The Apache config gives these responses:
HTTP with IP address or incorrect domain -> ‘nothing to see here’.
HTTP with correct domain -> automatic redirect to HTTPS.
HTTPS with IP address or incorrect domain -> self-signed cert (bogus domain), ‘nothing to see here’
HTTPS with correct domain -> access to UCP or FreePBX admin (with obscure username and strong password)

I totally agree, by default 5038 is exposed, go figure, these guys “fingerprint” your server to see if you are using FreePBX, the clever ones will then concentrate on that.

Watch sngrep to see who is trying, they start there then escalate , usually from a disparate IP , commonly in the same CIDR. . .

I expect that we will soon see escalation from a different CIDR, i.e. ‘scouting’ attackers selling their ‘lead’ lists to other attackers.

Perhaps so, I have never seen that though. But I monitor all the time. After a while dropping all the major cloud servers including amazon, microsoft,whoever helps, almost no real clients will be on them, they will be on comcast or cox or some other legit network

Hi All,

Thank you for the valuable input. We have put in several RIPE ranges and that has been most successful.

Using a FQDN for extension registration has proved extremely problematic over the years. We have a variety of phone manufacturers connected and some of proven impossible to provision with a FQDN, we have had to use the IP instead.

Again, thank you