1-2-3 Secure a WordPress Website

images

Securing WordPress has become easy thanks to the amazing work the WordPress team continuously do to fix vulnerabilities and improve the security of the platform. With the addition of Wordfence, it is possible to run a secure WordPress site and sleep well at night knowing your investment is safe.

1. Ensure that your site is backed up

Backups are the first step in securing your website. Your backups ensure that even if your site is compromised or damaged in some way, you can always recover it. We suggest running a full backup before making the changes below so that you can recover your site if you break anything. In addition to Daily scheduled backup, you can always submit a request to back your site manually anytime you like.

2. Delete any themes, plugins or extensions that you don’t need or that aren’t maintained

Sign in to your WordPress site and go to Plugins > Installed Plugins. Delete any plugins that you no longer use. Check everything else and make sure you recognize it and use it.

You can click the “Details” link next to each plugin to see when it was last updated. We strongly recommend that you delete any plugin that has not been updated for 2 years or more. It is unlikely that the author is maintaining the plugin and if a vulnerability is reported, it may not be fixed quickly.

Do the same for WordPress themes. Go to Appearance > Themes. Then delete any themes you no longer use. If you switched themes at some point and still require images in another theme directory, we recommend you delete as much as you can of the legacy theme and just preserve static assets like images and stylesheets.

Deleting old extensions, plugins and themes will remove them as potential entry points for a hacker.

3. custom WordPress themes?

If your theme is custom designed and you aren’t able to update it, you are going to need a developer to maintain that software. This is an unfortunate reality and expense of having a custom theme installed. You can’t just install and forget.

Many themes use libraries that eventually have vulnerabilities discovered in them. If your theme is not maintained, your site will eventually become hacked through this vulnerable software. When engaging the services of a company that designs custom WordPress websites, you should ask them if they will be maintaining any custom software they install on your WordPress site.

 

How To Protect WordPress from XML-RPC Attacks

wordpress-xml-rpc

Introduction

WordPress is a popular and powerful CMS (content management system) platform. Its popularity can bring unwanted attention in the form of malicious traffic specially targeted at a WordPress site.

NOTE: Wpstack takes care of all these for you out of the box.

There are many instances where a server that has not been protected or optimized could experience issues or errors after receiving a small amount of malicious traffic. These attacks result in exhaustion of system resources causing services like MySQL to be unresponsive. The most common visual cue of this would be an Error connecting to database message. The web console may also display Out of Memory errors.

This guide will show you how to protect WordPress from XML-RPC attacks on an Ubuntu 14.04 system.

What is XML-RPC?

WordPress utilizes XML-RPC to remotely execute functions. The popular plugin JetPack and the WordPress mobile application are two great examples of how WordPress uses XML-RPC. This same functionality also can be exploited to send thousands of requests to WordPress in a short amount of time. This scenario is effectively a brute force attack.

 Recognizing an XML-RPC Attack

The two main ways to recognize an XML-RPC attack are as follows:

1) Seeing the “Error connecting to database” message when your WordPress site is down
2) Finding many entries similar to "POST /xmlrpc.php HTTP/1.0” in your web server logs

The location of your web server log files depends on what Linux distribution you are running and what web server you are running.

For Apache on Ubuntu 14.04, use this command to search for XML-RPC attacks:

  • grep xmlrpc /var/log/apache2/access.log

For Nginx on Ubuntu 14.04, use this command to search for XML-RPC attacks:

  • grep xmlrpc /var/log/nginx/access.log

Your WordPress site is receiving XML-RPC attacks if the commands above result in many lines of output, similar to this example:

access.log
111.222.333.444:80 555.666.777.888 - - [01/Jan/2016:16:33:50 -0500] "POST /xmlrpc.php HTTP/1.0" 200 674 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

The rest of this article focuses on three different methods for preventing further XML-RPC attacks.

Method 1: Installing the Jetpack Plugin

Ideally, you want to prevent XML-RPC attacks before they happen. The Jetpack plugin for WordPress can block the XML-RPC multicall method requests with its Protect function. You will still see XML-RPC entries in your web server logs with Jetpack enabled. However, Jetpack will reduce the load on the database from these malicious log in attempts by nearly 90%.

Note: A WordPress.com account is required to activate the Jetpack plugin.

Jetpack installs easily from the WordPress backend. First, log into your WordPress control panel and select Plugins->Add New in the left menu.

WordPress Plugins Menu

Jetpack should be automatically listed on the featured Plugins section of the Add New page. If you do not see it, you can search for Jetpack using the search box.

Jetpack Install Page

Click the Install Now button to download, unpack, and install Jetpack. Once it is successfully installed, there will be an Activate Plugin link on the page. Click that Activate Plugin link. You will be returned to the Plugins page and a green header will be at the top that states Your Jetpack is almost ready!. Click the Connect to WordPress.com button to complete the activation of Jetpack.

Connect to WordPress.com button

Now, log in with a WordPress.com account. You can also create an account if needed.

Log into WordPress.com form

After you log into your WordPress.com account, Jetpack will be activated. You will be presented with an option to run Jump Start which will automatically enable common features of Jetpack. Click the Skip link at this step.

Jump Start Screen.

The Protect function is automatically enabled, even if you skip the Jump Start process. You can now see a Jetpack dashboard which also displays the Protect function as being Active. White list IP addresses from potentially being blocked by Protect by clicking the gear next to the Protect name.

Jetpack Dashboard

Enter the IPv4 or IPv6 addresses that you want to white list and click the Save button to update the Protect white list.

Protect Settings

Method 2: Manually Blocking All XML-RPC Traffic

Alternatively, the XML-RPC block can manually be applied to your Apache or Nginx configuration.

For Apache on Ubuntu 14.04, edit the configuration file with the following command:

  • sudo nano /etc/apache2/sites-available/000-default.conf

Add the highlighted lines below between the <VirtualHost> tags.

Apache VirtualHost Config
<VirtualHost>
…    
    <files xmlrpc.php>
      order allow,deny
      deny from all
    </files>
</VirtualHost>

Save and close this file when you are finished.

Restart the web server to enable the changes:

  • sudo service apache2 restart

For Nginx on Ubuntu 14.04, edit the configuration file with the following command (change the path to reflect your configuration file):

  • sudo nano /etc/nginx/sites-available/example.com

Add the highlighted lines below within the server block:

Nginx Server Block File
server {
…
 location /xmlrpc.php {
      deny all;
    }
}

Save and close this file when you are finished.

Restart the web server to enable the changes:

  • sudo service nginx restart

Warning: This method will stop anything that utilizes XML-RPC from functioning, including Jetpack or the WordPress mobile app.

Verifying Attack Mitigation Steps

Whatever method you chose to prevent attacks, you should verify that it is working.

If you enable the Jetpack Protect function, you will see XML-RPC requests continue in your web server logs. The frequency should be lower and Jetpack will reduce the load an attack can place on the database server process. Jetpack will also progressively block the attacking IP addresses.

If you manually block all XML-RPC traffic, your logs will still show attempts, but the resulting error code be something other than 200. For example entries in the Apache access.log file may look like:

access.log
111.222.333.444:80 555.666.777.888 - - [01/Jan/2016:16:33:50 -0500] "POST /xmlrpc.php HTTP/1.0" 500 674 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

Conclusion

By taking steps to mitigate malicious XML-RPC traffic, your WordPress site will consume less system resources. Exhausting system resources is the most common reason why a WordPress site would go offline on a VPS. The methods of preventing XML-RPC attacks mentioned in this article along with will ensure your WordPress site stays online.

To learn more about brute force attacks on WordPress XML-RPC, read Sucuri.net — Brute Force Amplification Attacks Against WordPress XMLRPC.

 

Thousands of Hacked Home Routers are Attacking WordPress Sites

 

wordpresswebsite-are-under_attack

Update: By popular request, we have created a tool that lets you check if your own home router is vulnerable to the problems discussed in this post. Visit this page to check if your home router has port 7547 open or if it’s running a vulnerable version of RomPager.

Last week, while creating the Wordfence monthly attack report, we noticed that Algeria had moved from position 60 in our “Top Attacking Countries” list to position 24. That was a big jump and we were curious why Algeria had climbed the attack rankings so rapidly.

What we discovered on closer examination is that over 10,000 IP addresses in Algeria were attacking WordPress websites in March. Most IPs were only launching between 50 and 1000 attacks during the entire month.

The following chart is a histogram. It groups IP addresses by the number of times they attacked. As you can see by the spike on the left, the most common number of attacks was around 100 to 200 for an IP address. Few of the attacking IPs generated more than 2,000 attacks during the entire month of March, 2017.

We wanted to learn more about these attacking IPs, so we dug a little deeper.

A Botnet Using Burst Attacks

We extracted the list of Algerian attack IPs and we included the time of first attack logged and the time of last attack logged. The majority of the IPs spent just a few hours attacking and then stopped for the rest of the month. The histogram below shows how many IPs spent less than a day (shown as 0) attacking compared to those that spent 1 or more days. As you can see over 7,000 IPs spent just a few hours attacking during March before they stopped.

These IPs switch on, perform a few attacks and then switch off and aren’t heard from again for a month. What we have found is a botnet that is distributed across thousands of IPs. Each IP is only performing a few attacks, those attacks are spread across many websites and the attacks only last a few minutes or hours.

The attacker controlling this botnet is using several evasive techniques. They are spreading their attacks across a very large number of IP addresses. They are using low frequency attacks to avoid being blocked. They are also spreading their attacks across a large number of WordPress sites.

These evasive techniques indicate a higher level of sophistication than we see from, for example, “PP Sks-Lugan” which we’ve written about in the past where we see a single IP generating millions of attacks.

Hacked Home Routers Hacking WordPress

When we looked at who owns each of the attacking IPs in Algeria, we found, over 97% of them are owned by Telecom Algeria. There are approximately 30 different ISPs in Algeria. We do see some attacks from other networks, but nothing compared to the volume that originates from Telecom Algeria.

The attacks we saw in March originated from the following networks:

  • 41.96.0.0/12 which ranges from 41.96.0.0 to 41.111.255.255 had 4671 attacking IPs in March.
  • 105.96.0.0/12 which ranges from 105.96.0.0 to 105.111.255.255 had 4591 attacking IPs in March.
  • 154.240.0.0/12 which ranges from 154.240.0.0 to 154.255.255.255 had 715 attacking IPs in March.
  • 197.112.0.0/13 which ranges from 192.112.0.0 to 197.119.255.255 had 401 attacking IPs in March.

Telecom Algeria is the state owned telecommunications provider in Algeria. It is therefore the largest telecommunications provider in the country.

We performed a network survey on a sample of 8,962 IPs on Telecom Algeria’s network. We received responses from 3,855 IP addresses.

Out of those IPs we discovered that  1501 are Zyxel routers that are listening on port 7547 and are running “Allegro RomPager 4.07 UPnP|1.0 (ZyXEL ZyWALL 2)”.

Allegro RomPager 4.07 is an embedded web server that has a severe vulnerability, dubbed the Misfortune Cookie by Checkpoint, who discovered it in 2014. The identifier is CVE-2014-9222.

It appears that attackers have exploited home routers on Algeria’s state owned telecommunications network and are using the exploited routers to attack WordPress websites globally.

Other ISPs With Vulnerable Routers

Algeria drew our attention because its country ranking jumped from 60 to 24 in our top attacking countries for March. Once we took a closer look at the attacking IPs, we were able to identify a specific pattern of behavior for these attack IPs:

  • They generally attack for less than 48 hours and then stop.
  • Most of them generate less than 1000 attacks.
  • There is usually a large number of attacking IPs on a single ISP.

