Containersicherheit
Linux-Server werden oft als Basis für die Ausführung von Docker-Containern und Docker-Orchestrierungstools verwendet. Die Containersicherheitsfunktion ist Teil des Echtzeit-Dateischutzes in ESET Server Security for Linux.
ESET Server Security for Linux kann Bedrohungen oder verdächtige Aktivitäten in einem Container erkennen und blockieren, jedoch nicht entfernen. Das bedeutet, dass die Ausführung eines verdächtigen Skripts blockiert, das Skript selbst aber nicht gelöscht wird. Sie können die Datei manuell löschen.
Echtzeit-Dateischutz
Der Echtzeit-Dateischutz von ESET scannt den Container in den folgenden Phasen:
•Vorgehensweise für das Erstellen des Containerimages
•Bereitstellen des Containerimages auf einem Computer, der geschützt ist durch ESSL
Die Aktivität im Container wird ebenfalls in Echtzeit auf verdächtige Verhaltensweisen gescannt.
Web-Schutz
Der Web-Schutz wird nur für Container im Hostnetzwerk unterstützt. Container in anderen Netzwerktypen sind weiterhin ungeschützt. Der gesamte HTTP-Datenverkehr wird automatisch gescannt, wenn sich ein Container im Hostnetzwerk befindet. Importieren Sie das Zertifikat ESET-SSL-Filter-CA.pem in den Container, um das Scannen des HTTPS-Datenverkehrs zu ermöglichen.
Das Zertifikat befindet sich in:
/etc/ssl/certs/ |
Alternativ:
/etc/pki/ca-trust/extrahiert/pem/ |
On-Demand-Scans
Ein On-Demand-Scan kann die Infektion säubern, wenn sich die infizierte Datei an einem öffentlichen Bereitstellungspunkt befindet und nicht in einem privaten Namespace verborgen ist.
Kubernetes
In Kubernetes mit containerd wird die Bereitstellung des infizierten Containers erkannt, und sie schlägt fehl.
Beispiel für die Dateierkennung 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 |
Der Pod kann nicht gestartet werden und schreibt den Pull-Fehler ins Log:
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 mit CRI-O wird die Bereitstellung des infizierten Containers nur erkannt, aber nicht gesäubert, und ein Container wird gestartet.
|
Wenn die Netzwerkisolierung aktiv ist, gilt Folgendes: •Die Kommunikation zwischen Containern im Bridge-Netzwerk wird blockiert. •Die Kommunikation von Overlay-Netzwerkcontainern zum Host wird blockiert. •Der Web-Schutz scannt die Container-Kommunikation nicht. |
ESET hat Folgendes getestet:
•Kubernetes mit containerd
•Kubernetes mit CRI-O