<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=645174729237247&amp;ev=PageView&amp;noscript=1">
We are updating the structure and design of KernelCare blog for your convenience. Today, you may experience some text formatting inconvenience which will be fixed shortly.

Cloud Servers Need Updating Too

Cloud Servers Need Updating Too

Cloud provisioning has steadily replaced locally hosted servers. It’s simply much faster, and often cheaper, to fire up cloud-hosted Linux VMs to handle workloads and to scale in response to demand.

No wonder the infrastructure-as-a-service (IaaS) market is growing rapidly, with Gartner suggesting that IaaS billings grew by 37.3% in 2019 alone. But this ease of use can be deceiving – and leave companies that operate cloud-hosted Linux servers at massive risk of cyberattacks.

In this article, we explain why cloud-hosted Linux servers pose unique security risks, what that means in terms of your company’s maintenance responsibilities, and outline what your company can do to ensure its cloud Linux servers are always up to date.

 

Contents:

  1. What Are Virtual Machines In The Cloud (IaaS)?
  2. Cloud Services, And IaaS, Are At Risk
  3. Case In Point: SACK Panic
  4. It’s Easy To Spin Up A New System, But The Maintenance And Security Is On You
  5. The Problem With Kernel Patching
  6. How KernelCare Can Help
  7. Conclusion

 

What Are Virtual Machines In The Cloud (IaaS)?

What Are Virtual Machines In The Cloud (IaaS)?

Infrastructure as a service (IaaS) can be defined as “an instant computing infrastructure, provisioned and managed over the Internet”. A key component of IaaS is the ability to purchase the use of hardware resources such as servers and to quickly deploy these resources to meet your company’s or your customer’s application requirements.

Renting a server could imply renting an entire physical server, but more commonly, companies rent virtualized hardware infrastructure that grants access to a specific amount of processing power and storage. This is delivered by the IaaS vendor, a provider that flexibly manages physical hardware using cutting edge virtualization technology.

As part of a cloud server package, your vendor will usually give you convenient routes to installing a pre-packed Linux distribution. It’s simple too: just click to trigger the installation, and you’re set to start running your Linux workload.

However, installation can be deceptively simple and it is easy to assume that you can simply set up and then forget about your Linux server. But that would be taking a significant risk.

 

 

Cloud Services, And IaaS, Are At Risk

Cloud Services, And IaaS, Are At Risk

The recent Sophos The State of Cloud Security survey illustrated how easy it is to take cloud security for granted – and at what cost that comes. According to the Sophos survey, 98% of companies did not enable the most elementary security step – multi-factor (MFA) – authentication on their accounts.

That makes it no surprise that of the 3,200 IT managers that were surveyed, 70% reported that they were hacked or that data leaked from their accounts.

Breaches of cloud security keep coming hard and fast. In one example, earlier this year, a sophisticated group hacked Amazon Web Services (AWS), installing a rootkit that enabled the hackers to remotely control AWS servers.

It’s not just AWS, of course. In 2019, Israeli firm NSO Group, creators of the Pegasus malware used to hack WhatsApp, stated that it was able to breach all of the major tech firm’s cloud services. In essence, the company claimed that its software is designed to enable crime investigations for law enforcement firms.

Either way, it is clear indication that cloud servers are vulnerable. And one of the key points of vulnerability is Linux kernels.

 

 

Case in point: SACK Panic

Also in 2019, media giant Netflix found a number of critical networking vulnerabilities in Linux kernels. With this exploit, attackers could proceed as long as they could open a TCP connection to the server – irrespective of the service in play. One of the most critical vulnerabilities was named “SACK Panic” by Netflix.

When used, an attacker could force a Linux machine to crash using traffic that is specifically crafted for that purpose. It has led many major distributions including Ubuntu and Red Hat to issue warnings against the SACK Panic kernel exploit.

The Netflix discovery highlights how Linux kernels are incredibly vulnerable. Yes, vulnerabilities will lead to kernel patches that effectively patch those vulnerabilities, but patches have a key weakness: a perfectly effective patch will never work if the operator of the Linux machine does not apply the patch.

 

 

It’s Easy To Spin Up A New System, But The Maintenance And Security Is On You

It’s Easy To Spin Up A New System, But The Maintenance And Security Is On You

A comprehensive list of the security measures required to secure cloud services (e.g. MFA) is beyond the scope of this article, but we’ll address one critical point here: Linux kernel patching. In the view of the example above, kernel patching is an obvious but often neglected aspect of cloud server security.

