Altro che Social Engineering! Qui basta un (dis)onesto Social Manoval!

Ecco la foto di un giornalista intervistato da una televisione americana.
Probabilmente si trova in una sala stampa, e quelle credenziali per l’accesso a due distinte reti wireless, così stupidamente appiccicate al muro e così in bella vista, dovrebbero servire a giornalisti e fotografi (i due distinti SSID suggeriscono in tal senso), per connettersi via Internet alle rispettive redazioni e inviare loro, rapidamente, notizie e immagini.
Anche la scelta delle password non sembra delle migliori, ma sorvoliamo pure!

Se non vi è mai capitato di imbattervi in qualcosa di simile in un ufficio italiano, vi invito a dare un occhiata alla massa di postit giallini che in genere decorano i monitor dei pc nei vari uffici di stato, regioni, province (tanto non scompariranno mai), comuni, usl, banche, assicurazioni, sindacati, poste, in cui avrete prima o poi il piacere di trascorrere un po’ del vostro tempo.
Per non parlare poi degli uffici delle aziende private e degli studi professionali.

Un falso addetto alla manutenzione di qualcosa o alle pulizie potrebbe facilmente fare incetta di credenziali oltre a installare rapidamente backdoors sui vari computers in rete.

Send post as PDF to

Un prerequisito piuttosto importante è che la frequenza nel Kernel Timer della AMI prescelta sia impostato a 1000HZ, e così non resta che sincerarsene:

$ sudo cat /boot/config-`uname -r` | grep HZ
...
CONFIG_HZ_1000=y
CONFIG_HZ=1000

I comandi riportati di seguito dettagliano passo per passo la parte relativa alla installazione di Asterisk IP PBX sulla nostra micro istanza di un Amazon AWS EC2 Cloud Server.

Occorre accedere via SSH alla micro istanza, ed aggiornare il Server:

$ sudo yum update

Loaded plugins: fastestmirror, priorities, security, update-motd
Loading mirror speeds from cached hostfile
* amzn-main: packages.eu-west-1.amazonaws.com
* amzn-updates: packages.eu-west-1.amazonaws.com
Setting up Update Process
No Packages marked for Update

Quindi navigare fino alla directory /usr/src, e qui scaricare i sorgenti di Asterisk (addirittura la prima Release Candidate 10.4.0), usando wget:

$ cd /usr/src
$ sudo wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-10.4.0-rc1.tar.gz
--2012-04-21 21:15:47--  http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-10.4.0-rc1.tar.gz
Resolving downloads.asterisk.org... 76.164.171.233, 2001:470:e0d4::e9
Connecting to downloads.asterisk.org|76.164.171.233|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 25018992 (24M) [application/x-gzip]
Saving to: “asterisk-10.4.0-rc1.tar.gz”

100%[=============================================================================>] 25,018,992  1.12M/s   in 17s

2012-04-21 21:16:03 (1.44 MB/s) - “asterisk-10.4.0-rc1.tar.gz” saved [25018992/25018992]

Da notare la notevole rapidità con cui è avvenuto il download:

Occorre ora installare i necessari packages per la compilazione di Asterisk:

$ sudo yum groupinstall ‘Development Tools’
$ sudo yum install -y ncurses-devel libtermcap-devel zlib-devel libtool sqlite-devel.x86_64

Scompattare ed estrarre i files dal tarball di Asterisk:

$ sudo tar xvzf asterisk-10.4.0-rc1.tar.gz

Installare Asterisk:

$ sudo ln -s asterisk-10.4.0-rc1 asterisk
$ cd asterisk
$ sudo ./configure –disable-xmldoc
$ sudo make menuconfig
$ sudo make
$ sudo make install
$ sudo make samples
$ sudo make config
We could not install init scripts for your distribution.
$ echo $?
0

Ora che abbiamo il nostro Amazon AWS configurato come micro istanza ed Asterisk installato sopra, possiamo dedicarci a configurare un service provider.

Per questo test, anche per fare qualche esperimento sulla connettività, la latenza, ed altri possibili problematiche derivanti da siffatta interazione, ho optato per mantenere lo stesso account Messagenet utilizzato in precedenza per l’esperimento di Asterisk Cloud su Dnshosting, in modo da poterne utilizzare il numero geografico per le chiamate inbound.

Di conseguenza ci dovremo connettere al nostro cloud server Asterisk via SSH ed editare il file sip.conf per crearvi, tra l’altro, le voci relative al provider voip (Messagenet) da utilizzare, e ad un softphone per il mio Android, ad esempio così:

[general]
port=5060
localnet = 10.226.234.0 / 255.255.254.X
externip = 54.247.165.170
nat=yes
disallow= all
allow=alaw
allow=ulaw
context=ael-default
register => XXXXXX:YYYYYY@sip.messagenet.it:5061/0437xxxxxxx

[messagenet]
type=peer
host=sip.messagenet.it
fromuser=XXXXXX
defaultuser=XXXXXX
secret=YYYYYY
realm=sip.messagenet.it
qualify=no
insecure=port,invite
port=5061
disallow=all
allow=alaw
allow=ulaw

[3cxandroid]
type=friend
callerid=-mySmart<201>
secret=quellochetipare
language=it
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=alaw
allow=ulaw

e poi anche il file extensions.ael, ad esempio così:

context ael-default {
_0437xxxxxxx => {
Wait(1);
Answer;
Set(TIMEOUT(digit)=5);
Set(TIMEOUT(response)=10);
Dial(SIP/3cxandroid,30,tTr);
Hangup();
};
};

Dopodiché, una volta lanciato Asterisk, il nostro centralino virtuale su Amazon EC2 risulterà pronto a ricevere chiamate, e a trasferirle via internet verso il client SIP del mio smartphone Android.

*CLI>   == Using SIP RTP CoS mark 5
-- Executing [0437xxxxxxx@ael-default:1] Wait(”SIP/messagenet-00000000″, “1″) in new stack
– Executing [0437xxxxxxx@ael-default:2] Answer(”SIP/messagenet-00000000″, “”) in new stack
– Executing [0437xxxxxxx@ael-default:3] Set(”SIP/messagenet-00000000″, “TIMEOUT(digit)=5″) in new stack
– Digit timeout set to 5.000
– Executing [0437xxxxxxx@ael-default:4] Set(”SIP/messagenet-00000000″, “TIMEOUT(response)=10″) in new stack
– Response timeout set to 10.000
– Executing [0437xxxxxxx@ael-default:5] Dial(”SIP/messagenet-00000000″, “SIP/3cxandroid,30,tTr”) in new stack
– Called SIP/3cxandroid
– SIP/3cxandroid-00000003 is ringing
– SIP/3cxandroid-00000003 answered SIP/messagenet-00000002
== Spawn extension (ael-default, 0437xxxxxxx, 6) exited non-zero on ‘SIP/messagenet-00000000′


Send post as PDF to

Dato che Amazon, molto gentilmente peraltro, mette a disposizione gratuitamente una cosidetta “micro instance” AWS (Amazon Web Service) per la durata di un intero anno, tale mi è senbrata una buona occasione per effettuare un test, puntando nello specifico l’attenzione su quel particolare tipo di AWS che prende il nome di EC2, o Amazon Elastic Compute Cloud, ovvero la versione Amazon per un server in the cloud.

Occorre, cosa ampiamente prevedibile del resto, iscriversi a qualche servizio.
Se non si possiede già un account AWS, bisognerà ottenerne uno. L’account AWS darà accesso alla totalità dei servizi possibili, ma vi verrà addebitato esclusivamente il consumo delle risorse effettivamente utilizzate. Una micro istanza sarà sempre disponibile gratuitamente per l’arco di un anno, con dei limiti di esercizio ben stabiliti oltre i quali l’utilizzo della micro istanza comporta un costo.

I termini di servizio entro i quali l’uso di una micro-istanza sono gratuiti (per un anno) sono i seguenti:

Per creare un account AWS, occorre visitare http://aws.amazon.com e fare click su “Sign Up Now”, dopodiché occorre seguire le istruzioni che appariranno sullo schermo.

E’ opportuno precisare a questo punto che, per poter proseguire con l’ impostazione dell’account, purtroppo si rende necessario fornire un numero di carta di credito valido. L’adozione di questa misura è dettata dal possibile sforamento dei limiti di traffico imposti ad una micro-istanza “free”.
I costi d’esercizio proposti da Amazon, in ogni caso, sembrano decisamente economici, sopratutto se del cloud computing si fa un uso intelligente, che è poi il motivo per cui diviene così allettante.
Al contrario dell’hosting tradizionale, chi ne usufruisce può veramente essere in grado di pagare esclusivamente per ciò che consuma.
Consiglio di usare, per questo tipo di test ed altri simili, una postepay visa electron con solo qualche spicciolo accreditato.

