[Spam protector] too long lines created in .htaccess file

[DLange]

The "Spam protector" plugin will write way too long lines into the .htaccess file if it has enough IPs in the database spamblock_htaccess table (within two days' time stamps). Apache will then truncate the line and interpret the remainder of an IP address as an invalid command resulting in "500 Server error" and the site is dead.

[Mon Apr 22 08:33:48 2013] [alert] [client 184.154.15.x] /webpath/.htaccess: Invalid command '6.48.15.137', perhaps misspelled or defined by a module not included in the server configuration, [..]

According to http://httpd.apache.org/docs/current/en ... uring.html the maximum line length in .htaccess files is 8190 chars. The plugin needs to honour that and stay below that upper limit.

Easy would be to add a LIMIT clause to
$q = "SELECT ip FROM {$serendipity['dbPrefix']}spamblock_htaccess WHERE timestamp > " . (time() - 86400*2) . " GROUP BY ip";
(from serendipity_event_spamblock.php)

Paging through (e.g.) 100 entries at a time would allow adding multiple "Deny from" lines.

Better (but slower) would be to check the length of $deny and stop adding older IPs to the end of the string when the length would go beyond 8178 (or 8000 for ease of implementation). Obviously adding multiple "Deny from" lines would be a good idea again.

Probably a valid quick-fix is to limit the entries in the table to the maximum safe amount (~177) and delete all older ones on the insert of a new spam source. (Still only a single line in .htaccess then.)

At this time IPv6 IPs should be taken into account as well, so please don't fall for Max_Length(IP) = 15. That's obsolete these days. Max_Length(IPv6) is 45. Hence 177 entries as a safe maximum for one line in .htaccess.

[garvinhicking]

Hi!

Yeah, that experimental function never proved to be worthwile at all. Apache parsing of those lines also takes ages, and on a frequent blog, the "bad IPs" simply fill up too easily. I would recommend to not use this in actual production blogs, I don't think this blocking idea was such a good idea. We'll quite likely remove the function at some point.

Best regards,
Garvin

[Timbalu]

Could you check if this would apply (see the elseif part)? (Lines ~466+)

Code: Select all

                // Check if an old htaccess file existed and try to preserve its contents. Otherwise completely wipe the file.
                if ($htaccess != '' && preg_match('@^(.*)#SPAMDENY.*Deny From.+#/SPAMDENY(.*)$@imsU', $htaccess, $match)) {
                    // Code outside from s9y-code was found.
                    $content = trim($match[1]) . "\n#SPAMDENY\nDeny From " . implode(' ', $deny) . "\n#/SPAMDENY\n" . trim($match[2]);
                } elseif (count($deny) > 177) {
                    $cdeny = array_chunk($deny, 177));
                    $content = '';
                    foreach($cdeny AS $cd) {
                        $content .= trim($htaccess) . "\n#SPAMDENY\nDeny From " . implode(' ', $cd) . "\n#/SPAMDENY\n";
                    }
                } else {
                    $content = trim($htaccess) . "\n#SPAMDENY\nDeny From " . implode(' ', $deny) . "\n#/SPAMDENY\n";
                }

@Garvin
We could flag this IP-blocking as experimental and as not recommended and still leave it for those with enough resources...

[DLange]

I like the feature and I'd keep it (otherwise I'd have to re-implement something similar via e.g. fail2ban and that's much more work).

Timbalu's proposal is a step in the right direction.

[Timbalu]

But fail2ban would be much better and faster as using iptables... (there was a blog article by Kris Köhntopp, but this blog was sadly closed down).
You did not say if my "proposel" is working well and could get implemented within an update?

[DLange]

I added

Code: Select all

ORDER BY timestamp DESC LIMIT 177

to the original line as a quick fix.
I'm waiting for a proper solution from Garv. Can't be that we can easily have people running that plugin DoS'd by spamming them from a few hundred IPs within two days...

[Timbalu]

Well ... in this case ... you will have to wait then...

[DLange]

With the appended line, it works quite nicely again.
In my case the 177 entries are good for about one day of spammer activity as it currently is.
@Timbalu: Your code did not work for me (blog doesn't load anymore after editing the file, could be suhosin killing it, did not debug further)
@Garv: I recommend appending

Code: Select all

ORDER BY timestamp DESC LIMIT 177

as a quick fix in the next release. If somebody wants to fix it proper, that's very welcome. But this is good enough for me.

[garvinhicking]

Hi!

I agree, I just implemented your patch!

Thanks,
Garvin

[ju]

But fail2ban would be much better and faster as using iptables... (there was a blog article by Kris Köhntopp, but this blog was sadly closed down).

fortunately it is still in the web-archive:

http://web.archive.org/web/201001041040 ... backs.html

My filter looks like this:

Code: Select all

[Definition]
failregex =^<HOST> .*POST /comment.php
ignoreregex = 

and the section in jail.local:

Code: Select all

[s9y]

enabled = true
port = http
filter = s9y-kommentarspam
logpath = /var/log/apache2/queer-news-access.log
maxretry = 3
findtime = 300
bantime = 86400

Obviously I started out with short bantimes and looked at the logfiles regularely to not catch some innocent commenter. In a very busy blog with lots of short comments findtime and maxretry would have to be tested and adjusted.