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

Cosa succede ad un server quando lo pubblichiamo su internet? IP nuovo... server nuovo... ma che vuoi che accada? Forza... vediamo un po'...

HoneyPot

Di recente abbiamo messo in piedi una rete di 13 HoneyPot in 13 nazioni diverse. I server HoneyPot sono dei server esca che espongono servizi trappola volontariamente vulnerabili così da farsi attaccare e raccogliere dati. Queste informazioni vengono da noi raccolte per poi essere catalogate per stilare una raccolta di indirizzi IP a cui viene assegnata una bassa reputazione. Il fine è di trasferire queste informazioni a oggetti (firewall o filtri hardware) in grado di bloccare questi IP a monte, prima che essi movimentino qualsiasi operazione verso i servizi leciti.

L'esperimento

Ebbene, accendiamo uno dei 13 HoneyPot su un indirizzo nuovo di zecca. Giusto il tempo di configurarlo e sistemare le esche... cosa avrà raccolto nelle sue prime due ore operative? Quanti attacchi vuoi che abbia mai preso questo server?

Nelle prime 2 ore di vita, il server ha ricevuto più di 5.400 attacchi sui servizi esposti e che è in grado di riconoscere. Che ovviamente sono solo una infinitesimale parte dei servizi che un server può esporre.

Attaccanti univoci

Entriamo nel dettaglio. "Certamente molti attacchi provengono dagli stessi IP"... nì... Dal grafico evinciamo che in media ogni IP ha veicolato circa 4 attacchi, il che significa che non siamo stati presi di mira da qualcuno in particolare, ma da tanti che fanno questo da mattina a sera mediante degli automatismi.

Geolocalizzazione degli attacchi

Andiamo a vedere chi ci attacca... maddai, sicuramente arrivano tutti da una zona... e invece no. Altro luogo comune da sfatare, gli attacchi arrivano da ovunque. Server forati utilizzati come ponte, VPS, telecamere e oggetti IoT vulnerabili, router vecchi, NVR per videosorveglianza (molto gettonati, devo dire)... qualsiasi oggetto può essere utilizzato, e chi ne risponde è il titolare della connessione che ospita il device vulnerabile.

Va detto, qui siamo stati particolarmente sfortunati, per mia esperienza normalmente la Turchia è un paese da cui provengono meno attacchi rispetto a Russia e USA.

Servizi e tipologia degli attacchi

Andiamo a scoprire quali servizi vengono presi di mira...

The winner is SAMBA! Aaah... che bello avere i propri file sempre con se anche fuori casa. Ma a chi vuoi che importi se espongo il mio filesystem? Bhè, a quanto pare a molti.

Avete presente poi quella stampante vecchiotta che lavora solo con SMBv1 ? Quel protocollo vecchio che quei cattivoni di Microsoft disabilitano ad ogni aggiornamento perchè vulnerabile e facile facile da forare? Eccolo qui...

Cosa abbiamo qui? Uh... anche il protocollo RDP... Quello che vogliamo a tutti i costi abilitare per accedere da casa al proprio server o al proprio computer... si si, proprio quello che "eh ma ogni volta devo stare a cliccare qui su Start VPN... inaccettabile!!!". Eh... mi sa che invece è proprio necessario... Perchè si da il caso che la maggior parte dei ransomware si prende proprio da lì, da attaccanti che hanno compromesso il server che esponeva il protocollo RDP (Desktop Remoto) senza VPN e crittografia.

Nota di colore, nelle prime 2 ore non ci hanno attaccato il famigerato log4j, ma comunque mentre sto scrivendo questo articolo già sono arrivate decine di tentativi.

Attacchi alle password

La mia password è inattaccabile!! Non serve l'autenticazione a due fattori!!! Ok... questi sono i tentativi (i maggiori, l'infografica li evidenzia in base al numero) arrivati in solo 2 ore... (sopra username e sotto password)

OS Focus

Maddai, non serve aggiornare Windows 7... ok...

Ah... quindi serviva?

Serve proteggere il proprio perimetro con un sistema di filtraggio supplementare?

Il grafico non lascia spazio a dubbi. Assolutamente si, motivo per cui la nostra area R&D è impegnata nello sviluppo di un sistema di filtraggio a sè stante, una blackbox che fa solo questo. Non è un firewall configurabile, ma un sistema di pre-filter in bridge.

Conclusioni

Faccio ormai da molti anni questo mestiere, con la speranza di riuscire a farlo al meglio delle mie possibilità e delle mie capacità, con passione e impegno. E nonostante sia un ventennio che mi occupo di questo, onestamente sono abbastanza sorpreso. Dall'ultima analisi che avevo fatto mi aspettavo sì un numero elevato di attacchi, ma non così elevato. Nell'ultimo anno sostanzialmente si sono triplicati, ma la cosa abbastanza sorprendente è la rapidità con cui gli attacchi hanno raggiunto un server su un nuovo IP.

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

Bande sempre più performanti... ok, ma c'è un punto in cui casca l'asino! Parliamo di peering.

 Oggi parliamo di Peering (in maniera molto superficiale e con linguaggio adatto anche ai neofiti) per capire cosa accade realmente quando navighiamo o esponiamo dei servizi.

Oramai siamo abituati a connettività in fibra da 100, 200 e addirittura in Gigabit o 2,5 Gigabit. Siamo altrettanto abituati ad avviare uno speed test e darci una pacca sulla spalla quando leggiamo valori coerenti con quanto abbiamo acquistato. Una cosa che, tuttavia, non sarà scritta in nessun contratto, è quanto il nostro operatore è performante nel peering con altri operatori. Un esempio? Quando uno speed test restituisce valori bassi, in genere "bolliamo" la cosa con "il server su cui sto facendo il test è scadente". No, non sempre, anzi! E ora cerco di spiegarvi perchè.

Facciamo un passo indietro... cosa accade quando navighiamo?

Molto brevemente: poniamo il caso di voler contattare www.google.it. Tra il nostro client e i server di google ci saranno molti punti di routing (hop) che dovremo attraversare. Alcuni saranno interni al nostro operatore, altri saranno interni all'entità che vogliamo contattare (o Autonomous System, che nell'esempio è Google), al centro di essi vedremo tipicamente un Internet Exchange che si occupa di mettere in comunicazione i maggiori AS (Telecom, Vodafone, Wind, Fastweb, ma anche Google, Facebook e tutti quei operatori che hanno investito e deciso di collegarsi "direttamente" ai "fulcri" su cui si snoda la rete internet, ovvero i punti di interscambio) con degli accordi di Peering. I puristi non si scandalizzassero della banalizzazione e della non differenziazione tra Peering Privato e Peering Pubblico: è un articolo per neofiti!

Volendo schematizzare, quindi, lanciando un tracert da una connettività A (su fastweb) ad un punto B (su vodafone) nel nostro caso avremo i seguenti punti di routing:

 

