This is probably going to be dependent on what server you're running and on which OS but this is one example of how to handle it.
You can capture the error response and send them to another page instead of returning error codes.
If I were implementing this I would send all errors to your index page. That way the attacker doesn't know if something's restricted, not there, broken etc. This also makes bruteforce scanning with dirb
dirbuster
and wfuzz
a pain as they leverage response codes to identify pages. So if you always return a 200 status code then you effectively break using those tools.
Custom error documents are configured using the ErrorDocument
directive, which may be used in global, virtualhost, or directory
context. It may be used in .htaccess files if AllowOverride is set to
FileInfo.
- ErrorDocument 500 "Sorry, our script crashed. Oh dear"
- ErrorDocument 500 /cgi-bin/crash-recover
- ErrorDocument 500 http://error.example.com/server_error.html
- ErrorDocument 404 /errors/not_found.html
- ErrorDocument 401 /subscription/how_to_subscribe.html
The syntax of the ErrorDocument directive is: ErrorDocument
<3-digit-code> where the action will be treated as: A local URL to redirect to (if
the action begins with a "/").
An external URL to redirect to (if the
action is a valid URL). Text to be displayed (if none of the above).
The text must be wrapped in quotes (") if it consists of more than one
word.
When redirecting to a local URL, additional environment variables are
set so that the response can be further customized. They are not sent
to external URLs.
For more information check out the documentation
https://httpd.apache.org/docs/2.4/custom-error.html
This is not a fix all for web bruteforcing. I wrote a script not long ago that leverages content length instead of status code. You can see how it works on GitHub
To defeat content length scanners I'd probably just include a hidden random string with a variable length in my index or error page.