Revisió del 15:33, 2 gen 2024

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 regles dentro de la capa 2, 3 y 5 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 concepte és força important, qui escriu? qui fa el tagged? Una opció que tenim és que els nostres dispositius finals generin un tagged en la mesura que es connectin a la xarxa, tots els sistemes operatius ofereixen la possibilitat de taggejar el seu tràfic (Windows, Linux). Però no és molt comú, doncs és un tipus de configuració que requereix un esforç per part dels administradors IT, doncs ens podem trobar dispositius que no ofereixin aquest tipus de suports, i a més a més, ens podem trobar amb el BYOD. Per tot això, moltes vegades ens trobarem que el tagged el faci directament el nostre dispositius de capa 2 (switch).

Aquesta decisió influenciarà alhora d'administrar el nostre switch, doncs una de les opcions que ens podem trobar és que haguem de definir si el nostre port és tagged o untagged. Què significa? Si posem tagged, la interfície del switch esperarà trobar-se amb el protocol 802.1Q configurat, i per tant, en cas que no hi sigui descartarà el paquet. Això significa, que si no hem configurat el nostre dispositiu final amb el tagged (el nostre windows o linux), haurem de posar untagged en la interfície per on rebi el paquet.

A la figura es poden veure diversos punts interessants:

 * L'organització té dos departaments diferents, on es fan servir dues VLAN, la 110 i la 120.
 * Cada departament, donada la seva mida té un //switch// individual, però tots dos //switches// es connecten a un //switch// central.
 * Els recursos locals (servidors, serveis per als empleats...) estan segmentats dels departaments, així un possible atac al departament (o al servei) quedaria aïllat a la xarxa corresponent, complicant-ne la difusió
 * Els recursos públics estan també separats de la resta, en aquest cas utilitzant o bé adreces IP públiques o configurant //Port Forwarding// al tallafoc, per oferir el servei cap a l'exterior.
 * La xarxa sense fils de l'empresa, com ha de ser, no és confiable, de manera que els empleats que usin equips de fora de l'empresa no tindran accés per defecte als serveis interns.

Cal notar que en aquesta topologia els enllaços que van entre els commutadors i l'encaminador (//router//), i entre commutadors són uns **colls d'ampolla**. És per això que es recomana fer servir o bé balanceig de càrrega a nivell d'enllaç de dades, o bé ports del commutador i encaminador més ràpids (2.5G, 5G o 10G) per fer que la xarxa escali millor.

Actualment, la segmentació amb VLAN està àmpliament utilitzada gràcies a la seva versatilitat i bon rendiment en general. Així i tot, donades les noves arquitectures de programari, la gran adopció de tecnologiesal núvol (//cloud//), la virtualització dels serveis en forma de màquina virtual o de contenidors, aquest paradigma està canviant radicalment. El que històricament se solucionava amb maquinari, a poc a poc està passant a un format molt més **basat en programari**, amb la millor versatilitat que això dona a les noves arquitectures. Així es passa a un model basat en **microserveis**.

El proxy

A nivell de serveis, en l'actualitat hi ha dues tendències que estan provocant canvis alhora de protegir les xarxes a través de la segmentació:

El núvol
Els contenidors

En relació al núvol, tenim la possibilitat de generar un túnel VPN, i a partir d'aquí, podem tractar la xarxa del cloud com si fos interna i generar noves segmentacions específiques per cadascun dels serveis.

En relació als contenidors, la seva configuració és una mica més complicada. La idea dels contenidors és oferir serveis el més atòmics possibles, microserveis molt orientats al seu ús final, i per norma general, aquests rebran la seva configuració de forma automàtica en el moment que es pugi el contenidor.

Un dels aspectes més importants i que ha ajudat en l'èxit dels contenidors, és la capacitat que tenen per autoescalar-se. És tècnicament fàcil, doblar un microservei quan el primer servei pateixi una sobrecàrrega de feina. Això comporta un repte, quan un paquet arriba a la nostra xarxa, com sabem on enviar-lo tenint en compte la segmentació de la nostra xarxa? La resposta és el Proxy.

Un Proxy és un equip que intercepta el tràfic a nivell d'aplicació i que és capaç d'administrar-lo segons uns requisits concrets. Poden arribar a treballar com un Firewall, però tenen l'avantatge que poden treballar amb les dades d'aplicació. En aquest camp, s'han anat creant un conjunt gran d'aplicacions i opcions que dificulten el fet de crear una única categoria, per exemple, molts WAF (Web Application Firewall) tenen més de Proxy, de monitoratge o de generació d'alertes, que no pas de Firewall. Per això, lo important d'un Proxy és entendre que pot llegir i administrar tot el tràfic d'Internet sense les limitacions dels Firewalls típics. Un Proxy és capaç de saber:

L'estat de cadascun dels microserveis.
El nombre de peticions fetes, resoltes i aturades en cadascun dels microserveis.
La càrrega general de tot el sistema.

Amb aquestes dades, el Proxy és capaç d'anar dirigint el tràfic entre cadascun dels microserveis.

Totes aquestes avantatges, van associades també a mancances que cal tenir en compte:

Les connexions xifrades no sempre poden ser interceptades. Per exemple, podem interceptar un intercanvi de claus, però si ho fem, els protocols PKI de certificats digitals de l'aplicació, detectaran que la clau pública enviada no està generada pel servidor, sinó que ha estat feta pel nostre proxy.
Quan nosaltres enviem un paquet per Internet, la capa 4 de transport és l'encarregada de dividir els paquets, enviar-los d'un en un, i després tornar-los a adjuntar per tal que la capa d'aplicació en faci el seu tractament. Això comportarà que, si el Proxy llegeix la capa d'aplicació, haurà d'esperar sempre a rebre tot el paquet abans de poder actuar, a diferència del Firewall comú, que si veia que la IP ja es podia bloquejar, ho feia directament.

El tallafocs Firewall

El tallafocs és un dispositius de Software o Hardware que permet controlar l'accés entre dues xarxes i ens ofereix una capa de seguretat en els protocols de capa 3 i 4, tot i que també tenim opcions en la capa 2. Els tallafocs els podem trobar de moltes maneres diferents:

Un Software en un dispositiu final com un PC, com el firewall de windows o de Linux.
Un Software en un router, a vegades forma part del mateix soft del router, o a vegades, el podem instal·lar per separat.
Un Hardware únic d'una opció comercial concreta com Palo Alto.

El funcionament en tots tres casos sempre acaba sent el mateix, tenim un conjunt de regles conegudes com ACL (Access Control List), les quals acaben determinant si es deixa passar un paquet o no. Tota la informació que genera el firewall, com per exemple, quants paquets ha deixat passar, quins paquets han quedat bloquejats, etc... que guardat en el log, i serà tasca del administrador d'IT, determinar el nivell de log que volem publicar. (Un SIEM és capaç de poder llegir els logs d'un Firewall i llençar les alarmes que es consideri necessari)

Un aspecte important de les ACL és que el firewall les llegeix en ordre. Si nosaltres tenim una configuració similar a:

ACCEPT port 80
DENY ALL

La primera acl serà la que accepti paquets al port 80, per tant, només acceptarà aquest tipus de paquets, ja que la resta seran tots denegats.

Per tant, hi ha dos grans polítiques alhora de configurar el nostre Firewall, podem partir de crear una ACL com a llista negra (Informem de tot allò que volem bloquejar), o crear una ACL com a llista blanca (Informem de tot allò que volem deixar passar). La segona opció sempre és més segura, és la opció de bloquejar tot el tràfic, amb la excepció d'aquell que volem deixar passar.

El firewall de iptables

Com ja és comú, moltes vegades per entendre les solucions actuals, és millor cercar solucions antigues però més fàcils d'entendre, per després, poder fer el pas a entendre les solucions més complexes. Aquest és el cas dels firewalls de Linux (en especial Debian). Per això, farem primer una petita explicació del firewall d'iptables, per després, explicar la solució actual de nftables.

Encara a dia d'avui és el firewall més conegut en distribucions Linux i a vegades pot tenir una configuració no gaire fàcil. Per això, les noves distribucions Ubuntu han incorporat per defecte el firewall UFW, una versió amigable i amb menys opcions que l'Iptables. (Molt fàcil de fer servir quan volem configuracions estàndards).

Abans d'entrar a fons amb Iptables, cal entendre el funcionament intern de com organitza el tràfic i el tipus de regles i taules amb les que treballa.

Entendre aquest esquema és clau per entendre el funcionament d'Iptbles. És comú saber-se les principals acl de l'Iptables, però un bon administrador IT ha de ser capaç d'entendre el seu funcionament i crear la regla que es requereixi en cada moment.

Si us fixeu, l'esquema té dues entrades possibles i dues sortides possibles, aquest serà el tràfic en qualsevol dels nostres dispositius Linux, o el tràfic ens prové de fora o el genera una aplicació, i al revés, o enviem el tràfic cap a la xarxa o cap alguna de les nostres aplicacions. Una opció, que podeu veure recollida, és que a vegades ens podem trobar amb un tràfic que pot provenir d'una xarxa i després sortirà per una altra xarxa (un router).

Després, cadascuna de les fases per on es mou el nostre tràfic és anomenat com a chain i en total en tenim cinc: PREROUTING, FORWARD, POSTROUTING, INPUT, OUTPUT. Aquestes cadenes ens serveixen per determinar on es troba el paquet que volem filtrar. Per exemple, si tenim el paquet en POSTROUTING, significarà que està a punt d'anar cap a la xarxa; o per exemple, si tenim un paquet en INPUT, voldrà dir que està a punt d'entrar en la nostra aplicació.

Però tota aquesta informació, encara que sembli que es guardi en chains, no és així, sinó que les diverses ACL es guarden en les taules que tenim: mangle, nat, filter. Cadascuna d'aquestes taules té una funció i una semàntica diferent:

MANGLE: Ens permet la modificació de les capçaleres dels paquet en la capa 3 i 4.
FILTER: És la taula que ens permet filtrar els paquets en la capa 3 i 4.
NAT: És la taula que ens permet configurar el protocol Network Address Translation (abans ja explicat)

Així doncs, si volíem crear una ACL que permetés el tràfic SSH pel port 22, només des d'una IP determinada faríem:

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

I automàticament, iptables ens afegiria la ACL en la chain d'INPUT i en la taula de filter. A partir d'aquí, les opcions eren múltiples, però en l'actualitat, Debian recomana treballar amb nftables, el firewall per defecte des de la versió 11 Bullseye.

El Firewall de nftables

Nftables encara és un programari relativament nou, serà molt comú que us trobeu amb configuracions d'Iptables, i part de la vostra tasca inicial, sigui la de traduir-ho cap a nftables. Una opció que tenim disponible, és un traductor automàtic:

$ 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 és una aplicació més aviat complexa, sobretot perquè venim d'iptables que ja era força més amigable per la majoria d'administradors IT, i que a diferència de nftables, tot estava més estructurat. Tota la informació la podem trobar a la seva wiki nftables.

Per utilitzar nftables cal tenir present:

Les taules ara son contenidors de chains sense que aquestes hagin de tenir una semàntica concreta.
Les cadenes dins d'una taula contenen regles (ACL)
Les regles fan referència a un conjunt d'accions que s'executen en una chain.

https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes

https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

Fixem-nos ara, amb la diferència alhora d'entendre l'esquema de nftables:

Anem a intentar endreçar tot el que veiem, que d'entrada, ja veiem que és força més complex. Tot i així, no és impossible d'entendre. Fixeu-vos, pensem amb una connexió ssh i observem els passos que faria segons l'esquema:

Ens arriba una connexió a l'INGRESS.
Després valora si és una connexió bridge.
També valora si és un paquet ARP o IP, arriba a IP Layer.
És analitzat per el hook PREROUTING.
La connexió ssh és local, per tant, després va al hook INPUT.
Per acabar, arriba a l'aplication layer, i serà tractat a nivell d'aplicació (fora de capa 3-4)

Per tant, aquesta connexió ha pogut ser tractada per tres hooks: INGRESS, PREOROUTING o INPUT. S'assembla una mica al que havíem vist amb Iptables.

Potser la part més estranya era el hook d'ingress, doncs és una de les particularitats interessants de nftables, doncs ens permet associar cadascun dels hooks ingress, a una interfície concreta.

Però què és un hook? Doncs son els tipus de chain que teníem abans.

Per posar en context

Podem generar les taules que vulguem, a més a més, si volem, les podem relacionar amb alguna de les famílies ja existents: ip, arp, ip6, bridge, inet, netdev. Aquestes famílies van molt relacionades amb la capa on treballen.

El primer de tot, és que amb nftables, les taules tenen un significat diferent, ara mateix hi ha

En total tenim 6 tipus de taules: ip, arp, ip6, bridge, netdev.

En el moment que generem una taula, haurem d'indicar de quin tipus és.

Aquí farem un repàs de com podem començar, i sobretot, entendre La :figure:figura.01: mostra de forma esquemàtica com s'avaluen les regles.

figure:figura.01

title: Esquema de funcionament d'una Llista de control d'accés

 :footer:

Fpce:cib:m02:u2:a3:cib m02 u2 016.png?200

Així, quan un paquet arriba al tallafoc, el sistema comença a avaluar les regles en l'ordre que han estat configurades, un cop es troba que el paquet compleix la condició de la regla, se li aplica el comportament que s'ha preestablert i es para de buscar. En el cas que el paquet no compleixi cap de les condicions estipulades per les regles, se li aplicarà el comportament per defecte, que a voltes pot ser d'//ACCEPT// o //DENY//.

example:

title: Exemple de regla al tallafoc amb nftables

A tall d'exemple, la eina de codi obert nftables, l'estàndard de facto dels sistemes Linux, i substitut del clàssic iptables proposa el següent l'esquema d'una regla:

 * Taula on s'ha de posar la regla
 * La cadena dins de la taula
 * Llista de condicions
 * Acció

On la taula és el tractament general del paquet, normalment s'utilitza per indicar quin comportament té el sistema, per al propòsit d'aquesta lliçó el que és rellevant és el filtratge de paquets. La cadena és el lloc dins de la taula on s'interceptarà el paquet.

\\ Així un exemple de regla en aquest cas pot ser:

\\ # nft add rule ip filter input ip saddr 192.168.134.0/24 drop

\\ Que no permetria el tràfic entrant al sistema que provingués de la xarxa 192.168.134.0/24

text:

title:nftables

Surt fora de l'objectiu d'aquesta lliçó aprofundir en la forma de funcionament de nftables, una forma simplificada d'entendre una cadena és analitzant el paquet i veient si és d'entrada, de sortida, o si va dirigit al mateix equip del tallafoc o no. Podeu trobar més informació sobre nftables a: [[1]].

Condicions a les regles

A l'hora d'establir les regles, un tallafoc permet establir condicions que contemplin la gran majoria de camps de la capçalera tant a nivell de xarxa com a nivell de transport. En alguns casos, i trencant la regla que un tallafoc treballa com a molt a nivell de transport, hi ha solucions que permeten especificar alguns camps a nivell d'aplicació, això és així per fer tallafocs més competitius comercialment.

Així, típicament un tallafoc utilitza els següents camps per identificar el tràfic:

 * **Protocol**: IPv4, IPv6, ICMP, ARP, TCP, UDP, SCTP, DCCP...
 * **Adreces de xarxa**: origen o destí, inclús es permet l'especificació de subxarxes
 * **Servei**: utilitzant els ports origen i destí es pot limitar o permetre el tràfic dirigit a una aplicació particular, per exemple HTTP, FTP, SSH, Telnet...
 * **Estat de la connexió**: quan s'utilitza un protocol de transport orientat a connexió com ara TCP es pot limitar per estat de connexió: Establerta, Iniciant-se, Acabant, Nova, ja existent...
 * **Interfície**: si bé un tallafoc treballa a nivell de xarxa, té consciència dels nivells inferiors i permet especificar, per exemple, la interfície de xarxa per la qual han arribat o marxaran els paquets

important:

Si bé com s'ha dit anteriorment, hi ha tallafocs que treballen a nivell d'aplicació en segons quins casos, això acostuma a tenir implicacions en el rendiment, ja que poder donar suport a nivell d'aplicació s'han d'analitzar molts bytes del paquet, fet que porta més temps i complexitat algorísmica. Així, com a norma general, es recomana **que no s'utilitzi un tallafoc amb regles del nivell d'aplicació**, és molt més efectiu utilitzar //Web Application Firewalls// (WAF) o //Proxies//.

Limitacions dels firewalls

Cal tenir en compte que un tallafoc, com qualsevol altre component d'una xarxa, només pot actuar a sobre el tràfic que veu. És per això que és imprescindible ubicar el tallafoc en una localització estratègica on tot el tràfic entrant i sortint passi a través d'ell. Així i tot, els tallafocs tenen algunes restriccions importants.

El fet de treballar a nivell de xarxa, fa que un tallafoc no pot analitzar el tràfic entre dos sistemes que estiguin a la mateixa subxarxa, ja que es comuniquen directament sense passar per l'encaminador, aquesta limitació es pot mitigar mitjançant l'ús de tallafocs a les mateixes estacions de treball, que proporcionen seguretat a nivell local a l'equip. Cal notar, que aquest punt reflecteix una altra limitació d'aquests sistemes, com a ens centralitzat, deslocalitzar els tallafocs a les estacions de treball implica una tasca d'administració molt important, ja que els tallafocs no proporcionen sistemes d'administració distribuïts.

Donat el funcionament estàtic de les regles, quan hi ha canvis a la política de seguretat, o als serveis, el canvi a un tallafoc s'ha de fer de forma manual, així, clàssicament els tallafocs manquen de capacitats dinàmiques a les regles i adaptabilitat als canvis en les polítiques.

D'altra banda, i relacionat amb la manca de dinamisme, els tallafocs només coneixen informació de xarxa, per la qual cosa no protegeixen contra errors en la configuració dels serveis, o l'ús de contrasenyes insegures o aplicacions mal configurades, que passen a ser un vector d'atac molt clàssic i indetectable pels tallafocs.

Evolució actual dels tallafocs

Arran de les limitacions presents als tallafocs, la indústria ha evolucionat a models de seguretat molt més avançats, tot utilitzant el tallafoc com la base i pedra angular de la seguretat d'un sistema. Així s'ha evolucionat d'un model de tallafocs tradicional cap a un model amb sistemes avançats com ara:

UTM (Unified Threat Management)

NGFW (Next Generation Firewall)

UTM (Unified Threat Management)

Amb l'objectiu de simplificar la gestió de la seguretat, els Unified Threat Management són una evolució directa dels tallafocs, bàsicament un UTM proporciona un sistema amb múltiples funcions de seguretat en un paquet únic, que evita haver de tenir diversos sistemes de gestió, així els UTM integren en un mateix sistema Tallafocs, Intrusion Detection System (IDS), Intrusion Prevention Systems (IPS). Però, depenent del fabricant també inclouen antivirus, tallafocs a nivell d'aplicació, com ara proxies o detectors de physhing i de llocs fraudulents; sistemes per evitar la pèrdua de dades (Data Loss Prevention (DLP)), sistemes per la gestió d'alertes (Security information and event management (SIEM)), Virtual Private Networks (VPN), i mitigació d'atacs de denegació de servei (DoS).

Totes aquestes funcionalitats estan integrades generalment amb un centre de control que permet orquestrar i gestionar el comportament del sistema, dotant així la xarxa d'una protecció integral.

NGFW (Next Generation Firewall)

Es podria pensar que amb els UTM la xarxa ja té el nivell de seguretat desitjat, si bé els UTM són una millora estructural als tallafocs, continuen tenint un problema important i és el fet que el sistema continua sent eminentment local, o sigui que tota la gestió contempla que l'organització està administrada i gestionada localment, així les actualitzacions del sistema i la gestió de regles, si bé millor que amb els tallafocs, continuen depenent en gran manera del coneixement de l'administrador. D'altra banda, continuen tenint el problema que no proporcionen una "Defensa en profunditat", ja que la topologia de la seguretat continua sent eminentment centralitzada.

Així, amb l'aparició de noves tecnologies al núvol i la gran millora present actualment en els sistemes basats en intel·ligència artificial, apareixen el que es coneix com els Next Generation Firewalls (NGFW).

Els NGFW no són més que l'evolució tecnològica dels UTM, però amb capacitats al núvol, on el tallafoc ja no és una entitat local, sinó que està deslocalitzada al núvol amb les capacitats i integracions del fabricant, qui de forma transparent actualitza les polítiques de seguretat, actualitza els sistemes per suportar les noves amenaces que van apareixent i proporcionen un sistema dinàmic que s'ajusta a les necessitats de cada xarxa de forma transparent.

Per complementar els NGFW, la presència de la intel·ligència artificial proporciona una adaptabilitat sense precedents, on el sistema aprèn del comportament dels usuaris i la dinàmica de comunicació entre els actors de la xarxa permetent detectar anomalies d'una forma molt més efectiva.

Així un NGFW proporciona les característiques típiques d'un tallafoc: inspecció amb estat del tràfic, amb la prevenció d'intrusions integrada, però amb capacitats semàntiques per entendre les aplicacions, per analitzar-les i bloquejar-les quan sigui necessari de forma dinàmica. El NGFW proporciona fonts d'intel·ligència d'amenaces i mecanismes d'actualització per mantenir les bases de dades al dia amb tècniques flexibles per mitigar amenaces canviants.

Els beneficis dels NGFW són:

La consciència de les aplicacions (Application awareness), on es permet indicar les regles particulars per cada aplicació en comptes d'utilitzar dades de xarxa com ara ports o adreces IP. D'aquesta manera quan es defineix una aplicació, amb aquesta definició es pot proporcionar la seguretat en l'àmbit corporatiu i detectar amenaces, així és molt més senzill indicar-li al sistema: bloquejar xarxes socials, més que haver de configurar centenars de regles al tallafoc amb totes les IP de totes les xarxes socials existents.
Intrusion Prevention Systems avançats i dinàmics, amb regles actualitzades al núvol.
Intel·ligència d'amenaces (Threat Intelligence), amb regles dinàmiques als tallafocs per mitigació de noves amenaces.
Anàlisi detallada del tràfic (Deep Packet Inspection) de forma distribuïda i eficient per detecció de programari maliciós (malware) de forma avançada.
Informació de context, un NGFW treballa de forma distribuïda i considera la informació rebuda de forma coordinada i contextualitzada.

example:

title: Exemple de regla avançada en un NGFW

Amb un tallafoc no es pot indicar una regla per detectar accessos fraudulents, però amb un NGFW es poden indicar regles de l'estil:

 * Detectar accessos fallits a la base de dades i llençar una alerta de nivell baix si succeeix
 * Si aquest accés fallit s'ha fet des de fora de l'empresa, s'emet una alerta de nivell mitjà
 * I si s'ha realitzat fora de l'horari laboral i des d'un país asiàtic emet una alerta de nivell alt.

Aquesta contextualització permet elevar el nivell de seguretat per sobre de les capacitats d'un tallafoc.

Els detectors d'intrusos: IDS/IPS

Com passa amb moltes eines de seguretat, els IDS/IPS han anat evolucionant, per exemple, avui en dia ens costaria trobar un IDS que no fos alhora IPS, i al final, se'ls acaba definint més per la funció que fan en el sistema en qüestió. A més a més, actualment ja no només estan orientats a les intrusions no autoritzades, sinó que poden tenir altres funcions com la detecció d'un atac DDoS.

Els conceptes claus d'un IDS/IPS son:

Escolta tot el tràfic de xarxa, si volem que treballi com a IPS s'haurà de situar entre els dos punts d'origen i destí, i si volem que treballi com a IDS podem duplicar el tràfic amb un splitter.
Hi haurà un conjunt de regles que analitzaran el tràfic, molts IDS/IPS fan servir la nomenclatura de les regles SIGMA, però no és universal. Aquestes regles poden estar basades o en signatures, o en comportaments.
Les regles d'un IPS, a més d'enviar alertes, també tindran la possibilitat de bloquejar el tràfic.
Hi ha biblioteques de regles que podem anar instal·lant al nostre IDS/IPS.
Tenen visibilitat fins a la capa d'aplicació.

Un IDS/IPS generalment manté una base de dades d'atacs coneguts i compara els patrons d'activitat observats que estan monitorant, d'aquesta manera es poden reconèixer quan es produeix una coincidència propera entre un atac conegut i un comportament actual o recent a la xarxa.

Una altra possibilitat que ens proporcionen la majoria d'IDS/IPS és executar algun tipus d'ordre en la mesura que salti una alarma o un bloqueig. A partir d'aquí, les opcions poden ser infinites, poden generar noves regles, poden agregar ACL al firewall, o poden recopilar un conjunt d'evidències per després analitzar-les a través de forensics.

Des del punt de vista de l'arquitectura, d'IDS n'hi ha de tres tipus, els Network Intrusion Detection System (NIDS) i els Host Intrusion Detection System (HIDS).

Network Intrusion Detection System (NIDS)

Els Network Intrusion Detection System NIDS són sistemes de detecció d'intrusions analitzant el tràfic de xarxa. Internament, és similar a un tallafoc, en el sentit que tots dos es basen en l'anàlisi del tràfic, però en el cas del NIDS es miren més camps del paquet i es busquen signatures conegudes al tràfic.

Un NIDS, per poder actuar i analitzar de forma correcta el tràfic de xarxa, necessita poder capturar i estudiar els paquets fins a la capa d'aplicació, això implica que ha de fer el que es coneix com inspecció profunda de paquets (Deep packet inspection o DPI). DPI és una forma de filtratge de paquets de xarxa que examina la part de les dades, la interpreta i analitza. El NIDS amb aquesta informació normalment busca problemes coneguts als protocols, o bé signatures de virus, correu brossa (spam) o intrusions amb criteris predefinits, aleshores es decideix si el paquet pot passar o no, o inclús si cal enviar-lo a un destí diferent. També es pot analitzar per extreure'n informació estadística.

Els NIDS inicialment s'implementaven amb maquinari específic, però avui dia amb les tecnologies al núvol i la millora dels equips de propòsit genèric com servidors, han passat a un model basat amb programari executant-se directament amb un sistema operatiu genèric.

Host Intrusion Detection System (HIDS)

El Host Intrusion Detection System (HIDS) monitora les característiques d'un sol equip, se centra en els esdeveniments que ocorren en aquest equip i cerca activitat sospitosa. L'HIDS inspecciona el tràfic de xarxa que arriba a l'equip, però també els registres del sistema (logs), els processos en execució, els accessos i modificacions de fitxers, els canvis de configuració del sistema i les aplicacions.

Per poder funcionar correctament un HIDS s'implementa mitjançant un agent instal·lat als equips o aplicacions d'interès: cada agent monitora l'activitat i transmet informació als servidors d'administració. D'aquesta manera una de les funcions principals d'un HIDS és d'actuar de verificador de la integritat del sistema, monitors de fitxers de registre i de sistemes trampa (tipus honeypot).

Un sistema trampa o honeypot és un sistema que simula una vulnerabilitat o un comportament particular d'una màquina fent creure a l'atacant que està vulnerant un sistema real.

Des del punt de vista d'arquitectura, es recomana que l'agent HIDS s'instal·li a tots els equips de l'organització, des dels equips dels empleats fins als servidors, en el cas dels equips de xarxa que no tinguin la possibilitat de tenir instal·lat un HIDS s'ha d'efectuar l'enviament dels registres d'events a un servidor que sí que en tingui, d'aquesta manera es poden detectar les amenaces existents.

