La seguridad en redes

Como viajan los datos por la red

El viaje por la red

Entender como viajan nuestros datos por la red es fundamental para entender las tipologias y las medidads de seguridad que se deben aplicar. Para cualquier usuario no técnico, la estructura de la red es algo similar a:

El usuario, no se plantea nada más, solo sabe que se tiene que conectar a un router , y por lo normal, tampoco tiene claro que comporta.

Pero las comunicaciones en una red son de carácter estructurado, necesitan de un mismo código para que miles de dispositivos diferentes puedan hacer uso de la misma estructura. Estos códigos, mecanismos, estructuras, se les llama protocolos, y podemos encontrar muchos por la red, algunos incluso ya en desuso. Un ejemplo de la multitud de protocolos los podemos encontrar en todos aquellos que aceptan conexiones 5 GHz:


Protocolo	Frecuencia	Velocidad máxima
802.11ax	2,4 o 5 GHz	2,4 Gbps
802.11 ac wave2	5 GHz	1,73 Gbps
802.11 ac wave1	5 GHz	866,7 Mbps
802.11n	2,4 o 5GHz	450 Mbps

Cada uno de estos protocolos tiene su propio documento donde se explica como funciona.

Dividimos los protocolos por capa

Ya sabemos, que nuestras conexiones funcionan a través de protocolos, que nos sirven para que las computadoras se pueden intercambiar información a través de la red. Estos protocolos los dividimos por capas, la idea es que cada una de las capas se ocupe solo de una tasca. El concepto es el siguiente, cada capa recoge los datos de una forma predeterminada y las entrega a los protocolos de la siguiente capa de una forma predeterminada, también. De esta forma, protocolos diferentes pueden trabar entre si. Vamos a poner un ejemplo:

Un usuario está en una cafetería haciendo uso de la conexión WiFi que se ofrece de forma gratuita gracias al café con leche que se está tomando. El vídeo sale del servidor, llega al router de la empresa en cuestión, viaja por Internet, llega al router WiFi de la cafetería, y después nos llega a nuestro dispositivo. Fijaros que nuestro reproductor de vídeo (una aplicación dentro de nuestro ordenador) decidirá si quiere mostrar el vídeo en streaming en directo, o si quiere descargar el vídeo i mostrarlo más adelante. Todo el viaje que hagan los datos del vídeo, es independiente de esta decisión, si el vídeo ha estado viajando por routers de Bélgica, Dinamarca, o Suecia, será independiente de como se haya reproducido el vídeo: esto son las capas (layers), una decisión no altera el resto de capas, solo alterará aquellas capas que sean responsables de ese proceso.

En la actualidad coexisten dos modelos, el OSI y el TCP/IP. En estos materiales haremos servir el modelo OSI para las cuatro primeras capas, pero en cambio, las tres últimas capas las agruparemos como hace el modelo TCP/IP. Aquí tenéis un gráfico donde se muestran las capas según el protocolo:


Modelo OSI	Protocolos más comunes	Modelo TCP/IP	Qué envía?
7 - Capa de aplicación	HTTP, SSL, FTP, SQL, SMB...	Capa de aplicación	DATA
6 - Capa de presentación
5 - Capa de sesión
4 - Capa de transporte	TCP, UDP	Capa de transporte	Segmento
3 - Capa de red	IPv4, IPv6, ARP, ICMP	Capa de Internet	Packet
2 - Capa de enlace	MAC	Capa de acceso a la red	Frame
1 - Capa física	MAC	Capa de acceso a la red	Bits

Protocolos y dispositivos

Otro aspecto importante, es que los dispositivos de red solo son capaces de trabajar con aquellas capas que están predestinados a trabajar. Por ejemplo, por lo normal, un switch solo sabe trabajar con la capa 2, esto quiere decir, que no es capaz de leer IP, está en una capa diferente. En cambio, un 'router', solo trabaja con la capa 3, i por tanto, puede trabajar con IPs (Hoy en día, nos podemos encontrar con dispositivos que trabajen en más de una capa).

Capa de aplicación

Esta forma de ir construyendo las capa y que cada dispositivo trabaje con los datos de una capa en concreto se consigue a través de la construcción de un conjunto de datos que viajarán por la red. Imaginemos el ejemplo anterior: queremos enviar un vídeo. Nosotros tenemos el vídeo en formato mp4 (una sucesión de bits), pues no solo enviarán los bits del vídeo en si, si no que también se enviará la información del tamaño, la ratio de comprensión, las pistas de audio,... un conjunto de información que nosotros veremos como un solo archivo mp4.

Pero este archivo, nosotros lo queremos enviar encriptado, de esta forma lo podremos enviar de forma confidencial al receptor. Para hacerlo, se necesitará encriptarlo con algún mecanismo de encriptación, clave pública/privada o clave simétrica, la elección no afectará a las otras capas, solo afectará a la capa de aplicación, la responsable de los protocolos de encriptación. Una vez encriptado este archivo, se envía el archivo a la tarjeta de red de nuestro servidor, la cual será la encargada de transformar todo este conjunto de datos (vídeo mp4 + encriptación) a través de Internet.

Capa de transporte

En al capa siguiente, nos encontraremos los protocolos que trabajan normalmente con el software de la tarjeta de red. Una vez nosotros hemos decidido enviar el vídeo, queda una decisión importante que afectará solo a la capa de transporte: decidir si lo enviaremos por streaming o si lo descargaremos de forma indirecta. Es decir, si usaremos el protocolo UDP o el protocolo TCP. A más a más, esta capa que conoce como se enviarán los paquetes, también es la responsable de dividir el conjunto de datos que queremos enviar, en paquetes más pequeños que puedan ser soportados por toda la infraestructura de la red.

El tamaño máximo y mínimo se conoce como MTU y las tarjetas de red que trabajan en la capa de transporte son capaces de ir negociando según la fluidez de nuestra red. Por eso, siempre estamos descargando a velocidades diferentes.

Toda esta información quedará recogida en los datos que añada el dispositivo a la capa de transporte y se conoce como segment:


32 bits
0-3	4-7	8-11	12-15	16-19	20-23	24-27	28-31
Source Port				Destination Port
Sequence number
Acknowledgement number
Bits de control				Windows size
Checksum				Urgent pointer
Options
Data Optional

Fijaros, que cada una de las opciones ocupa un nombre de bits concreto, por ejemplo, el puerto de origen tiene 15 bits, esto quiere decir que es imposible que haya un puerto más grande que 65.536 (2¹⁶). Así pues, la capa de transporte es capaz de conocer la cantidad de paquetes que ha provocado la conexión, el origen y el destino del puerto, y tambien controla el tamaño de los paquetes que se envían con el valor de windows size.

Capa de red

La capa de red es la que se encarga de enviar los datos entre redes. Es la encargada, por ejemplo, de conectar nuestra red de casa con las redes de los servidores de juegos en línea.

Algunos de los protocolos más conocidos son el IPv4, el IPv6 y el ICMP. Los dos protocolos de enrutamiento son IPv4 y IPv6, y cada uno de ellos tiene sus características. En esta capa, podemos observar la idea esta de las capas independientes. A finales del s. XX solo existía el protocolo IPv4, este protocolo permitía un total de 2³² de IPs tal y como muestran sus headers:


IPv4
32 bits
0-3	4-7	8-11	12-15	16-19	20-23	24-27	28-31
Ver	IHL	TOS		Total Length
Identification				Flags	Fragm offset
TTL		Protocol		Header Checksum
Source address
Destination address
Options - Up to 40 bytes
Data + Segment - Up to 65515 bytes

Esta era un total de unos 4.000 millones de dispositivos posibles, al principio se pensó que era suficiente, pero a finales del s. XX se vio que acabaría colapsando el sistema de IPs y que se requería de una solución técnica para ello. No era una solución general a todo Internet, no se buscaba una solución para todas las capas, si no que solo se requería una solución para la capa de red, aquí está la bondad de dividir el tráfico de red en capas.

En este contexto, justo el mismo año 1996, aparecieron dos soluciones diferentes para el mismo problema: la primera solución era el nuevo protocolo IPv6, el cual permitía tener IPs con 128 bits, y con ello, dispositivos casi ilimitados (340 sextillones), a más, el nuevo protocolo permitía, por ejemplo, que el propio dispositivo se autoconfigurara su IP sin necesidad de servidor DHCP y con solo la ayuda de los dispositivos vecinos.


IPv6
32 bits
0-3	4-7	8-11	12-15	16-19	20-23	24-27	28-31
Ver	Traffic class		Flow label
Payload length				Next header		Hop limit
Source address 128 bits (4 rows)
Destination address 128 bits (4 rows)
Data + Segment - Up to 65515 bytes

Este protocolo IPv6 tiene una implantación diferente según los países, la media del uso de IPv6 de la UE se sitúa entorno al 40%, pero en España no supera el 10%, a la espera que la nueva política de IPs de Movistar cambie un poco el panorama.

La poca implantación del protocolo IPv6 en España, y otros países, es debida a que en el mismo 1996 apareció otro nuevo protocolo, una variante de un protocolo existente (NAT): el NAPT (Network Address and Port Translation, aunque hoy en día se le conoce como NAT), se trata de un protocolo que utiliza un dispositivo de capa 3 que controla una red interna, como por ejemplo un router. Para poder tener más IPs, se asignan diversas IPs privadas a nuestros dispositivos de la red interna, y todos ellos, comparten una sola IP pública.

Las redes privadas estan preasignadas y solo puede ser: 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. Esto hace, que a nivel mundial, puedan haver muchos dispositivos compartiendo a la vez la IP: 192.168.0.1, pero es una IP que solo estará en redes locales, nunca expuestas a Internet. En conclusión, ya vemos que un problema en un protocolo de una capa, se soluciona dentro de la misma capa con nuevos protocolos como IPv6 o NAT, y al final, será responsabilidad del administrador IT quien decida por cual opción se decide.

El otro protocolo importante dentro de la capa de red es el ICMP. Es un protocolo que tiene su pequeño debate, pues por convención se acepta que forma parte de la capa de red, pero requiere de los protocolos de enrutamiento para funcionar. Por tanto, en el datagrama añadiremos el protocolo de enrutamiento IPv4 o IPv6, y luego, los datos del protocolo ICMP.

Los headers de ICMP son:


ICMP
32 bits
0-3	4-7	8-11	12-15	16-19	20-23	24-27	28-31
Type		Code		Checksum
Identification				Number of sequence
Options - Up to 40 bytes
Data - Up to 576 bytes

La combinación entre los types y los codes, nos ofrecen una información muy diversa, tenéis más información en esta tabla en la Wikipedia.

Una de las vulnerabilidades más típicas de esto protocolo es la posibilidad de incluir información extra (576 bytes) dentro de el paquete. Estos datos extra se usan para lo que se conoce como Ping of Death o para crear un tunneling.

Capa de enlace

Los últimos protocolos que veremos son los de la capa de enlace de datos. En los dispositivos de casa, este protocolo normalmente se implementa en nuestras tarjetas de red y en el típico router wifi que tenemos todos. Es el protocolo que se responsabiliza, por un lado del direccionamiento interno de la red, y por el otro, lleva el control de flujo de información que vamos transmitiendo, por ejemplo, es quien se encarga de conocer el medio por donde viajará la información y se adapta a ello.

Para lograr el direccionamiento interno, se utilizan las direcciones MAC, direcciones de 48 bits que tienen todos los dispositivos i que son irrepetibles en todo el mundo. Muchas veces escucharéis que la dirección física es la MAC y que la dirección lógica es la IP.

Los dispositivos de red que trabajan normalmente en la capa 2 son los switchs, todos ellos tienen una tabal donde se relaciona cada uno de sus puertos con las MAC que pueden haber en ellas. La forma en como se asigna una interface y una MAC es una de los aspectos más vulnerables de nuestra red y requiere que se configure correctamente:

Se debe apagar todas los puertos de interface que no se vayan a usar.
Es una buena práctica, solo aceptar una MAC por interface y no sea intercambiable.
Evitar la redundancia en la red habilitando el Spanning Tree Protocol.

A más, los switchs más sofisticados tienen más funciones de seguridad para evitar intrusiones y ataques de Man-in-Middle. Para cualquier pentester que acceda a nuestra red, lo primero que intentará seguramente sea probar ataques tipo de capa 2. A más a más, hoy en día se puede modificar la MAC de nuestro dispositivo con software, y por tanto, es relativamente fácil general una suplantación.

En la capa 2, tenemos dos protocolos que se usan muchos, el protocolo que se usa para conectar nuestro dispositivo mediante cableado: Ethernet - 802.3; y el protocolo que usamos para conectarnos wireless: WiFi - 802.11.

El protocolo Ethernet tiene los siguientes headers:


Ethernet 802.3
32 bits
0-3	4-7	8-11	12-15	16-19	20-23	24-27	28-31
Preamble							SFD
MAC destination
MAC Dst				MAC Src
MAC Source
802.1Q tag (VLANS - Optional)
Ethertype or length				Start Payload
Payload: Packet + Segment + Data Up to 1500 bytes
Frame check CRC
IPG (12 bytes)

En cambio, el protocolo WiFi es más complejo, no solo porqué trabaja con tres direcciones MAC, si no por los primeros dos bytes del frame control, los cuales se encargan de mantener la sesión entre el dispositivo wireless y el punto AP.


WiFi 802.11
32 bits
0-3	4-7	8-11	12-15	16-19	20-23	24-27	28-31
Frame Control				Duration ID
MAC Wireless host or AP to receive frame
MAC W-AP				MAC Src
MAC Source - send frame
MAC Router APP is attached
MAC Router				Seq control
MAC ad hoc Mode
Mac ad hoc				Start Payload
Payload: Packet + Segment + Data Up to 1500 bytes
Frame check CRC

Arquitecturas de red

Evolución de la topología de redes

La evolución de las computadoras ha ido intrínsicamente al lado de la evolución de las redes. Al principio, la topología de las redes eran planas, todas las computadoras se podían ver entre ellas. Con la aparición de Internet, todo cambio y se empezó a aislar las redes entre redes privadas/locales LAN(Local Area Network) y las redes públicas/externas WAN (Wide Area Network).

Internet es la combinación de LANs y WANs. Esta era la idea hasta relativamente hace poco, una gran red global no segura hecha con un conjunto de redes privadas seguras. Esto provocó que se concentraran los recursos en la securización del perímetro que separaba ambas redes.

Con la entrada del nuevo siglo, esta visión fue superada y aparecieron nuevos conceptos como: DMZ, BYOD o VLANs; todos ellos en la línea de no entender la red interna como una red segura. Este nuevo paradigma es donde se está centrando el mercado de la seguridad en los últimos años. Debemos encontrar mecanismos para evitar y disminuir el riesgo que comporta estar conectados a la red.

El elemento clave, en la defensa perimetral de las redes ha estado el Firewall.

Firewalls

Un firewall es un dispositivo hardware, o una aplicación software, que tiene por objetivo evitar las intrusiones externas no deseadas a nuestra red. Trabaja con reglas dentro de la capa 2, 3 y 4 del modelo OSI: Esto significa que es capaz de filtrar por MAC, IP y Puerto (El filtrage por capa 2 no es común en todos los firewalls).

Muchas veces nos podemos encontrar con firewalls que funcionan internamente dentro de los routers de capa 3. Esto es así, porqué el propio dispositivo router permite configurar un conjunto de reglas para filtrar los paquetes entrantes. Pero también nos podemos encontrar que estos dos dispositivos estén separados. En este caso, el dispositivo firewall requerirá de dos interfaces con dos IPs (entrada y salida del tráfico de red). En estos casos, normalmente lo que haremos es que la puerta de enlace de nuestra red local sea nuestro firewall.

Los firewalls, como ya hemos comentado, trabajan sobretodo en capa 3 - red y en capa 4 - transporte. Por defecto, son capaces de leer los headers de los protocolos de estas capas. La parte interesante, es como trabajan en capa 4, pueden analizar una conexión como el conjunto de sus paquetes.

Una conexión se puede pot identificar con:

   * IP Origen
   * IP Destino
   * Puerto origen
   * Puerto destino
   * Protocolo de transporte usado (TCP/UDP)

Un beneficio de las conexiones, es que nos permite aceptar tráfico que haya estado solicitado desde el interior de nuestra red.

Así, el firewall está compuesto por un conjunto de reglas que determinan la política de seguridad del firewall. Este conjunto de reglas de control de acceso se llama Access Control Lists ACL. Las ACL son unas listas de reglas que definen unas condiciones, estas reglas se verifican de forma secuencial. Cuando un paquete que pase por nuestro firewall coincida con alguna de nuestras reglas, el firewall tomará la decisión de Aceptar o Bloquear según este especificado en la ACL.

Topología con conexión doble ('Dual-Homed')

La topología de red más sencilla posible es la DUAL, esta se caracteriza por la utilización de un router y un firewall. El router tiene la función de separar las dos redes, mientras que el firewall tiene la función de filtrar los paquetes que pasan de una red a otra. Como ya hemos comentado, muchas veces estas dos funciones las podemos encontrar juntas dentro de un mismo dispositivo.

Esta topología de red sencilla permite observar aspectos importantes:

El firewall se tiene que ubicar en algún sitio privilegiado de la red por donde pase todo el tráfico de la red que se quiere securizar.
Como los firewalls trabajan a escala de red, todo el tráfico que no salga de la LAN (por ejemplo entre un cliente y un servidor interno) no pasará por el firewall; de manera que si comprometemos un equipo interno, puede llevar a poner en serios compromisos a toda la red.
Es habitual que los firewalls coexistan en el mismo equipo que los routers, esto permite simplificar y abaratar el coste del despliegue de sistemas en una red. Pero también existe hardware especifico sin funciones de enrutamiento.

Esta solución la llamamos conexión doble (Dual-Homed) porqué el firewall tiene dos interfaces.

Topología con conexión triple ('Three-Legged')

Tener solo dos interfaces provocaba que los administradores de redes tuviesen de jugar al 'blanco o negro', o tratamos la red como segura o como completamente insegura. Por eso, tener tres interfaces permitía tener una para la WAN, una para la LAN y una última para la DMZ, y crear así una segunda red local con servicios abiertos a la red externa. Inicialmente, esta tercera red, conocida con el nombre de DMZ (DeMilitarez Zone) era visible toda ella desde la WAN, pero rápidamente se securizo con un conjunto de ACLs específicas para la DMZ y diferentes de las de la LAN.

En la siguiente imagen podemos ver una topología de red típica con DMZ:

Al final pues, la topología DMZ incorpora siempre tres juegos de instrucciones ACL:

   * Tráfico desde Internet hacia la DMZ y viceversa.
   * Tráfico desde Internet hacia la LAN y viceversa.
   * Tráfico desde la DMZ hacia la LAN y viceversa.

Por lo normal, las ACL siguen los siguientes criterios:

   * Denegar todo el tráfico de entrada a la LAN exceptuando el que es originado como una petición interna.
   * Solo permite el tráfico a los puertos de los servicios públicos de la DMZ, bloqueando el resto, a excepción de la respuestas a peticiones internes de la DMZ.
   * Dependiendo de la política de seguridad, el criterio de conexiones entre la LAN y la DMZ puede ser igual de restrictivo que desde Internet, o bien, se puede permitir la conexión a servicios especiales para la LAN.

Balanceo de carga

En la actualidad, las topologías de red han aumentado su complejidad ya que la mayoría tiene por objetivo su escalabilidad. Para ello, una de las opciones que tenemos es usar los balanceadores de carga. De esta forma podemos mejorar la disponibilidad de nuestros servidores y garantizar la simultaneidad de varias peticiones.

Hay varias técnicas para poder ofrecer un servicio escalable, pero en todos los casos se necesita soporte a través de la red local, y generalmente, se necesita distribuir la carga entre varios nodos. Esta distribución recoge las peticiones de tráfico que recibe un dispositivo y las distribuye de la forma óptima que haya configurado el administrador IT. Tenemos dos alternativas para el balanceo:

 * balanceo de carga por medio del Enlace de Dataos (L2) 
 * balanceo de carga por medio de la Red (L3).

Balanceo de carga en L2

El balanceo de carga por medio de la capa 2 se consigue duplicado las interfaces de los switchs. La duplicación de una interfaz nos permite que el propio switch gestione por donde enviará el tráfico. Esta configuración se puede hacer directamente en nuestro switch.

Lo llamamos de capa 2, ya que la distribución se hace con las MAC, el identificador que tienen todos los dispositivos conectados a una red, en ningún momento varia el header de la capa IP.

Todos los switchs tiene una tabal donde se relaciona una MAC con una interfaz.

Los protocolos de la capa 2 no tienen en cuenta la red global ni las IPs; solo tienen conocimiento de su red local y de las direcciones MAC. Así, estos protocolos puedes distribuir las peticiones entre equipos diferenciándolos a través de la MAC.

Balanceo de carga en L3

En contraposición al balanceo de capa 2, en capa 3 si se tiene constancia de la red, y por tanto, podemos reenviar el tráfico tiendo en cuenta el equipo de origen y de destino. Como se puede ver en la imagen, para poder hacer el balanceo, tendremos una IP pública (normalmente apuntando a nuestro router), y una vez llegue a nuestra red un Proxy será el responsable de reenviar la petición al servidor interno que decida. Los proxy nos permiten enviar las peticiones, según los parámetros que hayamos establecido, al servidor que decida y cada uno de ellos con una IP diferente para que el proxy pueda diferenciarlos.

En este tipo de infraestructura, siempre es mejor poner el firewall antes de nuestro proxy. A más, también se deberá prestar atención para que el resto de nuestra infraestructura pueda soportar el balanceo de carga y no se generen problemas de escalabilidad.

Por tanto, tendremos que estar atentos que todo nuestro flujo de tráfico llegue a nuestros servidores. La configuración de la red puede soportar este tipo de sistemas, pero tendremos que tener cura en la replicaciones de direcciones IP.

Este modelo de balanceo de carga tiene variantes, una de ellas se basa en poder ofrecer alta disponibilidad a través de al redundancia, es decir, no se trata de poder distribuir el tráfico de red según la carga de trabajo, sino de ofrecer alternativas en nuestra red en caso de fallo. Para ello, la IP comuna se llama IP flotante y varia de un equipo a otro, los protocolos Virtual Router Redundancy Protocol (VRRP) o Heartbeat decidirán a que IP enviar las peticiones y comprobar su disponibilidad.

Las vulnerabilidades de los protocolos

Capa física

Cada una de las capas tiene sus propias características, a veces nos puede parecer que la capa física la tenemos como olvidada, pero aún en la capa física tendremos que estar atentos a sus vulnerabilidades.

Los principales ataques a la capa física son los referenciados a la denegación de servicio DoS, a la captura de datos en vivo, y por último, el robo y acceso de nuestros dispositivos.

Los ataques DoS se pueden provocar a través de interferencias con señales eléctricas, pues podemos alterar las señales generando ondas de interferencia en la WiFi, o podemos generar corrientes eléctricas que alteren la señal de Ethernet.

