Feeds:
Posts
Comments

Malware aruba.it

Oggi vedo arrivare messaggi contenenti presunte fatture di Aruba.it:

 

From: comunicazioni@staff.aruba.it
Subject: Invio copia bollettino

Gentile cliente,

come da lei richiesto in allegato potrà trovare copia del bollettino postale con cui effettuare il pagamento.

Saluti
______________________________

Aruba S.p.A.

Servizio Clienti – Aruba.it

http://www.aruba.it

http://assistenza.aruba.it

Call center: 0575/0505

Fax: 0575/862000

_______________________________

 

In allegato, un file con nome del tipo 123456789_1234567890.pdf.zip

Guardando l’allegato un po’ più da vicino:

skull@mithrandir:~$ unzip 12345678_1234567890.pdf.zip
Archive: 12345678_1234567890.pdf.zip
inflating: 87654321_0987654321.pdf.pif

skull@mithrandir:~$ file 87654321_0987654321.pdf.pif
87654321_0987654321.pdf.pif: MS-DOS executable

Ovviamente, una occhiata agli header conferma che la mail non viene affatto da Aruba:

Return-Path: <xxxxx@hotel.de>
Received: from [80.86.156.104] (unknown [80.86.156.104])
	by mta1.spin.it (Postfix) with ESMTP id xxxxx
	for <xxxxx>; Mon, 21 Jul 2014 13:xx:xx +0200 (CEST)
Received: from [59.22.31.20] (helo=xxxxx.xxxxx.net)
	by  with esmtpa (Exim 4.69)
	(envelope-from )
	id xxxxx
	for xxxxx; Mon, 21 Jul 2014 12:xx:xx +0100
Received: from [109.26.59.81] (helo=xxxxx.xxxxx.su)
	by  with esmtpa (Exim 4.69)
	(envelope-from )
	id xxxxx
	for xxxxx; Mon, 21 Jul 2014 12:xx:xx +0100
Date: Mon, 21 Jul 2014 12:xx:xx +0100
From: comunicazioni@staff.aruba.it
To: <xxxxx>
Subject: Invio copia bollettino


Al momento della ricezione, la lista degli AV che lo riconoscono per quel che è è desolantemente scarna, come di consueto:

 

VirusTotal

 

All’occhio…

Months ago I wrote a serie of articles (Italian only) about why relying on an AntiVirus only is far from being an effective approach to network safety nowadays. Today, I stumbled upon this piece, where Brian Dye, Symantec’s senior Vice President for Information Security apparently says «AntiVirus is dead».

To quote Mark Twain, I think the report of AV death is an exaggeration: nobody should -in my opinion- turn their AV off because it’s not effective anymore. It is certainly true, however, that this approach cannot be the only one in place if you plan to combat malware on your network effectively.

In the fourth part of the series above I already suggested using lists of Command & Control IPs to create nullrouting or firewall entries to inhibit network traffic trying to reach “bad resources”. I also said how one of these lists is available from Spamhaus (as that’s the one I’ve been using) and how they provide this list in the form of a BGP feed you can configure directly in your border router(s).

Whatever the list you chose and however you’re feeding it to your router, you’re going to face a problem: how to monitor what is being nullrouted and what the supposedly infected system is trying to do?

Here is what I did and how you can use a normal linux system to dump and log the blocked traffic and hijack the HTTP sessions (that are by far the most interesting ones) to obtain more intel about the infections.

Continue Reading »

I spent a good part of the last few days trying to debug a very weird problem involving postfix and opendkim, so I thought it was a good idea to write the entire experience down for anybody who might be encountering the same (or a similar) problem. This was probably the weirdest misbehaviour I managed to trigger without involving any real bug…

 

On a system I control, I installed opendkim for signing only and configured postfix to interact with it: installation was smooth as usual and everything was deployed in an hour or two. The emails sent by the system are partly anonymized and some headers are therefore stripped before the mail goes out. For this reason, DKIM was configured to sign only some of the headers (and not all of them) or the signatures would fail to validate for remote users.

I sent a few test emails to Gmail and everything seemed to be fine: mail signed, signature header as expected, Google verifying the signature correctly and so on. So I told other users of the same server that the feature was enabled and to poke me in case something was wrong. Immediately one user wrote back saying he wasn’t seeing any signature at all in the emails he was sending.

I checked the logs for his email and found this:

Mar 24 12:22:56 myserver opendkim[32082]: 0CA2F2F1: can’t determine message sender; accepting

The presence of a “From” or “Sender” header within the email is mandatory for DKIM, otherwise the mail can’t be signed; this message was saying that the mail had none and was therefore refusing to sign it.

Easy.

 

Continue Reading »

OK, this is ridiculous…

Screen Shot 2014-02-16 at 16.01.39

Ogni tanto capita di scrivere qualcosa di lungo in risposta ad una domanda posta in qualche newsgroup/ML/forum/whatever.
Visto che oramai son scritte, tantovale riciclarle qui, dove magari possono essere integrate e corrette nel tempo (e magari popolano anche queste pagine altrimenti scevre di novità)…Inizio con questa, passata su it.comp.os.linuxsys:
On 03/02/14 10:05, Roberto Tagliaferri wrote:

Hola, capita che qualche cliente si becchi uno worm di quelli che invia le
credenziali email per spammare.
Il server ovviamente lo fa inviare (ha login e password corretti) e le
botnet nuove sono abbastanza intelligenti da non inviare troppe email
insieme (per non sovraccaricare il server) e magari le spediscono fuori
orario ufficio (così vengono beccati dopo qualche giorno).
Oltre a decapitare il cliente (è comunque una azione postuma) che si può
fare?
Avevo pensato ad un controllo che bloccasse invii da classi di ip diverse
(chessò, invii da 10 classi ip differenti in 12 ore) ma è un approccio forse
un po’ troppo grossolano (c’è comunque un filtro di fail2ban o un milter
adatto?)
Con postfix che si può fare?
Continue Reading »

Un altro pippone non lo riscrivo, ma oggi è un’occasione per rilinkare quello già scritto a suo tempo, nonché per prendere atto del fatto che ‘sto blog oramai ha passato i 5 anni di vita. Agonizzante e sofferta, ma vita.😛

Di depeering e altre bazzecole

(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?

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: