NET-AUDIT WIKI
v2.0
15 incidències
📋 MANUAL OPERATIU · AUDITORIES DE XARXA
Catàleg d’Incidències
Típiques de Xarxa
Document de referència operatiu per a la detecció, diagnosi i resolució de les incidències més habituals en auditories de xarxa corporativa.
15Incidències
4Nivells de gravetat
5Categories
100%Operatiu mòbil
📌 Justificació de la selecció
Aquestes 15 incidències representen els problemes detectats amb major freqüència en entorns corporatius de xarxa, basats en l’anàlisi de les categories de fallades de la família ISO/IEC 27001 i els protocols MUST (Monitoring, Uptime, Security, Topology). S’han prioritzat aquelles amb major impacte en la disponibilitat del servei, la seguretat i el rendiment. Les incidències de capa 2 (bucles, STP, VLAN) apareixen en >70% de les auditories; les de seguretat (accessos no autoritzats, SNMP) representen el risc de compliment normatiu més crític; i les d’infraestructura (DNS, DHCP, NTP) afecten la operativitat diària de forma silenciosa però persistent.
⏱ Temps resolució estimat
🔍 Detecció via protocols MUST
⚡ Alerta primerenca disponible
🔗 Enllaç a protocol
Cap incidència trobada amb aquests criteris.
I01
Bucle de Capa 2 (Broadcast Storm)
📋 Descripció
Trànsit de broadcast es replica indefinidament en bucle per la xarxa, saturant el 100% de l’ample de banda disponible i causant caiguda total de servei en qüestió de segons.
🔬 Causa probable
- Connexió redundant sense STP actiu
- STP mal configurat o desactivat deliberadament
- Switch no gestionat afegit a la topologia
- Error de cablejat creant bucle físic
🔍 Com es detecta — Protocols MUST
- Monitoring: CPU del switch al 100%, llums de port intermitents, show interfaces counters mostra errors creixents
- Uptime: Caiguda sobtada de latència → timeout generalitzat
- Topology: show spanning-tree mostra ports en estat de Listening/Learning indefinidament
- Wireshark: Flux de broadcast superior al 30% del trànsit total
✅ Com es resol
- Identificar i desconnectar físicament el port que crea el bucle
- Activar spanning-tree portfast + bpduguard en ports d’accés
- Configurar Rapid PVST+ (IEEE 802.1w) en tots els switches
- Implementar storm-control broadcast level 20 com a mesura preventiva
⚡ Alerta primerenca
Monitora el % de broadcast per port amb SNMP. Configura alerta si supera el 10% del trànsit. Revisa la topologia lògica mensualment amb → Protocol Topology.
I02
Adreces IP Duplicades
📋 Descripció
Dos o més dispositius comparteixen la mateixa adreça IP, causant intermitència en les connexions, pèrdua de servei aleatòria i possibles problemes de seguretat per suplantació ARP.
🔬 Causa probable
- Assignació manual d’IP dins del rang DHCP
- Reserva DHCP incorrecta o desactualitzada
- Dispositiu amb IP estàtica antiga reconectat
- ARP spoofing / atac actiu
🔍 Com es detecta — Protocols MUST
- Security: arp -a mostra la mateixa IP amb dues MAC diferents
- Monitoring: Alertes de conflicte IP al registre d’esdeveniments del SO
- Wireshark: Filtre arp.duplicate-address-detected detecta conflictes en temps real
- DHCP log: Entrada «DHCPNAK» per conflicte d’adreça
✅ Com es resol
- Identificar els dos dispositius amb show ip arp al switch
- Reassignar IP estàtiques fora del rang DHCP (ex: 192.168.1.200-254 per a dispositius estàtics)
- Activar ip dhcp snooping + ip arp inspection (DAI)
- Documentar totes les IPs estàtiques en un inventari centralitzat
⚡ Alerta primerenca
Implementa Dynamic ARP Inspection al switch. Configura alertes SNMP per conflictes ARP. → Protocol Security
I03
Dispositiu No Autoritzat a la Xarxa
📋 Descripció
Un dispositiu desconegut accedeix a la xarxa corporativa sense autorització, podent exfiltrar dades, propagar malware o actuar com a punt d’entrada per a atacs interns.
🔬 Causa probable
- Ports de switch sense 802.1X activat
- Wi-Fi corporatiu sense autenticació forta
- Proveïdor o visita amb accés físic al rack
- Rogue AP o switch no gestionat instal·lat
🔍 Com es detecta — Protocols MUST
- Security: Escaneig periòdic amb nmap -sn 192.168.0.0/24 i comparació amb inventari
- Monitoring: IDS/IPS genera alerta per MAC desconeguda
- Topology: show mac address-table mostra MAC no registrada
- DHCP log: Petició DHCP de MAC no reconeguda
✅ Com es resol
- Bloquejar el port de switch immediatament: shutdown a la interfície
- Implementar 802.1X (autenticació per port) amb servidor RADIUS
- Activar port-security maximum 1 en ports d’accés crítics
- Establir llista blanca de MACs al DHCP per a dispositius autoritzats
⚡ Alerta primerenca
Desplegament d’un sistema NAC (Network Access Control). Alerta automàtica quan apareix una MAC nova. → Protocol Security
I04
VLAN Mal Configurada o Absent
📋 Descripció
La segmentació de la xarxa en VLANs és incorrecta, permetent trànsit no desitjat entre departaments, reduint el rendiment i comprometent la seguretat (ex: accés de usuaris a servidors de producció).
🔬 Causa probable
- Ports d’accés assignats a VLAN incorrecta
- Links trunk sense configuració de VLANs permeses
- VLAN nativa no canviada (per defecte VLAN 1)
- Inter-VLAN routing excessivament permissiu
🔍 Com es detecta — Protocols MUST
- Topology: show vlan brief i show interfaces trunk per verificar assignacions
- Security: Prova de ping entre VLANs sense enrutament configurat → si respon, hi ha problema
- Monitoring: Trànsit entre segments no esperats visible al firewall
✅ Com es resol
- Redefinir l’assignació de VLANs per departament i funció
- Configurar trunks amb switchport trunk allowed vlan explícit
- Canviar la VLAN nativa: switchport trunk native vlan 999
- Revisar i restringir les regles inter-VLAN al router/firewall capa 3
⚡ Alerta primerenca
Documentar el diagrama VLAN i revisar-lo trimestralment. Alerta si apareix trànsit entre VLANs sense regla ACL associada. → Protocol Topology
I05
Errors de Resolució DNS
📋 Descripció
El servidor DNS intern resol incorrectament els noms de domini, causant que els usuaris no puguin accedir a aplicacions corporatives, tot i que la connectivitat IP és correcta.
🔬 Causa probable
- Zona DNS interna desactualitzada o corrupta
- Servidor DNS primari caigut, secundari no configurat
- Enveri DNS (DNS poisoning) actiu
- TTL excessivament alt amb registres obsolets
🔍 Com es detecta — Protocols MUST
- Monitoring: nslookup domini.local i dig @servidor domini per verificar respostes
- Uptime: Test de disponibilitat del port 53 UDP/TCP al servidor DNS
- Security: Comparar respostes DNS amb registres coneguts per detectar poisoning
✅ Com es resol
- Corregir registres A/CNAME incorrectes a la zona DNS
- Configurar servidor DNS secundari com a fallback
- Implementar DNSSEC per a zones crítiques
- Ajustar TTL a valors raonables (300-3600 segons per a registres dinàmics)
⚡ Alerta primerenca
Monitor DNS amb check_dns (Nagios/Zabbix). Alerta si el temps de resposta supera 200ms o la resolució falla. → Protocol Uptime
I06
Pool DHCP Exhaurit
📋 Descripció
El servidor DHCP ha esgotat totes les adreces IP disponibles del pool, impedint que nous dispositius obtinguin configuració de xarxa i bloquejant el seu accés.
🔬 Causa probable
- Rang del pool massa petit per al nombre de dispositius
- Temps de lease excessivament llarg amb IPs «retingudes»
- Atac DHCP starvation (esgotament deliberat)
- Dispositius fantasma amb leases actives (dispositius apagats)
🔍 Com es detecta — Protocols MUST
- Monitoring: show ip dhcp pool mostra «Available: 0» o pròxim a zero
- Uptime: Nous dispositius obtenen APIPA (169.254.x.x) en lloc d’IP corporativa
- Security: Revisar log DHCP per a peticions massives des d’una mateixa MAC
✅ Com es resol
- Ampliar el rang del pool DHCP o afegir subnets addicionals
- Reduir el temps de lease a 4-8 hores per a dispositius d’accés
- Netejar leases antigues: clear ip dhcp binding *
- Implementar ip dhcp snooping rate-limit per prevenir starvation
⚡ Alerta primerenca
Alerta SNMP quan el pool superi el 80% d’ocupació. Revisió setmanal d’estadístiques DHCP. → Protocol Monitoring
I07
Encaminament Asimètric
📋 Descripció
El trànsit d’anada i tornada entre dos punts segueix camins de xarxa different, causant problemes amb firewalls stateful, connexions TCP truncades i dificultat per diagnosticar problemes.
🔬 Causa probable
- Múltiples gateways sense coordinació de rutes
- ECMP (Equal-Cost Multi-Path) mal configurat
- Rutes estàtiques contradictòries amb el protocol dinàmic
- Policy-based routing inconsistent
🔍 Com es detecta — Protocols MUST
- Topology: traceroute bidireccional mostra camins diferent en cada sentit
- Monitoring: Sessions TCP s’estableixen però es trenquen de forma aleatòria
- Security: Firewall genera logs «invalid state» per sessions sense SYN inicial
✅ Com es resol
- Revisar i harmonitzar la taula de rutes en tots els routers
- Configurar métriques coherents a OSPF/BGP
- Usar ip route per establir rutes explícites quan sigui necessari
- Desactivar RPF check si és l’origen del problema: ip verify unicast source reachable-via any
⚡ Alerta primerenca
Verificació mensual de taules de rutes. Documentar diagrama lògic de routing. → Protocol Topology
I08
Firewall amb Política Permissiva
📋 Descripció
El firewall té regles excessivament permissives (ex: permit any any), zones de seguretat mal definides, o ports innecessaris oberts, exposant la xarxa a atacs externs i moviments laterals interns.
🔬 Causa probable
- Regles temporals de resolució de problemes no eliminades
- Política «deny by default» no implementada
- Falta d’auditoria periòdica de regles
- Regles heretades de migracions anteriors
🔍 Com es detecta — Protocols MUST
- Security: Escaneig de ports extern amb nmap -sV IP_publica per veure serveis exposats
- Security: Revisió manual del ruleset del firewall cercant regles «any-any»
- Monitoring: Anàlisi de logs de connexions acceptades des d’IPs externes no autoritzades
✅ Com es resol
- Implementar política «default deny» en totes les zones
- Eliminar totes les regles any-any i substituir per regles específiques
- Revisar i documentar cada regla existent; eliminar les no necessàries
- Segmentar en zones: WAN, DMZ, LAN, Management, Producció
⚡ Alerta primerenca
Auditoria de regles firewall cada 90 dies. Alerta automàtica si es crea una regla «any» sense aprovació. → Protocol Security
I09
Congestió d’Ample de Banda
📋 Descripció
Un o més enllaços de la xarxa operen al 100% de la seva capacitat de forma sostenida, causant cues de paquets, alta latència i degradació del servei per a tots els usuaris.
🔬 Causa probable
- Aplicació de backup o còpia massiva no planificada
- Usuari descarregant grans volums de dades
- Trànsit P2P o streaming no restringit
- Creixement orgànic de la xarxa sense augment de capacitat
🔍 Com es detecta — Protocols MUST
- Monitoring: Gràfiques SNMP d’ús d’interfície superant el 80% de forma sostinguda
- Monitoring: show interfaces GigEth0/0 → «output queue drops»
- Uptime: Increment de latència RTT mesurat amb ping continu
- Wireshark/NetFlow: Identificació dels top-talkers de la xarxa
✅ Com es resol
- Identificar i limitar l’origen de la congestió (rate limiting per IP/aplicació)
- Implementar QoS: prioritzar VoIP i aplicacions crítiques
- Planificar backups en horari nocturn
- Avaluar ampliació de l’ample de banda del link o WAN optimization
⚡ Alerta primerenca
Alerta SNMP al 80% d’ús sostenible durant més de 5 minuts. Revisió de capacitat trimestral. → Protocol Monitoring
I10
STP Inestable (TCN Excessius)
📋 Descripció
El protocol Spanning Tree genera canvis de topologia (TCN) freqüents, causant que les taules MAC s’esborrin constantment, la qual cosa provoca flooding temporal i degradació del rendiment.
🔬 Causa probable
- Dispositiu que connecta/desconnecta repetidament (flapping)
- Port d’accés sense PortFast configurat
- Switch amb prioritat STP incorrecta competint per ser root
- Problemes de cablejat causant pèrdua de link intermitent
🔍 Com es detecta — Protocols MUST
- Topology: show spanning-tree detail → comptador «topology changes» elevat
- Monitoring: Pics periòdics de trànsit de broadcast cada 30 segons
- Syslog: Missatges «%SPANTREE-5-TOPOTRAP» freqüents
✅ Com es resol
- Identificar el port origen del TCN i configurar portfast
- Fixar el root bridge amb prioritat baixa: spanning-tree vlan 1 priority 4096
- Revisar el cablejat del port problemàtic
- Implementar spanning-tree loopguard globalment
⚡ Alerta primerenca
Alerta syslog per TCN. Revisar comptadors STP setmanalment. → Protocol Topology
I11
NTP Dessincronitzat
📋 Descripció
Els dispositius de la xarxa no estan sincronitzats temporalment, causant errors d’autenticació Kerberos, certificats SSL invàlids, logs inconsistents i dificultat per correlacionar incidents de seguretat.
🔬 Causa probable
- Servidor NTP intern caigut o mal configurat
- Dispositius apuntant a servidors NTP públics inconsistents
- Deriva de rellotge (clock drift) en servidors virtuals
- Firewall bloquejant UDP 123 al servidor NTP
🔍 Com es detecta — Protocols MUST
- Monitoring: ntpq -p mostra offset superior a 128ms o servidor no sincronitzat
- Security: Errors d’autenticació Kerberos «clock skew too great»
- Uptime: Timestamps de logs inconsistents entre dispositius
✅ Com es resol
- Configurar jerarquia NTP: stratum 1 extern → stratum 2 intern → clients
- ntp server pool.ntp.org prefer en el servidor mestre intern
- Verificar que UDP 123 passa pel firewall cap al servidor NTP
- Forçar sincronització immediata: ntpdate -u servidor_ntp
⚡ Alerta primerenca
Monitor NTP amb alerta si el offset supera 50ms. Revisar sincronització diàriament. → Protocol Monitoring
I12
Pèrdua de Paquets i Alta Latència
📋 Descripció
Un percentatge significatiu de paquets es perd durant la transmissió, o la latència supera els llindars acceptables, degradant la qualitat de les aplicacions en temps real (VoIP, videoconferència, VDI).
🔬 Causa probable
- Cable danyat o connexió física defectuosa (errors CRC)
- Negociació de velocitat/dúplex incorrecta (duplex mismatch)
- Interferència en Wi-Fi (solapament de canals)
- Buffer overrun en router o switch saturat
🔍 Com es detecta — Protocols MUST
- Monitoring: ping -c 100 destí mesura packet loss; mtr destí identifica el salt problemàtic
- Topology: show interfaces → errors CRC, input/output errors elevats
- Uptime: Test de jitter amb iperf3 per a circuits WAN/VoIP
✅ Com es resol
- Substituir cable o SFP si hi ha errors CRC persistents
- Forçar velocitat i dúplex manualment: speed 1000 / duplex full
- En Wi-Fi: canviar canal, reduir solapament, considerar 5GHz
- Revisar la càrrega del dispositiu i aplicar QoS per prioritzar trànsit sensible
⚡ Alerta primerenca
Monitor continu de latència i packet loss. Alerta si supera 1% de pèrdua o 10ms latència en LAN. → Protocol Uptime
I13
Firmware/SO Obsolet amb CVEs Coneguts
📋 Descripció
Switches, routers o firewalls executen versions de firmware amb vulnerabilitats de seguretat (CVEs) públicament conegudes, que podrien ser explotades per actors maliciosos per obtenir accés privilegiat o provocar denegació de servei.
🔬 Causa probable
- Política de patches inexistent o no complerta
- Por a interrupcions de servei durant l’actualització
- Dispositius en zones de xarxa poc monitorades
- Desconeixement de les versions instal·lades
🔍 Com es detecta — Protocols MUST
- Security: Inventari de versions amb show version i comparació amb base de dades CVE (NIST NVD)
- Security: Escaneig de vulnerabilitats amb Nessus / OpenVAS
- Monitoring: Subscripció a butlletins de seguretat del fabricant (Cisco PSIRT, etc.)
✅ Com es resol
- Inventariar totes les versions de firmware/SO de la xarxa
- Prioritzar actualitzacions per CVSS score (≥7.0 → actualització urgent)
- Planificar finestres de manteniment per a actualitzacions
- Establir política de patching trimestral per a dispositius de xarxa
⚡ Alerta primerenca
Subscripció a CVE feeds del fabricant. Inventari automàtic de versions amb Ansible/scripts SNMP. → Protocol Security
I14
SNMP amb Community Strings per Defecte
📋 Descripció
Dispositius de xarxa amb SNMP v1/v2c configurat amb les community strings per defecte (public/private), permetent a qualsevol atacant consultar la configuració completa del dispositiu o fins i tot modificar-la.
🔬 Causa probable
- Configuració de fàbrica no modificada
- Desconeixement del risc de seguretat d’SNMP v1/v2c
- SNMP activat per monitoratge sense hardening posterior
🔍 Com es detecta — Protocols MUST
- Security: snmpwalk -v2c -c public IP_dispositiu → si retorna dades, les credencials per defecte estan actives
- Security: Escaneig amb Nessus detecta SNMP «default community strings»
- Monitoring: Revisar show snmp community en tots els dispositius
✅ Com es resol
- Canviar les community strings per cadenes complexes úniques
- Migrar a SNMPv3 amb autenticació SHA i xifratge AES
- Restringir l’accés SNMP per ACL: snmp-server community XXXXX ro ACL_MGMT
- Desactivar SNMP write si no és necessari
⚡ Alerta primerenca
Auditoria de credencials SNMP en cada incorporació de dispositiu. Usar SNMPv3 per defecte en nous desplegaments. → Protocol Security
I15
QoS Absent per a Serveis Crítics
📋 Descripció
La xarxa no té implementades polítiques de QoS (Quality of Service), de manera que trànsit crític com VoIP o videoconferència competeix en igualtat de condicions amb transferències de fitxers o backups, degradant la qualitat percebuda.
🔬 Causa probable
- QoS mai configurat des del desplegament inicial
- Introducció de VoIP sense revisar la configuració de QoS existent
- Creixement de la xarxa sense actualitzar les polítiques
🔍 Com es detecta — Protocols MUST
- Monitoring: MOS score de VoIP inferior a 4.0; jitter superior a 30ms mesurat amb iperf3 -u
- Topology: show policy-map interface → sense polítiques configurades
- Uptime: Usuaris reporten tallades durant hores d’ús intensiu
✅ Com es resol
- Classificar trànsit: DSCP EF (46) per VoIP, AF41 per vídeo, BE per dades
- Implementar LLQ (Low Latency Queuing) per a VoIP: priority percent 20
- Configurar DSCP end-to-end des del dispositiu endpoint fins al router WAN
- Limitar trànsit bulk (backup, FTP) a horari nocturn o rate-limit
⚡ Alerta primerenca
Monitor de jitter i MOS score en temps real. Revisar polítiques QoS abans de desplegar nous serveis de veu/vídeo. → Protocol Monitoring