NOT FOUND HANDLER

[JuergenS]

Hi Alexandre,

I have installed my own NOT FOUND HANDLER (404) to prevent scraping.
When a user searches entire directories for files, after a certain number of times the user's IP address is temporarily blocked.

I have now discovered that the NOT FOUND HANDLER is no longer called by the server when file extensions are blocked.
Instead, a session is created and the server blocks after a while.

Could it be that the handling has changed in one of the last versions?

Regards

Juergen

[Alexandre Machado]

I'll need some more information.

How you register your handler? Also, for that matter, how do you keep the IP list?

PS: I have just tested the BlockedDocExtensions and it works as expected in the latest version, returning 404 - Resource not found whenever a document containing a blocked extension is requested, so there is something else going on

[JuergenS]

I may have expressed myself a bit unclearly.

My NOT FOUND HANDLER is always triggered when a file is requested from an IP address that does not exist on the server.
The HANDLER stores the IP address, the time of the first error and the number of errors. In addition, the session created is terminated immediately.
If too many such files are requested for an IP address within a certain time interval, this IP address will be temporarily blocked.
This has certainly worked so far, even for PHP files!

However, recently the NOT FOUND HANDLER no longer triggers for PHP files,
but only the INTRAWEB standard handler for 404, which does not terminate the created sessions immediately and does not recognize brute force attacks.

It seems like my HANDLER is no longer called for files whose file extension is blocked by INTRAWEB!
If I unblock PHP or other extensions, my HANDLER will trigger again.

[Alexandre Machado]

Can you provide a minimum test case for this?

The php extension is indeed blocked by default by IntraWeb, but way before a session is created. You can bombard an IW application with thousands of requests requiring a .php file and not a single session will be created. This has been extensively tested and I'm deeply sure that it works as intended.

[JuergenS]

I don't have a test case at the moment, but I could send the contents of real server log files that show the case.

[Alexandre Machado]

Please do. My email is alexandre [at] atozed dot com

[Alexandre Machado]

After analysing your log files I could recreate the issue.

The thing is not in IW code but actually in Indy server code. Some specific URLs were being (wrongly?) parsed by Indy code and the document part of the URL was being discarded, so the code to block certain file extensions was not able to identify and block the request.

This has been fixed and will be available in the next release.

Cheers,

[JuergenS]

Ok, thanks a lot.

[JuergenS]

Hi Alexandre,

unfortunately I'm having problems with PHP attacks again.

I'm using IW15.4.1.

Trace files would be available.

Regards
Jürgen

[JuergenS]

Hi Alexandre, you wrote:

09-20-2023, 03:45 AM 

After analysing your log files I could recreate the issue.

The thing is not in IW code but actually in Indy server code. Some specific URLs were being (wrongly?) parsed by Indy code and the document part of the URL was being discarded, so the code to block certain file extensions was not able to identify and block the request.

This has been fixed and will be available in the next release.



Is it possible that these changes are not included in the latest Indy version?

Juergen