This fix works for me
The list is:
https://raw.githubusercontent.com/stamparm/ipsum/refs/heads/master/levels/1.txt
Name: level1
Works!
This fix works for me
The list is:
https://raw.githubusercontent.com/stamparm/ipsum/refs/heads/master/levels/1.txt
Name: level1
Works!
Is there any way to add a list with xx.xx.xx.xx/xx to block entire subnets rather than just individual ips? My list of ips with subnets errors out.
Yes, that should work out of the box.
What’s the error? How did you create the ipset, and how are you adding the subnets?
I created a txt file on github that is the same as the level4 list (that works above) but the list looks like:
xx.xx.xx.xx/xx
xx.xx.xxx.xx/xx
Here’s the list: https://raw.githubusercontent.com/themew/ipblock/refs/heads/main/blacklist1.txt
and I get the ‘error populating ip table’.
That’s because you have duplicated entries. In this case 185.208.158.0/24 appears twice.
You can use this to remove duplicates and sort them:
awk -i inplace '!a[$0]++' blacklist1.txt && sort -rV -o blacklist1.txt blacklist1.txt
3 Likes
@sahsanu As always, you’re amazing – I didn’t catch the duplicate error. Thank you so much!
1 Like
Weird – the truncated file loaded into Hestia without an error, but 196.251.88.45 (196.251.88.0/24) is still getting through. Adding it to fail2ban seems to get rid of the constant POST request.
Which port is that IP accessing?
Check whether the ip 196.251.88.45 is really included in your ipset (replace ipsetName by the actual ipset name)
ipset test ipsetName 196.251.88.45
Check what are the firewall rules defined in Hestia for that ipset (replace ipsetName by the actual name):
v-list-firewall | grep 'ipset:ipsetName'
The same for the active iptables rules:
iptables -S | grep 'ipsetName'
1 Like
I have a question regarding a situation I’ve been experiencing. I added the list of blacklisted IP addresses, which, as far as I can see, was added correctly. The list is as follows:
https://raw.githubusercontent.com/borestad/blocklist-abuseipdb/main/abuseipdb-s100-14d.ipv4
However, reviewing the real-time logs, I see that an IP address on the list still has access to the server.
Example IP: 40.113.90.212
Log nginx:
40.113.90.212 - - [17/Apr/2025:14:48:03 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:03 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:03 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:04 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
40.113.90.212 - - [17/Apr/2025:14:48:05 -0500] "GET /u.php HTTP/1.1" 301 162 "-" "-"
According to this, I see that the IP addresses aren’t being blocked correctly. Is there anything else I need to do?
At least two options:
1.- You added the ipset but you didn’t add a firewall rule to block the source IP based on that ipset.
2.- You are using Cloudflare. So the IP you see in the logs is not the real IP connecting to your server, the real one is the Cloudflare’s IP. What you see in the logs is the origin IP extracted from the header CF-Connecting-IP sent by Cloudflare.
1 Like
Hello
Yes i use CloudFlare, How can I then in that case block the connections that are delivered by CloudFlare since they are not being blocked?
Using Cloudflare Web Application Firewall (WAF).
1 Like
In the WAF Managed Rules, i can’t add an IPset or large list of maliciuous IP’s, is possible integrate Fail2Ban with the CF-Connecting-IP?
That’s a question for Cloudflare.
Anything is possible, but what action do you want to take when Fail2Ban triggers a ban? You can’t add a rule on your server to block the IP, because that IP isn’t connecting directly to your server. If Cloudflare provides an API to interact with the WAF, you could add the IP to Cloudflare’s WAF every time Fail2Ban triggers a ban. However, I don’t use Cloudflare, so I can’t provide more details.
This may get you on the right track.
https://community.cloudflare.com/t/does-cloudflares-fail2ban-action-still-work/640904
2 Likes