I primi punti (omessi nell'immagine) sono il nostro router ed i router del nostro operatore. Gli ultimi punti (sempre omessi) sono, specularmente, i router dell'operatore e il router della connettività finale. Ma al centro avviene una magia: tutti i maggiori operatori si incontrano in uno o più Internet Exchange e comprano porte su switch (router) con cui smistarsi il traffico.

Nell'esempio di cui sopra, è plausibile pensare che 93.63.100.145 sia il router di fastweb al MIX-IT e 217.29.67.27 sia il suo corrispettivo di Vodafone. Il MIX ( https://www.mix-it.net/ consiglio un giro sul sito per maggiore approfondimento) è uno degli snodi italiani più importanti in cui questo avviene.

 

Dove casca l'asino?

Gli operatori, quindi, comprano delle porte e delle bande per smistarsi il traffico tra di loro. Pertanto, fin quando dall'operatore A finisco sempre sull'operatore A, il routing sarà interno. Quando dovrò attraversare il perimetro del mio operatore per contattarne un altro, dovrò necessariamente e ovviamente passare da un AS ad un altro.

Per farsi un'idea di quanto gli operatori hanno investito, questo straordinario sito riporta i Peer: https://peeringdb.com/

Ad esempio questi sono i Peer nel punto di interscambio di Francoforte: https://peeringdb.com/ix/31 (a destra le velocità).

Perchè uno speed test su server diversi restituisce risultati molto diversi?

Perchè il server è scadente? No, nella maggior parte dei casi no. Dopo tutta questa spiegazione, abbiamo gli elementi per dire che il peering potrebbe averci messo lo zampino.

Quando facciamo uno speed-test tipicamente finiamo su di un server del nostro stesso operatore. Quindi facciamo un bellissimo speed test in una condizione ottimale. 

Qui, ad esempio, Vodafone su Vodafone MI:

 

 

Ma quale percentuale di siti o servizi internet nel mondo si trovano ospitati per coincidenza proprio sul nostro operatore? Una percentuale irrisoria (a prescindere da quanto grande possa essere il nostro operatore), quindi potremo dire che nel 99% dei casi la nostra navigazione uscirà dal nostro operatore e attraverserà il suo perimetro, pertanto questo nostro speed test sarà sostanzialmente inutile.

 

Proviamo a fare uno speed test, sempre dalla nostra connessione di esempio, su OVH Graveline, uno dei provider di servizi in cloud più importanti d'europa (e su cui verosimilmente ci si trovi realmente in qualche maniera a far del traffico):

 

 

 

Proviamo a testare un salto di operatore andando, sempre dalla stessa connessione dell'esempio Vodafone, verso Wind:

 

 

 

Ora proviamo dalla stessa su di un server di un piccolo operatore locale (che certamente non ha le economie necessarie a comprare Terabit di banda negli Internet Exchange):

Non mi fraintendete, l'articolo non vuole puntare il dito verso un operatore specifico (anche perchè noi non abbiamo gli elementi per dire che la caduta di performance sia colpa dell'uno o dell'altro operatore): lo scopo è solo didattico.

Conclusioni

Capite bene che la velocità è relativa e condizionata da molti fattori. Fare uno speed test ci da solo un aspetto (condizionato, inoltre, dal carico di quel momento), e normalmente si tratta anche di un aspetto abbastanza aleatorio. Non c'è una risposta precisa alla domanda "si, ok, ma la mia connessione a quanto va?". La risposta più corretta è "dipende da te, dipende dal tuo interlocutore e dipende anche e soprattutto da quanto i rispettivi operatori hanno investito nel traffico di interscambio".

Di sicuro rimane sempre valido il consiglio, ad esempio, di interconnettere in VPN sedi diverse della stessa azienda possibilmente utilizzando sempre lo stesso operatore, proprio per evitare passaggi e latenze supplementari.

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

Che succede? Attacchi, attacchi ovunque! Ma spesso la colpa non è dei clienti!

•  22 Ottobre 2021: San Carlo viene attaccata da una cyber-gang, parte dei dati vengono trafugati e pubblicati in rete a dimostrazione della violazione (carte di identità, dati di produzione, numeri di telefono, etc.). Viene chiesto un riscatto a scopo estorsivo. https://milano.repubblica.it/cronaca/2021/10/26/news/attacco_hacker_san_carlo_azienda_patatine_chiesto_riscatto_ransomware_gang_conti-323808439/

• 21 Ottobre 2021: SIAE viene attaccata, i dati (estremamente sensibili) di autori, cantanti e personale vengono trafugati e viene chiesto un riscatto di 3 milioni di euro. https://www.ilsole24ore.com/art/attacco-hacker-siae-esfiltrati-dati-chiesto-riscatto-AE5HBGr?refresh_ce=1
  

• 20 Ottobre 2021: L'IRAN subisce un attacco informatico che blocca le stazioni di rifornimento di carburante, bloccando di fatto l'intero paese. https://www.redhotcyber.com/post/l-iran-%C3%A8-a-secco-di-carburante-a-causa-di-un-attacco-informatico

Anche alla meno tecnica cronaca generalista certamente non è mancato di sottolineare l'attacco informatico a Regione Lazio, alla struttura sanitaria di San Giovanni Addolorata a Roma, a Luxottica e persino alla nota multinazionale informatica Accenture.

E nel nostro mondo più locale, personalmente in media ricevo un paio di telefonate a settimana di imprenditori che hanno prima sottovalutato il problema e poi si sono trovati ad essersi amaramente pentiti, con dati persi e quella sensazione di smarrimento che hai quando improvvisamente qualcosa che davi per scontato diventa (spesso) irrimediabilmente perduta.

Che succede? Succede che la consapevolezza che la sicurezza informatica sia un cardine delle attività produttive sta certamente aumentando, ma non sufficientemente. Ieri per l'ennesima volta sollecitavo una soluzione di backup in cloud ad una S.p.A. che non ne vuole proprio sapere di investire una quota irrisoria per un salvagente così importante.

Dal World Economic Forum la sicurezza informatica è stata inserita tra i principali rischi per l’economia globale. E' evidente: ci troviamo in un momento storico in cui non è più pensabile sottovalutare il problema, così come non è più pensabile lasciare la serranda e le porte di accesso alla propria azienda aperte di notte. 

 

Cari tecnici, spesso la colpa non è del cliente...

Va detto con estrema onestà intellettuale: ciò che è meno evidente è che non tutti gli operatori IT hanno la sensibilità e le competenze giuste per occuparsi di sicurezza. Così come un elettrauto non è solitamente in grado di riparare un paraurti ed un cardiologo non è un ortopedico, a prescindere da chi fa la parte gestionale o hardware, un supervisore della sicurezza delle infrastrutture IT potrà dare certamente un parere più specialistico e accurato per evitare errori spesso fatali (backup crittografabili, accessi lasciati aperti, permessi generosi, etc.). 

Nella stragrande maggioranza dei casi che mi trovo ad analizzare, l'incidente di sicurezza era estremamente evitabile e causato, perlopiù, da tecnici che mettono in atto pratiche francamente sconsiderate. In oltre vent'anni di esperienza, posso stilare un piccolo elenco di errori che spesso i tecnici (IT interni o aziende esterne) commettono in relazione alla sicurezza delle infrastrutture informatiche:

1. "comodità": "nnnah, devo fare un tunnel vpn per accedere al desktop remoto? Troppo impegno!"
2. "sottovalutazione": "non ho niente da nascondere! Che gliene importa dei miei dati!"
3. "ignoranza": "Tunnel chee? Io giro la 3389 e pace."
4. "errore umano": Questo caso è più raro, ma accade. Apro una porta sul firewall che mi serviva per testare qualcosa, la lascio aperta e dopo qualche mese diventa un ricettacolo di attacchi. Motivo per cui quando i miei tecnici installano un firewall, un primo tecnico lo installa e configura ed un secondo tecnico fa "pelo e contropelo" alla configurazione del primo. E randomicamente i firewall vengono ricontrollati da cima a fondo.
   
5. "sottomissione al cliente": "io ho proposto di avviare un Tunnel VPN... ma il cliente non vuole sapere di fare un click in più!".
   

E su quest'ultimo punto davvero ci sarebbe da scrivere un libro... Vuoi la sicurezza? Allora gioco mio e regole mie. Se invece il cliente proprio non ne vuole sapere di adottare delle pratiche corrette, mi permetto di suggerire un piccolo trucco che funziona sempre: vuoi la comodità e fare di testa tua? Allora mi firmi una liberatoria con assunzione di responsabilità. Non la firma nessuno.

Sulla sicurezza non si scherza. Andiamo sempre più verso un mondo informaticamente duro, complesso ed ostile. Facciamocene una ragione. Gli sforzi fatti oggi, vengono spesso premiati in futuro con uno sterile stato di "non succede niente". Agli occhi dei meno attenti "tutto funziona" è poca cosa, agli occhi di un esperto di sicurezza è certamente la soddisfazione più grande. Apprezziamo il "non succede niente"!

 

 

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

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.

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.html e https://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.

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.

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.

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.

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.

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.

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.