Login
Login

Login with your control panel details.

Forgot your Password or Username?

Articles in this section

See more

Protection For Common Login Areas

Avatar
Tony Phillips
Updated
Follow

PLEASE NOTE:

This article currently applies ONLY to our Linux Shared hosting servers.

It DOES NOT effect access to websites themselves - the blocks applies only to common bruteforce targets.

 

 

Covered Items:

 

 

What Did We Do?

We have implemented some extra security measures to help guard against attacks on sites using CMS systems like WordPress; the process blocks access to common login areas on those CMS, and other websites alike, and only from certain countries where we see the majority of attacks from.

 

 

Why?

We have seen an increased level of bruteforce activity against CMS websites - including Wordpress and Joomla, which has a negative effect of both being troublesome for websites, - with result of performance impact or possible compromise, and also causes a great deal of extra load on the webservers.

Usually we would identify the source of the traffic and simply block access from the source manually (and we still do), however we wish to be more proactive and deter this unwanted traffic - such is why we put these protections in place.

It should be noted however that while the traffic gets though, to the webserver, it is greeted with a 403 response - which is negligible in terms of bandwidth/load on the servers; the overall process simply deters bots from repeatably requesting the resource and they will, after a number of attempts, stop and move on.

 

 

What Is Blocked?

Currently, the following resources are blocked, under differing scenarios, based on previous traffic patterns from certain countries where we see the majority of attacks from; note that the blocking criteria is reviewed by our engineers regularly.

  • administrator.php
    • Joomla mostly, but can apply to other websites also.
  • wp-login.php
    • Wordpress Dashboard.
  • xmlrpc.php
    • Wordpress mostly, but can apply to other websites also.

 

Web Bots

As a side note, we are also blocking some web "Bots" due to their often aggressive crawler techniques which impact on both bandwidth and server resources; you can see more on this here:

Some Aggressive or Bad Bots We Have Blocked To Our Shared Hosting Network

 

 

How Do I Check For This?

The most likely scenario is that some of your Admins or Users - that login, may contact you about being unable to access the resource listed above - or otherwise you are unable to access the same.

As a visual aid, the screen you will see is shown below:

 

It should be noted that if you do see this - for the above resources, while the most likely scenario is a block (as per the protection in place), it is possible there is another reason for this screen; as this is the case, you will need to consult the error logs to determine if indeed it is as a result of the blocking in place.

Please see the following article in relation to checking your error logs:
Viewing error logs on cp.blacknight.com

 

In the error logs, you may notice something like the following - which is on one line (in the logs):

[Tue Sep 15 12:22:29 2015] [error] [client 192.168.0.1]
client denied by server configuration:
/usr/local/pem/vhosts/#####/webspace/httpdocs/wp-login.php

 

The important parts here are:

  • client 192.168.0.1
    • This indicates the IP address the request came from.
  • client denied by server configuration
    • This indicates that the block has been implemented via some DENY directive on the server (or in the website itself).
  • wp-login.php
    • This indicates the resource being accessed.
    • Note: This could be one of the above mentioned resources.

 

So in summary:

If you (or the requester) sees the screen above AND the above error is listed in the error logs for the Webspace, the likelihood is that the request is being blocked via our protection mechanism.

 

 

What Can I Use To Unblock The Affected URLs?

There are a number of ways to accomplish this - depending on what suits your scenario; albeit all require you to add entries to Whitelist, in respective .htaccess files in your Webspace/Websites.

 

1) Unblock By Country Code

You may find that the requests - to the blocked resources, may be coming from IP addresses in common locations - usually in this case unblocking via the country code that contains these IPs can be preferable.

The issue with this method however is that you may also allow through unintended traffic i.e. bruteforce, as this method opens the resources to many networks in that country.

# Whitelist Countries
SetEnvIf GEOIP_COUNTRY_CODE IE Whitelist
SetEnvIf GEOIP_COUNTRY_CODE UK Whitelist
SetEnvIf GEOIP_COUNTRY_CODE US Whitelist

 

Notes: 

  • You can see the a full listing for country codes as per the following:
  • You can add multiple lines, for each country to be Whitelisted.
  • It is important to be careful of the formatting of the lines:
    • Incorrect entry can be in effective and/or break your website.

 

 2) Unblock By Source IP Address

This method is more of a specific process, where you Whitelist per IP address (or IP range).

The issue with this method however is you may need to update it on a regular basis, should the source IP be a Dynamic IP or the access is coming from various different locations.

# Whitelist Specific IP Address
SetEnvIf Remote_Addr ^(10\.20\.30\.40) Whitelist
SetEnvIf Remote_Addr ^(11\.21\.31\.41) Whitelist
# Whitelist IP Ranges 
#     e.g: 10.20.30.40 AND 20.30.40.0/24
SetEnvIf Remote_Addr ^(10\.20\.30\.40|20\.30\.40\.) Whitelist

 

Notes: 

  • You can multiple lines, for each item(s) to be Whitelisted
  • Be sure to put a '\' in front of each dot:
    • A a dot is considered a wildcard in regular expression terms.
  • It is important to be careful of the formatting of the lines:
    • Incorrect entry can be in effective and/or break your website.

 

 

Where Do I Put This Code?

The above code is placed in a number of places in your Webspace - where depends on your scenario.

 

1) Default Locations

There two locations that the code must go into, to allow both normal (http://) and secured (https://) traffic; however note that this applies to all websites/targets listed under those locations.

# Normal Traffic (http://)
#
webspace/httpdocs/.htaccess

# Secured Traffic (https://) - where applicable.
#
webspace/httpsdocs/.htaccess

 

Note: 

  • The unblocking code should be placed at the TOP of the file.
  • If the .htaccess file does not exist at these locations, you will need to create them as required.

 

2) Specific Locations

You can unblock only specific websites/targets if you wish.

In this scenario you would simply add the unblocking code to the relevant folder that contains the website (or resource) - for example.

# Normal Traffic (http://)
#
webspace/httpdocs/domain.tld/.htaccess

# Secured Traffic (https://) - where applicable.
#
webspace/httpsdocs/domain.tld/.htaccess

 

Note: 

  • The unblocking code should be placed at the TOP of the file.
  • If the .htaccess file does not exist at these locations, you will need to create them as required.

 

3) Site Applications

The main caveat to all of this is where you have Site Application installations effected by the protection.

In this scenario, you have to combine process 1 or 2 (above) while also adding the unblocking code to the .htaccess file at the root of the installation - for example.

# Normal Traffic (http://)
#
webspace/httpdocs/.htaccess
webspace/siteapps/siteapp-folder/htdocs/.htaccess

# Secured Traffic (https://) - where applicable.
#
webspace/httpsdocs/.htaccess
webspace/siteapps/siteapp-folder/htdocs/.htaccess

 

Note: 

 

 

Is That All I Need To Be Aware Of?

For the most part, carrying out the steps above is all you will need to do to unblock the requester, however note the below. 

 

1) Your website's performance may be effected by the allowed traffic

This would especially be the case where you allow all traffic, as a result should your website have an impact on the server's performance we will be forced to disable your website.

As this is the case you will need to implement your own blocking mechanisms to deter bruteforce traffic - the various CMS systems have various third-party plugins/services to allow for this; for example - in the case of Wordpress, popular plugins to deter bruteforce are Wordfence and Securi.

 

2) Your website's security may be impacted

If you do not have bruteforce protection, and your website allows consistent login checks, it is possible in time that your website will become compromised.

If you website becomes compromised, the attackers can:

  • Deface the website.
  • Inject code - or use existing vulnerabilities, to abuse other networks.
  • Inject code - or use existing vulnerabilities, to send spam (abuse/performance impacting).
  • Inject code - or use existing vulnerabilities, to target users in Phishing scams.
  • Implement various other nefarious or malicious process.

Obviously if the website is compromised, it is not an ideal situation for the owner/account holder.

Similarly it is not an ideal situation for us where the compromise is performance effecting or abusive to other networks; in such a scenario we will also be forced to disable the website until such time you resolve the issue.

 

 

Additional Support

As always, should you require more assistance in relation to this issue, please contact our Helpdesk explaining your issue - and what you have done to this point, and we will be happy to assist you further.

Please see our full contact information, on our main website: Contact Us.

Alternatively, email help@blacknight.com for assistance.

 

 

Related articles

Get more from Blacknight

Comments

0 comments

Article is closed for comments.