Vai al contenuto
Strategia Informatica
  1. Inizio
  2. Competenze
  3. Reti

Reti e sicurezza perimetrale

Gestiamo, quasi sempre a distanza, router, firewall, switch e reti Wi-Fi di aziende industriali, della distribuzione, dei trasporti e dei servizi: collegamenti fra sedi, VPN su più marche, messa a punto dei firewall, diagnosi di dorsali con apparati di produttori diversi, reti temporanee per eventi.

Lavoriamo sugli apparati in esercizio, quindi con prudenza: prima si misura, poi si propone; ogni modifica parte con la sua via di ritorno; alla fine restano runbook, configurazioni salvate e, quando serve, il resoconto di che cosa è andato storto e perché.

Collegamenti fra sedi ed estensioni di rete

Colleghiamo sedi, stabilimenti e datacenter con WireGuard, EoIP e OpenVPN; configuriamo bridge con VLAN, MTU e clamp dell’MSS, policy routing su più linee e ridondanza dei router con VRRP. Quando una rete va estesa a livello 2 fino a un datacenter, lo facciamo sapendo dove stanno le insidie: frammentazione, NAT che scarta le risposte, indirizzi ammessi nei tunnel.

Tecnologie e prodotti

  • MikroTik RouterOS 7
  • WireGuard
  • EoIP e GRE
  • OpenVPN
  • VRRP
  • IEEE 802.1Q

Esempi

  1. Azienda di servizi informatici In esercizio

    Una rete di sede estesa fino al datacenter

    Il problema
    La LAN e due VLAN della sede dovevano arrivare, a livello 2, ai server ospitati in datacenter; la soluzione precedente su L2TP e IPsec non bastava.
    Cosa abbiamo fatto
    Tre tunnel EoIP sopra WireGuard, con una MTU utile di 1378 byte. Due insidie risolte strada facendo: il NAT del firewall di sede scartava le risposte quando la porta WireGuard di origine coincideva con quella di destinazione, e gli indirizzi ammessi nel tunnel dovevano comprendere tutte le reti instradate.
    Risultato
    Estensione in esercizio. L’alta affidabilità automatica fra i due router di sede è stata studiata e, per ora, giudicata non pronta: lo abbiamo scritto, invece di attivarla.
  2. Gruppo della distribuzione In esercizio

    Una sede collegata in 5G con due operatori

    Il problema
    Una sede doveva lavorare su linee 5G in attesa della fibra, senza perdere la gestione remota.
    Cosa abbiamo fatto
    Due router e due linee 5G di operatori diversi: la navigazione esce dalla seconda linea con il policy routing, la prima resta ai tunnel e alla gestione. Uno script a bordo salva un punto di ripristino dopo 30 minuti di funzionamento sano e lo ricarica se gestione e Internet tacciono. La misura di banda ha mostrato che il limite era la CPU del router (97%), non la linea.
    Risultato
    La sede ha lavorato in 5G e oggi il 5G fa da riserva alla fibra; il passaggio fra le due segue una procedura in cinque passi con nove controlli preliminari.

VPN fra sedi, verso il cloud e per il lavoro a distanza

Configuriamo VPN IPsec (IKEv1 e IKEv2, basate su policy o su route) fra apparati di marche diverse e verso i cloud pubblici, concentratori WireGuard e OpenVPN, accesso remoto con autenticazione centralizzata. Progettiamo anche il passaggio al sito di disaster recovery, con il suo collaudo nei due versi.

Tecnologie e prodotti

  • IPsec e NAT-T
  • WireGuard
  • OpenVPN
  • SoftEther
  • FortiClient
  • SAML con Microsoft Entra ID
  • VPN di Oracle Cloud e Google Cloud

Esempi

  1. Azienda di servizi informatici In esercizio

    VPN verso il sito di disaster recovery in cloud

    Il problema
    Il sito di disaster recovery in cloud doveva essere raggiungibile in modo affidabile, e la configurazione non doveva mai mettere a rischio la produzione.
    Cosa abbiamo fatto
    Due tunnel verso i due punti di terminazione del sito DR. Lo script che li configura ha anteprima, verifica, ritorno indietro e un blocco che protegge la produzione.
    Risultato
    VPN collaudata nei due versi su entrambi i tunnel (16-18 ms) e passaggio manuale al DR pronto. Il passaggio automatico, una macchina a tre stati con isteresi, è una proposta; i due tunnel attivi con BGP sono uno studio.
  2. Sede di un'azienda di servizi informatici In esercizio

    Accesso remoto su un firewall senza SSL-VPN

    Il problema
    Su quel modello di firewall la VPN SSL non esiste, ma gli utenti dovevano lavorare da fuori come se fossero in ufficio.
    Cosa abbiamo fatto
    FortiClient su IPsec IKEv2 con EAP: i client prendono un indirizzo della LAN (con proxy ARP) e raggiungono anche le VPN verso le altre sedi senza modifiche dall’altra parte. Dietro un hotspot il traffico di ritorno si perdeva nel NAT: abbiamo forzato il NAT-T.
    Risultato
    Accesso remoto in esercizio; l’accesso con le credenziali aziendali Microsoft Entra ID via SAML è configurato e in prova.
  3. Fornitore di servizi informatici In esercizio

    Un server VPN che esauriva la memoria sei volte al giorno

    Il problema
    Il server VPN usato per i backup di un cliente veniva terminato per memoria esaurita fino a sei volte al giorno.
    Cosa abbiamo fatto
    La causa era un bridge su una scheda di rete spenta, che apriva un socket al secondo: 27.233 socket orfani, circa 7 GB di memoria del kernel. Abbiamo tolto il bridge e aggiunto un controllo automatico.
    Risultato
    Memoria usata scesa dal 95% al 3,7%; un controllo automatico sorveglia il servizio.

Firewall perimetrali e segmentazione

Analizziamo e mettiamo a punto firewall Palo Alto, FortiGate e Check Point e i filtri di MikroTik e Linux: zone, regole, NAT, profili di prevenzione delle intrusioni. Per i Palo Alto abbiamo strumenti nostri che, attraverso le API, dicono quale regola colpisce un flusso, quali regole consentono un certo traffico e che cosa è pubblicato su Internet.

Segmentiamo le reti per ridurre i danni possibili: Wi-Fi ospiti su una VLAN propria con i client isolati fra loro, server datati pubblicati solo verso poche sorgenti (e la restrizione provata da un indirizzo non ammesso), telecamere su una rete a parte.

Tecnologie e prodotti

  • Palo Alto PAN-OS e Strata Cloud Manager
  • FortiGate (FortiOS)
  • Check Point Gaia
  • WatchGuard Fireware
  • Firewall di RouterOS
  • iptables e nftables

Esempi

  1. Gruppo industriale In esercizio

    Una firma IPS che isolava un server ogni ora

    Il problema
    Un server perdeva il dominio a cadenza regolare, senza tracce evidenti nei log di traffico del firewall.
    Cosa abbiamo fatto
    Una firma di prevenzione delle intrusioni scattava sul traffico ONVIF verso due telecamere e la sua azione di blocco scartava tutto il traffico del server, 3.700 pacchetti al secondo; il blocco si rinnovava a ogni scadenza. Abbiamo creato l’eccezione attraverso le API del gestore in cloud.
    Risultato
    Server stabile. Ora un controllo automatico legge ogni 3 minuti le tabelle dei blocchi di cinque cluster di firewall e avvisa con un pulsante di sblocco.
  2. Gruppo industriale con firewall gestiti dal cloud Consegnato

    Regole che sembravano bloccare e non bloccavano

    Il problema
    Le regole distribuite dal gestore in cloud non si leggono nella configurazione locale, e la prova di corrispondenza delle policy restituiva sempre la stessa regola.
    Cosa abbiamo fatto
    Abbiamo usato come riferimento i log e le sessioni, che non mentono, e fatto l’inventario delle pubblicazioni su Internet. Così è emerso che il blocco degli indirizzi malevoli era inefficace: una regola di permesso lo precedeva di 355 posizioni.
    Risultato
    Il blocco è stato spostato prima del permesso; inventario delle pubblicazioni consegnato.

Progetto e messa in servizio di reti di sede

Progettiamo la rete di una sede (firewall, switch, Wi-Fi, VPN), la prepariamo accanto a quella esistente e facciamo il passaggio in una finestra concordata, con runbook e ritorno indietro pronto. Alla fine uno script controlla l’impianto punto per punto.

Tecnologie e prodotti

  • FortiGate in alta affidabilità (FGCP)
  • Aruba CX (AOS-CX)
  • UniFi
  • VPN di Google Cloud
  • rsyslog

Esempi

  1. Sede di un'azienda di servizi informatici In esercizio

    La rete nuova di una sede, passata in una giornata

    Il problema
    Sostituire firewall, switch e Wi-Fi di una sede in esercizio, insieme alle VPN verso il cloud e verso le altre sedi.
    Cosa abbiamo fatto
    Cluster FortiGate attivo-passivo, due switch Aruba CX, controller UniFi e tre access point, preparati accanto alla rete esistente. Poi cinque VPN fra sedi (tre basate su route verso Google Cloud, due verso Check Point), l’accesso remoto e la Wi-Fi aziendale e ospiti.
    Risultato
    Passaggio in una giornata, alta affidabilità provata, ritorno indietro non necessario. Il giorno dopo lo script di controllo dava 38 verifiche positive su 38; i contatori hanno fatto emergere una porta guasta, che ogni volta che risaliva provocava un ricalcolo dello spanning tree, ed è stata spenta.
  2. Gruppo della distribuzione In esercizio

    Il nodo di distribuzione di una sede logistica

    Il problema
    Il nodo di distribuzione della rete di sede era instabile e l’uplink passava da un modulo ottico difettoso.
    Cosa abbiamo fatto
    Nuovo switch Aruba come radice MSTP, uplink spostato dal modulo difettoso, un server syslog e un cruscotto di disponibilità per 22 apparati.
    Risultato
    Rete di sede stabile e osservabile; lo studio dello spanning tree è applicato in parte.

Switching, dorsali e spanning tree

Leggiamo e correggiamo dorsali HPE e Aruba, Dell, Cisco e MikroTik: aggregazioni LACP, MLAG nelle sue varianti (VSF, distributed trunking, VLT), STP, RSTP e MSTP, VLAN per tratta. Gli anelli intermittenti, quelli che compaiono e spariscono, li cerchiamo con misure ripetute e strumenti scritti apposta.

Tecnologie e prodotti

  • HPE ArubaOS-Switch
  • Dell OS10 (VLT)
  • Aruba CX
  • Cisco Catalyst
  • MikroTik CRS e SwOS
  • LLDP e CDP
  • IEEE 802.1D, 802.1w, 802.1s, 802.3ad

Esempi

  1. Gruppo industriale con più campus In corso

    Un anello intermittente fra due tecnologie di aggregazione

    Il problema
    Alcuni server perdevano traffico a tratti, senza un guasto evidente, su una dorsale di otto apparati di due produttori distribuiti su tre campus.
    Cosa abbiamo fatto
    Abbiamo scritto un rilevatore che parte da un principio semplice: i due membri di una coppia VLT non possono essere in disaccordo su dove si trova un indirizzo MAC. Ha individuato i server colpiti, e lo studio delle configurazioni ha localizzato il ciclo nel punto in cui si incontrano due tecnologie MLAG diverse, su un collegamento con lo spanning tree filtrato.
    Dove siamo arrivati
    Tolte 28 VLAN da un collegamento (CPU di un core dal 27% al 12%), riattivato un secondo link senza spostamenti su 578 MAC, ridotti gli spostamenti di MAC da 12 a 2 al minuto e azzerate le incoerenze VLT con un intervento provvisorio. La soluzione strutturale è studiata, con i vincoli dell’hardware verificati.
  2. Sito produttivo In esercizio

    Ridondanza dei router di un sito produttivo

    Il problema
    La coppia di router del sito non garantiva un subentro pulito: le BPDU non si scambiavano perché la VLAN 1 era senza tag da un lato e con tag dall’altro.
    Cosa abbiamo fatto
    Ridondanza rifatta con VRRP e un controllo automatico contro gli anelli.
    Risultato
    Subentro misurato: circa 5 secondi per un guasto del router, 10 per un cavo WAN staccato, rientro senza sovrapposizioni.

Flotte di apparati, hardening e automazione

Teniamo un inventario unico degli apparati di rete e lo interroghiamo con strumenti nostri (SSH, API di RouterOS, API REST di FortiOS, API XML di PAN-OS): versioni, esposizione, regole di gestione applicate con ripristino automatico a bordo, ricerca di indicatori di compromissione, backup completi prima e dopo ogni modifica.

Tecnologie e prodotti

  • Python (paramiko, routeros_api)
  • API di RouterOS
  • API REST di FortiOS
  • API XML di PAN-OS
  • Checkpoint di AOS-CX

Esempi

  1. Flotta MikroTik di più clienti In esercizio

    Gestione chiusa su 26 router dopo un avviso di sicurezza

    Il problema
    Un avviso del CERT segnalava vulnerabilità di RouterOS sfruttate attraverso SSH. Bisognava sapere subito quali apparati erano esposti e chiudere, senza perdere l’accesso a nessuno.
    Cosa abbiamo fatto
    Inventario di 67 apparati di 11 progetti con un semaforo basato sull’esposizione alle vulnerabilità note, non sui numeri di versione. Su 26 apparati abbiamo ristretto l’accesso di gestione agli indirizzi ammessi e spento i servizi inutili, con anteprima obbligatoria, uno scheduler a bordo che ripristina tutto in 10 minuti se la modifica non viene confermata, e una verifica con una connessione nuova.
    Risultato
    Risultato misurato: nessun apparato con SSH esposto. Il piano di aggiornamento in sei ondate è scritto e in corso.
  2. Infrastruttura di rete di servizi Consegnato

    Verifica di compromissione su un concentratore VPN

    Il problema
    Escludere con certezza che un concentratore VPN fosse stato manomesso.
    Cosa abbiamo fatto
    Controllo completo di utenti, chiavi, attività pianificate, script, tunnel, firewall, rotte, DNS, proxy, certificati e storico delle modifiche.
    Risultato
    Nessun impianto trovato, con l’elenco puntuale di che cosa è stato verificato.

Wi-Fi aziendale e di magazzino

Ricostruiamo l’architettura reale di una rete Wi-Fi (chi fa da gateway, chi dà gli indirizzi, dove va l’autenticazione), correggiamo roaming e parametri radio e analizziamo i client che si comportano male partendo dai dati del controller, non dalle impressioni.

Tecnologie e prodotti

  • UniFi
  • Alcatel-Lucent OmniVista Cirrus
  • Cisco WLC
  • IEEE 802.11k, 802.11r, 802.11v
  • 802.1X e RADIUS

Esempi

  1. Gruppo industriale con più sedi In esercizio

    Roaming corretto su oltre cento access point

    Il problema
    Roaming lento e terminali «connessi ma senza indirizzo» in più sedi.
    Cosa abbiamo fatto
    Abbiamo documentato che il controller lavora solo a livello 2, mentre gateway e relay DHCP stanno sul firewall e l’autenticazione 802.1X va ai server RADIUS. Le correzioni (802.11r su 20 SSID, assistente di roaming, DTIM, velocità minima) sono state applicate con uno script e verificate con 57 controlli automatici (56 superati), con un ritorno indietro mirato su tre SSID.
    Risultato
    Roaming corretto. Sui terminali senza indirizzo abbiamo anche corretto per iscritto la nostra prima ipotesi: a sbloccarli è stato il riavvio degli access point, non la disattivazione di 802.11r.
  2. Distribuzione con più sedi logistiche Studio

    Terminali di magazzino che cambiavano access point cinque volte l'ora

    Il problema
    I terminali di magazzino più vecchi perdevano la connessione durante il lavoro.
    Cosa abbiamo fatto
    Dai dati del controller: sullo SSID con 802.11r quei terminali facevano 4,8 roaming e 3,8 disconnessioni all’ora, contro 0 e 0,2 sullo SSID senza. Le cause sono più d’una: soglia per i client «appiccicosi» disattivata, driver datato, assenza di 802.11k e v, problemi noti della combinazione FT-PSK.
    Dove siamo arrivati
    Raccomandazioni consegnate in ordine di priorità.

Reti per eventi

Mettiamo in servizio reti temporanee e le seguiamo per tutta la durata dell’evento: gateway ridondati, più linee Internet, VLAN per area con limiti di banda, Wi-Fi ad alta densità con un piano dei canali che rispetta i vincoli italiani, apparati preparati al banco e gestiti da remoto.

Tecnologie e prodotti

  • Pacemaker e Corosync
  • Policy routing su Linux, iptables, tc
  • ISC DHCP
  • MikroTik, Cisco Catalyst, UniFi
  • SNMP e ONVIF

Esempi

  1. Grande evento culturale internazionale Consegnato

    La rete di un grande evento, dal banco alla chiusura

    Il problema
    Una rete temporanea con molte aree, ospiti e produzioni diverse, che doveva reggere per tutto l’evento ed essere governabile da remoto.
    Cosa abbiamo fatto
    Gateway e DHCP su un cluster Linux in alta affidabilità, portato da due a quattro nodi senza fermo; due linee Internet con policy routing per VLAN; 16 VLAN, alcune con limite di banda. Sette router agganciati alla VPN di gestione: alcune unità clonate avevano lo stesso MAC di bridge e portavano la perdita di pacchetti fino al 100%. Undici access point con il piano dei canali costruito sui vincoli italiani (canali DFS, zone dei radar meteorologici). Un pannello web per spostare una VLAN da una linea all’altra, collaudato con 10 prove che hanno fatto emergere tre difetti, tutti corretti.
    Risultato
    Rete in servizio per l’intero evento, con monitoraggio ridondato: rientro automatico misurato in circa 18 secondi.
  2. Grande evento culturale internazionale Consegnato

    Access point preparati al banco

    Il problema
    Preparare in poco tempo access point nuovi, con firmware, nomi e indirizzi corretti.
    Cosa abbiamo fatto
    Banco con il controller su un portatile e gli access point collegati uno alla volta in PoE; uno script PowerShell li adotta, aggiorna il firmware, li rinomina, assegna l’indirizzo e imposta via SSH l’indirizzo del controller.
    Risultato
    Circa 5 minuti per access point, 8 preparati in una giornata, con le trappole documentate per la volta successiva.

Pubblicazione sicura di servizi web

Pubblichiamo applicazioni dietro reverse proxy esponendo il minimo, gestiamo certificati e DNS, limitiamo l’ingresso alle porte necessarie. Il principio è non sembrare niente: nessuna versione nelle intestazioni, errori generici, chiusura silenziosa verso chi non conosce il nome del sito.

Tecnologie e prodotti

  • nginx e Nginx Proxy Manager
  • Let's Encrypt
  • fail2ban
  • nftables
  • Cloudflare
  • Controllo su liste nere DNS

Esempi

  1. Fornitore di servizi web In esercizio

    Un'applicazione web esposta solo dove serve

    Il problema
    Un’applicazione raggiungibile da Internet riceveva traffico di scanner e tentativi di accesso.
    Cosa abbiamo fatto
    nginx inoltra due soli percorsi e chiude tutto il resto senza rispondere; accesso consentito a un elenco di sorgenti, limite di 10 richieste al secondo per indirizzo, 21 scanner riconosciuti e respinti, quattro regole fail2ban corrette perché non leggevano i log.
    Risultato
    Superficie ridotta a due percorsi. Quando un aggiornamento automatico ha mandato in crash un modulo di terze parti, l’abbiamo individuato dal log del kernel e disattivato.
  2. Gruppo della distribuzione In esercizio

    Outlook che faceva bloccare l'ufficio dal sito vetrina

    Il problema
    L’indirizzo Internet della sede finiva nella lista nera del servizio di hosting del sito aziendale.
    Cosa abbiamo fatto
    Abbiamo scoperto che Outlook interrogava il servizio autodiscover sul sito vetrina 378 volte al giorno, e il filtro anti-bot dell’hosting lo scambiava per un attacco. Una regola Cloudflare risponde a quelle richieste prima che arrivino al sito, verificata su 16 varianti.
    Risultato
    Le richieste di Outlook non arrivano più al sito e la sede non finisce più in lista nera.

Diagnosi e misura del traffico

Separiamo le cause con prove che escludono, contatori e log degli apparati. Se la raccolta dei flussi non c’è, la impiantiamo.

Tecnologie e prodotti

  • ntopng e nprobe
  • NetFlow v9
  • ClickHouse
  • SNMP
  • tcpdump e sniffer di RouterOS

Esempi

  1. Azienda con videosorveglianza su più sedi Consegnato

    Eventi di videosorveglianza che non arrivavano alla centrale

    Il problema
    Gli eventi delle telecamere non arrivavano alla centrale, eppure i collegamenti fra i server funzionavano tutti.
    Cosa abbiamo fatto
    I log del firewall hanno mostrato che il canale degli eventi viaggiava in UDP verso indirizzi APIPA, annunciati dal software delle schede USB di gestione dei server. Abbiamo disattivato quelle schede e riavviato il servizio solo dove serviva.
    Risultato
    Eventi di nuovo regolari, senza toccare il resto dell’impianto.
  2. Sede di un'azienda di servizi In corso

    PC che non si aggiornavano, per tre cause sovrapposte

    Il problema
    Gli aggiornamenti di Windows fallivano su molti PC della sede.
    Cosa abbiamo fatto
    Le cause erano tre. Due sono state risolte sui PC; la terza è stata localizzata con TTL e tempi di risposta in un proxy trasparente dell’operatore, dopo aver scagionato router e firewall con i loro contatori.
    Dove siamo arrivati
    Due cause risolte, la terza documentata e in mano all’operatore.
  3. Fornitore di servizi cloud In esercizio

    Raccolta dei flussi di rete per un fornitore cloud

    Il problema
    Mancava una visione di chi parla con chi e quanto.
    Cosa abbiamo fatto
    nprobe come collettore NetFlow v9 verso ntopng, con archivio su ClickHouse; definite le reti locali.
    Risultato
    Host riconosciuti come locali passati da 0 a 82, nessun flusso perso.

Raccontateci il problema

Una rete da rimettere in ordine, un incidente da gestire, dati da far parlare: la prima conversazione serve a capire se e come possiamo essere utili.