When companies deploy Linux servers in the cloud they rely on the rapid, simple, and scalable roll-out processes offered by IaaS providers. It involves rolling out a standard but often slightly dated Linux distribution – which inevitably won’t contain the latest critical patches.

Worse, operators of cloud servers sometimes assume that the IaaS provider is responsible for kernel live patching when in fact they patch only with reboot. As SACK Panic shows us, an unpatched kernel can lead to an incredibly expensive cyber breach. As the operator of Linux virtual servers, your company cannot ignore kernel live patching.

Unfortunately, consistently patching kernels is easier said than done.

 

 

The Problem With Kernel Patching

The Problem With Kernel Patching

First, patching the kernel in a server typically requires a reboot. While rebooting, a server is taken offline – and the services supported by that server are taken offline. It is a huge disincentive to regular, frequent patching – companies simply do not want to disrupt services just to apply a security patch unless it is absolutely critical.

Next, patching is a labor-intensive process. It’s not just the patching: it’s monitoring server performance on restart and ensuring that patches do not break critical services. Between the downtime caused by patching and the effort involved, there is no surprise that regular patching takes a back seat, which creates significant cybersecurity risks.

There is an alternative to server restarts and manual patching, however.

 

 

How KernelCare Can Help

How KernelCare Can Help

Automating kernel patching to ensure consistent, effort-free patching of kernels is the first step and at its core, that is what KernelCare does. KernelCare continuously monitors for newly released patches and automatically triggers the update process once a patch is identified.

This automation takes away the problem of manual effort – no matter how many patches are rolled out, your cloud Linux servers are always patched and secure. However, KernelCare goes a step further.

In contrast to many other automated patching solutions, KernelCare can perform live patching. Companies that use KernelCare for automated patching experience minimise downtime because KernelCare can apply kernel patches without requiring a complete reboot of the Linux server.

As a result, KernelCare ensures that your Linux servers are always patched and that you do not need to depend on your patching efforts or the (likely absent) support of your IaaS provider.

 

Conclusion

Live patching is a key step, but the overall message of this article remains that you must actively manage your IaaS Linux server instances. Think twice about leaving server maintenance and security up to the vendors that provide the infrastructure. Doing so will leave your operations open to security vulnerabilities that can be very costly – and which are completely avoidable.

Cloud Servers Need Updating Too

Cloud Servers Need Updating Too

Cloud provisioning has steadily replaced locally hosted servers. It’s simply much faster, and often cheaper, to fire up cloud-hosted Linux VMs to handle workloads and to scale in response to demand.

No wonder the infrastructure-as-a-service (IaaS) market is growing rapidly, with Gartner suggesting that IaaS billings grew by 37.3% in 2019 alone. But this ease of use can be deceiving – and leave companies that operate cloud-hosted Linux servers at massive risk of cyberattacks.

In this article, we explain why cloud-hosted Linux servers pose unique security risks, what that means in terms of your company’s maintenance responsibilities, and outline what your company can do to ensure its cloud Linux servers are always up to date.

 

Contents:

  1. What Are Virtual Machines In The Cloud (IaaS)?
  2. Cloud Services, And IaaS, Are At Risk
  3. Case In Point: SACK Panic
  4. It’s Easy To Spin Up A New System, But The Maintenance And Security Is On You
  5. The Problem With Kernel Patching
  6. How KernelCare Can Help
  7. Conclusion

 

What Are Virtual Machines In The Cloud (IaaS)?

What Are Virtual Machines In The Cloud (IaaS)?

Infrastructure as a service (IaaS) can be defined as “an instant computing infrastructure, provisioned and managed over the Internet”. A key component of IaaS is the ability to purchase the use of hardware resources such as servers and to quickly deploy these resources to meet your company’s or your customer’s application requirements.

Renting a server could imply renting an entire physical server, but more commonly, companies rent virtualized hardware infrastructure that grants access to a specific amount of processing power and storage. This is delivered by the IaaS vendor, a provider that flexibly manages physical hardware using cutting edge virtualization technology.

As part of a cloud server package, your vendor will usually give you convenient routes to installing a pre-packed Linux distribution. It’s simple too: just click to trigger the installation, and you’re set to start running your Linux workload.

However, installation can be deceptively simple and it is easy to assume that you can simply set up and then forget about your Linux server. But that would be taking a significant risk.

 

 

Cloud Services, And IaaS, Are At Risk

