Skip to content

v1.62.0: icmp-type-255-matches-any — IPv4 iptables reads ICMP type 255 as "any" - #91

Merged
DannyRuizB merged 1 commit into
mainfrom
icmp-type-255-any
Nov 11, 2026
Merged

DannyRuizB merged 1 commit into
mainfrom
icmp-type-255-any

Conversation

@DannyRuizB

Copy link
Copy Markdown
Owner

Qué

Smell nuevo icmp-type-255-matches-any (warning). En IPv4, el match icmp del kernel deja pasar un paquete si el tipo de la regla es 0xFF o si tipo y código coinciden: --icmp-type 255 casa todo el ICMP, lleve el código que lleve, y ! --icmp-type 255 no casa ninguno.

Medido (iptables 1.8.11, nf_tables y legacy, 3 pings reales por INPUT)

Regla Paquetes casados (de 6)
--icmp-type 8 / 0 3 / 3
--icmp-type 255, 255/0, 255/255 6
! --icmp-type 255 (se guarda como ! --icmp-type any) 0
ip6tables --icmpv6-type 255 0 (literal)
nft icmp type 255 0 (literal)

iptables-save imprime un 255 suelto como any, pero mantiene 255/0 tal cual: un volcado no lo delata. Por encima de 255 no carga (rc 2 / nft rc 1), y eso ya lo cubre icmp-type-unknown.

También corrige los análisis ICMP del propio linter

Leían el 255 como un tipo literal:

  • -p icmp --icmp-type 255 -j DROP ahora da icmp-pmtud-blocked (se traga fragmentation-needed); antes, nada.
  • ! --icmp-type any -j DROP ya no lo da: no tira ningún ICMP. Antes era una falsa alarma.
  • Un ACCEPT con --icmp-type any o 255 cuenta como responder al ping en unlimited-icmp-echo, igual que un -p icmp a secas.
  • Corregido el comentario de icmp-type-unknown que llamaba al 255 «un tipo sin nombre».

Muestra

samples/iptables-icmp-255.txt (botón ICMP type 255): un bloque de «tirar ICMP raros» con --icmp-type 255/0 -j DROP. Con pings desde otro netns (por un veth, porque -i lo acepta antes): 0 de 3 contestados en los dos backends; sin esa línea, 3 de 3. Tiene un ESTABLISHED,RELATED delante, así que lo que se pierde es el ping, no el PMTUD de las conexiones ya establecidas (así lo explica su comentario).

Verificación

  • Tests 382 → 388, lint limpio. Contra el linter.js de main fallan 7: 4 de los 5 nuevos (el de «ip6tables/nft lo leen literal» pasa también en main), la muestra y los dos guardianes.
  • README: 76 smells (guardián lista = ids), entrada v1.62.0.

🤖 Generated with Claude Code

…5 as "any"

The kernel's IPv4 icmp match passes a packet when the rule's type is 0xFF
or type and code agree, so `--icmp-type 255` matches EVERY ICMP packet,
whatever code follows it, and `! --icmp-type 255` matches none. Measured
(iptables 1.8.11, nf_tables and legacy, 3 real pings through INPUT):
`--icmp-type 8` and `0` matched 3 of 6 packets; 255, 255/0 and 255/255
matched 6 of 6; the negated form 0. iptables-save prints a bare 255 back
as `any` but keeps `255/0` as written. ip6tables (--icmpv6-type 255: 0 of
6) and nft (icmp type 255: 0) read it literally - IPv4 iptables only.

The linter's own ICMP analyses read 255 as one literal type: a
`--icmp-type 255 -j DROP` now raises icmp-pmtud-blocked (before: nothing),
`! --icmp-type any -j DROP` no longer does (before: a false alarm for a rule
that drops no ICMP), and an `any`/255 ACCEPT counts as answering ping for
unlimited-icmp-echo. The icmp-type-unknown comment that called 255 "a type
with no name" is corrected.

Sample iptables-icmp-255.txt (a "drop the oddballs" block with 255/0):
0 of 3 pings from another netns answered in both backends; without that
line, 3 of 3. Tests 382 -> 388; against main's linter.js 7 fail.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@DannyRuizB
DannyRuizB merged commit 1236f5a into main Nov 11, 2026
1 check passed
@DannyRuizB
DannyRuizB deleted the icmp-type-255-any branch November 11, 2026 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant