nV 25
21-02-2005, 14:24
un pò di chiarezza su alcuni aspetti di L'n'S che lo rendono cosi' ermetico per i meno pratici ( tra cui mi colloco di diritto anch'io :( ....nessuno, infatti, nasce imparato! :D )
1) consultando la guida in linea della scheda internet filtering, si nota chiaramente questo discorso (anche se non troppo enfatizzato).... :
Le regole sono applicate NELL'ORDINE in cui sono visualizzate nella apposita schermata.
Pertanto, se un pacchetto con determinate caratteristiche dovesse incontrare una specifica regola posta ad un certo livello della sezione internet filtering, questo verrebbe automaticamente "interpretato" senza dover far intervenire successivamente regole immediatamente a valle preposte all'intercettazione di altri aspetti del flusso dati.
Ne discende la necessità di capire la logica sottostante la disposizione delle regole, che quindi non può essere arbitraria.
Lo schema generale vuole che la disposizione delle regole segua questa precisa architettura: regole per il protocollo IP, a seguire quelle per il TCP, UDP, ICMP, IGMP.
Detto questo, fondamentale è allora capire il ruolo rivestito dalla seguente regola: TCP:block incoming connection, vero spartiacque tra le regole che identificano il nostro PC come server o solo come client.
http://img226.exs.cx/img226/7444/a14py.jpg
il motivo è semplice:
la regola è impostata in modo tale da funzionare come "ASSORBENTE" di tutti i pacchetti che hanno il SYN-FLAG attivo (quelli inviati ad es da un qualsiasi PC client quando vuole iniziare una comunicazione), IMPEDENDO cosi' l'invio di una risposta ( da parte del NOSTRO terminale, assimilabile in questo caso ad un server) caratterizzata da un FLAG SYN-ACK, che è condizione necessaria perchè a seguito della prima sollecitazione (il pacchetto con SYN-FLAG attivo), il PC remoto completi la connessione chiudendo il ciclo (attraverso l'invio di pacchetti ACK).
Eccellente in proposito lo schema sotto:
http://img234.exs.cx/img234/5448/45lp.jpg
OK, ma perchè tutti questi discorsi? che c'incastrano con L'n'S?
Semplice, se ad es si vanno a scaricare le apposite regole per es di emule, si vede che queste sono costituite da 3 parti, 2 relative al protocollo TCP e 1 che riguarda il Protocollo UDP.
Queste, di default, vengono collocate in cima alla lista , ma devono poi essere riposizionate correttamente nella scheda internet filtering!
Pertanto, mentre la SOLA regola di emule ( che è quella che consente agli altri di instaurare una conness con il ns PC) :
http://img231.exs.cx/img231/7866/59ey.jpg
va posta, per i ragionamenti fatti, sopra la TCP:Block...., le altre, viceversa, vanno poste al di sotto, facendo attenzione peraltro a posizionare quella definita per il protocollo UDP nella sua apposita zona.
2) Se si abilita il meccanismo TCP: Stateful Packet Inspection e si utilizzano programmi di P2P (eMule in primis) si presenta il seguente problema:
la navigazione viene fortemente rallentata (al limite impedita del tutto) dopo diverse ore di connessione, e il Log è inondato letteralmente di avvisi TCP stateful packet inspection....
La causa: un problema intrinseco nell'attuale revision (2.05) di L'n'S, che non è capace di gestire più di 128 connessioni TCP con l'SPI attivo :( ...
Soluzione:
a) disabilitare la funzionalità SPI quando si usano software P2P (sconsigliata)
b) limitare il n° delle connessioni massime direttamente intervenendo sui settaggi di eMule ( in modo tale che siano minori delle 128 massime gestibili dal FW, ad es settando il valore max @ 100.....)
NDR: ho saputo proprio pochi min fà da fonte attendibile (uno dei programmatori) che presto verrà rilasciato un'aggiornamento per risolvere proprio questo bug...:D :sperem:
3) differenze tra l'Application filtering & l'Internet filtering.
L'n'S prevede 2 livelli di filtraggio, il 1° offerto dall'internet filtering è di basso livello nel senso che opera SIA nel momento in cui i dati entrino nel pc SIA nel momento in cui questi si apprestino ad uscire, pertanto il controllo effettuato sui pacchetti è nelle 2 direzioni ( outbound/inbound).
L'application filtering opera invece ad un livello più alto e entra in funzione SOLO nel momento in cui un'applicazione spedisca dati verso l'esterno.
Il flusso di dati in uscita subisce dunque un duplice controllo; pertanto, anche se questi avessero l'autorizzazione ad uscire (concessa dalle regole presenti nella scheda application filtering), prima di essere effettivamente spediti verso l'esterno i pacchetti di dati devono essere autorizzati anche dalle regole di + basso livello CHE HANNO LA PRIORITA' sulle regole nella sezione filtraggio applicazioni.
Ovviamente questa non è una guida di L'n'S, ma solo alcuni pensieri che mi piaceva condividere.....
Un grazie sincero a WinCenzo (P2P Forum italia) per il suo prezioso contributo.
1) consultando la guida in linea della scheda internet filtering, si nota chiaramente questo discorso (anche se non troppo enfatizzato).... :
Le regole sono applicate NELL'ORDINE in cui sono visualizzate nella apposita schermata.
Pertanto, se un pacchetto con determinate caratteristiche dovesse incontrare una specifica regola posta ad un certo livello della sezione internet filtering, questo verrebbe automaticamente "interpretato" senza dover far intervenire successivamente regole immediatamente a valle preposte all'intercettazione di altri aspetti del flusso dati.
Ne discende la necessità di capire la logica sottostante la disposizione delle regole, che quindi non può essere arbitraria.
Lo schema generale vuole che la disposizione delle regole segua questa precisa architettura: regole per il protocollo IP, a seguire quelle per il TCP, UDP, ICMP, IGMP.
Detto questo, fondamentale è allora capire il ruolo rivestito dalla seguente regola: TCP:block incoming connection, vero spartiacque tra le regole che identificano il nostro PC come server o solo come client.
http://img226.exs.cx/img226/7444/a14py.jpg
il motivo è semplice:
la regola è impostata in modo tale da funzionare come "ASSORBENTE" di tutti i pacchetti che hanno il SYN-FLAG attivo (quelli inviati ad es da un qualsiasi PC client quando vuole iniziare una comunicazione), IMPEDENDO cosi' l'invio di una risposta ( da parte del NOSTRO terminale, assimilabile in questo caso ad un server) caratterizzata da un FLAG SYN-ACK, che è condizione necessaria perchè a seguito della prima sollecitazione (il pacchetto con SYN-FLAG attivo), il PC remoto completi la connessione chiudendo il ciclo (attraverso l'invio di pacchetti ACK).
Eccellente in proposito lo schema sotto:
http://img234.exs.cx/img234/5448/45lp.jpg
OK, ma perchè tutti questi discorsi? che c'incastrano con L'n'S?
Semplice, se ad es si vanno a scaricare le apposite regole per es di emule, si vede che queste sono costituite da 3 parti, 2 relative al protocollo TCP e 1 che riguarda il Protocollo UDP.
Queste, di default, vengono collocate in cima alla lista , ma devono poi essere riposizionate correttamente nella scheda internet filtering!
Pertanto, mentre la SOLA regola di emule ( che è quella che consente agli altri di instaurare una conness con il ns PC) :
http://img231.exs.cx/img231/7866/59ey.jpg
va posta, per i ragionamenti fatti, sopra la TCP:Block...., le altre, viceversa, vanno poste al di sotto, facendo attenzione peraltro a posizionare quella definita per il protocollo UDP nella sua apposita zona.
2) Se si abilita il meccanismo TCP: Stateful Packet Inspection e si utilizzano programmi di P2P (eMule in primis) si presenta il seguente problema:
la navigazione viene fortemente rallentata (al limite impedita del tutto) dopo diverse ore di connessione, e il Log è inondato letteralmente di avvisi TCP stateful packet inspection....
La causa: un problema intrinseco nell'attuale revision (2.05) di L'n'S, che non è capace di gestire più di 128 connessioni TCP con l'SPI attivo :( ...
Soluzione:
a) disabilitare la funzionalità SPI quando si usano software P2P (sconsigliata)
b) limitare il n° delle connessioni massime direttamente intervenendo sui settaggi di eMule ( in modo tale che siano minori delle 128 massime gestibili dal FW, ad es settando il valore max @ 100.....)
NDR: ho saputo proprio pochi min fà da fonte attendibile (uno dei programmatori) che presto verrà rilasciato un'aggiornamento per risolvere proprio questo bug...:D :sperem:
3) differenze tra l'Application filtering & l'Internet filtering.
L'n'S prevede 2 livelli di filtraggio, il 1° offerto dall'internet filtering è di basso livello nel senso che opera SIA nel momento in cui i dati entrino nel pc SIA nel momento in cui questi si apprestino ad uscire, pertanto il controllo effettuato sui pacchetti è nelle 2 direzioni ( outbound/inbound).
L'application filtering opera invece ad un livello più alto e entra in funzione SOLO nel momento in cui un'applicazione spedisca dati verso l'esterno.
Il flusso di dati in uscita subisce dunque un duplice controllo; pertanto, anche se questi avessero l'autorizzazione ad uscire (concessa dalle regole presenti nella scheda application filtering), prima di essere effettivamente spediti verso l'esterno i pacchetti di dati devono essere autorizzati anche dalle regole di + basso livello CHE HANNO LA PRIORITA' sulle regole nella sezione filtraggio applicazioni.
Ovviamente questa non è una guida di L'n'S, ma solo alcuni pensieri che mi piaceva condividere.....
Un grazie sincero a WinCenzo (P2P Forum italia) per il suo prezioso contributo.