In recent times we are seeing an increased number of Docker container malware. Attackers scan the internet to identify the misconfigured Docker engine API installations to install the malicious images or run commands to install the malware. Access to the Docker engine API can provide an attacker fine control over the Docker installation enabling him/her to create, delete, dump and run commands in the containers, although the majority of the malware seen to-date are either using system resources for crypto mining or denial of service attacks. In general, the container is an encapsulated environment to run the application so it can be used for any activity from proxies to botnet services and can easily become part of attacker infrastructure to distribute malware.
It is not often that one runs into situations that so purely fit a classic stereotype. Securing and monitoring Docker containers happens to be one of those conundrums that is a textbook example of a “damned if you do and damned if you don’t” setup. On the surface, securing and monitoring containers seems like a straightforward affair – treat containers like mini virtual machines, and run your security/monitoring agents in each container; or, treat them like processes running on the host OS, and run your security/monitoring agents on the host OS. Sounds simple enough. However, both options run into some surprisingly natty difficulties.