1. 도커의 개요
1.1 도커의 정의와 구조
도커(Docker)는 컨테이너 기술을 지원하는 프로젝트 중 하나로써 리눅스 컨테이너에 리눅스 어플리케이션을
프로세스 격리기술을 사용하여 더 쉽게 컨테이너로 실행하고 관리할 수 있게 해주는 오픈소스 프로젝트다.
도커를 사용하는 이유는 다양한 프로그램, 실행환경을 컨테이너로 추상화하고 동일한 인터페이스를 제공하여
프로그램의 배포 및 관리를 단순하게 해주며, 개별 소프트웨어의 실행에 필요한 실행환경을
독립적으로 운용할 수 있도록 다른 실행환경과의 간섭을 막고 실행의 독립성을 확보해주기 때문이다.
가상화 기술인 가상머신은 하이퍼바이저(Hypervisor)를 이용해
여러 개의 운영체제를 하나의 호스트에서 생성하는 방식이다.
가상머신의 문제점은 각종 시스템 자원을 가상화하고 독립된 공간을 생성하려면
반드시 하이퍼바이저(Hypervisor)를 거쳐야 하기 때문에 일반 호스트에 비해 성능 손실이 발생한다.
또한, 가상머신은 Guest OS를 사용하기 위한 라이브러리와 커널을 포함하기 때문에 배포할 때 용량이 커지게 되어
성능 손실이 발생하고 효율성이 떨어지지만 도커 컨테이너는 이러한 가상머신의 문제점을 해결한다.
도커 컨테이너는 가상화 된 공간을 생성할 때 리눅스 자체 기능인
네임 스페이스(name space)와 컨트롤 그룹(control group)을 사용한다.
- 네임 스페이스: 프로세스를 독립시켜주는 가상화 기술
각 컨테이너에서 실행된 프로세스가 시스템에 대해 독립할 수 있도록 구성해줌.
- 컨트롤 그룹: 자원에 대한 제어를 가능하게 해주는 리눅스 커널 기능
도커 컨테이너는 해당 기술들을 통해 프로세스 단위로 격리 환경을 만들어 성능 손실을 최소화하고
가상머신과 달리 커널을 공유하기 때문에 가상머신과 비교하여 용량이 작다는 장점을 가진다.
따라서 컨테이너를 이미지로 제작하게 되면 배포하는 시간이 빠르고 성능 손실도 거의 없기 때문에
가상머신과 비교했을 때 효율성과 가용성이 뛰어나다.
1.2 모놀로식 아키텍처 vs 마이크로 서비스 아키텍처
클라우드와 컨테이너 기술이 도입되면서 소프트웨어 개발방식이 모놀로식(monolithic) 아키텍처에서
마이크로 서비스(micro service) 아키텍처로 변화되었다.
도커 컨테이너를 사용하게 된 이유도 이러한 소프트웨어 개발방식의 변화 때문이다.
전통적인 개발방식인 모놀로식 아키텍처는 소프트웨어 개발을 위한 기본 접근 방식으로
하나의 어플리케이션에서 모든 서비스를 단일 코드 베이스로 작성하고 단일 데이터베이스에 연결하는 방식이다.
모놀로식 아키텍처는 단순하면서 배포하기 간편하지만 규모가 커지면 유지보수가 어렵고 확장성이 좋지 않아
웹 서비스 배포에 있어 큰 단점으로 지목된다. 이런 문제를 해결하기 위해 나온 개발 방식이 마이크로 서비스 아키텍처다.
마이크로 서비스 아키텍처는 어플리케이션을 작은 서비스로 분할하고, 각 서비스가 서로 독립적으로 동작하기 때문에
각 서비스들은 고유한 데이터베이스를 소유할 수 있고 독립적인 배포가 가능하며 유연한 확장성을 확보할 수 있다.
1.3 도커 컨테이너 life cycle
도커 컨테이너에서 이미지를 사용하기 위해서는 도커 레지스트리를 통해 이미지를 가져와야 한다(PULL).
도커 레지스트리는 데이터베이스를 통해 이미지를 제공하는 저장소로 누구나 이미지를 다운로드 받거나
새롭게 제작하여 업로드할 수 있는 공간이다.
컨테이너 제작을 하기 위해 가져온 이미지로 컨테이너를 제작하고(CREATE), 컨테이너를 실행할 수 있다(RUN).
그리고 컨테이너를 실행(START)시키거나 정지(STOP)시켜 컨테이너의 시작과 종료를 제어할 수 있다.
1.4 도커 실습 환경 구축
도커 환경을 설치하기 위해 우선 apt(Advance Packaging Tools) update을 실행한다.
| apt update 우분투에서 설치 가능한 패키지 리스트를 최신화하기 위한 명령어 apt install 우분투에서 패키지 설치할 때 사용하는 명령어 |
apt update가 완료되었으면 apt install docker.io 명령어로 도커를 설치한다.
| docker -v 현재 설치된 도커의 버전을 확인하는 명령어 docker info 도커에 설치된 컨테이너 및 이미지와 내부 정보들을 확인하는 명령어 |
도커가 설치 완료되면 docker –help를 통해 도커 운영에 필요한 명령어를 찾아볼 수 있다.
2. 도커 이미지 및 로그 관리
2.1 도커 이미지 생성과 컨테이너 관리
도커 설치 후 docker images 명령어로 이미지 목록을 docker search ~ 명령어로 확인한다.
특정 OS나 플랫폼, WAS 서버 이름을 대상으로 검색 시 다양한 이미지들이 나온다.
| docker pull nginx repository에서 nginx 이미지 다운로드 docker run -itd -p 80:80 –name=web_test1 nginx kali linux의 80 port와 nginx의 80 port를 port forwarding하고 container의 이름은 web-test1로 설정한다 |
nginx를 docker pull nginx 명령어로 도커 repository에서 다운로드 받으면 docker images 명령어로
정상적으로 다운로드 되었는지 확인할 수 있다.
그리고 docker run -itd -p 80:80 –name=web_test1 nginx 명령어로 프로세스인 도커 컨테이너를 생성한다.
도커가 생성되면 kali Linux에 설치된 도커는 172.17.0.1/24 IP주소를 할당받게 되고
도커 내부에 생성된 컨테이너들은 172.17.0.~/24 대역 내의 IP 주소를 할당 받는다.
위에 설정한 VM 설정 과정과 kali linux 도커 컨테이너 구성도를 다음과 같이 표현할 수 있을 것 같다.
단순한 CVE 테스트를 위해 docker 이미지를 다운로드 후 실행할 수 있으며
하단의 표와 그림은 CVE-2024-23897테스트를 위해 설정한 docker 명령어와 실행결과이다.
| docker pull jenkins/jenkins:2.440-jdk17 docker image ls docker run -p 8080:8080 jenkins/jenkins:2.440-jdk17 docker ps ls |
2.2 도커 볼륨 생성 및 관리
도커 이미지로 컨테이너를 생성하면 컨테이너에서 활동한 내역들은 이미지 layer 위에 컨테이너 layer에 기록된다.
다만, 도커 이미지로 컨테이너를 생성했을 때 컨테이너를 삭제하면
컨테이너 안에 있는 데이터도 같이 삭제된다는 단점이 있다.
이런 경우 데이터 복구가 불가능하기 때문에 데이터 손실을 막기 위해 도커 볼륨을 사용한다.
도커 볼륨을 생성하는 방법은 다음과 같다.
| docker volume create vol_test1: “vol_test1” 이름으로 볼륨을 생성한다. docker run -itd --name=webpage1 -p 85:80 -v vol_test1:/var/log nginx: 컨테이너 이름을 “webpage1”로 설정하고 -v option을 사용해서 사용할 볼륨(vol_test1)과 컨테이너(webpage1)와 공유할 디렉토리 위치(/var/log)를 설정하여 컨테이너를 실행한다. |
| docker inspect vol_test1: 생성된 “vol_test1” 볼륨의 정보를 확인한다. docker logs vol_test1: “vol_test1” 컨테이너에서 발생한 log 확인 |
vol_test1의 Mountpoint 경로로 이동하면 컨테이너에서 발생된 로그 목록들을 확인할 수 있다.
해당 경로에서 nginx 디렉토리로 이동하면 컨테이너의 web 로그가 저장되어 있다.
Web 로그는 access.log와 error.log 두 개의 로그 파일들이 저장되었지만
stdout(표준출력) 과 stderr(표준에러) 방식으로 로그를 추출하기 때문에 docker log명령어를 통해서만 확인할 수 있다.
2.3 도커 파일 활용
도커 파일은 도커에서 인프라 구성을 기술한 파일로써 이미지를 생성하기 위한 파일이다.
도커 이미지를 다운로드 받아서 사용하는 대신 개발자가 원하는 개발 환경을 만들기 위해 도커 파일을 구현한 후,
이미지에 도커 파일을 build하여 새로운 도커 이미지를 생성한다.
도커 파일은 특정 명령어들을 통해 구성되어 작동되고 밑의 표는 도커 파일을 작성할 때
도커 파일에서 사용하는 명령어 예시다.
| 명령어 | 용도 |
| FROM | Base image를 설정한다. 다운로드 받은 image를 지정하는 명령어 |
| RUN | Image를 build 할 때 사용하는 명령어 |
| CMD | Image 실행 시 명령어 지정 및 파라미터 설정 |
| EXPOSE | 컨테이너가 listening할 port 및 protocol 설정 |
| ENV | 환경 변수 설정 |
| COPY/ADD | Image의 file system으로 파일 또는 디렉토리를 복사 |
다음은 도커 파일을 활용하여 컨테이너를 생성하는 과정이다.
3. OWASP Juice Shop Docker install
3.1 Docker install & juice shop Execute
docker pull 명령어로 OWASP Juice Shop의 image를 가져온다.
이후 docker run 명령으로 해당 image를 실행시키면 아래의 그림 같이 컨테이너가 실행된 것을 볼 수 있다.
실행된 docker image를 통해 웹 진단 환경을 구성해본다.
로컬 PC에서 설치된 Burp suite로 http://127.0.0.1:3000 URL로 접근 시도해보자
위와 같이 접근 불가할 경우 docker 컨테이너를 중지 후 재시작해주면 된다.
이제부터 웹 취약점 진단 환경이 구축되었으니 문제풀이와 동시에
취약점 조치와 관련된 포스팅을 시작하자
'취약점 진단' 카테고리의 다른 글
| OWASP Juice Shop [SQL Injection] (0) | 2025.12.11 |
|---|---|
| OWASP Juice Shop Mass Assignment (0) | 2025.12.11 |
| OWASP Juice Shop [Redirect 취약점] (0) | 2025.12.11 |
| OWASP Juice Shop [정보누출 취약점] (0) | 2025.12.11 |