이 메시지는 NAT 코드에 의해 출력되는데 멀티캐스트 패킷이 NAT 테이블을 건들고 있기 때문입니다. 현재 connection tracking은 멀티캐스트 패킷을 제대로 처리하고 있지 않습니다. 멀티캐스트가 무엇인지 모르겠거나 그것이 전혀 필요하지 않다면 다음과 같이 하세요:
iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8
syslog와 콘솔에 다음과같은 메시지가 출력됩니다:
NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
NAT 코드에 의해 출력되는 것으로 NAT가 유효한 connection tracking 정보를 갖기위해 패킷을 드롭하는 것입니다. 이 메시지는 connection tracking이 conntrack 정보를 결정할 수 없는 모든 패킷에 대해서 출력됩니다.
가능한 이유로는:
이 패킷에 대한 좀더 구체적인 로그를 얻고 싶다면 (스캐닝 패킷이나 외부에서의 어떤 공격 시도로 의심이 되면) 다음과 같은 룰을 사용하십쇼:
iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
패킷이 필터 테이블에 도착하기 전에 NAT 코드에 의해 드롭되기 때문에 이 룰은 mangle 테이블에 넣어야 합니다.
완벽한 transparent 방화벽을 구축할 계획이신가요? 좋은 생각입니다. 커널 2.4.16과 그리고 부가적인 패치는 다음 사이트에서 찾을 수 있습니다. http://bridge.sourceforge.net/.
글쎄요. 이것은 절반만 사실입니다. 오직 NAT 모듈만이 그들을 처리할 수 없습니다. NAT 없이 방화벽을 구현하고 있다면 반드시 잘 작동해야 합니다.
netfilter는 가능한한 적게 패킷을 조작합니다. 그래서 만약 freshly-rebooted가 가능한 머신과 그리고 누군가 SNAT 박스 안쪽에서 로컬 포트 1234를 열고 있다면 netfilter 박스는 오직 같은 상태로 머물러 있는 ip 주소와 포트만을 조작합니다.
누군가 같은 source 포트로 또 다른 접속을 하면 그것이 SNAT에게 있어 단일 IP라면 netfilter는 IP와 포트를 조작할 것입니다.
But if there are more than one available, it again only has to mangle the IP part. 하지만 2개 이상이라면 ip 부분을 다시 조작해야 합니다.
syslog에서 다음과 같은 메시지를 봤다면 이는 conntrack 데이터베이스가 여러분의 환경에 충분하지 않은 엔트리를 가진것을 의미합니다. 디폴트로 connection tracking 은 정해진 동시 접속 수까지만 처리합니다. 이 수는 여러분의 최대 메모리 크기에 의존적입니다(64MB: 4096, 128MB: 8192,...).
최대값은 쉽게 증가시킬 수 있지만 각각의 tracking 되는 접속은 약 350 바이트의 non-swappable 커널 메모리를 점유함을 유의해야 합니다.
최대값을 8192로 증가하기 예제
echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max
proc 화일 시스템에 보면 /proc/net/ip_conntrack라는 화일이 있습니다.
이 화일을 다음과 같이 출력해서 보면 됩니다.
cat /proc/net/ip_conntrack
모든 사용가능한 IP 테이블은 다음과 같이 출력할 수 있습니다.
cat /proc/net/ip_tables_names
이미 알려진 버그로써 최신 cvs로 업데이트를 하거나 iptables >=1.2.1 을 사용하면 됩니다.
이것은 iptables이 각각의 ip 주소에 대한 DNS lookup을 하기 때문입니다. 각각의 룰은 2개의 주소를 가지고 있고 최악의 경우 각각의 룰마다 DNS lookup을 두번하게 되는 경우가 있습니다.
문제는 사설 ip 주소를 사용하는 경우인데(10.x.x.x 혹은 192.168.x.x), DNS는 호스트이름을 찾을 수 없고 타임 아웃이 걸리게 됩니다. 이 타임아웃 시간을 모두 합하면 매우 긴 시간이 될 것입니다.
이렇듯 DNS lookup 하는 것을 방지하려면 -n (numeric) 옵션을 사용하시면 됩니다.
syslogd를 적절히 설정해 줘야합니다. LOG target은 우선순위 warning(4)로써 로그를 남기는 장치입니다. 이런 장치와 우선순위에 대해서 좀더 공부하고 싶으면 syslogd.conf 맨 페이지를 참고하시기 바랍니다.
디폴트로 debug(7) 우선순위보다 높은 모든 커널 메시지는 콘솔에 보내지도록 되어 있습니다. 이것을 7대신 4로 증가시킨다면 더이상 LOG 메시지가 콘솔상에 나타나지 않을것입니다.
이렇게 하면 콘솔상에 나타나야할 다른 중요한 메시지도 또한 나타나지 않는 점을 유의하셔야 합니다.
먼저 적합한 DNAT 혹은 REDIRECT 룰이 필요합니다. 만약 squid가 NAT 박스 상에서 동작한다면 REDIRECT를 사용하세요. 예를들면:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128
그리고 나서 squid를 적절하게 설정해야 합니다. 우리는 여기에서 짧은 예만을 보여줄 것이므로 좀더 자세한 사항에 대해서는 squid 문서를 참조하시기 바랍니다.
squid 2.3용 squid.conf는 다음의 사항들이 필요할 것입니다.
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
httpd_accel_single_host off
LOG target는 "non-terminating target"을 말합니다. 즉 이것은 패킷 룰 트래버스( traverse)를 끝내지 않습니다. LOG target을 사용하면 패킷은 로깅되고 룰의 순회는 다음룰까지 계속됩니다.
그럼 어떻게 동시에 로깅과 드롭이 될까요? 가장 쉬운 방법으로 다음 2개의 룰을 포함하는 사용자 체인을 생성하는 것이 있습니다.
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
"-j logdrop". 자 이제 패킷에 대한 로깅과 드롭을 원할 때면 언제든지 "-j logdrop"을 하면 됩니다.
patch-o-matic에 있는 tcp-window-tracking 패치를 사용했군요. 이 코드는 패킷의 seq/ack 번호, 세그먼트 크기 등등등에 의해 수용가능한 TCP 패킷을 기록하고 있습니다. 이것은 수용가능하지 않은 패킷을 탐지했을 때(out of the window) 그 패킷을 INVALID로 표시하고 위와 같은 메시지를 출력하게 됩니다.
새 버전에서는 그 패킷과 정확히 어떤 상태에서 fail이 발생했는지 로그를 남깁니다.
sysctl 또한 새버전에서는 sysctl을 통해서 로그를 철저히 감출수도 있습니다.
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window