Blocking comment spam

I don’t think there’s a problem with CIDR notation. I checked the Apache 2.2 documentation. All my blocking rules seem to work under test, so I’m happy it’s all good now.

I think I am introducing the custom 403 block by filling out the badbots section with blanket rules. Ideally, I wanted to say “block everything except robots.txt and 403.php”, but you can’t do negatives in the Files/FilesMatch container, as far as I know.

Apparently, FilesMatch “.*” is equivalent to no FilesMatch container at all, so I removed it. Adding the separate FilesMatch for the two file exclusions is enough to stop them being blocked by the following blanket rules. I tested this, and I get a nice 403 in a black-bordered box.

If you are interested, I can provide the code I settled upon. It might be worth adding it to your default, as it gives a good starting point for blanket blocking harvesters and IP ranges.

Here’s the Apache Core link for 2.4 that I frequently use since it has all the directives nicely indexed and linked on the right hand side of the page. Bookmark keeper. ??
https://httpd.apache.org/docs/current/mod/core.html

IMPORTANT NOTE: The Context section of the directive description states where the particular directive can be used. See the Context link below for what these mean: server config, virtual host, directory, .htaccess.
https://httpd.apache.org/docs/current/mod/directive-dict.html#Context

Always interested in what folks have come up with for their personal custom htaccess code so either use pastebin if you want to post/share it in the WP forum or if you want to post it in the BPS Forum then you can post all the code in a new forum topic.
https://forum.ait-pro.com/read-me-first/

While searching for something else I came across this thread.

Bunzer wrote:

but you can’t do negatives in the Files/FilesMatch container, as far as I know.

You can use negative assertion, but why would you when you can whitelist like this:

Order Allow,Deny
<FilesMatch "^(robots\.txt|403\.php)$">
Allow from all
</FilesMatch>

That would deny HTTP access to everything but those files listed.

First, all Allow directives are evaluated; at least one must match, or the request is rejected. Next, all Deny directives are evaluated. If any matches, the request is rejected. Last, any requests which do not match an Allow or a Deny directive are denied by default.

https://httpd.apache.org/docs/2.2/en/mod/mod_authz_host.html#order

But that was more or less designed to be used on a per directory basis and probably not in the root of a site.

If I were going to try and stop spam whether on login, registration, and/or commenting I would put in place rules that account for headers that are normally used by humans and not by bots (the more the better).

This is a basic one, but can be made stronger and configured better to your users/setup.

# AntiSpam for Comments
RewriteCond %{HTTP_REFERER} !^https?://([^.]+\.)?example\.com/ [NC,OR]
RewriteCond %{THE_REQUEST} !HTTP/1\.1$ [NC,OR]
RewriteCond %{HTTP:Connection} !^keep-alive$ [NC,OR]
RewriteCond %{HTTP:Accept-Encoding} !^gzip [NC,OR]
RewriteCond %{HTTP:Accept-Language} ^.?$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(.{0,49}|.{299,})$ [OR]
RewriteCond %{HTTP_ACCEPT} ^.?$
RewriteRule wp-comments-post\.php https://example.com/ [R=301,L,NS]

(Where example.com is your site.)

Again these are basics for normal headers. There are circumstances where these are too strong. You’d have to test for yourself. For example, any user agent that is less than 50 characters or more than 299 are send to your home page. You could actually make the Language header only be for English if you want.

RewriteCond %{HTTP:Accept-Language} !en [NC,OR]

To me, any server protocol less than 1.1 is way out of date, even though there are some circumstances like schools and proxies which are configured so that is something that may need to be taken into consideration as well.

Can all of this be spoofed? Why yes. But not many bots account for all. Requiring a cookie would be a good idea as well.

I have experimented with this HTTP Header line of code below (is not HTTP/1.1) in the past and it has not worked correctly for me. I have not picked apart why exactly that is, but have some logical ideas to go on. When I have some time I will look at it deeper.

RewriteCond %{THE_REQUEST} !HTTP/1\.1$ [NC,OR]

Using the matching condition (is HTTP/1.0) for bad bots, proxies, etc. is very effective on the other hand.

# Protect wp-login.php from Brute Force Login Attacks based on Server Protocol
# All legitimate humans and bots should be using Server Protocol HTTP/1.1
RewriteCond %{REQUEST_URI} ^/wp-login\.php$
RewriteCond %{THE_REQUEST} HTTP/1\.0
RewriteRule ^(.*)$ - [F,L]

This approach is for those folks who DO NOT allow anyone else to log into their websites. ie development, testing or sites where users are not allowed to register and comment.

# Protect wp-login.php from Brute Force Login Attacks
<FilesMatch "^(wp-login\.php)">
Order Allow,Deny
# Add your website domain name
Allow from example.com
# Add your website/Server IP Address
Allow from 69.200.95.1
# Add your Public IP Address using 2 or 3 octets so that if/when
# your IP address changes it will still be in your subnet range. If you
# have a static IP address then use all 4 octets.
# Examples: 2 octets: 65.100. 3 octets: 65.100.50. 4 octets: 65.100.50.1
Allow from 65.100.50.
</FilesMatch>

I believe that THE_REQUEST is basically this:

REQUEST_METHOD
REQUEST_URI (not decoded)
SERVER_PROTOCOL

In that order. So basically this:

RewriteCond %{THE_REQUEST} !HTTP/1\.1$ [NC,OR]

Means not SERVER_PROTOCOL HTTP/1.1

I believe I got that from jdMorgan. Can’t remember at the moment, but I’ve been using it for quite a long time. It maybe be safer to just use:
RewriteCond %{THE_REQUEST} HTTP/1\.0
or:
RewriteCond %{SERVER_PROTOCOL} HTTP/1\.0

I imagine the later would be slightly faster.

The thing I like about using certain HTTP headers, is that you can also include junk like this from commenting or whatever (but will block some mobile and satellite users as well):

RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR]
RewriteCond %{HTTP:VIA} !^$ [OR]

So:

RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR]
RewriteCond %{HTTP:VIA} !^$ [OR]
RewriteCond %{HTTP_REFERER} !^https?://([^.]+\.)?example\.com/ [NC,OR]
RewriteCond %{THE_REQUEST} !HTTP/1\.1$ [NC,OR]
RewriteCond %{HTTP:Connection} !^keep-alive$ [NC,OR]
RewriteCond %{HTTP:Accept-Encoding} !^gzip [NC,OR]
RewriteCond %{HTTP:Accept-Language} ^.?$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(.{0,49}|.{299,})$ [OR]
RewriteCond %{HTTP_ACCEPT} ^.?$
RewriteRule wp-comments-post\.php https://example.com/ [R=301,L,NS]

Yeah I’m sure the condition match works either way so my guess is that i forgot to use the starting slash in this URI rule: ^wp-login\.php$ and then fixed it later. ??

Yep, the whole mobile scene is booming now and tricky and changing very fast so for now I am putting any mobile or similar .htaccess code on hold until things stabilize.

Resolved.

Uninstalled. Too much work to maintain.