[Cloud] Docker 도커와 컨테이너

이번 포스팅에서는 도커와 컨테이너에 대해서 알아보겠습니다.

디도스를 쭉 보다가 조금 주제가 벗어나긴 했는데, 디도스가 실제 기업 특히 클라우드 환경을 사용하는 기업들에 어떻게 피해를 입힐까 생각을 해봤는데, 도커 컨테이너, 그리고 클라우드 환경의 네트워크 구성도를 이해할 수 있어야 할 것 같더라고요.

 

컨테이너 기술과 도커에 대해 조사하고, 도커와 같은 컨테이너 환경에서 발생할 수 있는 취약한 부분도 같이 살펴보면 좋을 것 같습니다.

 

 

도커는 아주 익숙한 툴입니다.

개발자들에게도 익숙할 거고, 보통 ctf풀면 도커로 이미지를 빌드하기도 하고, 워게임을 풀다보면 도커가 필수적으로 필요하기도 합니다.

저도 주기적으로 이미지를 지워도 문제 풀다보면 이미지들이 쌓입니다.

근데 조금 생각해보면 도커의 동작이 조금 신기하긴 합니다.

vmware같은 vm이랑 비슷하게 동작하는 것 같으면서도 훨씬 빠르고 가볍습니다.

이건 하드웨어와 소프트웨어를 이어주는 커널의 역할을 VM에서는 iso이미지파일로 구현하고, 하드웨어에 해당하는 부분들을 소프트웨어로 구성하기 때문에 그렇고, container는 host os의 커널을 이용하기에 그렇습니다.

버튼을 누르는것 만으로도 이미지를 키고 끄는게 쉽게 가능합니다/.

배포도 쉽게 가능한데, 

워게임 문제를 다운록드 받으면 도커파일이 주어지는 경우가 많습니다.

FROM ubuntu:18.04@sha256:ceed028aae0eac7db9dd33bd89c14d5a9991d73443b0de24ba0db250f47491d2

ENV user uaf_overwrite

ENV chall_port 7182

RUN apt-get update

RUN apt-get -y install socat

RUN adduser $user

ADD flag /home/$user/flag

ADD $user /home/$user/$user

RUN chown -R root:root /home/$user

RUN chown root:$user /home/$user/flag

RUN chown root:$user /home/$user/$user

RUN chmod 755 /home/$user/$user

RUN chmod 440 /home/$user/flag

WORKDIR /home/$user

USER $user

EXPOSE $chall_port

CMD while :; do socat -T 30 TCP-LISTEN:$chall_port,reuseaddr,fork EXEC:/home/$user/$user ; done

이건 위 uaf_overwrite에 해당하는 문제의 도커파일인데, 우분투 18.04 이미지를 사용하고,

ENV를 통해 환경 변수를 설정하고, socat설치 및 컨테이너 안으로 바이너리를 복사합니다.

그리고 바이너리에 권한을 주고, 7182번 포트로 연결을 받습니다.

 

또 생각해보면 신기한게, 도커에서 우분투를 다른 버전이어도 이미지만 다운로드 받으면 잘 돌아간단 말이죠

커널의 핵심 부분인 kernel space는 host pc걸 그대로 사용하고, user space에 해당하는 부분만 Ubuntu 18.04의 파일, 라이브러리를 사용합니다.

예를 들어 pwn문제의 glibc는 커널이 아니라 라이브러리에 포함되기 때문에, 이미지 파일만 바꿔도 정상적으로 동작이 되는 구조입니다.

 

Docker의 핵심 기술은 namespace입니다.

namespace는 리눅스에서 프로세스가 볼 수 있는 부분을 분리하는 기능입니다.

Docker 컨테이너가 도커 내부에서 독립된 서버처럼 보이는 이유는 namespace때문입니다.

대표적으로 다음과 같은 namespace가 있습니다.

1. PID namespace : 프로세스 PID 분리
2. Network namespace : 네트워크 공간 분리, 컨테이너마다 IP,포트,인터페이스를 다르게 가집니다. 여기서 라우팅은 Docker에서 담당해서 합니다.
3. Mount namespace :  프로세스에서 보이는 파일 시스템 구조를 다르게 만드는 기능입니다. 컨테이너 안에서 / 디렉토리를 보면 host의 /가 아닌 Docker이미지로 구성된 별도의 루트 파일 시스템이 보이는데, 이게 Mount namespace입니다.
4. UTS namespace
5. IPC namespace
6. User namespace

PID namespace를 보면 

docker이미지 내에서 ps aux를 보면 1번 PID에 dreamhack이 써져있고, python3 app.py를 볼 수 있습니다.

host pc에서 ps aux를 치면 1번은 /init이고 docker 관련되서는 209번 pid를 가지고 있습니다.

docker ps를 치면

다음과 같이 나옵니다.

이게 Docker Desktop + WSL 환경이라서 host -> docker engine이라 ps aux에서 바로 컨테이너가 나오진 않네요.

어쨌든 프로세스가 분리된다는게 특징입니다.

이게 가장 중요한 부분은 실행하는 프로세스마다 실행 환경을 독립시켜서 배포, 운영, 보안을 편하게 만든다는 것입니다.

저희가 ctf풀때 컨테이너를 사용하는 이유 중 가장 큰게 포너블문제에서의 libc라고 생각을 하는데, 예전에는 libc파일을 직접 줘서 이걸 링킹하고 하는 과정이 처음에 어려웠는데 현재는 도커파일 하나만 있어도 문제가 없습니다.

또 이제 배포부분에서도 이점이 많은데, Dockerfile 이미지와 소스코드만 깃허브에 올려서 받으면 그대로 같은 환경에서 실행됩니다.

또한 스케일링이 쉬워진다는 장점이 있는데, 트래픽이 늘면 같은 이미지를 기반으로 컨테이너를 여러개 띄울 수 있습니다.

나중에 다룰 쿠버네티스에서는 이걸 Pod이라는 개념으로 자동 조절할 수 있습니다.

 

두번째 핵심은 cgroups입니다.

cgoups은 리눅스에서 프로세스가 사용할 수 있는 자원을 제한, 관리하는 기능입니다.

컨테이너가 자원을 너무 소모하는걸 막지 못하는데 사용합니다.

--cpus나 --memory와 같은 옵션을 통해서 제안 가능합니다.

이런 기능이 별게 아니라고 느낄 수 있지만 이런 자원한도는 DoS와 이어질 수 있는 부분이기에 중요합니다.

 

이거를 첫 포스팅이니 가볍게 살펴보고 이것저것 자료조사를 하다보니 namespace나 cgroups으로 컨테이너를 직접 실습한 글들이 많더라고요. 다음 포스팅에서 이러한 부분들을 좀 딥하게 해볼 예정입니다.