By searching for similar patterns, we found that there are several other ISPs that seem to have the same problem that Telecom Algeria has.

BSNL – India

BSNL is a state owned telecommunications provider in India. During March we saw attacks from 11,495 IPs on their network.

In a survey of BSNLs network, we found that:

  • 11,495 IPs on BSNLs network attacked WordPress sites in March.
  • Out of those attacking IPs, 4857 IPs also have port 7547 open.
  • We found that 1635 of the IPs that attacked WordPress sites are also running “Allegro RomPager 4.07 UPnP|1.0 (ZyXEL ZyWALL 2)” which is vulnerable.

PLDT aka. Philippine Long Distance Telephone

PLDT is the largest telecommunications provider and digital services company in the Philippines.

In a survey of PLDT’s network we found that:

  • 3697 IPs on their network attacked WordPress sites in March.
  • 1612 of those attacking IPs on PLDTs network have port 7547 open.
  • 137 of those IPs are running “Allegro RomPager 4.07 UPnP|1.0 (ZyXEL ZyWALL 2)” which is vulnerable to remote exploitation.

28 ISPs with Suspicious Attack Patterns Indicating Compromised Routers

Once we could identify the attack pattern of compromised routers, we searched for other ISPs where the attack patterns fit the same criteria. That is, low frequency of attacks, each IP attacks for less than 48 hours and a large number of IPs are attacking WordPress sites from a specific ISP.

This is the full list of ISPs we found globally where attacks that match this criteria are originating from. Notice the low “average attacks per IP column” on the right of the table (scroll right) and the large number of attacking IPs per ISP.
https://airtable.com/embed/shrki8Dpy5C0gn21x?backgroundColor=cyan&viewControls=on

What is port 7547 and TR-069 and why is it a problem?

Port 7547 is a management port on home routers. It allows ISPs to manage the routers that their customers use on their home networks. It uses a protocol called TR-069 to provide a management interface. The TR-069 protocol can be used to provision devices, provide tech support and remote management, monitor routers for faults, for diagnostics, to replace a faulty configuration and to deploy upgraded firmware.

This protocol and port has had at least two serious security vulnerabilities associated with it in the past 4 years.

We have already mentioned the misfortune cookie vulnerability which targets management port 7547 and which some of the ISPs above are suffering from. RomPager version 4.07 suffers from the misfortune cookie vulnerability. In the ISPs that we are seeing attacks originating from, 14 out of 28 ISPs have remotely accessible routers that have a vulnerable version of RomPager version 4.07 on port 7547

Another vulnerability emerged in November last year which allows an attacker to use port 7547 and the management interface to gain administrative access to a router.

6.7% of Attacks on WordPress Sites are from Home Routers with Port 7547 Open

In addition to the network surveys we did on ISPs from which attacks are originating, we also surveyed 865,467 additional IP addresses which have engaged in brute force or complex attacks during the past 3 days. Out of those, 57,971 have port 7547 open indicating that they are home routers from which attacks are originating.

That means that 6.7% of all attacks on WordPress sites that we protect, during the past 3 days, came from home routers that have port 7547 open.

Shodan, an internet survey search engine, currently shows that over 41 million devices on the Internet are listening on port 7547. The TR-069 protocol is widely used among ISPs world-wide.

 

The Security Risk to Home Users

If a home router is successfully exploited, an attacker can access your internal home network. They have penetrated any firewall function that the router provides and can also bypass router network address translation. This enables them to exploit internal targets like workstations, mobile devices using WiFi and IoT devices like home climate control systems and home cameras.

We are already seeing bulk exploitation of TR-069 which has turned home routers into a botnet attacking WordPress sites. It is quite feasible that home network exploitation is already underway as well.

Security Risk to the Internet at Large

OVH was hit by a 1 Terabyte DDoS attack in September last year, one of the largest in history. Approximately 152,000 IOT (Internet of Things) devices that had been compromised generated the traffic in that attack.

