Certain strings saved in the errorlog.txt can cause serious issues in showing the error log.
These strings are the result of attempts to locate/access various server programs.

Since these attempts threw errors, the miscreants failed in getting to those files - BUT the saved error string itself can create problems when being looked at in the error log.
I'm working on preventative measures.

The current fix is to simply replace all the pointy brackets with html entities (with some work arounds for bold and breaks). That prevents bogus strings from messing up the html in the ErrorLog viewer.

We also need a 'block IP in .htaccess' for those not using the .htaccess function in Guardian. (Some of us don't like the automatic blocking function in Guardian.)

We're currently testing a "three-strikes you're out" auto-ban function for 'guest' IPs throwing repeated errors in a very short time. This is an idea JonB and I have talked about  - especially in light of the DOS attacks that have been aimed at YaBBForum.com.

These aren't things caught by Guardian as we're looking at the same IP throwing errors in an inhumanly short time..

I think a future solution may be to figure out a way to 'time ban' IPs in the .htaccess - timestamp them and set a time limit after which they get removed. What's been observed is that the non-legitimate bots rotate through IP addresses.

@Bill, we're not talking about keeping spambots from registering - we're talking about keeping them from attacking other portions of YaBB by inserting query stings Guardian doesn't catch (assuming it's turned on) and inundating the server with multiple errors per second. (And yes - PER SECOND!)  Every single error one of these b@stards throws gets written to the errorlog - which, despite outside appearances, is not a simple process.

We're talking about attacks aimed specifically at how YaBB's error logging and errorlog viewing is performed. And what they are trying to do is create a sting that will execute FROM THE ERRORLOG WHEN VIEWED! And if that fails, put enough garbage into the errorlog file that the viewer fails, the novice admin gets frustrated and goes to another forum software while bad-mouthing YaBB.
Edited:

Circumstantial evidence only - but yes.   

Some changes to YaBB's code in 2.6x have been deliberately left undocumented for that reason - why make it easy for the *tards? If they want to find an old weakness they can exploit they're going to darn well wade through however many thousands of lines of code to find what it looks like now. And JonB will be looking through the access logs and error logs to catch them trying.

It's not private - just not publicly announced. Anyone who cares to do a comparison between the old code and new can do so. But since nearly every line in YaBB has been changed in some way between 2.5.2 and 2.6x, they get to wade though a lot of code or they have to know exactly what they're looking for.

(I mean - a LOT of changes haven't been publicly announced - do we have to list every single spot where

<td align="right"> 

got changed to

<td style="text-align:right"> 

?  :)

Dandello wrote on Oct 4^th, 2014 at 2:07pm:


I agree... time stamping them is wise... Maybe putting the time stamp in a special comment line above the Deny line... And parsing, and preserving that line if still needed, every time when the .htaccess file is modified.