Los ataques de escucha se puede suceder tanto en Ethernet como en la red WiFi. En la ethernet a través de splits que nos permiten duplicar el tráfico de red y redirigirlo de forma transparente a los usuarios. Si somos capaces de introducir un split en una red interna, podremos analizar todo el tráfico que pase por la misma. Las redes inalámbricas son más fáciles de escuchar, pues solo hace falta tener una antena WiFi en modo escucha y recibiremos todas las comunicaciones, pero normalmente tienen el tráfico encriptado entre el punto AP y el cliente. Para poder leer todos los paquetes del tráfico de red necesitaremos una aplicación como Wireshark.

La escucha de información que se transmite entre usuarios puede comportar problemas importantes de fuga de información y es fácil de hacer cuando los usuarios no encriptan sus datos. El análisis de tráfico intenta extraer la máxima información posible de las comunicaciones entre estos.

Capa de enlace de datos

La capa de enlace de datos no es segura y la mayoría de sus protocolos parten de una confianza que no existe como tal, por tanto, es una capa altamente vulnerable y que requiere de configuraciones y software para evitar males mayores. La capa 2 es una capa local, por eso parte de la sí confianza. Por tanto, tenemos que evitar los accesos no deseados a nuestra red local, no podemos permitir que dispositivos no deseados entren en nuestra red.

Así pues, las vulnerabilidades de esta capa son:

Denegación de servicio: Tenemos varias opciones, podemos hacer falsificaciones en la tabla ARP, generar mucho ruido de tráfico interno, crear bucles infinitos o falsificar la MAC.
Escucha de tráfico: Un switch, a no ser que esté bien configurado, se le puede provocar lo que se conoce como MAC flooding, la idea es inundar de MACs un switch hasta que no tenga espacio suficiente para guardar los nuevos registros en su de referencia MAC-Interfaz. Cuando llegue este momento, para evitar ataques tipo DoS nuestro switch reenviará todo su tráfico por todas las interfaces, ya no hará caso de tabla.
Suplantación Spoofing: Dentro de una red interna, todos los dispositivos muestran de forma pública su IP y su MAC a través del protocolo ARP. Esto quiere decir, que es fácil conocer la IP y la MAC del dispositivo al que queremos suplantar. Por tanto, la suplantación passa por autoasignarse la misma IP y MAC de la máquina víctima y enviar paquetes al switch para que asigne la MAC a la nueva interfaz del atacante. Los switchs construyen la tabal de referecia MAC-Interaz a través de los paquetes que les entran por su interfaz, si ha entrado un paquete con una MAC de origen diferente a la que tenía, entonces actualiza la tabla y asigna la nueva MAC a la interfaz. Usando este funcionamiento, podemos ir haciendo peticiones vacías para que el switch siempre apunte a la máquina del atacante.

Capa de red

A nivel de red, la cantidad de posibles ataques también es muy alta, ya que ahora el acceso es global por todo Internet, y por tanto, los posibles orígenes de los ataques son infinitos. Aún así, los tipos de ataques son bastantes similares: Denegación de servicio, suplantación, y escucha de tráfico.

Los protocolos de red (IPv4, IPv6 y ICMP) no parten de la desconfianza, por eso tienen deficiencias grabes de seguridad:

En ningún momento del protocolo, se comprueba la identidad del emisor.
En ningún momento del protocolo, se comprueba si existe el destino.
En ningún momento del protocolo, se encriptan los datos.

Por tanto, fijémonos que si somos capaces de controlar un dispositivo de capa 3 por donde pase el tráfico de red de nuestra víctima, podremos hacer fácilmente ataques del tipo Man-in-the-Middle. Pero también, podremos redirigir el tráfico hacia donde nos interesa, sin que el emisor sea capaz de poderlo comprovar.

A más, a diferencia de la capa 2, aquí la red es global, y por tanto las vulnerabilidades están expuestas a todo Internet, nunca debemos olvidar que: Los protocolos de red y de enlace de datos no tienen mecanismos para certificar el origen y destino de las comunicaciones, nada de los que veamos por Internet tiene porque ser lo que queríamos ver. Todo puede ser falsificado, y por tanto, uno de los principales objetivos de la capa de aplicación será buscar mecanismos para proteger estas deficiencias de seguridad.

Pero no solo es un problema para la confianza, si no que también tendremos problemas para la integridad y la confidencialidad de la información. La información siempre se envía en abierto, no hay hay ningún mecanismo que permita ocultar la IP de destino o origen, ni tampoco el puerto de destino origen, esta información siempre irá en abierto, y cualquiera que tenga el control de un dispositivo de capa 3 por donde pase el tráfico, tendrá acceso a esta información, y por tanto, podrá modificar los headers a su antojo.

El único aliado en la capa 3, cosa en la capa 2 no, será el cortafuegos, el cual normalmente trabaja en capas 3-4 y puede filtrar el contenido que afecte a nuestros dispositivos.

Capa de transporte

La principal vulnerabilidad en la capa de transporte es el hecho que nuestro tráfico apunta a un puerto, e indirectamente, estamos informando del servicio solicitado por el usuario. Por tanto, es una capa que afectará a las aplicaciones que corran detrás del puerto en cuestión.

El ataque más conocido es la denegación de servicio, generalmente a través de la inundación de paquetes TCP o UDP (TCP/UDP Flooding):

TCP Flooding: se basa en el envío de paquetes corruptos TCP al destino. Una opción es el SYN floodiong donde aprovechamos el 3-way handshake del protocolo TCP para forzar la aplicación de destino a mantener muchas conexiones abiertas y así generar la denegación de servicio.
UDP Flooding: la idea es la misma , pero normalmente no es tan efectivo porqué el protocolo UDP es del tipo sin estado.

El último ataque a nivel de TCP que veremos es la predicción de secuencia con TCP (TCP Sequence prediction). En este caso, el atacante busca envenenar una comunicación adivinando el número de secuencia TCP en un flujo de comunicación y de esta forma robar una sesión existente. Pero este tipo de ataques se ha vuelto muy complicado, puesto que la secuencia ahora es un número siempre aleatorio (2^32 bits).

La protección de la red

Segmentación lógica de una red

Una de las primeras opciones que tenemos para poder proteger nuestra red es segmentarla. La segmentación no hace que nuestra red interna sea más segura, no mejora la disponibilidad, ni la integridad, ni la confidencialidad.... lo único que hace es que las redes local sean más pequeñas con subdivisiones para que no se vean entre ellas. Lo que buscamos, es generar círculos de confianza más pequeños, se trata de generar pequeños conjuntos de red que puedan compartir un conjunto de configuraciones comunes.

Tenemos dos posibilidades para poder segmentar una red local:

Segmentarla a nivel de capa 2: VLAN
Segmentarla a nivel de capa 3: Subnetting.

Por tanto, para podemos dividir la red con los dispositivos de capa 2 y de capa 3, cada una con sus protocolos, pero al ser dos capas diferentes, también tenemos la opción de poder combinar la segmentación a nivel 2 y 3.

Segmentación mediante Subnetting

Hoy en día, aún os podéis encontrar materiales que os hables de las direcciones IP de tipo A, B, C y D, esto es así, porqué en las primeras épocas de Internet y del protocolo IPv4 ya se pensó en una Internet segmentada, donde cada organización controlaría un rango de IPs determinada y según el tamaño se les daría más o menos rango. Así pues, a las empresas grandes se les daría una IP de tipo A (millones de dispositivos), en cambio, a las pequeñas de tipo C (miles de dispositivos).

Se daba más o menos rango según la máscara de red que tenía cada tipo de IP, la parte buena es que la organización podía ir segmentando su IP de red en la medida que iba incorporando routers a su red y iba aumentando el valor de la máscara de red.

Fijaros en el gráfico siguiente:

El esquema anterior os muestra la creación de diferentes subredes. De todas ellas, las únicas que aceptaran una configuración viable en los dispositivos finales como los PC, son: 192.168.0.0/26, 192.168.0.64/26, 192.168.0.128/27, 192.168.0.160/27 i la 192.168.0.192./26. De una sola red: 192.168.0.0/24, han aparecido 5 subredes a través de la segmentación lógica de nuestra red. Esta técnica nos permite ir creando subredes según nuestras necesidades organizativas.

Pero el subnetting tiene dos problemas básicos:

La necesidad de diversos dispositivos routers únicamente para poder generar nuestras subredes.
La complejidad que se genera en la creación y mantenimiento de nuestra capa física, pues las diversas subredes no pueden compartir los recursos de capa 2.

Por otro lado, el gran beneficio del subneting es que podemos situar un firewall entre las subredes.

Segmentación mediante VLAN

Ya hemos visto antes como en los headers del frame de capa 2 hay un conjunto de bits que se reservan para la creación de VLANs. La idea básica, es que gracias al protocolo 802.1Q, tenemos la capacidad que nuestro switch divida la red de forma lógica, y por tanto, evite que los dispositivos de dos VLANs diferentes se vean entre ellos, como si estuvieran en dos LAN diferentes.

De esta forma, un administrador puede asignar un conjunto de interfaces de un switch a una misma VLAN, todos los dispositivos conectados a estas interfaces trabajaran como si estudiveran en la misma LAN. Cuando dos equipos de VLAN diferentes quieren comunicar-se lo tienen que hacer a través del roter y a expensas de ser filtradas por nuestro firewall.

Con esta nueva modalidad de segmentación de red se obtienen varias ventajas:

Se reduce la necesidad de dispositivos de capa 2-3 para subdividir la red.
Se ofrece la posibilidad de filtrar los paquetes entre VLANs mediante el firewall.
Permite separar la red en unidades funcionales más pequeñas, que pueden seguir la estructura organizativa de la empresa, por ejemplo, otorgar una VLAN para cada uno de los Departamentos de una organización.

A nivel de implementación, se tiene que tener en cuenta un par de cosas:

Quien es el encargado de escribir en la capa 2 la VLAN a 802.1Q
Qué pasa cuando varias VLANs comparten una misma interfaz.

El primer concepto es importante, ¿Quién escribe? ¿Quién hace el tagged? Una opción que tenemos es que nuestros dispositivos finales generen un tagged en la medida que envíen paquetes a la red. Todos lo sistemas operativos tienen la posibilidad de taggear nuestro tráfico de red (Windows, Linux). Pero no es muy común, pues es un tipo de configuración que requiere un esfuerzo extra por parte de los administradores IT, pues nos podemos encontrar que algún dispositivo no tenga la posibilidad de taggear, o que dificulte nuestra política de BYOD. Por eso, muchas veces nos encontraremos que quien taggea es directamento nuestro dispositivo de capa 2 (switch).

Esta decisión influenciará a la hora de administrar nuestro switch, pues una de las opciones que debemos configurar en nuestro switch es si nuestro puerto es tagged o untagged. ¿Qué cambia? Pues si ponemos tagged en nuestra interfaz del switch, éste esperará encontrarse el protocolo 802.1Q configurado con la VLAN correcta, y si no encuentra la configuración o es una VLAN diferente, descartará el paquete. Por tanto, si nosotros no hemos configurado los dispositivos tipo PC para taggear los paquetes de red, tendremos que configurar las interfaces del switch como untagged para que no descarte los paquetes.

Por otro lado, cuando queremos que dos VLANs diferentes compartan una misma interfaz, lo que haremos es definir la interfaz en modo trunk. Esto hará, que el enlace pueda ser compartido por las dos VLANs. A más, para poder diferenciar el tráfico, tendremos que definir las interfaz como tagged, es decir, tenemos que requerir que los paquetes estén bien etiquetados. Si no queremos que se descarte ningún paquete, lo más fácil será definir la VLAN por defecto dentro del rango de VLANs que acepte el modo trunk.

