| Autore |
 Discussione  |
|
Diana
Advanced Member
269 Messaggi |
 Inserito il - 20/09/2007 : 18:46:31
|
Nel titolo del thread ho messo Outpost, ma il problema potrebbe riguardare qualsiasi firewall, perchè la cosa più complicata è quella di istruirlo, dargli delle regole che siano davvero efficaci ai finidella protezione.
Io ho installato Outpost pro 2.5 e ho scaricato dal sito [www].ilsoftware.it una guida abbastanza dettagliata di ben 33 pagine. Me la sono letta tutta, ho applicato molte delle cose scritte in
quel pdf, e tuttavia molte cose non mi sono chiare. Provo a spiegarmi.
Innanzitutto c'è da mettere in evidenza che coloro che hanno scritto il manuale, hanno un solo pc per modem. Io invece ho 2 pc, collegati a un router, che però condividono solo la linea adsl, NIENT'ALTRO!
1° problema: non so cosa devo mettere dentro la maschera relativa, appunto alla rete. Outpost, in automatico, mi rileva una rete Lan, e tuttavia mette un indirizzo generico, questo:
192.168.0.0(255.255.255.0).
Considerate che il mio rotuer ha indirizzo 192.168.0.1 e il mio pc 192.168.0.2 (quello del terzo pc è 192.168.0.3).
Quale IP devo mettere???
2° problema: con la rilevazione automatica Outpost ha individuato tutte le applicazioni che potrebbero interfacciarsi con la rete. Ovviamente molte di queste andranno eliminate perchè non le uso (tipo Telnet).
Ma non so quali possano servire a Windows per i vari update. E in ogni caso i permessi mi sembrano un po' troppo larghi. Perchè non approfondiamo questo argomento?
3° problema: nel manuale ho trovato le regole di seguito elencate. Le ho inserite tra le regole globali. Credete che siano sensate, possono andare bene?
Nuova regola#1
Dove il protocollo è protocollo sconosciuto
Negalo e Riportalo
Nuova regola#2
Dove protocollo è IP e di tipo è RAWSOCKET, ICMP, IGMP, GGP, IPIIP, ST, CBT, EGP, NVP, TMUX, HMP, RDP, IRTP, NETBLT, SDRP, GRE, ESP, AH, NARP, MEP, SKIP, ICMPv6, VMTP, OSPF, MTP, IFMP, PIM, IPPCP, VRRP, PGM, PTP, SCTP
Dove la direzione è in uscita e tipo di pacchetto è Locale, Transito, NAT
Negalo e Riportalo
Nuova regola#3
dove il protocollo è IP e di tipo è RAWSOCKET, ICMP, IGMP, GGP, IPIIP, ST, CBT, EGP, NVP, TMUX, HMP, RDP, IRTP, NETBLT, SDRP, GRE, ESP, AH, NARP, MEP, SKIP, ICMPv6, VMTP, OSPF, MTP, IFMP, PIM, IPPCP, VRRP, PGM, PTP, SCTP,
dove la direzione è in arrivo
Negalo e Riportalo
4° problema: per quanto riguarda il DNS Resolving, seguendo il manuale, ho messo tra le applicazioni bloccate svchost.exe, ho disattivato il servizio relativo al DNS, e ho dato ad ongi applicazione la seguente regola:
Regola per applicazione#
dove il protocollo è UDP
dove l'host remoto sono gli IP (DNS) del mio Provider
dove la porta remota è 53
Permettilo
Il fatto è che con le regole così impostate, io non riesco più a connettermi in rete! 
Mi date una mano e cerchiamo di approfondire questi temi che sono molto poco affrontati in qualsiasi forum e troppo superficialmente nelle varie guide online (consultate quasi tutte)?
|
|
|
pedrus
Moderatore
Città: Taranto - Pavia
952 Messaggi |
Inserito il - 20/09/2007 : 19:08:45
|
Citazione:
1° problema: non so cosa devo mettere dentro la maschera relativa, appunto alla rete. Outpost, in automatico, mi rileva una rete Lan, e tuttavia mette un indirizzo generico, questo:
192.168.0.0(255.255.255.0)
La maschera relativa alla rete, ma a quale aspetto della rete? Quello non è propriamente un indirizzo generico, indica solo a che classe appartiene la rete, con la relativa maschera di sottorete. Direi che è giusto così, una tipica rete locale con uno spazio di indirizzi abbastanza ampio per numerosi host eventualmente connessi.
Citazione:
2° problema: con la rilevazione automatica Outpost ha individuato tutte le applicazioni che potrebbero interfacciarsi con la rete. Ovviamente molte di queste andranno eliminate perchè non le uso (tipo Telnet).
Ma non so quali possano servire a Windows per i vari update. E in ogni caso i permessi mi sembrano un po' troppo larghi. Perchè non approfondiamo questo argomento?
Non ricordo quali sono quelli che usa windows update non avendo windows. Magari qualcuno ti potrà essere di aiuto.
Citazione:
3° problema: nel manuale ho trovato le regole di seguito elencate. Le ho inserite tra le regole globali. Credete che siano sensate, possono andare bene?
Sinceramente non sono sicuro, ma le regole 2 e 3 mi sembrano un po' troppo restrittive. Cioè, stando a quelle regole si ha la pretesa di bloccare una serie di protocolli appartenenti al settimo livello del modello OSI. Da quello che c'è scritto manca il htt*, che è quello che ti permette la normale navigazione, e quindi dovrebbe teoricamente funzionare, però ad esempio è citato lo ICMP che è utilizzato da parecchi programmi, ad esempio il ping. Prova a disattivare quelle due regole e vedi se funziona, eventualmente, invece di specificare tutti quei protocolli fallo uno alla volta e vedi cos'è che causa il blocco della navigazione.
In linea di massima, però, volendo gestire un firewall che agisce a quei livelli di networking, e non a livello di singoli programmi, un po' come avviene sotto linux con netfilter (e quindi iptables), preferirei bloccare tutto a priori, poi con un software per scanzionare i pacchetti che cercano di entrare e di uscire, vedere quali sono quelli che realmente mi servono e aprire le porte solo a quelli. |
 |
