Forum Moderators: open
let your server return a 403 File Not Found.
If your site runs a CMS that uses these files
Are you seeing these requests in your access logs
In some ways a 404 is the very best thing to send unwanted visitors, because it conveys absolutely no information.
Do they have a common UA?
No I don't run any of the services they are looking for, so am pretty safe there. But they are addressing the http address of my site, all of their requests get a "301" response which, so far, they have ignored.As I said, these vulnerability scans are common. I see them every day. If you don't have these files, just ignore the requests and let your server return a 403 File Not Found.
all of their requests get a "301" response which, so far, they have ignored.this means only that they are requesting the domain at a default URL (such as http://example.com/vulnerability-whatever ) which is being redirected to the correct syntax (such as https://www.example.com/vulnerability-whatever) which then causes the 404 response.
As I said, these vulnerability scans are common. I see them every day. If you don't have these files, just ignore the requests and let your server return a 403 File Not Found.
"Mozilla/5.0 Jorgee"
this means only that they are requesting the domain at a default URL (such as http://example.com/vulnerability-whatever ) which is being redirected to the correct syntax (such as https://www.example.com/vulnerability-whatever) which then causes the 404 response.
"Mozilla/5.0 Jorgee" has been around for a year and commented on this forum [webmasterworld.com]! it has been noted by many people, attacking from Germany, and other locations.
I have never seen a 404 response to these requests in my logs. Always 301. But as you say, the request is to http and is to being redirected to https. Would the fact that the requests come so fast prevent the server from sending a follow-up 404 response?
It's not the speed preventing a second request after the 301, it's likely the script is just not written to follow redirects. ... Newer vulnerability checker scripts will likely follow HTTP to HTTPS redirects since this is common now.
If the request is being redirected from HTTP to HTTPS the 404 might not be seen in the access logs for HTTP because there may be separate logs for HTTPS requests. I download my logs via ftp and there are two gzip files, one for HTTP and one for HTTPS.
If you're managing a site that is HTTPS, those are the logs you should be looking at :)
No, because each request is an island, and a 3xx response means just that: "Make a new request". The server doesn't know that the same entity put in a request two milliseconds ago. If something comes in too fast to be handled, you'll see a 500-class response, but it will still be logged. Now, some servers can get a little hiccupy about logging rapid requests: my logs, for example, very often show a bunch of supporting files before the main HTML request. Going by timestamps, things can get up to several seconds out of whack.
