Laboratorio di reti

Laboratorio di reti
Beretta Andrea, matr. 686368
[email protected]
Obbiettivo
Analisi di un "capture" tcpdump, al fine di identificare e categorizzare le attività di rete in
corso, e proporre soluzioni per migliorare e salvaguardare il network
Principali attivita’ di rete riscontrate
Portscan da probe.hackerwatch.org
Subito all’inizio del capture si puo’ notare una richiesta fatta dall’indirizzo IP 80.183.5.128 al
DNS server con IP 212.216.112.112, per richiedere l’indirizzo IP di probe.hackerwatch.org.
Ottenuta la risposta, viene eseguito con successo il three way handshake con 67.98.69.136,
ovvero probe.hackerwatch.org, e fatta una richiesta tramite il metodo GET della pagina con
URI /probe/hitme.asp, specificando la versione del protocollo http (1.1).
In questa pagina e’ presente un form, dove e’ stato premuto il tasto Hitme, a cui e’ seguita
un’altra richiesta con il metodo POST di /probe/hitme.asp, passando alla pagina il parametro
Action=Hit+Me. Il metodo POST infatti chiede al server di accettare dei dati forniti insieme alla
richiesta http da parte del client ed eseguire un’operazione relativa alla URI specificata nella
richiesta.
A questo punto dalla pagina in questione viene avviato un portscan sulle principali porte di
80.183.5.128. Il sito infatti invia diverso pacchetti TCP con flag SYN impostato ad 1 per vedere
le porte aperte. Infatti 80.183.5.128 risponde con un pacchetto con attivi i flag RST, ACK nel
caso la porta sia chiusa, oppure con SYN, ACK nel caso la porta sia usata da qualche servizio.
L’attivita’ impiega circa una trentina di secondi, e vengono controllate (in alcuni casi piu’ di
una volta) solamente le porte relative ai principali servizi come http, telnet, ftp, ssh, pop3,
netbios, imap, finger. Vengono inoltre inviati anche diversi pacchetti SYN alle porte 1098 e
4098.
Tra i vari servizi provati gll unici risultati attivo sono stati http ed https, come si puo’ notare
dai pacchetti con i flag SYN ed ACK ai frame 321 e 418. In questi caso 67.89.69.136 completa
la sincronia trilaterale rispondendo con un pacchetto ACK e infine chiude la connessione con un
FIN-ACK:
320
321
323
324
33.381836
33.382812
33.381836
33.381836
67.98.69.136
80.183.5.128
67.98.69.136
67.98.69.136
80.183.5.128
67.98.69.136
80.183.5.128
80.183.5.128
TCP
TCP
TCP
TCP
3960 > http
http > 3960
3960 > http
3960 > http
[SYN]
[SYN, ACK]
[ACK]
[FIN, ACK]
Avendo completato la sincronia trilaterale con l’unico servizio aperto si suppone si sia trattato
di un TCP Connect scan
Portscan da https://www.grc.com
Al frame 475 viene richiesto IP di grc.com (204.1.226.226), e poi avviato il three way
handshake con la porta 443 di 204.1.226.226 ed eseguito lo scambio di chiavi, come si puo’
notare dai diversi pacchetti relativi ad SSL.
Successivamente, mentre e’ ancora in corso l’invio dei pacchetti da probe.hackerwatch.org,
viene contattato nuovamente il DNS server 212.216.112.112 richiedendo l’indirizzo IP di
www.grc.com (frame 515 dopo 58.618164 sec.), ottenendo in risposta 204.1.226.230
Viene fatto un altro three way handshake con l’indirizzo IP 204.1.226.230 e fatta la richiesta
POST http://www.grc.com/x/ne.dll?bh0bkyd2 .
Molte delle immagini contenute nelle pagine, inoltre, sono hostate su images.grc.com, come si
puo’ osservere da diverse richieste GET oltre che dalla richiesta al DNS server per risolvere il
nome di tale host.
La pagina richiesta precedentemente con metodo POST corrisponde al servizio shieldsUP.
AL frame 919
viene inviato un pacchetto ICMP (echo request) da 204.1.226.228 a
80.183.5.128, e una volta ritornato l’echo reply ha inizio il portscan. Sono presenti un gran
numero di tentativi di connessione da 204.1.226.228, sempre dalla porta TCP 62496, diretti a
tutte le porte TCP in ordine dalla 0 alla 1055, riconoscibili per il flag SYN impostato a uno.
80.183.5.128 risponde con un SYN,ACK nel caso sulla porta sia in ascolto qualche servizio o
applicazione, oppure con RST,ACK. In caso di risposta positiva, 204.1.226.230 non termina
neppure il three way handshake inviando un pacchetto RST,ACK, resettando la connessione.
Dovrebbe quindi trattarsi di un SYN scan.
951 81.294922
952 81.295898
ACK]
[...]
954 ...
955 ...
ACK]
[...]
984 ...
ACK]
204.1.226.228
80.183.5.128
80.183.5.128
204.1.226.228
TCP 62489 > 139 [SYN]
TCP 139 > 62489 [RST,
204.1.226.228
80.183.5.128
80.183.5.128
204.1.226.228
TCP 62489 > 135 [SYN]
TCP 135 > 62489 [SYN,
204.1.226.228
80.183.5.128
TCP 62489 > 135 [RST,
L’invio dei SYN inizia dal frame 922(circa 81 sec) e termina col 3345 (113.6 sec).
Tra le porte TCP aperte di 80.183.5.128 (riconoscibili per avere risposto con un SYN-ACK) si
annovarano la 445(microsoft-ds), 443(https), 135(epmap), ed 80(http).
Durante lo scan inoltre sono presenti anche alcuni pacchetti del servizio messenger destinati
alla porta UDP 135, probabilmente per testare se il servizio e’ attivo sulla macchina target.
Portscan da Scan.sygatech.com
Al frame 3583 (161.45 sec.) viene contattato attraverso http://www.google.it (il cui indirizzo
e’ 66.249.85.99), il sito web http://scan.sygatetech.com, probabilmente conseguentemente
alla ricerca della query test+personal+firewall, come si puo’ notare da un campo Referer
dell’header http del pacchetto in questione. e dopo il three way handshake viene effettuata una
ricerca con la query test+personal+firewall.
A questo punto viene avviato il three way handshale con l’indirizzo IP 207.33.111.32, viene
fatta una richiesta con il metodo GET della risorsa specificata dall’URI / come si puo’ notare dal
frame 3591 :
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/xshockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, */*
Referer:http://www.google.it/search?sourceid=navclient&hl=it&ie=UTF8&rls=GGLD,GGLD:2003-43,GGLD:it&q=test+personal+firewall
Accept-Language: it
Accept-Encoding: gzip, deflate
If-Modified-Since: Wed, 20 Oct 2004 21:25:41 GMT
If-None-Match: "8bc30-40cc-4176d7d5"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR
1.1.4322)
Host: scan.sygatetech.com
Connection: Keep-Alive
Analizzando la richiesta stessa ed i campi costituenti l’header si uo’ notare che la versione del
protocollo http sia la 1.1, il browser utilizzato Mozilla/4.0, e l’host a cui la richiesta si riferisce.
Una stessa richiesta con un diverso header host puo’ infatti riferisi a due distinte risorse web.
L’header host e’ diventato obbligatorio per tutte le richieste http dalla versione 1.1 del
protocollo. L’utilita’ di questo campo dell’header e’ legata alla necessita’ di potere tradurre
senza problemi piu’ URL in un solo indirizzo IP. Una soluzione del genere e’ fondamentale per
quei server che hostino diversi siti, come il caso di un webserver apache che utilizzi la direttiva
VirtualHost.
L’header Connection: Keep-Alive specifica infine la persistenza della connessione, in modo che
la stessa non venga chiusa non appena la risposta sia stata completamente inviata al client.
La risposta di scan.sygatetech.com e’ invece la seguente :
HTTP/1.1 304 Not Modified
Date: Wed, 11 May 2005 10:37:15 GMT
Server: Apache/1.3.27 (Unix)
Connection: Keep-Alive
Keep-Alive: timeout=30, max=300
ETag: "8bc30-40cc-4176d7d5"
La prima riga e’ la “linea di stato” , che riporta la versione del protocollo utilizzato per la
risposta, un codice numerico che indica l’esito della richiesta, ed una rappresentazione testuale
dell’esito stesso. Tale codice, detto status code, e’ costituito da 3 cifre decimali, e nel caso
riportato, iniziando con il numero 3, indica una redirezione della richiesta su un’altra locazione.
Seguono richieste tramite il metodo GET delle diverse immagini presenti all’interno della
pagina identificata dalla URI / .
Successivamente viene cliccato il link che punta alla pagina probe.htm (lo si puo’ desumere
dal
campo
referer
dell’header
della
richiesta
http,
che
riporta
l’indirizzo
http://scan.sygatetech.com ). Successivamente richiesta con il metodo GET la pagina /
images/sygate.html. Il protocollo utilizzato passa poi da http ad https, come si puo’ osservere
dal pacchetto TCP 3668 con il flag SYN impostato ad 1 e diretto alla porta 443, e ad alcuni
pacchetti relativi a SSL.
Dal frame 3700 (178.6 sec.) ha inizio lo scan originato dall’indirizzo 207.33.111.35 e diretto a
80.183.5.128, verificando tra i principali servizi (finger, telnet, ssh, ftp, pop3, http, smtp) quali
siano attivi. Il primo tentativo di connessione riguarda la porta 80, che essendo aperta
risponde con un SYN-ACK. Inviato l’ACK di conferma, viene quindi fatta una richiesta con il
metodo HEAD a 80.183.5.128. Il metodo HEAD e’ identico al GET, con la differenza che in
risposta ad esso il server restituira’ esclusivamente l’header della risposta e non il body.
80.183.5.128, pero’, chiude la connessione inviando al mittente un pacchetto con i flag FIN ed
ACK (pacchetto numero 3704).
I vari pacchetti del portscan risultano, inoltre, inframezzati da pacchetti originati dalla porta
443 di https://scan.sygatetech.com e contengono il codice html della pagina che fara’ da
report dell’attivita’ svolta, e probabilmente costituiscono il body della risposta http alla
richiesta fatta col metodo GET della pagina da cui e’ stato avviato il portscan.
Successivamente vengono richieste nell’ordine con il metodo GET le pagine
prestealthscan.html,
/images/sygate.html,
stealthscan.html,
/images/sygate.html,
pretrojanscan.html, /images/sygate.html, /trojanscan.html, ecc. come si vede dall'http-referrer
ecc. Richieste le varie pagine vengono avviete le diverse parti dello scan.
Durante le varie parti dello scan vengono prima controllate le porte relative ai principali
servizi, come auth, finger, telnet, ssh, ftp, pop3, http, smtp ecc.
In ogni caso vengono inviati un gran numero di pacchetti TCP con il flag SYN impostato ad 1 a
diverse porte, in molti casi con la porta sorgente corrispondente a quelle di qualche servizio.
Nei pacchetti facenti parte del portscan sono infatti presenti diversi pacchetti con source port
53(dns), 80(http), 21(ftp), 25(smtp), 110 (pop3) ecc. Una soluzione del genere potrebbe
essere giustificata come un tentativo per eleudere le regole di filtraggio di un eventuale
firewall, presumendo che lasci passare i pacchetti relativi ai principali servizi applicativi.
Non esiste dubbio che si trati di un portscan, osservando il grande numero di pacchetti inviato
alle porte piu’ disparate. Come nei casi precedenti, porte chiuse ritornano un RST, ACK, mentre
quelle aperte un SYN, ACK. Anche in questo caso, la sincronia trilaterale non viene terminata,
ma viene inviato un pacchetto con il flag RST impostato a 80.183.5.128, come si puo’ ad
esempio vedere dai frame 3940, 3941, 3942 ad esempio. Si tratta quindi ancora di un SYN
scan.
Un'altra caratteristica evidente del fatto che si tratta di un portscan e’ dovuta al fatto che i
pacchetti vengono inviati “a blocchi”, ovvero in gruppi, tutti con la stessa porta sorgente e
catturati con il medesimo tempo. Ad esempio si possono osservare i gruppi 4225-4232, 42664272 ecc. che verificano diverse porte di destinazione TCP. Da segnalare, inoltre, il fatto, che i
numeri di porta di destinazione dei pacchetti del portscan non sono in ordine strettamente
crescente ( per es. non seguono un pattern del tipo 1001, 1002, 1003, 1004, 1005 … 1100
… ), probabilmente in modo da rendere il pattern del portscan un minimo meno evidente.
Dallo scan delle porte TCP sono risultate aperte le porte 80, 445, 443, e 8080.
A partire dal frame 4611 e’ invece possibile osservare unp scan UDP, verso diverse porte di
destinazione in ordine non sequenziale, e con porte sorgenti differenti. L’origine e’ sempre
l’indirizzo IP 207.33.111.35, a cui 80.183.5.128 risponde con dei pacchetti ICMP (Port
unreachable)
Tra questi pacchetti UDP, in particolare si puo’ notare il numero 4784, diretto alla porta 1900.
Ethereal indica questo pacchetto come malformato. La porta 1900 corrisponde al servizio di
rilevamento SSDP e permette il rilevamento di periferiche Universal Plug and Play presenti in
rete. Nell’esempio riportato il pacchetto fa parte di un portscan, ma in alcuni casi pacchetti
malformati diretti a questa porta potrebbero causare un overflow. Poiche’ il servizio dovrebbe
girare un kernel space, si potrebbe arrivare anche ad una compromissione del sistema,
secondo quanto riportato da alcuni advisory.
Sulla macchina in questione il servizio non risulta attivo, in ogni caso gli advisory che hanno
trattato il problema raccomandano di configurare il firewall in modo da bloccare l’accesso
dall’esterno alle porte UDP 1900 e 5000.
Sempre rimanendo in tema di pacchetti UDP malformati ne e’ presente anche uno alla
posizione 4703 diretto alla porta 53. Un possibile obbiettivo di un simile pacchetto, oltre alla
verifica del DNS server potrebbe essere causare un Denial of Service. Infatti le versioni di
ethereal precedenti alla 0.9.3 hanno un problema con il dissector DNS, e particolari pacchetti
malformati potrebbero fare entrare lo sniffer in un ciclo infinito, stando ad un Security advisory
di SCO.
Non sono infine da escludere attacchi Dos Diretti ad un DNS server. Ad esempio MaraDNS
server, puo’ essere soggetto a blocchi in seguito al processing di pacchetti opportuni pacchetti
malformati, impedendo quindi la risoluzione delle richieste successive.
www.ansa.it
Al frame 4867 viene chiesto l'indirizzo di www.ansa.it al DNS server 212.216.112.112.
Ottenuta la risposta con l'indirizzo IP 194.244.5.201, 80.183.5.128 richiede la root directory
del sito web con una GET / . Dalla risposta http di www.ansa.it si puo' osservare che il server
e' Sun-ONE webserver.
La pagina ritornata riporta la data 11 Maggio 2005, e l'ora 11:28, mentre l'ora presente negli
header della risposta del webserver e' 9:28. Tra le news la notizia di una possibile joint venture
tra toyota e General Motors per lo sviluppo di un motore ad idrogeno.
Al frame 5012 invece viene richiesto al DNS l'indirizzo IP di adsweb.tiscali.it (213.205.36.37)
e
seguentemente
vengono
fatte
delle
richieste
GET
/
banner/2005/IT/ansa_728*90***button.swf, e
GET /banner/2005/IT/netobserver120x240***button.swf, per dei banner, probabilmente
filmati in flash, vista l'estensione del file, inclusi nella pagina del sito dell'ansa
precedentemente caricata, e da qui direttamente linkati.
nssdcftp.gsfc.nasa.gov
Al frame 6007 si puo' osservare una connessione ftp (riconoscibile dalla porta di destinazione
21) di nssdcftp.gsfc.nasa.gov (128.183.114.83), in seguito alla richiesta di risoluzione del
nome presso il solito DNS server usato nel resto dal capture(pacchetto 6005).
Una volta connesso il login viene fatto come utente Anonymous, ed alla richiesta di password
viene fornito un indirizzo email per la precisione [email protected] . A questo punto l'utente
indica l'utilizzo della modalita' passiva con il comando PASV, in modo che il server specifichi al
client quale sia la porta maggiore di 1024 a cui connettersi per il trasferimento dei dati.
Il server risponde con una serie di sei numeri decimali che indicano il socket di connessione da
utilizzare. Nel frame 6032 tali valori sono ad esempio 128, 183, 114, 83, 160, 204, per
indicare il socket corrispondente all’indirizzo ip 128.183.114.83 ed alla porta
160*256+204=41164.
Si puo’ infatti notare come successivamente venga fatto il three way handshake con la porta
in questione (pacchetto 6033) e chiesto il listing di / :
drwxrwxr-x
drwxrwxr-x
-rwxr-xr-x
-rw-r--r-drwxr-xr-x
--x--x--x
drwxrwxr-x
d--x--x--x
drwxrwxr-drwxrwxr-x
drwxrwxr-x
drwxr-xr-x
drwxr-x--drwxrwxr-x
drwxrwxr-x
drwxrwxr-x
drwxrwxr-x
dr-xr-xr-x
15 root
sys
15 root
sys
1 njames
admin
1 root
other
3 root
admin
2 root
other
2 root
other
3 root
other
9 root
image
14 root
admin
10 bilitza itm
5 bell
photo
2 root
admin
10 njames
admin
44 root
sys
11 root
sys
7 root
std
5 root
other
1024 May 11
1024 May 11
1419 Dec 10
4561 May 6
1024 Nov 29
96 Mar 22
96 Feb 13
1024 Nov 24
81920 Mar 25
1024 Feb 12
1024 Apr 4
1024 Nov 13
1024 Nov 5
1024 Mar 12
1024 May 2
1024 May 9
1024 Feb 22
96 Sep 20
2004 .
2004 ..
2002 00README.TXT
2003 Access_Warning_Priv.html
2001 admind
2001 bin
2001 dev
2003 etc
14:52 image
2004 miscellaneous
2001 models
2001 photo_gallery
2004 pub
2004 selected_software
14:53 spacecraft_data
15:44 staging
16:41 standards
2000 usr
L'utente tenta quindi di cambiare un paio di volte la directory corrente, ma l'operazione viene
negata a causa di permessi d'accesso, prima di andare in /photo_gallery/. Ancora una volta
viene dato il comando PASV per indicare l'intenzione di utilizzare la modalita' passiva; ricevuta
la risposta dal server viene eseguito il three way handshake con la porta 41166, e quindi il
listing della directory:
drwxr-xr-x
drwxrwxr-x
-rwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
-rwxr-xr-x
5
15
1
2
8
7
1
bell
root
bell
bell
bell
bell
bell
photo
sys
photo
photo
photo
photo
photo
1024
1024
2075
5120
1024
96
6474
Nov
May
Nov
Nov
Nov
Nov
Nov
13
11
13
13
13
13
13
2001
2004
2001
2001
2001
2001
2001
.
..
AAREADME.TXT
caption
hi-res
image
photogallery-faq.txt
Cambiata nuovamente la directory corrente in hi-res, nuovamente comando PASV e sincronia
trilaterale con la porta 41167. Altro listing:
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
8
5
2
2
12
2
2
2
bell
bell
bell
bell
bell
bell
bell
bell
photo
photo
photo
photo
photo
photo
photo
photo
1024
1024
2048
96
1024
1024
1024
96
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
13
13
13
13
13
13
13
13
2001
2001
2001
2001
2001
2001
2001
2001
.
..
astro
misc
planetary
solar
spacecraft
special
Cambio directory con il comando cd astro, ancora comando PASV con risposta Entering Passive
Mode (128,183,114,83,160,208), connessione con la porta 41168 e directory listing:
drwxr-xr-x
2 bell
photo
drwxr-xr-x
8 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
hst_bubble_ngc7635_0004.tiff
-rwxr-xr-x
1 bell
photo
hst_carina_ngc3372_0006.tiff
2048
1024
14759134
14938100
14802276
15609480
6777962
16025486
1506848
6821964
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
13
13
13
13
13
13
13
13
13
13
2001
2001
2001
2001
2001
2001
2001
2001
2001
2001
10180918 Nov 13
2001
.
..
hst_30doradus_9933a.tiff
hst_30doradus_9933b.tiff
hst_abell2218_0008.tiff
hst_antennae_9734a.tiff
hst_antennae_9734a1.tiff
hst_antennae_9734b.tiff
hst_blkhole.tiff
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
hst_crescent_ngc6888_0023.tiff
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
hst_eskimo_ngc2392_0007.tiff
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
hst_neutron_star_9732.tiff
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
hst_pillars_m16_close.tiff
-rwxr-xr-x
1 bell
photo
hst_southern_crab_9932.tiff
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
-rwxr-xr-x
1 bell
photo
14141510 Nov 13
17009192 Nov 13
2001 hst_crab_nebula.tiff
2001
12538368 Nov 13
6753142 Nov 13
2001 hst_deep_field.tiff
2001
6626990
12785442
12718769
17402102
17445482
6269820
9942508
16190929
15134147
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
13
13
13
13
13
13
13
13
13
2001
2001
2001
2001
2001
2001
2001
2001
2001
hst_hcg87_9931.tiff
hst_helix_detail.tiff
hst_helix_nebula.tiff
hst_lagoon_detail.tiff
hst_lagoon_nebula.tiff
hst_lmc_9944.tiff
hst_m80_9926.tiff
hst_ms1054-03_9928.tiff
12962556
1359868
6695963
7415014
16701120
1201644
16593128
14039022
11798390
11619546
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
Nov
13
13
13
13
13
13
13
13
13
13
2001
2001
2001
2001
2001
2001
2001
2001
2001
2001
hst_ngc2207_9941.tiff
hst_ngc3314_0014.tiff
hst_ngc3603_9920.tiff
hst_ngc4414_9925.tiff
hst_ngc4438_0021.tiff
hst_ngc6822_0101.tiff
hst_omicron_ceti.tiff
hst_papillon_9923.tiff
hst_pillars_m16.tiff
16525626 Nov 13
2001
14158914
14081802
15120701
15100503
6794916
16180206
2001
2001
2001
2001
2001
2001
Nov
Nov
Nov
Nov
Nov
Nov
13
13
13
13
13
13
hst_starform_ngc2366.tiff
hst_starform_ngc604.tiff
hst_stingray_nebula.tiff
hst_tmr1.tiff
hst_trifid_9942.tiff
hst_wolf-rayet_9838.tiff
L'ultima serie di comandi e' costituita dal comando TYPE I, e seguito da un altro PASV. In
questo caso la porta indicata dal server e' la 41170, utilizzata per il download di un’immagine,
richiesta con il comando RETR hst_antennae_9734a1.tiff . Infine viene terminata la sessione
con il comando QUIT e chiusa la connessione con un pacchetto [RST,ACK] da 80.183.5.128 a
nssdcftp.gsfc.nasa.gov.
www.webzcan.com
Al frame 6879 viene richiesto al DNS server 212.216.112.112 l'indirizzo IP di www.google.it, e
ritornata la risposta con 66.249.85.104, per richiedere con metodo GET una pagina
corrispondente al risultato della ricerca della query remote+portscan.
Successivamente, al frame 6905, 80.183.5.128 richiede l'indirizzo IP di www.webzcan.com
(217.160.226.86), in modo da potere eseguire una richiesta con metodo GET della pagina /
Contents/pService.htm. La richiesta e' stata effettuata provenendo da un link ritornato da
google, in risposta alla query di ricerca remote+portscan, come si vede dal campo referer
dell’header http. Successivamente non deve essere stata trovata una risorsa richiesta, poiche'
viene ritornato da 217.160.226.86 (webserver Apache 1.3.29 su piattaforma Unix) un codice
di errore 404. Infine viene chiusa la connessione da parte di 80.183.5.128 .
www.phlack.org
Al frame 7295 viene richiesto al DNS l'indirizzo IP di www.phlak.org (140.211.166.28) e
quindi
richiesta
con
il
metodo
GET
la
pagina
/
modules/section/index.php?op=viewarticle&artid=1. Osservando l'header referer della
richiesta http, la richiesta e' conseguenza di una ricerca effettuata con google con la query
use+nessus+online. Infatti controllando il frame 7241 troviamo una richiesta a www.google.it
con metodo GET della pagina di ricerca con query use+nessus+online.
Probabilmente il sito visitato e' stato realizzato utilizzando il cms Xoops (vista anche
l'inclusione del javascript xoops.js richiesto con metodo GET al frame 7735). A conferma della
pagina come risultato della particolare query con google il fatto che tala pagina parli proprio di
Nessus, come il security tool of the week, per la settimana del 17/11/2003.
Successivamente viene avviata nuovamente una connessione con 140.211.166.28,
riconoscibile dal pacchetto con il flag SYN impostato a uno e fatta la richiesta GET /
modules/mydownloads. Il server che hosta il sito e' apache 1.3.26 con php 4.3.8 su
piattoforma debian GNU/Linux.
Al frame 7379 inoltre viene chiesto al DNS di risolvere l'indirizzo IP di www.paypal.com
(216.113.188.34). Nella pagina visitata su phlak.org e' infatti presente un'immagine hostata su
www.paypal.com (<input type="image" src="https://www.paypal.com/en_US/i/btn/xclick-but04.gif" border="0" name="submit" alt="Make payments with PayPal - it's
fast, free and secure!">), probabilmente usata come tasto per un form di donazioni a
favore di www.phlak.org.
ui.skype.com
Al frame 7795 da 80.183.5.128 viene fatta una richiesta http con il metodo GET della URI /
ui/0/1.2.0.48/it/getlatestversion?ver=1.2.0.48&uhash=1c8ac507ea3e08750ef3f3a7bf6
41e2f3 all'host ui.skype.com, corrispondente all'indirizzo IP 212.72.49.131. Secondo gli header
della richiesta http essa e' stata fatta usando la versione 1.2 di skype.
Portscan da http://www.darkeiler.com
Al frame 8054 (838.6 sec.) viene contattato attraverso http://www.google.it (il cui indirizzo e’
66.249.85.99), il sito web http://www.derkeiler.com/Service/Portscan ,dopo avere effettuato la
ricerca online+portscan, come si nota dal Referer della richiesta http.
Prima di effettuare il three way handshake, viene contattato il DNS server 212.216.112.112,
per risolvere l’indirizzo IP di www.derkeiler.com. Il DNS ritorna una risposta con l’indirizzo IP
195.140.232.111.
Viene quindi fatto il three way handshake e richiesta con il metodo GET la uri /
Service/Portscan. All’interno della pagina richiesta e’ presente un banner pubblicitario
visualizzato ricorrendo ad un javascript presente su pagead2.googlesyndication.com. Viene
infatti
fatta
una
richiesta
con
metodo
GET
anche
della
risorsa
pagead2.googlesyndication.com/pagead/show_ads.js , che viene richiamata dalla pagina
www.derkeiler.com/Service/Portscan come mostrato dal referer al frame 8089.
Referer: http://www.derkeiler.com/Service/PortScan/
Accept-Language: it
Accept-Encoding: gzip, deflate
If-Modified-Since: Fri, 06 May 2005 22:10:53 GMT; length=9268
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR
1.1.4322)
Host: pagead2.googlesyndication.com
Connection: Keep-Alive
In seguito viene chiesta piu’ volte la URI /Service/Portscan/Result, e piu’ volte chiusa la
connessione con la porta 80. Dal frame 8314 inizia poi il portscan verso porte TCP, con gruppi
di diversi pacchetti con lo stesso “tempo” di cattura. Le porte di destinazione non sembrano
seguire un pattern particolare, mentre la porta sorgente, cambia ad ogni pacchetto, sempre
pero’ con numeri piuttosto alti, tendenzialmente superiori a 64000.
Anche in questo caso si tratta di un SYN-SCAN, infatti nel caso su una porta sie in esecuzione
qualche servizio applicativo la sincronia trilaterale non viene completata, inviando un pacchetto
di reset da 195.140.232.111 a 80.183.5.128.
Il portscan molto corposo, riguarda un gran numero di porte TCP, in circa 8 secondi vengono
infatti inviati 1400-1500 pacchetti. Al termine del portscan risultano aperte le seguenti porte
TCP:
80 - http
135 - epmap
443 - https
445 - microsoft-ds
3000 – il webserver incluso in ntop (software per traffic monitoring) , oppure la backdoor
Kutex
8080 – squid, tomcat
9999 - abyss webserver oppure le Backdoor lateda e beasty, o ancora il trojan The Prayer
49489
Portscan da onlinecheck.emisisoft.com
Al frame 11775 80.183.5.128 richiede al DNS server 212.216.112.112 l'indirizzo IP di
http://onlinecheck.emsisoft.com/ (195.70.106.2), e successivamente contatta questo sito
web. Osservando l'header della richiesta http si puo' notare anche in questo caso come il
referer sia la pagina dei risultati di una ricerca con google, con la query online+portscan.
Successivamente vengono chieste con il metodo POST la pagina default.aspx e scan.aspx
con alcuni parametri come ad esempio portscan=1.
A questo punto il computer 80.183.5.128 viene sottoposto ad un portscan, mentre tra i diversi
pacchetti diretti ad esso ve ne sono diversi provenienti dalla porta 80, contenenti nel body del
messaggio http le varie parti di codice html che vanno a costituire la pagina con i risultati
dell'operazione di scanning. Tra i diversi tentatativi e' stata provata piu'volte la connessione
alle porte 27274, 12345 corrispondenti a due vecchie backdoor particolarmente note quali
subseven e netbus.
Dall'operazione risultano aperte le porte TCP seguenti :
80 - http
135 - epmap
443 - https
445 - microsoft-ds
3000 – il webserver incluso in ntop (software per traffic monitoring) , oppure la backdoor
Kutex
9999 – abyss webserver oppure le Backdoor lateda e beasty, o ancora il trojan The Prayer
www.liveye.net
Al frame 14441 viene fatta una richiesta GET / all’indirizzo IP 62.149.195.127 corrispondente
ad http://www.liveye.net. Seguono le richieste di ulteriori pagine per la precisione :
GET
GET
GET
GET
/ita/index.html
/ita/chisiamo.html (referer e' index.html)
/ita/prodotto.html (referer chisiamo.html)
/ita/contatti.html (referer contatti.html)
Inoltre, secondo le informazione contenute nel cookie utilizzato, il login dell’utente che ha
richiesto la pagina e' [email protected], la lingua l’italiano (lang=it) ed il tema scelto
Lookout. Infine la connessione viene chiusa da 80.183.5.128 inviando un pacchetto TCP con i
flag [RST][ACK]
Attivita’ msn messenger
In base ai pacchetti presenti nel capture, un utente sulla macchina 80.183.5.128 ha in
esecuzione microsft msn messenger. Sono infatti presenti alcuni pacchetti TCP con porta di
destinazione e di origine 1863, diretti all’indirizzo 207.46.107.102 .
Sebbene nel capture e’ sono del tutto assenti i pacchetti relativi all’avvio della connessione da
parte di un utente, l’invio delle informazioni relative al client e l’autenticazione dell’utente, e’
possibile riscontrare alcuni pacchetti relativi a questo sistema di messaggistica.
Ad esempio sono presenti diversi pacchetti ping diretti da 80.183.5.128 a 207.46.107.102.
Tali pacchetti hanno una funzione analoga al comando ping di IRC e sono riconoscibili dal
comando PNG presente nel payload del pacchetto. Analogamente sono presenti delle risposte a
questi ping, da parte di 207.46.107.102 e caratterizzate dalla presenza nel payload del
comando QNG. Alla ricezione del pacchetto QNG viene inviato in risposta un pacchetto di
acknowledgement con il flag ACK impostato ad 1. Questi pacchetti vengono normalmente
utilizzati per testare la latenza tra client e server oppure per assicurare che la connessione tra
le due parti resti attiva, e non venga magari chiuso il relativo socket. Si puo’ infatti notare
come tali pacchetti vengano inviati ad intervalli piu’ o meno regolari, ogni 45-50 secondi circa.
Altro pacchetto di interesse e’ il 3775, contente nel payload il comando FLN
[email protected] , da 207.46.107.102 a 80.183.5.128 . Il Comando FLN dovrebbe essere
inviato dal notification server quando un utente della propria lista si disconnette oppure
“nasconde” la propria presenza.
Sono inoltre presenti pacchetti contenenti la stringa UBX [email protected]. Il comando UBX e’ il
comando gemello di UUX. UUX viene inviato al notification server da un utente che ha
modificato il proprio messaggio personale o il brano attualmente in riproduzione. UBX al
contrario viene inviato dal server a coloro che abbiano l’utente in questione nella propria lista
di contatti per notificare la cosa. Il primo parametro del comando e’ l’identificativo del contatto
che ha effettuato la modifica, ed il secondo la lunghezza del payload.
Sono poi presenti degli UBX da [email protected]. Nel capture sono presenti due UBX relativi
[email protected] .
Nel primo caso(pacchetto 6078) il payload risulta 0 e manca la parte data:
UBX [email protected] 0
Nel secondo caso invece il payload del pacchetto 6085 e’ il seguente, e probabilmente riporta
la modifica del messaggio personale de [email protected], che desidera avvisare del fatto che si trovi
a casa:
UBX [email protected] 70
<Data><PSM>I'm at the house</PSM><CurrentMedia></CurrentMedia></Data>
Sono infine presenti anche due pacchetti diretti dal sever al client conteneti il comando NLN
(6080 e 6087). Tale Comando serve per indicare il proprio "status" (ad sempio Available, busy,
idle, ecc...). Probabilmente essi dovrebbero essere usati per inviare un messaggio di notifica
della propria presenza, include il proprio status, il display name(nickname?), e un numero che
rappresenta diverse informazioni riguardo il client.
Nel capture analizzato l’utente su 80.183.5.128 ha ricevuto la notifica seguente, che sta ad
indicare che l'utente [email protected] puo' ricevere messaggi, non essendo occupato con altro , e
vuole che ci si riferisca a lui come Jamey Kirby :
NLN IDL [email protected] Jamey%20Kirby 1073795116
Attivita’ samba-netbios
Nello scan sono presenti diversi pacchetti relativi al protocollo smb-cifs, che tendenzialmente
rispettano un medesimo pattern.
Inizialmente viene fatto un trhee way handshake sulla porta TCP 445 della macchina con
indirizzo 80.183.5.128, ed inviato un pacchetto con il comando SMB_COM_NEGOTIATE
(distinguibile dal codice esadecimale 0x72), in cui vengono specificati i dialetti cifs che il client
e’ in grado di comprendere, ovvero il set di comandi riconosciuti, specificati come stringhe
ASCI terminate dal carattere NULL.
A questo punto 80.183.5.128 risponde, facendo una comparazione sulle stringhe ricevute
ricerca il set di comandi di livello piu’ alto che e’ in grado di riconosce. Effettuata la ricerca
viene inviata una risposta contenente un indice per identificare la posizione del dialetto scelto
nella lista spedita precedentemente. Anche in questo caso il codice che rappresenta il comando
e' 0x72 .
80.183.5.128 ritorna anche un identificatore di sessione.
La fase successiva e’ il setup della sessione SMB. Un server con un livello di sicurezza “userlevel” richiede l’autenticazione degli utenti prima di concedere loro l’accesso alle risorse
condivise. Questa fase viene invece saltata nel caso di sicurezza al livello share-level.
Generalmente l’accesso per il browsing
Secondo il protocollo CIFS il nome per questa fase e’ SessionSetupAndX. L’idea di base e’
quella di inviare uno username ed una password per ottenere in risposta uno UID. Tra le
informazioni inviate dal client al server, all’interno del pacchetto possiamo trovare un buffer
contenente la password cifrata, lo username, ed altre stringhe che indicano il nome del sistema
operativo ed il LAN manager. La dimensione di tale buffer e’ specificata dal campo Bytecount
In tutte le richieste effettuate a 80.183.5.128 viene ritornato al richiedente lo UID 48(come si
puo’ vedere dal campo User ID).
Ottenuto uno UID un utente tenta di connettersi a qualche condivisione, specificando in un
pacchetto la condivisione richiesta. Il comando usato dovrebbe essere Tree Connect andX
request, identificato dal codice 0x75. Il nome dalla share richiesta e’ contenuta in un buffer, la
cui lunghezza viene specificata da bytecount. Nei pacchetti catturati da ethereal si nota che
viene richiesta la condivisione identificata dalla stringa PATH:\\80.183.5.128\ipc$ .
Segue quindi una risposta da parte del server, Tree Connect AndX Response (0x73): se la
condivisione specificata dal client esiste e l’utente ha i privilegi d’accesso richiesti allora il
server ritorna una risposta positive com il campo Tree Id impostato ad un numero usato come
riferimento per la risorsa. Se la condivisione non esiste o i privilegi sono insufficianti il server
ritornera’ l’opportuno errore. Nelle risposte date dal server alle richieste il valore Tree Id era
sempre impostato a 2048.
Infine l’utente cerca di accedere a files o directory nelle condivisione per cui ha ottenuto il TID.
All’interno del capture abbiamo due situazioni distinte :
-
una richiesta di Path:\lsarpc da parte dell’indirizzo IP 80.59.46.218 (indirizzo
spagnolo, del provider telefonica.es, TELEFONICA DE ESPANA).
Due richieste di Path:\srvsvc da parte di 195.70.106.2, quindi appartenente allo scan
fatto da parte di onlinecheck.emsisoft.com.
In entrambi i casi il risultato dell’operazione e’ l’errore STATUS_ACCESS_DENIED,
probabilmente perche’ il richiedente non ha aveva i privilegi d’accesso necessari all’interno del
contesto definito dai valori del Tree Id e UID.
Nel primo caso, una richiesta simile corrisponde a quelle fatte dal worm Sasser e da altri worm
della stessa famiglia, stando a quanto affermato dall’articolo Detecting activity that may be
due to LSASS worms, presente su www.symantec.com .
Nel secondo caso invece viene richiesta l’interfacca Server Service (srvsvc) Remote Procedure
Call. Essa consente di gestire file e stampanti e rispondere alle richieste fatte da altri computer
riguardo a risorse condivise sul computer locale. Le restrizione di accesso verso i servizi RPC,
come appunto srvsvc, sono fondamentali, ma talvolta possono trovarsi configurazioni in cui e’
possibile accedervi con accessi anonimi, sfruttando SMB NULL SESSION con la condivisione
IPC$ (interprocess communication)
Le null sessions sono una modalita’ di comunicazione del protocollo Server Message Block
(SMB), note ance come Accessi anonimi, e consentono ad un utente anonimo di ottenere
informazioni attraverso la rete (come ad esempio nomi di utenti e condivisioni) o di accedere a
alcune risorse senza autenticazione. Sfruttando un’accesso anonimo, su sistemi malconfigurati,
un attacker potrebbe quindi usare delle Remote Procedure Call, raccogliere info su password,
gruppi, utenti, servizi, persino tentare un’escalation dei privilegi.
Nello scan non dovrebbe di trattarsi di un’attivita’ malevola, poiche’ inserita all’interno del
testing e dello scan eseguito dal sito onlinechek.emsisoft.com . In ogni caso il sistema
controllato sembrerebbe essere configurato correttamente, poiche’ viene ritornato l’errore
STATUS_ACCESS_DENIED alle richieste effettuate.
Attivita’ sulla porta UDP 23713
E’ stata notata dell’attivita’ sulla porta UDP 23713, in cui sono coinvolti diversi indirizzi IP.
Per gran parte del capture (a partire dal terzo pacchetto) vengono inviati dall’indirizzo IP
82.50.155.97 (un’ADSL telecom italia) pacchetti alla porta 23713, con porta sorgente 38976.
80.183.5.128 risponde con un pacchetto UDP destinato alla porta 38976 e con porta sorgente
23713. Ogni pacchetto contiene 3 bytes di dati.
A partire dal pacchetto 186 sono presenti altri pacchetti alcuni pacchetti da 80.183.5.128 a
83.211.72.34 (Adsl Eutelia), tutti dalla porta 23713 alla UDP 32411. In ogni occasione
l’indirizzo di Eutelia ritorna un pacchetto ICMP di destination unreachable (port unreachable).
Sono poi presenti ancora pacchetti verso la porta udp 23713 di 80.183.5.128 e risposte con
porta sorgente udp 23713. Lo scambio avviene con diversi indirizzi IP, come 82.255.172.67
(Proxad, provider francese), 131.211.109.123 (Solisnet, universita' di Utrecht) ecc.
Attivita’ sulla porta TCP 135(epmap)
Nel capture si possono notare alcuni pacchetti legati alle RPC, Remote Procedure Calls, ovvero
un meccanismo comunicazione tra processi che che permette ad un programma che funziona
su un computer di eseguire codice su un sistema remoto. Esistono diversi exploit che sfruttano
le vulnerabilità di questo sistema, che permettono l'esecuzione di codice arbitrario.
Per esempio dal frame 346 si possono osservere in diversi momenti due serie di pacchetti
scambiati tra 80.183.5.128 e 80.183.10.77 (un’adsl telecom tin easy lite a giudicare
dall’indirizzo IP).
Altra attivita’ su questa porta di 80.183.5.128 viene generata da parte di:
-
82.52.27.158 (telecom italia) dal frame 12147
80.165.2.178 dal frame 14565. Il mittente in questo caso e’ un indirizzo danese TDCBREDBAANDSADSL-PROF-NET.
80.116.255.36 dal frame 715. Trattasi di un ADSL tin-easy lite
L’attivita’ su questa porta, comunque, non si limita solo a questi indirirzi IP, ma anche diversi
altri, ADSL tin-easy lite, Telecom Italia, neuf telecom ecc.
Per la precisione durante queste connessioni vengono fatte delle bind e delle chiamate alle
interfacce MGMT, DSSETUP, ed IsystemActivator, alle quali 80.183.5.128 risponde con lo
status di errore nca_s_fault_access_denied.
Tutti questi pacchetti sono molto probabilmente dei tentativi di sfruttare vulnerabilita’ presenti
nel servizio Microsoft Remote Procedure Call. Tale meccanismo e’ stato utilizzato anche dal
noto worm blaster. Vista la frequenza con cui questi pattern di traffico si ripetono da diversi
indirizzi IP, si suppone appunto che tali macchine siano state colpite dal worm in questione.
Tuttavia tali tentativi non raggiungono l’obbiettivo di compromettere 80.135.5.128; il sistema
in questione probabilmente e’ stato gia’ patchato o comunque configurato correttamente.
Altre attivita’ rilevate
Nell’analisi del capture sono state rilevate anche altre attivita’ tra cui si annoverano:
-
-
-
-
Al frame 460 l’indirizzo di Telecom Italia 80.183.98.41 tenta di accedere allo share IPC$
al frame 1460 un tentativo di connessione verso la porta 4480 (riconoscibile dal flag
SYN ad 1) da 82.49.143.50 a 80.183.5.128. L’indirizzo IP di origine e’ una ADSL
Telecom, mentre la porta di destinazione dovrebbe essere quella usata da Proxy+, un
software per windows che permette di svolgere le funzioni di firewall, proxy e mail
server;
ai frame 3778 e 7975 l’indirizzo IP 80.21.242.156 (Comune di Montecatini Terme) tenta
una connessione sulla porta TCP 4662 di 80.183.5.128. Questa porta viene
normalmente utilizzata per il trasferimento dei file dai vari programmi per il peer to
peer basati sul protocollo e2k, come emule ad esempio.
Dal frame 11698 l’indirizzo IP 80.183.47.34 (altra adsl telecom) invia per tre volte un
pacchetto TCP con flag SYN impostato a uno sulla porta 139(netbios-ssn) di
80.183.5.128.
Diversi pacchetti da 84.52.134.9 verso 80.183.5.128, con porta sorgente 1259 e
destinazione 14528
-
Strani pacchetti per il servizio window messenger, provenienti dagli IP 222.77.185.44 e
61.152.158.151, che riportano messaggi di avviso con errori critici riguardo allo stato di
80.183.5.128, per esempio avvisando di una corruzione del registro di windows, o
ancora 47 diversi errori critci invitando a visitare alcuni siti per correggere tali errori
quali
http://reg-scanner.com, http://reg-patch.com,
http://registryfixit.com
ed
eventualmente scaricare ed eseguire alcuni software che dovrebbero correggere i
presunti problemi. Sarebbe decisamente improbabile che windows inviti scaricare un
software di riparazione del registro senza passare per il download center di microsoft,
quindi si presume che gli alert inviati volessero attirare utenti sui siti indicati, si spera
per scopi pubblicitari, e non per scaricare qualche malware.
Considerazioni relativa alla salvaguardia del network
I portscan non dovrebbero destare preoccupazione, poiche’ eseguiti da siti contattati
direttamente dalla macchina “target”. Si presume che non si tratti di attivita’ volte alla raccolta
di informazioni per un successivo attacco, ma piu’ ad un controllo per verificare lo stato della
macchina in questione.
Si consiglia invece di filtrare a livello di firewall tutte le porte che risultano aperte e non
debbano essere accessibili da remoto.
Attenzione particolare andrebbe prestata alle porte 3000 e 9999. Esse corrispondono a servizi
perfettamente legittimi come il webserver integrato in ntop od il webserver Abyss, ma
potrebbe anche trattarsi di backdoor come Beasty, Lateda oppure Kutex
In ogni caso si consiglia di verificare se queste backdoor siano realmente presenti sul
computer in questione.
La porta 8080 invece potrebbe essere usata da Tomcato oppure Squid. Se tali servizi non
fossero effettivamente utilizzato si consiglia di disattivarli. Riguardo a squid inoltre si consiglia
di prestare particolare attenzione alla sua configuraazione, specialmente per quanto riguarda
l’autenticazione degli utenti, i meccanismi di logging,ed eventuali ACL. Se il servizio non deve
essere acceduto da un’interfaccia esterna, da parte di indirizzi ip che non siano gia’ noti a
priori, si consiglia di filtrare a livello di firewall su tale interfaccia la porta associata.
Lo stesso discorso e’ valido per la porta 80. A meno che non esista la reale necessita’ di avere
un webserver accessibile da web sulla propria macchina, e’ consigliabile arrestare tale servizio
o perlomeno filtrarlo a livello di firewall, poiche’ potrebbe esporre a diversi attacchi, sfruttando
eventuali vulnerabilita’.
Si cosiglia, inoltre, anche di filtrare le porte TCP 139 e 445 utilizzate per la condivisione di file
e stampanti, poiche’ molto spesso vulnerabilita’ dei protocolli CIFS ed SMB possono consentire
attacchi di diverso tipo. In caso il servizio debba essere attivo ed accessibile sarebbe opportuno
disabilitare tutte le condivisioni di default non utilizzate, ed impostare sempre il livello di
sicurezza come “user-level” in modo da richiedere l’autenticazione degli utenti che accedono
alle differenti risorse.
Infine, il computer in questione sembrerebbe sicuro rispetto alla vulnerabilita’ sfruttata da
blaster. In caso contrario sarebbe stato consigliabile verificare la presenza del worm,
eventualmente rimuoverlo con qualche tool, ed aggiornare windows in modo da correggere la
vulnerabilita’ sfruttata. Andrebbero inoltre di bloccate tramite un firewall le porte usate da RPC,
ovvero TCP 135, 139, 445 e 593; UDP 135, 137, 138 and 445, stando a diversi advisory
disponibili in rete.