Database abnormally increases from 130 to 1400 MB

[Sesquipedalian]

So, it looks like you have two distinct problems that you are trying to deal with, @Sono.

The fundamental problem is that some idiots are trying to trick your site into redirecting requests to other external websites. This isn't actually working for them, because your site correctly refuses to do that. But whatever mindless script they have running just keeps hammering away.

The second problem is that something about those weird requests is triggering error messages in SMF, which are clogging up your error log.

The second problem is one that the support team here can try to help with. But for the first, you might need to talk to your host. The advice you have been given above about blocking certain crawlers and IP addresses is good, but the heavy and sustained attack you are being subjected to may require more extensive protection. Your host will be in the best position to help you with that.

[Sir Osis of Liver]

Unless the site has been hacked and the script is running in situ.  That may be generating the errors.

[Sono]

So, it looks like you have two distinct problems that you are trying to deal with, @Sono.

The fundamental problem is that some idiots are trying to trick your site into redirecting requests to other external websites. This isn't actually working for them, because your site correctly refuses to do that. But whatever mindless script they have running just keeps hammering away.

The second problem is that something about those weird requests is triggering error messages in SMF, which are clogging up your error log.

The second problem is one that the support team here can try to help with. But for the first, you might need to talk to your host. The advice you have been given above about blocking certain crawlers and IP addresses is good, but the heavy and sustained attack you are being subjected to may require more extensive protection. Your host will be in the best position to help you with that.

This is fine, I also see there are multiple problems here. One problem I noticed meanwhile is that strangely there seems to be leftovers from the Pretty URL mod. I uninstalled it, but I found my .htaccess looks like this:

Code Select Expand

# PRETTYURLS MOD BEGINS
# Pretty URLs mod
# http://code.google.com/p/prettyurls/
# .htaccess file generated automatically on: January 15, 2024, 23:12

RewriteEngine on
RewriteBase /

# Rules for: actions
RewriteRule ^(activate|admin|announce|attachapprove|buddy|calendar|clock|collapse)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(coppa|credits|deletemsg|display|dlattach|editpoll|editpoll2|emailuser)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(findmember|forum|portal|groups|help|helpadmin|hidetopic|im)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(jseditor|jsmodify|jsoption|lock|lockvoting|login|login2|logout)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(markasread|mergetopics|mlist|moderate|modifycat|modifykarma|movetopic|movetopic2)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(notify|notifyboard|openidreturn|pm|post|post2|printpage|profile)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(quotefast|quickmod|quickmod2|recent|register|register2|reminder|removepoll)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(removetopic2|reporttm|requestmembers|restoretopic|search|search2|sendtopic|smstats)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(suggest|spellcheck|splittopics|stats|sticky|theme|trackip|about:mozilla)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(about:unknown|unread|unreadreplies|verificationcode|viewprofile|vote|viewquery|viewsmfile)/?$ ./index.php?pretty;action=$1 [L,QSA]
RewriteRule ^(who|\.xml|xmlhttp)/?$ ./index.php?pretty;action=$1 [L,QSA]

# Rules for: boards
RewriteRule ^([-_!~*'()$a-zA-Z0-9]+)/?$ ./index.php?pretty;board=$1.0 [L,QSA]
RewriteRule ^([-_!~*'()$a-zA-Z0-9]+)/([0-9]*)/?$ ./index.php?pretty;board=$1.$2 [L,QSA]

# Rules for: topics
RewriteRule ^([-_!~*'()$a-zA-Z0-9]+)/([-_!~*'()$a-zA-Z0-9]+)/?$ ./index.php?pretty;board=$1;topic=$2.0 [L,QSA]
RewriteRule ^([-_!~*'()$a-zA-Z0-9]+)/([-_!~*'()$a-zA-Z0-9]+)/([0-9]*|msg[0-9]*|new)/?$ ./index.php?pretty;board=$1;topic=$2.$3 [L,QSA]

# PRETTYURLS MOD ENDS

<IfModule mod_security.c>
    # Turn off mod_security filtering.
    SecFilterEngine Off

    # The next part below probably is not needed, but better safe than sorry.
    SecFilterScanPOST Off
</IfModule>

I wonder if this triggers the error log sections related to Pretty URL? Many of the logs are about some Pretty URL stuff.

Also, in News.php I still have this, I don't know if it was just left there accidentally, or it is for rewriting old URLs stored in Pretty URL form:

Code Select Expand

//    Pretty URLs need to be rewritten
    ob_start('ob_sessrewrite');
    $context['pretty']['search_patterns'][] = '~(<link>|<id>|<comments>|<guid>)([^#<]+)~';
    $context['pretty']['replace_patterns'][] = '~(<link>|<id>|<comments>|<guid>)([^<]+)~';

    if ($xml_format == 'smf' || isset($_REQUEST['debug']))
        header('Content-Type: text/xml; charset=' . (empty($context['character_set']) ? 'ISO-8859-1' : $context['character_set']));
    elseif ($xml_format == 'rss' || $xml_format == 'rss2' || $xml_format == 'webslice')
        header('Content-Type: application/rss+xml; charset=' . (empty($context['character_set']) ? 'ISO-8859-1' : $context['character_set']));
    elseif ($xml_format == 'atom')
        header('Content-Type: application/atom+xml; charset=' . (empty($context['character_set']) ? 'ISO-8859-1' : $context['character_set']));
    elseif ($xml_format == 'rdf')
        header('Content-Type: ' . ($context['browser']['is_ie'] ? 'text/xml' : 'application/rdf+xml') . '; charset=' . (empty($context['character_set']) ? 'ISO-8859-1' : $context['character_set']));
About the avatars I have no idea. But is there maybe a way to reset them? Have them deleted for everyone. Or that won't solve that issue related to them in the error log?

[Sono]

Unless the site has been hacked and the script is running in situ.  That may be generating the errors.

But in that case the redirects would happen, wouldn't they? So far none of the redirects go though. Noone ever reported seeing another page instead of the one intended.

Anyway, if there is a hack, where can it be found to be able to function? It should be in a file in the Source or Theme directory, right? Or a link to the script at least should be there. If I understand correctly, those are the two directories where the forum is functioning from.

[Sesquipedalian]

Unless the site has been hacked and the script is running in situ.  That may be generating the errors.

Maybe. But @Sono said that he went to the same URLs that appeared in the error log and was not redirected anywhere else. If the site had been hacked and a malicious script had been installed, one would expect it to actually perform the redirection to the new URLs given in the requests.

Instead, the pattern of behaviour that Sono has described sounds like an external script trying to exploit a vulnerability in some other software package and (as usual) getting nowhere. That happens to websites all the time. The only unusual features of this case are the fact that the way these particular requests are formed is managing to trigger an error message in SMF (or at least this particular installation of SMF) and the sustained nature of these requests.

[Sir Osis of Liver]

Your host will be in the best position to help you with that.

 ^ This.

[Sesquipedalian]

If Pretty URLs is not installed, then I think you should be able to delete that stuff from .htaccess and News.php. However, you should ask about that in the support topic for Pretty URLs.

Regarding your question about removing the avatars, let me take a closer look at the error logs you posted earlier before I answer.

[Sesquipedalian]

No, removing the avatars won't accomplish anything useful. That's only one of the sorts of requests that are triggering errors. The root causes are elsewhere.

[Sesquipedalian]

A complete set of the logged error messages would help.

[Sono]

What export format would you require to check? Like XML? Or SQL?

[Sesquipedalian]

SQL is easier to read.

[Sono]

SQL is easier to read.

Here is the link to download:
https://drive.google.com/file/d/1iZiqN4nw4yzvyfYltWGfg5g3fX_0sPXB/view?usp=sharing

Thanks in advance!

[Sesquipedalian]

Apart from a handful of password incorrect errors, every single error message in your log says this:

'2: Parameter 1 to optimus_buffer() expected to be a reference, value given'

Uninstall your outdated version of the Optimus mod, which used to be called Optimus Brave.

If you really want the Optimus mod's features, you will need to upgrade to SMF 2.1, which we strongly recommend anyway. Then you will be able to install the current version of the Optimus mod.

[AlanDewey]

35.91.39.172 is  Amazon.com, Inc.

About two months ago my server logs went from 3 MB a day to 200 MB per day because of three amazon IPs beating my server to death. 

End of story is that I put those three amazon IP addresses into my router for it to drop all packets from them.

[Sono]

Apart from a handful of password incorrect errors, every single error message in your log says this:

'2: Parameter 1 to optimus_buffer() expected to be a reference, value given'

Uninstall your outdated version of the Optimus mod, which used to be called Optimus Brave.

If you really want the Optimus mod's features, you will need to upgrade to SMF 2.1, which we strongly recommend anyway. Then you will be able to install the current version of the Optimus mod.

Done. Let's see what the new results will be.

[Sono]

35.91.39.172 is  Amazon.com, Inc.

About two months ago my server logs went from 3 MB a day to 200 MB per day because of three amazon IPs beating my server to death. 

End of story is that I put those three amazon IP addresses into my router for it to drop all packets from them.

My host has Directadmin, how can you ban IPs there, I don't find it?

[Sir Osis of Liver]

You can block IPs in .htaccess -

Code Select Expand


Deny from 35.91.39.172



[Sono]

You can block IPs in .htaccess -

Code Select Expand


Deny from 35.91.39.172



And how can you block IP range in that? I found tutorials online but those listed a solution like banning 1.1.1.* But what if you just want to ban a specific section of that range like 1.1.1.2 - 1.1.1.10 ? To that one I did not find a solution.

[Sono]

Something has happened anyway, because yesterday the bandwidth was only 25GB, today only 1GB. I have to admit though I also added this code to the htaccess:

Code Select Expand

#disable bad crawlers
RewriteCond %{HTTP_USER_AGENT} inetdex [NC,OR]
RewriteCond %{HTTP_USER_AGENT} MJ12bot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} SemrushBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} SentiBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} SeznamBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} YaK/ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} YandexBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} coccocbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} bitlybot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Mail.Ru [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Baidu [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Jakarta [NC,OR]
RewriteCond %{HTTP_USER_AGENT} seostar.co [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Neticle [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AhrefsBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} DotBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Bytespider [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Sogou [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Exabot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} MauiBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ia_archiver [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Kinza [NC,OR]
RewriteCond %{HTTP_USER_AGENT} PetalBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AspiegelBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Aspeigel [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Neevabot
RewriteRule ^.* - [F,L]
I has already been there in the past but somehow went missing. Maybe I confused two htaccess versions when modifying stuff on the forum or I don't know. Anyhow, it seems some outer activity is surely responsible for a part of these bandwidth issues. The unfortunate thing however is that when this code was there in the past, after a month or so there had been an upheaval again in bandwidth (though not as serious like recently), as if the outer manipulators would have adopted somehow to it.

[a10]

And how can you block IP range in that? I found tutorials online but those listed a solution like banning 1.1.1.* But what if you just want to ban a specific section of that range like 1.1.1.2 - 1.1.1.10 ? To that one I did not find a solution.

IP Range To CIDR
https://www.ipaddressguide.com/cidr