Revisió del 18:14, 1 gen 2024

La seguridad en redes

Como viajan los datos por la red

El viaje por la red

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

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

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


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

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

Dividimos los protocolos por capa

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

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

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


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

Protocolos y dispositivos

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

Capa de aplicación

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

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

Capa de transporte

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

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

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


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

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

Capa de red

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

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


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

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

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


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

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

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

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

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

Los headers de ICMP son:


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

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

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

Capa de enlace

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

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

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

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

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

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

El protocolo Ethernet tiene los siguientes headers:


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

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


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

Arquitecturas de red

Evolución de la topología de redes

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

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

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

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

Firewalls

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

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

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

Una conexión se puede pot identificar con:

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

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

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

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

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

Aquesta topologia tan senzilla permet observar diversos aspectes importants:

El tallafoc s'ha d'ubicar en algun lloc privilegiat de la xarxa per on passi tot el tràfic que es vol protegir.
Donat que els tallafocs treballen a escala de xarxa, tot el tràfic que no surti de la LAN (per exemple entre el client i el servidor de la figura), no passarà pel tallafoc; de manera que, si en compromet la seguretat d'un equip intern, això pot portar a un potencial compromís de tota la xarxa.
És habitual que els tallafocs coexisteixin al mateix equip que els encaminadors, això permet simplificar i abartir el cost de desplegar els sistemes d'una xarxa, però no és obligatori, hi ha equips que només actuen com a tallafocs sense capacitats d'encaminament.

D'aquesta solució se'n diu connexió doble ('Dual-Homed') perquè el tallafoc té dues interfícies.

Topologia amb connexió triple ('Three-Legged')

Tenir només dues interfícies provocava que els administradors de xarxes haguessin de jugar al blanc o negre. Inicialment, van arribar a situar dos routers, però ràpidament van aparèixer routers amb tres interfícies, una per la WAN, una per la LAN, i la terca, per la DMZ. Amb la tercera interfície es podia segmentar la xarxa interna en dues aïllades. Inicialment, aquesta tercera xarxa, coneguda amb el nom de DMZ (DeMilitarized Zones), era visible des de la WAN, però al final va acabar igualment securitzant-se a través d'un conjunt d'ACL especials per la DMZ.

En la següent imatge podem veure una topologia de xarxa típica amb DMZ:

Al final doncs, la topologia DMZ incorpora sempre tres jocs d'instruccions ACL:

   * Tràfic des d'Internet cap a la DMZ i viceversa.
   * Tràfic des d'Internet cap a la LAN i viceversa.
   * Tràfic des de la DMZ cap a la LAN i viceversa.

Per lo normal, les ACL segueixen els següents criteris:

   * Denegar tot el tràfic d'entrada a la LAN exceptuant el que és resposta d'una petició interna.
   * Només permetre el tràfic als ports dels serveis públics a la DMZ quan ve d'Internet, denegant la resta, a excepció de la resposta a peticions internes.
   * Depenent de la política de seguretat, el criteri de connexions entre la LAN i la DMZ pot ser igual de restrictiu que des d'Internet, o bé es pot permetre la connexió a alguns altres serveis si es creu oportú.

Balanceig de càrrega

En l'actualitat, les topologies de xarxa han augmentat la seva complexitat ja que s'intenta que siguin escalables. Una de les opcions que tenim, és utilitzar el balanceig de càrrega. D'aquesta manera podem garantir la disponibilitat dels nostres servidors i garantir la simultaneïtat de diverses peticions.

Hi ha diverses tècniques per poder oferir un servei escalable, però en tots els casos es necessita suport de la xarxa subjacent, i generalment, és necessari distribuir la càrrega entre diversos nodes. Aquesta distribució s'anomena Balanceig de Càrrega, i permet distribuir les peticions IP entre diversos equips diferents. Així, quant a infraestructura de xarxa, es plantegen dues alternatives:

 * balanceig de càrrega pel que fa a l'Enllaç de Dades (L2) 
 * balanceig de càrrega pel que fa a la Xarxa (L3).

Balanceig de càrrega a L2

El balanceig de càrrega a través de la capa 2 s'aconsegueix duplicant les interfícies dels switchs. La duplicació d'una interfície ens permet que el propi switch gestioni per on vol enviar la informació. Aquesta configuració es fa directament al nostra switch.

El balanceig s'anomena en capa dos, ja que es fa a través de les MAC, l'identificador que tenen tots els dispositius connectats a una xarxa. La MAC d'un dispositiu es fa servir per identificar els dispositius en la capa 2 del model OSI, això significa, que si un dispositiu treballa amb capa dos, podrà identificar l'origen i destí d'aquell paquet.

Tots els switchs tenen una taula on es relaciona una MAC amb una interfície,

Pel que fa a l'enllaç de dades, no hi ha el concepte de xarxa global; és un entorn que només té coneixement de la xarxa local i les adreces locals (//Medium Access Control// o MAC). Així els protocols que es troben en aquest nivell permeten distribuir peticions entre equips diferents adreçant-les a les corresponents adreces MAC. Com actualment no hi ha gaires protocols de nivell 2, a la pràctica això significa que l'enviament d'informació es distribuirà de forma equitativa entre més d'un enllaç per proporcionar més amplada de banda.

Balanceig de càrrega a L3

En contraposició al balanceig de càrrega de nivell 2, a nivell 3 es té constància de la xarxa i, per tant, es pot enviar el tràfic tenint en compte l'equip de destí. Com es pot veure a la següent imatge, per poder fer el balanceig, cara en fora hi ha una IP pública, la qual apuntarà al nostre router que farà de Proxy. El proxy ens permet anar enviant les peticions a un o altre servidor segons diversos paràmetres, per fer-ho, el proxy relaciona la nostra ip pública amb els dos servidors, però cadascun d'ells, tindrà una IP privada per tal que el proxy en pugui diferenciar el tràfic.

En aquest tipus d'infraestructura, sempre és millor posar el firewall abans del nostre Proxy. Cal tenir present que tota la nostra infraestructura de la xarxa ha de poder suportar aquest tipus de balanceig.

Això s'ha de fer a la connexió IP per garantir que tot el flux arriba al mateix servidor. La configuració de la xarxa per suportar aquest sistema ha de fer-se amb cura, ja que no tot el maquinari de xarxa suporta aquest tipus de replicació d'adreces IP. En aquest cas el //firewall// s'ubicaria a l'entrada de la xarxa abans de fer el balanceig de càrrega.

Aquest model de balanceig de càrrega té variants, una que proporciona alta disponibilitat, o sigui, redundància, on la IP comuna se'n diu IP flotant i va canviant d'un equip a un altre. Això es pot aconseguir amb protocols com ''Virtual Router Redundancy Protocol'' (VRRP), o amb tecnologies com ara Heartbeat. Aquestes variants de cops fan servir ''Multicast'' o protocols similars, però l'objectiu sempre serà aconseguir que, si un equip cau, es pugui enviar el tràfic cap a un altre de forma transparent.

Les vulnerabilitats dels seus protocols

Capa física

Cadascuna de les capes té les seves pròpies característiques, a vegades ens pot semblar, com és el cas de la capa física, que son capes poc tractades per el hàcking, però no per això tenen el seu recorregut i haurem de preveure els seus riscos.

Els principals atacs a la capa física son els referenciats a la denegació de servei DoS, a la captura de dades en viu, i per últim, el robatori i accés als propis dispositius.

Els atacs DoS es poden provocar a través de la interferència dels senyals elèctrics, podem alterar les senyals tant a través de generar ones d'interferència en les senyals WiFi, com generar corrents d'electricitat que alterin la senyal Ethernet.

Els atacs d'escolta es poden succeir tant a l'Ethernet com a la xarxa WiFi. A l'Ethernet a través de splits que ens permeten duplicar la nostra xarxa. Si som capaços de posar un dispositiu split en una xarxa, podrem reenviar el tràfic i escoltar-ne tot el seu contingut. No son elements que permetin fer un Man-in-the-Middle, sinó que només ens permeten fer-ne una escolta. La part positiva, és que son difícils de detectar a nivell lògic. Però també podem fer aquest tipus d'atacs en les xarxes sense fils, només cal anar recollint totes les comunicacions que es transmeten per l'aire, amb una antena receptora podrem ser capaços d'anar rebent tots els paquets i veure'ls amb un analitzadors de paquets com Wireshark.

