ATTACCO DA DOS
.0. PREFAZIONE
.A. INTRODUZIONE
.A.1. COS'è UN ATTACCO DENIAL OF SERVICE?
.A.2. PERCHè QUALCUNO DOVREBBE MANDARE IN CRASH UN SISTEMA?
.A.2.1. INTRODUZIONE
.A.2.2. STATO SOTTOCULTURALE
.A.2.3. PER GUADAGNARE L'ACCESSO
.A.2.4. VENDETTA
.A.2.5. RAGIONI POLITICHE
.A.2.6. RAGIONI ECONOMICHE
.A.2.7. CATTIVERIA
.A.3. ALCUNI SISTEMI OPERATIVI SONO PIù SICURI?
.B. ALCUNI OBBIETTIVI DI BASE PER UN ATTACCO
.B.1. SPAZIO SWAP
.B.2. FREQUENZA
.B.3. TAVOLE DEL KERNEL
.B.4. RAM
.B.5. DISCHI
.B.6. CACHE
.B.7. INETD
.C. ATTACCARE DALL'ESTERNO
.C.1. AVERE PROFITTO CON IL FINGER
.C.2. UDP E SUNOS 4.1.3.
.C.3. BLOCCARE X-WINDOWS
.C.4. USO MALIZIOSO DEI SERVIZI UDP
.C.5. ATTACCARE CON I CLIENTS LYNX
.C.6. USO MALIZIOSO DI telnet
.C.7. USO MALIZIOSO DI telnet SU SOLARIS 2.4
.C.8. COME DISABILITARE GLI ACCOUNTS
.C.9. LINUX E TCP TIME, DAYTIME
.C.10. COME DISABILITARE I SERVIZI
.C.11. PARAGON OS BETA R1.4
.C.12. FTP DI NOVELLS NETWARE
.C.13. ATTACCHI CON REINDIRIZZAMENTO DI ICMP
.C.14. TEMPESTE DI BROADCAST
.C.15. EMAIL BOMBING E SPAMMING
.C.16. TIME E KERBEROS
.C.17. IL BUG DOT DOT
.C.18. SUNOS KERNEL PANIC
.C.19. APPLESTS OSTILI
.C.20. VIRUS
.C.21. ABUSO DI FTP ANONIMO
.C.22. SYN FLOOD
.C.23. PING FLOOD
.C.24. MANDARE IN CRASH I SISTEMI CON IL PING DI WINDOWS 95
.C.25. USO MALIZIOSO DEL MESSAGGIO DI RISPOSTA DELLE SUBNET MASK
.C.26. FLEXlm
.C.27. PARTIRE CON FTP BANALI
.D. ATTACCARE DALL'INTERNO
.D.1. KERNEL PANIC SOTTO SOLARIS 2.3
.D.2. BLOCCARE IL SERVER X
.D.3. RIEMPIRE L'HARD DISK
.D.4. USO MALIZIOSO DI eval
.D.5. USO MALIZIOSO DI fork()
.D.6. CREARE FILES CHE SONO DIFFICILI DA RIMUOVERE
.D.7. DIRECTORY NAME LOOKUPCACHE
.D.8. ATTACCO CSH
.D.9. CREARE FILES IN /tmp
.D.10. USARE RESOLV_HOST_CONF
.D.11. SUN 4.X E LAVORI NASCOSTI
.D.12. MANDARE IN CRASH DG/UX CON ULIMIT
.D.13. NETTUNE E HP-UX
.D.14. SOLARIS 2.X E NFS
.D.15. STABILITà DEL SISTEMA COMPROMESSA CON MOUNT_UNION
.D.16. trap_mon CAUSA IL KERNEL PANIC SOTTO SUNOS 4.1.X
.E. DUMPING CORE
.E.1. BREVE COMMENTO
.E.2. USO MALIZIOSO DI NETSCAPE
.E.3. CORE DUMPED SOTTO WUFTPD
.E.4. ld SOTTO SOLARIS/X86
.F. COME PROTEGGO UN SISTEMA DAGLI ATTACCHI DENIAL OF SERVICE?
.F.1. PROTEZIONI DI BASE
.F.1.1. INTRODUZIONE
.F.1.2. PORT SCANNING
.F.1.3. CONTROLLA GLI ATTACCHI DALL'ESTERNO DESCRITTI
.F.1.4. CONTROLLA GLI ATTACCHI DALL'INTERNO DESCRITTI
.F.1.5. SISTEMI DI MASSIMA SICUREZZA
.F.1.6. CONTROLLARE LA SICUREZZA
.F.1.7. MANTENERE AGGIORNATO
.F.1.8. LEGGERE QUALCOSA DI MEGLIO
.F.2. CONTROLLARE LE PRESTAZIONI
.F.2.1. INTRODUZIONE
.F.2.2. COMANDI E SERVIZI
.F.2.3. PROGRAMMI
.F.2.4. RESOCONTI
.G. LETTURE SUGGERITE
.G.1. INFORMAZIONI PER CONOSCENZE PIù PROFONDE
.G.2. INFORMAZIONI SUGLI AGGIORNAMENTI
.G.3. INFORMAZIONI DI BASE
.H. COPYRIGHT
.I. DISCLAIMER
.0. PREFAZIONE
------------
In questo documento ho cercato di rispondere alle seguenti domande:
- Cos'è un attacco denial of service?
- Perchè qualcuno dovrebbe mandare in crash un sistema?
- Come si manda in crash un sistema?
- Come proteggo un sistema da un attacco denial of service?
C'è anche una sezione chiamata LETTURE SUGGERITE dove puoi trovare
suggerimenti su informazioni gratuite che ti potrebbero fornire una
conoscenza più dettagliata su qualcosa.
Ricorda che ho un'esperienza limitata con Macintosh, OS/2 e Windows
e la maggior parte del materiale è quindi per Unix.
Puoi trovare sempre le versioni più aggiornate al seguente indirizzo:
http://www.student.tdb.uu.se/~t95hhu/secure/denial/DENIAL.TXT
[NdT logicamente i testi sono in inglese]
Per commenti, suggerimenti e altro a:
t95hhu@student.tdb.uu.se
.A. INTRODUZIONE
~~~~~~~~~~~~~~~~
.A.1. COS'è UN ATTACCO DENIAL OF SERVICE
----------------------------------------
Denial of service quando si mettono fuori uso i servizi, per
esempio attraverso il crash dell'intero sistema. Questi tipi
di attacchi sono semplici da eseguire ed è difficile proteggere
un sistema contro di essi. Il problema di base è che Unix
presume che gli utenti sul sistema o su altri sistemi sanno
come comportarsi.
.A.2. PERCHè QUALCUNO DOVREBBE MANDARE IN CRASH UN SISTEMA?
-----------------------------------------------------------
.A.2.1. INTRODUZIONE
--------------------
Perchè qualcuno dovrebbe mandare in crash un sistema? Ci sono molti
motivi e ho presentato essi in maniera più specifica in una sezione
per ogni motivo, ma in sintesi:
.1. Introduzione
.2. Stato sottoculturale
.3. Per guadagnare l'accesso
.4. Vendetta
.5. Ragioni politiche
.6. Ragioni economiche
.7. Cattiveria
Penso che il primo e il sesto sono i più comuni oggi, ma che il quarto
e il quinto saranno i più comuni in futuro.
.A.2.2. STATO SOTTOCULTURALE
----------------------------
Dopo tutte le informazioni sul syn flood molti di tali attacchi
erano eseguiti dalla Svezia. La stragrande maggioranza di questi
attacchi non erano una parte di un attacco IP-spoof, erano "solo"
un attacco denial of service. Perchè?
Penso che gli hackers attaccano i sistemi per una pseudo-carriera
sottoculturale e penso che molti attacchi denial of service, e quì
nell'esempio il syn flood, erano eseguiti per questo motivo. Penso
anche che molti hackers cominciano la loro carriera con attacchi
denial of service.
.A.2.3. PER GUADAGNARE L'ACCESSO
--------------------------------
A volte un attacco denial of service potrebbe essere una parte di un
attacco per guadagnare l'accesso in un sistema. Al momento posso
pensare questo motivo e specificare i metodi:
.1. Qualche vecchia versione di x-lock potrebbe essere mandata
in crach con un metodo preso dalla famiglia dei denial of service
lasciando il sistema aperto. L'accesso fisico era necessario per
usare lo spazio di lavoro.
.2. Syn flood potrebbe essere una parte di un attacco IP-spoof.
.3. Alcuni programmi di sistema potrebbero avere buchi all'avvio,
che potrebbero essere usati per avere l'accesso root, per esempio
SSH (secure shell).
.4. Sotto un attacco potrebbe essere utile mandare in crash altre
macchine nella rete o negare ad alcune persone l'abilità di accedere
al sistema.
.5. Inoltre un sistema potrebbe essere avviato a volte in modo
sovvertito, specialmente nei rarp-boots. Se sappiamo quale porta
controlla il sistema (69 potrebbe essere un buon indizio) all'
avvio possiamo mandare falsi pacchetti e controllare quasi
totalmente l'avvio.
.A.2.4. VENDETTA
----------------
Un attacco denial of service potrebbe essere una parte di una vendetta
contro un utente o un amministratore.
.A.2.5. RAGIONI POLITICHE
-------------------------
Prima o poi vecchie e nuove organizzazioni capiranno il modo di
distruggere computer di sistemi e troveranno strumenti per farlo.
Per esempio immagina la Banca A che presta dei soldi alla Compagnia B
per costruire una fabbrica che minaccia l'ambiente. L'organizzazione C
L'organizzazione C quindi manda in crash il computer di sistema di A,
forse con l'aiuto di un impiegato. L'attacco potrebbe costare ad A una
grande quantità di denaro se il tempismo è giusto.
.A.2.6. RAGIONI ECONOMICHE
--------------------------
Immagina la piccola compagnia A che si muove in un mercato dominato
totalmente dalla compagnia B. I clienti di A e B fanno gli ordini dai
computers e dipendono pesantemente sull'orario che è stato effettuato (A
e B potrebbero essere compagnie di scambio). Se A e B non possono effettuare
l'ordine i clienti perdono tempo e cambiano compagnia.
Come parte di strategia di mercato A paga un esperto di computer per mandare
in crash i computers di B un numero di volte. Un anno dopo A è la compagnia
dominante.
.A.2.7. CATTIVERIA
------------------
Conosco una persona che trova una workstation dove l'utente si è dimenticato
di uscire. Questa persona si siede e scrive un programma che fa un kill -9 -1
a tempo indeterminato per almeno 30 minuti dopo il tempo di entrata e ha
piazzato una chiamata a un programma dal suo file di profilo. Questa è
cattiveria.
.A.3. ALCUNI SISTEMI OPERATIVI SONO PIù SICURI?
-----------------------------------------------
Questa è una domanda difficile a cui è difficile rispondere e non penso
che sarà data qualcosa per confrontare differenti piattaforme Unix.
Non puoi dire che un Unix è più sicuro di un altro contro i denial of
service, tutto dipende dall'amministratore.
Un confronto tra Windows 95 e NT da un lato e Unix e gli altri può
essere comunque interessante.
I sistemi Unix sono molto più complessi e hanno centinaia di programmi
integrati, servizi... Questo spesso apre molte vie per mandare in crash
il sistema dall'interno.
Nella normale rete Windows NT e 95 ci sono pochi modi per mandare in
crash il sistema. Comunque ci sono dei metodi che funzionano sempre.
Questo ci dice che non c'è una grande differenza tra Microsoft e Unix
per quanto riguarda gli attacchi dall'interno. Ma ci sono un paio di
punti:
- Unix ha molti più strumenti e programmi per scoprire un
attacco e controllare gli utenti. Per vedere cosa fa un
utente in windows è molto difficile.
- Gli amministratori medi di Unix probabilmente ha molta
più esperienza degli amministratori medi di Microsoft.
Questi due punti ci dicono che Unix è più sicuro contro gli attacchi
denial of service dall'interno.
Un confronto tra Microsoft e Unix per quanto riguarda gli attacchi
dall'esterno è molto più difficile. Comunque vorrei dire che i sistemi
medi Microsoft su Internet è più sicuro contro gli attacchi dall'esterno,
perchè normalmente hanno molti meno servizi.
.B. ALCUNI OBIETTIVI DI BASE PER UN ATTACCO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.B.1. SPAZIO SWAP
-----------------
La maggior parte dei sistemi hanno molte centinaia di Mbytes
di spazio swap per le richieste di servizio dei clients. Lo
spazio swap è usato tipicamente per una paio di processi che
hanno breve vita. Lo spazio swap non sarà quasi mai molto
usato. Un denial of service potrebbe essere basato su un
metodo che cerca di riempire lo spazio swap.
.B.2. FREQUENZA
-----------
Se la frequenza è troppo alta la rete non sarà più utilizzabile. La
maggior parte degli attacchi denial of service influenzano la
frequenza in alcuni casi.
.B.3. TAVOLE DEL KERNEL
-----------------------
E' banale traboccare le tavole del kernel che causeranno
seri problemi al sistema. I sistemi con cache vuota e piccoli
buffers buoti sono particolarmente sensibili.
L'allocazione di memoria del kernlel è anche un obietivo che è
sensibile. Il kernel ha un limite di kernelmap, se il sistema
supera questo limite non può essere più allocata memoria del
kernel e si deve riavviare la macchina. La memoria del kernel non
è usata solo per la RAM, CPU, schermi, e così via, è anche usata
per processi ordinari. Questo significa che ogni sistema può
essere mandato in crash e con un cattivo (o in alcuni casi buono)
algoritmo abbastanza veloce.
Per Solaris 2.X è misurato e riportato con il comando sar quanta
memoria del kernel sta usando il sistema, ma per SunOS 4.X non c'è
quel comando. Ciò significa che sotto SunOS 4.X non avrai un avviso.
Se usi Solaris devi scrivere sar -k 1 per avere le informazioni.
netstat -k può essere usato e mostra quanta memoria il kernel ha
allocata.
.B.4. RAM
---------
Un attacco denial of service che alloca una grande quantità di RAM
può causare una grande quantità di problemi. I servers NFS e di posta
sono attualmente estremamente sensibili perchè non hanno bisogno di
molta RAM e spesso non hanno molta RAM. Un attacco a un server NFS è
banale. Il normale client NFS farà una grande quantità di caching,
ma un clent NFS può includere comunque il programma che hai scritto
tu...
.B.5. DISCHI
------------
Un attacco classico è riempire l'hard disk, ma un attacco ai dischi
può fare molto di più. Per esempio un disco sovraccaricato può essere
manomesso in molti modi.
.B.6. CACHE
------------
Un attacco denial of service che coinvolge la cache può essere basato
su un metodo per bloccare la cache o per annullarla.
Queste cache sono trovte su Solaris 2.X:
Directory name lookup cache: Associa il nome di un file con un vnode.
Inode cache: Deposita le informazioni lette da un disco se sono ancora
necessarie.
Rnode cache: Raccoglie informazioni sul filsystem NFS.
Buffer cache: Collega i blocchi e i cilindri con il disco I/O.
.B.7. INETD
-----------
Una volta che inetd è andato in crash tutti gli altri servizi che
sono eseguiti attraverso inetd non funzioneranno più.
.C. ATTACCARE DALL'ESTERNO
~~~~~~~~~~~~~~~~~~~~~~~~~~
.C.1. AVERE PROFITTO CON IL FINGER
----------------------------------
La maggior parte delle installazioni del fingerd supportano i
reindirizzamenti agli altri gost.
Es:
$finger @system.two.com@system.one.com
il finger nell'esempio andrà attraverso system.one.com a system.two.com.
Così system.two.com sa che è system.one.com che fa il finger. Così
questo metodo può essere usato per nascondersi, ma anche per
un attacco denial of service. Guarda quì:
$ finger @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@host.we.attack
Tutti quei segni @ faranno un finger a host.we.attack una, due, tre
... volte. L'effetto su host.we.attack è potente e il risultato è
grande frequenza, poca memoria libera e hard disk con poco spazio libero,
dovuto a tutti i processi figli (confronta con .D.5.).
La soluzione è installare un fingerd che non supporta i reindirizzamenti,
per esempio GNU finger. Puoi anche eliminare il servizio finger, ma penso
che è un po' troppo.
.C.2. UDP E SUNOS 4.1.3.
------------------------
SunOS 4.1.3. si avvia se un pacchetto con un'informazione non corretta
nell'header è mandata ad esso. Questa è l causa se l'ip_options indica
una dimensione sbagliata del pacchetto.
La soluzione è di installare la patch appropriata.
.C.3. BLOCCARE UP X-WINDOWS
---------------------------
Se un host accetta una sessione telnet alla porta di X-Windows
(generalmente una porta tra 6000 e 6025. Nella maggior parte dei casi
6000) potrebbe essere usata per bloccare il sistema X-Windows. Questo
può essere fatto con molte connessioni telnet alla porta o con un
programma che manda molti XOpenDisplay() alla porta.
La stessa cosa può accadere a Motif o Open Windows.
La soluzione è di negare le connessioni alla porta X-Windows.
.C.4. USO MALIZIOSO DEI SERVIZI UDP
-----------------------------------
E' semplice avere i servizi UDP (echo, time, daytime, chargen) da
far andare in loop, a causa di banali IP-spoofing. L'effetto può
essere alta frequenza che causa l'inutilità della rete. Nell'esmpio
l'header richiede che il pacchetto viene da 127.0.0.1 (loopback) e
l'obiettivo è la porta echo di system.we.attack. Siccome
system.we.attack conosce 127.0.0.1 il collegamento è stato stabilito.
Es:
from-IP=127.0.0.1
to-IP=system.we.attack
Packet type:UDP
from UDP port 7
to UDP port 7
Nota che il nome system.we.attack sembra un nome DNS, ma l'obiettivo
dovrebbe essere sempre rappresentato dall'IP.
Citazione dal commento di proberts@clark.net (Paul D. Robertson) su
comp.security.firewalls sul tema di "Introduzione ai denial of service"
" Una grande quantità di sistemi non mettono loopback sulla rete,
e semplicemente li emulano. Quindi, questo attacco avrà l'effetto
desiderato sulla macchina solo in alcuni casi. E' molto meglio
usare l'indirizzo di una differente macchina sulla stessa rete.
Ancora, i servizi standard dovrebbero essere disabilitati in
inetd.conf. Altri attacchi per stacks di IP che non supportano
ICMP, il servizio echo non è usato da molti programmi, e TCP
echo dovrebbe essere usato al posto di UDP dove è necessario ".
.C.5. ATTACCARE CON CLIENTS LYNX
--------------------------------
Un server Worold Wide Web inforcherà un processo httpd come una
risposta a una richiesta da un client, spesso Netscape o Mosaic.
Il processo dura meno din un secondo e il caricamento non sarà
mai mostrato se qualcuno usa ps. Nella maggior parte dei casi è
comunque sicuro eseguire un attacco denial of service che usa molti
clients W3, di solito clients lynx. Ma nota che il comando netstat
potrebbe essere usato per rintracciare l'attacco (grazie a Paul D.
Robertson).
Alcuni httpd (per esempio http-gw) hanno problemi normalmente con la
frequenza alta, poca memoria... E l'attacco può in quei casi far andare in
loop il server. (confronta con .C.6.)
.C.6. USO MALIZIOSO DI telnet
-----------------------------
Studia questo piccolo script:
while : ; do
telnet system.we.attack &
done
Un attacco che usa questo script potrebbe mangiare della frequenza,
ma non ha niente a che vedere con il metodo finger o altri metodi.
Il punto è che alcuni comuni firewall e httpd pensano che l'attacco
è un loop e lo annullano, fino a che l'amministratore non manda un
kill -HUP.
Questa è una semplice vulnerabilità ada alto rischio che dovrebbe
essere controllata e se presente riparata.
.C.7. USO MALIZIOSO DI telnet SU SOLARIS 2.4
---------------------------------------------
Se l'attacco fa una connessione telnet all'host Solaris 2.4 e quit
si usa:
Control-}
quit
inetd lo terrà per sempre. Un paio di centinaia...
La soluzione è installare la patch appropriata.
.C.8. COME DISABILITARE GLI ACCOUNTS
------------------------------------
Alcuni sistemi disabilitano un account dopo alcune login sbaglite, o
aspettano alcuni secondi. Tu puoi usare questa funzione per cacciare
gli utenti dal sistema.
.C.9. LINUX E TCP TIME, DAYTIME
----------------------------------
Si sa che inetd sotto Linux va in crach se troppo pacchetti SYN sono
mandati a daytime (porta 13) e/o a time (porta 37).
La soluzione è installare la patch appropriata.
.C.10. COME DISABILITARE I SERVIZI
----------------------------------
La maggior parte dei sistemi Unix disabilitano i servizi dopo un certo
numero di sessioni aperte in un certo periodo di tempo. La maggior parte
dei sistemi hanno uno standard ragionevole (diciamo 800-1000), ma non
alcuni sistemi SunOS che hanno lo standard a 48...
La soluzione è settare il numero in qualcosa di ragionevole.
.C.11. PARAGON OS BETA R1.4
---------------------------
Se qualcuno reindirizza un pacchett ICMP (Internet Control Message Protocol)
a un paragon OS beta R1.4 la macchina si bloccherà e deve essere riavviata.
Un reindirizzo di ICMP dice al sistema di sostituire le tavole di routing.
I router usano questo per dire all'host che sta mandando il pacchetto a un
router sbagliato.
La soluzione è installare la patch appropriata.
.C.12. FTP DI NOVELLS NETWARE
-----------------------------
Il server FTP di Novells Netware è conosciuto poichè la memoria si riduce
se ci sono molte sessioni ftp connesse.
.C.13. ATTACCHI CON REINDIRIZZAMENTO DI ICMP
--------------------------------------------
Le Gateways usano il reindirizzamento di ICMP per dire al sistema di cambiare
le tavole di routing, cioè sta dicendo al sistema di prendere una via migliore.
Per manomettere il reindirizzo degli ICMP dobbiamo conoscere una connessione
esistente (ne possiamo creare una per noi stessi, ma non c'è molto utilizzo
per quella). Se abbiamo trovato una connessione noi possiamo mandare un flusso
che gli fa perdere la connessione o potremmo mandare falsi messaggio all'host
se la connesione che abbiamo trovato non cripta i pacchetti.
Es: (messaggio falso da mandare)
DESTINATION UNREACHABLE
TIME TO LIVE EXCEEDED
PARAMETER PROBLEM
PACKET TOO BIG
L'effetto di tale messaggio è il blocco della connessione.
La soluzione potrebbe essere disabilitare il reindirizzamento di ICMP, non
usato propriamente dal servizio.
.C.14. TEMPESTE DI BROADCAST
----------------------------
Questo è un metodo molto popolare nelle reti dove tutti gli host agiscono
come gateways.
Ci sono molte versioni dell'attacco, ma il metodo di base è mandare molti
pacchetti a tutti gli host nella rete con una destinazione che non esiste.
Ogni host cercherà di inoltrare ogni pacchetto così i pacchetti rimbalzeranno
per molto tempo. E se si aggiungono i nuovi pacchetti alla rete, la rete
sarà nei guai.
I servizi che possono essere manomessi e utilizzati in questo tipo di attacco
sono per esempio il ping, il finger e il sendmail. Ma possono essere manomessi
la maggior parte dei servizi in un modo o nell'altro.
.C.15. EMAIL BOMBING E SPAMMING
-------------------------------
In un attacco email bombing l'attaccante manderà ripetutamente identici messaggi
email a un indirizzo. L'effetto sull'obiettivo è alta frequenza, un hard disk con poco
spazio e così via... L'email spamming è quando si mandano delle mail a tutti (o
quasi) gli utenti del sistema. Il motivo per il quale si usa lo spamming al posto
del bombing è che alcuni utenti cercano di mandare una risposta e se l'indirizzo
è falso, la mail tornerà indietro. In quel caso una mail si è trasformata in tre
mail. L'effetto sulla frequenza è ovvio.
Non c'è modo di prevenire un email bombing o spamming. Comunque dai un'occhiata
al documento della CERT "Email bomginb and spamming".
.C.16. TIME E KERBEROS
----------------------
Se le macchine sorgente e obiettivo sono allineate da vicino il biglietto verrà
respinto, ciò significa che se il protocollo che setta il tempo è protetto sarà
possibile settare un server kerberos.
.C.17. IL BUG DOT DOT
---------------------
Il sistema di condivisione file di Windows NT è vulnerabile al famoso bug dot dot
sotto Windows 95. Ciò significa che chiunque può mandare in crash il sistema. Se
qualcuno manda un "DIR ..\" alla workstation un messaggio di STOP apparirà sullo
schermo del computer Windows NT. Nota che è applicabile alle versioni 3.50 e 3.51
per le versioni sia workstation che server.
La soluzione è installare la patch appropriata.
.C.18. KERNEL PANIC DEL SUNOS
-----------------------------
Alcuni sistemi SunOS (che eseguono TIS?) avranno un kernel panic se è mandato un
getsockopt(). La connessione così sarà interrotta.
La soluzione potrebbe essere installare la Sun Patch 100804.
.C.19. APPLETS OSTILI
---------------------
Una applet ostile è quando un applet cerca di usare il tuo sistema in un modo
inappropriato. I problemi nel linguaggio java potrebbero essere ordinati in due
grandi gruppi:
1) Problemi dovuti ai bugs.
2) Problemi dovuti a caratteristiche nel linguaggio.
Nel primo gruppo abbiamo per esempio il bug java bytecode verifier, che permette a
un'applet di eseguire tutti i comandi che un utente potrebbe eseguire. Ciò significa
che tutti i metodi di attacco descritti in .D.X. possono essere seguiti attraverso
un'applet. Il bug java bytecode verifier fu scoperto a fine Marzo 1996 e non ci sono
patch disponibili (correggetemi se sbaglio!).
[NdT siccome il documento è un po' vecchio, probabilmente ora esiste una patch per
questo bug]
Nota che due altri bugs possono essere inseriti nel primo gruppo ma sono entrambi
riparati in Netscape 2.01 e JDK 1.0.1.
Il gruppo due è più interessante e una grande problema è il fatto che java può
connettersi alle porte. Ciò significa che tutti i metodi descritti in .C.X. possono
essere eseguiti da un'applet. Maggiori informazioni ed esempio possono essere
trovati all'indirizzo:
http://www.math.gatech.edu/~mladue/HostileArticle.html
Se hai bisogno di un maggior livello di sicurezza usa dei firewall che proteggono
da java. Come utente, dovresti aver disabilitato java.
.C.20. VIRUS
------------
I virus per il computer sono scritti allo scopo di distruggere e propagare i sistemi.
I virus sono ancora il metodo d'attacco denial of service più diffuso.
Non è vero che scrivere virus è difficile. Se conosci il linguaggio assembly e hai
alcuni codici sorgente di virus è facile. Si possono scaricare degli strumenti per la
costruzione di virus, per esempio:
* Genvir.
* VCS (Virus Construction Set).
* VCL (Virus Construction Laboratory).
* PS-MPC (Phalcon/Skism - Mass Produced Code Generator).
* IVP (Instant Virus Production Kit).
* G2 (G Squared).
PS-MPC e VCL sono i migliori e possono aiutare il programmatore novello a capire
come scrivere un virus.
Si può trovare anche uno strumento chiamato MtE. MtE trasformerà un virus in un
virus "mutevole". Il motore mutevole di MtE è noto e può essere rintracciato da
un antivirus.
.C.21. ABUSO DI FTP ANONIMO
---------------------------
Se un archivio FTP anonimo ha un'area scrivibile può essere manomesso per un attacco
denial of service simile a quello .D.3. Noi così possiamo riempire l'hard disk.
Un host inoltre può essere temporanemante inaccessibile a causa di eccessive
richieste FTP.
Pe maggiori informazioni su come proteggere un FTP anonimo, il documento della CERT
"Anonymous FTP Abuses" potrebbe essere un buon punto d'inizio.
.C.22. SYN FLOOD
----------------
Sia 2600 e Phrack hanno pubblicato informazioni sull'attacco syn flood. 2600 ha anche
pubblicato un exploit per l'attacco.
Come sappiamo il pacchetto syn è usato in un handshake di 3 fasi. L'attacco syn flood
è basato su un incompleto handshake. L'host che attacca manderà un flusso di pacchetti
syn ma non risponerà con un pacchetto ACK. Lo stack TCP/IP aspetterà un certo periodo
di tempo prima di interrompere la connessione, così un attacco syn flood manterrà quindi
la connessione tcp_received in coda della macchina colpita.
L'attacco syn flood è molto buono ed è facile trovare maggiori informazioni su di esso,
per esempio:
[.1.] http://www.eecs.nwu.edu/~jmyers/bugtraq/1354.html
Articolo di Christopher Klaus che include una "soluzione".
[.2.] http://jya.com/floodd.txt
2600, Estate, 1996, pp. 6-11. FLOOD WARNING di Jason Fairlane
[.3.] http://www.fc.net/phrack/files/p48/p48-14.html
IP-spoofing Demystified by daemon9 / route / infinity
per Phrack Magazine
.C.23. PING FLOOD
-----------------
Non testato quanto può essere grande un attacco ping flood, ma potrebbe essere abbastanza
grande.
Sotto Unix possiamo trovare qualcosa come: ping -s host
per mandaer pacchetti di 64 bytes.
Se hai Windows 95, clicca sul pulsante Avvio, poi su Esegui e poi scrivi:
PING -T -L 256 xxx.xxx.xxx.xx. Eseguilo circa 15 volte contemporaneamente.
.C.24. MANDARE IN CRASH I SISTEMI CON IL PING DI WINDOWS 95
-----------------------------------------------------------
Se qualcuno può pingare la tua macchina da una macchina Windows 95 eglio può resettare o
bloccare la tua macchina. L'attaccante scrive semplicemente:
ping -l 65510 address.to.the.machine
E la macchina si bloccherà o si riavvierà.
Funziona con il kernel 2.0.7 fino alla versione 2.0.20 e 2.1.1 per Linux (crash).
AIX4, OSF, HPUX 10.1,DUnix 4.0 (crash).
OSF/1, 3.2C, Solaris 2.4 x86 (riavvio).
.C.25. USO MALIZIOSO DEL MESSAGGIO DI RISPOSTA DELLE SUBNET MASK
----------------------------------------------------------------
Il messaggio di riposta delle subnet mask è usato al riavvio, ma alcuni hosts
accettano il messaggio ogni volta senza controllare. In questo modo tutte le
comunicazioni a o dall'host sono interrotte.
L'host non dovrebbe accettare il messaggio sempre ma solo durante il riavvio.
.C.26. FLEXlm
-------------
Ogni host che esegue FLEXlm ha la FLEXlm license manager daemon su ogni rete
che per spegnere usano il comando FLEXlm lmdown.
# lmdown -c /etc/licence.dat
lmdown - Copyright (C) 1989, 1991 Highland Software, Inc.
Shutting down FLEXlm on nodes: xxx
Are you sure? [y/n]: y
Shut down node xxx
#
.C.27. PARTIRE CON FTP BANALI
-----------------------------
Per partire con workstation senza disco si usa un ftp banale con rarp o bootp.
Se un attaccante non è protetto può usare tftp per avviare l'host.
.D. ATTACCARE DALL'INTERNO
~~~~~~~~~~~~~~~~~~~~~~~~~~
.D.1. KERNEL PANIC SOTTO SOLARIS 2.3
------------------------------------
Solaris 2.3 avrà un kernel panic se è eseguito questo:
$ndd /dev/udp udp_status
La soluzione è installare la patch appropriata.
.D.2. MANDARE IN CRASH IL SERVER X
----------------------------------
Se stickybit non è settato in /tmp, il file /tmp/.x11-unix/x0 può essere rimosso
e il server X andrà in crash.
Es:
$ rm /tmp/.x11-unix/x0
.D.3. RIEMPIRE L'HARD DISK
--------------------------
Se lo spazio sul tuo hard disk non è limitato o se puoi usare /tmp è possibile
riempire il file system.
Es:
while : ;
mkdir .xxx
cd .xxx
done
.D.4. USO MALIZIOSO DI eval
---------------------------
Alcuni vecchi sistemi andranno in crash se è eseguito eval '\!\!' in una C-shell.
Es:
% eval '\!\!'
.D.5. USO MALIZIOSO DI fork()
-----------------------------
Se qualcuno esegue questo programma C++ il risultato sarà il crash della maggior
parte dei sistemi.
Es:
#include
#include
#include
main()
{
int x;
while(x=0;x<1000000;x++)
{
system("uptime");
fork();
}
}
Puoi usare tutti i comandi che vuoi, ma uptime è bello perchè mostra il carico
di lavoro.
Per avere un attacco più grande e potente dovresti comunque rimpiazzare uptime
con sync. Questo è molto cattivo.
Se fai sul serio puoi instaurare un processo "figlio" per ogn processo "figlio" e
avremo un incremento del carico di lavoro.
Non ci sono buoni modi di fermare questo attacco e attacchi simili. Una soluzione
potrebbe essere piazzare un limite di tempo sull'esecuzione e dimensione dei processi.
.D.6. CREARE FILES CHE SONO DIFFICILI DA RIMUOVERE
--------------------------------------------------
Tutti i files possono essere rimossi, ma quì c'è qualche idea:
Es.1.
$ cat > -xxx
^C
$ ls
-xxx
$ rm -xxx
rm: illegal option -- x
rm: illegal option -- x
rm: illegal option -- x
usage: rm [-fiRr] file ...
$
Es.2.
$ touch xxx!
$ rm xxx!
rm: remove xxx! (yes/no)? y
$ touch xxxxxxxxx!
$ rm xxxxxxxxx!
bash: !": event not found
$
Altri metodi conosciuti sono files con caratteri dispari o spazi nel nome.
Questi metodi potrebbero essere usati in combinazione con ".D.3. RIEMPIRE L'
HARD DISK". Se vuoi rimuovere questi files devi usare degli script o un'interfaccia
grafica come il File Manager di OpenWindow. Puoi anche tentare di usare: rm ./
Dovrebbe funzionare per il primo esempio se hai una shell.
.D.7. DIRECTORY NAME LOOKUPCACHE
--------------------------------
Directory name lookupcache (DNLC) è usato quando un file è aperto. DNLC associa
il nome del file a un vnode. Ma DNLC può solo operare su files i quali nomi sono
composti da un certo numero di caratteri (per SunOS 4.x fino a 14 caratteri, per
Solaris 2.x fino a 30 caratteri). Questo significa che è facile eseguire un discreto
attacco denial of service.
Crea diciamo 20 directory (per iniziare) e metti 10 files vuoti in ogni directory.
Fai sì che ogni nome di file abbia oltre i 30 caratteri ed esegui uno script che
fa molti ls-al nelle directory.
Se l'impatto non è grande abbastanza, dovresti creare più files o eseguire più
processi.
.D.8. ATTACCO CSH
-----------------
Esegui questo in /bin/csh (dopo le modifiche appropriate) e il livello di caricamento
salirà di molto (100% del tempo della cpu) in poco tempo.
|I /bin/csh
nodename : **************b
.D.9. CREARE FILES IN /tmp
--------------------------
Molti programmi creano files in /tmp, ma è difficile trattare del problema se
il file esiste già. In alcuni casi questo potrebbe essere usato per un attacco
denial of service.
.D.10. USARE RESOLV_HOST_CONF
-----------------------------
Alcuni sistemi hanno un piccolo buco di sicurezza nel modo in cui usano la variabile
RESOLV_HOST_CONF. Noi possiamo mettere delle cose in esso e attraverso l'accesso
ping avremo dei dati come /etc/shadow o potremo mandare in crash il sistema. La maggior
parte dei sistemi andranno in crash se c'è /proc/kcore nella variabile e accedendo
tramite ping.
Es:
$ export RESOLV_HOST_CONF="/proc/kcore" ; ping asdf
.D.11. SUN 4.X E LAVORI NASCOSTI
--------------------------------
Grazie a Mr David Honig
" Metti la stringa "a&" in un file chiamato "a" e esegui un "chomod +x a". Eseguendo
"a" disattiverai lentamente una macchina SunOS 4.x, disabilitando anche il login root
e riempiendo le tavole del kernel."
" La cosa bella è la dimensione dello script, e quante poche battute di tasti ci vogliono
per disattivare una macchina Sun come utente".
.D.12. MANDARE IN CRASH DG/UX CON ULIMIT
----------------------------------------
ulimit è usato per settare un limite sulle risorse di sistema disponibili alla shell. Se
ulimit 0 è chiamato prima di /etc/passwd, sotto DG/UX, il file passwd sarà settato a 0.
.D.13. NETTUNE E HP-UX
----------------------
/usr/contrib/bin/nettune è SETUID root su HP-UX, cioè ogni utente può resettare tutti gli
ICMP, IP e i parametri TCP del kernel, per esempio i seguenti parametri:
- arp_killcomplete
- arp_killincomplete
- arp_unicast
- arp_rebroadcast
- icmp_mask_agent
- ip_defaultttl
- ip_forwarding
- ip_intrqmax
- pmtu_defaulttime
- tcp_localsubnets
- tcp_receive
- tcp_send
- tcp_defaultttl
- tcp_keepstart
- tcp_keepfreq
- tcp_keepstop
- tcp_maxretrans
- tcp_urgent_data_ptr
- udp_cksum
- udp_defaultttl
- udp_newbcastenable
- udp_pmtu
- tcp_pmtu
- tcp_random_seq
La soluzione potrebbe essere settare il permesso appropriato a /sbin/mount_union:
#chmod u-s /sbin/mount_union
.D.14. SOLARIS 2.X E NFS
------------------------
Se un processo sta scrivendo a NFS e l'utente supera lo spazio sul disco il processo
andrà in un loop infinito.
.D.15. STABILITà DEL SISTEMA COMPROMESSA DA MOUNT_UNION
-------------------------------------------------------
Eseguendo una sequenza di comandi mount_union ogni utente può causare un "ricaricamento"
del sistema su tutti i FreeBSD 2.x prima del 18/05/1996.
$ mkdir a
$ mkdir b
$ mount_union ~/a ~/b
$ mount_union -b ~/a ~/b
La soluzione potrebbe essere settare il permesso appropriato in /sbin/mount_union:
#chmod u-s /sbin/mount_union
.D.16. trap_mon CAUSA KERNEL PANIC SOTTO SUNOS 4.1.X
----------------------------------------------------
Eseguendo l'istruzione trap_mon da utente si può causare un kernel panic o un
"window underflow watchdog reset" sotto SunOS 4.1.x, architettura sun4c.
.E. DUMPING CORE
~~~~~~~~~~~~~~~~
.E.1. BREVE COMMENTO
-------------------
I core dumps non appartengono in realtà a questo documento ma li ho messi comunque.
.E.2. USO MALIZIOSO DI NETSCAPE
-------------------------------
Sotto Netscape 1.1N questo collegamento causerà un segmentation fault e un core dump.
.F.1.7. CONTROLLARE LA SICUREZZA
--------------------------------
Inoltre controlla la sicurezza regolarmente, per esempio esaminando i log di sistema,
i files history... In ogni sistema senza altri sistemi di sicurezza alcuni strumenti
possono essere trovati. Alcuni strumenti sono:
- uptime
- showmount
- ps
- netstat
- finger
(vedi il testo del man per maggiori informazioni).
.F.1.8. MANTENERE AGGIORNATO
----------------------------
E' molto importante essere aggiornati con i problemi di sicurezza. Ricorda inoltre che
i siti, come CERT, avvisano quando il problema è già conosciuto dal pubblico "oscuro"
da qualche tempo, perciò non aspettare. Le risorse seguenti ti aiutano a mantenerti
aggiornato:
- Mailing list di CERT. Manda una email a cert@cert.org per iscriversi alla
lista
- Mailing list di Bugtraq. Manda una email a bugtraq-request@fc.net.
- Mailing list di WWW-security. Manda una email a www-security@ns2.rutgers.edu.
.F.1.9. LEGGI QUALCOSA DI MEGLIO
--------------------------------
Comincia con i documenti su Internet. Mi dispiace dire che non ci sono molti documenti
gratis disponibili, ma qui ho messo una piccola collezione.
(1) I Rainbow books sono una lunga serie di libri gratis sulla sicurezza del computer.
I cittadini degli USA possono prenderli da:
INFOSEC AWARENESS OFFICE
National Computer Security Center
9800 Savage Road
Fort George G. Meader, MD 20755-600
Noi dobbiamo leggere i documenti dal web. Ogni documento non può essere trovato su internet.
(2) "Improving the security of your Unix system" di Curry è anche buono se hai bisogno
di conoscenze di base. Se non sai niente sulla sicurezza del computer non potevi trovare un
inizio migliore.
(3) "The WWW security FAQ" di Stein tratta la sicurezza W3 ed è il miglior documento che
si può trovare su internet.
(4) CERT ha pubblicato anche dei buoni documenti, come per esempio:
- Anonymous FTP Abuses.
- Email Bombing and Spamming.
- Spoofed/Forged Email.
- Protecting yourself from password file attacks.
Penso comunque che l'ultimo documento ha tralasciato alcune cose.
(5) Per una lunga lista di documenti raccomando:
"FAQ: Computer Security Frequently Asked Questions".
(6) Vedi anche la sezione ".G. LETTURE SUGGERITE"
Potresti anche acquistare dei libri, ma non ne raccomando.
.F.2. CONTROLLARE LE PRESTAZIONI
--------------------------------
.F.2.1. INTRODUZIONE
--------------------
Ci sono molti comandi e servizi che possono essere usati per controllare le prestazioni.
Su internet si possono trovare almeno due buoni programmi gratuiti.
.F.2.2. COMANDI E SERVIZI
-------------------------
Per maggiori informazioni leggi il testo del man.
netstat Mostra lo stato della rete.
nfsstat Mostra le statistiche NFS.
sar Riporta l'attività del sistema.
vmstat Riporta le statistiche di memoria virtuale.
timex Temporizza un comando, riporta i dati dei processi e le attività di sistema.
time Temporizza un comando semplice.
truss Traccia le chiamate e i segnali di sistema.
uptime Mostra per quanto tempo il computer è stato acceso.
Nota che se un server netstat pubblico puoi usare netstat dall'esterno. netstat può
anche dare informazioni come i numeri di sequenza tcp e altro.
.F.2.3. PRGORAMMI
-----------------
Proctool: Proctool è uno strumento gratis per Solaris che controlla i processi.
ftp://opcom.sun.ca/pub/binaries/
Top: Top dovrebbe essere un programm più semplice di Proctool, ma è comunque buono.
.F.2.4. RESOCONTI
-----------------
Per controllare le prestazioni devi avere delle informazioni per un lungo periodo di
tempo. Tutti i sistemi Unix hanno dei log di resovonto per identificare quanto tempo,
CPU e memoria usa un programma. Dovresti controllare il tuo manuale per controllare
come abilitare questo servizio.
Potresti anche inventare il tuo sistema di resoconto usando contrab e uno script con
i comandi che vuoi eseguire. Fai eseguire lo script a contrab ogni giorno e controlli
le informazioni una volta a settimana. Potresti far eseguire allo script:
- netstat
- iostat -D
- vmstat
.G. LETTURE SUGGERITE
~~~~~~~~~~~~~~~~~~~~~
.F.1. INFORMAZIONI PER CONOSCENZE PIù PROFONDE
----------------------------------------------
(1) Hedrick, C. Routing Information Protocol. RFC 1058, 1988.
(2) Mills, D.L. Exterior Gateway Protocol Formal Specification. RFC 904, 1984.
(3) Postel, J. Internet Control Message Protocol. RFC 792, 1981.
(4) Harrenstien, K. NAME/FINGER Protocol, RFC 742, 1977.
(5) Sollins, K.R. The TFTP Protocol, RFC 783, 1981.
(6) Croft, W.J. Bootstrap Protocol, RFC 951, 1985.
Molti documenti in questa categoria erano degli RFC. Un RFC è un documneto
che descrive un protocollo. Le lettere RFC stanno per Request For Comment.
Si presume che su internet si conoscano almeno quelli più comuni. Se vuoi
saperne di più su un protocollo è sempre bene leggere l'appropriato RFC.
Puoi trovare un indice sugli RFC all'indirizzo:
http://pubweb.nexor.co.uk/public/rfc/index/rfc.html
.F.2. INFORMAZIONI SULL'AGGIORNAMENTO
-------------------------------------
(1) Mailing list di CERT. Manda una email a cert@cert.org per iscriverti.
(2) Mailing list di Bugtraq. Manda una email a bugtraq-request@fc.net.
(3) Mailing list di WWW-security. Manda una email a www-security@ns2.rutgers.edu.
(4) Sun Microsystems Security Bulletins.
(5) Vari articoli da: - comp.security.announce
- comp.security.unix
- comp.security.firewalls
(6) Varie pubblicazioni di 40Hex.
.F.3. INFORMAZIONI DI BASE
--------------------------
(1) Husman, H. INTRODUKTION TILL DATASÄKERHET UNDER X-WINDOWS, 1995.
(2) Husman, H. INTRODUKTION TILL IP-SPOOFING, 1995.
(3) I seguenti rainbow books: - Teal Green Book (Dizionario dei
termini di sicurezza).
- Bright Orange Book( Una guida per
capire il controllo della sicurezza
nei sistemi).
- C1 Technical Report-001
(Virus per il computer: prevenzione
rivelazione e trattamento).
(4) Ranum, Marcus. Firewalls, 1993.
(5) Sun Microsystems, OpenWindows V3.0.1. User Commands, 1992.
(6) Husman, H. ATT SPÅRA ODOKUMENTERADE SÄKERHETSLUCKOR, 1996.
(7) Dark OverLord, Unix Cracking Tips, 1989.
(8) Shooting Shark, Unix Nasties, 1988.
(9) LaDue, Mark.D. Hostile Applets on the Horizone, 1996.
(10) Curry, D.A. Improving the security of your unix system, 1990.
(11) Stein, L.D. The World Wide Web security FAQ, 1995.
(12) Bellovin, S.M. Security Problems in the TCP/IP Protocol, 1989.
------------
Post
Posta un commento