약 1 백만 개의 IP 주소를 블랙리스트에 IPtables 또는 null route를 사용합니까?

클라이언트가 1 백만 개 미만의 개별 IP 주소 (서브넷 없음) 집합을 블랙리스트에 추가해야하는 상황을 겪어 왔으며 네트워크 성능이 중요합니다. IPTables 규칙이 경로보다 성능에 미치는 영향은 적다고 추측하지만 추측에 불과합니다.

누구든지 긴 IP 주소 목록을 블랙리스트에 올리는 솔루션으로 IPTables 또는 null 라우팅을 선호한다는 확실한 증거 나 다른 근거가 있습니까? 이 경우 모든 것이 자동화되므로 사용 편의성은 실제로 중요하지 않습니다.

26 년 11 월 11 일 수정

일부 테스트 및 개발 후 이러한 옵션 중 어느 것도 실행 가능한 것으로 보이지 않습니다. 경로 조회와 iptables 모두 규칙 세트를 통해 선형 검색을 수행하고이 많은 규칙을 처리하는 데 너무 오래 걸리는 것 같습니다. 최신 하드웨어에서 iptables 블랙리스트에 1M 항목을 넣으면 서버가 초당 약 12 ​​개의 패킷으로 느려집니다. 따라서 IPTables 및 null 경로가 없습니다.

ipset, 지미 헤드 먼 (Jimmy Hedman)이 추천 한대로 세트에서 65536 개가 넘는 주소를 추적 할 수 없다는 점을 제외하고는 훌륭 할 것입니다.

이 많은 IP를 차단하는 유일한 솔루션은 응용 프로그램 계층에서 인덱스 조회를 수행하는 것입니다. 그렇지 않습니까?

추가 정보 :

이 인스턴스의 사용 사례는 IP 주소의 "알려진 범죄자"목록이 웹 서버의 정적 컨텐츠에 액세스하는 것을 차단합니다. FWIW, Apache를 통한 차단 Deny from은 선형 스캔과 마찬가지로 느리게 진행됩니다.

참고 : 최종 작업 솔루션은 버클리 DB 맵과 함께 apache의 mod_rewrite를 사용하여 블랙리스트에 대한 조회를 수행하는 것이 었습니다. 버클리 DB의 인덱스 특성으로 인해 목록은 O (log N) 성능으로 확장 될 수있었습니다.

iptables를 사용하고 다중 레벨 트리를 작성하여 조회 수를 줄이십시오.

iptables -N rules_0_0_0_0_2
iptables -N rules_64_0_0_0_2
iptables -N rules_128_0_0_0_2
iptables -N rules_192_0_0_0_2
iptables -N rules_0_0_0_0_4
iptables -N rules_16_0_0_0_4

iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/2 -j rules_0_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 64.0.0.0/2 -j rules_64_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 128.0.0.0/4 -j rules_128_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 192.0.0.0/4 -j rules_192_0_0_0_2

iptables -A rules_0_0_0_0_2 -s 0.0.0.0/4 -j rules_0_0_0_0_4
iptables -A rules_0_0_0_0_2 -s 16.0.0.0/4 -j rules_16_0_0_0_4

등등-중첩 수준 추가; 분명히 규칙을 작성하는 자동 방법이 필요하며 하나 이상의 위반자가있는 네트워크에 대해서만 체인을 가져야합니다. 이러한 방식으로 상당히 많이 수행해야하는 조회 수를 줄일 수 있으며 실제로 작동합니다.

이것은 정확히 무엇 ipset을위한 것입니다.

웹 사이트 http://ipset.netfilter.org/에서 :

원한다면

• 여러 IP 주소 또는 포트 번호를 저장하고 한 번에 iptables로 수집과 일치시킵니다.
• 성능 저하없이 IP 주소 또는 포트에 대해 iptables 규칙을 동적으로 업데이트합니다.
• 하나의 단일 iptables 규칙으로 복잡한 IP 주소 및 포트 기반 규칙 세트를 표현하고 IP 세트 속도의 이점

그러면 ipset이 적절한 도구 일 수 있습니다.

netfilter 핵심 팀 멤버 인 Jozsef Kadlecsik (REJECT 목표를 쓴 사람)이 작성했기 때문에 이것이 내가 생각할 수있는 최선의 선택입니다.

최신 커널에도 포함되어 있습니다.

