ModSecurity® Reference Manual

목차 ModSecurity® 참조 설명서 v2.5.13 현재 v2.6 v2.7 v2.8 v2.9 v3.0 (rc) 저작권 © 2004-2017 [https://www.trustwave.com/ Trustwave Holdings, Inc.] 목차 소개 실시간 모니터링 및 공격 탐지 공격 방지 및 가상 패치 유연한 규칙 엔진 임베디드 모드 배포 네트워크 기반 배포 이식성 라이센스 OWASP ModSecurity 핵심 규칙 집합 (CRS) 프로젝트 개요 핵심 규칙 내용 아파치 설치 선결 요건 ModSecurity 2.x는 Apache 2.0.x 이상에서만 작동합니다. mod_uniqueid libapr과 libapr-util libpcre libxml2 liblua v5.1.x libcurl v7.15.1 이상 설치 방법 GitHub 액세스 안정적인 릴리스 다운로드 설치 단계 유닉스 Windows (MS VC ++ 8) 메인 아파치 httpd 설정 파일 (보통 httpd.conf)을 편집하십시오. ModSecurity 구성 아파치 웹 서버 시작하기 NGINX 설치 NGINX에 수동으로 ModSecurity 모듈 설치 사전 설치 단계 설치 단계 구성 단계 Microsoft IIS 용 설치 IIS에서 ModSecurity 모듈 설치 수동 설치 및 문제 해결 구성 일반적인 문제 구성 지시어 SecAction SecArgumentSeparator SecAuditEngine SecAuditLog SecAuditLog2 SecAuditLogDirMode SecAuditLogFormat SecAuditLogFileMode SecAuditLogParts SecAuditLogRelevantStatus SecAuditLogStorageDir SecAuditLogType SecCacheTransformations SecChrootDir SecCollectionTimeout SecComponentSignature SecConnEngine SecContentInjection SecCookieFormat SecCookieV0Separator SecDataDir SecDebugLog SecDebugLogLevel SecDefaultAction SecDisableBackendCompression SecHashEngine SecHashKey SecHashParam SecHashMethodRx SecHashMethodPm SecGeoLookupDb SecGsbLookupDb SecGuardianLog SecHttpBlKey SecInterceptOnError SecMarker SecPcreMatchLimit SecPcreMatchLimitRecursion SecPdfProtect SecPdfProtectMethod SecPdfProtectSecret SecPdfProtectTimeout SecPdfProtectTokenName SecReadStateLimit SecConnReadStateLimit SecSensorId SecWriteStateLimit SecConnWriteStateLimit SecRemoteRules SecRemoteRulesFailAction SecRequestBodyAccess SecRequestBodyInMemoryLimit SecRequestBodyLimit SecRequestBodyNoFilesLimit SecRequestBodyLimitAction SecResponseBodyLimit SecResponseBodyLimitAction SecResponseBodyMimeType SecResponseBodyMimeTypesClear SecResponseBodyAccess SecRule SecRuleInheritance SecRuleEngine SecRulePerfTime SecRuleRemoveById SecRuleRemoveByMsg SecRuleRemoveByTag SecRuleScript SecRuleUpdateActionById SecRuleUpdateTargetById SecRuleUpdateTargetByMsg SecRuleUpdateTargetByTag SecServerSignature SecStatusEngine SecStreamInBodyInspection SecStreamOutBodyInspection SecTmpDir SecUnicodeMapFile SecUnicodeCodePage SecUploadDir SecUploadFileLimit SecUploadFileMode SecUploadKeepFiles SecWebAppId SecXmlExternalEntity Processing Phases Phase Request Headers Phase Request Body Phase Response Headers Phase Response Body Phase Logging 변수 ARGS ARGS_COMBINED_SIZE ARGS_GET ARGS_GET_NAMES ARGS_NAMES ARGS_POST ARGS_POST_NAMES AUTH_TYPE DURATION ENV FILES FILES_COMBINED_SIZE FILES_NAMES FULL_REQUEST FULL_REQUEST_LENGTH FILES_SIZES FILES_TMPNAMES FILES_TMP_CONTENT GEO HIGHEST_SEVERITY INBOUND_DATA_ERROR MATCHED_VAR MATCHED_VARS MATCHED_VAR_NAME MATCHED_VARS_NAMES MODSEC_BUILD MULTIPART_CRLF_LF_LINES MULTIPART_FILENAME MULTIPART_NAME MULTIPART_STRICT_ERROR MULTIPART_UNMATCHED_BOUNDARY OUTBOUND_DATA_ERROR PATH_INFO PERF_ALL PERF_COMBINED PERF_GC PERF_LOGGING PERF_PHASE1 PERF_PHASE2 PERF_PHASE3 PERF_PHASE4 PERF_PHASE5 PERF_RULES PERF_SREAD PERF_SWRITE QUERY_STRING REMOTE_ADDR REMOTE_HOST REMOTE_PORT REMOTE_USER REQBODY_ERROR REQBODY_ERROR_MSG REQBODY_PROCESSOR REQUEST_BASENAME REQUEST_BODY REQUEST_BODY_LENGTH REQUEST_COOKIES REQUEST_COOKIES_NAMES REQUEST_FILENAME REQUEST_HEADERS REQUEST_HEADERS_NAMES REQUEST_LINE 요청하기 REQUEST_PROTOCOL REQUEST_URI REQUEST_URI_RAW RESPONSE_BODY RESPONSE_CONTENT_LENGTH RESPONSE_CONTENT_TYPE RESPONSE_HEADERS RESPONSE_HEADERS_NAMES RESPONSE_PROTOCOL RESPONSE_STATUS 규칙 SCRIPT_BASENAME SCRIPT_FILENAME SCRIPT_GID SCRIPT_GROUPNAME SCRIPT_MODE SCRIPT_UID SCRIPT_USERNAME SDBM_DELETE_ERROR SERVER_ADDR SERVER_NAME SERVER_PORT SESSION SESSIONID STATUS_LINE STREAM_INPUT_BODY STREAM_OUTPUT_BODY TIME TIME_DAY TIME_EPOCH TIME_HOUR TIME_MIN TIME_MON TIME_SEC TIME_WDAY TIME_YEAR TX UNIQUE_ID URLENCODED_ERROR USERID USERAGENT_IP WEBAPPID WEBSERVER_ERROR_LOG XML 변환 함수 base64Decode sqlHexDecode base64DecodeExt base64Encode cmdLine compressWhitespace cssDecode escapeSeqDecode hexDecode hexEncode htmlEntityDecode jsDecode length lowercase md5 none normalisePath normalizePath normalisePathWin normalizePathWin parityEven7bit parityOdd7bit parityZero7bit removeNulls removeWhitespace replaceComments removeCommentsChar removeComments replaceNulls urlDecode uppercase urlDecodeUni urlEncode utf8toUnicode sha1 trimLeft trimRight trim 행위 정확성 허용하다 추가하다 감사 로그 블록 포착 체인 CTL 부정하다 deprecatevar 하락 임원 expirevar 신분증 initcol 로그 로그 데이터 성숙 msg 멀티 매치 noauditlog 노고 패스 중지 단계 앞에 붙이다 대리 리디렉션 회전 sanitiseArg sanitiseMatched sanitiseMatchedBytes sanitiseRequestHeader sanitiseResponseHeader 엄격 setuid setrsc setsid 세트 엔브 세트 바 버킷 skipAfter 지위 티 꼬리표 ver xmlns 연산자 시작과 함께 포함하다 containsWord detectSQLi detectXSS endsWith 퍼지 해시 eq GE geoLookup gsbLookup gt inspectFile ipMatch ipMatchF ipMatchFromFile 르 lt 일치하지 않음 오후 pmf pmFromFile rbl rsub rx 스트레치 발목 잡기 무조건 일치 validateByteRange validateDTD validateHash validateSchema validateUrlEncoding validateUtf8Encoding verifyCC verifyCPF verifySSN 이내에 매크로 확장 영구 저장 장치 기타 주제 mod_log_config를 통한 Apache 로그인 다른 Apache 모듈에 비해 ModSecurity의 우선 순위 권장 기본 구성 임피던스 불일치 PHP 애플리케이션의 임피던스 불일치

ModSecurity® 참조 설명서

v2.5.13 현재 v2.6 v2.7 v2.8 v2.9 v3.0 (rc)

저작권 © 2004-2017 Trustwave Holdings, Inc.

목차

소개

ModSecurity는 웹 응용 프로그램 방화벽 (WAF)입니다. 웹 응용 프로그램 수준에서 공격의 70 % 이상이 수행되므로 조직은 시스템 보안을 유지하는 데 필요한 모든 도움을 필요로합니다. WAF는 웹 응용 프로그램에 도달하기 전에 공격을 탐지 및 / 또는 방지하기 위해 증가 된 외부 보안 계층을 구축하기 위해 배포됩니다. ModSecurity는 웹 응용 프로그램에 대한 다양한 공격으로부터 보호하며 기존 인프라를 거의 또는 전혀 변경하지 않고 HTTP 트래픽 모니터링과 실시간 분석을 허용합니다.

== HTTP Traffic Logging == SecGsbLookupDb 웹 서버는 일반적으로 마케팅 분석에 유용한 형식으로 트래픽을 로깅 할 수 있도록 잘 준비되어 있지만 웹 애플리케이션에 대한 트래픽 로깅은 짧습니다. 특히, 대부분은 요청 본문을 로깅 할 수 없습니다. 적수는 이것을 알고 있기 때문에 POST 요청을 통해 대부분의 공격이 수행되어 시스템이 눈을 멀게합니다. ModSecurity는 전체 HTTP 트랜잭션 로깅을 가능하게하여 완전한 요청과 응답을 기록 할 수있게합니다. 또한 로깅 기능을 사용하면 로깅되는 대상과시기에 대해 세밀한 결정을 내릴 수 있으므로 관련 데이터 만 기록되도록 할 수 있습니다. 일부 요청 및 / 또는 응답에는 특정 필드에 중요한 데이터가 포함될 수 있으므로 ModSecurity는 감사 로그에 기록되기 전에 이러한 필드를 마스크하도록 구성 될 수 있습니다.

실시간 모니터링 및 공격 탐지

ModSecurity는 로깅 기능을 제공 할뿐만 아니라 공격을 탐지하기 위해 HTTP 트래픽을 실시간으로 모니터링 할 수 있습니다. 이 경우 ModSecurity는 웹 침입 탐지 도구로 작동하여 웹 시스템에서 발생하는 의심스러운 이벤트에 대응할 수 있습니다.

공격 방지 및 가상 패치

ModSecurity는 또한 공격이 당신의 웹 애플리케이션에 도달하는 것을 막기 위해 즉시 행동 할 수 있습니다. 일반적으로 사용되는 세 가지 방법이 있습니다.

1. 부정적인 보안 모델. 부정적인 보안 모델은 비정상적인 동작, 비정상적인 동작 및 일반적인 웹 응용 프로그램 공격에 대한 요청을 모니터링합니다. 각 요청, IP 주소, 응용 프로그램 세션 및 사용자 계정에 대한 예외 점수를 유지합니다. 높은이 상 점수를 가진 요청은 모두 기록되거나 거부됩니다.
2. 긍정적 인 보안 모델입니다. 긍정적 인 보안 모델이 배포되면 유효한 것으로 알려진 요청 만 수락되고 나머지는 거부됩니다. 이 모델에는 보호하려는 웹 응용 프로그램에 대한 지식이 필요합니다. 따라서 긍정적 인 보안 모델은 많이 사용되지만 드물게 업데이트되어 모델 유지 관리가 최소화 된 응용 프로그램에서 가장 잘 작동합니다.
3. 알려진 약점 및 취약점. 규칙 언어는 ModSecurity를 ​​이상적인 외부 패치 도구로 만듭니다. 외부 패치 (Virtual Patching이라고도 함)는 기회 창을 줄이는 것입니다. 응용 프로그램 취약점을 패치하는 데 필요한 시간은 종종 많은 조직에서 몇 주까지 걸립니다. ModSecurity를 ​​사용하면 응용 프로그램 소스 코드를 건드리지 않고 (심지어 액세스 권한이 없어도) 외부에서 패치를 적용 할 수 있으므로 응용 프로그램에 적절한 패치가 적용될 때까지 시스템을 안전하게 유지할 수 있습니다.

유연한 규칙 엔진

ModSecurity의 핵심에는 유연한 규칙 엔진이 있습니다. ModSecurity Rule Language는 HTTP 트랜잭션 데이터로 작업하도록 특수화 된 프로그래밍 언어 인 ModSecurity Rule Language를 구현합니다. ModSecurity Rule Language는 사용하기 쉬우면서도 유연하게 설계되었습니다. 일반적인 작업은 간단하지만 복잡한 작업이 가능합니다. ModSecurity에 포함 된 Certified ModSecurity Rules에는 범용 보안 강화, 프로토콜 유효성 검사 및 일반적인 웹 응용 프로그램 보안 문제 감지를 구현하는 포괄적 인 규칙 집합이 포함되어 있습니다. 이 규칙은 학습 도구로 많이 사용될 수 있습니다.

임베디드 모드 배포

ModSecurity는 웹 서버가 Apache, IIS7 또는 Nginx 인 경우 기존 웹 서버 인프라의 일부로 배포 할 수있는 임베디드 웹 응용 프로그램 방화벽입니다. 이 배포 방법에는 다음과 같은 이점이 있습니다.

1. 기존 네트워크는 변경되지 않습니다. ModSecurity를 ​​기존 웹 서버에 추가하는 데 몇 분 밖에 걸리지 않습니다. 또한 기본적으로 완전히 수동적으로 설계 되었기 때문에 점진적으로 배포하고 필요한 기능 만 사용하면됩니다. 필요한 경우 제거하거나 비활성화하는 것도 쉽습니다.
2. 단일 실패 지점이 없습니다. 네트워크 기반 배포와 달리 시스템에 새로운 장애 지점을 추가하지는 않습니다.
3. 암시 적로드 균형 조정 및 확장 ModSecurity는 웹 서버에 내장되어 작동하기 때문에 추가로드 균형 조정 및 확장 기능을 자동으로 활용합니다. 기존 시스템에로드 밸런싱 및 스케일링이 필요하지 않으면로드 밸런싱 및 스케일링을 고려할 필요가 없습니다.
4. 최소한의 오버 헤드. 웹 서버 프로세스 내부에서 작동하기 때문에 네트워크 통신에 대한 오버 헤드가없고 구문 분석 및 데이터 교환에 소요되는 오버 헤드가 최소화됩니다.
5. 암호화되거나 압축 된 컨텐츠에는 문제가 없습니다. 많은 IDS 시스템은 SSL 트래픽을 분석하는 데 어려움이 있습니다. 이는 트래픽이 해독되고 압축 해제 될 때 작동하도록 위치하기 때문에 ModSecurity에는 문제가되지 않습니다.

네트워크 기반 배포

ModSecurity는 역방향 프록시 서버의 일부로 배포 할 때도 동일하게 작동하며 많은 고객이이를 선택합니다. 이 시나리오에서 ModSecurity를 ​​한 번 설치하면 여러 개의 백엔드 웹 서버를 보호 할 수 있습니다.

이식성

ModSecurity는 다양한 운영 체제에서 잘 작동하는 것으로 알려져 있습니다. 고객은 Linux, Windows, Solaris, FreeBSD, OpenBSD, NetBSD, AIX, Mac OS X 및 HP-UX에서 성공적으로 실행합니다.

라이센스

ModSecurity는 Apache Software License v2에서 사용할 수 있습니다. http://www.apache.org/licenses/LICENSE-2.0.txt

참고 : ModSecurity, mod_security, ModSecurity Pro 및 ModSecurity Core Rules는 Trustwave Holdings, Inc.의 상표 또는 등록 상표입니다.

OWASP ModSecurity Core Rule Set (CRS) Project

개요

ModSecurity는 자체적으로 보호 기능을 거의 제공하지 않는 웹 응용 프로그램 방화벽 엔진입니다. 유용하게 사용하려면 ModSecurity가 규칙으로 구성되어야합니다. 사용자가 ModSecurity를 ​​최대한 활용할 수 있도록 Trustwave의 SpiderLabs에서는 OWASP ModSecurity Core 규칙 세트 (CRS) 프로젝트를 만들었습니다. 알려진 취약점에 고유 한 서명에 의존하는 침입 탐지 및 방지 시스템과 달리 CRS는 웹 응용 프로그램에서 흔히 발견되는 알려지지 않은 취약점으로부터 일반적인 보호 기능을 제공합니다. CRS는 ModSecurity의 단계별 배포 가이드로 사용할 수 있도록 크게 언급되었습니다. 최신 규칙 패키지는 OWASP ModSecurity CRS Project Site 에서 찾을 수 있습니다 .

Core Rules Content

일반적인 웹 응용 프로그램 보호 기능을 제공하기 위해 CRS는 다음 예제 기술 중 일부를 사용합니다.

• HTTP 보호 - HTTP 프로토콜 및 로컬 정의 사용 정책의 위반을 탐지합니다.
• 공통 웹 공격 보호 - 일반적인 웹 애플리케이션 보안 공격 탐지.
• 자동화 탐지 - 봇, 크롤러, 스캐너 및 기타 표면 악의적 인 활동을 탐지합니다.
• Trojan Protection - 트로이 목마에 대한 액세스를 탐지합니다.
• 오류 숨기기 - 서버에서 보낸 오류 메시지를 가장합니다.

아파치 설치(Installation for Apache)

선결 요건(Prerequisites)

ModSecurity 2.x는 Apache 2.0.x 이상에서만 작동합니다.

ModSecurity 팀은 ModSecurity 버전 2.x가 모든 버전의 Apache 2.x 이상에서 작동 할 수 있도록 최선을 다하고 있습니다. 모든 버전 (2.2.x, 2.4.x 또는 2.6.x)에서 비 호환성을 발견하면 즉시 ModSecurity 팀에 알려주십시오.

mod_uniqueid

mod_unique_id설치 했는지 확인하십시오 . mod_unique_id는 Apache httpd와 함께 제공됩니다.

libapr과 libapr-util

libapr 및 libapr-util - http://apr.apache.org/

libpcre

http://www.pcre.org/

libxml2

http://xmlsoft.org/downloads.html

liblua v5.1.x

이 라이브러리는 선택 사항이며 새로운 Lua 엔진 ( http://www.lua.org/download.html)을 사용하는 경우에만 필요합니다 .

참고 : ModSecurity에는 동적 라이브러리가 필요합니다. 소스 배포판에는 기본적으로 빌드되지 않으므로 바이너리 배포가 권장됩니다.

libcurl v7.15.1 이상

ModSecurity Log Collector (mlogc)를 사용하여 중앙 저장소에 감사 로그를 보내려면 curl 라이브러리가 필요합니다.

http://curl.haxx.se/libcurl/

참고 : 많은 사람들이 SSL / TLS 지원을 위해 GnuTLS 라이브러리와 링크 된 libcurl에 문제가있었습니다. openssl 라이브러리는 libcurl의 SSL / TLS 지원에 사용하는 것이 좋습니다.

설치 방법

설치를 시작하기 전에 선호하는 설치 방법을 선택해야합니다. 먼저 ModSecurity의 최신 버전을 git (최상의 기능이지만 불안정 할 수도 있음)에서 직접 설치할지 또는 최신 안정 버전 (권장)을 사용할지 선택해야합니다. 안정적인 릴리스를 선택하면 바이너리에서 ModSecurity를 ​​설치할 수 있습니다. 소스 코드에서 항상 컴파일 할 수 있습니다.

다음 몇 페이지는 한 가지 방법을 다른 방법보다 많이 선택했을 때의 이점에 대해 더 많은 정보를 제공합니다.

GitHub 액세스

최신 버전의 모듈에 액세스하려면 git 저장소에서 가져와야합니다. 마지막 안정 릴리스 이후 변경된 사항 목록은 웹 사이트 (및 파일 CHANGES)에서 정상적으로 사용할 수 있습니다. ModSecurity에 대한 git 저장소는 GitHub ( http://www.github.com )에서 호스팅합니다 . 이 주소 ( https://github.com/SpiderLabs/ModSecurity)를 사용하여 웹을 통해 직접 액세스하거나 볼 수 있습니다.

가장 최근의 TRUNK 소스 코드를 컴퓨터에 다운로드하려면 다음 명령을 실행해야합니다 :

git

$ git clone git : //github.com/SpiderLabs/ModSecurity.git
$ git checkout remotes/trunk

v2.6.0 이상에서는 설치 프로세스가 변경되었습니다. 다음 단계를 따르십시오.

1. 디렉토리에 cd - $cd ModSecurity
2. autogen.sh 스크립트 실행 - $./autogen.sh
3. configure 스크립트 실행 - $./configure
4. make - $make
5. make install을 실행하십시오 - $make install
6. 새 mod_security2.so 파일을 적절한 Apache 모듈 디렉토리에 복사하십시오. $cp /usr/local/modsecurity/lib/mod_security2.so /usr/local/apache/modules/

안정적인 릴리스 다운로드

안정 버전을 다운로드하려면 http://www.modsecurity.org/download/ 을 방문하십시오 . 때때로 이진 배포판을 사용할 수 있습니다. 그럴 경우 다운로드 페이지에 나열됩니다. 소스 코드 배포판을 다운로드하지 않은 경우.

설치 단계

• Apache httpd를 중지하십시오.
• ModSecurity 아카이브의 압축을 풉니 다.
• Build

UNIX (또는 UNIX와 유사한) 운영 체제와 Windows에서는 빌드가 다릅니다.

유닉스

configure 스크립트를 실행하여 Makefile을 생성하십시오. 일반적으로 옵션은 필요하지 않습니다.

./configure

더 많은 사용자 정의를 위해 옵션을 사용할 수 있습니다 (전체 목록은 ./configure --help 사용). 일반적으로 Apache httpd에 --with-apxs 옵션과 함께 설치되는 apxs 명령의 위치 만 지정하면됩니다.

./configure --with-apxs = / path / to / httpd-2.xy / bin / apxs

참고 : 다른 개발 용도를 디버깅하기위한 특정 구성 옵션이 있습니다. 이 옵션을 사용하면 성능에 큰 영향을 줄 수 있습니다. 이러한 옵션에는 --debug- * 옵션과 --enable-performance-measurements 옵션이 모두 포함됩니다.

컴파일 대상 :

make

선택 사항 :

make CFLAGS=-DMSC_TEST test

참고 :이 단계는 아직 약간 실험적입니다. 문제가있는 경우 빌드에서 전체 출력 및 오류를 지원 목록으로 보내주십시오. 가장 일반적인 문제는 필요한 헤더 및 / 또는 라이브러리를 찾지 못하는 것과 관련이 있습니다.

선택적으로 다음을 사용하여 ModSecurity Log Collector를 빌드하십시오.

make mlogc

선택적으로 mlogc를 설치하십시오. 배포판의 apache2 / mlogc-src 디렉토리에 포함 된 INSTALL 파일을 검토하십시오. 다음과 같이 ModSecurity 모듈을 설치하십시오.

make install

Windows (MS VC ++ 8)

Makefile.win을 편집하여 Apache 기본 및 라이브러리 경로를 구성하십시오. 다음으로 컴파일 nmake -f Makefile.win 하십시오. ModSecurity 모듈을 다음 과 같이 설치하십시오 nmake -f Makefile.win install . libxml2.dll 및 lua5.1.dll을 Apache bin 디렉토리로 복사하십시오. 또는 LoadFile을 사용하여 이러한 라이브러리를로드하려면 아래 단계를 수행하십시오.

참고 : 사용자는 README_WINDOWS.txt의 단계를 따라 ModSecurity tarball을 따라야합니다.

메인 아파치 httpd 설정 파일 (보통 httpd.conf)을 편집하십시오.

UNIX에서 (그리고 위에서 설명한 것처럼 DLL을 복사하지 않았다면) ModSecurity 전에 libxml2와 lua5.1을 다음과 같이로드해야합니다 :

LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so

ModSecurity 모듈을 다음과 같이로드하십시오 :

LoadModule security2_module 모듈 / mod_security2.so

ModSecurity 구성

아파치 웹 서버 시작하기

이제 ModSecurity 2.x를 실행해야합니다.

참고 : 아파치를 직접 컴파일 한 경우 PCRE에 대해 ModSecurity를 ​​컴파일 할 때 문제가 발생할 수 있습니다. 이는 Apache가 PCRE를 번들로 제공하지만이 라이브러리는 일반적으로 운영 체제에서 제공되기 때문입니다. 나는 대부분의 (모든) 벤더 패키지 아파치 배포판이 외부 PCRE 라이브러리를 사용하도록 구성되기를 기대하기 때문에 (그렇게해서는 안된다.)

당신은 번들 된 PCRE 라이브러리와 운영체제가 제공하는 것과 연결된 ModSecurity를 ​​사용하여 아파치를 피하기를 원한다. 이를 수행하는 가장 쉬운 방법은 운영체제가 제공하는 PCRE 라이브러리에 대해 Apache를 컴파일하는 것입니다 (또는 PCRE 배포 사이트에서 다운로드 한 최신 PCRE 버전과 비교하여 컴파일 할 수 있습니다). --with-pcre 스위치를 사용하여 구성시이 작업을 수행 할 수 있습니다. Apache를 다시 컴파일 할 수있는 위치에 있지 않다면 ModSecurity를 ​​성공적으로 컴파일하려면 번들로 제공된 PCRE 헤더 (Apache 소스 코드에서만 사용 가능)에 액세스해야하며 ModSecurity의 포함 경로를 변경해야합니다 (위의 7 단계에서와 같이) --with-pcre ModSecurity configure 옵션을 통해 그들을 가리 키도록).

아파치가 외부 PCRE 라이브러리를 사용하고 있다면, WITH_PCRE_STUDY가 정의 된 ModSecurity를 ​​컴파일 할 수 있습니다. 그러면 정규 표현식 처리에서 약간의 성능 향상을 얻을 수 있습니다.

gcc가 아닌 컴파일러는 현재 빌드 시스템이 gcc 컴파일러 주위에 설계되고 일부 컴파일러 / 링커 플래그가 다를 수 있으므로 즉시 실행하는 데 문제가있을 수 있습니다. gcc가 아닌 컴파일러를 사용하려면 사용자 정의 CFLAGS 및 CPPFLAGS 환경 변수를 내 보내서 문제를 해결할 수없는 경우 일부 수동 Makefile 수정이 필요할 수 있습니다.

ModSecurity 1.x에서 업그레이드하는 경우 http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf 의 마이그레이션 매트릭스를 참조하십시오.

ModSecurity 2.7.0부터 몇 가지 중요한 설정 옵션이 있습니다.

1. --enable-pcre-jit - regex 성능을 향상시킬 수있는 pcre> = 8.20의 JIT 지원을 활성화합니다.
2. --enable-lua-cache - 루아 스크립트 성능을 향상시킬 수있는 루아 vm 캐싱을 가능하게합니다. 차이점은 ModSecurity가 트랜잭션 당 둘 이상의 스크립트를 실행해야하는 경우에만 나타납니다.
3. --enable-request-early - ModSecurity 2.6에서 1 단계가 2 단계 후크로 이동되었습니다.이 옵션을 사용하여 주위를 재생하려면이 옵션을 사용하십시오.
4. --enable-htaccess-config - AllowOverride 옵션이 설정된 경우 .htaccess 파일에 follow 지시문을 사용할 수 있습니다.

        - SecAction
        - SecRule

        - SecRuleRemoveByMsg
        - SecRuleRemoveByTag
        - SecRuleRemoveById

        - SecRuleUpdateActionById
        - SecRuleUpdateTargetById
        - SecRuleUpdateTargetByTag
        - SecRuleUpdateTargetByMsg

NGINX 설치

nginx 서버의 확장 성 모델은 동적으로로드 된 모듈을 포함하지 않으므로 ModSecurity는 주 서버의 소스 코드로 컴파일해야합니다. nginx는 여러 Unix 기반 플랫폼에서 (그리고 Windows에서도) 사용할 수 있기 때문에 현재 nginx 용 ModSecurity를 ​​얻는 권장 방법은 지정된 환경에서 컴파일하는 것입니다.

NGINX에 수동으로 ModSecurity 모듈 설치

내장 된 ModSecurity 모듈을 가진 nginx 서버를 얻는 첫 번째 단계는 중간 API 집합을 가진 완전한 ModSecurity를 ​​포함하는 독립형 라이브러리를 구축하는 것입니다 (이 계층은 IIS 버전, nginx 버전 및 ModSecurity의 서버리스 명령 행 버전에 대한 공통 기반입니다. ). 먼저 ModSecurity 빌드 환경을 준비한 후 아래의 설치 단계를 따르십시오. 독립형 ModSecurity는 https://www.modsecurity.org/download.html에 있습니다.

사전 설치 단계

GNU / Linux 플랫폼에서 독립 실행 형 모듈을 소스에서 빌드하려면 apache 및 prce 용 표준 및 개발 패키지를 설치해야합니다. 예 :

# RHEL/CentOS style install. You may also need systemd-devel on newer versions
sudo yum install httpd-devel pcre pcre-devel libxml2-devel 

# Debian style install
apt-get install apache2-threaded-dev libxml2-dev

nginx에서 ModSecurity를 ​​컴파일해야하는 이유에 대한 자세한 내용은이 패키지가 필요합니다 ( 문제 603 참조) .

설치 단계

1. - 독립형 모듈 컴파일 :

~ / mod_security $ ./configure --enable-standalone-module --disable-mlogc
~ / mod_security $ make

mod_security 폴더의 경로와 이름은 modsecurity.org 에서 tarball을 다운로드하는 버전과 버전에 따라 다릅니다 .

2. 일단 독립형 라이브러리가 성공적으로 빌드되면 nginx 빌드 자습서의 단계에 따라 nginx 서버를 빌드 할 수 있습니다.

~ / nginx-1.2.0 $ ./configure --add-module = .. / mod_security / nginx / modsecurity
~ / nginx-1.2.0 $ make
~ / nginx-1.2.0 $ sudo make install

마지막 명령은 로컬 컴퓨터에 서버 설치를 수행합니다.이 컴퓨터는 빌드 된 바이너리가 패키지되거나 대체 서버로 이동되어 사용자 정의되거나 생략 될 수 있습니다.

구성 단계

3. ModSecurity 구성 파일은 Nginx의 ModSecurity 확장 모듈에 정의 된 다음 지시문을 사용하여 nginx.conf 파일에 링크되어야합니다. 이것은 ModSecurity를 ​​Nginx 요청 처리기로 구성합니다 (현재 요청 흐름은 request -> modsecurity handler -> backend입니다). 구성 파일은 다음과 유사하게 나타납니다.

위치 / {
           ModSecurityEnabled on;
           ModSecurityConfig modsecurity.conf;
           # 프록시를 포함 할 경우에만 필요합니다.
           proxy_pass http : // localhost : 8011;
           proxy_read_timeout 180s;
       }

modSecurity.conf 파일의 권장 샘플은 ModSecurity git 저장소 ( https://raw.githubusercontent.com/SpiderLabs/ModSecurity/master/modsecurity.conf-recommended ) 에서 찾을 수 있습니다 . 이 파일은 동일한 저장소 ( https://raw.githubusercontent.com/SpiderLabs/ModSecurity/master/unicode.mapping ) 에도있는 unicode.mapping 파일을 참조합니다 .

4. 다른 설정 파일 추가하기 (옵션) : 다중 설정 파일 (예 : OWASP CRS)을 사용하기를 원한다면 Nginx는 오직 하나의 'ModSecurityConfig'지시자만을 지원하기 때문에, 지정된 파일 내에서 'Include'지시어를 사용하기 만하면됩니다 에서 'ModSecurityConfig'. 이 지침은 APR에 의해 제공되며이 안내서에 문서화되어 있지는 않지만 사용하기에 충분히 간단합니다. modsecurity.conf의 맨 아래에 다음을 추가하면 test.conf라는 동일한 디렉토리의 파일이 포함됩니다.

Include test.conf

include 지시문은 와일드 카드 문자 (*)와 전체 경로도 지원합니다. CRS가 다운로드되어이 경로에 설치되었다고 가정하면 다음과 같은 것을 쉽게 추가 할 수 있습니다.

Include /opt/owasp-modsecurity-crs/modsecurity_crs_10_setup.conf
Include /opt/owasp-modsecurity-crs/rules/*.conf

참고 : 버전 2.7.2 이전에는 Nginx가 ModSecurityPass 지시문을 사용하여 프록시 연결을 제어했지만, 이는 앞서 언급 한 버전을 위해 제거되었습니다. ModSecurity 2.7.1 또는 이전 버전을 실행중인 경우 구성이 다음과 비슷해야합니다.

location / {
           ModSecurityEnabled on;
           ModSecurityConfig modsecurity.conf;
           ModSecurityPass @ backend;
       }

location @backend {
           proxy_pass http : // localhost : 8011;
           proxy_read_timeout 180s;
       }

이 방법을 통해 배포 할 때 Nginx가 프록 싱하고있는 올바른 백엔드 웹 응용 프로그램을 가리 키도록 @backend 정의를 수정해야합니다. 다시, ModSecurity 2.7.2부터 ModSecurityPass 옵션이 제거되었습니다.

Microsoft IIS 용 설치

ModSecurity를 ​​설치하기 전에 Visual Studio 2013 런타임 (vcredist)이 설치되어 있는지 확인하십시오. Vcredist는 http://www.visualstudio.com/downloads/download-visual-studio-vs에서 다운로드 할 수 있습니다 (두 가지 버전 32 및 64b가 있음).

ModSecurity의 IIS 구성 요소 소스 코드가 완전히 게시되고 이진 빌드 프로세스가 설명됩니다 (README_WINDOWS.TXT 참조). 빠른 설치를 위해서는 ModSecurity 프로젝트의 SourceForge 파일 저장소에서 제공되는 표준 MSI 설치 프로그램을 사용하거나 바이너리 패키지를 사용하고 수동 설치 단계를 따르는 것이 좋습니다.

설치 오류나 경고 메시지는 응용 프로그램 이벤트 로그의 'ModSecurityIIS Installer'원본에 기록됩니다.

OWASP CRS는 선택한 폴더의 시스템 드라이브에도 설치됩니다. 이 파일은 web.config 파일의 system.webServer 섹션에 다음 줄을 추가하여 모든 웹 사이트에 포함시킬 수 있습니다.

        <ModSecurity enabled = "true"configFile = "c : \ path \ to \ owasp_crs \ modsecurity_iis.conf"/>

(상대 경로도 그에 따라 사용할 수 있음)

IIS에서 ModSecurity 모듈 설치 수동 설치 및 문제 해결

구성(Configuration)

설치 후 모듈은 기본적으로 모든 웹 사이트에서 실행됩니다. 웹 사이트에서 제거하려면 web.config에 추가하십시오.

<modules>
    <remove name="ModSecurityIIS" />
</ modules>

웹 사이트에서 모듈을 구성하려면 web.config에 추가하십시오.

<? xml version = "1.0"encoding = "UTF-8"?>
<configuration>
    <system.webServer>
        <ModSecurity enabled = "true"configFile = "c : \ inetpub \ wwwroot \ xss.conf"/>
    </system.webserver>
</ configuration>

여기서 configFile은 표준 ModSecurity 구성 파일입니다.

모듈의 이벤트가 "응용 프로그램"Windows 로그에 표시됩니다.

일반적인 문제

설치 후 보호 된 웹 사이트가 HTTP 503 오류로 응답하고 이벤트 ID 2280이 응용 프로그램 이벤트 로그에 계속 기록되는 경우 :

Log Name:      Application
Source:        Microsoft-Windows-IIS-W3SVC-WP
Event ID:      2280
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Description:
The Module DLL C : \ Windows \ system32 \ inetsrv \ modsecurityiis.dll을로드하지 못했습니다. 데이터가 오류입니다.

대부분 설치 프로세스가 실패했고 ModSecurityIIS.dll 모듈에 의존하는 하나 이상의 라이브러리가 누락되었다는 것을 의미합니다. 전제 조건 W 모듈 파일의 설치를] 복하여 문제점을 수정해야합니다. 종속성 워커 도구 :

• http://www.dependencywalker.com/

누락 된 라이브러리 또는로드 할 수없는 라이브러리를 파악하는 데 사용할 수 있습니다.

구성 지시어

다음 섹션에서는 모든 ModSecurity 지시어에 대해 간략히 설명합니다. ModSecurity 지시어의 대부분은 VirtualHost, Location, LocationMatch, Directory 등과 같은 다양한 Apache Scope 지시문에서 사용할 수 있습니다. 그러나 주 구성 파일에서만 한 번만 사용할 수있는 다른 것들이 있습니다. 이 정보는 아래 범위 섹션에 명시되어 있습니다. 주어진 지시어를 사용하는 첫 번째 버전은 아래의 버전 섹션에 나와 있습니다.

이러한 규칙은 핵심 규칙 파일과 함께 httpd.conf 파일 외부의 파일에 포함되어야하며 Apache "Include"지시문을 사용하여 호출해야합니다. 이렇게하면 규칙을 쉽게 업데이트 / 마이그레이션 할 수 있습니다. 핵심 규칙과 함께 사용할 사용자 지정 규칙을 직접 만드는 경우 - modsecurity_crs_15_customrules.conf라는 파일을 만들어 핵심 규칙 파일과 동일한 디렉터리에 배치해야합니다. 이 파일 이름을 사용하면 사용자 정의 규칙이 표준 ModSecurity 코어 규칙 구성 파일 다음에 있지만 다른 핵심 규칙보다 먼저 호출됩니다. 이렇게하면 특정 "허용"규칙을 구현하거나 핵심 규칙이 사이트에 적용될 때 오 탐지 (false positive)를 수정해야하는 경우 유용 할 수있는 규칙을 먼저 평가할 수 있습니다.

참고 : 핵심 규칙 파일 자체는 편집하지 말고 모든 변경 사항 (예 : SecRuleRemoveByID, 등)을 사용자 지정 규칙 파일에 저장하는 것이 좋습니다. 새로운 코어 규칙이 릴리스 될 때 쉽게 업그레이드 할 수 있습니다.

SecAction

설명 : 첫 번째이자 유일한 매개 변수로 수신 한 작업 목록을 무조건 처리합니다. 매개 변수의 구문은의 세 번째 매개 변수의 구문과 동일합니다 SecRule.

Syntax:: SecAction "action1,action2,action3,...“

Scope: Any

Version: 2.0.0

이 지시어는 일반적으로 initcol 액션을 사용하여 변수를 설정하고 지속적 컬렉션을 초기화하는 데 사용됩니다. 예 :

SecAction nolog,phase:1,initcol:RESOURCE=%{REQUEST_FILENAME}

SecArgumentSeparator

설명 : application / x-www-form-urlencoded 콘텐츠의 구분자로 사용할 문자를 지정합니다.

Syntax: SecArgumentSeparator character

기본값 : &

범위 : 기본 (<2.7.0), 모두 (2.7.0)

버전 : 2.0.0

이 지시문은 백엔드 웹 응용 프로그램이 비표준 인수 구분 기호를 사용하는 경우 필요합니다. 세미콜론 분리 기호를 사용하기 위해 응용 프로그램을 작성하는 경우는 드뭅니다. 작업중인 응용 프로그램에 다른 구분 기호가 필요하다는 것을 확인하지 않는 한 기본 설정을 변경하지 마십시오. 이 지시어가 각 웹 어플리케이션에 대해 적절하게 설정되지 않으면, ModSecurity는 인수를 적절하게 구문 분석 할 수 없으며 규칙 일치의 효율성이 현저히 떨어집니다.

SecAuditEngine

설명 : 감사 로깅 엔진을 구성합니다.

Syntax: SecAuditEngine RelevantOnly

기본값 : 꺼짐

범위 : 모든

버전 : 2.0.0

SecAuditEngine 지정 문은 전체 트랜잭션을 기록하는 감사 엔진을 구성하는 데 사용됩니다. ModSecurity는 현재 모든 트랜잭션이 아닌 대부분의 로그를 기록 할 수 있습니다. 오류 (예 : 400 및 404 트랜잭션)와 관련된 트랜잭션은 ModSecurity가 지원하지 않는 다른 실행 경로를 사용합니다.

감사 로그 엔진에 사용할 수있는 값은 다음과 같습니다.

• 켜기 : 모든 트랜잭션 로그
• 꺼짐 : 트랜잭션을 기록하지 않습니다.
• RelevantOnly : 경고 또는 오류를 유발 한 로그 트랜잭션 또는 관련성이 있다고 간주되는 상태 코드가있는 트랜잭션 (SecAuditLogRelevantStatus 지시어에 의해 결정됨)

주 : 트랜잭션 로그 단위로 (예 : 일부 트랜잭션 데이터에 대한 응답으로) 감사 로그 엔진 구성을 변경해야하는 경우 ctl 조치를 사용하십시오.

다음 예제에서는 SecAuditEngine이 사용되는 방법을 보여줍니다.

SecAuditEngine RelevantOnly
SecAuditLog는 / audit / audit.log를 기록합니다.
SecAuditLogParts ABCFHZ 
SecAuditLogType 동시 
SecAuditLogStorageDir 로그 / 감사 
SecAuditLogRelevantStatus ^ (?: 5 | 4 (?! 04))

SecAuditLog

설명 : 기본 감사 로그 파일 (직렬 로깅 형식) 또는 동시 로깅 색인 파일 (동시 로깅 형식)에 대한 경로를 정의합니다. mlogc (병행 로깅에서만 가능)와 함께 사용하는 경우이 지시문은 mlogc 위치와 명령 행을 정의합니다.

Syntax: SecAuditLog /path/to/audit.log

범위 : 모든 버전 : 2.0.0

이 파일은 직렬 감사 로깅 형식을 사용하는 경우 감사 로그 항목을 저장하는 데 사용됩니다. 동시 감사 로깅 형식을 사용하는 경우이 파일은 색인으로 사용되며 작성된 모든 감사 로그 파일의 레코드를 포함합니다. 동시 감사 로깅을 사용하여 감사 로그 데이터를 원격 서버로 보내려면 다음과 같이 ModSecurity Log Collector (mlogc)를 배포해야합니다.

SecAuditLog "/ path / to / mlogc /path/to/mlogc.conf"

주 :이 감사 로그 파일은 일반적으로 서버가 여전히 루트로 실행 중일 때 시작시 열립니다. 루트가 아닌 사용자가이 파일이나 디렉토리에 대한 쓰기 권한을 가질 수 없도록해야합니다.

SecAuditLog2

설명 : 동시 로깅이 사용 가능할 때 2 차 감사 로그 색인 파일에 대한 경로를 정의합니다. 자세한 내용은 SecAuditLog를 참조하십시오.

Syntax: SecAuditLog2 /path/to/audit.log

범위 : 모든

버전 : 2.1.2

SecAuditLog2의 목적은 두 개의 원격 서버에 대한 로깅을 가능하게하는 것입니다.이 작업은 일반적으로 mlogc 도구의 두 인스턴스를 각각 다른 구성으로 실행하여 수행됩니다 (또한 인스턴스 중 하나에 파일을 삭제하지 않도록 지시해야합니다 제출). 이 지시문은 SecAuditLog가 이전에 구성되었고 동시 로깅 형식이 사용되는 경우에만 사용할 수 있습니다.

SecAuditLogDirMode

설명 : 8 진 모드 값을 매개 변수 (chmod에서 사용됨)를 사용하여 동시 감사 로그에 대해 작성된 모든 디렉토리의 모드 (권한)를 구성합니다.

Syntax: SecAuditLogDirMode octal_mode|"default"

기본값 : 0600

범위 : 모든

버전 : 2.5.10

새 감사 로그 디렉토리 (0600)의 기본 모드는 소유자 (일반적으로 Apache가 실행되는 계정 (예 : apache))에 대한 읽기 / 쓰기 권한 만 부여합니다. 다른 계정에서 액세스해야하는 경우 (예 : mpm-itk 사용)이 지시문을 사용하여 추가 읽기 및 쓰기 권한을 부여 할 수 있습니다. 잠재적으로 중요한 데이터가 권한이없는 사용자에게 노출되지 않도록하려면이 지정 문을주의해서 사용해야합니다. 값을 매개 변수로 사용하면 구성이 기본 설정으로 되돌아갑니다. 이 기능은 8 진 파일 모드를 지원하지 않는 운영 체제에서는 사용할 수 없습니다.

예:

SecAuditLogDirMode 02750

주 : 프로세스 umask는이 지정 문을 사용하여 설정된 모드보다 더 제한적인 경우 여전히 모드를 제한 할 수 있습니다.

SecAuditLogFormat

설명 : AuditLog의 출력 형식을 선택하십시오. 형식은 기본 AuditLogs 형식 또는 JSON 일 수 있습니다.

Syntax: SecAuditLogFormat JSON|Native

기본값 : 기본

범위 : 모든

버전 : 2.9.1

참고 : JSON 형식은 ModSecurity가 YAJL 라이브러리를 통해 JSON을 지원하도록 컴파일 된 경우에만 사용할 수 있습니다. 컴파일하는 동안 yajl-dev 패키지 (또는 이와 유사한 패키지)가 시스템의 일부 여야합니다. configure 스크립트는 YAJL 지원이 활성화되었는지 여부를 알려줍니다.

SecAuditLogFileMode

설명 : 8 진 모드 (chmod에서 사용됨)를 사용하여 동시 감사 로그 용으로 작성된 파일의 모드 (권한)를 구성합니다. 생성 된 감사 로그 디렉토리의 모드를 제어하려면 SecAuditLogDirMode를 참조하십시오.

Syntax: SecAuditLogFileMode octal_mode|"default"

기본값 : 0600

범위 : 모든

버전 : 2.5.10

사용 예 : SecAuditLogFileMode 00640

이 기능은 8 진 파일 모드를 지원하지 않는 운영 체제에서는 사용할 수 없습니다. 기본 모드 (0600)는 파일을 쓰는 계정에만 읽기 / 쓰기 권한을 부여합니다. 다른 계정에서 액세스해야하는 경우 (mpm-itk를 사용하는 것이 좋습니다)이 지시문이 필요할 수 있습니다. 그러나 잠재적으로 중요한 데이터가 권한이없는 사용자에게 노출되지 않도록하려면이 지정 문을주의해서 사용하십시오. "default"값을 사용하면 기본 설정으로 되돌아갑니다.

주 : 프로세스 umask는이 지정 문을 사용하여 설정된 모드보다 더 제한적인 경우 여전히 모드를 제한 할 수 있습니다.

SecAuditLogParts

설명 : 감사 로그에 기록 할 각 트랜잭션의 부분을 정의합니다. 각 부분에는 하나의 문자가 할당됩니다. 편지가 목록에 나타나면 해당 부분이 녹음됩니다. 모든 부품 목록은 아래를 참조하십시오.

Syntax: SecAuditLogParts PARTLETTERS

사용 예 : SecAuditLogParts ABCFHZ

범위 : 모든 버전 : 2.0.0

기본값 : ABCFHZ 참고

감사 로그 형식의 형식은 감사 로그 데이터 형식 문서에 자세히 설명되어 있습니다.

사용 가능한 감사 로그 부분 :

• A : 감사 로그 헤더 (필수).
• B : 헤더를 요청하십시오.
• C : 요청 본문 (요청 본문이 존재하고 ModSecurity가이를 가로 채기 위해 구성되어있는 경우에만 존재 함)이 경우 SecRequestBodyAccess를 on으로 설정해야합니다.
• D : 중간 응답 헤더 용으로 예약 됨. 아직 구현되지 않았습니다.
• E : 중개자 응답 본문 (ModSecurity가 응답 본문을 가로 채기 위해 구성되고 감사 로그 엔진이이를 기록하도록 구성된 경우에만 표시됨) 응답 본문 차단은 SecResponseBodyAccess를 사용하도록 설정해야합니다. 중간 응답 본문은 ModSecurity가 중간 응답 본문을 가로 채지 않는 한 실제 응답 본문과 동일합니다.이 경우 실제 응답 본문에 오류 메시지 (Apache 기본 오류 메시지 또는 ErrorDocument 페이지)가 포함됩니다.
• F : 최종 응답 헤더 (날짜 및 서버 헤더 제외, 컨텐츠 전달의 후반부에 항상 Apache에 추가됨).
• G : 실제 응답 본문에 예약되어 있습니다. 아직 구현되지 않았습니다.
• H : 감사 로그 트레일러.
• I :이 부분은 부분 C를 대체합니다. 다중 부분 / 양식 데이터 인코딩이 사용되는 경우를 제외하고는 모든 경우에 C와 동일한 데이터를 로깅합니다. 이 경우 매개 변수에 대한 정보는 포함하고 파일에 대한 정보는 포함하지 않는 가짜 응용 프로그램 / x-www-form-urlencoded 본문을 기록합니다. 감사 로그에 (대개 큰) 파일을 저장하지 않으려면이 방법이 유용합니다.
• J :이 부분은 멀티 파트 / 폼 데이터 인코딩을 사용하여 업로드 된 파일에 대한 정보를 포함합니다.
• K :이 부분은 매치 된 순서로 (매 줄마다) 일치하는 모든 규칙의 전체 목록을 포함합니다. 규칙은 완전하며 따라서 상속 된 조치 및 기본 운영자를 보여줍니다. v2.5.0부터 지원됩니다.
• Z : 최종 경계, 항목의 끝을 나타냅니다 (필수).

SecAuditLogRelevantStatus

설명 : 감사 로깅의 목적에 적합한 응답 상태 코드를 구성합니다.

Syntax: SecAuditLogRelevantStatus REGEX

사용 예 : SecAuditLogRelevantStatus "^(?:5|4(?!04))"

범위 : 모든

버전 : 2.0.0

종속성 / 메모 : SecAuditEngine을 RelevantOnly로 설정해야합니다. 또한 기본적으로 감사 로그 작업이 규칙에 존재하므로 엔진이 'SecAuditLogRelevantStatus'를 무시하고 상태와 상관없이 규칙 일치를 감사 로그에 보냅니다. 규칙에 noauditlog를 수동으로 지정하거나 SecDefaultAction에 설정해야합니다.

이 지정 문의 주된 목적은 제공된 정규 표현식과 일치하는 상태 코드가있는 트랜잭션에 대해서만 감사 로깅을 구성 할 수있게하는 것입니다. 제공된 예제는 404를 제외한 모든 5xx 및 4xx 레벨 상태 코드를 기록합니다. 5 단계에서 규칙을 적용해도 동일한 효과를 얻을 수 있지만 SecAuditLogRelevantStatus는 SecRuleEngine이 비활성화 된 경우에도 계속 작동하기 때문에 더 나은 경우가 있습니다.

SecAuditLogStorageDir

설명 : 동시 감사 로그 항목이 저장 될 디렉토리를 구성합니다.

구문 :SecAuditLogStorageDir /path/to/storage/dir

사용 예 : SecAuditLogStorageDir /usr/local/apache/logs/audit 

범위 : 모든

버전 : 2.0.0

이 지정 문은 동시 감사 로깅을 사용할 경우에만 필요합니다. 디렉토리는 이미 존재해야하며 웹 서버 사용자가 쓸 수 있어야합니다. 감사 로그 항목은 Apache가 비 루트 계정으로 전환 한 후 런타임에 작성됩니다. 모든 로깅 메커니즘과 마찬가지로, 충분한 디스크 공간이 있고 주 시스템 파티션에없는 파일 시스템 위치를 지정해야합니다.

SecAuditLogType

설명 : 사용할 감사 로깅 메커니즘의 유형을 구성합니다.

Syntax: SecAuditLogType Serial|Concurrent|HTTPS 

사용 예 : SecAuditLogType Serial

범위 : 모든

버전 : 2.0.0

가능한 값은 다음과 같습니다.

일련 : 감사 로그 항목은 SecAuditLog에 의해 지정된 단일 파일에 저장됩니다. 이것은 일상적인 사용에 편리하지만 한 번에 하나의 감사 로그 항목 만 파일에 기록 될 수 있기 때문에 서버 속도가 느려질 수 있습니다.

동시 : 트랜잭션 당 하나의 파일이 감사 로깅에 사용됩니다. 이 접근법은 과도한 로깅이 필요할 때 (여러 트랜잭션을 동시에 기록 할 수있는 경우) 확장 성이 뛰어납니다. 원격 로깅을 사용해야하는 경우에도 유일한 선택입니다.

HTTPS :이 기능은 libModSecurity 및 현재 테스트 단계에서만 사용할 수 있습니다. 보유하고있는 요청 금액에 따라 적절할 수 있습니다. 파일의 경로 대신 엔드 포인트의 URL을 사용하십시오.

주 : HTTPS 감사 로그 유형은 현재 libModSecurity에서만 지원됩니다.

SecCache 변환

설명 : 변환 캐싱을 제어하므로 복잡한 규칙 집합 처리 속도가 빨라질 수 있습니다. 캐싱은 기본적으로 2.5.6부터 시작하여 더 이상 사용되지 않으며 실험실로 다운 그레이드됩니다.

Syntax: SecCacheTransformations On|Off [options] 

사용 예 : SecCacheTransformations On "minlen:64,maxlen:0" 

범위 : 모든

버전 : 2.5.0; 2.5.6에서 더 이상 사용되지 않습니다.

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

첫 번째 지시문 매개 변수는 다음 중 하나 일 수 있습니다.

• 켜기 : 변환을 (트랜잭션 당, 단계별로) 캐시하면 동일한 변환을 한 번만 수행 할 수 있습니다.
• 꺼짐 : 변환을 캐시하지 않고 필요할 때마다 모든 변환을 수행합니다.

다음 옵션을 사용할 수 있습니다 (여러 옵션을 쉼표로 구분해야 함).

• incremental : on | off :이 옵션을 켜면 최종 변환 대신 모든 변환이 캐시됩니다. 기본값은 off입니다.
• maxitems : N : N 개 이상의 변환을 캐시 할 수 없습니다. 이 숫자에 도달하면 캐시가 비활성화됩니다. 0 값은 무제한으로 해석됩니다. 이 옵션은 많은 수의 변수가있는 양식의 캐싱을 제한하는 데 유용 할 수 있습니다. 기본값은 512입니다.
• minlen : N : 변수의 길이가 N 바이트보다 작 으면 변환을 캐시하지 않습니다. 기본 설정은 32입니다.
• maxlen : N : 변수의 길이가 N 바이트보다 크면 변환을 캐시하지 않습니다. 0 값은 무제한으로 해석됩니다. 기본 설정은 1024입니다.

SecChrootDir

설명 : 웹 서버 프로세스를 감옥에 보낼 디렉토리 경로를 구성합니다.

Syntax: SecChrootDir /path/to/chroot/dir 

사용 예 : SecChrootDir /chroot 

범위 : Main

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

Windows 빌드에서는이 기능을 사용할 수 없습니다. ModSecurity가 제공하는 내부 chroot 기능은 간단한 설정에 유용합니다. 간단한 설정의 한 가지 예는 Apache가 정적 파일 만 제공하거나 내장 모듈을 사용하여 응용 프로그램을 실행하는 것입니다. 보다 복잡한 설정으로 인해 발생할 수있는 몇 가지 문제 :

1. DNS 조회가 작동하지 않습니다 (이 기능은 chroot가 발생한 후 필요에 따라로드되는 공유 라이브러리가 필요하기 때문입니다).
2. 감옥 밖에서 sendmail과 sendmail을 사용하기를 원하기 때문에 PHP에서 전자 메일을 보낼 수 없습니다.
3. 경우에 따라 Apache를 구성에서 분리하면 재시작 및 정상적인 재로드가 더 이상 작동하지 않습니다.

SecChrootDir을 사용하는 가장 좋은 방법은 다음과 같습니다.

1. 기본 jail 디렉토리가되도록 / chroot를 생성하십시오.
2. 감옥에 / chroot / opt / apache를 생성하십시오.
3. / opt / apache에서 / chroot / opt / apache로 심볼릭 링크를 만듭니다.
4. 이제 / chroot / opt / apache에 아파치를 설치하십시오.

내부 chroot 기능은 100 % 신뢰할 수 없다는 것을 알고 있어야합니다. Apache 웹 서버에 사용할 수있는 많은 수의 기본 및 타사 모듈로 인해 내부 chroot가 모든 모듈에서 안정적으로 작동하는지 확인할 수 없습니다. Apache 내에서 작업하는 모듈은 감옥에서 탈출하기 쉬운 일을 할 수 있습니다. 특히, 모듈 초기화 단계 (mod_fastcgi, mod_fcgid, mod_cgid와 같은)에서 fork하는 모듈을 사용한다면, 각 Apache 프로세스를 검사하고 현재 작업 디렉토리, 프로세스 루트 및 파일을 엽니 다. 당신의 선택권이 무엇인지 생각하고 자신의 결정을 내리십시오.

참고 : VirtualHosts에서는이 지시어를 사용할 수 없습니다. 활성화 된 경우 기본 modsecurity.conf와 같은 전역 서버 전체 구성 파일에 배치해야합니다.

SecCollectionTimeout

설명 : 콜렉션 시간 초과를 지정합니다. 기본값은 3600 초입니다.

Syntax: SecCollectionTimeout seconds

기본값 : 3600

범위 : 모든

버전 : 2.6.3

libModSecurity에서 지원됨 : 예

SecComponentSignature

설명 : 구성 요소 서명을 ModSecurity 서명에 추가합니다.

Syntax: SecComponentSignature "COMPONENT_NAME/X.Y.Z (COMMENT)" 

사용 예 :SecComponentSignature "core ruleset/2.1.3"

범위 : Main

버전 : 2.5.0

libModSecurity에서 지원됨 : 예

이 지시문은 중요한 규칙 집합의 존재를 알리는 데 사용해야합니다. 전체 서명이 트랜잭션 감사 로그에 기록됩니다.

SecConnEngine

설명 : 연결 엔진을 구성합니다. 이 지시문은 지시문 (SecConnReadStateLimit 및 SecConnWriteStateLimit)에 영향을줍니다.

Syntax: SecConnEngine On|Off|DetectionOnly 

사용 예 : SecConnEngine On 

범위 : 모든

버전 : 2.8.0-2.9.x

libModSecurity : TBI 에서 지원됨

가능한 값은 다음과 같습니다 (SecRuleEngine과 동일).

• On : 프로세스 SecConn [읽기 | 쓰기] StateLimit.
• Off : 지시어를 무시합니다. SecConn [읽기 | 쓰기] StateLimit
• DetectionOnly : 프로세스 SecConn [읽기 | 쓰기] StateLimit 정의를 자세한 모드로 실행하지만 아무런 파괴 작업도 수행하지 않습니다.

SecContentInjection

설명 : append 및 prepend 작업을 사용하여 콘텐츠 주입을 활성화합니다.

Syntax: SecContentInjection On|Off 

사용 예 : SecContentInjection On 

범위 : 모든

버전 : 2.5.0-2.9.x

libModSecurity : TBI 에서 지원됨

이 지시문은 규칙이 원하는 것과 상관없이 콘텐츠 삽입을 쉽게 제어 할 수있는 방법을 제공합니다. 컨텐츠 삽입을 사용하기 위해 응답 바디 버퍼링을 사용할 필요는 없습니다.

참고 : @rsub + STREAM_ 변수를 사용하여 실제 트랜잭션 데이터를 조작하려면이 지정 문을 사용 가능하게 설정해야합니다.

SecCookieFormat

설명 : 현재 구성 컨텍스트에서 사용할 쿠키 형식을 선택합니다.

Syntax: SecCookieFormat 0|1 

사용 예 : SecCookieFormat 0 

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

가능한 값은 다음과 같습니다.

• 0 : 버전 0 (Netscape) 쿠키를 사용하십시오. 이것은 대부분의 응용 프로그램에서 사용하는 것입니다. 이것이 기본값입니다.
• 1 : 버전 1 쿠키를 사용하십시오.

SecCookieV0 분리 자

설명 : 쿠키 v0 컨텐츠의 구분 기호로 사용할 문자를 지정합니다.

Syntax: SecCookieV0Separator character

범위 : 모든

버전 : 2.7.0-2.9.x

libModSecurity : TBI 에서 지원됨

SecDataDir

설명 : 영구 데이터 (예 : IP 주소 데이터, 세션 데이터 등)가 저장되는 경로입니다.

Syntax: SecDataDir /path/to/dir 

사용 예 : SecDataDir /usr/local/apache/logs/data 

범위 : Main

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

이 지시문은 initcol, setsid 및 setuid를 사용하기 전에 제공해야합니다. 지시어가 가리키는 디렉토리는 웹 서버 사용자가 쓸 수 있어야합니다.

참고 : VirtualHosts에서는이 지시어를 사용할 수 없습니다. 활성화 된 경우 기본 modsecurity.conf와 같은 전역 서버 전체 구성 파일에 배치해야합니다.

SecDebugLog

설명 : ModSecurity 디버그 로그 파일의 경로입니다.

Syntax: SecDebugLog /path/to/modsec-debug.log 

사용 예 : SecDebugLog /usr/local/apache/logs/modsec-debug.log 

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

SecDebugLogLevel

설명 : 디버그 로그 데이터의 상세 정보를 구성합니다.

구문 :SecDebugLogLevel 0|1|2|3|4|5|6|7|8|9

사용 예 : SecDebugLogLevel 4 

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

레벨 1-3의 메시지는 항상 Apache 오류 로그에 복사됩니다. 따라서 성능에 매우 관심이 있다면 항상 프로덕션의 기본 로깅 수준으로 수준 0을 사용할 수 있습니다. 그렇다고해서 가장 좋은 값은 3입니다. 생산량이 많으면 성능에 좋지 않은 영향을주기 때문에 생산량이 높을수록 권장하지 않습니다.

디버그 로그 수준에 사용할 수있는 값은 다음과 같습니다.

• 0 : 로깅 없음
• 1 : 오류 (차단 된 요청) 만
• 2 : 경고
• 3 : 고지
• 4 : 트랜잭션 처리 방법에 대한 세부 정보
• 5 : 위와 같지만 처리되는 각 정보에 대한 정보 포함
• 9 : 매우 자세한 디버깅 정보를 포함하여 모든 것을 기록하십시오.

SecDefaultAction

설명 : 동일한 구성 컨텍스트의 규칙에 상속 될 기본 동작 목록을 정의합니다.

Syntax: SecDefaultAction "action1,action2,action3“ 

사용 예 : SecDefaultAction "phase:2,log,auditlog,deny,status:403,tag:'SLA 24/7'“ 

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

기본값 : 단계 : 2, 로그, 감사 로그, 통과

SecDefaultAction동일한 구성 컨텍스트 의 이전 지정 문 다음에 오는 모든 규칙 은 더 구체적인 조치가 사용되지 않는 한 해당 설정을 상속합니다. 모든 SecDefaultAction지시문은 파괴적인 작업과 처리 단계를 지정해야하며 메타 데이터 작업을 포함 할 수 없습니다.

경고 : SecDefaultAction구성 컨텍스트간에 상속되지 않습니다. (이것이 문제가 될 수있는 이유의 예를 보려면 다음 ModSecurity 블로그 항목 http://blog.spiderlabs.com/2008/07/three-modsecurity-rule-language-annoyances.html을 읽으십시오 .)

SecDisableBackendCompression

설명 : 프론트 엔드 압축을 사용 가능하게 유지하면서 백엔드 압축을 사용 불가능하게합니다.

Syntax: SecDisableBackendCompression On|Off 

범위 : 모든

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

기본값 : 꺼짐

이 지시문은 백엔드 서버가 응답 압축을 지원하지만 응답 본문을 검사하려는 경우 역방향 프록시 모드에서 필요합니다. 백엔드 압축을 사용하지 않으면 ModSecurity는 압축 된 내용 만 볼 수 있습니다. ModSecurity는 응답 압축이 수행되기 전에 검사를 수행하기 때문에 임베디드 모드에서는이 지시어가 필요하지 않습니다.

SecHashEngine

설명 : 해시 엔진을 구성합니다.

Syntax: SecHashEngine On|Off

사용 예 : SecHashEngine On 

범위 : 모두

버전 : 2.7.1-2.9.x

libModSecurity : TBI 에서 지원됨

기본값 : 꺼짐

가능한 값은 다음과 같습니다.

• 켜기 : 해시 엔진이 요청 / 응답 데이터를 처리 할 수 ​​있습니다.
• 꺼짐 : 해시 엔진이 데이터를 처리하지 않습니다.

참고 : 사용자는 스트림 출력 변수 및 내용 삽입을 활성화해야합니다.

SecHashKey

설명 : HMAC에서 사용할 키를 정의하십시오.

Syntax: SecHashKey rand|TEXT KeyOnly|SessionID|RemoteIP

사용 예 : SecHashKey "this_is_my_key" KeyOnly

범위 : 모두

버전 : 2.7.1-2.9.x

libModSecurity : TBI 에서 지원됨

ModSecurity 해시 엔진은 지정된 경우 사용자의 세션 ID 또는 원격 IP를 MAC 조작 전에 키에 추가합니다. 첫 번째 매개 변수가 "rand"이면 임의의 키가 생성되어 엔진에서 사용됩니다.

SecHashParam

설명 : MAC 해시를 수신 할 매개 변수 이름을 정의하십시오.

Syntax: SecHashParam TEXT

사용 예 : SecHashParam "hmac"

범위 : 모두

버전 : 2.7.1-2.9.x

libModSecurity : TBI 에서 지원됨

ModSecurity 해시 엔진은 MAC 해시가 포함 된 보호 된 HTML 요소에 새 매개 변수를 추가합니다.

SecHashMethodRx

설명 : 해시 엔진이 정규 표현식을 기반으로 서명해야하는 HTML 데이터의 종류를 구성합니다.

Syntax: SecHashMethodRx TYPE REGEX

사용 예 :SecHashMethodRx HashHref "product_info|list_product"

범위 : 모든

버전 : 2.7.1-2.9.x

libModSecurity : TBI 에서 지원됨

HTTP 리디렉션 코드가 전송 될 때 HREF, FRAME, IFRAME 및 FORM ACTION html 요소와 응답 위치 헤더를 보호하기위한 초기 지원이 가능합니다.

TYPE에 가능한 값은 다음과 같습니다.

• HashHref : href = html 요소에 서명하는 데 사용됩니다.
• HashFormAction : form action = html 요소에 서명하는 데 사용됩니다.
• HashIframeSrc : iframe src = html 요소에 서명하는 데 사용됩니다.
• HashframeSrc : 프레임 src = html 요소에 서명하는 데 사용됩니다.
• HashLocation : 위치 응답 헤더에 서명하는 데 사용됩니다.

참고 :이 지시문은 요소에 서명하는 데 사용되지만 사용자는 @validateHash 연산자를 사용하여 데이터 무결성을 적용해야합니다.

SecHashMethodPm

설명 : 해시 엔진이 문자열 검색 알고리즘을 기반으로 서명해야하는 HTML 데이터의 종류를 구성합니다.

Syntax: SecHashMethodPm TYPE "string1 string2 string3..."

사용 예 :SecHashMethodPm HashHref "product_info list_product"

범위 : 모든

버전 : 2.7.1-2.9.x

libModSecurity : TBI 에서 지원됨

HTTP 리디렉션 코드가 전송 될 때 HREF, FRAME, IFRAME 및 FORM ACTION html 요소와 응답 위치 헤더를 보호하기위한 초기 지원이 가능합니다.

TYPE에 가능한 값은 다음과 같습니다.

• HashHref : href = html 요소에 서명하는 데 사용됩니다.
• HashFormAction : form action = html 요소에 서명하는 데 사용됩니다.
• HashIframeSrc : iframe src = html 요소에 서명하는 데 사용됩니다.
• HashframeSrc : 프레임 src = html 요소에 서명하는 데 사용됩니다.
• HashLocation : 위치 응답 헤더에 서명하는 데 사용됩니다.

참고 :이 지시문은 요소에 서명하는 데 사용되지만 사용자는 @validateHash 연산자를 사용하여 데이터 무결성을 적용해야합니다.

SecGeoLookupDb

설명 : Geolocation 조회에 사용될 데이터베이스의 경로를 정의합니다.

Syntax: SecGeoLookupDb /path/to/db 

사용 예 :SecGeoLookupDb /path/to/GeoLiteCity.dat

범위 : 모든

버전 : 2.5.0

libModSecurity에서 지원됨 : 예

ModSecurity는 MaxMind http://www.maxmind.com 에서 얻을 수있는 무료 Geolocation 데이터베이스 (GeoLite City 및 GeoLite Country)를 사용합니다 . 현재 ModSecurity는 기존 GeoIP 형식 만 지원합니다. Maxmind의 새로운 GeoIP2 형식은 아직 지원되지 않습니다.

SecGsbLookupDb

설명 : Google 안전 브라우징 (GSB) 조회에 사용될 데이터베이스의 경로를 정의합니다.

Syntax: SecGsbLookupDb /path/to/db 

사용 예 :SecGsbLookupDb /path/to/GsbMalware.dat

범위 : 모든

버전 : 2.6.0

libModSecurity에서 지원됨 : TBD

ModSecurity는 Google GSB API http://code.google.com/apis/safebrowsing/ 에서 무료로 제공되는 Google 안전 브라우징 데이터베이스를 사용합니다 .

참고 : Google 개발자 팀이 데이터베이스 다운로드를 더 이상 허용하지 않기로 결정한 후 2.7.0에서 더 이상 사용되지 않습니다. 세이프 브라우징 API 키를 등록하고 획득하면 wget과 같은 도구를 사용하여 GSB를 자동으로 다운로드 할 수 있습니다. 다운로드 진행 방법에 대한 자세한 내용은 Google 웹 사이트 ( https://developers.google.com/safe-browsing/v3/update-guide) 를 방문 하십시오.

SecGuardianLog

설명 : 파이프 로깅을 통해 모든 트랜잭션에 대한 정보를 수신 할 외부 프로그램을 구성합니다.

Syntax: SecGuardianLog |/path/to/httpd-guardian 

사용 예 : SecGuardianLog |/usr/local/apache/bin/httpd-guardian 

범위 : Main

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

Guardian 로깅은 모든 요청에 ​​대한 정보를 외부 프로그램에 보내도록 설계되었습니다. 일반적으로 Apache는 다중 프로세스 방식으로 배포되므로 프로세스 간의 정보 공유가 어려워지기 때문에 하나의 외부 프로세스를 배포하여 모든 요청을 상태 기반 방식으로 관찰하여 추가 보호 기능을 제공하는 것이 좋습니다.

현재 보호자 로깅과 관련하여 알려진 유일한 도구는 httpd-guardian 입니다.이 도구는 Apache httpd 도구 프로젝트 http://apache-tools.cvs.sourceforge.net/viewvc/apache-tools/apache-tools/의 일부입니다 . httpd-guardian 도구는 서비스 거부 공격으로부터 보호합니다. 동일한 프로젝트의 블랙리스트 도구를 사용하여 iptables 기반 (Linux 시스템에서) 또는 pf 기반 (BSD 시스템에서) 방화벽과 상호 작용하여 문제가되는 IP 주소를 동적으로 차단합니다. 또한 SnortSam http://www.snortsam.net과 상호 작용할 수도 있습니다 . httpd-guardian이 이미 구성되어 있다고 가정하면 (자세한 지침은 소스 코드를 참조하십시오.) Apache 구성에 한 줄만 추가하면 배포 할 수 있습니다.

SecGuardianLog | / 경로 / to / httpd-guardian

참고 : VirtualHosts에서는이 지시어를 사용할 수 없습니다. 활성화 된 경우 기본 modsecurity.conf와 같은 전역 서버 전체 구성 파일에 배치해야합니다.

SecHttpBlKey

설명 : @rbl과 함께 사용할 사용자의 등록 된 허니팟 프로젝트 HTTP BL API 키를 구성합니다.

Syntax: SecHttpBlKey [12 char access key] 

사용 예 : SecHttpBlKey whdkfieyhtnf 

범위 : Main

버전 : 2.7.0

libModSecurity에서 지원됨 : 예

@rbl 연산자가 dnsbl.httpbl.org RBL ( http://www.projecthoneypot.org/httpbl_api.php )을 사용하는 경우 API 키를 제공해야합니다. 이 키는 개별 사용자에게 등록되며 RBL DNS 요청에 포함됩니다.

SecInterceptOnError

설명 : 룰 처리가 실패 할 때 대응하는 방법을 구성합니다.

Syntax: SecInterceptOnError On|Off 

사용 예 : SecInterceptOnError On 

범위 : Main

버전 : 2.6-2.9.x

libModSecurity : TBI 에서 지원됨

연산자 실행이 실패하거나 0보다 큰 값을 반환하면이 지시문은 반응하는 방법을 구성합니다. "Off"로 설정하면 규칙은 무시되며 엔진은 규칙을 단계적으로 계속 실행합니다. "On"으로 설정하면 규칙이 삭제되고 같은 단계에서 규칙이 더 이상 실행되지 않으며 차단도 수행되지 않습니다.

SecMarker

설명 : skipAfter 작업에서 대상으로 사용할 수있는 고정 된 규칙 표식을 추가합니다. SecMarker 지시어는 본질적으로 아무것도하지 않고 지정된 ID를 전달하는 유일한 목적을 가진 규칙을 만듭니다.

Syntax: SecMarker ID|TEXT 

사용 예 :SecMarker 9999 

범위 : 모든

버전 : 2.5.0

값은 숫자 또는 텍스트 문자열이 될 수 있습니다. SecMarker 지시문을 사용하면 건너 뛰기를 구현하는 가장 좋은 방법을 선택할 수 있습니다. 핵심 규칙 집합에서 사용한 예제는 다음과 같습니다.

SecMarker BEGIN_HOST_CHECK

        SecRule & REQUEST_HEADERS : 호스트 "@eq 0"\
                ID : '960008', 태그 : 'PROTOCOL_VIOLATION / MISSING_HEADER_HOST', tag : '호스트 헤더가 누락 됨'요청 : skipAfter : END_HOST_CHECK, 단계 : 2, rev : '2.1.1' WASCTC / WASC-21 '태그 :'OWASP_TOP_10 / A7 ', 태그 :'PCI / 6.5.10 ', 심각도 :'5 ', setvar :'tx.msg = % {rule.msg} ', setvar : tx. + {% 일치 된 버전} = % {일치 된 버전} = {
        SecRule REQUEST_HEADERS : "^ $"호스트
                ID : '960008', 태그 : 'PROTOCOL_VIOLATION / MISSING_HEADER_HOST', 태그 : 'WASCTC / WASC- 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % ','OWASP_TOP_10 / A7 ' % {일치 된 버전} = % {일치 된 버전} ",

SecMarker END_HOST_CHECK

SecPcreMatchLimit

설명 : PCRE 라이브러리에 일치 제한을 설정합니다.

Syntax: SecPcreMatchLimit value 

사용 예 :SecPcreMatchLimit 1500 

범위 : Main

버전 : 2.5.12

libModSecurity에서 지원됨 : 예

기본값 : 1500

ModSecurity가 컴파일 준비가되면 기본값이 변경 될 수 있습니다. --enable-pcre-match-limit = val configure 옵션은 사용자 정의 기본값을 설정하고 --disable-pcre-match-limit 옵션은 기본값으로 되돌립니다. PCRE 라이브러리 자세한 내용은 pcreapi man 페이지의 pcre_extra 필드를 참조하십시오.

참고 : VirtualHosts에서는이 지시어를 사용할 수 없습니다. 활성화 된 경우 기본 modsecurity.conf와 같은 전역 서버 전체 구성 파일에 배치해야합니다.

SecPcreMatchLimitRecursion

설명 : PCRE 라이브러리에 일치 제한 재귀를 설정합니다.

Syntax: SecPcreMatchLimitRecursion value 

사용 예 : SecPcreMatchLimitRecursion 1500 

범위 : Main

버전 : 2.5.12

libModSecurity에서 지원됨 : 예

기본값 : 1500

ModSecurity가 컴파일 준비가되면 기본값을 변경할 수 있습니다 : --enable-pcre-match-limit-recursion = val configure 옵션은 커스텀 기본값을 설정하고 --disable-pcre-match-limit-recursion 옵션은 되돌릴 것입니다 PCRE 라이브러리의 기본값으로 설정하십시오. 자세한 내용은 pcreapi man 페이지의 pcre_extra 필드를 참조하십시오.

참고 : VirtualHosts에서는이 지시어를 사용할 수 없습니다. 활성화 된 경우 기본 modsecurity.conf와 같은 전역 서버 전체 구성 파일에 배치해야합니다.

SecPdfProtect

설명 : PDF XSS 보호 기능을 사용합니다.

Syntax: SecPdfProtect On|Off 

사용 예 : SecPdfProtect On 

범위 : 모든

버전 : 2.5.0; 트렁크에서 제거하다

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

일단 활성화되면 PDF 파일에 대한 액세스가 추적됩니다. 직접 액세스 시도는 일회성 토큰이 포함 된 링크로 리디렉션됩니다. 유효한 토큰이있는 요청은 수정되지 않고 사용할 수 있습니다. 유효하지 않은 토큰이있는 요청도 허용되지만 PDF 파일을 강제 다운로드 할 수는 있습니다. 이 구현은 응답 헤더를 사용하여 PDF 파일을 감지하므로 요청 URI에 .pdf 확장자가없는 동적으로 생성 된 PDF 파일과 함께 사용할 수 있습니다.

SecPdfProtectMethod

설명 : PDF 파일 요청이 감지 될 때 사용할 보호 방법을 구성하십시오.

Syntax: SecPdfProtectMethod method 

사용 예 :SecPdfProtectMethod TokenRedirection 

범위 : 모두

버전 : 2.5.0; 트렁크에서 제거하다

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

기본값 : TokenRedirection

가능한 값은 TokenRedirection 및 ForcedDownload입니다. 토큰 재 지정 접근법은 가능한 경우 토큰으로 리디렉션을 시도합니다. 이렇게하면 PDF 파일을 계속해서 인라인으로 열 수 있지만 GET 요청에만 사용할 수 있습니다. 강제 다운로드는 항상 PDF 파일을 불투명 한 바이너리 및 첨부 파일로 제공합니다. 후자는 GET이 아닌 요청에 항상 사용됩니다. 강제 다운로드는보다 안전하다고 간주되지만 사용자에게 유용성 문제가 발생할 수 있습니다 ( "이 PDF는 더 이상 열리지 않습니다!").

SecPdfProtectSecret

설명 : 일회성 토큰을 구성하는 데 사용할 비밀을 정의합니다.

Syntax: SecPdfProtectSecret secret 

사용 예 : SecPdfProtectSecret MyRandomSecretString

범위 : 모든

버전 : 2.5.0; 트렁크에서 제거하다

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

비밀에 대해서는 합리적으로 긴 값을 사용해야합니다 (예 : 16 자). 일단 선택되면 변경 전의 토큰이 깨지기 때문에 비밀은 변경되어서는 안됩니다. 그러나 변경하더라도 큰 문제가 아닙니다. 지난 몇 초 동안 발행 된 토큰이 포함 된 PDF 파일을 강제로 다운로드하게됩니다.

SecPdfProtectTimeout

설명 : 토큰 시간 초과를 정의합니다.

Syntax: SecPdfProtectTimeout timeout 

사용 예 :SecPdfProtectTimeout 10 

범위 : 모든

버전 : 2.5.0; 트렁크에서 제거하다

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

기본값 : 10

토큰이 만료 된 후에는 더 이상 PDF 파일에 대한 액세스를 허용하지 않습니다. 요청은 통과 할 수 있지만 PDF는 첨부 파일로 전달됩니다.

SecPdfProtectTokenName

설명 : 토큰의 이름을 정의합니다.

구문 :SecPdfProtectTokenName name 

사용 예 :SecPdfProtectTokenName PDFTOKEN 

범위 : 모두

버전 : 2.5.0; 트렁크에서 제거하다

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

기본값 : PDFTOKEN

토큰 이름을 변경하려는 유일한 이유는 ModSecurity를 ​​실행한다는 사실을 숨기려는 경우입니다. 그것은 좋은 이유지만, 실제로 도움이되지는 않습니다. 적들이 PDF 보호에 사용되는 알고리즘을 살펴보고 어쨌든 알아낼 수 있기 때문입니다. 그것은 약간 막대기를 올린다, 그래서 원한다면 전진하십시오.

SecReadStateLimit

설명 : SERVER_BUSY_READ 상태가 될 수있는 연결 수에 대한 IP 주소 별 제한을 설정합니다.

Syntax: SecReadStateLimit LIMIT 

사용 예 :SecReadStateLimit 50 

범위 : Main

버전 : 2.5.13, v2.8.0부터 사용이 중단되었습니다.

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

기본값 : 0 (제한 없음)

v2.8.0 이상인 경우 SecConnReadStateLimit를 참조하십시오.

SecConnReadStateLimit

설명 : SERVER_BUSY_READ 상태가 될 수있는 연결 수에 대한 IP 주소 별 제한을 설정합니다.

Syntax: SecConnReadStateLimit LIMIT OPTIONAL_IP_MATCH_OPERATOR

사용 예 :SecConnReadStateLimit 50 "!@ipMatch 127.0.0.1"

범위 : Main

버전 : v2.8.0-2.9.x (Apache 전용)

libModSecurity : TBI 에서 지원됨

기본값 : 0 (제한 없음)

이 측정 값은 단일 IP 주소에서 슬로 로우 (Slowloris) 스타일의 공격에 효과적이지만 요청 본문 내용을 천천히 전송함으로써 작동하는 수정 된 공격에 비해 좋지 않을 수 있습니다. 이는 요청 헤더가 읽혀지면 Apache가 SERVER_BUSY_WRITE로 전환하기 때문입니다. 대안으로, mod_reqtimeout (Apache의 2.2.15 부분)을 고려하십시오. 두 공격 유형 모두에 대해 효과적 일 것으로 예상됩니다. 느린 DoS 공격 완화에 대한 블로그 게시물 - http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html을 참조하십시오.. v2.8.0 이상에서는 @ipMatch, @ipMatchF 및 @ipMatchFromFile 연산자를 의심 스럽거나 허용 된 사이트를 만드는 데 사용 된 음수 (예 :! @ipMatch)와 함께 지원합니다. 의심스러운 목록에 알리면 목록에 속한 IP 만 필터링됩니다. SecConnReadStateLimit의 여러 정의를 사용하면 의심스러운 항목과 허용 된 항목을 조합 할 수 있지만 제한 사항은 항상 후속 항목으로 덮어 쓰게됩니다.

참고 : 이 기능은 Apache에만 해당됩니다.

참고 2 : 이 기능을 사용하기 전에 참조 설명서 # secconnengine 이 켜져 있는지 확인하십시오 .

SecSensorId

설명 : 로그 부분 H에 나타날 센서 ID를 정의하십시오.

Syntax: SecSensorId TEXT 

사용 예 :SecSensorId WAFSensor01 

범위 : Main

버전 : 2.7.0-2.9.x

libModSecurity : TBI 에서 지원됨

SecWriteStateLimit

설명 : SERVER_BUSY_WRITE 상태가 될 수있는 연결 수에 대한 IP 단위 주소 제한을 설정합니다.

Syntax: SecWriteStateLimit LIMIT 

사용 예 :SecWriteStateLimit 50 

범위 : Main

버전 : 2.6.0, v2.8.0부터 사용이 금지되었습니다.

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

기본값 : 0 (제한 없음)

v2.8.0 이상인 경우 SecConnWriteStateLimit를 참조하십시오.

SecConnWriteStateLimit

설명 : SERVER_BUSY_WRITE 상태가 될 수있는 연결 수에 대한 IP 단위 주소 제한을 설정합니다.

Syntax: SecConnWriteStateLimit LIMIT OPTIONAL_IP_MATCH_OPERATOR

사용 예 :SecConnWriteStateLimit 50 "!ipMatch 127.0.0.1"

범위 : Main

버전 : 2.6.0-2.9.x (Apache 전용)

libModSecurity : TBI 에서 지원됨

기본값 : 0 (제한 없음)

이 측정은 Slow DoS 요청 본문 공격에 효과적입니다. v2.8.0 이상에서는 @ipMatch, @ipMatchF 및 @ipMatchFromFile 연산자를 의심 스럽거나 허용 된 사이트를 만드는 데 사용 된 음수 (예 :! @ipMatch)와 함께 지원합니다. 의심스러운 목록에 알리면 목록에 속한 IP 만 필터링됩니다. SecConnReadStateLimit의 여러 정의를 사용하면 의심스러운 항목과 허용 된 항목을 조합 할 수 있지만 제한 사항은 항상 후속 항목으로 덮어 쓰게됩니다.

참고 : 이 기능은 Apache에만 해당됩니다.

참고 2 : 이 기능을 사용하기 전에 참조 설명서 # secconnengine 이 켜져 있는지 확인하십시오 .

SecRemoteRules

설명 : HTTPS 사이트에서 호스팅되는 지정된 파일에서 규칙을로드합니다.

Syntax: SecRemoteRules [crypto] key https://url 

사용 예 :SecRemoteRules some-key https://www.yourserver.com/plain-text-rules.txt

범위 : 모든

버전 : 2.9.0-RC1 +

libModSecurity에서 지원됨 : 예

이 옵션은 사용자가 원격 서버에서 규칙을로드 할 수있게하는 선택적인 지시문입니다. URL 외에도 사용자는 다른 키에 대해 다른 내용을 제공하기 위해 대상 서버에서 사용할 수있는 키를 제공해야합니다.

사용자가 제공 한 키와 함께 ModSecurity는 고유 ID 및 헤더 형식의`상태 호출 '을 대상 웹 서버에 보냅니다. 다음 헤더가 사용됩니다.

 - ModSec- 상태
 - ModSec 고유 ID
 - ModSec-key

선택적 옵션 "crypto"는 ModSecurity가 서버로부터 암호화 된 일부 컨텐츠를 기대하도록 지시합니다. SecRemoteRules의 사용은 TLS에서만 허용되므로이 옵션은 필요하지 않을 수 있습니다.

참고 : 유효하고 신뢰할 수있는 디지털 인증서가 최종 서버에 필요합니다. 또한 서버에서 TLS 1.2를 사용하는 것이 좋습니다.

SecRemoteRulesFailAction

설명 : SecRemoteRules가 ModSecurity가 다운로드 할 수없는 URL을 지정하는 경우 수행 할 작업입니다.

Syntax: SecRemoteRulesFailAction Abort|Warn 

사용 예 :SecRemoteRulesFailAction Abort

범위 : 모든

버전 : 2.9.0-RC1 +

libModSecurity에서 지원됨 : 예

기본 동작은 주어진 URL을 다운로드하는 데 문제가있을 때마다 중단하는 것입니다.

참고 :이 지시어는 HTTPS URI와 함께 원격 파일을 검색 할 때 @ipMatchFromFile의 동작에도 영향을 미칩니다.

SecRequestBodyAccess

설명 : 요청 본문을 ModSecurity가 버퍼링하고 처리할지 여부를 구성합니다.

Syntax: SecRequestBodyAccess On|Off 

사용 예 :SecRequestBodyAccess On

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

이 지시문은 데이터 전송 요청 본문 (예 : POST 매개 변수)을 검사하려는 경우 필요합니다. 신뢰할 수있는 차단을 가능하게하려면 요청 버퍼링이 필요합니다. 가능한 값은 다음과 같습니다.

• 켜기 : 버퍼 요청 본문
• 꺼짐 : 요청 본문을 버퍼링하지 않습니다.

SecRequestBodyInMemoryLimit

설명 : ModSecurity가 메모리에 저장할 최대 요청 본문 크기를 구성합니다.

Syntax: SecRequestBodyInMemoryLimit LIMIT_IN_BYTES 

사용 예 : SecRequestBodyInMemoryLimit 131072 

범위 : 모든

버전 : 2.0.0-2.9.x

libModSecurity에서 지원됨 : 아니오

기본값 : 131072 (128KB)

다중 파트 / 양식 데이터 요청이 처리 될 때 메모리 내 한계에 도달하면 요청 본문이 디스크의 임시 파일로 스트리밍되기 시작합니다.

주 : libModSecurity는 파일 또는 버퍼 (요청 된 또는 요청되지 않은)에서 요청 본문을 처리 할 수 ​​있습니다. 웹 서버에는 요청을 파일에 저장하거나 버퍼로 사용할 때마다이를 제어하는 ​​속성이 있습니다 (예 : client_body_buffer_size https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size ). 파일 인 경우 ModSecurity는 파일을 사용하여 검사를 수행합니다. 그렇지 않으면 버퍼가 사용됩니다.

SecRequestBodyLimit

설명 : ModSecurity가 버퍼링을 허용 할 최대 요청 본문 크기를 구성합니다.

Syntax: SecRequestBodyLimit LIMIT_IN_BYTES 

사용 예 : SecRequestBodyLimit 134217728 

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

기본값 : 134217728 (131072 KB)

한도를 초과하는 항목은 상태 코드 413 (요청 엔터티가 너무 큼)으로 거부됩니다. 1GB의 하드 제한이 있습니다.

참고 : ModSecurity 2.5.x 및 이전 버전에서는 SecRequestBodyLimit가 주 서버 구성 또는 VirtualHost 컨테이너에서 사용되는 경우에만 작동합니다. 이 버전에서는 요청 본문 제한이 1 단계 바로 뒤에 적용되지만 2 단계 구성 (즉, 위치 컨테이너에있는 모든 항목)이 해결되기 전에 요청 본문 제한이 적용됩니다. ctl : requestBodyLimit 동작을 사용하여 요청 본문 제한을 동적으로 변경하는 1 단계 규칙을 사용하여이 제한을 해결할 수 있습니다. ModSecurity 2.6.x (현재 트렁크에만 있음)와이 제한이 없습니다.

SecRequestBodyNoFilesLimit

설명 : ModSecurity가 요청할 때 전송되는 파일의 크기를 제외하고 버퍼링을 허용 할 최대 요청 본문 크기를 구성합니다. 이 지시문은 매우 큰 크기의 요청 본문을 보낼 때 DoS 공격에 대한 취약성을 줄이는 데 유용합니다. 파일 업로드가 필요한 웹 응용 프로그램에서는 SecRequestBodyLimit을 높은 값으로 구성해야하지만 대용량 파일은 디스크로 스트리밍되기 때문에 파일 업로드로 인해 메모리 사용량이 증가하지는 않습니다. 그러나 누군가가 큰 요청 본문 한도를 활용하고 크기가 큰 비 업로드 요청을 보낼 수도 있습니다. 이 지시어는 허점을 제거합니다.

Syntax: SecRequestBodyNoFilesLimit NUMBER_IN_BYTES 

사용 예 : SecRequestBodyNoFilesLimit 131072 

범위 : 모든

버전 : 2.5.0

libModSecurity에서 지원됨 : 예

기본값 : 1048576 (1 MB)

일반적으로 기본값은 충분하지 않습니다. 대부분의 응용 프로그램에서는 128KB 이하로 줄일 수 있습니다. 한도를 초과하는 항목은 상태 코드 413 (요청 엔터티가 너무 큼)으로 거부됩니다. 1GB의 하드 제한이 있습니다.

SecRequestBodyLimitAction

설명 : SecRequestBodyLimit으로 구성된 요청 본문 제한에 도달하면 어떤 일이 발생할지 제어합니다.

Syntax: SecRequestBodyLimitAction Reject|ProcessPartial 

사용 예 : SecRequestBodyLimitAction ProcessPartial

범위 : 모든

버전 : 2.6.0

libModSecurity에서 지원됨 : 예

기본적으로 ModSecurity는 지정된 길이보다 긴 요청 본문을 거부합니다. 이것은 특히 ModSecurity가 DetectionOnly 모드에서 실행되고 있고 그 의도가 완전히 수동적이어서 트랜잭션에 대해 파괴적인 조치를 취하지 않을 때 문제가됩니다. 한도에 도달하면 어떤 일이 발생할지 선택하는 기능으로 사이트 관리자는 요청의 첫 번째 부분, 원하는 제한에 맞출 수있는 부분 및 나머지 부분을 검사하도록 선택할 수 있습니다. 이것은 가능한 회피 문제 관점에서 이상적이지는 않지만 특정 상황에서는 받아 들일 수 있습니다.

참고 : SecRuleEngine을 DetectionOnly로 설정하면 SecRequestBodyLimitAction이 자동으로 ProcessPartial로 설정되어 중단되지 않습니다. 요청 본문 크기가 제한을 초과하는지 여부를 알고 싶으면 INBOUND_ERROR_DATA 변수가 있는지 확인하는 규칙을 만들 수 있습니다.

SecResponseBodyLimit

설명 : 버퍼링에 대해 승인 할 최대 응답 본문 크기를 구성합니다.

Syntax: SecResponseBodyLimit LIMIT_IN_BYTES 

사용 예 : SecResponseBodyLimit 524228 

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

기본값 : 524288 (512KB)

이 제한을 초과하는 항목은 상태 코드 500 (내부 서버 오류)으로 거부됩니다. 이 설정은 버퍼링을 위해 선택되지 않은 MIME 유형의 응답에는 영향을 미치지 않습니다. 1GB의 하드 제한이 있습니다.

SecResponseBodyLimitAction

설명 : SecResponseBodyLimit으로 구성된 응답 본문 제한이 발생하면 수행되는 작업을 제어합니다.

Syntax: SecResponseBodyLimitAction Reject|ProcessPartial 

사용 예 : SecResponseBodyLimitAction ProcessPartial 

범위 : 모든

버전 : 2.5.0

libModSecurity에서 지원됨 : 예

기본적으로 ModSecurity는 지정된 길이보다 긴 응답 본문을 거부합니다. 그러나 일부 웹 사이트에서는 응답 시간이 매우 길어 합리적인 한계를 찾기 어렵습니다. 이러한 사이트는 처음부터 제한을 두지 않을 목적으로 (메모리 소비를 제어하기 위해) 한도를 적절히 높이어 적절하게 기능해야합니다. 한도에 도달하면 일어날 일을 선택할 수있는 기능을 통해 사이트 관리자는 응답의 첫 번째 부분, 원하는 제한에 부합하는 부분 및 나머지 부분을 검사하도록 선택할 수 있습니다. 어떤 사람들은 응답의 일부가 미심쩍어 지도록 허용하는 것이 약점이라고 주장 할 수 있습니다. 이것은 이론상 사실이지만 공격자가 결과를 제어하는 ​​경우에만 적용됩니다 (예 : 임의로 길게 만들 수 있음). 그러나 그러한 경우, 어쨌든 누설을 방지 할 수는 없습니다. 공격자는 데이터가 되돌아 가기 전에 데이터를 압축, 난독 화 또는 암호화하여 모든 모니터링 장치를 우회 할 수 있습니다.

SecResponseBodyMimeType

설명 : 응답 본문 버퍼링을 위해 고려해야 할 MIME 유형을 구성합니다.

Syntax: SecResponseBodyMimeType MIMETYPE MIMETYPE ... 

사용 예 :SecResponseBodyMimeType text/plain text/html text/xml

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

기본값 : 텍스트 / 일반 텍스트 / html

여러 개의 SecResponseBodyMimeType 지시문을 사용하여 MIME 유형을 추가 할 수 있습니다. 이전에 구성된 MIME 형식을 지우고 다시 시작하려면 SecResponseBodyMimeTypesClear를 사용하십시오.

SecResponseBodyMimeTypesClear

설명 : 응답 본문 버퍼링에 고려되는 MIME 유형 목록을 지우고 처음부터 목록을 채울 수 있습니다.

Syntax: SecResponseBodyMimeTypesClear 

사용 예 : SecResponseBodyMimeTypesClear 

범위 : 모든

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

SecResponseBodyAccess

설명 : 응답 본문을 버퍼링할지 여부를 구성합니다.

Syntax: SecResponseBodyAccess On|Off 

사용 예 : SecResponseBodyAccess On 

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

기본값 : 꺼짐

이 지시문은 HTML 응답을 검사하고 응답 차단을 구현하려는 경우 필요합니다. 가능한 값은 다음과 같습니다.

• On : 버퍼 응답 본문 (단, 응답 MIME 형식이 SecResponseBodyMimeType으로 구성된 목록과 일치하는 경우에만 해당)
• 꺼짐 : 응답 본문을 버퍼링하지 않습니다.

SecRule

설명 : 선택한 연산자를 사용하여 선택한 변수를 분석 할 규칙을 작성합니다.

Syntax: SecRule VARIABLES OPERATOR [ACTIONS] 

사용 예 : SecRule ARGS "@rx attack" "phase:1,log,deny,id:1" 

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

모든 규칙은 연산자를 검사 할 때 사용해야하는 하나 이상의 변수를 제공해야합니다. 조치가 제공되지 않으면 기본 목록이 사용됩니다. SecDefaultAction을 사용하여 명시 적으로 설정되지 않은 경우에도 항상 기본 목록이 있습니다. 규칙에 지정된 작업이 있으면 기본 목록과 병합되어 사용되는 최종 작업을 구성합니다. 규칙의 작업은 기본 목록의 작업을 덮어 씁니다. 자세한 내용은 SecDefaultAction을 참조하십시오.

SecRule 상속

설명 : 현재 컨텍스트가 상위 컨텍스트의 규칙을 상속하는지 여부를 구성합니다.

Syntax: SecRuleInheritance On|Off 

사용 예 : SecRuleInheritance Off 

범위 : 모든

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

기본값 : 켜기

때로는 컨테이너를 사용하여보다 구체적인 구성 컨텍스트를 만들 때 부모 컨텍스트에서 사용되는 것과 다른 규칙 집합을 사용하고자 할 수 있습니다. SecRuleInheritance를 Off로 설정하면 부모 규칙이 상속되지 않으므로 처음부터 다시 시작할 수 있습니다. ModSecurity 2.5.x에서는 설정 컨텍스트에서 1 단계 규칙을 무시할 수 없습니다. 현재 개발 버전에서 그 점에는 아무런 제한이 없습니다 (그리고 다음 주요 버전에는 없을 것입니다).

가능한 값은 다음과 같습니다.

• 켜기 : 상위 컨텍스트에서 규칙을 상속합니다.
• 꺼짐 : 상위 컨텍스트에서 규칙을 상속하지 않습니다.

참고 : 구성 컨텍스트는 Apache 개념입니다. 지시문,, 및은 모두 구성 컨텍스트를 만드는 데 사용됩니다. 자세한 내용은 Apache 설명서 (구성 섹션 http://httpd.apache.org/docs/2.0/sections.html)를 참조하십시오 . 이 지정.은 구성 옵션이 계승되는 f}에는 영향을주지 않습니다.

SecRuleEngine

설명 : 룰 엔진을 구성합니다.

Syntax: SecRuleEngine On|Off|DetectionOnly

사용 예 : SecRuleEngine On 

범위 : 모두

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

기본값 : 꺼짐

가능한 값은 다음과 같습니다.

• 켜기 : 프로세스 규칙
• 꺼짐 : 규칙을 처리하지 않습니다.
• DetectionOnly : 규칙을 처리하지만 임의의 파괴적인 작업 (차단, 거부, 삭제, 허용, 프록시 및 리디렉션)을 절대로 실행하지 않습니다.

SecRulePerfTime

설명 : 규칙에 대한 성능 임계 값을 설정합니다. 적어도 정의 된 시간을 소비하는 규칙은 Audit Log Part H에 id = usec, 쉼표로 구분 된 형식으로 Rules-Performance-Info로 기록됩니다.

Syntax: SecRulePerfTime USECS 

사용 예 : SecRulePerfTime 1000 

범위 : 모든

버전 : 2.7-2.9.x

libModSecurity : TBI 에서 지원됨

임계 값에 도달하는 규칙은 PERF_RULES 컬렉션을 통해 액세스 할 수 있습니다.

SecRuleRemoveById

설명 : 현재 구성 컨텍스트에서 일치하는 규칙을 제거합니다.

Syntax: SecRuleRemoveById ID ID RANGE ... 

사용 예 : SecRuleRemoveByID 1 2 "9000-9010" 

범위 : 모든

버전 : 2.0.0 - 3.x (사전)

libModSecurity에서 지원됨 : 예

이 지정 문은 여러 매개 변수를 지원하며 각 매개 변수는 규칙 ID 또는 범위가 될 수 있습니다. 공백이 포함 된 매개 변수는 큰 따옴표로 구분해야합니다.

주 : 이 지정 . 은 사용 불가능한 j 다음에 지정해야합니다 . 타사 규칙 집합을 처리 한 로컬 사용자 지정 규칙 파일 내에서 사용해야합니다. 예제 파일 - modsecurity_crs_60_customrules.conf.

SecRuleRemoveByMsg

설명 : 현재 구성 컨텍스트에서 일치하는 규칙을 제거합니다.

Syntax: SecRuleRemoveByMsg REGEX 

사용 예 : SecRuleRemoveByMsg "FAIL" 

범위 : 모든

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

일반적으로 SecRuleRemoveById를 사용하여 규칙을 제거하지만 규칙에 ID가 정의되어 있어야합니다. 그렇지 않은 경우 규칙 메시지와 일치하는 정규 표현식과 일치하는 SecRuleRemoveByMsg를 사용하여 제거 할 수 있습니다.

주 :이 지정.은 사용 불가능한 j 다음에 지정해야합니다. 타사 규칙 집합을 처리 한 로컬 사용자 지정 규칙 파일 내에서 사용해야합니다. 예제 파일 - modsecurity_crs_60_customrules.conf.

SecRuleRemoveByTag

설명 : 현재 구성 컨텍스트에서 일치하는 규칙을 제거합니다.

Syntax: SecRuleRemoveByTag REGEX 

사용 예 : SecRuleRemoveByTag "WEB_ATTACK/XSS" 

범위 : 모든

버전 : 2.6-2.9.x

libModSecurity : TBI 에서 지원됨

일반적으로 SecRuleRemoveById를 사용하여 규칙을 제거하지만 규칙에 ID가 정의되어 있어야합니다. 그렇지 않으면 규칙 태그 데이터와 일치하는 정규 표현식과 일치하는 SecRuleRemoveByTag를 사용하여 제거 할 수 있습니다. 이는 태그 데이터를 기반으로 전체 규칙 그룹을 비활성화하려는 경우에 유용합니다. OWASP ModSecurity CRS에 사용되는 태그의 예는 다음과 같습니다.

• 자동화 / MALICIOUS
• 자동화 / MISC
• AUTOMATION / SECURITY_SCANNER
• LEAKAGE / SOURCE_CODE_ASP_JSP
• LEAKAGE / SOURCE_CODE_CF
• LEAKAGE / SOURCE_CODE_PHP
• WEB_ATTACK / CF_INJECTION
• WEB_ATTACK / COMMAND_INJECTION
• WEB_ATTACK / FILE_INJECTION
• WEB_ATTACK / HTTP_RESPONSE_SPLITTING
• WEB_ATTACK / LDAP_INJECTION
• WEB_ATTACK / PHP_INJECTION
• WEB_ATTACK / REQUEST_SMUGGLING
• WEB_ATTACK / SESSION_FIXATION
• WEB_ATTACK / SQL_INJECTION
• WEB_ATTACK / SSI_INJECTION
• WEB_ATTACK / XSS

주 :이 지정.은 사용 불가능한 j 다음에 지정해야합니다. 타사 규칙 집합을 처리 한 로컬 사용자 지정 규칙 파일 내에서 사용해야합니다. 예제 파일 - modsecurity_crs_60_customrules.conf.

SecRuleScript

설명 :이 지시어는 Lua 스크립트를 실행하여 일치 여부를 결정하는 특별한 규칙을 만든다. SecRule과의 주요 차이점은 대상도없고 운영자도 없다는 것입니다. 스크립트는 ModSecurity 컨텍스트에서 임의의 변수를 가져올 수 있으며 모든 루아 연산자를 사용하여 변수를 테스트 할 수 있습니다. 두 번째 선택적 매개 변수는 의미가 SecRule의 의미와 동일한 작업 목록입니다.

Syntax: SecRuleScript /path/to/script.lua [ACTIONS]

사용 예 : SecRuleScript "/path/to/file.lua" "block"

범위 : 모든

버전 : 2.5.0-2.9.x

libModSecurity : TBI 에서 지원됨

참고 : 모든 루아 스크립트는 설정시 컴파일되고 메모리에 캐시됩니다. 스크립트를 다시로드하려면 Apache를 다시 시작하여 전체 ModSecurity 구성을 다시로드해야합니다.

예제 스크립트 :

- 스크립트가 기본 항목을 정의해야합니다.
- 포인트.
function main ()
    - 레벨 1에 로그인하십시오. 일반적으로
    - 로깅 아무것도, 특히 레벨 1이 아니지만, 이것은
    - 당신이 보여줄 수 있습니다. 디버깅에 유용합니다.
    m.log (1, "Hello world!");

    - 하나의 변수를 검색하십시오.
    로컬 var1 = m.getvar ( "REMOTE_ADDR");

    - 하나의 변수를 검색하고 하나의 변환 함수를 적용하십시오.
    - 두 번째 매개 변수는 문자열입니다.
    local var2 = m.getvar ( "ARGS", "lowercase");

    - 여러 변형 함수를 적용하여 하나의 변수를 검색합니다.
    - 두 번째 매개 변수가 이제 목록입니다. m.getvar ()
    - 컬렉션 이름을 쉼표로 구분해야합니다.
    - 변수 이름. 이는 하나의 변수 만 반환되기 때문입니다.
    로컬 var3 = m.getvar ( "ARGS.p", { "소문자,"compressWhitespace "});

    -이 규칙을 일치 시키려면 문자열을 반환합니다.
    - 오류 메시지를 포함합니다. 메시지에는 이름이 있어야합니다.
    - 문제가있는 변수의 값.
    - "변수 ARGS : p가 의심스러워!"를 반환합니다.

    - 그렇지 않으면 단순히 nil을 반환합니다.
    return nil;
종료

이 첫 번째 예제에서는 그 당시 한 변수 만 검색하고있었습니다. 이 경우 변수의 이름을 알 수 있습니다. 그러나 많은 경우 스크립트 매개 변수와 같이 미리 알지 못하는 변수를 검사해야합니다.

m.getvars ()를 사용하여 여러 변수를 한 번에 가져 오는 방법을 보여주는 예제 :

function main ()
    - 스크립트 매개 변수를 검색하십시오.
    로컬 d = m.getvars ( "ARGS", { "소문자,"htmlEntityDecode "});

    - 매개 변수를 반복합니다.
    i = 1, #d do
        - 매개 변수 값을 검사하십시오.
        if (string.find (d [i] .value, "<script"))) then
            - 항상 변수 이름을 지정하십시오.
            - 문제점이 오류 메시지에 있습니다.
            return ( "변수의 예상 XSS".. d [i] .name .. ".");
        종료
    종료

    - 잘못 찾지 않았습니다.
    return nil;
종료

참고 : Lua 프로그래밍 언어에 대한 자세한 내용은 http://www.lua.org/ 를 참조하십시오 . 참조 설명서 역시 http://www.lua.org/manual/5.1/ 에서 온라인으로 볼 수 있습니다 .

참고 : 루아 지원은 최상의 구현 스타일을 위해 작업하는 동안 프로 그래밍 인터페이스가 계속 진화하는 방식으로 실험적으로 표시됩니다. 프로그래밍 인터페이스에 대한 모든 사용자 입력을 환영합니다.

SecRuleUpdateActionById

설명 : 지정된 규칙의 작업 목록을 업데이트합니다.

Syntax: SecRuleUpdateActionById RULEID[:offset] ACTIONLIST

사용 예 : SecRuleUpdateActionById 12345 "deny,status:403"

범위 : 모든

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

이 지정 문은 지정된 규칙의 조치 목록을 두 번째 매개 변수에서 제공된 조치로 겹쳐 씁니다. 여기에는 두 가지 제한 사항이 있습니다. 규칙의 ID 또는 단계를 변경하는 데 사용할 수 없습니다. 한 번만 나타날 수있는 작업 만 덮어 씁니다. 목록에 여러 번 나타날 수있는 동작은 목록의 끝에 추가됩니다.

SecRule ARGS 공격 "단계 : 2, id : 12345, t : 소문자, 로그, 통과, msg : '메시지 텍스트'"
SecRuleUpdateActionById 12345 "t : 없음, t : compressWhitespace, 거부, 상태 : 403, msg : '새 메시지 텍스트'

앞의 예제에서 효과적인 결과 규칙은 다음과 같습니다.

SecRule ARGS 공격 "단계 : 2, id : 12345, t : 소문자, t : 없음, t : compressWhitespace, 거부, 상태 : 403, msg : '새 메시지 텍스트'

t : none을 추가하면 이전의 변환 함수를 중립화합니다 (예 : t : 소문자).

참고 : 대상 규칙이 체인 규칙 인 경우에는 SecRuleUpdateActionById 작업 목록에서도 chain을 지정해야합니다. 이 문제는 향후 버전에서 수정 될 예정입니다.

SecRuleUpdateTargetById

설명 : 지정된 규칙의 대상 (변수) 목록을 업데이트합니다.

Syntax: SecRuleUpdateTargetById RULEID TARGET1[,TARGET2,TARGET3] REPLACED_TARGET

사용 예 : SecRuleUpdateTargetById 12345 "!ARGS:foo"

범위 : 모든

버전 : 2.6-3.0 (사전)

libModSecurity에서 지원됨 : 예

이 지정.은 두 x 째 매개 변수에 제공된 대 s으로 지정된 j의 현재 대 s 목록에 변수를 추가 (또는 대 체)합니다. 2.7.0부터이 기능은 ID 범위를 지원합니다.

명시 적으로 대상 첨부

이는 특정 변수의 검사를 제외하도록 대상 목록을 외부 적으로 업데이트하려는 예외를 구현할 때 유용합니다.

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} "

SecRuleUpdateTargetById 958895! ARGS : 전자 메일

앞의 예제에서 효과적인 결과 규칙은 다음과 같이 대상을 변수 목록의 끝에 추가합니다.

ARR : 이메일 "[\; \ | \`] \ W *? \ bmail \ b"\
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} ""

타겟 사양에서 정규 표현식을 사용할 수도 있습니다.

SecRuleUpdateTargetById 981172 "! REQUEST_COOKIES : / ^ appl1 _. * /"

명시 적으로 대상 대체

또한 대상 목록을 환경에 적합한 다른 것으로 완전히 대체 할 수 있습니다. 예를 들어 REQUEST_FILENAME 대신 REQUEST_URI를 검사하려면 다음과 같이하면됩니다.

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} "

SecRuleUpdateTargetById 958895 REQUEST_URI REQUEST_FILENAME

앞의 예제에서 효과적인 결과 규칙은 다음과 같이 변수 목록의 시작 부분에있는 대상을 대체합니다.

SecRule REQUEST_URI | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"\
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} ""

주 : ruleRemoveById 지정 문에 ctl 조치를 사용하여 동일한 작업을 수행 할 수도 있습니다. 이는 특정 URL에 대한 대상 만 업데이트하여 대상을 조건부로 추가하려는 경우에 유용합니다.

SecRuleUpdateTargetByMsg

설명 : 지정된 규칙의 대상 (변수) 목록을 규칙 메시지로 업데이트합니다.

Syntax: SecRuleUpdateTargetByMsg TEXT TARGET1[,TARGET2,TARGET3] REPLACED_TARGET

사용 예 : SecRuleUpdateTargetByMsg "Cross-site Scripting (XSS) Attack" "!ARGS:foo"

범위 : 모든

버전 : 2.7-2.9.x

libModSecurity : TBI 에서 지원됨

이 지정.은 두 x 째 매개 변수에 제공된 대 s으로 지정된 j의 현재 대 s 목록에 변수를 추가 (또는 대 체)합니다.

명시 적으로 대상 첨부

이는 특정 변수의 검사를 제외하도록 대상 목록을 외부 적으로 업데이트하려는 예외를 구현할 때 유용합니다.

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} "

SecRuleUpdateTargetByMsg "시스템 명령 주입"! ARGS : 전자 메일

앞의 예제에서 효과적인 결과 규칙은 다음과 같이 대상을 변수 목록의 끝에 추가합니다.

ARR : 이메일 "[\; \ | \`] \ W *? \ bmail \ b"\
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} ""

명시 적으로 대상 대체

또한 대상 목록을 환경에 적합한 다른 것으로 완전히 대체 할 수 있습니다. 예를 들어 REQUEST_FILENAME 대신 REQUEST_URI를 검사하려면 다음과 같이하면됩니다.

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} "

SecRuleUpdateTargetByMsg "시스템 명령 삽입"REQUEST_URI REQUEST_FILENAME

앞의 예제에서 효과적인 결과 규칙은 다음과 같이 대상을 변수 목록의 끝에 추가합니다.

SecRule REQUEST_URI | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"\
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} ""

SecRuleUpdateTargetByTag

설명 : 지정된 규칙의 대상 (변수) 목록을 규칙 태그로 업데이트합니다.

Syntax: SecRuleUpdateTargetByTag TEXT TARGET1[,TARGET2,TARGET3] REPLACED_TARGET

사용 예 : SecRuleUpdateTargetByTag "WEB_ATTACK/XSS" "!ARGS:foo"

범위 : 모든

버전 : 2.7-3.0 (사전)

libModSecurity에서 지원됨 : 예

이 지정.은 두 x 째 매개 변수에 제공된 대 s으로 지정된 j의 현재 대 s 목록에 변수를 추가 (또는 대 체)합니다.

명시 적으로 대상 첨부

이는 특정 변수의 검사를 제외하도록 대상 목록을 외부 적으로 업데이트하려는 예외를 구현할 때 유용합니다.

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} "

SecRuleUpdateTargetByTag "WASCTC / WASC-31"! ARGS : 이메일

앞의 예제에서 효과적인 결과 규칙은 다음과 같이 대상을 변수 목록의 끝에 추가합니다.

ARR : 이메일 "[\; \ | \`] \ W *? \ bmail \ b"\
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} ""

명시 적으로 대상 대체

또한 대상 목록을 환경에 적합한 다른 것으로 완전히 대체 할 수 있습니다. 예를 들어 REQUEST_FILENAME 대신 REQUEST_URI를 검사하려면 다음과 같이하면됩니다.

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} "

SecRuleUpdateTargetByTag "WASCTC / WASC-31"REQUEST_URI REQUEST_FILENAME

앞의 예제에서 효과적인 결과 규칙은 다음과 같이 대상을 변수 목록의 끝에 추가합니다.

SecRule REQUEST_URI | ARGS_NAMES | ARGS | XML : / * "[\; \ | \`] \ W *? \ bmail \ b"\
     auditLogParts = + E, block, msg : 'System Command Injection', id : 2, rev : '2.1.1', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhitespace, t : 소문자, ctl : WASCTC / WASC-31 ', 태그 :'OWASP_TOP_10 / A1 ', 태그 :'PCI / 6.5.2 ', 로그 데이터 :'% {TX.0} ','958895 '태그 :'WEB_ATTACK / COMMAND_INJECTION ' , 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score} setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = %
{tx.0} ""

SecServerSignature

설명 : ModSecurity에게 "Server :"응답 헤더 토큰에 표시된 데이터를 변경하도록 지시합니다.

Syntax: SecServerSignature "WEB SERVER SOFTWARE"

사용 예 : SecServerSignature "Microsoft-IIS/6.0"

범위 : Main

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

이 지정 문이 작동하려면 Apache ServerTokens 지정 문을 Full로 설정해야합니다. ModSecurity는이 메모리 공간에 보관 된 서버 서명 데이터를이 지시문에 설정된 데이터로 덮어 씁니다. ServerTokens가 Full로 설정되지 않은 경우 메모리 공간은 삽입하려는 새 데이터를 보유 할만큼 충분히 크지 않습니다.

참고 : VirtualHosts에서는이 지시어를 사용할 수 없습니다. 활성화 된 경우 기본 modsecurity.conf와 같은 전역 서버 전체 구성 파일에 배치해야합니다.

SecStatusEngine

설명 : 상태보고 기능을 제어합니다. DNS 기반보고를 사용하여 ModSecurity Project 팀에 소프트웨어 버전 정보를 보냅니다.

Syntax: SecStatusEngine On|Off

사용 예 : SecStatusEngine On

범위 : 모든

버전 : 2.8.0-2.9.x

libModSecurity에서 지원됨 : 예

기본값 : 꺼짐

SecStatusEngine 지정 문이 없으면 비활성화됩니다. SecStatusEngine이 On으로 표시되면 웹 서버가 시작될 때 다음 정보가 ModSecurity 프로젝트 팀과 공유됩니다.

• 서버의 익명 고유 ID
• 버전 :
  • ModSecurity
  • 웹 서버 소프트웨어 (Apache, IIS, Nginx, Java)
  • 4 월
  • Libxml2
  • 루아
  • PCRE

참고 : 이것은 어떤 데이터가 전송 될지를 나타내는 Apache error_log에 제공된 정보의 예입니다.

[: 1 월 20 일 10 : 55 : 22.001020 2014] [: 공지] [pid 18231 : tid 140735189168512] ModSecurity : StatusEngine 호출 : "2.7.7, Apache / 2.4.4 (Unix), 1.4.6 / 1.4.6, 8.32 /8.32 2012-11-30, 루아 5.1 / (null), 2.7.8 / (null), 96ce9ba3c2fb71f7a8bb92a88d560d44dbe459b8 "
[Mon Jan 20 10 : 55 : 22.089012 2014] [: notice] [pid 18231 : tid 140735189168512] ModSecurity : StatusEngine 호출이 성공적으로 제출되었습니다.

SecStreamInBodyInspection

설명 : 재 할당 가능한 버퍼에서 인바운드 요청 데이터에 대한 스트림 검사를 사용하는 기능을 구성합니다. 보안상의 이유로 우리는 여전히 스트림을 버퍼링하고 있습니다.

Syntax: SecStreamInBodyInspection On|Off

사용 예 : SecStreamInBodyInspection On

범위 : 모든

버전 : 2.6.0-2.9.x

기본값 : 꺼짐

libModSecurity에서 지원됨 : 아니오

이 기능을 사용하면 STREAM_INPUT_BODY 변수를 만들 수 있으며 데이터 수정이나 모든 콘텐츠 유형의 원시 데이터에있는 데이터와 일치하는 데 유용합니다.

참고 :이 지시문은 REQUEST_BODY 페이로드 데이터에 대한 전체 액세스 권한을 제공합니다. REQUEST_URI 또는 ​​REQUEST_HEADER 데이터는 포함되지 않습니다. 또한 REQUEST_BODY와는 다른 모든 종류의 콘텐츠 유형에 데이터를 제공합니다.

참고 :이 지시문은 libModSecurity (v3)에서 지원되지 않습니다. 당연히 STREAM_INPUT_BODY도 libModSecurity에서 지원되지 않습니다.

참고 :이 지시어는 파일 업로드 시간에 상당한 영향을 줄 수 있습니다. 영향은 서버 자원과 스트리밍되는 요청 본문에서 수행되는 작업의 성격에 따라 달라집니다.

SecStreamOutBodyInspection

설명 : 재 할당 가능한 버퍼에서 아웃 바운드 요청 데이터에 대한 스트림 검사를 사용하는 기능을 구성합니다. 보안상의 이유로 우리는 여전히 스트림을 버퍼링하고 있습니다.

Syntax: SecStreamOutBodyInspection On|Off

사용 예 : SecStreamOutBodyInspection On

범위 : 모든

버전 : 2.6.0-2.9.x

libModSecurity에서 지원됨 : TBD

기본값 : 꺼짐

이 기능을 사용하면 STREAM_OUTPUT_BODY 변수를 만들 수 있으며 응답 본문에 데이터를 수정해야 할 때 유용합니다.

참고 :이 지시문은 RESPONSE_BODY 페이로드 데이터에 대한 액세스를 제공합니다. RESPONSE_HEADER 데이터는 포함되지 않습니다.

SecTmpDir

설명 : 임시 파일을 작성할 디렉토리를 구성합니다.

Syntax: SecTmpDir /path/to/dir

사용 예 : SecTmpDir /tmp

범위 : 모든

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

지정된 위치는 Apache 사용자 프로세스가 쓰기 가능해야합니다. 이것은 검사 중에 ModSecurity가 메모리 부족 (SecRequestBodyInMemoryLimit 지정 문에 지정된 것보다 많은 데이터)이있는 경우 디스크로 데이터를 스왑 할 디렉토리 위치입니다.

SecUnicodeMapFile

설명 : urlDecodeUni 변환 함수가 정규화 중에 유니 코드 코드 포인트를 매핑하는 데 사용할 파일의 경로를 정의하고 사용할 코드 포인트를 지정합니다.

Syntax: SecUnicodeMapFile /path/to/unicode.mapping CODEPOINT

사용 예 : SecUnicodeMapFile unicode.mapping 20127

범위 : 모든

버전 : 2.6.1-2.9.x

libModSecurity : TBI 에서 지원됨

SecUnicodeCodePage

설명 : 정규화 중에 urlDecodeUni 변환 함수가 사용할 유니 코드 코드 포인트를 정의합니다.

Syntax: SecUnicodeCodePage XXXXX

사용 예 : SecUnicodeCodePage 20127

범위 : 모든

버전 : 2.6.1 - 사용 불능

libModSecurity에서 지원됨 : 아니오 (더 이상 사용되지 않음)

SecUploadDir

설명 : 가로채는 파일을 저장할 디렉토리를 구성합니다.

Syntax: SecUploadDir /path/to/dir

사용 예 : SecUploadDir /tmp

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

이 디렉토리는 SecTmpDir로 정의 된 임시 디렉토리와 동일한 파일 시스템에 있어야합니다. 이 지시문은 SecUploadKeepFiles와 함께 사용됩니다.

SecUploadFileLimit

설명 : 다중 파트 POST에서 처리되는 최대 파일 업로드 수를 구성합니다.

Syntax: SecUploadFileLimit number

사용 예 : SecUploadFileLimit 10

범위 : 모든

버전 : 2.5.12

libModSecurity에서 지원됨 : 예

기본값은 100 개의 파일로 설정되지만이 값을 줄이는 것이 좋습니다. 제한을 초과하는 파일은 추출되지 않으며 MULTIPART_FILE_LIMIT_EXCEEDED 및 MULTIPART_STRICT_ERROR 플래그가 설정됩니다. 파일 검사를 우회하지 않으려면이 플래그 중 하나를 확인해야합니다.

참고 : 한도를 초과하면 부품 이름과 파일 이름이 FILES_NAME 및 FILES에 계속 기록되며 파일 크기는 FILES_SIZES로 기록되지만 임시 파일이 생성되지 않았으므로 FILES_TMPNAMES에는 레코드가 없습니다.

SecUploadFileMode

설명 : 8 진수 모드 (chmod에서 사용)를 사용하여 업로드 된 파일의 모드 (권한)를 구성합니다.

Syntax: SecUploadFileMode octal_mode|"default"

사용 예 : SecUploadFileMode 0640

범위 : 모든

버전 : 2.1.6

libModSecurity에서 지원됨 : 예

이 기능은 8 진 파일 모드를 지원하지 않는 운영 체제에서는 사용할 수 없습니다. 기본 모드 (0600)는 파일을 쓰는 계정에만 읽기 / 쓰기 권한을 부여합니다. 다른 계정에서 액세스해야하는 경우 (clamd를 사용하는 것이 좋습니다)이 지시문이 필요할 수 있습니다. 그러나 잠재적으로 중요한 데이터가 권한이없는 사용자에게 노출되지 않도록하려면이 지정 문을주의해서 사용하십시오. "default"값을 사용하면 기본 설정으로 되돌아갑니다.

주 : 프로세스 umask는이 지정 문을 사용하여 설정된 모드보다 더 제한적인 경우 여전히 모드를 제한 할 수 있습니다.

SecUploadKeepFiles

설명 : 트랜잭션 처리 후 가로채는 파일을 보관할지 여부를 구성합니다.

Syntax: SecUploadKeepFiles On|Off|RelevantOnly

사용 예 : SecUploadKeepFiles On

범위 : 모든

버전 : 2.0.0

libModSecurity에서 지원됨 : 예

이 지시문은 저장 디렉터리를 정의해야합니다 (SecUploadDir 사용).

가능한 값은 다음과 같습니다.

• 켜기 - 업로드 된 파일을 유지합니다.
• 끄기 - 업로드 된 파일을 보관하지 마십시오.
• RelevantOnly - 관련성 이 높은 요청에 속한 파일 만 보관합니다.

SecWebAppId

설명 : 별도의 영구 세션 및 사용자 저장소를 허용하는 응용 프로그램 네임 스페이스를 만듭니다.

Syntax: SecWebAppId "NAME" 

사용 예 : SecWebAppId "WebApp1" 

범위 : 모든

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

기본값 : 기본값

응용 프로그램 네임 스페이스는 여러 응용 프로그램이 동일한 서버에 배포 될 때 세션 ID와 사용자 ID 간의 충돌을 피하기 위해 사용됩니다. 사용하지 않으면 세션 ID 간의 충돌이 발생할 수 있습니다.

<VirtualHost * : 80> 
ServerName app1.example.com 
SecWebAppId "App1"...
</ virtualhost>

<VirtualHost * : 80> 
ServerName app2.example.com 
SecWebAppId "App2"...
</ virtualhost>

표시된 두 가지 구성 예제에서 SecWebAppId는 Apache VirtualHost 지시문과 함께 사용됩니다. 응용 프로그램 네임 스페이스 정보는 감사 로그에도 기록됩니다 (H 부분의 WebApp-Info 헤더 사용).

SecXmlExternalEntity

설명 : xml 외부 엔터티의로드 프로세스를 사용 또는 사용 안 함으로 설정합니다. 프로세스를 올바르게 확인하지 않고 외부 엔터티를로드하면 보안 문제가 발생할 수 있습니다.

Syntax: SecXmlExternalEntity On|Off 

사용 예 : SecXmlExternalEntity Off 

범위 : 모든

버전 : 2.7.3

libModSecurity에서 지원됨 : 예

기본값 : 기본값은 꺼짐입니다.

참고 :@validateSchema 또는 @validateDtd연산자 를 사용해야하는 경우이 지정 문을 활성화해야합니다 .

처리 단계

ModSecurity 2.x는 규칙을 Apache 요청주기의 다음 5 단계 중 하나에 배치 할 수 있습니다.

• 요청 헤더 (REQUEST_HEADERS)
• 요청 본문 (REQUEST_BODY)
• 응답 헤더 (RESPONSE_HEADERS)
• 응답 본문 (RESPONSE_BODY)
• 로깅 (로깅)

다음은 표준 Apache 요청주기의 다이어그램입니다. 다이어그램에는 5 개의 ModSecurity 처리 단계가 표시됩니다.

규칙이 실행되는 동안 실행되는 단계를 선택하려면 규칙에서 직접 또는 SecDefaultAction 지시문을 사용하여 단계 작업을 사용하십시오.

SecDefaultAction "로그, 패스, 단계 : 2, ID : 4"
SecRule REQUEST_HEADERS : 호스트 "! ^ $" "거부, 단계 : 1, ID : 5"

참고 : 각 단계에서 사용할 수있는 데이터는 누적됩니다. 즉, 이후 단계로 이동하면 트랜잭션에서 점점 더 많은 데이터에 액세스 할 수 있습니다.

참고 : 규칙은 단계에 따라 실행되므로 두 규칙이 구성 파일에서 인접하지만 다른 단계에서 실행되도록 설정되어 있어도 차례대로 발생하지는 않습니다. 구성 파일의 규칙 순서는 각 단계의 규칙 내에서만 중요합니다. 이것은 skip 및 skipAfter 액션을 사용할 때 특히 중요합니다.

참고 : LOGGING 단계는 특별합니다. 이전 단계에서 발생한 모든 트랜잭션의 끝에서 실행됩니다. 이것은 요청이 가로 채거나 트랜잭션을 통과시키기 위해 허용 조치가 사용 된 경우에도 처리된다는 것을 의미합니다.

위상 요청 헤더

이 단계의 규칙은 Apache가 요청 헤더 읽기를 완료 한 직후에 처리됩니다 (읽기 후 요청 단계). 이 시점에서 요청 본문은 아직 읽히지 않았습니다. 모든 요청 인수를 사용할 수있는 것은 아닙니다. 규칙은 요청을 처리하기 전에 Apache가 요청을 수행하기 전에 조기에 실행해야하는 경우 (요청 본문이 읽히기 전에 수행 할 작업), 요청 본문을 버퍼링해야하는지 여부를 결정할 때이 단계에 배치해야합니다. 요청 본문을 처리해야합니다 (예 : XML로 구문 분석할지 여부).

참고 :이 단계의 규칙은 읽기 요청 후 훅에 아직이 정보가 없으므로 Apache 범위 지침 (디렉토리, 위치, 위치 일치 등)을 활용할 수 없습니다. 여기 예외는 VirtualHost 지시어입니다. Apache 위치에서 ModSecurity 규칙을 사용하려면 Phase 2에서 실행해야합니다. Apache Request Cycle / ModSecurity Processing Phases 다이어그램을 참조하십시오.

위상 요청 본문

이것은 범용 입력 분석 단계입니다. 대부분의 응용 프로그램 지향 규칙은 여기에 있어야합니다. 이 단계에서는 요청 본문을 읽었 음을 보증합니다 (요청 본문을 읽은 경우). ModSecurity는 요청 본문 단계에 대해 세 가지 인코딩 유형을 지원합니다.

• application / x-www-form-urlencoded - 양식 데이터를 전송하는 데 사용됩니다.
• multipart / form-data - 파일 전송에 사용됩니다.
• text / xml - XML ​​데이터를 전달하는 데 사용됩니다.

다른 인코딩은 대부분의 웹 응용 프로그램에서 사용되지 않습니다.

참고 : 요청 본문 단계 데이터에 액세스하려면 SecRequestBodyAccess를 On으로 설정해야합니다.

위상 응답 헤더

이 단계는 응답 헤더가 클라이언트로 다시 보내지기 직전에 수행됩니다. 해당 상황이 발생하기 전에 응답을 관찰하고 응답 헤더를 사용하여 응답 본문을 버퍼링할지 여부를 결정하려면 여기를 실행하십시오. 일부 응답 상태 코드 (예 : 404)는 Apache의 요청주기에서 일찍 처리되므로 예상대로 트리거 할 수 없습니다. 또한, 아파치가 나중에 훅 (예 : 날짜, 서버 및 연결)에서 추가하거나 응답하지 못하는 일부 응답 헤더가 있습니다. 프록시 설정 또는 단계에서 적절하게 작동해야합니다. 5 (로깅).

위상 응답 바디

이것은 범용 출력 분석 단계입니다. 이 시점에서 응답 본문에 대해 규칙을 실행할 수 있습니다 (물론 버퍼링 된 경우). 이것은 정보 유출, 오류 메시지 또는 실패한 인증 텍스트에 대해 아웃 바운드 HTML을 검사하려는 단계입니다.

참고 : 응답 본문 데이터에 액세스하려면 SecResponseBodyAccess를 On으로 설정해야합니다

위상 로깅

이 단계는 로깅이 시작되기 직전에 실행됩니다. 이 단계에 적용되는 규칙은 로깅이 수행되는 방식에만 영향을 미칩니다. 이 단계는 Apache가 기록한 오류 메시지를 검사하는 데 사용할 수 있습니다. 너무 늦기 때문에이 단계에서 연결을 거부하거나 차단할 수 없습니다. 이 단계에서는 3 단계 또는 4 단계 중 사용할 수 없었던 다른 응답 헤더도 검사 할 수 있습니다. 이 단계에서 ModSecurity 2.5.0 이상 버전의 구성 오류이므로 규칙에 방해가되지 않도록주의해야합니다.

변수

ModSecurity 2.x에서 지원되는 변수는 다음과 같습니다.

ARGS

ARGS는 콜렉션이며 자체 매개 변수 (POST Payload를 포함한 모든 인수를 의미 함), 정적 매개 변수 (해당 이름의 인수와 일치) 또는 정규 표현식 (모든 인수를 정규 표현식과 일치하는 이름과 일치 시킴)과 함께 사용할 수 있습니다. . 쿼리 문자열 또는 본문 인수 만 보려면 ARGS_GET 및 ARGS_POST 컬렉션을 참조하십시오.

일부 변수는 실제로 콜렉션이며, 런타임시 더 많은 변수로 확장됩니다. 다음 예는 모든 요청 인수를 검사합니다.

SecRule ARGS dirty "id:7"

그러나 때로는 컬렉션의 일부만보기를 원할 것입니다. 이 작업은 선택 연산자 (콜론)를 사용하여 수행 할 수 있습니다. 다음 예제는 p라는 이름의 인자만을 살펴볼 것입니다 (일반적으로 요청은 같은 이름의 인자를 여러 개 가질 수 있습니다).

SecRule ARGS:p dirty "id:8"

제외를 지정할 수도 있습니다. 다음은 z라는 이름의 것을 제외하고 dirty라는 단어에 대한 모든 요청 인수를 검사합니다 (다시 z라는 이름의 인수가 0 개 이상있을 수 있음).

SecRule ARGS|!ARGS:z dirty "id:9"

컬렉션에 얼마나 많은 변수가 있는지 계산할 수있는 특수 연산자가 있습니다. 다음 규칙은 요청에 0보다 많은 인수가있는 경우 트리거합니다 (당분간 두 번째 매개 변수를 무시하십시오).

SecRule &ARGS !^0$ "id:10"

그리고 때로는 약간 다른 이름을 가진 일련의 매개 변수를 살펴볼 필요가 있습니다. 이 경우 선택 연산자 자체에서 정규 표현식을 지정할 수 있습니다. 다음 규칙은 이름이 id_로 시작하는 모든 인수를 조사합니다.

SecRule ARGS:/^id_/ dirty "id:11"

참고 : ARGS : p를 사용하면 인수 p가없는 경우 연산자에 대해 아무런 호출도 발생하지 않습니다.

ModSecurity 1.X에서 ARGS 변수는 QUERY_STRING + POST_PAYLOAD를 나타 냈지만 이제는 개별 변수로 확장됩니다.

ARGS_COMBINED_SIZE

모든 요청 매개 변수의 결합 된 크기를 포함합니다. 파일은 계산에서 제외됩니다. 이 변수는 예를 들어 인수 데이터의 전체 크기가 특정 임계 값 이하인지 확인하는 규칙을 작성하는 경우에 유용합니다. 다음 규칙은 매개 변수의 길이가 2500 바이트를 초과하는 요청을 감지합니다.

SecRule ARGS_COMBINED_SIZE "@gt 2500" "id:12"

ARGS_GET

ARGS_GET은 ARGS와 유사하지만 쿼리 문자열 매개 변수 만 포함합니다.

ARGS_GET_NAMES

ARGS_GET_NAMES는 ARGS_NAMES와 유사하지만 쿼리 문자열 매개 변수의 이름 만 포함합니다.

ARGS_NAMES

모든 요청 매개 변수 이름을 포함합니다. 검사 할 특정 매개 변수 이름을 검색 할 수 있습니다. 긍정적 인 정책 시나리오에서는 권한 부여 된 인수 이름 만 허용 목록 (느낌표가있는 거꾸로 된 규칙 사용)을 허용 할 수 있습니다. 이 예제 규칙은 두 개의 인수 이름 만 허용합니다. p 및 a :

SecRule ARGS_NAMES "!^(p|a)$" "id:13"

ARGS_POST

ARGS_POST는 ARGS와 비슷하지만 POST 본문의 인수 만 포함합니다.

ARGS_POST_NAMES

ARGS_POST_NAMES는 ARGS_NAMES와 유사하지만 요청 본문 매개 변수의 이름 만 포함합니다.

AUTH_TYPE

이 변수는 HTTP에 내장 된 메소드 중 하나가 사용되는 경우 사용자를 확인하는 데 사용되는 인증 메소드를 보유합니다. 역방향 프록시 배포에서는 인증이 백엔드 웹 서버에서 처리되는 경우이 정보를 사용할 수 없습니다.

SecRule AUTH_TYPE "Basic" "id:14"

지속

현재 트랜잭션이 시작된 이후 경과 된 시간 (밀리 초)을 포함합니다. 2.6.0부터 사용 가능합니다.

참고 : ModSecurity 2.7.0부터는 시간이 마이크로 초입니다.

ENV

ModSecurity 또는 다른 서버 모듈에 의해 설정된 환경 변수에 대한 액세스를 제공하는 콜렉션. 원하는 변수의 이름을 지정하려면 단일 매개 변수가 필요합니다.

# 환경 변수 설정 
SecRule REQUEST_FILENAME "printenv"\
"단계 : 2, id : 15, 통과, setenv : tag = 의심스러운" 

# 환경 변수 검사
SecRule ENV : 태그 "의심스러운" "id : 16"

# 다른 아파치 모듈에서 환경 변수 읽기 (mod_ssl)
SecRule TX : ANOMALY_SCORE "@gt 0" "단계 : 5, id : 16, msg : '% {env.ssl_cipher}'"

참고 : setenv를 사용하여 Apache에서 액세스 할 환경 변수를 설정하십시오.

파일

원본 파일 이름 모음을 포함합니다 (원격 사용자의 파일 시스템에서 호출 됨). 검사 된 다중 파트 / 양식 데이터 요청에서만 사용할 수 있습니다.

SecRule FILES "@rx \.conf$" "id:17"

참고 : 파일이 요청 본문에서 추출 된 경우에만 사용할 수 있습니다.

FILES_COMBINED_SIZE

요청 본문으로 전송 된 파일의 총 크기를 포함합니다. 검사 된 다중 파트 / 양식 데이터 요청에서만 사용할 수 있습니다.

SecRule FILES_COMBINED_SIZE "@gt 100000" "id:18"

FILES_NAMES

파일 업로드에 사용 된 양식 필드 목록을 포함합니다. 검사 된 다중 파트 / 양식 데이터 요청에서만 사용할 수 있습니다.

SecRule FILES_NAMES "^upfile$" "id:19"

FULL_REQUEST

전체 요청을 포함합니다 : 요청 줄, 요청 헤더 및 요청 본문 (있는 경우). SecRequestBodyAccess가 On으로 설정된 경우에만 마지막으로 사용할 수 있습니다. 여기서 SecRequestBodyAccess의 모든 속성 (예 : SecRequestBodyLimit)을 준수합니다.

SecRule FULL_REQUEST "User-Agent: ModSecurity Regression Tests" "id:21"

참고 : 버전 2.8.0 이상에서 사용 가능

FULL_REQUEST_LENGTH

FULL_REQUEST가 사용할 수있는 바이트 수를 나타냅니다.

SecRule FULL_REQUEST_LENGTH "@eq 205" "id:21"

참고 : 버전 2.8.0 이상에서 사용 가능

FILES_SIZES

개별 파일 크기 목록을 포함합니다. 개별 업로드 된 파일에 크기 제한을 구현하는 데 유용합니다. 검사 된 다중 파트 / 양식 데이터 요청에서만 사용할 수 있습니다.

SecRule FILES_SIZES "@gt 100" "id:20"

FILES_TMPNAMES

디스크의 임시 파일 이름 목록을 포함합니다. @inspectFile과 함께 사용할 때 유용합니다. 검사 된 다중 파트 / 양식 데이터 요청에서만 사용할 수 있습니다.

SecRule FILES_TMPNAMES "@inspectFile /path/to/inspect_script.pl" "id:21"

FILES_TMP_CONTENT

value가 업로드 된 파일의 내용 인 키 - 값 세트를 포함합니다. @fuzzyHash와 함께 사용할 때 유용합니다.

SecRule FILES_TMP_CONTENT "@fuzzyHash $ENV{CONF_DIR}/ssdeep.txt 1" "id:192372,log,deny"

참고 : 버전 2.9.0-RC1 +에서 사용 가능

참고 II :이 컬렉션을 채우려면 SecUploadKeepFiles를 'On'으로 설정해야합니다.

GEO

GEO는 마지막 @geoLookup 연산자의 결과로 채워지는 모음입니다. 컬렉션은 IP 주소 또는 호스트 이름에서 보이는 지형 필드를 일치시키는 데 사용할 수 있습니다.

ModSecurity 2.5.0부터 사용 가능합니다.

전지:

• COUNTRY_CODE : 두 자로 된 국가 코드. 예 : 미국, GB 등
• COUNTRY_CODE3 : 최대 3 자의 문자 국가 코드.
• COUNTRY_NAME : 전체 국가 이름입니다.
• COUNTRY_CONTINENT : 국가가 위치한 두 대륙의 대륙. 예 : EU
• 지역 : 두 개의 문자 영역. 미국의 경우 이것은 주입니다. 캐나다, 섭리 등
• CITY : 데이터베이스에서 지원하는 경우 도시 이름.
• POSTAL_CODE : 데이터베이스에서 지원하는 우편 번호입니다.
• LATITUDE : 데이터베이스가 지원하는 경우 위도.
• LONGITUDE : 데이터베이스에서 지원하는 경도.
• DMA_CODE : 데이터베이스에서 지원하는 대도시 지역 코드입니다. (미국에만 해당)
• AREA_CODE : 전화 시스템 지역 번호. (미국에만 해당)

예:

SecGeoLookupDb /usr/local/geo/data/GeoLiteCity.dat
...
SecRule REMOTE_ADDR "@geoLookup" "chain, id : 22, drop, msg : '비 -GB IP 주소'"
SecRule GEO : COUNTRY_CODE "! @streq GB"

최우선 순위

이 변수는 지금까지 일치하는 모든 규칙 중 가장 높은 심각도를 보유합니다. 심각도는 숫자 값이므로 @lt와 같은 비교 연산자와 함께 사용할 수 있습니다. 값 255는 심각도가 설정되지 않았 음을 나타냅니다.

SecRule HIGHEST_SEVERITY "@le 2" "phase:2,id:23,deny,status:500,msg:'severity %{HIGHEST_SEVERITY}'"

참고 : 심각도가 높을수록 숫자 값이 낮습니다.

INBOUND_DATA_ERROR

요청 본문 크기가 SecRequestBodyLimit 지시어로 구성된 설정보다 높으면이 변수는 1로 설정됩니다. 정책에는 항상이 변수를 검사하는 규칙이 있어야합니다. 가양 성 및 기본 정책의 비율에 따라 규칙 실행 여부를 결정하거나 차단할지 여부를 결정해야합니다.

이 변수를 사용하는 가장 좋은 방법은 아래 예와 같습니다.

SecRule INBOUND_DATA_ERROR "@eq 1" "phase:1,id:24,t:none,log,pass,msg:'Request Body Larger than SecRequestBodyLimit Setting'"

MATCHED_VAR

이 변수는 가장 최근에 일치 된 변수의 값을 보유합니다. TX : 0과 유사하지만 모든 운영자가 자동으로 지원하므로 캡처 작업을 지정할 필요가 없습니다.

SecRule ARGS 패턴 체인, deny, id : 25
  SecRule MATCHED_VAR "추가 조사"

참고 :이 변수는 마지막 연산자 일치에 대한 데이터를 보유합니다 . 즉, 하나 이상의 일치 항목이있는 경우 마지막 항목 만 채워집니다. 모든 일치를 원하면 MATCHED_VARS 변수를 사용하십시오.

MATCHED_VARS

MATCHED_VAR과 유사 하지만 현재 연산자 검사에 대한 모든 일치 항목 의 모음입니다 .

SecRule ARGS 패턴 "chain, deny, id : 26"
  SecRule MATCHED_VARS "@eq ARGS : param"

MATCHED_VAR_NAME

이 변수는 일치 된 변수의 전체 이름을 보유합니다.

SecRule ARGS 패턴 "chain, deny, id : 27"
  SecRule MATCHED_VAR_NAME "@eq ARGS : param"

참고 :이 변수는 마지막 연산자 일치에 대한 데이터를 보유합니다 . 즉, 하나 이상의 일치 항목이있는 경우 마지막 항목 만 채워집니다. 모든 일치 항목을 원하면 MATCHED_VARS_NAMES 변수를 사용하십시오.

MATCHED_VARS_NAMES

MATCHED_VAR_NAME과 유사 하지만 현재 연산자 검사에 대한 모든 일치 항목 의 모음입니다 .

SecRule ARGS 패턴 "chain, deny, id : 28"
  SecRule MATCHED_VARS_NAMES "@eq ARGS : param"

MODSEC_BUILD

이 변수는 ModSecurity 빌드 번호를 저장합니다. 이 변수는 특정 빌드에서만 사용할 수있는 기능을 사용하기 전에 빌드 번호를 확인하는 데 사용됩니다. 예:

SecRule MODSEC_BUILD "! @ge 02050102" "skipAfter : 12345, id : 29"
SecRule ARGS "@pm 일부 키워드" "id : 12345, deny, status : 500"

MULTIPART_CRLF_LF_LINES

이 플래그 변수는 다중 부분 요청이 혼합 행 종결자를 사용할 때마다 1로 설정됩니다. 다중 파트 / 양식 데이터 RFC는 행을 종료하는 데 CRLF 시퀀스를 사용해야합니다. 일부 클라이언트 구현에서는 LF 만 사용하여 특정 상황에서 진행할 수 있도록하려는 경우 (MULTIPART_STRICT_ERROR 사용을 중지하고 각 다중 부분 플래그 변수를 개별적으로 검사하여 MULTIPART_LF_LINE을 피할 필요가 있음). 그러나 CRLF와 LF 라인 종결자를 혼합하는 것은 회피를 허용 할 수 있기 때문에 위험합니다. 따라서 이러한 경우 MULTIPART_CRLF_LF_LINES에 대한 수표를 추가해야합니다.

MULTIPART_FILENAME

이 변수는 FILENAME 필드의 다중 부분 데이터를 포함합니다.

MULTIPART_NAME

이 변수는 NAME 필드의 다중 부분 데이터를 포함합니다.

MULTIPART_STRICT_ERROR

REQBODY_PROCESSOR_ERROR, MULTIPART_BOUNDARY_QUOTED, MULTIPART_BOUNDARY_WHITESPACE, MULTIPART_DATA_BEFORE, MULTIPART_DATA_AFTER, MULTIPART_HEADER_FOLDING, MULTIPART_LF_LINE, MULTIPART_MISSING_SEMICOLON MULTIPART_INVALID_QUOTING MULTIPART_INVALID_HEADER_FOLDING MULTIPART_FILE_LIMIT_EXCEEDED 다음 변수 중 하나가도 1로 설정된 경우 MULTIPART_STRICT_ERROR 1로 설정한다. 이 변수들 각각은 multipart / form-data 형식의 요청 본문에서 흔치 않은 (때때로 합법적 임에도 불구하고) 측면을 포함합니다. 정책에는 항상이 변수 (더 쉽게) 또는 하나 이상의 개별 변수 (원하는 것을 정확하게 알고있는 경우)를 검사하는 규칙이 포함되어야합니다. 가양 성 및 기본 정책의 비율에 따라 규칙 실행 여부를 결정하거나 차단할지 여부를 결정해야합니다.

이 변수를 사용하는 가장 좋은 방법은 아래 예와 같습니다.

SecRule MULTIPART_STRICT_ERROR "! @eq 0"\
"phase : 2, id : 30, t : none, log, deny, msg : '다중 요청 요청 본문 \
엄격한 검증 실패 : \
PE % {REQBODY_PROCESSOR_ERROR}, \
BQ % {MULTIPART_BOUNDARY_QUOTED}, \
BW % {MULTIPART_BOUNDARY_WHITESPACE}, \
DB % {MULTIPART_DATA_BEFORE}, \
DA % {MULTIPART_DATA_AFTER}, \
HF % {MULTIPART_HEADER_FOLDING}, \
LF % {MULTIPART_LF_LINE}, \
SM % {MULTIPART_MISSING_SEMICOLON}, \
IQ % {MULTIPART_INVALID_QUOTING}, \
IQ % {MULTIPART_INVALID_HEADER_FOLDING}, \
FE % {MULTIPART_FILE_LIMIT_EXCEEDED} ' "

multipart / form-data 파서는 ModSecurity v2.1.3에서 업그레이드되어 회피 신호를 적극적으로 찾습니다. 많은 변수 (위에 열거 된 바와 같이)가 파싱 과정에서 발견 된 다양한 사실을 노출하기 위해 추가되었습니다. MULTIPART_STRICT_ERROR 변수는 한 번에 모든 이상을 검사 할 때 편리합니다. 개별 변수를 사용하면 오탐 (false positive)의 수를 줄이기 위해 상황에 따라 탐지를 미세 조정할 수 있습니다.

MULTIPART_UNMATCHED_BOUNDARY

multipart / request-body의 구문 분석 단계에서 ModSecurity가 경계와 같은 느낌을 만났지만 그렇지 않은 경우 1로 설정합니다. 이러한 사건은 ModSecurity의 회피가 시도 될 때 발생할 수있다.

이 변수를 사용하는 가장 좋은 방법은 아래 예와 같습니다.

SecRule MULTIPART_UNMATCHED_BOUNDARY "! @eq 0"\
"phase : 2, id : 31, t : none, log, deny, msg : 'Multipart 파서가 가능한 경계를 감지했습니다.'

오 탐지 (false positive)가 많은 경우 규칙을 차단에서 로깅 전용으로 변경하십시오.

OUTBOUND_DATA_ERROR

응답 본문 크기가 SecResponseBodyLimit 지시어로 구성된 설정보다 높으면이 변수는 1로 설정됩니다. 정책에는 항상이 변수를 검사하는 규칙이 있어야합니다. 가양 성 및 기본 정책의 비율에 따라 규칙 실행 여부를 결정하거나 차단할지 여부를 결정해야합니다.

이 변수를 사용하는 가장 좋은 방법은 아래 예와 같습니다.

SecRule OUTBOUND_DATA_ERROR "@eq 1" "phase:1,id:32,t:none,log,pass,msg:'Response Body Larger than SecResponseBodyLimit Setting'"

PATH_INFO

경로 정보라고도하는 추가 요청 URI 정보가 들어 있습니다. (예 : URI /index.php/123에서 / 123은 경로 정보입니다.) 포함 된 배포에서만 사용할 수 있습니다.

SecRule PATH_INFO "^/(bin|etc|sbin|opt|usr)" "id:33"

PERF_ALL

이 특수 변수는 다른 모든 성능 변수의 조합 인 문자열을 포함하며 Stopwatch2 감사 로그 헤더에 나타나는 순서와 동일한 순서로 배열됩니다. 사용자 정의 Apache 로그에서 사용하기위한 것입니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_COMBINED

현재 트랜잭션 동안 ModSecurity에서 보낸 시간 (마이크로 초)을 포함합니다. 이 변수의 값은 PERF_SREAD를 제외한 모든 성능 변수를 추가하여 도달합니다 (영구 저장 장치에서 읽는 데 소요 된 시간은 이미 위상 측정에 포함되어 있음).

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_GC

가비지 수집을 수행하는 데 소요 된 시간을 마이크로 초 단위로 포함합니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_LOGGING

감사 로깅에 소비 된 시간 (마이크로 초)을 포함합니다. 이 값은 트랜잭션 처리가 완료된 후에 만 ​​알려져 있으므로 mod_log_config 및 % {VARNAME} M 구문을 사용하여 기록 할 수 있습니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_PHASE1

처리 단계 1을 소비 한 시간 (마이크로 초)을 포함합니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_PHASE2

처리 단계 2를 소비 한 시간 (마이크로 초)을 포함합니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_PHASE3

처리 단계 3을 소비 한 시간 (마이크로 초)을 포함합니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_PHASE4

처리 단계 4를 소비 한 시간 (마이크로 초)을 포함합니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_PHASE5

처리 단계 5를 소비 한 시간 (마이크로 초)을 포함합니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_RULES

PERF_RULES는 SecRulePerfTime으로 정의 된 성능 임계 값을 지정하는 규칙으로 채워지는 모음입니다. 컬렉션에는 마이크로 초 단위로 개별 규칙을 처리하는 데 소요 된 시간이 포함됩니다. 컬렉션의 다양한 항목은 규칙 ID를 통해 액세스 할 수 있습니다.

버전 : 2.7.0-2.9.x

libModSecurity : TBI 에서 지원됨

SecRulePerfTime 100

SecRule FILES_TMPNAMES "@inspectFile /path/to/util/runav.pl"\
  "phase : 2, id : 10001, deny, log, msg : '바이러스 검사가 오류를 감지했습니다.'"

SecRule 및 PERF_RULES "@eq 0" "단계 : 5, id : 95000, \
  pass, log, msg : '모든 규칙은 처리 시간 제한 이하로 수행되었습니다.' "
SecRule PERF_RULES "@ge 1000" "단계 : 5, id : 95001, pass, log, \
  msg : '규칙 % {MATCHED_VAR_NAME}이 (가) 1000 usec 이상을 소비했습니다.' '
SecAction "단계 : 5, id : 95002, pass, log, msg : '파일 검사에 % {PERF_RULES.10001} usec 걸렸습니다.'"

id가 10001 인 규칙은 외부 파일 검사 규칙을 정의합니다. ID가 95000 인 규칙은 PERF_RULES 컬렉션의 크기를 확인합니다. 콜렉션이 비어 있으면 로그 파일에 메모를 씁니다. 규칙 95001은 PERF_RULES 컬렉션의 모든 항목에 대해 실행됩니다. 따라서 모든 항목은 1000 마이크로 초의 한계에 대해 검사됩니다. 룰이 적어도 그 시간 동안 소비 되었다면, 룰 ID를 포함하는 노트가 로그 파일에 기록됩니다. 최종 규칙 95002는 규칙 10001 (바이러스 검사)에 소요 된 시간을 기록합니다.

PERF_SREAD

영구 저장소에서 읽은 시간을 마이크로 초 단위로 나타냅니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

PERF_SWRITE

영구 저장 장치에 쓰는 데 소비 한 시간 (마이크로 초)을 포함합니다.

버전 : 2.6.0-2.9.x

libModSecurity : TBI 에서 지원됨

QUERY_STRING

요청 URI의 쿼리 문자열 부분을 포함합니다. QUERY_STRING의 값은 URL 디코딩이 발생하지 않고 항상 원시로 제공됩니다.

SecRule QUERY_STRING "attack" "id:34"

REMOTE_ADDR

이 변수는 원격 클라이언트의 IP 주소를 보유합니다.

SecRule REMOTE_ADDR "@ipMatch 192.168.1.101" "id:35"

REMOTE_HOST

Apache 지시문 HostnameLookups가 On으로 설정된 경우이 변수는 DNS를 통해 해결 된 원격 호스트 이름을 보유합니다. 지시문을 Off로 설정하면이 변수는 원격 IP 주소를 보유하게됩니다 (REMOTE_ADDR과 동일). 이 변수의 가능한 용도는 알려진 나쁜 클라이언트 호스트 또는 네트워크 블록을 거부하거나 역으로 승인 된 호스트를 허용하는 것입니다.

SecRule REMOTE_HOST "\.evil\.network\org$" "id:36"

REMOTE_PORT

이 변수에는 웹 서버에 대한 연결을 시작할 때 클라이언트가 사용한 원본 포트에 대한 정보가 들어 있습니다.

다음 예에서는 REMOTE_PORT가 1024 미만인지 여부를 확인하여 사용자가 권한있는 사용자임을 나타냅니다.

SecRule REMOTE_PORT "@lt 1024" "id:37"

REMOTE_USER

이 변수는 인증 된 사용자의 사용자 이름을 보유합니다. 암호 액세스 컨트롤이 없으면 (기본 또는 다이제스트 인증)이 변수는 비어있게됩니다.

SecRule REMOTE_USER "@streq admin" "id:38"

참고 : 역방향 프록시 배포에서는 인증이 백엔드 웹 서버에서 처리되는 경우이 정보를 사용할 수 없습니다.

REQBODY_ERROR

요청 본문 파싱에 사용되는 요청 본문 프로세서의 상태를 포함합니다. 값은 0 (오류 없음) 또는 1 (오류) 일 수 있습니다. 이 변수는 작업을 수행하지 못할 때 요청 본문 처리기 (일반적으로 다중 / 요청 데이터 구문 분석기, JSON 또는 XML 구문 분석기)에 의해 설정됩니다.

SecRule REQBODY_ERROR "@eq 1" deny,phase:2,id:39 

참고 : 2 단계 초반에 요청 본문 프로세서 오류를 확인하는 규칙이 정책에 있어야합니다. 그렇게하지 않으면 임피던스 불일치 공격에 대한 문이 열리게됩니다. 예를 들어, ModSecurity가 파싱 할 수없는 페이로드가 응용 프로그램에서 작동하는 관대 한 파서에 의해 성공적으로 파싱 될 수 있습니다. 정책에서 차단을 지시하는 경우 오류가 감지되면 요청을 거부해야합니다. 탐지 전용 모드로 작동 할 때, 요청 본문 처리가 실패 할 때 규칙은 높은 심각도로 경고해야합니다.

관련 문제 : # 1475

REQBODY_ERROR_MSG

요청 본문 파싱 중에 오류가 발생하면 변수에 다음 오류 메시지가 포함됩니다.

SecRule REQBODY_ERROR_MSG "failed to parse" "id:40"

REQBODY_PROCESSOR

현재 사용 된 요청 본문 프로세서의 이름을 포함합니다. 가능한 값은 URLENCODED, MULTIPART 및 XML입니다.

SecRule REQBODY_PROCESSOR "^ XML $ chain, id : 41 
  SecRule XML "@validateDTD /opt/apache-frontend/conf/xml.dtd"

REQUEST_BASENAME

이 변수는 REQUEST_FILENAME의 파일 이름 부분 만 포함합니다 (예 : index.php).

SecRule REQUEST_BASENAME "^login\.php$" phase:2,id:42,t:none,t:lowercase

참고 : 기본적으로이 변수에는 비 회피 변환이 적용되지 않습니다. REQUEST_BASENAME은 경로 구분 기호로 /와 \를 모두 인식합니다. 이 변수의 값은 요청시 제공된 값에 따라 다르며 웹 서버에서 사용할 자원 (디스크)에 해당 할 필요는 없다는 것을 이해해야합니다.

REQUEST_BODY

원시 요청 본문을 보유합니다. 이 변수는 URLENCODED 요청 본문 프로세서가 사용 된 경우에만 사용할 수 있습니다. 이는 응용 프로그램 / x-www-form-urlencoded 콘텐츠 유형이 감지되거나 URLENCODED 요청 본문 파서의 사용이 강제 실행될 때 기본적으로 발생합니다.

SecRule REQUEST_BODY "^username=\w{25,}\&password=\w{25,}\&Submit\=login$" "id:43"

2.5.7부터는 REQUEST_HEADERS 단계에서 ctl : forceRequestBodyVariable 옵션을 사용하여 정의 된 요청 본문 프로세서가없는 경우에만 REQUEST_BODY 변수의 존재를 강제 할 수 있습니다.

REQUEST_BODY_LENGTH

요청 본문에서 읽은 바이트 수를 포함합니다. v2.6부터 사용 가능

REQUEST_COOKIES

이 변수는 모든 요청 쿠키 (값만)의 모음입니다. 예제 : 다음 예제에서는 Ampersand 특수 연산자를 사용하여 컬렉션에있는 변수 수를 계산합니다. 이 규칙에서는 요청에 쿠키 헤더가 포함되어 있지 않으면 트리거합니다.

SecRule &REQUEST_COOKIES "@eq 0" "id:44"

REQUEST_COOKIES_NAMES

이 변수는 모든 요청 쿠키의 이름 모음입니다. 예를 들어 JSESSIONID 쿠키가 없으면 다음 규칙이 트리거됩니다.

SecRule &REQUEST_COOKIES_NAMES:JSESSIONID "@eq 0" "id:45"

REQUEST_FILENAME

이 변수는 쿼리 문자열 부분이없는 상대 요청 URL을 보유합니다 (예 : /index.php).

SecRule REQUEST_FILENAME "^/cgi-bin/login\.php$" phase:2,id:46,t:none,t:normalizePath

참고 : REFERENCE_FILENAME에는 비 회피 변환이 사용되지 않으므로이 변수를 사용하는 규칙에 지정해야합니다.

REQUEST_HEADERS

이 변수는 모든 요청 헤더의 모음으로 사용되거나 선택된 헤더를 검사하는 데 사용될 수 있습니다 (REQUEST_HEADERS : Header-Name 구문 사용).

SecRule REQUEST_HEADERS:Host "^[\d\.]+$" "deny,id:47,log,status:400,msg:'Host header is a numeric IP address'"

참고 : ModSecurity는 웹 서버가 메시지를 처리하는 방식에 따라 동일한 이름을 가진 여러 헤더를 처리합니다. Apache의 경우 이는 모두 구분 기호로 쉼표가 붙은 단일 헤더로 연결된다는 것을 의미합니다.

REQUEST_HEADERS_NAMES

이 변수는 모든 요청 헤더의 이름 모음입니다.

SecRule REQUEST_HEADERS_NAMES "^x-forwarded-for" "log,deny,id:48,status:403,t:lowercase,msg:'Proxy Server Used'"

REQUEST_LINE

이 변수는 요청 메소드 및 HTTP 버전 정보를 포함하여 서버로 전송 된 전체 요청 라인을 보유합니다.

# POST, GET 및 HEAD 요청 메소드 만 허용하고
# 유효한 프로토콜 버전 
HTTP / (0 \ .9 | 1 \ .0 | 1 \ .1) $) ""단계 : 1, id (SecRule REQUEST_LINE "! (^ : 49, 로그, 블록, t : 없음 "

요청하기

이 변수는 트랜잭션에서 사용되는 요청 메소드를 보유합니다.

SecRule REQUEST_METHOD "^(?:CONNECT|TRACE)$" "id:50,t:none"

REQUEST_PROTOCOL

이 변수는 요청 프로토콜 버전 정보를 보유합니다.

SecRule REQUEST_PROTOCOL "!^HTTP/(0\.9|1\.0|1\.1)$" "id:51"

REQUEST_URI

이 변수는 쿼리 문자열 데이터 (예 : /index.php? p = X)를 포함한 전체 요청 URL을 포함합니다. 그러나 요청 줄에 도메인 이름이 포함되어 있어도 결코 도메인 이름을 포함하지 않습니다.

SecRule REQUEST_URI "attack" "phase:1,id:52,t:none,t:urlDecode,t:lowercase,t:normalizePath"

참고 : REFERENCE_URI에는 방지 (anti-evasion) 변환이 사용되지 않으므로이 변수를 사용하는 규칙에 지정해야합니다.

REQUEST_URI_RAW

REQUEST_URI와 동일하지만 요청 줄에 도메인 이름이 포함 된 경우 도메인 이름이 포함됩니다 (예 : http://www.example.com/index.php?p=X ).

SecRule REQUEST_URI_RAW "http:/" "phase:1,id:53,t:none,t:urlDecode,t:lowercase,t:normalizePath"

참고 : REFERENCE_URI_RAW에는 방지 (anti-evasion) 변환이 사용되지 않으므로이 변수를 사용하는 규칙에 지정해야합니다.

RESPONSE_BODY

이 변수는 응답 본문에 대한 데이터를 보유하지만 응답 본문 버퍼링이 설정된 경우에만 유지됩니다.

SecRule RESPONSE_BODY "ODBC Error Code" "phase:4,id:54,t:none"

RESPONSE_CONTENT_LENGTH

응답 본문 길이 (바이트)입니다. 3 단계부터 사용할 수 있지만 응답 바디의 길이가 항상 미리 알려지지는 않으므로 반드시 그럴 필요는 없습니다. 크기를 알 수없는 경우이 변수에는 0이 포함됩니다. RESPONSE_CONTENT_LENGTH가 단계 5에서 0을 포함하면 응답 본문의 실제 크기가 0임을 의미합니다.이 변수의 값은 본문이 수정되면 단계 사이에서 변경 될 수 있습니다. 예를 들어, 내장 모드에서 mod_deflate는 위상 4와 5 사이의 응답 본문을 압축 할 수 있습니다.

RESPONSE_CONTENT_TYPE

응답 내용 유형. 3 단계부터 시작해야합니다.이 변수에서 사용할 수있는 값은 Apache의 내부 구조에서 직접 가져옵니다. 즉, 응답 헤더에서 아직 사용할 수없는 정보가 포함될 수 있습니다. 포함 된 배포에서는 항상 RESPONSE_HEADERS : Content-Type이 아닌이 변수를 참조해야합니다.

RESPONSE_HEADERS

이 변수는 REQUEST_HEADERS가 헤더를 요청하는 것과 같은 방식으로 응답 헤더를 참조합니다.

SecRule RESPONSE_HEADERS:X-Cache "MISS" "id:55"

이 변수는 임베디드 모드에서 실행할 때 일부 헤더에 액세스하지 못할 수 있습니다. Server, Date, Connection 및 Content-Type과 같은 헤더는 클라이언트에 데이터를 보내기 바로 전에 추가 될 수 있습니다. 이 데이터는 5 단계 또는 프록시 모드로 배포 할 때 사용할 수 있어야합니다.

RESPONSE_HEADERS_NAMES

이 변수는 응답 헤더 이름의 모음입니다.

SecRule RESPONSE_HEADERS_NAMES "Set-Cookie" "phase:3,id:56,t:none"

RESPONSE_HEADERS에서 논의 된 것과 동일한 제한 사항이 적용됩니다.

RESPONSE_PROTOCOL

이 변수는 HTTP 응답 프로토콜 정보를 보유합니다.

SecRule RESPONSE_PROTOCOL "^HTTP\/0\.9" "phase:3,id:57,t:none"

RESPONSE_STATUS

이 변수는 HTTP 응답 상태 코드를 포함합니다.

SecRule RESPONSE_STATUS "^[45]" "phase:3,id:58,t:none"

이 변수는 임베디드 모드에서 예상대로 작동하지 않을 수 있습니다. 아파치는 때때로 특정 요청을 다르게 처리하고 ModSecurity (다른 모든 모듈)를 호출하지 않습니다.

규칙

이것은 액션을 트리거 한 규칙의 id, rev, severity, logdata 및 msg 필드에 대한 액세스를 제공하는 특별한 컬렉션입니다. 그것이있는 동일한 규칙만을 참조하는 데 사용될 수 있습니다.

SecRule &REQUEST_HEADERS:Host "@eq 0" "log,deny,id:59,setvar:tx.varname=%{RULE.id}"

SCRIPT_BASENAME

이 변수는 SCRIPT_FILENAME의 로컬 파일 이름 부분 만 보유합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

SecRule SCRIPT_BASENAME "^login\.php$" "id:60"

참고 : 프록시 모드에서는 사용할 수 없습니다.

SCRIPT_FILENAME

이 변수는 요청을 처리하는 데 사용될 스크립트의 전체 내부 경로를 보유합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

SecRule SCRIPT_FILENAME "^/usr/local/apache/cgi-bin/login\.php$" "id:61"

참고 : 프록시 모드에서는 사용할 수 없습니다.

SCRIPT_GID

이 변수는 스크립트의 그룹 소유자의 숫자 식별자를 보유합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

SecRule SCRIPT_GID "!^46$" "id:62"

참고 : 프록시 모드에서는 사용할 수 없습니다.

SCRIPT_GROUPNAME

이 변수는 스크립트의 그룹 소유자 이름을 보유합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

SecRule SCRIPT_GROUPNAME "!^apache$" "id:63"

참고 : 프록시 모드에서는 사용할 수 없습니다.

SCRIPT_MODE

이 변수는 스크립트의 권한 모드 데이터 (예 : 644)를 보유합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

# 작성할 수있는 스크립트를 허용하지 않습니다.
SecRule SCRIPT_MODE "^ (2 | 3 | 6 | 7) $" "id : 64"

참고 : 프록시 모드에서는 사용할 수 없습니다.

SCRIPT_UID

이 변수는 스크립트 소유자의 숫자 식별자를 보유합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

# 소유하고있는 스크립트를 실행하지 마십시오. 
# by Apache (아파치의 사용자 ID는 46 임) 
SecRule SCRIPT_UID "! ^ 46 $" "id : 65"

참고 : 프록시 모드에서는 사용할 수 없습니다.

SCRIPT_USERNAME

이 변수는 스크립트 소유자의 사용자 이름을 보유합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

# Apache SecRule이 소유 한 스크립트를 실행하지 마십시오. 
SCRIPT_USERNAME "^ apache $" "id : 66"

참고 : 프록시 모드에서는 사용할 수 없습니다.

SDBM_DELETE_ERROR

버전 : 2.x

libModSecurity에서 지원됨 : 아니오

이 변수는 APR이 SDBM 항목을 삭제하지 못하면 1로 설정됩니다.

SERVER_ADDR

이 변수는 서버의 IP 주소를 포함합니다.

SecRule SERVER_ADDR "@ipMatch 192.168.1.100" "id:67"

서버 이름

이 변수는 요청 자체에서 가져온 트랜잭션의 호스트 이름 또는 IP 주소를 포함합니다 (이는 원칙적으로 신뢰할 수 없어야 함을의 L합니다).

SecRule SERVER_NAME "hostname\.com$" "id:68"

SERVER_PORT

이 변수는 웹 서버 (또는 역방향 프록시)가 수신 대기중인 로컬 포트를 포함합니다.

SecRule SERVER_PORT "^80$" "id:69"

세션

이 변수는 세션 정보가 들어있는 모음입니다. setsid가 실행 된 후에 만 ​​사용 가능하게됩니다.

다음 예제에서는 setsid를 사용하여 SESSION을 초기화하는 방법, setvar를 사용하여 SESSION.score 값을 높이는 방법, SESSION.blocked 변수를 설정하는 방법, 마지막으로 SESSION : blocked 값을 기반으로 연결을 거부하는 방법을 보여줍니다.

# 세션 저장 장치 초기화 
SecRule REQUEST_COOKIES : PHPSESSID! ^ $ "phase : 2, id : 70, nolog, pass, setsid : % {REQUEST_COOKIES.PHPSESSID}"

# 공격시 세션 점수 증가 
Securule REQUEST_URI "^ / cgi-bin / finger $" "단계 : 2, id : 71, t : 없음, t : 소문자, t : normalizePath, pass, setvar : SESSION.score = + 10" 

# 세션에서 너무 많은 공격 탐지
SecRule 세션 : 점수 "@gt 50" "phase : 2, id : 72, pass, setvar : SESSION.blocked = 1"

# 세션 차단 적용 
SecRule 세션 : "@eq 1"차단 "단계 : 2, id : 73, 거부, 상태 : 403"

세션 ID

이 변수는 setsid로 설정된 값을 포함합니다. 전체 예제는 SESSION (위)을 참조하십시오.

STATUS_LINE

이 변수는 서버가 보낸 전체 상태 줄 (요청 방법 및 HTTP 버전 정보 포함)을 포함합니다.

# 응용 프로그램이 500 개의 오류를 생성 할 때 경고를 생성합니다.
SecRule STATUS_LINE "@contains 500" "단계 : 3, id : 49, log, pass, logdata : '응용 프로그램 오류가 발생했습니다!, t : 없음'

버전 : 2.x

libModSecurity : TBI 에서 지원됨

STREAM_INPUT_BODY

버전 : 2.6.0-2.9.x

libModSecurity에서 지원됨 : 아니오

이 변수는 원시 요청 본문 내용에 대한 액세스 권한을 부여합니다. 이 변수는 두 가지 유스 케이스에 가장 잘 사용됩니다.

1. 빠른 패턴 매칭 - @ pm / @ pmf를 사용하여 모든 종류의 컨텐츠 유형 데이터에 대해 큰 텍스트 문자열을 사전 인증합니다. 이것은 Phase : 2 변수 모집단에서 ModSecurity 구문 분석을 수행하기 전에 REQUEST_BODY / ARGS_POST / ARGS_POST_NAMES를 사용하는 것보다 훨씬 더 효과적입니다.
2. 데이터 대체의 경우 -이 변수에 대해 @rsub를 사용하면 라이브 요청 본문 데이터를 조작 할 수 있습니다. 예 - 문제가되는 페이로드를 제거하거나 양호한 데이터를 대체합니다.

참고 : SecStreamInBodyInspection 지시문을 활성화해야합니다

참고 :이 지시문은 libModSecurity (v3)에서 지원되지 않습니다.

STREAM_OUTPUT_BODY

이 변수는 원시 응답 본문 내용에 대한 액세스 권한을 부여합니다. 이 변수는 대소 문자에 가장 잘 사용됩니다.

1. 데이터 대체의 경우 -이 변수에 대해 @rsub를 사용하면 라이브 요청 본문 데이터를 조작 할 수 있습니다. 예 - 문제가되는 페이로드를 제거하거나 양호한 데이터를 대체합니다.

버전 : 2.6.0-2.9.x

libModSecurity에서 지원됨 : TBD

참고 : SecStreamOutBodyInspection 지시문을 활성화해야합니다

시각

이 변수는 시간 (시 : 분 : 초)을 나타내는 형식화 된 문자열을 보유합니다.

SecRule TIME "^(([1](8|9))|([2](0|1|2|3))):\d{2}:\d{2}$" "id:74"

TIME_DAY

이 변수는 현재 날짜 (1-31)를 유지합니다. 다음 규칙은 한 달에 열 번째와 열 번째 사이에 언제든지 발생하는 거래를 트리거합니다.

SecRule TIME_DAY "^(([1](0|1|2|3|4|5|6|7|8|9))|20)$" "id:75"

TIME_EPOCH

이 변수는 1970 년 이래로 시간을 초 단위로 유지합니다.

TIME_HOUR

이 변수는 현재 시간 값 (0-23)을 유지합니다. 다음 규칙은 요청이 "근무 시간 외"일 때 트리거됩니다.

SecRule TIME_HOUR "^(0|1|2|3|4|5|6|[1](8|9)|[2](0|1|2|3))$" "id:76"

TIME_MIN

이 변수는 현재 분 값 (0-59)을 유지합니다. 다음 규칙은 매 시간의 마지막 30 분 동안 트리거합니다.

SecRule TIME_MIN "^(3|4|5)" "id:77"

TIME_MON

이 변수는 현재 월 값 (0-11)을 유지합니다. 다음 규칙은 월이 11 월 (값 10) 또는 12 월 (값 11) 인 경우 일치합니다.

SecRule TIME_MON "^1" "id:78"

TIME_SEC

이 변수는 현재의 두 번째 값 (0-59)을 유지합니다.

SecRule TIME_SEC "@gt 30" "id:79"

TIME_WDAY

이 변수는 현재 평일 값 (0-6)을 유지합니다. 다음 규칙은 토요일과 일요일에만 실행됩니다.

SecRule TIME_WDAY "^(0|6)$" "id:80"

TIME_YEAR

이 변수는 현재 4 자리 연도 값을 보유합니다.

SecRule TIME_YEAR "^2006$" "id:81"

TX

이것은 데이터 조각을 저장하고 트랜잭션 이상 점을 만드는 데 사용되는 임시 트랜잭션 컬렉션입니다. 이 콜렉션에 배치 된 변수는 트랜잭션이 완료 될 때까지만 사용 가능합니다.

# 공격시 트랜잭션 공격 점수 증가 
SecRule ARGS 공격 "단계 : 2, id : 82, nolog, pass, setvar : TX.score = + 5"

# 점수가 너무 높은 거래를 차단하십시오 
SecRule TX : SCORE "@gt 20" "phase : 2, id : 83, log, deny"

TX 컬렉션의 일부 변수 이름은 예약되어 있으므로 사용할 수 없습니다.

• TX : 0 : 캡처 작업과 함께 @rx 또는 @pm 연산자를 사용할 때의 일치 값
• TX : 1-TX : 9 : 괄호 캡쳐와 함께 @rx 연산자를 사용할 때 캡쳐 된 서브 표현식 값과 캡쳐 동작
• TX : MSC _. * : ModSecurity 처리 플래그
• MSC_PCRE_LIMITS_EXCEEDED : PCRE 일치 제한을 초과하면 0이 아닌 값으로 설정하십시오. 자세한 내용은 SecPcreMatchLimit 및 SecPcreMatchLimitRecursion을 참조하십시오.

UNIQUE_ID

이 변수는 mod_unique_id http://httpd.apache.org/docs/2.2/mod/mod_unique_id.html에 의해 생성 된 데이터를 저장 합니다. 이 모듈은 매우 특정한 조건에서 "모든"요청에 대해 고유 한 것으로 보장되는 각 요청에 대한 마법 토큰을 제공합니다. 고유 식별자는 올바르게 구성된 시스템 클러스터의 여러 시스템에서 고유합니다. 환경 변수 UNIQUE_ID는 각 요청의 식별자로 설정됩니다. UNIQUE_ID 환경 변수는 알파벳 [A-Za-z0-9 @]를 사용하여 112 비트 (32 비트 IP 주소, 32 비트 PID, 32 비트 타임 스탬프, 16 비트 카운터) 4 배 인코딩 방식으로 구성됩니다 MIME base64 인코딩과 유사하게 19자를 생성합니다.

URLENCODED_ERROR

이 변수는 쿼리 문자열을 파싱하는 동안 (모든 요청시) 또는 응용 프로그램 / x-www-form-urlencoded 요청 본문을 구문 분석하는 동안 잘못된 URL 인코딩이 발생하면 생성됩니다 (URLENCODED 요청을 사용하는 요청에만 해당) 바디 프로세서).

USERID

이 변수는 setuid로 설정된 값을 포함합니다.

# 사용자 추적 초기화
SecAction "nolog, id : 84, pass, setuid : % {REMOTE_USER}" 

# 현재 사용자가 관리자입니까?
SecRule 사용자 ID "admin" "id : 85"

USERAGENT_IP

이 변수는 modsecurity를 ​​apache2.4와 함께 실행할 때 생성되며 프록시 연결에서 mod_remoteip에 의해 설정된 클라이언트 IP 주소를 포함합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

WEBAPPID

이 변수는 현재 응용 프로그램 이름을 포함하며 SecWebAppId를 사용하여 구성에서 설정됩니다.

버전 : 2.0.0-2.9.x

libModSecurity : TBI 에서 지원됨

WEBSERVER_ERROR_LOG

버전 : 2.x

libModSecurity : TBI 에서 지원됨

웹 서버에서 생성 된 0 개 이상의 오류 메시지가 들어 있습니다. 이 변수는 5 단계 (로깅)에서 가장 잘 액세스됩니다.

SecRule WEBSERVER_ERROR_LOG "File does not exist" "phase:5,id:86,t:none,nolog,pass,setvar:TX.score=+5"

XML

XML 파서와 상호 작용하는 데 사용되는 특수 컬렉션. validateDTD 및 validateSchema 연산자의 대상으로 독립 실행 형으로 사용할 수 있습니다. 그렇지 않으면 유효한 XPath 표현식을 포함해야하며, 이전에 파싱 된 XML DOM 트리에 대해 평가됩니다.

SecDefaultAction 로그, 거부, 상태 : 403, 단계 : 2, ID : 90
SecRule REQUEST_HEADERS : Content-Type ^ text / xml $ "단계 : 1, id : 87, t : 소문자, nolog, 패스, ctl : requestBodyProcessor = XML"
SecRule REQBODY_PROCESSOR "! ^ XML $"skipAfter : 12345, id : 88

SecRule XML : / employees / employee / name / text () Fred "id : 89"
SecRule XML : / xq : employees / employee / name / text () Fred "id : 12345, xmlns : xq = http : //www.example.com/employees"

첫 번째 XPath 표현식은 네임 스페이스를 사용하지 않습니다. 다음과 같은 페이로드와 일치합니다.

<직원>
    <직원>
        <name> 프레드 존스 (Fred Jones) </ name>
        <address location = "home">
            <street> 900 Aurora Ave. </ street>
            <city> 시애틀 </ city>
            <상태> WA </ 상태>
            <zip> 98115 </ zip>
        </ address>
        <address location = "work">
            <street> 2011 152 번가 NE </ street>
            <city> 레드 몬드 </ city>
            <상태> WA </ 상태>
            <zip> 98052 </ zip>
        </ address>
        <phone location = "work"> (425) 555-5665 </ phone>
        <phone location = "home"> (206) 555-5555 </ phone>
        <phone location = "mobile"> (206) 555-4321 </ phone>
    </ employee>
</ employees>

두 번째 XPath 표현식은 네임 스페이스를 사용합니다. 다음 페이로드와 일치합니다.

<xq : employees xmlns : xq = "http://www.example.com/employees">
    <직원>
        <name> 프레드 존스 (Fred Jones) </ name>
        <address location = "home">
            <street> 900 Aurora Ave. </ street>
            <city> 시애틀 </ city>
            <상태> WA </ 상태>
            <zip> 98115 </ zip>
        </ address>
        <address location = "work">
            <street> 2011 152 번가 NE </ street>
            <city> 레드 몬드 </ city>
            <상태> WA </ 상태>
            <zip> 98052 </ zip>
        </ address>
        <phone location = "work"> (425) 555-5665 </ phone>
        <phone location = "home"> (206) 555-5555 </ phone>
        <phone location = "mobile"> (206) 555-4321 </ phone>
    </ employee>
</ xq : 직원>

두 번째 예제에서 사용 된 다른 네임 스페이스에 주목하십시오.

변환 함수

변환 함수는 입력 데이터가 일치 (예 : 연산자 실행)에 사용되기 전에 변경하는 데 사용됩니다. 입력 데이터는 결코 수정되지 않습니다. 사실, 변환 기능을 사용할 것을 요청할 때마다, ModSecurity는 데이터 사본을 생성하고 변환 한 다음 결과에 대해 연산자를 실행합니다.

참고 : ModSecurity (1.x)의 첫 번째 세대에는 기본 변환 함수가 없습니다.

다음 예에서 요청 매개 변수 값은 일치하기 전에 소문자로 변환됩니다.

SecRule ARGS "xp_cmdshell" "t:lowercase,id:91"

동일한 규칙에서 여러 변형 동작을 사용하여 변형 파이프 라인을 만들 수 있습니다. 변환은 규칙에 나타나는 순서대로 수행됩니다.

대부분의 경우, 변환이 수행되는 순서가 매우 중요합니다. 다음 예제에서는 일련의 변환 함수가 회피를 위해 수행됩니다. 다른 순서로 변환을 수행하면 숙련 된 공격자가 탐지를 피할 수 있습니다.

SecRule ARGS "(asfunction|javascript|vbscript|data|mocha|livescript):" "id:92,t:none,t:htmlEntityDecode,t:lowercase,t:removeNulls,t:removeWhitespace"

경고 : 현재 SecDefaultAction을 사용하여 변환 함수의 기본 목록을 지정할 수 있습니다.이 목록은 SecDefaultAction 지시문을 따르는 모든 규칙에 적용됩니다. 그러나이 방법은 실수를 매우 쉽게하기 때문에 권장하지 않습니다. 특정 규칙에 필요한 변환 함수를 항상 지정하고 t : none (상속 된 변환 함수를 지울 수 있음)으로 목록을 시작하는 것이 좋습니다.

이 섹션의 나머지 부분에서는 현재 ModSecurity에서 사용할 수있는 변환 함수에 대해 설명합니다.

base64Decode

Base64로 인코딩 된 문자열을 디코딩합니다.

SecRule REQUEST_HEADERS : 권한 "^ 기본 ([a-zA-Z0-9] + = *) $" "단계 : 1, ID : 93, 캡처, 체인, 로그 데이터 : % {TX.1}"
  SecRule TX : 1 ^ (\ w +) : t : base64Decode, 캡처, 체인
    SecRule TX : 1 ^ (admin | root | backup) $ 

주 : base64Decode를 다른 변환과 함께 적용 할 때는주의하십시오. 어떤 변형은 디코딩되기 전에 base64로 인코딩 된 문자열을 변경하거나 무효화 할 수 있으므로 변환 순서가 중요합니다 (예 : t : 소문자 등). 이것은 물론 base64decoded 값을 확인하는 단일 규칙을 작성하거나 인코딩되지 않은 값을 변환과 함께 작성하는 것은 매우 어렵다는 것을 의미합니다.이 상황에서 두 가지 규칙을 작성하는 것이 가장 좋습니다.

sqlHexDecode

SQL 16 진수 데이터를 디코드합니다. 예 (0x414243)는 (ABC)로 디코딩됩니다. 2.6.3부터 사용 가능

base64DecodeExt

Base64로 인코딩 된 문자열을 디코딩합니다. base64Decode와는 달리,이 버전은 용서되는 구현을 사용합니다.이 구현은 유효하지 않은 문자를 무시합니다. 2.5.13부터 사용 가능합니다.

PHP 사이트에서 Base64Decoding 회피 문제에 관한 블로그 게시물보기 - http://blog.spiderlabs.com/2010/04/impedance-mismatch-and-base64.html

base64Encode

Base64 인코딩을 사용하여 입력 문자열을 인코딩합니다.

cmdLine

참고 : 이것은 Marc Stern이 개발 한 커뮤니티 기여입니다. http://www.linkedin.com/in/marcstern

Windows 및 Unix에서 명령은 다음과 같은 다른 방법으로 이스케이프 처리 될 수 있습니다.

• c ^ ommand / c ...
• "명령"/ c ...
• 명령, / c ...
• 유닉스 명령의 중간에 백 슬래시

cmdLine 변환 함수는 다음과 같은 방법으로 변수 contend를 조작하여이 문제를 방지합니다.

• 모든 백 슬래시 삭제 [\]
• 모든 큰 따옴표 삭제 [ "]
• 모든 sigle 따옴표 삭제 [ ']
• 모든 캐럿 삭제 [^]
• 슬래시 /
• 열려있는 부모 제거 ([]) 전에 공백을 삭제합니다.
• 모든 쉼표 [,] 및 세미콜론 [;]을 공백으로 바꾸십시오.
• 여러 개의 공백 (탭, 줄 바꿈 등 포함)을 하나의 공백으로 바꾸기
• 모든 문자를 소문자로 변환

사용 예 :

phase : 2, id : 94, t : none, ": SecRule ARGS"(? : command (? :. com) t : cmdLine "

compressWhitespace

공백 문자 (0x20, \ f, \ t, \ n, \ r, \ v, 0xa0)를 공백 (ASCII 0x20)으로 변환하여 여러 개의 연속 된 공백 문자를 하나로 압축합니다.

cssDecode

CSS 2.x 이스케이프 규칙 syndata.html # 문자를 사용하여 인코딩 된 문자를 디코딩합니다 . 이 함수는 디코딩 프로세스에서 최대 2 바이트 만 사용합니다. 즉, CSS 인코딩 (일반적으로 인코딩되지 않음)을 사용하여 인코딩 된 ASCII 문자를 찾아내는 데 유용하거나 역 슬래시와 비표준의 조합 인 회피에 유용합니다 16 진수 문자 (예 : ja \ vascript는 javascript와 같습니다).

escapeSeqDecode

\ n, \ r, \ t, \ v, \\, \, \ ', \ ", \ xHH (16 진수), \ 0OOO (8 진수) 유효하지 않은 인코딩이 출력에 남습니다.

16 진수 코드

hexEncode에서 사용 된 알고리즘과 동일한 알고리즘을 사용하여 인코딩 된 문자열을 디코딩합니다 (다음 항목 참조).

hexEncode

각 입력 바이트를 두 개의 16 진수로 바꾸어 문자열 (2 진 문자 포함 가능)을 인코딩합니다. 예를 들어 xyz는 78797a로 인코딩됩니다.

htmlEntityDecode

HTML 엔터티로 인코딩 된 문자를 디코딩합니다. 다음 변형이 지원됩니다.

• HH 및 HH; (H는 임의의 16 진수)
• DDD 및 DDD; (여기서 D는 십진수)
• & quot;
• & nbsp 그리고 
• & lt;
• & gt>

이 함수는 항상 하나의 HTML 엔터티를 하나의 바이트로 변환하므로 정보가 손실 될 수 있습니다 (엔터티가 단일 바이트로 표시 할 수없는 문자를 참조하는 경우). 따라서 인코딩 할 필요가없는 바이트를 밝히는 것이 유용하지만 0xff 이상의 범위의 문자로는 의미있는 작업을 수행 할 수 없습니다.

jsDecode

JavaScript 이스케이프 시퀀스를 디코딩합니다. \ uHHHH 코드가 FF01-FF5E (전각 ASCII 코드)의 범위에있는 경우, 상위 바이트는 하위 바이트를 감지하고 조정하는 데 사용됩니다. 그렇지 않으면 하위 바이트 만 사용되며 상위 바이트는 0으로 설정됩니다 (정보가 손실 될 수 있음).

길이

입력 문자열의 길이를 바이트 단위로 조회하여 문자열로 출력 형식으로 배치합니다. 예를 들어 입력시 ABCDE를 얻으면이 변환 함수는 출력시 5를 반환합니다.

소문자

현재 C 로케일을 사용하여 모든 문자를 소문자로 변환합니다.

md5

입력 된 데이터에서 MD5 해시를 계산합니다. 계산 된 해시는 원시 이진 형식이므로 인쇄 (또는 기록)하기 위해 텍스트로 인코딩해야 할 수 있습니다. 해시 함수는 일반적으로 hexEncode와 함께 사용됩니다 (예 : t : md5, t : hexEncode).

없음

실제 변환 함수가 아니라 현재 규칙과 관련된 모든 변환 함수를 제거하기위한 ModSecurity에 대한 지침입니다.

정규 경로

normalizePath를 참조하십시오.

정규화 경로

입력 문자열에서 여러 슬래시, 디렉토리 자체 참조 및 디렉토리 역 참조 (입력의 시작 부분을 제외하고)를 제거합니다.

참고 : 2010 년 현재 normalisePath의 이름이 normalizePath (MODSEC-103)로 변경되었습니다. NormalisePath는 현재 버전에서 하위 호환성을 유지하지만 사용하면 안됩니다.

normalisePathWin

normalizePathWin을 참조하십시오.

normalizePathWin

normalizePath와 같지만 먼저 백 슬래시 문자를 슬래시로 변환합니다.

참고 : 2010 년부터 normalisePathWin이 normalizePathWin (MODSEC-103)으로 이름이 변경되었습니다. NormalisePathWin은 현재 버전에서 하위 호환성을 유지하지만 사용하면 안됩니다.

parityEven7bit

각 대상 바이트의 8 번째 비트를 계산 된 패리티 비트로 바꾸는 7 비트 데이터의 짝수 패리티를 계산합니다.

패리티 Odd7bit

각 대상 바이트의 8 번째 비트를 계산 된 패리티 비트로 바꾸는 7 비트 데이터의 홀수 패리티를 계산합니다.

패리티 Zero7bit

각 대상 바이트의 8 번째 비트를 0 패리티 비트로 바꾸는 7 비트 데이터의 영 (0) 패리티를 계산하여 짝수 / 홀수 패리티 7 비트 데이터를 ASCII7 데이터로 검사 할 수 있습니다.

removeNulls

모든 NUL 바이트를 입력에서 제거합니다.

removeWhitespace

모든 공백 문자를 입력에서 제거합니다.

replaceComments

C 스타일 주석 (/ * ... * /)의 각 항목을 하나의 공백 (여러 번 연속 된 항목은 압축되지 않음)으로 바꿉니다. 끝나지 않은 주석은 공백 (ASCII 0x20)으로 대체됩니다. 그러나 주석 (* /)의 독립형 종료는 적용되지 않습니다.

removeCommentsChar

일반 주석 문자 (/ *, * /, -, #)를 제거합니다.

removeComments

버전 : 2.x-3.x (사전)

libModSecurity에서 지원됨 : 예

주석의 각 항목을 제거합니다 (/ * ... * /, -, #). 여러 번 연속으로 나타나는 항목은 압축되지 않습니다.

참고 : 이 변환은 신뢰할 수 없다고 알려져 있으며, 예기치 않은 동작이 발생할 수 있으며 향후 릴리스에서 곧 중단 될 수 있습니다. 자세한 내용은 문제 # 1207 을 참조하십시오 . .

replaceNulls

입력 된 NUL 바이트를 공백 문자 (ASCII 0x20)로 바꿉니다.

urlDecode

URL로 인코딩 된 입력 문자열을 디코딩합니다. 유효하지 않은 인코딩 (즉, 16 진수가 아닌 문자 또는 문자열 끝에 있고 하나 또는 두 개의 문자가없는 문자)은 변환되지 않지만 오류는 발생하지 않습니다. 유효하지 않은 인코딩을 찾으려면 먼저 입력 데이터에서 @validateUrlEncoding 연산자를 사용하십시오. 두 번 URL 디코딩을 수행하려는 의도가 아니라면 이미 URL 디코딩 된 변수 (예 : 요청 매개 변수)에 대해 변환 함수를 사용하면 안됩니다.

대문자

현재 C 로케일을 사용하여 모든 문자를 대문자로 변환합니다.

버전 : 3.0 (pre)

libModSecurity에서 지원됨 : 예

urlDecodeUni

Like urlDecode, but with support for the Microsoft-specific %u encoding. If the code is in the range of FF01-FF5E (the full-width ASCII codes), then the higher byte is used to detect and adjust the lower byte. Otherwise, only the lower byte will be used and the higher byte zeroed.

urlEncode

Encodes input string using URL encoding.

utf8toUnicode

Converts all UTF-8 characters sequences to Unicode. This help input normalization specially for non-english languages minimizing false-positives and false-negatives. (available with 2.7.0)

sha1

Calculates a SHA1 hash from the input string. The computed hash is in a raw binary form and may need encoded into text to be printed (or logged). Hash functions are commonly used in combination with hexEncode (for example, t:sha1,t:hexEncode).

trimLeft

Removes whitespace from the left side of the input string.

trimRight

Removes whitespace from the right side of the input string.

trim

Removes whitespace from both the left and right sides of the input string.

Actions

Each action belongs to one of five groups:

• Disruptive actions - Cause ModSecurity to do something. In many cases something means block transaction, but not in all. For example, the allow action is classified as a disruptive action, but it does the opposite of blocking. There can only be one disruptive action per rule (if there are multiple disruptive actions present, or inherited, only the last one will take effect), or rule chain (in a chain, a disruptive action can only appear in the first rule).

Note : Disruptive actions will NOT be executed if the SecRuleEngine is set to DetectionOnly. If you are creating exception/whitelisting rules that use the allow action, you should also add the ctl:ruleEngine=On action to execute the action.

• Non-disruptive actions - Do something, but that something does not and cannot affect the rule processing flow. Setting a variable, or changing its value is an example of a non-disruptive action. Non-disruptive action can appear in any rule, including each rule belonging to a chain.
• Flow actions - These actions affect the rule flow (for example skip or skipAfter).
• Meta-data actions - Meta-data actions are used to provide more information about rules. Examples include id, rev, severity and msg.
• Data actions - Not really actions, these are mere containers that hold data used by other actions. For example, the status action holds the status that will be used for blocking (if it takes place).

accuracy

Description: Specifies the relative accuracy level of the rule related to false positives/negatives. The value is a string based on a numeric scale (1-9 where 9 is very strong and 1 has many false positives).

Action Group: Meta-data

Version: 2.7

Example:

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bgetparentfolder\b" \
	"phase:2,ver:'CRS/2.2.4,accuracy:'9',maturity:'9',capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,msg:'Cross-site Scripting (XSS) Attack',id:'958016',tag:'WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'% \
{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

allow

Description: Stops rule processing on a successful match and allows the transaction to proceed.

Action Group: Disruptive

Example:

# Allow unrestricted access from 192.168.1.100 
SecRule REMOTE_ADDR "^192\.168\.1\.100$" phase:1,id:95,nolog,allow

Prior to ModSecurity 2.5 the allow action would only affect the current phase. An allow in phase 1 would skip processing the remaining rules in phase 1 but the rules from phase 2 would execute. Starting with v2.5.0 allow was enhanced to allow for fine-grained control of what is done. The following rules now apply:

1. If used one its own, like in the example above, allow will affect the entire transaction, stopping processing of the current phase but also skipping over all other phases apart from the logging phase. (The logging phase is special; it is designed to always execute.)
2. If used with parameter "phase", allow will cause the engine to stop processing the current phase. Other phases will continue as normal.
3. If used with parameter "request", allow will cause the engine to stop processing the current phase. The next phase to be processed will be phase RESPONSE_HEADERS.

Examples:

# Do not process request but process response.
SecAction phase:1,allow:request,id:96

# Do not process transaction (request and response).
SecAction phase:1,allow,id:97

If you want to allow a response through, put a rule in phase RESPONSE_HEADERS and simply use allow on its own:

# Allow response through.
SecAction phase:3,allow,id:98

append

Description: Appends text given as parameter to the end of response body. Content injection must be en- abled (using the SecContentInjection directive). No content type checks are made, which means that before using any of the content injection actions, you must check whether the content type of the response is adequate for injection.

Version: 2.x-2.9.x

Supported on libModSecurity: No

Action Group: Non-disruptive

Processing Phases: 3 and 4.

Example:

SecRule RESPONSE_CONTENT_TYPE "^text/html" "nolog,id:99,pass,append:'<hr>Footer'"

Warning : Although macro expansion is allowed in the additional content, you are strongly cau- tioned against inserting user-defined data fields into output. Doing so would create a cross-site scripting vulnerability.

auditlog

Description: Marks the transaction for logging in the audit log.

Action Group: Non-disruptive

Example:

SecRule REMOTE_ADDR "^192\.168\.1\.100$" auditlog,phase:1,id:100,allow

Note : The auditlog action is now explicit if log is already specified.

block

Description: Performs the disruptive action defined by the previous SecDefaultAction.

Action Group: Disruptive

이 작업은 본질적으로 규칙 작성자가 차단 작업을 요청하기 위해 사용되지만 차단이 수행되는 방법을 지정하지 않고 사용하기위한 것입니다. 그와 같은 결정은 사용자가 원하는 경우 차단을 무시할 수있을뿐만 아니라 사용자를 제어하는 ​​것이 가장 바람직합니다. ModSecurity의 차후 버전에서는 더 많은 제어 및 기능이 추가되어 "방법"이 차단됩니다.

예 :

# 차단이 수행되는 방법 지정 
SecDefaultAction 단계 : 2, 거부, id : 101, 상태 : 403, 로그, 감사 로그

# 차단하려는 공격을 탐지합니다. 
SecRule ARGS 공격 1 단계 : 2, 블록, ID : 102

# 우리가 경고하기를 원하는 곳의 공격 탐지 
SecRule ARGS 공격 2 단계 : 2, 통과, id : 103

SecRuleUpdateActionById 지정 문을 사용하여 규칙에서 차단을 처리하는 방법을 무시할 수 있습니다. 이것은 다음 세 가지 경우에 유용합니다.

1. 규칙이 하드 코딩 된 것을 차단하고 결정한 정책을 사용하려는 경우
2. 규칙이 차단하도록 작성되었지만 경고 만 표시하도록하려는 경우
3. 규칙이 경고 만하도록 작성되었지만 차단을 원할 경우

다음 예제는 하드 코딩 된 블록이 사용자가 제어 할 수있는 블록을 위해 제거 된 첫 번째 경우를 보여줍니다.

# 차단이 수행되는 방법 지정 
SecDefaultAction 단계 : 2, 거부, 상태 : 403, 로그, 감사 로그, id : 104

# 공격 감지 및 차단 
SecRule ARGS 공격 1 단계 : 2, id : 1, 거부

# 규칙 ID 1 차단 방법 변경 
SecRuleUpdateActionById 1 블록

포착

설명 : 정규식 연산자 (@rx)와 함께 사용하면 캡처 작업에서 정규식 캡처의 복사본을 만들어 트랜잭션 변수 컬렉션에 저장합니다.

액션 그룹 : 무중단

예:

SecRule REQUEST_BODY "^ 사용자 이름 = (\ w {25,})"단계 : 2, 캡처, t : 없음, 체인, id : 105
  SecRule TX : 1 "(? :( ?: a (dmin | nonymous)))"

0에서 9까지의 숫자로 구성된 이름을 가진 성공적인 패턴 일치에서 최대 10 개의 캡처가 복사됩니다. TX.0 변수는 항상 정규식이 일치하는 전체 영역을 포함합니다. 다른 모든 변수에는 캡쳐 된 값이 캡처 괄호가 정규 표현식에 나타나는 순서대로 포함됩니다.

체인

설명 : 바로 뒤에 오는 규칙으로 현재 규칙을 연결하여 규칙 체인을 만듭니다. 연결 규칙은보다 복잡한 처리 논리를 허용합니다.

액션 그룹 : 흐름

예:

# Content-Length 헤더를 포함하지 않는 POST 요청을 허용하지 않습니다. 
# (이 규칙 앞에는 규칙이 있어야 함을 유의하십시오 
유효한 요청 방법 만 사용되는지 확인하는 #이 사용됩니다.) 
SecRule REQUEST_METHOD "^ POST $"단계 : 1, 체인, t : 없음, id : 105
  SecRule & REQUEST_HEADERS : 내용 길이 "@eq 0"t : 없음

참고 : 규칙 체인을 사용하면 논리적 AND를 시뮬레이션 할 수 있습니다. 모든 변수 검사가 양수 히트를 반환하는 경우에만 체인화 된 규칙의 첫 번째 부분에 지정된 파괴적인 작업이 트리거됩니다. 체인 규칙 중 하나의 측면이 음수이면 전체 규칙 체인이 일치하지 않습니다. 또한 파괴적인 동작, 실행 단계, 메타 데이터 동작 (id, rev, msg, tag, severity, logdata), skip 및 skipAfter 작업은 chain starter 규칙에 의해서만 지정 될 수 있습니다.

다음 지시문을 규칙 체인에 사용할 수 있습니다.

• SecAction
• SecRule
• SecRuleScript

특수 규칙은 연결 규칙에서 작업 사용을 제어합니다.

• Any actions that affect the rule flow (i.e., the disruptive actions, skip and skipAfter) can be used only in the chain starter. They will be executed only if the entire chain matches.
• Non-disruptive rules can be used in any rule; they will be executed if the rule that contains them matches and not only when the entire chain matches.
• The metadata actions (e.g., id, rev, msg) can be used only in the chain starter.

ctl

Description: Changes ModSecurity configuration on transient, per-transaction basis. Any changes made using this action will affect only the transaction in which the action is executed. The default configuration, as well as the other transactions running in parallel, will be unaffected.

Action Group: Non-disruptive

Example:

# Parse requests with Content-Type "text/xml" as XML 
SecRule REQUEST_CONTENT_TYPE ^text/xml "nolog,pass,id:106,ctl:requestBodyProcessor=XML"

# white-list the user parameter for rule #981260 when the REQUEST_URI is /index.php
SecRule REQUEST_URI "@beginsWith /index.php" "phase:1,t:none,pass, \
  nolog,ctl:ruleRemoveTargetById=981260;ARGS:user

The following configuration options are supported:

1. auditEngine (Supported on libModSecurity: TBI)
2. auditLogParts
3. debugLogLevel (Supported on libModSecurity: TBI)
4. forceRequestBodyVariable (Supported on libModSecurity: TBI)
5. requestBodyAccess
6. requestBodyLimit (Supported on libModSecurity: TBI)
7. requestBodyProcessor
8. responseBodyAccess (Supported on libModSecurity: TBI)
9. responseBodyLimit (Supported on libModSecurity: TBI)
10. ruleEngine (Supported on libModSecurity: YES)
11. ruleRemoveById - since this action us triggered at run time, it should be specified before the rule in which it is disabling.
12. ruleRemoveByMsg (Supported on libModSecurity: TBI)
13. ruleRemoveByTag (Supported on libModSecurity: TBI)
14. ruleRemoveTargetById - since this action is used to just remove targets, users don't need to use the char ! before the target list.
15. ruleRemoveTargetByMsg - since this action is used to just remove targets, users don't need to use the char ! before the target list. (Supported on libModSecurity: TBI)
16. ruleRemoveTargetByTag - since this action is used to just remove targets, users don't need to use the char ! before the target list.
17. hashEngine (Supported on libModSecurity: TBI)
18. hashEnforcement (Supported on libModSecurity: TBI)

With the exception of the requestBodyProcessor and forceRequestBodyVariable settings, each configuration option corresponds to one configuration directive and the usage is identical.

The requestBodyProcessor option allows you to configure the request body processor. By default, ModSecurity will use the URLENCODED and MULTIPART processors to process an application/x-www-form-urlencoded and a multipart/form-data body, respectively. Other two processors are also supported: JSON and XML, but they are never used implicitly. Instead, you must tell ModSecurity to use it by placing a few rules in the REQUEST_HEADERS processing phase. After the request body is processed as XML, you will be able to use the XML-related features to inspect it.

Request body processors will not interrupt a transaction if an error occurs during parsing. Instead, they will set the variables REQBODY_PROCESSOR_ERROR and REQBODY_PROCESSOR_ERROR_MSG. These variables should be inspected in the REQUEST_BODY phase and an appropriate action taken. The forceRequestBodyVariable option allows you to configure the REQUEST_BODY variable to be set when there is no request body processor configured. This allows for inspection of request bodies of unknown types.

Note : There was a ctl:ruleUpdateTargetById introduced in 2.6.0 and removed from the code in 2.7.0. JSON was added as part of v2.8.0-rc1

deny

Description: Stops rule processing and intercepts transaction.

Action Group: Disruptive

Example: SecRule REQUEST_HEADERS:User-Agent "nikto" "log,deny,id:107,msg:'Nikto Scanners Identified'"

deprecatevar

설명 : 영구 저장 장치에 저장된 변수에만 적용되는 의미있는 시간 경과에 따른 숫자 값의 감소.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 무중단

예 : 다음 예는 매 300 초마다 카운터를 감소시킵니다.

SecAction 단계 : 5, id : 108, nolog, pass, deprecatevar : SESSION.score = 60 / 300

카운터 값은 항상 양수이므로 값이 절대로 0 이하가되지 않습니다. expirevar와 달리, deprecate 조치는 모든 요청에서 실행되어야합니다.

하락

설명 : FIN 패킷을 보내 TCP 연결을 즉시 종료합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 파괴적인

예 : 다음 예는 기본 인증 시도를 추적하기 위해 IP 콜렉션을 시작합니다. 클라이언트가 2 분 내에 25 회를 초과하는 임계 값을 초과하면 후속 연결을 삭제합니다.

SecAction 단계 : 1, id : 109, initcol : ip = % {REMOTE_ADDR}, nolog
SecRule ARGS : 로그인 "! ^ $" "nolog, 단계 : 1, id : 110, setvar : ip.auth_attempt = +1, deprecatevar : ip.auth_attempt = 25 / 120"
SecRule IP : AUTH_ATTEMPT "@gt 25" "로그, 드롭, 단계 : 1, id : 111, msg : '가능한 총 공격"

참고 :이 작업은 현재 Windows 기반 빌드에서는 사용할 수 없습니다.

두 경우 모두, 네트워크 대역폭과 클라이언트에 반환되는 데이터 양을 최소화하려면, 무력하고 있다는 점에서 서비스 거부 공격 모두에 응답 할 때이 작업은 매우 유용합니다. 이 작업을 수행하면 로그에 오류 메시지가 나타납니다. "(9) 잘못된 파일 설명자 : core_output_filter : 네트워크에 데이터 쓰기"

임원

설명 : 매개 변수로 제공된 외부 스크립트 / 바이너리를 실행합니다. 간부 인에 공급되는 파라미터합니다 (.lua 확장에 의해 검출) 루아 스크립트인지 v2.5.0로, 스크립트는 내부적으로 처리된다. 즉, 스크립트에서 내부 요청 컨텍스트에 직접 액세스 할 수 있습니다. Lua 스크립트를 작성하는 방법에 대한 자세한 내용은 SecRuleScript 설명서를 참조하십시오.

액션 그룹 : 무중단

버전 : 2.x

libModSecurity : TBI 에서 지원됨

예:

# 규칙 매치에서 외부 프로그램 실행 
Securule REQUEST_URI "^ / cgi-bin / script \ .pl" "단계 : 2, ID : 112, t : 없음, t : 소문자, t : normalizePath, 블록, \ exec : / usr / local / apache / bin / test .sh "

# 규칙 매치에서 루아 스크립트를 실행합니다. 
SecRule ARGS : p 공격 "단계 : 2, id : 113, 블록, exec : /usr/local/apache/conf/exec.lua"

exec 작업은 지정된 모든 파괴 작업과 독립적으로 실행됩니다. 외부 스크립트는 매개 변수없이 항상 호출됩니다. 일부 거래 정보는 환경 변수에 저장됩니다. 모든 일반적인 CGI 환경 변수가있을 것입니다. 스레드 프로세스를 포크하면 모든 스레드가 새 프로세스에서 복제됩니다. 따라서 포킹은 다중 스레드 배포에서 큰 오버 헤드를 초래할 수 있습니다. 스크립트는 stdout에 무언가를 써야합니다. 그렇지 않으면 ModSecurity는 스크립트가 실패했다고 가정하고 실패를 기록합니다.

expirevar

설명 : 지정된 기간 (초) 후에 만료되도록 콜렉션 변수를 구성합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 무중단

예:

SecRule REQUEST_COOKIES : JSESSIONID "! ^ $" "nolog, 단계 : 1, ID : 114, 통과, setsid : % {요청한 쿠키 : JSESSIONID}"
Securule REQUEST_URI "^ / cgi-bin / script \ .pl" "단계 : 2, id : 115, t : 없음, t : 소문자, t : normalizePath, log, allow, setvar : session.suspicious = 1, expirevar : session .suspicious = 3600, 단계 : 1 "

의도 한 만기 시간을 유지하기 위해 setvar 조치를 사용하는 것과 동시에 expirevar 조치를 사용해야합니다. 자체적으로 사용되는 경우 (아마도 SecAction 지시문에서) 만료 시간이 재설정됩니다.

신분증

설명 : 나타나는 규칙 또는 체인에 고유 한 ID를 할당합니다. ModSecurity 2.7부터는이 동작이 필수적이며 숫자 여야합니다.

액션 그룹 : 메타 데이터

예:

SecRule & REQUEST_HEADERS : 호스트 "@eq 0" "log, id : 60008, severity : 2, msg : '호스트 헤더 누락 요청'"

참고 : id 작업은 v2.7.0부터 모든 SecRule / SecAction 지시문에 필요합니다.

다음은 예약 된 범위입니다.

• 1-99,999 : 로컬 (내부) 용으로 예약되어 있습니다. 적합하다고 생각되면 사용하지만 다른 사람에게 배포되는 규칙에는이 범위를 사용하지 마십시오.
• 100,000-199,999 : 오라클에서 게시 한 규칙을 위해 예약 됨
• 20 만 -299,999 명 : Comodo 게시 규칙 예약
• 300,000-399,999 : gotroot.com에 게시 된 규칙을 위해 예약 됨
• 400,000-419,999 : 미사용 (예약 가능)
• 420,000-429,999 : ScallyWhack 용으로 예약 됨 http://projects.otaku42.de/wiki/Scally-Whack
• 430,000-439,999 : Flameeyes http://www.flameeyes.eu/projects/modsec에서 게시 한 규칙을 위해 예약 됨
• 440.000-599,999 : 미사용 (예약 가능)
• 600,000-699,999 : Akamai http://www.akamai.com/html/solutions/waf.html 에서 사용하도록 예약 됨
• 700,000-799,999 : 이반 루스틱 전용
• 900,000-999,999 : OWASP ModSecurity 핵심 규칙 세트 용으로 예약 됨 http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Projectproject
• 1,000,000-1,009,999 : Redhat Security 팀에서 게시 한 규칙에 예약되어 있습니다.
• 1,010,000 ~ 1,999,999 : 미사용 (예약 가능)
• 2,000,000-2,999,999 : Trustwave의 SpiderLabs Research 팀의 규칙 예약
• 3,000,000-3,999,999 : Akamai http://www.akamai.com/html/solutions/waf.html 에서 사용하도록 예약 됨
• 4,000,000-4,099,999 예약 : AviNetworks에서 사용 중 https://kb.avinetworks.com/docs/latest/vantage-web-app-firewall-beta/
• 4,100,000-4,199,999 예약 : 빠른 사용 https://www.fastly.com/products/cloud-security/#products-cloud-security-web-application-firewall
• 4,200,000 이상 : 미사용 (예약 가능)

initcol

설명 : 저장소의 데이터를로드하거나 메모리에 새 컬렉션을 만들어 명명 된 영구 컬렉션을 초기화합니다.

액션 그룹 : 무중단

예 : 다음 예는 1 단계에서 가장 잘 수행되는 IP 주소 추적을 시작합니다.

SecAction 단계 : 1, id : 116, nolog, pass, initcol : ip = % {REMOTE_ADDR}

컬렉션은 initcol 액션이 실행될 때 필요에 따라 메모리에로드됩니다. 컬렉션은 트랜잭션 처리 과정에서 변경된 경우에만 지속됩니다.

자세한 내용은 "영구 저장 장치"절을 참조하십시오.

로그

Description: Indicates that a successful match of the rule needs to be logged.

Action Group: Non-disruptive

Example:

SecAction phase:1,id:117,pass,initcol:ip=%{REMOTE_ADDR},log

This action will log matches to the Apache error log file and the ModSecurity audit log.

logdata

Description: Logs a data fragment as part of the alert message.

Action Group: Non-disruptive

Example:

SecRule ARGS:p "@rx <script>" "phase:2,id:118,log,pass,logdata:%{MATCHED_VAR}"

The logdata information appears in the error and/or audit log files. Macro expansion is performed, so you may use variable names such as %{TX.0} or %{MATCHED_VAR}. The information is properly escaped for use with logging of binary data.

maturity

Description: Specifies the relative maturity level of the rule related to the length of time a rule has been public and the amount of testing it has received. The value is a string based on a numeric scale (1-9 where 9 is extensively tested and 1 is a brand new experimental rule).

Action Group: Meta-data

Version: 2.7

Example:

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bgetparentfolder\b" \
	"phase:2,ver:'CRS/2.2.4,accuracy:'9',maturity:'9',capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,msg:'Cross-site Scripting (XSS) Attack',id:'958016',tag:'WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'% \
{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

msg

Description: Assigns a custom message to the rule or chain in which it appears. The message will be logged along with every alert.

Action Group: Meta-data

Example:

SecRule &REQUEST_HEADERS:Host "@eq 0" "log,id:60008,severity:2,msg:'Request Missing a Host Header'"

Note : The msg information appears in the error and/or audit log files and is not sent back to the client in response headers.

multiMatch

Description: If enabled, ModSecurity will perform multiple operator invocations for every target, before and after every anti-evasion transformation is performed.

Action Group: Non-disruptive

Example:

SecRule ARGS "attack" "phase1,log,deny,id:119,t:removeNulls,t:lowercase,multiMatch"

Normally, variables are inspected only once per rule, and only after all transformation functions have been completed. With multiMatch, variables are checked against the operator before and after every transformation function that changes the input.

noauditlog

Description: Indicates that a successful match of the rule should not be used as criteria to determine whether the transaction should be logged to the audit log.

Action Group: Non-disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "Test" allow,noauditlog,id:120

If the SecAuditEngine is set to On, all of the transactions will be logged. If it is set to RelevantOnly, then you can control the logging with the noauditlog action.

The noauditlog action affects only the current rule. If you prevent audit logging in one rule only, a match in another rule will still cause audit logging to take place. If you want to prevent audit logging from taking place, regardless of whether any rule matches, use ctl:auditEngine=Off.

nolog

Description: Prevents rule matches from appearing in both the error and audit logs.

Action Group: Non-disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "Test" allow,nolog,id:121

Although nolog implies noauditlog, you can override the former by using nolog,auditlog.

pass

Description: Continues processing with the next rule in spite of a successful match.

Action Group: Disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "Test" "log,pass,id:122"

When using pass with a SecRule with multiple targets, all variables will be inspected and all non-disruptive actions trigger for every match. In the following example, the TX.test variable will be incremented once for every request parameter:

# Set TX.test to zero 
SecAction "phase:2,nolog,pass,setvar:TX.test=0,id:123"

# Increment TX.test for every request parameter 
SecRule ARGS "test" "phase:2,log,pass,setvar:TX.test=+1,id:124"

pause

Description: Pauses transaction processing for the specified number of milliseconds. Starting with ModSecurity 2.7 this feature also supports macro expansion.

Version: 2.x

Supported on libModSecurity: TBI

Action Group: Disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "Test" "log,pause:5000,id:125"

Warning : This feature can be of limited benefit for slowing down brute force authentication attacks, but use with care. If you are under a denial of service attack, the pause feature may make matters worse, as it will cause an entire Apache worker (process or thread, depending on the deployment mode) to sit idle until the pause is completed.

phase

Description: Places the rule or chain into one of five available processing phases. It can also be used in SecDefaultAction to establish the rule defaults.

Action Group: Meta-data

Example:

# Initialize IP address tracking in phase 1
SecAction phase:1,nolog,pass,id:126,initcol:IP=%{REMOTE_ADDR}

Starting in ModSecurity version v2.7 there are aliases for some phase numbers:

• 2 - 요청
• 4 - 응답
• 5 - 기록

예:

SecRule REQUEST_HEADERS : 사용자 에이전트 "테스트" "단계 : 요청, 로그, 거부, ID : 127"

경고 : 잘못된 단계를 지정하면 규칙에 사용 된 변수를 아직 사용할 수 없다는 점에 유의하십시오. 이로 인해 변수와 연산자가 정확할 수도 있지만 잘못된 단계를 지정했기 때문에 악의적 인 데이터가 누락되는 거짓 부정적인 상황이 발생할 수 있습니다.

앞에 붙이다

설명 : 매개 변수로 주어진 텍스트를 응답 본문 앞에 추가합니다. 콘텐츠 주입은 (SecContentInjection 지시문을 사용하여) 활성화되어야합니다. 내용 유형 검사가 수행되지 않습니다. 즉, 내용 주입 작업을 사용하기 전에 응답의 내용 유형이 주입에 적합한 지 여부를 확인해야합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 무중단

처리 단계 : 3 및 4.

예:

SecRule RESPONSE_CONTENT_TYPE ^ text / html \ "단계 : 3, nolog, pass, id : 128, 앞에 'Header <br>'"

경고 : 삽입 된 내용에서 매크로 확장이 허용 되더라도 사용자 정의 데이터 필드를 int 출력에 삽입하지 않도록주의해야합니다. 이렇게하면 사이트 간 스크립팅 취약점이 발생합니다.

대리

설명 : 프록시 백엔드를 사용하여 다른 웹 서버로 요청을 전달하여 현재 트랜잭션을 차단합니다. 포워딩은 HTTP 클라이언트에게 투명하게 수행됩니다 (즉, 외부 리다이렉션이 일어나지 않습니다).

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 파괴적인

예:

SecRule REQUEST_HEADERS : 사용자 에이전트 "테스트"로그, id : 129, proxy : http : // honeypothost /
SecRule REQUEST_URI "@streq /test.txt" "단계 : 1, 프록시 : '[nocanon] http : // $ ENV {SERVER_NAME} : $ ENV {SERVER_PORT} /test.txt',id:500005"

이 작업을 수행하려면 mod_proxy도 설치해야합니다. 이 작업은 일치하는 요청을 허니팟 웹 서버에 프록시하려는 경우, 특히 IP 주소 또는 세션 추적과 함께 사용할 때 유용합니다.

주 : v2.9.1에서는 프록시 조치가 "[nocanon]"이라는 특수 매개 변수를 수신 할 수 있습니다. "[nocanon]"매개 변수는 url을 원래 형식 (원시)으로 백엔드에 전달합니다. "nocanon"에 대한 자세한 내용은 https://httpd.apache.org/docs/2.2/pt-br/mod/mod_proxy.html을 참조하십시오 .

리디렉션

설명 : 지정된 위치로 외부 (클라이언트가 볼 수있는) 리디렉션을 실행하여 트랜잭션을 차단합니다.

액션 그룹 : 파괴적인

예:

SecRule REQUEST_HEADERS : User-Agent "Test" "단계 : 1, id : 130, log, redirect : http : //www.example.com/failed.html"

상태 작업이 동일한 규칙에 있고 해당 값을 리디렉션에 사용할 수있는 경우 (즉, 301, 302, 303 또는 307 중 하나임) 리디렉션 상태 코드에 값이 사용됩니다. 그렇지 않으면 상태 코드 302가 사용됩니다.

회전

설명 : 룰 개정을 지정합니다. id 액션과 함께 사용하면 규칙이 변경되었다는 표시를 제공 할 수 있습니다.

액션 그룹 : 메타 데이터

예:

(? :( Wget | curl)) \ b | \ / cc (? : SecRule REQUEST_FILENAME | ARGS_NODE | ARGS | [\ '\ "\ | \; \`\ - \ s] | $))"\
	                "단계 : 2, rev : '2.1.3', 캡처, t : 없음, t : normalizePath, t : 소문자, ctl : auditLogParts = + E, block, msg : '시스템 명령어 삽입', id : '950907' 태그 : 'WASCTC / WASC-31', 태그 : 'OWASP_TOP_10 / A1', 태그 : 'PCI / 6.5.2', 로그 데이터 : '% {TX.0}', 심각도 : 'WEB_ATTACK / COMMAND_INJECTION' 2, setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx.command_injection_score = + % {tx.critical_anomaly_score}, setvar : tx. % {rule.id} -WEB_ATTACK / COMMAND_INJECTION - % {matched_var_name} = % {tx.0}, skipAfter : END_COMMAND_INJECTION1 "

참고 :이 작업은 id 작업과 함께 사용되어 변경 후에 같은 규칙 ID를 사용할 수 있지만 규칙이 변경되었음을 알리는 표시를 제공합니다.

sanitiseArg

설명 : 중요한 요청 매개 변수 데이터가 감사 로그에 기록되지 않도록합니다. 명명 된 매개 변수의 각 바이트는 별표로 대체됩니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 무중단

예:

# 비밀번호를 기록하지 마라. 
SecAction "nolog, 단계 : 2, id : 131, sanitiseArg : 암호, sanitiseArg : newPassword, sanitiseArg : oldPassword"

주 : sanitize 조치는 감사 로그에 기록 될 때 데이터에만 영향을줍니다. 고급 디버그 로그에는 중요한 데이터가 들어있을 수 있습니다. Apache 액세스 로그에는 요청 URI에있는 중요한 데이터가 들어있을 수 있습니다.

sanitiseMatched

설명 : 일치하는 변수 (요청 인수, 요청 헤더 또는 응답 헤더)가 감사 로그에 기록되지 않도록합니다. 명명 된 매개 변수의 각 바이트는 별표로 대체됩니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 무중단

예 : 임의의 트랜잭션 요소가 조건과 일치 할 때 위의 작업을 사용하여 위탁 할 수 있습니다. 예를 들어, 아래 예제는 이름에 password라는 단어가 포함 된 모든 인수를 위생 처리합니다.

SecRule ARGS_NAMES 암호 nolog, pass, id : 132, sanitiseMatched

주 : sanitize 조치는 감사 로그에 기록 될 때 데이터에만 영향을줍니다. 고급 디버그 로그에는 중요한 데이터가 들어있을 수 있습니다. Apache 액세스 로그에는 요청 URI에있는 중요한 데이터가 들어있을 수 있습니다.

sanitiseMatchedBytes

설명 : 변수의 일치 문자열이 감사 로그에 기록되지 않도록합니다. 명명 된 매개 변수의 각 바이트 또는 범위는 별표로 바뀝니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 무중단

예 : 임의의 트랜잭션 요소가 조건과 일치 할 때 위의 작업을 사용하여 위탁 할 수 있습니다. 예를 들어, 아래 예는 신용 카드 번호를 위생 처리합니다.

• sanitiseMatchedBytes - 이것은 일치하는 바이트만을 x 출력합니다.
• sanitiseMatchedBytes : 1 / 4 - 일치하는 바이트를 x x하지만 첫 번째 바이트와 마지막 4 바이트를 유지합니다.

# 매개 변수 및 신용 카드 번호 검색 
# 감사 로그에 기록되지 않도록합니다. 
SecRule ARGS "@verifyCC \ d {13,16}" "단계 : 2, id : 133, nolog, capture, pass, msg : '요청시 가능한 신용 카드 번호', sanitiseMatchedBytes"
"잠재적 인 신용 카드 번호는 응답 본문입니다.", sanitiseMatchedBytes : 0/4 ","

주 : sanitize 조치는 감사 로그에 기록 될 때 데이터에만 영향을줍니다. 고급 디버그 로그에는 중요한 데이터가 들어있을 수 있습니다. Apache 액세스 로그에는 요청 URI에있는 중요한 데이터가 들어있을 수 있습니다. sanitiseMatchedBytes로 캡처 작업을 사용해야하므로 운영자는 캡처 작업을 지원해야합니다. ie : @rx, @verifyCC.

sanitiseRequestHeader

설명 : 명명 된 요청 헤더가 감사 로그에 기록되지 않도록합니다. 명명 된 요청 헤더의 각 바이트는 별표로 대체됩니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 무중단

예: Authorization 헤더의 데이터를 삭제합니다.

SecAction "단계 : 1, nolog, pass, id : 135, sanitiseRequestHeader : 권한 부여"

주 : sanitize 조치는 감사 로그에 기록 될 때 데이터에만 영향을줍니다. 고급 디버그 로그에는 중요한 데이터가 들어있을 수 있습니다. Apache 액세스 로그에는 요청 URI에있는 중요한 데이터가 들어있을 수 있습니다.

sanitiseResponseHeader

설명 : 명명 된 응답 헤더가 감사 로그에 기록되지 않도록합니다. 명명 된 응답 헤더의 각 바이트는 별표로 바뀝니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

액션 그룹 : 무중단

예 : 이것은 클라이언트로 전송 된 Set-Cookie 데이터를 위생 처리합니다.

SecAction "단계 : 3, nolog, pass, id : 136, sanitiseResponseHeader : Set-Cookie"

주 : sanitize 조치는 감사 로그에 기록 될 때 데이터에만 영향을줍니다. 고급 디버그 로그에는 중요한 데이터가 들어있을 수 있습니다. Apache 액세스 로그에는 요청 URI에있는 중요한 데이터가 들어있을 수 있습니다.

엄격

설명 : 심각도를 사용하는 규칙에 할당합니다.

액션 그룹 : 메타 데이터

예:

SecRule REQUEST_METHOD "^ PUT $" "id : 340002, rev : 1, 심각도 : CRITICAL, msg : '제한된 HTTP 기능'"

ModSecurity의 심각도 값은 syslog의 숫자 배율을 따릅니다 (0이 가장 심각합니다). 아래 데이터는 OWASP ModSecurity 핵심 규칙 집합 (CRS)에서 사용합니다.

• 0 - 비상 사태 : 인바운드 공격 및 아웃 바운드 누출이있는 이상 점수 데이터와의 상관 관계에서 생성됩니다.
• 1 - ALERT : 인바운드 공격 및 아웃 바운드 응용 프로그램 수준 오류가있는 상관 관계에서 생성됩니다.
• 2 - CRITICAL : Anomaly Score 5. 상관 관계없이 가장 높은 심각도 수준이 가능합니다. 일반적으로 웹 공격 규칙 (40 레벨 파일)에 의해 생성됩니다.
• 3 - 오류 : 오류 - 이상 점 4. 아웃 바운드 누출 규칙 (50 레벨 파일)에서 대부분 생성됩니다.
• 4 - 경고 : 이상 점수 3. 악성 클라이언트 규칙 (35 레벨 파일)에 의해 생성됩니다.
• 5 -주의 사항 : 이상 점수 2. 프로토콜 정책 및 이상 파일에 의해 생성됩니다.
• 6 - 정보
• 7 - 디버그

숫자 값 또는 텍스트 값을 사용하여 심각도 수준을 지정할 수는 있지만 숫자가 의미하는 것을 기억하기가 어렵 기 때문에 항상 텍스트 값을 사용하여 심각도 수준을 지정해야합니다. 숫자 값의 사용은 버전 2.5.0에서 더 이상 사용되지 않으며 이후 주요 업데이트 중 하나에서 제거 될 수 있습니다.

setuid

설명 : 매개 변수로 제공된 사용자 이름을 사용하여 USER 컬렉션을 초기화하는 특수 용도의 작업입니다.

액션 그룹 : 무중단

예:

SecRule ARGS : username ". *" "phase : 2, id : 137, t : none, pass, nolog, noauditlog, 캡처, setvar : session.username = % {TX.0}, setuid : % {TX.0} "

초기화가 수행 된 후, 변수 USERID는 후속 규칙에서 사용 가능합니다. 이 작업은 응용 프로그램 네임 스페이스 (SecWebAppId를 사용하여 구성됨)를 인식하고 구성된 경우 응용 프로그램 네임 스페이스를 사용합니다.

setrsc

설명 : 매개 변수로 제공된 키를 사용하여 RESOURCE 컬렉션을 초기화하는 특수 용도의 작업입니다.

액션 그룹 : 무중단

버전 : 2.x-3.0 (사전)

libModSecurity에서 지원됨 : 예 - 9cb3f2 현재 https://github.com/SpiderLabs/ModSecurity/commit/9cb3f23b5095cad7dfba8f140a44b9523f2be78b

예:

SecAction "단계 : 1, 통과, id : 3, 로그, setrsc : 'abcd1234'"

이 작업은 응용 프로그램 네임 스페이스 (SecWebAppId를 사용하여 구성됨)를 인식하고 구성된 경우 응용 프로그램 네임 스페이스를 사용합니다.

setsid

설명 : 매개 변수로 제공된 세션 토큰을 사용하여 SESSION 컬렉션을 초기화하는 특수 용도의 작업입니다.

액션 그룹 : 무중단

예:

# 세션 쿠키 값을 사용하여 세션 변수를 초기화합니다. 
SecRule REQUEST_COOKIES : PHPSESSID! ^ $ "nolog, pass, id : 138, setsid : % {REQUEST_COOKIES.PHPSESSID}"

노트

초기화가 수행 된 후 변수 SESSION이 후속 규칙에서 사용 가능합니다. 이 작업은 응용 프로그램 네임 스페이스 (SecWebAppId를 사용하여 구성됨)를 인식하고 구성된 경우 응용 프로그램 네임 스페이스를 사용합니다.

Setsid는 컬렉션이 아닌 개별 변수를 취합니다. setsid와 같은 액션 내의 변수는 [collection]. [variable] 형식을 사용합니다.

세트 엔브

설명 : Apache에서 액세스 할 수있는 환경 변수를 작성, 제거 및 업데이트합니다.

액션 그룹 : 무중단

버전 : 2.x

libModSecurity : TBI 에서 지원됨

예 :

세션 (세션 ID) | cf (id | 토큰) | SecRule RESPONSE_HEADERS : / Set-Cookie2? / "(? i : (j? sessionid | (php)? sessid | (asp | jserv | | sid)) "단계 : 3, t : 없음, 전달, id : 139, nolog, setvar : tx.sessionid = % {matched_var}"
SecRule TX : SESSIONID "! (? i : \ ;?? httponly ;?)" "단계 : 3, id : 140, t : 없음, setenv : httponly_cookie = % {matched_var}, pass, log, auditlog, msg : AppDefect : 누락 된 HttpOnly 쿠키 플래그. ' "

헤더 세트 쿠키 "% {httponly_cookie} e; HTTPOnly"env = httponly_cookie

참고 : 체인에서 사용될 때이 작업은 전체 체인이 아닌 개별 규칙이 일치 할 때 실행됩니다.

세트 바

설명 : 변수를 작성, 제거 또는 갱신합니다. 변수 이름은 대소 문자를 구별하지 않습니다.

액션 그룹 : 무중단

예 : 변수를 만들고 그 값을 1 (일반적으로 플래그 설정에 사용)로 설정하려면 다음을 사용하십시오.setvar:TX.score

변수를 만들고 동시에 초기화하려면 다음을 사용하십시오. setvar:TX.score=10

변수를 제거하려면 이름 앞에 느낌표를 추가하십시오. setvar:!TX.score

변수 값을 늘리거나 줄이려면 숫자 앞에 + 및 - 문자를 사용하십시오. setvar:TX.score=+5

OWASP CRS의 예 :

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "\ bsys \ .user_catalog \ b"\
		"단계 : 2, rev : '2.1.3', 캡처, t : 없음, t : urlDecodeUni, t : htmlEntityDecode, t : 소문자, t : replaceComments, t : compressWhiteSpace, ctl : auditLogParts = + E,
태그 : 'WASCTC / WASC-19', 태그 : 'OWASP_TOP_10 / A1', 태그 : 'OWASP_AppSensor / CIE1'태그 : '블라인드 SQL 주입 공격', ID : '959517', 태그 : 'WEB_ATTACK / SQL_INJECTION' , \
태그 : 'PCI / 6.5.2', 로그 데이터 : '% {TX.0}', 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.sql_injection_score = + % {tx.critical_anomaly_score}, \
setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx. % {rule.id} -WEB_ATTACK / SQL_INJECTION - % {matched_var_name} = % {tx.0} "

참고 : 체인에서 사용될 때이 동작은 개별 규칙이 일치하고 전체 체인이 일치하지 않을 때 실행됩니다. 이것은

SecRule REQUEST_FILENAME "@contains /test.php" "chain,id:7,phase:1,t:none,nolog,setvar:tx.auth_attempt=+1" 
    SecRule ARGS_POST:action "@streq login" "t:none"

test.php가 방문 될 때마다 (제출 된 매개 변수에 관계없이) 증가 할 것입니다. 전체 규칙이 일치하는 경우에만 원하는 목표가 변수를 설정하는 것이면 체인의 마지막 규칙에 포함되어야합니다. 예를 들면 :

SecRule REQUEST_FILENAME "@streq test.php" "chain,id:7,phase:1,t:none,nolog"
    SecRule ARGS_POST:action "@streq login" "t:none,setvar:tx.auth_attempt=+1"

버킷

설명 : 성공적인 일치시 하나 이상의 규칙 (또는 체인)을 건너 뜁니다.

액션 그룹 : 흐름

예:

# Accept 헤더는 필요하지만 localhost로부터의 액세스는 필요하지 않습니다. 
SecRule REMOTE_ADDR "^ 127 \ .0 \ .0 \ .1 $" "단계 : 1, 건너 뛰기 : 1, ID : 141" 

#이 규칙은 REMOTE_ADDR이 127.0.0.1 일 때 건너 뜁니다. 
SecRule & REQUEST_HEADERS : "@eq 0"을 받아들입니다. "phase : 1, id : 142, deny, msg : '요청 헤더를받지 못했습니다.'"

건너 뛰기 동작은 현재 처리 단계에서만 작동하며 구성 파일에 규칙이 나타나는 순서와 반드시 일치하지는 않습니다. 건너 뛰기를 사용하는 1 단계 규칙 이후에 2 단계 규칙을 배치하면 2 단계 규칙을 건너 뛰지 않습니다. 단계에서 다음 단계 1 규칙을 건너 뜁니다.

skipAfter

설명 : 성공적인 일치시 하나 이상의 규칙 (또는 체인)을 건너 뛰고 제공된 ID로 규칙 (또는 SecMarker에서 만든 마커)을 따르는 첫 번째 규칙을 사용하여 규칙 실행을 다시 시작합니다.

액션 그룹 : 흐름

예제 : 다음 규칙은 건너 뛰기 예제와 같은 논리를 구현하지만 skipAfter를 사용합니다.

# Accept 헤더는 필요하지만 localhost로부터의 액세스는 필요하지 않습니다. 
SecRule REMOTE_ADDR "^ 127 \ .0 \ .0 \ .1 $" "단계 : 1, id : 143, skipAfter : IGNORE_LOCALHOST" 

#이 규칙은 REMOTE_ADDR이 127.0.0.1 일 때 건너 뜁니다. 
SecRule & REQUEST_HEADERS : "@eq 0"을 수락 "phase : 1, deny, id : 144, msg : '요청을 수락 헤더 누락' '" 
SecMarker IGNORE_LOCALHOST

OWASP ModSecurity CRS의 예 :

SecMarker BEGIN_HOST_CHECK

	SecRule & REQUEST_HEADERS : 호스트 "@eq 0"\
    		ID : '960008', 태그 : 'PROTOCOL_VIOLATION / MISSING_HEADER_HOST', tag : '호스트 헤더가 누락되었습니다.', ID : '960008', 태그 : 'skipAfter : END_HOST_CHECK, 단계 : 2, rev : WASCTC / WASC-21 ', \
태그 : 'OWASP_TOP_10 / A7', 태그 : 'PCI / 6.5.10', 심각도 : '5', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx. notice_anomaly_score}, \
setvar : tx.protocol_violation_score = + % {tx.notice_anomaly_score}, setvar : tx. % {rule.id} -PROTOCOL_VIOLATION / MISSING_HEADER - % {matched_var_name} = % {matched_var} "

	SecRule REQUEST_HEADERS : "^ $"호스트
    		ID : '960008', 태그 : 'PROTOCOL_VIOLATION / MISSING_HEADER_HOST', 태그 : 'WASCTC / WASC-2': '2 단계 : rev :'2.1.3 ', t : none, block, msg :'호스트 헤더 누락 요청 ' 21 ', 태그 :'OWASP_TOP_10 / A7 ', \
태그 : 'PCI / 6.5.10', 심각도 : '5', setvar : 'tx.msg = % {rule.msg}', setvar : tx.anomaly_score = + % {tx.notice_anomaly_score}, setvar : tx.protocol_violation_score = + % {tx.notice_anomaly_score}, \
setvar : tx. % {rule.id} -PROTOCOL_VIOLATION / MISSING_HEADER - % {matched_var_name} = % {matched_var} "

SecMarker END_HOST_CHECK

skipAfter 액션은 현재 처리 단계에서만 작동하며 반드시 구성 파일에 규칙이 나타나는 순서는 아닙니다. 건너 뛰기를 사용하는 1 단계 규칙 이후에 2 단계 규칙을 배치하면 2 단계 규칙을 건너 뛰지 않습니다. 단계에서 다음 단계 1 규칙을 건너 뜁니다.

지위

설명 : 거부 및 재 지정 작업에 사용할 응답 상태 코드를 지정합니다.

액션 그룹 : 데이터

예:

# 상태 403으로 거부
SecDefaultAction "단계 : 1, 로그, 거부, ID : 145, 상태 : 403"

Apache 범위 위치 (예 : 디렉토리, 위치 등)에 정의 된 상태 작업은 단계 : 1 작업 설정으로 대체 될 수 있습니다. 구성에 Apache ErrorDocument 지정 문이 있으면 트리거됩니다. 따라서 이전에 특정 상태에 대한 사용자 정의 오류 페이지를 정의한 경우 해당 페이지가 실행되고 출력이 사용자에게 표시됩니다.

티

설명 : 이 작업은 일치시키기 전에 규칙에 사용 된 각 변수의 값을 변환하는 데 사용할 변환 파이프 라인을 지정하는 데 사용됩니다.

액션 그룹 : 무중단

예:

t : 없음, t : htmlEntityDecode, t : 소문자, t : removeNulls, t : removeWhitespace "(숨김 참조)

SecRule에 지정하는 변환 함수는 모두 SecDefaultAction에 지정된 이전 함수에 추가됩니다. 규칙에 항상 t : none을 사용하면 기본 구성에 따라 t : none을 사용하지 않는 것이 좋습니다.

꼬리표

설명 : 규칙 또는 체인에 태그 (카테고리)를 할당합니다.

액션 그룹 : 메타 데이터

예:

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "\ bgetparentfolder \ b"\
	auditLogParts = + E, block, msg : 'XSS (Cross-Site Scripting)'단계 : 2 단계 : rev : '2.1.3', 캡처, t : 없음, t : htmlEntityDecode, t : compressWhiteSpace, t : 소문자, ctl : 태그 : 'WASCTC / WASC-8', 태그 : 'WASCTC / WASC-22', 태그 : 'OWASP_TOP_10 / A2', 태그 : 'OWASP_AppSensor / Attack', id : '958016'태그 : 'WEB_ATTACK / XSS' IE1 ', 태그 :'PCI / 6.5.1 ', 로그 데이터 :'%
심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.xss_score = + % {tx.critical_anomaly_score}, setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx. % {rule.id} -WEB_ATTACK / XSS - % {matched_var_name} = % {tx.0} "

태그 정보는 다른 규칙 메타 데이터와 함께 나타납니다. 이벤트를 자동으로 쉽게 분류 할 수 있도록 태그 지정 메커니즘의 목적입니다. 같은 규칙에 여러 태그를 지정할 수 있습니다. 슬래시를 사용하여 범주의 계층 구조를 만듭니다 (예에서와 같이). ModSecurity 2.6.0 태그는 매크로 확장을 지원합니다.

ver

설명 : 룰 세트 버전을 지정합니다.

액션 그룹 : 메타 데이터

버전 : 2.7

예:

SecRule REQUEST_FILENAME | ARGS_NAMES | ARGS | XML : / * "\ bgetparentfolder \ b"\
	"크로스 사이트 스크립팅 (XSS)"단계 : 2, 버전 : 'CRS / 2.2.4, 캡처, t : 없음, t : htmlEntityDecode, t : compressWhiteSpace, t : 소문자, ctl : auditLogParts = + E, 태그 : 'WASCTC / WASC-8', 태그 : 'WASCTC / WASC-22', 태그 : 'OWASP_TOP_10 / A2', 태그 : 'OWASP_AppSensor /IE1',tag:'PCI/6.5.1',logdata:'% \
심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.xss_score = + % {tx.critical_anomaly_score}, setvar : tx.anomaly_score = + % {tx.critical_anomaly_score}, setvar : tx. % {rule.id} -WEB_ATTACK / XSS - % {matched_var_name} = % {tx.0} "

xmlns

설명 : XML 네임 스페이스를 구성합니다.이 네임 스페이스는 XPath 표현식의 실행에 사용됩니다.

액션 그룹 : 데이터

예:

Securule REQUEST_HEADERS : Content-Type "text / xml" "단계 : 1, id : 147, pass, ctl : requestBodyProcessor = XML, ctl : requestBodyAccess =
    xmlns : xsd = "http://www.w3.org/2001/XMLSchema"
SecRule XML : / soap : Envelope / soap : Body / q1 : getInput / id () "123"단계 : 2, 거부, id : 148

연산자

이 섹션에서는 현재 ModSecurity에서 사용할 수있는 연산자를 설명합니다.

시작과 함께

설명 : 매개 변수 문자열이 입력의 시작 부분에서 발견되면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# "GET"으로 시작하지 않는 요청 줄 검색 
SecRule REQUEST_LINE "! @beginsWith GET" "id : 149"

포함하다

설명 : 매개 변수 문자열이 입력의 어디에서나 발견되면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# 요청 줄 어디서나 ".php"를 탐지하십시오. 
SecRule REQUEST_LINE "@ 포함 .php" "id : 150"

containsWord

설명 : 매개 변수 문자열 (단어 경계 포함)이 입력의 모든 위치에서 발견되면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# ARGS의 어느 곳에서나 "select"를 탐지합니다. 
SecRule ARGS "@containsWord select" "id : 151"

에 일치합니다 - 
-1 조합 을 선택 wp_users FROM 벤치 마크 (2142500, MD5 (CHAR (115,113,108,109,97,112))) WHERE ID = 1 (아스키 (SUBSTR (USER_LOGIN, 1,1)) 0x01로 = 0) wp_users에서 어디 ID = 1--

하지만,하지에 - 
당신의 위치는 폭이 선택 컴퓨터의 이온.

detectSQLi

설명 : SQL 주입 페이로드가 발견되면 true를 반환합니다. 이 연산자는 LibInjection을 사용하여 SQLi 공격을 탐지합니다.

버전 : 2.7.4

예:

# 요청 URI 내부의 SQL 인젝션 탐지 " 
SecRule REQUEST_URI "@detectSQLi" "id : 152"

참고 :이 연산자는 "캡처"작업을 지원합니다.

detectXSS

설명 : XSS 주입이 발견되면 true를 반환합니다. 이 연산자는 LibInjection을 사용하여 XSS 공격을 탐지합니다.

버전 : 2.8.0

예:

# 요청 본문 내에서 XSS 주입 감지 
SecRule REQUEST_BODY "@detectXSS" "id : 12345, log, deny"

endsWith

설명 : 매개 변수 문자열이 입력의 끝에서 발견되면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# "HTTP / 1.1"로 끝나지 않는 요청 줄 검색 
SecRule REQUEST_LINE "! @endsWith HTTP / 1.1" "id : 152"

퍼지 해시

설명 : fuzzyHash 연산자는 컨텍스트에 의해 트리거 된 조각 별 해시 (CTPH)를 계산하기위한 프로그램 인 ssdeep을 사용합니다. 퍼지 해시라고도하는 CTPH는 상동 성이있는 입력을 일치시킬 수 있습니다. 이러한 입력 사이에는 바이트가 내용과 길이가 다를 수 있지만 이러한 입력에는 동일한 순서의 동일한 바이트 순서가 있습니다.

ssdeep에 대한 자세한 내용은 해당 사이트를 방문하십시오. http://ssdeep.sourceforge.net/

버전 : v2.9.0-RC1-2.9.x

libModSecurity : TBI 에서 지원됨

예:

SecRule REQUEST_BODY "\ @ 퍼지 해쉬 / 경로 /to/ssdeep/hashes.txt 6" "id : 192372, log, deny"

eq

설명 : 숫자 비교를 수행하고 입력 값이 제공된 매개 변수와 같으면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# 정확히 15 개의 요청 헤더 감지 
SecRule & REQUEST_HEADERS_NAMES "@eq 15" "id : 153"

참고 : 정수로 변환 할 수없는 값 (예 : 문자열)이 제공되면이 연산자는 해당 값을 0으로 처리합니다.

GE

설명 : 숫자 비교를 수행하고 입력 값이 제공된 매개 변수보다 크거나 같으면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# 15 개 이상의 요청 헤더를 탐지합니다. 
SecRule & REQUEST_HEADERS_NAMES "@ge 15" "id : 154"

참고 : 정수로 변환 할 수없는 값 (예 : 문자열)이 제공되면이 연산자는 해당 값을 0으로 처리합니다.

geoLookup

설명 : 이전에 SecGeoLookupDb를 사용하여 구성된 Geolocation 데이터베이스에 대한 입력의 IP 주소를 사용하여 Geolocation 조회를 수행합니다. 조회가 성공적이면 획득 된 정보가 GEO 컬렉션에 캡처됩니다.

예 : geoLookup 연산자는 성공시 일치하므로 nolog, pass와 조합하여 사용하는 것이 가장 좋습니다. 실패한 조회 (위치 정보 데이터베이스의 정확도에 따라 맨 위에있을 수 있음)를 차단하려는 경우 다음 예는이를 수행하는 가장 좋은 방법을 보여줍니다.

# Geolocation 데이터베이스 구성 
SecGeoLookupDb /path/to/GeoLiteCity.dat 
... 
# 조회 IP 주소 
SecRule REMOTE_ADDR "@geoLookup" "단계 : 1, id : 155, nolog, pass"

# Geolocation이 실패한 IP 주소 차단
 SecRule & GEO "@eq 0" "phase : 1, id : 156, deny, msg : 'IP 조회 실패'

사용 가능한 다양한 필드에 대한 예제 및 추가 정보는 GEO 변수를 참조하십시오.

gsbLookup

설명 : 이전에 SecGsbLookupDb를 사용하여 구성된 GSB 데이터베이스에 대한 입력 URL을 사용하여 Google의 세이프 브라우징을 로컬로 검색합니다. 캡처 연산자와 결합하면 일치하는 url을 tx.0 변수에 저장합니다.

Syntax: SecRule TARGET "@gsbLookup REGEX" ACTIONS

버전 : 2.6

libModSecurity에서 지원됨 : TBD

예 : gsbLookup 연산자는 성공시 일치하므로 블록 또는 리디렉션 작업과 함께 사용하는 것이 가장 좋습니다. 성공적인 조회를 차단하려면 다음 예제를 참조하십시오.

# Google 세이프 브라우징 데이터베이스 구성 
SecGsbLookupDb /path/to/GsbMalware.dat 
... 
# 응답 본문에서 악성 링크 확인
Securule RESPONSE_BODY "@gsbLookup = \"https? \ : \ / \ ""단계 : 4, id : 157, capture, log, block, msg : 'RESPONSE_BODY에서 잘못된 URL이 감지되었습니다 (Google Safe 브라우징 확인) ', 로그 데이터 :'http : //www.google.com/safebrowsing/diagnostic? site = % {tx.0} ''

참고 :이 연산자는 "캡처"작업을 지원합니다.

gt

설명 : 숫자 비교를 수행하고 입력 값이 연산자 매개 변수보다 큰 경우 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# 요청에서 15 개가 넘는 헤더 검색 
SecRule & REQUEST_HEADERS_NAMES "@gt 15" "id : 158"

참고 : 정수로 변환 할 수없는 값 (예 : 문자열)이 제공되면이 연산자는 해당 값을 0으로 처리합니다.

inspectFile

설명 : 대상 목록의 모든 변수에 대해 외부 프로그램을 실행합니다. 변수의 내용은 명령 행의 첫 번째 매개 변수로 스크립트에 제공됩니다. 프로그램은 연산자의 첫 번째 매개 변수로 지정해야합니다. 버전 2.5.0에서, 제공된 프로그램 파일 이름이 절대적이지 않으면, 구성 파일이 상주하는 디렉토리와 관련하여 처리됩니다. 또한 버전 2.5.0에서 파일 이름이 Lua 스크립트 (.lua 확장자 기반)로 결정되면 스크립트는 내부 Lua 엔진에 의해 처리됩니다. 내부적으로 처리되는 스크립트는 종종 더 빠르게 실행되며 (프로세스 생성 오버 헤드가 없음) ModSecurity의 트랜잭션 컨텍스트에 대한 완전한 액세스 권한을가집니다.

@inspectFile 연산자는 초기에 파일 검사를 위해 설계되었으므로 (이름), 외부 논리를 사용하여 의사 결정이 필요한 상황에서도 사용할 수 있습니다.

OWASP ModSecurity 핵심 규칙 집합 (CRS)에는 runav.pl http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/util/ 이라는 유틸리티 스크립트가 / util 디렉토리 에 있습니다. ClamAV 바이러스 스캐너와 통합하는 파일 승인 메커니즘 이는 바이러스 및 악용 사례가 파일 업로드를 통해 웹 서버에 들어가는 것을 방지하기 위해 특히 편리합니다.

#! / usr / bin / perl
#
# runav.pl
# Copyright (c) 2004-2011 Trustwave
#
#이 스크립트는 ModSecurity와 그 스크립트 사이의 인터페이스입니다
#을 통해 업로드되는 파일을 가로 챌 수있는 능력
# 웹 서버 및 ClamAV


$ CLAMSCAN = "clamscan";

if ($ # ARGV! = 0) {
    인쇄 "사용법 : runav.pl <파일 이름> \ n";
    출구;
}

내 ($ FILE) = 교대 @ARGV;

$ cmd = "$ CLAMSCAN --stdout --no-summary $ FILE";
$ input =`$ cmd`;
$ input = ~ m /^(.+)/;
$ error_message = $ 1;

$ output = "0 clamscan 출력 [$ 1]을 (를) 구문 분석 할 수 없습니다.";

if ($ error_message = ~ m / : 빈 파일 \.? $ /) {
    $ output = "1 빈 파일";
}
elsif ($ error_message = ~ m / : (. +) ERROR $ /) {
    $ output = "0 clamscan : $ 1";
}
elsif ($ error_message = ~ m / : (. +) FOUND $ /) {
    $ output = "0 clamscan : $ 1";
}
elsif ($ error_message = ~ m / : OK $ /) {
    $ output = "1 clamscan : OK";
}

print "$ output \ n";

예 : runav.pl 스크립트 사용 :

# 업로드 된 파일의 유효성을 검사하기 위해 외부 프로그램 실행 
SecRule FILES_TMPNAMES "@inspectFile / path /to/util/runav.pl" "id : 159"

Lua 스크립트 사용의 예 (설정 파일과 같은 디렉토리에 위치) :

SecRule FILES_TMPNAMES "@inspectFile inspect.lua" "id : 160"

inspect.lua의 내용 :

함수 main (파일 이름)
    - 파일을 확인하여 확인하십시오. 이 예에서 우리는
    - 파일 시작 부분에서 최대 10자를 읽습니다.
    로컬 f = io.open (파일 이름, "rb");
    로컬 d = f : 읽기 (10);
    f : close ();
   
    - 아무것도 없다고 생각할 이유가 없으면 null을 반환합니다.
    - 파일에 문제가 있습니다 (일치하지 않음). 텍스트를 반환하면 가져옵니다.
    - 경기가 호랑이를 당해야 함을 의미합니다.
    null를 돌려 준다.
종료

참고 : 버전 2.9부터 시작 ModSecurity는 SecTmpSaveUploadedFiles 지시문이 On이거나 SecUploadKeepFiles 지시문이 RelevantOnly로 설정되어 있지 않으면 FILES_TMPNAMES 변수를 채우지 않습니다.

참고 : @inspectFile은 신중하게 사용하십시오. @inspectFile을 FILES_TMPNAMES가 아닌 다른 변수와 함께 사용하는 것은 안전하지 않을 수 있습니다. "FULL_REQUEST"와 같은 다른 변수에는 플랫폼에서 처리 과정을 포크하게하는 내용이 포함되어있어 공격자가 웹 서버와 동일한 권한을 사용하여 코드를 실행할 수 있습니다. 다른 변수들에 대해서는 Lua 스크립트 엔진을 보길 원할 것입니다. 이 관찰은 사용자 메일 링리스트의 "Gryzli"에 의해 주목을 끌었습니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

참조 : http://blog.spiderlabs.com/2010/10/advanced-topic-of-the-week-preventing-malicious-pdf-file-uploads.html

참조 : http://sourceforge.net/p/mod-security/mailman/mod-security-users/?viewmonth=201512

ipMatch

설명 : REMOTE_ADDR 변수 데이터의 빠른 ipv4 또는 ipv6 일치를 수행합니다. 다음 형식을 처리 할 수 ​​있습니다.

• 전체 IPv4 주소 - 192.168.1.100
• 네트워크 차단 / CIDR 주소 - 192.168.1.0/24
• 전체 IPv6 주소 - 2001 : db8 : 85a3 : 8d3 : 1319 : 8a2e : 370 : 7348
• 네트워크 블록 / CIDR 주소 - 2001 : db8 : 85a3 : 8d3 : 1319 : 8a2e : 370 : 0/24

버전 : 2.7

예 :

개별 주소 :

SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" "id : 161"

네트워크 블록이있는 다중 주소 :

SecRule REMOTE_ADDR "@ipMatch 192.168.1.100,192.168.1.50,10.10.50.0 / 24" "id : 162"

ipMatchF

ipMatchFromFile의 짧은 별칭

버전 : 2.7

ipMatchFromFile

설명 : REMOTE_ADDR 변수의 빠른 ipv4 또는 ipv6 일치를 수행하여 파일의 데이터를로드합니다. 다음 형식을 처리 할 수 ​​있습니다.

• 전체 IPv4 주소 - 192.168.1.100
• 네트워크 차단 / CIDR 주소 - 192.168.1.0/24
• 전체 IPv6 주소 - 2001 : db8 : 85a3 : 8d3 : 1319 : 8a2e : 370 : 7348
• 네트워크 블록 / CIDR 주소 - 2001 : db8 : 85a3 : 8d3 : 1319 : 8a2e : 370 : 0/24

버전 : 2.7

예 :

SecRule REMOTE_ADDR "@ipMatchFromFile ips.txt" "id : 163"

ips.txt 파일에는 다음 항목이 포함될 수 있습니다.

192.168.0.1
172.16.0.0/16
10.0.0.0/8

참고 : v2.9.0-RC1에서이 연산자는 HTTPS 서버에서 제공하는 컨텐츠를로드하는 기능도 지원합니다.

참고 : HTTPS 서버에서 제공하는 컨텐츠와 함께 사용할 경우 원격 컨텐츠를 검색 할 수 없을 때 SecRemoteRulesFailAction 지시문을 사용하여 중단 대신 경고를 구성 할 수 있습니다.

르

설명 : 숫자 비교를 수행하고 입력 값이 연산자 매개 변수보다 작거나 같으면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예 :

# 요청에서 15 개 이하의 헤더를 탐지합니다. 
SecRule & REQUEST_HEADERS_NAMES "@le 15" "id : 164"

참고 : 정수로 변환 할 수없는 값 (예 : 문자열)이 제공되면이 연산자는 해당 값을 0으로 처리합니다.

lt

설명 : 숫자 비교를 수행하고 입력 값이 연산자 매개 변수보다 작 으면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# 요청에서 15 개 미만의 헤더 검색 
SecRule & REQUEST_HEADERS_NAMES "@lt 15" "id : 165"

참고 : 정수로 변환 할 수없는 값 (예 : 문자열)이 제공되면이 연산자는 해당 값을 0으로 처리합니다.

일치하지 않음

설명 : 규칙이 항상 false를 반환하도록합니다.

오후

설명 : 제공된 입력 값에 대해 제공된 구를 대 / 소문자를 구분하지 않고 일치시키는 방식으로 수행합니다. 연산자는 집합 기반 매칭 알고리즘 (Aho-Corasick)을 사용합니다. 즉, 임의의 수의 키워드와 동시에 매칭됩니다. 많은 수의 키워드가 일치해야하는 경우이 연산자는 정규 표현식보다 훨씬 뛰어납니다.

예:

# 사용자 에이전트 식별 정보를보고 의심스러운 클라이언트를 탐지합니다. 
SecRule REQUEST_HEADERS : 사용자 에이전트 "@pm WebZIP WebCopier Webster WebStripper ... SiteSnagger ProWebWalker CheeseBot" "id : 166"

참고 : ModSecurity v2.6.0부터이 연산자는 snort / suricata 콘텐츠 스타일을 지원합니다. 예 : "@pm A | 42 | C | 44 | F".

참고 :이 연산자는 매크로 확장을 지원하지 않습니다 (ModSecurity v2.9.1 기준).

참고 :이 연산자는 "캡처"작업을 지원합니다.

pmf

pmFromFile의 짧은 별칭입니다.

pmFromFile

설명 : 제공된 입력 값에 대해 제공된 구를 대 / 소문자를 구분하지 않고 일치시키는 방식으로 수행합니다. 연산자는 집합 기반 매칭 알고리즘 (Aho-Corasick)을 사용합니다. 즉, 임의의 수의 키워드와 동시에 매칭됩니다. 많은 수의 키워드가 일치해야하는 경우이 연산자는 정규 표현식보다 훨씬 뛰어납니다.

이 연산자는 @pm과 동일하지만 파일 목록을 인수로 사용한다는 점만 다릅니다. 대상 값의 어느 위치에서나 파일에 나열된 구문 중 하나와 일치합니다.

예:

# 키워드를 사용하여 의심스러운 사용자 에이전트를 검색합니다. 
# 파일 / 경로 / to / blacklist1 및 blacklist2 (후자 
#은 설정 파일과 같은 폴더에 위치해야합니다) 
SecRule REQUEST_HEADERS : 사용자 에이전트 "@pmFromFile / path / to / blacklist1 blacklist2" "id : 167"

노트:

1. 파일은 한 줄에 하나의 구를 정확하게 포함해야합니다. 라인 마커 끝 (LF 및 CRLF)은 각 구 및 시작과 끝에서 모두 다듬어 진 공백에서 제거됩니다. 빈 행과 주석 행 (# 문자로 시작하는 행)은 무시됩니다.
2. 룰 세트에 구 (phrase) 파일을보다 쉽게 ​​포함 할 수 있도록, 상대 경로가 구 (phrase) 파일에 사용될 수 있습니다. 이 경우 규칙이 포함 된 파일의 경로가 구문 파일 경로 앞에 추가됩니다.
3. @pm 연산자 구문은 메타 문자를 지원하지 않습니다.
4. 이 연산자는 일치 할 때 경계를 확인하지 않기 때문에 어떤 경우에는 오탐 (false positive)이 발생할 수 있습니다. 예를 들어 IP 주소 일치에 @pm을 사용하려는 경우 1.2.3.4 구는 하나 이상의 IP 주소와 일치 할 수 있습니다 (예 : 1.2.3.40 또는 1.2.3.41과 일치). 가양 성을 피하기 위해 자신의 경계를 문구에 사용할 수 있습니다. 예를 들어 1.2.3.4 대신에 /1.2.3.4/를 사용하십시오. 그런 다음 규칙에 적절한 경우 경계를 추가하십시오. 이 예제에서 완전한 예제를 찾을 수 있습니다.

# 커스텀 REMOTE_ADDR 변수 준비 
SecAction "단계 : 1, id : 168, nolog, pass, setvar : tx.REMOTE_ADDR = / % {REMOTE_ADDR} /"

# REMOTE_ADDR이 블랙리스트에 있는지 확인하십시오. 
SecRule TX : REMOTE_ADDR "@pmFromFile blacklist.txt" "phase : 1, id : 169, deny, msg : '블랙리스트에있는 IP 주소' 

blacklist.txt 파일에는 다음 항목이 포함될 수 있습니다.

# ip-blacklist.txt 내용 :
# 참고 : 모든 IP에는 규칙으로 "/"접두사 / 접미사를 사용해야합니다
#이 문자를 경계로 추가하여
# 전체 IP가 일치합니다.
# SecAction "단계 : 1, id : 170, pass, nolog, setvar : tx.remote_addr = '/ % {REMOTE_ADDR} /'"
/1.2.3.4/ 
/5.6.7.8/

경고 : ModSecurity 2.5.12 이전에는 @pmFromFile 연산자가 LF 행의 끝 부분 만 이해했으며 구에서 공백을 삭제하지 않았습니다. 이전 버전의 ModSecurity를 ​​사용하는 경우에는 phrase 파일을 편집 할 때주의해야합니다. 예를 들어, 패턴에 원하지 않는 문자가 사용되는 것을 피하십시오. 라인 끝 마커는 문구 (LF 및 CRLF)에서 제거되고 문구의 양쪽에서 공백이 제거됩니다. 빈 행과 주석 행 ( '#'으로 시작)은 무시됩니다. 룰셋을 사용하여 구문 파일을보다 쉽게 ​​포함 할 수 있도록 구문 파일에 상대 경로를 사용할 수 있습니다. 이 경우 규칙을 포함하는 파일의 경로가 구문 파일 경로 앞에 추가됩니다.

참고 : ModSecurity v2.6.0부터이 연산자는 snort / suricata 콘텐츠 스타일을 지원합니다. 즉 : "A | 42 | C | 44 | F".

주 II : v2.9.0-RC1에서이 연산자는 HTTPS 서버가 제공하는 컨텐츠를로드하는 것을 지원합니다. 그러나 한 번에 하나의 URL 만 사용할 수 있습니다.

rbl

설명 : 매개 변수로 주어진 RBL (실시간 차단 목록)의 입력 값을 조회합니다. 매개 변수는 IPv4 주소 또는 호스트 이름이 될 수 있습니다.

예:

msg : 'SPAM 소스에 대한 RBL 일치', 태그 : 'AUTOMATION / MALICIOUS', 'AUTOMATION / MALICIOUS', 'AUTOMATION / MALICIOUS' 심각도 : '2', setvar : 'tx.msg = % {rule.msg}', setvar : tx.automation_score = + % {tx.warning_anomaly_score}, setvar : tx.anomaly_score = + % {tx.warning_anomaly_score}
setvar : tx. % {match_var} = % {matched_var}, setvar : ip.spammer = 1, expirevar : ip.spammer = 86400, setvar : ip.previous_rbl_check = 1, expirevar : ip.previous_rbl_check = 86400, skipAfter : END_RBL_CHECK "

참고 : RBL이 dnsbl.httpbl.org (Honeypot Project RBL) 인 경우 SecHttpBlKey 지시문은 사용자의 등록 된 API 키를 지정해야합니다.

참고 : 사용 된 RBL이 multi.uribl.com 또는 zen.spamhaus.org 결합 RBL 인 경우 DNS 응답의 마지막 옥텟에있는 반환 코드를 구문 분석하여 IP가 발견 된 특정 RBL을 식별 할 수도 있습니다.

참고 :이 연산자는 "캡처"작업을 지원합니다.

rsub

설명 : STREAM_INPUT_BODY 또는 STREAM_OUTPUT_BODY 변수에 적용 할 때 정규 표현식 데이터 대체를 수행합니다. 이 연산자는 매크로 확장도 지원합니다. ModSecurity 2.7.0부터이 연산자는 | hex | 사용자가 \ n \ r과 같은 특수 문자를 사용할 수있게합니다.

Syntax: @rsub s/regex/str/[id]

버전 : 2.x

libModSecurity : TBI 에서 지원됨

예 : 응답 본문에서 HTML 주석 제거 :

SecStreamOutBodyInspection 사용
SecRule STREAM_OUTPUT_BODY "@rsub s // /" "단계 : 4, id : 172, t : 없음, nolog, pass"

참고 : STREAM_ 변수와 함께 @rsub를 사용하여 실시간 데이터를 조작하려는 경우 SecContentInjection 지시문도 활성화해야합니다.

정규식은 PCRE 라이브러리 http://www.pcre.org 에서 처리합니다 . ModSecurity는 다음 설정으로 정규 표현식을 컴파일합니다.

1. 개행 문자가있는 경우에도 전체 입력은 단일 행으로 취급됩니다.
2. 모든 일치는 대소 문자를 구분합니다. 대 / 소문자를 구분하지 않고 일치 시키려면 소문자 변환 함수를 사용하거나 정규식 패턴 앞에 (? i) 한정자 (PCRE 기능)를 붙이면 대 / 소문자를 구분하지 않고 일치시킬 수 있습니다. PCRE 문서). 또한 매크로 확장을 사용할 때 정규 표현식 문자열 char를 이스케이프하려면 플래그 [d]를 사용해야합니다.
3. 컴파일하는 동안 PCRE_DOTALL 및 PCRE_DOLLAR_ENDONLY 플래그가 설정됩니다. 즉, 한 점이 개행을 포함하여 모든 문자와 일치하며 $ end 앵커가 후행 개행 문자와 일치하지 않습니다.

정규 표현식은 매우 강력한 도구입니다. PCRE 문서를 읽고 해당 기능을 익히는 것이 좋습니다.

참고 :이 연산자는 "캡처"작업을 지원합니다.

rx

설명 : 매개 변수로 제공된 패턴의 정규 표현식 일치를 수행합니다. 이것은 기본 연산자입니다. 연산자를 명시 적으로 지정하지 않는 규칙은 @rx로 기본 설정됩니다 .

예 :

# Nikto 검색 
SecRule REQUEST_HEADERS : 사용자 에이전트 "@rx nikto"단계 : 1, id : 173, t : 소문자

# Nikto는 대소 문자를 구분하지 않는 패턴으로 탐지합니다. 
SecRule REQUEST_HEADERS : 사용자 에이전트 "@rx (? i) nikto"단계 : 1, id : 174, t : 없음

# Nikto는 대소 문자를 구분하지 않는 패턴으로 탐지합니다. 
SecRule REQUEST_HEADERS : 사용자 에이전트 "(? i) nikto" "id : 175"

정규식은 PCRE 라이브러리 http://www.pcre.org 에서 처리합니다 . ModSecurity는 다음 설정으로 정규 표현식을 컴파일합니다.

1. 개행 문자가있는 경우에도 전체 입력은 단일 행으로 취급됩니다.
2. 모든 일치는 대소 문자를 구분합니다. 대 / 소문자를 구분하지 않고 일치 시키려면 소문자 변환 함수를 사용하거나 정규식 패턴 앞에 (? i) 한정자 (PCRE 기능)를 붙이면 대 / 소문자를 구분하지 않고 일치시킬 수 있습니다. PCRE 문서).
3. 컴파일하는 동안 PCRE_DOTALL 및 PCRE_DOLLAR_ENDONLY 플래그가 설정됩니다. 즉, 한 점이 개행을 포함하여 모든 문자와 일치하며 $ end 앵커가 후행 개행 문자와 일치하지 않습니다.

정규 표현식은 매우 강력한 도구입니다. PCRE 문서를 읽고 해당 기능을 익히는 것이 좋습니다.

참고 :이 연산자는 "캡처"작업을 지원합니다.

스트레치

설명 : 문자열 비교를 수행하고 매개 변수 문자열이 입력 문자열과 동일한 경우 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# "bar"를 # 포함하지 않는 요청 매개 변수 "foo"를 정확하게 탐지합니다. 
SecRule ARGS : foo "! @streq bar" "id : 176"

발목 잡기

설명 : 제공된 단어와 원하는 입력 값의 문자열 일치를 수행합니다. 연산자는 Boyer-Moore-Horspool 알고리즘과 일치하는 패턴을 사용합니다. 이는 단일 패턴 일치 연산자임을 의미합니다. 이 연산자는 정규식보다 훨씬 뛰어납니다.

예:

# 사용자 에이전트 식별 정보를보고 의심스러운 클라이언트를 탐지합니다. 
SecRule REQUEST_HEADERS : 사용자 에이전트 "@strmatch WebZIP" "id : 177"

참고 : ModSecurity v2.6.0부터이 연산자는 snort / suricata 콘텐츠 스타일을 지원합니다. 예 : "@strmatch A | 42 | C | 44 | F".

무조건 일치

설명 : 규칙이 항상 true를 반환하도록합니다. 이것은 SecAction과 비슷하지만 규칙 일치의 결과로 발생하는 모든 작업은 MATCHED_VAR 설정과 같이 실행됩니다. 이것은 또한 사슬 룰의 일부가 될 수 있습니다.

예:

SecRule REMOTE_ADDR "@unconditionalMatch" "id : 1000, 단계 : 1, 전달, nolog, t : hexEncode, setvar : TX.ip_hash = % {MATCHED_VAR}"

validateByteRange

설명 : 입력에 사용 된 바이트 값이 연산자 매개 변수에 지정된 범위에 속하는지 확인합니다. 이 연산자는 지정된 범위가 아닌 바이트가 들어있는 입력 값과 일치합니다.

예:

# 요청 매개 변수에 매우 엄격한 바이트 범위 적용 
# 다른 언어를 사용하지 않는 응용 프로그램에서 작동 함 
#보다 영어). 
SecRule ARGS "@validateByteRange 10, 13, 32-126" "id : 178"

validateByteRange는 합법적 인 용도는 없지만 회피 기술로 자주 사용되는 NUL 바이트의 존재를 감지하는 데 사용될 때 가장 유용합니다.

# NUL 바이트 허용 안 함 
SecRule ARGS "@validateByteRange 1-255" "id : 179"

참고 : 특정 바이트 범위의 바이트로만 요청을 구성 할 수 있습니다. 이는 스택 오버플로 공격을 피하는 데 유용 할 수 있습니다 (일반적으로 "임의"바이너리 컨텐츠가 포함되어 있기 때문에). 기본 범위 값은 0과 255이며, 즉 모든 바이트 값이 허용됩니다. 이 지시문은 여러 부분 / 양식 데이터 인코딩 (파일 업로드)이 사용될 때 POST 페이로드의 바이트 범위를 확인하지 않습니다. 이렇게하면 이진 파일이 업로드되지 않습니다. 그러나 이러한 요청에서 매개 변수가 추출 된 후 유효 범위가 검사됩니다.

validateByteRange는 ModSecurity 1.X SecFilterForceByteRange 지시문과 비슷하지만 규칙 컨텍스트에서 작동하기 때문에 다음과 같은 차이점이 있습니다.

• 다른 변수에 대해 다른 범위를 지정할 수 있습니다.
• 그것에는 "이벤트"컨텍스트 (id, msg ....)가 있습니다.
• 이것은 사전 검사 (pre-check)가 내장 된 것이 아니라 규칙의 흐름에서 실행됩니다.

validateDTD

설명 : 제공된 DTD에 대해 XML DOM 트리의 유효성을 검사합니다. DOM 트리는 XML 요청 본문 프로세서를 사용하여 이전에 작성되어 있어야합니다. 이 연산자는 유효성 검사가 실패하면 일치합니다.

예:

# XML이 포함 된 요청 본문을 파싱합니다. 
SecRule REQUEST_HEADERS : Content-Type ^ text / xml $ "phase : 1, id : 180, nolog, pass, t : 소문자, ctl : requestBodyProcessor = XML"

# DTD에 대해 XML 페이로드 유효성 검사 
SecRule XML "@ validateDTD /path/to/xml.dtd" "phase : 2, id : 181, deny, msg : 'DTD 유효성 검사에 실패했습니다.'"

참고 :SecXmlExternalEntity 지시문을 활성화해야합니다 .

validateHash

설명 : 해시 엔진으로 보호되는 데이터가 포함 된 REQUEST_URI의 유효성을 검사합니다.

버전 : 2.x

libModSecurity : TBI 에서 지원됨

예:

# 요청 된 URI가 정규 표현식과 일치하는지 확인합니다.
SecRule REQUEST_URI "@validatehash"product_info | product_list ""phase : 1, deny, id : 123456 "

validateSchema

설명 : 제공된 XML 스키마에 대해 XML DOM 트리의 유효성을 검사합니다. DOM 트리는 XML 요청 본문 프로세서를 사용하여 이전에 작성되어 있어야합니다. 이 연산자는 유효성 검사가 실패하면 일치합니다.

예:

# XML이 포함 된 요청 본문을 파싱합니다. 
SecRule REQUEST_HEADERS : Content-Type ^ text / xml $ "phase : 1, id : 190, nolog, pass, t : 소문자, ctl : requestBodyProcessor = XML"

# DTD에 대해 XML 페이로드 유효성 검사 
SecRule XML "@ validateSchema /path/to/xml.xsd" "phase : 2, id : 191, deny, msg : 'DTD 유효성 검사에 실패했습니다.'"

참고 :SecXmlExternalEntity 지시문을 활성화해야합니다 .

validateUrlEncoding

설명 : 제공된 입력 문자열에서 URL로 인코딩 된 문자의 유효성을 검사합니다.

예:

# 요청 URI에서 URL 인코딩 문자 검증 
SecRule REQUEST_URI_RAW "@validateUrlEncoding" "id : 192"

ModSecurity는 요청 매개 변수에서 URL 인코딩 문자를 자동으로 디코딩합니다. 즉, 요청 매개 변수 중 일부가 두 번 이상 URL 인코딩 된 경우를 제외하고 @validateUrlEncoding 연산자를 적용하는 것은 거의 의미가 없습니다. 원시 입력 또는 URL 인코딩 된 입력에 대해이 연산자를 사용하십시오. 예를 들어 일부 응용 프로그램은 쿠키를 URL 인코딩합니다 (표준이 아님). ModSecurity는 표준에 있지 않기 때문에 그러한 인코딩을 검증하거나 디코딩하지 않습니다.

validateUtf8Encoding

설명 : 입력이 유효한 UTF-8 문자열인지 확인하십시오.

예:

# 모든 요청 매개 변수가 유효한 UTF-8 만 포함하는지 확인하십시오. 
SecRule ARGS "@ validateUtf8Encoding" "id : 193"

@ validateUtf8Encoding 연산자는 다음 문제를 감지합니다.

충분하지 않은 바이트 : UTF-8은 2, 3, 4, 5 및 6 바이트 인코딩을 지원합니다. ModSecurity는 문자에서 하나 이상의 바이트가 누락 된 경우를 찾습니다.

잘못된 문자 : 대부분의 문자에서 가장 중요한 두 비트는 0x80으로 고정되어야합니다. 일부 공격 기법은 회피 기술과 다른 값을 사용합니다.

긴 문자 : ASCII 문자는 UTF-8로 직접 매핑됩니다. 즉, ASCII 문자는 동시에 한 UTF-8 문자입니다. 그러나 UTF-8에서는 많은 ASCII 문자가 2, 3, 4, 5 및 6 바이트로 인코딩 될 수 있습니다. 새로운 버전의 유니 코드에서는 더 이상 유효하지 않지만 이전의 많은 구현체에서도 여전히이를 지원합니다. 과도한 UTF-8 문자의 사용은 회피에 일반적입니다.

노트 :

• 대부분의 응용 프로그램이 UTF-8을 사용하지만 일부 응용 프로그램은 아닙니다. 응용 프로그램을 다루는 경우 모든 요청 매개 변수가 유효한 UTF-8 문자열임을 확인하면 다양한 UTF-8 약점을 사용하는 여러 가지 회피 기술을 방지 할 수 있습니다. UTF-8을 사용하지 않는 응용 프로그램에서이 연산자를 사용하면 위양성 (false positive)이 발생할 수 있습니다.
• 많은 웹 서버는 요청 URI에서 UTF-8도 허용합니다. 요청한 경우 @ validateUtf8Encoding을 사용하여 요청 URI를 확인할 수 있습니다.

verifyCC

설명 : 입력 된 신용 카드 번호를 감지합니다. 이 연산자는 제공된 정규 표현식을 사용하여 초기 일치를 수행하고, Luhn 알고리즘 계산을 따라 오 탐지 (false positive)를 최소화합니다.

예:

# 매개 변수 및 신용 카드 번호 검색 
# 감사 로그에 기록되지 않도록합니다. 
SecRule ARGS "@verifyCC \ d {13,16}" "단계 : 2, id : 194, nolog, pass, msg : '잠재적 인 신용 카드 번호', sanitiseMatched"

참고 :이 연산자는 "캡처"작업을 지원합니다.

verifyCPF

설명 : 입력 된 CPF 번호 (브라질 소셜 번호)를 감지합니다. 이 연산자는 먼저 제공된 정규 표현식을 사용하여 초기 일치를 수행하고 오탐 (false positive)을 최소화하기 위해 알고리즘 계산을 수행합니다.

예:

# 매개 변수 및 CPF 번호 검색 
# 감사 로그에 기록되지 않도록합니다. 
SecRule ARGS "@verifyCPF /^([0-9]{3}\.){2}[0-9]{3}-[0-9]{2}$/" "phase : 2, id : 195 , nolog, pass, msg : '잠재 CPF 번호', sanitiseMatched '

버전 : 2.6-3.0 (사전)

libModSecurity에서 지원됨 : 예

참고 :이 연산자는 "캡처"작업을 지원합니다.

verifySSN

설명 : 입력 된 미국 사회 보장 번호 (SSN)를 감지합니다. 이 연산자는 제공된 정규 표현식을 사용하여 초기 일치를 수행하고 오탐 (false positive)을 최소화하기 위해 SSN 알고리즘 계산을 수행합니다.

예:

# 사회 보장 번호를 매개 변수 및 
# 감사 로그에 기록되지 않도록합니다. 
SecRule ARGS "@verifySSN \ d {3} -? \ d {2} -? \ d {4}" "단계 : 2, id : 196, nolog, pass, msg : '잠재적 인 사회 보장 번호', sanitiseMatched"

버전 : 2.6-3.0 (사전)

libModSecurity에서 지원됨 : 예

SSN 형식 :

사회 보장 번호는 세 부분으로 나뉩니다 :

• 면적 (3 자리)
• 그룹 (2 자리)
• 일련 번호 (4 자리)

verifySSN 검사 :

• 9 자리 숫자 여야합니다.
• 시퀀스 번호 일 수 없습니다 (즉, 123456789, 012345678).
• 반복 시퀀스 번호 일 수 없습니다 (예 : 11111111, 222222222).
• 영역 및 / 또는 그룹 및 / 또는 연속 된 제로 시퀀스를 가질 수 없습니다.
• 지역 번호는 740보다 작아야합니다.
• 지역 번호는 666과 달라야합니다.

참고 :이 연산자는 "캡처"작업을 지원합니다.

이내에

설명 : 입력 값 (바늘)이 @within 매개 변수 (건초 더미) 내의 모든 위치에서 발견되면 true를 반환합니다. 매크로 확장은 비교하기 전에 매개 변수 문자열에서 수행됩니다.

예:

# GET, POST 및 HEAD 이외의 요청 방법 검색 
SecRule REQUEST_METHOD "! @within GET, POST, HEAD"

참고 :이 연산자에는 구분 기호가 없으므로 일부 경우 인위적으로 지정해야합니다. 이것은 setvar를 사용하여 수행 할 수 있습니다. 예를 들어 아래의 예제에서 부과 된 구분 기호 ( '/')가 없으면 'range'가 제공된 매개 변수 내에 있으므로이 규칙은 'range'헤더 (다른 많은 조합과 함께)에서도 일치합니다. 부과 된 구분 기호로 규칙은 범위 헤더가 제공 될 때 '/ range /'를 확인하므로 '/ range /가 @within 매개 변수의 일부가 아니므로 일치하지 않습니다.

SecRule REQUEST_HEADERS_NAMES "@rx ^.*$" \
"chain,\
id:1,\
block,\
t:lowercase,\
setvar:'tx.header_name=/%{tx.0}/'"
   SecRule TX:header_name "@within /proxy/ /lock-token/ /content-range/ /translate/ /if/" "t:none"

매크로 확장

매크로를 사용하면 런타임에 값으로 확장 될 규칙에서 위치 보유자를 사용할 수 있습니다. 현재 변수 확장 만 지원되지만 ModSecurity의 이후 버전에서는 더 많은 옵션이 추가 될 수 있습니다.

체재:

%{변하기 쉬운}
% {COLLECTION.VARIABLE}

매크로 확장은 initcol, setsid, setuid, setvar, setenv, logdata와 같은 작업에서 사용할 수 있습니다. 런타임에 평가되는 연산자는 위에서 설명한 확장을 지원합니다. 이러한 연산자에는 @beginsWith, @endsWith, @contains, @within 및 @streq가 포함됩니다. @rx와 같은 "컴파일 된"연산자에 대해서는 매크로 확장을 사용할 수 있습니다.하지만 효율성에 어느 정도 영향을 미칩니다.

확장하려는 일부 값에는 TX, REMOTE_ADDR, USERID, HIGHEST_SEVERITY, MATCHED_VAR, MATCHED_VAR_NAME, MULTIPART_STRICT_ERROR, RULE, SESSION, USERID 등이 포함됩니다.

영구 저장 장치

현재 데이터가 지속적으로 저장되는 5 개의 콜렉션 (예 : 여러 요청에 사용 가능한 데이터) 만 가능합니다. GLOBAL, RESOURCE, IP, SESSION 및 USER입니다.

모든 모음에는 다르게 지정되지 않은 한 사용할 수 있고 읽기 전용 인 몇 가지 기본 제공 변수가 들어 있습니다.

1. CREATE_TIME - 콜렉션 생성 날짜 / 시간.
2. IS_NEW - 콜렉션이 새롭다면 (아직 지속되지 않음) 1로 설정되고 그렇지 않으면 0으로 설정됩니다.
3. KEY - initcol 변수의 값 (예제에서 클라이언트의 IP 주소).
4. LAST_UPDATE_TIME - 콜렉션에 대한 최종 갱신 날짜 / 시간.
5. TIMEOUT - 다른 업데이트가 발생하지 않은 경우 메모리에서 디스크의 모음을 업데이트 할 날짜 / 시간 (초)입니다. 명시 적 만료 시간을 지정하려면이 변수를 설정할 수 있습니다 (기본값은 3600 초).
6. UPDATE_COUNTER - 생성 이후에 콜렉션이 갱신 된 회수.
7. UPDATE_RATE - 생성 이후 분당 평균 속도 업데이트입니다.

세션 변수 (SESSION)를 보유 할 콜렉션을 작성하려면 actions setsid를 사용하십시오. 사용자 변수 (USER)를 보유 할 콜렉션을 작성하려면 setuid 조치를 사용하십시오. 클라이언트 주소 변수 (IP), 글로 z 데이터 또는 자원 특정 데이터를 보유 할] 렉션을 작성하려면, 조치 initcol을 사용하십시오.

참고 : 영구 컬렉션은 트랜잭션 당 한 번만 초기화 할 수 있습니다.

참고 : ModSecurity는 현재 정수 변수 (카운터)에 대해서만 영구 변수의 원자 적 업데이트를 구현합니다. 변수는 initcol이 규칙에서 발견 될 때마다 저장소에서 읽히고 요청 처리가 끝날 때까지 지속됩니다. 카운터는 지속되기 직전에 지속 된 데이터를 다시 읽음으로써 생성 된 델타를 적용하여 조정됩니다. 이렇게하면 카운터가 수정되어 트랜잭션 중에 다른 스레드 / 프로세스에 의해 유지되는 경우에도 카운터 데이터가 일관되게 유지됩니다.

참고 : ModSecurity는 영구 저장소에 Berkeley Database (SDBM)를 사용합니다. 이 유형의 데이터베이스는 일반적으로 키당 최대 1008 바이트를 저장하는 것으로 제한됩니다. 단일 키의 변수에 상당량의 데이터를 저장하려고하면이 제한이있을 수 있습니다. 이 제한 중 일부는 향후 ModSecurity 버전에서 축소 될 예정입니다.

기타 주제

mod_log_config를 통한 Apache 로그인

ModSecurity 변수는 Apache의 mod_log_config (-> Apache Access Log)에서 액세스 할 수 있습니다. 항목의 형식은 % {VARIABLE} M입니다. ModSecurity 감사 로그의 레코드가 기록 된 후 Apache는 트랜잭션의 끝에 이러한 로그를 기록합니다. 따라서 감사 로그를 작성한 후에 만 ​​정의 된 로그 변수를 사용할 수 있습니다.

예제 Apache mod_log_config :

LogFormat "% t % {UNIQUE_ID} e % {MULTIPART_STRICT_ERROR} M % {TX.ANOMALY_SCORE} M"사용자 정의 형식

다른 Apache 모듈에 비해 ModSecurity의 우선 순위

ModSecurity 규칙은 다섯 단계 중 하나로 실행됩니다. 첫 번째 두 단계는 요청을 읽을 때 실행되고 세 번째와 네 번째 단계는 응답이 생성 된 후 실행되고 다섯 번째 단계는 응답이 보내지고 로그 파일이 작성됩니다.

다양한 단계가 다른 Apache 모듈과 함께 Apache 요청 수명주기에 연결됩니다. 각 후크에서 하나 이상의 모듈이 실행될 수 있습니다. 우선 순위가 작용하는 곳입니다.

우선 순위는 컴파일시 할당되며 주로 ModSecurity 소스 코드에 하드 코딩됩니다. 컴파일 지시문 --enable-request-early는 ModSecurity 단계 1의 처리를 다른 후크로 옮기는 데 사용할 수 있습니다 (위 참조).

응답을 검토 할 때 ModSecurity는 가능한 한 빨리 시도합니다. 예를 들어, phase 3과 phase 4는 _Header_ 지시어로 mod_headers보다 먼저 실행됩니다. 그러나 _early_ 키워드를 _early_로 호출하면 우선 순위가 높아지며 ModSecurity 단계 3 이전에 지시문이 실행됩니다. 따라서 mod_headers로 HTTP 응답 헤더를 편집하려는 경우 (쿠키에 보안 플래그를 추가하면 마음이 바뀝니다) ModSecurity로 헤더 조작의 효과를 검사하기 전에 보통 ModSecurity 단계 5까지 기다려야합니다.

처리 단계 (위)를 참조하십시오.

권장 기본 구성

기본 ModSecurity 지시어 / 설정을 처리하는 권장 구성 파일은 소스 코드 아카이브에서 사용할 수 있으며 modsecurity.conf 권장으로 레이블이 지정되어 있습니다. git 저장소 에서도 사용할 수 있습니다 . 이 권장 구성에 나열된 항목은 관리자가 자체 사이트를 처리하고 구성해야하는 항목입니다. 이 설정은 타사 규칙 파일에 포함되어서는 안됩니다.

임피던스 불일치

웹 응용 프로그램 방화벽은 응용 프로그램과 비즈니스 논리에 대한 지식이 없어도 통과하는 데이터를 이해하려고 노력하기가 어렵습니다. 그들이 제공하는 보호 기능은 외부에 독립적 인 보안 계층을 가짐으로써 제공됩니다. 데이터 유효성 검사가 두 번 수행되므로 응용 프로그램을 건드리지 않고도 보안을 강화할 수 있습니다. 그러나 어떤 경우에는 모든 것이 두 번 수행된다는 사실 때문에 문제가 발생합니다. 통신 프로토콜이 잘 정의되지 않은 영역이나 장치 또는 응용 프로그램이 사양에없는 작업을 수행하는 영역에서 문제가 발생할 수 있습니다. 그러한 경우 하나의 장치에 의해 해석되고 다른 장치에 의해 해석 될 페이로드를 설계하는 것이 가능할 수있다. 이 문제는 임피던스 불일치로 더 잘 알려져 있습니다. 보안 장치를 회피하기 위해 악용 될 수 있습니다.

우리는 다양한 회피 기술을 다루기 위해 ModSecurity를 ​​지속적으로 개선 할 것이지만 문제는 최소화 될 수 있지만 해결되지는 못합니다. 이렇게 많은 다른 응용 프로그램 백엔드 기회들 중 일부는 항상 완전히 예상치 못한 일을 할 것입니다. 유일한 해결책은 규칙을 작성할 때 백엔드의 기술을 인식하고 규칙을 적용하여 불일치를 제거하는 것입니다. 몇 가지 예는 다음 섹션을 참조하십시오.

PHP 애플리케이션의 임피던스 불일치

1. PHP 애플리케이션을 보호하기위한 규칙을 작성할 때 다음 사실에주의해야합니다.
2. "register_globals"가 "On"으로 설정되면 요청 매개 변수가 자동으로 스크립트 변수로 변환됩니다. 일부 PHP 버전에서는 $ GLOBALS 배열을 덮어 쓸 수도 있습니다.
3. 매개 변수 이름의 시작 부분에있는 공백은 무시됩니다. 특정 명명 된 변수를 대상으로 규칙을 작성하는 경우 매우 위험합니다.
4. 나머지 공백 (매개 변수 이름에서)은 밑줄로 변환됩니다. 변수 이름에 일치하는 닫는 대괄호가 포함되어 있지 않으면 도트와 "["]에도 동일하게 적용됩니다. 즉, 이름에 밑줄이 포함 된 변수를 통해 스크립트를 악용하려는 경우 대신 공백이나 점으로 매개 변수를 보낼 수 있습니다.
5. 쿠키는 요청 매개 변수로 처리 될 수 있습니다.
6. 변수 이름에 대한 설명은 쿠키 이름에도 동일하게 적용됩니다.
7. 요청 및 환경에서 매개 변수를 가져 오는 순서는 EGPCS (환경, GET, POST, 쿠키, 내장 변수)입니다. 이는 POST 매개 변수가 요청 행 (QUERY_STRING)에서 전송 된 매개 변수를 겹쳐 쓰게됨을 의미합니다.
8. "magic_quotes_gpc"가 "On"으로 설정되면 PHP는 백 슬래시를 사용하여 작은 따옴표, 큰 따옴표, 백 슬래시 및 nul 바이트를 이스케이프 처리합니다.
9. "magic_quotes_sybase"가 "On"으로 설정되면 작은 따옴표 만 다른 작은 따옴표를 사용하여 이스케이프됩니다. 이 경우 "magic_quotes_gpc"설정은 관련성이 없어집니다. "magic_quotes_sybase"설정은 "magic_quotes_gpc"동작을 완전히 무시하지만 Sybase 특정 인용이 작동하려면 "magic_quotes_gpc"가 "On"으로 설정되어야합니다.
10. PHP는 자동으로 중첩 배열을 생성합니다. 예를 들어 "p [x] [y] = 1"은 총 세 개의 변수를 생성합니다.