Apache Upgrade(2.2 -> 2.4)

2021년 2월 02일 Jason 댓글 남기기

개요

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

2021년 1월 29일 Jason 댓글 남기기

개요

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

Syslog & Log Analyzer

Rsyslog Log Analyzer Overview

2021년 1월 27일 Jason 댓글 남기기

개요

Rsyslog Log Analyzer는 rsyslog 데몬으로 수신한 리눅스, 윈도우, 네트워크 장비의 로그를 MariaDB(MySQL)에 적재하고, Apache 기반의 웹 인터페이스로 간단한 통계를 시각화하는 오픈소스 툴입니다. 오래된 툴이라 UI가 다소 구식이지만 간단한 로그 집계와 검색에는 여전히 활용할 수 있습니다.

로그 수집 아키텍처

Rsyslog + MariaDB + Log Analyzer로 구성된 중앙 로그 시스템의 데이터 흐름은 다음과 같습니다. 각 서버(리눅스, 윈도우, 네트워크 장비)의 rsyslog/syslog 클라이언트가 UDP/TCP 514 포트로 중앙 rsyslog 서버에 로그를 전송합니다. 중앙 서버의 rsyslog는 ommysql 모듈을 통해 MariaDB의 Syslog 데이터베이스에 로그를 INSERT합니다. Log Analyzer는 Apache와 PHP로 구동되는 웹 인터페이스로, 브라우저에서 호스트별 로그 발생 빈도, 심각도별 분류, 키워드 검색 기능을 제공합니다.

시스템 구성

rsyslog 데몬을 사용하여 리눅스, 윈도우, 네트워크 장비로 부터 수신 로그를 mariadb에 적재하게 되고 아파치로 간단한 통계로도 볼 수 있게 구축 해서 사용하고 있습니다.

나온지도 오래되었고 UI가 상당히 구식이지만 간단하게 보기에는 쓸만하여 종종 사용하는 편 입니다.

단점은 DB에 로그가 장기간 쌓이면 통계 페이지를 제대로 표시하지 못하는 경우도 있고 특정 호스트의 로그 발생 빈도가 높으면 통계 페이지를 보기 불편한 부분이 있었습니다. 저는 일정 기간 이전의 로그를 삭제하는 SQL스크립트를 crontab에 등록 하여 유지하고 있습니다.

그와 별개로 DB에 있는 로그 데이터를 elasticsearch등으로 시각화 시키는 것도 좋은 방법인 것 같습니다.

※ 테스트를 해보진 않았지만 Log Analyzer 최신 버전은 그래프 생성 관련 타임 아웃 현상을 해결 했다고 합니다.

화면 구성 예시

아래는 Rsyslog Log Analyzer의 실제 화면 구성입니다. 호스트별 로그 발생 현황과 상세 검색 기능을 웹 브라우저에서 확인할 수 있습니다.

Rsyslog Log Analyzer 대시보드 — 호스트별 로그 발생 현황

Rsyslog Log Analyzer 상세 로그 검색 화면

운영 시 고려사항

DB에 로그가 장기간 쌓이면 통계 페이지 표시가 느려지거나 실패할 수 있습니다. 일정 기간 이전 로그를 정기적으로 삭제하는 SQL 스크립트를 스케줄러에 등록하여 DB 크기를 관리하는 것이 좋습니다. 또한 특정 호스트의 로그 발생 빈도가 과도하게 높을 경우 rsyslog 필터 규칙으로 해당 호스트 로그를 별도 파일로 분리하는 것도 방법입니다.

보다 현대적인 로그 시각화가 필요하다면 Elasticsearch + Kibana 또는 Loki + Grafana 조합을 검토해볼 수 있습니다.

참고

참고 문서: Adiscon Log Analyzer 공식 사이트 · rsyslog ommysql 모듈 문서

IT Garage