Cloud Services, And IaaS, Are At Risk

The recent Sophos The State of Cloud Security survey illustrated how easy it is to take cloud security for granted – and at what cost that comes. According to the Sophos survey, 98% of companies did not enable the most elementary security step – multi-factor (MFA) – authentication on their accounts.

That makes it no surprise that of the 3,200 IT managers that were surveyed, 70% reported that they were hacked or that data leaked from their accounts.

Breaches of cloud security keep coming hard and fast. In one example, earlier this year, a sophisticated group hacked Amazon Web Services (AWS), installing a rootkit that enabled the hackers to remotely control AWS servers.

It’s not just AWS, of course. In 2019, Israeli firm NSO Group, creators of the Pegasus malware used to hack WhatsApp, stated that it was able to breach all of the major tech firm’s cloud services. In essence, the company claimed that its software is designed to enable crime investigations for law enforcement firms.

Either way, it is clear indication that cloud servers are vulnerable. And one of the key points of vulnerability is Linux kernels.

 

 

Case in point: SACK Panic

Also in 2019, media giant Netflix found a number of critical networking vulnerabilities in Linux kernels. With this exploit, attackers could proceed as long as they could open a TCP connection to the server – irrespective of the service in play. One of the most critical vulnerabilities was named “SACK Panic” by Netflix.

When used, an attacker could force a Linux machine to crash using traffic that is specifically crafted for that purpose. It has led many major distributions including Ubuntu and Red Hat to issue warnings against the SACK Panic kernel exploit.

The Netflix discovery highlights how Linux kernels are incredibly vulnerable. Yes, vulnerabilities will lead to kernel patches that effectively patch those vulnerabilities, but patches have a key weakness: a perfectly effective patch will never work if the operator of the Linux machine does not apply the patch.

 

 

It’s Easy To Spin Up A New System, But The Maintenance And Security Is On You

It’s Easy To Spin Up A New System, But The Maintenance And Security Is On You

A comprehensive list of the security measures required to secure cloud services (e.g. MFA) is beyond the scope of this article, but we’ll address one critical point here: Linux kernel patching. In the view of the example above, kernel patching is an obvious but often neglected aspect of cloud server security.

When companies deploy Linux servers in the cloud they rely on the rapid, simple, and scalable roll-out processes offered by IaaS providers. It involves rolling out a standard but often slightly dated Linux distribution – which inevitably won’t contain the latest critical patches.

Worse, operators of cloud servers sometimes assume that the IaaS provider is responsible for kernel live patching when in fact they patch only with reboot. As SACK Panic shows us, an unpatched kernel can lead to an incredibly expensive cyber breach. As the operator of Linux virtual servers, your company cannot ignore kernel live patching.

Unfortunately, consistently patching kernels is easier said than done.

 

 

The Problem With Kernel Patching

The Problem With Kernel Patching

First, patching the kernel in a server typically requires a reboot. While rebooting, a server is taken offline – and the services supported by that server are taken offline. It is a huge disincentive to regular, frequent patching – companies simply do not want to disrupt services just to apply a security patch unless it is absolutely critical.

Next, patching is a labor-intensive process. It’s not just the patching: it’s monitoring server performance on restart and ensuring that patches do not break critical services. Between the downtime caused by patching and the effort involved, there is no surprise that regular patching takes a back seat, which creates significant cybersecurity risks.

There is an alternative to server restarts and manual patching, however.

 

 

How KernelCare Can Help

How KernelCare Can Help

Automating kernel patching to ensure consistent, effort-free patching of kernels is the first step and at its core, that is what KernelCare does. KernelCare continuously monitors for newly released patches and automatically triggers the update process once a patch is identified.

This automation takes away the problem of manual effort – no matter how many patches are rolled out, your cloud Linux servers are always patched and secure. However, KernelCare goes a step further.

In contrast to many other automated patching solutions, KernelCare can perform live patching. Companies that use KernelCare for automated patching experience minimise downtime because KernelCare can apply kernel patches without requiring a complete reboot of the Linux server.

As a result, KernelCare ensures that your Linux servers are always patched and that you do not need to depend on your patching efforts or the (likely absent) support of your IaaS provider.

 

Conclusion

Live patching is a key step, but the overall message of this article remains that you must actively manage your IaaS Linux server instances. Think twice about leaving server maintenance and security up to the vendors that provide the infrastructure. Doing so will leave your operations open to security vulnerabilities that can be very costly – and which are completely avoidable.