Ci verrà richiesta una identificazione tramite chiamata telefonica, che avverrà puntualmente da parte di Amazon sul numero che avremo indicato:

Ci verrà poi notificato per email quando il nostro account è attivo e disponibile.

in questo modo:

Nel creare una istanza, ho scelto il datacenter geograficamente più vicino per poter usufruire (teoricamente) della migliore connessione possibile.

Si presenta a questo punto la necessità di trovare la AMI (Amazon Machine Image) che possa fare al caso nostro.

Una Amazon Machine Image (AMI) contiene tutte le informazioni necessarie ad avviare istanze del nostro software. Per esempio, una AMI può contenere, tipicamente, tutto il software necessario a implementare un completo web server. È possibile lanciare una o più istanze Amazon EC2 a partire da una AMI, e tutte le istanze saranno esattamente identiche.

Amazon Elastic Compute Cloud (Amazon EC2) dà la possibilità di scegliere in maniera flessibile tra un vasto numero di differenti tipi di istanze per venire incontro alle più varie esigenze. Ciascuna istanza fornisce un prevedibile quantità di risorse computazionali dedicate ed il loro consumo viene monetizzato su base oraria.

Per la precisione, di seguito vi sono i vari tipi di istanza disponibili

Standard Instances, adatte ad ogni tipo di applicazione, suddivise a loro volta in.

Small Instance – default*
1.7 GB memory
1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)
160 GB instance storage
32-bit or 64-bit platform
I/O Performance: Moderate

Medium Instance
3.75 GB memory
2 EC2 Compute Unit (1 virtual core with 2 EC2 Compute Unit)
410 GB instance storage
32-bit or 64-bit platform
I/O Performance: Moderate

Large Instance
7.5 GB memory
4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)
850 GB instance storage
64-bit platform
I/O Performance: High
API name: m1.large

Extra Large Instance
15 GB memory
8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)
1,690 GB instance storage
64-bit platform
I/O Performance: High

e poi le Micro Instances

Le Micro instances (t1.micro) forniscono una moderata ma consistente quantità di risorse CPU, i cui termini di servizio ci sono già noti.

Un’ampia selezione di AMIs è resa disponibile direttamente da parte di Amazon e della community sorta intorno a Amazon EC2.

