Security technology: virtual servers vs. containers
Which technology is safer? Many people think that virtual servers are largely dominated by these qualities. In theory, yes, but in practice ... there are doubts.
Often we hear such loud statements like “HTTPS is well protected”, or “HTTP is not secure”. But what do we really mean by these phrases? "HTTPS is difficult to track down and launch a man-in-the-middle attack, or" my grandmother has no problem tracking HTTP. "
In this matter, you can not throw such phrases, because HTTPS can be cracked (and there have been cases), and HTTP is safe in some cases. In addition, if upon detection of a vulnerability related to operation in a common implementation that supports HTTPS (meaning OpenSSL and Heartbleed), then this very HTTPS can become a hacker gateway until the entire system is fixed.
')
HTTP and HTTPS are the protocols defined by the Internet Engineering Council (IETF) in RFCs numbered 7230-7237 and 2828. HTTP originally appeared, and in 2000 HTTPS was developed as a more secure analog of HTTP. However, it cannot be said that HTTPS is secure, but HTTP is not. there are exceptions.
Divide and conquer is a winning principle not only for military strategy, but also for software. When the architecture divides one large, complex, intractable security problem into easier tasks, the solution to each component of this problem in most cases will be a safer option than in a situation where there is one solution that addresses all problems.
Containers are just a vivid example of this principle. Due to the fact that each application is segregated in its own “cell”, deficiencies in one application do not weaken applications in other containers. Virtual machines also exist on this principle, but in this case, and every action they take in isolation.
When working with containers, the following risk exists: Weakness or malfunction of one application enclosed in a “cell” cannot directly affect other applications, but this faulty application can cause damage to a single operating system (OS), which other containers also use. Thus, all containers will have a negative impact. In view of all this, we can conclude that when using a common OS, the entire structure is at risk if a malfunction occurs in at least one of its components. Those. if at least some segment is adversely affected, then it threatens the physical machine.
Multi-tier architecture, such as virtualization of Windows VDS servers, separates the stack of each application up to the hardware, eliminating the possibility of applications interacting with each other through a common OS. In addition, there are even-numbered boundaries between each application stack and equipment to prevent further errors and misuse. All this provides additional reliability and protection, not allowing applications to adversely affect each other. Virtual machines separate the OS that controls the user’s actions from the hypervisor, which controls the interaction between the guest OS and the hardware. The guest OS of the virtual machine controls the actions of users, but not the interaction with the hardware. Errors in the application or guest OS are unlikely to affect physical hardware or other virtual machines.
If you take 2 identical OSs (guest OS of the virtual machine and OS of the container), then with any negative impact all containers running on the OS will be compromised, and no threat will be detected for the virtual machines. The reason is that virtual machines for security use a method where applications are isolated horizontally, and the OS is separated from hardware vertically.
But still back to the article title, are virtual machines so ideal? And yet, even in such an architecture, which involves the separation of all layers, a threat may arise. And the weak point in this architecture is the hypervisor. Hypervisor disruption is a single point of failure that can disable the entire system, or cause data to become unavailable, especially in public clouds. Thus, a situation may well arise when one hacker runs malicious code on a virtual machine managed by other applications that belong to users of the public cloud, and thereby using one attack, he will acquire all the data of the public cloud.
An architecture with a solid structure may still have implementation errors that significantly weaken the system. Violations in the work of the hypervisor are often not given due attention, because there is a strong opinion that nothing will ever happen to them. After all, it is believed that hypervisors are so simple, so well written, so thoroughly tested that they simply never fail. But the consequences of mistakes in the work of the hypervisor can be as devastating as the sadly familiar consequences of the WannaCry virus. By the way, by the way, let us also recall the infamous Heartbleed, an error in the OpenSSL cryptographic software. But OpenSSL has far fewer lines of code than the hypervisor. But for now don't worry about it.
To date, we have no information about any resonant and serious hypervisor violations that would put the entire system at risk. But a quick, rapid analysis of the well-known Information Security Vulnerability (CVE) database reveals that researchers still find flaws in the operation of the hypervisor that affect the vulnerability of the technology. But it is worth paying tribute to the developers of the hypervisor, as the emergence and detection of any system vulnerabilities, they quickly find ways to fix them. In March 2017, Microsoft released security bulletin MS17-008, which documented seven fixed vulnerabilities in the Hyper-V hypervisor, by the way, all of which are designated as serious or critical.
In conclusion, we can say that, based on practical use and theoretical knowledge of the operation of the system, virtual machines still provide better security than containers. But we must look at the security of virtual machine systems without rose-colored glasses and always be alert. In addition, containers and virtual machines are often combined, so you can discuss this topic for a long time.
Often we hear such loud statements like “HTTPS is well protected”, or “HTTP is not secure”. But what do we really mean by these phrases? "HTTPS is difficult to track down and launch a man-in-the-middle attack, or" my grandmother has no problem tracking HTTP. "
In this matter, you can not throw such phrases, because HTTPS can be cracked (and there have been cases), and HTTP is safe in some cases. In addition, if upon detection of a vulnerability related to operation in a common implementation that supports HTTPS (meaning OpenSSL and Heartbleed), then this very HTTPS can become a hacker gateway until the entire system is fixed.
')
HTTP and HTTPS are the protocols defined by the Internet Engineering Council (IETF) in RFCs numbered 7230-7237 and 2828. HTTP originally appeared, and in 2000 HTTPS was developed as a more secure analog of HTTP. However, it cannot be said that HTTPS is secure, but HTTP is not. there are exceptions.
Why VPS (virtual machines) are safer than containers
Divide and conquer is a winning principle not only for military strategy, but also for software. When the architecture divides one large, complex, intractable security problem into easier tasks, the solution to each component of this problem in most cases will be a safer option than in a situation where there is one solution that addresses all problems.
Containers are just a vivid example of this principle. Due to the fact that each application is segregated in its own “cell”, deficiencies in one application do not weaken applications in other containers. Virtual machines also exist on this principle, but in this case, and every action they take in isolation.
When working with containers, the following risk exists: Weakness or malfunction of one application enclosed in a “cell” cannot directly affect other applications, but this faulty application can cause damage to a single operating system (OS), which other containers also use. Thus, all containers will have a negative impact. In view of all this, we can conclude that when using a common OS, the entire structure is at risk if a malfunction occurs in at least one of its components. Those. if at least some segment is adversely affected, then it threatens the physical machine.
Multi-tier architecture, such as virtualization of Windows VDS servers, separates the stack of each application up to the hardware, eliminating the possibility of applications interacting with each other through a common OS. In addition, there are even-numbered boundaries between each application stack and equipment to prevent further errors and misuse. All this provides additional reliability and protection, not allowing applications to adversely affect each other. Virtual machines separate the OS that controls the user’s actions from the hypervisor, which controls the interaction between the guest OS and the hardware. The guest OS of the virtual machine controls the actions of users, but not the interaction with the hardware. Errors in the application or guest OS are unlikely to affect physical hardware or other virtual machines.
If you take 2 identical OSs (guest OS of the virtual machine and OS of the container), then with any negative impact all containers running on the OS will be compromised, and no threat will be detected for the virtual machines. The reason is that virtual machines for security use a method where applications are isolated horizontally, and the OS is separated from hardware vertically.
Hypervisor Vulnerability
But still back to the article title, are virtual machines so ideal? And yet, even in such an architecture, which involves the separation of all layers, a threat may arise. And the weak point in this architecture is the hypervisor. Hypervisor disruption is a single point of failure that can disable the entire system, or cause data to become unavailable, especially in public clouds. Thus, a situation may well arise when one hacker runs malicious code on a virtual machine managed by other applications that belong to users of the public cloud, and thereby using one attack, he will acquire all the data of the public cloud.
An architecture with a solid structure may still have implementation errors that significantly weaken the system. Violations in the work of the hypervisor are often not given due attention, because there is a strong opinion that nothing will ever happen to them. After all, it is believed that hypervisors are so simple, so well written, so thoroughly tested that they simply never fail. But the consequences of mistakes in the work of the hypervisor can be as devastating as the sadly familiar consequences of the WannaCry virus. By the way, by the way, let us also recall the infamous Heartbleed, an error in the OpenSSL cryptographic software. But OpenSSL has far fewer lines of code than the hypervisor. But for now don't worry about it.
To date, we have no information about any resonant and serious hypervisor violations that would put the entire system at risk. But a quick, rapid analysis of the well-known Information Security Vulnerability (CVE) database reveals that researchers still find flaws in the operation of the hypervisor that affect the vulnerability of the technology. But it is worth paying tribute to the developers of the hypervisor, as the emergence and detection of any system vulnerabilities, they quickly find ways to fix them. In March 2017, Microsoft released security bulletin MS17-008, which documented seven fixed vulnerabilities in the Hyper-V hypervisor, by the way, all of which are designated as serious or critical.
In conclusion, we can say that, based on practical use and theoretical knowledge of the operation of the system, virtual machines still provide better security than containers. But we must look at the security of virtual machine systems without rose-colored glasses and always be alert. In addition, containers and virtual machines are often combined, so you can discuss this topic for a long time.
Source: https://habr.com/ru/post/348430/
All Articles