← Índex

Cicle formatiu: Administració de sistemes informàtics en xarxa (ASIX)

Mòdul: 0378. Seguretat i alta disponibilitat

Introducció

Un tallafocs (firewall) és l’element de seguretat perimetral més bàsic i, alhora, més crític de qualsevol infraestructura de xarxa. La seva funció és senzilla d’explicar, però delicada de configurar bé: decidir, paquet a paquet o connexió a connexió, què pot entrar i sortir d’una xarxa (o d’una màquina) i què no.

En aquesta unitat treballarem els vuit criteris d’avaluació del RA4, des de la teoria (tipus, nivells de filtratge) fins a la pràctica (regles amb nftables i amb un tallafocs perimetral tipus pfSense/OPNsense), passant per l’anàlisi de registres, les proves de funcionament i el diagnòstic d’incidències.

Com a escenari de referència farem servir un muntatge típic de xarxa docent, similar al del nostre laboratori THOS.LOCAL:

                    ┌─────────────┐
   Internet ────────┤  TALLAFOCS  ├──────── DMZ (10.0.10.0/24)
                    │      3      │            └─ srv-web, srv-mail
                    │ interfícies ├──────── LAN interna (10.0.20.0/24)
                    └─────────────┘            └─ SRV-DC01, SRV-FS01, clients

1. Característiques, tipus i funcions dels tallafocs

1.1. Què és un tallafocs

Un tallafocs és un sistema (maquinari, programari o una combinació dels dos) situat en un punt de la xarxa que inspecciona el trànsit que hi circula i aplica una política de seguretat definida per l’administrador, que permet o denega connexions segons un conjunt de regles.

Característiques bàsiques que ha de complir:

• Tot el trànsit que ha de ser controlat hi ha de passar obligatòriament. Si existeix una via alternativa (un mòdem 4G connectat a un equip intern, una xarxa Wi-Fi no controlada…), el tallafocs deixa de ser efectiu.
• Només ha de deixar passar el trànsit autoritzat, seguint el principi de mínim privilegi (denegar per defecte, permetre només el necessari).
• Ha de ser resistent als atacs, ja que és un dels elements més exposats de la infraestructura.
• No protegeix contra amenaces que no passen per ell: atacs interns, dispositius USB infectats, enginyeria social, etc.

1.2. Tipus de tallafocs

1.3. Funcions principals

1. Filtratge de trànsit segons adreces IP, ports, protocols o aplicacions.
2. Traducció d’adreces (NAT/PAT), imprescindible per compartir una única IP pública.
3. VPN (terminació de túnels IPsec/WireGuard/OpenVPN per a accés remot o interconnexió de seus).
4. Registre i auditoria (logging) del trànsit permès i denegat.
5. Balanceig de càrrega i alta disponibilitat en els models més avançats (failover entre dos tallafocs).
6. IDS/IPS integrat per detectar i bloquejar signatures d’atac conegudes.

2. Nivells de filtratge de trànsit

El filtratge es pot fer a diferents capes del model OSI/TCP-IP. Com més amunt es filtra, més informació té el tallafocs però més cost de procés i més complexitat:

En la pràctica, un tallafocs modern combina diversos nivells alhora:

• Filtratge de paquets (packet filtering): decisió paquet a paquet, sense memòria de connexions anteriors. Ràpid, però limitat (no distingeix una resposta legítima d’un paquet fals amb el mateix port).
• Filtratge amb inspecció d’estat (stateful inspection): el tallafocs recorda les connexions que ell mateix ha permès i només cal obrir regla d’entrada per a les noves connexions; les respostes es permeten automàticament (estat ESTABLISHED,RELATED).
• Filtratge a nivell d’aplicació: entén el protocol i pot prendre decisions més fines (per exemple, permetre HTTP però bloquejar només certs URL, o permetre FTP però inspeccionar el canal de dades dinàmic obert pel mode passiu).

3. Planificació de la instal·lació de tallafocs

3.1. Ubicació dins la xarxa

La decisió d’on col·locar el tallafocs és tan important com la configuració de les regles. Els punts habituals són:

1. Perímetre (Internet ↔︎ xarxa corporativa): el més bàsic i imprescindible. Separa la xarxa interna d’Internet.
2. Entre zones internes de diferent nivell de confiança (per exemple, xarxa d’administració vs. xarxa d’aules, o xarxa de servidors vs. xarxa de clients). Aplica el principi de segmentació: si un segment es compromet, el tallafocs interior limita la propagació (moviment lateral).
3. Davant d’una DMZ (zona desmilitaritzada): xarxa intermèdia on es col·loquen els serveis que han de ser accessibles des d’Internet (web, correu, DNS públic) però que no han de tenir accés directe a la LAN interna.
4. A escala d’amfitrió (host-based): cada servidor o client amb el seu propi tallafocs local, com a capa addicional de seguretat (defensa en profunditat).

3.2. Arquitectures típiques amb DMZ

a) Tallafocs amb tres interfícies (arquitectura més habitual en centres educatius i pimes):

Internet ── [WAN] TALLAFOCS [DMZ] ── srv-web, srv-mail
                       [LAN] ── xarxa interna

Un únic dispositiu amb tres (o més) interfícies físiques o VLANs, cadascuna amb la seva política. És l’arquitectura més senzilla d’administrar.

b) Doble tallafocs (arquitectura “back-to-back”):

Internet ── TALLAFOCS EXTERN ── DMZ ── TALLAFOCS INTERN ── LAN

Més segura (dos productes/fabricants diferents redueixen el risc que una vulnerabilitat afecti els dos alhora), però més cara i complexa de mantenir. Habitual en entorns d’alta seguretat.

3.3. Criteris de planificació

Abans de desplegar cal documentar:

• Inventari de zones i actius: quines xarxes existeixen, quins serveis corren a cada màquina, quins ports necessiten.
• Matriu de fluxos: qui ha de parlar amb qui i per quin port (origen, destí, protocol, port, justificació). Aquesta matriu és la base de les regles que es configuraran a 4.4.
• Política per defecte: recomanada default deny (es denega tot i només es permet el trànsit explícitament necessari), més segura que default allow.
• Redundància: si el tallafocs falla, cau tota la connectivitat que hi passa. Cal valorar un clúster actiu-passiu (per exemple amb CARP a pfSense/OPNsense o VRRP amb keepalived en Linux).
• Dimensionament: throughput necessari, nombre de connexions simultànies esperades, si cal inspecció SSL/TLS (consumeix molta CPU).

4. Configuració de filtres a partir d’un llistat de regles

4.1. Regles de filtratge: estructura general

Independentment del producte, una regla de tallafocs sol tenir aquests camps:

Interfície | Direcció | Protocol | IP origen | Port origen | IP destí | Port destí | Acció | Log

Les accions habituals són ACCEPT/PASS, DROP (descarta sense avisar) i REJECT (descarta i respon amb un missatge d’error, per exemple ICMP port unreachable).

4.2. Exemple amb nftables (Linux)

Suposem el tallafocs de l’escenari amb tres interfícies: eth0 (WAN), eth1 (DMZ, 10.0.10.0/24) i eth2 (LAN, 10.0.20.0/24).

#!/usr/sbin/nft -f

flush ruleset

table inet filter {

    chain input {
        type filter hook input priority 0; policy drop;

        # Trànsit ja establert o relacionat, sempre permès
        ct state established,related accept
        ct state invalid drop

        # Loopback
        iif lo accept

        # Gestió del propi tallafocs només des de la LAN, per SSH
        iif eth2 tcp dport 22 accept

        # Registre de la resta abans de descartar
        log prefix "INPUT-DROP: " drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        ct state established,related accept
        ct state invalid drop

        # Internet -> DMZ: només HTTP/HTTPS al servidor web i SMTP/IMAP al de correu
        iif eth0 oif eth1 ip daddr 10.0.10.10 tcp dport { 80, 443 } accept
        iif eth0 oif eth1 ip daddr 10.0.10.20 tcp dport { 25, 143, 993 } accept

        # LAN -> Internet: navegació i DNS
        iif eth2 oif eth0 tcp dport { 80, 443 } accept
        iif eth2 oif eth0 udp dport 53 accept

        # LAN -> DMZ: administració del servidor web des de la LAN
        iif eth2 oif eth1 ip daddr 10.0.10.10 tcp dport 22 accept

        # La DMZ MAI ha d'iniciar connexions cap a la LAN
        iif eth1 oif eth2 drop

        log prefix "FORWARD-DROP: " drop
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Punts clau d’aquest exemple:

• La política per defecte (policy drop) de les cadenes input i forward implementa el principi default deny.
• ct state established,related accept és el que permet el filtratge amb estat: no cal obrir regla d’entrada per a les respostes.
• La regla iif eth1 oif eth2 drop és explícita per deixar constància de la decisió de disseny (la DMZ és una zona no confiable i mai ha d’iniciar trànsit cap a la LAN), encara que la política per defecte ja ho denegaria.
• Cada bloc que descarta trànsit no esperat es registra (log prefix) abans de fer drop, per poder-ho revisar després (vegeu 4.5).

4.3. Exemple equivalent en un tallafocs perimetral (pfSense/OPNsense)

En aquest tipus de producte les regles es defineixen per interfície, amb interfície gràfica, però segueixen la mateixa lògica. Per a la interfície WAN:

Per a la interfície LAN:

5. Revisió dels registres d’esdeveniments

5.1. Per què cal revisar els logs

Configurar les regles no és suficient: cal verificar que fan el que es pretenia. Els registres (logs) del tallafocs permeten:

• Confirmar que el trànsit legítim passa i el no autoritzat es bloqueja.
• Detectar intents d’accés no autoritzat (escanejos de ports, força bruta) o mala configuració (una regla massa restrictiva que bloqueja trànsit vàlid).
• Fer forense després d’un incident.
• Complir requisits normatius d’auditoria (ENS, RGPD en el que sigui aplicable).

5.2. On i com consultar-los

A Linux (nftables/iptables), els paquets marcats amb log es registren via journald/syslog:

# Veure en temps real
journalctl -k -f | grep 'FORWARD-DROP'

# Comptar quants intents s'han bloquejat per IP origen en l'última hora
journalctl -k --since "-1 hour" | grep 'INPUT-DROP' | grep -oP 'SRC=\K[\d.]+' | sort | uniq -c | sort -rn

A pfSense/OPNsense, l’apartat Status → System Logs → Firewall mostra taula amb interfície, acció, origen/destí i regla que ha coincidit, amb possibilitat de filtrar en temps real.

Centralització: en un entorn amb diversos tallafocs (o simplement per no dependre de logs locals que roten), és recomanable enviar-los a un servidor de logs centralitzat (syslog remot, Wazuh, Graylog…) per correlacionar-los amb altres fonts (IDS, servidors) i generar alertes.

5.3. Què buscar

6. Proves de funcionament: opcions de programari i maquinari

6.1. Programari vs. maquinari

En un centre educatiu és habitual combinar totes dues coses: un tallafocs perimetral (programari com OPNsense sobre maquinari genèric, o un aparell comercial) i tallafocs locals a cada servidor (firewalld, Windows Defender Firewall) com a capa addicional.

6.2. Sondeig i proves

Un cop desplegades les regles, cal provar-les activament, no donar per fet que funcionen:

Des de fora cap al tallafocs (comprovar que només s’obre el necessari):

# Escaneig de ports TCP contra la IP pública/WAN
nmap -sS -p 1-1000 <IP_WAN>

# Comprovar un port concret
nmap -p 443 <IP_WAN>

# Petició real al servei per confirmar que respon correctament
curl -I https://<IP_WAN>

Des de la LAN cap a l’exterior o la DMZ (comprovar que el permès funciona i el prohibit es bloqueja):

# Ha de funcionar (permès a la matriu de fluxos)
curl -I https://www.exemple.cat

# Ha de fallar/bloquejar-se (LAN -> DMZ per un port no autoritzat)
nc -zv -w2 10.0.10.10 21

Comprovació de l’estat de les connexions al mateix tallafocs:

# nftables: veure la taula d'estats de connexió
cat /proc/net/nf_conntrack | wc -l
conntrack -L | grep ESTABLISHED

Auditoria automatitzada de la configuració: eines com nmap --script firewall-bypass o revisions manuals de la política contra la matriu de fluxos prevista ajuden a detectar regles obsoletes o massa permissives (per exemple, una regla any any any oblidada d’una prova).

7. Diagnòstic de problemes de connectivitat provocats pel tallafocs

Quan un usuari reporta “no tinc accés a X”, el tallafocs sol ser el primer sospitós (i sovint, amb raó). Metodologia recomanada:

7.1. Reproduir i acotar el problema

• Des de quina IP/xarxa falla? Falla també des d’altres xarxes?
• Quin port/protocol/servei concret? (no és el mateix “no puc navegar” que “no puc enviar correu”)
• És total (cap paquet passa) o parcial (connecta, però es talla, va molt lent)?

7.2. Comprovar la connectivitat capa a capa

# Capa 3: hi ha ruta i respon l'equip?
ping <IP_desti>

# Capa 3/4: hi ha un salt (el tallafocs) que talla el camí?
traceroute <IP_desti>          # Linux
tracert <IP_desti>             # Windows

# Capa 4: el port concret és accessible?
nc -zv <IP_desti> <port>
telnet <IP_desti> <port>

Si el ping (ICMP) falla, però el servei real funciona (o a l’inrevés), sovint és perquè hi ha una regla que tracta l’ICMP de manera diferent del trànsit TCP/UDP — un error de disseny relativament habitual.

7.3. Consultar els registres del tallafocs (enllaç directe amb 4.5)

Els logs solen donar la resposta immediata: buscar l’entrada DROP/REJECT corresponent a l’origen, destí i port del problema, i identificar quina regla (o la política per defecte) l’ha generat.

7.4. Causes habituals de problemes de connectivitat provocats pel tallafocs

8. Documentació del tallafocs

Un tallafocs sense documentar és un risc de seguretat en si mateix: si la persona que el va configurar marxa, ningú sap per què existeix cada regla, i això porta a no gosar tocar-lo mai (regles obsoletes que s’acumulen) o a eliminar regles necessàries per error.

8.1. Continguts mínims de la documentació

1. Esquema de xarxa amb totes les zones, interfícies, VLANs i adreçament IP.
2. Matriu de fluxos (la treballada a 4.3), amb justificació de negoci/servei de cada flux permès.
3. Llistat de regles amb, per a cadascuna: propòsit, data d’alta, responsable de la petició i data de revisió/caducitat prevista (especialment important en regles “temporals”).
4. Procediment de gestió de canvis: com se sol·licita, aprova i desplega un canvi a les regles (evita canvis improvisats sense registre).
5. Procediment de còpia de seguretat i restauració de la configuració del tallafocs.
6. Procediment davant d’incidents: què fer si es detecta un atac o una regla compromesa, a qui escalar-ho.
7. Registre de canvis (cronologia): qui ha canviat què i quan (idealment amb control de versions si la configuració és fitxers de text, com en el cas de nftables).

8.2. Exemple de plantilla de fitxa de regla

### Regla: WEB-DMZ-HTTPS-01
- **Zones:** WAN -> DMZ
- **Origen:** any
- **Destí:** 10.0.10.10 (srv-web)
- **Port/Protocol:** TCP/443
- **Acció:** ACCEPT
- **Justificació:** publicació del web corporatiu
- **Sol·licitat per:** Direcció / Comunicació
- **Data d'alta:** 2026-02-10
- **Revisió prevista:** anual

Versions d’aquest document

• HTML
• PDF
• ODT
• MD

Domini Públic (CC0)