Tres de les cinc troballes del pentest anterior eren, en el fons, problemes de xarxa: un tauler publicat a la interfície externa del host, un subdomini que apuntava a una IP aliena i un servei accessible des d'on no havia de ser-ho. I segueixen pendents des de 05-01 els tres grans: PostgreSQL escoltant a 0.0.0.0:5432, SSH obert a tot Internet i la consultora amb accés permanent. Aquesta lliçó dibuixa la xarxa de Nimbus tal com està, la redissenya per zones, tanca aquests forats, munta l'accés remot i el DNS com han d'estar, i acaba comprovant amb proves de connectivitat que la segmentació funciona de debò: un disseny no provat és només un dibuix bonic.

1. La xarxa de Nimbus avui, amb els seus problemes
2. Segmentació: el control amb millor relació cost/impacte
3. Tallafocs: tipus, política per omissió i regles de sortida
4. Accés remot segur: VPN, bastió i accés just-in-time
5. Wifi corporativa i de convidats
6. DNS: resolució, filtratge i protecció del domini
7. Protecció davant de DoS i DDoS
8. Detecció en xarxa i el problema del trànsit xifrat
9. Zero Trust aplicat a la xarxa
10. Verificar que la segmentació funciona

Set problemes, ordenats per gravetat:

Cap no requereix comprar res per corregir-se. Els set són configuració, i aquesta és la millor notícia de la lliçó.

La segmentació divideix la xarxa en zones i controla explícitament què pot parlar amb què. És el control que té millor relació cost/impacte perquè no impedeix la intrusió, però impedeix que la intrusió es converteixi en catàstrofe: converteix «han compromès un portàtil» en «han compromès un portàtil», i no en «han compromès l'empresa».

És la lliçó de Target (02-06): els atacants van entrar pel proveïdor de climatització i van arribar als terminals de pagament perquè entre tots dos no hi havia cap frontera. I és també el dia 1-4 de l'incident de Nimbus: des de la xarxa d'administració s'arribava a la zona de dades sense cap control intermedi.

Vocabulari mínim. Una VLAN separa dominis de difusió al mateix switch físic (és lògica, no cablatge nou); una subxarxa és el rang IP associat; el trànsit entre VLAN passa per un dispositiu que encamina i allà és on s'aplica la política. Al núvol l'equivalent són les subxarxes de la VPC i els grups de seguretat, que són tallafocs per instància i no per perímetre: això permet microsegmentació, és a dir, que dos servidors de la mateixa subxarxa no puguin parlar entre si si no ho han de fer.

Disseny objectiu de l'oficina:

I al núvol:

La correcció dels dos forats històrics és literalment això: 5432 deixa d'acceptar 0.0.0.0/0 i només accepta la subxarxa d'aplicació; 22 deixa d'acceptar 0.0.0.0/0 a cada servidor i només s'assoleix des del bastió, que al seu torn només s'assoleix des de la VPN. Vint minuts de feina per al risc més ben puntuat del registre de 04-01.

Dos principis governen la configuració. El primer: política per omissió de denegar. Es tanca tot i s'obre el que està justificat, amb un comentari que digui per què. Una regla sense justificació documentada és una regla que ningú no gosarà treure d'aquí a tres anys.

El segon, el que gairebé ningú no aplica: filtrar també la sortida. Gairebé totes les organitzacions controlen què entra i deixen sortir qualsevol cosa cap a qualsevol lloc. Però l'exfiltració d'1,2 TB de 02-06 i el canal de comandament i control són trànsit de sortida. Un servidor de base de dades no necessita navegar per Internet.

Al núvol, la mateixa política expressada com a grups de seguretat:

Referenciar grups i no rangs d'IP és la bona pràctica més rendible del núvol: la regla segueix sent correcta quan l'API escala, se substitueix o canvia d'IP, i expressa la intenció («l'aplicació parla amb les dades») en lloc d'un accident d'adreçament.

El que costa de debò el filtratge de sortida és la primera setmana: apareixen dependències que ningú no havia documentat. És exactament el motiu pel qual val la pena, perquè aquestes dependències desconegudes són també la superfície que l'atacant fa servir. Es desplega primer en mode registre, es llegeixen els SORTIDA-BLOQUEJADA durant dues setmanes, s'obre el que és legítim i llavors s'activa.

WireGuard és lliure, ràpid, cap en 4.000 línies de codi auditable i la seva configuració entra en una pantalla.

Tres decisions importen. Una IP fixa per persona converteix els registres de tallafoc en traçabilitat real. L'autenticació és per clau, sense contrasenyes per endevinar, però això obliga a un procediment d'alta i baixa: la baixa d'un empleat inclou esborrar el seu [Peer], i si no és a la llista de comprovació de sortida, l'accés sobreviu a la persona. I la VPN dona accés a la xarxa, no als sistemes: ser a la VPN no ha de bastar per entrar a la base de dades; segueix calent autenticació a cada servei.

ProxyJump és la peça clau: el bastió reenvia la connexió, però l'autenticació passa d'extrem a extrem i la clau privada no toca el bastió. És la diferència amb el vell hàbit de copiar la clau al salt, que converteix el bastió en el punt únic de compromís total. El bastió, a més, registra totes les sessions i és l'únic host amb 22 accessible, i només des de la VPN.

L'accés just-in-time inverteix el model: en lloc d'un accés permanent que es revoca quan algú se'n recorda, no hi ha accés fins que es demana, s'aprova i es concedeix amb caducitat automàtica. És el control C-03 de 04-03, i per a A-19 la implementació acordada a 04-04 és:

• Comptes nominals, un per tècnic de la consultora. S'ha acabat el svc-consultora compartit: sense nom no hi ha responsabilitat ni investigació possible.
• MFA obligatori, el control que per si sol hauria evitat l'incident.
• Sol·licitud amb tiquet que indica sistema, motiu i durada; aprovació de la Lucía o la Marta.
• Caducitat de 8 hores, aplicada pel sistema i no per la memòria de ningú.
• Accés només al sistema concret, no a la xarxa completa.
• Alerta D-03 de 05-02 si apareix una autenticació fora de la finestra pactada.
• Revocació de l'excepció del 2023 sense caducitat del registre de 04-02, que és el que mantenia viu l'accés permanent.

Per a Nimbus: WPA3 on el maquinari ho permeti i WPA2-Enterprise a la resta, amb credencial individual contra el proveïdor d'identitat. La clau única compartida per 38 persones és a desenes de mòbils, ha passat per xats i no es canvia des del 2022.

La xarxa de convidats ha d'estar realment aïllada: VLAN 30 pròpia, sense ruta cap a cap altra VLAN, aïllament entre clients activat (que dos convidats no es vegin entre si), límit d'amplada de banda, portal amb condicions d'ús i clau rotada. L'error habitual és fer servir el mateix punt d'accés amb SSID diferent però sense separació de VLAN: això és la mateixa xarxa amb dos noms.

Dues coses que no són controls, i convé dir-ho sense embuts: el filtratge per MAC —les MAC es clonen amb una ordre i es veuen a l'aire encara que el trànsit estigui xifrat— i amagar l'SSID —la xarxa continua anunciant-se a cada connexió d'un client, i a més obliga els portàtils a anar-la buscant activament, cosa que facilita els punts d'accés falsos—. Consumeixen temps d'administració i donen una falsa sensació de seguretat.

El risc de la wifi pública afecta la meitat de la plantilla. Avui TLS protegeix el contingut (03-05), així que l'escenari clàssic de «et llegeixen la contrasenya» és en gran mesura històric; el que continua sent real és el punt d'accés fals que suplanta un portal conegut i l'enverinament de DNS local. La mesura efectiva és simple i ja està muntada: VPN sempre activa fora de l'oficina, amb DNS forçat pel túnel, més HSTS a tots els dominis propis.

El DNS és el control més barat que existeix i el més oblidat. Tres fronts:

Resolució segura i filtratge. Tots els equips fan servir el resolutor corporatiu (o el del túnel VPN), mai el que ofereixi la wifi del bar. Un DNS filtrant bloqueja la resolució de dominis maliciosos, de dominis acabats de registrar i de categories no desitjades. És un control desproporcionadament eficaç: talla el phishing al clic i talla el comandament i control a la primera trucada a casa, funciona igual al portàtil de casa i a l'oficina, i hi ha opcions gratuïtes o de pocs euros per usuari. Per a Nimbus és, juntament amb el MFA, la millor compra per euro del catàleg. DNSSEC protegeix la integritat de les respostes i s'activa al domini propi; DoH/DoT xifren la consulta, amb la contrapartida que un DoH descontrolat al navegador se salta el filtratge corporatiu, així que es configura de forma explícita.

Protecció del propi domini. nimbusreservas.example és l'actiu A-08, crític, i perdre'l és perdre el correu, el web i la capacitat d'emetre certificats. Quatre mesures: bloqueig de transferència al registrador (registrar lock), MFA al compte del registrador amb dues persones amb accés, renovació automàtica amb alerta a 90 dies —han caigut empreses senceres per un domini no renovat—, i revisió trimestral de la zona, que és on apareixen els registres oblidats.

Apropiació de subdominis. És el que va trobar el pentest a 05-03. Passa quan un registre CNAME o A continua apuntant a un recurs que ja no controles —un bucket esborrat, un servei donat de baixa, una IP alliberada—: qualsevol pot reclamar aquell recurs i servir contingut sota el teu domini, amb el teu certificat vàlid i, si les galetes són de domini ampli, amb accés a les sessions dels teus usuaris.

Convé ser honest sobre el que pot i no pot fer una empresa de 38 persones.

Mesures realistes: CDN o proxy invers amb protecció anti-DDoS davant de l'API i del web (hi ha plans gratuïts suficients per a aquesta mida), cosa que a més amaga la IP real de l'origen —que llavors ha d'acceptar trànsit només des de la CDN, o l'atacant l'esquiva—; límit de taxa per IP, per client i per tenant (02-04 i 05-05); autoescalat amb sostre, perquè sense límit l'atac deixa de ser una caiguda i passa a ser una factura; i paginació obligatòria als endpoints que retornen llistes.

Què fer durant un atac, en ordre: confirmar que és un atac i no un pic legítim o una fallada pròpia; activar el mode de protecció de la CDN; no desactivar el registre (es perd l'evidència just quan cal); bloquejar per patró a la vora i no a l'origen; comunicar-ho als clients amb honestedat (04-05); i no pagar cap extorsió associada. I després: post mortem i ajust de llindars.

On es col·loquen els sensors importa tant com quins es trien:

Què es perd amb el xifratge. Avui més del 90 % del trànsit va xifrat, així que un IDS de signatures veu molt menys que fa deu anys. El que continua sent visible sense desxifrar res és molt: qui parla amb qui, quant, en quina direcció i amb quin ritme; el nom del servidor a la salutació TLS i les consultes DNS; el certificat i l'empremta del client TLS. Amb això n'hi ha prou per detectar exfiltració, comandament i control periòdic i destinacions anòmales. Per això els registres de flux i de DNS reten més, i surten molt més barats, que intentar mirar a dins.

L'alternativa —inspecció TLS, és a dir, acabar el xifratge en un equip intermedi per llegir el contingut— té un cost que va més enllà del tècnic: obliga a instal·lar una autoritat de certificació pròpia a cada equip, exposa en aquest punt tot el que la gent fa, inclosa la seva banca i la seva salut, i crea un objectiu d'altíssim valor. Per a Nimbus la conclusió és clara: no es fa inspecció TLS sobre els equips d'empleats; s'inverteix en flux, DNS i telemetria de l'endpoint, que donen gairebé el mateix senyal sense aquest cost. (Nota de validació legal i laboral: a Espanya, qualsevol mesura que permeti accedir al contingut de les comunicacions de la plantilla exigeix informació prèvia, proporcionalitat i, segons el cas, negociació amb la representació dels treballadors; requereix validació jurídica abans d'implantar-se. Es desenvolupa a 06-03 i 06-06.)