Si può utilizzare la AWS Management Console (all’indirizzo http://console.aws.amazon.com) per andare alla ricerca di AMIs in possesso di criteri specifii e quindi avviare istanze di tali AMIs. Per esempio, ricercare le AMIs che ha fornito direttamente Amazon, le AMIs fornite dalla comunità sorta intorno a EC2, o le AMIs che fanno uso di uno specifico sistema operativo.

Per trovare una AMI adatta:

1. Aprire la console Amazon EC2 all’indirizzo https://console.aws.amazon.com/ec2/.
2. Nel pannello “Navigation”, cliccare AMIs.

Nella sezione “Amazon Machine Images”, nella lista “Viewing”, che mostra tutte le piattaforme (All Platforms,) potremmo fare click su Linux.
In questo esempio, faremo click su Amazon Images per limitare la visualizzazione solo alle AMIs fornite direttamente da Amazon Web Services

Selezioniamo una AMI (in questo caso amzn-ami-pv-2012.03.1.x86_64-ebs) e poi facciamo click su Launch (il pulsante in alto a sinistra).

Abbiamo appena avviato la fase di lancio di una istanza Amazon EC2 usando la AMI selezionata in precedenza. Il lancio di una istanza implica le seguenti operazioni:

• Configurare l’istanza.
• Creare a coppia di chiavi.
• Creare un security group.
• Avviare effettivamente l’istanza.

Dopo aver selezionato una AMI, e aver cliccato su Launch Instance come indicato in precedenza, apparirà la pagina “Create a New Instance”, nominiamola per esempio “Asterisk Cloud Server”.

Accettiamo gli altri valori di defaults su questa pagina, e poi facciamo click su Continue.
Accettiamo pure i valori di defaults presentati nelle successive due pagine, e facciamo click su Continue per ciascuna di esse.
Quando il wizard mostrerà la pagina “Create Key Pair”, seguite i passi illustrati di seguito.

Le istanze Amazon EC2 create a partire da una Public AMI usano una coppia di chiavi pubblica/privata, piuttosto che una password, per autenticarsi. La chiave pubblica è embedded nella nostra istanza. Faremo invece uso della private key per accreditarci in modo sicuro senza dover utilizzare una password. Una volta create le proprie AMIs, si possono adottare altri meccanismi per accedere in modo sicuro alle nuove istanze.

Non avendo ancora mai utilizzato Amazon EC2 e non avendo creato finora alcuna coppia di chiavi, quando il wizard mostra la pagina Create Key Pair, il button Create a new Key Pair verrà selezionato di default.

Nella pagina “Create Key Pair”, nella fattispecie nel box “Enter a name for your key pair”, introducete qualcosa tipo “voiphack_test_key”. Questo sarà il nome del file relativo alla chiave privata associata alla coppia (con una estensione .pem).

Fate Click su “Create & Download your Key Pair”.

Vi verrà ora richiesto di salvare la chiave privata della coppia di chiavi sul vostro sistema.

Salvate la chiave privata in un posto sicuro del vostro sistema ad esempio ~/.ssh, registrandone la locazione.

Il wizard mostrerà poi la pagina “Configure Firewall”, dove andrà creato e configurato un security group.

Un security group ci permette di aprire specifiche porte sulla nostra micro intanza, agendo proprio come un firewall.
In altri termini un security group definisce le regole firewall delle nostre istanze. Tali regole specificano quale traffico di rete in ingresso debba venire inoltrato alla nostra istanza (per esempio accettando il traffico ssh sulla porta 22). Il rimanente traffico viene ignorato. Sarà possibile modificare le regole di un group in qualsiasi momento. Le nuove regole vengono automaticamente imposte a tutte le istanze in esecuzione.

Per rendere possibili connessioni SIP ed SSH, è necessario aprire le porte TCP 22, UDP 5060 ed ancora UDP nel range 10000-20000, range, che essendo molto ampio, potremmo ragionevolmente ridurre a un decimo (dovremo eventualmente poi ricordarci di andare a modificare di conseguenza il file rtp.conf del server), il che implica comunque, ancora, l’apertura di 1000 porte per dialogo vocale basato su RTP.

Nel box “Group Name”, introduciamo qualcosa, tipo my_group.

Nel box “Description”, introduciamo una descrizione per il security group appena creato.

Nel box “Create a New Rule” (Inbound Rules), fare click su SSH, quindi fare click su Add Rule.
Lo stesso vale per SIP e UDP nel range 10000-11000, come stabilito in precedenza.

Una volta che l’ istanza è diventata operativa e andata in esecuzione le viene assegnato un indirizzo IP statico interno (nel caso particolare 10.48.206.47).

Ma perché il nostro cloud server diventi realmente utile gli dovremo attribuire un indirizzo tramite il quale essere raggiungibile dall’esterno. Amazon lo chiama Elastic IP ed è anch’esso gratuito e va associato ad una istanza in esecuzione.

Clicchiamo a sinistra su Elastic IP, allochiamo un nuovo IP (in questo caso 54.247.165.170), ed associamolo alla istanza.

l’indirizzo IP ottenuto ed associato è ora risolvibile nel nome di ec2-54-247-165-170.eu-west-1.compute.amazonaws.com

Dato che il Security Group precedentemente associato con la nostra micro instanza lo permette, ora dovremmo essere in grado di connetterci all’istanza in esecuzione. La connessione prevista all’ istanza deve avvenire via SSH usando la coppia di chiavi Key Pair creata in precedenza

Nell’ esempio, mi sto connettendo alla istanza attraverso una abituale linux box. La coppia di chiavi si chiama voiphack_test_key.pem e si trova nella directory .ssh della mia home directory, in compagnia del file known_hosts.

Al prompt, digito:

# ssh -i .ssh/voiphack_test_key.pem ec2-user@54.247.165.170
Last login: Sat Apr 21 15:56:46 2012 from adsl-ull-142-196.49-151.net24.it

__|  __|_  )
_|  (     /   Amazon Linux AMI
___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2012.03-release-notes/
[ec2-user@ip-10-48-206-47 ~]$

54.247.165.170 rappresenta l’ IP address associato con la micro istanza ed ec2-user l’utente (di default) con cui ci dovremo loggare.  Un modo alternativo veloce per collegarsi alla propria istanza consiste nel selezionarla, e con il tasto destro selezionare “Connect”.

Oltre alla possibilità di utilizzare un client stand-alone, per il quale viene suggerito il comando che abbiamo già utilizzato, vi è la possibilitàa di utilizzare un client ssh java senza dover uscire dall’ambiente del browser.

Assicuratevi che le permissioni relative al file <Key Pair>.pem file siano impostate a 400.  In caso contrario la connessione verrebbe negata.

Giunti fin qui possiamo dire di aver creato con successo una micro istanza Amazon AWS, di averle assegnato un indirizzo IP Statico, di aver aperto le necessarie porte nel firewall, e di essere infine connessi alla nostra istanza utilizzando SSH.

Nel successivo post la seconda parte dell’articolo, dove verrà trattata la parte relativa alla installazione di Asterisk IP PBX sulla nostra micro istanza.

Send post as PDF to

La prima soluzione alternativa adottabile sfrutta l’ SSH Port Forwarding, che abbiamo già incontrato in precedenza:

da client:

user@client ~ $ ssh -L1111:192.168.0.1:22 user@firewall

aperta un’altra shell su client:

user@client ~ $ ssh -p 1111 user@localhost
Last login: ...
user@interno1 ~ $

ed il problema è risolto. Ma cosa comporta questo metodo nel caso in cui gli hosts cui si vuole accedere siano numerosi? Diventa necessario aprire un equivalente numero di sessioni sul firewall, ciascuna per il forwarding verso una differente porta locale, oltre a dover ricordare precisamente le relazioni tra host target e porta locale:

user@client ~ $ ssh -L1111:192.168.0.1:22 user@firewall
user@client ~ $ ssh -L1112:192.168.0.2:22 user@firewall
user@client ~ $ ssh -L1113:192.168.0.3:22 user@firewall

Aumentando il numero di hosts cui accedere ovviamente le cose si complicano.

Ma vi è pure un altro inconveniente, che si presenta quando vi sia la necessità di connettersi ad un firewall differente, riutilizzando ad esempio ancora la porta 1111 per il forwarding verso qualche host interno:

client:~$ ssh -L1111:172.16.0.17:22 anotheruser@anotherfirewall
client:~$ ssh -p 1111 root@localhost
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
..................
Host key verification failed.

Una seconda soluzione si basa su una particolare configurazione DNAT, impostando il forwarding, tramite iptables, direttamente sul firewall, in modo che connessioni a porte differenti siano inoltrate a hosts interni differenti.

Assumendo che sul firewall, l’interfaccia su Internet sia 85.113.155.115:

firewall:~# iptables -t nat -A PREROUTING -p tcp -d 85.113.155.115 --dport 1111 -j DNAT --to-destination 192.168.0.1:22
firewall:~# iptables -t nat -A PREROUTING -p tcp -d 85.113.155.115 --dport 1112 -j DNAT --to-destination 192.168.0.2:22
firewall:~# iptables -t nat -A PREROUTING -p tcp -d 85.113.155.115 --dport 1113 -j DNAT --to-destination 192.168.0.3:22

Il vantaggio in questo caso consiste nel fatto che le associazioni divengono permanenti e non necessitano più di essere impostate sul client locale.
Essendo le associazioni permanenti diviene inoltre possibile definire e dare un nome a ciasuna connessione nel proprio file di configurazione ssh (ad es. ~/.ssh/config):

# cat ~/.ssh/config
Host interno1
HostName 85.113.155.115
Port 1111
User someuser

Host interno2
HostName 85.113.155.115
Port 1112
User someuser
...

in tal modo si può utilizzare ad esempio:

# ssh interno1

ed accedere direttamente all’host interno 192.168.0.1.

Tuttavia, per adottare questo metodo occorre disporre di un accesso in qualità di utente root al firewall per modificarne la configurazione, cosa che potrebbe anche non essere permessa. Questo metodo significa anche l’apertura di un certo numero di porte esterne sul firewall, operazione in generale non desiderabile.

Terza soluzione tramite ProxyCommand

Tra le molte opzioni di SSH ve ne è una chiamata ProxyCommand, particolarmente adatta al nostro scopo. Consiste essenzialmente nello specificare un comando che SSH utilizzerà come un canale di trasporto per connettersi all’host di destinazione. Anziché utilizzare TCP, dove l’ I/O avviene tramite un network socket, scrittura e lettura avverranno rispettivamente tramite standard input e standard output del comando specificato. Tale comando dovrà infine convertire i propri stdin ed stdout in una reale connessione di rete ad un host terminale. In altre parole, un comando che si comporti da un lato come cat ma sia in grado di connettersi ad un network socket e trasportare dati in entrambe le direzioni. Come è facile indovinare, questo comando è netcat.

Ecco come l’opzione ProxyCommand potrebbe essere implementata:

# cat ~/.ssh/config
Host interno1
User root
ProxyCommand ssh user@85.113.155.115 'nc 192.168.0.1 22'

Impartendo “ssh interno1″, viene eseguito ProxyCommand, ed in tal modo viene stabilita una connessione con la macchina firewall, e da quest’ultima viene lanciato un netcat relativo all’ host interno1. Sul firewall, stdin ed stdout di netcat sono connessi al processo genitore sshd, che a sua volta si trova connesso via TCP al comando ssh del client. Ciò che si ottiene è effettivamente una connessione bidirezionale tra stdin/stdout del client ssh locale e la porta TCP 22 dell’ host con indirizzo 192.168.0.1 (interno1). Possiamo verificarlo lanciando il comando stand-alone:

# ssh user@85.113.155.115 'nc 192.168.0.1 22'

La risposta arriverà direttamente dal daemon SSH di 192.168.0.1.

Una recente introduzione implementa il ‘netcat mode’ direttamente in SSH (dalla versione 5.4): “ssh -W host:port [user@]hostname”.
Questo permette, ad esempio, l’utilizzo diretto di ssh come ProxyCommand per l’instradamento di connessioni attraverso servers intermedi.

Si potrebbe pertanto usare qualcosa di simile

# cat ~/.ssh/config
Host interno1
User root
ProxyCommand ssh -W 192.168.0.1:22 user@85.113.155.115


Send post as PDF to

ipset è una estensione per iptables che permette la creazione di regole firewall applicabili contemporaneamente ad interi insiemi di indirizzi. A differenza di quanto avviene nelle normali catene iptables, che sono memorizzate e traversate linearmente, i sets sono memorizzati in strutture dati indicizzate, caratteristica che ne rende la consultazione molto efficiente, anche in presenza di sets voluminosi.

Oltre che in situazioni dove è facile immaginarne l’utilità, come il blocco di lunghe liste di “bad” hosts senza doversi preoccupare dell’eccessivo impiego di risorse di sistema o della congestione di quelle di rete, ipset offre anche un nuovo approccio a determinati aspetti inerenti la progettazione di un firewall, semplificandone la configurazione.

ipset è un package presente in molte distribuzioni, ma solo come raccolta di tools, per cui ho preferito ignorarlo ed installare (sotto Linux Mint) i packages xtables-addons-common ed xtables-addons-source.
E successivamente impartire

# module-assistant auto-install xtables-addons-source

per ottenere un ipset funzionale.

Prima di proseguire è doveroso spendere un po’ di tempo a rinfrescare alcuni concetti fondamentali di iptables.

In sintesi, la configuratione di un firewall iptables consiste di un set di “chains” built-in (raggruppate in quattro “tables”) che contengono ciascuna una lista di regole o “rules”.

Per ciascun pacchetto, in ciascuna fase del suo trattamento, il kernel consulta la chain appropriata per determinarne il destino.
Le chains vengono consultate in rigoroso ordine, basato sulla direzione del pacchetto (remoto->locale, remoto->remoto oppure locale->remoto) e la sua fase corrente di trattamento o processing (prima o dopo il “routing”).

Il pacchetto viene confrontato con ciascuna delle regole della chain, nell’ ordine, fino a che non viene trovata una corrispondenza. Una volta che ciò avviene, viene intrapresa la azione specificata nel target della regola.
Se viene invece raggiunta la fine della chain senza trovare una corrispondenza, viene intrapresa la azione target di default per la catena, o policy.

Una chain non è altro che una lista ordinata di regole, ed una regola non è altro che una combinazione corrispondenza/target.
Un semplice esempio di corrispondenza è “TCP destination port 25″.
Un semplice esempio di target può essere “scarta il pacchetto” (DROP).
I targets possono anche redirigere ad altre chains definite dall’utente, cosa che fornisce un meccanismo per raggruppare e suddividere le regole seguendo una logica.
Ciascun comando iptables destinato a definire una regola, corto o lungo che sia, è composto di tre parti fondamentali che specificano la table/chain, la corrispondenza (match) ed il target

Per creare una completa configurazione firewall, occorre di fatto mandare in esecuzione una serie di comandi iptables, in uno specifico ordine.

ipset
ipset è una “match extension”, cioè una estensione basata sulla definizione di corrispondenze, per iptables.
Per poterla usare è prima necessario creare e popolare dei “sets” univocamente chiamati utilizzando il tool a linea di comando ipset, e successivamente fare riferimento a tali sets in una o più regole iptables.

Un set può essere semplicemente una lista di indirizzi archiviata per un efficiente ritrovamento.
Prendiamo come riferimento i seguenti normali comandi iptables destinati a bloccare il traffico in ingresso proveniente da 201.121.12.1 e 202.121.12.2:

# iptables -A INPUT -s 201.121.12.1 -j DROP
# iptables -A INPUT -s 202.121.12.2 -j DROP

La sintassi che specifica la corrispondenza (-s 201.121.12.1) significa “i pacchetti il cui indirizzo di origine è 201.121.12.1″. Per bloccare sia 201.121.12.1 che 202.121.12.2, devono venire definite due distinte regole iptables con due distinte specificazioni di corrispondenza (una per 201.121.12.1 ed una per 202.121.12.2).

In alternativa, i seguenti comandi ipset/iptables servono ad ottenere lo stesso risultato:

# ipset -N myset iphash
# ipset -A myset 201.121.12.1
# ipset -A myset 202.121.12.2
# iptables -A INPUT -m set --set myset src -j DROP

I comandi ipset appena visti creano un nuovo set (myset, del tipo iphash) con due indirizzi (201.121.12.1 e 202.121.12.2).
Il successivo comando iptables fa quindi riferimento al set specificando la corrispondenza con -m set –set myset src, che significa “i pacchetti il cui source header è compreso nel set di nome myset”.
Il flag src significa che la corrispondenza deve avvenire su “source”. Analogamente il flag dst avrebbe spostato la corrispondenza su “destination”, mentre il flag src,dst avrebbe riguardato sia source che destination.

Nella seconda versione è richiesto un solo comando iptables, indipententemente da quanti indirizzi IP siano presenti nel set.
Anche se fossero migliaia, sarebbe necessaria sempre una singola regola iptables, mentre l’approccio tradizionale, senza il vantaggio offerto da ipset, richiederebbe migliaia di regole.

Tipi di set
Ciascun set è di uno specifico tipo, che definisce che genere di valore possa esservi memorizzato (indirizzi IP, networks, porte ecc.) così come debba essere ricercata la corrispondenza (ovvero, quale parte del pacchetto debba essere controllata e come debba essere confrontata coi valori presenti nel set).
Oltre ai tipi più comuni, che controllano gli indirizzi IP, ne sono disponibili addizionali che si riferiscono alla porta, sia all’indirizzo IP che alla porta contemporaneamente, oppure contemporaneamente al MAC address e all’indirizzo IP, ecc.

Ciascun tipo di set ha le proprie regole per tipo, range e distribuzione dei valori che può contenere.
Differenti tipi di set usano anche differenti tipi di indici e risultano ottimizzati per differenti scenari. La scelta del migliore / più efficiente tipo di set dipende dalla situazione.

I tipi più flessibili di set sono iphash, che archivia liste di indirizzi IP arbitrari, e nethash, che archivia liste di networks eterogenee (IP/mask) di varie dimensioni. Si faccia comunque riferimento all man page di ipset per un elenco completo ed una descrizione di tutti i tipi di set (attualmente 11).

È anche disponibile il tipo speciale setlist, che consente di raggruppare insieme differenti sets in un set unico.
È vantaggioso se si desidera, ad esempio,avere un singolo set che contenga sia singoli indirizzi IP che networks.

Altri vantaggi di ipset
Oltre ad un guadagno in termini di performances, ipset consente anche configurazioni più semplici in molti scenari.
Se si volesse ad esempio definire una condizione di filtraggio che corrisponda a qualsiasi pacchetto che non provenga da 201.121.12.1 oppure 202.121.12.2, perché continui a venire processato in mychain, la sintassi seguente non funzionerebbe:

# iptables -A INPUT -s ! 201.121.12.1 -g mychain
# iptables -A INPUT -s ! 202.121.12.2 -g mychain

Se un pacchetto provenisse da 201.121.12.1, non sarebbe interessato dalla prima regola (perché l’indirizzo sorgente è proprio 201.121.12.1), ma verrebbe catturato dalla seconda regola (perché l’indirizzo sorgente non è 202.121.12.2).
Se un pacchetto provenisse da 202.121.12.2, corrisponderebbe alla prima regola (perché l’indirizzo sorgente non è 201.121.12.1). Le regole si annullano a vicenda (qualsiasi pacchetto troverebbe corrispondenza in una delle due).

Sebbene esistano altri modi di costruire correttamente la regola che avevamo in realtà desiderato, e senza fare uso di ipset, nessuno è altrettanto intuitivo e semplice:

# ipset -N myset iphash
# ipset -A myset 201.121.12.1
# ipset -A myset 202.121.12.2
# iptables -A INPUT -m set ! --set myset src -g mychain

Qui, se un pacchetto provenisse da 201.121.12.1, non sarebbe interessato dalla regola (perché invece l’indirizzo sorgente 201.121.12.1 appartiene al set myset). Lo stesso avverrebbe, per lo stesso motivo, ad un pacchetto che provenisse da 202.121.12.2.

Sebbene si tratti di un esempio banale quello appena visto evidenzia il fondamentale beneficio derivante dall’ aver implementato una condizione completa in una singola regola.

Un altro vantaggio offerto da ipset dipende dal fatto che i sets possono essere manipolati in maniera indipendente dalle regole iptables attive. L’aggiunta e la rimozione di voci è una attività semplice e l’ordine irrilevante.
In iptables, al contrario, oltre al fatto che una regola è un oggetto significativamente più complesso, l’ ordine delle regole è di fondamentale importanza, pertanto la modifica sul posto di una o più regole è una operazione più impegnativa e soggetta ad errori.

Esclusione di specifiche Routed Networks dal NAT - il modo corretto
Il NAT sul traffico uscente (SNAT oppure IP masquerade) consente agli hosts appartenenti ad una LAN privata di accedere ad Internet.
Una appropriata regola iptables NAT intercetta i pacchetti destinati ad Internet originati dalla LAN privata e sostituisce l’indirizzo sorgente con l’indirizzo (esterno) del gateway stesso (facendo apparire il gateway come host originante e nascondendo il reale host originante privato).
Il NAT automaticamente traccia le connessioni attive pertanto inoltra i pacchetti di ritorno all’host interno corretto (cambiando l’indirizzo di destinazione da quello del gateway all’indirizzo dell’ originale host interno).

Qui di seguito c’è l’ esempio di una semplice regola NAT outbound che realizza quanto detto, e dove 192.168.10.0/24 rappresenta la LAN interna:

# iptables -t nat -A POSTROUTING \
-s 192.168.10.0/24 -j MASQUERADE

Questa regola si applica a tutti i pacchetti in uscita dalla LAN e consiste nel mascherarli (cioè applicarvi il processo di “NAT”). Ciò potrebbe essere sufficiente se l’unica rotta possibile fosse verso Internet.
Se tuttavia vi fossero rotte verso altre networks private, come avviene in VPN o links fisici WAN, probabilmente non risulterebbe desiderabile avere quel traffico mascherato.

Un modo semplice di superare questa limitazione (parzialmente) consiste nel basare la regola NAT sulle interfacce fisiche anziché su indirizzi di rete:

# iptables -t nat -A POSTROUTING \
-o eth0 -j MASQUERADE

Questa regola assume che eth0 sia la interfaccia esterna e si applica a tutti i pacchetti in uscita tramite essa.
Contrariamente alla regola precedente, i pacchetti destinati ad altre networks che utilizzano delle rotte in uscita attraverso differenti interfacce (ad esempio i collegamenti OpenVPN), non saranno interessati da questa regola.

Sebbene tuttavia molte connessioni di rete possano avere rotte tramite interfaccie separate non è altrettanto vero che tutte lo possano fare. Ad esempio Openswan, che non fa uso di interfaccie virtuali come altre VPN user-space (come OpenVPN).

In ogni caso progettare delle regole di firewall che si basino sulla interfaccia fisica può introdurre limiti e dipendenze nella topologia di rete, motivo che consiglia di evitare tale approccio, quando non strettamente necessario.

Ecco dunque un altro grande campo di applicazione per ipset.

Supponiamo che oltre a fare l’ Internet gateway per la locale LAN privata (10.0.0.0/24), la nostra linux box abbia delle rotte dirette verso altre quattro network private (10.10.30.0/24, 10.10.40.0/24, 192.168.4.0/23 e 172.22.0.0/22).

Basta utilizzare I seguenti comandi:

# ipset -N routed_nets nethash
# ipset -A routed_nets 10.10.30.0/24
# ipset -A routed_nets 10.10.40.0/24
# ipset -A routed_nets 192.168.4.0/23
# ipset -A routed_nets 172.22.0.0/22
# iptables -t nat -A POSTROUTING \
-s 10.0.0.0/24 \
-m set ! --set routed_nets dst \
-j MASQUERADE

Questa unica regola maschererà tutto il traffico che attraversa il box ed è originato dalla LAN interna (10.0.0.0/24) ad eccezione di quei pacchetti destinati alle reti elencate nel set routed_nets, preservando quindi il normale routing IP verso tali reti.

Poiché tale configurazione si basa solamente su indirizzi di rete non dovrete più preoccuparvi dei tipi di connessione in questione (tipo di VPNs, numero di hops ecc), e nemmeno dovrete più preoccuparvi di interfacce fisiche e topologie.

Limitare l’accesso restringendolo solo a certi hosts pubblici da parte di certi PC della rete locale
Supponiamo che il megadirettoregalattico sia molto infastidito dall”idea che certi impiegati, Filini, Fantozzi e Fracchia possano passare il tempo a trastullarsi con Internet invece di lavorare e vi chieda di limitare l’accesso da parte dei loro PCs a uno specifico set di siti cui è necessario collegarsi per lavoro.
Per limitare i tre PCs (192.168.0.5 è quello di Filini, 192.168.0.6 quello di Fantozzi e 192.168.0.7 quello di Fracchia) ad accedere solamente a renatobrunetta.it, avvenire.it e inps.it, si possono utilizzare i seguenti comandi:

# ipset -N limited_hosts iphash
# ipset -A limited_hosts 192.168.0.5
# ipset -A limited_hosts 192.168.0.6
# ipset -A limited_hosts 192.168.0.7
# ipset -N allowed_sites iphash
# ipset -A allowed_sites renatobrunetta.it
# ipset -A allowed_sites avvenire.it
# ipset -A allowed_sites inps.it
# iptables -I FORWARD \
-m set --set limited_hosts src \
-m set ! --set allowed_sites dst \
-j DROP

Questo esempio effettua un confronto con due sets in una singola regola. Se il l’indirizzo sorgente è compreso in limited_hosts e la destinazione non è compresa in allowed_sites, il pacchetto viene semplicemente scartato (a limited_hosts è permesso comunicare solamente con allowed_sites).

Si noti che dato che questa regola si trova nella chain FORWARD, non riguarda le comunicazioni da e verso il firewall stesso nè il traffico interno.

Bloccare l’accesso a un certo insieme di siti tranne che da certi PCs (scenario inverso)
Supponiamo che il solito megadirettoregalattico voglia bloccare l’accesso ad un certo insieme di siti da parte di tutti gli hosts della LAN fatta eccezione per il suo PC e quello della sua segretaria.
Per variare, in questo esempio, decidiamo inoltre di individuare i PCs del capo e della sua segretaria tramite MAC address anziché indirizzo IP. Supponiamo che i MACs siano 11:11:11:11:11:11 e 22:22:22:22:22:22, e che i siti da bloccare per tutti gli impiegati siano supersex.com, badboy.com e gazzetta.it.
Anziche utilizzare un secondo ipset per comprendervi gli indirizzi MAC, utilizzeremo comandi multipli iptables con il target MARK allo scopo appunto di marcare i pacchetti, per processarli in successive regole della stessa chain:

# ipset -N blocked_sites iphash
# ipset -A blocked_sites supersex.com
# ipset -A blocked_sites badboy.com
# ipset -A blocked_sites gazzetta.it
# iptables -I FORWARD -m mark --mark 0x187 -j DROP
# iptables -I FORWARD \
-m mark --mark 0x187 \
-m mac --mac-source 11:11:11:11:11:11 \
-j MARK --set-mark 0x0
# iptables -I FORWARD \
-m mark --mark 0x187 \
-m mac --mac-source 22:22:22:22:22:22 \
-j MARK --set-mark 0x0
# iptables -I FORWARD \
-m set --set blocked_sites dst \
-j MARK --set-mark 0x187

Come si può facilmente osservare, per non avere usato ipset per svolgere tutto il lavoro di controllo, come invece avvenuto nell’esempio precedente, i comandi sono un po’ più involuti e complessi.
Dato che si tratta di comandi iptables multipli, occorre intanto supporre che il loro ordine sia di vitale importanza.

Si noti che queste regole vengono aggiunte col l’opzione -I (insert) invece di -A (append).
Quando di una regola viene effettuato l’insert, viene aggiunta in testa alla chain, sopravanzando tutte le regole eventualmente esistenti.

Poiché tutte le regole vengono inserite, l’ effettivo ordine in cui verranno esaminate viene invertito.

L’ultimo comando iptables diventa pertanto il primo nella chain di FORWARD. La regola riguarda tutti i pacchetti con destinazione compresa nel set blocked_sites, e marca tali pacchetti con 0×187 (un numero esadecimale preso arbitrariamente).

Le successive due regole riguardano solamente i pacchetti provenienti dai due hosts esclusi dal filtraggio, e che sono anch’essi già marcati con il valore 0×187. Queste due regole rimarcano I pacchetti con 0×0, cancellando in tal modo il precedente 0×187.

Infine l’ultima regola iptables (rappresentata dal primo comando iptables presente) scarta tutti i pacchetti col marchio 0×187 mark.
Questo corrisponde a tutti i pacchetti con destinazioni comprese nel set blocked_sites ad eccezione dei pacchetti provenienti dai due MACs, dato che il valore marcato in tali pacchetti viene ripulito prima che sia raggiunta la regola che effettua il DROP.

Per inciso: nella maggior parte dei casi pratici questa soluzione non è valida per bloccare l’accesso a quei Web sites che dovrebbero essere i candidati ideali a finire nel set blocked_sites (tipo Facebook, MySpace e compagnia cantante), dato che essi possono avere indirizzi IP multipli, e questi ultimi variare di frequente.

Una limitazione generale di iptables/ipset è che gli hostnames dovrebbero venire specificati solamente se risovono in un singolo indirizzo IP.
Inoltre il lookup di un hostname avviene solamente quando il comando viene eseguito, per cui se l’indirizzo IP address cambiasse, la regola firewall ignorerebbe il cambiamento e continuerebbe a fare riferimento all’originale IP.

Ban automatico di Hosts che tentano di accedere a servizi non validi
ipset aggiunge a iptables anche una “target extension” che fornisce un meccanismo in grado di aggiungere e rimuovere dinamicamente da un set voci basate su una qualsiasi regola iptables.
Invece di aggiungere voci manualmente col comando ipset, si può fare in modo che iptables li aggiunga al volo al posto nostro.

Per esempio, se un host remoto tentasse di connettersi alla porta 25, senza che vi sia in ascolto alcun server SMTP, sarebbe probabilmente una buona idea impedire a quell’host l’ opportunità di tentare qualcosa d’altro proattivamente, usando le seguenti regole:

# ipset -N banned_hosts iphash
# iptables -A INPUT \
-p tcp --dport 25 \
-j SET --add-set banned_hosts src
# iptables -A INPUT \
-m set --set banned_hosts src \
-j DROP

Se un pacchetto arrivasse sulla porta 25, diciamo con indirizzo sorgente 94.10.18.1, tale indirizzo verrebbe aggiunto istantaneamente al set banned_hosts, come se venisse impartito il comando:

# ipset -A banned_hosts 94.10.18.1

Tutto il traffico proveniente da 94.10.18.1 verrebbe da quel momento bloccato dalla regola col target DROP.

Azzeramento della configurazione corrente
Volendo azzerare la corrente configurazione ipset ed iptables (set, regole, voci) e tornare ad uno stato di firewall completamente open (utile in testa ad uno script che imposti da zero un firewall), si possono mandare in esecuzione i seguenti comandi:

# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -t filter -F
# iptables -t raw -F
# iptables -t nat -F
# iptables -t mangle -F
# ipset -F
# ipset -X

Sets che siano “in uso”, cioè referenziati da una o più regole iptables, non possono essere distrutti (con ipset -X). Pertanto, per ottenere un reset completo, occorre un flush preventivo delle chains iptables (come mostrato qui sopra).

Send post as PDF to

Non starò qui a raccontare le mie peripezie da novello designer, architetto e gestore di un sito di questo tipo (il che non è esattamente uno scherzetto), dirò solamente che dal punto di vista della piattaforma scelta per l’hosting, fatto un iniziale tentativo con un OScommerce preinstallato (e già notoriamente vulnerabile) su hosting linux condiviso (già defacciato dal solito turco prima ancora che vi accedessi una sola volta), ho optato alla fine per una soluzione “in the cloud”, della quale mi ritengo tuttora soddisfatto.
Ciò si risolve in pratica nel disporre, anziché di un server fisico, di una “istanza” Debian Linux server, soluzione decisamente più economica e sopratutto scalabile (perfino nel senso di effettuare dei downsize) rispetto a quella tradizionale basata su server dedicato, e col medesimo SO.

Per quanto il nostro cloud server faccia girare anche altri servizi, tipicamente quelli postali con Dovecot e Exim, il suo ruolo principale è quello di servire le pagine dinamiche del sito www.ilmandala.it, realizzato grazie ad un software open source di alto livello come Prestashop.
Ovviamente parte importante  del backend è costituita da un onnipresente database mysql.

La navigabilità e la reattività del sito sono finora sempre risultate ottime, soprattutto se si considera che sono riferite ad una disponibilità di risorse attualmente molto bassa: 1 GB RAM e 1 CPU.

La cosa mi ha stimolato ad andare oltre, fino a trasportare sul medesimo cloud server anche il PBX Asterisk aziendale e sistemare così il lato telefonia.
Non descriverò l’operazione, essendo assolutamente analoga a quanto accade su server fisico, anche se devo confessare di avere passato parecchio tempo in fase di make menuselect a deselezionare le opzioni non necessarie, fino ad ottenere un puro SIP server e nient’altro.

Dato che il PBX si occupa solo dell’inbound (tra l’altro così non vi è alcun rischio che possa venire utilizzato in maniera fraudolenta), è bastato prendere una linea VoIP ed un numero geografico tramite Messagenet.

È subito evidente il vantaggio, a fronte di un canone irrisorio, di poter applicare il tipico routing intelligente di Asterisk alle chiamate in ingresso, senza tuttavia alcuna necessità di installare fisicamente e gestire un server Asterisk dedicato.

Al momento il PBX si comporta egregiamente, senza sembrare disturbato da contemporanee richieste web.
Dato che mi voglio proprio rovinare, penso che effettuerò l’upgrade per un ulteriore GB di RAM.

Send post as PDF to

In realtà gli attacchi basati sulla DNS amplification non sono una novità, tuttavia non sono mai stati comunemente utilizzati.

Cercherò di spiegare di cosa si tratti.

La categoria degli attacchi Denial of service (DoS) è molto vasta, ma è rivolta ad ottenere sempre lo stesso risultato: il servizio bersagliato diviene indisponibile ai propri utenti.

Una forma comune di DoS consiste nell’indurre un esaurimento delle capacità della rete nella quale il bersaglio risiede.
Questo tipo di attacco implica l’invio ad un server di una quantità di traffico (o di richieste) maggiore di quanto sia in grado di gestire abitualmente.
Ciò comporta per l’attaccante la capacità di generare una grossa massa di traffico, effetto ottenibile utilizzando molti sistemi, tipicamente aggregati in una botnet.

La tecnica detta “DNS Amplification” utilizza il DNS, in particolare i DNS servers mal configurati, per avviare efficaci attacchi di tipo “denial of service” (DoS) consentendo all’attaccante di utilizzare una quantità minima di banda e mascherare contemporaneamente l’indirizzo IP originante dell’attacco nei pacchetti UDP emessi. In tal modo diventa possibile indurre un server DNS a inviare le proprie risposte ad uno specifico indirizzo (il reale obiettivo dell’attacco).
La componente amplificativa dell’ attacco risiede nella disponibilità del server DNS ad eseguire per conto dell’attaccante una richiesta che comporti una risposta più ampia della richiesta stessa.

Per comprendere il principio della “DNS amplification” è necessario comprendere prima i due concetti che consentono a tale tipo di attacco di avere luogo. Il primo è noto come “reflection”:
A differenza del più comunemente usato Transmission Control Protocol (TCP), i protocolli UDP (User Datagram Protocol) e ICMP (Internet Control Message Protocol) non attuano alcuna connessione, motivo per cui sono comunemente definiti “connectionless”.
I pacchetti IP che incapsulano TCP o UDP contengono un indirizzo sorgente ed uno di destinazione, me nel caso di UDP il destinatario del pacchetto non ha modo di accertare che l’indirizzo di origine non sia stato falsificato, pratica comunemente conosciuta come spoofing. Un computer che riceva un pacchetto UDP con un indirizzo IP “spoofed” invierà una risposta proprio a quell’indirizzo IP, e non al mittente reale.
La “reflection” pùò anche consentire all’attaccante di far credere che il traffico generato provenga da molte differenti origini, rendendo difficoltoso attuare un filtro dei dati in ingresso.

Il secondo concetto è quello di “amplification”, cioè di moltiplicazione del traffico originariamente inviato.
Ogni computer implicato nell’attacco replica alla vittima, inondandola di traffico.
Mentre la reflection nasconde il sorgente iniziale dell’attacco DoS, la amplification incrementa la quantità di traffico ricevuto dalla vittima decine, centinaia o migliaia di volte.

Uno degli attacchi basati su amplificazione più datati e conosciuti è noto come “smurf”. In un attacco smurf, l’attaccante invia un ping ICMP all’indirizzo IP broadcast, simulando che a inviarlo sia l’indirizzo IP della vittima (spoofing).
L’invio di un singolo pacchetto viene replicato da tutti i nodi di una rete amplificando il traffico totale ricevuto dalla vittima.

Gli attacchi smurf tuttavia non costituiscono più una seria minaccia dal momento che gli attuali routers sono configurati per non lasciar passare pacchetti broadcast alle altre reti, limitando di fatto il campo di applicazione di un attacco smurf alla subnet locale.

Una categoria più recente di attacchi DoS sfrutta invece l’infrastruttura DNS per amplificare la quantità di traffico che un singolo nodo può inviare.
Una richiesta DNS per un record di tipo A per uno specifico ampio dominio, tipico esempio google.com, restituisce molti più dati di quelli necessari per la semplice richiesta.
Le richieste DNS utilizzano poi comunemente messaggi basati su UDP, uno strumento ideale per attacchi basati sia sulla reflection che sulla amplification.

Un altro fattore chiave risiede nella disponibilità di servers DNS configurati per effettuare richieste di tipo ricorsivo. Tali servers sono comunemente detti “open resolvers”.

Effettuando una tipica richiesta per un record DNS di tipo A, in certi casi capita che la risposta risulti più piccola della interrogazione, ma è molto semplice ottenere una risposta voluminosa facendo richiesta di informazioni addizionali.

Se invece di una query per un record A ne venisse fatta una di tipo ANY, il server restiturebbe anche i valori relativi ai records MX ed NS, ottenendo, nel caso in cui, ad esempio, il dominio in questione sia google.com, un fattore di amplificazione 4x.

Per incrementare ancora l’ amplificazione, un eventuale attaccante può sfruttare gli ampi record forniti dalle DNS Security Extensions (DNSSEC) per le zone definite.
DNSSEC restituisce i dati relativi ad una firma digitale (cryptographic signature) oltre ai normali dati del record DNS richiesto per consentire al destinatario di verificare l’autenticità dei dati ottenuti. Ciò fa aumentare significativamente la quantità di traffico restituito da un DNS server.

Effettuando una richiesta ANY di 78 bytes (ethernet) relativa al dominio usa.gov tramite il server 198.153.192.1 (di nortondns.com) e specificando la richiesta di records DNSSEC, ho ottenuto in risposta 3 frames ethernet di 1514+1514+1018=4046 bytes, con un fattore di amplificazione di oltre 50x.

Questa la richiesta effettuata:

# dig @198.153.192.1 ANY +dnssec usa.gov

e la relativa risposta:

; <<>> DiG 9.7.3 <<>> @198.153.192.1 ANY +dnssec usa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63509
;; flags: qr rd ra; QUERY: 1, ANSWER: 29, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;usa.gov.            IN    ANY

;; ANSWER SECTION:
usa.gov.        300    IN    SOA    dns.gsa.gov. hostmaster.gsa.gov. 1203130000 86400 600 1296000 10800
usa.gov.        300    IN    RRSIG    NSEC3PARAM 7 2 300 20120412123801 20120313113801 61638 usa.gov. hqAvKJVia4C96oKETI9vHns+mM58Sh/YhA+Jrslfjdfc/qYnoA4cztPr uNv9lAPxPhaiUMjP+vxPCj6aDmaxKVWjTX7ELgMOsV7u3kRMOVxmV4Og kk4w+NgPoN46/3bEZfDofremw3FNId+soFSsKLp4FGwMJXM2+oD4EXsY vbI=
usa.gov.        300    IN    RRSIG    DNSKEY 7 2 300 20120412123801 20120313113801 53313 usa.gov. bvMBZsLxqyNDblOMnsLyWNrm4Pfn9xhp0HNYbTWR9s1DVc0DcqG1mN0R OG4biFFG7nxjuPuLOYXREOfwbaChuzRRK5DERprT4ejhvOepR+wT518e +/7dS5F+35rrl4ymBhU6c4MN3J17K+oUqE9YwjvSG8YpKjhKMoOe1ami 2dab9amJbmYuzMBHCPwDDllomSFqXH2J7NMnwQbDtdjXJXk0arSZ2YEO KeFbGbQf0a7Pz4usPgipfcv7N8Ekh1r2r5rVzKTvpKz4YTg31iRWVkOQ LWhFuUCAm/RJF5PxrWHkwgLfxMuK2jZj/xptKtPnzQyEYmDHF9fcdO+6 tzCGTw==
usa.gov.        300    IN    RRSIG    DNSKEY 7 2 300 20120412123801 20120313113801 61638 usa.gov. PJga6q4tjRifPCR/rkGCpoMYinDUcvDWB4RwYAMFHauunqHcwGl4MYES jzuVV8CqcuG+ILl9+lwTGMafABD/W67GuQv+/pRKvpkb+0hw5ByMOzSC wR17oWHCXW0VYYcxjeZNW1X2CMW3mSx53W079DMzHdAPioJavBM6zT5b dro=
usa.gov.        300    IN    RRSIG    SOA 7 2 300 20120412123801 20120313113801 61638 usa.gov. ruGzimcqC+8YUj9wNvEjh5dX9/TI0sZRK8bIC+CfKtnZJs5FzKDuZgdK x9YunDQ/WKaxkkkYU9XCdma41cEwUN/Ymc6QLCts0jYphfUAYM+RAU7e 4Agi6seJfsxtpGsHvZ4MaCahFOsiKpsd1Kp+8vZeSlxDvZVm7Yq23bsx m3w=
usa.gov.        3600    IN    RRSIG    MX 7 2 3600 20120412123801 20120313113801 61638 usa.gov. rfL4qho8S73nC/t+fGHfhPm69jbKdRNexJAamVdgXIzGVc1+UDvDfaBD qnMP7df4YpyysqLDoITmpFsPe48w4EQnuQRJWjSqCGKFUWmHqrvQLPIX uyJSClCy2TghllWtXmc0299ny/OCY2odfT46GDLnMMWUb8LeSQml43QC 2mY=
usa.gov.        3600    IN    RRSIG    A 7 2 3600 20120412123801 20120313113801 61638 usa.gov. O55BJ3n4GGZoIe/eETN9omyGnL2GrIHgBLhUSFDcFEo3xvyQvLCv45Ec XYwGeUMZJoIgnNI4njOoflaXS3E8U4oqMCqDs9xz+NMQvC8xYDU20puY +Jktb9yj/s0XL4gz9mC3sqSgmOJkhyPQm0QDsB2phAPwFAmXKBwyX3KJ Vs0=
usa.gov.        300    IN    RRSIG    NS 7 2 300 20120412123801 20120313113801 61638 usa.gov. U9hfCzMLAaoc8QfpTBKhdkopOqGKjps4aW4NTX+HzKDwLsL3qLRLURpm QuO18T4mDcAkIGU9Vr3wsJC85f0P91Dus++J2t4x0+zqTceYSUcIAax6 OhuT0vre7czspqZh6+ZiQov/sNXfGWx+Vfch9jpx0E0gK+XXI4P40M5o sQc=
usa.gov.        300    IN    NSEC3PARAM 1 0 12 AABBCCDD
usa.gov.        300    IN    RRSIG    NSEC3PARAM 7 2 300 20120412123801 20120313113801 61638 usa.gov. hqAvKJVia4C96oKETI9vHns+mM58Sh/YhA+Jrslfjdfc/qYnoA4cztPr uNv9lAPxPhaiUMjP+vxPCj6aDmaxKVWjTX7ELgMOsV7u3kRMOVxmV4Og kk4w+NgPoN46/3bEZfDofremw3FNId+soFSsKLp4FGwMJXM2+oD4EXsY vbI=
usa.gov.        300    IN    DNSKEY    256 3 7 AwEAAb7LoWNLiPwBhNFUBf+1r841RFpc+1Zj7tpLz99bY/53amEiHkrH vpd48XX/J2aXsqCBhxBi3t0wvtWfHGolVD64UYn/JxVfkx1r5xv6nETV MTDEW3OMAfA+m+gWwxACJc3TPsyFtN5ExCBjbb0tLJCiXdHj8D5pC2gD KcQZ+J/H
usa.gov.        300    IN    DNSKEY    257 3 7 AwEAAZD19uIi0nuONBNkQDrFL9NZuYb8iiaEGWBmj7EJ7Dse1kz5kdK6 DVxan1J5WMN7YDr/3eNSerogcJP8IFOqMxNdwKHMRMp3mavVVMR1ddnv t4hy1j3Pd+y6DELdZxNixOZgI7vKj67RMlyjWjzz96i64dghKM89/9S2 5VMi2BlUVJ9f74TOTiYxJpAqz9DuRzGKr1c29HQNpnPu4syXQy367XNk syzndaN+vFZYxw6ukv707by7XI2UyXO1AtNTFHiDpz1uFnnf26EBG2Nq 4DfS6dAlUKqTdb+QvTbSGeMgpFotz5ZJLQjl+XFWarNenX6LowMl4mzv VjtUzKWHXRU=
usa.gov.        300    IN    DNSKEY    257 3 7 AwEAAaJXTYjFMibSsZMzzgi+qGYLUHDMj+5v6YDfG/maMOyT0rC51bkw ZRie6XHkjAEW9CWZe3m87FHXJ3PmG8O+LfO0bz1yRftOtS1OvdyX+Jeb jVUR4eOVitNZL8cz1zAj7Fv2wFU3BjlqhFyB2q17sEkKFfbt16LwL6hR 6/CbFDtg00VykZ3nNYkZy2r8GsbTlrXkAEur5mX+Ls+cTksaUlzPQhFc 8ST5nRc6/ebSGg+gwVjWZLrmncbrdNq887HZdy5NDT7bxn0ArRi41f4/ P6Y9dI8DXVcxMPa2y6P2UzwNYY60UHqp3GLoV7x4hobduf74ffCVgzuJ QGP6e9PqTtU=
usa.gov.        300    IN    DNSKEY    256 3 7 AwEAAXY7OaGoaM+8pyyRWniow6SrKpMD2F/yweKz0CNAV18dn2mGOOmM eGNOzhkg+MTkHtZxKQ1LzZtveg8wO3mTn3g23Sr/1I8uIfABSDTGuHgb wTxKQpaC+eHcc01Ucn9EGkzS/kt8g0HwwDQ4YZgoxjBGS/dEqE/JX0h4 31PyV/0J
usa.gov.        300    IN    RRSIG    DNSKEY 7 2 300 20120412123801 20120313113801 53313 usa.gov. bvMBZsLxqyNDblOMnsLyWNrm4Pfn9xhp0HNYbTWR9s1DVc0DcqG1mN0R OG4biFFG7nxjuPuLOYXREOfwbaChuzRRK5DERprT4ejhvOepR+wT518e +/7dS5F+35rrl4ymBhU6c4MN3J17K+oUqE9YwjvSG8YpKjhKMoOe1ami 2dab9amJbmYuzMBHCPwDDllomSFqXH2J7NMnwQbDtdjXJXk0arSZ2YEO KeFbGbQf0a7Pz4usPgipfcv7N8Ekh1r2r5rVzKTvpKz4YTg31iRWVkOQ LWhFuUCAm/RJF5PxrWHkwgLfxMuK2jZj/xptKtPnzQyEYmDHF9fcdO+6 tzCGTw==
usa.gov.        300    IN    RRSIG    DNSKEY 7 2 300 20120412123801 20120313113801 61638 usa.gov. PJga6q4tjRifPCR/rkGCpoMYinDUcvDWB4RwYAMFHauunqHcwGl4MYES jzuVV8CqcuG+ILl9+lwTGMafABD/W67GuQv+/pRKvpkb+0hw5ByMOzSC wR17oWHCXW0VYYcxjeZNW1X2CMW3mSx53W079DMzHdAPioJavBM6zT5b dro=
usa.gov.        3600    IN    MX    20 mx20.usa.gov.
usa.gov.        3600    IN    MX    10 mx10.usa.gov.
usa.gov.        3600    IN    RRSIG    MX 7 2 3600 20120412123801 20120313113801 61638 usa.gov. rfL4qho8S73nC/t+fGHfhPm69jbKdRNexJAamVdgXIzGVc1+UDvDfaBD qnMP7df4YpyysqLDoITmpFsPe48w4EQnuQRJWjSqCGKFUWmHqrvQLPIX uyJSClCy2TghllWtXmc0299ny/OCY2odfT46GDLnMMWUb8LeSQml43QC 2mY=
usa.gov.        3600    IN    A    173.252.148.104
usa.gov.        3600    IN    A    216.128.241.47
usa.gov.        3600    IN    RRSIG    A 7 2 3600 20120412123801 20120313113801 61638 usa.gov. O55BJ3n4GGZoIe/eETN9omyGnL2GrIHgBLhUSFDcFEo3xvyQvLCv45Ec XYwGeUMZJoIgnNI4njOoflaXS3E8U4oqMCqDs9xz+NMQvC8xYDU20puY +Jktb9yj/s0XL4gz9mC3sqSgmOJkhyPQm0QDsB2phAPwFAmXKBwyX3KJ Vs0=
usa.gov.        300    IN    NS    dns3.gsa.gov.
usa.gov.        300    IN    NS    dns5.gsa.gov.
usa.gov.        300    IN    NS    dns2.gsa.gov.
usa.gov.        300    IN    NS    dns6.gsa.gov.
usa.gov.        300    IN    NS    dns.gsa.gov.
usa.gov.        300    IN    NS    dns4.gsa.gov.
usa.gov.        300    IN    RRSIG    NS 7 2 300 20120412123801 20120313113801 61638 usa.gov. U9hfCzMLAaoc8QfpTBKhdkopOqGKjps4aW4NTX+HzKDwLsL3qLRLURpm QuO18T4mDcAkIGU9Vr3wsJC85f0P91Dus++J2t4x0+zqTceYSUcIAax6 OhuT0vre7czspqZh6+ZiQov/sNXfGWx+Vfch9jpx0E0gK+XXI4P40M5o sQc=

;; Query time: 156 msec
;; SERVER: 198.153.192.1#53(198.153.192.1)
;; WHEN: Fri Mar 16 00:15:01 2012
;; MSG SIZE  rcvd: 3936

Questa invece la cattura (tramite tcpdump) della risposta frammentata:

# tcpdump -i eth0 -v 'udp port 53 or (ip[6:2] & 0×2000 == 0×2000 or ip[6:2] & 0×1fff !=0×0000)’
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:15:01.051922 IP (tos 0×0, ttl 64, id 61723, offset 0, flags [none], proto UDP (17), length 64)
silversurfer.49904 > 198.153.192.1.domain: 63509+ [1au] ANY? usa.gov. (36)
00:15:01.206712 IP (tos 0×0, ttl 54, id 10190, offset 0, flags [+], proto UDP (17), length 1500)
198.153.192.1.domain > silversurfer.49904: 63509 29/0/5 usa.gov. SOA dns.gsa.gov. hostmaster.gsa.gov. 1203130000 86400 600 1296000 10800, usa.gov. RRSIG, usa.gov. RRSIG, usa.gov. RRSIG, usa.gov. RRSIG, usa.gov. RRSIG, usa.gov. RRSIG, usa.gov. RRSIG, usa.gov. Type51, usa.gov. RRSIG[|domain]
00:15:01.207146 IP (tos 0×0, ttl 54, id 10190, offset 1480, flags [+], proto UDP (17), length 1500)
198.153.192.1 > silversurfer: udp
00:15:01.207152 IP (tos 0×0, ttl 54, id 10190, offset 2960, flags [none], proto UDP (17), length 1004)
198.153.192.1 > silversurfer: udp

Un singolo computer collegato ad Internet tramite una buona ADSL potrebbe ragionevolmente generare 512 Kbps di traffico, certo non abbastanza per causare un DoS. Moltiplicando tale valore per 50, e utilizzando una piccola
botnet composta da 1000 nodi, sarebbe facilmente possibile generare 25 Gbps di traffico, abbastanza per saturare pressoché qualsiasi connessione Internet.

Per concludere, un attacco di tipo “DNS amplification” può rivelarsi enormemente efficace, tuttavia necessita di due condizioni senza le quali non è praticabile:

1) Sebbene gli indirizzi IP dei pacchetti UDP possano essere alterati (spoofed), ciò non è necessariamente sempre possibile. Se è vero cioè che UDP non può assicurare la reale origine di un pacchetto, un ISP potrebbe sempre filtrare i pacchetti in uscita dalla propria rete per assicurare che l’indirizzo IP sorgente risieda effettivamente all’interno di essa.
Il documento redatto dalla Internet Engineering Task Force (IETF) “Best Current Practice 38″ (BCP38) suggerisce proprio questo tipo di filtraggio. Se molte networks lo hanno implementato, molte altre non lo hanno semplicemente fatto, adducendo come motivo il sovraccarico cui sarebbero di conseguenza sottoposti i propri apparati.

2) Il secondo prerequisito necessario affinché una DNS amplification possa essere attuata risiede nella cooperazione da parte di uno o più DNS servers. Già nel 2006, Dan Kaminsky aveva evidenziato la presenza di oltre 580000 open resolvers attivi in Internet. Qualsiasi buon amministratore di un server DNS dovrebbe configurarlo in modo che non possa effettuare queries ricorsive o almeno consentirle esclusivamente ad uno specifico range di indirizzi IP.

Send post as PDF to

L’attacco ha seguito uno schema composto da tre distinte fasi: arruolamento e comunicazione, analisi tramite riconoscimento delle caratteristiche tecniche dell’obbiettivo con contemporanei attacchi al livello applicativo, e da ultimo, un attacco di tipo DDoS (distributed denial of service).

Come canali di arruolamento sono stati utilizzati i Social media, in particolar modo Twitter, Facebook e YouTube, usati prevalentemente per indicare un obiettivo e giustificare ideologicamente un attacco, e contemporaneamente arruolare volontari disposti a participare alla campagna militare. Tutto questo durante la prima fase, quella definita di “Arruolamento e comunicazione”.

Gli hackers più sofisticati e tecnicamente capaci costituiscono solo una piccola parte degli attivisti e sono principalmente coinvolti nella fase di riconoscimento e nella fase di attacco al livello applicativo, incentrati sulla ricerca di specifichè vulnerabilità applicative o in attacchi di tipo SQL injection, allo scopo di introdursi a qualche titolo nel sistema bersaglio.

