Archivi tag: file hosts

DNS Spoofing a fin di bene

Networking, Sicurezza, SO: Linux, , , ,

Facendo una rapida ricerca su Google si evince che il DNS Spoofing è una tecnica di cracking che rientra nella categoria MITM (Man in The Middle), tramite la quale “si fa credere” al PC della vittima che il sito X (ad esempio www.facebook.com) risponde all’indirizzo IP della macchina dell’aggressore (ad esempio 192.168.1.5). Se oltre a ciò sulla macchina dell’aggressore è presente anche una replica della home di facebook (ottenuta, ad esempio, mediante wget), le credenziali della vittima potranno essere facilmente individuate, a meno di messaggi HSTS (connessione non sicura/sito non attendibile) e di utenti più smaliziati (assenza del “lucchetto” di fianco alla barra degli indirizzi del browser).

Essa può essere realizzata seguendo 2 alternative: l’inserimento di record ad hoc all’interno del file hosts della macchina vittima oppure modificando il suo nameserver primario (dalle impostazioni di rete). In quest’ultimo caso parliamo di DNS Hijacking.

dnsspoofing

Dopo questa breve premessa è comunque utile fare una precisazione: il DNS Spoofing non è sempre sinonimo di cracking. Infatti, basti pensare al caso in cui l’ISP decide di “bloccare” l’accesso ad un sito per via dei suoi contenuti, agendo direttamente sui propri nameserver in modo da creare una mappatura statica indirizzo IP/FQDN che rimanda ad una pagina Web specifica, in cui viene notificato all’utente il blocco in atto (con eventuale registrazione degli indirizzi delle macchine che tentano di accedervi).

Un altro caso di utilizzo “bonario” della tecnica in questione riguarda il “blocco” di domini che veicolano notoriamente spyware, adaware e malware di ogni tipo. In questo post vi mostrerò come configurare il nameserver locale (realizzato grazie a dnsmasq, vedi qui per ulteriori dettagli) in modo da ottenere il blocco dei suddetti domini, semplicemente facendoli puntare a 127.0.0.1 (localhost).

Occorre precisare, inoltre, che tale tecnica funziona solo ed esclusivamente nel caso in cui gli utenti non abbiano privilegi di amministrazione sulle loro macchine e che quindi non siano in grado di modificare le impostazioni delle schede di rete (lasciando come nameserver primario quello da noi configurato). In aggiunta, la manutenibilità dei siti da bloccare è di gran lunga superiore rispetto a quella offerta dai blocchi mediante file hosts di ciascuna macchina (poichè, nel primo caso, si ha a disposizione una lista “centralizzata” di domini malevoli).

Ma passiamo alla configurazione vera e propria di dnsmasq. I domini che intendiamo bloccare sono i seguenti:

doubleclick.net
scorecardresearch.com
criteo.com
imrworldwide.com

per cui le direttive da aggiungere a dnsmasq saranno le seguenti:

address=/doubleclick.net/127.0.0.1
address=/scorecardresearch.com/127.0.0.1
address=/criteo.com/127.0.0.1
address=/imrworldwide.com/127.0.0.1

da notare che verranno bloccati non solo i suddetti domini, ma anche tutti gli eventuali sottodomini ad essi riconducibili.

Riavviamo dnsmasq:

root@ubuntubox:~# service dnsmasq restart

e testiamo il funzionamento del blocco appena configurato, pingando uno dei domini che intendiamo “dirottare” su localhost:

root@ubuntubox:~# ping criteo.com
PING criteo.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.035 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.037 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.036 ms

ed anche qualche sottodominio:

root@ubuntubox:~# ping pippo.criteo.com
PING pippo.criteo.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.051 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.040 ms
64 bytes from localhost (127.0.0.1): icmp_req=4 ttl=64 time=0.039 ms

Infine, diamo una ripulita ai PC degli utenti utilizzando software specifici quali Malwarebytes (in modo da eliminare il problema alla radice), continuando anche a monitorare le hit del proxy alla ricerca di eventuali domini “sospetti”.

Alla prossima.

PS: tale tecnica, a mio avviso, è più performante (ma meno malleabile) rispetto al blocco realizzato mediante l’uso di un proxy (ad esempio squid + squidguard), poichè agendo direttamente sul meccanismo di risoluzione dei nomi, si crea meno overhead e si ottengono tempi di risposta molto più ridotti.

IPSOA e rotte statiche

SO: Windows XP, , , , , ,

Recentemente ho installato un piccolo server in uno studio commercialista, su cui far girare un particolare applicativo sviluppato per la gestione della contabilità (et similia), il cui nome è IPSOA.

ipsoa.jpg

Per ragioni che non sto qui a spiegarvi, è stato deciso di inibire la connettività ad Internet del server in questione, ragion per cui non è stato impostato alcun gateway per l’accesso alla rete pubblica. Rimaneva un problema però, ovvero l’aggiornamento del software IPSOA.

Come si è proceduto dunque? Semplice, impostando delle rotte statiche che consentono di contattare gli indirizzi necessari per il download degli aggiornamenti. Ora, non conoscendo a priori tali indirizzi, mi son dovuto armare di uno sniffer (Wireshark) ed ho proceduto con un’analisi del traffico generato da IPSOA dopo aver cliccato sul pulsante per il download degli update.

Per prima cosa, il software in questione contatta il sito www.ipsoa.it per testare la connettività ad Internet.

Da un semplice ping ho constatato che l’hostname www.ipsoa.it risponde all’indirizzo IP pubblico 89.118.245.220.

Ho dunque proceduto con la creazione di una entry DNS nel file hosts di Windows, presente nella directory Windows->System32->drivers->etc. Per modificare tale file basta aprirlo con notepad (alias blocco note).

Inserite il seguente record:

89.118.245.220 www.ipsoa.it

Ora che esiste la entry DNS nel file hosts, possiamo procedere con la creazione della rotta statica per l’accesso al sito www.ipsoa.it

Apriamo un prompt dei comandi e digitiamo:

C:\> route -p add 89.118.245.220 mask 255.255.255.255 <ip del nostro gw>

Così facendo, attraverso la flag -p, la rotta statica verrà inserita all’interno del registro di Windows in modo permanente, e non dovrà essere ricreata ad ogni riavvio del sistema.

Verifichiamo che la rotta sia effettivamente stata salvata digitando il comando:

C:\> route print

e testiamo infine la connettività verso l’indirizzo IP 89.118.245.220 e verso l’hostname www.ipsoa.it (tirando in ballo, in quest’ultimo caso, il file hosts precedentemente modificato).

C:\> ping 89.118.245.220

C:\> ping www.ipsoa.it

Se ai nostri ping segue una reply degli host contattati significa che tutto funziona correttamente.

Eseguiamo la stessa procedura per l’host liveupdate.wki.it, ovvero quello da cui vengono effettivamente scaricati gli aggiornamenti. Esso risponde all’indirizzo IP pubblico 212.239.62.150:

C:\> route -p add 212.239.62.150 mask 255.255.255.255 <ip del nostro gw>

e modifichiamo il file hosts aggiungendo la entry:

212.239.62.150 liveupdate.wki.it

lanciamo un route print ed eseguiamo i ping di rito. Se tutto funziona possiamo effettuare l’aggiornamento di IPSOA, il quale dovrebbe riuscire senza inghippi.

A presto.

NB: è stato possibile seguire questa logica poichè abbiamo a che fare con indirizzi IP statici su cui non è applicato il roud robin per la risoluzione dei nomi.