Viewing 12 replies - 16 through 27 (of 27 total)
  • Hi @wpzugang,

    Ok, so the entries below tell us that the brute force method is now xmlrpc:

    url => https://domain.com/xmlrpc.php
    source => xmlrpc

    Luckily the iTSec plugin allows us to disable xmlrpc. The majority of WordPress websites don’t need it. If disabling it causes any problems for the site you can always enable it again. To disable xmlrpc navigate to:

    Security > Settings > Advanced > WORDPRESS TWEAKS

    I would also recommend to set the REST API setting to Restricted Access.

    Thank you again for your great support ?? I turned off xmlrpc yesterday and activated restricted acces and haven’t had any new brute forces since then. Hope it will stay like this (fingers crossd).

    The brute foreces became less but started again. Are your suggestions everything I can to with this plugin or are there more possiblities to secure my website?

    Brute Force:

    id => 2908
    module => brute_force
    type => notice
    code => invalid-login::user-2
    timestamp => 2023-04-23 02:08:11
    init_timestamp => 2023-04-23 02:08:10
    remote_ip => 183.88.243.152
    user_id => [empty string]
    url => https://bluwingmedia.com/xmlrpc.php
    memory_current => 10284144
    memory_peak => 10302672
    data => Array
    details => Array
    source => xmlrpc
    authentication_types => Array
    0 => username_and_password
    user => Object WP_Error
    errors => Array
    incorrect_password => Array
    0 => Error: The password you entered for the username Bluwing is incorrect. Lost your password?
    error_data => Array()
    username => Bluwing
    user_id => [integer] 2
    SERVER => Array
    HTTP_HOST => bluwingmedia.com
    HTTP_X_REAL_IP => 183.88.243.152
    HTTP_X_FORWARDED_FOR => 183.88.243.152
    HTTP_CONNECTION => close
    CONTENT_LENGTH => 212
    HTTP_ACCEPT_ENCODING => gzip,deflate
    CONTENT_TYPE => application/octet-stream
    HTTP_USER_AGENT => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4895.86 Safari/537.36
    REQUEST_SCHEME => https
    SCRIPT_FILENAME => /home/www/wordpress/xmlrpc.php
    HTTP_AUTHORIZATION => [empty string]
    HTTPS => on
    SERVER_PROTOCOL => HTTP/1.0
    REQUEST_METHOD => POST
    REQUEST_TIME_FLOAT => [double] 1682215690.9298
    REQUEST_TIME => [integer] 1682215690

    Network Brute force:

    id => 2906
    module => ipcheck
    type => notice
    code => failed-login-by-blocked-ip
    timestamp => 2023-04-23 02:07:11
    init_timestamp => 2023-04-23 02:07:11
    remote_ip => 5.188.62.140
    user_id => [empty string]
    url => https://bluwingmedia.com/xmlrpc.php
    memory_current => 10291808
    memory_peak => 10310648
    data => Array
    details => Array
    source => xmlrpc
    authentication_types => Array
    0 => username_and_password

    Ah, right. Turns out your site is running on Nginx and despite disabling xmlrpc the xmlrpc.php file is still publicly accessible. So xmlrpc brute force attacks continue …

    Ideally you want to deny public access to the xmlrpc.php file from the web server layer. Unfortunately for Nginx you need to manually include the nginx.conf file into the Nginx server configuration. When disabling xmlrpc (on Nginx) the iTSec plugin writes some rules to a nginx.conf file. To see what those rules are navigate to:

    Security > Settings > Tools > Server Config Rules

    You’ll probably need to contact your hosting provider and ask them to help you get the nginx.conf file included into the Nginx server configuration.

    On top of that the Nginx server needs to be stopped/started (or nginx process reloaded) for the changes to have any effect.

    Once the disable xmlrpc configuration rules (nginx.conf) are in place attempting to access:

    https://www.example.com/xmlrpc.php

    should return a 403 Forbidden response.

    (This is all so much easier when running the site on Apache web server).

    • This reply was modified 1 year, 7 months ago by nlpro.
    • This reply was modified 1 year, 7 months ago by nlpro.

    Thanks I will get in contact with my hosting provider and will come back if I need further assistance.

    My hosting provider answered and said they cannot do this modification because the server runs on Apache2 and NGINX is only a backup proxy.

    Alternatively they suggested to block all accesses to xmlrpc.php via htaccess with the code:

    <Files xmlrpc.php>
    order deny,allow
    deny from all

    </Files>

    Would that help and would I still have access to my website?

    Hi @wpzugang,

    Ah ok. Before answering your question let’s make sure what your WordPress site says it is using: Apache or Nginx web server.

    Please navigate to:

    Tools > Site Health

    Click on the Info tab and then scroll down to the Server section. Expand the Server section and let me know the Web server option value (Apache or Nginx).

    Hi @nlpro, here it comes:

    Server architectureLinux 5.10.0-19-amd64 x86_64
    Web serverApache
    PHP version8.0.27 (Supports 64bit values)
    PHP SAPIapache2handler

    PHP max input variables 1000
    PHP time limit 30
    PHP memory limit 256M
    Max input time -1
    Upload max filesize 50M
    PHP post max size 50M
    cURL version 7.74.0 OpenSSL/1.1.1n
    Is SUHOSIN installed? No
    Is the Imagick library available? Yes
    Are pretty permalinks supported? Yes
    .htaccess rules Custom rules have been added to your .htaccess file.

    Ok, so it’s Apache.

    Now navigate to:

    Security > Settings > Tools

    Please confirm that under Server Config Rules (amongst other rules) the rules below exist:

    	# Disable XML-RPC - Security > Settings > WordPress Tweaks > XML-RPC
    	<files xmlrpc.php>
    		<IfModule mod_authz_core.c>
    			Require all denied
    		</IfModule>
    		<IfModule !mod_authz_core.c>
    			Order allow,deny
    			Deny from all
    		</IfModule>
    	</files>

    Note these rules are only expected to exist when the iTSec plugin XML-RPC setting is currently set to Disable XML-RPC.

    Also confirm these rules actually exist in your current .htaccess file.

    Okay I disabled XML-RPC at Settings -> Advanced -> WordPress Tweaks -> API Access.

    After a reload, I now have to following entry:

    # Disable XML-RPC - Security > Settings > WordPress Tweaks > XML-RPC
    	<files xmlrpc.php>
    		<IfModule mod_authz_core.c>
    			Require all denied
    		</IfModule>
    		<IfModule !mod_authz_core.c>
    			Order allow,deny
    			Deny from all
    		</IfModule>
    	</files>

    But not yet in the htaccess

    	# Protect System Files - Security > Settings > System Tweaks > System Files
    	<files .htaccess>
    		<IfModule mod_authz_core.c>
    			Require all denied
    		</IfModule>
    		<IfModule !mod_authz_core.c>
    			Order allow,deny
    			Deny from all
    		</IfModule>
    	</files>

    How to add it there?

    It may take a moment for the plugin to write the rules to the .htaccess file. I just tried accessing:

    https://www.example.com/xmlrpc.php

    (Replace https://www.example.com with your site domain).

    and I got the respons:

    Forbidden

    You don’t have permission to access this resource.

    So the rules should now be visible in the .htaccess file.

    Yes it is now there. I was probably too impatient:

    # Disable XML-RPC - Security > Settings > WordPress Tweaks > XML-RPC
    	<files xmlrpc.php>
    		<IfModule mod_authz_core.c>
    			Require all denied
    		</IfModule>
    		<IfModule !mod_authz_core.c>
    			Order allow,deny
    			Deny from all
    		</IfModule>
    	</files>

    Now I had no more brute forces since yesterday. From 750 attacks the day before yesterday down to zero today. Hoping it will stay like this.

    Thank you again for your time and help! ??

Viewing 12 replies - 16 through 27 (of 27 total)
  • The topic ‘What can do to more secure for “Site lockout notification”?’ is closed to new replies.