Escoltar la informació que transmeten altres usuaris comporta problemes greus de divulgació d'informació i es pot aconseguir fàcilment si no es xifren les dades. L'anàlisi del tràfic intenta extreure la màxima informació possible de les comunicacions mentre aquestes s'estan realitzant.

Capa d'enllaç de dades

La capa d'enllaç és una capa no segura i la major part dels seus protocols parteixen de la confiança, per tant, és una capa altament vulnerable i que requereix de configuracions i software per evitar-ne mals majors. La capa 2 és una capa local, d'aquí que parteixi de la sí confiança. Per tant, per atacar-la, sempre haurem d'aconseguir primer accés a la xarxa local, i aquesta serà, una de les nostres prioritats inicials: evitar els accessos no desitjats a la nostra xarxa interna.

D'entrada, manté els dos atacs que ja trobàvem en la capa física, però aquesta vegada l'atacant té més opcions:

Denegació de servei - Tenim vàries opcions, podem fer una inundació a la taula del protocol ARP, generar molt de tràfic intern, crear bucles infinits o suplantar la MAC.
Escolta de tràfic - Un switch, a no sé que estigui ben configurat, es pot provocar el Mac flooding, aquesta vegada, el que fem és inundar de MACs un switch per tal d'arribar al límit de MACs possible que pot enregistrar un Switch, quan arriba aquest moment, els switchs tenen un mecanisme que per evitar les DoS reenvien tot el tràfic per totes les interfícies, i en aquell moment, ja podem escoltar el tràfic que hi passa.
Suplantació Spoofing - I tot això ens porta a la suplantació, el protocol Ethernet funciona de forma pública mostrant totes les MAC i IP dels dispositius de la nostra xarxa a través del protocol ARP. Això vol dir, que conèixer els dispositius, les seves MAC i les seves IP és extraordinàriament senzill, igual que autoassignar-se la IP i la MAC. Un Switch que estigui configurat per tal que no es repetixin les MAC en les seves interfícies, pot rebre un atac de suplantació. El Switch construeix la seva MAC-Interface llegint els paquets entrants, en cas que no acceptem MACs repetides, sempre assignarà aquella MAC a la última interfície que hagi detectat una MAC com entrant. Per tant, per fer un atac de suplantació, el que farem és generar paquets constants per quedar-nos sempre l'assignació de la interfície que volem. Aquesta

Capa de xarxa

A escala de xarxa, la quantitat d'atacs possibles explota exponencialment. Ara ja es té accés global a tot Internet i, per tant, les possibilitats són virtualment infinites; així i tot, els tipus d'atacs continuen formant part de la mateixa classificació: **denegació de servei, suplantació, i escolta de tràfic**.

Si recordem la capa de xarxa, cap dels protocols que vam veure: IPv4, IPv6 o ICMP; tenen un conjunt de deficiències força greus:

En cap moment del protocol, es comprova que l'emissor és qui diu ser.
En cap moment del protocol, es comprova que el destí existeixi.
En cap moment del protocol, les dades viatgen en obert.

Per tant, fixem-nos que si som capaços de controlar un dispositiu de capa 3 podem controlar completament una xarxa, podem generar atacs de Man-in-the-Middle amb relativa facilitat. Però també, podem redirigir el tràfic cap a on ens interessi, sense que l'emissor sigui capaç de poder-ho comprovar.

A més, a diferència de la capa 2 que parlàvem de la xarxa interna, aquí parlem de la xarxa d'Internet, i això té unes implicacions molt profundes i és que: Els protocols de xarxa i d'enllaç de dades no tenen mecanismes per certificar-ne l'origen o el destí, res del que accedim a Internet tenim la seguretat que sigui el que nosaltres volem. Tot pot ser falsificat, i per tant, un dels principals objectius de la capa d'aplicació serà buscar mecanismes per tal de protegir aquetes deficiències.

Però no només és un problema per la confiança, sinó que també tenim problemes en la integritat i la confidencialitat de la informació. La informació sempre s'envia en obert, no hi ha cap mecanisme que permeti ocultar la IP de destí o origen, o el port de destí o origen, aquesta informació sempre anirà en obert, i qualsevol persona que tingui el control d'un dispositiu de capa 3 per on passi la nostra informació, n'hi tindrà accés, i per tant, tindrà també la possibilitat de modificar-ne les dades.

