
netfilter
INPUT
내 체인에서 거부된 트래픽이 내 체인을 통과하도록 허용하는 것 같습니다 OUTPUT
. INPUT
문제의 패킷에 적용되는 체인 의 규칙은 다음과 같습니다 .
LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "ICATCH:"
REJECT-PKT all -- * * 0.0.0.0/0 0.0.0.0/0
사용자 정의 REJECT-PKT
체인 및 관련 규칙:
REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp reject-with tcp-reset
기록된 결과는 다음과 같습니다.
May 15 06:41:51 li51-144 kernel: ICATCH:IN=eth0 OUT= MAC=f2:3c:91:1f:61:44:84:78:ac:0d:97:c1:08:00 SRC=188.138.135.9 DST=<my IP> LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=46841 PROTO=TCP SPT=8838 DPT=23 WINDOW=22014 RES=0x00 SYN URGP=0
May 15 06:41:51 li51-144 kernel: OCATCH:IN= OUT=eth0 SRC=<my IP> DST=188.138.135.9 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=23 DPT=8838 WINDOW=0 RES=0x00 ACK RST URGP=0
두 번째 줄은 표의 다음(두 번째) 규칙에 따라 생성됩니다 OUTPUT
.
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "OCATCH:"
RST
나는 거부된 패킷이 어떻게든 커널에 의해 표시되고 규칙 에 따른 플래그 가 있는 TCP 트래픽이 iptables
방화벽에 의해 처리되지 않는다는 인상을 받았습니다 .
내가 무엇을 잘못 이해했나요?
답변1
@Aaron이 말했듯이 이것은 정상입니다.
들어오는 패킷이 REJECT
규칙에 도달하면 netfilter에 의해 처리되고 RST
패킷과 메시지로 보낸 사람에게 응답합니다.
그러나 대신에 설정하면 DROP
소스는 메시지를 수신하지 않습니다.
이 링크를 확인하세요: 삭제와 거부의 차이점
실행 tcpdump
하거나 wireshark
출력을 캡처하고 허브 아래에서 진행되는 작업을 확인할 가치가 있습니다.