Cal dir que els HIDS en l'actualitat es coneixen sovint amb el nom d'EDR (Endpoint Detection and Response o 'Detecció i resposta a l'equip final'), i s'han convertit amb la pedra angular de la seguretat corporativa.

Fortificació i gestió del Switch

Fins aquest punt, tots els aspectes de seguretat tractats han posat el focus en el nivell de xarxa i superiors. Si bé aquests nivells són els que generalment reben més atenció, convé no negligir altres aspectes importants. Els commutadors, donat que treballen a nivell d'enllaç de dades, seran la primera línia de defensa, tant contra els atacs físics de denegació de servei, com per atacs de suplantació d'identitat o d'accés a la xarxa.

Per protegir un commutador es poden utilitzar diferents estratègies, algunes d'elles depenen del fabricant del commutador; així i tot, hi ha una sèrie de bones pràctiques que tot administrador de xarxes hauria d'implementar:

Protegir l'accés físic al dispositiu: tot i ser complicat en la majoria dels casos, permetre l'accés al commutador permet a un atacant desconnectar cables d'equips existents o bé connectar el seu propi cable per accedir a la xarxa. També cal vigilar aquells accessos que s'han quedat oblidats, hauríem de comprovar que el nostre switch només tingui obertes les interfícies que n'està fent ús.
Contrasenyes predeterminades: la immensa majoria de commutadors gestionats tenen contrasenyes predeterminades per al primer cop que un usuari s'hi connecta. És imprescindible canviar aquesta contrasenya per evitar que un atacant prengui control del dispositiu.
SNMP v3: si és possible utilitzar la versió 3 de SNMP és més segur fer-la servir, si no es pot, aleshores es recomana que la contrasenya community que feu servir sigui molt llarga per evitar que sigui massa fàcil d'endevinar.
Registre de logs: configurar el registre centralitzat per poder observar les activitats del commutador. D'aquesta manera i juntament amb HIDS se simplifica enormement la correlació d'events al servidor.
Authorization, Authentication, Accounting (AAA): és molt convenient activar la gestió per usuaris al commutador. D'aquesta manera s'agrupen els ports i se'ls hi assigna automàticament una VLAN depenent de l'usuari que s'estigui connectant. Això es pot aconseguir amb RADIUS de forma senzilla si el commutador ho suporta.
Identificador d'usuari/contrasenya locals: en cas d'utilitzar AAA, cal estar segur que hi ha algun usuari configurat localment al commutador que en cas de no funcionar el sistema s'hi pugui connectar l'administrador per solucionar el problema.
VLAN de gestió: molts commutadors admeten una VLAN de gestió, aquesta VLAN permet administrar el commutador, així, com els usuaris utilitzaran una VLAN diferent serà impossible que puguin canviar la configuració de l'equip.
Segmentació de la xarxa: és imprescindible segmentar la xarxa amb VLAN per segregar les diferents parts de la xarxa. Relacionat amb aquest punt, cal també configurar el tallafoc amb les ACL necessàries per controlar els fluxos de tràfic entre elles.
Etiquetatge de ports: si bé no és una mesura de seguretat per se, però és important i estalvia molta feina si cada port del commutador està etiquetat a nivell de configuració amb l'equip o el propòsit del port. Llavors mostrant la configuració del port es pot veure fàcilment quin equip hi ha connectat.
SSH vs Telnet: Telnet es considera un protocol no segur, viatja en clar, i per això és més segur utilitzar SSH v2 per xifrar les comunicacions.
Interfície web: en cas que sigui necessària convé fer servir SSL o, si no és necessària, es pot deshabilitar. Malauradament, molts commutadors encara necessiten que es gestioni el dispositiu mitjançant diverses interfícies, ja que no totes les funcionalitats estan disponibles a totes les interfícies.
IP de gestió: molts commutadors permeten configurar les adreces IP de gestió del dispositiu. Si és així és important configurar-la per limitar qui pot administrar l'equip i des de quina interfície ho podrà fer.
Seguretat del port: si la configuració d'AAA no és possible, convé molts cops habilitar el control d'accés per MAC al dispositiu, així només es permetrà la connexió d'equips coneguts, si la MAC de l'atacant no és coneguda, el commutador automàticament tanca el port on es connecti l'atacant. També es pot configurar, que només accepti la MAC del primer dispositiu que s'hi connecti per primera vegada.
VLAN dinàmica: les VLAN dinàmiques són aquelles on es decideix la VLAN del port arran de conèixer qui és l'usuari (o la MAC) del dispositiu que s'ha connectat.
NTP: sincronitzar el rellotge del commutador és important per poder correlar events amb la data adequada.
Supervisió: cal vigilar el tràfic que passa pels ports del commutador, si s'observa 10 cops més de tràfic per un port, convé mirar què pot estar passant.
Limitar el nombre d'adreces MAC per port: en cas que algun usuari vulgui configurar més d'una adreça MAC al seu equip, per exemple, configurant un punt d'accés sense fils o actuar com a commutador, a aquestes MAC extra no se'ls hauria de permetre l'accés a la xarxa.

Fortificació dels accessos wifi

La fortificació d'accés a la xarxa sense fils és extremadament crítica, ja que un potencial atacant no té per què estar dins de l'organització per poder realitzar algun atac; en aquest cas, la cobertura de la xarxa podria arribar fins al carrer sense problemes.

D'aquesta manera tenir una bona política de seguretat és imprescindible. Les recomanacions a l'hora de protegir la seguretat del sistema són:

No permetre l'existència de punts d'accés no registrats: si bé això no afecta a la configuració de la xarxa en si, és important remarcar que si es detecta un punt d'accés no conegut dins la xarxa s'ha de bloquejar tot el seu tràfic de forma automàtica.
Utilitzar protocols de protecció wifi: no s'ha de permetre la presència de punts d'accés oberts o amb seguretat tipus WEP, ja que són sistemes obsolets i clarament insegurs. La recomanació és emprar com a mínim WPA v2.0, tant en la seva modalitat Personal com Enterprise. La versió Personal permet connectar-se als usuaris amb una contrasenya única, mentre que la versió Enterprise permet, a través de sistemes federats autenticar usuaris i donar-los la configuració de xarxa adequada.
Contrasenyes predeterminades: igual que amb el cas del commutador, els punts d'accés tenen contrasenyes predeterminades per al primer cop que un usuari s'hi connecta. És imprescindible canviar aquesta contrasenya per evitar que un atacant prengui control del dispositiu.
Registre de logs: configurar també el registre centralitzat per poder observar les activitats del commutador.
SNMP v3: si és possible fer servir la versió 3 de SNMP és més segur fer-la servir. Però en qualsevol cas és un protocol que permet observar estadístiques de l'equip.
NTP: sincronitzar el rellotge del punt d'accés és important per poder correlar events amb la data adequada entre fonts de registres diferents.
Deshabilitar el servidor DHCP: és convenient centralitzar a un equip l'assignació d'adreces IP, és millor tenir un servidor encarregat que no el punt d'accés.
SSH vs Telnet: Telnet es considera un protocol no segur, viatja en clar, i per això és més segur utilitzar SSH v2 per xifrar les comunicacions.
Filtratge d'adreces MAC: si no hi ha possibilitat d'usar WPA Enterprise, aleshores limitar l'accés per MAC pot ajudar a mitigar problemes de seguretat.

Comunicacions segures en entorns no confiables

Per tal de garantir la seguretat dels sistemes és important, com ja s'ha vist, seguir certes bones pràctiques, però hi ha cops, que és necessari estar connectats des de xarxes no confiables, encara més, és ben conegut que Internet és una xarxa inherentment insegura per defecte, donada la falta de seguretat inherent al protocol IP i l'existència de protocols no xifrats. Per tant, és primordial per garantir la seguretat en les comunicacions que existeixin mecanismes que facin més segura la xarxa.

D'aquesta manera, per tenir comunicacions segures s'han identificat dos mecanismes diferents:

Xarxes Privades Virtuals (//Virtual Private Networks// o VPN).
Utilització de protocols segurs

Xarxes Privades Virtuals (Virtual Private Networks o VPN)

Una VPN és un mecanisme per crear connexions segures entre dues ubicacions de la xarxa. Per aconseguir-ho, una VPN crea el que es coneix com una overlay, o sigui, una xarxa a sobre d'una xarxa, el que a la pràctica significa que es creen túnels de tràfic IP dins del tràfic a nivell de xarxa o de transport.

En la següent imatge podem veure com funcionaria un paquet amb totes les seves capçaleres viatjant per una xarxa:


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

Un software VPN, el que provoca és que encripta les capes de xarxa, transport i aplicació, les guarda totes en la capa d'aplicació, i envia els paquets a l'altre extrem de la VPN que desencriptarà la informació, i podrà conèixer l'origen, el port, i les dades que s'hi continguin. Al treballar amb dades de capes 3-4, ens permet també treballar amb aquests protocols, com per exemple, el protocol ICMP.

Així doncs, el nou paquet tindria 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

També existeixen VPN que treballen a nivell de capa d'enllaç de dades, aquestes VPN ens permeten comunicar-nos de forma segura dins una mateixa xarxa.

La part important és entendre, que nosaltres tindrem en la nostra xarxa algun tipus de servidor VPN que rebrà els nostres paquets, si el servidor llegeix que la informació s'ha d'enviar a la xarxa que hi ha a l'altra banda de la VPN, encapsularà i encriptarà tota la informació, refarà les capçaleres de la capa 3 i 4, i ho enviarà a l'altre servidor VPN que tenim a l'altra banda de la xarxa. És a dir, en cas que hi hagués una escolta del nostre tràfic, només aconseguirien les dues IPs dels servidors VPN, però la resta de dades restarien encriptades.

De VPN n'hi ha de tres tipus, depenent de qui treballa com a servidor:

Host-to-Host: Els dos equips tenen una aplicació que corre com a servidor VPN i no hi ha cap xarxa entre ells.
Network-to-Host: És el típic cas del teletreball, volem per exemple, que l'ordinador del treballador funcioni com si estigués dins la pròpia empresa, per això, el dispositiu del treballador tindrà un servidor VPN i a l'altre exemple hi haurà un dispositiu de capa 3 (router) amb una altra aplicació de servidor VPN.
Network-to-Network: En aquests casos, l'objectiu és connectar dues xarxes entre elles. El nostre router tindrà una aplicació VPN interna, que quan redirigeixi els paquets cap a l'altre extrem de la VPN els encriptarà.

L'ús de VPN ha estat extensiu des de fa molts anys, amb un increment notable arrel de la pandèmia de la COVID-19.

Ús de protocols segurs

En molts casos l'ús de VPN no és pràctic o bé no està disponible, una bona opció que a poc a poc està agafant volada és la utilització de protocols que ja són segurs de base.

Alguns exemples d'aquests protocols segurs de base poden ser l'HTTPS o l'SSH, els quals encripten les dades entre extrems. És habitual, que les aplicacions, per fer comunicacions segures, fan ús d'aquests protocols com l'HTTPS. Tots aquests protocols es consideren d'una seguretat equivalent a la VPN i molts d'ells provenen de la implantació de sistemes d'encriptació en protocols inicialment no segurs com el HTTP o el Telnet.

Menció especial mereix el protocol DNS, el qual un atacant podria monitorar els dominis que està visitant la víctima, aconseguint informació que s'hauria de mantenir privada. En l'actualitat existeix el DNSSEC, que encripta la informació entre extrems i n'assegura l'autenticitat, la integritat i la confidencialitat de les dades. Però és un protocol que no està estès i les aplicacions com els navegadors no el tenen incorporat.

Fortificació i monitoratge de la xarxa interna

La fortificació des de IT

Com administradors IT, la nostra missió és assegurar la nostra xarxa i els nostres sistemes. La nostra organització ens reclamarà seguretat, és a dir, confidencialitat, integritat i disponibilitat de les dades. Tot això, de forma constant, i sense tenir en compte la evolució de les amenaces cibernètiques. Per això, és bàsic seguir un conjunt de passos que ens ajudin a securitzar el nostre sistema.

Implementar la protecció perimetral

Utilitzar tallafocs per controlar i monitorar el trànsit de la xarxa, permetent només el trànsit autoritzat i bloquejant els intents d'accés no autoritzats.
Configurar polítiques de filtratge d'adreces IP per prevenir atacs de denegació de servei (DDoS) i limitar l'accés des d'ubicacions geogràfiques indesitjades.

Actualitzacions i Patchs

Implementar un programa de gestió d'actualitzacions per garantir que tots els dispositius de la xarxa tinguin les últimes actualitzacions de seguretat.
Automatitzar el procés d'actualització per minimitzar el temps de vulnerabilitat dels sistemes.

Sistemes d'autenticació forta

Utilitzar protocols d'autenticació robustos com LDAP o Kerberos per verificar la identitat dels usuaris i dispositius.
Implementar l'autenticació multifactorial per afegir una capa addicional de seguretat mitjançant factors com ara claus de seguretat o autenticació biomètrica.

Monitoratge Continu

Desplegar eines de monitoratge de seguretat per detectar activitats sospitoses a la xarxa.
Configurar alertes per a incidents de seguretat i establir protocols de resposta ràpida en cas d'atacs o comportaments anòmals.

Xifrat de Dades

Implementar protocols de xifrat robustos com SSL/TLS per protegir les comunicacions sensibles entre els dispositius.
Utilitzar xifrat de disc per protegir les dades emmagatzemades en servidors i dispositius de la xarxa.

Gestió de Polítiques de Seguretat

Establir polítiques de seguretat clares i aplicables a tots els usuaris i dispositius de la xarxa.
Educar els usuaris sobre les pràctiques de seguretat, com ara la creació de contrasenyes fortes i la prevenció de l'enginyeria social.

L'enfortiment d'una xarxa interna és un procés continu que requereix vigilància constant i adaptació a les noves amenaces. La implementació d'aquestes pràctiques contribuirà a crear una xarxa robusta, resistent als atacs cibernètics i protegida contra possibles vulnerabilitats.

Complementant tot això, és crític per la seguretat d'una xarxa conscienciar als empleats de les organitzacions amb la utilització de bones pràctiques i tenir consciència del perill de compartir dades privades o de negligir aspectes com la robustesa de les contrasenyes o bé la detecció d'intents d'atac d'enginyeria social.

Al final, l'enfortiment d'una xarxa interna és una tasca crítica per a qualsevol organització que desitgi garantir la seguretat, la integritat i la disponibilitat de les seves dades. A mesura que les amenaces cibernètiques evolucionen, és essencial adoptar estratègies i pràctiques que protegeixin eficaçment els recursos de la xarxa. Per això, tot i que les bones pràctiques abans comentades sempre hi han de ser-hi, requerirem d'altres eines que ens ajudaran a monitorar el sistema i poder respondre de manera eficaç als incidents de ciberseguretat.güents estratègies:

Els registres monitorables

El monitoratge de registres (logs) forma part de les tasques crítiques a tenir en compte amb un entorn segur, monitorar registres proporciona informació vital sobre l'estat, el rendiment i els esdeveniments (events) rellevants del sistema operatiu.

Amb independència del sistema operatiu utilitzat, l'anàlisi i gestió del monitoratge de registres ha de considerar certs aspectes fonamentals. D'entrada ha de monitorar els events del sistema operatiu**:

Errors al nucli del sistema
Events inesperats com accessos a fitxers per usuaris sense privilegis
Accessos fallits al sistema, sigui localment o remotament
Inici, parada i duració de les sessions dels usuaris
Accions realitzades pels administradors
Ha de monitorar els serveis oferts: HTTP, Mail...,tot monitorant accessos erronis, mal funcionaments...

Tots aquests registres els podem monitoritzar amb un EDR o un HIDS, és la forma actual més utilitzada, d'aquesta manera es centralitza la vigilància dels nostres serveis. Però aquest tipus d'aplicacions tenen el seu propi funcionament intern i moltes d'elles tenen formacions especialitzades. Per això, ara farem un repàs d'aquelles aplicacions de sistema que tenim al nostre abast per poder fer les mateixes tasques de monitoreig.

A continuació, s'analitzen les capacitats de monitoratge de registres en dos dels sistemes operatius més utilitzats: Linux amb rsyslog i journalctl, i Windows amb el seu Event Log.

Anàlisi de registres amb Linux: rsyslog

rsyslog és un sistema de registre per a sistemes UNIX que permet la recopilació, el processament i l'enviament de registres a diversos destins. Suporta protocols com syslog, TCP i UDP, i proporciona una flexibilitat considerable per personalitzar el tractament dels registres.

Les parts que formen el rsyslog són:

Senders: configurats per enviar registres des de les aplicacions o sistemes als servidors de registres.
Receivers: encarregats de rebre els registres i dirigir-los al destí adequat.
Filters: permeten seleccionar i processar registres basant-se en criteris específics, com ara nivell de gravetat o origen.

Facilities amb rsyslog

Una facility es refereix a una categoria o tipus de missatges de registre que es poden generar pel sistema. rsyslog usa el protocol syslog, que és un protocol estàndard de registre.

Les facilities en syslog són un mecanisme per classificar els missatges de registre en categories específiques, indicant la naturalesa del missatge i el component del sistema que l'ha generat. Cada missatge de registre syslog conté una facility i un severity level (nivell de gravetat), que determinen la importància i la categoria del missatge.

Hi ha 24 facilities estàndard a syslog, i cadascuna es designa amb una paraula clau que descriu la categoria dels missatges associats. Algunes de les facilities més comunes són:

kernel: missatges del kernel del sistema operatiu.
user: missatges d'usuaris generals o aplicacions que no estan associats amb altres facilities.
mail: missatges relacionats amb el correu electrònic.
daemon: missatges de serveis del sistema (daemons).
auth: missatges d'autenticació i seguretat.
syslog: missatges generats pel propi daemon syslog.
lpr: missatges relacionats amb la impressió.
news: missatges de sistemes de notícies.
uucp: missatges relacionats amb el protocol UUCP (Unix-to-Unix Copy).
cron: missatges relacionats amb el programador de tasques cron.
authpriv: missatges d'autenticació privats (seguretat privada).

Convé no confondre les facilities amb aplicacions, la faclilty només proporciona un mecanisme de classificació, per exemple amb fitxers diferents.

Severities

Relacionat amb cada facility el sistema també permet, per cada facility determinar la gravetat del missatge. Els severity levels (nivells de gravetat) són:


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

Així, com administradors podem fer que el sistema permeti ignorar segons quines severities depenent de cada facility, per configurar-ho en linux editarem l'arxiu /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
</div>

<div lang="ca" dir="ltr" class="mw-content-ltr">

 :title: Gestió de les severities al fitxer /etc/rsyslog.conf

En aquest cas, es guarda en el registre qualsevol nivell de les facilities auth, authpriv, kern i mail als fitxers que s'observen a la dreta de la llista, mentre que els missatges d'ERROR o superior (ERROR, CRITICAL, ALERT i EMERG) també es guarden al fitxer /var/log/kern-important.log.

Registres amb rsyslog

Els registres amb rsyslog inclouen informació bàsica de quan, qui, on, la gravetat del missatge i perquè es va generar el registre.

Amb una mica més de detall, els camps habituals es poden veure en el següent exemple:

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

Com es pot observar, la informació que hi ha és:

Hora de l'event: 2023-11-14T07:54:46.924376+01:00
Equip que ha generat el registre: acme-server
Aplicació que ha generat el registre: sshd
En aquest punt, el format que hi ha a continuació ja depèn de la facility en si, en aquest cas:
- Informació del event: Failed password
- Usuari: root
- Source IP: 61.183.129.50
- Port: 18705
- Protocol: SSH2

Anàlisi de registres amb Linux: journalctl

A partir de systemd, Linux va introduir journalctl com a eina per accedir als registres del sistema emmagatzemats pel journal del sistema. Aquest servei registra informació detallada sobre esdeveniments (events) del sistema, incloent-hi metadades com ara timestamps i ID de procés. De fet, guarda les mateixes dades que rsyslog però utilitzant un format de base de dades per tenir els registres més compactes.

Amb journalctl, els usuaris poden:

Veure tots els esdeveniments del sistema.
Filtrar registres per nivell de gravetat, origen i temps.
Accedir a informació detallada, incloent-hi missatges d'error i dades relacionades amb processos.

Registres amb Windows

Windows, a nivell de sistema, utilitza l'Event Log com a sistema de monitoratge.

Windows fa servir aquest servei per mantenir registres d'activitats del sistema, seguretat i aplicacions. Aquest sistema està organitzat en tres categories principals:

System Log: registra esdeveniments del sistema, com ara arrencades i aturades del sistema, errors de hardware i missatges del sistema operatiu.
Security Log: recull informació sobre esdeveniments de seguretat, com ara intents d'inici de sessió, canvis de contrasenya i altres activitats relacionades amb la seguretat del sistema.
Application Log: registra esdeveniments relacionats amb aplicacions, incloent-hi missatges d'error, advertències i informació sobre l'ús de les aplicacions.

Els administradors de sistema poden utilitzar l'eina Event Viewer per explorar, filtrar i analitzar els registres d'esdeveniments del sistema. Els esdeveniments s'organitzen segons categories, nivells de gravetat i altres metadades per facilitar la seva gestió.

Amb l'Event Log (a través de l'Event Viewer) es poden registrar, consultar i subscriure's a esdeveniments del sistema per rebre alertes, realitzar accions i senzillament arxivar registres d'esdeveniments. També es poden obtenir els registres per ser exportats a serveis externs en format XML (evtx) o format simple. Windows guarda els logs a la carpeta C:\Windows\System32\winevt\Logs.

Cal anar amb compte, ja que Windows, per defecte, limita la mida de cada un dels fitxers de logs (com System, Security, o Application). De manera que, un cop s'arribi a la mida màxima, se sobreescriuran els registres més antics; si no es volen perdre, s'haurà de, o canviar aquesta configuració, o bé enviar els registres a un equip remot. Això es pot aconseguir de diverses formes, activant des de l'Event Viewer l'arxiu dels fitxers de log al menú propietats, o bé des de la línia de d'ordres, utilitzant:

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

Tipus d'esdeveniments

L'Event Log registra diversos tipus d'esdeveniments (events) que proporcionen informació detallada sobre l'estat, el rendiment i les activitats del sistema operatiu. Els principals tipus d'esdeveniments que es poden trobar són:

Information: aquest tipus d'esdeveniment proporciona informació general o registra activitats normals del sistema. Exemples: inici d'un servei, connexió d'un dispositiu, o una tasca programada completada amb èxit.
Warning:' un Advertiment' indica situacions que no són necessàriament errors, però que podrien requerir atenció. És una advertència sobre una condició potencialment problemàtica. Exemples: baix rendiment d'un servei, manca d'espai en el disc o aturada inesperada d'una aplicació.
Error: indica situacions problemàtiques que poden afectar el rendiment o el funcionament normal del sistema. Exemples: fallada d'una aplicació, error en una tasca programada o problema amb un controlador de dispositiu.
Critical:' el nivell Crític' és el nivell més alt de gravetat i indica problemes greus que poden afectar significativament el rendiment o la disponibilitat del sistema. Exemple: caiguda d'un sistema crític, error en una funcionalitat essencial o fallada important d'una aplicació.
Audit Success: registra esdeveniments d'auditoria quan una acció s'ha completat amb èxit. Exemple: accés a un recurs compartit amb èxit.
Audit Failure: registra esdeveniments d'auditoria quan una acció ha fallat. Exemples: intent d'inici de sessió fallit, intent d'accés no autoritzat.
Security: aquest tipus d'esdeveniment es centra en esdeveniments relacionats amb la seguretat i l'autenticació. Exemples: intent d'inici de sessió, canvis en les polítiques de seguretat.
System: registra esdeveniments del sistema que no encaixen en altres categories específiques. Exemples: inici o aturada del sistema, canvis en la configuració del sistema.

Aquesta classificació en diferents tipus d'esdeveniments facilita la identificació i el diagnòstic d'incidents, problemes o situacions rellevants per a la gestió i el monitoratge del sistema amb l'eina Event Log de Windows. A més a més, Event Log identifica tots els tipus esdeveniments amb un ID, aquest ens permet no només cercar-lo amb més facilitat, sinó també poder-lo utilitzar en el monitoratge i incloure'l en regles del tipus SIGMA.

Serveis de monitoratge especialitzats

En l'actualitat, i en entorns corporatius, ningú fa servir eines locals com ara journalctl o Event Viewer, més enllà de volgué fer alguna auditoria concreta. Per norma general, us trobareu un seguit d'aplicacions com SIEM, SOAR, EDR, HIDS, que s'acaben totes integrant entre elles. La nomenclatura no és molt important, doncs realment ha anat variant molt al llarg dels anys i moltes vegades venen predeterminades per solucions comercials. Però en línies generals, ens trobarem amb agents que s'instal·len als nostres dispositius, o recopiladors de logs, i servidors que recolliran totes aquestes dades per després tractar-les.

Una altre fet a destacar, és que aquest conjunt d'eines son les que actualment fan de frontera entre els Departaments de IT i el Blue Team de Ciberseguretat.

Feta aquesta definició àmplia, hi ha variacions, cada organització acabarà fent ús d'un determinat seguit d'eines, i el més probable, és que tinguin eines que es solapen en les seves funcions. Podríem intentar fer la següent definició múltiple:

Un HIDS genera un conjunt d'alertes i bloquejos en relació al tràfic de xarxa segons un tipus de regles concrets (tipus SIGMA o altres).
Un EDR genera un conjunt d'alertes i bloquejos en relació a la capa d'aplicació, arxius, malware, segons un tipus de regles concretes (tipus YARA o altres). També monitoritzen l'estat del sistema i el consum de recursos.
Un SIEM recull el conjunt d'alertes i les mostres per poder ser tractades.
Un SOAR genera processos davant d'una alerta concreta.

No agafeu aquestes com definicions fixes i immutables, ens podem trobar amb múltiples formulacions i variacions possibles. Dintre de tota aquesta amalgama, podem dir que la principal aplicació son els SIEM, doncs son els encarregats de recollir els events i ajudar al Blue Team en la mitigació i recuperació del sistema.

Algunes aplicacions SIEM, tot i que sempre amb matisos, podrien ser:

Nagios: És una eina de monitoratge d'àmplia utilització i de codi obert. Pot supervisar servidors, dispositius de xarxa, aplicacions i més.
- Característiques:
  - Suport per a protocols com SNMP, SMTP, POP3, o HTTP.
  - Capacitat per personalitzar scripts i plugins per a supervisió específica.
  - Alertes i notificacions configurables.
  - Interfície web per a la visualització d'estadístiques i informes.
Zabbix: És una plataforma de monitoratge integral que ofereix funcions avançades de recopilació de dades i anàlisi.
- Característiques:
  - Supervisió de xarxes, servidors, aplicacions i recursos de maquinari (hardware).
  - Creació de gràfics i informes personalitzats.
  - Suport per a la generació d'alertes i notificacions.
  - Capacitat per a monitoratge distribuïda i descentralitzada.
Prometheus: És una eina de monitoratge i d'alertes amb un enfocament orientat a serveis i arquitectures de contenidor.
- Característiques:
  - Recopilació de dades mitjançant un model pull (el servidor recull dades dels agents).
  - Suport per a consultes i alertes basades en el llenguatge PromQL.
  - Integració amb l'ecosistema de contenidors, com ara Docker i Kubernetes.
  - Arquitectura modular i expansible.
SolarWinds: És un conjunt d'eines de monitoratge que ofereixen una varietat de solucions per a xarxes, servidors, bases de dades i més.
- Característiques:
  - Monitoratge del rendiment de xarxes i servidors.
  - Anàlisi del trànsit de la xarxa i identificació de problemes.
  - Gestió de la configuració dels dispositius de xarxa.
  - Supervisió de l'ús de la infraestructura cloud.
Splunk: És una plataforma que ofereix monitoratge, recopilació i anàlisi de dades a gran escala.
- Característiques:
  - Recopilació i indexació de dades de logs.
  - Recerca i anàlisi ad hoc de dades.
  - Alertes i notificacions basades en patrons i consultes.
  - Visualització de dades en temps real amb dashboards interactius.
Dynatrace. És una plataforma de monitoratge i gestió del rendiment d'aplicacions amb una visió integral de l'entorn de l'aplicació.
- Característiques:
  - Supervisió del rendiment de l'aplicació en temps real.
  - Identificació automàtica de dependències i problemes.
  - Anàlisi de rendiment d'aplicacions web i mòbils.
  - Generació de reports i informes detallats.
Wazuh. És una plataforma de seguretat basada en codi obert que proporciona funcionalitats avançades de recopilació, anàlisi i resposta a esdeveniments de seguretat en temps real.
- Característiques:
  - Integració amb OSSEC: wazuh es basa en el projecte OSSEC per a la detecció d'intrusions i la gestió de registres.
  - Monitoratge de registres: recopila i analitza registres de sistemes, aplicacions i dispositius de xarxa.
  - Detecta Amenaces: utilitza regles i signatures per identificar activitats malicioses i comportaments sospitosos.
  - Plataforma d'Amenaces: proporciona una plataforma centralitzada per gestionar amenaces i respondre-hi.

@@ Línia 499: / Línia 499: @@
 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.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== Segmentación mediante ''Subnetting'' ===
-=== Segmentació mitjançant ''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).
-Encara avui en dia, us podeu trobar a diferents materials que us parlin dels tipus d'adreces A, B, C i D, això és així, perquè des del primer moment es va pensar la idea que el protocol IPv4 havia de promoure la divisió. Per tant, la idea inicial era que segons el tipus de IP que es donava, això provocava que poguessis tenir un rang més gran o més petit de IPs, doncs la gran diferència és que segons el tipus d'adreça tenies una màscara de xarxa o una altra.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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.
-Una vegada tenies una màscara concreta, podies anar creant subxarxes en la mesura que anaves incorporant ''routers'' a la teva xarxa. A cada pas, la màscara de subxarxa s'anava fent més gran, fins que arribaves al propi dispositiu.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Fijaros en el gráfico siguiente:
-Fixeu-vos en el següent gràfic:
+[[Fitxer:Subnetting L3.png|alt=Ejemplo de generación de subredes con ''routers''|center|miniatura|Ejemplo de generación de subredes con ''routers'']]
-[[Fitxer:Subnetting L3.png|alt=Exemple de generació de subxarxes amb encaminadors|center|miniatura|Exemple de generació de subxarxes amb encaminadors]]
+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.
-L'esquema anterior us mostra la creació de vàries subxarxes. D'aquestes, les úniques que acceptaran una configuració de dispositius finals com un 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. Al final, d'una sola xarxa: 192.168.0.0/24, hem creat un total de 5 xarxes. Hem dividit la nostra xarxa i serà la nostra configuració en els ''routers'' la que decidirà la disponibilitat, o no, de les subxarxes entre elles. Al final, hem aconseguit dividir la nostra xarxa de forma lògica, evitem que els dispositius de subxarxes diferents es coneguin entre ells, i a més a més, podem anar creant subxarxes segons les nostres necessitats organitzatives.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Pero el ''subnetting'' tiene dos problemas básicos:
-Però el ''subnetting'' té dos problemes bàsics:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# La necesidad de diversos dispositivos ''routers'' únicamente para poder generar nuestras subredes.
-# La necessitats de diversos dispositius ''routers'' únicament per poder anar generant les nostres subxarxes.
+# 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.
-# La complexitat que es genera en la la creació de la capa física d'una organització, doncs no es poden compartir els dispositius de capa 2.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Por otro lado, el gran beneficio del ''subneting'' es que podemos situar un ''firewall'' entre las subredes.
-Per altra banda, el gran benefici del subnetting és que podem situar un Firewall per passar d'una xarxa a una altra.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== Segmentación mediante VLAN ===
-=== Segmentació mitjançant 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.
-Ja hem vist abans com, en les capçaleres dels frames de capa 2 hi havia un conjunt de bits que es reservaven per la creació de VLANs. La idea bàsica, és que gràcies al protocol 802.1Q, tenim la capacitat que un switch es divideixi de forma lògica, i per tant, eviti que un conjunt de dispositius connectats al mateix switch es vegin entre ells com si estiguessin en una mateixa xarxa LAN.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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''.
-D'aquesta manera, un administrador pot assignar un conjunt de interfícies a una mateixa VLAN, i així fer que tots aquells equips es puguin veure a nivell 2 i superiors, però que no puguin veure els equips pertanyents a altres VLAN. Quan dos equips de VLAN diferents volen comunicar-se ho han de fer a través d'un encaminador i, per tant, com es va veure a la lliçó anterior, el tràfic està subjecte a les polítiques de seguretat del tallafoc.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Con esta nueva modalidad de segmentación de red se obtienen varias ventajas:
-Amb aquesta nova modalitat de segmentació de la xarxa s'obtenen els següents avantatges
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Se reduce la necesidad de dispositivos de capa 2-3 para subdividir la red.
-* Es redueix la necessitat de dispositius de capa 2-3 que es requereix per poder subdividir una xarxa.
+* Se ofrece la posibilidad de filtrar los paquetes entre VLANs mediante el firewall.
-* S'ofereix més seguretat a través de tallafocs, limitant l'accés entre les diferents xarxes.
+* 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.
-* Permet separar la xarxa en unitats funcionals més petites, que poden seguir l'estructura de l'empresa, per exemple creant una o més VLAN per cada departament, o per cada planta, o seguint qualsevol criteri que estimi necessari l'administrador.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+A nivel de implementación, se tiene que tener en cuenta un par de cosas:
-A nivell d'implementació, cal tenir en compte que a nivell conceptual, caldrà tenir en compte dues coses:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# Quien es el encargado de escribir en la capa 2 la VLAN a 802.1Q
-# Qui és l'encarregat d'escriure a la capa 2 la VLAN a 802.1Q
+# Qué pasa cuando varias VLANs comparten una misma interfaz.
-# Què passa quan diverses VLANS comparteixen una interfície.
-</div>
 <div lang="ca" dir="ltr" class="mw-content-ltr">

Seguretat en xarxes/es: diferència entre les revisions

Revisió del 15:33, 2 gen 2024

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 tallafocs Firewall

El firewall de iptables

El Firewall de nftables

Condicions a les regles

Limitacions dels firewalls

Evolució actual dels tallafocs

UTM (Unified Threat Management)

NGFW (Next Generation Firewall)

Els detectors d'intrusos: IDS/IPS

Network Intrusion Detection System (NIDS)

Host Intrusion Detection System (HIDS)

Fortificació i gestió del Switch

Fortificació dels accessos wifi

Comunicacions segures en entorns no confiables

Xarxes Privades Virtuals (Virtual Private Networks o VPN)

Ús de protocols segurs

Fortificació i monitoratge de la xarxa interna

La fortificació des de IT

Els registres monitorables

Anàlisi de registres amb Linux: rsyslog

Facilities amb rsyslog

Severities

Registres amb rsyslog

Anàlisi de registres amb Linux: journalctl

Registres amb Windows

Tipus d'esdeveniments

Serveis de monitoratge especialitzats

Menú de navegació