Sucuri failed login report not accepted by Amazon EC2 Abuse Report

There is no need for us to collect that information because you can already get a copy of those logs from your hosting provider. The file is usually called “access_log” and is stored inside a directory called “logs” just above the document root of your website. If you cannot locate them in your account, you can simply ask your hosting provider for a copy of the most recent access logs and they will definitely send it to you.

That’s right but its time consuming, doing the way you said will dramatically reduce the reports because of the delay. The best thing would be for sucuri to add the time zone in report or even subject of the email.

Alright, I thought you were asking for a copy of the logs because it was urgent, that’s why I suggested you to ask your hosting provider for a copy of the access logs.

I personally don’t think adding the rest of the information to the “Failed Logins” page is a good idea, it will just clutter the page with redundant information. I will explain… Currently, the plugin logs this information:

• Username
• IP Address
• Date and Time
• Web Browser

Here is an example:

Information   | Value
--------------|----------------------------------------------
Username      | foo
IP Address    | 192.168.16.1
Date and Time | November 3, 2018 5:34 pm
Web Browser   | Mozilla/5.0 (KHTML, like Gecko) Safari/537.36

And this is what I can see in the “access_log” file:

Information   | Value
--------------|----------------------------------------------
IP Address    | 192.168.16.1
Identd        | -
Username      | -
Date and Time | [03/Nov/2018:17:34:45 +0000]
Request       | "POST /wp-login.php HTTP/1.1"
HTTP Status   | 200
Response Size | 1884
Referer       | "https://wordpress.test/wp-login.php"
Web Browser   | Mozilla/5.0 (KHTML, like Gecko) Safari/537.36

If you compare both logs, the one from the plugin and the one from the server, they are pretty much the same, the data that is missing is ignored because it’s redundant, like this:

• Identd is ignored because it’s always empty,
• Request is ignored because it’s always the same. The request is always executed with the “POST” method and the target is always pointing to the “wp-login.php” file,
• HTTP Status is ignored because it’s always the same, “200 OK” which means the request was accepted and processed by the web application, otherwise it wouldn’t even be in the plugin logs,
• Response Size is ignored because the amount of bytes transfered back to the web browser is irrelevant,
• Referer is ignored because it doesn’t provides significant information, it can always be faked by the client, so adding this information to the plugin logs would just add noise.

I will consider this a feature request and work on it right now, but be aware that the other maintainers of the code may disagree with this feature and decline the update. I would suggest to leave this ticket open for a few weeks, if more people are interested in this feature I will add it.

Meanwhile, you can tell the Amazon support agent that the requests are always using the “POST” method. The “Referer” is irrelevant because it can be faked. The “HTTP Status Code” is “200 OK”. The “Size of the Response” is irrelevant as well as the “Identd”. The only piece of the puzzle that cannot be inferred from the plugin logs is the name of the file that’s receiving the request, but I don’t think you need that in order to block someone’s attempts to break into your website.

I don’t see so much noise, just some extra fields. All this info doens’t help us too much but only to copy and paste it to the IP owner, so the more details the better. I rather find the proper data in the report email, instead of ssh the server and access the log, or any other additional step which can take me precious time. They need the exact time in order to find the abuser, I think this in an import issue that need to be fixed.

Same problem here. Please click here for similar issue and more details (including an explanation for the “abuse” reported). Sucuri: Please fix this.

Please re-open this ticket. Issue is not solved.

Thank you!

Hello @jetxpert , the ticket that you linked has nothing to do this with this one.

Sucuri: Please fix this.

There is nothing to fix, the plugin is not broken, there is no bug. The author of this ticket just wants me to include extra information in the logs that the plugin is collecting when someone is trying to brute-force the WordPress user login.

That being said, I will accept the feature request and add an option to increase the data collection in your own web server, this extra data will be sent to Sucuri and used to complement the information in the logs, which is what the original poster is asking for.

It will take me a few days before I can implement this option as I have other things in my “TODO” list with more priority. I’ll update this ticket when the new feature is implemented and released.

Hi @yorman,

Thank you for your quick response.

In reference to the original statement above:

“… it does not provide enough information for our customers to investigate or for us to clearly identify the owner of the IP address.

Yes, in addition to updating the logs, it would be nice to know what servers and/or IPs are being used by Sucuri. Can you add them to your KB? It will help this case and the one hyperlinked above.

By the way, the IPs we are registering during each malware scan are: 35.175.205.111 and 52.203.142.240 (Fake Google Bots as your explained here).

Again, thank you. Cheers!