L'únic aliat que tenim en la capa 3, cosa que en la capa dos no teníem, és el tallafocs, el qual treballa en capa 3-4 i pot filtrar el contingut que afecti als nostres dispositius.

Capa de transport

La principal vulnerabilitat de la capa de transport és que el fet d'apuntar a un port, indirectament, ja ens estan informant de quin servei s'ha sol·licitat per part de l'usuari. Per tant, molts dels atacs orientats als serveis, ja els situaríem més en vulnerabilitats de la capa d'aplicació.

L'atac més conegut pel que fa a transport és el de **denegació de servei**, generalment perpetrat a través de la inundació de paquets TCP o UDP (TCP/UDP Flooding):

TCP Flooding: es basa en l'enviament de paquets TCP al destí, una variant molt utilitzada és el SYN flooding que s'aprofita del 3-way handshake de TCP per tal de forçar a l'aplicació destí a generar molts processos i potencialment causar una aturada del servidor. Aquest atac és molt efectiu perquè l'atacant gasta 40bytes per paquet i el servidor ha de replicar tants processos com SYN es reben.
UDP Flooding: és el mateix amb paquets UDP, aquest atac no és tant efectiu com la versió amb TCP.

El darrer atac conegut a nivell TCP és la predicció de Seqüència amb TCP (TCP Sequence prediction). La idea és endevinar el número de seqüència d'un flux TCP amb l'objectiu de cometre un robatori d'una sessió existent. Però avui en dia és molt difícil que això pugui passar, ja que el número de seqüència es tria aleatòriament entre 2^32 valors.

La protecció de la xarxa

Segmentació lògica d’una xarxa

Una de les primeres opcions que tenim per poder protegir la nostra xarxa és segmentar-la. La segmentació no fa que la nostra xarxa interna sigui més segura, no millora la disponibilitats, ni la integritat, ni la confidencialitat.... l'únic que fem és que la nostra xarxa interna sigui més petita a través de crear subdivisions que no es poden veure entre elles. El que estem creant, son cercles de confiança més petits, es tracta de crear petits conjunts d'una mateixa xarxa que puguin compartir després un conjunt de configuracions comunes.

Tenim dues possibilitats alhora de segmentar una xarxa local:

Segmentar-la a nivell de capa 2: VLAN
Segmentar-la a nivell de capa 3: Subnetting.

Per tant, i és important entendre-ho així, podem dividir la xarxa amb els dispositius de capa 3 o amb els dispositius de capa 2, i encara més, com que son protocols en dues capes diferents, també els podem combinar.

Segmentació mitjançant Subnetting

Encara avui en dia, us podeu trobar a diferents materials que us parlin dels tipus d'adreces A, B, C i D, això és així, perquè des del primer moment es va pensar la idea que el protocol IPv4 havia de promoure la divisió. Per tant, la idea inicial era que segons el tipus de IP que es donava, això provocava que poguessis tenir un rang més gran o més petit de IPs, doncs la gran diferència és que segons el tipus d'adreça tenies una màscara de xarxa o una altra.

Una vegada tenies una màscara concreta, podies anar creant subxarxes en la mesura que anaves incorporant routers a la teva xarxa. A cada pas, la màscara de subxarxa s'anava fent més gran, fins que arribaves al propi dispositiu.

Fixeu-vos en el següent gràfic:

L'esquema anterior us mostra la creació de vàries subxarxes. D'aquestes, les úniques que acceptaran una configuració de dispositius finals com un PC son: 192.168.0.0/26, 192.168.0.64/26, 192.168.0.128/27, 192.168.0.160/27 i la 192.168.0.192./26. Al final, d'una sola xarxa: 192.168.0.0/24, hem creat un total de 5 xarxes. Hem dividit la nostra xarxa i serà la nostra configuració en els routers la que decidirà la disponibilitat, o no, de les subxarxes entre elles. Al final, hem aconseguit dividir la nostra xarxa de forma lògica, evitem que els dispositius de subxarxes diferents es coneguin entre ells, i a més a més, podem anar creant subxarxes segons les nostres necessitats organitzatives.

Però el subnetting té dos problemes bàsics:

La necessitats de diversos dispositius routers únicament per poder anar generant les nostres subxarxes.
La complexitat que es genera en la la creació de la capa física d'una organització, doncs no es poden compartir els dispositius de capa 2.

