보안 취약점 진단 및 조치
KISA에서 제공한 2024 클라우드 진단 가이드 기반
- 1. 웹 서비스 영역의 분리
- 2. 불필요한 파일 제거
- 3. 링크 사용 금지
- 4. 파일 업로드 및 다운로드 제한
- 5. 디렉터리 리스팅 제거
- 6. 웹 프로세스 권한 제한
- 7. 최신 보안 패치 적용
- 외전. 버전정보 숨김 처리
1. 웹 서비스 영역의 분리
취약점 설명
Apache 설치시 기본적으로 설치되는 경로가 있다.
/var/www/html
공격자가 대상의 웹서버가 Apache를 사용한다는걸 인지하고 있다면, 혹은 인지하지 못하더라도 우선적으로 확인하는 경로가 될 것 이다.
해당 기본 디랙터리를 DocumentRoot 라고 지칭하며, 디폴트 값이 아닌 수정된 경로로 DocumentRoot 를 변경하여 운영하고 있는지 확인하여야 한다.
딴소리
윈도우의 경우에는 경로뿐만 아니라 드라이브 자체를 구분짓는걸 권고하는듯 하다. (너무 FM인가..)
C 드라이브를 메인으로 쓰고 있다면, apache를 운영하는 디렉터리는 D,E,F 등 다른 드라이브에 설치
진단 방법
apache 환경 설정 파일을 cat으로 출력하되 grep 명령어로 DocumentRoot 문자열 필터링
Ubuntu / Debian 의 경우 /etc/apache2/ 경로에 존재하며
CentOS / RHEL / Fedora 계열의 경우 /etc/httpd/ 에 존재한다.
진단은 Ubuntu 기준으로 진행한다.
/etc/apache2/sites-available/000-default.conf 파일이 기본적으로 웹 서비스에 적용되는 config 파일이며,
다른 conf 파일을 만들어 a2ensite 명령어를 통해 적용 시킬 수도 있다.
양호 취약 기준
위 진단 결과의 경우 DocumentRoot 가 기본디렉터리 (/var/www/html) 이므로 취약
기본 디렉터리와 다른 경로를 DocumentRoot로 지정하였을 경우 양호
참고
2. 불필요한 파일 제거
취약점 설명
어찌보면 당연한 이야기, 기본적으로 생성되는 메뉴얼 파일을 제거 및 테스트용으로 만들어둔 더미 파일들이 존재하지 않나 체크하면 된다.
딴소리
진단 스크립트의 경우 기본적으로 존재하는 매뉴얼 파일만 스캔 후 양호, 취약을 결정짓는 케이스와
파일명에 test가 들어있거나, 혹은 웹 서비스 디렉터리의 파일들을 나열하여 담당자에게 불필요 파일이 존재하는지 한번 더 인터뷰를 거치는 케이스
두가지가 존재하는 것 같다.
진단 방법
담당자와의 인터뷰를 통해 불필요 파일을 제거하고 있는지 확인
양호 취약 기준
주기적으로 불필요한 웹 서비스 파일을 제거 중이면 양호
기본적으로 존재하는 매뉴얼 파일 삭제가 되어 있지 않거나, 불필요한 테스트 파일등에 대한 관리가 이뤄지고 있지 않을 시 취약
참고
3. 링크 사용 금지
취약점 설명
심볼릭 링크는 윈도우의 바로가기 와 같은 맥락의 기능이다.
웹 서비스에선 기본적으로 DocumentRoot 디렉터리 보다 상위 디렉터리로 접근하는 것을 차단하는데,
심볼릭 링크 사용이 활성화되어 있을 경우, /etc/passwd 와 같은 민감 데이터에 접근이 가능하다.
딴소리
해당 취약점 시연 과정은 아래 링크를 참조
https://www.ochidstudy.com/books/apache/page/9c838
진단 방법
우분투 기준 /etc/apache2/apache2.conf 에서 FollowSymLinks 를 grep으로 필터링
양호 취약 기준
FollowSymLinks 설정이 없거나 앞에 - 가 붙을 경우 양호
(앞의 Indexes는 다음 취약점 시연을 위해 + 상태, 뒤의 Follow 부분에만 기호를 붙일 경우 오류가 발생하므로 앞에 + 혹은 -를 붙여줄것)
마지막 줄은 # 을 통해 주석처리되었으므로 해당사항 없음
FollowSymLink 에 - 설정이 존재하지 않을 경우 취약
참고
4. 파일 업로드 및 다운로드 제한
취약점 설명
업/다운로드 용량을 지정하지 않을 경우 악의적으로 대용량, 혹은 수많은 파일들을 업/다운로드 해 서비스 운영에 영향을 줄 수 있다.
딴소리
용량을 꼭 특정 값 이하로 지정해야하는건 아니다. 서비스 운영 상 필요한 만큼만 제한을 걸어 놓으면 된다.
용량제한이 30기가로 되어 있더라도, 서비스 운영상 해당 용량이 필요할 경우 양호가 될 수 있다.
용량제한 500기가와 용량제한 없음은 완전히 다르다.
진단 방법
apache2.conf 에서 LimitRequestBody 값을 grep으로 식별
cat /etc/apache2/apache2.conf | grep LimitRequestBody
양호 취약 기준
서비스 운영 상 필요한 용량제한을 설정하고 있을경우 양호
용량 제한을 설정하지 않았을 경우 취약
출력되는 값이 없을 경우 용량을 제한하고 있지 않으므로 취약
참고
5. 디렉터리 리스팅 제거
취약점 설명
디렉터리 리스팅의 경우 특정 파일이 아닌 디렉터리 경로로 진입했을 경우 해당 디렉터리의 파일들을 보여주는 설정이다.
(www.test.com/main.php 가 아닌 www.test.com/upload/ 같은 경로)
개발 환경에서는 사용하여 편의성을 높일 수 있겠지만 해당 설정이 운영 중에도 활성화 되어 있을 경우 굉장히 취약해진다.
딴소리
웬만하면 다들 막혀있지만, 정말 가끔 웹 모의해킹 시 보이는 경우가 있다.
진단 방법
apache2 conf 파일에 Indexes 옵션이 활성화 되어 있는지 확인
cat /etc/apache2/apache2.conf | grep Indexes
양호 취약 기준
Indexes 값 앞에 - 기호가 붙어있거나, 값이 존재하지 않을 경우
Indexes 값을 삭제하여도 무관하나, 버전에 따라 기본값이 적용되 활성화가 될 수 있으므로 - 기호로 명시함을 권고
Indexes 값 앞에 - 기호가 존재하지 않거나 + 상태일 경우 취약
참고
6. 웹 프로세스 권한 제한
취약점 설명
apache 서버 데몬이 root 권한으로 운영될 경우 불필요하게 과도한 권한을 가지고 있으며, 다른 취약점들을 통해 root 권한을 획득 할 수 있으므로
별도 계정을 사용한다.
기본적으로 www-data 계정을 사용한다.
진단 방법
아래 명령어를 통해 apache2가 어떤 계정으로 실행되는지 확인
ps-ef | grep apache2 딴소리
진단 시 아래와 같은 프로세스들이 나열된다.
맨위의 프로세스가 root로 실행되고 있으니 취약인가? 라고 생각할 수 있지만
웹 서비스의 통신을 담당하는 자식 프로세스들을 관리하는 마스터 프로세스이며, 마스터 프로세스는 시스템 포트를 점유하고, 설정 파일을 읽으며, 로그 파일을 열어야 하기 때문에 root 권한이 필요하다.
웹 서비스 요청을 처리하는 작업자는 밑의 자식 프로세스 들이며 마스터프로세스의 PID(2525) 값을 포함하고 있는것을 위에서 확인할 수 있다.
양호 취약 기준
마스터 프로세스를 제외, 자식 프로세스들이 root가 아닌 계정으로 실행되고 있을 경우 양호
자식 프로세스들이 root 계정으로 실행되고 있을 경우 취약
참고
apache2.conf 파일 이 존재하는 경로의 envvars 파일을 확인하면 어떤 계정으로 아파치가 구동이 될지 설정값이 존재한다.
보안 조치가 필요할 경우 해당 값을 변경해주면 된다.
7. 최신 보안 패치 적용
취약점 설명
대부분의 서비스 진단 시 포함되어 있는 항목이다.
EOS 날짜를 확인 후 보안패치가 진행되고 있는 버전을 사용 중인지 확인한다.
진단 방법
아래 명령어를 사용하여 버전 정보 확인
apache2 -vEOS 확인 사이트에서 apache2의 EOS 날짜 확인
양호 취약 기준
apache의 버전이 보안 패치(Security Support)를 지원할 경우 양호
2.4 뒤의 52 같은 값들은 안봐도 된다. 앞의 2.4, 2.2 등 버전을 구분하는 큰 분류만 확인하면 됨
참고
외전. 버전정보 숨김 처리
취약점 설명
웹서비스를 운영할 경우 존재하지 않는 디렉터리, 파일 등에 접근하게 되면 Not Found 페이지가 출력된다.
별도의 설정이 없을 경우 Apache의 버전정보가 출력되므로 수정이 필요하다.
딴소리
아니 이거 왜 진단 가이드에 없지;
웹 모의해킹 절차에 있어서 그냥 스킵했나..?
진단 방법
apache2/conf-available 경로의 security.conf 파일을 확인하여 아래 두가지 항목의 활성화 여부 확인
양호 취약 기준
ServerToken OS (취약)
ServerToken Prod (양호)
ServerSignature On (취약)
ServerSignature Off (양호)
참고
조치 후 오류페이지 접근 시
가이드 상은 이정도 조치를 권고하지만, 401, 403, 404 등 통신 오류의 종류를 보여주는 것도 공격자에게 힌트가 될 수 있으므로
하나의 오류페이지를 제작하여 일괄적으로 사용하는 것을 권고한다.