owasp-modsecurity/modsecurityModSecurity는 Apache, IIS 및 Nginx를 위한 오픈 소스 크로스 플랫폼 웹 애플리케이션 방화벽(WAF) 엔진입니다. 견고한 이벤트 기반 프로그래밍 언어를 갖추고 있어 웹 애플리케이션에 대한 다양한 공격으로부터 보호하며 HTTP 트래픽 모니터링, 로깅 및 실시간 분석을 지원합니다.
Libmodsecurity는 ModSecurity v3 프로젝트의 구성 요소 중 하나입니다. 이 라이브러리 코드베이스는 웹 트래픽을 받아 전통적인 ModSecurity 처리를 적용하는 ModSecurity 커넥터(Connectors)를 위한 인터페이스 역할을 합니다. 일반적으로 ModSecurity SecRules 형식으로 작성된 규칙을 로드/해석하고, 커넥터를 통해 애플리케이션에서 제공하는 HTTP 콘텐츠에 이를 적용하는 기능을 제공합니다.
Apache용 ModSecurity(일명 ModSecurity v2.x)를 찾고 계신다면, 해당 버전은 여전히 유지 관리 중이며 다음에서 이용할 수 있습니다: 여기.
Libmodsecurity는 ModSecurity 플랫폼을 완전히 재작성한 것입니다. ModSecurity 프로젝트는 처음 고안되었을 때 단순한 Apache 모듈로 시작했습니다. 시간이 지나면서 프로젝트는 폭넓은 요구에 힘입어 Nginx와 IIS를 포함한(이에 국한되지 않는) 다른 플랫폼을 지원하도록 확장되었습니다. 추가 플랫폼 지원에 대한 증가하는 요구에 부응하기 위해, 이 프로젝트의 기반이 되는 Apache 의존성을 제거하여 보다 플랫폼 독립적으로 만드는 것이 필요해졌습니다.
이러한 목표의 결과로 우리는 Libmodsecurity를 재설계하여 더 이상 Apache 웹 서버에 의존하지 않도록(컴파일 시와 런타임 모두에서) 만들었습니다. 이에 따른 부수적인 효과 중 하나는 모든 플랫폼에서 사용자가 향상된 성능을 기대할 수 있다는 것입니다. 또한 우리는 이 기회를 활용하여 사용자들이 오랫동안 바라왔던 몇 가지 새로운 기능의 기반을 마련했습니다. 예를 들어, 향후 버전에서 JSON 형식의 감사 로그(auditlogs)를 기본적으로 지원하는 것과 더불어 다양한 기능을 제공할 계획입니다.
'ModSecurity' 브랜치는 전통적으로 한데 묶여 패키징되던 기존의 모듈 로직(Nginx, Apache, IIS용)을 더 이상 포함하지 않습니다. 대신 이 브랜치는 이 프로젝트의 라이브러리 부분(libmodsecurity)만 포함합니다. 이 라이브러리는 우리가 '커넥터(Connectors)'라고 부르는 것에 의해 사용되며, 이 커넥터들은 웹 서버와 인터페이스하여 라이브러리가 이해할 수 있는 공통 형식을 제공합니다. 각 커넥터는 별도의 GitHub 프로젝트로 유지 관리됩니다. 예를 들어, Nginx 커넥터는 ModSecurity-nginx 프로젝트(https://github.com/owasp-modsecurity/ModSecurity-nginx)에서 제공됩니다.
이렇게 커넥터를 분리하여 유지함으로써 각 프로젝트는 서로 다른 릴리스 주기, 이슈, 개발 트리를 가질 수 있습니다. 또한 이는 ModSecurity v3를 설치할 때 사용하지 않을 추가 요소 없이 정확히 필요한 것만 얻게 된다는 것을 의미합니다.
컴파일 과정을 시작하기 전에 필요한 모든 종속성이 설치되어 있는지 확인하십시오.
자세한 내용은 종속성 및 Git 서브모듈 섹션을 참조하십시오.
컴파일 후 빌드/플랫폼에 문제가 없는지 확인하십시오.
단위 테스트와 회귀 테스트를 실행할 것을 강력히 권장합니다. 이러한 테스트 유틸리티는 tests/ 하위 폴더에 있습니다.
동적 라이브러리로서 libmodsecurity는 운영 체제가 동적 라이브러리를 찾을 수 있는 위치에 설치되어야 합니다.
Unix 계열 시스템에서 이 프로젝트는 컴파일 과정에 autotools를 사용합니다.
git 체크아웃으로 작업하는 경우, 빌드 전에 저장소를 재귀적으로 복제하거나 모든 서브모듈을 초기화해야 합니다.
Git 서브모듈 섹션도 참조하십시오.
git clone https://github.com/owasp-modsecurity/ModSecurity ModSecurity
cd ModSecurity
이 저장소는 git 서브모듈을 사용합니다. 복제한 후에는 반드시 모든 서브모듈을 초기화하고 가져오세요:
git submodule update --init --recursive
다음을 통해 모든 서브모듈이 올바르게 초기화되었는지 확인할 수 있습니다:
git submodule status
올바르게 초기화된 서브모듈은 커밋 해시를 표시합니다.
앞에 붙은 -는 해당 서브모듈이 초기화되지 않았음을 나타냅니다.
그런 다음 빌드 프로세스를 시작할 수 있습니다:
./build.sh
./configure
make
sudo make install
배포판별 빌드에 대한 자세한 내용은 Wiki에서 확인할 수 있습니다: Compilation Recipes
Windows 빌드 정보는 여기에서 확인할 수 있습니다.
SecRules의 정규 표현식 처리는 Regex 유틸리티(src/utils/regex.*)를 통해 구현됩니다.
기본적으로 ModSecurity는 정규 표현식 처리를 위해 PCRE2를 사용합니다.
이는 @rx, @rxGlobal, @verifyCC와 같은 연산자에서 사용됩니다.
빌드 시 동작:
--with-pcre가 명시적으로 제공되면(WITH_PCRE) 레거시 PCRE를 사용할 수 있습니다.즉, 현재 빌드는 명시적으로 다르게 구성하지 않는 한 PCRE2를 기대합니다.
@rx와 @rxGlobal은 기본적으로 DOTALL | MULTILINE으로 패턴을 컴파일합니다: DOTALL은
.이 줄바꿈과 일치하도록 하며, MULTILINE은 ^/$가 전체 대상의 시작/끝에서만이 아니라
모든 내부 줄바꿈 위치에서 앵커링되도록 합니다. 대신 DOTALL | DOLLAR_ENDONLY로
컴파일하려면 --enable-regex-dollar-endonly=yes를 전달하십시오: MULTILINE이 없으면
^/$는 전체 대상의 시작/끝에서만 앵커링되며, DOLLAR_ENDONLY는 $가 후행 줄바꿈
바로 앞에서도 일치하는 대신 오직 그 위치에서만 일치하도록 추가로 제한합니다. DOTALL은
어느 경우든 변경되지 않으므로, 패턴은 여전히 .을 통해 내부 줄바꿈을 넘어 일치할 수
있습니다. 이는 ModSecurity v2의 @rx 동작과 일치합니다. 이 플래그는 기본적으로
비활성화되어 있습니다. 이슈 #3295를 참조하십시오.
다른 모든 종속성은 SecRules 또는 구성 지시문에 지정된 연산자와 관련되어 있으며 컴파일에는 필요하지 않을 수 있습니다.
libinjection은 @detectXSS 및 @detectSQL 연산자에 필요합니다.curl은 SecRemoteRules 지시문에 필요합니다.해당 라이브러리가 없으면 ModSecurity는 해당 연산자 또는 지시문에 대한 지원 없이 컴파일됩니다.
저장소에는 다음 서브모듈이 포함되어 있습니다:
others/libinjection – @detectSQLi 및 @detectXSS 연산자에서 사용됩니다.
others/mbedtls (TF-PSA-Crypto 하위 집합) – 암호화 함수 및 헬퍼(예: 해싱, base64)에 사용됩니다.
참고: 최신 mbedTLS v4 레이아웃은 이전 v3 구조와 호환되지 않습니다. 내부 구조가 크게 변경되었으며, 많은 구성 요소가 서브모듈(예: TF-PSA-Crypto)로 이동되었습니다.
PR #3532를 병합한 후에는 다음을 실행해야 합니다:
git submodule update --init --recursive
이렇게 하면 필요한 모든 서브모듈이 가져와집니다. 이 단계가 없으면 프로젝트가 성공적으로 빌드되지 않습니다.
다음을 사용하여 모든 서브모듈이 올바르게 초기화되었는지 확인할 수 있습니다:
git submodule status
예시 출력:
bc625d5... bindings/python
2117822... others/libinjection (v4.0.0)
0fe989b... others/mbedtls (v4.1.0)
a3d4405... test/test-cases/secrules-language-tests
하위 모듈이 누락된 경우 앞에 -가 붙어 표시됩니다. 예를 들어:
-bc625d5... bindings/python
앞의 -는 서브모듈이 초기화되거나 가져와지지 않았음을 나타냅니다.
test/test-cases/secrules-language-tests – make check에서 사용하는 공유 SecRules 적합성 및 회귀 테스트 스위트입니다.
bindings/python – ModSecurity용 Python 바인딩입니다(핵심 라이브러리 컴파일에 필요하지 않음).
others/libinjection과 others/mbedtls는 소스 빌드에 사실상 필수적이며, 빌드 전에 초기화해야 합니다.
여러 외부 라이브러리는 선택 사항이며 다음과 같은 추가 기능을 활성화합니다.
libcurl – SecRemoteRules에 필요
LMDB – 영구 저장소 지원
Lua – 스크립팅 지원
XML 라이브러리 – 확장된 XML 처리
GeoIP (레거시) / MaxMind
레거시 GeoIP C API(libGeoIP)는 MaxMind에 의해 더 이상 사용되지 않으며 유지 관리되지 않습니다. 업스트림 저장소는 보관 처리되었으며, 새로운 배포에는 사용해서는 안 됩니다.
대신 ModSecurity는 활발히 유지 관리되는 최신 **MaxMind DB API(libmaxminddb)**를 지원합니다.
구성 중에 다음과 같은 메시지가 표시될 수 있습니다.
+ GeoIP/MaxMind ....found
* (MaxMind) v1.12.2
-lmaxminddb , -I/usr/include/x86_64-linux-gnu
이는 libmaxminddb가 사용되고 있음을 나타냅니다(권장됨).
레거시 GeoIP 라이브러리 대신 MaxMind DB를 사용할 것을 강력히 권장합니다.
라이브러리 문서는 코드 내에 Doxygen 형식으로 작성되어 있습니다. 이 문서를 생성하려면 "doc/" 하위 폴더에 있는 제공된 구성 파일 "doxygen.cfg"와 함께 doxygen 유틸리티를 사용하십시오. 그러면 사용 예제를 포함한 HTML 형식의 문서가 생성됩니다.
라이브러리는 C++ 및 C 인터페이스를 제공합니다. 일부 리소스는 현재 C++ 인터페이스를 통해서만 사용할 수 있습니다. 예를 들어, 사용자 정의 로깅 메커니즘을 생성하는 기능이 그러합니다(이러한 로깅 메커니즘이 어떻게 작동하는지 확인하려면 회귀 테스트를 참조하십시오). 목표는 두 API(C, C++)가 동일한 기능을 제공하는 것입니다. 특정 인터페이스를 통해 API의 일부 측면이 누락된 것을 발견하면 이슈를 열어 주십시오.
examples 하위 폴더 안에는 API를 사용하는 방법에 대한 간단한 예제가 있습니다. 아래에 몇 가지가 예시되어 있습니다: