netfilterParece permitir que el tráfico rechazado de mi INPUTcadena pase por mi OUTPUTcadena. Estas son las reglas de la INPUTcadena que se aplican a los paquetes en cuestión:
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
La cadena definida por el usuario REJECT-PKTy su regla relevante:
REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp reject-with tcp-reset
Aquí está el resultado registrado:
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
La segunda línea se produce mediante la siguiente (penúltima) regla de la OUTPUTtabla:
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "OCATCH:"
Tenía la impresión de que los paquetes rechazados estaban de alguna manera marcados por el kernel y que el firewall no procesaba el tráfico TCP con una RSTbandera que resultaba de las reglas.iptables
¿Qué he entendido mal?
Respuesta1
Como dijo @Aaron, esto es normal.
Cuando el paquete entrante alcance REJECT la regla, Netfilter lo procesará y responderá al remitente con RSTel paquete y el mensaje.
Sin embargo, si lo configura DROPen su lugar, la fuente no recibirá ningún mensaje.
Mira este enlace: Diferencia entre SOLTAR Y RECHAZAR
Vale la pena ejecutarlo tcpdumpo wiresharkcapturar el resultado y ver qué sucede debajo del centro.