SICUREZZA DI BASE: Attacchi alla rete

Wednesday, 03 February 2010 15:21

Come effettuare Semplici attacchi di rete

ATTACCHI ALLA RETE (BEGINNER)

INTRODUZIONE

1) OTTENERE INFORMAZIONI

1.1 - CON UN SEMPLICE TELNET
1.2 Scanning della rete con nmap

2) GLI ATTACCHI FONDAMENTALIi

2.1 Sniffing
2.2 Denial of Service (DoS)

ATTACCHI ALLA RETE (BEGINNER)

INTRODUZIONE

Questa mini guida è da interdersi per i neofiti della rete, in particolare per tutti coloro che sono interessati e che si avvicinano per la prima volta ai temi della sicurezza di rete, temi che vengono trattati in maniera semplice e lineare con esempi concreti e di immediata attuazione. I presupposti tecnici per assimilare il contenuto di queste pagine consistono nell’avere già una minima esperienza di cosa si intende per shell e nel conoscere le linee fondamentali della teoria del TCP/IP, per quanto riguarda l’installazione/configurazione dei tool impiegati, ove presenti si rimanda al sito web ufficiale.

Ogni esercitazione presuppone almeno due PC configurati in rete locale, il primo con indirizzo IP 192.168.0.11 con netmask 255.255.255.0 (con installato Linux - Kernel 2.x.x) mentre il secondo con IP 192.168.0.10 con netmask 255.255.255.0 (con installato Windows), uno sarà l’attaccante e l’altro la vittima.

1) OTTENERE INFORMAZIONI

1.1 - CON UN SEMPLICE TELNET

Una tecnica molto semplice per ottenere informazioni sul sistema operativo e sul servizio in ascolto dell’host remoto consiste nell'effettuare un telnet sulle porte più comuni, sfruttando le informazioni ascii fornite dai protocolli dei banner. Aprire la shell e digitare il seguente comando

[root@rh73 root]$ telnet 192.168.0.10 80

get / http/1.0

Trying 192.168.0.10...

Connected to 192.168.0.10.

Escape character is '^]'.

HTTP/1.1 400 Bad Request

Server: Microsoft-IIS/5.1

Date: Sat, 22 Sep 2001 13:49:54 GMT

Content-Type: text/html

Content-Length: 87

C:\>telnet 192.168.0.11 80

get / http/1.0

Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1

.0.3 PHP/4.1.2 mod_perl/1.26

Allow: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE

Connection: close

Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD><TITLE>501 Method Not Implemented</TITLE> </HEAD><BODY><H1>Method Not Implemented</H1>get to /index

.html not supported.<P>Invalid method in request get / http/1.0<P>

<HR><ADDRESS>Apache/1.3.23 Server at RedHat73! Port 80</ADDRESS></BODY></HTML>

Da notare quante informazioni sull’host remoto siamo riusciti ad ottenere con un semplice telnet, nel primo caso verso una macchina Windows XP, nel secondo invece su una Linux box (RedHat).

Si può provare a connettersi sulla porta TCP 25, ottenedo informazioni sul demone della posta elettronica in uscita (SMTP) o eseguire un telnet sulla porta 21 (ftp).

1.2 Scanning della rete con nmap

(www.insecure.org/nmap/)

Per installare nmap, basta digitare dalla shell il seguente comando:

rpm –vhU http://www.insecure.org/nmap/dist/nmap-2.53-1.i386.rpm (funziona con Redhat e Mandrake). Un metodo di installazione che prescinde dalla distribuzione utilizzata è quello di compilare i sorgenti.

Lo stack del TCP/IP è implementato in maniera più o meno differente da sistema a sistema, il modo in cui un SO risponde (o meno) a determinati pacchetti TCP/IP consente di riconoscere con un a certa approssimazione un sistema operativo di rete remoto, di fare port scanning avanzati attraverso IP spoofing o scansioni stealth, etc. Una delle caratteristiche allettanti del programma di network scanning nmap consiste nel fatto che è estremamente duttile e personalizzabile in base alle esigenze. Consente di creare pacchetti IP ad hoc, formattati con i più disparati flag in modo da “ingannare” gli host vittime dei nostri attacchi.

Per effettuare lo scanning delle porte TCP usare lo switch –sT.

[root@rh73 root]# nmap -sT 192.168.0.10

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

Interesting ports on (192.168.0.10):

(The 1546 ports scanned but not shown below are in state: closed)

Port State Service

25/tcp open smtp

80/tcp open http

135/tcp open loc-srv

139/tcp open netbios-ssn

443/tcp open https

445/tcp open microsoft-ds

1025/tcp open listen

5000/tcp open fics

Nmap run completed -- 1 IP address (1 host up) scanned in 12 seconds

Mentre per il rilevamento delle porte UDP aperte, digitare –sU.

[root@rh73 root]# nmap -sU 192.168.0.10

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

Interesting ports on (192.168.0.10):

(The 1453 ports scanned but not shown below are in state: closed)

Port State Service

135/udp open loc-srv

137/udp open netbios-ns

138/udp open netbios-dgm

445/udp open microsoft-ds

500/udp open isakmp

3456/udp open vat

Nmap run completed -- 1 IP address (1 host up) scanned in 14 seconds

A volte può capitare che tra l’host che effettua la scansione e l’host vittima vi sia un firewall che blocchi I pacchetti ICMP echo request, in particolare pingando l’host vittima non si riceve risposta. In questo caso utilizzare l’opzione –P0, così nmap non pinga l’host e non blocca la scansione poichè non lo considera DOWN.

[root@rh73 root]# nmap -sU -P0 192.168.0.10

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

Interesting ports on (192.168.0.10):

(The 1453 ports scanned but not shown below are in state: closed)

Port State Service

135/udp open loc-srv

137/udp open netbios-ns

138/udp open netbios-dgm

445/udp open microsoft-ds

500/udp open isakmp

3456/udp open vat

Per individuare gli host attivi di una rete, si può utilizzare lo switch –sP, che invia pacchetti di tipo ICMP echo request agli host della rete.

[root@rh73 root]# nmap -sP 192.168.0/24

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

Host (192.168.0.10) appears to be up.

Host (192.168.0.11) appears to be up.

Host (192.168.0.12) appears to be up.

Host (192.168.0.13) appears to be up.

Host (192.168.0.14) appears to be up.

Nmap run completed -- 256 IP addresses (5 hosts up) scanned in 26 seconds

Per capire se le porte dell’host remoto sono filtrate o meno da un firewall, utilizzare lo switch –sA. Il programma invia pacchetti all’host vittima con il flag ack (riconoscimento) attivato ed analizza la risposta: se riceve pacchetti rst (reset) allora la porta è UNfiltered mentre se non riceve risposta allora la porta è filterd, in quanto protetta dal firewall.

[root@rh73 root]# nmap -sA -p 80 –P0 192.168.0.10

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

The 1 scanned port on (192.168.0.10) is: UNfiltered

[root@rh73 root]# nmap -sA -P0 192.168.0.10

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

All 1554 scanned ports on (192.168.0.10) are: Unfiltered

Con l’opzione -sS si effettua un TCP SYN stealth port scan, cioè l’host attiva i pacchetti che invia alla vittima con il flag syn per aprire una sessione ed attende come al solito la risposta: se riceve l’rst, la porta è chiusa mentre se riceve un syn-ack la porta è aperta. In questo caso, viene inviato subito un pacchetto di reset (rst) alla vittima per annullare la sessione la quale sessione TCP non completata in genere non viene annotata sui file di log della maggior parte dei sistemi a meno che non si concluda l’handshake a 3 fasi del TCP/IP che deteremina appunto l’instaurazione della sessione tra due host.

Three way TCP/IP handshake

