Cicle formatiu: Administració de sistemes informàtics en xarxa (ASIX)
Mòdul: 0378. Seguretat i alta disponibilitat
Per als exemples pràctics utilitzarem una topologia de laboratori amb tres màquines: un router/firewall amb dues o tres interfícies de xarxa (WAN, LAN, DMZ), un servidor intern (LAN) i un client remot que simula un usuari des d’Internet.
Quan un sistema informàtic deixa de ser una illa i es connecta a Internet, apareixen riscos que no existeixen en una xarxa tancada. Els escenaris típics que obliguen a fortificar la xarxa són:
En tots aquests casos, el principi que guia el disseny és el mateix: exposar el mínim imprescindible i segmentar la resta. D’aquí neix la seguretat perimètrica.
El perímetre de xarxa és la frontera entre allò que controlem (la xarxa interna) i allò que no controlem (Internet). Els elements bàsics que en formen part són:
| Element | Funció |
|---|---|
| Router frontera | Connecta la xarxa interna amb l’exterior; sol fer NAT. |
| Tallafocs (firewall) | Filtra el trànsit segons regles (IP, port, protocol, estat de la connexió). |
| IDS/IPS | Detecta (IDS) o detecta i bloqueja (IPS) patrons de trànsit maliciós. |
| Proxy | Intermedia connexions (sortints o entrants), pot fer cache i filtrat de contingut. |
| Passarel·la VPN | Punt d’entrada xifrat per a usuaris o xarxes remotes. |
| Bastion host | Servidor endurit (hardened) exposat a Internet, únic punt d’entrada a la DMZ. |
Segons el nivell d’exposició i confiança, classifiquem la xarxa en zones:
La regla d’or de la DMZ és: el trànsit d’Internet pot arribar a la DMZ; el trànsit de la DMZ cap a la LAN és molt restringit; el trànsit d’Internet mai arriba directament a la LAN.
Utilitza un únic tallafocs amb tres interfícies (WAN, DMZ, LAN):
Internet ── [ Tallafocs (3 interfícies) ] ── DMZ
│
LANAvantatges: senzilla, econòmica, un sol punt de gestió.
Inconvenients: un únic punt de fallada. Si el tallafocs és compromès o mal configurat, tota la protecció cau alhora. Un error de regles pot exposar la LAN directament.
Utilitza dos tallafocs (idealment de fabricants diferents), amb la DMZ situada entre tots dos:
Internet ── [ Tallafocs extern ] ── DMZ ── [ Tallafocs intern ] ── LANAvantatges: defensa en profunditat. Un atacant que compromet un servidor de la DMZ encara ha de superar un segon tallafocs, possiblement d’un fabricant diferent (evita que una mateixa vulnerabilitat afecti els dos).
Inconvenients: més cost, més complexitat de gestió i manteniment.
Abans de parlar de VPN cal saber quins protocols proporcionen xifratge i autenticació, i a quin nivell de la pila OSI/TCP-IP actuen:
| Protocol | Nivell | Àmbit d’ús típic |
|---|---|---|
| IPSec | Xarxa (nivell 3) | VPN site-to-site, VPN d’accés remot a escala de xarxa |
| SSL/TLS | Transport/sessió (nivell 4-5) | HTTPS, VPN SSL (portal web o client), correu segur (IMAPS, SMTPS) |
| SSH | Aplicació (nivell 7) | Administració remota, túnels d’aplicació, SFTP |
| WireGuard | Xarxa (nivell 3, en espai d’usuari/kernel) | VPN moderna, alternativa lleugera a IPSec |
| RADIUS/TACACS+ | Aplicació | Autenticació i autorització centralitzada d’accessos |
La diferència pràctica és què queda protegit: IPSec xifra tot el trànsit IP entre dos punts (transparent a les aplicacions), SSL/TLS xifra una connexió concreta pel que fa a la sessió, i SSH xifra una sessió o un túnel concret a nivell d’aplicació.
Una VPN crea un canal de comunicació xifrat i autenticat sobre una xarxa no confiable (normalment Internet), simulant que els extrems estan connectats per una xarxa privada.
Tipus segons l’ús:
| Línia dedicada | VPN sobre Internet | |
|---|---|---|
| Cost | Alt (lloguer de circuit) | Baix (només connexió a Internet) |
| Latència/QoS | Garantida pel proveïdor | Depèn d’Internet, sense garanties |
| Desplegament | Lent (instal·lació física) | Ràpid (configuració de programari) |
| Escalabilitat | Costosa d’ampliar | Molt escalable (nous usuaris = nova configuració) |
| Seguretat | Física (el mitjà no és compartit) | Criptogràfica (depèn de la implementació) |
Les VPN modernes es basen en criptografia asimètrica per a l’intercanvi inicial de claus i criptografia simètrica per xifrar el volum de dades (és molt més ràpida):
Aquest esquema és el que trobem tant a IPSec (IKE) com a TLS (handshake) com a SSH i WireGuard.
IPSec no és un sol protocol sinó un conjunt:
Modes de funcionament:
A la pràctica, la solució IPSec més estesa en entorns Linux és strongSwan, i és compatible amb clients natius de Windows, macOS, iOS i Android (IKEv2), fet que la fa molt útil per a VPN d’accés remot sense instal·lar programari addicional al client.
SSH permet crear túnels xifrats per a aplicacions concretes sense muntar una VPN completa:
# Túnel local: accedim a un servei intern (ex: escriptori remot al port 3389)
# a través del servidor SSH bastion, com si fos local al nostre equip (port 13389)
ssh -L 13389:servidor-intern:3389 usuari@bastion.exemple.cat
# Túnel remot: exposem un servei nostre cap a la xarxa remota
ssh -R 8080:localhost:80 usuari@servidor-remot.exemple.cat
# SSH com a proxy SOCKS: tot el trànsit d'una aplicació passa xifrat pel túnel
ssh -D 1080 usuari@bastion.exemple.catDiferència clau amb una VPN real: SSH tuneling xifra connexions concretes (aplicació per aplicació), mentre que IPSec o WireGuard xifren tot el trànsit IP entre els dos extrems, de manera transparent per a qualsevol aplicació.
Muntarem una passarel·la VPN amb WireGuard, per la seva senzillesa de configuració i el seu ús creixent en entorns de producció, com a exemple pràctic de VPN a escala de xarxa amb clau pública/privada.
203.0.113.10, interfície WireGuard 10.10.0.1/24.10.10.0.2/24 i, a través del túnel, accedirà a la LAN
interna 192.168.10.0/24.sudo apt update
sudo apt install wireguard -y
# Generem el parell de claus del servidor
wg genkey | sudo tee /etc/wireguard/server_private.key
sudo cat /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.keyFitxer /etc/wireguard/wg0.conf al servidor:
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <clau_privada_servidor>
# Reenviem trànsit del túnel cap a la LAN interna i apliquem NAT si cal
PostUp = iptables -A FORWARD -i wg0 -o eth1 -j ACCEPT
PostUp = iptables -A FORWARD -i eth1 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -o eth1 -j ACCEPT
PostDown = iptables -D FORWARD -i eth1 -o wg0 -j ACCEPT
[Peer]
# Client remot
PublicKey = <clau_publica_client>
AllowedIPs = 10.10.0.2/32Cal habilitar l’encaminament IP al sistema:
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -pAixequem la interfície i l’activem a l’arrencada:
sudo systemctl enable --now wg-quick@wg0wg genkey | tee client_private.key | wg pubkey > client_public.keyFitxer wg0.conf al client:
[Interface]
Address = 10.10.0.2/24
PrivateKey = <clau_privada_client>
[Peer]
PublicKey = <clau_publica_servidor>
Endpoint = 203.0.113.10:51820
# Només enviem pel túnel el trànsit cap a la LAN interna (split tunnel)
AllowedIPs = 192.168.10.0/24, 10.10.0.0/24
PersistentKeepalive = 25Si a AllowedIPs del client hi poséssim 0.0.0.0/0, tot el trànsit d’Internet del
client passaria pel túnel (full tunnel), útil per inspeccionar o filtrar
la navegació dels usuaris remots, però consumeix més amplada de banda a
la passarel·la.
Cal obrir únicament el port UDP de WireGuard des d’Internet:
sudo iptables -A INPUT -p udp --dport 51820 -j ACCEPTLa resta de trànsit d’Internet cap a la passarel·la ha de quedar bloquejat: la passarel·la només ha d’exposar el servei VPN, seguint el mateix principi de mínima exposició de la seguretat perimètrica.
Un cop el túnel xifrat està establert, cal decidir com s’autentica l’usuari. No és el mateix xifrar el canal que verificar qui hi ha a l’altre extrem.
| Mètode | Descripció | Seguretat |
|---|---|---|
| PAP (Password Authentication Protocol) | Envia usuari i contrasenya en clar (dins del túnel, però sense protecció addicional). | Baixa |
| CHAP (Challenge Handshake) | El servidor envia un repte (challenge); el client respon amb un hash de la contrasenya + el repte. La contrasenya mai viatja per la xarxa. | Mitjana |
| MS-CHAPv2 | Variant de CHAP de Microsoft, amb autenticació mútua. Usat històricament amb PPTP/L2TP. | Mitjana |
| EAP (Extensible Authentication Protocol) | Marc extensible que permet diversos mètodes (EAP-TLS amb certificats, EAP-PEAP, EAP-MSCHAPv2…). Base de l’autenticació 802.1X i de molts servidors RADIUS. | Alta (segons el mètode EAP triat) |
| Certificats digitals (clau pública) | L’usuari es presenta amb un certificat signat per una CA de confiança, en lloc d’una contrasenya. | Alta |
| Autenticació multifactor (MFA) | Combina alguna cosa que l’usuari sap (contrasenya) amb alguna cosa que té (token, app OTP) o és (biometria). | Molt alta |
A la pràctica, moltes passarel·les (IPSec amb IKEv2, VPN SSL) permeten combinar certificat de màquina + usuari/contrasenya (o EAP), de manera que cal tant un dispositiu autoritzat com unes credencials vàlides.
En lloc de mantenir una llista d’usuaris a cada passarel·la, el més habitual és centralitzar l’autenticació en un servidor dedicat. El protocol estàndard per a això és RADIUS (Remote Authentication Dial-In User Service).
sudo apt update
sudo apt install freeradius -yDonem d’alta un client RADIUS (la nostra passarel·la VPN) a /etc/freeradius/3.0/clients.conf:
client passarella-vpn {
ipaddr = 10.10.0.1
secret = SecretCompartit2024
shortname = vpn-gateway
}Creem un usuari de prova a /etc/freeradius/3.0/users:
usuari1 Cleartext-Password := "Contrasenya123"Reiniciem el servei i el provem en mode depuració:
sudo systemctl restart freeradius
sudo freeradius -XDes d’una altra terminal, validem l’autenticació amb l’eina de proves inclosa:
radtest usuari1 Contrasenya123 localhost 0 SecretCompartit2024Una resposta Access-Accept confirma que el servidor
autentica correctament.
L’últim pas és configurar la passarel·la (per exemple, un servidor
strongSwan amb mòdul EAP-RADIUS, o un OpenVPN amb el
connector radiusplugin) perquè, en lloc de validar
contrasenyes localment, delegui l’autenticació al servidor RADIUS.
Exemple de configuració a /etc/strongswan.d/charon.conf
per activar l’agent EAP-RADIUS:
charon {
plugins {
eap-radius {
servers {
freeradius-server {
address = 192.168.10.5
secret = SecretCompartit2024
auth_port = 1812
}
}
}
}
}I a la configuració de la connexió IKEv2
(/etc/ipsec.conf), s’indica que l’autenticació de l’usuari
es fa per EAP:
conn accesremot
left=%any
leftauth=pubkey
leftcert=serverCert.pem
right=%any
rightauth=eap-radius
rightsourceip=10.10.0.0/24
auto=addD’aquesta manera, el servidor s’autentica amb el client mitjançant certificat (l’usuari sap que es connecta a la passarel·la legítima), i l’usuari s’autentica mitjançant EAP contra el servidor RADIUS, que és qui finalment decideix si les credencials són vàlides.