Per altra banda, el gran benefici del subnetting és que podem situar un Firewall per passar d'una xarxa a una altra.

Segmentació mitjançant VLAN

Ja hem vist abans com, en les capçaleres dels frames de capa 2 hi havia un conjunt de bits que es reservaven per la creació de VLANs. La idea bàsica, és que gràcies al protocol 802.1Q, tenim la capacitat que un switch es divideixi de forma lògica, i per tant, eviti que un conjunt de dispositius connectats al mateix switch es vegin entre ells com si estiguessin en una mateixa xarxa LAN.

D'aquesta manera, un administrador pot assignar un conjunt de interfícies a una mateixa VLAN, i així fer que tots aquells equips es puguin veure a nivell 2 i superiors, però que no puguin veure els equips pertanyents a altres VLAN. Quan dos equips de VLAN diferents volen comunicar-se ho han de fer a través d'un encaminador i, per tant, com es va veure a la lliçó anterior, el tràfic està subjecte a les polítiques de seguretat del tallafoc.

Amb aquesta nova modalitat de segmentació de la xarxa s'obtenen els següents avantatges

Es redueix la necessitat de dispositius de capa 2-3 que es requereix per poder subdividir una xarxa.
S'ofereix més seguretat a través de tallafocs, limitant l'accés entre les diferents xarxes.
Permet separar la xarxa en unitats funcionals més petites, que poden seguir l'estructura de l'empresa, per exemple creant una o més VLAN per cada departament, o per cada planta, o seguint qualsevol criteri que estimi necessari l'administrador.

A nivell d'implementació, cal tenir en compte que a nivell conceptual, caldrà tenir en compte dues coses:

Qui és l'encarregat d'escriure a la capa 2 la VLAN a 802.1Q
Què passa quan diverses VLANS comparteixen una interfície.

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

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

A la figura es poden veure diversos punts interessants:

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

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

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

El proxy

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

El núvol
Els contenidors

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

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

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

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

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

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

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

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

El tallafocs Firewall

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

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

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

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

ACCEPT port 80
DENY ALL

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

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

El firewall de iptables

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

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

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

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

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

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

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

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

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

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

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

El Firewall de nftables

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

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

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

Per utilitzar nftables cal tenir present:

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

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

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

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

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

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

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

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

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

Per posar en context

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

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

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

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

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

figure:figura.01

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

 :footer:

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

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

example:

title: Exemple de regla al tallafoc amb nftables

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

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

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

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

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

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

text:

title:nftables

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

Condicions a les regles

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

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

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

important:

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

Limitacions dels firewalls

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

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

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

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

Evolució actual dels tallafocs

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

UTM (Unified Threat Management)

NGFW (Next Generation Firewall)

UTM (Unified Threat Management)

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

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

NGFW (Next Generation Firewall)

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

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

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

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

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

Els beneficis dels NGFW són:

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

example:

title: Exemple de regla avançada en un NGFW

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

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

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

Els detectors d'intrusos: IDS/IPS

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

Els conceptes claus d'un IDS/IPS son:

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

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

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

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

Network Intrusion Detection System (NIDS)

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

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

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

Host Intrusion Detection System (HIDS)

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

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

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

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

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

Fortificació i gestió del Switch

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

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

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

Fortificació dels accessos wifi

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

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

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

Comunicacions segures en entorns no confiables

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

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

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

Xarxes Privades Virtuals (Virtual Private Networks o VPN)

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

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


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

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

Així doncs, el nou paquet tindria una forma similar a:


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

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

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

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

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

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

Ús de protocols segurs

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

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

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

Fortificació i monitoratge de la xarxa interna

La fortificació des de IT

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

Implementar la protecció perimetral

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

Actualitzacions i Patchs

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

Sistemes d'autenticació forta

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

Monitoratge Continu

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

Xifrat de Dades

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

Gestió de Polítiques de Seguretat

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

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

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

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

Els registres monitorables

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

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

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

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

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

Anàlisi de registres amb Linux: rsyslog

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

Les parts que formen el rsyslog són:

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

Facilities amb rsyslog

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

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

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

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

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

Severities

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


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

Així, com administradors podem fer que el sistema permeti ignorar segons quines severities depenent de cada facility, per configurar-ho en linux editarem l'arxiu /etc/rsyslog.conf. Per exemple:

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

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

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

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

