Debian 12 또는 11에서 Apache와 함께 ModSecurity 2를 설치하는 방법

ModSecurity 2는 Apache HTTP 서버를 보호하기 위한 필수적인 웹 애플리케이션 방화벽(WAF)으로, 실시간 모니터링과 규칙 기반 필터링을 제공합니다. Debian 12 또는 11 Linux 서버에 설치된 ModSecurity는 SQL 주입, 크로스 사이트 스크립팅(XSS) 및 기타 공격을 방지하는 데 도움이 됩니다. Digitalwave ModSecurity Repository는 설치를 간소화하여 최신 안정 버전을 사용하고 있는지 확인합니다.

보안을 강화하기 위해 OWASP Core Rule Set(CRS)은 일반적인 취약성을 대상으로 하는 사전 구성된 규칙을 제공합니다. 이를 설정하면 관리자는 최소한의 수동 구성으로 방어를 강화할 수 있습니다. 이 가이드에서는 Digitalwave 저장소를 사용하여 Debian에 ModSecurity 2를 설치하고 최적의 보호를 위해 OWASP CRS를 구성하는 방법을 보여줍니다.

ModSecurity 2 설치를 위한 Debian 시스템 패키지 업데이트

첫 번째 단계는 데비안 시스템을 업데이트하는 것입니다. 그렇게 하면 모든 기존 패키지가 최신 상태로 유지되고, 최적의 성능이 보장되며, 보안 위험이 최소화됩니다. 다음 명령을 실행하여 이를 달성하세요.

sudo apt update && sudo apt upgrade

시스템을 업데이트한 후 Apache가 설치되어 있는지 확인하세요. 설치되어 있지 않으면 다음 명령을 사용하여 설치하세요.

sudo apt install apache2

ModSecurity 모듈 PPA 가져오기

필요한 저장소 설정

목록에서 다음 작업은 ModSecurity Apache 모듈을 설치하는 것입니다. Debian의 기본 저장소에서 사용할 수 있는 버전은 최신이 아닐 수 있으며, 이를 사용하면 즉시 오류가 발생할 수 있습니다. 대신 타사 저장소를 가져와 Apache용 최신 ModSecurity 모듈을 설치합니다. Digitalwave에서 유지 관리하는 이 타사 저장소는 안정적인 바이너리로 유명합니다.

먼저 필요한 패키지 세트를 설치합니다.

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

그런 다음 ModSecurity 2 모듈 PPA 저장소를 가져옵니다. GPG 키:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null

GPG 키를 취득한 후 시스템에 저장소를 추가합니다.

echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list

새로운 Apache 모듈 PPA 저장소 우선 순위 지정

저장소가 제자리에 있으면 이제 ModSecurity와 관련된 특정 패키지에 대해 이 저장소를 우선시하도록 APT 정책을 조정해야 합니다. 다음 명령은 이를 수행합니다.

cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

다음으로, 새로 가져온 소스를 반영하기 위해 APT 업데이트를 실행합니다.

sudo apt update

또한, 기본 설정을 확인하려면 다음을 통해 정책 변경 사항을 확인할 수 있습니다.

sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3

ModSecurity 2 모듈 설치

이제 저장소가 준비되었으므로 libapache2-mod-security2 모듈 설치를 진행하세요.

sudo apt install libapache2-mod-security2

설치 후 모듈을 활성화해야 합니다. 다음 명령을 사용하여 이를 달성하세요.

sudo a2enmod security2

Apache 서비스 재시작

마지막으로 Apache 서비스를 다시 시작하여 모든 변경 사항이 적용되고 새로 추가된 ModSecurity 모듈이 올바르게 통합되었는지 확인합니다.

sudo nano /etc/apache2/mods-enabled/security2.conf

Apache HTTP에서 ModSecurity 2 모듈 활성화

ModSecurity 구성 파일 액세스

