
En la parte anterior, mostré cómo imponer límites razonables a los clientes, y cómo registrar trazas. En esta parte pretendo mostrar cómo minimizar el riesgo de falseo de direcciones de origen, detectar posibles escaneos de puertos, y otros temas afines.
Tal como dejamos nuestras reglas en la parte anterior, un usuario malicioso dentro de nuestra red local podría intentar falser su dirección IP de origen para hacerse pasar por otro equipo, de modo que conviene protegerse en este sentido.
Mitigando el falseo de direcciones
El primer paso será evitar (y registrar) que otro equipo pueda intente colocarse como dirección IP de origen la dirección de cualesquiera de las interfaces de nuestro equipo:
1 2 | iptables -t raw -A PREROUTING ! -i lo -m addrtype --src-type LOCAL -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A PREROUTING ! -i lo -m addrtype --src-type LOCAL -j DROP |
¿Por qué recomiendo usar la tabla raw en lugar de la tabla filter? Para empezar, porque es la primera tabla con la cual se evalúan los paquetes; además es rápida, porque en esta tabla aún no se activa el rastreo de conexiones. De modo que puede aprovecharse para mitigar intentos de ataque. En este caso, evitar que un paquete recibido por cualquier interfaz diferente a la local, utilice una dirección IP de origen perteneciente a nuestro equipo.
Además, si nuestro equipo tiene su interfaz LAN con una dirección en el bloque 192.168.0.0/24. Por lógica, ningún paquete proveniente de esa subred debería tener una ip de origen que no pertenecza al rango, de modo que agreguémoslo:
1 | iptables -t raw -A PREROUTING -i eth0 ! -s 192.168.0.0/24 -j DROP |
Ahora bien, existe una excepción válida. Si nuestro equipo tiene además habilitado un servicio DHCP, con la regla anterior ningún otro equipo de nuestra LAN podría utilizar dicho servicio para recibir la asignación apropiadamente. Una forma de solucionar este problema es mediante cadenas personalizadas, pero primero conviene comprender el funcionamiento del servicio DHCP.
Cuando se conecta un nuevo equipo que nunca ha recibido una asignación de dirección IP, envía un paquete mediante el protocolo UDP desde el puerto 68 con la ip de origen 0.0.0.0, destinado al puerto 67 de la ip 255.255.255.255, es decir, a la dirección de difusión (BROADCAST) global.
Aunque esto sea solo parte del proceso de asignación, comprenderlo nos sirve para declarar algo como esto:
1 2 3 4 5 6 7 8 9 | iptables -t raw -N DHCP iptables -t raw -A DHCP -j NFLOG --nflog-prefix ORIGEN iptables -t raw -A DHCP -s 0.0.0.0 -d 255.255.255.255 -p udp -m udp --dport 67 --sport 68 -j ACCEPT iptables -t raw -A DHCP -j DROP iptables -t raw -A DHCP -j RETURN iptables -t raw -A PREROUTING -i eth0 ! -s 192.168.0.0/24 -j DHCP iptables -A INPUT -i eth0 -s 0.0.0.0 -d 255.255.255.255 -p udp -m udp --dport 67 --sport 68 -j ACCEPT iptables -A INPUT -i eth0 -s 192.168.0.0/24 -p udp -m udp --dport 67 --sport 68 -j ACCEPT |
El bloque anterior tiene dos partes, la primera crea en la tabla raw una nueva cadena de nombre DHCP, a la cual se agregan entonces reglas que registren todos los paquetes, acepten los que conicidan con una petición DHCP, descarten todo los demás, y finalmente regresen a la cadena desde donde se hizo el salto.
En la segunda parte del bloque, utilizamos la cadena que acabamos de crear como destino de salto para todos aquellos paquetes entrantes por la interfaz de la red local (eth0) cuya IP de origen no pertenezca al bloque de direcciones de nuestra subred local, y posteriormente permitimos la entrada a los que cumplan el criterio de una solicitud de asignación correcta. Pudiera parecer que hay redundancia, pero sin la penúltima regla del bloque, aunque la solicitud de asignación se acepte en la tabla raw, no llegaría al servicio DHCP a causa de las políticas predeterminadas de la cadena INPUT, que son restrictivas, de modo que hay que permitir el acceso explícitamente.
Finalmente, se añade una regla para las renovaciones, que son un caso diferente porque el equipo invitado ya obtuvo una dirección IP de la red local, de modo que solicitará la renovación directamente al servidor que le otorgó la asignación. Sólo en caso de no encontrar el servidor, el equipo solicita una asignación nueva, que quedará similarmente cubierta por el bloque de reglas que acabamos de declarar.
Las respuestas del servicio quedarín cubiertas por las reglas que permitan paquetes de conexiones establecidas y relacionadas, que en el artículo pasado movimos hacia el final de nuestro script.
Ahora bien, hasta aquí hemos prevenido una parte de los intentos de suplantación, pero queda otro escenario: que alguien se coloque la dirección IP de un equipo privilegiado. Para minimizar esta vulnerabilidad, puede utilizarse la dirección física de las interfaces.
Direcciones físicas
Cada interfaz de red, además de utilizar una dirección IP tiene una dirección física que consiste en seis cifras hexadecimales, de las cuales las primeras tres suelen utilizarse para identificar el fabricante del equipamiento y las últimas tres funcionan como identificador seriado del dispositivo. Estas direcciones también pueden utilizarse para asegurar un poco más nuestro cortafuegos.
Por ejemplo, supongamos que el modem-router ADSL que nos proporciona enlace a Internet tiene la dirección IP 192.168.2.1 y la dirección MAC A1:B2:C3:D4:E5:F6
, y que en nuestra red local tenemos un servidor de correo con la dirección IP 192.168.0.25 y la dirección MAC 00:00:00:A1:B2:C3
. Ambos equipos son sensibles y quisiéramos evitar en lo posible que otros equipos de la red intenten asignarse estas direcciones IP; podríamos lograrlo con reglas como estas:
1 2 3 4 | iptables -t raw -A PREROUTING -i eth0 -s 192.168.0.25 -m mac !--mac-source 00:00:00:A1:B2:C3 -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A PREROUTING -i eth0 -s 192.168.0.25 -m mac !--mac-source 00:00:00:A1:B2:C3 -j DROP iptables -t raw -A PREROUTING -i eth1 -s 192.168.2.1 -m mac !--mac-source A1:B2:C3:D4:E5:F6 -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A PREROUTING -i eth1 -s 192.168.2.1 -m mac !--mac-source A1:B2:C3:D4:E5:F6 -j DROP |
Nótese que este tipo de reglas reglas no son infalibles, son sólo una medida más de protección básica. Existen herramientas que permiten modificar una dirección física, pero no por ello este tipo de comprobación deja de tener su utilidad.
Mitigando el escaneo de puertos
Uno de los primeros pasos que un posible atacante suele tomar antes de intentar vulnerar una red, consiste en escanear los puertos abiertos. De modo que dificultar el escaneo de puertos puede ser un medida efectiva de seguridad adicional.
Pues bien, existe un módulo para netfilter llamado psd cuyo propósito es analizar los paquetes TCP y UDP provenientes de un mismo cliente con diferentes puertos de destino para tratarlos como una secuencia de escaneo de puertos. Sucede que este módulo no se instala por defecto, sino que se ecuentra dentro de un grupo de extensiones que es necesario compilar desde el código fuente. Afortunadamente, existe un asistente que puede facilitarnos la tarea. Para instalar el módulo entonces, usualmente basta con ejecutar los siguientes comandos:
1 2 | apt-get install linux-headers-$(uname -r) xtables-addons-{common,dkms,source} module-assistant module-assistant --verbose --text-mode auto-install xtables-addons |
Con esto, el paquete modules-assistant compilará e instalará automáticamente el código fuente de las extensiones contenidas en xtables-addons. ¿Cómo usar entonces el módulo psd que acabamos de instalar? Esta podría ser una forma:
1 2 3 4 5 6 7 | iptables -t mangle -N PORTSCAN iptables -t mangle -A PORTSCAN -j NFLOG --nflog-prefix PORTSCAN iptables -t mangle -A PORTSCAN -i eth0 -j REJECT --reject-with icmp-admin-prohibited iptables -t mangle -A PORTSCAN -j DROP iptables -t mangle -A PORTSCAN -j RETURN iptables -t mangle -A PREROUTING ! -i lo -m conntrack --ctstate NEW -m psd --psd-weight-threshold 21 --psd-delay-threshold 300 --psd-lo-ports-weight 3 --psd-hi-ports-weight 1 -j PORTSCAN |
En este caso propongo usar la tabla mangle porque es una tabla que se evalúa antes que filter, tiene cadena PREROUTING y control de estado. En otras palabras, los paquetes puede verificarse antes de enrutarse, independientemente de que estén destinados al propio equipo u otros, y puede comprobarse su estado. Esto evita duplicar las mismas reglas en las cadenas INPUT y FORWARD de la tabla filter.
En la cadena integrada PREROUTING declaramos entonces una regla que evalúe con el criterio de parámetros del módulo psd los paquetes nuevos que no provengan de la interfaz local, y en caso de coincidencia, los hacemos saltar a la cadena personalizada PORTSCAN. De esta manera, evitamos declarar la regla múltiples veces.
En la cadena personalizada PORTSCAN, ante todo, el intento quedará registrado en las trazas. Luego, en caso de que provenga de la interfaz interna (LAN), se rechazará con un mensaje de prohibición por parte del administrador, y en caso de que provenga desde cualquier otra interfaz, se descartará silenciosamente.
El mecanismo del módulo psd es el siguiente: se establece un límite de peso, que en este caso es 21. Cada puerto que un cliente «toque» se pesará según el valor de --psd-lo-ports-weight
para los puertos entre 0 y 1023, y según el valor de --psd-hi-ports-weight
para los puertos entre 1024 y 65535. Si en el lapso de tiempo definido por --psd-delay-threshold
(en centécimas de segundo) la sumatoria de pesos alcanza el valor establecido, la coincidencia será verdadera.
Un par de detalles a tomar en consideración: En el caso de Proxmox, las extensiones deben instalarse en el host si se pretende usarlas desde contenedores. En caso de tenerse habilitado SELinux, es conveniente deshabilitarlo antes de instalar las extensiones.
Servicios de administración
El módulo psd podría ser insuficiente si el cliente toma la precaución de probar sólo unos 5 puertos cada 5 segundos. No obstante, es muy probable que entre los intentos de acceso se encuentren servicios de administración como Telnet, SSH, VNC o RDP que suelen estar reservados sólo para ciertos equipos en la red. Esto podemos aprovecharlo, como explicaré a continuación.
Actividad reciente
Netfilter tiene un módulo denominado recent que podríamos utlizar para descartar temporalmente cualquier paquete que provenga de un equipo no autorizado que haya tocado recientemente alguno de los puertos correspondientes a servicios de administración. ¿Cómo lograrlo? De la siguiente manera, por ejemplo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | iptables -t raw -N VERIFICAR iptables -t raw -A VERIFICAR -s 192.168.0.11 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F1 -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A VERIFICAR -s 192.168.0.11 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F1 -m comment --comment Administrador1 -j DROP iptables -t raw -A VERIFICAR -s 192.168.0.12 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F2 -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A VERIFICAR -s 192.168.0.12 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F2 -m comment --comment Administrador2 -j DROP iptables -t raw -A VERIFICAR -s 192.168.0.13 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F3 -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A VERIFICAR -s 192.168.0.13 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F3 -m comment --comment Administrador3 -j DROP iptables -t raw -A VERIFICAR -j RETURN iptables -t raw -A PREROUTING -m iprange --src-range 192.168.0.11-192.168.0.13 -j VERIFICAR iptables -t mangle -N VERIFICAR iptables -t mangle -A VERIFICAR -j NFLOG --nflog-prefix ADMINISTRACION iptables -t mangle -A VERIFICAR -m iprange ! --src-range 192.168.0.11-192.168.0.13 -m recent --name listanegra --set -j DROP iptables -t mangle -A VERIFICAR -j RETURN iptables -t mangle -A PREROUTING -m recent --name listanegra --update --seconds 300 -j DROP iptables -t mangle -A PREROUTING -p tcp -m multiport --dports 22:23,3389,5900 -m conntrack --ctstate NEW -j VERIFICAR |
En este caso, creamos en la tabla raw la cadena personalizada VERIFICAR, en la cual registramos y descartamos cualquier paquete cuya IP de origen coincida con la de un equipo autorizado, pero no así la dirección MAC correspondiente. Posteriormente agregamos en la cadena PREROUTING una regla que haga saltar los paquetes con IP de origen en el rango de direcciones de administración, para evaluarlos con la cadena personalizada. Esto sirve como una primera etapa de filtrado. Nótese la introducción de los comentarios.
Entonces, en la tabla mangle creamos otra cadena personalizada VERIFICAR, en la cual primero registramos todo intento de conexión, y luego descartamos aquellos paquetes cuya dirección IP de origen no se encuentre entre las autorizadas a utilizar los servicios de administración, no sin antes colocar la dirección IP de origen en una lista negra (esta es la novedad).
Posteriormente, en la cadena PREROUTING descartamos durante 5 minutos todo paquete proveniente de una dirección IP en lista negra, y finalmente hacemos que aquellos paquetes de una nueva conexión que intenten acceder a puertos de administración salten a evaluarse con la cadena personalizada VERIFICAR de la tabla mangle.
La penúltima regla se coloca antes de la que manda a verificar el paquete, porque si la dirección IP de un cliente ya fue puesta en lista negra, pueden descartarse los paquetes posteriores provenientes de ese cliente directamente sin que sea necesario evaluarlos cada vez. Adicionalmente, el parámetro --update
hace que se extienda el tiempo de prohibición de acceso por otros 5 minutos. Es decir que el cliente en lista negra que insista en acceder a nuestro equipo, solo conseguirá prolongar el tiempo que permanece en la lista negra. Sólo después de un período de inactividad superior a 5 minutos, podrá volver a realizar operaciones normales.
Colocar estas reglas en la tabla mangle sin declarar una dirección IP de destino, ofrece la ventaja de que funcionarán lo mismo para un paquete entrante que para un paquete que se intente reenviar a otro equipo usando el nuestro como pasarela. En otras palabras, a los efectos prácticos es equivalente a declarar las mismas reglas duplicadas en las cadenas INPUT y FORWARD de la tabla filter.
Paquetes inválidos
En la primera parte mencionamos el estado INVALID (inválido), que se asigna a cualquier paquete con parámetros inesperados o que alegue ser parte de una conexión, pero el rastreo de conexiones no haya visto tráfico asociado a ninguna conexión conocida.
Además de este, existen para el protocolo TCP las así llamadas flags (banderas) o parámetros del protocolo: SYN, ACK, FIN, RST, URG, PSH, ALL, NONE. No nos extenderemos aquí a detallar el funcionamiento del protocolo TCP/IP, pero existen combinaciones de estos parámetros que a veces se utilizan para fines maliciosos y en realidad no deberían coexistir naturalmente en un mismo paquete.
La documentación de netfilter no es muy clara en cuanto a qué considera como inválido, pero si examinamos el código fuente (netfilter/nf_conntrack_proto_tcp.c
), veremos que esto depende del valor del kernel net.netfilter.nf_conntrack_tcp_be_liberal
. Si este valor se ha establecido en 0, el estado INVALID detectará una buena parte de las combinaciones de flags incorrectas, por lo que podrá ser suficiente con algo como esto:
1 2 | iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j NFLOG --nflog-prefix INVALIDO iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP |
Sin embargo, si el valor de net.netfilter.nf_conntrack_tcp_be_liberal
es diferente de cero, solo se detectarán como inválidos los paquetes con el flag RST activo pero fuera de la ventana esperada, por lo que podrá ser necesario excluir manualmente las combinaciones incorrectas, por ejemplo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | iptables -t mangle -N INVALIDO iptables -t mangle -A INVALIDO -j NFLOG --nflog-prefix INVALIDO iptables -t mangle -A INVALIDO -j DROP iptables -t mangle -A INVALIDO -j RETURN iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ACK,FIN,PSH,RST,SYN,URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ACK,FIN,RST,SYN,URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,SYN,URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,SYN -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags RST,SYN RST,SYN -j INVALIDO |
Ahora bien, la comprobación de flags del protocolo TCP no invalida la comprobación del estado INVALID, pues este puede cubrir también el protocolo UDP, de modo que ambas soluciones podrían combinarse por si acaso.
Uniéndolo todo
A estas alturas, nuestro script de cortafuegos ha adquirido cierta complejidad, de modo que conviene mostrar aproximadamente cómo podría quedar, para ver el orden de declaración de las reglas:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 | iptables -t raw -P PREROUTING ACCEPT iptables -t raw -N SUPLANTACION iptables -t raw -A SUPLANTACION -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A SUPLANTACION -j DROP iptables -t raw -A SUPLANTACION -j RETURN iptables -t raw -N DHCP iptables -t raw -A DHCP -j NFLOG --nflog-prefix ORIGEN iptables -t raw -A DHCP -s 0.0.0.0 -d 255.255.255.255 -p udp -m udp --dport 67 --sport 68 -j ACCEPT iptables -t raw -A DHCP -j DROP iptables -t raw -A DHCP -j RETURN iptables -t raw -N VERIFICAR iptables -t raw -A VERIFICAR -s 192.168.0.11 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F1 -m comment --comment Administrador1 -j SUPLANTACION iptables -t raw -A VERIFICAR -s 192.168.0.12 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F2 -m comment --comment Administrador2 -j SUPLANTACION iptables -t raw -A VERIFICAR -s 192.168.0.13 -m mac ! --mac-source -m recent 0A:00:00:D5:E6:F3 -m comment --comment Administrador3 -j SUPLANTACION iptables -t raw -A VERIFICAR -s 192.168.0.25 -m mac ! --mac-source 00:00:00:A1:B2:C3 -m comment --comment "Falso MTA" -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A VERIFICAR -s 192.168.2.1 -m mac ! --mac-source A1:B2:C3:D4:E5:F6 -m comment --comment "Falso Router" -j NFLOG --nflog-prefix SUPLANTACION iptables -t raw -A VERIFICAR -j RETURN iptables -t raw -A PREROUTING ! -i lo -m addrtype --src-type LOCAL -j SUPLANTACION iptables -t raw -A PREROUTING -i eth0 ! -s 192.168.0.0/24 -j DHCP iptables -t raw -A PREROUTING -m iprange --src-range 192.168.0.11-192.168.0.13 -j VERIFICAR iptables -t raw -A PREROUTING -i eth0 -s 192.168.0.25 -m comment --comment "MTA" -j NFLOG --nflog-prefix VERIFICAR iptables -t raw -A PREROUTING -i eth1 -s 192.168.2.1 -m comment --comment "Router" -j NFLOG --nflog-prefix VERIFICAR iptables -t mangle -P PREROUTING ACCEPT iptables -t mangle -N VERIFICAR iptables -t mangle -A VERIFICAR -j NFLOG --nflog-prefix ADMINISTRACION iptables -t mangle -A VERIFICAR -m iprange ! --src-range 192.168.0.11-192.168.0.13 -m recent --name listanegra --set -j DROP iptables -t mangle -A VERIFICAR -j RETURN iptables -t mangle -N PORTSCAN iptables -t mangle -A PORTSCAN -j NFLOG --nflog-prefix PORTSCAN iptables -t mangle -A PORTSCAN -j DROP iptables -t mangle -A PORTSCAN -j RETURN iptables -t mangle -N INVALIDO iptables -t mangle -A INVALIDO -j NFLOG --nflog-prefix INVALIDO iptables -t mangle -A INVALIDO -j DROP iptables -t mangle -A INVALIDO -j RETURN iptables -t mangle -A PREROUTING -m recent --name listanegra --update --seconds 300 -j DROP iptables -t mangle -A PREROUTING -p tcp -m multiport --dports 22:23,3389,5900 -m conntrack --ctstate NEW -j VERIFICAR iptables -t mangle -A PREROUTING ! -i lo -m conntrack --ctstate NEW -m psd --psd-weight-threshold 21 --psd-delay-threshold 300 --psd-lo-ports-weight 3 --psd-hi-ports-weight 1 -j PORTSCAN iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ACK,FIN,PSH,RST,SYN,URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ACK,FIN,RST,SYN,URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,SYN,URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,SYN -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j INVALIDO iptables -t mangle -A PREROUTING -p tcp --tcp-flags RST,SYN RST,SYN -j INVALIDO iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT iptables -A INPUT -p udp -m udp --dport 33434:33534 -m conntrack --ctstate NEW -j REJECT iptables -A INPUT -i eth0 -p udp -m udp --dport 67 --sport 68 -m conntrack --ctstate NEW -j NFLOG --nflog-prefix DHCP iptables -A INPUT -i eth0 -s 0.0.0.0 -d 255.255.255.255 -p udp -m udp --dport 67 --sport 68 -j ACCEPT iptables -A INPUT -i eth0 -s 192.168.0.0/24 -p udp -m udp --dport 67 --sport 68 -j ACCEPT iptables -A INPUT -i eth0 -s 192.168.0.0/24 -p udp -m udp --dport 123 -j NFLOG --nflog-prefix NTP iptables -A INPUT -i eth0 -s 192.168.0.0/24 -p udp -m udp --dport 123 -m hashlimit --hashlimit-mode srcip,dstip,dstport --hashlimit-upto 8/hour --hashlimit-burst 4 --hashlimit-htable-expire 900000 --hashlimit-name LIM_NTP_RQ -j ACCEPT iptables -A INPUT -i eth0 -m iprange --src-range 192.168.0.11-192.168.0.13 -p tcp -m multiport --dports 22:23,3389,5900 -m conntrack --ctstate NEW -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j NFLOG --nflog-prefix HTTP iptables -A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -m hashlimit --hashlimit-mode srcip,dstip,dstport --hashlimit-upto 200/minute --hashlimit-burst 100 --hashlimit-htable-expire 15000 --hashlimit-name LIM_WEB_RQ -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate ESTABLISHED -m connlimit --connlimit-saddr --connlimit-upto 100 -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 80 -j DROP iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT |
Con esto, incluso si las reglas de nuestro cortafuegos no garantizan una efectividad absoluta, nuestro equipo estará considerablemente más protegido que al principio.
(Continuará)
En la próxima parte de este tema, hablaré de las redirecciones y la tabla de traducción de direcciones, entre otros temas.
Notas
Revisando el artículo encontré errores en la declaración de algunas reglas, que acabo de arreglar. Por favor, notificar cualquier posible error en un comentario.
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36
hola. buen articulo, excepto por la regla de bloqueo DHCP que es una situación imposible. Si tienes un servidor linux con dhcp instalado y los usuarios reciben el arrendamiento del servidor dhcp, pero las conexiones físicas van a un switch o access point, etc, iptables nada podrá hacer al respecto porque los usuarios se conectan entre sí. hablamos de capas diferentes. La única manera en que tus reglas de DHCP funcionen es que los usuarios se conecten directamente al servidor si pasar por ningún otro dispositivo de hardware. Obviamente el servidor tendría que tener un poco de tarjetas de red para cada usuario y crear un puente.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Naturalmente que netfilter no es infalible de manera aislada, por ejemplo un equipo de la red puede intentar hacerse pasar por servidor DHCP, etc.
Pero para esto pueden aplicarse otras medidas, como la detección de cambio de direcciones IP o MAC, uso de switch gestionables con reglas que impidan que los equipos escuchen por el puerto UDP 67, etc.
Por eso la palabra que usé fue mitigar y no erradicar o eliminar, jjj.
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36
pero sería un switch cisco, que son los que traen dhcp snooping, o con AP isolation en los access point que lo tengan. Este tema es casi un imposible. Aquí hay un hilo sobre eso y la conclusión es la misma. https://unix.stackexchange.com/questions/352231/iptables-dhcp-snooping