Registres amb rsyslog

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

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

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

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

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

Anàlisi de registres amb Linux: journalctl

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

Amb journalctl, els usuaris poden:

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

Registres amb Windows

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

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

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

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

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

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

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

Tipus d'esdeveniments

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

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

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

Serveis de monitoratge especialitzats

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

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

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

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

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

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

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

@@ Línia 242: / Línia 242: @@
 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''.
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+<span id="Capa_d&#039;enllaç"></span>
-==== Capa d'enllaç ====
+==== Capa de enlace ====
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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.
-Els últims protocols que veurem son els de la capa d'enllaç. En els dispositius de casa, aquest protocol normalment s'implementa en les nostres targetes de xarxa i en el típic ''rotuer wifi'' que tenim tots. És el protocol que es responsabilitza, per una banda de l'adreçament intern de la xarxa, i per l'altre, porta el control del flux d'informació que anem transmetent, per exemple, és qui s'encarrega de conèixer el medi per on viatjarà la informació i s'hi adapta.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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.
-Per aconseguir l'adreça intern, utilitza les adreces MAC, adreces de 48 bits que tenen tots els nostres dispositius i que son irrepetibles a tot el mon. Trobareu moltes vegades, que l'adreça MAC és l'adreça física, i l'adreça IP és l'adreça lògica.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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:
-Els dispositius que treballen sovint amb la capa 2 son els ''switchs'', tots ells tenen una taula on es relaciona cadascun dels seus ports amb les MAC que hi pugui haver-hi darrera. La forma en com s'assigna una interfície i una MAC és un dels aspectes més vulnerables de la nostra xarxa i requereix que ho configurem correctament:
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+# Se debe apagar todas los puertos de interface que no se vayan a usar.
-# Cal apagar tots els ports d'interfície que no es vagin a fer servir.
+# Es una buena práctica, solo aceptar una MAC por interface y no sea intercambiable.
-# És una bona pràctica, només acceptar una MAC per interfície i que no sigui intercanviable.
+# Evitar la redundancia en la red habilitando el ''Spanning Tree Protocol''.
-# Evitar la redundància a la xarxa habilitant l'Spanning Tree Protocol.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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.
-A més, els ''switchs'' més avançants tenen més funcions de seguretat per evitar intrusions i l'atac Man-in-Middle. Qualsevol ''pentester'' que accedeixi a la vostra xarxa, el primer que farà és provar aquest tipus d'atacs a la capa 2. A més a més, avui en dia podem modificar la MAC del nostre dispositiu amb ''Software'', i per tant, és molt fàcil generar una suplantació.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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'''.
-A la capa 2, tenim dos protocols molt fets servir, el protocol que fa servir per connectar-se el nostre dispositiu a través de cable: '''Ethernet - 802.3''', i el protocol que fem servir per connectar-nos sense fils: '''WiFi - 802.11".
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+El protocolo '''Ethernet''' tiene los siguientes ''headers'':
-El protocol '''Ethernet''' té els següents ''headers'':
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 {|class="wikitable" style="text-align: center;"
 |+
@@ Línia 313: / Línia 297: @@
 | colspan="8" |IPG (12 bytes)
 |}
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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'''.
-En canvi, el protocol ''WiFi'' és força més complex, no només perquè sempre està treballant amb tres adreces MAC, sinó pels primers dos bytes ''Frame'' Control, els quals s'encarreguen de mantenir la sessió entre el dispositiu sense fil i el nostre punt AP.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
 {| class="wikitable" style="text-align: center;"
 |+
@@ Línia 359: / Línia 339: @@
 | colspan="8" |Frame check CRC
 |}
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+<span id="Arquitectures_de_xarxa"></span>
-== Arquitectures de xarxa ==
+== Arquitecturas de red ==
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+=== Evolución de la topología de redes===
-=== Evolució de la topologia de xarxes ===
+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'').
-La evolució dels computadors ha anat lligada també a la evolució de les xarxes. Al principi, la topologia de les xarxes eren planes, totes els computadors es podien veure entre tots. Amb l'aparició d'Internet, tot va anar canviar i es van anar aïllant les xarxes entre les xarxes locals '''LAN''' (''Local Area Network'') i les xarxes públiques '''WAN''' (''Wide Area Network'').
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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.
-Internet és la combinació de '''LANs''' i '''WANs'''. Aquesta era la idea fins fa relativament poc, una gran xarxa global no segura i unes xarxes internes segures. Això va provocar que es centrés els esforços de la securització en el perímetre que separava ambdues xarxes.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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.
-D'ençà l'entrada del nou segle, aquesta visió s'ha vist superada i conceptes com: DMZ, BYOD o VLANs, han anat en la línia de no entendre la xarxa interna com a segura. Aquest nou paradigma és el que ha marcat els últims anys en la securització de les xarxes. Cal trobar mecanismes per evitar i disminuir el risc que comporta està connectats a la xarxa.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+El elemento clave, en la defensa perimetral de las redes ha estado el ''Firewall''.
-L'element clau, en la defensa perimetral de les xarxes ha estat el Firewall.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+<span id="Tallafocs_(Firewalls)"></span>
-=== Tallafocs (''Firewalls'') ===
+=== ''Firewalls'' ===
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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 tallafocs (''firewall'') és un dispositiu ''hardware'', o aplicació de ''software'', que té per objectiu vetllar i evitar intrusions a la xarxa. Treballa amb regles dins la capa 2, 3 i 4 del model OSI. '''Això significa que es capaç de filtrar per MAC, IP i PORT'''. (El filtratge per capa 2 no és comú a tots els firewalls)
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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''.
-Moltes vegades ens trobarem amb dispositius ''firewalls'' que funcionen juntament amb els ''routers'' de capa 3. Això és així, perquè el propi dispositiu ''router'' permet configurar un conjunt de regles per filtrar paquets. Però també ens podem trobar que estiguin separats. En aquest cas, el dispositiu ''firewall'' haurà de tenir dues interfícies amb dues IPs per on entri i surti el tràfic de xarxa. En aquest cas, la nostra xarxa interna apuntarà com a porta d'enllaç al ''firewall''.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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.
-Els ''firewall'', com ja hem comentat, treballen en '''capa 3 - xarxa''' i en '''capa 4 - transport'''. Per defecte, son capaços de llegir les capçaleres IP, els ports i els protocols de transport ('''TCP i UDP'''). Com que treballa en capa 4, pot entendre un conjunt de paquets com una connexió.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Una conexión se puede pot identificar con:
-Una connexió es pot identificar amb:
      * IP Origen
-     * IP Destí
+     * IP Destino
-     * Port (transport) Origen
+     * Puerto origen
-     * Port (destí)
+     * Puerto destino
-     * Protocol de transport usat (TCP/UDP generalment)
+     * Protocolo de transporte usado (TCP/UDP)
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+Un beneficio de las conexiones, es que nos permite aceptar tráfico que haya estado solicitado desde el interior de nuestra red.
-Un benefici de les connexions, és que ens permet acceptar tràfic que hagi estat sol·licitat des de l'interior de la nostra xarxa.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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'''.
-Així, el tallafoc estarà compost per un seguit de regles que determinen la **política de seguretat** del tallafoc. Aquest conjunt de regles de control d'accés s'anomenen //Access Control Lists// (ACL). Les ACL són una llista de regles que defineixen una sèrie de condicions, aquestes regles es verifiquen de forma seqüencial. I a la primera regla que es troba una condició que es compleix els sistema, pren una decisió d' '''Acceptar''', si el paquet es considera legítim o '''Denegar''', en el cas que no ho sigui.
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+<span id="Topologia_amb_connexió_doble_(&#039;Dual-Homed&#039;)"></span>
-==== Topologia amb connexió doble ('Dual-Homed') ====
+==== Topología con conexión doble ('Dual-Homed') ====
-</div>
-<div lang="ca" dir="ltr" class="mw-content-ltr">
+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.
-La topologia de xarxa més senzilla possible és la DUAL, aquesta es caracteritza per la utilització d'un ''router'' i un tallafoc. El ''router'' té la funció de separar les dues xarxes, mentre que el ''firewall'' té la funció de filtrar els paquets que poden passar d'una xarxa a l'altra. Com ja hem comentat, moltes vegades aquestes dues funcions es poden trobar en un mateix dispositiu.
-</div>
 <div lang="ca" dir="ltr" class="mw-content-ltr">

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