Host----->syn----->Host vittima

Host<----syn-ack<--Host vittima

Host----->ack----->Host vittima (la conclusione dell’handshake viene registrata |nei log dell’host vittima)

Scansione con l’opzione –sS.

Host----->syn----->Host vittima

Host<----syn-ack<--Host vittima

Host----->rst----->Host vittima (il client risponde con un reset per non portare a compimento le tre fasi dell’handshake e quindi per evitare il logging sulla maggior parte dei sistemi operativi)

nmap mette a disposizione un’utile funzione per tentare di individuare il NOS in esecuzione sull’host remoto attraverso l’utilizzo di una serie di tecniche che identificano il TCP/IP fingerprinting dell’host remoto confrontandolo con il database di OS fingerprints di nmap.

NB: l’opzione –v può essere usata sempre, e serve per visuallizzare l’output completo di namp.

[root@rh73 root]# nmap -O -P0 -v 192.168.0.10

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. Use -sP if you really don't want to portscan (and just want to see what hosts are up).

Host (192.168.0.10) appears to be up ... good.

Initiating Connect() Scan against (192.168.0.10)

Adding open port 445/tcp

Adding open port 21/tcp

Adding open port 1025/tcp

Adding open port 80/tcp

Adding open port 25/tcp

Adding open port 139/tcp

Adding open port 443/tcp

Adding open port 135/tcp

Adding open port 5000/tcp

The Connect() Scan took 3 seconds to scan 1554 ports.

For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled

Interesting ports on (192.168.0.10):

(The 1545 ports scanned but not shown below are in state: closed)

Port State Service

21/tcp open ftp

25/tcp open smtp

80/tcp open http

135/tcp open loc-srv

139/tcp open netbios-ssn

443/tcp open https

445/tcp open microsoft-ds

1025/tcp open listen

5000/tcp open fics

Remote OS guesses: Windows Me or Windows 2000 RC1 through final release, Windows Millenium Edition v4.90.3000

TCP Sequence Prediction: Class=random positive increments Difficulty=18387 (Worthy challenge) IPID Sequence Generation: Incremental

Ci sono due modi per fare una scansione delle porte senza che l’host vittima abbia la certezza o possa individuare l’IP dell’host malintenzionato, in particolare l’opzione –D (decoy) e l’opzione –S (IP spoofing).

Con il decoy si fa in modo che l’host vittima creda che più host stiano facendo la scansione su di esso, in questo modo non riesce ad individuare con esattezza quale host è quello da cui realmente è partito il port scannning. L’opzione “me” nella riga di comando rappresenta l’ip del proprio host, quello che effettua la scansione. In tal modo l’host vittima riceverà i pacchetti TCP con flag syn attivato (-sS) nell’ordine in cui sono impostati nel comando di nmap. E’ importante che gli host indicati nel comando siano attivi altrimenti si può essere facilmente individuati essendo il nostro l’unico IP attivo.

[root@rh73 root]# nmap 192.168.0.10 -sS -D 192.168.0.12, 192.168.0.13,me,192.168.0.14

L’altro modo consiste nell’usare l’opzione –S per effettuare l’IP spoofing e contemporamente colpire la vittima con il port scanning. La figura 1 dimostra come Tiny Personal Firewall abbia loggato l’IP dell’host malintenzionato come 1.1.1.1 mentre il suo vero IP è 192.168.0.11. Purtoppo (per l’attacker ma non per la vittima!) il firewall non ha permesso ad nmap di individuare le porte aperte, in quanto risultano filtered.

[root@rh73 root]# nmap -P0 -e eth0 -S 1.1.1.1 -sS 192.168.0.10

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )

All 1554 scanned ports on (192.168.0.10) are: filtered

Nmap run completed -- 1 IP address (1 host up) scanned in 1724 seconds

+---------------------------------------------------------------+

| Someone from 1.1.1.1, port 59171 wants to connect to port 80 |

| owned by ‘Internet Information Services’ on your computer. |

+---------------------------------------------------------------+

figura 1

Un’altra interessante opzione è –f che esegue la frammentazione dell’intestazione TCP su una serie di pacchetti quando si effettuano alcuni tipi di scansioni (SYN, FIN, XMAS, NULL). Questo rende più difficile la vita ai sistemi di Intrusion Detection (IDS)

Per avere una dimostrazione concreta dell’uso di nmap, sarebbe utile avere due PC a disposizione. Sul primo si lancia nmap con le opzioni fin qui descritte, sul secondo PC (l’host vittima) si lancia invece un programma per monitorare il traffico di rete (es. Ethereal, etc.) attraverso il quale andare a vedere il contenuto dei pacchetti IP “crafted” ricevuti dall’host che opera la scansione.

- Fornire il minor numero di informazioni possibili

Nel caso di Apache/1.3.26, se si vuole che fornisca informazioni del tipo “Server: Pippo’s MegaHTTPD Server” è indispensabile modificare il codice sorgente di Apache e compilarlo nuovamente.

Oppure, si possono limitare le informazioni che sono passate negli headers al client, usando le direttive Server Tokens: impostandole a Prod, lasceranno passare il minor numero di informazioni possibili.

Per quanto riguarda IIS si può consultare l’articolo How do I limit the header size of the HTTP transmission that Microsoft Internet Information Services (IIS) will accept from a client? al sito http://www.jsifaq.com/SUBI/tip4200/rh4247.htm

- Come difendersi dal network scanning?

Ci sono due approcci fondamentali per difendersi dal network scanning, il primo consiste nell’utilizzare un firewall (es. Black Ice o Tiny Personal Firewall) su ciascun PC ritenuto possibile bersaglio della scansione proveniente dall’interno della rete oppure, installando un firewall professionale (es. CISCO PIX, Check Point FW1, IPTables, IPChains) sul punto di interconnessione tra la nostra LAN privata e Internet.

L’alternativa consiste, invece, nell’implementazione di sistemi di intrusion detection, che avvisano in tempo reale l’amministratore di sistema se avvengono tentaivi di port scanning e di intromissioni non autorizzate.

2) GLI ATTACCHI FONDAMENTALIi

2.1 Sniffing

Gli attacchi sniffing vengono definiti passivi proprio a causa della modalità con cui vengono perpetrati.

La tecnica dello sniffing consiste nel registrare i pacchetti che viaggiano in rete ma che non sono destinati al proprio PC. Settando la scheda di rete in modalità promiscua, gli si impone di copiare in un buffer di memoria tutti i pacchetti che riceve, senza scartare quelli che non hanno come destinazione il MAC address (o indirizzo ethernet) della proria scheda. In modalità standard non promiscua, una scheda di rete bufferizza e manda al sistema operativo solo i pacchetti destinati ad essa. Il programma di sniffing altro non fa che annotarsi tutto questo traffico per poi eseguire delle scremature.

Supponiamo che i nostri 2 PC siano collegati tra loro in una LAN attraverso degli hub o che magari siano sullo stesso hub. Usando il programma dniff, è possibile intercettare tutte le combinazioni di username/password digitate dall’utente vittima.

Sul PC Linux, l’utente Pippo apre una shell ed esegue dsniff lasciandolo in ascolto mentre sull’altro PC, l’utente Pluto apre una finestra di comando Windows per accedere ad un server telnet (es. telnet 192.168.0.230 23). Pluto esegue alcune operazioni e conclude la sessione. A questo punto, Pippo osserva sulla sua shell i risultati.

Pippo, esegue dnisff sempre dalla linux box mentre Pluto esegue una connessione ad un server ftp (es. ftp 192.168.0.230), immette qualche comenado e quando ha terminate le sue operazioni, chiude la sessione ftp col server. A Pippo non rimane altro che verificare l’intercettazione.

