06-04-2021, 07:13 AM
I'll do a couple of posts in this thread. The first would be a quick review of the OP highlighting the main issues I had reading it. The second will address @deanhills' questions and @LightDestory's answers to them. May be later on, I'll open a more comprehensive thread on Linux containers and where Docker containers rank among them.
Here I won't go back to my previous principled objection (done elsewhere on this board) of using Docker inside a KVM VPS and just go along the assumption that the resources are good enough to get everything run smoothly.
Okay, now, for the OP's review. I understand that it wasn't planned to be a stand-alone topic from its intro. but still the whole OP fails on so many points that I can't just let it pass un-annotated--at least not under my watch :-)
1- The Why Docker Container Part:
From the above we deduce that the main incentive in using Docker containers here is the isolated, ephemeral and statelessness of the Docker container that makes it disposable, i.e. just throw the container away and spin up another one.
Nothing wrong there, in fact, it's perfectly what Docker containers are designed for:
> Docker containers are "ephemeral, stateless, minimal containers that won’t typically get upgraded or re-configured but instead just be replaced entirely.”
Although I did sense a bit of confusion in this part of the last paragraph:
It might be due to a lack of a clear view of what a container is really all about?!.. A container can be mentally viewed as a process tree running inside its own namespace (hence the isolated environment); the malware resides(/confined) somewhere in that process tree. Once the container is destroyed, ie the process tree killed, the malware is killed too from within.. That simple!
2- The Docker Container Creation Part:
Unfortunately this part is all wrong!.. And I don't recommend using it at all!.. Nothing in it makes sense as far as Docker container best practices go.
The example above download a Docker Debian-latest image and runs it on the fly in interactive mode to gain access to the shell from which it ask you to follow @Mashiro's tutorial!!..
Well, GoodBye the minimal container part that the Docker container definition is based on.
Even more, goodbye the ephemeral and stateless argument that the whole OP is based on (re-read section 1 about the CVE stuff and spinning up containers at will.) If each time we want to recreate our container after a malware infection we have to go through the whole @Mashiro's tutorial again!!!.. I would say that we didn't gain anything in this process, we just added the extra Docker part to the @Mashiro's already lenghty tutorial!..
Remember, we've said that:
> Docker containers are "ephemeral, stateless, minimal containers that won’t typically get upgraded or re-configured but instead just be replaced entirely.”
So, what's the solution?.. If we really want to do what the OP suggested, then we need to use a system container (like LX D/LXC containers) not an application container like Docker containers.
But if we still want to stick with Docker, then we need to create 2 Docker images: one for a database, ie MySQL/MariaDB, and one for the Nginx/PHP+WP or Apache/PHP+WP.
Both type of images are already available online but I will advice people to create their own Docker images by familiarizing themselves with Dockerfiles (pretty easy to pick up on.)
That should be all till Post_2.
Here I won't go back to my previous principled objection (done elsewhere on this board) of using Docker inside a KVM VPS and just go along the assumption that the resources are good enough to get everything run smoothly.
Okay, now, for the OP's review. I understand that it wasn't planned to be a stand-alone topic from its intro. but still the whole OP fails on so many points that I can't just let it pass un-annotated--at least not under my watch :-)
1- The Why Docker Container Part:
(05-23-2021, 11:58 AM)LightDestory Wrote: So, on @Mashiro topic about setting up a WP from scratch I wrote a simple command-list to create a container... Why? I think that nowadays it is important to isolate any application because there could be any CVE that can hurt our precious VPS!
BEWARE: CONTAINERS ARE NOT A SECURITY TOOLS. YOU MUST SECURE YOURSELF CONFIGURING A STRONG PROTECTION AGAIN ATTACKS
So, why create a container?
Let's imagine that we were running a Laravel WebApplication and someone used the latest known CVE to inject on our machine a cryptominer know as kdevtmpfsi . The cryptominer is a cron-job script that check if the miner process is running, if not it will download the binaries and run it. If you kill it... it will just respawn.
To get rid of the cryptominer you must FIND the faulty cronjob and delete it. Then you can hope that by deleting the binaries it will not respawn. I got a personal experience with such miner and it was a pain. My friend application was running on barehardware and the miner got injected into the main system...
If the application were running inside a container the solution could be very fast: just destroy and recreate the container! I mean, we were still vulnerable but the recovery process was much faster, as I have already said: containers aren't security tools!
From the above we deduce that the main incentive in using Docker containers here is the isolated, ephemeral and statelessness of the Docker container that makes it disposable, i.e. just throw the container away and spin up another one.
Nothing wrong there, in fact, it's perfectly what Docker containers are designed for:
> Docker containers are "ephemeral, stateless, minimal containers that won’t typically get upgraded or re-configured but instead just be replaced entirely.”
Although I did sense a bit of confusion in this part of the last paragraph:
(05-23-2021, 11:58 AM)LightDestory Wrote: If the application were running inside a container the solution could be very fast: just destroy and recreate the container! I mean, we were still vulnerable but the recovery process was much faster, as I have already said: containers aren't security tools!
It might be due to a lack of a clear view of what a container is really all about?!.. A container can be mentally viewed as a process tree running inside its own namespace (hence the isolated environment); the malware resides(/confined) somewhere in that process tree. Once the container is destroyed, ie the process tree killed, the malware is killed too from within.. That simple!
2- The Docker Container Creation Part:
(05-23-2021, 11:58 AM)LightDestory Wrote: Now, for example we want to run WP from scratch but inside a container? How can do such a complex thinh? Don't worry... using a container is easy as using a normal terminal connection :)
A basic way to create a basic container ready for any usage is:
(.................)Code: (Select All)docker run -it -d --name debian -p 9090:80 debian:latest
Now, inside the container shell you can just follow @Mashiro tutorial 1:1 with commands, there is no differences!
Unfortunately this part is all wrong!.. And I don't recommend using it at all!.. Nothing in it makes sense as far as Docker container best practices go.
The example above download a Docker Debian-latest image and runs it on the fly in interactive mode to gain access to the shell from which it ask you to follow @Mashiro's tutorial!!..
Well, GoodBye the minimal container part that the Docker container definition is based on.
Even more, goodbye the ephemeral and stateless argument that the whole OP is based on (re-read section 1 about the CVE stuff and spinning up containers at will.) If each time we want to recreate our container after a malware infection we have to go through the whole @Mashiro's tutorial again!!!.. I would say that we didn't gain anything in this process, we just added the extra Docker part to the @Mashiro's already lenghty tutorial!..
Remember, we've said that:
> Docker containers are "ephemeral, stateless, minimal containers that won’t typically get upgraded or re-configured but instead just be replaced entirely.”
So, what's the solution?.. If we really want to do what the OP suggested, then we need to use a system container (like LX D/LXC containers) not an application container like Docker containers.
But if we still want to stick with Docker, then we need to create 2 Docker images: one for a database, ie MySQL/MariaDB, and one for the Nginx/PHP+WP or Apache/PHP+WP.
Both type of images are already available online but I will advice people to create their own Docker images by familiarizing themselves with Dockerfiles (pretty easy to pick up on.)
That should be all till Post_2.
