Newsgroup: it.comp.sicurezza.windows
Titolo: Le porte Tcp

Come diavolo si fa a chiudere le porte tcp. In anzienda abbiamo il proxy
server 2 di Microsoft (incluso in SBS 4.5) e abbiamo impostato nel socks
proxy: Deny a tutte le porte sopra la 0, tranne quelle a cui abbiamo
dato Permit (le 80, 21, 25 e 110). Ho stoppato tutti i servizi del
proxy, li ho riavviati e ho fatto uno scan delle prime 2000 porte con il
tool Superscan 3. Ho trovato aperte 43 porte (per esempio le
27,42,135,389,563,593,636,993,995,1033,1040,1043,1045,1048,1051...ecc)
oltre a quelle da me indicate.
E' possibile chiuderle. E se si, come??
Grazie e ciao
Stefano
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:1ac10e46c275c3d1abd...@mygate.mailgate.org...


 E' possibile chiuderle. E se si, come??
Fermando i servizi che le aprono o filtrando con il packet filter.
Fabio

 oltre a quelle da me indicate.
Due ipotesi:
1) su quel server stai eseguendo troppi servizi/applicazioni (non ci stai 
facendo girare il newsreader, explorer, kazaa e chissa' che altro, 
vero?), controlla e chiudi qualche applicazione
2) hai utilizzano un tipo di scan non adatto per quel tipo di host, ad 
esempio un X-mas tree su un windows, per cui alcune porte risultano 
aperte quando in realta' sono chiuse.
-- 
HappyCactus - Registered Linux User #209744
http://www.angelfire.com/jazz/happycactus/index.html
Made with 100% recycled electrons

 aperte quando in realta' sono chiuse.
Il problema e' il contrario: lo stack tcp/ip di windows risponde con
RST anche ai FIN e ai FINPUSHURG sulle porte aperte le quali, quindi,
vengono mostrate come chiuse.
Fabio

 vengono mostrate come chiuse.
uhm: ok.
Due cazzate in poche righe: sto migliorando, no?
(eppure... ma c'era un tipo di scan che mostrava porte aperte anche 
quando in realta' eran chiuse... talvolta mi capita... boh! forse 
questione di timeout...)
HappyCactus che dovrebbe ripassare un attimino gli scan...


in ascolto sulle interfacce di rete
Mi credi sulla parola se ti dico che il mio IEXPLORE.EXE sta tenendo
aperta (listening) la porta 1258?
Risultano trasemssi e ricevuti 63 byte.
Questo secondo Tiny e netstat conferma.
-- 
Federico Spano`

In un messaggio a nome di Federico Spano` e` scritto:

"Ovviamente" e' usata per le interrogazioni al DNS.
-- 
Federico Spano`

 "Ovviamente" e' usata per le interrogazioni al DNS.
???
Fabio

> dovresti avere un file che si chiama services.txt o 
services.sy
 nella
[snip]
Guarda che quella roba che ti stanno vendendo fa schifo: cerca un nuovo
pusher ;)
Fabio

???
E' semplicemente la porta che viene usata per le interrogazioni in UDP
al DNS. L'ho scoperto bloccandola. 
La differenza e' che IE la tiene aperta in listen, Mozilla pure, ma in
TCP.
-- 
Federico Spano`

 Su quale interfaccia?
Mio esempio.
Ho aperto ie e ho cliccato su "WindowsUpdate".
Finito di caricare la pagina Activeports mi riporta quanto segue
1) IEXPLORE.EXE 127.0.0.1 4025 udp (in listen)
2) IEXPLORE.EXE 192.168.1.1 4033 tcp (in wait)
3) IEXPLORE.EXE 127.0.0.1 4024 tcp (in listen)
La 2 e', correttamente, l' istanza di ie che ha aperto e caricato la
pagina, ma le altre 2 non le capiso.
Forse che ie utilizzi piu' istanze per velocizzare (3) l' apertura delle
pagine?
A.
--
Inviato il gio 01 ago 2002 15:41:43 CEST da 
mlsmipro.ntt.it
[212.17.209.220]
http://www.neuromante.net/

 TCP.
Per le interrogazioni al dns non devi aprire nessuna porta in listen, ne
in udp ne in tcp: deve essere qualcosa d'altro. Non hai scritto su quale
interfaccia di rete sia in ascolto.
Fabio

 3) IEXPLORE.EXE 127.0.0.1 4024 tcp (in listen)
Iexplore.exe apre porte >1024 in listen sull'interfaccia di loopback
per scopi, pare, diagnostici. Su queste porte scrive e legge il buon
explorer, senza che il traffico lasci mai (e' quasi banale dirlo) la
macchina da cui viene generato. E non e' ovviamente possibile che da
fuori qualcuno possa connettersi a queste porte. Morale: varie parti
di explorer hanno bisogno di chiacchierare tra loro per funzionare e
la microsoft ha deciso di farglielo fare con udp su 127.0.0.1 invece
che con un altro sistema.
Fabio

> E' semplicemente la porta che viene usata per le interrogazioni in UDP

L'unica, non ho LAN, solo un accesso internet ISDN. Adesso sono sotto
LInux e non so fare granche', soprattutto non so granche' gestire il
firewall per fare qualche prova. Quello che so e' che quando l'ho
bloccata dal firewall ha smesso di funzionare il dns, e d'altronde
quando era aperta veniva usata per interrogare il dns (si vedeva
l'host che contattava ed era il dns del provider).
Comunque il netstat di Linux (che non so usare), con Mozilla aperto
non scrive 'listening' (ma scrive parecchie cose che non capisco e
potrebbero anche essere equivalenti).
-- 
Federico Spano`

 potrebbero anche essere equivalenti).
Con linux, se una porta sta' ascoltando viene scritto LISTEN. In
windows viene scritto LISTENING. La differenza e' che in linux le
porte indicate in LISTEN sono veramente il LISTEN mentre con win
vengono mostrate il listen anche porte che non lo sono (vedi nei
post precedenti).
Fabio e perche' mai explorer deve scambiarsi punti esclamativi
via udp che complica la vita a tutti.

post precedenti).
Bah, allora non c'e' niente listening sotto Linux. Credo di poter
concludere che:
Premessa: le porte listening sia di Explorer sia di Mozilla sono
sempre sull'interfaccia lo;
come tu hai scritto, Explorer usa l'UDP per parlare da solo;
la prova che ho fatto mi bloccava il dns perche' per fare prima avevo
detto di bloccare tutte le porte in udp;
il fatto che anche adesso ho la localhost:1130 aperta in listening tcp
da Mozilla, e contemporaneamente la stessa 1130 ha una connessione
stabilita in ingresso con la localhost:1131, sempre ad opera di
Mozilla, vuol dire che 1. Mozilla parla da solo anche lui, e 2.
Windows fa vedere listening anche porte che non lo sono?
Tiny purtroppo non fa file di testo, ma riporto qui sotto le parti
pertinenti del netstat -a, che forse spiega il mistero. E' Tiny che
non fa vedere tutte e due le porte in listening, ma solo la 1130.
Connessioni attive
  Proto  Indirizzo locale         Indirizzo remoto             Stato
  TCP    
127.0.0.1:1131
 
0.0.0.0:0
              LISTENING
  TCP    
127.0.0.1:1130
 
0.0.0.0:0
              LISTENING
  TCP    
127.0.0.1:1130
          localhost:1131         ESTABLISHED
  TCP    
127.0.0.1:1131
          localhost:1130         ESTABLISHED
Insomma, accidenti a Windows.
Ciao e grazie
-- 
Federico Spano`

 Insomma, accidenti a Windows.
Tanto per spezzare un'arancia a favore di windows (anzi: di IE)
talvolta anche gnome si comporta cosi'. Spesso mi ritrovo aperta la 
32768, ma solo se ho l'interfaccia grafica aperta (con ICEwm)
