Revisió de 14:17, 17 abr 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 reglas dentro de la capa 2, 3 y 4 del modelo OSI: Esto significa que es capaz de filtrar por MAC, IP y Puerto (El filtrage por capa 2 no es común en todos los firewalls).

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

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

Una conexión se puede pot identificar con:

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

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

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

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

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

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

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

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

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

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

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

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

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

Por lo normal, las ACL siguen los siguientes criterios:

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

Balanceo de carga

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

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

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

Balanceo de carga en L2

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

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

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

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

Balanceo de carga en L3

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

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

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

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

Las vulnerabilidades de los protocolos

Capa física

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

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

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

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

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

Capa de enlace de datos

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

Así pues, las vulnerabilidades de esta capa son:

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

Capa de red

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

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

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

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

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

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

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

Capa de transporte

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

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

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

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

La protección de la red

Segmentación lógica de una red

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

Tenemos dos posibilidades para poder segmentar una red local:

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

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

Segmentación mediante Subnetting

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

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

Fijaros en el gráfico siguiente:

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

Pero el subnetting tiene dos problemas básicos:

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

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

Segmentación mediante VLAN

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

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

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

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

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

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

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

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

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

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

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

En el esquema podemos observar los siguientes aspectos importantes:

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

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

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

El Proxy

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

El cloud
Los containers

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

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

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

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

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

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

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

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

El Cortafuegos Firewall

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

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

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

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

ACCEPT port 80
DENY ALL

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

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

El firewall de iptables

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

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

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

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

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

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

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

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

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

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

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

El firewall de nftables

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

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

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

Para utilizar nftables se debe tener presente:

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

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

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

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

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

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

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

# nft add table inet filter

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

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

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

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

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

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

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

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

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

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

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

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

% nft -f file_ruleset

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

flush ruleset

table inet ...{
.
.
.
}

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

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

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

El conjunto de reglas ACL en nftables

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

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

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

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

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

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

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

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

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

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

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

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

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

    chain inbound {                                                              

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

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

        # Allow loopback traffic.
        iifname lo accept

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

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

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

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

La llamada meta se realiza de la siguiente forma:

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

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

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

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

% nft add rule filter output ip daddr 8.8.8.8 counter

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

% nft list table filter
% nft list chain filter ouput

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

nft add rule filter output position 8 ip daddr 127.0.0.8 drop

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

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

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

Limitaciones de los firewalls

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

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

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

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

Evolución actual de los firewall

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

UTM (Unified Threat Management)

NGFW (Next Generation Firewall)

UTM (Unified Threat Management)

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

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

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

NGFW (Next Generation Firewall)

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

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

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

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

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

.

Los detectores de intrusiones: IDS/IPS

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

Los conceptos clave de un IDS/IPS son:

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

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

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

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

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

Network Intrusion Detection System (NIDS)

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

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

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

Host Intrusion Detection System (HIDS)

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

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

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

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

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

Fortificación y gestión del Switch

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

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

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

Fortificación de los accesos WiFi

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

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

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

Comunicaciones seguras en entornos no confiables

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

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

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

Redes Privadas Virtuales (Virtual Private Network VPN)

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

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


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

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

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


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

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

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

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

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

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

Uso de protocolos seguros

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

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

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

Fortificación y monitoreo de la red interna

La fortificación desde IT

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

Implementar la protección perimetral

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

Actualitzaciones y Patchs

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

Sistemas de autenticación fuerte

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

Monitoreo Continuo

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

Cifrado de Datos

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

Gestión de Políticas de Seguridad

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

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

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

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

Los registros

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

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

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

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

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

Análisis de registros en Linux: rsyslog

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

Las partes que forman parte del rsyslog son:

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

Facilities con rsyslog'

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

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

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

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

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

Severities

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


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

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

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

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

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

Registros con ryslog'

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

Podemos ver el siguiente ejemplo:

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

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

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

Análisis de registro con Linux: journalctl

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

Con journalctl, los usuarios pueden:

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

Registros con Windows

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

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

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

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

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

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

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

Tipo de eventos

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

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

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

Servicios de monitoreo especializado

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

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

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

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

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

Algunas aplicaciones SIEM, aunque algunas con matices, son:

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

@@ Línia 355: / Línia 355: @@
 === ''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'').
+Un '' firewall'' es un dispositivo ''hardware'', o una aplicación ''software'', que tiene por objetivo evitar las intrusiones externas no deseadas a nuestra red. Trabaja con reglas dentro de la capa 2, 3 y 4 del modelo OSI: '''Esto significa que es capaz de filtrar por MAC, IP y Puerto''' (El filtrage por capa 2 no es común en todos los ''firewalls'').
 Muchas veces nos podemos encontrar con ''firewalls'' que funcionan internamente dentro de los ''routers'' de capa 3. Esto es así, porqué el propio dispositivo ''router'' permite configurar un conjunto de reglas para filtrar los paquetes entrantes. Pero también nos podemos encontrar que estos dos dispositivos estén separados. En este caso, el dispositivo ''firewall'' requerirá de dos interfaces con dos IPs (entrada y salida del tráfico de red). En estos casos, normalmente lo que haremos es que la puerta de enlace de nuestra red local sea nuestro ''firewall''.
@@ Línia 531: / Línia 531: @@
 # Qué pasa cuando varias VLANs comparten una misma interfaz.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+El primer concepto es importante, ¿Quién escribe? ¿Quién hace el ''tagged''? Una opción que tenemos es que nuestros dispositivos finales generen un ''tagged'' en la medida que envíen paquetes a la red. Todos lo sistemas operativos tienen la posibilidad de ''taggear'' nuestro tráfico de red ([https://learn.microsoft.com/en-us/powershell/module/netadapter/set-netadapter?view=windowsserver2022-ps Windows], [https://github.com/canonical/netplan/blob/main/examples/vlan.yaml Linux]).
