owasp-modsecurity/modsecurityModSecurity는 Apache, IIS 및 Nginx를 위한 오픈 소스 크로스 플랫폼 웹 애플리케이션 방화벽(WAF) 엔진입니다. 견고한 이벤트 기반 프로그래밍 언어를 갖추고 있어 웹 애플리케이션에 대한 다양한 공격으로부터 보호하며 HTTP 트래픽 모니터링, 로깅 및 실시간 분석을 지원합니다.
Libmodsecurity는 ModSecurity v3 프로젝트의 한 구성 요소입니다. 이 라이브러리 코드베이스는 웹 트래픽을 수신하고 기존 ModSecurity 처리를 적용하는 ModSecurity 커넥터에 대한 인터페이스 역할을 합니다. 일반적으로 ModSecurity SecRules 형식으로 작성된 규칙을 로드/해석하고 커넥터를 통해 애플리케이션에서 제공하는 HTTP 콘텐츠에 적용하는 기능을 제공합니다.
Apache용 ModSecurity(일명 ModSecurity v2.x)를 찾고 있다면, 해당 버전은 여전히 유지관리되며 사용할 수 있습니다: 여기.
Libmodsecurity는 ModSecurity 플랫폼의 완전한 재작성입니다. 처음 고안되었을 때 ModSecurity 프로젝트는 단순한 Apache 모듈로 시작했습니다. 시간이 지나면서 대중의 요구로 인해 Nginx 및 IIS를 포함한(그러나 이에 국한되지 않는) 다른 플랫폼을 지원하도록 확장되었습니다. 추가 플랫폼 지원에 대한 증가하는 수요를 충족하기 위해 이 프로젝트의 기반이 되는 Apache 의존성을 제거하여 더 플랫폼 독립적으로 만드는 것이 필요해졌습니다.
이 목표의 결과로 우리는 Libmodsecurity를 (컴파일 시와 런타임 모두에서) 더 이상 Apache 웹 서버에 의존하지 않도록 재설계했습니다. 그 부수 효과 중 하나는 모든 플랫폼에서 사용자가 향상된 성능을 기대할 수 있다는 것입니다. 또한, 사용자들이 오랫동안 찾아온 일부 새로운 기능을 위한 기반을 마련할 기회를 잡았습니다. 예를 들어, 향후 버전에서 JSON 형식의 감사 로그(auditlog)를 기본 지원하고 다양한 다른 기능도 제공할 계획입니다.
'ModSecurity' 브랜치는 더 이상 기존에 함께 패키징되던 (Nginx, Apache, IIS용) 전통적인 모듈 로직을 포함하지 않습니다. 대신 이 브랜치에는 이 프로젝트의 라이브러리 부분(libmodsecurity)만 포함됩니다. 이 라이브러리는 우리가 '커넥터'라고 부르는 것에 의해 사용됩니다. 이 커넥터는 웹 서버와 인터페이스하여 라이브러리가 이해하는 공통 형식을 제공합니다. 각 커넥터는 별도의 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에서 확인할 수 있습니다: 컴파일 레시피
Windows 빌드 정보는 여기에서 확인할 수 있습니다.
SecRules의 정규 표현식 처리는 Regex 유틸리티(src/utils/regex.*)를 통해 구현됩니다.
기본적으로 ModSecurity는 정규식 처리를 위해 PCRE2를 사용합니다.
@rx, @rxGlobal, @verifyCC와 같은 연산자에서 사용됩니다.
빌드 시 동작:
--with-pcre가 명시적으로 제공되면(WITH_PCRE) 레거시 PCRE를 사용할 수 있습니다.즉, 명시적으로 다르게 구성하지 않는 한 현재 빌드는 PCRE2를 기대합니다.
다른 모든 의존성은 SecRules 내에 지정된 연산자나 구성 지시문과 관련이 있으며 컴파일에 필요하지 않을 수 있습니다.
@detectXSS 및 @detectSQL 연산자에는 libinjection이 필요합니다.SecRemoteRules 지시문에는 curl이 필요합니다.이러한 라이브러리가 없으면 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 사용 방법에 대한 간단한 예제가 있습니다. 아래에 그중 일부가 설명되어 있습니다:
using ModSecurity::ModSecurity;
using ModSecurity::Rules;
using ModSecurity::Transaction;
ModSecurity *modsec;
ModSecurity::Rules *rules;
modsec = new ModSecurity();
rules = new Rules();
rules->loadFromUri(rules_file);
Transaction *modsecTransaction = new Transaction(modsec, rules);
modsecTransaction->processConnection("127.0.0.1");
if (modsecTransaction->intervention()) {
std::cout << "There is an intervention" << std::endl;
}
#include "modsecurity/modsecurity.h"
#include "modsecurity/transaction.h"
char main_rule_uri[] = "basic_rules.conf";
int main (int argc, char **argv)
{
ModSecurity *modsec = NULL;
Transaction *transaction = NULL;
Rules *rules = NULL;
modsec = msc_init();