Zero Trust no es compra: s'implanta per fases, i per a Nimbus les tres primeres ja estan en marxa o són gratuïtes:

L'advertiment pràctic: una VPN no és Zero Trust. Una VPN que dona accés a tota la xarxa interna reprodueix el perímetre amb un altre nom; es converteix en un pas cap a Zero Trust només quan el que hi ha darrere està segmentat i cada servei autentica pel seu compte.

Aquest és l'apartat que més vegades es salta i el que decideix si tot l'anterior és real. Un disseny de xarxa no provat és un dibuix, i la forma de provar-lo és intentar, des de cada zona, arribar al que no s'hauria d'assolir.

Quatre detalls que fan útil aquest script. Declara l'expectativa, així que serveix de documentació executable del disseny. Inclou un control positiu (1.1.1.1:53 ha d'estar obert): si tot surt «tancat», el més probable és que el problema sigui el mateix script o que no hi hagi xarxa, no que la segmentació sigui perfecta. Retorna codi de sortida diferent de zero, cosa que permet executar-lo des del CI d'infraestructura després de cada canvi. I s'executa des de cada zona, perquè la resposta depèn de l'origen: això vol dir llançar-lo des d'un portàtil a la VLAN d'usuaris, des de la wifi de convidats, des del bastió i des de preproducció.

Per a una comprovació més àmplia, nmap des de cada zona contra les altres documenta el mapa real:

L'error a evitar, i és el més comú de la lliçó: donar per bona la segmentació perquè el diagrama és correcte i les regles «hi són posades». Les regles se solapen, els grups de seguretat s'hereten, algú obre alguna cosa «un moment» per depurar i no la tanca, i una taula de rutes converteix dues zones separades en una de sola. L'única prova que dues zones estan separades és intentar creuar-les i no poder.

• Xarxa plana «perquè som pocs». La mida no protegeix (02-06): amb 38 persones i 40 portàtils, un sol equip compromès arriba a tot.
• Convidats amb SSID diferent però sense VLAN separada. És la mateixa xarxa amb dos noms.
• Confiar en el filtratge MAC o a amagar l'SSID. No són controls; són feina administrativa amb sensació de seguretat.
• Obrir SSH a Internet i «compensar-ho» amb fail2ban. El control correcte és que no sigui assolible; fail2ban és la segona línia, no la primera.
• No filtrar la sortida. És el que permet l'exfiltració i el comandament i control. Comença en mode registre i activa'l en dues setmanes.
• VPN que dona accés a tota la xarxa interna. És el perímetre amb un altre nom; darrere hi ha d'haver segmentació i autenticació per servei.
• Deixar registres DNS de recursos donats de baixa. És la porta a l'apropiació de subdominis, amb el teu domini i el teu certificat.
• Consell: comença pels tres tancaments de vint minuts. 5432 a la subxarxa d'aplicació, 22 només des del bastió i la VPN, i l'excepció d'A-19 revocada. És el descens de risc per hora invertida més gran de tot el curs.
• Consell: posa l'script de verificació al CI d'infraestructura. Si una regla s'obre per error, ho sabràs el mateix dia i no al pròxim pentest.
• Consell: el DNS filtrant és la millor compra per euro després del MFA. Talla phishing i comandament i control, funciona dins i fora de l'oficina i costa uns pocs euros per usuari.

Escriu, per a cadascuna de les tres troballes pendents des de 05-01 —PostgreSQL a 0.0.0.0:5432, SSH obert a 0.0.0.0/0 i l'accés permanent de la consultora (A-19)—: el canvi concret, el risc del registre de 04-01 que redueix, el temps estimat i com verificaries que està fet.

Un antic becari va deixar documentada aquesta configuració de l'oficina:

1. Reescriu el disseny en zones amb els seus rangs i la seva matriu de comunicació permesa.
2. Indica quins dos «controls» cal retirar i per què.
3. Proposa tres regles de sortida i explica quin atac talla cadascuna.

Després d'aplicar la segmentació, la Lucía executa l'script del §10 des d'un portàtil de la VLAN d'usuaris i obté:

Interpreta cada fallada, indica la causa més probable i l'ordre en què les atacaries.

Exercici 1

L'observació de fons: el més important dels tres no és tècnic. Els dos primers són regles de tallafoc; el tercer exigeix una conversa contractual amb un proveïdor, i per això fa dos anys que està pendent. És la diferència entre 04-04 i aquesta lliçó.

Exercici 2

(1) Zones i matriu. El disseny és el de la taula del §2: VLAN 10 usuaris (10.20.10.0/24), 20 servidors locals (10.20.20.0/24), 30 convidats (10.20.30.0/24), 40 gestió (10.20.40.0/24) i 50 no fiables (10.20.50.0/24), amb la TV de sala a la 50 i els punts d'accés, el switch i el router a la 40.

Detall que sol oblidar-se: aïllament també dins de la VLAN d'usuaris. Un portàtil no necessita parlar amb un altre portàtil, i aquest trànsit és justament el del moviment lateral i el del ransomware que es propaga per la xarxa local.

(2) Els dos «controls» a retirar són el filtratge MAC i l'SSID ocult. El primer se salta clonant una MAC visible a l'aire, i a canvi genera feina cada vegada que entra un dispositiu. El segon no amaga res —la xarxa apareix tan bon punt un client s'hi connecta— i empitjora la seguretat: obliga els portàtils a anar preguntant per aquell SSID allà on vagin, cosa que facilita que un punt d'accés fals respongui «sí, sóc jo». Se substitueixen per WPA3 o WPA2-Enterprise amb credencial individual.

(3) Tres regles de sortida:

• Bloquejar tot el sortint llevat de 80/443, DNS al resolutor intern i NTP. Talla el comandament i control per ports no estàndard i bona part del programari maliciós genèric, que sol trucar a casa per ports alts.
• Bloquejar DNS sortint (53, DoH conegut) cap a qualsevol destinació que no sigui el resolutor corporatiu. Talla l'exfiltració per DNS —una tècnica clàssica precisament perquè el DNS gairebé mai no es filtra— i obliga que tot el trànsit passi pel filtre de dominis.
• Bloquejar SMB, RDP i SSH sortints des de la VLAN d'usuaris cap a Internet. No hi ha cas d'ús legítim, i talla tant l'exfiltració a servidors externs com la connexió inversa des d'un equip compromès.

Exercici 3

La tercera fallada és la més important i cal llegir-la primer. 1.1.1.1:53 esperat OBERT i real TANCAT és el control positiu, i que falli invalida els altres resultats: pot ser que el portàtil no tingui xarxa, que el DNS sortint estigui bloquejat per la nova regla d'egress (cosa que seria correcta i només obliga a canviar el control positiu pel resolutor intern) o que l'script estigui malament. Sense control positiu vàlid, els «OK» de les línies 1, 3 i 5 no proven res: podrien ser tancats per falta de connectivitat i no per segmentació.

Interpretació dels altres dos:

• 10.30.10.11:22 obert des de la VLAN d'usuaris. El bastió està ben tancat (línia 3 en OK), però el servidor de l'API continua acceptant SSH des de fora del bastió. Causa més probable: la regla es va aplicar al grup de seguretat nou, però la instància conserva una segona pertinença a un grup antic més permissiu, i al núvol els grups se sumen, no es resten. És l'error clàssic. Es revisa la llista completa de grups de la instància, no només el que s'acaba d'editar.
• 10.20.40.1:443 obert: el panell de gestió del router s'assoleix des de la xarxa d'usuaris. Causa més probable: el dispositiu de gestió escolta a totes les seves interfícies i no només a la VLAN 40, o falta la regla entre VLAN. S'acota a la interfície de gestió i es comprova de nou.

