Feeds:
Posts
Comments

Archive for the ‘Informatica e reti’ Category

(no, non sono morto…)

Forse alcuni di voi avranno sentito parlare di “depeering”, negli ultimi mesi. Cerco per prima cosa di fare un po’ di chiarezza a riguardo, per i meno tecnici.

Internet è una rete con una topologia magliata: tra un punto e un altro della rete esistono -tipicamente- parecchi percorsi, con protocolli di rete (BGP in primis) che provvedono ad individuare la strada teoricamente più efficiente (sia sul piano della velocità del traffico, sia sul piano dei costi) per arrivare dall’uno all’altro.

Questa magliatura è importante per diverse ragioni, e due in particolare

  1. la ridondanza: se un percorso “si rompe” ne viene individuato un altro funzionante
  2. la scalabilità: se la strada per una destinazione è congestionata, è possibile dirottare il traffico diretto ad essa verso un percorso più scarico

Un ruolo cruciale, in tale topologia di rete, è ricoperto dagli IXP (Internet eXchange Points): detta semplicemente, si tratta di infrastrutture (di fatto tipicamente LAN) in grado di veicolare grandi quantità di traffico tra diversi operatori; ciascun operatore “porta la propria rete” fino all’IXP e qui viene connesso alla rete di quest’ultimo. Da tale momento in poi può usufruire di codesta infrastruttura per scambiare traffico con gli altri operatori afferenti allo stesso IXP.

Dovrebbe risultare evidente come ciò sia ben più efficiente che non implementare una linea fisica che connetta a ciascuno di tali operatori: in primo luogo il costo è quello di una unica connessione “grossa” (quella che va dalla rete dell’ISP fino all’IXP) anziché tante connessioni “piccole”. In secondo luogo, la capacità di tale link va dimensionata in base al traffico aggregato e non in base a quello atteso per i singoli ISP con cui va scambiato: se il traffico diretto ad A e B passa dentro lo stesso link, nel momento in cui A è scarico la capacità residua può essere utilizzata per B e viceversa, liddove nel caso di un-link-per-operatore se A è saturo e B è scarico ciò è evidentemente impossibile.

E ancora: se un ISP si connette a diversi IXPs, ha a propria disposizione molteplici strade per scambiare traffico con gli altri operatori che facciano altrettanto; in tal modo, se ISP-A e ISP-B sono entrambi presenti in due IXP, possono decidere ad esempio di spostare il traffico che si scambiano da IXP-A a IXP-B qualora i loro link (dell’uno e/o dell’altro) verso IXP-A abbiano problemi di qualsivoglia tipo. Ovviamente -anche qui- è impensabile poter mettere in piedi link ridondanti con ciascun operatore, come sarebbe necessario fare in assenza di punti di interscambio.

Ecco, ciò che Telecom Italia ha deciso di fare è in sostanza di eliminare unilateralmente pressoché tutti i peering con altri operatori sul territorio nazionale.

Le ragioni apportate (di fatto dall’ufficio marketing di T.I. e da una manciata di quelli che posso solo definire pennivendoli compiacenti) sono abbastanza ridicole, come già ampiamente argomentato da Marco d’Itri in questo suo articolo. Articolo che consiglio vivamente di leggere, perché non ne riprenderò i contenuti in alcun modo.

Quel che invece vorrei trattare qui è un effetto collaterale -in qualche misura- di queste pratiche: se prima il traffico tra il provider medio e un cliente di T.I. era così…

Con IXP

(la freccia rossa indica il passaggio attraverso l’IXP)

…adesso invece assomiglia tipicamente a una cosa così…

Senza IXP

Che il giro sia più lungo è evidente a tutti. Quello che è meno evidente è che ci sono ottime probabilità che i passaggi aggiuntivi (quelli color arancio qui sopra) avvengano all’estero.

E’ questo un problema? Sì/No/Dipende…

Al di là infatti degli aspetti inerenti le banali ottimizzazioni di traffico, latenze, ecc., questo detour ha anche altre implicazioni: porta il traffico scambiato tra due operatori Italiani a transitare attraverso altre giurisdizioni.

E’ questione di lana caprina? Forse. A volte sì, a volte no.

Senza dubbio, per la maggior parte degli utenti (da entrambi i lati della comunicazione) ciò è di norma del tutto irrilevante.

Ma che accade quando uno dei due capi della comunicazione è un sito istituzionale? O la rete di un ministero?

Proviamo… Ecco un traceroute eseguito da rete NGI:

traceroute to http://www.governo.it (195.66.10.19), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 1.259 ms 1.203 ms 1.742 ms
2 xdsl-gw.net.ngi.it (81.174.0.1) 44.398 ms 41.737 ms 42.259 ms
3 core1-v6.net.ngi.it (81.174.0.188) 40.801 ms 45.205 ms 40.799 ms
4 212.73.241.13 (212.73.241.13) 91.319 ms 41.194 ms 42.964 ms
5 ae-0-11.bar2.Milan1.Level3.net (4.69.142.190) 42.260 ms 42.274 ms 42.947 ms
6 ae-14-14.ebr1.Frankfurt1.Level3.net (4.69.142.194) 50.201 ms 51.000 ms 50.344 ms
7 ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 49.976 ms
ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2) 49.977 ms 50.168 ms
8 ae-1-60.edge3.Frankfurt1.Level3.net (4.69.154.7) 50.244 ms 51.713 ms
ae-2-70.edge3.Frankfurt1.Level3.net (4.69.154.71) 49.462 ms
9 ae5.franco31.fra.seabone.net (195.22.214.52) 50.704 ms 50.182 ms 50.704 ms
10 ibs-resid.milano26.mil.seabone.net (195.22.192.34) 51.884 ms 55.340 ms 51.477 ms
11 172.17.6.114 (172.17.6.114) 55.621 ms 55.126 ms 54.789 ms
12 172.17.8.134 (172.17.8.134) 76.438 ms 63.814 ms 65.646 ms
13 172.17.7.226 (172.17.7.226) 58.971 ms 59.267 ms 71.624 ms
14 80.21.5.97 (80.21.5.97) 60.008 ms 59.486 ms 59.466 ms
15 host146-56-static.199-31-b.business.telecomitalia.it (31.199.56.146) 60.556 ms 59.924 ms 60.472 ms

Di nuovo, chissenefrega dell’efficienza del routing. Sta di fatto che un utente della provincia di Gorizia, per raggiungere il sito del Governo Italiano passa per l’infrastruttura tedesca di un provider USA. Altrettanto vale, senza alcun dubbio, per le email ivi dirette, dato che gli MX per governo.it stanno sulla stessa rete…

Siamo sicuri che la cosa sia saggia?

Perché, chiariamo: non metto minimamente in dubbio che comunicazioni di natura realmente critica (come gli scambi di informazioni tra ministeri, per dire) avvengano su canali diversi dalla Internet pubblica, come backbone dedicate etc  (me lo auguro, almeno); ma è altresì indubbio che, viceversa, una certa quantità di informazione riservata è estraibile anche a partire dall’intercettazione del traffico pubblico.

E’ quindi opportuno che tale traffico transiti in maniera massiccia attraverso reti poste al di fuori della sovranità nazionale?

E’ in realtà una domanda che mi pongo da parecchio, e mi son sempre risposto che -tutto sommato- è solo paranoia.

Quest’oggi, tuttavia, a quanto pare la stessa domanda se la sta ponendo un sacco di gente. Un recente thread su NANOG vede operatori Canadesi osservare come una parte saliente del loro traffico nazionale si ritrovi a transitare attraverso reti USA, ed iniziano a loro volta a domandarsi se ciò non sia evitabile, ovviamente come conseguenza delle recenti rivelazioni riguardo alle intercettazioni massive del traffico Internet operate dall’NSA.

Ergo, la domanda che mi sovviene è: nel momento in cui le Istituzioni (quelle con la “I” maiuscola) provvedono ad individuare un fornitore per connettività ad uso Istituzionale, queste domande se le devono porre, o no? E, se se le pongono, come vedono -loro- l’operazione di depeering?!?

Paranoia di massa?

Read Full Post »

Sono oramai più di due settimane che comunicare con l’esterno è diventato impossibile.

Da quando quell’oscura organizzazione senza volto pare aver hackerato il mondo, entrando in controllo di praticamente qualsiasi cosa parli con bit e byte, anche camminare per strada è diventato rischioso. Sanno chi siamo, sanno tutto di noi; e ci possono osservare di continuo quando siamo in campo aperto, grazie alla miriade di telecamere di sorveglianza che il mondo intero ha avuto il dubbio piacere di mettere a disposizione dei loro piani di conquista e controllo.

L’unica possibilità del nostro gruppo di resistenza è restare al coperto, cercando di pianificare una qualche disperata forma di contrattacco. E sperare che lì fuori, da qualche parte, ci siano tanti altri gruppi come il nostro. E che, anche se finora non siamo stati in grado di entrare in contatto con loro, in qualche modo si riesca a concertare delle azioni insieme. E che queste azioni di guerriglia possano qualcosa, contro chiunque stia facendo tutto questo…

