Container security
Linux servers are often a base for running Docker containers and Docker orchestration tools. The container security feature is part of the real-time file system protection in ESET Server Security for Linux.
ESET Server Security for Linux can detect threats or suspicious activity in a container and block them but cannot eliminate them; meaning, a suspicious script will be blocked from execution but will not be deleted. You can delete it manually.
Real-time file system protection
ESET's real-time file system protection can scan the container in the following phases:
•process of building the container image
•deploying the container image on a machine protected by ESSL
The activity inside the container is also scanned in real-time for suspicious behavior.
|
This feature currently supports only containers running on Docker technology. If real-time file system protection detects an infected sample inside the container, the detection log records contain the object URI information, indicating that it was detected inside a container from specific images with a specific ID. |
Example of object URI:
docker://alpine:latest@025098c...70a1fe59004a5ecc23ede60a/eicar.com |
•docker:// represents container technology
•alpine:latest represents the container image
•025098c...70a1fe59004a5ecc23ede60a represents the container ID
•eicar.com represents the infected file
Example of complete detection record:
05/21/2026 11:01:40 PM,Error,Real-time file system protection,docker://alpine:latest@025098c...70a1fe59004a5ecc23ede60a/eicar.com,Eicar,Test file,Retained,root,/bin/busybox,Event occurred on a newly created file.,,3395856CE81F2B7382DEE72602F798B642F14140,@NAME=Eicar@TYPE=Teststring@SUSP=inf |
Web access protection
Web access protection is supported only for containers on the host network. Containers on any other network type remain unprotected. All HTTP traffic is scanned automatically when a container is on the host network. To enable scanning of HTTPS traffic, import the ESET-SSL-Filter-CA.pem certificate into the container.
The certificate is located in:
/etc/ssl/certs/ |
alternatively
/etc/pki/ca-trust/extracted/pem/ |
On-demand scans
An on-demand scan can clean the infection if the infected file is located at a public mount point and not hidden in a private namespace.
Kubernetes
In Kubernetes with containerd, the deployment of the infected container is detected, and the deployment fails.
Example of file detection in logs:
09.09.2024 13:56:43,1,Real-time file system protection,file:///var/lib/rancher/k3s/agent/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/82/fs/eicar.com,Eicar,Test file,Cleaned by deleting,root,/var/lib/rancher/k3s/data/e50868881d9744d0d0027dda983507e867b3787482eb00005d97239d9aa501a5/bin/k3s,Event occurred on a newly created file.,3395856CE81F2B7382DEE72602F798B642F14140,@NAME=Eicar@TYPE=Teststring@SUSP=inf |
The pod cannot start and logs the pull error:
root@userr-kubernetes:~/k8s_test# kubectl describe pods ...
Normal Pulling 7m47s (x4 over 10m) kubelet Pulling image "user/ubuntu_with_eicar:1.0" Warning Failed 7m27s (x4 over 9m48s) kubelet Error: ErrImagePull |
In Kubernetes with CRI-O the deployment of the infected container is only detected but not cleaned and a container is started.
|
When network isolation is active: •Communication between containers on the bridge network is blocked. •Communication from overlay network containers to the host is blocked. •Web access protection does not scan container communication. |
At ESET, we tested:
•Kubernetes with containerd
•Kubernetes with CRI-O