Logging docker container logins, EC2 Host

Question

I have an AWS EC2 instance with docker installed, running a default nginx container - docker run -it --rm -d -p 8080:80 --name web nginx.

I have an rsyslog setup that successfully captures the auth.log file for the host, so I can capture any login attempts to that machine. However, I'm wondering if there is any way I can capture container login attempts, i.e if someone gains access to the machine and runs docker exec -it web bash.

While the container is running, docker logs outputs anything the container is logging to stdout/err. But I haven't found any documentation on container login attempts. Is docker exec the correct way to try "logging in" to the container? Is this something I can feasibly capture? Does it make sense to? When I run docker exec I haven't seen it logged anywhere - host syslog, kernel.log, auth.log, docker logs, nothing at all.

So, it doesn't seem like container "logins" are even captured anywhere, and as long as the container is not running with privileged access (as USER root), there is minimal risk. It seems that protecting the host is far more important.

More generally, if anyone is in the container poking around, running commands that require root etc., is this logged anywhere on the host? Or do I need to configure rsyslog in the container in order to capture such events.

Any insight would be greatly appreciated!

Answer 1

Well, that is difficult. If you "login" into a container (using docker exec) then technically you do not login into a container. You are simply opening a shell. Docker opens a window for you to enter commands and see their result. Then in the container you are usually able to run commands as the user which was chosen to run the application inside the container (the person who creates the image changes this usually from root to a user with less privileges).

Is docker exec the correct way to try "logging in" to the container?

If you really want to or have to run commands inside the container: Yes.

But this should not be a standard-task. This feature is good for debugging problems etc.. Images should be designed in a way that docker exec will be used rarely.

Is this something I can feasibly capture?

Probably not. (docker exec can only be executed by a user who has elevated privileges. When an attacker can do that, you have probably other/more problems. He could disable the "login-logs" or simply remove all logs.)

as long as the container is not running with privileged access I can't imagine it's too important.

Since we are here on security.stackexchange:

It is important to use a user inside the container who has as few rights as possible. Attacking your server is one common attack-vector. Exploiting the application which is running inside the container is another common attack-vector. If an attacker has an exploit for the application he can maybe running arbitrary commands in your container (without "login" into your container so you won't be able to log this in general to come back to your question). If an attacker can do this, you do not want that he can to anything. He will try to escape out of the container. So he should not be able to run any command who can help him. Even something like find, ls, gcc, echo "<malware>" > script.sh etc. should not be possible in the container for this reason. Hardening docker-images is quite important.

Answer 2

Yes! Use auditd on the host.

Docker containers are not VMs and you don’t log into them. You run commands in the context of the docker container (ie the commands you run think they are in a container but they are really running on the host OS).

If you want to monitor the commands run on the container you can the same way you monitor the commands run on the host - by monitoring syscalls.

Running ls fires syscalls with parameters. Your container probably executes some of those System calls with the same parameters over and over. A human would run different System calls.

For you to monitor your container, you would monitor the syscalls created by the container. Once its been running for a couple days you, should have a list of normal System calls.

If the container starts making new syscalls then you likely have a human using it. Alert on that. Using auditd you can trace the user who called docker exec. Auditd also uses syscalls so maybe that’s all that you need.

Check out this oreilly book:

containers run Linux processes that are visible from the host. A containerized process uses system calls and needs permissions and privileges in just the same way that a regular process does.