Title: Delete Xmlrpc.php Last modified: August 22, 2016 --- # Delete Xmlrpc.php * [H1cH4m](https://wordpress.org/support/users/h1ch4m/) * (@h1ch4m) * [11 years, 9 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/) * Hi , i want to secure my wordpress blog against brute forcing with the use of xmlrpc.php file , is there any way to do that , also if i just delete the file, is the blog will work normal or not ? Viewing 8 replies - 1 through 8 (of 8 total) * Moderator [James Huff](https://wordpress.org/support/users/macmanx/) * (@macmanx) * [11 years, 9 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253665) * If you remove xmlrpc.php, you won’t be able to use the mobile apps or certain plugins, like Jetpack. Though vulnerable to brute-force, it’s still a necessary file. After all, wp-login.php is vulnerable to brute-force too, but you won’t delete that. 😉 * First, add this to your .htaccess file: * ``` RewriteEngine On RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php* RewriteCond %{HTTP_REFERER} !.*(example.com|jetpack.wordpress.com).* [OR] RewriteCond %{HTTP_USER_AGENT} ^$ RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L] ``` * Replace “example.com” with your domain, and if you aren’t using Jetpack Comments, remove “|jetpack.wordpress.com”. * This will prevent bots from directly attacking wp-login.php and wp-comments-post. php, they will need to go through the forms to login or leave comments. This is important, as wp-login.php can be protected this way, which will present much less load for your server than a plugin guarding everything. * After that, install a plugin like [http://wordpress.org/plugins/bruteprotect/](http://wordpress.org/plugins/bruteprotect/) to both catch anything else that makes it through and protect xmlrpc.php. * Thread Starter [H1cH4m](https://wordpress.org/support/users/h1ch4m/) * (@h1ch4m) * [11 years, 9 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253679) * well , to secure wp-login.php is easy , just put a firewall , but the problem isl in xmrpc.php , people use it to brute force using POST method , also if i secure wp-login.php and somebody use xmlrpc.php and get the user and password, what he can do with it ? * Moderator [James Huff](https://wordpress.org/support/users/macmanx/) * (@macmanx) * [11 years, 9 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253681) * You can install a plugin like [http://wordpress.org/plugins/bruteprotect/](http://wordpress.org/plugins/bruteprotect/) to both catch anything else that makes it through and protect xmlrpc.php. 😉 * Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/) * (@bcworkz) * [11 years, 9 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253684) * I second the need for another layer of protection from brute force attacks beyond checking HTTP_REFERER. All brute force attacks I’ve observed provided the correct referrer field even though access logs indicate they never requested the pages they purported to be from. * The referrer check might deter a few script kiddies, but savvy attackers know enough to not get caught that way. More aggressive protection is very much warranted. * Thread Starter [H1cH4m](https://wordpress.org/support/users/h1ch4m/) * (@h1ch4m) * [11 years, 9 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253729) * also BruteProtect plugin can be bypassed if someone programme a script for brute forcing and using a proxy each time he get banned * Moderator [James Huff](https://wordpress.org/support/users/macmanx/) * (@macmanx) * [11 years, 9 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253730) * Well, that could be said for any brute force protection. BruteProtect uses a cloud-based blacklist built by analyzing brute force attacks again all BruteProtect users, so the chances of repeat attacks getting through (even via proxy) is incredibly slim, plus most bots don’t bother to go to the trouble (there are much easier fish to catch out there). * [Thomas O.](https://wordpress.org/support/users/thomas-o/) * (@thomas-o) * [11 years, 9 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253783) * I usually don’t share too many of my creations, but I figure it’s time. You can use .htaccess to block abnormal behavior, as most skiddies don’t have their scripts set up completely. Yet, I do see a few that do. Granted most headers can be spoofed, the majority of legitimate browsers either have them or don’t and they are either normal or they’re not normal. The code is below with explanations in the comments. The only thing you might want to change is the RewriteRule. It could include comments.php and/or other files. And the target of the RewriteRule could be changed to whatever you want as well. Sending it back to the sender or even redirecting to a 404 Not Found page, but I digress. That’s your choice. I just placed example. com, but you can do whatever you want. * ``` # WordPress login and brute-force protection # First set a cookie # Where cookie-name is your cookie name # Where cookie-value is your cookie value # Where example.com is where the cookie is valid (your domain) RewriteRule ^ - [CO=cookie-name:cookie-value:example.com] # If no cookie, then bounce them RewriteCond %{HTTP_COOKIE} !cookie-name=cookie-value [OR] # If referrer doesn't match the HTTP host, then bounce them # Comment out the line below if your server does not incorporate Atom Back References RewriteCond %{HTTP_HOST}@@%{HTTP_REFERER} !^([^@]*)@@https?://\1/ [NC,OR] # If a known proxy header is detected, then bounce them # You can always add others. These are just the ones I mainly see. RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR] RewriteCond %{HTTP:X-FORWARDED-FOR} !^$ [OR] RewriteCond %{HTTP:HTTP_CLIENT_IP} !^$ [OR] RewriteCond %{HTTP:HTTP-CLIENT-IP} !^$ [OR] RewriteCond %{HTTP:VIA} !^$ [OR] # If not a valid GET or POST request, then bounce them # This is more than just allowing a GET or POST request only. The request must be valid. RewriteCond %{THE_REQUEST} !^(?:GE|POS)T\ .+\ HTTP/1\.1$ [NC,OR] # Since HEAD is implied with GET, bounce it because it should not be used on the login RewriteCond %{REQUEST_METHOD} ^HEAD [NC,OR] # If the known header fields for most humans are not present or invalid, then bounce them RewriteCond %{HTTP:Connection} !^keep-alive$ [NC,OR] RewriteCond %{HTTP:Accept-Encoding} !^gzip [NC,OR] # If your site is only viewed in English, they you could modify the line below to look like this: # RewriteCond %{HTTP:Accept-Language} !en [OR] RewriteCond %{HTTP:Accept-Language} ^.?$ [OR] RewriteCond %{HTTP_USER_AGENT} ^(?:.{0,49}|.{299,})$ [OR] RewriteCond %{HTTP_USER_AGENT} \n [OR] RewriteCond %{HTTP_ACCEPT} ^(?:\*/\*|.)?$ RewriteRule wp-login\.php http://example\.com [R=301,L,NS] ``` * [rossino](https://wordpress.org/support/users/rossino/) * (@rossino) * [11 years, 5 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253919) * Thank you for sharing Thomas, it is really an interesting solution. Viewing 8 replies - 1 through 8 (of 8 total) The topic ‘Delete Xmlrpc.php’ is closed to new replies. * In: [Hacks](https://wordpress.org/support/forum/plugins-and-hacks/hacks/) * 8 replies * 5 participants * Last reply from: [rossino](https://wordpress.org/support/users/rossino/) * Last activity: [11 years, 5 months ago](https://wordpress.org/support/topic/delete-xmlrpcphp/#post-5253919) * Status: not resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics