태그 보관물: Apache

Apache

Apache Upgrade(2.2 -> 2.4)

댓글 남기기

개요

Apache 2.2에서 2.4로 업그레이드되면서 접근 제어(Policy), VirtualHost, CGI 모듈 설정 방식이 변경되었습니다. 기존 2.2 설정 파일을 그대로 사용하면 서비스 기동이 실패할 가능성이 높으므로 업그레이드 전 설정 파일 검토가 반드시 필요합니다. 주요 변경사항을 비교표와 예제 코드로 정리합니다.

아파치 2.2에서 2.4로 업그레이드 되면서 일부 설정 파일의 변화가 있었습니다. 내용을 간략히 정리해 보았습니다.

기존 2.2 설정을 유지한 상태로 서비스를 기동하게 되면 서비스 기동이 실패할 확률이 높으므로 설정 파일에 대한 검토가 선행 되어야 합니다.

업그레이드 전 설정 파일 검토 포인트

Apache 2.2에서 2.4로 업그레이드할 때 서비스 중단을 방지하려면 다음 세 가지를 사전에 점검해야 합니다.

첫째, 접근 제어(Policy) 지시자 변경입니다. 2.2에서 사용하던 Order allow,deny / Allow from all 방식은 2.4에서 Require all granted로 교체되었습니다. 기존 설정을 그대로 두면 403 Forbidden 또는 기동 실패가 발생합니다. 둘째, NameVirtualHost 지시자 제거입니다. 2.4에서는 NameVirtualHost *:80이 불필요하며 오히려 경고 메시지를 유발합니다. 셋째, mod_cgid 모듈 비활성화입니다. 2.4에서 CGI 기반 모듈 설정 방식이 변경되어 기존 LoadModule cgid_module 라인을 주석 처리해야 합니다.

설정 파일 수정 후 httpd -t(또는 apachectl configtest) 명령으로 문법 오류를 확인하고 서비스를 기동하면 예기치 않은 장애를 예방할 수 있습니다.

주요 설정 변경사항

주요 설정 차이는 아래와 같습니다.

Version 2.2
Policy Order allow,denyAllow from all
Vhosts NameVirtualHost *:80

<VirtualHost *:80>
    DocumentRoot “D:\webapp\testlocalhost”
    ServerName testlocalhost
    ServerAlias testlocalhost
    ErrorLog “logs/testlocalhost -error.log”
    CustomLog “logs/testlocalhost -access.log” common
</VirtualHost>
cgid_modules LoadModule cgid_module modules/mod_cgid.so
on httpd.conf
Version 2.4
Policy Require all granted
Vhosts <VirtualHost testlocalhost:80>
    DocumentRoot “D:\webapp\testlocalhost”
    ServerName testlocalhost
    ErrorLog “logs/testlocalhost -error.log”
    CustomLog “logs/testlocalhost -access.log” common
</VirtualHost>
cgid_modules 주석처리
on httpd.conf
refer(예시)
DocumentRoot /some/local/dir

<Directory /some/local/dir/>
   <RequireAll>
      Require all granted
      Include conf/IPList.conf
   </RequireAll>
</Directory>

#this will also work
<Location />
   <RequireAll>
      Require all granted
      Include conf/IPList.conf
   </RequireAll>
</Directory>
And inside conf/IPList.conf, you will have individual lines with entries like the following
conf/IPList.conf에 아래와 같이 개별 접근 제어할 IP 리스트를 파일로 보관할 수 있으며 2.2의 Allow 대신 Require를 사용하게 되었습니다.

Require not ip 10.10.1.23
Require not ip 192.168.22.199
Require not ip 10.20.70.100

그 외 변경사항은 Apache 공식 업그레이드 가이드에서 확인할 수 있습니다.

참고

참고 문서: Apache 공식 — 2.2에서 2.4로 업그레이드 가이드 · Apache mod_authz_host 공식 문서

Apache

웹 취약점 보완 기본 I

댓글 남기기

개요

Apache HTTPS 기본 설정 후 웹 취약점 보완을 위한 보안 헤더를 추가하면 보안 진단 도구의 등급을 F에서 A로 빠르게 개선할 수 있습니다. HSTS, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection 4가지 헤더 설정이 핵심입니다.

기본 SSL 상태 점검

아파치 설치 후 기본적인 SSL 설정만 적용한 상태에서 보안 등급을 점검하면 보안 헤더가 설정되지 않아 아래와 같이 낮은 등급이 표시됩니다.

기본 SSL 설정만 적용한 상태의 보안 점수 — F 등급
F Score에 좌절할 필요 없이 다음 단계로….

보안 헤더 추가 — httpd.conf 설정

httpd.conf(또는 ssl.conf)에 아래 4가지 보안 헤더를 추가합니다. mod_headers 모듈이 활성화되어 있어야 합니다.

# HSTS(Strict Transport Security) Config
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

# X Frame Options Config
Header always set X-Frame-Options "SAMEORIGIN"

# X Content Type Options Config
Header always set X-Content-Type-Options nosniff

# X XSS Protection Config
Header always set X-XSS-Protection "1; mode=block"

결과 확인

Apache를 재시작한 후 동일 도구로 재점검하면 HSTS, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection 항목이 모두 통과되어 A 등급으로 개선됩니다.

보안 헤더 적용 후 보안 점수 — A 등급 개선 결과
Strict Transport Security
X Content Type Options
X Frame Options
X XSS Protection
해결…
A Score….

각 보안 헤더 설명

  • HSTS (Strict-Transport-Security): 브라우저가 해당 도메인에 항상 HTTPS로만 접속하도록 강제합니다. max-age=31536000은 1년 유효 기간을 의미합니다.
  • X-Frame-Options: SAMEORIGIN: 동일 도메인 외의 iframe 삽입을 차단하여 클릭재킹 공격을 방지합니다.
  • X-Content-Type-Options: nosniff: 브라우저가 응답의 Content-Type을 임의로 변경하는 MIME 스니핑을 방지합니다.
  • X-XSS-Protection: 1; mode=block: 브라우저 내장 XSS 필터를 활성화하여 반사형 XSS를 차단합니다. 최신 브라우저에서는 CSP 적용이 더 권장됩니다.

Content Security Policy (CSP) 소개

보안 헤더 중 가장 강력하고 복잡한 것이 Content-Security-Policy(CSP)입니다. 브라우저가 허용된 출처에서만 스크립트, 스타일시트, 이미지, 폰트 등을 로드하도록 강제하여 XSS(Cross-Site Scripting) 공격을 근본적으로 방어합니다. 그러나 CDN, 외부 폰트(Google Fonts), 외부 분석 도구(Google Analytics) 등이 있는 사이트에서 CSP를 잘못 설정하면 해당 리소스가 차단되어 서비스 오류가 발생합니다.

CSP 도입 전 단계로 Content-Security-Policy-Report-Only 헤더를 먼저 적용하면 실제 차단 없이 위반 사항을 report-uri로 수집할 수 있습니다. 수집된 리포트를 분석하여 정책을 튜닝한 후 실제 CSP를 적용합니다. 기본 시작점으로 default-src 'self'를 설정하고 필요한 외부 출처를 하나씩 추가하는 방식을 권장합니다.

※ Content Security Policy 부분이 남아 있지만 이부분은 적용시 실제 서비스에 영향을 크게 끼치므로 코드와 도메인 부분의 검토가 필요합니다.

내용을 준비해서 이후에 별도로 다뤄보도록 하겠습니다…

참고

참고 문서: MDN — Strict-Transport-Security · MDN — X-Frame-Options