Container security best practices often tout the ‘born secure’ concept. It reinforces the DevOps approach adopted in containerization where codes are developed, tested and run in CI/CD pipelines before they are deployed in the actual production environment. Attacks on an application in a container environment can happen even before the application goes live. This vulnerability and many other attributes of the container environment have massively changed the way enterprises manage the security of their applications in the cloud.
Microservices-based applications
At this juncture, most of us at the IT end know that containerization revolves around the virtualization of the host operating system (OS), an architecture that is vastly different from the virtualization of the underlying physical infrastructure. Containers are created and orchestrated on orchestration platforms such as Amazon, Kubernetes, Amazon, Azure, Google and Red Hat OpenShift using container technologies such as Docker and CoreOS Rocket.
Virtualization of the host OS simply means that containers can be spun up and run in seconds. It accelerates the creation of cloud native applications in a microservices architecture where monolithic codes are broken down into smaller services for scalability and ease of deployment. Microservices, when containerized, make scaling, replicating and moving between clouds and operating systems seamless. Using container images and image registry, new microservices encapsulated in containers can be created and deleted continuously, based on demand and resources.
North-south traffic goes east-west
However, this agility and speed comes at a cost. The microservices architecture expands the attack surface for an application as it exposes more application endpoints. The probability of vulnerable interfaces increases with a growing number of east-west connections and higher traffic between containers and pods as well as the deployment of applications on multiple clouds using service meshes. As containers are ephemeral, and sometimes only last for minutes, malware activity can be initiated and then disappear without trace. Add to this the dynamic provisioning of IP addresses, and network monitoring becomes a challenge, while cyberattacks become harder to track and capture.
Let’s examine the Kinsing malware1
for example. This malware scouts for misconfigured open Docker Daemon API ports to launch its own malware-filled container. The Kinsing malware exhausts the underlying server resources to run Bitcoin mining, infesting other containers while doing so, and propagates throughout the network.
Due to their vulnerabilities, misconfigured open API ports have become top targets for cybercriminals. DOKI2, another malware, uses these ports to launch new self-propagating containers unleashing new attacks on the network. DOKI avoids traceability by creating short-lived containers with short-lived IP addresses, which renders traditional behavior or anomaly tracking ineffective when it comes to identifying the culprit.
Securing container networks with DPI
If enterprises were to scale up their cloud deployments, container security is something that they must consider. Concepts such as ‘born secure’ add to the handful of best practices which include platform-specific security policies, for example Docker CIS Benchmark and Kubernetes CIS Benchmark and the automation of security policies throughout the container lifecycle. This extends to scans and periodic audits of images, containers, pods, registries, namespaces and clusters, and strict admission controls for access.
Interestingly, given the distributed nature of applications, identification of anomalies and malicious activity at the network layer introduces a new level of security control in containerized applications. It enables packet inspection tools such as Deep Packet Inspection (DPI) to sniff out existing and potential threats and infiltrating pods and containers before these threats become endemic. In many ways, network-level scrutiny via interface checkpoints puts a native grip on container security, especially as east-west traffic and the number of links, bridges and tunnels within container networks continue to grow.
DPI in a container
DPI software, for example our DPI engine R&S®PACE 2, enables developers to build their own images, deploying the DPI software code on downloaded Dockerfiles and connecting the application to the engine’s threat signature library via a web console or an API. Thus, the DPI software gains access to relevant network interfaces. This enables R&S®PACE 2 to detect traffic patterns and traffic protocols (e.g DNS, SMTP, HTTP and MySQL), applications (e.g. Gmail, Facebook, Skype) and application attributes (e.g. video, chat) for both internal and external traffic. With DPI functionality automated onto the orchestration platform, traffic anomalies and suspicious behavior from any pod or container can be identified in real time, even for the newest containers and for those that were only alive for a few minutes. The notorious DOKI malware for example, can be detected by DPI via packet-level identification of the Ngrok Mining Botnet.
More importantly, DPI can also be used as a Layer-7 firewall service with its ability to block traffic, based on container-specific security rules or general rules imported from existing web applications, including rules for detection of DDoS, XSS, zero-day and DNS attacks. It supports Intrusion Detection/Prevention systems (IDS/IPS) and web filtering by supplying real-time data to these engines, in addition to enforcing whitelist/blacklist policies for selected applications. Attacks on the enterprise’s CI/CD pipelines can be identified through the analysis of traffic entering or exiting the control repository and developer workstations. DPI also enables the implementation of data protection, including data loss prevention systems.
The added bonus of having DPI on a container network is that it also acts as a performance monitor. The computing, storage and memory of hosts, pods and containers are identified in real time, enabling application owners to identify activities, especially unauthorized container activities, that can place a strain on the network.
In its ‘State of Container and Kubernetes Security Fall 2020’ report3, Stackrox reported that the share of organizations with more than half of their applications containerized has reached 33 %. While a host of container security measures, including built-in codes such as runtime application self-protection (RASP) security control as well as routine scans and zero-trust policies can identify imminent dangers for containers, network-level security will be needed as inter-cloud and intra-cloud lateral traffic surges to new levels since more applications are containerized and split into microservices.
For fans of DPI, it is time to brace ourselves and watch DPI in action, as it takes on each cyberthreat in real time, in the world of clouds and containers.
Sources:
