Playbooks para la gestión básica de infraestructura IT

Continuando con la automatización de configuraciones de nuestra infraestructura, en la Escuela Politécnica también hemos programado (y liberado) playbooks de Ansible relacionados con las tareas básicas que se realizan con los servidores de nuestros servicios IT.

Más información sobre estos playbooks en https://blogs.ua.es/labseps/?s=ansible&x=0&y=0

Y el software en https://github.com/EPSAlicante/ansibleEPS

¡Espero que os sea útil!


Transparencias de clase sobre “Firewalls”

Continuando con las publicaciones de viejas transparencias de clase de Administración e Instalación de Redes de Computadores, en particular, de las que dedicaba a seguridad en red, hoy toca el turno de la presentación que hice sobre el diseño y configuración de cortafuegos. Para estas transparencias usé como principal fuente de información el libro “Building Internet Firewalls” de D. Bremt Chapman y Elizabeth D. Zwicky, editado por O’Reilly.

¡Espero que os sea útil!


Otra protección más con iptables y módulo recent

Al hilo de esta entrada, si lo que queremos es controlar, incluso, un posible escaneo de puertos desde una IP, y no solo peticiones abusivas a uno de nuestros servicios que es de lo que trataba la entrada anterior, tenemos:

iptables -I INPUT  --m state --state NEW -m recent  --set
iptables -I INPUT  --m state --state NEW -m recent  --update --seconds 60 --hitcount 5 -j DROP

Con la ejecución de estas 2 órdenes, cualquier intento de realizar más de 5 conexiones (destinados a cualquiera de nuestros puertos) desde una misma IP, producirá un bloqueo de las conexiones desde esta IP durante 60 segundos.

Este es un mecanismo fácil, rápido y eficiente de control de las peticiones que recibimos en nuestros servidores y más ligero que opciones como la comentada aquí, ya que detectamos y protegemos con el módulo recent de iptables, en un nivel más bajo y que apenas introduce carga al sistema.

Como ya comenté, lo podemos hacer también en routers, solo que afecta a otras tablas/cadenas (filter/FORWARD, nat/PREROUTING,…) y opciones a considerar.

¡Espero que os sea útil!

 Referencias

  1. man iptables

Port Knocking con iptables

Existe software desarrollado, como knockd, que nos permite utilizar una técnica de protección muy interesante: Port Knocking La idea es que, cuando se da una secuencia concreta de conexiones a determinados puertos, se habilita otro, que es nuestro objetivo final. Por ejemplo, tenemos deshabilitado el acceso al servidor SSH y, tras recibir una secuencia de conexión a los puertos 2000, 2002 y 50005, se activa la conexión, para esa IP de origen, al puerto 22 del SSH. Es una técnica más de las utilizadas para la fortificación de SSH (no es la panacea, ya que se puede descubrir la secuencia fácilmente, pero ya se sabe que cuanto más azúcar, más dulce).

Esta función se puede desarrollar  de manera muy sencilla con iptables y el módulo recent (que gestiona listas dinámicas de IPs  y que ya utilizamos para controlar el número de conexiones entrantes desde una misma IP en esta entrada). La siguiente lista de órdenes habilitaría el acceso al servicio SSH para la IP de origen desde la que se intente la conexión (en la secuencia correcta) a los puertos 2000 y 3000:

/sbin/iptables -N CADENA_PASO2
/sbin/iptables -A CADENA_PASO2 -m recent --name PASO1 --remove
/sbin/iptables -A CADENA_PASO2 -m recent --name PASO2 --set
/sbin/iptables -A CADENA_PASO2 -j LOG --log-prefix "ENTRANDO EN PASO 2: "
/sbin/iptables -I INPUT -m recent --update --name PASO1
/sbin/iptables -I INPUT -p tcp --dport 2000 -m recent --set --name PASO1
/sbin/iptables -I INPUT -p tcp --dport 3000 -m recent --rcheck --name PASO1 -j CADENA_PASO2
/sbin/iptables -I INPUT -p tcp --dport 22 -m recent --rcheck --seconds 5 --name PASO2 -j ACCEPT

Con estas reglas, debemos activar la política por defecto a DROP, para la cadena INPUT; también necesitamos una regla ACCEPT, para el puerto de origen 22 para cualquier destino en la cadena OUTPUT.

Para conectarnos, podemos ejecutar uno de los siguientes bloques de órdenes:

nmap -sn -PS2000 --host_timeout 200 --max-retries 0 servidor
nmap -sn -PS3000 --host_timeout 200 --max-retries 0 servidor
ssh [email protected] # Ahora está permitido 
telnet servidor 2000
telnet servidor 3000
ssh [email protected] # Ahora está permitido 

Con la segunda opción, los telnets estarán esperando a que salte el timeout y con 5″ de ventana de tiempo…

En cuanto a la primera:

  • “-sn”: No port scan
  • “-PS4000”: TCP SYN al puerto 4000
  • “–max-retries 0”: que no intente ningún reenvío
  • “–host-timeout 200”: que espere 200ms

Si queremos emular al conocido personaje Seldon Cooper,  y sus 3 “toques” cada vez que llama a una puerta, solo debemos añadir un puerto y su correspondiente fase más. Así, por ejemplo, para que la secuencia de activación de SSH sea: 4000, 2000, 3000, deberíamos configurar las iptables de la siguiente manera:

/sbin/iptables -N CADENA_PASO2
/sbin/iptables -A CADENA_PASO2 -m recent --name PASO1 --remove
/sbin/iptables -A CADENA_PASO2 -m recent --name PASO2 --set
/sbin/iptables -A CADENA_PASO2 -j LOG --log-prefix "ENTRANDO EN PASO 2: "
/sbin/iptables -N CADENA_PASO3
/sbin/iptables -A CADENA_PASO3 -m recent --name PASO2 --remove
/sbin/iptables -A CADENA_PASO3 -m recent --name PASO3 --set
/sbin/iptables -A CADENA_PASO3 -j LOG --log-prefix "ENTRANDO EN PASO 3: "
/sbin/iptables -I INPUT -m recent --update --name PASO1
/sbin/iptables -I INPUT -p tcp --dport 4000 -m recent --set --name PASO1
/sbin/iptables -I INPUT -p tcp --dport 2000 -m recent --rcheck --name PASO1 -j CADENA_PASO2
/sbin/iptables -I INPUT -p tcp --dport 3000 -m recent --rcheck --name PASO2 -j CADENA_PASO3
/sbin/iptables -I INPUT -p tcp --dport 22 -m recent --rcheck --seconds 5 --name PASO3 -j ACCEPT

Estas líneas que implementan la funcionalidad port knocking se deben añadir a los filtros que tengamos en nuestro servidor (o router, pero en este caso las reglas anteriores deben ir a la cadena FORWARD) y debemos tener en cuenta que:

  1. Las comunicaciones para SSH (o el servicio que sea) deben estar INHABILITADAS.  Con, por ejemplo, /sbin/iptables -P INPUT DROP lo logramos. La activación se hace con las órdenes del port knocking. Si no queremos ser tan drásticos: /sbin/iptables -A INPUT -p tcp –dport 22 -j DROP
  2. Debemos tener una regla que habilite las conexiones establecidas. Si no, nuestra sesión durará 5″ 🙁 Por ejemplo, una podría ser: /sbin/iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

¡Espero que os sea útil!

 Referencias

  1. man iptables
  2. Guía avanzada de nmap elaborada en conjunto por CSIRT-CV y el Centro Criptológico Nacional (CCN)

Cómo controlar la recepción de peticiones abusivas desde una misma IP

Hace unos meses escribí esta entrada sobre un guión en Python para la detección de peticiones abusivas hacia un servidor web Apache. Me faltó indicar cómo controlarlas y es muy sencillo:

iptables -I INPUT --dport 80  -p tcp --syn -m recent --name "CONTROL-WEB" --set
iptables -I INPUT -p tcp --dport 80 --syn -m recent --update --seconds 30 --hitcount 20 -j DROP

Estas líneas de iptables, que podemos añadir al principio de la lista de órdenes de nuestro filtro de acceso al servidor, se encargan de contar el número de peticiones de establecimiento de conexión por cada dirección IP en los últimos 30 segundos, descartando los que puedan llegar cuando la cuenta ha superado el valor de 20 e impidiendo, por tanto, la conexión desde esa IP. El guión de la entrada mencionada nos puede servir para hacernos una idea de qué es lo habitual en nuestro sistema y ajustar los segundos y número de conexiones en esos segundos que queremos admitir.

La primera orden crea una lista dinámica de nombre CONTROL-WEB en la que insertará la IP de origen del paquete. La segunda, comprueba si esa IP se ha añadido a la lista en los últimos 30″ y, en el caso de que se hayan contabilizado más de 20 peticiones, deniega la petición.

Podemos ser más específicos indicando que solo queremos contabilizar los inicio de conexión:

iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent -name "CONTROL-WEB" --set
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 30 --hitcount 50 -j DROP

En el directorio /proc/net/xt_recent encontraremos un fichero de nombre CONTROL-WEB y cuyo contenido es la lista de IPs añadidas por las reglas anteriores.

Referencia

  1. man iptables

IGMP: tráfico multicast y filtros

Cuando diseñamos una red una de las tecnologías/infraestructuras que planificaremos será la instalación de un cortafuegos*. En estas circunstancias tenemos que tener claro qué paquetes dejamos pasar, cuales desechamos, y todo en función de nuestra política de seguridad y sin perder la funcionalidad para la que estamos diseñando nuestra red.

Si utilizamos OSPF o, en general, si queremos manejar tráfico multicast, debemos habilitar los paquetes IGMP en nuestros filtros (suponiendo que tenemos la estrategia de denegar todo lo que no está explicitamente habilitado) ya que es el protocolo que utilizaran hosts y routers para establecer los miembros de los grupos de multicast. De este protocolo, debemos tener en cuenta, sobre todo, que se encapsula en datagramas IP con el número 2 de protocolo (esto implica que NO utiliza UDP ni TCP ni, por tanto, tiene puertos). Otro detalle que debemos tener en cuenta es que el TTL de los paquetes de IGMP, por defecto, es 1, lo que implica que no “atravesarán” los routers y no saldrán de la subred en la que se genera, aunque puede aumentarse para localizar servidores lejanos utilizando este campo como “barrera” y configurando los routers para que sean transparentes y no decrementen el TTL**.

La ejecución de las siguientes órdenes provocará que nuestro router de filtrado acepte y saque mensajes IGMP:

iptables -A INPUT -p igmp -j ACCEPT
iptables -A OUTPUT -p igmp -j ACCEPT

Para el caso de los grupos multicast relacionados con OSPF que comentábamos en la entrada anterior, podríamos limitar las reglas habilitando solo los grupos relacionados con OSPF:

iptables -A INPUT -p igmp -d 224.0.0.5 -j ACCEPT
iptables -A INPUT -p igmp -d 224.0.0.6 -j ACCEPT
iptables -A OUTPUT -p igmp -d 224.0.0.5 -j ACCEPT

Referencias

  1. Building Internet Firewalls, de Elizabeth D. Zwicky, Simon Cooper y D. Brent Chapman
  2. https://tools.ietf.org/html/rfc3376, RFC para IGMP versión 3
  3. http://tools.ietf.org/html/rfc2236, RFC para IGMP versión 2

* Prefiero usar el concepto de cortafuegos para la infraestructura de protección de red que diseñamos y que puede estar compuesta por varios elementos donde, uno de ellos, el dispositivo de red que filtra paquetes y que -casi- todo el mundo denomina cortafuegos, yo prefiero denominarlo router de filtrado.

** Una orden genérica para este caso es: iptables -A FORWARD -p igmp -j ACCEPT Si queremos, por ejemplo, especificar que el tráfico que queremos es el relacionado con el audio/vídeo: iptables -A FORWARD -p udp -m udp -d 239.0.0.0/16 –dport 5001 -j ACCEPT

 


Filtros de red para OSPF (Open Shortest Path First)

Si en nuestros routers utilizamos la estrategia de denegar todo por defecto y permitir expresamente lo que deseamos, en el caso de que estos equipos tengan configurado que aprendan sus rutas con OSPF, debemos habilitar dicho protocolo. Para ello, debemos tener en cuenta que OSPF

  • se encapsula en datagramas IP con el número 89 de protocolo (esto implica que NO utiliza UDP ni TCP ni, por tanto, tiene puertos),
  • usa tanto paquetes multicast (los grupos 224.0.0.5 y 224.0.0.6 y lo que nos obliga a configurar, usar y habilitar en nuestros filtros IGMP*) como unicast,
  • el TTL de sus paquetes es 1, por lo que no atravesarán un cortafuegos, salvo que configuremos un túnel (http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml),
  • y por último, dispone de un identificador de tipo de paquete (nos permite mejorar las reglas, aunque dependemos del software de filtrado).

Con iptables, la forma más fácil es ejecutar las siguientes ordenes**:

iptables -A INPUT -p 89 -j ACCEPT
iptables -A OUTPUT -p 89 -j ACCEPT

Si queremos ser más “finos”, debemos indicar las IPs de origen, destino y, si lo permite el software de filtrado, el tipo de paquete de OSPF. Las reglas en este caso***:

#hello ospf between rt_ext and rt_int
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
#database description, link state request, asking for information about a particular link and request/update link state
iptables -A INPUT -s rt_ext -d rt_int -p 89 -j ACCEPT
iptables -A OUTPUT -d rt_int -s rt_int -p 89 -j ACCEPT
#link state update, flooding all link states from rt_ext router
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
#rt_int router link state update from rt_ext router
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT

Referencias

  1. Building Internet Firewalls, de Elizabeth D. Zwicky, Simon Cooper y D. Brent Chapman

* Es muy sencillo, pero lo dejo para otra entrada 😉

**Estamos considerando que NO queremos reenviar (forward). Si quisiéramos hacerlo, ver el punto 3 de las consideraciones de OSPF que he escrito en la entrada. Además, estas reglas deben ejecutarse en los routers designados.

***Las reglas se deben de ejecutar en los router afectados (en rt_ext cuando ‘-s rt_ext’ o en rt_int si ‘-s rt_int’), salvo que dispongamos de un cortafuegos específico y, en ese caso, se ejecutan todas en él. Recordad que debe disponer de un túnel (ver **)


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.