El bit maligno es un campo ficticio de encabezado de paquete IPv4 propuesto en una humorística RFC del Día de los Inocentes de 2003, [1] escrita por Steve Bellovin . La Solicitud de comentarios recomendaba que el último bit sin usar, el "Bit reservado" [2] en el encabezado de paquete IPv4 , se utilizara para indicar si un paquete se había enviado con intenciones maliciosas, lo que hace que la ingeniería de seguridad informática sea un problema fácil: simplemente ignore cualquier mensaje que tenga el bit maligno activado y confíe en el resto.
Una investigación de 2015 realizada por el ingeniero de redes Ben Cartwright-Cox reveló que varios sitios web populares (436 sitios web de Alexa 20k en ese momento), como los que pertenecen a varias universidades y bancos, al proveedor de antivirus Kaspersky y al proveedor de software de escritorio remoto Teamviewer respetan la "parte malvada" al descartar la solicitud entrante, lo que los hace compatibles con RFC 3514. [3]
El bit maligno se ha convertido en sinónimo de todos los intentos de buscar soluciones técnicas simples a problemas sociales humanos difíciles que requieren la participación voluntaria de actores maliciosos, en particular los esfuerzos por implementar la censura de Internet utilizando soluciones técnicas simples.
Como broma, FreeBSD implementó soporte para la parte malvada ese día, pero eliminó los cambios al día siguiente. [4] Un parche de Linux que implementa el módulo iptables "ipt_evil" fue publicado el año siguiente. [5] Además, hay disponible un parche para FreeBSD 7, [6] y se mantiene actualizado.
Existe una extensión para el protocolo XMPP , inspirada en Evil Bit. [7]
Este RFC también ha sido citado en el por lo demás completamente serio RFC 3675, ".sex Considered Dangerous", lo que puede haber hecho que los defensores de .xxx se preguntaran si el Grupo de Trabajo de Ingeniería de Internet (IETF) estaba comentando sobre su solicitud de un dominio de nivel superior (TLD) – el documento no estaba relacionado con su solicitud. [8]
Para el Día de los Inocentes de 2010, Google agregó un &evil=trueparámetro a las solicitudes a través de las API de Ajax. [9]
Se propuso un parche para agregar compatibilidad con RFC 3514 en Wireshark , pero nunca se implementó. [10]