나는 이것을 직접 테스트하지는 않았지만 문제 설명을 들었을 때 나는 즉시 pfOpenBSD에서와 같이 " " 라고 생각했다 .

pf당신이 찾고있는 주소 테이블 의 개념을 가지고 있습니다.

내가 한 매우 객관적인 연구 에 따르면 이것이보다 확장 가능성이 더 큰 것 같습니다 ipset. 런타임 옵션에 대한 PF FAQ의 장에 따르면 튜닝없이 즉시 pf는 총 1,000 개의 테이블을 지원하며 기본적으로 모든 테이블에서 총 200,000 개의 항목을 지원합니다. (시스템에 100MB 미만의 실제 메모리가있는 경우 10 만). 이것은 어떤 종류의 유용한 수준에서 작동하는지 확인하기 위해 이것을 테스트하는 것이 좋습니다.

물론 Linux에서 서버를 실행한다고 가정하므로 OpenBSD 또는 FreeBSD와 같은 pf로 일부 OS를 실행하는 별도의 방화벽 상자가 있어야합니다. 모든 종류의 상태 저장 패킷 필터링을 제거하여 처리량을 향상시킬 수도 있습니다.

FIB_HASH 대신 FIB_TRIE를 사용하여 조사한 적이 있습니다.

FIB_TRIE는 접두사 수에 비해 훨씬 확장 성이 좋아야합니다. (/ 32s null 경로는 여전히 접두사이며 매우 구체적입니다)

커널을 사용하려면 커널을 컴파일해야하지만 도움이됩니다.

FIB_TRIE 노트

후손의 경우 : ipset문서 에 따라 세트의 기본 크기는 65536이며 옵션으로 변경할 수 있습니다.

maxelem이 매개 변수는 모든 해시 유형 세트의 작성 명령에 유효합니다. 기본 65536 세트에 저장할 수있는 최대 요소 수를 정의합니다. 예 :ipset create test hash:ip maxelem 2048.

아직 댓글을 달 수 없기 때문에 여기에 넣었습니다.

앞으로이 문제를 우연히 발견하는 사람을위한 유용한 참고 사항 :

우선, 필요하지 않은 트래픽은 분석하지 마십시오. 예를 들어 TCP 트래픽을 차단하는 경우 SYN 패킷 만 필터링하면 연결 당 한 번만 필터에 도달합니다. -m state원하는 경우 사용할 수 있지만 연결 추적에는 자체 오버 헤드가 있으므로 성능에 문제가있는 경우 피할 수 있습니다.

둘째, iptables에 백만 개의 규칙을 적용하는 데 시간이 오래 걸립니다. 몇 분. 많은 엔티티를 추적해야하는 경우 아마도 netfliter에서 멀리하는 것이 가장 좋습니다. 규칙 세트의 크기가 큰 차이를 만듭니다.

셋째, 목표는 선형 스캔을 피하는 것입니다. 그러나 불행히도 iptables와 iproute2는 본질적으로 선형입니다. 이진 트리 스타일로 규칙을 여러 체인으로 나눌 수 있으므로 상담해야 할 규칙의 수를 제한 할 수 있지만 iptables는 이러한 규모의 문제에 적합하지 않습니다. 그것은 작동 하지만, 귀중한 자원의 낭비입니다.

넷째, 가장 중요한 것은 워크로드를 사용자 공간으로 푸시하는 것은 나쁜 생각이 아닙니다. 이를 통해 고유 한 코드를 작성하거나 문제 세트에 맞게 조정 된 상용 솔루션을 사용할 수 있습니다. 언급 한 바와 같이이 문제에 대한 나의 해결책은 아파치의 mod_rewrite 시스템을 통해 트리거 된 BDB 조회를 사용하는 것이 었습니다. 세션 당 하나의 조회 만 트리거 할 수 있고 유효한 요청이 제출 된 후에 만 ​​추가 이점이 있습니다. 이 경우 성능이 매우 빨랐으며 차단 목록 비용은 거의 무시할 수있었습니다.

-j QUEUE와 함께 대상 을 사용하여 iptables로 유사한 사용자 공간 조작을 수행 할 수 있습니다 libnetfilter_queue. 이 도구는 강력하고 단순하며 문서화가 잘되어 있지 않습니다. 공식 문서의 일부가 아닌 웹에 많은 흥미로운 자료가 흩어져 있기 때문에 가능한 한 많은 자료를 최대한 많이 읽는 것이 좋습니다.