There are many ways in which you can protect your VPS – from strict password policies, through to aggressive spam filtering, basic firewall configurations and antivirus. However, no matter how fancy and elaborate your security precautions are, there will always be someone ready to launch dictionary attacks and probe for vulnerable scripts on your poor server.
Even though we preconfigure strict firewall policies on our fully managed Cloud VPS, there are some services – like the web server itself – that have to remain wide open to the world. Without those gates, there would be no mail flow or web browsing.
Consequently your Cloud VPS can be kept quite busy just fighting off failed FTP/S password probes along with the load of “404 not found” reports in your apache error logs from bots searching for common software exploits. Not to mention the wealth of failed IMAP, SMTP and POP3 connections from spammers and identity thieves trying to compromise your mailbox.
If you weren’t really careful about keeping your website software 100% up to date you have, probably, at some point, received a support ticket from our abuse department notifying you that your VPS has unfortunately become a spam crib due to malware injections or a simple password breach.
A few months ago Parallels (now Odin) introduced new security enhancements to Plesk 12. Such features as WordPress Toolkit, mobile manager application, antispam and antivirus capabilities; the platform is a great choice for any web administrator. One little gem, in terms of security, was the addition of Fail2Ban. Let’s take a look at how it works and how it can save your server from compromise.
Every internet user is familiar with the lock icon which comes with almost every website these days – this means that the website is secured by an SSL certificate which will guarantee that sensitive information sent across the Internet is encrypted.
We all know how vital security is in the online world, but how does the SSL manage to encrypt all of this information so that it won’t get in the wrong hands?
Well, the answer is the hashing algorithm – an important feature of the public-key encryption which is used to encrypt the communication between a server and a browser. It’s really important to keep up with it and use the latest version to make sure your website is protected. Here at Layershift, this is our main purpose: to ensure that your website and business are protected and up to date – so we followed the evolution of the hashing algorithm and pro-actively updated the certificates issued via ourselves to use the latest version.
Thanks to SNI technology you can now host multiple SSL certificates on a single IP address. But what is SNI? How does it work its magic? What are the disadvantages? Let’s take a closer look and decide together if you should use SNI for your production websites.
Two announcements that shook the Internet
Could the Internet be reaching its last days? Surely it could never happen? Ok, perhaps slightly melodramatic, but a few recent incidents clearly demonstrated the impact IPv4 address shortages are starting to have on everyday Internet operations.
One of the largest outages in Internet history recently shook the online community. Major Internet Services Providers like BT and Virgin in the UK and AT&T, Time Warner and Verizon in the US went down. It appears that these outages were all caused by growth of the BGP routing table – a knock-on impact of the increasing scarcity of available IPv4 addresses.
Our friends over at Microsoft Azure also had their own problems when they ran out of spare IPv4 addresses earlier this year.
Add to that the fact that Google have started giving a ranking boost to secure https/SSL sites, and intends to accelerate the prominence of this factor in future. So Google are at it again – shaping the lives of SEO experts and their clients the world over. This time there’s a catch due to the implications this has for excessive IPv4 address consumption!
As explained last time the media got all excited by a security vulnerability; proactive security patching is all in a days work here at Layershift. So it shouldn’t come as any great surprise that we were once again all over this as soon as the appropriate patches were released by the relevant upstreams.
Two separate patches were issued in respect of this vulnerability, and they even have two separate CVE references for the pleasure: CVE-2014-6271 and CVE-2014-7169.
This widely reported vulnerability was first publicised late on Wednesday afternoon, 24th September 2014, with patches provided and installed later that day / overnight. However, that first patch was found to be incomplete – alas CVE-2014-7169 was born!
Early on Friday morning, 26th September 2014, a new patch was issued, and once again our engineers have worked tirelessly to get it deployed across all of our platforms in short order.
Shellshock patch status
- Managed Cloud VPS – PATCHED
- Jelastic PaaS – PATCHED
- Managed dedicated – PATCHED
- Shared hosting – PATCHED
- Internal infrastructure – PATCHED
You might think the Heartbleed bug is already history, but in recent days some of our customers have requested a public announcement due to the unprecedented media profile of this particular security vulnerability.
Whilst the media are (rightly, to an extent) making a lot of noise about this bug and its significance to the Internet population at large, the truth is we as sysadmins haven’t treated this security threat any differently to any other.
There are lots of important security vulnerabilities uncovered which have the potential to give an attacker full access to your server (arguably more serious than this case) – so we patch and workaround security vulnerabilities on an almost daily basis as part of our fully managed service. There is simply no reason or benefit to announce each and every one of these – our customers use our service to stay focused on their business rather than technical details like these.
Our expert technical team are always there in the background, performing server tune-ups to ensure that the configuration is optimal and secure at all times, so that you don’t have to.
If you somehow managed to miss the media coverage and the myriad of announcements and emails in your inbox about the Heartbleed bug, you can find more details regarding this vulnerability alert issued by the OpenSSL group on April 7, 2014: http://heartbleed.com/