[Ciaba]

Originariamente inviato da frank10

Ecco, vedi. Se riuscivo a leggere prima la tua guida non avrei aperto quel thread... hehe

Grazie della guida: era esattamente il mio problema con il system e il svchost.
Solo che io ho in più questo: ho dovuto creare una regola per impedire 'send datagrams' col svchost. E anche per il 'receive datagrams'... Si possono unificare in una sola?

Ma cosa sono questi datagrams? E anche quelle porte 135-139? E il system? Mah.

Un osservazione all'ottima guida: per il Firefox si potrebbe evitare di creare manualmente le regole che hai descritto, mettendo sul Verdict 'Web Browser' invece che allow per ogni richiesta. E aggiungere sotto la reject shild.

E un'altra osservazione: invece che accettare tutte le richieste quando si installano molti programmi per poi cancellarle tutte, si potrebbe disattivare il FW temporaneamente e poi riattivarlo dopo le installazioni.

Comunque mooolti complimenti per questa guida! Grazie mille

Devo ancora capire cos'altro c'è nella mia configurazione che mi succhia quei pochi KB: come posso fare per sapere quali porte o processi spediscono questi pacchetti?
Perché il FW non rileva niente di anomalo e perciò il log non segnal nulla. Tieni presente che tengo aperto solo il TIM Data Kit che serve per la connessione e nient'altro proprio per capire cosa succede.

Un ultima considerazione su Jetico: ECCEZIONALE. Mi piace tantissimo e puoi agire su tutto. Lo consiglio a tutti anche se capisco che qualcuno potrebbe un po' perdersi, ma con questa guida si ritroverà

...intanto ti ringrazio e sono felice nel vedere che a qualcuno torna utile
Poi, veniamo alle cose "tecniche":

-i datagrams(o datagrammi), sono semplicemente i "famosi" pacchetti di trasmissione dei dati. Il protocollo IP cioé nn invia(a volte??...sempre??), in rete flussi di dati continui ma sequenze di binari spezzettate e raggruppate in pacchetti appunto...di più nn so'.
Riguardo al svchost ad essi collegato va fatta una distinzione in base alle porte che esso utilizza e al tipo di svchost che è. Cioè per capirsi,...svchost nn è un servizio ma un contenitore di servizi(spero che con Windows Vista l'abbiano cambiato perché per me è una cosa assurda), infatti con appositi programmi si può andare a vedere quali reali servizi si nascondano sotto tale generico nome e in base a tali informazioni capire meglio cosa far passare e cosa no. Come settaggio base però considera che l'invio di datagrams su porta specifica(53) è necessario per li aggiornamenti di Windows quindi crea una regola appositamente per quello.
Riguardo al receive datagrams nn so che dirti, nn mi è mai capitato. Potrebbe èssere quindi un servizio legato al tipo di connessione o a servizi che hai abilitati. Se scopri il tipo di servizio scopri anche come monitorarlo e creare regole appositamente per esso. Quindi in definitiva direi di no a una regola unificata per i datagrams...in quanto credo siano fenomeni di eventi profondamente diversi.

-le porte: in verità su una pianificazione firewall arebbe di norma bloccato tutto il traffico dalla 124 alla 136(in quanto nn sono porte normalmente utilizzate), e solo monitorate le porte 137-139(netbios),...però è questo un lavoro che i moderni firewall svolgono in maniera eccellente in quanto bloccano tutto eccetto quello che si permette tramite le regole. In questo senso a noi serve solo regolarizzare svchost sulla 135 e la 139(raramente la 138), quindi dato che siamo di strada si fa una regola unica dalla minima che utilizza(135), alla massima(139). Niente di scientifico

-Osservazione su Firefox: ok, però stai attento che moltissimi siti(o finti tali), cercano ci comunicare con porte che nn sono quelle canoniche(e abbastanza sicure), utilizzate da un browser. Per rendersene conto basta fare le regole come suggerisco io senza fare la regola Shild e poi andare a farsi una bella navigata in solitario per il mare della rete. Personalmente quindi preferisco avere regole specifiche, ma la mia è solo un'indicazione, ognuno può provare a fare come meglio ritiene giusto anche in base alle esigenze e alla macchina che ha


-L'osservazione sulla creazione e cancellazione delle regole: anche qui un appunto me lo permetto. Solitamente a controllare la bontà di quello che si scarica ci pensa il guard dell'antivirus(se è un antivirus degno di tale nome), però, se ci si trovasse di fronte a eseguibili rimanipolati ad arte, è proprio al momento dell'installazione che ci si può accorgere della loro presenza grazie a Jetico. Infatti la finestra di controllo ProcessAttackTable racchiude quelli eventi che partono da un eseguibile e ne attivano un altro o cercano, tramite i meccanismi di Windows, di raggiungere servizi o eseguibili secondari. Senza Jetico attivo queste meccaniche vanno in automatico senza che l'utente si accorga di niente...ma cosa succede se si tratta di virus o troyan che cercano di insinuarsi in altri programmi o prendere possesso di particolari settori di essi??
Non solo, pensa a quando si aggiorna da MSUpdate...con il Pc in rete disattivare il firewall è praticamente un suicidio a scopo di suicidio( ), e durante l'aggiornamento di Win ci sono 2 richieste di regola per ogni pacchetto da scaricare-installare, se si danno regole temporali invece il numero diventa esponenziale in quanto vengono monitorati i singoli pacchetti di ogni download costringendo all'assenso temporaneo ad ognuno...una palla.


-Riguardo ai Kb persi nn so che dirti, potrebbe èssere qualsiasi cosa...anche il servizio di aggiornamento di win per esempio(ma avrò di sicuro detto una vaccata). Cmq con ProcessEplorer della Sysinternals puoi monitorare processo per processo quante risorse occupa e per quale scopo comunica(listening, send, etc etc), mi raccomando però con Jetico dagli accesso alla rete perché per fare questo lavoro usa il LocalHost.
Se nn ti basta e vuoi qualcosa di più specifico prova a chiedere a Wgator che lui su queste cose sa un ballino di roba, potrebbe darti una dritta in merito.

Fine papiro della XII dinastia