Nftables y su puñetera documentación: TCP flags

mceds 11 septiembre 2016 00:44

⋮

Ya sé que, en el caso hipotético de que la "Gran G" indexe este hilo, apenas lo aprovecharán cuatro frikis. El caso es que, a la hora de hacerme mi propio router neutro, me he enamorado de la nueva criatura que va a reemplazar a IPTABLES en Linux (principalmente por tener una sintaxis mucho más clara y limpia, al estilo de los IPFW o PF de los xBSD y salvando las distancias, que al fin y al cabo Netfilter sigue estando "ahí debajo"); pero resulta que la criatura está a medio hacer, sobre todo en lo que se refiere a documentación.

Me he pasado buena parte de la tarde rompiéndome la cabeza para establecer reglas que inspeccionen las cabeceras de los paquetes TCP y así evitar los ataques DoS/DDoS más comunes. Nftables está preparado para tal cosa, pero la anteriormente mencionada carencia de documentación hace que tengas que ir a ciegas. Lo peor llega cuando su propio wiki pone ejemplos que, luego, no funcionan:

add rule filter output tcp flags "& (syn | ack) == (syn | ack)" counter log
# This one doesn't work on Nftables 0.6            ^ Unexpected (

Comando que devuelve un bonito error de sintaxis: "unexpected (" o algo así, señalando a la segunda de las aperturas de paréntesis. Lo malo es que dicho error es, a su vez, reproducido por otros tutoriales; lo que demuestra que la gente copia&pega pero luego no se molesta en comprobar, a la manera de Ana Rosa Q.

Bien, por pura coña he llegado a la sintaxis correcta de ese ejemplo y es la siguiente (el truco está en eliminar el segundo paréntesis):

add rule filter output tcp flags "& (syn | ack) == syn | ack" counter log

Y, por ejemplo, para desechar y registrar en el log los intentos de Xmas Scan:

add rule filter input tcp flags "& (fin | syn | rst | psh | ack | urg) == fin | psh | urg" log drop

Lo he comprobado atacándome a mí mismo con hping3 y ha funcionado. Que, hablando del log de Nftables, es otro dolor de huevos (averiguar que hay que instalar ulogd2 para visualizarlo, sufrir la inoperancia de systemd a la hora de arrancarlo por primera vez...)

Ojalá le sea útil a alguien.

BocaDePez 11 septiembre 2016 08:53

⋮

Gracias por compartir tus conocimientos.

superllo 11 septiembre 2016 10:42

⋮

Y si en la documentación dice una cosa y la realidad es otra, ¿no podría ser un bug?, lo digo por si les da por "arreglarlo" y te toca cambiarlo.

✖

BocaDePez 11 septiembre 2016 11:32

⋮

La wiki no es una documentación, probablemente la escriba gente que no está relacionada con el proyecto.

Si pusiera algo en la documentación oficial que luego no funciona, habría que abrir un ticket, porque eso no es normal.

BocaDePez 11 septiembre 2016 12:31

⋮

gracias por la informacion, has probado en la wiki de informarles de esto?

✖

mceds 11 septiembre 2016 13:30

⋮

No. He buscado "nftables bug" y me remite al sistema de Bugzilla que exige registro incluso para buscar si ya está "reportado". Y me da bastante pereza registrarme.

✖

BocaDePez 11 septiembre 2016 17:15

⋮

Te vas al final de la página de man, buscas el correo del autor, y se lo comentas.

Uno de los desarrolladores es zevillano, seguro que le puedes mandar el correo en andalú y lo entiende la mar de bien.

✖

mceds 11 septiembre 2016 18:35

⋮

Gracias por la sugerencia, pero el señor Patrick McHardy debe de estar hasta el sombrero andalú de recibir correos habida cuenta de lo que aún le falta a su firewall para alcanzar la potencia de iptables (creo que estaban al 60%). Casi prefiero registrarme en Bugzilla.

✖

mceds 16 septiembre 2016 08:25

⋮

pepejil 16 septiembre 2016 15:48

⋮

Tiene buena pinta nftables pero después de meses para manejar iptables, ahora van y me hacen aprender una nueva sintaxis que no es ni de lejos la que he usado siempre con iptables.

Por cierto, en uno de los cursos de Linux Foundation, en la parte de "Cortafuegos", pasan de iptables y de nftables y te enseñan firewallD que ya si que te pegas un tiro porque tiene otra síntaxis distinta. No se ponen de acuerdo ni siquiera dentro de la fundación Linux.

✖

rbetancor 16 septiembre 2016 15:57

⋮

Hombre, no confundas firewald, que está al nivel de shorewall, osea ... un script o conjunto de scripts que te permiten auto-generar reglas de iptables, con nftables, que se supone en un nuevo framework para el kernel, con una capa de compatilibdad con iptables.

No sé ... yo el cambio de ipchains a iptables ... lo entendí, me costó cogerle el traquillo ... pero luego con herramientas como shorewall, que te simplifican la creación y administración del firewall ... por ahora voy servido.

✖

pepejil 16 septiembre 2016 16:01

⋮

No, no lo comparo ni lo confundo, pero me hace gracia que la Linux Foundation dé un tema entero usando de base este sistema en vez de usar iptables o el futuro nftables (Que sería lo más lógico, además, no sé si este firewallD usa netfilter, por lo que da a entender su guía, no).

Nftables es necesario porque ya agrupa varias funciones que en iptables están separadas pero es una sintaxis que da casi toda la vuelta. No creo que cueste mucho, quizás en una tarde me empapo y empiezo a darle uso en mis servidores.

Por cierto, firewallD tiene reglas basadas en servicios. ¿También lo tiene nftables?

✖

mceds 16 septiembre 2016 21:33

⋮

Según linuxito.com/gnu-linux/nivel-alto/423-mi…on-firewalld

En realidad FirewallD es una capa de abstracción de iptables (sí, de fondo usa iptables) para que los administradores vagos no tengan que lidiar con sus reglas, sino con reglas más simples (no son más simples, son distintas). No gracias, me quedo con iptables.

Que, por cierto, no sé si con lo de "servicios" te refieres a lo que en ese artículo se explica. Pero vamos, no lo pone precisamente muy bien.

Yo me he empapado en un par de tardes la docu de iptables, nftables, IPFW y PF. Al final acabas con la cabeza como un bombo y no sabiendo ni poner una coma o un guión en su sitio; pero aprendes que los conceptos básicos son muy parecidos. Es como aprender portugués, castellano, italiano y francés al mismo tiempo.

De lo que estoy enamorado de nftables es de su sintaxis en archivos "dump" (no la de shell, lo de $nft add tal y tal). Esta es la parte de NAT de mi router actual:

table ip nat {

        chain prerouting {

                type nat hook prerouting priority 0; policy accept;
                oif br0 tcp dport 22 dnat 192.168.1.2:22
        }
        chain postrouting {
                type nat hook postrouting priority 0; policy accept;
                oif eth2 masquerade
        }
}
# br0 es la interfaz que da a mi LAN y eth2 la que da a WAN; uso "masquerade" porque tengo IP dinámica.

A diferencia de iptables, en el que hay que abrir una regla en NAT:prerouting y otra en FILTER:forward para redirigir un puerto, en nftables se hace en un "oneliner" (supongo que te refieres a eso, pepejlr). Y esa sintaxis de llaves e indentados es una maravilla para la vista.

✖

pepejil 16 septiembre 2016 22:05

⋮

BocaDePez 18 septiembre 2016 21:08

⋮

Si quieres una difusión más grande ponlo como artículo en cualquier foro de Linux con bastante tráfico, LQ por ejemplo.

✖

mceds 18 septiembre 2016 21:13

⋮

Gracias por la sugerencia, pero prefiero esperar a la respuesta oficial, no sea que sea una cagada mía. Al fin y al cabo, ellos son expertos programadores y de redes mientras que yo soy un aficionado: cabe considerar la posibilidad de que esté haciendo algo mal.

Por otra parte, en una búsqueda "nftables syn ack" este hilo ya sale en cuarto lugar en el buscador de la G. Difusión tiene.

mceds 28 enero 2017 09:06

⋮

Bug solucionado.