Databases, Systems & Networks

If you run a wordpress blog these days, you are likely to experience brute force attacks where nefarious individuals attempt to break in to your website by quickly a list of userids and passwords against your wp-login.php.  Here’s how I automated detection and blocking of WordPress brute force login attacks.

Detecting a WordPress Brute Force Attack

One can typically detect a wordpress brute force attack by parsing through your webserver’s access_log file.  The access_log file records all of the access requests that a web server handles.  A brute force attack typically will have frequent and numerous attempts to the wp-login.php file as shown below:

Example:  In the access_log file below, we detect a brute force login attack on our WordPress blog.  We detected it by noticing frequent and constant requests to the wp-login.php file.

31.192.210.159 - - [11/Sep/2014:02:01:43 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:44 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:45 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:47 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:49 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:50 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:51 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:52 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:54 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:55 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"

Typically in an event like this, I lookup the IP address in the ARIN database as I showed in a previous article:  What Personal Information Can You Get From Your Web Server?  Frequently, I find that the address is from APAC or RIPE addresses.

Lire la suite…

WordPress is one of the most popular content publishing platform used by some of the very high traffic website. Beauty of the wordpress is in its simplicity. If you will setup your WordPress correctly then your website performance will be fantastic. In this article we will explore various aspect of the WordPress Performance Tuning. Before going further let me clear that why you need to optimize your WordPress website performance.

Why you should spend time on WordPress Performance Tuning ?

Performance tuning or Optimization is required due to following reason:

1. If you will correctly optimize or tune your WordPress performance then your visitor experience will be better.
2. Search engines are giving high preference to high speed website.  So your SEO will be improved.
3. Sometime while doing your WordPress performance tuning you will analyzed and remove unwanted thing from your WordPress which reduce your server work. So your server will have less load.

Tool / Plugin / Stuff you need while WordPress Performance tuning

WordPress performance tuning does not mean to only changing some configuration of your WordPress. There are several area where you need to fine tune like apache(your webserver), Mysql etc. So before going further you need following tool/plugin

1. Installation of plugin w3 total plugin.
2. Firefox web browser with firebug tool.
3. Google Page Speed Test  or GT Metrix.
4. SSH connection to your server (only required if you want to tune Apache and MySQL performance).
5. A good Internet speed.

Before going further for your WordPress Performance Tuning please arrange above written tool.

Analyze your WordPress Performance

Before going to optimize your WordPress Performance you need to analyze that whether your website performance is good or bad. Or in other word we can say that you need to check whether your website is served quickly or not. Following are the factor which mainly affect your website performance and you need to check.

1. Time taken to load your web page
2. Number of CSS, js and Images are getting downloaded on every request
3. CSS and JS are placed correctly or not.

You can check your website performance in either Google Page Speed or Gtmetrix. I prefer to use Gtmetrix. Both tool will gives rating to your website Speed and suggestion to improve your website performance further. Gtmetrix will also provide you the timeline waterfall(what is repose time of your website and how many images, css , js or other resources are getting downloaded) of your website. I prefer Gtmetrix because of TimeLine waterfall feature.
You will get following type snapshot for your website in Gtmetrix

In above snapshot you can see the following 4 tab

1. Page Speed : In this tab you can find your website performance analysis with GooglePageSpeed.
2. YSlow : In this tab you can find your website performance analysis with YSlow.
3. TimeLine : In this tab you can find your website page load water fall.
4. History: In this tab you can find previous history of your website page speed test if you did the test in in future.

Lire la suite…

Graphs on Munin

Enable and disable plugins on each node

rm /etc/munin/plugins/diskstats
service munin-node restart

ln -s /usr/share/munin/plugins/diskstats /etc/munin/plugins/diskstats
service munin-node restart

Process Backgrounded
2014/03/10-15:59:47 Munin::Node::Server (type Net::Server::Fork) starting! pid(32231)
Resolved [*]:4949 to [::]:4949, IPv6
Not including resolved host [0.0.0.0] IPv4 because it will be handled by [::] IPv6
Binding to TCP port 4949 on host :: with IPv6
2014/03/10-16:00:04 CONNECT TCP Peer: "[::ffff:203.28.51.227]:45965" Local: "[::ffff:50.23.111.122]:4949"
2014/03/10-16:05:04 CONNECT TCP Peer: "[::ffff:203.28.51.227]:46109" Local: "[::ffff:50.23.111.122]:4949"
2014/03/10-16:10:04 CONNECT TCP Peer: "[::ffff:203.28.51.227]:46109" Local: "[::ffff:50.23.111.122]:4949"

How to set-up a high-availability cluster

Here are a few notes about how to set-up a high-availability web server farm using Ubuntu 12.04 LTS using a whole load of awesome software (HAProxy, HeartBeat, Watchdog and Nginx)

The setup

In my setup I have five virtual machines, these are named and used for the following:-

haproxy1 – Our first proxy (master)/load-balancer (running HAProxy, HeartBeat and Watchdog) [IP address: 172.25.87.190]
haproxy2 – Our second proxy (failover)/load-balancer (running HAProxy, HeartBeat and Watchdog) [IP address: 172.25.87.191]
web1 – Our first web server node (running nginx) [IP address: 172.25.87.192]
web2 – Our second web server node (running nginx) [IP address: 172.25.87.193]
web3 – Our third web server node (running nginx) [IP address: 172.25.87.194]

The servers are connected in the following way:-

In my next post I will also explain how to configure the web servers to point to a backend shared storage cluster (using NFS) and a MySQL cluster server to have a truly highly available web hosting platform.

Lets get going…

Firstly, add the following to each of your server’s /etc/hosts file (to ensure all machines can resolve each other’s hostnames)

172.25.87.180 yoursite.com #This is our 'floating' (virtual IP) for our web-cluster.
172.25.87.190 haproxy1
172.25.87.191 haproxy2
172.25.87.192 web1
172.25.87.193 web2
172.25.87.194 web3
10.100.100.1 haproxy1
10.100.100.2 haproxy2

Next ensure that both of the load balancers (haproxy1 and haproxy2) have a second network card installed so we can configure a separate ‘monitoring’ network between the two load-balancers. The second network card will enable Heartbeat to constantly send ‘Im alive’ messages to one another, when the master stops responding to the fail-over load-balancer, the fail-over proxy will take over! This image on the left demonstrates how this looks.

The network configuration in /etc/network/interfaces should look as follows:

On haproxy1 (Our master load-balancer):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
 address 172.25.87.190
 netmask 255.255.255.0
 gateway 172.25.87.1
 dns-nameservers 8.8.8.8 8.8.4.4
auto eth0:1
iface eth0:1 inet static
 address 172.25.87.180
 netmask 255.255.255.0
auto eth1
iface eth1 inet static
 address 10.100.100.1
 netmask 255.255.255.0

On haproxy2 (our failover load-balancer):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
 address 172.25.87.191
 netmask 255.255.255.0
 gateway 172.25.87.1
 dns-nameservers 8.8.8.8 8.8.4.4
auto eth0:1
iface eth0:1 inet static
 address 172.25.87.180
 netmask 255.255.255.0
auto eth1
iface eth1 inet static
 address 10.100.100.2
 netmask 255.255.255.0

As you can see above, we’ve configured a virtual IP address of which both machines are able to use, to ensure that both machines can start (as normally two machines in the same network cannot have the same IP address) we need to run the following command (on both haproxy1 and haproxy2):-

echo "net.ipv4.ip_nonlocal_bind=1" >> /etc/sysctl.conf

Then confirm that the changes have been made by running (sysctl -p) (it should return ‘net.ipv4.ip_nonlocal_bind = 1‘)

Now you should be able to restart the networking service on both our HAProxy servers.

service networking restart

We now need to create a few config files, these files are for the configuration of HeartBeat, these files are the same on both the haproxy servers (haproxy1 and haproxy2) servers!

First file to create should be located in: /etc/ha.d/ha.cf

watchdog            /dev/watchdog
logfile             /var/log/ha-log
debugfile           /var/log/ha-debug
deadtime            5
warntime            10
initdead            15
bcast               eth1
auto_failback       on
node                haproxy1
node                haproxy2

Second file, to be located: /etc/ha.d/authkeys

auth 3
1 crc
2 sha1 yourpasswordhere
3 md5 yourpasswordhere

Now, change the file permissions to 600 like so:-

chmod 600 /etc/ha.d/authkeys

Lastly, the final Heartbeat configuration file which is to be located in: /etc/ha.d/haresources

haproxy1 \
       IPaddr::172.25.87.180/24/eth0

Now we need to configure HAProxy, HAProxy shares the traffic  web server nodes. In the below configuration, HAProxy will ’roundrobin’ the web server requests to all active web server nodes.

The configuration on both servers, identicial again! – So ensure that both servers have the following content appended to the end of /etc/haproxy/haproxy.cfg

listen     web-cluster         172.25.87.180:80
                 mode http
                 stats enable
                 stats auth admin:password # Change this to your own username and password!
                 balance roundrobin
                 option httpclose
                 option forwardfor
                 cookie JSESSIONID prefix
                 server web1 172.25.87.192:80 cookie A check
                 server web2 172.25.87.193:80 cookie B check
                 server web3 172.25.87.194:80 cookie C check

The very last step, before starting the HAProxy daemon is to enable the daemon, again, this step needs to be carried out on both servers!

nano /etc/default/haproxy

and change:

ENABLED=0

to

ENABLED=1

Fantastic, HAProxy should now start without any problems, lets try starting it (on both servers) like so:-

/etc/init.d/haproxy start

Installing the web servers

For this simple test, I’ve very quickly installed nginx on each of the web servers, you can do so by running the following command:

apt-get install nginx

Then, to test the load-balancing is working correctly later on, I’ve edited the default nginx ‘welcome’ page found in /usr/share/nginx/www/index.html and then simply added the name of the server to display on that page, later on when testing our new setup you can then easily see what server is serving the content!

The content of my index.html file looks as follows:-

<html>
<head>
<title>Welcome to nginx!</title>
</head>
<body bgcolor="white" text="black">
<center><h1>Welcome to nginx! (web1)</h1></center>
</body>
</html>

Thats great, thats all we need to do on the web servers!

Testing it out…

Now, as long as your web servers are online, you should now be able to access your webserver cluster from your web browser at: http://172.25.87.180/

Now, refresh the pages a few times, the page should then change to ‘Welcome to nginx (web2)’ and then ‘Welcome to nginx (web3)’ and then will go back to ‘Welcome to nginx (web1)’ etc. – This is known as ’roundrobin’ load-balancing.

As we’ve also enabled the HAProxy stats you can also see your cluster stats (which web servers are online etc) by typing:- http://172.25.87.180/haproxy?stats, once you’ve entered the correct username and password combination you’ll be faced with a nice statistics page like so:-

Credit where credit is due, most of the information for this I found on this great webpage:- http://blog.romerojunior.com/linux/linux-building-basic-high-availability-infrastructure-for-web-servers/

Introduction

In this guide we will create and deploy a scalable WordPress instance consisting of a MySQL database server, a GlusterFS distributed filesystem, Nginx web servers and an Nginx load balancer. By using user-data and droplet meta-data we will automate the deployment of our site. Finally we will provide a Ruby script which will automate this entire process and ease the creation of scalable WordPress sites. Through this tutorial you will learn about the power and flexibility of user-data and droplet meta-data in deploying services on DigitalOcean.

Step One – Planning our Deployment

The deployment we create in this tutorial will consist of a single MySQL database server, multiple GlusterFS servers in a cluster, multiple Nginx web servers and a single Nginx load balancer.

Before we begin we should know:

• What size droplet we will use for our MySQL server
• How many GlusterFS nodes we will create
• What size our GlusterFS nodes will be
• How many web server nodes we will need
• What size droplets we will use for our web servers
• What size droplet we will use for our load balancer
• The domain name we will use for our new site

We can add additional nodes or scale up the nodes we created if we need to later. Once we have decided on these details we can begin deploying our site.

Lire la suite…