Scrittura · 1 apr 2020
Traffic shaping con iptables e tc
Limitare la banda in uscita per indirizzo IP del client
Il mese scorso ho ricevuto un avviso automatico che segnalava un uso eccessivo di banda, di solito un segno di guai. Quando succede, dovresti seguire una procedura standard di gestione degli incidenti, cercando di isolare la fonte del traffico prima di spegnerla. La causa di questo incidente però non era quella che mi aspettavo... e richiedeva un tipo di mitigazione diverso da un semplice blocco.
Avviso di banda eccessiva
Quando gestisci dei server noti che il traffico internet segue di solito schemi prevedibili. Proprio come il traffico reale sulle strade, ci sono orari regolari in cui è intenso e orari in cui è tranquillo.
Lo schema prevedibile permette di rilevare automaticamente le anomalie. Come un ingorgo in autostrada a un'ora insolita può essere il risultato di un incidente, oscillazioni inattese del traffico internet possono indicare un incidente nel cyberspazio.
Isolare la fonte
La prima cosa da fare è trovare la fonte del problema. Lo fai analizzando l'anomalia così:
- Stabilisci se il traffico extra è in entrata o in uscita (upload o download?)
- Stabilisci gli indirizzi IP di origine e di destinazione associati (quale server è coinvolto? Dove va o da dove arriva il traffico?)
- Stabilisci il tipo di traffico (e-mail, web o qualcos'altro?)
Per farlo devi ispezionare i grafici del traffico, che di solito distinguono chiaramente ingresso e uscita. Poi devi cercare gli indirizzi IP coinvolti. Può voler dire guardare altri grafici (dei singoli server) e statistiche dentro switch, router e server. Poi guarda l'uso della CPU e i file di log per capire quale applicazione è coinvolta, come la posta o il web. Più è grande l'anomalia, più è facile trovarla.
Potresti essere tentato di eliminare l'anomalia appena l'hai trovata, fermando subito il traffico associato. Ma dovresti davvero tenerla in vita (almeno un po' più a lungo) per imparare da essa il più possibile.
Usa uno strumento come iftop per vedere una panoramica in tempo reale dell'uso della banda per ogni indirizzo IP connesso. È molto utile per capire cosa sta succedendo, soprattutto in combinazione con i file di log (che collegano l'indirizzo IP ai singoli account).
Una causa insolita
Il server che produceva l'uso eccessivo di banda era un server di posta. Spesso vengono presi di mira dagli hacker per trasformarli in server di inoltro dello spam. Può succedere in vari modi, di solito perché gli spammer ottengono un login valido. Ne risulta molto traffico in uscita, perché gli spammer spediscono un sacco di e-mail. Se un'ondata di spam parte dal tuo server, probabilmente lo vedi nei log, perché i messaggi di spam spesso rimbalzano e le code di posta si riempiono in fretta. Diventa subito un disastro, ma su questo server non c'era nessun disastro: solo un sacco di banda usata in modo insolito.
La posta (e lo spam) si invia con il protocollo SMTP, ma il traffico sulla porta SMTP di questo server era del tutto normale. Era molto strano, perché significava che il traffico eccessivo veniva da qualcos'altro. Ma da cosa? Dopo aver analizzato vari file di log sul server di posta ho stabilito che il protocollo responsabile era IMAP. In qualche modo un client collegato al server di posta con IMAP generava quantità eccessive di traffico di rete. IMAP è un protocollo usato per leggere la posta, non per inviarla, il che rende molto rare le anomalie legate a IMAP.
Analizzando il log del server di posta ho trovato l'utente che causava il traffico. Ho contattato il cliente per chiedergli se avesse notato qualcosa di strano dalla sua parte. Non a caso, aveva notato che il suo computer era un po' lento ultimamente.
Un ciclo di sincronizzazione di Microsoft Outlook
Dopo un po' di tentativi al telefono, abbiamo stabilito che qualcosa faceva sì che Microsoft Outlook sincronizzasse in continuazione le cartelle IMAP, in un ciclo. Questo faceva scaricare al suo computer l'intero contenuto della casella di posta, ancora e ancora! Siccome la sua casella superava i 40 gigabyte, il traffico era notevole. A quanto pare è causato da un bug di Microsoft Outlook, e purtroppo non c'è una soluzione semplice.
Mitigare con il traffic shaping
Mi sono trovato davanti a una scelta difficile: bloccare il cliente (normale, legittimo, pagante) oppure lasciar continuare il traffico eccessivo (con costi seri per il provider di rete). Bloccare utenti legittimi che gestiscono la loro attività con la posta è una pessima idea, ma lasciar continuare il traffico eccessivo è un'idea altrettanto cattiva. Per fortuna ho trovato un modo alternativo per ridurre il traffico eccessivo continuando a permettere al cliente di accedere alla sua posta (con la sua fidata, ma difettosa, app Outlook).
Traffic Shaping
Come tecnica di gestione della banda, puoi usare il traffic shaping per ritardare alcuni (o tutti i) pacchetti di dati e farli rientrare in un profilo di traffico desiderato. Se lo applichi, stai letteralmente dando forma ai grafici del traffico, da qui il nome.
Questa tecnica non è priva di controversie, perché è l'opposto del tanto celebrato principio della "neutralità della rete". Con il traffic shaping puoi bloccare di proposito o rallentare (o far pagare di più) specifici tipi di traffico. Per principio sono contrario a tutto ciò che danneggia la neutralità della rete, ma in questa situazione specifica non avevo alternative praticabili. Dovevo rallentare seriamente il traffico di posta di questo cliente, riducendo la banda e continuando a dargli accesso al suo account.
Implementare il traffic shaping
Per dare forma al traffico devi fare due cose:
- marcare il traffico: vuoi influenzare solo un certo traffico di rete, in questo caso l'accesso IMAP di un dato client. Il resto del traffico non deve essere toccato. Si fa marcando i pacchetti che hanno determinate caratteristiche, come l'IP del client o i numeri di porta
- applicare la politica di shaping: con strumenti di controllo del traffico come 'tc' applichi poi la politica di shaping al traffico marcato. Ci sono vari modi, ma uno comune è lavorare con i cosiddetti "Hierarchy Token Buckets" o HTB.
Hierarchy Token Buckets (HTB)
In linea di principio un token bucket è simile all'idea di limitare il numero di passeggeri in un viaggio in treno distribuendo solo un numero fisso di gettoni disponibili. Quando i passeggeri (o i pacchetti di dati) salgono sul treno (o sulla rete) prendono un gettone. Quando scendono (o raggiungono la destinazione) il gettone viene restituito. Con il principio del token bucket puoi controllare la quantità di traffico simultaneo in un sistema.
Puoi implementare questo principio con gli strumenti di rete "tc" (traffic control) in combinazione con "iptables". Puoi usare uno script per impostare le regole di marcatura e di applicazione. Online trovi vari esempi: io ho usato questo di Julien Vehent.
Conclusione
A volte le anomalie di rete non sono ciò che ti aspetti, perciò dovresti sempre prenderti il tempo di indagare! Bloccare il traffico alla cieca è un metodo rozzo: a volte devi affinare i tuoi metodi per mitigare i problemi.
Applicare tecniche di filtraggio poco ortodosse non è una cosa che mi piace, ma a volte sono l'unico mezzo per raggiungere lo scopo. Sapere cosa stai facendo e perché lo stai facendo è molto importante!