Spam login attempts, ip:s blocked but still “recorded”?

Interesting issue. Let me share my thoughts. Disclaimer: My assumptions may be wrong.

Will Simple History “record” attempts even if they are blocked by nginx rule ?

No plugin, theme or WP core can record attempts if the request is blocked by Nginx rule.

To put otherwise, Nginx can not pass a “blocked” request to PHP in order to get it processed by a plugin, theme or WP core.

A request from a visitor goes to Nginx and it passes or blocks the request based on its own rules. Nginx can never block and let it pass for logging purpose. It isn’t the way Nginx works.

it could be set to have more robust logging and is recording the blocked attempts.

There is only one way to record blocked attempts, by looking at the logs of Nginx. However, Nginx logs can never be reached by a traditional WP plugin or WP core. If a plugin can read Nginx logs, then something is wrong in the whole setup in terms of security, because Nginx should run as a different user than PHP on a secured environment and Nginx user should have only read permission for WP file. The PHP user should never have any permission to read the logs of Nginx (or any web server).

Probably, the host runs both Nginx and PHP as the same user. Even so, how can a plugin access the Nginx log without knowing the location of logs? Does this plugin know the standard location of logs in popular hosts?

I’d like to hear from the plugin author as well.

If the IP numbers that are blocked still show up in Simple History that sounds like the block is not working. What kind of events are logged? I guess it’s failed login attempts? Could you click on the date and time of an event to get a “popup” with some more details and post that info here? Maybe that could give me some more ideas or clues on what’s going on…

Hi,

Here are some info from the popup:

Anonymous user from (ip from blocked country) Failed to login with username (existing/real username specified) (incorrect password entered)

Context data
This is potentially useful meta data that a logger has saved.

logger SimpleUserLogger
level warning
message Failed to login with username “{login}” (incorrect password entered)
initiator web_user
context_message_key user_login_failed
server_http_user_agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
_message_key user_login_failed
_xmlrpc_request true

“+67 similar events” (all seem to be occuring at the same time/minute)

According to WP Engine the blocking rules are working.

…does Simple History always list the last digit in ip:s as a zero?

Thanks!

Ah, yes, the ip number always ends with a 0 by default. This was added in version 2.22 in may 2018:

IP addresses are now anonymized by default. This is mainly done because of the General Data Protection Regulation (GDPR)
Both IPv4 and IPv6 addresses will be anonymized and the IP addresses are anonymized to their network ID.
So for example the IPv4 address 192.168.123.124 is anonymized to 192.168.123.0 and
the IPv6 address 2a03:2880:2110:df07:face:b00c::1 is anonymized by default to 2610:28:3090:3001::.

Maybe that is causing you to block the anonymized ip address instead of the real one!
You can start to log the real ip by using the filter simple_history/privacy/anonymize_ip_address.

• This reply was modified 5 years, 7 months ago by eskapism.

Thank you,

I don′t think this is the problem here since this ip is blocked based on it′s country but I will doublecheck…

Hi again,

I just heard back from WP Engine and they located the IP that matches (part from the last digit) at the same times that Simple History is logging these spam login attempts WP Engine is logging response code 403.
Does that make sense?

Thanks!

It sounds really strange because Simple History logs things using the built in filters and hooks in WordPress. So if Simple History logs a failed login attempt then it means that that user (or bot/computer) did access the site somehow and did make WordPress fire the login hook, in your case the filter wp_authenticate_user. Also in your case the login attempt was probably made using a XML-RPC-call.

Not sure how it works, but maybe the hackers are using spoofed ip addresses. Other than that I really don’t know how these attempts can be logged and at the same time being blocked by a firewall.

Thank you for your reply,

I just wanted to follow up on this. I have seen a few more of these and WP Engine has been able to match the date/time/IP from the failed login attempts (according to Simple history log) with hits to xmlrpc.php…these hits has been blocked by WP Engine, giving 403:s.
I′m still a little confused as to how these attempts would end up in Simple History log if they are blocked with 403 but I guess it′s all good, does it make sense to how your plugin work?

Thanks!

I’m confused too! If the requests are blocked they can’t show up in Simple History. The plugin does not parse any server logs or similar, it just use hooks that WordPress fire. So if a login attempt ends up in the audit log of Simple History then I believe the request was not blocked.

So there is no way that the requests to xmlrpc.php (seen in WP Engine log) with response code 403 are the same as the ones that are logged as failed login attempts in Simple History?
(WP Engine explained that depending on the request, they block from different places and this is not triggered from the country/IP -block I mention above)

Thanks!

WP Engine explained that depending on the request, they block from different places and this is not triggered from the country/IP -block I mention above

This explains everything. From what I know, there are only three places where a host can block a request. Firewall and web server are the first two places. Once a request goes through both, the only other place is WP where any plugin can log those attempts.