A 4-Step Guide to Building Continuous Security into Container Deployment

系统架构 容器 安全

摘要： Containers face security risks at every stage, from building to shipping to the run-time production phases. Securing them requires a layered strategy throughout the stack and the deployment process.

作者： Fei Huang

审校： Manuel Pais

正文：

本文要点

• Risks to containers come in many forms: ransomware, application-level DDoS, compromised containers or breakouts, and more

• Every successful attack involves a 'kill chain' of events, curtailing them requires a layered security strategy throughout the stack and at each phase of the deployment process

• There are specific security measures to be applied not just in production but at each of the previous 3 phases as well: build, ship, preparation for production

• For continuous security in container build, ship and preparation for production phases should include: code analysis, hardening, image scanning, image signing and user access controls, host & kernel security, system & Docker daemon security, secrets management, auditing, and orchestration security & networking

• Preparation for and runtime production phases should include: network inspection & visualization, layer 7-based application isolation, threat detection, privilege escalation detection, container quarantine, run-time vulnerability scanning, and packet capture & event logging

Containers face numerous security risks at every stage of the deployment process, from building to shipping to the run-time production phases. These threats make achieving continuous security essential to the integrity and safety of containers. However, often these security measures are skipped or overlooked in the rush to get the CI/CD pipeline flowing faster. Many businesses are paying the price today for poor security implemented years ago. Hopefully, these mistakes won’t be repeated in the migration to a containerized environment.

Risks to containers and their hosts come in many forms: ransomware, application-level DDoS and cross-site scripting attacks, compromised containers that download extra malware or hunt for sensitive data or weaknesses in internal systems, container breakouts allowing unauthorized access across systems, containers forced to eat up system resources to crash other containers, and plenty others.

Many of these attacks start with previously undetected vulnerabilities that can lie dormant for years. Attackers exploit these to gain a foothold, and then expand into other hosts or containers.

Apache Struts Exploit Used in Equifax Breach

Apache Struts is a widely used framework for creating web applications in Java. It was initially believed that the newly-published Struts vulnerability, CVE-2017-9805, was responsible for the Equifax data breach. However, the latest announcement from Equifax indicates that it was vulnerability CVE-2017-5638, which was discovered in March, that allowed the Equifax data breach.

The vulnerable code of CVE-2017-9805 resides in the REST plugin of the Struts framework. The plugin fails to validate and deserialize safely the user uploaded data in the HTTP request. This allows attackers to write arbitrary binary code to the web server and execute it remotely. In March, the vulnerability CVE-2017-5638 was reported in the Jakarta multi-part parser. By injecting a crafted Content-Type HTTP header with a '#cmd=' string, the attacker is also able to execute arbitrary commands on the web server.

Ransomware

Recent ransomware attacks have exploited various vulnerabilities, including open ports, remote code execution, and other application liabilities.

WannaCry/WannaCrypt is basically attacking Microsoft Windows vulnerabilities on SMB, RDP, and IIS service ports like 445. Like most attacks, there is a "kill chain" of events that leads to the ransomware demand.

Once attackers are able to get inside a network they spread laterally in an ‘east-west’ direction. Doing that has become much easier in a containerized environment due to the lack of visibility into east-west container traffic.

SambaCry is a 7-year-old critical remote code execution vulnerability (CVE-2017-7494) discovered in the Samba networking software that could allow a remote attacker to take control of an affected Linux system. Today, if you have your CVE database updated in time, vulnerability scanning software could help to find this CVE in container images. Other techniques can also help detect a privilege escalation or breakout.

ElasticSearch and MongoDB are two of the most popular application container downloads from Docker Hub. Surprisingly simple attacks involving open ports and passwords could allow these to be used for ransomware. Basic container security precautions could prevent such an attack. Frequent auditing and testing of host and container security settings would highlight risks introduced by the latest application updates or host deployments.

Dirty Cow

The Dirty Cow (CVE-2016-5195) kernel exploit is used by attackers to overwrite a so-called setuid program in the system. By replacing the setuid program, the attacker gains root access privilege when the program is executed, and is then able to do whatever they want. While an attacker can perform destructive acts, it is more likely that at this point they will try to expand to other systems or applications as stealthily as possible. It’s even possible for the exploit to stick around in a container environment, even when the infected containers are destroyed.

Linux Stack Clash

The Linux Stack Clash vulnerability (CVE-2010-2240) was recently discovered by Qualys security researchers and has been named "Stack Clash" because it involves "clashing" the stack with another memory region, such as the heap. While this is a local exploit in the user space, it can still give attackers a foothold into the operating system or kernel. Stack Clash could be used with other exploits to wreak even more havoc on systems and potentially move laterally. For example, a recent sudo vulnerability (CVE-2017-100367) could be combined with Stack Clash to be able to run arbitrary code with root privileges.

Attack Detection

Every successful attack involves a ‘kill chain’ of events, and detection is possible at multiple points using various techniques. Generally, to mitigate these risks in a container environment, the following security measures should be taken:

1. Scan hosts and containers (before and during run-time) for vulnerabilities and patch vulnerable systems;
2. Monitor hosts and containers for suspicious processes such as root privilege escalations and port scanning;
3. Detect lateral movements and breakouts using suspicious network connections to other hosts or containers;
4. Lock down containers from external access if not strictly required;
5. Continuously audit security settings for containers, hosts, and platform tools.