In just the past month we have seen over 90,000 unique IP addresses at 28 ISPs that fit our compromised-router attack pattern. We monitor these attacks across our customer websites which is an attack surface of over 2 million websites. We only see a sample of the attacks that all websites globally experience. If you extrapolate the numbers, it indicates that there is a very large number of compromised ISP routers out there performing attacks and acting in concert.

At this point it would not be a stretch to say that vulnerabilities in TR-069 may have created a very large botnet which could soon generate the largest DDoS attack the Internet has ever seen.

How ISPs can help

Exposing port 7547 to the public Internet gives attackers the opportunity to exploit vulnerabilities in the TR-069 protocol. ISPs should filter out traffic on their network coming from the public internet that is targeting port 7547. The only traffic that should be allowed is traffic from their own Auto Configuration Servers or ACS servers to and from customer equipment.

There are already a large number of compromised routers out there. ISPs should immediately start monitoring traffic patterns on their own networks for malicious activity to identify compromised routers. They should also force-update their customers to firmware that fixes any vulnerabilities and removes malware.

What we are doing

At Wpstack Wordfence powered, We run a real-time IP blacklist for our premium customers. We are adjusting our blacklist algorithms to identify and include IP addresses that engage in these kinds of attacks. We are also working to create awareness among ISPs and security professionals about the risk that TR-069 presents and how they can help to mitigate that risk.

Source: https://www.wordfence.com/blog/2017/04/home-routers-attacking-wordpress/?utm_source=list&utm_medium=email&utm_campaign=041117

Is your website HTTP/2 Ready??

HTTP/2 (originally named HTTP/2.0) is a major revision of the HTTP network protocol used by the World Wide Web. It was developed from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2was developed by the Hypertext Transfer Protocol working group httpbis (where bis means “second”) of the Internet Engineering Task Force. HTTP/2 is the first new version of HTTP since HTTP 1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to IESG for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 in May 2015.

The standardization effort was supported by Chrome, Opera, Firefox, Internet Explorer 11, Safari, Amazon Silk, and Edge browsers. Most major browsers added HTTP/2 support by the end of 2015.

According to W3Techs, as of January 2017, 12.7% of the top 10 million websites supported HTTP/2.

Differences from HTTP 1.1

The proposed changes do not require any changes to how existing web applications work, but new applications can take advantage of new features for increased speed.[13]

HTTP/2 leaves most of HTTP 1.1’s high-level syntax, such as methods, status codes, header fields, and URIs, the same. The element that is modified is how the data is framed and transported between the client and the server.

Websites that are efficient minimize the number of requests required to render an entire page by minifying (reducing the amount of code and packing smaller pieces of code into bundles, without reducing its ability to function) resources such as images and scripts. However, minification is not necessarily convenient nor efficient and may still require separate HTTP connections to get the page and the minified resources. HTTP/2 allows the server to “push” content, that is, to respond with data for more queries than the client requested. This allows the server to supply data it knows a web browser will need to render a web page, without waiting for the browser to examine the first response, and without the overhead of an additional request cycle.

Additional performance improvements in the first draft of HTTP/2 (which was a copy of SPDY) come from multiplexing of requests and responses to avoid the head-of-line blocking problem in HTTP 1 (even when HTTP pipelining is used), header compression, and prioritization of requests.

How can I test if my website is HTTP/2 Enabled:

You can visit https://tools.keycdn.com/http2-test  to test if your website is HTTP/2 ready. Wpstack is one of the early Managed WordPress hosting platform which offers HTTP/2 out of the box.

Encryption:

HTTP/2 is defined for both HTTP URIs (i.e. without encryption) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required).

Although the standard itself does not require usage of encryption, most client implementations (Firefox,Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.

HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol.

The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.

The basis of the work was SPDY, but HTTP/2 has evolved to take the community’s input into account, incorporating several improvements in the process.

Github: https://http2.github.io/