Gestione rete e nodi E.P.

Necessita’ fondamentali Identificazione nodi utente Protezione del nodo Identificazione dell’amministratore / responsabile Protezione dei servizi comuni Richiede maggiore attenzione Protezione dei nodi utente Separazione dei servizi di passaggio verso la WAN Rete per ospiti (INFN-Web, eduroam)

Protezione della rete Come ottenere una protezione ottimale della rete? Protezione da Accessi non autorizzati ed attacchi da WAN Comunicazione verso l’interno solo attraverso nodi controllati (bastion host) Accessi non autorizzati ed attacchi da LAN Presuppone la conoscenza di nodi connessi e relativi responsabili Segmentazione della rete per limitare il traffico broadcast e filtrare accessi tra sottoreti Separazione dei nodi per tipo di traffico ed eventualmente servizi offerti Protezione dei servizi comuni Servizi su VLAN specifica Nodi raggiungibili solo sulle porte dedicate al servizio offerto Separazione da tutti gli accessi degli utenti

ACL Metodo di protezione principale: ACL Due tipi di ACL Protezione dalla WAN ACL sul router Protezione dalla LAN ACL sul centro stella

Criteri Segmentazione della rete Tipologia di nodi Funzionalita’ separate devono poter essere associate a VLAN separate Criteri legati all’accesso (ACL tra le VLAN) Tipologia di nodi Nodi utente/gruppo Farm di calcolo Nodi di servizio (servizi di rete) Nodi di accesso (bastion host) Nodi ospiti Nodi “critici” Amministrazione Servizi interni Stampanti pubbliche Stampanti private Apparati di rete NAS e dischi condivisi Sistemi obsoleti / nodi di laboratorio

Esempio: Wi-fi Non raggiungibili dall’esterno Con filtri da/verso la LAN Eduroam Si fornisce solo passaggio INFN-Web INFN-dot1x Per utenti locali o INFN Accesso ai nodi locali Accesso alle risorse

Esperienza attuale Filtro sul router Problemi rilevati Pacchetti in entrata solo per connessioni established Problemi rilevati Traceroute E’ necessario che funzioni? Vidyo Funziona solo attraverso il proxy Perdita di performance ~10% Test con meeting CMS – non sembra un problema Team Speak AFS ?

Protezione servizi Le iptables non sono sufficienti Al momento non sono puntuali “Chiudono” servizi invece di “aprire” le porte necessarie Metodo ACL su 6509 Iptables mantenute in modo sistematico per proteggere I nodi singoli da eventuali problemi nella VLAN Vantaggi: Permette filtri tra sottoreti Banco di prova per riscrittura ACL su router Tabella delle verita’ Quali porte devono essere accessibili Da dove devono essere accessibili Chi deve accedere e come Mantenuta su wiki Accesso per i membri del SICR VPN dedicata

Nodi membri del SICR (1) Allo stesso tempo Richiesta Nodi utente Porte aperte necessarie per applicazioni (esempio videoconferenza) Nodi di servizio Semplice accesso alla rete dei servizi Richiesta Accesso semplice alla gestione dei servizi Garanzia delle funzionalita’ utente Mantenimento della protezione della rete dei servizi

Nodi membri del SICR (2) Separazione delle reti SICR e servizi Opzioni Sottorete dedicata per I nodi dei membri del servizio (e stampanti) Nodi sulle VLAN utente VPN “selettivo” sulla rete 26 (split tunnel) Pacchetti scambiati con la rete dei servizi tramite VPN Verso tutte le altre reti nodo utente

GARR mailbox dns1 login vpn R www 6509 stampanti

Tavola della verita’ L’applicazione della ACL deve essere verificata e quindi monitorata puntualmente, per evitare disagi all’utenza Riempimento tabella servizi ed accessi necessari (AS, CB) Analisi delle performance del 6509 che svolgera’ un ruolo diverso rispetto all’attuale: il controllo dei pacchetti richiedera’ un maggior uso della CPU

Come procedere (1) Classificazione nodi “di servizio” ? In generale questi devono esporre solo il servizio Porte ed i protocolli necessari Verso la rete 26 Ssh (tutti) http (ove necessario) Verso la LAN Esempio: wikisicr – ma e’ necessario aprila alla lan ? Verso la WAN (c’e’ una differenza rispetto al punto precedente) ? Esempio: il DNS espone la porta 53

Come procedere (2) Separazione nodi SICR Divisione della 11 64 per i nodi accesso utente 64 vuoti 128 per la VLAN dei membri del SICR con accesso all’ssh sulla 26 Preparazione VPN dedicata + ssh Bastion host per i nodi dei servizi Test split tunnel Migrazione sulla sottorete 11

Come procedere (3) Preparazione e test ACL Nodo per nodo: Definizione porte e protocolli da esporre Test con implementazione come regole firewall Inserimento in tabella Scrittura ACL ed implementazione sul centro stella

Nodi di accesso (bastion hosts) Rete dedicata all’accesso degli utenti dal mondo esterno Separata dai nodi utente e dai servizi 141.108.11.x Protocolli utilizzati: SSH VPN Macchine virtuali ridondate Cluster oVirt dedicato 3 macchine virtuali per servizio su 3 macchine fisiche Anche per queste reti tabella analoga Quali servizi devono essere resi disponibili tramite questi nodi?

Servizi “locali” Reti con numerazione privata per Stampanti Access point Apparati di rete (switch) NAS e dischi condivisi ?? Macchine di laboratorio obsolete WinXP Oscilloscopi con Win 2000 In alcuni casi e’ semplice definire gli accessi necessari In altri meno…

VLAN per gli “ospiti” Eduroam/INFN-Web Dedicate agli ospiti Possono ospitare nodi non conosciuti Devono quindi essere separate dal resto della LAN Merita ulteriore discussione Doppie ACL ? Connessione fisica con indirizzamento verso il router? GARR R 6509

Nodi utente In generale non offrono servizi O non dovrebbero offrirne Esempio contrario: siti web personali o di gruppo Da scoraggiare e se possibile eliminare Spostamento su DMZ con regole speciali Per proteggere i nodi utente e gli altri Necessaria riscrittura regole ACL Da zero con criteri opposti alle attuali Dovrebbe comportare semplificazione Criteri simili alla 26 Survey per sottorete Tramite scan dei nodi e “interrogazione” Nodo per nodo per capire le necessita’ Scopo finale: costruzione tabella

Identificazione dei nodi Nodi identificati da ip Corrispondono ad un responsabile Come assicurare che il nodo sia veramente quello dichiarato ? Verificare corrispondenza mac/ip Strumenti di monitor attuali Cacti permette di navigare attraverso I mac e gli ip con vari filtri Arpwatch segnala cambi di mac address Script di check sugli ip “rubati” Al momento non c’e’ forzatura della regola

Problemi attuali Ip rubati Nodi vaganti Flip-flop Responsabili scaduti Dinamici Caso meno frequente (?) Statici Errori di configurazione IP non autorizzati presi “per pigrizia” o perche’ non si ha diritto Nodi vaganti Esempio tipico: esercitazioni Flip-flop Responsabili scaduti Relazione con gestione utenze e responsabili nodi

Come risolvere il problema Gli switch HP supportano l’autenticazione tramite radius Possibile usare Credenziali utente MAC address come credenziali Assicura l’identificazione del nodo e quindi del responsabile Assicura la corretta classificazione del nodo Piu’ pratico per nodi fissi Evita lo scambio di password (magari…) La porta switch si “apre” solo se l’utente e’ autenticato Da studiare DHCP con indirizzi fissi per tutte le VLAN DHCP “dinamico” per l’attuale DHCP

DHCP Al momento Se un utente prende un indirizzo 141.108.13.x su porta DHCP si connette Qualsiasi sia la macchina Con Radius la porta e’ protetta (solo un MAC autorizzato passa) ma: Cosa succede se c’e’ un DHCP non autorizzato sulla VLAN ? Soluzione: DHCP snooping Le richieste DHCP vengono girate dallo switch direttamente al server autorizzato Per rivedere le ACL sul DHCP Survey sui nodi autorizzati

Mobilita’ utenti con IP fisso Il metodo “DHCP con autenticazione” Permette la mobilita’ degli utenti ma: Suppone cablaggio a capienza! Altrimenti si rischia il caos nella richiesta attivazioni E comunque non ci guadagnamo nulla Protezione iniziale Porte con MAC address bloccato Preparazione moduli per richiesta spostamento nodi Eventualmente automatico quando il sistema diventa DHCP Preparazione piano per cablaggio a capienza Attenzione: necessario seguire da vcino tutti i lavori !!!

Attenzione Tutti I nodi sono spostabili ? Esempio: nodi di laboratori studenti

Come procedere Sperimentazione con switch Applicazione alla rete DHCP Radius ed autenticazione DHCP snooping Applicazione alla rete DHCP Verifica protezione Studio passaggio a DHCP con indirizzi fissi per VLAN utente