In total, over 900 runners took part on the day to raise money and awareness for charities such as ‘Street Games’ a new National Charity delivering ‘Sport in Deprived Communities’, The North West Kidney Patient Association, The New Children’s Hospital Appeal, UNICEF and Brain Tumour UK.

Although it showed just how unfit we all are, we had a very enjoyable day and look forward to more events to raise money for charity soon.

Sim, Dan and Chris completing the Urbanathlon

Chris Marsh, Business Development Manager

Anyway, we’ve now made it easier for customers to make sure they get their referral reward every time they send someone our way.

Basically, if you’re kind enough to link to us from your website, you can now add a suffix containing your client ID, which means that anyone who you referred placing an order will notify us, allowing us to attribute the sale back to you.

After that you get your referral gift, which is a choice of:

• A case of 6 bottles of quality wine, sourced from family-owned producers, from local wine merchant Reserve Wines.
• An ipod shuffle in your choice of colours.  Don’t worry we won’t have it engraved with any terse ‘thank you’ message!
• A £50 (including VAT) credit to your account.
• A £50 donation to the charity of your choice.

(we’ll email you to ask which you’d prefer).

Find out more details of our referral program.

The event focused on the impact which Twitter and Facebook (amongst others) has had on society and business. John Greenway from Manchester Airport spoke about how Twitter helped keep in touch with the public during the ash cloud days and heavy snowfall during December and January. There was also talks from Martine Alexander on how Twitter has helped promote her Styling business, Rick Guttridge on how it is used with PR, Chi-chi Ekweozor on promoting and using social media on her charitable project 7 wonders in 7 days, and finally Dom Hodgson on the pros and cons you should be aware of when tweeting to the masses…

Nigel and the rest of the team from Studio Skylab put in great effort to make sure the event was promoted and went without any hiccups with video links to similar set ups in Portugal and California (we even made ABC News that evening which you can view on our Facebook page ).

Chris Marsh,  Business Development Manager

Due to a very competitive licensing deal we’ve just signed with the software vendor, R1Soft, we can now offer managed backup for just £5 per month per server, or free if you’re a managed server customer.  Data stored on the backup server is charged at the low cost of £0.50 per GB per month.

Existing customers will be contacted by their account managers to arrange to have the rental charges reduced from their next invoices.

To find out more information about the service please see our UltraVault™ Managed Backup section or speak to your account manager today.   UltraVault™ is available to customers with virtual, dedicated or colocated servers, and customers with rackspace.

Danger 4: The danger of over-contention

There’s a potential for over-selling with virtual servers, as the provider may not tell you how many virtual machines they intend running on one physical node, whether memory and CPU time are contended, or how fast the physical node is uplinked to the network.

The whole point is to put limitations in-place to stop one virtual server from hogging the resources at a performance cost to neighbouring virtual servers.

A responsible provider uses a virtualisation technology that does not allow memory or disk space to be contended, and has fixed parameters in place to ensure CPU and network resources are fairly shared out.  This includes setting an upper limit to the number of virtual machines that can run on a physical node, and also ensuring the physical nodes are uplinked to the ‘net at a suitable speed such that every server gets a decent sized connection.  For example a gigabit connection shared between 30 virtual machines gives an average throughput capacity of approximately 30Mbps to each virtual machine, whereas a 10Mbps connection shared by the same 30 virtual machines would give a measly 0.3Mbps average to each VM.

5. The danger of not having tools to help yourself in the case of emergency.

You would generally want KVM over IP and remote reboot facilities on a dedicated server, to give you “sat in front of the machine” access in the case of a major OS failure, or to correct network settings when the machine is otherwise inaccessible.

The same should apply to a virtual server.  This technology can be a life-saver when you need to work on a virtual server at 2am without waiting for your provider to respond to help you out.  It gives you complete self-sufficiency.

Conclusion

There’s plenty of scope for virtual server providers to cut corners.  That said, if you research your provider well, using the above questions as part of your decision-making process, you’re likely to find a service that’s a high-availability and high-performance alternative to dedicated servers.

To sum up make sure that any virtual server provider can meet the following criteria and you’ve done your utmost to mitigate the dangers we’ve described:

1. Uses SAN Storage
2. SAN and host servers have redundant critical components
3. Nodes dual-uplinked through two switches (front-end and backend)
4. You have your own VLAN
5. Provides a hardware firewall
6. No kernel sharing between host node and virtual machines
7. Has a reasonable SLA
8. Console access with reboot facility
9. Has support that is responsive and knowledgeable
10. Knows how to look after customers

As you’ll have no doubt guessed, Melbourne’s UltraVM™ Cloud Servers come up trumps on all of these points.

Daniel Keighron-Foster, Managing Director

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

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

We’re obviously a good luck charm, as four of our clients are shortlisted for big chip awards!

• 11 Out Of 10 are up for best e-business project;
• KMP Digitata are nominated twice for best e-business project;
• Cahoona are up for best not-for-profit project, best use of visual design, best newcomer and the tasty website award;
• PushON are up for best use of search and best digital marketing campaign.

We obviously wish all our clients the best of luck (along with all the entrants of course)!

Chris Marsh
Business Development Manager

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

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