"iptables"가 패킷을 유효하지 않은 것으로 간주하는 이유를 이해하는 방법은 무엇입니까?

"iptables"가 패킷을 유효하지 않은 것으로 간주하는 이유를 이해하는 방법은 무엇입니까?

잘못된(잘못된 ) 패킷이 기록되고 삭제 iptables되도록 몇 가지 규칙을 설정했습니다 . --state INVALID패킷이 유효하지 않은 것으로 간주된 이유를 이해하기 위해 로그를 어떻게 읽을 수 있습니까? 예를 들어 다음과 같습니다.

11월 29일 22:59:13 htpc 라우터 커널: [6550193.790402] ::IPT::DROP:: IN=ppp0 OUT= MAC= SRC=31.13.72.7 DST=136.169.151.82 LEN=40 TOS=0x00 PREC=0x00 TTL =242 ID=5104 DF PROTO=TCP SPT=80 DPT=61597 WINDOW=0 RES=0x00 ACK RST URGP=0

답변1

상태 저장 패킷 검사를 사용할 때 패킷의 상태는 다양할 수 있습니다.

  • 새로운: 패킷이 알려진 스트림이나 소켓에 속하지 않으며 TCP 플래그의 SYN 비트가 켜져 있습니다.
  • 확립된: 패킷이 추적된 스트림 또는 소켓과 일치 CONNTRACK하며 TCP 플래그가 있습니다. 초기 TCP 핸드셰이크가 완료된 후 패킷이 설정된 상태가 되려면 SYN 비트가 꺼져 있어야 합니다.
  • 관련된: 패킷이 알려진 스트림이나 소켓과 일치하지 않지만 이를 예측할 기존 소켓이 있기 때문에 패킷이 예상됩니다(예: 포트 21에 기존 FTP 세션이 있고 포트 20에 UDP 데이터가 있는 경우). TCP 포트 5060의 기존 SIP 연결). 이를 위해서는 연관된 ALG가 필요합니다.
  • 유효하지 않은: 이전 상태 중 어느 것도 적용되지 않으면 패킷은 상태에 있습니다 INVALID. 이는 다양한 유형의 보이지 않는 네트워크 프로브로 인해 발생하거나 항목이 부족함을 의미할 수 있습니다 CONNTRACK(로그에도 이러한 항목이 표시되어야 함). 아니면 완전히 양성일 수도 있습니다.

귀하의 경우, 참조하는 패킷은 TCP 플래그를 표시 ACK하고 RST소스 포트는 입니다 80. 이는 웹 서버 31.13.72.7(Facebook)가 재설정 패킷을 보냈음을 의미합니다. 이전 패킷(있는 경우)을 보지 않고는 이유를 아는 것이 완전히 불가능합니다. 그러나 컴퓨터가 재설정이 유효하지 않다고 생각하는 것과 같은 이유로 재설정을 보낼 가능성이 높습니다.

관련 정보