La truppa in attesa viene scatenata solo durante la terza fase, sintomo che i precedenti attacchi sono semplicemente andati a vuoto.

Anonymous ha sviluppato alcuni tools software, specificamente il software Low Orbit Ion Cannon (LOIC) ed anche un tool che consente di partecipare ad un attacco DDoS a partire dal browser di uno smatphone, sfrutta il venerabile Slowloris, nato ai tempi della rivolta in Iran del 2009. Il gruppo fa invece affidamento su tools pubblicamente disponibili e largamente utilizzati (in modo assolutamente legale) nel penetration testing per rilevare e sfruttare le vulnerabilità delle (proprie) applicazioni web, durante le fasi di riconoscimeto ed attacco a livello applicativo.

Analizzando a posteriori l’attacco di ieri, se ne deduce comunque che si sia trattato di un mezzo fallimento, e che tutto si sia ridotto ad una probabile autoesclusione del cluster vaticano (212.77.1.244, 212.77.1.246, 212.77.1.247 e 212.77.1.243) dalla rete, dopo un attacco DDOS, che molto probabilmente esporrà molti a possibili rappresaglie giudiziarie).

Piuttosto cattiva, ma meritevole di considerazione, la definizione data di Anonymous da qualcuno del team: “Anonymous è un manipolo di geni circondati da una massa di idioti”.

Send post as PDF to

Per meglio mascherare la realtà, una volta preso il controllo del sistema, il malware prova a scaricare l’autentico slowloris, proprio come lo script-kiddie si sarebbe aspettato.

Gli attacchi DDoS si sono svolti come pianificato, ma nel frattempo il trojan Zeus faceva incetta delle credenziali di accesso e, se presenti, dei dati finanziari della ignara hacktivittima (del resto è specializzato proprio in questo).

Dulcis in fundo, l’arruolamento forzato e inconsapevole in una botnet criminale.

Send post as PDF to

Gizmodo riporta che i militari erano a conoscenza dei rischi potenziali legati allo spoofing GPS con la conseguenza per un drone di venire costretto ad atterrere in maniera analoga a quanto successo sin dal 2003 e non avevano mai affrontato il problema.

Tuttavia, certi attacchi basati su GPS spoofing sono molto difficili da mettere in pratica, e gli analisti diffidano fortemente delle tesi iraniane, classificandola propaganda. Le autorità iranian avrebbero dovuto conoscere la localizzazione del drone entro una manciata di metri e colpirlo con un segnale GPS più forte delle trasmissioni satellitari. Nessuno di questi segnal è criptato cosicchè il segnale più forte l’avrebbe vinta, ma a questo punto sarebbe necessario introdurre gradualmente degli errori per guidare il velivolo al punto di atterraggio scelto.
Gli USA controbattono infatti che il drone è andato perso durante una missione nell’Ovest dell’Afghanistan e portato in Iran in seguito ad una operazione spionistica.

Send post as PDF to