A blog about server hosting

Over the coming weeks, I’ll be covering a number of technical aspects required to achieve PCI compliance. For information on what PCI compliance is and when you’ll require it, see this detailed wikipedia entry. For now, let’s move onto our first topic:

Disable SSLv2 and Weak Ciphers

Section 4.1 of the PCI-DSS states that you are required to “Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”

Put simply; you will need to ensure that any web servers running SSL in your PCI environment, are configured to use strict set of security rules including disallowing Secure Socket Layer (SSL) version 2 as well as all weak cryptography.

Even if you’re not interested in PCI compliance, the techniques documented within are still extremely important as they disable a number of vulnerable protocols and encryption cyphers.

How to test for SSL V2:

In order to perform the following tests, you will need to have OpenSSL installed. Once installed, run the following command:

openssl s_client -ssl2 -connect SERVER:44

If SSL V2 is already disabled, you should see the following:

2295:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

How to disable SSLv2 in Apache 2:

You will need to replace the SSLProtocol directive in either httpd.conf, apache2.conf or ssl.conf dependant on your distribution.

The following configuration will selectively enable only SSLv3 and TLSv1

SSLProtocol -ALL +SSLv3 +TLSv1

Restart the web service and run the check again to ensure connections are no longer accepted.

How to disable SSL V2 in IIS:

You will need to apply the follow keys into the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
“Enabled”=dword:00000000

Restart the server and run the check again to ensure connections are no longer accepted.

How to test for weak cyphers:

In order to perform the following tests, you will need to have OpenSSL installed. Once installed, run the following command. Alternatively, an open source utility known as SSLScan is available to do the checks for you.

# openssl s_client -connect SERVER:443 -cipher LOW:EXP

If weak cyphers are already disabled, you should see the following:

2362:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

How to disable weak cyphers in Apache 2:

You will need to replace the SSLCipherSuite directive in either httpd.conf, apache2.conf or ssl.conf dependant on your distribution.

The following will disable all cyphers except for those classed as high security, and therefore PCI compliant:

SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH

Restart the web service and run the check again to ensure connections are no longer accepted.

How to disable weak cyphers in IIS:

You will need to apply the follow keys into the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC464/128]
“Enabled”=dword:0000000

Restart the server and run the check again to ensure connections are no longer accepted.

At this point, scans performed against the SSL boxes in your PCI environment should pass all tests covering section 4.2 of the compliance requirements, as well as a number of non-PCI security scans covering SSL vulnerabilities.

Rob Greenwood, Technical Lead

Welcome to the third installment of “the five dangers of virtual servers”.  In my previous post, I talked about the danger of interference from other customers’ VMs on badly-configured platforms. So let’s move on to the next potential pitfall:

Danger Three: The danger of not having a Service Level Agreement (SLA)

It’s one thing to say that a service is reliable, but quite another to put a money-back guarantee or Service Level Agreement (SLA) on it.  Obviously what you want is a working service, not a money-back guarantee, but it certainly puts an emphasis on the provider having a standard to work towards.

Many providers say SLAs are a waste of time, and marketing hype. If they truly believed this, surely they’d offer an SLA anyway as they have nothing to lose?

Some virtual server products come without an SLA; some even charge you extra for an SLA. In short, any decent high-availability virtual server offering should have an SLA on both the network connectivity, but more importantly the availability of the “virtual hardware” of your virtual server.

A decent SLA should provide a realistic and achievable service level (100% SLAs are usually vanity only, or exclude so much that they’re almost pointless) and a penalty for the host if the SLA is not achieved. It should also be clear what the SLA covers. For example, a lot of network/connectivity SLAs cover only the provider’s own network in their data centre, and not their upstream providers. That means your server may be inaccessible but if it was due to their provider and not their own internal network, you’re not covered.

Our own UltraVM™ Cloud Servers come with a 99.95% ‘hardware’ uptime and network guarantee, although in reality 100% uptime is both our goal and what we achieve.

Daniel Keighron-Foster, Managing Director

In my previous post, we were talking about the danger of hardware failure in virtual machines.  Let’s move on to the next…

Danger Two:  The danger of interference from other customers’ virtual servers.

There are several ways in which one virtual server can interfere with another, when they’re running on the same node.  However, when security is properly implemented, this risk is completely mitigated, and the solution is just as secure as a dedicated server.

A responsible host will have thought out these issues and put safeguards in place to ensure that one virtual server cannot impact upon another.  Here are some questions to ask your potential virtual server provider:

• Will I have my own VLAN or are all virtual servers on the same network segment?
  This is important, as virtual servers on the same VLAN are on the same broadcast domain.  This means if someone enters your IP address in their network configuration incorrectly, they could take your virtual server offline.  It also means you’d receive their broadcast traffic. Finally, it means that there is complete lack of firewalling between your virtual server and others, unless a software firewall is put in-place (see the next point for more on this).
• Will I have the protection of a hardware firewall?
  With a separate VLAN, it’s possible to protect a virtual server in the same way as you would a dedicated server.  This means that not only traffic from the outside world, but also to other neighbouring customers, is allowed through only if it meets the firewall rules you’ve set.
• Are the kernels shared with the host operating system?
  Slightly more complex this one; basically some virtualisation technologies share the host node’s base operating system kernel with the virtual servers, for various reasons, usually so the provider can put more virtual servers on a node.  However this means that any kernel vulnerability could mean that a compromised virtual server can effectively take down the whole of the host node, which basically means all the virtual servers running on the node will be taken down too.

It kinda goes without saying that our UltraVM™ cloud servers pass all these tests (otherwise why would we have written this blog!).  Take a look at the feature-set, and visit back for danger 3, 4 and 5 later this week.

Daniel Keighron-Foster, Managing Director

In this short series of blog posts, we’ll be looking at five important considerations you need to make when choosing a virtual server.  It may seem that all virtual servers, or cloud servers, are similar, but like everything technical, the devil is in the detail.

Danger 1: The danger of hardware failure

One of the benefits of virtualisation should be an improvement of service availability, so it’s important that the topology of the cluster is well thought out, such that a failure of a major central component such as a network switch, or even just the physical node (server) that your virtual server is running on, doesn’t cause your virtual server to go offline.

Use Centralied SAN Storage

The best solution uses centralised SAN storage, so that if the physical node (server) you’re running on fails, your virtual server will automatically re-start on a spare node.

An added benefit of this is that your hosting service can take nodes out of service for maintenance without affecting your virtual server. That means you’re truly available for the maximum amount of time possible.

Look for an option of fast disks (i.e. 15,000rpm SAS disks) to keep the I/O throughput of your virtual server tip-top.

Use Hardware Resilience

Nodes should be dual-uplinked through two switches, to both the frontend (i.e. the internet) and also the backend (i.e. to the storage) such that the failure of a network switch or uplink cable (or just someone accidentally un-plugging it) does not stop your virtual server from running, or being accessible.

The centralised SAN storage should be built with resilient/failover power supplies and controllers, such that the failure of any component within the SAN does not take offline any virtual server.

A decent service provider will offer the option of offsite backup space to be mounted to your virtual server to give you a self-standing off-site copy of your important data.

Daniel Keighron-Foster, Managing Director

As with any web application, a great level of thought and planning goes into the optimization of the webapp to ensure fast response times. However, what often gets overlooked is the configuration of the LAMP stack itself. There is plenty of benefit to be gained from optimizing the configuration of Apache, PHP and MySQL.

Although all the different components provide ‘optimised’ configurations, they’re generalised and not written for an applications specific requirements. The aim of the ‘Optimising the LAMP Stack’ series is not to provide an example configuration, but to explain the more important configuration options and what impact those settings have on your web applications – giving a greater in site into how to configure it correctly.

Your MySQL configuration can generally be found in /etc/my.cnf – heres a list of what I see as the most important variables.

1. query_cache_size:
   • MySQL 4 onwards provides query caching, whereby if a database has to continually run the same queries on the same dataset it will cache the results. Although this level of caching should generally be taken care of by the application, this is a good alternative and saves the server repeating tasks.
2. thread_cache:
   • Thread creation/destruction can be expensive, and this happens on every new connection. Keep this in line with the amount of connections you expect your  server to receive. If you start to see a spike in threads created, increase it. The goal is to not have threads created during normal operation.
3. key_buffer_size:
   • The key buffer is used with indexes. The larger you set the buffer, the quicker queries will complete and return a result. I recommend setting this somewhere between a quarter, but no more than half of the systems totally memory. In an ideal situation, this will be sufficient to contain all your table indexes.
4. table_cache:
   • Each time MySQL opens a table, it’s placed in the cache. The more tables you open, the higher cache you’ll require. Also bare in mind that MySQL is multi-threaded, therefore you could end up opening the same table multiple times in different processes and need to account for this.

The above list is the most important options for optimising a standard MySQL servers workload. Although there are plenty more, a lot can degrade performance when used incorrectly or when an applications requirements differ.

Should you wish to further optimize your configuration, I would suggest looking through the sample ‘optimized’ configuration provided with the MySQL server (Generally located in /usr/share/mysql). MySQLTuner is also pretty useful for configuration reccommendations when your database has been up and running for a few days.

Rob Greenwood, Technical Lead

Quite a specific case this one, but something I’ve seen quite often when people are using Remote Desktop (RDP) to work remotely.

Basically, with RDP, you can map the printers on your local workstation to the server you’re connecting to, so you can print from applications from the server, and hey presto, it comes out of the printer sat next to you.

This relies of course on you having installed the driver for your local printer, on the server to which you’re RDP’ing.

What I’ve noticed on several occasions though, is if you have a printer which has a non-local port, for example a DOT4 port (used mainly for printer/scanner/fax/teasmaids), or an IP port (i.e. printers with a HP JetDirect card), even if you have the correct driver installed on the server, when you connect via RDP, your printers are still not mapped.

“Why?”, I hear you ask.  After a bit of digging, I found this MS knowledgebase article.  Essentially, any ports not starting with COM LPT or USB are not redirected as default.

Why MS decided, in their infinite wisdom, to do this, I’m not sure.  However, there’s quite a simple registry fix for this one, shown in the article.

Why have I written a blog post about this fascinating topic?  I’ve noticed that this has foiled RDP users on many occasions as it’s quite a common set of circumstances; increasingly so with the prevalence of using RDP to access a centralised server for out-of-office working.

Daniel Foster,
Technical Director

Since the release of Windows XP and, later, its companion Windows Server 2003, Microsoft have packaged a basic firewall with its operating systems. Formerly known as “Internet Connection Firewall”, this has become a popular addition to the bundled packages, with many users finding it effective for basic firewalling of their internet connections.

But is there a downside to using it? After all, it is a free firewall, simplified and integrated into the operating system… what could be better?

Well in the context of a business-oriented server, almost anything, actually.

The benefits of Windows Firewall to home users are fairly obvious, and can effectively protect a home PC from inbound attacks from the vast number of hackers on the internet. The problems for servers arise due to their usually “remote” nature.. ie. locked up in a server room in the basement, or even 100 miles away in a world-class datacentre such as our own(!)

The firewall runs as a service within Windows itself and, although it will likely spend most of its time disabled, it can be activated by the occasional Windows Update, and can then lock you out of the server altogether, involving costly technician intervention. The default Windows Firewall configuration may well allow your webserver to run, but can block RDP for remote desktop administration, or even ICMP Ping, often used for checking a system’s “alive status”. We regularly take calls from customers whose Windows Firewall has been accidentally enabled.

When you use the firewall’s control panel, you have the option to turn it “On”, or “Off”, but this is not a secure method of deactivation. We recommend disabling the Windows Firewall service entirely from within Control Panel > Administrative Tools > Services.

Even a third-party firewall may give you problems if it is run on the server it is intended to protect. The best practice option is to either opt for a hardware-based firewall or even a small computer set up as an internet security device to go between your critical server and the internet.

Here at Melbourne, we offer an Enterprise-Class shared firewall solution called “Ultrafire” which uses a simple but powerful web-based interface for setting up rules, network aliases and IP services. More details can be found here: http://www.melbourne.co.uk/ultrafire.htm

In conclusion then, it’s best to view Windows Firewall as a handy utility for home use, but to completely disable it if you are running a server.

(Terminal Service Client 6.0)

(Applies to Windows XP only)

For those of you who use Remote Desktop to manage your servers, and, let’s face it that’s most of us who use Windows servers, the updated version of the RDP client is causing some irritation among IT professionals by making the process of logging onto the servers more convoluted.

Basically, Microsoft have, in their wisdom, decided to force you to enter your server’s credentials BEFORE connecting to terminal services. It quite often then inserts a useless string such as “server_name\login” where just the login will suffice, forcing you to correct it.

There is, however, a cure for all this timewasting: remove version 6.0 entirely and go back to using the perfectly adequate version 5.1.

To do this, uninstall RDC 6.0 from Control Panel | Add / Remove Programs.  Check the box “Show Updates”, locate “Update for Windows XP (KB925876)” and uninstall.