• 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
  • Inviting everyone to the UX test of a new security feature in the WP Toolkit
    For WordPress site owners, threats posed by hackers are ever-present. Because of this, we are developing a new security feature for the WP Toolkit. If the topic of WordPress website security is relevant to you, we would be grateful if you could share your experience and help us test the usability of this feature. We invite you to join us for a 1-hour online session via Google Meet. Select a convenient meeting time with our friendly UX staff here.

Resolved fail2ban filter apache-badbots "unknown"

shopuser

Basic Pleskian
Server operating system version
Ubuntu 22.04.3 LTS
Plesk version and microupdate number
Plesk Obsidian v18.0.57_build1800231128.16
i try to block in fail2ban filter apache-badbots unknown boots but dosent work

badbotscustom = unknown|...
 
I'm not sure what you're trying to do. Is "unknown" a word you've seen in the webserver logs?
 
yes in the log, the agent:

2023-12-11 13:53:33 Error 45.128.232.56 400 POST /register/saveRegister/sTarget/account/sTargetAction/index HTTP/1.0 Unbekannt 18.8 K SSL/TLS-Zugriff für Apache
 
Is that a line from /var/www/vhosts/domain.com/logs/proxy_access_ssl_log or from another source?
 
Does it really say "Unbekannt" in the log or does it say "unknown"? If the user-agent string is "Unbekannt", you must add Unbekannt as the custom bot name, too.
 
yes in the log, the agent:

2023-12-11 13:53:33 Error 45.128.232.56 400 POST /register/saveRegister/sTarget/account/sTargetAction/index HTTP/1.0 Unbekannt 18.8 K SSL/TLS-Zugriff für Apache

I suspect that in some cases the user-agent data on a request is shown in the Plesk log viewer as unknow (or Unbekannt in German), while in the actual log the user-agent string is either absent or malformed. So the word unknown (or Unbekannt) isn't actually logged, but only shown as an indication that the user-agent data is unknown to Plesk. Which is probably the reason why the fail2ban filter cannot act on it.

If you want to be sure about the user-agent you'll have to take a look at the raw log. Which you can view from Plesk via the log viewer by clicking on the "Manage Log Files" button (I don't know that the German translation is). On the list with log files of the domain you can click on the icons on the right side to either view the raw log in a new browser window or download the raw log.
 
Last edited:
yes this is the problem, in the logfile access_ssl_log.processed i can see only "-" There is a normal entry in the 4th line

192.144.39.104 - - [11/Dec/2023:00:45:07 +0100] "GET / HTTP/1.0" 301 5742 "" "-"
192.144.39.104 - - [11/Dec/2023:00:45:08 +0100] "GET / HTTP/1.0" 200 5489 "https://......de/" "-"
38.89.139.99 - - [10/Dec/2023:20:57:18 +0100] "GET / HTTP/1.1" 403 5752 "-" "-"
44.203.225.207 - - [11/Dec/2023:15:05:55 +0100] "GET / HTTP/1.1" 301 5695 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
 
Hi,

I've seen in my server in the last few months a lot of seemingly malicious "-" "-" entries in the access logs also. I created a custom jail just for these entries, instead of trying to use the badbots jail. One caveat: it requires a really fine tuning and monitoring so to not block harmless normal accesses.
 
I can already anticipate hackers naming their bad bots "unknown" to totally confuse users ... o_O
 
Hi,

I've seen in my server in the last few months a lot of seemingly malicious "-" "-" entries in the access logs also. I created a custom jail just for these entries, instead of trying to use the badbots jail. One caveat: it requires a really fine tuning and monitoring so to not block harmless normal accesses.
Actually, when no user-agent is transmitted and the source address is neither localhost, nor your own public IP, you could almost certainly block that traffic.
 
  • Like
Reactions: JVG
Back
Top