bob73

Hi Gioni
Thanks a lot. This is helpful in my case.

After disabling XML-RPC in the hardening menu, this access has been blocked. This solution would be fine for me at the moment, as my web site does not need XML-RPC.

May I address an issue related to the custom login URL ?
I have set a custom URL and activated the option “Disable wp-login.php”.
Beside this, only one static IP address is white-listed in the access list.

Now, if there is a login attempt to the custom URL from any other IP address than the one defined in the white-list, the request still lands on the WP login page, and the remote user meanwhile gets the warning that he has reached the login attempts limit, so he is locked out for the next XX minutes, let’s say 60 minutes (if configured so).
Wouldn’t it be more logical and secure that this user (mostly intruder) gets a 404 or 403 response instead of disclosing that:
– he actually managed to find out the right custom URL
– WordPress is being used on this server (because of the WP login form)
– he is locked out for “only” 60 minutes, so he can go on hacking afterwards (and the option aggressive lockout duration may sometimes not help, if the hacker waits enough until the next access attempt)

Another way of asking this question is : wouldn’t it be more logical to consider the white-list more like a pure access authorization instead of IPs that will never be locked out ? Or give the custom URL option some kind of higher priority in order to avoid the described issue. I would expect that a request from any other IP than the one white-listed is automatically rejected or ignored.

Thanks a lot.
Best regards.