Curtailing these threats requires a layered security strategy that is implemented to prevent issues throughout the stack and at each phase of the deployment process. The correct security controls and automated tests to detect and address attacks and other issues are critical components for ensuring effective and secure applications.

Here are the measures you can put in place throughout the container deployment process to enact continuous security.

Step 1 - Build Phase

Continuous security begins with building secure applications. Developers must understand and utilize proper techniques for minimizing risk within the application code itself. These techniques include:

Code analysis – Developers should make use of code analysis tools that can recognize and report any potential vulnerabilities.

Hardening – Reduce the attack surface of the container image by removing any libraries and packages that aren’t needed, and by restricting non-required functions.

Image Scanning – Just before the ship phase, container images should be scanned for vulnerabilities in order to catch any issues before the application is built. Registry scanning should also be done regularly, as this can find new issues in existing images.

As a practical matter of executing these security measures, they should be automated into the delivery process/pipeline using adequate tools, as doing so ensures they are performed continuously and without fail.

Step 2 - Ship Phase

When preparing to deploy images, security depends on the right controls and verifications in place to ensure trust. These include:

Image signing – This ensures that the author / publisher is verified and that no image tampering has occurred. For example, Docker’s Content Trust feature provides this security.

User access controls – Sensitive systems and deployment tools (registries, orchestration tools, etc.) should have mechanisms in place to effectively enforce restrictions and monitor for user access.

In order to automate these security features to facilitate continuous security, images for production use should be signed and tagged automatically. Access controls for sensitive tools should be integrated with Active Directory, or LDAP directories. Docker Bench for Security can be run as an automated process to test content trust and access control issues.

Step 3 - Run Phase: Preparation

Ahead of running application containers live in production, the run-time environment needs to be secured – including the host, kernel, Docker daemon, and all network and system services.

Host and kernel security – These can be safeguarded using security modules such as AppArmor, SELinux, seccomp, or the equivalent host security settings.

System and Docker daemon security – Make sure that only authorized users can access sensitive systems and Docker commands and settings.

Secrets Management – Utilize encryption to protect secrets that are subject to application and API access.

Auditing – Perform audits of security settings both before and during run-time. This can be accomplished using the previously mentioned Docker Bench for Security, Kubernetes CIS Benchmark, or other tools, and has the additional benefit of helping to meet container compliance requirements.

Orchestration security & networking – Secure the container environment by using container management and orchestration tools capable of controlling access, setting network policies and appropriate names and labels. These tools can also make sure that security containers are running on every host.

These orchestration and integrated security tools can deliver automated security testing and checks against standard benchmarks, as well as automatic policy updates to adapt to configuration changes and offer clearer visualization of behavior within the application and containers.

Step 4 - Run Phase: Production

Run-time in production environments is the most crucial phase when it comes to container security. This is the battleground where hackers will attempt to exploit any vulnerabilities they’ve discovered, and security efforts must detect and thwart those attempts. Hacker actions will include a "kill chain," the series of events that occur as the hacker moves from the host or another container to the targeted exploit point. This chain of events often presents several chances for the hacker’s activities to be detected and prevented, using these techniques:

Network inspection & visualization – Inspecting network behavior is the most opportune vantage point for monitoring and recognizing suspicious activity. Be sure to inspect all container-to-container connections, as well as container and host processes, and visualize application stack behavior. If an attack spreads and real-time response is necessary, these capabilities will enable the security team to see it coming and respond.

Layer 7-based application isolation – Go beyond L3/4 network segmentation by also isolating and protecting based on application protocols and container meta-data inspection. As necessary, application activity can be blocked without affecting containers.

Threat detection – Monitor applications, always remaining on the lookout for DDoS, DNS, or other varieties of network-based application attacks.

Privilege escalation detection – Hacking efforts may attempt to grant greater administrative privileges to unauthorized intruders. Detect these escalations on hosts and containers to foresee break outs and defend against such attacks.

Container quarantine – When a container exhibits suspicious behavior, have the ability to quarantine it for safety while the container is investigated.

Run-time vulnerability scanning – All running containers should be scanned for vulnerabilities; all newly created containers should be scanned immediately as well.

Packet capture & event logging – Capturing packets and creating event logs allows for more capable forensics efforts.

Tools that enable these security measures should be automatically deployed to each host, and new container behavior should be learned automatically or added to the security policy programmatically. Real-time monitoring and alerts can be managed from either local consoles or logs exported to SIEM systems.

Conclusion

With the right strategy in place to integrate security tools and automate policy, continuous container security that offers protection throughout the container deployment process can be achieved.

本文作者简介

Fei Huang is the Co-Founder & CEO of NeuVector, a Docker container network security solution that uses behavioral learning to secure containers during run-time. Fei has over 20 years of experience in enterprise security, virtualization, cloud and embedded software. He was part of the founding team of Cloudvolumes (acquired by VMware) and co-founder of Provilla, a DLP security company (acquired by TrendMicro). Fei holds several patents in security, virtualization and software architecture.

查看英文原文： A 4-Step Guide to Building Continuous Security into Container Deployment