netfilter / iptables : raw 테이블을 사용하지 않는 이유는 무엇입니까?


22

Linux에서는 일반적으로 "filter"테이블을 사용하여 일반적인 필터링을 수행합니다.

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

아래의 넷 필터 순서도에 따르면 패킷은 먼저 "원시"테이블을 통과합니다.

여기에 이미지 설명을 입력하십시오

그래서 우리는 쓸 수 있습니다 :

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT
  • conntrack + mangle + nat + routing을 거치지 않아도 패킷을 더 빨리 처리 할 수 ​​있습니다. 따라서 사용되는 CPU / 메모리가 약간 줄어 듭니다 (그리고 iptable_raw 모듈을로드해야한다는 사실에 의해 약간 보상됩니다)
  • 상자가 라우터이기도 한 경우 규칙 하나만 적용 (필터 / 전달에 동일한 규칙을 추가 할 필요가 없기 때문에 모든 규칙에 대해 괜찮지는 않습니다)

나는 빠른 테스트 만했는데 이것은 완벽하게 작동합니다.
내가 찾은 문서는 항상 엄격한 경우에 사용되는 원시 테이블을 설명합니다. 그러나 가장 작은 정당화조차 제공하지 않습니다.

질문 : 독단적 인 테이블을 제외하고 원시 테이블을 사용하지 않는 이유가 있습니까?


특정 IP 주소에서 모든 트래픽을 삭제하려면 원시 테이블에 문제가 없습니다. 그러나 방화벽은 종종 그보다 약간 세분화되므로 일부 규칙은 기본 규칙으로, 일부 규칙은 필터로 끝납니다. 이로 인해 유지 관리가 어려워지고 몇 번의 CPU 사이클 가치가 있습니다.
wurtel

1
두통 문제 일 경우 원시 테이블에 대해 말하는 몇 가지 예를 찾아야한다고 생각합니다. 그렇지 않은 경우, 두통 이론은 아마도 주요 요인이 아닐 수 있습니다.
Gregory MOUSSAT

1
ipset의 저자는 ipset iptables 규칙에 대한 원시 테이블 사용을 권장합니다. ipset.netfilter.org/tips.html
Stuart Cardall

답변:


17

에서 남자의 iptables :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

분석 :

따라서 RAW 테이블은 conntrack 이전이며 netfilter에서 추적하지 않으려는 패킷에 NOTRACK 표시를 설정하는 데 사용되도록 목적으로 설계되었습니다.

-j 대상은 NOTRACK에만 제한되지 않으므로 CPU / 메모리 소비를 줄이려면 원시 테이블의 패킷을 필터링하십시오.

대부분의 경우 서버는 모든 연결을 추적 할 필요가 없습니다. 이전에 설정된 연결을 기반으로 iptables에서 패킷을 필터링해야하는 경우 추적 만 필요합니다. 포트 80 (아마 21) 만 열려있는 것처럼 단순한 용도로만 사용되는 서버에서는 필요하지 않습니다. 이러한 경우 연결 추적을 비활성화 할 수 있습니다.

그러나 NAT 라우터를 실행하려고하면 약간 복잡해집니다. 무언가를 NAT로 만들려면 외부 네트워크에서 내부 네트워크로 패킷을 전달할 수 있도록 해당 연결을 추적해야합니다.

NOTRACK으로 전체 연결을 설정하면 관련 연결을 추적 할 수 없으며 conntrack 및 nat 도우미는 추적되지 않은 연결에 대해 작동하지 않으며 관련 ICMP 오류도 수행하지 않습니다. 다시 말해 수동으로 이들을 열어야합니다. FTP 및 SCTP 등과 같은 복잡한 프로토콜과 관련하여 관리하기가 매우 어려울 수 있습니다.

사용 사례 :

한 가지 예는 트래픽이 많이 발생하는 라우터가 있고 들어오는 트래픽과 나가는 트래픽을 방화벽으로 만들고 싶지만 라우팅 된 트래픽이 아닌 경우입니다. 그런 다음 처리 된 전력을 절약하기 위해 전달 된 트래픽을 무시하도록 NOTRACK 표시를 설정할 수 있습니다.

NOTRACK을 사용할 수있는 또 다른 예는 트래픽이 많은 웹 서버가있는 경우 로컬에서 소유 한 모든 IP 주소 또는 실제로 웹 트래픽을 제공하는 IP 주소에서 포트 80을 추적하는 규칙을 설정할 수 있습니다. 그러면 이미 오버로드 된 시스템에서 일부 처리 성능을 절약 할 수있는 웹 트래픽을 제외하고 다른 모든 서비스에서 상태 저장 추적을 즐길 수 있습니다.

예-> semi-stateless-linux-router-for-private-network 실행

결론 : 원시 테이블을 사용하지 않는 강력한 이유는 없지만 원시 테이블에서 NOTRACK 대상을 사용할 때주의해야 할 몇 가지 이유가 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.