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.

martedì 24 agosto 2021

Le botti di ferro non esistono... Qualche riflessione sui ransomware recenti e gli attacchi mirati su Regione Lazio

Cosa sta accadendo nel mondo dei ransomware?

Andiamo con ordine, proviamo a dare un rapido sguardo a cosa accaduto a Regione Lazio.

Un gruppo di criminali ha attaccato il sistema sanitario di Regione Lazio attraverso l'infezione di una macchina di un tecnico che, quindi, aveva privilegi elevati. L'attacco ha messo fuori uso tutti i sistemi di backup, inclusa la tape library (almeno, da quanto ci è dato sapere).

La Tape Library è, per chi non lo sapesse, un sistema a cassette (tape) che vengono ciclate da un sistema meccanizzato all'interno di un "mangianastro" con lo scopo di mantenere delle copie di backup. I sistemisti affezionati al sistema lo richiedono ancora, seppur via via sempre con meno fermezza, considerandolo un sistema più sicuro dei NAS normalmente utilizzati allo scopo. Software come veeam backup si poggiano sui driver della tape e ne utilizzano le funzionalità per stoccare tipicamente copie di backup precedentemente effettuati sui NAS. Tecnicamente si tratta di un backup del backup, ma poco cambia. Oggi è utile? Non lo è? Personalmente non amo particolarmente questo strumento in quanto estremamente lento e costoso, ma andiamo con ordine.


Come molti sanno, un dato cancellato non lo è realmente fin quando quello spazio non viene sovrascritto (volontariamente o involontariamente) da altri dati. E' evidente, chi attacca un sistema, si assicura che i backup non vengano solo eliminati/crittografati, ma anche sovrascritti così da risultare effettivamente irrecuperabili. Questo è ovviamente accaduto su ogni fronte, tuttavia la Tape Library è un elefante lento e macchinoso, sovrascrivere tutto potrebbe richiedere svariati giorni... e poi diciamoci la verità, questo sistema è conosciuto appena, è "roba vecchia", "dai sù... basta una cancellazione dei nastri e pace" avranno pensato.

Quando tutto era perduto, gli specialisti hanno recuperato, invece, tutto quanto proprio dalla tape library che era stata sì cancellata, ma non sovrascritta. (ripeto, almeno così ci è dato sapere, ma a mio avviso è tecnicamente plausibile).

I sostenitori della Tape Library di tutto il mondo hanno stappato bottiglie di spumante agitando il proprio dito di biasimo esclamando "ve l'avevo detto io!!! E voi che non volevate spendere 10, 15 o 30 mila euro di tape library!!". Bhè, come dargli torto... ma a mio avviso la lezione è diversa.

I detrattori della Tape Library, invece, hanno saggiamente fatto notare che quindi la tape (ritenuta inviolabile e "offline") è vulnerabile tanto quanto i NAS, nè più nè meno. Ed è solo per pigrizia che gli attaccanti non hanno investito tempo su questo strumento... state certi che non accadrà più, perdere qualche decina di milione di dollari per un errore è un monito più che sufficiente ad indottrinare generazioni di attaccanti per qualche decennio almeno.


L'attacco ai sistemi di Regione Lazio ci ha insegnato qualcosa, motivo per cui la direzione che ha preso il GDPR circa la necessità di rendere noti i dettagli degli attacchi informatici è da me estremamente condivisa non solo per motivazioni legate ad eventuali lesioni derivanti dall'utilizzo improprio dei dati, ma anche per raccogliere eventuali errori e mettere in atto contromisure adeguate alla rapida evoluzione che il settore sviluppa. Ci ha insegnato che il vecchio detto che "solo oggetti spenti sono sicuri" (più o meno, al netto di WoL), è vero. E lo è sempre più. A tal punto che il backup totalmente offline o in un cloud a sè stante è una risorsa fondamentale. A patto di non commettere errori del tipo "portarsi il disco in chiaro a casa e farselo rubare dalla macchina". Un evergreen.

 


Certamente ci saranno nuove compromissioni e nuove contromisure da adottare, nessuno sa cosa ci attende nel futuro della sicurezza delle infrastrutture informatiche, ma di certo l'analisi degli attacchi gioca un ruolo fondamentale per strutturare una difesa sempre più attenta. Ed è certamente positivo che la sensibilità delle aziende stia crescendo, così come anche gli investimenti. Finalmente si sente la consapevolezza che quello che difendiamo non è "il server", ma il patrimonio informatico aziendale e che senza di esso un'azienda può persino cessare la sua attività. 
 
Sorprende, infine, che questi criminali, alla luce delle profonde radici etiche su cui l'hacking basa le sue origini, non abbiano sviluppato il benchè minimo senso di coscienza. Obiettivamente, come si può bloccare un sistema sanitario in piena campagna vaccinale? Come si può far chiudere un'azienda che dà lavoro a centinaia di famiglie? Come puoi bloccare un ospedale? Davvero si può diventare così inumani? Tu, attaccante, non avrai mai bisogno di un ospedale? Sono dubbi che non possono non assalire chi crede profondamente in quelle radici così onorevoli poc'anzi citate.



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

venerdì 5 febbraio 2021

VMware CVE-2020-3992 e CVE-2019-5544

