평범한 직장인의 메모장 :)

1. 보안 방안

2. 시연

1) 도커 컨테이너 내리기

# 컨테이너 ID 확인
docker ps

# 컨테이너 내림
docker kill [컨테이너 ID]

2) 도커 이미지 삭제

# 도커 이미지 확인
docker images

# 도커 이미지 삭제
docker rmi [이미지 ID] -f

3) 도커 파일 삭제

vulnerable.conf 파일 내부에 nginx 설정이 들어있으므로 이 부분을 수정한다.

위와 같이 /static을 /static/으로 바꾸고 저장한다.

4) 도커 컨테이너 다시 생성

docker build -t nginx-traversal .
docker run -d -p 127.0.0.1:3000:80 nginx-traversal:latest

5) 브라우저 테스트

1. 구성 환경

- VMware Player

- CentOS 7.8

- Docker

2. 구축

1) VMware에 CentOS를 설치 후 yum update까지 완료한다. (과정 생략)
2) 터미널에서 yum update까지 완료 후 아래와 같이 Docker 설치 수행

yum install docker
systemctl start docker
systemctl status docker

3) Github 샘플 가져오기

yum install git

# 취약점 샘플 GitHub 사이트
git clone https://github.com/tkmru/nginx-alias-traversal-sample

4) 기져온 Dockerfile 실행

cd nginx-alias-traversal-sample/
docker build -t nginx-traversal .
docker run -d -p 127.0.0.1:3000:80 nginx-traversal:latest

3. 시연

3000번 포트를 80번 포트로 연결하였으므로 localhost:3000으로 연결할 경우 위와 같은 페이지가 나타난다.

먼저 localhost:3000/static/welcome.txt에 접속할 경우, 환영한다는 텍스트 파일이 출력된다.
참고로 해당 샘플 테스트 사이트는 flag.txt를 여는 것이 목적이다.

물론, 바로 주소창에 입력해서 해당 경로로 접근하면 404 Not Found 에러가 출력된다.
존재하지 않는 파일이라는 것을 추측할 수 있다.

그렇다면 localhost:3000/static/welcome.txt에 다시 돌아간 뒤, localhost:3000/static../를 입력할 경우
403 Forbidden 에러가 출력된다.
여기서 우리는 폴더는 존재하나 직접적인 접근 권한이 나한테 없는 것을 추측할 수 있다.

flag 값이 떨어지는 것을 볼 수 있고, localhost:3000/static../flag.txt 요청 시 
localhost:3000/static/../flag.txt이 요청된 셈이고, 

잘못된 별칭(alias) 설정이 공격자가 Nginx가 지정한 대상 폴더 외부의 파일을 읽을 수 있게 할 수 있다는 것을 알 수 있다.

1. 발생한 배경

웹 서버 운영 시, 다수의 클라이언트들이 다양한 브라우저를 통해 접속을 하게 되는데 만약 큰 포털 사이트라면 엄청난 부하를 감당해야 한다. 이를 위해 등장한 것이 경량화 웹 서버라는 개념이며 Nginx는 그 중에 하나이다.

그럼 왜 앞에서 부하가 왜 많이 일어날까?

우선 Apache와 같은 웹 서버는 클라이언트로부터 받은 요청을 처리할 때 새로운 프로세스나 쓰레드를 생성하여 처리하는데, 사용자가 많아질수록 그만큼 대응하는 프로세스와 쓰레드도 많아지므로 CPU와 자원이 증가하게되기 때문이다.

2. Nginx 란?

3. Reverse Proxy Server ?

우선 포워드 프록시(Forward Proxy)와 리버스 프록시(Reverse Proxy) 차이부터 알면 이해가 쉽다.
또한, 우리가 흔히 말하는 프록시 서버는 포워드 프록시(Forward Proxy) 서버를 가르킨다.

지금까지 배워온 프록시 서버 즉, 클라이언트가 인터넷 웹 서버에 요청을 보내면 중간에서 포워드 프록시 서버가 요청을 가로채고 프록시 서버가 해당 요청을 웹 서버에 보내고, 응답을 받아와 다시 클라이언트에게 전달하는 방식이다.

아래 구성도를 보면 프록시 서버(포워드 프록시 서버)는 보통 클라이언트 앞쪽에 놓여져 있다.

이제 리버스 프록시 서버를 보면 포워드 프록시 서버와 반대로 웹 서버 앞에 위치하고 있다. 

4. Reverse Proxy Server를 사용하는 이유

1) 로드 밸런싱에 유리하다.

앞서 말했듯이 유명하거나 큰 포털 사이트는 수백 수천이 방문하는데 대량의 트래픽 부하를 감당해야하는데, 이를 하나의 서버가 감당하기란 어렵다. 리버스 프록시 서버를 여러대를 웹 서버 앞에 두면 특정 서버가 과부화 되는 것을 방지 할 수 있다.

2) 보안성 측면에서 좋다.

리버스 프록시 방식을 사용하면 웹 서버 자체의 IP를 노출 시킬 필요가 없으며, DDoS 공격과 같은 공격을 어느정도 방어할 수 있다.

3) 캐시 데이터 저장 기능으로 인한 성능 향상

자주 방문하는 사이트나 해외 사이트 등 매번 반복적으로 동일한 데이터를 요청할 필요 없이 캐싱된 데이터를 사용하면 되므로 성능적인 측면에서 좋다.

4) SSL 암호화에 용이하다.

원래 서버가 클라이언트들과 통신을 할 때 암호화 통신을 하는것을 당연하고, 이 과정에서 소모되는 비용은 상당하다. 그러나 리버스 프록시에는 이 과정이 모두 포함되어 있어 안전한 통신이 가능하다.

5. Forward Proxy 와 Reverse Proxy 차이

솔직히 위 도식도만 보면 크게 차이가 없어 보인다.

포워드 프록시(Forward Proxy)는 클라이언트의 입장에서 본인이 누구인지 웹 서버한테 숨기는 것에 중점을 두고 있고, 리버스 프록시(Reverse Proxy)는 다수의 클라이언트가 정체를 숨길 필요 없이 웹 서버를 방문할 경우 정확한 웹 서버의 위치나 정보를 숨기고, 성능 향상 등을 통해 부하를 줄여 웹 서버를 보호하는 것에 중점을 두고 있는 것 같다.

1. 개요

2. 용어

3. 보안 방법

    1) 크롬 상단의 설정으로 이동

    2) Chrome 정보 > 업데이트 수행 (스크린샷은 업데이트가 완료된 모습)

4. 공격 원리