Newsgroup: it.comp.sicurezza.varie
Titolo: porta 135 aperta

netstat -an mi dice che la porta 135 è in ascolto, eppure il firewall
outpost di default la chiude (block remote procedure call tcp/udp è
spuntato) solo il FW di XP la chiude.
c'è qualcosa che posso fare a parte cambiare FW?
ciao

Sgranocchiando il cranio di kamt, vi trovai inciso:

si, stare tranquillo e studiare come funziona un firewall e come funziona
netstat :-)
Capiresti che le due cose non sono correlate..
Per sapere se la porta è chiusa o no dovresti fare uno scan dall'esterno...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 Per sapere se la porta è chiusa o no dovresti fare uno scan dall'esterno...
fatto anche quello ovvio:
http://www.pcflank.com/test.htm
Danger!
The test found open port(s) on your system: 135

 The test found open port(s) on your system: 135
La porta e' tenuta aperta dal servizio che gira sul tuo pc.
Pero' il firewall blocca i pacchetti in ingresso da quella
porta, anche se e' aperta.



??? Uno scanner invia pacchetti a un host su una porta; se l'host li
accetta la porta per lo scanner è aperta; se l'host risponde con un reject
per lo scanner la porta è chiusa; se l'host droppa i pacchetti, ovvero non
risponde, per lo scanner la porta, e l'host, possono anche non esistere. Se
uno scanner dall'esterno trova aperta la porta 135, vuol dire che il
compuuter accetta i pacchetti in arrivo, non che "la porta è aperta ma i
pacchetti bloccati" !!!


Mettiamola cosi' allora: il servizio e' in ascolto sulla suddetta porta,
pero' il firewall ne blocca l'accesso dall'esterno... e' possibile ?

 accetta la porta per lo scanner è aperta; se l'host risponde con un
Giusto un inciso: quando si parla di "porte" e' indispensabile
specificare il protocollo IP utilizzato, tcp o udp. Infatti il
comportamento (e di conseguenza l'esito degli scan) e' differente e va
interpretato alla luce del funzionamento di tali protocolli.
Nella fattispecie:
Protocollo TCP:
Il server invia un pacchetto con flag SYN
Il client puo':
	Rispondere con SYN+ACK -> La porta e' aperta
	Rispondere con RST -> La porta e' chiusa
	Non rispondere -> La porta e' "in stealth"[1][2]
	Rispondere con un altro tipo di pacchetto
		-> Il sistemista e' un bofh oppure non sa cosa sta facendo[1]
[1] Questi comportamenti non sono standard, e di conseguenza sono
fortemente deprecati in quanto possono portare a problemi in situazioni
particolari (ad esempio: load balancing)
[2] Checche' ne dica Gibson, che notiriamente ne capisce piu' di
merletti al tombolo che di sicurezza
Protocollo UDP:
Il server invia un pacchetto UDP
Il client puo:
	Rispondere con un ICMP port unreachable
		-> La porta e' chiusa
	Non rispondere o rispondere con un UDP dalla stessa porta
		-> La porta e' aperta
Ovviamente il caso di non risposta puo' anche essere dovuto a errori di
trasmissione, lag nei routing, filtraggio di qualche router nel percorso
di instradamento, e via discorrendo. Di conseguenza gli scan di tipo UDP
sono molto meno affidabili di quelli TCP.
HappyCactus per chiarezza, e se balongo fosse mai nato...
-- 
*    HappyCactus - Linux User #209744 - BOFH Certified Engineer    *
*           27/11/2003 Rilaciata la prima relase di qixl!          *
*    
http://sourceforge.net/projects/qixl
 : una gui per iSiloXC    *
*  
www.google.com
 / 
groups.google.com
 : cercare prima di chiedere  *

 pero' il firewall ne blocca l'accesso dall'esterno... e' possibile ?
Sì, ma lui sta dicendo che uno scanner esterno la rileva aperta, questo
significa che il firewall non sta bloccando nulla

 interpretato alla luce del funzionamento di tali protocolli.
Chiaro, avevo solo messo giů 2 righe per spiegare l'inesattezza del post di
danny...

 pero' il firewall ne blocca l'accesso dall'esterno... e' possibile ?
No.
Non sarebbe un firewall, sarebbe una spugna, che prende i pacchetti
indirizzati alle porte da proteggere, li legge, e poi li butta via.
Oppure il firewall e' *dopo* il servizio che ascolta sulla suddetta
porta, in questo caso, il firewall e' inutile e non viene interessato
dall'arrivo dei pacchetti.
Terza possibilita': il routere stesso (che e' prima del firewall)
accetta i pacchetti, cosa se ne faccia e' un mistero.
Quarta possibilita': quello scan e' fatto da un incompetente, ed e'
sbagliato. :-)
Un firewall all'arrivo di un pacchetto ha tre opzioni, come ti hanno
detto:
Accetta i pacchetti
Respinge i pacchetti
Non risponde ai pacchetti
Se lo scan remoto trova la porta aperta, qualcuno, a quell'indirizzo,
accetta i pacchetti su quella porta.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 particolari (ad esempio: load balancing)
Qui però non sono d'accordo. La mia filosofia è "let them time out". Mi sai
dire a quali standard questi comportamenti (intendo lo stealth) non sono
compliant, e qualche fonte che li considera deprecati?
Cosa c'entra il load balancing? Se ho un firewall sulla mia rete, e decido
di non rispondere a richieste TCP su determinate porte, qual è il legame
con il load balancing?
Illuminami

 Illuminami
Non ne hai bisogno, il palco e' tutto tuo.


 
Raga, il mio post non era ironico. Il mio "illuminami" era sincero. Nessuno
ha detto RFC=carta igienica, ora leggerò e mi farò un'idea.
Grazie
Stefano

 Non ne hai bisogno, il palco e' tutto tuo.
????
ve beh...essere umili e dire "fammi imparare" procura solo sarcasmo, a
quanto vedo.

 Uhm, l'avevo postata qui?
Mi daresti un link?
Grazie
Stefano

 quanto vedo.
Generalmente "illuminami" lo si dice per provocare. Forse (e qui vado ad
interpretare) non era tua intenzione.
Come ti ho detto, c'era un post (ma a sto punto, non ricordo dove) in
cui l'amico whiplash illustrava dei problemi avuti con un firewall che
droppava troppo. Passo la palla a lui, che ricorda certamente meglio di
me la situazione
HappyCactus a voi studio


 Generalmente "illuminami" lo si dice per provocare. 
Se si è dei provocatori :-)