로드 밸런서 뒤에 여러 Apache 2.4 웹 서버가 있고 CDN 프런트 엔드(HTTPS가 종료됨) 뒤에는 백엔드 Apache 로그의 프런트 엔드 헤더에 클라이언트 IP가 표시됩니다. iptables의 문자열 일치(웹 서버 시스템에서)를 사용하여 특정 헤더, 즉 내부에 클라이언트 IP가 있는 헤더만을 기반으로 IP를 차단하는 것이 가능한지 궁금합니다.
우리의 Linux 커널은 최신 버전이며 iptables 커널 모듈은 CONFIG_NETFILTER_XT_MATCH_STRING=m으로 컴파일되었습니다.
나는 문자열 일치가 클라이언트 IP를 포함하는 특정 헤더 이상으로 일치하면 CPU를 많이 사용하고 의도하지 않은 결과를 초래할 수 있다는 것을 읽었습니다. 또는 이를 달성하기 위한 프록시와 같은 더 나은 도구가 있지만 여전히 Apache 및 fall2ban과 함께 iptables의 문자열 일치 기능을 사용하는 다른 사람들의 경험에 대해 더 알고 싶습니다.
이상적으로 Apache는 nginx의 444와 같은 것을 가질 것입니다. IP에 403을 제공할 수 있습니다.헤더의 IP 일치를 기반으로, 그러나 444 연결 끊김은 403에 비해 낮은 수준(더 갑작스럽고 바람직함)과 리소스 집약도가 낮은 것으로 보입니다. 그래도 궁금하네요 - 그렇죠? 444가 403보다 리소스 집약적일까요?
통찰력을 가져 주셔서 감사합니다!
답변1
Fail2ban 및 관련 로직이 백엔드 서버에서 실행 중인 경우 쉬운 해결책은 없습니다.
첫 번째 단계는 Apache를 사용하는 것이라고 생각합니다.mod_remoteip; 그러면 백엔드 서버의 Apache 로그에는 프런트 엔드/로드 밸런서의 IP 주소가 아닌 실제 클라이언트 IP가 포함됩니다.
Apache는 기본적으로 연결
client_ip값으로 사용자 에이전트를 식별하고 연결은remote_host이remote_logname값에서 파생됩니다. 이러한 필드는 다른 로드 가능한 모듈의 인증, 권한 부여, 로깅 및 기타 목적에서 역할을 합니다.mod_remoteip는 요청 기간 동안 프록시 또는 로드 밸런서가 제공한 대로 광고된 사용자 에이전트 IP로 연결의 클라이언트 IP를 재정의합니다. 로드 밸런서는 서버와의 장기간 지속되는 연결 유지를 설정할 수 있으며, 로드 밸런서의 기본 클라이언트 IP 주소가 변경되지 않은 경우에도 각 요청은 올바른 사용자 에이전트 IP를 갖게 됩니다.
그런 다음 Apache 로그 파일에 대해 fall2ban을 쉽게 실행하여 문제가 되는 IP를 식별할 수 있습니다.
그러면 다음이 필요합니다.관습적절한 Fail2ban금지 조치백엔드 서버에서 발행되면 문제가 되는 IP를 차단합니다. 예를 들어 문제가 되는 IP를 차단 목록 등에 추가하는 프런트 엔드 앞의 방화벽에 대한 API 호출이 될 수 있습니다.