Newsgroup: it.comp.os.linux.sys
Titolo: Nessus... ma quanto e' affidabile?

A volte nessus mi da risultati che proprio non capisco!
Stavo facendo un po' di controlli ordinari su reti che amministro da remoto.
Oggi lancio nessuss per controllare l'ip pubblico di un cliente che ha una
lan che naviga in internet attraverso un router con quell'ip e scopro che
c'e' una fantomatica porta 34555/udp aperta, e dice che e' per via di un
trojan di nome trin00.
Pero' localmente nessun pc appare infetto da tale trojan. Inoltre nmap non
rileva nulla ne da fuori ne localemnte, stessa cosa con i vari netststat
sulle macchine.
Tcpdump? Stessa cosa, non rilevo nessun tipo di traffico sospetto da e per
quella porta.
Lo stesso nc ip_incriminato 34555 -u -z non rileva connessioni in listen
Mi devo preoccupare? Falso allarme?
Ciao.
--------------------------------------------
     Davide D'Amico - SysAdmin
Resp. Sistemi Operativi e Hardware
       Novasoft s.a.s. - Pescara
          Linux User #280127
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.718 / Virus Database: 474 - Release Date: 09/07/2004

> scopro che c'e' una fantomatica porta 34555/udp aperta, e dice che e' per
con nmap hai specificato udp ?
è strano che sia chiusa se nessus la rileva.
ciao.
-- 
I comandanti migliori sono i pazzi.
                -- "Melrose Place"

 Mi devo preoccupare? Falso allarme?
Mi viene da farti due calci piazzati di quelli cattivi:
1) se l'ip che stavi verificando apparteneva ad un router che effettua
nat, come ti aspettavi che potesse esserci un trojan? mica ne ho mai
sentiti che dopo aver infettato una macchina configurano una nat sul
router...
2) visto che per come funziona il protocollo udp una porta è aperta
quando anzichè rispondere con un port unreachable non risponde proprio,
hai ripetuto il test per verificare che non fosse semplicemente un
pacchetto perso?
/me che strumenti automatici sì, purchè aprano un filehandle verso
/dev/brain...
-- 
cat: .signature: No such file or directory

 /dev/brain...
Aggiungo inoltre che le sansioni di porte UDP quando in mezzo ci sono
router o firewall non č MAI affidabile.
le scansioni UDP hanno un senso solo ed esclusivamente quando vengono fatte
in lan. Ed in ogni caso, non č necessario, in talune implementazioni, che
ci siano pacchetti di ritorno.
Una porta aperta ed una posta filtrata (che non repla con un port
unreachable ma droppa il pacchetto) spessissimo non sono distinguibili.
Basta avere un pň di basi del TCP/IP e andare a googolare.
UDP č un protocollo connectionless... remember.
Max

 pacchetto perso?
Qui forse effettivamente un tirata di orecchie.... poiche' hai ragione nel
senso che ho posto male domanda.
E' vero che una porta udp e' aperta quando non risponde, infatti un nmap -sU
mi da open tutte le porte, ma visto che stiamo parlando di un protocollo di
trasporto non basato sulla connessione, il fatto che nmap me lo faccia
vedere come open non mi e' di nessun aiuto, e mi chiedo allora, dato che non
lo so, con quale criterio nessus indichi quella porta, come aperta, cosi'
magari potendo riprodurre il test manualmente posso fare un controllo piu'
approfondito su questa cosa!
Ciao.


 mando e su qualche porta non lo fa, posso anche dedurne qualcosa.
Certo. puoi dedurre, dove non risponde:
1) che esiste un servizio ma è firewallato.
2) che non esiste ma è firewallato lo stesso sulla macchina
3) che non esiste ma è firewallato lo stesso sui router perimetrali
4) che non risponde perchè per quel demone non è prevista nessuna risposta
ma magari è aperto tutto quanto
Per dove risponde, invece, puoi dedurre che:
1) la porta è chiu2a
2) la porta è aperta solo ad alcuni IP, il servizio funziona ma non sei
nelle ACL
3) etcccc....
quando sei connectionless in UDP puoi dedurre tutto e niente.
Max

 quando sei connectionless in UDP puoi dedurre tutto e niente.
Benissimo... e da qui (ri)aggancio la mia domanda, quiali ragionamenti
usera' nessus?
Ripeto che alcuni router telecom, me ne sto accorgendo questi giorni,
presentano _tutte_ le porte udp aperte, un nmap -sU mi fa vedere che
qualsiasi back-door esistente al mondo e' aperto sul router, questo perche'
non sono impostati i firewall integrati nel modo corretto sicuramente, e da
qui tutte le considerazioni (giuste) che avete fatto finora. Bene. Ma tra
tutte quelle porte nessus mi mette l'allarme su uno in particolare, e non
potendo stabilire con un semplice portscan la reale percolosita' di una
porta simile, suppongo che faccia "qualcosa" per testare, che poero' io non
so ma mi piacerebbe testare.
Sto googlando nel frattempo, ma se qualcuno piu' illuminato di me (e qui il
98% dei frequentatori lo sono) puo' chiarirmi questa cosa glie ne sarei
grato.
Tnx a lot.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.719 / Virus Database: 475 - Release Date: 12/07/2004

 grato.
Ti abbiamo già risposto.
Riepilogo.
1) UDP è connectionless...
vuol dire che una connessione non esiste.
Lanci un pacchetto UDP e se c'è qualcuno che lo prende bene, altrimenti
nulla.
Non è nemmeno previsto che ci sia una risposta. PUNTO
2) parliamo di TCP/IP...
quando una macchina ne contatta un'altra, sarebbe previsto che la macchina
contattata col prococollo TCP o UDP risponda in maniera adeguata... 
Se il servizio non esiste, la macchina risponde con un ICMP unreachable che
dovrebbe comunicare alla macchina che richiede che la porta non è
disponibile
3) è prassi comune  che gli unreachable li forniscano: 
- le macchine con le porte chiuse
- i firewall dove le porte sono filtrate (lo fa iptables con -j REJECT)
- i router con le ACL che non lasciano passare una cippa
4) NEL CASO l'unrachable NON TORNI INDIETRO
- o hai un router che filtra e non risponde
- o hai un firewall che filtra e non risponde (iptables con -j DROP)
- hai un firewall locale che droppa
- la porta è aperta ma il protocollo non prevede una risposta che torni
indietro.
DA QUI SI DEDUCE che nessus manda un pacchetto alla porta.
Se torna indietro un unrachable la considera chiusa
se non torna indietro una cippa è aperta (mi pare)
Per le cose che ti ho elencato, se nel mezzo ci sono router o firewall, la
correttezza della risposta è affidabile allo 0%.
(non consideriamo poi i problemi di rete... che magari i pacchetti si
perdono ed essendo connectionless ottieni risposte differenti)...
Se non mi sbaglio, sulle doc di nessus c'è scritto un bel pò di roba su sto
argomento.
Consiglio: se sei arrivato fino a qui, rileggi dall'inizio cercando di
capire punto per punto: non è poi difficile.. è spiegato abbastanza "monkey
proof"
Max

 proof"
Che vuoi fare... la materia grigia sta scivolando via insieme ai capelli :-p
