Server

아파치 보안 설정

LimeLee 2018. 4. 11. 09:55

1. 서버 정보 숨기기

2. 디렉토리 인덱싱 차단

3. 심볼릭 링크 차단

4. 웹 서버 프로세스 권한 제한

5. HTTP Method 제한

6. 에러페이지 설정

7. SSL 프로토콜 및 알고리즘 설정

8. http 접속 시 https 리다이렉트(RewriteEngine)

9. 특정 디렉터리 내 파일 실행 차단

* 앞으로 시간나면 추가할 예정

 

 

1. 서버 정보 숨기기


 

웹 페이지의 헤더와 404 에러페이지에서 서버에서 사용하고 있는 우분투 버전/ OS 정보가 노출되었다.
1-Day공격으로 이어질 수 있기 때문에 보안 상 당연히 이런 서버 정보가 노출되는 것을 차단하게 권장하고 있다.

 

버전정보 노출 여부를 설정하는 파일의 위치는 OS별로 아래와 같다.

 

우분투 : /etc/apache2/conf-available/security.conf

CentOS : /etc/httpd/conf/httpd.conf

 

설치한 버전, 방법, OS에 따라 경로는 조금씩 달라질 수 있다.

명시한 경로에 없을 경우, find 또는 grep을 이용하여 본인 서버에 맞는 설정파일 경로를 찾는 것을 추천.

 

설정파일 내 ServerTokens 를 수정한다.

ServerTokens 설정은 HTTP response의 HTTP Header에 노출되는 서버 정보를 얼마나 보여줄 것인가를 설정할 수 있다.

설정 값은 Full, OS, Minimal, Minor, Major, Prod 이 있다.

 

Full Apache/2.4.18 (Ubuntu) / PHP ...
 OS Apache/2.4.18 (Ubuntu)
 Min Apache/2.4.18
 Minor Apache/2.4
 Major Apache/2
 Prod Apache

 

아파치를 재시작 하고 다시 서버에 요청을 날리면 버전 정보를 노출하지 않는 것을 확인할 수 있다.

 

 

 

 

2. 디렉토리 인덱싱 차단


 

디렉토리 인덱싱은 OWASP 2017에서도 5위를 할 정도로 높으며, 해커의 입장에선 쉽게 공격할 수 있으면서 악용 가능성은 높은 공격이다.

방어 역시 쉬우므로 꼭 해두는 것이 좋다.

 

 

설정을 제대로 해두지 않으면 인덱싱 기능을 활성화한 디렉토리로 접근했을 때, 디렉토리 내에 있는 모든 파일과 디렉토리를 열람할 수 있다.

해당 페이지에서 파일로 접근할 수도 있고 하위 디렉토리, 상위 디렉토리로도 접근할 수 있다.

 

 

인덱싱 기능은 아래의 설정 파일에서 수정 가능하다

/etc/apache2/apache2.conf

설정 파일 내 인덱싱 기능을 비활성화활 디렉터리의 Options 부분에 있는 Indexes를 제거한다.

 

 

이후 /var/www/와 하위 디렉터리는 디렉토리 인덱싱을 시도할 시 403 에러를 출력한다.

 

 

 


apache 기본 설정일 경우, 심볼릭 링크에 보안상으로 취약할 수 있다.

 

예를 들어, 위처럼 웹 루트에 루트로 연결되는 심볼릭 링크가 있다고 하자.

 

 

웹 사용자는 웹 루트에서 root 라는 디렉터리로 이동할 시, 해당 서버의 /(루트) 디렉터리를 열람할 수 있게 된다.

 

2번에서 인덱싱 설정을 하였으면, 심볼릭 링크를 이용하여 /(루트) 디렉터리에 접근하였더라도 Forbidden 페이지가 뜨지만 루트 디렉터리의 열람권한만 없는 것이지 루트 디렉토리 내 파일을 못 접근하는 것은 아니다.

 

그래서 열람 권한만 있고 루트 디렉토리에서 열람하고자 하는 파일의 위치가 어디인지만 알면 파일을 열어볼 수 있다.

 

 

심볼릭 링크 설정은 인덱싱과 동일한 설정파일에서 수정 가능하다

/etc/apache2/apache2.conf

웹루트 설정의 FollowSymLinks 옵션을 지워주면 된다.

웹 루트 위의 심볼릭 링크가 허용되면 안되는 것이기 때문에, 서버 루트가 아닌 웹 루트의 FollowSymLinks 옵션을 지워줘야한다.

만약 Options의 옵션을 지우다 허용한 옵션이 없으면 None 을 쓰면 된다.

 

 

FollowSymLinks의 옵션을 지우고 apache2를 재시작하면 다음과 같이 심볼릭 링크로 서버 루트 위의 파일을 열람할 수 없게 된다.

 

 

4. 웹 서버 프로세스 권한 제한


 

Web 서버 데몬이 root 권한으로 실행될 경우, 웹 어플리케이션 취약점 등으로 root 권한을 취득하게 될 수 있다.

최근엔 패키지 설치로도 웹 데몬 사용자가 따로 생성되지만 웹 서버 프로세스 사용자 권한이 root 일 경우, 변경해주어야 한다.

 

 

웹 서버 데몬을 실행할 사용자를 만들어 준다.

해당 사용자는 쉘 권한이 필요 없으므로, 불필요한 쉘 권한을 주지 않기 위해  -s 옵션을 사용한다.

$useradd -s /sbin/nologin 사용자명

이렇게 생성된 사용자는 SSH로 접속할 수 없고, FTP 접속만 가능해진다.

 

/etc/apache2/apache2.conf

/etc/httpd/conf/httpd.conf

설정 파일에서 해당 라인을 위에 만든 쉘 권한이 주어지지 않은 사용자로 설정한다.

www-data권한으로 실행하고 싶다면

User www-data

으로 바꾸어준다.

 

 

아파치를 재시작하면, www-data 권한으로 웹 데몬이 실행된다. 

 

 

5. HTTP Method 제한


HTTP Method에는 여러가지 종류가 존재한다.

서버 정보를 알 수 있는 HEAD, 서버에서 지원하는 메소드를 확인할 수 있는 OPTION 등 있지만 

GET, POST를 제외한 Method는 웹 서버에서 사용할 수 없게 제한을 두는 것이 좋다.

 

 

설정은 /etc/apache2/apache2.conf 에서 할 수 있다.

Limit 옵션은 해당 메소드에 대한 설정이고

LimitExcept는 해당 메소드를 제외한 메소드에 대한 설정이다.

위 설정 같은 경우, GET POST 메소드는 허용하고 GET POST 외의 메소드는 거부하는 설정이다.

 

 

해당 설정을 한 뒤, 아파치를 재시작하여 GET 메소드로 요청을 한다.

 

 

제대로 설정이 되었다면, GET POST 메소드에 한해서는 응답코드 200를 리턴한다.

 

 

 

GET POST 이외의 메소드를 요청하면 403 Forbidden 응답코드를 반환한다.

 

 

6. 에러페이지 설정


 

 

없는 파일 혹은 권한이 없는 디렉터리를 열람했을 때, 뜨는 404 에러와 403 에러 코드이다.

이런 에러 코드와 에러 페이지에 있는 내용은 공격자에게 서버에 대한 정보를 제공하고 2차적인 공격을 할 수 있게 해주는 정보가 된다.

404, 403 에러로 예를 들어, 있을만한 디렉터리/파일 명을 겟싱하여 403 혹은 200이 뜨면 있는 디렉토리/파일이고, 

404가 뜨면 없는 디렉토리나 파일로 유추할 수 있게 된다. 

 

이런 에러 페이지가 노출되는 것은 한국인터넷진흥원에서 제공하는 보안가이드에도 있는 사항이므로 이에 대한 보안 설정을 해두는 것이 좋다.

 

 

우분투: /etc/apache2/sites-available/default-ssl.conf

CentOS: /etc/httpd/conf/httpd.conf 

 

위 설정파일에서 ErrorDocument 옵션을 추가해준다.

 

리다이렉트 될 에러 페이지는 웹 루트를 기준으로 한다. 

 

 

제대로 설정하였다면 커스텀 에러 페이지로 리다이렉트 된 것을 확인 할 수 있다.

ErrorDocument 옵션으로 지정해 준 에러 페이지는 에러코드를 출력하지 않아야 하고, 또한 에러 페이지 간의 다른 점을 보고 어느 에러코드에 대한 에러 페이지인지 유추할 수 없어야 한다.

 

 

경로를 잘못 설정하였거나, 혹은 파일이 없을 경우 기존 404 페이지 밑에 ErrorDocument 옵션에 대한 에러도 같이 출력해준다.

 

+

 

 

위에서 설정한 것으로만 끝내게되면 같은 에러페이지를 띄우지만 응답코드는 바뀌지 않는다.

403, 404 에러가 발생할 경우 커스텀 페이지를 띄워주긴하나 403, 404에러를 출력하지 않지는 않기때문에 에러페이지를 보지않아도 유추가 가능해진다.

 

첫번 째 방법으로 302 리다이렉션을 사용한다.

https://ameblo.jp/itboy/entry-11364873019.html

ErrorDocument에 http(s)://를 붙이게 되면 같은 서버 내의 문서라도 리다이렉션을 한다.

403, 404 에러코드가 발생하면 302 리다이렉션을 해서 404.html을 호출하게 된다.

 

403, 404에러코드 둘다 커스텀 에러페이지로 리다이렉트(302) > 커스텀 에러페이지를 정상적으로 호출(200) 로 보여진다.

 

++

 

두번째 방법은 서버 설정은 아니지만 PHP로 운영하고 있다면 커스텀 헤더를 추가하여 응답코드를 404로 보이게 하는 방법도 있다.

https://stackoverflow.com/questions/1486304/is-there-a-way-to-force-apache-to-return-404-instead-of-403

 

커스텀 에러페이지에 다음과 같은 값을 추가한다.

 

이렇게 보여진다.

 

 

7. SSL 프로토콜 및 알고리즘 설정


전자금융거래법에서 정의한 "전자금융기반시설"에 해당하는 서비스는 취약한 HTTPS 프로토콜 및 암호 알고리즘 사용 여부가 평가 기준에 들어가고 KISA에서 배포한 주요정보통신기반시설 기술적 취약점 분석 가이드에서도 취약한 버전의 프로토콜 사용 여부를 점검하므로 조치를 해두는 것이 좋다.

 

취약한 프로토콜 및 알고리즘을 사용 중일 경우 데이터 패킷을 해독해 중요 정보를 탈취할 수 있다.

 

KISA에서 배포한 가이드(21.04)에서는 SSLv2, SSLv3 사용 여부만 점검하고 TLSv1.2만을 사용할 것을 권고하고 있는데, 구글 Chrome 81버전에서는 21.03 업데이트로 이미 TLSv1, TLSv1.1을 지원하지 않으므로 이번 게시글은 TLSv1.2만 사용하도록 설정할 것이다.

 

개인서버를 ssllab에 돌렸더니 TLS 1.0, TLS 1.1 그리고 약한 강도의 알고리즘을 사용 중임을 확인했다.

 

아래의 설정파일에서 서버에서 사용할 프로토콜, 알고리즘을 설정할 수 있다.

 

우분투: /etc/apache2/sites-available/default-ssl.conf

CentOS: /etc/httpd/conf/httpd-ssl.conf

 

 

SSLProtocol -all +TLSv1.2
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256

 

모든 프로토콜을 사용하지 않고 TLSv1.2만 허용하며 위 2개의 암호 알고리즘만을 허용한다.

 

ssllab은 IANA 표현방식을 사용하므로 아래의 사이트를 참조하여 추가할 알고리즘을 확인한다.

 

SSLCipherSuite List

https://www.openssl.org/docs/man1.0.2/man1/ciphers.html

https://testssl.sh/openssl-iana.mapping.html

 

설정 후 아파치를 재시작한다.

 

