Seguridad en tu servidor I – Iptables (Parte 2)

IPTABLES parte 1 (versión sencilla)

Muy buenas tardes a todos pequeños mortales, y bienvenidos a una segunda parte de seguridad para tu servidor (VPS o Dedicado unicamente), dónde profundizaremos mas con las reglas IpTables, y añadiremos una pequeña capa de seguridad y protección sencilla contra DoS. Los DDoS son mas dificiles de tratar y no entran en este apartado.

Avíso: Recomendamos encarecidamente la lectura completa del artículo antes de proceder a actuar en tu servidor, podrías perder la comunicación con él y debas solicitar un reinicio forzado a tu proveedor.

Primero que nada, nos aseguraremos de tener IpTables instalado, puedes ver las instrucciones en el post anterior, y empezamos primero limpiando todas las reglas (flush), comandos:

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -X
iptables -F

El firewall de Linux tiene tres cadenas principales, la Input (Entrada), Output (Salida) y Forward (A través). La primera es para las conexiones entrantes, la segunda para las salientes y la tercera, en caso que nuestro servidor tuviera dos interfaces de red, se podría configurar como enrutador, pero no es el proposito de este articulo. De como funciona IpTables, he hecho un esquema muy muy sencillo de las cadenas que trataremos:

EsquemaSecillisimoIptables

La regla por defecto dice que hay que aceptar todas las conexiones, asi que esto lo cambiaremos para que por defecto no acepte nada, a menos que sea una conexión ya establecida (Input), o sea el propio servidor que establece una nueva conexion hacia fuera (Output). Empezamos con estos tres comandos:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Ahora mismo el servidor es un búnker, casi impenetrable, y si ahora se nos corta la conexión SSH. hay que solicitar un reinicio remoto, para que se deshagan los cambios realizados, aunque es buena idea añadir a continuación una regla para permitir el puerto SSH:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Prosigamos. Una de las primeras reglas que creo que es importante, es la comunicación lookpack (a uno mismo), por ejemplo en una network con BungeeCord que tengas varios Spigot tambien en el servidor, o una base de datos MySQL, asi que ejecutaremos los siguientes:

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Ahora que ya tenemos el escenario preparado, vamos abriendo los puertos que deseemos. Por ejemplo, tenemos una página web con un servidor web? No hay problema, igual que el SSH:

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Y asi vamos abriendo los puertos que deseemos que se conecten. El de Minecraft es el 25565, pero antes de abrirlo, lo haremos con estas dos reglas:

iptables -A INPUT -p tcp --syn --dport 25565 -m connlimit --connlimit-above 10 -j DROP
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

Si nos fijamos, la segunda regla es la que permite que nos podamos conectar al Minecraft, y ¿Qué hace la primera? Pues no permite que de una misma IP entren mas de 10 personas. Esto ayuda a frenar DoS sencillos que pueda hacer una sola IP, intentando meter 100 bots de golpe, pero en un DDoS no, porque se hace desde miles de IP diferentes. Y hablando de seguridad, que tal si os comentamos unas cuantas reglas mas para aumentar la seguridad de nuestro server? Esto ya es seguridad avanzada, no os lo perdais!

police-tux

iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -j DROP

Estas reglas protegen contra inundaciones de tramas SYN. Explicado sencillo, cada vez que alguien intenta conectar con nuestro server, envia un SYN, y el server responde ACK conforme hay un servicio iniciado (Por ejemplo, el server de Minecraft). Para que serviria esto? Pues para proteger si alguien nos escanea el servidor, descubrir que servicios tenemos ejecutando, dificultandole la tarea.

iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j LOG --log-prefix PING-DROP:
iptables -A INPUT -p icmp -j DROP

Estas siguientes reglas limitan la cantidad de PINGS por segundo que contestara nuestro servidor, ademas que lo guardará en un log (Registro, visible en Debian con el comando dmesg), y si alguien intenta enviar mas pings del normal (Conocido anteriormente como el Ping de la muerte) entonces el server los bloqueará. Hace unos años con las conexiones que había, era fácil poder tumbar un server con este metodo, pero hoy día con las conexiones de Fibra, es mas complicado.

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Esta regla, explicada, hace que todas las nuevas conexiones que se establezcan al server, tienen que ser con el SYN (Como comentaba anteriormente) para que nuestro server responda. Si no es asi, ya estan intentando enviar datos modificados, y no es válido, asi que lo denegamos. Siempre que se inicia una nueva conexion, siempre se envia la primera comunicacion con SYN, a la espera del ACK del server.

iptables -A INPUT -f -j DROP

Esta regla cortita hace que los datos enviados de forma forzosa los rechaze. No sobreexplotemos a nuestro server 😀

iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

Esta regla se la conoce como “Paquetes XMAS” porque son comunicaciones que vienen con todos los parametros formados, y tal y como esta diseñada la red, no es necesareo que siempre esten todos, por lo que en ese caso, tambien los rechazamos.

iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

Igual, esta hace lo contrario: Paquetes sin ningun parametro, para que los queremos si no tienen nada? Sayonada baby~

iptables -A INPUT -m state --state INVALID -j DROP

El núcleo (kernel) de Linux es capaz de detectar paquetes invalidos y repararlos como tal, para ser procesados, pero si queremos evitar esto, los podemos rechazar antes de que lo haga.

iptables -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

Estas tres reglas, como comentabamos antes al comprobar que no se envien todos los parametros o no se envie ninguno, son otras excepciones de parametros que no “son compatibles” cuando se envian en comunicaciones a través de la red. Como siempre: fuera.

iptables -A INPUT -f -m length --length 0:40 -j DROP

Y esta, para terminar, hace que cuando se envien paquetes de tamaño muy reducido tampoco los procese, todos los paquetes tienen un tamaño minimo, y si envian de tamaños inferiores, no es posible de procesar, asi que los ignoramos de nuevo.

Y si llegaste hasta aqui, felicidades, ya tienes una capa de protección extra para tu servidor Minecraft en Linux. Tienes curiosidad de como quedarían estas reglas todas juntas? Mira este link! Ahora comprueba que puedes abrir una nueva terminal SSH, puedes entrar en tu servidor minecraft, y todo. Si es asi, ya puedes ejecutar el iptables-save que comentamos al articulo anterior 😀 y si ves que algo falla, siempre puedes deshacer los cambios, como comentamos anteriormente (vease los primeros comandos al principio de este post) y empezar de nuevo.

No olvideis comentar que tal os ha ido en los comentarios, y si teneis alguna regla mas, se agradece compartirla 😀 Y no lo olvideis: galletas para todos!

Comentarios (by Facebook)
Comparte este artículo: