UKC02 – Upgrade to Plesk Obsidian

Security, Performance and Feature Enhancements

We are pleased to announce that all hosting accounts that reside on UKC02 (Plesk 12) will be upgraded to the very latest Plesk Obsidian panel between 1800 Thursday 10th and 0400 Friday 11th December. There will be no disruption to your service.

Plesk Obsidian brings a whole suite of new features as well as the highest level of security and performance. In addition to the panel and base operating system upgrade your server hardware will be upgraded to the latest generation equipment thus delivering the highest performance for your web hosting services.

Access to the Plesk panel and the recommended name servers remain unchanged:

Panel access: https://ukc02.uk:8443
Nameserver 1: ns.ukc02.uk
Nameserver 2: ns2.ukc02.uk

The web server IP address will change from 195.224.99.180 to 195.224.99.182. If you use your own name servers (i.e. not the recommended name servers ns.ukc02.uk and ns2.ukc02.uk) then please ensure you change your DNS A records to use the new IP address within 7 days.

In the event that you have a problem with your web site service or you feel the migration of some of your data may need further attention please do not hesitate to contact the Helpdesk, advise of the specific problem you are experiencing and we will resync your data without delay.

We hope you enjoy the enhanced performance and security of your new UKC Plesk Obsidian Server.

UKC02 – Service Outage 16/12/2019

UKC02 – Service Outage Updates

Latest update 20:30 20th December

The Plesk Objects have been imported successfully, we are now running a number of tests on the Plesk services.

We will be bringing sites back online over the next 48 hours, this is a temporary solution, we will upgrade all accounts to Plesk Onyx after the festive period.

Plesk Onyx offers some of the latest features available with Plesk, such as PHP 7.3, LetsEncrypt, DNSSEC and webmail SSL support.

All domains using the following nameservers will automatically resolve at the new IP address once DNS propagation has completed:

ns.ukc02.uk
ns2.ukc02.uk

If you are using a third party DNS provider and are pointing A records at UKC02, please update all instances of the old IP address 5.77.35.132 to the new IP address 195.224.99.180 inside your DNS control panel.

Thank you very much for your patience throughout this difficult time.

How to fix: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80

sshApache Error: (98) Address already in use

Occasionally your VPS or dedicated server will just not play ball.

Whenever Apache gives up the ghost it usually a case of restarting the service and within seconds your sites are back online, as if nothing happened. Great!

# service httpd restart

Most of the time, this resolves the issue. But, on occasion, apache simply doesn’t want to play. The most common issue we hear about is the Address already in use issue, which looks something like this

# service httpd restart
Stopping httpd:                                            [FAILED]
Starting httpd: (98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
                                                           [FAILED]

How to resolve this apache issue

Unless apache is restarting at the time you are trying to restart manually then what we have here is a locked process. Thankfully the resolution is quite simple. We just need to find the locked process, kill it then restart apache as usual.

Let’s find the locked process id

# netstat -ltnp | grep ':80'

This will return something like this

tcp  0  0 :::80  :::* LISTEN      3826/sudo

Now we have identified the PID as 3826, we just need to kill it

# kill -9 3826

With a little luck, a simple apache start will now get everything working

# service httpd start

Starting httpd: [  OK  ]

If the problem persists then review the apache error log to locate the issue:

# tail -500 /var/log/httpd/error_log

Protect against WordPress Pingback Vulnerability

How to Neutralise a Pingback DDOS Attack

sshThe WordPress Pingback Vulnerability is used to maliciously attack your WordPress site via the Pingback service.

If the attack is heavy enough then not only will your site be seriously slowed if not inaccessible) but your server will also be overloaded with requests thus risking your shared hosting account altogether.

This type of attack is usually instigated via a botnet of many hundreds (if not thousands) of different IP addresses so a simply blocking the IP address of the attacker is not practical.

If you are under attack right now then there are actions you can take to minimise (if not nullify) the effect of attack.

Disable the WordPress XMLRPC Service

We can do this by adding a “deny” to “xmlrpc.php” in your .htaccess file. This will disable the your WordPress site from participating with the pingback requests.

Add the following to the top of your .htaccess file:

<files xmlrpc.php>
order deny, allow
deny from all
</files>

The attack will now have less effect on your server load.

Once the attack is over, you may remove deny code if you need XMLRPC services active on your WordPress site. There’s a 95% chance you can leave it there with no noticeable effect at all.

Blocking the DDOS Attack using CSF

If you use CSF, you may still want to block the IP addresses of the attacking botnet. It’s quite easy to do.

Here is a bash one-liner that will do the job for you in real-time:

tail -f /var/www/vhosts/yourdomain.com/logs/access_log | grep "\"WordPress/" | grep -v "POST " | awk '{print $1}' | while read IP; do /usr/sbin/csf -td $IP 7d BlockPingback; done

There is some satisfaction in having the IPs permanently blocked. You can add the resulting IP block to your deny files on all servers and accounts.

It does make sense as all the attacking WordPress sites are clearly compromised and will no longer be a problem (for you at least) if permanently blocked from your server.

How to Upgrade IGB NIC Driver

Upgrade IGB Driver to Fix Packet Loss Problems

The early versions of igb NIC/LAN driver were buggy, if your version look like this:

# ethtool -i eth1
driver: igb
version: 5.0.5-k

Any version under v5.2.15 is buggy and a simple ping test to your server will show packet loss issues, usually around 20%.

To upgrade the driver, use the following steps.

1) cd /root
2) wget http://sourceforge.net/projects/e1000/files/igb%20stable/5.2.17/igb-5.2.17.tar.gz
3) tar -xvzf igb-5.2.17.tar.gz
4) cd igb-5.2.17/src/
5) make install
6) rmmod igb; modprobe igb
7) rmmod ixgbe; modprobe igb
8) vi /etc/sysconfig/modules/igb.modules

and set 

modprobe igb

9) Following is the output ::

=========================

root@server [~]# modinfo igb

filename: /lib/modules/2.6.32-504.12.2.el6.x86_64/kernel/drivers/net/igb/igb.ko
version: 5.2.17
license: GPL
description: Intel(R) Gigabit Ethernet Network Driver
author: Intel Corporation, 
srcversion: 420A0DE22C6377FB9C68995
alias: pci:v00008086d000010D6sv*sd*bc*sc*i*
=======\\=================
=======================
root@server [~]# lsmod | grep dca
dca 7101 1 igb
=======================

Let’s see the active version after the upgrade:

# ethtool -i eth1
driver: igb
version: 5.2.17
firmware-version: 1.52, 0x800007ae
bus-info: 0000:01:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

That resolves the issue. No reboot/restart is required.