- Come annullare la cattura non autorizzata delle informazioni?

In prima istanza è fondamentale comprendere l’importanza di un protocollo di comunicazione che ci dia garanzia che il traffico tra l’host e il server venga in qualche maniera crittografato prima di essere spedito sul cavo in rete. Invece di usare il client telnet per gestire remotamente un server, è consigliato l’uso di un qualsiasi client SSH (Secure Shell) come ad esempio Secure CRT, Putty, OpenSSH su UNIX i quali sfruttano appunto un certo algoritmo crittografico per inviare/riceve i dati durante la sessione.

Buona norma, anche se costosa, è che la rete locale sia munita di soli switch piuttosto che di hub, ovvero sia una switched network, non solo per motivi di sicurezza ma anche e per migliorare il throughtput generale nonchè le prestazioni di rete. Lo switch, che lavora al secondo strato della pila ISO/OSI, ha la caratteristica fondamentale di creare una linea punto-punto tra due host della rete, “imparando” la posizione sulle porte dei MAC address degli host della rete. In questo modo, si evita gran parte del broadcast che invece è proprio degli hub.

Per quanto riguarda l’ftp, è possibile installare sul proprio server delle versioni sicure del servizio ftp che sfruttano l’SSH (SFTP) od utilizzare il Secure Copy (SCP).

2.2 Denial of Service (DoS)

Gli attacchi di tipo DoS sono diffusi nel panorama di Internet essendo non molto complessi da mettere in atto. In sostanza si tratta di trovare un modo per indurre uno o più host della rete a negare l’erogazione dei propri servizi che normalmente distribuisce ai client. Ad esmepio, un attacco di negazione del servizio (Denial of Service) ben riuscito nei confronti di un server Web, induce quest’ultimo a non fornire più il servizio HTTP ai propri client fino a quando l’amministratore di sistema non riesce a sbloccare il server, spesso con banale riavvio. Vi sono attacchi banwidth consumption (a consumo di banda) che mirano a saturare la banda disponibile in una determinata rete; vi sono attacchi di resource starvation (cosumo delle risorse) rivolti a saturare le risorse di sistema del server, normalmente tendono ad innalzare al livello del 100% l’uso della CPU fino al bloccaggio del server. Anche le email possono essere utilizzate per un attacco DoS, basta sapere che virus come Nimda hanno la caratteristica di diffondersi in maniera molto rapida attraverso le email, andanto a inondare i server di posta delle aziende e provocando sovente un blocco del sistema di posta che non riesce a smaltire tutta la posta che lo subissa. Ultima considerazione riguarda gli attacchi DoS che puntano e sfruttano i difetti di programmazione dei software che girano sui server; questo genere di attacchi è molto difficile da portare a segno in quanto presuppone un’ottima conoscenza e capacità di programmazione per creare un exploit che sfrutti un punto debole riconosciuto del server vittima. Tutto ciò si trasforma in un grosso problema finanziare per le società colpite dalla scure del DoS, infatti, molti sono i costi dovuti ai tempi morti del disservizio arrecato agli utenti finali del server colpito ma ci sono anche costi legati ai mancati introiti dei potenziali clienti senza contare il costo tecnico per far ripartire un servizio che in genere coinvolge un certo numero di server collegati tra loro. Inoltre la maggioranza dei programmi creati per effettuare un attacco DoS, sono intuitivi e semplici da usare permetttendo quasi a chiunque abbia un minimo di esperienza di fare attacchi del genere. Infatti, compromettere il corretto funzionamento di una rete è di gran lunga più facile che ottenerne l’accesso non autorizzato.

L’attacco smurfing consiste nello sfruttare la capacità di amplificazione degli host che compongono la rete. Si tratta di utilizzare un PC per inviare una sequenza di pacchetti ICMP ECHO Request (di tipo 8) direttamente all’indirizzo di broadcast della rete, in cui ovviamente verrà contraffatto l’indirizzo IP del mittente in modo che risulti un IP fasullo o, meglio ancora, l’IP di un host a cui vogliamo fare del “male”. L’inidirizzo di broadcast di una rete è in genere “255” (esempio con IP 192.168.0.11 e Mask 255.255.255.0, il Bcast è 192.168.0.255) ed inviando tali pacchetti all’indirizzo IP di broadcast, tutti gli host della rete per default rispondono con un ECHO REPLY all’indirizzo IP che credono li abbia generati, inondando sia la rete che l’host di destinazione (si possono comunque configurare gli host della rete per evitare di rispondere a richieste ICMP ECHO che giungono in broadcast). Nel caso di una rete locale contenente 200 host, se l’attacker invia ripetutamente pacchetti ICMP ECHO da 50000 bytes all’indirizzo IP di broadcast, si avrà che tutti e 200 gli host risponderanno insieme, provocando sia la saturazione della banda (bloccando quindi l’utilizzo della rete) che l’inondazione di pacchetti nei confronti dell’host vittima, quello di cui si è impostato l’IP come sorgente (invece di quello reale).

L’utility ping è utilizzata per verificare se un host è attivo o meno in rete in un certo momento. L’opzione -l permette di impostare la grandezza in bytes dei pacchetti ICMP che sequenzialmente vengono inviati all’IP di destinazione. Notare come nel primo caso con l’invio di pacchetti da 50000 bytes il tempo di ritorno degli stessi sia stato in media di 4ms mentre nel secondo caso, con pacchetti standard da 32 bytes la media sia stata di 0ms, questo per evidenziare il consumo di banda. Se si agisce da più PC in contemporanea indirizzando i pacchetti all’indirizzo IP di broadcast della rete, si ottiene una amplificazione enorme dei dati in ritorno cosa che potrebbe causare la paralisi momentanea dei servizi che “viaggiano” in rete.

Ovviamente, è bene usare un programmino che risca a spoofare l’IP sorgente in modo da non essere rintracciati e magari di convogliare tutto il traffico direttamente contro un host particolarmente antipatico.

C:\>ping -l 50000 192.168.0

Pinging 192.168.0.10 with 50000 bytes of data:

Reply from 192.168.0.10: bytes=50000 time=5ms TTL=128

Reply from 192.168.0.10: bytes=50000 time=4ms TTL=128

Reply from 192.168.0.10: bytes=50000 time=5ms TTL=128

Ping statistics for 192.168.0.10:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 4ms, Maximum = 5ms, Average = 4ms

C:\>ping 192.168.0.10

Pinging 192.168.0.10 with 32 bytes of data:

Reply from 192.168.0.10: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.0.10:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

Utilizzando il programma hping2 è possibile inviare pacchetti ICMP ECHO Request spoofando (sostituendo) il proprio indirizzo IP con quello della vittima che si vuole inondare e quindi portare in una condizione di negazione del servizio.

[root@rh73 root]# hping2 IPdiBroadcast –a IPHostVittima -1

dove IPdiBroadcast è appunto l’IP del broadcast, -a è l’opzione che permette di specificare l’IP della vittima (che riceverà in ritorno gli ECHO REPLY di tutti gli host coinvolti nel broadcast) e -1 genera pacchetti ICMP.

- Limitare lo smurfing

Per evitare gli attacchi smurfing, bisogna fare in modo che gli host della rete non rispondano alle ECHO che arrivano in broadcast. Come prima cosa vanno configurati i router, per quelli CISCO è sufficiente dare il comando no ip directed-broadcast; per Solaris 2.3,2.4,2.5,2.51,2.6 bisogna aggiungere la riga ndd –set /dev/ip ip respond_to_echo_broadcast 0 al file /etc/rc2.d/S69inet; su Linux va lanciato il comando ipfwadm –I –a deny –P icmp –D 192.168.0.255 –S 0/0 0 8 e il comando ipfwadm –I –a deny –P icmp –D 192.168.0.0 –S 0/0 0 8. vedi con alex????????????????????????????????????????????

