You would think you’d already have problems if someone’s managed to compromise one or more of your containers without you knowing though whether they can get the host or not
True, but the security idea behind being in a containerised environment is that your problems aren’t immediately made worse by the fact that your database server is on the same machine as your web application - since they’d both be on separate but networked containers.
What if anything do people do about anti virus in containers?
The real threat to containers isn’t AV-detectable malware, but Remote Code Execution (RCE) exploits.
Containers are best used as single purpose installations. With that configuration, it isn’t easy to get non-standard executables - including malware - onto a container.
Most RCE exploits also don’t involve the dropping of malware files onto the file system. There are some that do, but that issue is better handled in other ways.
Why? Well AVs only do something about binaries they know or think to be malware. A well crafted, customised Cobalt Strike beacon (aka: malicious remote control software) will blow through any resistance an AV has to offer.
So what do we do? Remember what I said that containers are best used as single purpose installations? Therefore you know exactly what executables should be running, making it trivial to set up executable whitelisting. That means that any executable not on the list will not run.
But even that isn’t completely bulletproof. It won’t do much against web shells, in which case your best detection mechanism is to look for applications calling /bin/bash or /bin/sh that shouldn’t be.
True, but the security idea behind being in a containerised environment is that your problems aren’t immediately made worse by the fact that your database server is on the same machine as your web application - since they’d both be on separate but networked containers.
The real threat to containers isn’t AV-detectable malware, but Remote Code Execution (RCE) exploits.
Containers are best used as single purpose installations. With that configuration, it isn’t easy to get non-standard executables - including malware - onto a container.
Most RCE exploits also don’t involve the dropping of malware files onto the file system. There are some that do, but that issue is better handled in other ways.
Why? Well AVs only do something about binaries they know or think to be malware. A well crafted, customised Cobalt Strike beacon (aka: malicious remote control software) will blow through any resistance an AV has to offer.
So what do we do? Remember what I said that containers are best used as single purpose installations? Therefore you know exactly what executables should be running, making it trivial to set up executable whitelisting. That means that any executable not on the list will not run.
But even that isn’t completely bulletproof. It won’t do much against web shells, in which case your best detection mechanism is to look for applications calling /bin/bash or /bin/sh that shouldn’t be.