ModSecurity-nginx 커넥터는 nginx와 libmodsecurity(ModSecurity v3) 사이의 연결 지점입니다. 다르게 말하면 이 프로젝트는 nginx와 libmodsecurity 간의 통신 채널을 제공합니다. 이 커넥터는 nginx와 함께 LibModSecurity를 사용하는 데 필요합니다.
ModSecurity-nginx 커넥터는 nginx 모듈 형식을 취합니다. 이 모듈은 단순히 nginx와 ModSecurity 간의 통신 계층 역할을 합니다.
이 프로젝트는 ModSecurity(버전 2.9 이하)가 아닌 libmodsecurity에 의존합니다.
이전 버전은 ModSecurity를 nginx에 연결하기 위한 Apache 내부용 래퍼인 ModSecurity 독립 실행형을 사용합니다. 이 현재 버전은 nginx에 더 가깝고 더 이상 Apache에 의존하지 않는 새로운 libmodsecurity를 사용합니다. 결과적으로 이 현재 버전은 종속성이 적고 버그가 적으며 속도가 더 빠릅니다. 또한 디렉터리/위치별 사용자 정의(예: SecRuleRemoveById)와 함께 전역 규칙 구성을 사용할 수 있는 가능성과 같은 몇 가지 새로운 기능도 제공됩니다.
이 소프트웨어를 컴파일하기 전에 libmodsecurity가 설치되어 있는지 확인하십시오. ModSecurity git 저장소에서 다운로드할 수 있습니다. libmodsecurity의 컴파일 및 설치에 관한 정보는 함께 제공되는 문서를 참조하십시오.
libmodsecurity가 설치되면 nginx 타사 모듈 설치 절차에 따라 ModSecurity-nginx 커넥터 설치를 진행할 수 있습니다. nginx 소스 디렉터리에서:
./configure --add-module=/path/to/ModSecurity-nginx
또는 동적 모듈을 빌드하려면 다음을 수행하세요.
./configure --add-dynamic-module=/path/to/ModSecurity-nginx --with-compat
동적 모듈을 빌드할 때 nginx 소스 버전은 이를 컴파일하는 nginx 버전과 일치해야 합니다.
nginx 타사 추가 기능 지원에 대한 자세한 내용은 http://wiki.nginx.org/3rdPartyModules에서 확인할 수 있습니다.
nginx용 ModSecurity는 nginx 구성 지시문을 확장합니다. 4개의 새로운 지시문이 추가되었으며 그 내용은 다음과 같습니다.
구문: modsecurity on | 끄다
컨텍스트: http, 서버, 위치
기본값: 꺼짐
ModSecurity 기능을 켜거나 끕니다. 이 구성 지시문은 더 이상 SecRule 상태와 관련이 없습니다. 대신, 이제 모듈을 활성화하거나 비활성화하는 nginx 플래그로만 사용됩니다.
구문: modsecurity_rules_file <규칙 파일 경로>
컨텍스트: http, 서버, 위치
기본값: 아니요
modsecurity 구성 파일의 위치를 지정합니다. 예:
server {
modsecurity on;
location / {
root /var/www/html;
modsecurity_rules_file /etc/my_modsecurity_rules.conf;
}
}
구문: modsecurity_rules_remote <키> <규칙 URL>
컨텍스트: http, 서버, 위치
기본값: 아니요
인터넷에서 modsecurity 구성 파일을 다운로드할 위치를 지정합니다. 또한 해당 서버에 인증하는 데 사용할 키를 지정합니다.
server {
modsecurity on;
location / {
root /var/www/html;
modsecurity_rules_remote my-server-key https://my-own-server/rules/download;
}
}
구문: modsecurity_rules
컨텍스트: http, 서버, 위치
기본값: 아니요
ModSecurity 규칙을 nginx 구성에 직접 포함할 수 있습니다. 다음 예에서는 파일에서 규칙을 로드하고 디렉터리/별칭별로 특정 구성을 삽입합니다.
server {
modsecurity on;
location / {
root /var/www/html;
modsecurity_rules_file /etc/my_modsecurity_rules.conf;
}
location /ops {
root /var/www/html/opts;
modsecurity_rules '
SecRuleEngine On
SecDebugLog /tmp/modsec_debug.log
SecDebugLogLevel 9
SecRuleRemoveById 10
' ;
}
}
구문: modsecurity_transaction_id 문자열
컨텍스트: http, 서버, 위치
기본값: 아니요
라이브러리에서 트랜잭션 ID를 생성하는 대신 nginx에서 트랜잭션 ID를 전달할 수 있습니다. 이는 추적 목적에 유용할 수 있습니다. 예를 들어 다음 구성을 고려하십시오.
log_format extended ' $remote_addr - $remote_user [ $time_local ] '
'" $request " $status $body_bytes_sent '
'" $http_referer " " $http_user_agent " $request_id ' ;
server {
server_name host1;
modsecurity on;
modsecurity_transaction_id "host1- $request_id " ;
access_log logs/host1-access.log extended;
error_log logs/host1-error.log;
location / {
...
}
}
server {
server_name host2;
modsecurity on;
modsecurity_transaction_id "host2- $request_id " ;
access_log logs/host2-access.log extended;
error_log logs/host2-error.log;
location / {
...
}
}
log_format과 modsecurity_transaction_id의 조합을 사용하면 동일한 고유 식별자를 사용하여 액세스 로그와 오류 로그 항목 간의 상관 관계를 찾을 수 있습니다.
문자열에는 변수가 포함될 수 있습니다.
오픈 소스 프로젝트로서 우리는 커뮤니티의 모든 사람이 우리 프로젝트에 기여하도록 초대하고 장려합니다. 이는 새로운 기능, 버그 수정, 버그 보고서, 초보자 사용자 지원 및 귀하가 기꺼이 도와줄 수 있는 모든 형태를 취할 수 있습니다. 감사합니다.
우리는 검토 작업과 QA 통합을 용이하게 하기 위해 GitHub 인프라 내에 패치를 두는 것을 선호합니다. GitHub는 "Pull Request"를 수행하는 방법에 대한 훌륭한 문서를 제공합니다. 자세한 내용은 여기에서 확인할 수 있습니다: https://help.github.com/articles/using-pull-requests/
사용 중인 코딩 스타일을 존중하십시오. 풀 요청에는 다양한 커밋이 포함될 수 있으므로 커밋당 하나의 수정 사항이나 하나의 기능을 제공하세요. 대상 작업 범위를 벗어난 어떤 것도 변경하지 마십시오(예: 전달한 함수의 코딩 스타일).
코드에는 주의가 필요할 수 있는 TODO 또는 FIXME로 표시된 다양한 항목이 있습니다. grep을 수행하여 항목 목록을 확인합니다.
$ cd /path/to/modsecurity-nginx
$ egrep -Rin "TODO|FIXME" -R *
또한 최근 버그 보고서와 미해결 문제를 살펴보고 우리가 어떤 도움을 찾고 있는지 알아볼 수도 있습니다.
수동 테스트와 함께 nginx 테스트 유틸리티를 사용하여 패치가 nginx의 동작이나 성능에 부정적인 영향을 미치지 않는지 확인하는 것이 좋습니다.
nginx 테스트는 http://hg.nginx.org/nginx-tests/에서 사용할 수 있습니다.
해당 테스트를 사용하려면 Perl 유틸리티 증명(Perl 5의 일부)이 있는지 확인하고 다음 명령을 진행하십시오.
$ cp /path/to/ModSecurity-nginx/tests/* /path/to/nginx/test/repository
$ cd /path/to/nginx/test/repository
$ TEST_NGINX_BINARY=/path/to/your/nginx prove .
모든 nginx 테스트를 통과하기 위해 추가된 기능을 얻는 데 문제가 있는 경우 언제든지 당사에 문의하거나 nginx 메일링 리스트(http://nginx.org/en/support.html)에 문의하세요.
우리는 nginx 디버깅 스키마를 존중합니다. nginx 구성 중에 "--with-debug" 구성 옵션을 사용하면 커넥터의 디버그 메시지도 활성화됩니다. 코어 덤프 및 충돌은 nginx를 디버깅하는 데 사용되는 것과 동일한 방식으로 디버깅될 것으로 예상됩니다. 자세한 내용은 nginx 디버깅 정보를 확인하세요: http://wiki.nginx.org/Debugging
구성 문제가 있거나 예상대로 작동하지 않는 경우 ModSecurity 사용자의 메일링 리스트를 사용하세요. GitHub의 문제도 환영하지만 전체 커뮤니티에 접근할 수 있는 메일링 리스트에 사용자가 먼저 질문하는 것을 선호합니다. 또한 새 문제를 열기 전에 기존 문제를 찾는 것을 잊지 마세요.
마지막으로, GitHub에서 이슈를 공개할 계획이라면 libmodsecurity 버전과 실행 중인 nginx 커넥터 버전을 알려주시기 바랍니다.
보안 문제를 공개적으로 보고하지 마십시오. 대신 [email protected]로 연락해 문제를 보고해 주세요. 문제가 해결되면 발견에 대한 크레딧을 제공해드립니다.
우리는 새로운 기능에 대해 갖고 있는 아이디어에 대해 논의하고 싶습니다. 이는 커뮤니티 중심 프로젝트이므로 먼저 피드백을 받으려면 메일링 리스트를 통해 커뮤니티에 연락하세요. 또는 새로운 기능을 요청하는 GitHub 문제를 자유롭게 열어보세요. 새 이슈를 열기 전에 원하는 기능에 대한 기존 기능 요청이 있는지 확인하세요.
제 시간에 패키지를 배포판에 포함시키는 것은 우리가 매우 원하는 것입니다. 패키저로서 귀하의 작업을 용이하게 하기 위해 우리가 할 수 있는 일이 있다면 알려주십시오.