Apache ModSecurity의 구성 파일은 /etc/apache2/mods-enabled/security2.conf에서 찾을 수 있습니다. 다음 명령으로 nano 텍스트 편집기(또는 선호하는 텍스트 편집기)를 사용하여 이 파일에 액세스합니다.

sudo nano /etc/apache2/mods-enabled/security2.conf

다음과 같이 적힌 줄을 찾으세요:

IncludeOptional /etc/modsecurity/*.conf

이 줄은 /etc/modsecurity 디렉토리의 다른 필수 구성 파일을 포함하므로 주석 처리가 해제되어 있는지 확인하십시오. 기본적으로 주석 처리가 해제되어야 합니다.

ModSecurity 2 구성 수정

modsecurity.conf-recommended 구성 파일을 modsecurity.conf로 이름을 바꿔 활성화해야 합니다. 다음 명령으로 이를 수행할 수 있습니다.

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

이제 새로 이름이 지정된 구성 파일을 열어 보겠습니다.

sudo nano /etc/modsecurity/modsecurity.conf

ModSecurity 규칙 엔진은 이 파일 내에서 기본적으로 DetectionOnly로 설정됩니다. 즉, 차단하지 않고 잠재적으로 악의적인 동작을 식별하고 기록합니다. 이를 변경하고 ModSecurity의 차단 기능을 활성화하려면 SecRuleEngine 줄(줄 7 근처)을 찾아 DetectionOnly를 On으로 바꿉니다.

에서:

SecRuleEngine DetectionOnly

에게:

SecRuleEngine On

Apache에 대한 로그 설정 조정

구성 파일 아래쪽에 SecAuditLogParts 줄(224줄 근처)이 있습니다. 이 줄의 기본 설정은 정확하지 않습니다. 모든 거래 정보를 정확하게 기록하도록 조정해야 합니다.

변화:

SecAuditLogParts ABDEFHIJZ

에게:

SecAuditLogParts ABCEFHJKZ

이러한 수정 사항을 적용한 후, 변경 사항을 저장하고 편집기를 종료합니다.

변경 사항을 적용하기 위해 Apache 재시작

이 프로세스의 마지막 단계는 ModSecurity 구성에 대한 변경 사항이 적용되도록 Apache 서비스를 다시 시작하는 것입니다. 이는 다음 명령을 사용하여 수행됩니다.

sudo systemctl restart apache2

ModSecurity2용 OWASP Core Rule Set 설치

ModSecurity만으로는 웹 서버를 보호할 수 없습니다. 잠재적 위협을 식별하고 악성 활동을 차단하기 위한 규칙 세트가 필요합니다. OWASP(Open Web Application Security Project) Core Rule Set(CRS)은 다양한 웹 서버와 웹 애플리케이션 방화벽(WAF)에서 사용하는 매우 높은 평가를 받는 규칙 세트입니다. 이 규칙 세트를 배포하면 인터넷에서 발생하는 다양한 위협으로부터 서버를 강력하게 보호할 수 있습니다.

진행하기 전에 OWASP CRS의 최신 버전이 있는지 확인하는 것이 필수적입니다. OWASP 릴리스 태그 페이지. 이 단계에서는 서버에 대한 최신 보안 조치를 다운로드하고 설치합니다.

OWASP CRS에 대한 부모 디렉터리 생성

먼저 mkdir 명령을 사용하여 OWASP의 주요 상위 디렉터리를 만들어 보겠습니다.

sudo mkdir /etc/apache2/modsec/

Debian에서 OWASP CRS Archive 다운로드

다음으로, wget 명령을 사용하여 작성 당시 안정된 버전인 OWASP CRS 3.3.4 아카이브를 가져옵니다. 앞서 언급한 링크를 사용하여 버전을 확인해야 한다는 점을 기억하세요.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip

야간 빌드는 최신 보안 조치를 제공할 수 있지만 개발 상태로 인해 문제가 발생할 수 있습니다. 신규 사용자의 경우 잠재적인 합병증을 피하기 위해 안정적인 버전을 사용하는 것이 좋습니다.

참고: 업데이트를 지속적으로 확인해야 합니다. 안정적인 규칙은 매주 변경되지 않고 분기마다 변경되며 긴급 업데이트가 필요한 경우는 예외입니다.

아카이브 추출

보관 파일을 다운로드한 후에는 앞서 생성한 디렉토리에 압축을 풀 수 있습니다.

sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec

다운로드한 OWASP CRS 버전에 따라 명령어를 변경하세요.

규칙 세트 구성

OWASP CRS에는 원본을 백업으로 유지하면서 이름을 바꿔야 하는 샘플 구성 파일이 있습니다. 'cp 명령'을 사용하여 이를 수행할 수 있습니다.

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

참고: /coreruleset-3.3.4/를 선택한 OWASP CRS 버전으로 바꾸는 것을 잊지 마세요.

규칙 활성화

규칙을 활성화하려면 /etc/apache2/mods-enabled/security2.conf 파일을 엽니다.

sudo apt install unzip -y

그리고, 다음 두 줄을 삽입합니다.

Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf

참고: 다시 한번 말씀드리지만, /coreruleset-3.3.4/를 선택한 OWASP CRS의 정확한 버전으로 바꿔야 합니다. 다운로드하게 될 coreruleset은 가이드의 예보다 최신 버전일 가능성이 높습니다.

또한, 다음 줄을 주석으로 처리하거나 제거하세요.

IncludeOptional /usr/share/modsecurity-crs/*.load

완료되면 파일을 저장하고 종료합니다.

변경 사항을 적용하기 위해 Apache 재시작

마지막 단계는 Apache 서비스를 다시 시작하여 변경 사항이 적용되는지 확인하는 것입니다.

sudo systemctl restart apache2

OWASP Core Rule Set 및 ModSecurity 2 시작하기

OWASP Core Rule Set(CRS)은 다양한 사용자 정의 옵션이 있는 포괄적인 도구입니다. 기본 구성은 정품 방문자나 검색 엔진 최적화(SEO) 봇에 영향을 미치지 않고 대부분의 서버에 대한 즉각적인 보안 강화를 제공합니다. 이 섹션에서는 CRS의 몇 가지 중요한 측면에 대해 논의하지만, 사용 가능한 모든 옵션을 완전히 이해하기 위해 구성 파일을 탐색하는 것은 항상 유익합니다.

CRS 구성 조정

CRS 설정의 대부분을 변경할 수 있는 crs-setup.conf 파일을 열어서 시작합니다.

sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

CRS 채점 시스템 이해

ModSecurity는 두 가지 모드로 작동합니다.

• 이상 점수 모드: 대부분 사용자에게 권장되는 이 모드는 규칙이 일치할 때마다 '이상 점수'를 할당합니다. 인바운드 및 아웃바운드 규칙을 모두 처리한 후 이상 점수를 확인하고 필요한 경우 방해 조치가 트리거됩니다. 이 조치는 종종 403 오류의 형태를 띱니다. 이 모드는 정확한 로그 정보를 제공하고 차단 정책을 설정하는 데 더 큰 유연성을 제공합니다.
• 자체 포함 모드: 이 모드에서는 규칙이 일치할 때마다 작업이 즉시 적용됩니다. 리소스 사용량을 줄일 수 있지만 유연성이 떨어지고 정보성 있는 감사 로그가 덜 생성됩니다. 첫 번째 규칙이 충족되고 지정된 작업이 실행되면 규칙 일치 프로세스가 중지됩니다.

편집증 수준 이해

OWASP CRS는 편집증 수준을 4가지로 정의합니다.

• 편집증 레벨 1: 기본 레벨은 대부분 사용자에게 적합합니다.
• 편집증 레벨 2: 고급 사용자용.
• 편집증 레벨 3: 전문가용입니다.
• 편집증 레벨 4: 특별한 상황에서만 권장됨.

더 높은 편집증 수준은 추가 규칙을 가능하게 하고, 보안을 강화하며, 거짓 양성으로 인해 합법적인 트래픽을 차단할 가능성을 증가시킵니다. 귀하의 전문성과 보안 요구 사항에 맞는 편집증 수준을 선택하는 것이 필수적입니다.

서버에서 OWASP CRS 테스트

OWASP CRS가 서버에서 올바르게 작동하는지 확인하려면 인터넷 브라우저를 사용하여 다음 URL에 액세스하세요. "yourdomain.com"을 실제 도메인으로 바꾸는 것을 잊지 마세요.

https://www.yourdomain.com/index.html?exec=/bin/bash

403 Forbidden 오류가 발생하면 OWASP CRS는 예상대로 작동합니다. 그렇지 않은 경우 주의가 필요한 설정 프로세스의 실수가 있을 수 있습니다. 가장 흔한 문제는 DetectionOnly를 On 또는 이와 유사한 것으로 변경하는 것을 잊는 것입니다.

거짓 양성 및 사용자 정의 제외 규칙 해결

ModSecurity와 OWASP Core Rule Set(CRS)을 사용하여 거짓 양성을 관리하는 것은 지속적인 작업일 수 있습니다. 그러나 이러한 시스템이 광범위한 위협에 대해 제공하는 강력한 방어력으로 인해 이러한 노력이 필수적입니다. 처음에 거짓 양성을 최소화하려면 낮은 편집증 수준을 설정하는 것이 좋습니다.

몇 주 또는 몇 달 동안 낮은 편집증 수준에서 규칙 세트를 실행하면 압도적인 수의 거짓 양성 반응 가능성을 줄일 수 있습니다. 이 접근 방식은 더 엄격한 보안을 위해 편집증 수준을 점진적으로 높이기 전에 경고와 적절한 대응에 익숙해질 시간을 제공합니다.

OWASP, ModSecurity 2를 사용하여 Debian에서 알려진 애플리케이션의 False Positives 관리

ModSecurity에는 의도치 않게 거짓 양성을 유발할 수 있는 특정 작업을 허용 목록에 추가하는 기능이 포함되어 있습니다. 예를 들어:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

WordPress, phpBB, phpMyAdmin과 같은 애플리케이션에 대한 허용 목록을 시행하려면 해당 줄의 주석 처리를 해제하고 (1) 값을 유지합니다. 사용하지 않는 서비스의 허용 목록을 방지하려면 값을 (0)으로 조정합니다.

업데이트된 구성은 다음과 같습니다.

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

이 경우에는 불필요한 옵션이 제거되어 필요한 구성에 맞는 올바른 구문이 남았습니다.

CRS 구현 전 규칙 제외 생성

사용자 정의 제외 항목을 만들려면 다음 명령을 사용하여 “REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf” 파일의 이름을 바꾸는 것으로 시작합니다.

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Apache2 서비스 테스트 중 오류를 방지하기 위해 각 제외 규칙에는 고유한 'idnumber'가 있어야 합니다.

예를 들어, 일부 "REQUEST_URI"는 거짓 양성을 일으킬 수 있습니다. 다음 예는 Google PageSpeed ​​비콘과 WordPress용 WPMU DEV 플러그인을 포함하는 두 가지 사례를 보여줍니다.

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

이러한 규칙은 지정된 경로로 시작하는 모든 URL을 자동으로 허용합니다.

특정 IP 주소를 허용 목록에 추가할 수도 있습니다.

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

첫 번째 규칙에서는 단일 IP 주소가 허용 목록에 추가되고, 두 번째 규칙에서는 더 광범위한 서브넷 매칭을 위해 '@ipMatch' 지시어를 사용합니다. 서브넷이나 IP 주소를 차단하려면 'allow'를 'deny'로 바꾸기만 하면 됩니다. 이러한 유연성을 통해 자세한 블랙리스트와 허용 목록을 만들 수 있으며, 이는 Fail2Ban과 통합하여 향상된 보안 전략을 구축할 수 있습니다.

OWASP, ModSecurity 2를 사용하여 Debian에서 특정 규칙 비활성화

전체 경로를 허용 목록에 추가하는 대신, 지속적인 거짓 양성을 유발하는 특정 규칙을 비활성화하는 것도 다른 방법입니다. 이 방법은 더 많은 테스트가 필요하지만 장기적인 이점을 제공합니다.

예를 들어, "/admin/" 영역의 규칙 941000 및 942999가 팀에 대해 거짓 양성 반응을 유발하는 경우 ModSecurity 로그에서 규칙 ID를 찾아 "RemoveByID" 명령을 사용하여 해당 ID만 비활성화할 수 있습니다.

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

로그 모니터링 및 패턴 식별

Apache, ModSecurity, OWASP에서 거짓 양성을 처리할 때 지속적인 로그 모니터링이 필수적입니다. 거짓 양성을 유발하는 패턴을 식별하는 데 도움이 되므로 이를 해결하기 위한 사용자 지정 규칙을 만들 수 있습니다.

예를 들어, 특정 규칙이 지속적으로 거짓 양성을 유발하는 경우, 이러한 특정 인스턴스를 처리하기 위한 제외 규칙을 만들 수 있습니다. 이러한 맞춤형 접근 방식은 거짓 양성을 보다 효과적으로 관리할 수 있도록 합니다.

정기적으로 로그를 검토하고 규칙을 조정하면 애플리케이션에 대한 보안과 효율성을 더욱 높일 수 있습니다.

ModSecurity 2에 대한 로그 회전

웹 트랜잭션의 동적 특성으로 인해 ModSecurity 로그가 빠르게 커질 수 있으므로 효과적인 로그 관리가 중요합니다. 로그 로테이션은 이러한 로그를 관리하는 데 유용한 도구이지만 ModSecurity에서는 기본적으로 구성되지 않습니다. 이 섹션에서는 ModSecurity에 맞게 로그 로테이션을 설정하는 방법을 안내합니다.

ModSecurity 로테이션 파일 생성

먼저, ModSecurity 로그 로테이션을 위한 전용 파일을 만들어야 합니다. 이를 위해 다음 명령을 사용하여 modsec이라는 이름의 새 파일을 만들고 엽니다.

sudo nano /etc/logrotate.d/modsec

회전 파일 구성

새로 만든 ModSecurity(modsec) 구성 파일에 다음을 추가합니다.

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

이 구성은 31일 동안 로그를 보관하지만 필요에 맞게 숫자를 수정할 수 있습니다. 예를 들어, 'rotate 7'로 변경하면 대신 일주일치 로그가 보관됩니다.

'daily' 지시어는 로그가 매일 회전되도록 보장하는 반면, 'compress'는 오래된 로그를 압축하여 공간을 절약합니다. 'delaycompress' 옵션은 두 번째 회전 주기까지 압축을 지연하고, 'missingok'는 로그 파일이 없는 경우 오류를 방지합니다. 또한, 'notifempty'는 빈 로그 파일이 회전되지 않도록 보장합니다.

팁: 너무 큰 로그 파일을 처리하지 않으려면 매일 로그를 순환하는 것이 좋습니다. 너무 큰 로그 파일은 분석에 더 많은 시간을 소모하게 만들기 때문입니다.

결론

이제 Digitalwave 저장소를 사용하여 Debian 12 또는 11 서버에 ModSecurity 2를 설치하고 OWASP Core Rule Set을 구성했습니다. 이러한 도구를 사용하면 서버가 많은 일반적인 웹 애플리케이션 위협을 차단할 수 있습니다.

CRS를 정기적으로 업데이트하고 거짓 양성 또는 누락된 취약성을 모니터링하는 것을 잊지 마세요. 견고한 보안 설정을 유지하려면 일관된 테스트와 조정이 중요합니다.