설정 후 개인서버의 SSL 설정 결과

 

 

높은 수준의 알고리즘만 지원할 경우 일부 환경에서는 접속이 불가능 할 수 있다.

개인서버라 일부 환경의 사용자들을 크게 고려 할 필요가 없지만 그렇지 않은 경우 호환성과 환경을 고려해서 설정해 줄 필요가 있다.

 

 

8. http 접속 시 https 리다이렉트(RewriteEngine)


 

http와 https를 혼용하다보면 waf 등 보안 장비들의 웹 보안 정책을 http또는 https중 하나에만 적용해 공격자들이 정책이 적용 안 된 http(s)에 접근하여 보안 장비를 우회하는 케이스가 존재한다.
http를 사용해야만 하는 불가피한 상황이라면 모르겠지만 http와 https의 서버 응답이 동일한 경우 혼용할 필요 없이 http접근을 https로 강제로 리다이렉트 시키면 관리해야할 보안 정책이 기존보단 줄어들기에 관리하기 용이해진다.

 

apache에선 RewriteEngine을 지원하므로 이를 이용한다.

 

쉘에서


a2enmod rewrite
a2enmod ssl


를 입력하여 RewriteEngine을 활성화한다.

RewriteEngine을 활성화했다면 http로 접근 시 https로 리다이렉트 시키는 설정을 추가한다.

설정파일은 아래와 같다.
우분투: /etc/apache2/sites-available/default-ssl.conf
CentOS: /etc/httpd/conf/httpd.conf

<VirtualHost *:80>
DocumentRoot /var/www/html/

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</VirtualHost>


아파치 재 실행 후 http로 접근 시 https로 리다이렉트 되는 것을 확인 가능함.

 

 

9. 특정 디렉터리 내 파일 실행 차단


업로드 기능을 제공해주는 서비스에 웹쉘을 업로드하여 서버를 장악하는 경우가 존재한다.

파일의 확장자 등을 서버 측에서 검증하여 악의적인 파일이 업로드 되지 못하도록 해야하지만 만약에 업로드되었을 경우 웹쉘 등의 파일이 실행되지 못하도록 설정해 큰 피해를 방지할 수 있다.

 

서버 언어로 PHP를 사용하는 경우

/files/라는 업로드 디렉터리가 존재하고 해당 디렉터리에 업로드 된 PHP 파일에 접근 시 파일이 실행되는 것을 확인 가능하다. /files/라는 디렉터리에 PHP 파일 실행을 차단하고 싶다.

 

아래의 설정 파일에서 다음과 같이 수정해주도록 한다.

 

우분투: /etc/apache2/apache2.conf

CentOS: /etc/httpd/conf/httpd.conf

 

<Directory /var/www/html/files>
	php_admin_flag engine off
</Directory>

 

 

AllowOverride all, Options +Indexes +FollowSymLinks는 해당 서버의 일부 기능 동작을 위해 허용된 옵션으로 자신의 서버에 필요하지 않을 경우 추가하지 않도록 한다.

 

설정 추가 후 서버 재시작 시 files/ 디렉터리와 그 하위의 디렉터리에서 PHP가 실행되지 않는 것을 확인 가능하다.

 

서버 언어로 PHP를 사용하지 않는 경우

 

서버 언어가 PHP가 아니거나 혹은 다른 클라이언트 언어가 동작하는 것도 방지하고 싶을 때는 위의 방법으로 방지할 수 없다.

files/ 디렉터리에 업로드 된 test.html 파일에 접근하면 javascript 언어가 실행되는 것을 확인할 수 있다.

 

설정 파일에서 다음과 같이 수정해주도록 한다.

 

# Apache 2.4
<Directory /var/www/html/files>
	ForceType application/octet-stream
</Directory>

# Apache 2.2
<Directory /var/www/html/files>
	DefaultType application/octet-stream
</Directory>

 

 

아파치를 재시작하면 files/ 하위의 파일을 접근했을 때 Content-Type이 application/octet-stream으로 변경되며 실행되지 않고 다운로드된다.