Ordre de treball: (1) arreglar el control positiu i repetir la prova completa, perquè fins llavors no hi ha resultats fiables; (2) l'SSH de l'API, perquè és accés administratiu des d'una zona d'usuaris i equival a no haver tancat res; (3) el panell del router, que és greu —controla la xarxa— però és un graó per sota. I una conclusió transversal: aquest script s'ha d'executar al CI d'infraestructura després de cada canvi, perquè les dues fallades són exactament el tipus de residu que ningú no detecta fins al pentest següent.

Has convertit la xarxa de Nimbus d'un dibuix amb set problemes en un disseny defensable, i ho has fet sense comprar res: els set eren configuració. Saps per què la segmentació és el control amb millor relació cost/impacte —no impedeix la intrusió, impedeix que es converteixi en catàstrofe—, distingeixes VLAN, subxarxa, grup de seguretat i microsegmentació, i tens el disseny objectiu per zones de l'oficina (usuaris, servidors, convidats, gestió, no fiables) i del núvol (pública amb bastió, aplicació, dades, preproducció aïllada), amb la correcció concreta de 5432 acotat a la subxarxa d'aplicació i 22 assolible només des del bastió.

Coneixes els tipus de tallafoc i on va cadascun, la política per omissió de denegar, i el control que gairebé ningú no aplica: filtrar la sortida, amb regles nftables comentades i el seu equivalent en grups de seguretat que referencien grups i no rangs d'IP. Saps que el filtratge de sortida costa una primera setmana de dependències no documentades i que aquest és justament el motiu pel qual val la pena, i que es desplega en mode registre abans d'activar-se. Muntes l'accés remot amb WireGuard —una IP fixa per persona perquè els registres identifiquin algú— i amb bastió SSH fent servir ProxyJump, on la clau privada no toca mai el salt; i saps per què una VPN no és Zero Trust si darrere no hi ha segmentació. Has tancat A-19 amb comptes nominals, MFA, tiquet, caducitat de 8 hores, alerta D-03 i la revocació de l'excepció del 2023.

Saps triar entre WPA2-Personal, WPA2-Enterprise i WPA3, aïllar de debò la xarxa de convidats i per què el filtratge MAC i l'SSID ocult no són controls —el segon fins i tot empitjora la seguretat—. Domines el DNS en els seus tres fronts: resolució i filtratge com la millor compra per euro després del MFA, DNSSEC, protecció del domini A-08 amb bloqueig de transferència, MFA al registrador i renovació automàtica, i l'apropiació de subdominis amb la seva comprovació trimestral. Saps què pot i què no pot fer Nimbus davant de DDoS —el d'aplicació sí, el volumètric no— i què fer durant un atac. Saps on col·locar Suricata, Zeek i els registres de flux, què continua sent visible encara que tot vagi xifrat (qui parla amb qui, quant, DNS i SNI) i per què Nimbus no farà inspecció TLS sobre els equips de la seva plantilla. I tens Zero Trust com a pla per fases, amb les tres primeres gratuïtes o en curs.

Sobretot, t'endus la disciplina que separa el disseny de la realitat: l'script de verificació de segmentació, amb expectatives declarades, control positiu, codi de sortida per al CI i execució des de cada zona. L'única prova que dues zones estan separades és intentar creuar-les i no poder.

La xarxa ja no regala l'accés. Però fixa't en on queda ara la superfície d'atac: el port 443 de l'API continua obert a tot Internet, i ho ha d'estar, perquè allà viu el producte. Cap regla de tallafoc no distingeix una reserva legítima d'un intent de llegir les dades d'una altra clínica: aquesta distinció només la pot fer l'aplicació. A Seguretat en Aplicacions (05-05) entrem al codi: cicle de desenvolupament segur, defenses concretes contra el Top 10 d'OWASP amb les correccions escrites, autorització centralitzada que generalitza la lliçó de l'IDOR, seguretat d'APIs, gestió de secrets, capçaleres i CSP, i un pipeline de CI amb SAST, DAST, SCA i escaneig de secrets que decideix què trenca el build i què només avisa.