-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 ([https://learn.microsoft.com/en-us/powershell/module/netadapter/set-netadapter?view=windowsserver2022-ps Windows], [https://github.com/canonical/netplan/blob/main/examples/vlan.yaml 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'').
+Pero no es muy común, pues es un tipo de configuración que requiere un esfuerzo extra por parte de los administradores IT, pues nos podemos encontrar que algún dispositivo no tenga la posibilidad de ''taggear'', o que dificulte nuestra política de ''BYOD''. Por eso, muchas veces nos encontraremos que quien ''taggea'' es directamento nuestro dispositivo de capa 2 (''switch'').
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Esta decisión influenciará a la hora de administrar nuestro ''switch'', pues una de las opciones que debemos configurar en nuestro ''switch'' es si nuestro puerto es ''tagged'' o ''untagged''. ¿Qué cambia? Pues si ponemos ''tagged'' en nuestra interfaz del ''switch'', éste esperará encontrarse el protocolo 802.1Q configurado con la VLAN correcta, y si no encuentra la configuración o es una VLAN diferente, descartará el paquete. Por tanto, si nosotros no hemos configurado los dispositivos tipo PC para ''taggear'' los paquetes de red, tendremos que configurar las interfaces del ''switch'' como ''untagged'' para que no descarte los paquetes.
-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.
-</div>
+Por otro lado, cuando queremos que dos VLANs diferentes compartan una misma interfaz, lo que haremos es definir la interfaz en modo '''trunk'''. Esto hará, que el enlace pueda ser compartido por las dos VLANs. A más, para poder diferenciar el tráfico, tendremos que  definir las interfaz como ''tagged'', es decir, tenemos que requerir que los paquetes estén bien etiquetados. Si no queremos que se descarte ningún paquete, lo más fácil será definir la VLAN por defecto dentro del rango de VLANs que acepte el modo '''trunk'''.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Tener en cuenta, que aunque nosotros no etiquetemos los paquetes cuando salen del PC y que pasen por una interfaz ''untagged'', cuando llegan al ''switch'' que tiene definida una VLAN concreta, lo que hará el ''switch'' es etiquetar el paquete, y por tanto, estos paquetes ya podrán acceder a la interfaz del modo ''trunk''. A más, como la capa 2 es la primera de las capas de  ''headers'', el ''switch'' no tiene que esperar a recibir todo el paquete para etiquetarlo.
-----
-----
-----
-----
-----
-:::
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Fijaros con el esquema siguiente de implantación de tres VLANs en una organización:
-A la figura es poden veure diversos punts interessants:
+[[Fitxer:Schema VLANs Coorp.png|alt=Esquema de administración de tres VLANs en una organización.|center|miniatura|Esquema de administración de tres VLANs en una organización.]]
-  * 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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+En el esquema podemos observar los siguientes aspectos importantes:
-:::
+* En total tenemos tres VLANs en toda nuestra organización.
-</div>
+* El uso de recursos ''hardware'' es menor que si quisiéramos hacer lo mismo con ''subnetting''.
+* Todos los PCs de una misma VLAN se pueden ver entre ellos.
+* El tráfico de red, entre dos PCs de una misma VLAN, '''no''' pasará por el ''router''.
+* El tráfico de red, entre dos PCs de una VLAN diferente, '''sí''' pasará por el ''router''.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+En el esquema podemos observar como el enlace entre los ''switchs'', y entre el ''switch'' y el ''router'', será de tipo ''trunk'' y ''tagged''. En cambio, los enlaces entre los ''switchs'' de cada planta con sus dispositivos, será de tipo ''untagged'' para cada VLAN definida.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Actualmente, la segmentación con VLANs está ampliamente utilizada gracias a su versatilidad y buen rendimiento general. Aún así, dadas las arquitecturas de nueva tendencia de como la nube, los contenedores y la virtualización, está haciendo cambiar su uso. Lo que históricamente se solucionaba con  ''hardware'', poco a poco está pasando a formatos '''basados en software''', que ofrecen mejor versatilidad a las nuevas arquitecturas. Estamos pasando a modelos basados en '''microservicios'''.
-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**.
-</div>
 === El Proxy ===
@@ Línia 606: / Línia 590: @@
 Un aspecto importante de las ACL es que el ''firewall'' las lee en orden. Si nosotros tenemos una configuración similar a:
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 # ACCEPT port 80
 # DENY ALL
-</div>
 La primera ACL será que acepte paquetes en el puerto 80, por tanto, en este ejemplo solo aceptarían paquetes a este puerto, todo el resto de tráfico quedaría bloqueado.
@@ Línia 625: / Línia 607: @@
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Entender este esquema es clave para entender el funcionamiento de iptables. Es bastante común saberse aquellas ACL principales, pero un buen administrador IT tiene que ser capaz de entender su funcionamiento y crear las reglas que se requiera en cada momento.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Si os fijáis, el esquema tiene dos entradas y salidas posibles, este será el tráfico de cualquiera de nuestros dispositivos Linux, o el tráfico proviene de fura o es generado por alguna aplicación, y viceversa, o se envía tráfico a alguno aplicación o se envía tráfico a través de la red. Una opción, que podemos ver recogida, es que a veces podemos encontrar tráfico que puede provenir de una red y después ir a otra red (un ''''router'''').
-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''''').
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Después, cadascuna de las fases por donde se va moviendo nuestro tráfico se llama ''chain'' y en total tenemos cinco: '''PREROUTING, FORWARD, POSTROUTING, INPUT y OUTPUT'''. Estas cadenas nos sirven para determinar donde se encuentra el paquete que queremos filtrar. Por ejemplo, si tenemos el paquete en '''POSTROUTING''', significará que está a apunto de ir a la capa de red; otro ejemplo, si tenemos el paquete en '''INPUT''', querrá decir que está a punto de entrar en nuestra aplicación.
-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ó.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Pero toda esta información, aunque parezca que se guarde en ''chains'', no es así, si no que las ACL se guardan en las tablas que tenemos: '''mangle, nat y filter'''. Cada una de estas tablas tiene una función y una semántica diferente:
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''MANGLE''': Nos permite la modificación de los ''headers'' de los paquetes de la capa 3 y 4.
-* MANGLE: Ens permet la modificació de les capçaleres dels paquet en la capa 3 i 4.
+* '''FILTER''': Es la tabla que nos permite filtrar los paquetes en la capa 3 y 4.
-* FILTER: És la taula que ens permet filtrar els paquets en la capa 3 i 4.
+* '''NAT''': Es la tabla que nos permite configurar el protocolo ''Network Address Translation'' (antes explicado).
-* NAT: És la taula que ens permet configurar el protocol Network Address Translation (abans ja explicat)
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Así pues, si queremos crear una ACL que permita el tráfico SSH por el puerto 22 de una IP predeterminada, haríamos:
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 sudo iptables -A INPUT -s IPDeterminada -p tcp --dport 22 -j ACCEPT
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Y automáticamente iptables añadiría la ACL en la ''chain'' de ''INPUT'' y en la tabla de ''filter''. A partir de aquí, las opciones son múltiples, pero en la actualidad Debian recomienda trabajar con ''''nftables'''', el ''firewall'' que por defecto tiene la versión de Debian 11 Bullseye.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== El ''firewall'' de nftables ===
-=== El Firewall de nftables ===
+Nftables aún es una aplicación relativamente nueva, lo más normal es que de momento aún os encontráis con configuraciones basadas en iptables, y parte de vuestra tasca inicial sea la de traducir iptables a nftables. Una opción que tenemos disponible es la de usar un traductor automático:
-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:<syntaxhighlight lang="bash" line="1" start="1">
+<syntaxhighlight lang="bash" line="1" start="1">
 $ 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
-</syntaxhighlight>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 [https://wiki.nftables.org/wiki-nftables/index.php/Main_Page wiki nftables].
+</syntaxhighlight>
-</div>
+Nftables es una aplicación más bien compleja, iptables ya no era un firewall extremadamente amigable (en comparación con UFW), pero nftables ha augmentado su complejidad. Podéis encontrar más información de nftables en su docWeb: [https://wiki.nftables.org/wiki-nftables/index.php/Main_Page wiki nftables].
+Para utilizar nftables se debe tener presente:
+* Las tablas están definidas por el tipo de familia (netdev, ipnet, ip, ipv6 y bridge) y la función que desarrolla (filter, nat o route).
+* Las cadenas ''chain'' estan definidas por las ''chain type hook'' y la tabla definida en el punto anterior (tipo de família y función).
+* Dentro de cada hook se incluye el conjunto de ACLs.
+Fijémonos ahora, con el esquema siguiente para entender mejor la diferencia entre ''hooks'', cadenas y familias:
+[[Fitxer:Nfatbles schema.png|alt=Esquema de las ''chain'', ''hooks'' y tablas de nftables|center|miniatura|Esquema de las ''chain'', ''hooks'' y tablas de nftables]]
+Como podemos observar, hay lo que se llama familias de tabla, una agrupación de las posibles tablas existentes según el protocolo de red con el que trabajan:
+* '''Inet, Ip, Ipv6''': son tres familias diferentes, pero las tres se refieren el protocolo IP. La familia 'Ip' para las IPv4 y la familia 'Inet' para cuando nos queremos referir a IPv6 y IPv4 a la vez.
+* '''bridge''': es el tipo de tabla que visualiza el tráfico que pasa por los ''bridge''.
+* '''arp''': son aquellas tablas que visualizan el tráfico de red que genera el protocolo ARP.
+* '''netdev''': tienen un funcionamiento una poco diferente, son tablas relacionadas directamente con el ingreso del tráfico en una interfaz. Se pueden usar para generar balanceadores de carga.
+Cada una de estas tablas tiene sus ''chain type base'' (tipo de cadena de base):
+* '''filter''': son las tablas de ACL que se encargan de filtrar los paquetes.
+* '''route''': son las tablas de ACL que se encargan de enrutar  los paquetes.
+* '''nat''': son les tablas de ACL encargadas de aplicar el protocolo NAT (''Network Address Translation'').
+Con las ''family type'' y las ''chain type base'' se construyen las tablas en nftables. Por ejemplo, si queremos crear una tabla que filtre paquetes entrantes IP (IPv4 y IPv6):
+<syntaxhighlight lang="bash" line="1" start="1">
+# nft add table inet filter
+</syntaxhighlight>
+Una vez hemos creado una tabla, debemos crear las diversas ''chains'' (cadenas) que poblarán la tabla. Las cadenas se agrupan por ''hoooks'', que son 'momentos', o puntos en el proceso de tráfico de nuestras conexiones:
+* '''ingress''': solo para ''netdev'', es justo en el momento cuando nuestra conexión llega a nuestra tarjeta de red y previo al '''PREROUTING'''.
+* '''prerouting''': es el momento que llega el tráfico de red, visualiza los paquetes antes de cualquier decisión.
+* '''input''': visualiza todo el trfáico de red antes de redirigirse a nuestra sistema local (aplicaciones locales).
+* '''forward''': visualiza todos los paquetes que no se redirigen a nuestra sistema local.
+* '''output''': visualiza los paquetes originados por nuestra sistema local (aplicacions locals).
+* '''postrouting''': visualiza los paquetes después de redirigirlos fuera de nuestro dispositivo.
+En nftables, podemos incorporar el conjunto de tablas, cadenas y ACL a través de ''rulesets'' ( a más de hacerlos con la comanda de nftables). De esta forma, podemos cargar todo el ''firewall'' a la vez y es más fácil de administrar. Siguiendo con el ejemplo anterior, nuestro ''ruleset'' de momento quedaría de la forma siguiente:
+<syntaxhighlight lang="bash" line="1" start="1">
+table inet filter{
+  chain services {
+    <<<ACLs>>>
+  }
+  chain input {
+    <<<ACLs>>>
+  }
+}
+</syntaxhighlight>
+Este ''rulset'' fijaros que genera una tabla que filtra paquetes IP y que tiene dos ''chains''. El nombre de las cadenas puede ser aleatorio.
+Para poder definir las cadenas usaremos la expresión ''type'':
+<syntaxhighlight lang="bash" line="1" start="1">
+table inet filter{
+  chain services {
+    type filter hook input priority 0; policy accept;
+    <<<ACLs>>>
+  }
+  chain input {
+    type filter hook input priority 1; policy droop;
+    <<<ACLs>>>
+  }
+}
+</syntaxhighlight>
+En este caso, hemos definido dos cadenas en el mismo ''hook'', esto es así gracias a ''priority''. Aunque las dos cadenas estén en el mismo ''hook'' ('''INPUT HOOK'''), primero se analizará la cadena ''services'' y después la cadena ''input'' (atención, con que el nombre ''input'' es libre, podemos llamarla como queramos).
+Otro aspecto interesante es la política por defecto, la primera cadena usa lo que antes comentábamos como '''lista negra''', acepta todo el tráfico de red pero creará bloqueos por protocolos que no acepte; por contra, en la cadena ''input'' usamos el concepto de '''lista blanca''', bloqueará todo el tráfico de red excepto aquellas ACL que permitirán el paso.
+También atención con la prioridad y las políticas por defecto, fijaros que si intercambiásemos las prioridades, podríamos provocar que todo el tráfico de red quedase bloqueado por defecto.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Ara ya somos capaces de crear ''chains'', establecer prioridad y políticas por defecto, y todo esto en el conjunto de nuestro ''firewall''.
-Per utilitzar nftables cal tenir present:
-</div>
+Todos estos ''rulesets'' se pueden cargar como un fichero a nuestro ''nftables'' de la siguiente forma:
+<syntaxhighlight lang="bash" line="1" start="1">
+% nft -f file_ruleset
+</syntaxhighlight>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Un pequeño truco para poder ir actualizando nuestro conjunto de reglas es hacer que, antes que nos cargue las nuevas reglas, limpie las existentes. De esta forma, siempre podemos subir el archivo entero. Para hacerlo, en la primera línea de nuestro archivo escribiremos ''flush ruleset'' y os quedaría de la siguiente forma:
-* Les taules ara son contenidors de ''chains'' sense que aquestes hagin de tenir una semàntica concreta.
+<syntaxhighlight lang="bash" line="1" start="1">
-* Les cadenes dins d'una taula contenen regles (ACL)
+flush ruleset
-* 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
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+table inet ...{
-https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
+.
-</div>
+.
+.
+}
+</syntaxhighlight>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+También tenemos la opción de crear nuestras tablas y cadenas desde la línea de comandas, tanto con ''bash'', como con la propia consola de ''nft'' ('''nft -i'''). Si lo hacemos desde el ''bash'' escriviremos '''nft 'add table...' ''', todo entre comillas. En cambio, si lo hacemos des de la consola de ''nft'' pondremos directamente la orden sin el ''nft''.
-Fixem-nos ara, amb la diferència alhora d'entendre l'esquema de nftables:
-[[Fitxer:Nfatbles schema.png|alt=Esquema de les chain, hooks i tables de nftables|center|miniatura|Esquema de les chain, hooks i tables 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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Así pues, si queremos crear una tabla y después una cadena como el anterior ejemplo, haríamos:
-# Ens arriba una connexió a l''''INGRESS'''.
+<syntaxhighlight lang="bash" line="1" start="1">
-# Després valora si és una connexió bridge.
+% nft 'add table inet filter'
-# També valora si és un paquet ARP o IP, arriba a IP Layer.
+% nft 'add chain inet filter services { type filter hook input priority 0; policy accept; }'
-# És analitzat per el hook '''PREROUTING'''.
+</syntaxhighlight>
-# 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)
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+==== El conjunto de reglas ACL en nftables ====
-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.
+Ara ya solo nos queda saber crear nuestras reglas ACL y incluirlas a nuestro ''firewall''. Es un proceso minucioso, que requiere de una comprobación constante del funcionamiento correcto de todo el sistema.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Las reglas de un ''firewall'' estan formadas por condiciones, estas pueden estar referidas a la gran mayoría de campos de los ''headers'', tanto a nivel de red como de transporte.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Algunas soluciones comerciales también ofrecen que sus ''firewalls'' trabajen a nivel de aplicación, ofreciendo de esta forma, una mayor profundidad en el escaneo de paquetes para así mejorar la seguridad.
-'''Però què és un hook?''' Doncs son els tipus de chain que teníem abans.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Pero no es así con nftables, el cual solo trabaja en capas 3 y 4. No por eso es una mala solución, no os olvidéis que es el nuevo ''firewall'' que marcará una época en Debian, una de las distribuciones por excelencia de Linux.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Y por otro lado, tenemos soluciones como los '''WAF''' ''Web Application Firewall'' o los '''Proxies''' que ofrecen funciones similares a las de un ''firewall'' y que pueden visualizar el tráfico a nivel de aplicación.
-El primer de tot, és que amb nftables, les taules tenen un significat diferent, ara mateix hi ha
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Típicamente un cortafuegos utiliza los siguientes campos para identificar el tráfico:
-En total tenim 6 tipus de taules: ip, arp, ip6, bridge, netdev.
+* '''Protocolo''': IPv4, IPv6, ICMP, ARP, TCP, UDP, SCTP, DCCP...
-</div>
+* '''Direcciones de red''': origen o destino, también se permite la especificación de subredes.
+* '''Servicio''': utilizando los puertos de origen y destino, se puede limiar o permitir el tráfico dirigido a una aplicación en particular: HTTP, FTP, SSH, Telnet...
+* '''Estado de la conexión''': cuando se utiliza un protocolo de transporte orientado a conexión, como TCP, se puede filtrar por el estado de la conexión: ''related'', ''established'', o ''invalid''.
+* '''Interfaz''': si bien un ''firewall'' trabaja a nivel de red, tiene conciencia de los niveles inferiores y permite especificar aspectos como la interfaz de red por donde ha llegado el tráfico.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Para generar las ACL en ''nftables'' tenemos la complejidad que no siempre sigue la misma escaleta. Si no que dependiendo de la familia, el topo de cadena y el ''hook'', la ACL se escribirá de una forma o otra.
-En el moment que generem una taula, haurem d'indicar de quin tipus és.
-</div>
+Otra opción, era como habíamos visto antes, usar un traductor de ACL, si buscáis por Internet encontraréis muchos ejemplos de ACL creadas para Iptables con funciones muy concretas. Las podéis traducir e incorporar a vuestro ''ruleset''.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+A más a más, en este caso también será diferente si trabajamos con el archivo de ''ruleset'' o si queremos trabajar con la línea de comandos.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Si trabajamos por ''ruleset'' podemos incluir un archivo similar como el que tenemos como ejemplo en la wiki de nftables:
-:: figure:figura.01
+https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server
-</div>
-  <div lang="ca" dir="ltr" class="mw-content-ltr">
+<syntaxhighlight lang="bash" line="1" start="1">
-:title: Esquema de funcionament d'una Llista de control d'accés
+flush ruleset
-  :footer:
-{{:fpce:cib:m02:u2:a3:cib_m02_u2_016.png?200|}}
+table inet firewall {
-</div>
+    chain inbound_ipv4 {
+        # accepting ping (icmp-echo-request) for diagnostic purposes.
+        # However, it also lets probes discover this host is alive.
+        # This sample accepts them within a certain rate limit:
+        #
+        icmp type echo-request limit rate 5/second accept
+    }
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+    chain inbound_ipv6 {
-:::
+        # accept neighbour discovery otherwise connectivity breaks
-</div>
+        #
+        icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
+        # accepting ping (icmpv6-echo-request) for diagnostic purposes.
+        # However, it also lets probes discover this host is alive.
+        # This sample accepts them within a certain rate limit:
+        #
+        icmpv6 type echo-request limit rate 5/second accept
+    }
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+    chain inbound {
-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//.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+        # By default, drop all traffic unless it meets a filter
-:: example:
+        # criteria specified by the rules that follow below.
-</div>
+        type filter hook input priority 0; policy drop;
-  <div lang="ca" dir="ltr" class="mw-content-ltr">
+        # Allow traffic from established and related packets, drop invalid
-:title: Exemple de regla al tallafoc amb ''nftables''
+        ct state vmap { established : accept, related : accept, invalid : drop }
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+        # Allow loopback traffic.
-\\ Així un exemple de regla en aquest cas pot ser:
+        iifname lo accept
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+        # Jump to chain according to layer 3 protocol using a verdict map
-\\ ''# nft add rule ip filter input ip saddr 192.168.134.0/24 drop''
+        meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 }
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+        # Allow SSH on port TCP/22 and allow HTTP(S) TCP/80 and TCP/443
-\\ Que no permetria el tràfic entrant al sistema que provingués de la xarxa ''192.168.134.0/24''
+        # for IPv4 and IPv6.
-</div>
+        tcp dport { 22, 80, 443} accept
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+        # Uncomment to enable logging of denied inbound traffic
-:::
+        # log prefix "[nftables] Inbound Denied: " counter drop
-</div>
+    }
+    chain forward {
+        # Drop everything (assumes this device is not a router)
+        type filter hook forward priority 0; policy drop;
+    }
+    # no need to define output chain, default policy is accept if undefined.
+}
+</syntaxhighlight>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+De todo el código, quizá la parte más complicada es entender la línea de ''meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 }''. En esta línea, lo que hace nftables es separar los paquetes entre aquellas que usan el protocolo IPv4 y aquellas que usan el IPv6. Separa según el tipo de protocolo y envía el paquete a una ''chain'' diferente. Una vez allí, el ejemplo permite crear ACL personalizadas para IPv4 o IPv6, en nuestro caso la ACL limita la ratio de 5 pings por segundo.
-:: text:
-</div>
-  <div lang="ca" dir="ltr" class="mw-content-ltr">
+La llamada ''meta'' se realiza de la siguiente forma:
-:title:''nftables''
+* '''meta''': función de nftables que busca en los paquetes una condición en concreto. (https://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation)
-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: [[https://wiki.nftables.org/wiki-nftables/index.php/Main_Page%7Chttps://wiki.nftables.org/wiki-nftables/index.php/Main_Page]].
+* ''protocol'': define un parámetro de la búsqueda, en este caso que se busque según protocolo.
-</div>
+* '''vmap''': mapea las posibles soluciones y las redirige usando ''jump''.
+* '''ip: jump inbound_ipv4''': que vendría a decir, si es protocolo IPv4 salta a la cadena con el nombre: ''inbound_ipv4'' (https://wiki.nftables.org/wiki-nftables/index.php/Verdict_Maps_(vmaps))
+Una vez ha finalizado la cadena (IPv4 o IPv6), vuelve a la cadena original y seguirá con el listado que haya. Tiene un funcionamiento parecido al que tendría una función en programación.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Fijaros por esto, que escribir ACL filtrando según el puerto de origen es relativamente fácil con ''ruleset'': ''tcp dport { 22, 80, 443} accept''. Y si queremos filtrar segun puerto de origen, usaremos ''sport''.
-:::
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Si queremos, también podemos incluir las reglas a través de la línea de comandos, por ejemplo:
-==== Condicions a les regles ====
+<syntaxhighlight lang="bash" line="1" start="1">
-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.
+% nft add rule filter output ip daddr 8.8.8.8 counter
-</div>
+</syntaxhighlight>
+Es una buena práctica, poder mirar antes de incluir las nuevas ACL, como tenemos todo nuestro ''firewall'' listando todas las tablas, cadenas, hooks y listas ACL:
+<syntaxhighlight lang="bash" line="1" start="1">
+% nft list table filter
+% nft list chain filter ouput
+</syntaxhighlight>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+También podemos añadir una ACL en una posición en concreto:
-Així, típicament un tallafoc utilitza els següents camps per identificar el tràfic:
+<syntaxhighlight lang="bash" line="1" start="1">
-  * **Protocol**: IPv4, IPv6, ICMP, ARP, TCP, UDP, SCTP, DCCP...
+nft add rule filter output position 8 ip daddr 127.0.0.8 drop
-  * **Adreces de xarxa**: origen o destí, inclús es permet l'especificació de subxarxes
+</syntaxhighlight>
-  * **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
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Poder explicar completamente nftables en unos materiales generales de protección de redes es complicado por la dimensión. Por esto, aquí tenéis unos cuantos enlaces a la wiki de nftables que os pueden servir para ampliar vuestros conocimientos y poder configurar mejor vuestro ''firewall'':
-:: important:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Los tipos de famílias. https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev
-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//.
+* Crear las cadenas. https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types
-</div>
+* Los tipos de familias, cadenas y hooks posibles. https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks#Hooks_by_family_and_chain_type
+* Generación de reglas ACL. https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management
+* Operar con el ruleset. https://wiki.nftables.org/wiki-nftables/index.php/Operations_at_ruleset_level
+* Página principal de la wiki. https://wiki.nftables.org/wiki-nftables/index.php/Main_Page#Basic_operation
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+El nftables es pues, el nuevo ''firewall'' que marcará tendencia, familiarizarse con él será esencial para la tarea del administrador IT. Es una herramienta potente, moderna, en proceso de desarrollo y con múltiples funciones que podéis observar simplemente leyendo el índice de la wiki de nftables.
-:::
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== Limitaciones de los ''firewalls'' ===
-=== Limitacions dels ''firewalls'' ===
+Se debe prestar atención al hecho que un cortafuegos, como cualquier otro componente de la red, solo puede actuar con el tráfico que es capaz de ver. Por eso, es siempre imprescindible ubicar el ''firewall' en una localización estratégica donde todo el tráfico entrante y saliente pase a través de el. Así y todo, el ''firewall'' tiene algunas restricciones importantes.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+El hecho de trabajar a nivel de red, hace que un ''firewall'' ''''no pueda analizar el tráfico entre dos sistemas que estén en una misma subred''', ya que se comunican directamente sin pasar por el encaminador, esta limitación se puede mitigar usando un ''firewall'' en los hosts. Pero esta descentralización de los ''firewalls'' aumentará la complejidad de la administración de nuestra red y sistemas, ya que pocos ''firewalls'' ofrecen sistemas de administración distribuidos.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+A más, el hecho que las ACL sean estáticas, comportará que cuando haya un cambio en la política de seguridad en la empresa, tendremos que hacer los cambios de forma manual.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Por otro lado, y relacionado con el dinamismo, el ''firewall'' '''solo conoce la información de la red''', por tanto no puede proteger contra errores de configuración de los servicios o el uso de contraseñas inseguras, que será uno de los vectores de ataque más clásicos que encontraremos y indetectables por parte del ''firewall''.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== Evolución actual de los ''firewall'' ===
-=== Evolució actual dels tallafocs ===
+Debido a estas limitaciones presentes en los ''firewalls'', la industria ha evolucionado a modelos de seguridad más avanzados, utilizando el ''firewall'' como base y piedra angular de un sistema de seguridad más completo. Así se ha evolucionado de un modelo de ''firewall'' tradicional a un modelo avanzado como:
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 * UTM (''Unified Threat Management'')
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 * NGFW (''Next Generation Firewall'')
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 ==== 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'').
+Con el objetivo de simplificar la gestión de la seguridad, los '''UTM''' son una evolución directa de los ''firewall'', básicamente proporcionan un sistema con múltiples funciones de seguridad, todo en un solo paquete, para así evitar diversos sistemas de gestión, e integran: '''Firewall, Intrusion Detection System (IDS), Intrusion Prevention Systems (IPS)'''. Pero, dependiendo del fabricante también pueden incluir antivirus:
-</div>
+* ''Firewalls'' a nivel de aplicación como ''proxies''.
+* Detectores de ''physhing'' y sitios fraudulentos.
+* Sistemas de perdida de datos (''Data Loss Prevention DLP'')
+* Sistemas de gestión de alertas (''Security information and event management SIEM'')
+* Redes de enrutamiento virtual (''Virtual Private Network VPN'')
+* Sistemas de mitigación a ataques de denegación de servicio DoS.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Todas estas funcionalidad están integradas generalmente en un centro de control que permite orquestras y gestionar el comportamiento de un sistema, dando así una protección integral a la red.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 ==== 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.
+Se podría pensar que con los UTM la red ya puede llegar a un nivel de seguridad requerido, pero los UTM son una mejora estructural de los ''firewall'', continúan teniendo un problema importante y es el hecho que el sistema continua siendo local, es decir, toda la gestión de la organización está administrada y gestionada de forma local, como las actualizaciones o la gestión de las reglas. Por otro lado, siguen con teniendo el problema que no proporcionan una '''Defensa en profundidad''', ya que la topología de la seguridad continua siendo centralizada.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Por eso, la aparición de las nuevas tecnologías en la nube y la mejora permanente de los sistemas basados en inteligencia artificial (IA), hizo evolucionar a lo que hoy llamamos como ''''Next Generation Firewall NGFW''''.
-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).
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Los NGFW son una evolución tecnológica de los UTM, pero con las capacidades del '''cloud''', donde el ''firewall'' ya no es una entidad local, si no que está centralizada des de la nube con las capacidades y integraciones del fabricante, quien de forma transparente actualiza las políticas de seguridad y los sistemas, proporcionando un sistema dinámico que se ajusta a las necesidades de cada red y a las nuevas amenazas que vayan apareciendo.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Para complementar el NGFW, la presencia de la '''IA''' proporciona una adaptabilidad sin precedentes, donde el sistema aprende del comportamiento de los usuarios y la dinámica de comunicación entre los actores de la red, para así detectar anomalías en su comportamiento.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Así, un NGFW proporciona las características típicas de un ''firewall'': inspección con estado del tráfico, prevención de intrusiones integrada; pero con las capacidades semánticas para entender las aplicaciones, poder analizarlas y bloquearlas cuando se crea necesario, y todo de forma dinámica. El NGFW proporciona fuentes de inteligencia de amenazas y mecanismos de actualización para mantener las bases de datos al día con técnicas flexibles para mitigar amenazas cambiantes.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+.
-Els beneficis dels NGFW són:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+.
-* 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:
-</div>
-   <div lang="ca" dir="ltr" class="mw-content-ltr">
+   .
-: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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+.
-:::
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+== Los detectores de intrusiones: IDS/IPS ==
-== Els detectors d'intrusos: IDS/IPS ==
+Como pasa con muchas herramientas de seguridad, los IDS/IPS han ido evolucionando de una forma muy rápida, por ejemplo, hoy en día nos costaría encontrar con un IDS que no fuera a la vez IPS, y al final, se acaba definiendo más por el concepto de función que tienen dentro de un sistema, que no por las características concretas.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Los conceptos clave de un IDS/IPS son:
-Els conceptes claus d'un IDS/IPS son:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# Escucha de todo el tráfico de red, si queremos que trabaje como IPS se tendrá que situar en medio del tráfico para poder bloquearlo, y si solo trabaja como IDS con un ''splitter'' podremos duplicar la red y leerla.
-* 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''.
+* Hay un conjunto de reglas que analizan el tráfico, muchos IDS/IPS hacen servir la nomenclatura SIGMA, pero no es universal. Estas reglas pueden estar basadas en signaturas o en comportamientos.
-* 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.
+* Las reglas de un IPS, a más de enviar alertas, también tienen la posibilidad de bloquear el tráfico.
-* Les regles d'un IPS, a més d'enviar alertes, també tindran la possibilitat de bloquejar el tràfic.
+* Hay bibliotecas de reglas que podemos instalar de forma automática en nuestro IDS/IPS.
-* Hi ha biblioteques de regles que podem anar instal·lant al nostre IDS/IPS.
+* Tienen visibilidad hasta la capa de aplicación.
-* Tenen visibilitat fins a la capa d'aplicació.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Un IDS/IPS generalmente mantiene una base de datos de ataques conocidos y compara los patrones de actividad observando y monitoreando la red, de esta forma se pueden reconocer cuando se produce una coincidencia con un ataque conocido.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Otra posibilidad que proporcionan la mayoría de IDS/IPS es ejecutar algún tipo de orden en la medida que salte una alarma o un bloqueo. A partir de estos ''scripts'' las opciones pueden ser infinitas, podemos generar nuevas reglas, podemos agregar ACL a los ''firewalls'' perimetrales, o podemos recopilar el conjunto de evidencias que definamos para después analizarlas a través de ''forensics''.
-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''.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Des de el punto de vista de la arquitectura, podemos definir dos tipos de IDS/IPS: los ''Network Intrusion Detection System'' (NIDS) y los''Host Intrusion Detection System'' (HIDS).
-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).
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 === 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.
+Los NIDS son '''sistemas de detección de intrusiones''' que analizan el tráfico de red. Internamente, es similar a un ''firewall'', en el sentido que todos se basan en el análisis del tráfico de red, pero en el caso de los NIDS es capaz de analizar más capas de red y es capaz de buscar firmas conocidas de tráfico.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Un NIDS, para poder actuar y analizar de forma correcta el tráfico de red, necesita poder capturar y estudiar los paquetes hasta la capa de aplicación, esto implica que ha de hacer una inspección profunda de los paquetes (''Deep packet inspection DPI''). DPI es una forma de filtrage de paquetes de red que examina la parte de los datos, los interpreta y los analiza. El NIDS lo que hace es buscar problemas conocidos a los protocolos, firma de virus conocidos, correo basura (''spam'') o intrusiones con los criterios predefinidos.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Los NIDS inicialmente se implementaban en ''hardware'' específico, pero hoy en día con las tecnologías en la nube y la mejora de los equipos de propósito genérico como servidores, han pasado pasado a un modelo basado en ''software'' ejecutándose directamente en el sistema genérico.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 === 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.
+El HIDS monitorea las características de un solo equipo, se centra en los eventos que ocurren en este equipo y busca actividad sospechosa. Los HIDS inspeccionan el tráfico de red que llega al equipo, pero también pueden inspeccionar los registros del sistema ('''logs'''), los procesos en ejecución, los accesos y modificación de ficheros y los cambios de configuraciones del sistema y aplicaciones.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Para poder funcionar correctamente un HIDS se implementa mediante un agente instalado en los equipos o aplicaciones de interés: cada agente monitorea la actividad de su cliente y transmite la información a los servidores de administración. Por tanto, el HIDS nos permite verificar la integridad de un sistema a través de las monitorización de registros y nos permite monitorear las trampas tipo ''honeypot''.
-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'').
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Un ''honeypot'' es un sistema que simula una vulnerabilidad de una máquina para poder analizar los atacantes.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Des de el punto de vista de la arquitectura, se recomienda que el agente HIDS se instale en todos los equipos de la organización, tanto PCs como servidores. En caso de no poderse instalar, reenviaremos los registros al servidores para que se puedan tratar allí.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Todas estas nuevas funciones del HIDS han hecho que hoy en día se conozcan como '''EDR''' ''Endpoint Detection and Response'' y son la piedra angular de la nueva seguridad de las organizaciones.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+== Fortificación y gestión del ''Switch'' ==
-== Fortificació i gestió del Switch ==
+Hasta este punto, la mayoría de aspectos de seguridad tratados han puesto el foco en la capa de red y superiores. Si bien estos niveles son generalmente los que reciben más atención, conviene no olvidar los aspectos importantes de la capa 2. Los ''switchs'' trabajan a nivel de enlace de datos y son la primera línea de defensa contra los ataques de denegación de servicio, suplantación de identidad o acceso a la red.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Para proteger un ''switch'' se pueden utilizar diferentes estrategias, algunas de ellas dependen normalmente del fabricante, aún así, hay una serie de buenas prácticas que todo administrador debería implementar.
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''Proteger el acceso físico al dispositivo''': aunque puede ser complicado en la mayoría de casos, permitir el acceso al ''switch'' permite a un atacante desconectar cables de equipos existentes y conectarse el mismo. También se debe vigilar que todas las interfaces que no se usen en el ''switch'' estén deshabilitadas.
-* '''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.
+* '''Contraseñas predeterminadas''': la inmensa mayoría de ''switchs'' gestionados tienen contraseñas predeterminadas que tendremos que cambiar la primera vez que entremos para evitar perder el control de nuestro dispositivo.
-* '''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.
+* '''Supervisión''': vigilar y monitorizar las interfaces del ''switch'' (normalmente a través del protocolo SNMP).
-* '''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.
+* '''SNMP v3''': si es posible, utilizaremos la versión 3 de SNMP que es más segura y procuraremos que la contraseña del ''community'' sea bien larga para evitar ataques de fuerza bruta.
-* '''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.
+* '''Registro de logs''': configurar el registro centralizado para poder observar las actividades de los ''switchs''. De esta forma, juntamente con los HIDS, se simplifica mucho la correlación de eventos de un servidor.
-* '''Authorization, Authentication, Accounting (AAA)''': é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.
+* '''Authorization, Authentication, Accounting (AAA)''': es una buena práctica activar la asignación de VLAN por usuario, esto lo podemos conseguir con RADIUS pero requiere que nuestro ''switch'' lo soporte.
-* '''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.
+* '''Seguridad del puerto''': también podemos configurar las interfaces de nuestro ''switch'' para que solo pueda acceder una MAC determinada. En este sentido, normalmente tenemos la opción de aceptar en una interfaz solo la primera MAC que se conecte..
-* '''VLAN 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.
+* '''VLAN dinámica''': las VLAN dinámicas son aquellas que deciden la VLAN según el usuario o la MAC del dispositivo.
-* '''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.
+* '''Identificador de usuario/contraseña local''': en caso de utilizar AAA, se debe dejar una puerta trasera con un usuario local por si un caso fallara el sistema de autenticación en red.
-* '''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.
+* '''Segmentación de la red''': es imprescindible segmentar la red con VLAN para segregar las diversas partes de la red. A más, configuraremos los ''firewalls'' para filtrar el tráfico entre las VLAN.
-* '''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.
+* '''VLAN de gestión''': muchos ''switchs'' admiten una VLAN de gestión para poder administrar todos los ''switchs''.
-* '''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ón''': En esta VLAN configuraremos la IP de gestión del dispositivo, una red diferente a la de la organización.
-* '''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.
+* '''Etiquetaje de puertos''': siempre está bien tenerlo todo ordenado y escribir todas las descripciones que podamos a nivel interno y etiquetar de forma externa todas nuestras conexiones.
-* '''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.
+* '''SSH vs Telnet''': Telnet se considera un protocolo no seguro, viaja en claro, y por tanto debemos usar siempre SSH v2 y deshabilitar los puertos Telnet de nuestro ''switch''.
-* '''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.
+* '''Interfaz web''': en caso de tener la posibilidad de una interfaz web, esta deberá funcionar con los protocolos SSL (HTTPS).
-* '''NTP''': sincronitzar el rellotge del commutador és important per poder correlar events amb la data adequada.
+* '''NTP''': sincronizar los relojes de todos los ''switchs''.
-* '''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 de direcciones MAC por interfaz''': de esta forma podemos evitar que se genere un punto de acceso fraudulento o evitar una inundación de MAC en la tabla intefaz-MAC.
-* '''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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+== Fortificación de los accesos WiFi ==
-== Fortificació dels accessos wifi ==
+La fortificación de acceso a las redes inalámbricas es extremadamente crítico, ya que un potencial atacante no tiene porqué buscar un punto de conexión físico, si no que podemos hacerlo des de la calle mismo.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+De esta forma, una buena política de seguridad es imprescindible. Las principales recomendaciones son:
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''No permitir la existencia de puntos de acceso no registrados''': debemos tener mecanismos de detección por si un nuevo punto AP aparece sin nuestro reconocimiento.
-* '''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.
+* '''Utilizar protocolos de protección wifi''': La recomendación mínima de contraseña debe ser WPA 2.0, tanto en su versión ''Personal'' como ''Enterprise''.
-* '''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.
+* '''Contraseñas predeterminadas''': igual que con los ''switchs'', debemos cambiar todas las contraseñas predeterminadas para evitar perder el control del dispositivo.
-* '''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.
+* '''Registro de logs''': configurar también el registro centralizado.
-* '''Registre de logs''': configurar també el registre centralitzat per poder observar les activitats del commutador.
+* '''SNMP v3''': siempre intentar usar la versión 3 de SNMP.
-* '''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''': sincronizar los relojes.
-* '''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''': es una buena practicar diferenciar las funciones de AP y de DHCP (en casa es común, pero en organizaciones siempre mejor centralizar el DHCP)
-* '''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''': siempre accederemos a nuestros dispositivos usando protocolos encriptados.
-* '''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.
+* '''Filtraje de direcciones MAC''': si no podemos usar los protocolos ''WPA 2 Enterprise'', buscaremos otros mecanismos de filtraje de dispositivos como puede ser a través de la MAC..
-* '''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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+= Comunicaciones seguras en entornos no confiables =
-= Comunicacions segures en entorns no confiables =
+Para garantizar la seguridad de un sistema es importante, como ya hemos visto, como ya hemos visto, seguir ciertas buenas prácticas, pero hay veces que es imposible estar conectado en una red confiable, aún más, debemos de tener presente que el propio Internet es inseguro dada la falta de seguridad del propio protocolo IP y por la existencia de protocolos no cifrados. Por tanto, es primordial garantizar la seguridad en las comunicaciones cuando no se den las situaciones óptimas.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+En estos casos, tenemos dos formas de hacer comunicaciones seguras:
-D'aquesta manera, per tenir comunicacions segures s'han identificat dos mecanismes diferents:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Redes Privadas Virtuales (''Virtual Private Networks'' o VPN).
-* Xarxes Privades Virtuals (//Virtual Private Networks// o VPN).
+* Utilización de protocolos seguros.
-* Utilització de protocols segurs
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== Redes Privadas Virtuales (''Virtual Private Network VPN'') ===
-=== Xarxes Privades Virtuals (Virtual Private Networks o VPN) ===
+Una VPN es un mecanismo para crear conexiones seguras entre dos ubicaciones. Para conseguirlo, una VPN crea lo que se conoce como un ''overlay'', es decir, '''una red encima de otra red''', lo que a la práctica significa que se crea un túnel de tráfico IP dentro del tráfico de capa 3.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+En la siguiente tabla podemos ver como funcionaría a nivel de paquete y sus ''headers'':
-En la següent imatge podem veure com funcionaria un paquet amb totes les seves capçaleres viatjant per una xarxa:
 {| class="wikitable"
 |+
@@ Línia 1.054: / Línia 993: @@
 |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.
+Un ''software'' VPN, lo que hace es encriptar las capas de red, transporte y aplicación, lo garda todo en la capa de datos del nuevo paquete de aplicación, y lo envía al otro lado del extremo de la VPN, el cual podrá desencriptar la capa de aplicación. Al trabajar en capa 3-4, nos permite también la posibilidad de trabajar con protocolo como ICMP.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Así pues, nos quedaria un paquete de una forma similar a:
-Així doncs, el nou paquet tindria una forma similar a:
 {| class="wikitable"
 |+
@@ Línia 1.087: / Línia 1.024: @@
 encrypt
 |}
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+También existen VPN que trabajan a nivel de capa de enlace de datos, estas VPN nos permiten comunicarnos de forma seguro dentro de una misma red.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+La parte importante a entender, es que tiene que haber algún tipo de servidor VPN que reciba los paquetes VP, si este servidor debe enviar el paquete por Internet, encapsulará y encriptará toda la información, rehará los ''headers'' de las capas 3 y 4, y lo enviará al otro servidor VPN. Por tanto, fijaros que en caso de escuchas de tráfico, lo único que se conocerá son las IPs de nuestros servidores VPN, pero el resto de datos viajará encriptado.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+De VPN hay de tres tipos, dependiendo de como trabajen los servidores:
-De VPN n'hi ha de tres tipus, depenent de qui treballa com a servidor:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''Host-to-Host''': Los dos equipos tienen una aplicación que corre internamente como un servidor VPN. Para los equipos en cuestión, entre ellos están en la misma red.
-* '''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:''' Es el típico caso del teletrabajo, queremos por ejemplo que el PC del trabajador funcione como si estuviera dentro de la red de la organización, en este caso el PC del trabajador sería un extremo de la VPN y en el otro extremo habría un dispositivo capa 3 (''router'').
-* '''Network-to-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 estos casos el objetivo es conectar dos redes entre ellas. Para ello los dos ''routers'' tendrán instalada la aplicación VPN y se redirigirán los paquetes entre ellos según la tabla de enrutamiento.
-* '''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à.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+El uso de las VPN está muy extendido des de hace muchos años, con un incremento notable después de la COVID-19.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== Uso de protocolos seguros ===
-=== Ús de protocols segurs ===
+En muchos casos el uso de las VPN no es práctico, o bien porqué no está disponible, o bien porqué ya estamos usando protocolos que son ''seguros de base''' y por tanto no es necesario.
-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'''.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Algunos ejemplos de estos protocolos seguros podrían ser el '''HTTPS''' o el '''SSH''', los cuales encriptan los datos entre extremos. Es habitual que nos encontremos aplicaciones que para establecer comunicaciones seguras usen protocolos como el HTTPS. Todos estos protocolos se consideren de una seguridad equivalente a la VPN y muchos de ellos provienen de la implementar sistemas de encriptación protocolos que inicialmente no eren seguros como HTTP o Telnet.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Mención especial merece el protocolo '''DNS'', el cual un atacante podría '''monitorizar los dominios que está visitando la víctima'''. En la actualidad existe el DNSSEC, que encripta la información entre extremos y nos asegura la autenticidad, la integridad y la confidencialidad de los datos. Pero es un protocolo que no está extendido y que los navegadores no llevan incorporado.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+<span id="Fortificació_i_monitoratge_de_la_xarxa_interna"></span>
-= Fortificació i monitoratge de la xarxa interna =
+= Fortificación y monitoreo de la red interna =
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== La fortificación desde IT ===
-=== La fortificació des de IT ===
+Como administrador IT, nuestra misión es asegurar nuestra red y nuestros sistemas. Nuestra organización nos reclama seguridad, es decir: confidencialidad, integridad y disponibilidad de datos. Todo eso, de forma constante, y sin tener en cuenta la evolución de las amenazas cibernéticas. Por eso, es básico seguir un conjunto de pasos que nos ayuden a securizar nuestro sistema.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# <li value="1">'''Implementar la protección perimetral'''</li>
-# <li value="1">'''Implementar la protecció perimetral'''</li>
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Utilizar ''firewalls'' para controlar y monitorear el tráfico de red, permitiendo solo aquel tráfico autorizado y bloqueando los intentos de acceso no autorizados.
-* 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íticas de filtraje de direcciones IP para prevenir ataques de denegación de servicio (DoS DDoS) y limitar el acceso des de ubicaciones geográficas indeseadas.
-* 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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# <li value="2">'''Actualitzaciones y Patchs'''</li>
-# <li value="2">'''Actualitzacions i Patchs'''</li>
+* Implementar un programa de gestión de actualizaciones para garantizar que todos los dispositivos de la red tengan las últimas actualizaciones de seguridad.
-* Implementar un programa de gestió d'actualitzacions per garantir que tots els dispositius de la xarxa tinguin les últimes actualitzacions de seguretat.
+* Automatizar el proceso de actualización para minimizar el tiempo de vulnerabilidad de los sistemas.
-* Automatitzar el procés d'actualització per minimitzar el temps de vulnerabilitat dels sistemes.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# <li value="3">'''Sistemas de autenticación fuerte'''</li>
-# <li value="3">'''Sistemes d'autenticació forta'''</li>
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Utilizar protocolos de autenticación robustos con LDAP o Kerberos para verificar la identidad de los usuarios y dispositivos.
-* Utilitzar protocols d'autenticació robustos com LDAP o Kerberos per verificar la identitat dels usuaris i dispositius.
+* Implementar la autenticación multifactorial para añadir una capa adicional de seguridad mediante factores como ahora llaves de seguridad o autenticación biométrica.
-* Implementar l'autenticació multifactorial per afegir una capa addicional de seguretat mitjançant factors com ara claus de seguretat o autenticació biomètrica.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# <li value="4">'''Monitoreo Continuo'''</li>
-# <li value="4">'''Monitoratge Continu'''</li>
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Desplegar herramientas de monitoreo de seguridad para detectar actividades sospechosas.
-* Desplegar eines de monitoratge de seguretat per detectar activitats sospitoses a la xarxa.
+* Configurar alertas para incidentes de seguridad y establecer protocolos de respuestas rápida en caso de ataques o comportamientos anómalos.
-* Configurar alertes per a incidents de seguretat i establir protocols de resposta ràpida en cas d'atacs o comportaments anòmals.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# <li value="5">'''Cifrado de Datos'''</li>
-# <li value="5">'''Xifrat de Dades'''</li>
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Implementar protocolos de cifrado robustos como SSL/TLS para proteger comunicaciones sensibles entre los dispositivos.
-* Implementar protocols de xifrat robustos com SSL/TLS per protegir les comunicacions sensibles entre els dispositius.
+* Utilizar cifrado de disco para proteger los datos guardados en servidores y dispositivos de red.
-* Utilitzar xifrat de disc per protegir les dades emmagatzemades en servidors i dispositius de la xarxa.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# <li value="6">'''Gestión de Políticas de Seguridad'''</li>
-# <li value="6">'''Gestió de Polítiques de Seguretat'''</li>
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Establecer políticas de seguridad claras y aplicables a todos los usuarios y dispositivos de la red.
-* Establir polítiques de seguretat clares i aplicables a tots els usuaris i dispositius de la xarxa.
+* Educar los usuarios sobre las prácticas de seguridad, como la creación de contraseñas fuertes y la prevención de ingeniería social.
-* Educar els usuaris sobre les pràctiques de seguretat, com ara la creació de contrasenyes fortes i la prevenció de l'enginyeria social.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+La fortificación de una red interna es un proceso continuo que requiere de una vigilancia constante y adaptada a las nuevas amenazas. La implementación de estas prácticas contribuirá a crear una red robusta, resistente a los ataques cibernéticos y protegida contra posibles vulnerabilidades.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Completando esto, es crítico para la seguridad de la red concienciar a los trabajadores de las organizaciones a través de las buenas prácticas, la conciencia del peligro de compartir datos privados, el uso de contraseñas robustas o la detección de intentos de ataque de ingeniería social.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Al final, la fortificación de una red interna es una tarea crítica para cualquier organización que desee garantizar la seguridad, la integridad y la disponibilidad de sus datos. En la medida que las amenazas cibernéticas evolucionen, es esencial adoptar estratégicas y prácticas que protejan eficazmente los recursos de la red. Por esto, aunque las buenas prácticas antes comentadas siempre deben estar, requeriremos de otras herramientas que nos ayuden a monitorear los sistemas y la red y poder responder de forma eficaz los incidentes de ciberseguridad.
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== Los registros ===
-=== Els registres monitorables ===
+El monitoreo de registros (''logs'') forma parte de las tareas críticas a tener en cuenta en un entorno seguro, monitorear registros nos proporciona información vital sobre el estado, el rendimiento y los eventos (''events'') relevantes de nuestro sistema operativo.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Con independencia del sistema operativo que se utilice, el análisis y la gestión del monitoreo de registros ha de considerar ciertos aspectos fundamentales. De entrada ha de monitorear los ''events'' del sistema operativo:
-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**:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* errores del núcleo del sistema.
-* Errors al nucli del sistema
+* ''Events'' inesperados como accesos a ficheros hechos por usuarios sin privilegios.
-* ''Events'' inesperats com accessos a fitxers per usuaris sense privilegis
+* Accesos fallidos al sistema, sea de forma local o remota.
-* Accessos fallits al sistema, sigui localment o remotament
+* Inicio, finalización y tiempo de las sesiones de los usuarios.
-* Inici, parada i duració de les sessions dels usuaris
+* Acciones realizadas por los administradores.
-* Accions realitzades pels administradors
+* Monitorear los servicios que estamos ofreciendo: HTTP, Mail, etc.
-* Ha de monitorar els serveis oferts: HTTP, Mail...,tot monitorant accessos erronis, mal funcionaments...
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Todos estos registros los podemos monitorizar con un EDR o un HIDS, es la forma más utilizada, de esta forma se centraliza la vigilancia de nuestros servicios. Pero este tipo de aplicaciones tienen su propio funcionamiento interno y las propias casas comerciales ofrecen sus formaciones especializadas.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Pero más allá de las grandes casas comerciales, debemos conocer cuales son aquellas aplicaciones de sistema que nos permiten monitorear nuestro sistema: En Linux con ''rsyslog'' y ''journalctl'', y en Windows con el ''Event Log''.
-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''.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+==== Análisis de registros en Linux: rsyslog ====
-==== Anàlisi de registres amb Linux: rsyslog ====
+''rsyslog'' es un sistema de registro para sistemas UNIX que permite la recopilación, procesamiento y envío de registros a diversos destinos. Soporta protocolos como syslog, TCP y UDP, y proporciona una flexibilidad considerable para personalizar el tratamiento de los registros.
-''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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Las partes que forman parte del ''rsyslog'' son:
-Les parts que formen el ''rsyslog'' són:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''Senders''': es la parte encargada de enviar los registros de las aplicaciones y del sistema al servidor de registros.
-* '''Senders''': configurats per enviar registres des de les aplicacions o sistemes als servidors de registres.
+* '''Receivers''': es la parte encargada de recibir y redirigir los registros.
-* '''Receivers:''' encarregats de rebre els registres i dirigir-los al destí adequat.
+* '''Filters''': permite seleccionar y procesar los registros basándose en criterios específicos como el nivel de gravedad o el origen.
-* '''Filters''': permeten seleccionar i processar registres basant-se en criteris específics, com ara nivell de gravetat o origen.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+===== Facilities con ''rsyslog' =====
-===== Facilities amb ''rsyslog'' =====
+Una ''facility'' se refiere a una categoría o tipo de mensaje de registro que se generan en el sistema. ''rsyslog'' usa el protocolo '''syslog''' que es el protocolo estándar de registró.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Las ''facilities'' en syslog son mecanismos que usamos para clasificar los mensajes de registro en categorías específicas, indicando la naturaleza del mensaje y el componente del sistema que lo ha generado. Cada mensaje de registro syslog contiene una ''facility'' y un ''severity level'' (nivel de gravedad), que determinarán la importancia y la categoría del mensaje.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Hay 24 ''facilities'' estándar en ''syslog'' y cada una de ellas se designa con una palabra clave que describe la categoria de los mensajes asociados. Algunas de las ''facilities'' más comunes son:
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''kernel''': mensajes del kernel del sistema operativo.
-* '''kernel''': missatges del kernel del sistema operatiu.
+* '''user''': mensajes de usuarios generales o aplicaciones que no estan asociadas a ninguna ''facility''.
-* '''user''': missatges d'usuaris generals o aplicacions que no estan associats amb altres facilities.
+* '''mail''': mensajes relacionados con el correo electrónico.
-* '''mail''': missatges relacionats amb el correu electrònic.
+* '''daemon''': mensajes de servicios del sistema (daemons).
-* '''daemon''': missatges de serveis del sistema (daemons).
+* '''auth''': mensajes de autenticación y seguridad.
-* '''auth''': missatges d'autenticació i seguretat.
+* '''syslog''': mensajes generados por el propio ''daemon syslog''.
-* '''syslog''': missatges generats pel propi ''daemon syslog''.
+* '''lpr''': mensajes relacionados con la impresión.
-* '''lpr''': missatges relacionats amb la impressió.
+* '''news''': mensajes de sistemas de noticias.
-* '''news''': missatges de sistemes de notícies.
+* '''uucp''': mensajes relacionados con el protocolo UUCP (''Unix-to-Unix Copy'').
-* '''uucp''': missatges relacionats amb el protocol UUCP (''Unix-to-Unix Copy'').
+* '''cron''': mensajes relacionados con la aplicación cron.
-* '''cron''': missatges relacionats amb el programador de tasques cron.
+* '''authpriv''': mensajes de autenticación privados (seguridad privada).
-* '''authpriv''': missatges d'autenticació privats (seguretat privada).
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Conviene no confundir las ''facilities'' con aplicaciones, una ''facility'' puede ser para más de una aplicación.
-Convé no confondre les ''facilities'' amb aplicacions, la ''faclilty'' només proporciona un mecanisme de classificació, per exemple amb fitxers diferents.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 ===== 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:
+Relacionado con cada ''facility'' el sisetma también permite, para cada ''facility'' determinar el nivel de gravedad del mensaje. Los ''severity levels'' son:
 {| class="wikitable"
 |+
@@ Línia 1.318: / Línia 1.180: @@
 |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:<syntaxhighlight lang="bash" line="1">
+Así, como administradores podemos hacer que el sistema permita ignorar unas ''severities'' o otras dependiendo de cada ''facility'', para hacerlo editarmos el archivo:'''/etc/rsyslog.conf'''. Per exemple:
+<syntaxhighlight lang="bash" line="1">
 # Log commonly used facilities to their own log file
 auth,authpriv.* /var/log/auth.log
@@ Línia 1.324: / Línia 1.187: @@
 kern.ERROR -/var/log/kern-important.log
 mail.* -/var/log/mail.log
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 </syntaxhighlight>
-   :title: Gestió de les severities al fitxer ''/etc/rsyslog.conf''
+   :title: Gestión de las severities ''/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''.
+En este caso, se guardan los registros de cualquier nivel de gravedad de las ''facilities'': '''auth''', '''authpriv''', '''kern''' i '''mail''' al fichero que ponemos en la derecha, mientras que los mensajes de nivel de gravedad de '''ERROR''' o '''superior''' ('''ERROR''', '''CRITICAL''', '''ALERT''' i '''EMERG''') también se guardan en el fichero: ''/var/log/kern-important.log''.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+===== Registros con ''ryslog' =====
-===== Registres amb ''rsyslog'' =====
+En los registros con ''rsyslog'' incluimos información básica de cuando, quien, donde, la gravedad del mensaje y porque se generó el registro.
-Els registres amb ''rsyslog'' inclouen informació bàsica de quan, qui, on, la gravetat del missatge i perquè es va generar el registre.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Podemos ver el siguiente ejemplo: <syntaxhighlight lang="bash" line="1">
-Amb una mica més de detall, els camps habituals es poden veure en el següent exemple: <syntaxhighlight lang="bash" line="1">
 -11-14T07:54:46.924376+01:00 server sshd[1047736]: Failed password for root from 61.183.129.50 port 18705 ssh2
-</syntaxhighlight>Com es pot observar, la informació que hi ha és:
+</syntaxhighlight>Como se puede observar, la informaicón que hay es:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Hora del 'event'': '''2023-11-14T07:54:46.924376+01:00'''
-* Hora de l'''event'': '''2023-11-14T07:54:46.924376+01:00'''
+* Equipo que ha generado el registro: '''acme-server'''
-* Equip que ha generat el registre: '''acme-server'''
+* Aplicación que ha generado el registro: '''sshd'''
-* Aplicació que ha generat el registre: '''sshd'''
+* En este punto, el formato que hay a continuación ya depende de cada ''facility'' en si:
-* En aquest punt, el format que hi ha a continuació ja depèn de la ''facility'' en si, en aquest cas:
+** Información del ''event'': '''Failed password'''
-** Informació del event: '''Failed password'''
+** Usuario: '''root'''
-** Usuari: '''root'''
 ** Source IP: '''''61.183.129.50'''''
 ** Port: '''18705'''
 ** Protocol: '''SSH2'''
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+==== Análisis de registro con Linux: ''journalctl'' ====
-==== Anàlisi de registres amb Linux: ''journalctl'' ====
+A partir de systemd, Linux incorporó ''journalctl'' como herramienta para acceder a los registros del sistema. Este servicio  registra información detallada sobre los eventos (''events'') del sistema, incluyendo metadatos como los ''timestamps'' y el ''ID process''. De hecho, guarda los mismos datos que ''rsyslog'' pero utiliza el formato de base de datos para tener los registros de forma más compacta.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Con ''journalctl'', los usuarios pueden:
-Amb ''journalctl'', els usuaris poden:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* Ver todos los eventos del sistema.
-* Veure tots els esdeveniments del sistema.
+* Filtrar registros per nivel de gravedad, origen y tiempo.
-* Filtrar registres per nivell de gravetat, origen i temps.
+* Acceder a información detallada, incluyendo mensajes de error y datos relacionados con procesos.
-* Accedir a informació detallada, incloent-hi missatges d'error i dades relacionades amb processos.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+==== Registros con Windows ====
-==== Registres amb Windows ====
+Windows, a nivel de sistema, utiliza el '''Event Log''' como sistema de monitoreo.
-Windows, a nivell de sistema, utilitza l'''Event Log'' com a sistema de monitoratge.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Windows usa este servicio para mantener registros de actividades del sistema, seguridad y aplicaciones. Este sistema está organizado en tres categorías principales:
-Windows fa servir aquest servei per mantenir registres d'activitats del sistema, seguretat i aplicacions. Aquest sistema està organitzat en tres categories principals:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''System Log''': registra los eventos del sistema, como arranques, paros del sistema, errores de ''hardware'' y mensajes del sistema operativo.
-* '''System Log''': registra esdeveniments del sistema, com ara arrencades i aturades del sistema, errors de ''hardware'' i missatges del sistema operatiu.
+* '''Security Log''': recoge información sobre eventos de seguridad, como ahora intentos de inicio de sesión, cambios de contraseña y otras actividades relacionadas con la seguridad del sistema.
-* '''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 eventos relacionados con aplicaciones, incluyendo mensajes de error, advertencias y información sobre el uso de las aplicaciones.
-* '''Application Log''': registra esdeveniments relacionats amb aplicacions, incloent-hi missatges d'error, advertències i informació sobre l'ús de les aplicacions.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Los administradores del sistema pueden utilizar la herramienta ''Event viewer'' para explorar, filtrar y analizar los registros de eventos del sistema. Los eventos se organizan según categorías, niveles de gravedad y otros metadatos para facilitar su gestión.
-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ó.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Con el '''Event Log''' (a través del ''Event Viewer'') se puden registrar, consultar y subscribirse a los eventos del sistema para recibir alertas, realizar acciones concretas y archivar registros de eventos. También podemos obtener los registros para exportarlos a servicios externos en formato XML (''evtx'') o formato simple. Windows guarda los ''logs'' en la carpeta ''C:\Windows\System32\winevt\Logs''.
-Amb l'<nowiki/>''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''.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Se debe ir muy en cuenta, ya que Windows, por defecto, limita la mida de cada uno de los ficheros de los ''logs'' (como son los de ''System'', ''Security'', o ''Application''). De manera que, una vez se llegue a la mida máxima, se sobreescriven los registros más antiguos; si no queremos perder los registros los tendremos que guardar externamente, como por ejemplo enviarlos a un equipo remoto. Esto se puede conseguir activandolo en las propiedades del archivo de fichero de los ''logs'' en el ''Event Viewer'' , o  bien en la línia de comandos, utilizando:
-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:<syntaxhighlight lang="bash" line="1">
+<syntaxhighlight lang="bash" line="1">
 wevtutil.exe sl Security /ab:true /rt:true
 wevtutil.exe sl Application /ab:true /rt:true
 </syntaxhighlight>
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+===== Tipo de eventos =====
-===== Tipus d'esdeveniments =====
+El ''Event Log'' registra diversos tipos de eventos (''events'') que proporcionan información detallada sobre el estado, el rendimiento y las actividades del sistema operativo. Los principales tipos de eventos que hay son:
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''Information''': este tipo de evento proporciona información general o registro de actividades normales del sistema. Ejemplo: inicio de servicio, conexión de un dispositivo o tarea programada con éxito.
-* '''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''': indica situaciones que no son necesariamente errores, pero que podrían requerir la atención de un administrador. Es una advertencia sobre una condición potencialmente problemática. Ejemplos: bajo rendimiento de un servicio, manca de espacio en el disco duro o parada inesperada de una aplicación.
-* '''Warning:''' un '''Advertiment''<nowiki/>' 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 situaciones problemáticas que pueden afectar al rendimiento o funcionamiento normal del sistema. Ejemplos: fallo de una aplicación, error en una tarea programada o problema con un controlador de dispositivo.
-* '''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:''' es el nivel más alto de gravedad e indica problemas graves que pueden afectar significativamente el rendimiento o disponibilidad de nuestro sistema. Ejemplos: parada de un sistema crítico, error de funcionalidad esencial o fallo importante de una aplicación.
-* '''Critical:''' el nivell '''Crític''<nowiki/>' é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''': registro que indica que un evento se ha comprobado y se ha completado con éxito. Ejemplo: acceso a un recurso compartido con éxito.
-* '''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 que indica que un evento se ha comprobado y no se ha completado con éxito. Ejemplo: intento de sesión fallido o no autorizado.
-* '''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''': eventos relacionados con la seguridad y la autenticación. Ejemplo: cambio de la política de seguridad.
-* '''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 los eventos del sistema que no encajan en las otras categorias específicas. Ejemplo: los cambios en la configuración del sistema.
-* '''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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Esta clasificación en diferentes tipos de eventos facilita la identificación y el diagnóstico de incidentes, problemas o situaciones relevantes para la gestión y el monitoreo del sistema con la herramienta ''Event Log'' de Windows. A más a más, ''Event Log'' identifica todos los eventos con un ID, de esta forma nos permite no solo buscarlo con más facilidad, si no también poder utilizar este ID en las reglas SIGMA para el monitoreo de los sistemas y la red.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+===== Servicios de monitoreo especializado =====
-===== Serveis de monitoratge especialitzats =====
+En la actualidad, y sobre todo en entornos corporativos, no se usan estan herramientas locales como ''journalctl'' o ''Event viewer'', más allá de querer hacer alguna auditoría concreta. Por norma general, se usan un conjunto de aplicaciones como los '''SIEM, SOAR, EDR o HIDS''', que las acaban integrando. La nomenclatura en estos casos no es muy importante, pues realmente hay muchas variaciones a lo largo de los años y muchas veces herramientas que empiezan con unas características concretas, evolucionan para ofrecer más servicios. Solo tener en cuenta, que en líneas generales, nos encontraremos con agentes instalados en las máquinas y dispositivos de nuestro sistema, los cuales recopilan logs y eventos, y que los enviarán a servidores recolectores para su tratamiento.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Otro hecho a destacar, es que este conjunto de herramientas son las que actualmente hacen de frontera entre los Departamentos IT y el Blue Team de Ciberseguridad.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Todas estas herramientas, que en la práctica se parecen mucho, podríamos intentar distinguirlas de la forma siguiente:
-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:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* un HIDS genera un conjunto de alertas y bloqueos en relación al tráfico de red según un tipo de reglas concretas (tipo SIGMA o otras).
-* Un 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 conjunto de alertas y bloqueos en relación a la capa de aplicación, archivos dañinos o malware, según un tipo de reglas concretas (tipo YARA o otras).
-* Un 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 recoge el conjunto de alertas y los muestra para su tratamiento.
-* Un SIEM recull el conjunt d'alertes i les mostres per poder ser tractades.
+*Un SOAR genera proceso debido a una alerta concreta.
-* Un SOAR genera processos davant d'una alerta concreta.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+No son definiciones fijas e immutables, solo para ofrecer una idea general de los que nos podemos encontrar. Aún así, podríamos decir que la aplicación por excelencia son los SIEM para el monitoreo general y los EDR como clientes instalados en los dispositivos. Todo ello, administrado por el Blue Team para la mitigación y recuperación de los sistema en caso de incidente de ciberseguridad.
-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.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Algunas aplicaciones SIEM, aunque algunas con matices, son:
-Algunes aplicacions SIEM, tot i que sempre amb matisos, podrien ser:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+* '''Nagios''': Es una herramienta de monitoreo muy utilizada y de código abierto. Puede supervisar servidores, dispositivos de red, aplicaciones y mucho más.
-* '''Nagios:''' És una eina de monitoratge d'àmplia utilització i de codi obert. Pot supervisar servidors, dispositius de xarxa, aplicacions i més.
+** Características:
-** Característiques:
+*** Soporte para protocolos SNMP, SMTP, POP3 o HTTP.
-*** Suport per a protocols com SNMP, SMTP, POP3, o HTTP.
+*** Capacidad de personalizar los ''scripts'' y ''plugins'' para una supervisión específica.
-*** Capacitat per personalitzar ''scripts'' i ''plugins'' per a supervisió específica.
+*** Alertas i notificaciones configurables.
-*** Alertes i notificacions configurables.
+*** Interfaz web para  la visualización de estadísticas y informes.
-*** Interfície web per a la visualització d'estadístiques i informes.
+* '''Zabbix''': Es una plataforma de monitoreo integral que ofrece funciones avanzadas de recopilación de datos y análisis.
-* '''Zabbix:''' És una plataforma de monitoratge integral que ofereix funcions avançades de recopilació de dades i anàlisi.
+** Características:
-** Característiques:
+*** Supervisión de redes, servidores, aplicaciones y recursos de ''hardware''.
-*** Supervisió de xarxes, servidors, aplicacions i recursos de maquinari (''hardware'').
+*** Creación de gráficos e informes personalizados.
-*** Creació de gràfics i informes personalitzats.
+*** Soporte a la generación de alertas y notificaciones.
-*** Suport per a la generació d'alertes i notificacions.
+*** Capacidad para el monitoreo distribuido y descentralizado.
-*** Capacitat per a monitoratge distribuïda i descentralitzada.
+* '''Prometheus''': Es una herramienta de monitoreo y alertas para un enfoque orientado a servicios y arquitecturas contenedor.
-* '''Prometheus''': És una eina de monitoratge i d'alertes amb un enfocament orientat a serveis i arquitectures de contenidor.
+** Características:
-** Característiques:
+*** Recopilación de datos mediante un model ''pull''.
-*** Recopilació de dades mitjançant un model ''pull'' (el servidor recull dades dels agents).
+*** Soporte para consultas y alertas basadas en lenguaje PromQL.
-*** Suport per a consultes i alertes basades en el llenguatge PromQL.
+*** Integración con el ecosistema de contenedores como Docker o Kubernets.
-*** Integració amb l'ecosistema de contenidors, com ara Docker i Kubernetes.
+*** Arquitectura modular y expansible.
-*** Arquitectura modular i expansible.
+* '''SolarWinds''': Es un conjunto de herramientas para el monitoreo que ofrece una variedad de soluciones para redes, servidores y bases de datos.
-* '''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ísticas:
-** Característiques:
+*** Monitoreo del rendimiento de las redes y servidores.
-*** Monitoratge del rendiment de xarxes i servidors.
+*** Análisis del tráfico de la red e identificación de problemas.
-*** Anàlisi del trànsit de la xarxa i identificació de problemes.
+*** Gestión de la configuración de los dispositivos de red.
-*** Gestió de la configuració dels dispositius de xarxa.
+*** Supervisión del uso de la infraestructura ''cloud''.
-*** Supervisió de l'ús de la infraestructura ''cloud''.
+* '''Splunk''': Es una plataforma que ofrece monitoreo, recopilación y análisis de datos a gran escala.
-* '''Splunk:''' És una plataforma que ofereix monitoratge, recopilació i anàlisi de dades a gran escala.
+** Características:
-** Característiques:
+*** Recopilación e indexación de datos de ''logs''.
-*** Recopilació i indexació de dades de ''logs''.
+*** Análisis ad hoc de datos.
-*** Recerca i anàlisi ad hoc de dades.
+*** Alertas y notificaciones basadas en patrones y consultas.
-*** Alertes i notificacions basades en patrons i consultes.
+*** Visualización de datos en tiempo real con ''dashboards'' interactivos.
-*** Visualització de dades en temps real amb ''dashboards'' interactius.
+* '''Dynatrace''': Es una plataforma de monitoreo y gestión del rendimiento de aplicaciones con una visión integral del entorno.
-* '''Dynatrace'''. És una plataforma de monitoratge i gestió del rendiment d'aplicacions amb una visió integral de l'entorn de l'aplicació.
+** Características:
-** Característiques:
+*** Supervisión del rendimiento de la aplicación en tiempo real.
-*** Supervisió del rendiment de l'aplicació en temps real.
+*** Identificación automática de dependencias y problemas.
-*** Identificació automàtica de dependències i problemes.
+*** Análisis de rendimiento de aplicaciones web i móviles.
-*** Anàlisi de rendiment d'aplicacions web i mòbils.
+*** Generación de reportes e informes detallados.
-*** Generació de reports i informes detallats.
+* '''Wazuh''': Es una plataforma de seguridad basada en código libre que proporciona funcionalidades avanzadas de recopilación, análisis y respuesta a incidentes de seguridad en tiempo real.
-* '''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ísticas:
-** Característiques:
+*** Integración con OSSEC: wazuh se basa en el proyecto OSSEC para la detección de intrusiones y la gestión de los registros.
-*** Integració amb OSSEC: wazuh es basa en el projecte OSSEC per a la detecció d'intrusions i la gestió de registres.
+*** Monitoreo de registros: recopila y analiza registros de sistemas, aplicaciones y dispositivos de red.
-*** Monitoratge de registres: recopila i analitza registres de sistemes, aplicacions i dispositius de xarxa.
+*** Detecta Amenazas: utiliza reglas y firmas para identificar actividades maliciosas y comportamientos sospechosos.
-*** Detecta Amenaces: utilitza regles i signatures per identificar activitats malicioses i comportaments sospitosos.
+*** Plataforma de Amenazas: proporciona una plataforma centralizada para gestionar amenazas y responder para su mitigación.
-*** Plataforma d'Amenaces: proporciona una plataforma centralitzada per gestionar amenaces i respondre-hi.
-</div>

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

Revisió de 14:17, 17 abr 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 Cortafuegos Firewall

El firewall de iptables

El firewall de nftables

El conjunto de reglas ACL en nftables

Limitaciones de los firewalls

Evolución actual de los firewall

UTM (Unified Threat Management)

NGFW (Next Generation Firewall)

Los detectores de intrusiones: IDS/IPS

Network Intrusion Detection System (NIDS)

Host Intrusion Detection System (HIDS)

Fortificación y gestión del Switch

Fortificación de los accesos WiFi

Comunicaciones seguras en entornos no confiables

Redes Privadas Virtuales (Virtual Private Network VPN)

Uso de protocolos seguros

Fortificación y monitoreo de la red interna

La fortificación desde IT

Los registros

Análisis de registros en Linux: rsyslog

Facilities con rsyslog'

Severities

Registros con ryslog'

Análisis de registro con Linux: journalctl

Registros con Windows

Tipo de eventos

Servicios de monitoreo especializado

Menú de navegació