Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.
Visualizzazione post con etichetta Networking. Mostra tutti i post
Visualizzazione post con etichetta Networking. Mostra tutti i post

mercoledì 17 maggio 2023

Tempi di attivazione di un collegamento LAN su switch (STP, POE, DHCP, Negoziazione)

Un cliente oggi mi ha domandato il motivo per cui, da quando si collega un client ad uno switch mediante una patch LAN a quando lo stesso diviene in grado di comunicare con il resto della rete, passa del tempo.

 

Molto brevemente proviamo a capire insieme cosa accade:

1. In una fase iniziale lo switch (se POE) cerca di capire se il device è abilitato o meno a ricevere energia elettrica secondo gli standard 802.3af (low energy) o 802.3at(high energy o POE+). Senza entrare nel dettaglio tecnico ampiamente documentato, questa fase richiede del tempo ed è possibile vedere la porta, inizialmente accesa per un attimo, spegnersi e quindi riaccendersi definitivamente. [POE +5 secondi circa]

 

2. Nella fase successiva (o se non abbiamo uno switch POE salteremo direttamente qui), avviene la negoziazione della velocità e del duplex (tipicamente oggi 1Gbit in modalità Full Duplex, ovvero bidirezionale). Gli apparati (switch e device) cercheranno di negoziare la velocità migliore possibile. [AutoNegoziazione +4 secondi circa]


3. Se abbiamo abilitato lo Spanning Tree (tipicamente RSTP), lo switch metterà inizialmente la porta in blocking per evitare loop, dopodichè porterà la porta in listening, learning e infine in forwarding. Durante questi passaggi lo switch ascolta cosa sta accadendo sulla rete e attende di leggere eventuali BPDU per stabilire tutti i percorsi verso il suo root bridge. Non entro in ulteriore dettaglio del protocollo STP, ma questo tempo è utile allo switch per accertarsi che non vi siano broadcast storm (loop) causati da percorsi ridondati e attivi simultaneamente. [Spanning Tree +32 secondi circa]

 

4.  Finalmente siamo pronti a comunicare, ma se il nostro device ottiene l'indirizzo IP non manualmente ma in DHCP, dovremo attendere sia il meccanismo di DHCP Request/Relay sia l'assegnazione dell'IP all'interfaccia di rete (qui dipende molto anche dalla capacità computazionale del device). [DHCP +3 secondi]

 


Conviene disabilitare qualcosa pur di velocizzare l'accesso? Salvo non ci siano esigenze particolari,  certamente no. Parliamo di collegamenti LAN, perlopiù statici. Difficilmente si cambia porta LAN così di frequente da notare un rallentamento in queste operazioni. Anche all'atto dell'accensione di una postazione di lavoro, calcolando che la LAN rimane spesso attiva per il WakeOnLan (ma anche presupponendo una postazione elettricamente spenta), fin quando il sistema operativo viene caricato e l'utente accede alla propria macchina, certamente la LAN sarà più che pronta.

Ovviamente questi dati sono stati presi su uno switch, ma tipicamente questo tipo di comportamento varia da produttore a produttore. Ci sono produttori (soprattutto nello spanning tree) "più conservativi" che preferiscono attendere un tempo maggiore prima di dichiarare la porta "esente da percorsi ridondati", altri che attendono di meno.

 


Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

lunedì 5 settembre 2022

CyberSecurity Creativa

Carissimi,

questo post non è propriamente un manuale o una guida su un argomento specifico, piuttosto si tratta di un annuncio.  

Con grande piacere annuncio l'uscita del mio primo libro: CyberSecurity Creativa, reperibile >>>qui<<< sia in formato kindle, sia in formato cartaceo con copertina flessibile.

 

 


 

In questo libro ho voluto raccontare 20 anni di mestiere con aneddoti, orrori trovati e soluzioni creative. Vi rimando alla descrizione del volume:

 

In un mondo che evolve così rapidamente, dove gli attaccanti sono libellule e le nostre aziende degli elefanti, l’insieme degli approcci rende più resistente un’infrastruttura informatica. Proprio come accade nella protezione di una proprietà fisica, l’insieme di tecnologie concorre a rendere meno violabile casa propria. Ma poi il guizzo, l’idea fuori dagli schemi, la TV lasciata banalmente accesa, la temporizzazione delle luci nelle stanze... ci evita infine il furto. Ebbene, in questo libro non vi parlerò di firewall o di endpoint (non perlomeno in maniera convenzionale), questo voi amministratori di sistema dovreste già trattarlo. Io vi parlerò della TV lasciata accesa, dell’esca da lasciare all’attaccante per identificarlo anche quando sfuggito agli strumenti tradizionali, delle sonde invisibili, dei backup totalmente isolati dalla rete, di anonimizzazione del perimetro cosicchè il ladro non sappia nemmeno a chi citofonare per venirvi a far visita. E lo farò descrivendovi sia le tecniche architetturali utilizzate, sia gli errori potenzialmente fatali incontrati in 20 anni di mestiere tra aziende di produzione, ospedali, Comuni, Cloud Provider e realtà più o meno complesse. 
 
Di seguito, invece, è possibile trovare l'elenco breve degli argomenti trattati:

 

Capitolo 1 – Lo switch è tuo amico!

Cosa sono e come si utilizzano le VLAN 802.1q?

Tag, Untag, Trunk e Uplink e Private VLAN

Le vlan sul wireless (come suddividere correttamente le reti)

La compartimentazione e la DMZ

Chi deve fare routing?

Forwarding abusivi

SNMP: suvvia... Ma c’è qualcuno che se ne preoccupa?

Non buttate quegli hub! L’antenato del mirroring

Spanning Tree manipulation attack (e un caso concreto)

Port Security, MAC LockOUT e learning

DHCP Snooping: evitare il rilascio non autorizzato di IP

 

Capitolo 2 – Backup: invalidarli è un attimo

L’inutilità del backup leggibile dal server

Isolare il repository

FileSystem con snapshot e NAS duplicati

Il backup in cloud “corretto” (ed un caso concreto di rischio sfiorato)

Le Tape Library ed un caso concreto: quando la lentezza salva

Sottrazione di credenziali

I dati sono al sicuro in caso di furto fisico?

Procedure d’emergenza

Il plico cartaceo d’emergenza

Modalità “Riccio”

La routine di verifica

Non solo attacchi: sicurezza della sala CED (5 casi realmente accaduti)

Fatti qualche domanda (prontuario di valutazione dei backup)

 

Capitolo 3 – Anonimizzazione del perimetro e

Il ruolo del cloud provider ed il transito del routing

Esempi concreti di failover geografici applicabili da chiunque

Anonimizzazione: come posso evitare di dare informazioni tramite i miei DNS?

SPF e autodiscovery

Il peering

API ed esempio di automatismo su fail

 

Capitolo 4 – Honeypot: server esca volontariamente vulnerabili

Come funziona un Honeypot?

Installiamo l’Honeypot ed esponiamolo al mondo

Tuning del sistema

Capiamo come funziona il sistema

Esempio di un attaccante realmente scovato

HoneyPot vs Deception Technology (Tecnologia dell’Inganno)

Le prime 2 ore di un server pubblico... un po' di statistiche per farci riflettere

Analisi sull’andamento degli attacchi

 

Capitolo 5 – Server Pubblici: un lavoro ingrato

Linux? Windows?

Liste reputazionali

ipset, iptables e nftables

Blocchiamo nativamente la rete TOR o una qualsiasi lista di IP

Analizziamo i log di apache

Rilevare il cambio di MD5 su file di sistema

Lavorare sugli attributi estesi per rendere immutabile un WebServer

Estendiamo le potenzialità dell’antivirus con DB supplementari

Fail2ban

Autenticazione a due fattori

Port Knocking

Tunnel SSH: questi pericolosissimi sconosciuti

Archiviare i dati non più utili: un famoso caso italiano

 

Capitolo 6 – Un po’ di monitoring non fa mai male

L’importanza del monitoraggio attivo

Zabbix, Nagios e dintorni

MDR, EDR, XDR

Query SNMP

Gli Host Intrusion Detection System (HIDS)

OSSEC

WAZUH

Sonde silenti: gli IDS

Cos’è SecurityOnion?

SQUERT

Scovare le credenziali in chiaro

CyberChef

Inviare allarmi

Uno splendido progetto emergente UptK

 

Capitolo 7 – System Integrator e procedure

È sempre colpa del Cliente?

Gioco mio, regole mie

Utilizziamo il GDPR per dar peso a pratiche corrette

Protocolli di sicurezza interni

Gestione delle Password da parte del personale tecnico

Custodia delle informazioni sensibili dei Clienti

Apparati di sicurezza

Server contenenti dati sensibili dei Clienti

Postazioni di lavoro dedicate all’assistenza

Locali tecnici e di lavoro

Sistemi di Backup

Azioni irreversibili

Le console centralizzate: comodità e pericoli

Sistemi di teleassistenza

Controller di Dominio

Livelli di trust nelle postazioni di lavoro ed architetture

SandBoxing

SandBox nel concreto: becchiamoci volontariamente un ransomware

Qualche caso eclatante

giovedì 23 dicembre 2021

Performance: differenze tra iptables e nftables

Recentemente, grazie al progetto honeypot (discusso nell'articolo precedente) stiamo maneggiando una mole importanti di indirizzi IP da blacklistare. Con l'aumentare del numero, degradano drammaticamente le performance.

Condivido con i più esperti questo raffronto che ho realizzato oggi:

 


Throughput senza alcuna regola di firewalling:

 su questa macchina:



Il microserver ha 4 interfacce in bridge, il test è dall'host A all'host B con di mezzo il microserver. Quindi è stato abilitato ovviamente a livello di kernel:

echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo "br_netfilter" >> /etc/modules



iptables

Caricamento entry 

Ogni ip viene blacklistato in ingresso ed in uscita, con il logging. Pertanto ogni entry è da moltiplicare x4:



Le operazioni di caricamento sono durate davvero troppo e ci siamo fermati a circa 12000 ip blacklistati.

Le performance sono purtroppo drammaticamente distanti rispetto ad nftables, ma va detto che abbiamo abilitato il LOG sulle regole che, di fatto, raddoppiano con iptables le policy. 

12.000 ip blacklistati (x4, quindi effettivi 61858 policy) sono stati caricati in 11.000 secondi circa.

 

Throughput

 

Con circa 62k policy (per ogni ip c'è la policy di log in ingresso, log in uscita e blocco in ingresso ed in uscita) iptables crolla drammaticamente da 950Mbit a circa 5Mbit.


Senza log e policy solo in ingresso (-s)

Proviamo quindi ad alleggerire e carichiamo 41670 ip blacklistati in ingresso solamente, senza regole di log:

41670 policy effettive caricate in



Ancora non ci siamo.

 


nftables

Caricamento entry

Ogni ip viene blacklistato in ingresso ed in uscita, con il logging. Pertanto ogni entry è da moltiplicare x2 in quanto il logging è incluso nella policy:

35.535 ip blacklistati (x2) sono stati caricati in 460.1 secondi.

 

Throughput



IPSet

Per risolvere i problemi di performance, ipset è un tool che interagisce a livello kernel e si occupa di strutturare meglio (anche grazie a meccanismi avanzati di cache) le migliaia di policy.
 
Ecco i risultati:

 
 
 
 

Chiaramente si evince come al superamento delle 1000 policy sia assolutamente più conveniente utilizzare ipset, su tutta la linea.


Integro con questa interessante tesi di laurea che ho trovato online effettuando ricerche in merito: http://www.diva-portal.org/smash/get/diva2:1212650/FULLTEXT01.pdf



Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.