Tener en cuenta, que aunque nosotros no etiquetemos los paquetes cuando salen del PC y que pasen por una interfaz untagged, cuando llegan al switch que tiene definida una VLAN concreta, lo que hará el switch es etiquetar el paquete, y por tanto, estos paquetes ya podrán acceder a la interfaz del modo trunk. A más, como la capa 2 es la primera de las capas de headers, el switch no tiene que esperar a recibir todo el paquete para etiquetarlo.

Fijaros con el esquema siguiente de implantación de tres VLANs en una organización:

En el esquema podemos observar los siguientes aspectos importantes:

En total tenemos tres VLANs en toda nuestra organización.
El uso de recursos hardware es menor que si quisiéramos hacer lo mismo con subnetting.
Todos los PCs de una misma VLAN se pueden ver entre ellos.
El tráfico de red, entre dos PCs de una misma VLAN, no pasará por el router.
El tráfico de red, entre dos PCs de una VLAN diferente, sí pasará por el router.

En el esquema podemos observar como el enlace entre los switchs, y entre el switch y el router, será de tipo trunk y tagged. En cambio, los enlaces entre los switchs de cada planta con sus dispositivos, será de tipo untagged para cada VLAN definida.

Actualmente, la segmentación con VLANs está ampliamente utilizada gracias a su versatilidad y buen rendimiento general. Aún así, dadas las arquitecturas de nueva tendencia de como la nube, los contenedores y la virtualización, está haciendo cambiar su uso. Lo que históricamente se solucionaba con hardware, poco a poco está pasando a formatos basados en software, que ofrecen mejor versatilidad a las nuevas arquitecturas. Estamos pasando a modelos basados en microservicios.

El Proxy

A nivel de servicios, en la actualidad hay dos tendencias que estan provocando cambios a la hora de proteger las redes a través de la segmentación:

El cloud
Los containers

En relación a la nube (cloud), tenemos la posibilidad de generar túneles VPN, y a partir de aquí, podemos crear redes del cloud como si fueran internas y generar nuevas segmentaciones específicas para cada uno de los servicios.

En relación a los contenedores (containers), su configuración es un poco más complicada. La idea de los containers es ofrecer servicios lo más atómicos posibles, microservicios orientados a su final, y por norma general, estos reciben la configuración de forma automática en el moment que se sube el container.

Uno de los aspectos más importantes y que ha ayudado al éxito del container es la capacidad que tienen para auto-escalarse. Es técnicamente fácil, doblar un microservicio cuando el primero tenga una sobrecarga de trabajo. Esto comporta por eso un reto importante, cuando un paquete llegue a nuestra red, como sabemos el estado actual de la red y sus microservicios? La respuesta es el Proxy.

Un Proxy es un equipo que intercepta tráfico a nivel de aplicación y es capaz de administrarlo según los requisitos que se hayan definido. Pueden trabajar como si fueran un firewall con la ventaja que trabajan los datos a nivel de aplicación. Muchas aplicaciones que se nos muestran como firewall, son en su núcleo proxys, como en el caso de los WAF (Web Application Firewall), y sin las limitaciones típicas de los firewalls que no leen en capas de aplicación. Un proxy es capaz de saber:

El estado de cada uno de los microservicios
El nombre de peticiones hechas, resueltas y bloqueadas en cada uno de los microservicios.
La carga general de todo el sistema.

Con estos datos, el proxy es capaz de ir redirigiendo el tráfico entre los diversos microservicios que estén subidos.

Todas estan ventajas, van asociadas también a inconvenientes que se deben tener en cuenta:

Las conexiones cifradas no siempre pueden ser interceptadas. Por ejemplo, podemos interceptar el intercambio de claves, pero si lo hacemos, los protocolos PKI de certificados digitales de la aplicación detectaran que la llave pública enviada no està generada por el servidor, si no que ha estado hecha por nuestro proxy.
Cuando nosotros enviamos un paquete por Internet, la capa 4 de transporte es la encargada de dividir los paquetes, enviarlos de uno en uno, y después volverlos a juntar para que la capa de la aplicación reciba el paquete originario. Un proxy, necesita de todo el paquete originario a diferencia del firewall, por tanto, habrá una demora en su funcionamiento.

El Cortafuegos Firewall

El firewall es un dispositivo de Software o Hardware que permite controlar el acceso entre dos redes y ofrece una capa de seguridad a los protocolos de capa 3, 4 y algunas opciones de la capa 2. Los firewalls pueden trabajar de diversas formas:

Un Software en un dispositivo final como un PC, como el firewall de Windows o Linux.
Un Software en un router, a veces forma part del mismo soft, y a veces se instala como separado.
Un Hardware único de una opción comercial concreta como los firewalls de Palo Alto.

El funcionamiento en estos tres casos siempre acaba siendo el mismo, tenemos un conjunto de reglas conocidas como ACL (Access Control List), la cuales acaban determinando si se deja pasar el paquete o se bloquea. Toda la información que genera el firewall, como por ejemplo: cuantos paquetes ha dejado pasar, que paquetes han quedado bloqueados, etc...; quedan guardados en un log, y será tasca del administrador IT determinar el nivel del log que queremos que se vaya publicando (Un SIEM es capaz de poder leer los logs de un firewall' y levantar alarmas cuando considere oportuno).

Un aspecto importante de las ACL es que el firewall las lee en orden. Si nosotros tenemos una configuración similar a:

ACCEPT port 80
DENY ALL

La primera ACL será que acepte paquetes en el puerto 80, por tanto, en este ejemplo solo aceptarían paquetes a este puerto, todo el resto de tráfico quedaría bloqueado.

Por tanto, hay dos grandes políticas posibles a la hora de configurar nuestro firewall, podemos crear una ACL a partir de una lista negra (se detalla todo aquello que queremos bloquear), o creamos una ACL a partir de una lista blanca (detallamos lo que queremos dejar pasar). La segunda opción es siempre más segura, es la opción donde todo el tráfico queda bloqueado, exceptuando aquel que cumpla con alguna ACL.

El firewall de iptables

En la actualidad, iptables está siendo suplantado por varios inconvenientes, pero para entender las soluciones más actuales, es mejor hacer un repaso antes al iptables, ya que todas las nuevas propuestas Linux siguen basándose en iptables.

Una de las nuevas adaptaciones ha sido por ejemplo UFW, el firewall de la distribución Ubuntu , que ha apostado por la sencillez y por una visión muy amigable. Un firewall muy cómodo para el día a día.

Pero antes de entrar a fondo con iptables, necesitamos entender el funcionamiento interno del tráfico y el tipo de reglas y tablas con las que trabaja.

Entender este esquema es clave para entender el funcionamiento de iptables. Es bastante común saberse aquellas ACL principales, pero un buen administrador IT tiene que ser capaz de entender su funcionamiento y crear las reglas que se requiera en cada momento.

Si os fijáis, el esquema tiene dos entradas y salidas posibles, este será el tráfico de cualquiera de nuestros dispositivos Linux, o el tráfico proviene de fura o es generado por alguna aplicación, y viceversa, o se envía tráfico a alguno aplicación o se envía tráfico a través de la red. Una opción, que podemos ver recogida, es que a veces podemos encontrar tráfico que puede provenir de una red y después ir a otra red (un 'router').

Después, cadascuna de las fases por donde se va moviendo nuestro tráfico se llama chain y en total tenemos cinco: PREROUTING, FORWARD, POSTROUTING, INPUT y OUTPUT. Estas cadenas nos sirven para determinar donde se encuentra el paquete que queremos filtrar. Por ejemplo, si tenemos el paquete en POSTROUTING, significará que está a apunto de ir a la capa de red; otro ejemplo, si tenemos el paquete en INPUT, querrá decir que está a punto de entrar en nuestra aplicación.

Pero toda esta información, aunque parezca que se guarde en chains, no es así, si no que las ACL se guardan en las tablas que tenemos: mangle, nat y filter. Cada una de estas tablas tiene una función y una semántica diferente:

MANGLE: Nos permite la modificación de los headers de los paquetes de la capa 3 y 4.
FILTER: Es la tabla que nos permite filtrar los paquetes en la capa 3 y 4.
NAT: Es la tabla que nos permite configurar el protocolo Network Address Translation (antes explicado).

Así pues, si queremos crear una ACL que permita el tráfico SSH por el puerto 22 de una IP predeterminada, haríamos:

sudo iptables -A INPUT -s IPDeterminada -p tcp --dport 22 -j ACCEPT

Y automáticamente iptables añadiría la ACL en la chain de INPUT y en la tabla de filter. A partir de aquí, las opciones son múltiples, pero en la actualidad Debian recomienda trabajar con 'nftables', el firewall que por defecto tiene la versión de Debian 11 Bullseye.

El firewall de nftables

Nftables aún es una aplicación relativamente nueva, lo más normal es que de momento aún os encontráis con configuraciones basadas en iptables, y parte de vuestra tasca inicial sea la de traducir iptables a nftables. Una opción que tenemos disponible es la de usar un traductor automático:

$ iptables-translate -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
nft add rule ip filter INPUT tcp dport 22 ct state new counter accept

Nftables es una aplicación más bien compleja, iptables ya no era un firewall extremadamente amigable (en comparación con UFW), pero nftables ha augmentado su complejidad. Podéis encontrar más información de nftables en su docWeb: wiki nftables.

Para utilizar nftables se debe tener presente:

Las tablas están definidas por el tipo de familia (netdev, ipnet, ip, ipv6 y bridge) y la función que desarrolla (filter, nat o route).
Las cadenas chain estan definidas por las chain type hook y la tabla definida en el punto anterior (tipo de família y función).
Dentro de cada hook se incluye el conjunto de ACLs.

Fijémonos ahora, con el esquema siguiente para entender mejor la diferencia entre hooks, cadenas y familias:

Como podemos observar, hay lo que se llama familias de tabla, una agrupación de las posibles tablas existentes según el protocolo de red con el que trabajan:

Inet, Ip, Ipv6: son tres familias diferentes, pero las tres se refieren el protocolo IP. La familia 'Ip' para las IPv4 y la familia 'Inet' para cuando nos queremos referir a IPv6 y IPv4 a la vez.
bridge: es el tipo de tabla que visualiza el tráfico que pasa por los bridge.
arp: son aquellas tablas que visualizan el tráfico de red que genera el protocolo ARP.
netdev: tienen un funcionamiento una poco diferente, son tablas relacionadas directamente con el ingreso del tráfico en una interfaz. Se pueden usar para generar balanceadores de carga.

Cada una de estas tablas tiene sus chain type base (tipo de cadena de base):

filter: son las tablas de ACL que se encargan de filtrar los paquetes.
route: son las tablas de ACL que se encargan de enrutar los paquetes.
nat: son les tablas de ACL encargadas de aplicar el protocolo NAT (Network Address Translation).

Con las family type y las chain type base se construyen las tablas en nftables. Por ejemplo, si queremos crear una tabla que filtre paquetes entrantes IP (IPv4 y IPv6):

# nft add table inet filter

Una vez hemos creado una tabla, debemos crear las diversas chains (cadenas) que poblarán la tabla. Las cadenas se agrupan por hoooks, que son 'momentos', o puntos en el proceso de tráfico de nuestras conexiones:

ingress: solo para netdev, es justo en el momento cuando nuestra conexión llega a nuestra tarjeta de red y previo al PREROUTING.
prerouting: es el momento que llega el tráfico de red, visualiza los paquetes antes de cualquier decisión.
input: visualiza todo el trfáico de red antes de redirigirse a nuestra sistema local (aplicaciones locales).
forward: visualiza todos los paquetes que no se redirigen a nuestra sistema local.
output: visualiza los paquetes originados por nuestra sistema local (aplicacions locals).
postrouting: visualiza los paquetes después de redirigirlos fuera de nuestro dispositivo.

En nftables, podemos incorporar el conjunto de tablas, cadenas y ACL a través de rulesets ( a más de hacerlos con la comanda de nftables). De esta forma, podemos cargar todo el firewall a la vez y es más fácil de administrar. Siguiendo con el ejemplo anterior, nuestro ruleset de momento quedaría de la forma siguiente:

table inet filter{
  chain services {
    <<<ACLs>>>
  }
  chain input {
    <<<ACLs>>>
  }
}

Este rulset fijaros que genera una tabla que filtra paquetes IP y que tiene dos chains. El nombre de las cadenas puede ser aleatorio.

Para poder definir las cadenas usaremos la expresión type:

table inet filter{
  chain services {
    type filter hook input priority 0; policy accept;
    <<<ACLs>>>
  }
  chain input {
    type filter hook input priority 1; policy droop;
    <<<ACLs>>>
  }
}

En este caso, hemos definido dos cadenas en el mismo hook, esto es así gracias a priority. Aunque las dos cadenas estén en el mismo hook (INPUT HOOK), primero se analizará la cadena services y después la cadena input (atención, con que el nombre input es libre, podemos llamarla como queramos).

Otro aspecto interesante es la política por defecto, la primera cadena usa lo que antes comentábamos como lista negra, acepta todo el tráfico de red pero creará bloqueos por protocolos que no acepte; por contra, en la cadena input usamos el concepto de lista blanca, bloqueará todo el tráfico de red excepto aquellas ACL que permitirán el paso.

También atención con la prioridad y las políticas por defecto, fijaros que si intercambiásemos las prioridades, podríamos provocar que todo el tráfico de red quedase bloqueado por defecto.

Ara ya somos capaces de crear chains, establecer prioridad y políticas por defecto, y todo esto en el conjunto de nuestro firewall.

Todos estos rulesets se pueden cargar como un fichero a nuestro nftables de la siguiente forma:

% nft -f file_ruleset

Un pequeño truco para poder ir actualizando nuestro conjunto de reglas es hacer que, antes que nos cargue las nuevas reglas, limpie las existentes. De esta forma, siempre podemos subir el archivo entero. Para hacerlo, en la primera línea de nuestro archivo escribiremos flush ruleset y os quedaría de la siguiente forma:

flush ruleset

table inet ...{
.
.
.
}

También tenemos la opción de crear nuestras tablas y cadenas desde la línea de comandas, tanto con bash, como con la propia consola de nft (nft -i). Si lo hacemos desde el bash escriviremos nft 'add table...' , todo entre comillas. En cambio, si lo hacemos des de la consola de nft pondremos directamente la orden sin el nft.

Así pues, si queremos crear una tabla y después una cadena como el anterior ejemplo, haríamos:

% nft 'add table inet filter'
% nft 'add chain inet filter services { type filter hook input priority 0; policy accept; }'

El conjunto de reglas ACL en nftables

Ara ya solo nos queda saber crear nuestras reglas ACL y incluirlas a nuestro firewall. Es un proceso minucioso, que requiere de una comprobación constante del funcionamiento correcto de todo el sistema.

Las reglas de un firewall estan formadas por condiciones, estas pueden estar referidas a la gran mayoría de campos de los headers, tanto a nivel de red como de transporte.

Algunas soluciones comerciales también ofrecen que sus firewalls trabajen a nivel de aplicación, ofreciendo de esta forma, una mayor profundidad en el escaneo de paquetes para así mejorar la seguridad.

Pero no es así con nftables, el cual solo trabaja en capas 3 y 4. No por eso es una mala solución, no os olvidéis que es el nuevo firewall que marcará una época en Debian, una de las distribuciones por excelencia de Linux.

Y por otro lado, tenemos soluciones como los WAF Web Application Firewall o los Proxies que ofrecen funciones similares a las de un firewall y que pueden visualizar el tráfico a nivel de aplicación.

Típicamente un cortafuegos utiliza los siguientes campos para identificar el tráfico:

Protocolo: IPv4, IPv6, ICMP, ARP, TCP, UDP, SCTP, DCCP...
Direcciones de red: origen o destino, también se permite la especificación de subredes.
Servicio: utilizando los puertos de origen y destino, se puede limiar o permitir el tráfico dirigido a una aplicación en particular: HTTP, FTP, SSH, Telnet...
Estado de la conexión: cuando se utiliza un protocolo de transporte orientado a conexión, como TCP, se puede filtrar por el estado de la conexión: related, established, o invalid.
Interfaz: si bien un firewall trabaja a nivel de red, tiene conciencia de los niveles inferiores y permite especificar aspectos como la interfaz de red por donde ha llegado el tráfico.

Para generar las ACL en nftables tenemos la complejidad que no siempre sigue la misma escaleta. Si no que dependiendo de la familia, el topo de cadena y el hook, la ACL se escribirá de una forma o otra.

Otra opción, era como habíamos visto antes, usar un traductor de ACL, si buscáis por Internet encontraréis muchos ejemplos de ACL creadas para Iptables con funciones muy concretas. Las podéis traducir e incorporar a vuestro ruleset.

A más a más, en este caso también será diferente si trabajamos con el archivo de ruleset o si queremos trabajar con la línea de comandos.

Si trabajamos por ruleset podemos incluir un archivo similar como el que tenemos como ejemplo en la wiki de nftables: https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server

flush ruleset                                                                    
                                                                                 
table inet firewall {  
                                                                            
    chain inbound_ipv4 {
        # accepting ping (icmp-echo-request) for diagnostic purposes.
        # However, it also lets probes discover this host is alive.
        # This sample accepts them within a certain rate limit:
        #
        icmp type echo-request limit rate 5/second accept      
    }

    chain inbound_ipv6 {                                                         
        # accept neighbour discovery otherwise connectivity breaks
        #
        icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
                                                                                 
        # accepting ping (icmpv6-echo-request) for diagnostic purposes.
        # However, it also lets probes discover this host is alive.
        # This sample accepts them within a certain rate limit:
        #
        icmpv6 type echo-request limit rate 5/second accept
    }

    chain inbound {                                                              

        # By default, drop all traffic unless it meets a filter
        # criteria specified by the rules that follow below.
        type filter hook input priority 0; policy drop;

        # Allow traffic from established and related packets, drop invalid
        ct state vmap { established : accept, related : accept, invalid : drop } 

        # Allow loopback traffic.
        iifname lo accept

        # Jump to chain according to layer 3 protocol using a verdict map
        meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 }

        # Allow SSH on port TCP/22 and allow HTTP(S) TCP/80 and TCP/443
        # for IPv4 and IPv6.
        tcp dport { 22, 80, 443} accept

        # Uncomment to enable logging of denied inbound traffic
        # log prefix "[nftables] Inbound Denied: " counter drop
    }                                                                            
                                                                                 
    chain forward {                                                              
        # Drop everything (assumes this device is not a router)                  
        type filter hook forward priority 0; policy drop;                        
    }                                                                            
                                                                                 
    # no need to define output chain, default policy is accept if undefined.
}

De todo el código, quizá la parte más complicada es entender la línea de meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 }. En esta línea, lo que hace nftables es separar los paquetes entre aquellas que usan el protocolo IPv4 y aquellas que usan el IPv6. Separa según el tipo de protocolo y envía el paquete a una chain diferente. Una vez allí, el ejemplo permite crear ACL personalizadas para IPv4 o IPv6, en nuestro caso la ACL limita la ratio de 5 pings por segundo.

La llamada meta se realiza de la siguiente forma:

meta: función de nftables que busca en los paquetes una condición en concreto. (https://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation)
protocol: define un parámetro de la búsqueda, en este caso que se busque según protocolo.
vmap: mapea las posibles soluciones y las redirige usando jump.
ip: jump inbound_ipv4: que vendría a decir, si es protocolo IPv4 salta a la cadena con el nombre: inbound_ipv4 (https://wiki.nftables.org/wiki-nftables/index.php/Verdict_Maps_(vmaps))

Una vez ha finalizado la cadena (IPv4 o IPv6), vuelve a la cadena original y seguirá con el listado que haya. Tiene un funcionamiento parecido al que tendría una función en programación.

Fijaros por esto, que escribir ACL filtrando según el puerto de origen es relativamente fácil con ruleset: tcp dport { 22, 80, 443} accept. Y si queremos filtrar segun puerto de origen, usaremos sport.

Si queremos, también podemos incluir las reglas a través de la línea de comandos, por ejemplo:

% nft add rule filter output ip daddr 8.8.8.8 counter

Es una buena práctica, poder mirar antes de incluir las nuevas ACL, como tenemos todo nuestro firewall listando todas las tablas, cadenas, hooks y listas ACL:

% nft list table filter
% nft list chain filter ouput

También podemos añadir una ACL en una posición en concreto:

nft add rule filter output position 8 ip daddr 127.0.0.8 drop

Poder explicar completamente nftables en unos materiales generales de protección de redes es complicado por la dimensión. Por esto, aquí tenéis unos cuantos enlaces a la wiki de nftables que os pueden servir para ampliar vuestros conocimientos y poder configurar mejor vuestro firewall:

Los tipos de famílias. https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev
Crear las cadenas. https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types
Los tipos de familias, cadenas y hooks posibles. https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks#Hooks_by_family_and_chain_type
Generación de reglas ACL. https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management
Operar con el ruleset. https://wiki.nftables.org/wiki-nftables/index.php/Operations_at_ruleset_level
Página principal de la wiki. https://wiki.nftables.org/wiki-nftables/index.php/Main_Page#Basic_operation

El nftables es pues, el nuevo firewall que marcará tendencia, familiarizarse con él será esencial para la tarea del administrador IT. Es una herramienta potente, moderna, en proceso de desarrollo y con múltiples funciones que podéis observar simplemente leyendo el índice de la wiki de nftables.

Limitaciones de los firewalls

Se debe prestar atención al hecho que un cortafuegos, como cualquier otro componente de la red, solo puede actuar con el tráfico que es capaz de ver. Por eso, es siempre imprescindible ubicar el firewall' en una localización estratégica donde todo el tráfico entrante y saliente pase a través de el. Así y todo, el firewall tiene algunas restricciones importantes.

El hecho de trabajar a nivel de red, hace que un firewall 'no pueda analizar el tráfico entre dos sistemas que estén en una misma subred, ya que se comunican directamente sin pasar por el encaminador, esta limitación se puede mitigar usando un firewall en los hosts. Pero esta descentralización de los firewalls aumentará la complejidad de la administración de nuestra red y sistemas, ya que pocos firewalls ofrecen sistemas de administración distribuidos.

A más, el hecho que las ACL sean estáticas, comportará que cuando haya un cambio en la política de seguridad en la empresa, tendremos que hacer los cambios de forma manual.

Por otro lado, y relacionado con el dinamismo, el firewall solo conoce la información de la red, por tanto no puede proteger contra errores de configuración de los servicios o el uso de contraseñas inseguras, que será uno de los vectores de ataque más clásicos que encontraremos y indetectables por parte del firewall.

Evolución actual de los firewall

Debido a estas limitaciones presentes en los firewalls, la industria ha evolucionado a modelos de seguridad más avanzados, utilizando el firewall como base y piedra angular de un sistema de seguridad más completo. Así se ha evolucionado de un modelo de firewall tradicional a un modelo avanzado como:

UTM (Unified Threat Management)

NGFW (Next Generation Firewall)

UTM (Unified Threat Management)

Con el objetivo de simplificar la gestión de la seguridad, los UTM son una evolución directa de los firewall, básicamente proporcionan un sistema con múltiples funciones de seguridad, todo en un solo paquete, para así evitar diversos sistemas de gestión, e integran: Firewall, Intrusion Detection System (IDS), Intrusion Prevention Systems (IPS). Pero, dependiendo del fabricante también pueden incluir antivirus:

Firewalls a nivel de aplicación como proxies.
Detectores de physhing y sitios fraudulentos.
Sistemas de perdida de datos (Data Loss Prevention DLP)
Sistemas de gestión de alertas (Security information and event management SIEM)
Redes de enrutamiento virtual (Virtual Private Network VPN)
Sistemas de mitigación a ataques de denegación de servicio DoS.

Todas estas funcionalidad están integradas generalmente en un centro de control que permite orquestras y gestionar el comportamiento de un sistema, dando así una protección integral a la red.

NGFW (Next Generation Firewall)

Se podría pensar que con los UTM la red ya puede llegar a un nivel de seguridad requerido, pero los UTM son una mejora estructural de los firewall, continúan teniendo un problema importante y es el hecho que el sistema continua siendo local, es decir, toda la gestión de la organización está administrada y gestionada de forma local, como las actualizaciones o la gestión de las reglas. Por otro lado, siguen con teniendo el problema que no proporcionan una Defensa en profundidad, ya que la topología de la seguridad continua siendo centralizada.

Por eso, la aparición de las nuevas tecnologías en la nube y la mejora permanente de los sistemas basados en inteligencia artificial (IA), hizo evolucionar a lo que hoy llamamos como 'Next Generation Firewall NGFW'.

Los NGFW son una evolución tecnológica de los UTM, pero con las capacidades del cloud, donde el firewall ya no es una entidad local, si no que está centralizada des de la nube con las capacidades y integraciones del fabricante, quien de forma transparente actualiza las políticas de seguridad y los sistemas, proporcionando un sistema dinámico que se ajusta a las necesidades de cada red y a las nuevas amenazas que vayan apareciendo.

Para complementar el NGFW, la presencia de la IA proporciona una adaptabilidad sin precedentes, donde el sistema aprende del comportamiento de los usuarios y la dinámica de comunicación entre los actores de la red, para así detectar anomalías en su comportamiento.

Así, un NGFW proporciona las características típicas de un firewall: inspección con estado del tráfico, prevención de intrusiones integrada; pero con las capacidades semánticas para entender las aplicaciones, poder analizarlas y bloquearlas cuando se crea necesario, y todo de forma dinámica. El NGFW proporciona fuentes de inteligencia de amenazas y mecanismos de actualización para mantener las bases de datos al día con técnicas flexibles para mitigar amenazas cambiantes.

.

Los detectores de intrusiones: IDS/IPS

Como pasa con muchas herramientas de seguridad, los IDS/IPS han ido evolucionando de una forma muy rápida, por ejemplo, hoy en día nos costaría encontrar con un IDS que no fuera a la vez IPS, y al final, se acaba definiendo más por el concepto de función que tienen dentro de un sistema, que no por las características concretas.

Los conceptos clave de un IDS/IPS son:

Escucha de todo el tráfico de red, si queremos que trabaje como IPS se tendrá que situar en medio del tráfico para poder bloquearlo, y si solo trabaja como IDS con un splitter podremos duplicar la red y leerla.

Hay un conjunto de reglas que analizan el tráfico, muchos IDS/IPS hacen servir la nomenclatura SIGMA, pero no es universal. Estas reglas pueden estar basadas en signaturas o en comportamientos.
Las reglas de un IPS, a más de enviar alertas, también tienen la posibilidad de bloquear el tráfico.
Hay bibliotecas de reglas que podemos instalar de forma automática en nuestro IDS/IPS.
Tienen visibilidad hasta la capa de aplicación.

Un IDS/IPS generalmente mantiene una base de datos de ataques conocidos y compara los patrones de actividad observando y monitoreando la red, de esta forma se pueden reconocer cuando se produce una coincidencia con un ataque conocido.

Otra posibilidad que proporcionan la mayoría de IDS/IPS es ejecutar algún tipo de orden en la medida que salte una alarma o un bloqueo. A partir de estos scripts las opciones pueden ser infinitas, podemos generar nuevas reglas, podemos agregar ACL a los firewalls perimetrales, o podemos recopilar el conjunto de evidencias que definamos para después analizarlas a través de forensics.

Des de el punto de vista de la arquitectura, podemos definir dos tipos de IDS/IPS: los Network Intrusion Detection System (NIDS) y losHost Intrusion Detection System (HIDS).

Network Intrusion Detection System (NIDS)

Los NIDS son sistemas de detección de intrusiones que analizan el tráfico de red. Internamente, es similar a un firewall, en el sentido que todos se basan en el análisis del tráfico de red, pero en el caso de los NIDS es capaz de analizar más capas de red y es capaz de buscar firmas conocidas de tráfico.

Un NIDS, para poder actuar y analizar de forma correcta el tráfico de red, necesita poder capturar y estudiar los paquetes hasta la capa de aplicación, esto implica que ha de hacer una inspección profunda de los paquetes (Deep packet inspection DPI). DPI es una forma de filtrage de paquetes de red que examina la parte de los datos, los interpreta y los analiza. El NIDS lo que hace es buscar problemas conocidos a los protocolos, firma de virus conocidos, correo basura (spam) o intrusiones con los criterios predefinidos.

Los NIDS inicialmente se implementaban en hardware específico, pero hoy en día con las tecnologías en la nube y la mejora de los equipos de propósito genérico como servidores, han pasado pasado a un modelo basado en software ejecutándose directamente en el sistema genérico.

Host Intrusion Detection System (HIDS)

El HIDS monitorea las características de un solo equipo, se centra en los eventos que ocurren en este equipo y busca actividad sospechosa. Los HIDS inspeccionan el tráfico de red que llega al equipo, pero también pueden inspeccionar los registros del sistema (logs), los procesos en ejecución, los accesos y modificación de ficheros y los cambios de configuraciones del sistema y aplicaciones.

Para poder funcionar correctamente un HIDS se implementa mediante un agente instalado en los equipos o aplicaciones de interés: cada agente monitorea la actividad de su cliente y transmite la información a los servidores de administración. Por tanto, el HIDS nos permite verificar la integridad de un sistema a través de las monitorización de registros y nos permite monitorear las trampas tipo honeypot.

Un honeypot es un sistema que simula una vulnerabilidad de una máquina para poder analizar los atacantes.

Des de el punto de vista de la arquitectura, se recomienda que el agente HIDS se instale en todos los equipos de la organización, tanto PCs como servidores. En caso de no poderse instalar, reenviaremos los registros al servidores para que se puedan tratar allí.

Todas estas nuevas funciones del HIDS han hecho que hoy en día se conozcan como EDR Endpoint Detection and Response y son la piedra angular de la nueva seguridad de las organizaciones.

Fortificación y gestión del Switch

Hasta este punto, la mayoría de aspectos de seguridad tratados han puesto el foco en la capa de red y superiores. Si bien estos niveles son generalmente los que reciben más atención, conviene no olvidar los aspectos importantes de la capa 2. Los switchs trabajan a nivel de enlace de datos y son la primera línea de defensa contra los ataques de denegación de servicio, suplantación de identidad o acceso a la red.

Para proteger un switch se pueden utilizar diferentes estrategias, algunas de ellas dependen normalmente del fabricante, aún así, hay una serie de buenas prácticas que todo administrador debería implementar.

Proteger el acceso físico al dispositivo: aunque puede ser complicado en la mayoría de casos, permitir el acceso al switch permite a un atacante desconectar cables de equipos existentes y conectarse el mismo. También se debe vigilar que todas las interfaces que no se usen en el switch estén deshabilitadas.
Contraseñas predeterminadas: la inmensa mayoría de switchs gestionados tienen contraseñas predeterminadas que tendremos que cambiar la primera vez que entremos para evitar perder el control de nuestro dispositivo.
Supervisión: vigilar y monitorizar las interfaces del switch (normalmente a través del protocolo SNMP).
SNMP v3: si es posible, utilizaremos la versión 3 de SNMP que es más segura y procuraremos que la contraseña del community sea bien larga para evitar ataques de fuerza bruta.
Registro de logs: configurar el registro centralizado para poder observar las actividades de los switchs. De esta forma, juntamente con los HIDS, se simplifica mucho la correlación de eventos de un servidor.
Authorization, Authentication, Accounting (AAA): es una buena práctica activar la asignación de VLAN por usuario, esto lo podemos conseguir con RADIUS pero requiere que nuestro switch lo soporte.
Seguridad del puerto: también podemos configurar las interfaces de nuestro switch para que solo pueda acceder una MAC determinada. En este sentido, normalmente tenemos la opción de aceptar en una interfaz solo la primera MAC que se conecte..
VLAN dinámica: las VLAN dinámicas son aquellas que deciden la VLAN según el usuario o la MAC del dispositivo.
Identificador de usuario/contraseña local: en caso de utilizar AAA, se debe dejar una puerta trasera con un usuario local por si un caso fallara el sistema de autenticación en red.
Segmentación de la red: es imprescindible segmentar la red con VLAN para segregar las diversas partes de la red. A más, configuraremos los firewalls para filtrar el tráfico entre las VLAN.
VLAN de gestión: muchos switchs admiten una VLAN de gestión para poder administrar todos los switchs.
IP de gestión: En esta VLAN configuraremos la IP de gestión del dispositivo, una red diferente a la de la organización.
Etiquetaje de puertos: siempre está bien tenerlo todo ordenado y escribir todas las descripciones que podamos a nivel interno y etiquetar de forma externa todas nuestras conexiones.
SSH vs Telnet: Telnet se considera un protocolo no seguro, viaja en claro, y por tanto debemos usar siempre SSH v2 y deshabilitar los puertos Telnet de nuestro switch.
Interfaz web: en caso de tener la posibilidad de una interfaz web, esta deberá funcionar con los protocolos SSL (HTTPS).
NTP: sincronizar los relojes de todos los switchs.
Limitar el nombre de direcciones MAC por interfaz: de esta forma podemos evitar que se genere un punto de acceso fraudulento o evitar una inundación de MAC en la tabla intefaz-MAC.

Fortificación de los accesos WiFi

La fortificación de acceso a las redes inalámbricas es extremadamente crítico, ya que un potencial atacante no tiene porqué buscar un punto de conexión físico, si no que podemos hacerlo des de la calle mismo.

De esta forma, una buena política de seguridad es imprescindible. Las principales recomendaciones son:

No permitir la existencia de puntos de acceso no registrados: debemos tener mecanismos de detección por si un nuevo punto AP aparece sin nuestro reconocimiento.
Utilizar protocolos de protección wifi: La recomendación mínima de contraseña debe ser WPA 2.0, tanto en su versión Personal como Enterprise.
Contraseñas predeterminadas: igual que con los switchs, debemos cambiar todas las contraseñas predeterminadas para evitar perder el control del dispositivo.
Registro de logs: configurar también el registro centralizado.
SNMP v3: siempre intentar usar la versión 3 de SNMP.
NTP: sincronizar los relojes.
Deshabilitar el servidor DHCP: es una buena practicar diferenciar las funciones de AP y de DHCP (en casa es común, pero en organizaciones siempre mejor centralizar el DHCP)
SSH vs Telnet: siempre accederemos a nuestros dispositivos usando protocolos encriptados.
Filtraje de direcciones MAC: si no podemos usar los protocolos WPA 2 Enterprise, buscaremos otros mecanismos de filtraje de dispositivos como puede ser a través de la MAC..

Comunicaciones seguras en entornos no confiables

Para garantizar la seguridad de un sistema es importante, como ya hemos visto, como ya hemos visto, seguir ciertas buenas prácticas, pero hay veces que es imposible estar conectado en una red confiable, aún más, debemos de tener presente que el propio Internet es inseguro dada la falta de seguridad del propio protocolo IP y por la existencia de protocolos no cifrados. Por tanto, es primordial garantizar la seguridad en las comunicaciones cuando no se den las situaciones óptimas.

En estos casos, tenemos dos formas de hacer comunicaciones seguras:

Redes Privadas Virtuales (Virtual Private Networks o VPN).
Utilización de protocolos seguros.

Redes Privadas Virtuales (Virtual Private Network VPN)

Una VPN es un mecanismo para crear conexiones seguras entre dos ubicaciones. Para conseguirlo, una VPN crea lo que se conoce como un overlay, es decir, una red encima de otra red, lo que a la práctica significa que se crea un túnel de tráfico IP dentro del tráfico de capa 3.

En la siguiente tabla podemos ver como funcionaría a nivel de paquete y sus headers:


Layer Data link	Layer network	Layer transport	Layer application
Frame	Packet	Segment	Data

Un software VPN, lo que hace es encriptar las capas de red, transporte y aplicación, lo garda todo en la capa de datos del nuevo paquete de aplicación, y lo envía al otro lado del extremo de la VPN, el cual podrá desencriptar la capa de aplicación. Al trabajar en capa 3-4, nos permite también la posibilidad de trabajar con protocolo como ICMP.

Así pues, nos quedaria un paquete de una forma similar a:


Layer Data link	Layer network	Layer transport	Layer application
Frame	Packet	Segment	Layer network	Layer transport	Layer application
Frame	Packet	Segment	Packet encrypt	Segment encrypt	Data encrypt

También existen VPN que trabajan a nivel de capa de enlace de datos, estas VPN nos permiten comunicarnos de forma seguro dentro de una misma red.

La parte importante a entender, es que tiene que haber algún tipo de servidor VPN que reciba los paquetes VP, si este servidor debe enviar el paquete por Internet, encapsulará y encriptará toda la información, rehará los headers de las capas 3 y 4, y lo enviará al otro servidor VPN. Por tanto, fijaros que en caso de escuchas de tráfico, lo único que se conocerá son las IPs de nuestros servidores VPN, pero el resto de datos viajará encriptado.

De VPN hay de tres tipos, dependiendo de como trabajen los servidores:

Host-to-Host: Los dos equipos tienen una aplicación que corre internamente como un servidor VPN. Para los equipos en cuestión, entre ellos están en la misma red.
Network-to-Host: Es el típico caso del teletrabajo, queremos por ejemplo que el PC del trabajador funcione como si estuviera dentro de la red de la organización, en este caso el PC del trabajador sería un extremo de la VPN y en el otro extremo habría un dispositivo capa 3 (router).
Network-to-Network: En estos casos el objetivo es conectar dos redes entre ellas. Para ello los dos routers tendrán instalada la aplicación VPN y se redirigirán los paquetes entre ellos según la tabla de enrutamiento.

El uso de las VPN está muy extendido des de hace muchos años, con un incremento notable después de la COVID-19.

Uso de protocolos seguros

En muchos casos el uso de las VPN no es práctico, o bien porqué no está disponible, o bien porqué ya estamos usando protocolos que son seguros de base' y por tanto no es necesario.

Algunos ejemplos de estos protocolos seguros podrían ser el HTTPS o el SSH, los cuales encriptan los datos entre extremos. Es habitual que nos encontremos aplicaciones que para establecer comunicaciones seguras usen protocolos como el HTTPS. Todos estos protocolos se consideren de una seguridad equivalente a la VPN y muchos de ellos provienen de la implementar sistemas de encriptación protocolos que inicialmente no eren seguros como HTTP o Telnet.

Mención especial merece el protocolo DNS, el cual un atacante podría monitorizar los dominios que está visitando la víctima'. En la actualidad existe el DNSSEC, que encripta la información entre extremos y nos asegura la autenticidad, la integridad y la confidencialidad de los datos. Pero es un protocolo que no está extendido y que los navegadores no llevan incorporado.

Fortificación y monitoreo de la red interna

La fortificación desde IT

Como administrador IT, nuestra misión es asegurar nuestra red y nuestros sistemas. Nuestra organización nos reclama seguridad, es decir: confidencialidad, integridad y disponibilidad de datos. Todo eso, de forma constante, y sin tener en cuenta la evolución de las amenazas cibernéticas. Por eso, es básico seguir un conjunto de pasos que nos ayuden a securizar nuestro sistema.

Implementar la protección perimetral

Utilizar firewalls para controlar y monitorear el tráfico de red, permitiendo solo aquel tráfico autorizado y bloqueando los intentos de acceso no autorizados.
Configurar políticas de filtraje de direcciones IP para prevenir ataques de denegación de servicio (DoS DDoS) y limitar el acceso des de ubicaciones geográficas indeseadas.

Actualitzaciones y Patchs

Implementar un programa de gestión de actualizaciones para garantizar que todos los dispositivos de la red tengan las últimas actualizaciones de seguridad.
Automatizar el proceso de actualización para minimizar el tiempo de vulnerabilidad de los sistemas.

Sistemas de autenticación fuerte

Utilizar protocolos de autenticación robustos con LDAP o Kerberos para verificar la identidad de los usuarios y dispositivos.
Implementar la autenticación multifactorial para añadir una capa adicional de seguridad mediante factores como ahora llaves de seguridad o autenticación biométrica.

Monitoreo Continuo

Desplegar herramientas de monitoreo de seguridad para detectar actividades sospechosas.
Configurar alertas para incidentes de seguridad y establecer protocolos de respuestas rápida en caso de ataques o comportamientos anómalos.

Cifrado de Datos

Implementar protocolos de cifrado robustos como SSL/TLS para proteger comunicaciones sensibles entre los dispositivos.
Utilizar cifrado de disco para proteger los datos guardados en servidores y dispositivos de red.

Gestión de Políticas de Seguridad

Establecer políticas de seguridad claras y aplicables a todos los usuarios y dispositivos de la red.
Educar los usuarios sobre las prácticas de seguridad, como la creación de contraseñas fuertes y la prevención de ingeniería social.

La fortificación de una red interna es un proceso continuo que requiere de una vigilancia constante y adaptada a las nuevas amenazas. La implementación de estas prácticas contribuirá a crear una red robusta, resistente a los ataques cibernéticos y protegida contra posibles vulnerabilidades.

Completando esto, es crítico para la seguridad de la red concienciar a los trabajadores de las organizaciones a través de las buenas prácticas, la conciencia del peligro de compartir datos privados, el uso de contraseñas robustas o la detección de intentos de ataque de ingeniería social.

Al final, la fortificación de una red interna es una tarea crítica para cualquier organización que desee garantizar la seguridad, la integridad y la disponibilidad de sus datos. En la medida que las amenazas cibernéticas evolucionen, es esencial adoptar estratégicas y prácticas que protejan eficazmente los recursos de la red. Por esto, aunque las buenas prácticas antes comentadas siempre deben estar, requeriremos de otras herramientas que nos ayuden a monitorear los sistemas y la red y poder responder de forma eficaz los incidentes de ciberseguridad.

Los registros

El monitoreo de registros (logs) forma parte de las tareas críticas a tener en cuenta en un entorno seguro, monitorear registros nos proporciona información vital sobre el estado, el rendimiento y los eventos (events) relevantes de nuestro sistema operativo.

Con independencia del sistema operativo que se utilice, el análisis y la gestión del monitoreo de registros ha de considerar ciertos aspectos fundamentales. De entrada ha de monitorear los events del sistema operativo:

errores del núcleo del sistema.
Events inesperados como accesos a ficheros hechos por usuarios sin privilegios.
Accesos fallidos al sistema, sea de forma local o remota.
Inicio, finalización y tiempo de las sesiones de los usuarios.
Acciones realizadas por los administradores.
Monitorear los servicios que estamos ofreciendo: HTTP, Mail, etc.

Todos estos registros los podemos monitorizar con un EDR o un HIDS, es la forma más utilizada, de esta forma se centraliza la vigilancia de nuestros servicios. Pero este tipo de aplicaciones tienen su propio funcionamiento interno y las propias casas comerciales ofrecen sus formaciones especializadas.

Pero más allá de las grandes casas comerciales, debemos conocer cuales son aquellas aplicaciones de sistema que nos permiten monitorear nuestro sistema: En Linux con rsyslog y journalctl, y en Windows con el Event Log.

Análisis de registros en Linux: rsyslog

rsyslog es un sistema de registro para sistemas UNIX que permite la recopilación, procesamiento y envío de registros a diversos destinos. Soporta protocolos como syslog, TCP y UDP, y proporciona una flexibilidad considerable para personalizar el tratamiento de los registros.

Las partes que forman parte del rsyslog son:

Senders: es la parte encargada de enviar los registros de las aplicaciones y del sistema al servidor de registros.
Receivers: es la parte encargada de recibir y redirigir los registros.
Filters: permite seleccionar y procesar los registros basándose en criterios específicos como el nivel de gravedad o el origen.

Facilities con rsyslog'

Una facility se refiere a una categoría o tipo de mensaje de registro que se generan en el sistema. rsyslog usa el protocolo syslog que es el protocolo estándar de registró.

Las facilities en syslog son mecanismos que usamos para clasificar los mensajes de registro en categorías específicas, indicando la naturaleza del mensaje y el componente del sistema que lo ha generado. Cada mensaje de registro syslog contiene una facility y un severity level (nivel de gravedad), que determinarán la importancia y la categoría del mensaje.

Hay 24 facilities estándar en syslog y cada una de ellas se designa con una palabra clave que describe la categoria de los mensajes asociados. Algunas de las facilities más comunes son:

kernel: mensajes del kernel del sistema operativo.
user: mensajes de usuarios generales o aplicaciones que no estan asociadas a ninguna facility.
mail: mensajes relacionados con el correo electrónico.
daemon: mensajes de servicios del sistema (daemons).
auth: mensajes de autenticación y seguridad.
syslog: mensajes generados por el propio daemon syslog.
lpr: mensajes relacionados con la impresión.
news: mensajes de sistemas de noticias.
uucp: mensajes relacionados con el protocolo UUCP (Unix-to-Unix Copy).
cron: mensajes relacionados con la aplicación cron.
authpriv: mensajes de autenticación privados (seguridad privada).

Conviene no confundir las facilities con aplicaciones, una facility puede ser para más de una aplicación.

Severities

Relacionado con cada facility el sisetma también permite, para cada facility determinar el nivel de gravedad del mensaje. Los severity levels son:


Number	Severity	Keyword	Description
0	Emergency	emerg	System is unusuable
1	Alert	alert	Action must be taken immediatly
2	Critical	crit	Critical conditions
3	Error	err	Error conditions
4	Warning	warning	Warning conditions
5	Notice	notice	Normal but significant condicionts
6	Informational	info	Informational messages
7	Debug	debug	Debug-level messages

Así, como administradores podemos hacer que el sistema permita ignorar unas severities o otras dependiendo de cada facility, para hacerlo editarmos el archivo:/etc/rsyslog.conf. Per exemple:

# Log commonly used facilities to their own log file
auth,authpriv.* /var/log/auth.log
kern.* -/var/log/kern.log
kern.ERROR -/var/log/kern-important.log
mail.* -/var/log/mail.log

 :title: Gestión de las severities /etc/rsyslog.conf

En este caso, se guardan los registros de cualquier nivel de gravedad de las facilities: auth, authpriv, kern i mail al fichero que ponemos en la derecha, mientras que los mensajes de nivel de gravedad de ERROR o superior (ERROR, CRITICAL, ALERT i EMERG) también se guardan en el fichero: /var/log/kern-important.log.

Registros con ryslog'

En los registros con rsyslog incluimos información básica de cuando, quien, donde, la gravedad del mensaje y porque se generó el registro.

Podemos ver el siguiente ejemplo:

2023-11-14T07:54:46.924376+01:00 server sshd[1047736]: Failed password for root from 61.183.129.50 port 18705 ssh2

Como se puede observar, la informaicón que hay es:

Hora del 'event: 2023-11-14T07:54:46.924376+01:00
Equipo que ha generado el registro: acme-server
Aplicación que ha generado el registro: sshd
En este punto, el formato que hay a continuación ya depende de cada facility en si:
- Información del event: Failed password
- Usuario: root
- Source IP: 61.183.129.50
- Port: 18705
- Protocol: SSH2

Análisis de registro con Linux: journalctl

A partir de systemd, Linux incorporó journalctl como herramienta para acceder a los registros del sistema. Este servicio registra información detallada sobre los eventos (events) del sistema, incluyendo metadatos como los timestamps y el ID process. De hecho, guarda los mismos datos que rsyslog pero utiliza el formato de base de datos para tener los registros de forma más compacta.

Con journalctl, los usuarios pueden:

Ver todos los eventos del sistema.
Filtrar registros per nivel de gravedad, origen y tiempo.
Acceder a información detallada, incluyendo mensajes de error y datos relacionados con procesos.

Registros con Windows

Windows, a nivel de sistema, utiliza el Event Log como sistema de monitoreo.

Windows usa este servicio para mantener registros de actividades del sistema, seguridad y aplicaciones. Este sistema está organizado en tres categorías principales:

System Log: registra los eventos del sistema, como arranques, paros del sistema, errores de hardware y mensajes del sistema operativo.
Security Log: recoge información sobre eventos de seguridad, como ahora intentos de inicio de sesión, cambios de contraseña y otras actividades relacionadas con la seguridad del sistema.
Application Log: registra eventos relacionados con aplicaciones, incluyendo mensajes de error, advertencias y información sobre el uso de las aplicaciones.

Los administradores del sistema pueden utilizar la herramienta Event viewer para explorar, filtrar y analizar los registros de eventos del sistema. Los eventos se organizan según categorías, niveles de gravedad y otros metadatos para facilitar su gestión.

Con el Event Log (a través del Event Viewer) se puden registrar, consultar y subscribirse a los eventos del sistema para recibir alertas, realizar acciones concretas y archivar registros de eventos. También podemos obtener los registros para exportarlos a servicios externos en formato XML (evtx) o formato simple. Windows guarda los logs en la carpeta C:\Windows\System32\winevt\Logs.

Se debe ir muy en cuenta, ya que Windows, por defecto, limita la mida de cada uno de los ficheros de los logs (como son los de System, Security, o Application). De manera que, una vez se llegue a la mida máxima, se sobreescriven los registros más antiguos; si no queremos perder los registros los tendremos que guardar externamente, como por ejemplo enviarlos a un equipo remoto. Esto se puede conseguir activandolo en las propiedades del archivo de fichero de los logs en el Event Viewer , o bien en la línia de comandos, utilizando:

wevtutil.exe sl Security /ab:true /rt:true
wevtutil.exe sl Application /ab:true /rt:true

Tipo de eventos

El Event Log registra diversos tipos de eventos (events) que proporcionan información detallada sobre el estado, el rendimiento y las actividades del sistema operativo. Los principales tipos de eventos que hay son:

Information: este tipo de evento proporciona información general o registro de actividades normales del sistema. Ejemplo: inicio de servicio, conexión de un dispositivo o tarea programada con éxito.
Warning: indica situaciones que no son necesariamente errores, pero que podrían requerir la atención de un administrador. Es una advertencia sobre una condición potencialmente problemática. Ejemplos: bajo rendimiento de un servicio, manca de espacio en el disco duro o parada inesperada de una aplicación.
Error: indica situaciones problemáticas que pueden afectar al rendimiento o funcionamiento normal del sistema. Ejemplos: fallo de una aplicación, error en una tarea programada o problema con un controlador de dispositivo.
Critical: es el nivel más alto de gravedad e indica problemas graves que pueden afectar significativamente el rendimiento o disponibilidad de nuestro sistema. Ejemplos: parada de un sistema crítico, error de funcionalidad esencial o fallo importante de una aplicación.
Audit Success: registro que indica que un evento se ha comprobado y se ha completado con éxito. Ejemplo: acceso a un recurso compartido con éxito.
Audit Failure: registra que indica que un evento se ha comprobado y no se ha completado con éxito. Ejemplo: intento de sesión fallido o no autorizado.
Security: eventos relacionados con la seguridad y la autenticación. Ejemplo: cambio de la política de seguridad.
System: registra los eventos del sistema que no encajan en las otras categorias específicas. Ejemplo: los cambios en la configuración del sistema.

Esta clasificación en diferentes tipos de eventos facilita la identificación y el diagnóstico de incidentes, problemas o situaciones relevantes para la gestión y el monitoreo del sistema con la herramienta Event Log de Windows. A más a más, Event Log identifica todos los eventos con un ID, de esta forma nos permite no solo buscarlo con más facilidad, si no también poder utilizar este ID en las reglas SIGMA para el monitoreo de los sistemas y la red.

Servicios de monitoreo especializado

En la actualidad, y sobre todo en entornos corporativos, no se usan estan herramientas locales como journalctl o Event viewer, más allá de querer hacer alguna auditoría concreta. Por norma general, se usan un conjunto de aplicaciones como los SIEM, SOAR, EDR o HIDS, que las acaban integrando. La nomenclatura en estos casos no es muy importante, pues realmente hay muchas variaciones a lo largo de los años y muchas veces herramientas que empiezan con unas características concretas, evolucionan para ofrecer más servicios. Solo tener en cuenta, que en líneas generales, nos encontraremos con agentes instalados en las máquinas y dispositivos de nuestro sistema, los cuales recopilan logs y eventos, y que los enviarán a servidores recolectores para su tratamiento.

Otro hecho a destacar, es que este conjunto de herramientas son las que actualmente hacen de frontera entre los Departamentos IT y el Blue Team de Ciberseguridad.

Todas estas herramientas, que en la práctica se parecen mucho, podríamos intentar distinguirlas de la forma siguiente:

un HIDS genera un conjunto de alertas y bloqueos en relación al tráfico de red según un tipo de reglas concretas (tipo SIGMA o otras).
Un EDR genera un conjunto de alertas y bloqueos en relación a la capa de aplicación, archivos dañinos o malware, según un tipo de reglas concretas (tipo YARA o otras).
Un SIEM recoge el conjunto de alertas y los muestra para su tratamiento.
Un SOAR genera proceso debido a una alerta concreta.

No son definiciones fijas e immutables, solo para ofrecer una idea general de los que nos podemos encontrar. Aún así, podríamos decir que la aplicación por excelencia son los SIEM para el monitoreo general y los EDR como clientes instalados en los dispositivos. Todo ello, administrado por el Blue Team para la mitigación y recuperación de los sistema en caso de incidente de ciberseguridad.

Algunas aplicaciones SIEM, aunque algunas con matices, son:

Nagios: Es una herramienta de monitoreo muy utilizada y de código abierto. Puede supervisar servidores, dispositivos de red, aplicaciones y mucho más.
- Características:
  - Soporte para protocolos SNMP, SMTP, POP3 o HTTP.
  - Capacidad de personalizar los scripts y plugins para una supervisión específica.
  - Alertas i notificaciones configurables.
  - Interfaz web para la visualización de estadísticas y informes.
Zabbix: Es una plataforma de monitoreo integral que ofrece funciones avanzadas de recopilación de datos y análisis.
- Características:
  - Supervisión de redes, servidores, aplicaciones y recursos de hardware.
  - Creación de gráficos e informes personalizados.
  - Soporte a la generación de alertas y notificaciones.
  - Capacidad para el monitoreo distribuido y descentralizado.
Prometheus: Es una herramienta de monitoreo y alertas para un enfoque orientado a servicios y arquitecturas contenedor.
- Características:
  - Recopilación de datos mediante un model pull.
  - Soporte para consultas y alertas basadas en lenguaje PromQL.
  - Integración con el ecosistema de contenedores como Docker o Kubernets.
  - Arquitectura modular y expansible.
SolarWinds: Es un conjunto de herramientas para el monitoreo que ofrece una variedad de soluciones para redes, servidores y bases de datos.
- Características:
  - Monitoreo del rendimiento de las redes y servidores.
  - Análisis del tráfico de la red e identificación de problemas.
  - Gestión de la configuración de los dispositivos de red.
  - Supervisión del uso de la infraestructura cloud.
Splunk: Es una plataforma que ofrece monitoreo, recopilación y análisis de datos a gran escala.
- Características:
  - Recopilación e indexación de datos de logs.
  - Análisis ad hoc de datos.
  - Alertas y notificaciones basadas en patrones y consultas.
  - Visualización de datos en tiempo real con dashboards interactivos.
Dynatrace: Es una plataforma de monitoreo y gestión del rendimiento de aplicaciones con una visión integral del entorno.
- Características:
  - Supervisión del rendimiento de la aplicación en tiempo real.
  - Identificación automática de dependencias y problemas.
  - Análisis de rendimiento de aplicaciones web i móviles.
  - Generación de reportes e informes detallados.
Wazuh: Es una plataforma de seguridad basada en código libre que proporciona funcionalidades avanzadas de recopilación, análisis y respuesta a incidentes de seguridad en tiempo real.
- Características:
  - Integración con OSSEC: wazuh se basa en el proyecto OSSEC para la detección de intrusiones y la gestión de los registros.
  - Monitoreo de registros: recopila y analiza registros de sistemas, aplicaciones y dispositivos de red.
  - Detecta Amenazas: utiliza reglas y firmas para identificar actividades maliciosas y comportamientos sospechosos.
  - Plataforma de Amenazas: proporciona una plataforma centralizada para gestionar amenazas y responder para su mitigación.

Seguridad en redes

La seguridad en redes

Como viajan los datos por la red

El viaje por la red

Dividimos los protocolos por capa

Protocolos y dispositivos

Capa de aplicación

Capa de transporte

Capa de red

Capa de enlace

Arquitecturas de red

Evolución de la topología de redes

Firewalls

Topología con conexión doble ('Dual-Homed')

Topología con conexión triple ('Three-Legged')

Balanceo de carga

Balanceo de carga en L2

Balanceo de carga en L3

Las vulnerabilidades de los protocolos

Capa física

Capa de enlace de datos

Capa de red

Capa de transporte

La protección de la red

Segmentación lógica de una red

Segmentación mediante Subnetting

Segmentación mediante VLAN

El Proxy

El Cortafuegos Firewall

El firewall de iptables

El firewall de nftables

El conjunto de reglas ACL en nftables

Limitaciones de los firewalls

Evolución actual de los firewall

UTM (Unified Threat Management)

NGFW (Next Generation Firewall)

Los detectores de intrusiones: IDS/IPS

Network Intrusion Detection System (NIDS)

Host Intrusion Detection System (HIDS)

Fortificación y gestión del Switch

Fortificación de los accesos WiFi

Comunicaciones seguras en entornos no confiables

Redes Privadas Virtuales (Virtual Private Network VPN)

Uso de protocolos seguros

Fortificación y monitoreo de la red interna

La fortificación desde IT

Los registros

Análisis de registros en Linux: rsyslog

Facilities con rsyslog'

Severities

Registros con ryslog'

Análisis de registro con Linux: journalctl

Registros con Windows

Tipo de eventos

Servicios de monitoreo especializado

Menú de navegació