Sono un po’ tanti “se”, messi in fila; tanto da sembrare una disperata equazione di Drake… Ma è tutto ciò che possiamo fare: anche la potenza militare sembra essere stata messa in condizioni di non nuocere, da questa gente. Nessun convoglio militare, nessuna battaglia, nessuna rappresaglia armata. Niente.

Almeno per quanto ne sappiamo, dato che nemmeno quella vecchia radio ad onde lunghe pare riuscire a captare un diamine di segnale…

(more…)

Read Full Post »

http://www.senki.org/archives/966

Read Full Post »

Con un po’ di fatica, continuo questa disamina…
Avevamo visto nelle puntate precedenti come “segare a vista” alcune comunicazioni quando dirette ad entità malevole e/o compromesse possa aiutare in misura sensibile a limitare l’esposizione agli agenti infettivi e, in particolare, come affidarsi a  RPZ per posizionare parte di questa funzionalità all’interno del nostro resolver.

Tuttavia, come detto in uno dei primi episodi di questa serie, la prima cosa che viene alla mente quando si parla di “bloccare traffico” è il firewall. Perché non usare dunque le sue funzionalità?

L’idea è certamente buona, e certo non è nuova, ma ha un problema: poiché il nostro obiettivo è bloccare del traffico che normalmente consentiamo (come la navigazione web, ovvero la porta 80/TCP outbound) in virtù della nozione che alcune destinazioni non sono sicure, quel che ci serve è un ruleset dinamico, che ci permetta di far evolvere le nostre regole nel corso del tempo.

Per poterlo ottenere, ci servono due cose:

  1. Uno o più fornitori di intelligence, in grado di fornirci i dati che ci servono per applicare dei blocchi mirati
  2. Un framework che ci consenta di alimentare il ruleset dei nostri firewall con i dati succitati

Tutto sommato, non siamo in una situazione molto dissimile da quella del DNS che abbiam trattato la volta precedente…

Poco sorprendentemente, quindi, troviamo che lo scenario anche qui è lo stesso: per quanto riguarda i dati di intelligence, abbiamo i diversi progetti collaborativi con finalità di cyber-security, purché ci forniscano degli IP. Prima tra tutti la già citata Spamhaus.

Il vero problema è invece la disponibilità di un framework con cui poter alimentare i motori di filtraggio: ogni fornitore di firewall ha la sua GUI, a volte la sua CLI e (quando li ha) meccanismi di update dinamico dei dati di filtraggio la cui implementazione è chiusa e gestita centralmente dal fornitore, ergo pressoché inutilizzabile.

Ecco perché fare ‘ste cose direttamente sul firewall può rivelarsi estremamente ostico: è pur vero che, se c’è una CLI da poter utilizzare, in qualche maniera (expect e sue varianti?) si può scriptare qualcosa, ma non è certo una cosa semplice da realizzare nè alla portata del “tecnico medio”…

Fortunatamente, ci sono altre strade O:-)

Se ci pensate un poco, a conti fatti le funzionalità di un firewall non ci servono. Segare tutto il traffico da/per un determinato IP che si sa essere in mano a criminali non è in linea di massima un grosso problema; anzi, forse è la cosa più saggia… 😉 Questo ci lascia un’alternativa quasi migliore: saltare a piè pari la necessità di istruire un firewall e concentrarci sul come istruire un normale router, che può essere il router posto davanti al firewall o il firewall stesso: comandandogli di eseguire nullroute di tutto il traffico da/per gli IP che sappiamo essere malevoli, otteniamo esattamente lo stesso effetto.

“Bene” -mi si dirà- “ma perché istruirlo a fare il router dovrebbe essere più semplice che istruirlo a fare il firewall?”

Per due ragioni, in sostanza:

  1. scriptare qualcosa che “comandi” il router è necessità tutt’altro che rara, in parecchi ambienti. Ciò fa sì che esistano librerie specifiche, in diversi linguaggi, che rendono il compito abbastanza agevole (la prima che mi sovviene è Net::Telnet::Cisco disponibile in Perl…)
  2. poiché per far eseguire nullrouting al router dobbiamo nientemeno che passargli delle rotte, la CLI/GUI/API non è l’unico modo per farlo, nè il più comodo: i protocolli di routing sono stati inventati appositamente per quello, e fanno tutto da soli o quasi. In particolare BGP, oltre ad essere particolarmente adeguato allo scopo, gode anche di parecchia documentazione su come è possibile usarlo a tal fine.

In particolare il fatto di affidarsi a BGP affinché provveda lui ad istruire il router consente di spostare la componente di scripting altrove, ad un più tradizionale OS general purpose purché dotato di un routing daemon che supporti BGP. Quagga, per dire, è estremamente semplice da usare e più che adatto allo scopo.

In questo post non entrerò nel merito di come realizzare la struttura in questione; al limite ne scriverò a parte, per chi non fosse autonomo nell’implementarla da sè.

Voglio invece tornare sull’aspetto “sorgenti di intelligence”…

Quali dati usare per finalità di questo tipo?

Ci sono diverse scelte, che in parte si sovrappongono e in parte si completano, e che -se avete la pazienza, la competenza e l’autonomia decisionale di vagliarle- vi possono consentire di raccogliere buona parte dei dati necessari senza fare lavoro di intelligence da voi.

Da diversi anni, Spamhaus mantiene una lista di reti direttamente controllate da criminali, la cui finalità è esattamente quella di consentire il filtraggio a livello di router di confine. Si tratta di DROP, recentemente integrata da EDROP (non mi dilungo a spiegare la differenza tra le due: la trovate direttamente sul sito di Spamhaus; basti dire che, a meno che non siate un ISP, per le finalità qui descritte sono equivalenti). Di cosa sia in grado di fare DROP ne ho già parlato in passato, per quel che vale…

In DROP si trovano elencate reti estremamente permissive nei confronti dei propri utenti, tanto da consentire loro di far girare operazioni platealmente illegali garantendo (nei limiti del possibile) che esse non verranno interrotte a seguito di segnalazioni. Come immaginabile, è questi in servizi c.d. bulletproof che le operazioni veramente brutte si concentrano…

Tuttavia, proprio come conseguenza della notorietà cui queste reti sono soggette e della relativa facilità con cui è possibile isolarle, oggi come oggi parecchi degli exploit kit (vedi seconda puntata) vengono pubblicati su macchine dedicate appartenenti alle reti dei grossi datacenter e fornitori di VPS: è pur vero che in tal modo resteranno probabilmente in piedi solo per alcune ore prima che l’operatore -informato di cosa sta accadendo- le termini, ma per molte delle attività di Pay Per Install questa finestra temporale può essere sufficiente.

Soprattutto, ciò spiega anche quale sia lo scopo del layout a livelli multipli che abbiamo analizzato nella seconda puntata di questa serie di articoli. Se è vero infatti che l’host che esegue l’exploit kit può divenire indisponibile da un istante all’altro, è anche vero che lo spam-run inviato dal nostro malfattore non punta ad esso, ma ad uno o più siti del tutto leciti nei confronti dei quali i tempi di intervento degli operatori sono assai più dilatati. Sono poi queste pagine compromesse a portare l’incauto visitatore (direttamente o indirettamente) all’exploit kit. Se quest’ultimo diviene indisponibile, tutto ciò che il criminale deve fare è modificare le pagine già uploadate affinché linkino una nuova istanza dell’exploit kit, in esecuzione altrove.

In tal modo, il run di mail già inviate e contenenti un link non va buttato e mantiene inalterata la sua utilità, cosa che non avverrebbe se le mail linkassero direttamente l’exploit kit.

Ora: per via di come è strutturata l’accoppiata DROP+EDROP, singole macchine su reti lecite non vi sono incluse; quindi usando solamente queste due non le blocchereste. Ciononostante gli IP dove avvengono queste attività sono ugualmente noti a Spamhaus, che li eroga sotto forma di listing SBL…

Per renderli utilizzabili (ed in una maniera “semplice”) Spamhaus ha pertanto iniziato a mettere a disposizione dei propri utenti un feed BGP, attraverso cui fornisce i dati presenti in DROP+EDROP insieme con i singoli IP dei sistemi come quelli sopra descritti estratti da SBL. Al pari di RPZ, anche questo è al momento un servizio che Spamhaus offre ai soli clienti e non all’utenza generica; ma se già avete accesso al datafeed con tutta probabilità potete richiedere l’attivazione di BGPf già ora: senza nemmeno prendervi la briga di scriptare alcunchè, tutto ciò di cui avete bisogno è un router (o un firewall) che supporti BGP…

Read Full Post »

Piccola ricerca….

Chi volesse compilare questa form ha i miei ringraziamenti in anticipo…

Read Full Post »

« Newer Posts - Older Posts »

%d bloggers like this: