In recent weeks, it has come to light that there is an ongoing, highly distributed effort to attack
Wordpress websites with poorly secured administrator passwords.

This attack is highly organised, using over 90,000 IP addresses in an attempt to guess the
administrator password for WordPress sites.

We are aware of these efforts and are deploying a series of counter-measures to protect our
customers against this effort.

We do, however, encourage our customers to take steps to ensure their WordPress sites aren’t
compromised due to weak or insecure passwords.

The following are several ways customers can further protect their WordPress sites:

WordPress BulletProof Security Plugin

The WordPress BulletProof Security Plugin is a free, multi-purpose security tool for WordPress
intended to protect your WordPress site against a variety of security attacks.

This tool is installed like any other WordPress plugin and provides a number of tools customers can use to improve the security of their site.

If you are interested, you can find more details about the plugin at http://wordpress.org/extend/plugins/bulletproof-security/

WordPress Better WP Security Plugin

Another alternative plugin for WordPress, “Better wordpress security” provides extra features, and security measures which are widely used, and provides it in a single plugin which is easy to manage, and provides many methods for protection.

If you are interested, you can find more details about the plugin at http://wordpress.org/extend/plugins/better-wp-security/

Deny Access to your wp-login.php Page based on Country Code

Another method, which can assist, is by utilizing a rewrite which would deny access to your websites back-end unless the user is identified as being in Australia or New Zealand.

For anyone who runs a blog which is centralized around being logged into by Australian and New
Zealand users, this method would be a good start for security, as the attacks are generally originating from foreign networks.To deny access to IP addresses other than those from Australia and New Zealand add the following block of code in the /home/username/.htaccess file:

<FilesMatch “^wp-login.php$”>

<IfModule mod_geoip.c>

SetEnvIf GEOIP_COUNTRY_CODE AU AllowCountry

SetEnvIf GEOIP_COUNTRY_CODE NZ AllowCountry

Deny from all

Allow from env=AllowCountry

</IfModule>

</FilesMatch>

 

Note: replace “username” above with your cPanel username.

Password Protect Your wp-login.php Page

Another method, similar to above, is instead of blocking access based on a country, is assigning a password to your login pages.

There are two steps in accomplishing this. First you need to define a password in the .wpadmin file, and then you activate the security in the .htaccess file.

Step 1: Create the Password File

Create a file named .wpadmin and place it in your home directory, where visitors can’t access it.
(Please note there is a period preceding the wpadmin in that file name.) The following example is for cPanel. Plesk would require placing the file in/var/www/vhosts or /var/www/vhosts/domain.

EXAMPLE: /home/username/.wpadmin
(where “username” is the cPanel username for the account.)

Put the username and encrypted password inside the .wpadmin file, using the
formatusername:encryptedpassword
EXAMPLE: john:n5MfEoHOIQkKg

(where “john” is a username of your choice, and the password shown is encrypted.)
Generate Password File & Uploading Via File Manager or FTP
One way to do this is to generate the file using the website linked below, and then upload it to your
site via FTP or File Manager. In the directions below, we will use File Manager, but you could use FTP
instead, for those of you familiar with FTP.

1. Visit: http://www.htaccesstools.com/htpasswd-generator/
2. Use the form to create the username and password.
3. Login to cPanel in another window or tab.
4. Click on File Manager.
5. Select Home Directory.
6. Check Show Hidden Files (dotfiles) if not already checked.
7. Click on the Go button.8. Look for a .wpadmin file.
o If one exists, right click on it and select Code Edit to open the editor. Click on
the Edit button to edit the file.
o If one does not exist, click on New File at the top of the page, and specify the
name as .wpadmin (with the dot at the front) and click on the Create New
File button.
9. Paste the code provided from the website in step 2.
10. Click on the Save Changes button when complete.
11. You can Close the file when finished.

Step 2: Update the .htaccess File
All domains under the home directory will share the common .wpadmin file. (The command listed in
Option B above creates the /home/username/.wpadmin file due to the -c.)
The last step is to place the following code in the /home/username/.htaccess file:

ErrorDocument 401 “Unauthorized Access”

ErrorDocument 403 “Forbidden”

<FilesMatch “wp-login.php”>

AuthName “Authorised Users Only”

AuthType Basic

AuthUserFile /home/username/.wpadmin

require valid-user

</FilesMatch>

 

Note: in the above examples, you would of course replace “username” above with your
cPanel username.

SSD RAID 10 IOPS Testing - H700 Perc RAID Card Testing R710

Recently we’ve been playing with H700 RAID cards with SSD’s. We have had some issues which will be outlined in future follow up posts with SSD’s & H700 Compatibilities.

6 x 256GB Crucial M4 Firmware 0309 all confirmed in a RAID 10 array.
Testing tool : Fio 1.38 64bit

Fio is quite easy to configure and setup in all major linux distribution. We are testing it on Debian which is quite easy to install J From CLI (command line interface) just run the following commands:

This will update the Package Index. The APT package index is essentially a database of available packages from the repositories defined in the /etc/apt/sources.list file.

To update the local package index with the latest changes made in repositories,
root@server:/# Apt-get update

This command will then install FIO from the remote repositories & any dependencies
root@server:/# Apt-get install fio

We then want to create the actual configuration file which will have all the variables for this test , because we are utilising SSD’s it’s a good idea to setup the configuration file with the following settings

The easiest way to create the configuration file is like this:
root@server:/# nano random.fio

Then you want to paste the following in:

[random]
rw=randread
size=1g
directory=/iops
iodepth=403
direct=1
blocksize=4k
numjobs=16
nrfiles=1
group_reporting
ioengine=sync
loops=1

The second last step is to create a folder where all the working/testing will take place in , in our case we created /iops in the following way:
root@server:/# mkdir /iops

The final step is the actual test J just run the application with the configuration file name trailing
root@server:/# fio random.fio

And your output should be something like this. I have highlights the main performance outputs for you in red to compare your results! So we got roughly 19,000IOPS @ 4K Reads J Quite fast if you ask me

random: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=403
…
random: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=403
Starting 8 processes
random: Laying out IO file(s) (1 file(s) / 1024MB)
random: Laying out IO file(s) (1 file(s) / 1024MB)
random: Laying out IO file(s) (1 file(s) / 1024MB)
random: Laying out IO file(s) (1 file(s) / 1024MB)
Jobs: 2 (f=2): [_r__r___] [97.3% done] [34022K/0K /s] [8306/0 iops] [eta 00m:03s
Jobs: 2 (f=2): [_r__r___] [98.2% done] [25875K/0K /s] [6317/0 iops] [eta 00m:02s
Jobs: 2 (f=2): [_r__r___] [100.0% done] [25381K/0K /s] [6196/0 iops] [eta 00m:00
random: (groupid=0, jobs=8): err= 0: pid=3884
read : io=8192MB, bw=75793KB/s, iops=18948, runt=110678msec
clat (usec): min=82, max=39244, avg=282.17, stdev=70.87
bw (KB/s) : min= 336, max=20720, per=18.60%, avg=14099.28, stdev=930.13
cpu : usr=2.51%, sys=32.11%, ctx=2077702, majf=0, minf=588
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=2097152/0, short=0/0
lat (usec): 100=0.02%, 250=7.38%, 500=81.68%, 750=10.65%, 1000=0.14%
lat (msec): 2=0.10%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
Run status group 0 (all jobs):
READ: io=8192MB, aggrb=75792KB/s, minb=77611KB/s, maxb=77611KB/s, mint=110678 msec, maxt=110678msec
Disk stats (read/write):
dm-0: ios=2097110/1826990, merge=0/0, ticks=606753/2981152, in_queue=3673756, util=84.49%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=-nan%

CVE-2010-4344: A memory corruption vulnerability exists in Exim versions 4.69 and older
CVE-2010-4345: A privilege escalation vulnerability exists in Exim

If your server is running Exim 4.69-25 or older with maildir, or Exim 4.63-4 or older with mbox (deprecated), we highly recommend you upgrade asap.

Read more »