|
|
Diana
Advanced Member
269 Messaggi |
Inserito il - 20/09/2007 : 21:35:22
|
Grazie per le risposte innanzitutto.
Citazione:
Messaggio inserito da pedrus
La maschera relativa alla rete, ma a quale aspetto della rete? Quello non è propriamente un indirizzo generico, indica solo a che classe appartiene la rete, con la relativa maschera di sottorete.
Tieni presente, come ho specificato sopra, che con l'altro pc non condivido nulla (nemmeno una cartella!), soltanto la linea adsl, e che il router è anche uno switch. Come dovrei considere il mio pc, quindi? Un pc "singolo" direttamente collegato all'esterno, oppure un pc all'interno di una rete casalinga?
E' questo il dubbio che ho.
Citazione:
Messaggio inserito da pedrus
Direi che è giusto così, una tipica rete locale con uno spazio di indirizzi abbastanza ampio per numerosi host eventualmente connessi.
Sai però cosa mi succede? Che quando apro il browser, ad esempio, mi appaiono dei continui messaggi di "richiesta" o "risoluzione" (vado a memoria, ora sto sull'altra partizione) anomala del DNS, e vedo nello storico di Outpost l'aprirsi in sequenza di un casino di porte, tanto che più di una volta ho scollegato il cavo dalla paura!
Ma credo, in realtà, che la porta remota che si vuole collegare al mio localhost (127.0.0.1) sia proprio il router.
E allora mi chiedo perchè, sia Outpost che la suite di KIS, avvertano questo fatto come una minaccia.
Se non ho sbagliato la mia analisi, che regola devo creare affinchè non vedano il rotuer come un intruso?
Citazione:
Messaggio inserito da pedrus
Sinceramente non sono sicuro, ma le regole 2 e 3 mi sembrano un po' troppo restrittive. Cioè, stando a quelle regole si ha la pretesa di bloccare una serie di protocolli appartenenti al settimo livello del modello OSI.
Eh, l'ho studiato un pochino il modello OSI, ma sono arrivata soltanto fino al livello di data link, purtroppo!
Ma, se non vado errata, il settimo livello è quello dell'applicazione.
In effetti sono regole molto restrittive. Il fatto è che non ho molta dimistichezza con quei nomi (rawsocket, etc. etc.).
Ma quello che non capisco, soprattutto, è perchè quelle regole specifichino il tipo di protocollo IP.
E' questo che sembra fare la differenza!
Nella condizione, non c'è il protocollo UDP o TCP, ma IP
Citazione:
Messaggio inserito da pedrus
Da quello che c'è scritto manca il htt*, che è quello che ti permette la normale navigazione, e quindi dovrebbe teoricamente funzionare, però ad esempio è citato lo ICMP che è utilizzato da parecchi programmi, ad esempio il ping.
Mah, quella di non permettere l'ICMP, credo che sia una filosofia di coloro che hanno scritto il manuale, i quali sostengono che "meno siamo visibili in rete e meglio è".
In altre parole vorrebbero fare in modo che i nostri pc non possano essere nemmeno pingati, appunto.
Comunque, prima di formattare tutto, e con una versione più vecchia di Outpost, le avevo applicate quelle regole e, onestamente, navigavo senza problemi. Quindi non dovrebbero essere le regole globali a dare fastidio. Mi interesserebbe soltanto saperle decifrare.
Il problema per cui non mi collego più, credo che sia dovuto alla regola (da impostare per ogni singola applicazione) per il DNS Resolving.
A me sembra che manchi qualcosa...
Com'è possibile che si faccia una sola regola per pacchetti in uscita e soltanto con protollo UDP??
Non dovrebbe essercene una anche per il TCP?
E poi, i pacchetti, non dovrebbero viaggiare anche in entrata?
|
Modificato da - Diana in data 20/09/2007 21:41:12 |
|
|
|
pedrus
Moderatore
Città: Taranto - Pavia
952 Messaggi |
Inserito il - 20/09/2007 : 22:27:36
|
Citazione:
Come dovrei considere il mio pc, quindi? Un pc "singolo" direttamente collegato all'esterno, oppure un pc all'interno di una rete casalinga?
Se il pc, o i pc, sono dietro un router (e nel tuo caso mi sembra di capire che è così), allora sei all'interno di una rete. In pratica dall'esterno, quindi, lato Internet, vieni vista con un solo IP, che è quello pubblico, e poco importa se dietro quell'IP ci sono due o più PC, o anche uno solo. Di conseguenza, non è il pc che stai usando adesso che viene visto come un singolo pc collegato all'esterno, in realtà è il router che viene visto come un host, poi, all'interno è il router stesso che si occupa della gestione dei vari host, assegnando ad ognuno di essi un numero IP appartenenti alla classe riservata alle reti locali (che nel tuo caso è nel range 192.168.0.1 e 192.168.0.255). Quindi, l'IP che vedi sul tuo PC in realtà non è lo stesso IP con il quale vieni vista in rete, ma è solo l'IP con il quale vieni vista all'interno della rete locale.
Citazione:
Sai però cosa mi succede? Che quando apro il browser, ad esempio, mi appaiono dei continui messaggi di "richiesta" o "risoluzione" (vado a memoria, ora sto sull'altra partizione) anomala del DNS, e vedo nello storico di Outpost l'aprirsi in sequenza di un casino di porte, tanto che più di una volta ho scollegato il cavo dalla paura!
Beh, bisognerebbe vedere quali sono queste porte che outpost apre. In particolare, credo che nei log di outpost, non solo sia possibile vedere le porte che vengono aperte ma anche gli indirizzi del mittente e del destinatario. Cioè, se outpost apre una porta è perchè il pc deve comunicare con un qualche indirizzo (router? indirizzo Internet? Altro pc nella rete locale?), quindi solo leggendo il log nella sua interezza si potrebbe cercare di capire quali sono i meccanismi interessati in questo flusso di pacchetti e perchè.
Citazione:
Ma credo, in realtà, che la porta remota che si vuole collegare al mio localhost (127.0.0.1) sia proprio il router.
Se l'indirizzo di destinazione è 127.0.0.1 allora è un processo in esecuzione sul pc che cerca di comunicare con il pc stesso. Se fosse il router allora come destinazione non avresti localhost (127.0.0.1) ma 192.168.0.2 (o comunque l'IP che il router stesso ha assegnato al tuo pc)
Citazione:
E allora mi chiedo perchè, sia Outpost che la suite di KIS, avvertano questo fatto come una minaccia.
E' trascorso troppo tempo dal mio ultimo utilizzo di windows, in pratica due anni, quindi quello che dico sono solo nozioni teoriche di networking, e neanche ad alti livelli di preparazione, visto che non sono un'esperto. Però, se un software (o anche un dispositivo hardware) indicano una determinata cosa come una minaccia è semplicemente perchè sono stati addestrati così, quindi bisognerebbe impostare il software in modo tale che capisca definitivamente che una determinata cosa come una minaccia.
Citazione:
Se non ho sbagliato la mia analisi, che regola devo creare affinchè non vedano il rotuer come un intruso?
Il fatto è questo, il router in realtà non è che non sia una minaccia. Il router, salvo impostazioni particolari, in realtà non vuole comunicare con il tuo pc, ma fa semplicemente da tramite fra il tuo pc e Internet e fra il tuo pc e gli altri nella rete locale. Cioè, in linea di massima è molto difficile che nell'analizzare i pacchetti in arrivo tu veda come mittente il router, in realtà, vedrai come mittente inidirizzi Internet o gli indirizzi degli altri pc nella rete. Anche se tutti i pacchetti passano attraverso il router, lui li smista sul tuo pc senza fare una valutazione di ciò che deve o non deve passare (a meno che tu non abbia attivato il firewall integrato nel router stesso, visto che moltissimi ne sono provvisti), ecco perchè il router non necessariamente è fidato e, come detto, in ogni caso nei tuoi log difficilmente troverai come indirizzo del mittente quello del router.
Citazione:
Nella condizione, non c'è il protocollo UDP o TCP, ma IP
E' proprio qui, o comunque nei casi come questo, che sta l'importanza della comprensione del modello ISO/OSI. IP è ad un livello differente rispetto al TCP o UDP. IP è al livello networking, TCP e UDP sono dei protocolli, al livello di trasporto, con i quali viaggiano dei pacchetti di fatto "incapsulati" all'interno di IP. Per farla in parole povere, anzi poverissime, e quindi sotto certi aspetti inesatte, ma più facili da comprendere, se si ipotizzasse di bloccare tutti i pacchetti IP allora si bloccherebbero tutti i pacchetti che viaggiano sui protocolli sottostanti.
Citazione:
Mah, quella di non permettere l'ICMP, credo che sia una filosofia di coloro che hanno scritto il manuale, i quali sostengono che "meno siamo visibili in rete e meglio è".
Se sei dietro un router, allora bisognerebbe dire al router di non accettare quel tipo di pacchetti, visto che se arriva un ping da Internet, è il router che risponde e non il tuo pc, a prescindere da quale tipo di filtraggio sia stato impostato.
Citazione:
Com'è possibile che si faccia una sola regola per pacchetti in uscita e soltanto con protollo UDP??
Dipende da quali obiettivi l'autore della guida si è prefisso di ottenere. Nel caso specifico, il si intende usare quel protocollo solo per le richiese DNS.
Citazione:
Non dovrebbe essercene una anche per il TCP?
TCP e UDP sono profondamente diversi. Molto utile ai fine della comprensione delle differenze può essere la lettura di questa pagina htt*://it.wikipedia.org/wiki/Transmission_Control_Protocol .
E se sei interessata all'argomento, e vuoi approfondire il discorso dei livelli stabiliti dal modello ISO/OSI, potresti dare un'occhiata qui: htt*://it.wikipedia.org/wiki/Suite_di_protocolli_Internet. A suo tempo approndii un po' l'argomento grazie ad un testo eccezionale, magari un po' complesso, orientato più a studi universitari, ma molto molto approfondito: "Reti di Calcolatori" di Peterson e Davie. La parte iniziale del libro è molto chiara, o quantomeno riesce a far capire cosa sono i vari livelli del protocollo e come funzionano.
Mi spiace, probabilmente dal punto di vista strettamente pratico, tutto quello che ho detto non ti potrà essere utile, outpost non lo conosco, non ho neanche modo di installarlo non avendo windows, quindi purtroppo mi posso limitare a qualche chiarimento di carattere teorico, sempre sperando, dal basso della mia incopentenza, di non sparare troppe inesattezze. |
Modificato da - pedrus in data 20/09/2007 22:41:25 |
|
|
|
Diana
Advanced Member
269 Messaggi |
Inserito il - 20/09/2007 : 22:57:03
|
Naaaa, sei troppo modesto, te ne intendi eccome invece!!
In effetti a me piacerebbe molto approfondire, anzi, sicuramente lo farò (grazie per il link e il titolo del libro). Però al momento ho l'urgenza di settare il firewall.
E' chiaro che tra il firewall software e quello del router, preferirei settare il secondo, ma onestamente lo trovo più difficile ancora.
Che entrambi i pc collegati al router escano con lo stesso IP, ce l'ho abbastanza chiaro. Il problema è come far capire ad Outpost, o chi per lui, che deve lasciar fare al router il suo mestiere!
Certo, hai ragione tu a dire che se il firewall del router non è, a sua volta, ben settato, i problemi potrebbero arrivare anche attraverso di lui. Ottima considerazione, non ci avevo pensato!
Ad ogni modo, domani posterò uno screenshot o qualcosa del genere per farti vedere cosa succede esattamente, perchè io non so spiegartelo. Ora sono loggata sull'altra partizione e tra un po' vado a letto.
Magari con un'immagine più chiara del problema, potrai darmi anche qualche suggerimento pratico. Ma le tue spiegazioni non le disdegno affatto, quindi non dispiacerti nemmeno un po'!
A domani!
|
|
|
|
Diana
Advanced Member
269 Messaggi |
Inserito il - 21/09/2007 : 09:50:59
|
Ecco gli screenshot promessi ieri.
Li ho suddivisi nelle seguenti fasi:
All'avvio del pc:
- Rapporto allarmi
- Bloccati
- Permessi
All'avvio del browser:
- Rapporto allarmi
- Permessi
Rapporto allarmi all'avvio del pc, mentre parte l'autoaggiornamento dell'antivirus
htt*://img297.imageshack.us/my.php?image=richiestadnsanamalaog3.png
Permessi all'avvio del pc, durante l'autoaggiornamento dell'antivirus
htt*://img461.imageshack.us/my.php?image=avviopu8.png]
Bloccati all'avvio del pc, durante l'autoaggiornamento dell'antivirus
htt*://img297.imageshack.us/my.php?image=bloccatien8.png]
Rapporto allarmi all'avvio del browser
htt*://img461.imageshack.us/my.php?image=aperturadelbrowserpv1.png
Permessi durante l'avio del browser
htt*://img297.imageshack.us/my.php?image=permessiallaperturadelbpa6.png
Come potrai vedere, ogni volta che viene chiesta una connessione in uscita, si verifica una richiesta anomala del DNS. Tutte quelle scritte in blu nel primo screenshot, sono le varie porte che via via si aprono durante questa anomalia.
Altra cosa che non capisco sono quella "Ricezione di pacchetti non locali" in SYSTEM, e gli "allowloopback" che, da quanto ho scoperto, sono delle connessioni a sè stessi, e la cosa a me pare senza senso... a che serve che un pc invii dei pacchetti a se stesso?? 
Comunque, credo di aver fornito sufficienti elementi per un'analisi del problema. E faccio una precisazione: ho lasciato agire Outpost con la seconda configurazione, nella quale ho rimesso le sue impostazioni di default. (la prima configurazione è quella in cui ho fatto un po' di esperimenti inserendo le regole postate sopra.
A voi l'ardua sentenza! 
[edit]
Ah, dimenticavo: gli IP che vedete nel Rapporto Allarmi, sono rispettivamente quelli del mio provider e quello del mio pc.
|
Modificato da - Diana in data 21/09/2007 09:54:29 |
|
|
|
pedrus
Moderatore
Città: Taranto - Pavia
952 Messaggi |
Inserito il - 21/09/2007 : 10:56:44
|
Bah, a prima vista sembrerebbe che il problema sia nella risoluzione DNS. Credo che dipenda dal fatto che si cerca di allestire un firewall che agisce a vari livelli, in un caso si agisce a livello di pacchetti-indirizzi-protocolli, indipendentemente dalle applicazioni, e in un caso si agisce andando a intervenire sui processi, cioè autorizzando o meno alcuni processi a svolgere attività di rete. Credo che il problema nel tuo caso sia dovuto al fatto che alcune regole impostate vadano in conflitto fra di loro. Nell'ultimo screenshot, ad esempio, si vedono dei pacchetti in uscito relativi al DNS che sono stati permessi, ma non si vedono quelli in entrata che dovrebbero contenere le risposte alle richieste DNS.
Citazione:
Regola per applicazione#
dove il protocollo è UDP
dove l'host remoto sono gli IP (DNS) del mio Provider
dove la porta remota è 53
Permettilo
Suppongo che il problema sia in questa regola. Così come è scritta sembrerebbe esatta, ma sicura che sia impostata sia in IN che in OUT? Prova a disattivarla e vedi come va. Poi reimpostala in modo tale da permettere il traffico sia IN che OUT. In pratica:
Pacchetti UDP in uscita (OUT) destinazione "indirizzo provider" porta remota 53 > permettilo
Pacchetti UDP in entrata (IN) provenienza (o indirizzo remoto) "indirizzo provider" porta remota 53 > permettilo |
|
|
|
Diana
Advanced Member
269 Messaggi |
Inserito il - 21/09/2007 : 13:56:17
|
Citazione:
Messaggio inserito da pedrus
Bah, a prima vista sembrerebbe che il problema sia nella risoluzione DNS. Credo che dipenda dal fatto che si cerca di allestire un firewall che agisce a vari livelli, in un caso si agisce a livello di pacchetti-indirizzi-protocolli, indipendentemente dalle applicazioni, e in un caso si agisce andando a intervenire sui processi, cioè autorizzando o meno alcuni processi a svolgere attività di rete.
Sì, esattamente, Outpost ha delle regole globali e altre regole specifiche per le applicazioni.
Ma penso che la cosa valga anche per altri firewall, noo?
Citazione:
Messaggio inserito da pedrus
Credo che il problema nel tuo caso sia dovuto al fatto che alcune regole impostate vadano in conflitto fra di loro. Nell'ultimo screenshot, ad esempio, si vedono dei pacchetti in uscito relativi al DNS che sono stati permessi, ma non si vedono quelli in entrata che dovrebbero contenere le risposte alle richieste DNS.
E' quello che dicevo anch'io in un post precedente!
Non dovrebbe esserci una regola anche per i pacchetti in entrata in qualità di risposta al DNS?
Citazione:
Messaggio inserito da pedrus
Suppongo che il problema sia in questa regola. Così come è scritta sembrerebbe esatta, ma sicura che sia impostata sia in IN che in OUT? Prova a disattivarla e vedi come va. Poi reimpostala in modo tale da permettere il traffico sia IN che OUT. In pratica:
Pacchetti UDP in uscita (OUT) destinazione "indirizzo provider" porta remota 53 > permettilo
Pacchetti UDP in entrata (IN) provenienza (o indirizzo remoto) "indirizzo provider" porta remota 53 > permettilo
Proverò a settare come mi hai detto sul 1° profilo, quello cioè dove ho applicato tutte le regole del manuale.
Però considera che oggi mi sono collegata con il 2° profilo, quello dove ci stanno le impostazioni di default, e il DNS è gestito dal Servizio Client DNS che sfrutta le molteplici funzioni di svchost.exe.
In questo profilo ho lasciato tutto come ha impostato automaticamente lo stesso Outpost, e quindi non ho bloccato il svchost.exe!
(ora che ci penso, però, non è avviato il servizio Client DNS...  )
In questo momento sono collegata con il 2° profilo, perchè con il 1°, sebbene alla fine fossi riuscita a navigare lasciando al browser soltanto il permesso di inviare in uscita pacchetti con il protocollo UDP (porta remota 53), in seguito però il firewall ha interpretato come un attacco la continua errata Risoluzione del DNS e ha bloccato praticamente il mio provider
Spero che non me l'abbia bloccato per sempre!
Ciò che davvero non comprendo, inoltre, è perchè il firewall, anche con le impostazioni di default continua a chiedermi di permettere o di creare una regola per il loopback di localhost, ora in uscita e ora verso se stesso... ma che senso ha sta cosa??
Grazie Pedrus, mi stai dando una grossa mano! |
|
|
|
Diana
Advanced Member
269 Messaggi |
Inserito il - 21/09/2007 : 14:17:50
|
Ho impostato sul 1° profilo (quello che aveva bloccato il Provider) le due regole come le hai scritte tu. NAVIGO!!
Però il firewall continua a chiedermi di creare delle regole per il loopback... ma è proprio necessaria sta cosa?? A me non piace molto questa storia...
Nell'altra partizione (C:\win 2k) ho la suite del Kaspersky, e mi da lo stesso problema, mi chiede di autorizzare o bloccare il loopback. Ebbene, se lo blocco navigo ugualmente... quindi a che serve?
A stasera, ora devo uscire.  |
|
|
|
pedrus
Moderatore
Città: Taranto - Pavia
952 Messaggi |
Inserito il - 21/09/2007 : 15:25:45
|
L'argomento è talmente vasto e, a maio avviso, talmente interessante, che rispondere qui su due righe non è cosa semplice. Comunque:
Citazione:
Outpost ha delle regole globali e altre regole specifiche per le applicazioni.
Ma penso che la cosa valga anche per altri firewall, noo?
Non è proprio così. Dipende dalla tipologia di firewall. Sotto windows, i firewall sono tendenzialmente orientati alla gestione delle applicazioni, ovvero si autorizza o meno un'applicazione a fare uso della rete. I firewall nel senso classico del termine (e, a mio modestissimo parere, nel senso più corretto del termine) agiscono ad un livello più basso, ovvero sula gestione pura dei protocolli e dei pacchetti. Sotto linux si è più abituati a quest'ultimo tipo di gestione. In pratica si aprono o si chiudono determinate porte a determinati tipi di pacchetti provenienti o diretti verso certi indirizzi, o solo a determinati protocolli. Oppure autorizzare in entrata solo determinati pacchetti, con protocollo TCP e magari flag diverso da SYN e appartenenti a connessioni già aperte, ma in questi casi si va su una gestione molto accurata, è un po' come fare un lavoro di "chirurgia" molto precisa e selettiva. Non sono esperto ma questo tipo di gestione mi affascina. Comunque, tutto questo per dire che in questo modo il firewall opera su pacchetti e protocolli a prescindere da quale sarà poi l'applicazione che userà questi pacchetti. In poche parole, poco ci si preoccupa delle applicazioni, ma ci si preoccupa solo di ciò che realmente può entrare e uscire, e ci se ne occupa ad un livello di selettività molto elevato, potendo operare sui protocolli ad un livello di dettaglio elevatissimo. Chiramente, operando come nel tuo caso sia a livello delle applicazioni che a livello di protocollo e tipi di pacchetti, è più facile incorrere in conflitti. Ad esempio si autorizza un'applicazione a fare uso della rete ma le regole di base magari bloccano i tipi di pacchetti prodotti da quella stessa applicazione, sebbene autorizzata.
Citazione:
Non dovrebbe esserci una regola anche per i pacchetti in entrata in qualità di risposta al DNS?
Suppongo proprio di si, ecco perchè ti ho consigliato di controllare bene quelle regole ed eventualmente provare a riscriverle come ti ho descritto.
Citazione:
Però considera che oggi mi sono collegata con il 2° profilo, quello dove ci stanno le impostazioni di default, e il DNS è gestito dal Servizio Client DNS che sfrutta le molteplici funzioni di svchost.exe.
In questo profilo ho lasciato tutto come ha impostato automaticamente lo stesso Outpost, e quindi non ho bloccato il svchost.exe!
Sinceramente tocchiamo un argomento che non conosco. Certi processi di windows non li ho mai compresi a fondo.
Citazione:
Ciò che davvero non comprendo, inoltre, è perchè il firewall, anche con le impostazioni di default continua a chiedermi di permettere o di creare una regola per il loopback di localhost, ora in uscita e ora verso se stesso... ma che senso ha sta cosa??
Io personalmente opterei per autorizzare sempre l'interfaccia di loopback senza complicarsi la vita nella creazione di regole particolari. L'interfaccia di loopback, alla quale è di default assegnato numero IP 127.0.0.1, può essere utilizzata da vari processi. Ci sono infatti molti processi che per trasmettere (od ottenere) informazioni sfruttano dei socket di rete appositamente creati nel momento in cui viene avviato il processo stesso. In pratica, alcuni processi, all'avvio, creano un vero e proprio server che viene utilizzato per alcuni compiti, ma questo dipende sempre dall'applicazione. A titolo esemplificativo, anche quei software che permettono di scaricare in locale le email che giungono sulle caselle raggiungibili solo tramite web (libero, hotmail e altre) creano dei server di posta raggiungibili su localhost. Ma si potrebbero fare decine di esempi. In conclusione, il traffico diretto e ricevuto da localhost (che quindi si serve dell'interfaccia loopback) ritengo lo si possa autorizzare tranquillamente tranne che non ci sia qualche oscuro meccanismo di windows che per il quale è sconsigliato farlo, ma magari qualcuno più esperto di me ti potrà rispondere.
Citazione:
Ho impostato sul 1° profilo (quello che aveva bloccato il Provider) le due regole come le hai scritte tu. NAVIGO!!
Quindi ritengo che al momento hai risolto. Ti resta (o ti restava) solo il dubbio del loopback.
Citazione:
Nell'altra partizione (C:\win 2k) ho la suite del Kaspersky, e mi da lo stesso problema, mi chiede di autorizzare o bloccare il loopback. Ebbene, se lo blocco navigo ugualmente... quindi a che serve?
Si, se la blocchi navighi lo stesso, la loopback di fatto non ha comunicazioni con l'esterno (salvo impostazioni molto particolari), ma bloccarla, più che pregiudicare la navigazione, potrebbe pregiudicare il funzionamento di qualche programma che opera in locale, ecco perchè, come ho detto prima, io autorizzerei quell'interfaccia senza problemi. Io, sul mio pc, sebbene linux powered e non windows powered, faccio molto uso di quell'interfaccia, o meglio, più che io, i programmi che utilizzo ne fanno uso.
Tiro a indovinare, visto che non ne ho idea, magari anche il servizio di ricerca dei file su windows si serve di quell'interfaccia, perchè magari lui indicizza i file in un database e poi, quando cerchi un file viene interrogato quel database come in un'interrogazione di rete, solo che avviene in locale e, quindi, su localhost. E' solo un esempio, forse del tutto sbagliato, visto che non so come viene gestita la ricerca dei file su windows, però lo stesso esempio di può applicare a qualsiasi tipo di applicazione. Ecco perchè, e so che sono ripetitivo fino alla nausea, ritengo lecito autorizzare loopback. |
|
|
|
Diana
Advanced Member
269 Messaggi |
Inserito il - 21/09/2007 : 21:18:39
|
Allora, diciamo che ho risolto a metà...  (con windows ci vuole tanta pazienza!)
Non so se è per merito di quelle due regole, da te suggerite, che ho inserito, ma almeno si è sbloccato qualcosa, con il primo profilo ora navigo, purtroppo è rimasto il problema del DNS Resolving...
Non so, dopo aver letto quello che hai scritto, ovvero come agiscono i firewall di Linux, mi rendo conto che regole globali possano andare in conflitto con quelle per gli applicativi. La cosa stranissima però è che con la versione più vecchia di Outpost tutto ciò non è mai successo e lì avevo lasciato regole globali e quelle degli applicativi (soltanto quelli che usavo però) di dafault, non sapendo bene come mettere le mani in un firewall.
Con questa nuova versione, invece, il problema del DNS resolving ce l'ho sia con le impostazioni di default, che con le impostazioni mie. Vedrò di smanettare un po' di più e di venirne a capo in qualche modo.
Per quanto riguarda la questione del non far gestire il DNS Resolving a svchost.exe, sta scritto molto bene in questa guida htt*://[www].ilsoftware.it/articoli.asp?ID=2508&pag=4 (pag. 19, non pretendo che tu la legga tutta, è lunga 33 pagine, ma quel paragrafo magari riesce a spiegarti la cosa meglio di quanto non riesca a fare io).
E ora veniamo al loopback. Credo tu abbia ragione, infatti anche il mio antivirus sfrutta quella funzione. E' vero inoltre che anche FreePops usa il localhost per far funzionare la ricezione delle mail nel client. Diciamo che il grande dubbio mi è venuto quando ho visto che il firewall della suite di Kaspersky (rinomata come una delle migliori in assoluto) nelle impostazioni di base lascia il loopback disattivato, e gli udpate di Windows, ti assicuro, funzionano ugualmente.
Inoltre, non molto tempo fa, credo di essermi infettata con qualche brutta schifezza e me ne sono accorta proprio osservando i log del firewall: avvenivano molto frequentemente delle connessioni ad un sito in cui io non navigavo e ciò che succedeva ogni volta era proprio un loopback, ecco perchè lo temo tanto! 
Ed ecco, anche, perchè ora vorrei settare sto benedetto firewall al meglio.
Però credo tu abbia ragione sull'argomento (anche se non è strettamente connesso agli update di win). Solo che non ho capito molto bene come devo impostarlo, perchè ogni volta che il firewall mi chiede una regola al riguardo, mi presenta ogni volta una porta diversa, e qui vado in confusione.
La cosa più simpatica in tutta questa faccenda, è che mi sta aiutando un linuxiano doc!
Domani voglio leggere attentamente anche quei due link che mi hai postato, me se ti va ancora di darmi una mano o di postare quello che sai sulle reti, sappi che a me sta tornando molto utile.
|
|
|
|
pedrus
Moderatore
Città: Taranto - Pavia
952 Messaggi |
Inserito il - 21/09/2007 : 22:36:52
|
Citazione:
Non so se è per merito di quelle due regole, da te suggerite, che ho inserito, ma almeno si è sbloccato qualcosa, con il primo profilo ora navigo, purtroppo è rimasto il problema del DNS Resolving...
Puoi postare un nuovo screenshot dei messaggi che ti appaiono con l'attuale configurazione? Con le regole che hai impostato come ti ho descritto.
Citazione:
Con questa nuova versione, invece, il problema del DNS resolving ce l'ho sia con le impostazioni di default, che con le impostazioni mie. Vedrò di smanettare un po' di più e di venirne a capo in qualche modo.
Beh, noi stiamo smanettando su outpost, ma, in fin dei conti, a generare questo problema protrebbe essere qualcos'altro, magari una errata configurazione delle opzioni di rete, nelle quali magari è specificato di gestire alcune cose in un certo modo e, il firewall, alla fin fine sta facendo il suo dovere. Cioè, ora praticamente, dopo che hai impostato le regole come ti avevo indicato, riesci a navigare ma hai quei messaggi di errore (o avvisi), ma allora non è che è qualche altro processo che sta generando quel tipo di traffico e che il firewall, diligentemente, blocca o comunque genera l'avviso?
Citazione:
Per quanto riguarda la questione del non far gestire il DNS Resolving a svchost.exe, sta scritto molto bene in questa guida htt*://[www].ilsoftware.it/articoli.asp?ID=2508&pag=4 (pag. 19, non pretendo che tu la legga tutta, è lunga 33 pagine, ma quel paragrafo magari riesce a spiegarti la cosa meglio di quanto non riesca a fare io).
Magari con più calma posso anche leggerla tutta, ma sinceramente dimenticherei in poco tempo visto che non ho neanche un pc con windows per poter spermentare al momento le cose che leggerei. Magari meglio di volta in volta leggere le parti che possono servire. In particolare, ho letto quello che mi hai indicato (pag. 19). Ora, purtroppo posso limitarmi a ripeterti quello che c'è scritto sulla guida ma, in particolare, sicura che hai disabilitato il Servizio DNS Client e bloccato svchost.exe?
Citazione:
Diciamo che il grande dubbio mi è venuto quando ho visto che il firewall della suite di Kaspersky (rinomata come una delle migliori in assoluto) nelle impostazioni di base lascia il loopback disattivato, e gli udpate di Windows, ti assicuro, funzionano ugualmente.
Non lo metto in dubbio, anzi, mi sembra anche normale. Ma il problema non è questo, è che credo che non ti sia chiaro il concetto di interfaccia di loopback, infatti scrivi:
Citazione:
Inoltre, non molto tempo fa, credo di essermi infettata con qualche brutta schifezza e me ne sono accorta proprio osservando i log del firewall: avvenivano molto frequentemente delle connessioni ad un sito in cui io non navigavo e ciò che succedeva ogni volta era proprio un loopback, ecco perchè lo temo tanto!
Cioè, affermi che l'interfaccia di loopback stabiliva connessioni con un sito Internet? L'interfaccia di loopback fa solo connessioni sulla macchina locale, so che è un concetto poco facile da comprendere, e che io magari non sono neanche tanto capace di spiegare, ma la loopback fa solo connessioni su se stessa. Cioè, la loopback è un'interfaccia virtuale. Da remoto, le connessioni avvengono sulla tua interfaccia di rete (la porta ethernet, la porta dalla quale parte il cavo che arriva al router), quindi è li che devi preoccuparti di filtrare bene il traffico. Poi, che dirti, se proprio ritieni che nessun processo che utilizzi ha bisogno della loopback, allora disattivals. Io se disattivassi la loopback mi troverei nell'impossibilità di fare alcune cose.
E comunque, un discorso è la pericolosità di una interfaccia di rete, nella fattispecie la loopback, un discorso è la pericolosità dei processi che la usano. In fondo, se la loopback è attiva, è dei programmi che la usano che devi preoccuparti, cioè che siano esenti da bug, o che comunque siano processi legittimi, ma comunque, ripeto, la loopback la usa il sistema per comunicare con se stesso, e non con l'esterno. Per comunicare con l'esterno si serve dell'interfaccia di rete e, siccome si presuppone che l'ambiente ostile sia l'esterno e non casa nostra, è li che devi focalizzare l'attenzione. Comunque, ai fini della crescita culturale, cioè, per imparare qualcosina in più, dai uno sguardo qui, sicuramente si esprime molto meglio di me: htt*://it.wikipedia.org/wiki/Interfaccia_di_loopback oppure, con una piccola nota comica, guarda anche qui: htt*://it.wikipedia.org/wiki/Localhost
Citazione:
Solo che non ho capito molto bene come devo impostarlo, perchè ogni volta che il firewall mi chiede una regola al riguardo, mi presenta ogni volta una porta diversa, e qui vado in confusione.
Ecco qui un altro motivo di confusione. Allora, i server sono in ascolto su una porta specifica, che è fissa, i client si collegano al server utilizzando una porta a caso. Ora, senza andare a discutere troppo sull'uso delle porte, quelle fino alla 1024 (che sono particolari) o quelle superiori (per altri usi), riassumo brevemente una connessione:
INDIRIZZO DI ORIGINE:PORTA DI ORIGINE ============> INDIRIZZO DI DESTINAZIONE:PORTA DI DESTINAZIONE
Allora, se stai cercando di collegarti ad un server (ad esempio un server web, nel caso in cui tu stia navigando) l'indirizzo di origine è il tuo PC, il sistema poi provvede per quella connessione ad assegnare una porta a caso (in linea di massima sempre superiore a 1024) fra quelle disponibili, l'indirizzo di destinazione sarà il sito web che vuoi visitare e la porta sarà la 80 (perchè i server web sono in ascolto su quella porta e di default il browser cerca di contattare quella porta, salvo indicazione differente)
Se contemporaneamente cerchi di aprire un altra connessione con un altro sito vedrai che l'indirizzo di origine sarà sempre il tuo PC, ma la porta sarà una porta differente perchè, anche in questo caso, per quella singola connessione, il sistema assegnerà un altra porta fra quelle disponibili, essendo quella assegnata prima impegnata da un'altra connessione. La porta di destinazione sarà sempre la 80.
Allo stesso modo ti puoi accorgere di come vanno le cose guardando le risposte che arrivano dai siti che stai visitando, in pratica in questo caso l'indirizzo di origine sarà quello del sito che hai aperto, la porta di origine sarà la 80, perchè è su quella che il browser va a puntare, ma nell'indirizzo di destinazione troverai l'indirizzo del tuo PC e come porta vedrai la porta che era stata precedentemente aperta quando hai iniziato la connessione. In particolare, all'indirizzo htt*://it.wikipedia.org/wiki/Tcp , leggendo il paragrafo "Server e Client" troverai scritto "Il processo client richiede di stabilire una connessione verso un determinato server su una determinata porta. Normalmente la porta sorgente usata dal client viene allocata dinamicamente dal sistema operativo del client."
Ecco perchè vedi ogni volta una porta diversa, vuol dire in pratica che il tuo pc ha stabilito una connessione con un qualche indirizzo e che per quella connessione ha dovuto aprire una determinata porta, ma se controlli bene, la porta dell'altro indirizzo, quello verso cui sei connessa, o stai cercando di connetterti, è sempre la stessa, quantomeno a parità di tipo di connessione (web sulla porta 80, scaricare la posta via POP va sulla porta 110, quando la invii va sulla 25, ecc. ecc.)
So che a forza di scrivere così tante cose rischio di diventare noioso e di generare ulteriore confusione, ma purtroppo posso limitarmi solo agli aspetti teorici che, necessariamente, per essere compresi richiedono un certo approfondimento.
Se avessi outpost sarei passato agli aspetti pratici, ci avrei smanettato e se avessi risolto ti avrei detto "clicca qui, clicca li, premi ok, clicca quello, clicca questo, premi ok" e avresti risolto, con molte meno parole, ma forse senza neanche capire cosa stai facendo.
Purtroppo al momento non posso esserti di aiuto in altro modo. |
Modificato da - pedrus in data 21/09/2007 22:41:15 |
|
|
|
Diana
Advanced Member
269 Messaggi |
Inserito il - 22/09/2007 : 12:50:54
|
Guarda, le tue spiegazioni piano piano mi stanno facendo capire e anche ricordare, perchè, vedi, molte delle cose che tu hai scritto e anche tra quelle pubblcate su wikipedia, io le conosco. Conosco, ad esempio, il concetto di connesso e affidabile (o non); so che cos'è una sliding door (finestra scorrevole) che controlla la congestione ma anche la ricezione di tutti i pacchetti e in modo ordinato; so che cos'è un checksum, il controllo CRC e come viene eseguito.
Ma sono tutte cose che ho imparato soltanto in teoria e in modo piuttosto frammentato, o meglio a compartimenti stagni. In altre parole, mi rimane difficile collegare tra loro tutte queste cose e saperle tradurre nella pratica.
Quindi le tue spiegazioni, unitamente all'analisi di ciò che sta succedento ai miei firewall, mi aiutano a mettere questi tasselli di mosaico insieme, e a farne, si spera, una visione d'insieme più nitida e completa.
Ora veniamo all'analisi dunque, affrontando un problema per volta. Partiamo dal loopback.
Ora sto nella partizione in cui c'è win 2k e la suite di Kaspersky. Ho flaggato tutte le applicazioni in modo che avvenga una registrazione di ciò che succede (in poche parole affinchè si produca un log) e in alcuni casi io venga anche avvertita con un pop-up.
Quindi ho fatto caso che, appena acceso il pc, SERVICES chiedeva una connessione e su svariate porte. Questo è lo screenshot
htt*://img459.imageshack.us/my.php?image=udpeuproviderlocalhostun2.png
Allora sono andata prima nelle regole globali e ho visto che loopback (UDP e TCP e/u) era disabilitato; poi sono andata nelle regole delle applicazioni: a SERVICES gli avevo tolto la spunta, perchè non sapevo a cosa servisse (per ora ho tolto le spunte a tutte le applicazioni che non conosco o di cui voglio verificare le regole per poi, semmai, riabilitarle).
Quindi ho riabilitato SERVICES e ho visto che dentro ha una serie di regole preimpostate, tra cui il loopback, ecco lo screenshot (dai un'occhiata alle porte):
htt*://img227.imageshack.us/my.php?image=servicesudplocalhostyn1.png
A questo punto sono andata a vedere le regole di alcune applicazioni e molte di loro hanno spuntata (quindi abilitata) la funzione di loopback.
DEDUZIONE: Kaspersky non ha settato questa funzione nelle regole globali perchè le affida alle singole applicazioni e soltanto a quelle che la richiedono.
In Outpost, invece, la cosa è gestita in modo diverso: la regola globale vale per tutte le applicazioni, poi, se un'applicazione la deve usare bene, altrimenti semplicemente non la usa, ma la regola c'è ugualmente.
CONCLUSIONE: non ho ancora capito molto () perchè un'applicazione o il pc stesso, debba interfacciarsi con se stesso, mi sembra molto autoreferenziale la cosa... però ho capito, ed hai ragione, che è una funzione necessaria, in alcuni casi.
DUBBI: il range di quelle porte 1024-65535 mi sembra molto ampio. Inoltre ho letto da qualche parte che da un certo numero di porte fino alla 65535 sono porte molto vulnerabili (in teoria anche da bloccarsi). Però se ho compreso bene, qui si tratta non di aprire le porte ad un'applicazione esterna e quindi pericolosa, ma ad un'applicazione interna che semplicemente s'interfaccia con il pc stesso. Ho capito bene?
In seguito vediamo di affrontare anche il discorso (più rompicapo) del DNS Resolving, e forse qualche nuova idea ce l'ho, però devo spostarmi sulla partizione in cui ho xp e Outpost.
|
Modificato da - Diana in data 22/09/2007 12:57:48 |
|
|
|
pedrus
Moderatore
Città: Taranto - Pavia
952 Messaggi |
Inserito il - 22/09/2007 : 13:44:19
|
Citazione:
CONCLUSIONE: non ho ancora capito molto () perchè un'applicazione o il pc stesso, debba interfacciarsi con se stesso, mi sembra molto autoreferenziale la cosa... però ho capito, ed hai ragione, che è una funzione necessaria, in alcuni casi.
Esempio: sul tuo pc attivi un server web (in pratica come quelli dei siti a cui ti colleghi in Internet) e crei una pagina html che lasci sul tuo pc ospitata all'interno del server web. In pratica, così facendo è come se tu avessi creato un sito web a tutti gli effetti, ma sul tuo pc casalingo. Se io nel mio browser digito il tuo numero IP allora mi collego con il tuo sito (che come detto, è ospitato sul tuo pc), se tu nel tuo browser digiti 127.0.0.1 ti colleghi al tuo sito, così come faccio io, ma tu devi fare in quel modo perchè materialmente il server web si trova sul tuo pc, e quindi per navigare il sito da te creato, ti devi collegare a te stessa. Ed è qui che entra in gioco la loopback.
Altro esempio: sotto linux io uso un programma per ascoltare la musica che fa anche una sorta di organizzazione della collezione musicale in mio possesso, tanto per farti un'idea qui c'è uno screenshot htt*://[www].freefilehosting.net/show/MjM0Mzk= , se si vede troppo piccolo cliccaci sopra che si ingrandisce. Come vedi, sul lato sinistro della finestra ci sono alcune informazioni, la cover del CD, quante volte quel brano è stato ascoltato, l'elenco di altri brani simili in mio possesso, quando è stato ascoltato la prima volta, l'ultima volta, l'indice di gradimento. Per gestire quelle funzioni il programma permette di farlo in vari modi, fra cui quello di creare un database SQL che verrebbe creato al momento e aggiornato di volta in volta. Il database ovviamente si troverebbe sul mio pc e ogni volta che il programma deve cercare una canzone, deve visualizzare la cover del cd corrispondente o farmi visualizzare quelle informazioni, le dovrebbe ricavare dal database andandolo a interogare, così come in un database in rete. Ma essendo il database sul mio pc userebbe l'interfaccia di loopback.
Si possono fare decine di altri esempi, ma in ogni caso, alcuni processi o programmi fanno uso di quell'interfaccia in maniera del tutto trasparente all'utente, infatti l'utente neanche se ne accorge.
Il mio pc, acceso ininterrotamente da ieri, sull'interfaccia di loopback, fino ad ora ha prodotto questo traffico:
RX bytes:13279764 (12.6 MiB) TX bytes:13279764 (12.6 MiB)
Vuol dire che qualche processo per le sue funzioni si è servito di quell'interfaccia, 12.6 megabyte non sono tantissimi, ma sono una bella quantità che è indice del fatto che in qualche modo qualcosa ha sfruttato quell'interfaccia. Certo, linux e windows hanno funzionamenti profondamente diversi, magari sotto windows, facendo le stesse cose che faccio con linux il traffico su quell'interfaccia sarebbe forse profondamente diverso.
Citazione:
DUBBI: il range di quelle porte 1024-65535 mi sembra molto ampio. Inoltre ho letto da qualche parte che da un certo numero di porte fino alla 65535 sono porte molto vulnerabili (in teoria anche da bloccarsi). Però se ho compreso bene, qui si tratta non di aprire le porte ad un'applicazione esterna e quindi pericolosa, ma ad un'applicazione interna che semplicemente s'interfaccia con il pc stesso. Ho capito bene?
Non proprio. Allora, in linea di massima non sono le porte che sono vulnerabili, ma sono i processi che le utilizzano che possono esserlo, ecco perchè viene sempre consigliato di tenere il sistema e i software aggiornati, almeno per quanto riguarda gli aggiornamenti di sicurezza. Poi, una cosa sono le porte dell'interfaccia di rete, e un'altra cosa sono le porte dell'interfaccia di loopback. Entrambe le interfacce possono fare connessioni TCP e UDP sulle 65535 porte, ma sono comunque separate. Cioè, una connessione sulla porta, ad esempio, 800 della tua interfaccia di rete non corrisponde alla porta 800 dell'interfaccia di loopback. Cioè, due interfacce di rete dispongono per connessioni TCP e UDP ognuna di 65535 porte, quindi se vedi una connessione sulla loopback ad una determinata porta, non vuol dire che quella stessa porta sia aperta anche all'esterno, visto che per le connessioni esterne si usa un'altra interfaccia che quindi avrà a disposizione le sue porte. |
|
|
|
Diana
Advanced Member
269 Messaggi |
Inserito il - 22/09/2007 : 15:16:56
|
Citazione:
Messaggio inserito da pedrus
Esempio: sul tuo pc attivi un server web
Questo esempio è un SIGNOR ESEMPIO!!
Finalmente ho capito!!!
Anche l'esempio sul programma musicale mi è molto chiaro.
Tuttavia mi rimane un piccolo dubbio ancora (spero non mi menerai): perchè il mio browser, che uso soltanto per navigare in internet, usa il loopback? Forse perchè si deve interfacciare con un database, che so, di librerie ad esempio?
Citazione:
Messaggio inserito da pedrus
una cosa sono le porte dell'interfaccia di rete, e un'altra cosa sono le porte dell'interfaccia di loopback.
Ecco, questo non lo sapevo, ne avevo il vago sentore però... sto facendo progressi.
Citazione:
Messaggio inserito da pedrus
Entrambe le interfacce possono fare connessioni TCP e UDP sulle 65535 porte, ma sono comunque separate.
Anche quella di loopback può farle sia sulle UDP che sulle TCP?
Perchè, sia nella regola globale che in quella specifica per il browser (ad esempio), ho soltanto quella per il TCP.
Comunque, visto che mi stai spiegando già molte cose, e non vorrei spremerti come un limone, facciamo una cosa, ora carico in un sito gli screenshot dei quali necessiti e poi facciamo un'analisi su quello che sta succedendo.
Intanto ti dico che il loopback l'ho autorizzato, sia in globali che in applicazioni (solo browser per ora), e il pop-up per la richiesta di permesso non esce più, MENO MALE!
Quindi un problema è risolto.
|
|
|
|
pedrus
Moderatore
Città: Taranto - Pavia
952 Messaggi |
Inserito il - 22/09/2007 : 15:28:36
|
Citazione:
Tuttavia mi rimane un piccolo dubbio ancora (spero non mi menerai): perchè il mio browser, che uso soltanto per navigare in internet, usa il loopback?
Non dovrebbe utilizzare la loopback (e con questo non voglio dire che non deve), a meno che tu non abbia attivo qualche server web in locale e che, quindi si colleghi su localhost. Comunque, tramite browser sono tante le cose che si possono controllare. Esiste ad eesempio emuleweb, non è altro che emule che invece di controllarlo con la sua interfaccia grafica lo si può controllare tramite browser, quindi collegandosi su localhost. Nel tuo caso, se il tuo browser utilizza la loopback è perchè hai in esecuzione un qualcosa su localhost che può essere controllato da locale via browser. Per controllare certi flussi comunque ci sono dei programmi appositi, su windows a suo tempo esisteva ethereal, non so se c'è ancora. In pratica lo metti a "sniffare" il traffico su una interfaccia e lui mostra il log di ogni singolo pacchetto transitato, e lo mostra anche molto dettagliato. In pratica lo puoi mettere a sniffare l'interfaccia di loopback e vedere cosa esce, così capisci meglio quali sono i processi che stanno comunicando in locale.
Citazione:
Anche quella di loopback può farle sia sulle UDP che sulle TCP?
Perchè, sia nella regola globale che in quella specifica per il browser (ad esempio), ho soltanto quella per il TCP.
L'intefaccia di loopback la devi vedere come un'interfaccia di rete normalissima, alla pari di tutte le altre può trasmettere e ricevere dati con qualunque protocollo, ad esempio puoi anche fare un ping su 127.0.0.1, il ping sfrutta il protocollo ICMP.
Il fatto che tu hai impostato solo quello per il TCP non vuol dire che l'interfaccia di per se non conosca lo UDP, ma semplicemente non è stata impostata. |
|
|
|
Discussione |
|
|
|
Outpost e regole
Forum Bloccato