Di recente sono state scoperte due gravi vulnerabilità che interessano i sistemi virtuali ESXi (https://www.vmware.com/security/advisories/VMSA-2020-0023.htmlhttps://www.vmware.com/security/advisories/VMSA-2019-0022.html). 

Potenzialmente consentono ad un attaccante di crittografare e rendere inservibili le macchine virtuali. Qualche giorno fa VMware ha rilasciato un workaround per disabilitare il protocollo vulnerabile (https://kb.vmware.com/s/article/76372).

Si consiglia di applicare con urgenza la patch.

Sistemi coinvolti:



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

mercoledì 30 dicembre 2020

Monitorare gli host in maniera semplice - Script Bash

Sovente accade di voler monitorare degli host. Certo, esistono sistemi estremamente completi come Zabbix, ma spesso sovradimensionati rispetto ad un monitoraggio semplice e rapido. Ho, quindi, creato un semplice script Linux che ci consente di monitorare degli host in maniera semplice effettuando, a scelta, uno dei seguenti controlli:

  • ICMP Request (ping)
  • Verifica che una porta sia attiva (ad esempio la 25 per un mailserver)
  • Verifica la presenza di una stringa all'interno di una pagina web (per accertarsi che essa sia realmente reperibile)
  • Verifica la presenza di un file html con all'interno la dicitura "iocisono" (per minimizzare la richiesta di banda in monitoraggi particolarmente massivi)


Il progetto, scritto in bash per linux, è liberamente reperibile qui: https://github.com/cl4x/bashmonitoring e si compone di 3 file visibili nel progetto:

  •     monitoring.sh (il programma vero e proprio, ricordate di dare i permessi +x, che ometto in questo articolo in quanto si compone di circa 300 righe)

  •     monitoring.conf (il file di configurazione)

Il file di configurazione ha i seguenti parametri:

SLEEPTIME (si riferisce al tempo di sleep tra un controllo e quello dopo - il primo ciclo viene fatto integralmente senza sleep time)
SLEEPPRPOC (si riferisce al tempo di sleep tra un ciclo completo e l'altro, ovvero da quando finisce di controllare tutti gli host a quando riprende dall'inizio)
RETRY (indica il numero di tentativi, separati da un secondo, prima di dichiarare down l'host)
LOGENABLE 1|0 (abilita o disabilita i log)
LOGPATH (ovviamente dove scrivere i log che, per semplicità, non utilizzano syslogd)

  •     monitoring.hosts (qui andremo a definire gli host e che tipo di controllo effettuare)

 Il ogni riga è un controllo su un host, è diviso da ; ed è strutturato in questa maniera:

tipo di controllo;descrizione;host;eventuale opzione

ecco alcuni esempi:


ping;CloudFlare DNS;1.1.1.1

effettua un semplice ping


porta;Https su Repubblica;www.repubblica.it;443

verifica che la porta 443 sia aperta sul sito repubblica.it


porta;SMTP Gmail;gmail-smtp-in.l.google.com;25

verifica che la porta 25 su questo server sia aperta


porta;TestDown;11.22.33.44;11111

un esempio di come verrà evidenziato un host down


strhtml;Mozilla IT;https://www.mozilla.org/it/;Newsletter-mozilla-and-you

verifica che su questo sito la pagina web mostri la stringa "Newsletter-mozilla-and-you"

 

Ecco il risultato finale:

 

 

A breve integrerò, tempo permettendo, l'invio di email e anche una chiamata voip.

 

NB: deve essere installato nmap e curl, banalmente su debian/ubuntu basta dare 

sudo apt install nmap curl


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


giovedì 8 ottobre 2020

Containerizzazione vs Virtualizzazione spiegata in 2 minuti

La nuova frontiera della virtualizzazione consiste nel virtualizzare non una macchina intera (con il suo sistema operativo) ma un'immagine di un'applicazione specifica. Vediamo insieme di cosa si tratta e quali opportunità offre questa alternativa.


All'epoca, i più "stagionati" come me, lavoravano con le chroot jail in ambito linux. Esse consentivano di isolare un processo chiudendolo in una "gabbia" affinchè esso non possa "uscire" e arrecare danni al sistema madre. Il concetto di "containerizzazione" non si discosta molto a livello concettuale, ma a livello pratico introduce una serie di vantaggi davvero notevoli e sancisce una nuova generazione di strumenti a disposizione dei SysAdmin.


Avevo appena imparato a padroneggiare la virtualizzazione, sono spaesato, cos'è la containerizzazione?

Lo so, ti sono vicino. Partiamo dalla slide presente sul sito ufficiale di docker:

La differenza sostanziale risiede nel layer a cui la virtualizzazione viene effettuata. Mentre nella virtualizzazione tradizionale ad essere astratto è uno strato hardware che poi viene presentato alle macchine virtuali, nel container ad essere astratto è uno strato applicativo che condivide tra i container sostanzialmente il kernel del sistema ospitante. I container sono, di fatto, processi a sè stanti su di uno stesso sistema e che vengono lanciati nello user space.

Quali sono i vantaggi... e gli svantaggi?

PRO
  • I container sono molto più leggeri di una intera VM e richiedono meno risorse.
  • Fare il deploy di un'immagine (o un'applicazione, se volete) è estremamente semplice e rapido.
  • L'immagine si porta dietro tutte le librerie necessarie, non serve più impazzire sulle dipendenze. La portabilità è elevatissima.
  • L'architettura clusterizzata è semplice da implementare, le immagini sono già di per se nativamente predisposte all'utilizzo in cluster multinodo (o sciami).
  • Un'immagine può essere lanciata su qualsiasi sistema, sia esso Linux, Microsoft o MAC (almeno per docker di cui parleremo più avanti).
CONTRO
  • Il sistema è app-centrico, mi serve wordpress, lo scarico dall'hub, lo faccio girare, fine. Sarà non banale accedere allo storage, personalizzare un cron e lavorare sullo strato inferiore.
  • Fin quando la mia esigenza è confinata ad una specifica applicazione, la cosa è lineare. Ma se devo lavorare su un sistema completo e complesso, allora potrebbe non essere la tecnologia corretta.

 

Insomma, ad ognuno il suo, non è detto che la containerizzazione vada  sempre bene. Un provider che fa hosting di siti troverà notevole vantaggio. Un'azienda che ha un'architettura tradizionale (un db server, un'app server, un fs server, due dc, etc.) non trarrebbe alcun vantaggio veramente tangibile.

Nei prossimi capitoli creeremo un'architettura a container con Docker, parleremo dei cluster con swarm ed infine approfondiremo kubernetes con lo scopo di orchestrare il tutto.

 

 

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


giovedì 14 maggio 2020

Il nostro PC va lento! E' una nostra sensazione o sta rallentando tutto??

Stiamo tornando pian piano alla normalità, perlomeno informatica, e troviamo il nostro PC lento. Ci siamo arrugginiti noi o è realmente cambiato qualcosa?

Tranquilli. E' cambiato e sta cambiando qualcosa, il nostro fisiologico invecchiamento cellulare neurologico non centra con la sensazione di lentezza che stiamo riscontrando. Siamo salvi (più o meno).




Le motivazioni

Difficile dirlo, certamente gli ultimi aggiornamenti non sono stati brillanti (un po' su tutte le piattaforme), in molti casi hanno risolto alcuni problemi ma ne hanno introdotti molti altri. Personalmente penso che il processo di rilascio degli aggiornamenti, soprattutto in ambiente Windows, abbia subìto un peggioramento qualitativo abbastanza evidente. Tuttavia personalmente ritengo che le recenti vulnerabilità sulle CPU abbiano davvero fatto danni gravi.

Per i meno informati, a gennaio 2018 è stata pubblicata una ricerca su una famiglia di vulnerabilità hardware sui moderni processori in grado, teoricamente, di dare accesso a porzioni di memoria che possono contenere, tra le altre cose, anche credenziali (meglio note come Spectre e Meltdown, https://meltdownattack.com/, ne abbiamo parlato anche qui https://claudiodabbicco.blogspot.com/2019/02/vmware-e-vulnerabilita-cve2018-3646.html). La cosa non è banale perchè non è risolvibile con un semplice aggiornamento, si tratta di un problema architetturale dei processori Intel e AMD e che richiede una riprogettazione hardware tutt'altro che semplice.
Nel corso del tempo, questa famiglia di vulnerabilità (CVE-2017-5753, CVE-2017-5715 e CVE-2017-5754) è passata da uno stato "teorico" ad uno "pratico", pertanto si è reso indispensabile porvi un rimedio. E l'unico rimedio per sistemare la cosa non viene gratis, ma impatta drammaticamente le performance: le chiamate che prima venivano passate quasi direttamente al processore, ora devono essere vagliate più dettagliatamente dal sistema operativo, introducendo uno strato software che non potrà mai essere rapido ed immediato come una chiamata diretta su un hardware pensato appositamente. 


Proviamo a banalizzare: all'interno della nostra autovettura siamo abituati al comando dell'acceleratore, esso viene chiamato direttamente dal nostro piede destro. Ora immaginiamo di non avere più il pedale dell'acceleratore sotto il nostro piede, ma di averlo sotto il piede del nostro passeggero a cui dovremo di volta in volta dire "accelera", "alza il piede", "un po' di più", "un po' di meno" e così via. Introduciamo un inevitabile ritardo dovuto ad un ulteriore livello tra noi ed il comando. E questo, nel caso informatico, milioni di volte al secondo. Il motivo? Si è scoperto che l'acceleratore al posto di guida può far esplodere l'auto, spostarlo al passeggero è, per quanto scomodo, comunque il male minore.

A questo va aggiunto che il sistema operativo di Microsoft si sta arricchendo di moltissime funzionalità (non sempre gradite, intendiamoci) che inevitabilmente aggiungono carico su carico.

Aggiungiamoci anche che c'è stato un incremento esponenziale dei virus, pertanto gli antivirus sono diventati incolpevolmente più pesanti, più pignoli nel controllo e più gravosi per il sistema che proteggono.


Chi ha colpito?

Tutti. Lavoriamo con migliaia di macchine e su tutti i livelli il rallentamento è percepibile. Dagli i9 più potenti agli i3 meno performanti, tutti quanti avvertono un "lag", ovvero un ritardo nell'immediatezza con cui molte operazioni avvengono.


E linux? Ed i Mac?

Linux non è esente dal problema, tuttavia va detto che il sistema del pinguino è nativamente tipicamente più leggero, inoltre è possibile stabilire in fase di boot se il kernel debba o meno intervenire per mitigare il problema. A questo si aggiunge tutto lo strato antivirus presente sui sistemi Microsoft, normalmente non utilizzato su Linux (o se utilizzato, certamente meno impattante del suo omonimo pari prodotto per Windows).

Sui MAC la situazione è simile, se non peggiore, rispetto a Windows. Stiamo assistendo a macchine anche abbastanza recenti e che prima "se la cavicchiavano" e che ora diventano drammaticamente lente anche dopo averle formattate. E, per inciso, il discorso antivirus su Mac è totalmente diverso: i Mac hanno bisogno di un antivirus! E' un falso mito che esso non sia necessario, recentemente gli attacchi si sono concentrati persino più su questa piattaforma che su altre.


Cosa fare?

Nulla. Davvero, non c'è nulla da fare se non aspettare CPU di nuova generazione e aggiornamenti che mitighino, per quanto possibile, il fenomeno (che come abbiamo visto non è di semplice risoluzione). A breve si attende un aggiornamento massivo in casa Microsoft improntato sulle performance. Speriamo bene.



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


martedì 4 febbraio 2020

CEPH e FileSystem Distribuiti: Pro e Contro rispetto ad architetture tradizionali

Il mondo dei FileSystem Distribuiti è un mondo interessante, ma non privo di insidie. In questo articolo proveremo a scovare quelli che sono i problemi che potrebbero trasformare un bel progetto in un disastro completo.

Partiamo con il fare una distinzione. Ci sono due modi per progettare un'infrastruttura di virtualizzazione, il modo tradizionale ed il modo distribuito.

Infrastruttura tradizionale


L'infrastruttura tradizionale è composta da uno o più nodi ed una SAN. I nodi si occupano di erogare capacità computazionale (CPU e RAM) e la SAN si occupa di passare la parte di storage con le varie LUN. Non ci soffermiamo troppo sulle varie sfaccettature che questa architettura consente, volontariamente ho semplificato lo schema per non aggiungere "carne al fuoco". Inoltre nello schema la SAN è collegata in iSCSI, questo ci facilita le comparazioni architetturali.


Infrastruttura distribuita




Nell'infrastruttura distribuita ogni nodo apporta, a beneficio di tutti, non solo la propria capacità computazionale ma anche il proprio storage. Non esiste, pertanto, una vera e propria SAN. I nodi sono normalmente molto meno performanti, ma in quantità maggiore.


Alcuni approfondimenti preliminari


Qui abbiamo parlato degli errori comuni commessi da chi dimensiona una SAN.

Qui, invece, abbiamo parlato di architetture, ridondanze e performance. 

Questo, invece, è un articolo che entra molto nel dettaglio delle performance, vitali e fondamentali in un sistema di virtualizzazione, in grado di vanificare qualsiasi investimento se mal dimensionato.

In linea di massima, consiglio al lettore curioso un approfondimento di tutto il tag Storage di questo blog.


Il laboratorio

Per testare gli argomenti presi in esame e fortemente motivati da una sana curiosità verso quella che potrebbe essere una tecnologia rivoluzionaria, abbiamo creato un'infrastruttura con 10 nodi CEPH. A breve creeremo anche un laboratorio vSAN vmware. Lo so... comporta tempo, ne abbiamo poco, ma ritenere che la ricerca sia meno prioritaria dell'attività commerciale denota una visione aziendale non lungimirante. Ma questo è un altro discorso.


I 10 nodi consentono un'infrastruttura virtuale e mettono a disposizione CEPH. In CEPH, ogni disco (che per prassi è un disco fisico dedicato) diviene un OSD che possiamo suddividere in classi. I dischi con le stesse classi verranno aggregati. (in foto il test di 2 fault con dei pool con replica a 3)

In questo laboratorio abbiamo creato 3 FileSystem Distribuiti per un totale di 14 dischi dedicati:
  • HD300 è formato da soli 2 dischi SATA su due nodi diversi
  • Pool 32 è un pool di 8 dischi da 500Gb SATA, 1 per 8 nodi
  • SSD è un pool di 4 dischi SSD da 500Gb, sempre distribuiti 1 per nodo

Come funziona la replica?

E' improprio, ma immaginiamo un RAID sparpagliato su molti nodi. In fase di creazione del Pool di OSD (quindi dell'Array, per usare sempre il paragone con il RAID) potremo decidere il numero di repliche del dato, quindi quanto vorremo sacrificare il nostro spazio in favore della resilienza al guasto.

Va detto: i dischi non devono essere tutti uguali come nel RAID tradizionale. Qui ogni nodo apporta il suo. L'accortezza, al massimo, è di creare dischi che come performance siano paragonabili. Inutile mettere un SSD all'interno di un Pool con 10 SATA. 

La seconda accortezza è di non avere tagli troppo differenti in quanto un disco da 4Tb in un pool di 10 dischi da 250Gb non ha molto senso per una palese ed ovvia difficoltà di replica e distribuzione del dato. Il disco di grandi dimensioni verrà più interessato dalle operazioni di IO, questo è evidente.



Differenze progettuali tra le due architetture

E' evidente, le due architetture differiscono profondamente. A mio avviso non ha senso valutare un'infrastruttura distribuita con meno di 6 nodi (e che in previsione devono scalare nel breve periodo in numero maggiore). Proviamo comunque a schematizzarne i pregi ed i difetti di ognuna.

Tradizionale (PRO)
  • E' facile da manutenere, ogni elemento è identificabile e la diagnostica di problemi di performance è relativamente semplice
  • Da un punto di vista di licensing, con le nuove politiche basate su core e socket, è decisamente più economica
  • I consumi energetici sono minori in quanto le macchine da tenere accese sono certamente meno. Il contenimento dei costi energetici è un problema sempre più presente nelle aziende.
  • L'infrastruttura di rete può essere anche economica, avere interfacce in Gigabit non è scandaloso. Con l'architettura distibuita il 10Gbit è il minimo sindacale, senza se e senza ma, e questo decuplica i costi sul networking.
  • Se voglio la performance pura, questa si sposa più con l'architettura tradizionale in cui i nodi sono molto spinti come capacità computazionale. E' comunque sempre vero che una VM sfrutta al massimo quanto eroga il proprio nodo fisico, quindi se i nodi sono tanti ma economici, nessun nodo potrà erogare performance comparabili con uno "ben carrozzato".
  • In una SAN, l'aumento dei dischi coincide con l'aumento degli IOPS. A differenza dell'architettura distribuita dove il collo di bottiglia è sempre la NIC (preferenzialmente dedicata) dell'host che ospita la macchina virtuale.

Distribuita (PRO)
  • Estremamente scalabile, basta aggiungere nodi
  • Molto improntata al fault tolerance, non c'è un singolo point of failure, i nodi sono totalmente e indiscutibilmente indipendenti
  • Relativamente economica da un punto di vista hardware, i nodi costano molto meno in quanto hanno caratteristiche meno spinte e si può investire meno nella ridondanza del singolo nodo (a differenza del costo della parte rete)
  • Non c'è una SAN da acquistare e da manutenere

Conclusioni

"Non è tutto oro quel che luccica". Mi ha colpito la facilità con cui a caldo è possibile aumentare o diminuire il numero di dischi ed anche le repliche. Ma la sorpresa è stata amara quando abbiamo approfondito la parte di performance. La rete ad 1 Gbit NON è affatto sufficiente, le macchine sono troppo lente, le latenze estenuanti, hdparm restituiva un valore di circa 80MB/s su qualsiasi Pool (sia SATA sia SSD), quindi il nodo va veloce quanto la NIC dedicata alla parte storage, sempre e comunque meno di un FC o di un DAS. Questo comporta la necessità di salire come minimo a 10Gbit, con costi anche molto elevati. Da un punto di vista si risparmia sull'hardware dei nodi e della SAN, da un altro invece si spende sulla componente networking.

Nel frattempo ho ordinato 6 NIC a 10GbE ed uno switch Full 10Gbit (la ricerca costa! purtroppo solo il Cliente lungimirante comprende che gli esperimenti è meglio farli in laboratorio e non sulla sua pelle, e questo è incompatibile con una valutazione al massimo ribasso). Questo ci consentirà di fare dei test e capire se il livello di performance è accettabile, anche per applicazioni ad alto IO. Approfondiremo questa parte nel prossimo articolo, così come approfondiremo anche tutta la parte vmware vSAN.

Ultima nota: il FileSystem Distribuito consuma RAM e CPU, non poco, quindi i nodi devono essere dimensionati molto attentamente per non incorrere in freeze in caso di operazioni di riallineamento.



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










giovedì 23 gennaio 2020

Muovere i primi passi in IPv6 (dal tunnel broker all'host ipv6 only)

L'articolo che sto scrivendo ha un taglio più tecnico, per cui non me ne vogliano i meno esperti (a cui comunque cerco spesso di dedicare anche articoli "digeribili"), ma sarebbe opportuno che il lettore conosca cos'è un IPv4 e la relativa logica di routing legata alla maschera di rete, inoltre è necessario avere già conoscenze sui meccanismi di NAT per meglio comprendere il proseguo.

Lo scopo è quello di far muovere i primi passi e consentire al lettore di creare un laboratorio di test per effettuare una serie di esperimenti.

L'architettura presa in esame non prevede che il proprio ISP fornisca nativamente IPv6, quindi utilizzeremo un TunnelBroker, ovvero un  servizio in grado di creare un tunnel con il nostro gateway ed erogarci una classe /64 di IPv6 (di 18 milioni di miliardi di IP pubblici, ma questo lo vedremo avanti).

Premessa

Visto il taglio tecnico, mi dilungherò poco sulle premesse: oramai anche i muri sanno che gli IPv4 sono praticamente terminati su RIPE e ARIN, quindi la situazione (seppur se ne parli da molto tempo) riveste carattere d'urgenza. Piuttosto è importante sfatare alcuni miti per cui è opportuno che il lettore legga queste FAQ in italiano ad opera di ipv6italia (gruppo non più attivo, ma le cui fonti risultano comunque estremamente utili e preziose).

E' altrettanto opportuno che il lettore sappia leggere un IPv6, quindi rimando a https://it.wikipedia.org/wiki/IPv6 e nello specifico la sezione di "Notazione per gli indirizzi IPv6".


Primo Step: creare un collegamento ad un Tunnel Broker

Come abbiamo visto poc'anzi, un servizio di Tunnel Broker si occupa di fornire connettività IPv6 tunnellizzandola su una esistente IPv4, esso ci darà a disposizione una classe IPv6 /64 liberamente utilizzabile, ovvero 18446744073709551616 IP Pubblici Statici (per dirla con nomi familiari). Opzionalmente è possibile richiedere una /48 con un semplice click, ma ritengo che non siano particolarmente necessari i 1208925819614629174706176 indirizzi IP di questa maschera di rete. (almeno non ora, non parleremo di subnetting)

Nel nostro esperimento (estremamente pratico), ci collegheremo su https://www.tunnelbroker.net/, effettueremo una registrazione, quindi cliccheremo su Create Regular Tunnel. A questo punto potremo scegliere il nodo di collegamento IPv4 tra una serie corposa di Server sparsi in tutto il mondo.



A questo punto avremo tutto per creare un Tunnel tra noi e loro per utilizzare la nostra classe IPv6.


Potremo avere visibilità degli IP pubblici utilizzando il semplice tool CIDR Calculator per IPv6 reperibile qui https://www.ultratools.com/tools/ipv6CIDRToRange (in effetti non è proprio banale calcolare la notazione CIDR in v6!).



Secondo Step: Configuriamo il nostro router-tunnel

Qualcuno dovrà fare un tunnel, nel nostro caso il router che si occuperà di fare questo è un pfSense la cui documentazione relativa a questo aspetto è estremamente dettagliata e reperibile qui: https://docs.netgate.com/pfsense/en/latest/interfaces/using-ipv6-with-a-tunnel-broker.html


Se tutto va bene ed abbiamo seguito la guida "religiosamente", avremo il tunnel online. 

Interfaccia Tunnel online


Architetturalmente abbiamo deciso di mettere, a seguire, un firewall Stormshield dietro il pfSense, pertanto quest'ultimo non viene utilizzato come firewall, ma come semplice router.

Facciamo qualche prova utilizzando http://www.ipv6now.com.au/pingme.php

Perfetto, siamo belli, biondi e con gli occhi azzurri.


Terzo Step: La nostra LAN full IPv6

A questo punto abbiamo messo il firewall Stormshield a valle del pfSense (abilitandolo all'IPv6) in bridge, così da consentire l'adozione degli IPv6 pubblici su tutta la LAN. Il NAT su IPv6 non è necessario e da un punto di vista di sicurezza, in verità, non apporta alcun beneficio rispetto ad un filtro ben strutturato... anzi.





Configurato correttamente il Firewall in bridge, potremo notare sull'interfaccia out il traffico IPv6 mediante un tcpdump:



A questo punto abbiamo messo un server vmware direttamente connesso all'altra interfaccia del bridge sul firewall, così da poter installare due macchine virtuali, una Linux ed una Windows.


NB: Abbiamo abilitato sul firewall il DHCP6 Server, tuttavia esso non era indispensabile avendo lasciato abilitati i protocolli di Router Advertisemen (RA), di cui tuttavia ci occuperemo in un prossimo articolo.

A conti fatti, l'architettura che abbiamo realizzato è la seguente:

Qualche test

A questo punto abbiamo la nostra rete Full IPv6, ovvero ora non sussiste alcun IPv4 tradizionale (per la cronaca, il protocollo IPv4 è stato proprio disabilitato all'interno delle VM).




Le VM navigano (sui siti, pochi, IPv6 abilitati). Ovviamente Debian si è riuscito nativamente a scaricare i suoi aggiornamenti fin dalla fase di installazione. Come DNS abbiamo messo (quando facevamo da DHCP6 Server) i DNS6 di CloudFlare 2606:4700:4700::1111 e 2606:4700:4700::1001.


In sostanza, le due macchine tra di loro si pingano, raggiungono l'esterno e sono contattabili dall'esterno. Hanno, di fatto, degli IP pubblici. In questa fase non sono stati messi dei filtri, ne parleremo più avanti, è un laboratorio. Da notare che questa architettura non utilizza ovviamente NAT. Era banale da precisare (trovandoci in Bridge), ma è importante entrare nell'ottica che il NAT appartiene al mondo IPv4, e non a quello IPv6 (il NAT-PT è un'altra storia, prima o poi lo approfondiremo).

A questo punto, non posso che augurare al lettore sopravvissuto "buon divertimento" con i nuovi host IPv6 only. Buoni esperimenti!

E poi?

Le domande che a questo punto il lettore dovrebbe essersi già posto sono:
  • In una rete fullbridge (un po' come accade nei campus), come faccio a creare delle policy di firewalling?
  • In una rete fullbridge, come gestisco le VLAN e la relativa compartimentazione?
  • Il DHCPv6 Relay che vedo ha più IP, che ruolo ha la Router Advertisement (RA) in tutto questo?
  • Perchè la mia scheda di rete ha un indirizzo speciale fe80::/10 valido (da RFC) per lo specifico link fisico? (ovvero: cosa significa link fisico?? Che centrano i layer più bassi? Parleremo di Scope Address, un nuovo concetto) 
  • Facciamo alcune considerazioni di sicurezza, l'assenza del NAT semplifica di molto la gestione (NO! Il NAT non si applica per motivi di sicurezza ma solo per incrementare il numero di IPv4 utilizzabili!), inoltre il numero sproporzionato di indirizzi IPv6 rende difficoltoso il lavoro degli scanner generici. Tralasciando le fantasie sul supporto IPsec nativo di IPv6 rispetto a IPv4, che altri scenari si aprono sotto il fronte security?
Ne parleremo nel prossimo articolo, nel frattempo sarebbe interessante confrontarci sul tema. Lasciate pure nei commenti i vostri contatti (se personali non li pubblicherò, i commenti sono moderati). Ogni confronto è bene accetto, anche non necessariamente epistolare.

RA su StormShield

RA su pfSense



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

venerdì 10 gennaio 2020

MicroFollie dei filtri antispam Outlook/Live/Hotmail

Come molti dei miei lettori sanno, uno dei nostri prodotti di punta è il DM Pro, ovvero un MailServer basato su piattaforma Linux con Postfix come MTA. Inizialmente abbiamo avviato questo progetto timidamente, per poi acquisire sempre maggior know-how nel corso di questi intensi 8 anni di attività. Ne abbiamo viste di tutti i colori ed il nostro osservatorio umano ha classificato e creato oltre 25.000 regole personalizzate e specifiche per combattere lo spam. Insomma, la posta elettronica è un argomento complesso "sotto al cofano", ma è anche uno di quei settori dove abbiamo investito maggior tempo.

Purtroppo accade che alcuni grandi nomi decidano di non rispettare i protocolli standard (abbiamo in passato già parlato dei "capricci" di Microsoft in questo articolo) ed implementino variabili spesso fantasiose degli stessi. Anche per questo motivo può accadere che una email perfettamente lecita e formattata, inviata da un MailServer perfettamente configurato, finisca nello spam.

Per i meno addetti ai lavori, finire o meno in spam è una questione di reputazione. Migliore sarà la reputazione del mio MailServer, più probabilità ho di recapitare un'email al mio destinatario. Definiamo però reputazione perchè, in questo caso, reputazione è una parola che ha un ampio respiro. Fondamentalmente ci sono due momenti in cui un'email può essere rifiutata:
  1. In fase di contatto con l'MTA: ovvero quanto il mailserver mittente si presenta a quello di destinazione. Se vieni escluso in questa fase, probabilmente l'hai fatta grossa. Si tende, infatti, a limitare il rifiuto in questa fase in quanto il reject darà un errore di tipo 5.x.x, ovvero l'email verrà rifiutata senza se e senza ma. E' il caso (spesso, poi ognuno configura il proprio server come meglio crede) di un'email contenente un virus, o listata in una RBL particolarmente affidabile, o magari in caso di email inviata da una classe di IP pubblici.
  2. In fase di analisi: ovvero quando l'email ha passato i primi controlli, è stata totalmente scaricata e presa in carico dall'MTA e viene inviata al motore antispam (tipicamente SpamAssassin). Qui possiamo fare un controllo aggiuntivo che prima non potevamo fare, ovvero leggerne il contenuto intero (il body) e muoverci di conseguenza. A questo punto ogni cosa sviluppa un punteggio, al superamento di una soglia l'email verrà classificata come spam (e normalmente contrassegnata e spostata comunque dall'LDA nella casella di destinazione ma nella directory IMAP Junk). Un testo bianco su sfondo bianco, ad esempio, svilupperà un punteggio di 0.3, che si aggiungerà (sepre ad esempio) al punteggio di 3.0 se il link all'interno dell'email è ritenuto spam da una DBL, e così via. La soglia standard è 7, se l'email supera questo punteggio è spacciata. Un'email perfetta ha ottenuto un punteggio di 0.


Il fattaccio

Ebbene, ultimamente abbiamo notato che i filtri antispam di Microsoft (applicati quindi a Hotmail, Outlook, Live e tutti i servizi correlati) penalizzano MailServer perfettamente leciti la cui colpa è, probabilmente, non aver acquistato un prodotto Office 365.

Ma andiamo con ordine. Il MailServer in questione è stato perfettamente configurato:
  • Reverse DNS perfetto
  • Protocollo SPF perfettamente implementato
  • Protocollo DKIM perfettamente implementato
  • Protocollo DMARC perfettamente implementato
  • Punteggio ottenuto con mail-tester.com di 10/10 (il massimo, qui un punteggio alto invece è positivo)
ma le email ad un indirizzo hotmail finiscono in "indesiderata".

Apriamo un ticket al provider che erroneamente classifica l'email come spam e l'operatore, onestamente ignaro delle motivazioni astruse che stanno alla base del diniego nel recapito della posta, ci risponde di iscriverci al programma Outlook SNDS e al programma Outlook JMRS. Rispettivamente un programma di analisi reputazionale degli indirizzi IP e di reportististica dello spam.

Bene, ai punti sopra, quindi aggiungiamo:
  • Iscrizione al programma SNDS per gli IP correlati agli MX
  • Iscrizione al programma JMRS per i domini gestiti
Ma nulla, le email continuano inspiegabilmente a finire in spam nonostante il monitoraggio indichi come status "normal", ovvero senza alcun problema.

In qualche meandro della rete si vocifera che randomicamente un'email inviata da un altro client di posta (ad esempio Thunderbird) venga ritenuta spam solo perchè l'utente non ha come molti acquistato Outlook, ma noi non vogliamo crederci. Proviamo con Outlook e, ad onor del vero, anche qui l'email finisce in spam.

Il caso di "bullismo informatico" da parte del colosso verso il piccolo qui diviene evidente, ci impuntiamo, siamo certi di aver fatto le cose per bene e incalziamo pretendendo una risposta. Il supporto tecnico ci risponde:
Apply for the Sender Score Certified Mail program.
If you are doing all the above and you continue to have deliverability issues, you may wish to consider joining the Sender Score Certified Mail Program, a third party program administered by Return Path, Inc. Many legitimate mailers and marketers have qualified and joined this program to improve mail deliverability and decrease email from being filtered to the Junk E-mail Folder. Sender Score (https://returnpath.com/solutions/email-deliverability-optimization/ip-certification/) is the only service to which we subscribe.
Che per i più pigri significa:
Se stai facendo tutto quanto sopra e continui ad avere problemi di consegna, potresti prendere in considerazione l'idea di aderire al Programma di posta certificata Sender Score, un programma di terze parti gestito da Return Path, Inc. Molti mailer e rivenditori legittimi si sono qualificati e si sono uniti a questo programma per migliorare la consegna della posta e ridurre il filtraggio della posta nella cartella Posta indesiderata. Il punteggio mittente (https://returnpath.com/solutions/email-deliverability-optimization/ip-certification/) è l'unico servizio a cui ci abboniamo.

In sostanza: se il tuo MailServer è perfettamente configurato ma la tua unica colpa è non utilizzare un nostro software o un nostro servizio, allora per consegnarci la posta puoi iscriverti a pagamento a questo servizio esterno.


Forse è uno scherzo, il primo aprile è distante, ma magari c'è stato un cambiamento nel calendario americano, chi lo sa. Rispondo alle 7.53 indicando che una risposta simile non è accettabile, noi siamo in regola, abbiamo fatto tutte le cose per bene e devono approfondire il ticket.

Mi arriva un'email alle 8.11:
Thank you for contacting Microsoft Technical Support. The service request has been archived due to inactivity. If you still require assistance, please contact us via support.microsoft.com or 1-800-Microsoft.

Onestamente per molto meno Microsoft ha ricevuto multe milionarie e la prepotenza e l'arroganza di chi si sente in diritto di dettare leggi in un mondo che segue standard e regole, è imbarazzante. E questo si aggiunge all'incredibile politica di licensing folle basata su core che ha aumentato, in molti casi, il costo dei sistemi operativi di svariati ordini di grandezza. Ma questa è un'altra storia e, soprattutto, del tutto lecita. 

In ogni caso, manterrò aggiornato questo articolo.

giovedì 17 ottobre 2019

Leggi vigenti e tecnici, come non commettere (gravi) errori legali

Sistemisti e tecnici informatici spesso sottovalutano le leggi che regolamentano il nostro mestiere. Quanti prendono alla leggera il far eseguire un software di teleassistenza ad un Cliente che non ha siglato esplicitamente il consenso? Non è difficile, in questo campo, commettere un illecito penale e ritrovarsi nei guai. Capiamo insieme quali sono i limiti e quali le precauzioni attraverso le quali tutelare un mestiere che si muove sempre su una sottile linea di demarcazione tracciata tra etica, legalità e necessità tecniche.


Il padre di ogni articolo è il 615ter. C.P., ovvero:

Chiunque abusivamente si introduce in un sistema informatico o telematico protetto da misure di sicurezza, ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo, è punito con la reclusione fino a tre anni.

La pena è della reclusione da uno a cinque anni:

1) se il fatto è commesso da un pubblico ufficiale o da un incaricato di un pubblico servizio, con abuso dei poteri, o con violazione dei doveri inerenti alla funzione o al servizio, o da chi esercita anche abusivamente la professione di investigatore privato, o con abuso della qualità di operatore del sistema;
2) se il colpevole per commettere il fatto usa violenza sulle cose o alle persone, ovvero se è palesemente armato;
3) se dal fatto deriva la distruzione o il danneggiamento del sistema o l'interruzione totale o parziale del suo funzionamento, ovvero la distruzione o il danneggiamento dei dati, delle informazioni o dei programmi in esso contenuti.

Qualora i fatti di cui ai commi primo e secondo riguardino sistemi informatici o telematici di interesse militare o relativi all'ordine pubblico o alla sicurezza pubblica o alla sanità o alla protezione civile o comunque di interesse pubblico, la pena è, rispettivamente, della reclusione da uno a cinque anni e da tre a otto anni.
Nel caso previsto dal primo comma il delitto è punibile a querela della persona offesa; negli altri casi si procede d'ufficio.

Fin qui è evidente, non si scherza, ed è ben chiaro il campo di applicazione. Ma proviamo a fare degli esempi pratici:
  • Il ragazzetto che incautamente per arrotondare la paghetta si scrive 2 righe di VB e crea un ransomware, incorre nel comma 3 con l'aggravante di distruzione di dati, che prevede la reclusione da 1 a 5 anni. Sicuramente a questo articolo si aggiungerà il fine estorsivo (da 5 a 10 anni di reclusione nella variante più leggera).
  • Il tecnico che, per eseguire un intervento occasionale richiesto verbalmente, fa scaricare all'Utente Finale di un Cliente un software di teleassistenza, si espone alla possibilità che il responsabile IT o l'AD del Cliente stesso possano ritenere questo un accesso non autorizzato, con le conseguenze del caso. Per non incorrere in problemi, il consiglio è quello di avere sempre per iscritto, da parte di un responsabile o dell'Amministratore, la richiesta di intervento tecnico. Gli interventi in regime manutentivo esulano da questa dinamica in quanto regolamentati da un contratto di manutenzione che, a sua volta, dovrebbe prevedere la nomina della figura correttamente inquadrata all'interno del contesto del GDPR.
Qui c'è un risvolto estremamente interessante. La Corte di Cassazione (27/10/2011 n.4694 Sez. U) ha sancito il campo di applicazione del 615ter anche quando qualcuno, pur munito legittimamente di password, utilizzi quest'ultima per ragioni diverse da quelle proprie del suo incarico. E si aprono scenari estremamente interessanti che vediamo con degli esempi:
  • Il tecnico configura un FileServer ma, erroneamente, all'account del magazziniere ha dato privilegi per accedere all'area dell'amministrazione. Questo non solleva il magazziniere dalla responsabilità di non accedere ad aree a lui non concesse. L'abilitazione del proprio account, sostanzialmente, non è un giustificativo valido ad eccedere ed abusare dei propri privilegi.
  • Il tecnico che si deve occupare esclusivamente delle stampanti ha ottenuto la password di un utente amministrativo del dominio Active Directory affinchè il dispositivo di stampa possa collegarsi con quest'ultimo per ricevere l'elenco degli utenti. Il tecnico che utilizzi queste credenziali per altri fini, pur avendole ottenute legittimamente, sta commettendo l'illecito penale di cui sopra.
  • Il tecnico curioso che trova su un monitor di servizio in un aeroporto ID e password di un teamviewer e tenta di accedervi, anch'esso incorre nel 615ter. (il possedere le credenziali non lo autorizza ad accedere al sistema).
In sostanza la Cassazione ha sancito che, colui che pur essendo abilitato, acceda o si mantenga in un sistema informatico o telematico violando le condizioni ed i limiti risultanti dal complesso delle prescrizioni impartite dal titolare del sistema per delimitarne l'impiego, commette un illecito correlato al 615ter. indipendentemente dalla materiale possibilità di accedere indiscriminatamente a tutti i dati (anche nel privato).


Art. 615 quater, detenzione di codici di accesso:

Chiunque, al fine di procurare a sé o ad altri un profitto o di arrecare ad altri un danno, abusivamente si procura, riproduce, diffonde, comunica o consegna codici, parole chiave o altri mezzi idonei all'accesso ad un sistema informatico o telematico, protetto da misure di sicurezza, o comunque fornisce indicazioni o istruzioni idonee al predetto scopo, è punito con la reclusione sino a un anno e con la multa sino a cinquemilacentosessantaquattro euro.
La pena è della reclusione da uno a due anni e della multa da cinquemilacentosessantaquattro euro a diecimilatrecentoventinove euro se ricorre taluna delle circostanze di cui ai numeri 1) e 2) del quarto comma dell'articolo 617quater.

Qui c'è poco da commentare: le password dei nostri Clienti sono sacre. Diffonderle arbitrariamente ottenendo un vantaggio significa compiere un illecito.


Art. 617 quater, un altro interessante articolo:

Chiunque fraudolentemente intercetta comunicazioni relative a un sistema informatico o telematico o intercorrenti tra più sistemi, ovvero le impedisce o le interrompe, è punito con la reclusione da sei mesi a quattro anni.
Salvo che il fatto costituisca più grave reato, la stessa pena si applica a chiunque rivela, mediante qualsiasi mezzo di informazione al pubblico, in tutto o in parte, il contenuto delle comunicazioni di cui al primo comma.
I delitti di cui ai commi primo e secondo sono punibili a querela della persona offesa.
Tuttavia si procede d'ufficio e la pena è della reclusione da uno a cinque anni se il fatto è commesso:
1) in danno di un sistema informatico o telematico utilizzato dallo Stato o da altro ente pubblico o da impresa esercente servizi pubblici o di pubblica necessità;
2) da un pubblico ufficiale o da un incaricato di un pubblico servizio con abuso dei poteri o con violazione dei doveri inerenti alla funzione o al servizio, ovvero con abuso della qualità di operatore del sistema;
3) da chi esercita anche abusivamente la professione di investigatore privato.

Facciamo qualche esempio:
  • Abbiamo acceso uno sniffer e stiamo facendo un Man In The Middle intercettando il traffico.
  • Il Cliente ci ha chiesto di fare un'analisi di rete, il consiglio è quello di avere sempre un'autorizzazione scritta ad effettuare qualsiasi operazione che comporti lo sniffing o il dump del traffico.

Considerazioni

Ovviamente non ho trattato volontariamente la frode informatica (Art. 640ter C.P.), atto volontario con scopi ben delineati. L'articolo ha un fine diverso (per quanto io non sia un giurista, mi perdonino i lettori specializzati ai quali invito e, anzi, chiedo eventuali correzioni), ovvero quello di sensibilizzare chi di mestiere fa questo e che, a volte, incautamente, ingenuamente o involontariamente incorre in azioni che potrebbero avere risvolti estremamente seri e complessi.



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

mercoledì 26 giugno 2019

Plug, giunti ed errori comuni sul Layer 1

Il cablaggio, da sempre, è uno degli aspetti più sottovalutati delle telecomunicazioni. Tecnicamente è la strada fisica su cui le informazioni viaggiano, ma l'attenzione viene spesso spostata verso il server più potente o la postazione di lavoro più performante, dimenticandosi che, di fatto, il mezzo trasmissivo è la componente primaria mediante il quale il traffico viene veicolato

Ad aggravare questa noncuranza vi è un aspetto molto insidioso, ovvero che i problemi di un cablaggio fatto male sono spesso non tangibili. Rallentamenti inspiegabili, microdisconnessioni e performance mai piene quasi mai vengono attribuite ad un cablaggio fatto male. Questo perchè per identificare questi problemi servono strumenti certificatori che spesso costano più di un'autovettura e che chi si improvvisa cablatore non possiede. Parliamo di strumenti che ogni anno vanno inviati in taratura e che leggono parametri in grado di certificare la tratta secondo la categoria di appartenenza EIA/TIA, non certo del lantest con 8 led.

Lo strumento che abbiamo usato per queste prove è un Fluke DSX600 calibrato e tarato 3 mesi prima, con aggiunta di adattatori (o volgarmente "nasi") 6A.



La categoria

Parliamo innanzitutto di questo: cos'è una categoria? Una categoria è un riferimento ad una serie di parametri standardizzati che racchiudono, tra le altre cose, delle soglie elettromagnetiche entro le quali la tratta deve rientrare. Non solo, una categoria definisce anche delle regole che prescindono dalla misurazione. Ad esempio definiscono un massimo angolo di curvatura del cavo, una trazione massima, una vicinanza rispetto a motori elettromagnetici (ad esempio ascensori) e così via.

Ad esempio, queste sono delle regole che prescindono dalla certifica:
  • Monomarca: nella categoria 5e è consentito il mix di marchi diversi, dalla 6 no, il frutto e la patch devono essere dello stesso produttore
  • Plug: sono consentiti fino alla 5e, dalla 6 è vietato il plug crimpato e quindi la patch deve essere realizzata in fabbrica dal produttore
  • Giunti: sono consentiti fino alla categoria 3 compresa e assolutamente vietati oltre. Nella categoria 5e è consentito un giunto a norma (non certo saldato) e nulla vieta di fare un connection point passivo, ovvero frutto-patch-frutto perfettamente a norma.
Purtroppo non è semplice reperire materiale, ma il consiglio è quello di consultare esclusivamente lo standard e non siti che lo interpretano.
EIA/TIA Standard

 

Il patentino rilasciato dal Ministero

Recentemente assisto sempre più spesso a pseudo-professionisti che non hanno mai fatto un corso sul layer 1 e non conoscono neanche le basi del cablaggio, tuttavia asseriscono che "funziona quindi va bene". Diciamoci la verità, questo è dovuto anche all'abrogazione del patentino. In passato un'azienda doveva essere certificata per effettuare questi lavori:

a) primo    grado:    consente    l'installazione, l'ampliamento e l'allacciamento nonche' la manutenzione  di impianti interni di qualsiasi tipo e potenzialita';
b)  secondo grado: consente le stesse operazioni del 1 grado relativamente ad impianti interni con capacita'  fino a  400  terminazioni interne per voce e dati con esclusione di quelli realizzati con sistemi radio e/o fibra ottica;
c) terzo grado: consente le  operazioni  del  2  grado relativamente   ad  impianti  interni  per  sola  fonia  di capacita' fino a 120 derivati.
Giusto per capirci, per essere di primo grado (e quindi mettere anche solo un metro di fibra ottica) un'azienda (ahinoi) doveva possedere questi requisiti:

1) primo grado:
1.1) personale tecnico dipendente:
-una unita' addetta alla progettazione degli impianti;
-una unita' addetta alla direzione dei lavori;
-otto  unita'  addette  all'esecuzione  dei lavori e/o alla manutenzione delle apparecchiature terminali;
1.2) strumenti di misura:
-dotazione individuale di strumentazione di  base  per ogni unita' addetta all'esecuzione dei lavori;
-misuratore   di   terra   e  multimetro  digitale  da laboratorio,   oscilloscopio    50    MHz,    impulsografo, analizzatore  di  spettro,  analizzatore  di protocollo per reti  locali,  un  reflettometro  per  reti  locali  ed  un personal  computer portatile con schede di accesso per reti locali;  la  strumentazione  deve  essere   conforme   alle specifiche tecniche dichiarate dal costruttore;
1.3) locali:
-uffici:  un  locale ad uso ufficio presso cui ha sede l'impresa;
-magazzino: un deposito di adeguate dimensioni ad  uso esclusivo   dell'impresa   che  possa  contenere  le  varie apparecchiature di telecomunicazioni,  le  attrezzature  di cantiere e di squadra;
1.4) automezzi:
-cinque automezzi di cui due autofurgoni;
1.5) assicurazione:
-copertura   assicurativa  di  responsabilita'  civile verso terzi;
E' evidente, non ci si poteva improvvisare e questo garantiva al cliente finale un minimo di professionalità. Dal 2013 il patentino non è più obbligatorio e questo ha portato, obiettivamente, aziende giovani a fare certamente prezzi molto competitivi, ma spesso a discapito del know-how e degli strumenti necessari per fare un lavoro di qualità. Non ultima, la non obbligatorietà della presenza di strumenti di certifica in grado di validare la corretta esecuzione dei lavori.


Nel concreto

Quotidianamente vengo interpellato da clienti per risolvere problemi che, spessissimo, sono molto meno "sistemistici" di quanto i miei predecessori hanno considerato. E altettanto quotidianamente mi trovo a parlare con tecnici installatori che commettono errori grossolani (un classico è quello di pluggare la categoria 6 direttamente nello switch senza passare da un patch panel). Con questo articolo voglio entrare nel dettaglio con considerazioni obiettive (tramite uno strumento di certifica) degli errori più comuni fatti perchè "tanto funziona".


Il test di riferimento

Questa è una tratta di 45mt (con cavo U/UTP di prima qualità, con crociera al centro) in categoria 6A, fatta con 2 frutti cat.6A (di prima qualità anche questi) e patch dello stesso produttore.



Vorrei essere molto chiaro su questo: la categoria che vediamo stampata sul cavo non vuol dire nulla. Un cavo economico si vede: mi è capitato di assistere a certifiche che non passavano al superamento di 15 metri di tratta!! Il trittico cavo-frutti-patch deve prevedere materiale prodotto da produttori di comprovata affidabilità, perchè altrimenti è inutile anche parlarne. Ultimamente sta girando un cavo davvero imbarazzante la cui installazione è decisamente sotto qualsiasi soglia deontologicamente accettabile.