Il SYN flood è un’altra tecnica per attuare il denial of service ma è più specifico in quanto si rivolge in genere ad una porta del protocollo TCP/IP in ascolto su un particolare server. In pratica si usa un programma che permette all’attacker di strumentalizzare il modello delle tre fasi dell’handshake del TCP/IP. In consizioni normali l’Host Pippo invia una pacchetto SYN ad una specifica porta dell’Host vittima che risponde con un syn-ack, a questo punto l’Host Pippo dovrebbe rispondere con una ack ma così non è. Infatti, l’attacker che invia i pacchetti con il flag SYN ativato, imposta come IP sorgente un IP fasullo, un IP cioè che non esiste in rete facendo in modo che l’Host vittima non abbia alcuna risposta ack. Visto che ciascun sistema operativo è predisposto (anche se in maniera differente) per allocare parte delle risorse di sistema alla connesisone syn ricevuta da un qualsiasi host su una particolare porta del protocollo, esso attende un certo numero di secondi prima di considerare la richiesta syn come decaduta. Visto che l’host vittima manda un messaggio di syn-ack all’IP del mittente (che è stato spoofato che significa sostituito) che risulta inesistente, non potrà ricevere nè un pacchetto con il flag ack che completerebbe l’handshake a 3 fasi nè un pacchetto con il flag rst (reset). Se almeno l’IP fosse esistito (anche se differente da quello reale), l’host vittima avrebbe potuto chiudere la richiesta pendente perchè avrebbe ricevuto da esso un rst (l’host mittente, non ha iniziato un tentativo di connesisone, per cui risponde con un rst) e rilasciare le risorse impegnate in quel processo ad attendere appunto o un ack o un rst. In questo modo, non ricevendo alcunua risposta, le risorse allocate per gestire l’eventuale connessione sono risorse sprecate, inutilizzate per un minimo di 75 secondi ad un massimo di 23 minuti. Quindi, se si inviano periodicamente dei pacchetti syn con IP sorgente inesistene su una specifica porta di un server vittima, si può fare in modo di costringerlo ad allocare risorse e ad accodare richieste di connessione che mai avverranno, portando il server ad esaurire le risorse a disposizione per quella porta, provocando quindi una negazione del servizio che gira appunto sulla porta in questione.

Host Pippo----->syn---P80-->Host vittima

Host Pippo<----syn-ack<--Host vittima

Host Pippo----->rst----->Host vittima (non avviene la terza fase dell’handshake

Il programma octopus permette di inviare pacchetti TCP con impostato il flag syn su una determinata porta in ascolto sul server vittima ma senza chiudere la terza fase dell’handshake a tre fasi. In questo modo, l’Host vittima alloca un certo numero di risorse proporzionale alle sessione appese sulla porta TCP colpita dal syn flood, portanto piano piano all’esaurimento delle risorse totali del server. Al livello del TCP/IP, si ha una situazione del genere:

Host----->syn----->Host vittima

Host<----syn-ack<--Host vittima

. .

Host----->syn----->Host vittima

Host<----syn-ack<--Host vittima

Piuttosto che un comportamento rispettoso delle regole del protocollo:

Host----->syn----->Host vittima

Host<----syn-ack<--Host vittima

Host----->ack----->Host vittima

[root@rh73 root]# octopus Ipvittima Porta

- Ripararsi dal syn flooding

Se si crede di essere attaccati, si può usare il comando netstat e se si notano molte connessioni di tipo SYN RECEIVED, allora siamo in presenza di un attacco di questo genere. Buona norma è invece patchare i propri server, in modo da essere il meno vulnerabili possibili.

Netstat –n –p tcp

Proto Local Address Foreign Address State

TCP 192.168.0.10 192.168.0.11 SYN_RECEIVED

Sections

Documents