Come si leggono le certifiche? 
Senza entrare troppo nel dettaglio, se anche un trefolo supera la soglia rossa, la tratta è fuori certifica. E questo significherà ritrasmissioni, errori e rallentamenti perlopiù silenti e la cui colpa ricadrà su "quelli dei server" o "quelli del gestionale" in maniera immotivata.




Il primo errore comune: il famigerato "frutto sguainato"

Tipico di alcuni installatori di altra estrazione è il lavorare comodi, ovvero sguainando molto il cavo e rimuovendo la twistatura. Qui siamo stati gentili, ho visto di peggio (anche perchè poi, ripiegati i cavi nelle scatole di alloggiamento, la situazione diventa drammatica). Inoltre abbiamo usato, come al solito, dei frutti ottimi (la situazione peggiora con i plug diretti e ovviamente con cavi e frutti economici).



La normativa dice di non "stwistare" (passatemi il termine) i cavi oltre i 12mm... e c'è un motivo: il risultato è impietoso.



Con questo cavo non possiamo nemmeno stenderci i panni, non passa la 6A, non passa la 6 e non passa la 5e. Avete visto che differenza con il test di riferimento e quanto quest'ultimo sia abbondantemente sopra la linea di soglia?

(test di riferimento con tratta a regola d'arte)

 

Il secondo errore comune: "ci metto un plug e risparmio il frutto"

Nella categoria 5e potrebbe andar bene (per quanto statisticamente i plug crimpati hanno sempre delle criticità meccaniche e non siano minimamente paragonabili a una patch fatta dal produttore). Dalla 6 è esplicitamente vietato (nonostante si vendano degli inspiegabili plug cat6). Quindi già questo ci fa capire che il test è abbastanza relativo, perchè la tratta non sarà di categoria 6 neanche a test passato. Tuttavia noi siamo zelanti ed il test lo abbiamo fatto comunque.


Di poco, ma non è passata la categoria 6. A questo si aggiunge che, nel corso del tempo, la tratta degraderà molto a causa di una bassa resistenza meccanica.

Questo non significa che non funzionerà, ma significa che la colpa la daremo a "quelli del gestionale" o a "quelli del server". Il problema è sempre questo: il cablaggio genera problemi spesso silenti, si pensa che vada tutto bene anche quando non è così.


Il terzo errore comune: "io sono bravo e i giunti a me funzionano anche se non sono eleganti"

Probabilmente c'è un girone dell'inferno specifico per chi fa giunti, questo è abbastanza indubbio. Ma sono certo che le pene corporali nella dannazione eterna debbano subire un incremento per chi se ne vanta anche.

Questo è un giunto fatto molto bene, sguainamento minimo, frutti e cavi di qualità. Non contenti, abbiamo anche fatto una prova con il saldatore (terribile, si crea una palla di stagno che fa attenuazione) essendo una credenza comune quella di considerare il saldatore come il risolutore di ogni male.



Anche qui: la normativa EIA/TIA lo vieta quindi il test è molto relativo. Ad ogni modo, il cavo scende ai valori di NEXT e il test non passa in entrambi i casi.


Conclusioni


Il lettore sopravvissuto mi perdonerà la lungaggine, ma questo articolo nasce da una spontanea e sana esigenza di "evangelizzazione informatica". Troppi pseudoprofessionisti sono convinti che vada bene tutto perchè "tanto funziona", ignorando che nell'informatica il "come funziona" è ancor più importante. I Clienti spesso investono cifre considerevoli su server sovradimensionati, ignorando totalmente il budget dedicato al mezzo trasmissivo. Questo comporta sovente la vanificazione dell'investimento.

Il dato di fatto è che, sul cablaggio, i problemi sono certamente meno evidenti e misurabili solo con strumenti molto costosi. Ma questo non significa che quest'ultimo non possa essere (anzi...) oggetto di problemi, rallentamenti e microdisconnessioni! 

Se avete dubbi, certificate i punti e scoprirete che probabilmente il motivo per cui avete tanto dannato i tecnici dei layer superiori erano immotivati!

Ovviamente potremmo parlare di tratte FTP schermate male che causano più danno che beneficio, potremmo parlare di cavi da esterno con guaina supplementare con i plug crimpati sopra, e così via, ma avremmo certamente annoiato ulteriormente il lettore.


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