In primis un saluto a tutti.
Questo è il mio primo giorno con COMODO e questo è il mio primo post qui sul forum!!
Sto cercando di configurare COMODO INTERNET SECURITY 3.8.65951.477 (solo il firewall), però qualcosa non mi torna…
Vorrei bloccare l’accesso a pro.getright.com (IP 64.184.186.212) a Getright.
Ho impostato il livello del firewall su CUSTOM POLICY MODE e settato su VERY HIGH l’alert settings.
Ho inoltre controllato che nella NETWORK SECURITY POLICY non ci siano regole associate a getright…
In questo modo, corregetemi se sbaglio, ho modo di controllare e di impostare a piacere le regole per l’applicativo in questione.
Fatto questo apro Getright e CIS mi chiede l’autorizzzione per il DNS, e io la concedo. Controllo ed effettivamente è stata aggiunta la regola corretta.
Ora se provo a vedere tramite Getright se sono disponibili aggiornamenti, CIS non si accorge di nulla e quindi non blocca nulla. Non solo, ma se provo con il Getright browser ad accedere ad un qualunque sito (www.adobe.com ad esempio) CIS mi lascia passare senza nessun problema, nononstante l’unica regola impostata sia quella per il solo DNS (53:UDP)
Usando TCPView ho notato che Getright passa attraverso il NOD (ekern.exe:30606), cui ovviamente è consentito il traffico http, ed è quest’ultimo che accede a 64.184.186.212:http.
Fatta questa premessa, mi chiedo: CIS dove interviene? A livello di singola applicazione, e quindi si tratta di un bug o di una mia errata configurazione, o a livello di rete per cui CIS vede solo che ekern.exe tenta di collegarsi esternamente e non sa nulla di più sull’applicazione che sta a monte?
Spero di essere stato chiaro, anche se forse un po’ prolisso…
Grazie a tutti!
Qualche dettaglio tecnico.
NOD32 4.0.424
CIS 3.8.65951.477
Win XP Pro SP3 32bit
LAN + Router
o a livello di rete per cui CIS vede solo che ekern.exe tenta di collegarsi esternamente e non sa nulla di più sull'applicazione che sta a monte?
Ma questo Getright è installato sullo stesso PC dove è installato CIS?
Da quello che ho capito dovrebbe essere così …
E se è così il problema sta nel fatto che non hai creato una regola che blocchi l’indirizzo IP in questione.
In questo modo, correggetemi se sbaglio, ho modo di controllare e di impostare a piacere le regole per l'applicativo in questione.
Certo, ma se non imposti una regola di blocco, CIS non è una Sibilla e quindi, se autorizzi l’accesso al DNS e successivamente autorizzi una connessione TCP o UDP, per CIS significa che a te va bene così…
A meno che non crei ulteriori regole in NETWORK SECURITY POLICY.
Ho fatto una prova e, prima di permettere l’accesso di getright a Internet, CIS chiede l’autorizzazione.
Se tu permetti l’accesso, dopo devi pure creare delle regole, altrimenti come pretendi che CIS riconosca cosa deve bloccare o meno?
l’ultimo Nod32 che ho provato è il 2.70.39 e non conosco la v4, comunque curiosando ho letto che le ultime versioni dell’antivirus utilizzano una sorta di WebGuard (come quello di Avira Antivir Premium) che controlla le connessioni sulla porta 80, questo per proteggerci dai virus zero day.
Praticamente con questa funzione attiva (purtroppo non so come si chiama nel Nod32) le connessioni sulla porta 80 (non so se controlla altre porte) di qualsiasi applicazione, avvengono tramite il processo ekern.exe e CIS non le blocca perché è un processo fidato e perchè comunque tu hai una regola nelle Application Rules.
Per evitare, anzi meglio, per capire quale applicazione vuole connettersi e quindi per avere la richiesta da parte del firewall per qualsiasi programma che volesse trasmettere dati, ti consiglio di disabilitare tale funzione nel Nod32.
Avevo promesso ad un amico di mettere questa spiegazione nella guida… l’avevo dimenticato, cercherò di rimediare al più presto.
Se dovesse essere così, si può risolvere ugualmente creando una regola di blocco di qualsiasi IP si voglia bloccare, senza il bisogno di disinstallare la funzione, aggiungendola nelle Global Rules e, se è il caso, anche nelle Application Rules.
Io capisco che a volte nei forum ci sono domande un po’ strane, fatte da chi non ne sa proprio nulla, ma il dubbio se le due applicazioni siano installate sullo stesso PC, mi pare un po’ eccessivo.
E se è così il problema sta nel fatto che non hai creato una regola che blocchi l'indirizzo IP in questione.
A dire il vero tutto è nato proprio da questo. Io la regola l'avevo creata, ma visto che non c'era nessun rule match nel log del firewall, ho cominciato ad indagare questo strano comportamento...
Certo, ma se non imposti una regola di blocco, CIS non è una Sibilla e quindi, se autorizzi l'accesso al DNS e successivamente autorizzi una connessione TCP o UDP, per CIS significa che a te va bene così...
A meno che non crei ulteriori regole in NETWORK SECURITY POLICY.
Non pretendo certo che CIS sia una Sibilla, ma l'unica autorizzazione che concedo è per una connessione al DNS e non ne concedo altre, di nessun tipo, così come ho scritto nel mio post iniziale. Per essere più chiari CIS non mi chiede nessun tipo di autorizzazione per il traffico TCP o UDP, cosa che invece dovrebbe fare...
Se tu permetti l'accesso, dopo devi pure creare delle regole, altrimenti come pretendi che CIS riconosca cosa deve bloccare o meno?
Vedi sopra.
In buona sostanza, al momento Getright riesce ad effettuare connessioni senza che io abbia concesso una specifica autorizzazione e senza che CIS segnali la cosa.
Il post di sirio, ha chiarito la cosa. In effetti è bastato disabilitare momentaneamente il controllo HTTP di NOD e ora CIS si accorge del traffico TCP sull’ IP 64.184.186.212.
La questione sta esattamente in questi termini.
Tuttavia la soluzione che proponi, non è la più indicata, IMHO.
Bloccare l’IP nelle global rules o aggiungere una regola per ekern.exe, significa in definitiva bloccare a qualunque applicazione l’accesso all’IP in questione. Se avessi voluto fare questo avrei aggiunto una riga nel file HOST e avrei risolto in un attimo.
Io vorrei bloccare quell’IP per un applicativo (nel caso specifico Getright), e al tempo stesso poter accedere allo stesso IP con un altro (ad esempio un browser per controllare eventuali aggiornamenti).
A mio avviso, come suggeriva sirio, è il caso di specificare nella guida questo dettaglio, e trovare un modo per risolvere definitivamente il problema.
Per te che sai come è la situazione dei tuoi computer, potrà essere “eccessivo”;
per chi cerca di rispondere, invece, in base a quello che hai indicato, non lo è proprio.
Fatto sta che non hai specificato da nessuna parte, sul tuo post, se CIS e Getright e Nod siano installati sullo stesso PC, anzi, hai contribuito a rendere la cosa ancora più confusa, specificando proprio che hai una rete.
Una rete è composta da più computer, ognuno dei quali ha installato cose non necessariamente uguali.
Quindi, per illustrare il problema nel modo più chiaro possibile, avresti dovuto specificare che le due applicazioni risiedono sullo stesso PC e che il problema lo ha un PC e non la rete.
Dimmi dove, nel tuo post, si evince che i due software sono installati sullo stesso computer …
A dire il vero tutto è nato proprio da questo. Io la regola l'avevo creata, ma visto che non c'era nessun rule match nel log del firewall, ho cominciato ad indagare questo strano comportamento...
Sarebbe il caso di allegare immagini dettagliate sia delle tue “Application Rules” che delle “Global Rules”.
Non si può rispondere adeguatamente, nel caso specifico, se questo non viene fatto.
Tutto il resto che ne deriva, sono inutili e fuorvianti chiacchiere per gli utenti che leggono il post.
Sei quindi invitato ad attenerti, visto che finora non lo hai fatto, a quanto indicato in:
Attenzione: Come Postare Correttamente un Messaggio sul Forum:
- Oltre a quanto sopra indicato, può essere di molto aiuto allegare un'immagine (screenshot) relativa alla chiarificazione del problema, come per esempio i processi del task manager o le regole delle applicazioni (Application Rules)/regole globali (Global Rules) o il log del firewall o qualsiasi altra immagine che possa aiutare a capire il problema.
Non pretendo certo che CIS sia una Sibilla, ma l'unica autorizzazione che concedo è per una connessione al DNS e non ne concedo altre, di nessun tipo, così come ho scritto nel mio post iniziale. Per essere più chiari CIS non mi chiede nessun tipo di autorizzazione per il traffico TCP o UDP, cosa che invece dovrebbe fare...
Io credo invece che, impostato nella maniera corretta, lo faccia…
Probabilmente non lo hai impostato bene.
Ripeto che l’ausilio delle immagini sia il modo più opportuno per centrare il problema.
In buona sostanza, al momento Getright riesce ad effettuare connessioni senza che io abbia concesso una specifica autorizzazione e senza che CIS segnali la cosa.
Inserendo una regola “Ask” o “Block”, CIS invece “Chiede” o “Blocca”.
Tutt’è sapere “dove” mettere la regola.
Non si può avere tutta la pappa pronta senza un minimo di sforzo e di ricerca.
Il post di [b]sirio[/b], ha chiarito la cosa. In effetti è bastato disabilitare momentaneamente il controllo HTTP di NOD e ora CIS si accorge del traffico TCP sull' IP 64.184.186.212.
Con tutto il rispetto per la risposta di sirio, quella è una soluzione (parziale), non l’unica soluzione possibile.
Se esistono utenti che vogliono usare quella funzione del NOD, perchè la dovrebbero disabilitare quando è anche possibile mantenerla attiva e, allo stesso tempo, far bloccare/chiedere a CIS quello che serve?
Ma hai già provato ad inserire una regola di blocco per Getright nelle “Application Rules”?
Se avessi voluto fare questo avrei aggiunto una riga nel file HOST e avrei risolto in un attimo
Se è per questo non c’è bisogno di scomodarsi tanto. Basterebbe aggiungere il numero o il range nella funzione “My Blocked Networks” di CIS.
Io vorrei bloccare quell'IP per un applicativo (nel caso specifico Getright), e al tempo stesso poter accedere allo stesso IP con un altro (ad esempio un browser per controllare eventuali aggiornamenti).
A mio avviso, come suggeriva [b]sirio[/b], è il caso di specificare nella guida questo dettaglio, e trovare un modo per risolvere definitivamente il problema.
Ripeto la domanda … Ma hai già provato ad inserire una regola di blocco per Getright nelle “Application Rules”?
Dovresti impostare il log event per tutte le applicazioni e tutti gli eventi coinvolti nel problema (compreso “ekrn.exe”), ed anche creare una regola block and log any IP finale (in “ekrn.exe” con il log event attivato), ed una regola “ask any IP” in getright, come seconda regola (tutte con il log event attivo) e togliendo le altre “allow”.
Quindi ricreare la condizione in esame e postare anche il contenuto del log.
Ma la regola di blocco di getright l’hai aggiunta adesso o era già presente al momento del problema? ???
La regola su Getright c’è da quando sono stato sicuro di averla impostata correttamente, quindi da prima che iniziassi questo topic… prima di scrivere qui ho controllato di non aver fatto un errore stupido…
L’avevo impostata a mano configurando CIS subito dopo l’installazione, ma non funzionava, così l’ho rimossa pensando di aver sbagliato qualcosa; allora ho controllato su alcune guide online, e una volta certo di aver fatto la cosa giusta, l’ho rimessa ed è sempre rimasta. Il fatto è che non viene mai applicata perchè per CIS è ekern.exe che accede all’indirizzo IP 64.184.186.212.
Allego gli screen con le application rule e i log del firewall.
Come si può capire dal log le regole di Getright che riguradano il DNS, si sono aggiunte simulando il tutto. Lo stesso vale per le prime due regole per ekern.exe.
Ho inoltre provato a collegarmi tramite il browser di Getright a www.adobe.com per vedere il directory listing.
Come si vede nel log il traffico TCP di Getright è inesistente per CIS, mentre invece viene loggato il traffico di ekern.exe
Ho fatto delle prove installando il NOD, ed il problema non è dovuto a CIS ma, in effetti, al modo con cui vengono gestite le connessioni dal nuovo NOD 4 con il “Web Access Protection”.
La funzione del NOD s’intromette (in modo abbastanza invadente) nell’intercettazione delle connessioni tra CIS e le applicazioni, convogliandole verso l’eseguibile ekrn.exe, ed impedendo a CIS di filtrare capillarmente.
Ricordiamoci che questo NOD4 con la funzione “Web Access Protection” è uscito successivamente al CIS, e quindi ai suoi sviluppatori è stato possibile studiare un modo per interporsi o scavalcare CIS
Il problema illustrato, comunque, si può ovviare (lasciando la funzione NOD attiva) cancellando tutte le regole presenti in Getright.exe, e inserendo un’unica regola “Ask”:
Bisognerà poi ricordarsi di rispondere agli avvisi di CIS per il getright senza il remember.
L’unico accorgimento da adottare per impedire che Getright acceda anche ad altre connessioni non richieste dopo la prima autorizzazione è quello di chiudere l’applicazione subito dopo che ha eseguito un download e riavviarla qualora necessario;
in questo modo, se getright tenterà di accedere ad un IP non richiesto, CIS mostrerà di nuovo un avviso.
Questo vale anche per il contrario cioè, se si è dato inizialmente un blocco all’applicazione, bisogna chiuderla e riavviarla, per farla accedere dove serve.
Se invece si lascerà l’applicazione in esecuzione, il primo permesso di accesso o di blocco sarà considerato valido anche per i successivi tentativi di connessione di getright, che avverranno o non avverranno senza ulteriori avvisi.
Devo convenire che se si vuole che CIS faccia bene il suo lavoro, questa funzione “Web Access Protection” è meglio disabilitarla. :-\
Sono contento di leggere che non si è trattato di una mia distrazione o di una mia errata configurazione del CIS. Come hai potuto verificare l’unica soluzione davvero efficicace è quella di disabilitare la funzione nel NOD.
Detto questo bisogna che gli sviluppatori di CIS trovino a mio avviso un rimedio. COMODO IS e NOD32 sono certamente due applicativi largamente diffusi e, salvo non ne nasca un problema di compatibilità, devono poter coabitare senza problemi. Come diceva sirio, cosa che però non ho sperimentato personalmente, anche AVIRA sta adottando lo stesso sistema di web filtering, e anche in qusto caso si tratta di un AV che sta crescendo parecchio.
Sono d’accordo sul fatto che la funzione sul NOD sia stata sviluppata successivamente al CIS, quindi gli sviluppatori di ESET erano per così dire avvantaggiati, ma il fatto resta nella sua pericolosità.
Se vogliamo dirla in modo diverso io ho preso il firewall che ha ottenuto i migliori risultati nelle ultime prove comparative, uno degli antivirus che da tempo sono riconosciuti come ADVANDCED+ nei test specifici e li ho messi a lavorare insieme. Il firewall però non riesce a filtrare efficacemente il traffico e dal mio punto di vista questo è un problema piuttosto importante, cui occorre trovare rimedio al più presto.
Nel caso specifico si è trattato di un applicativo sicuro (Getright), ma sarebbe potuta accadere la stessa cosa anche per altre applicazioni molto meno gradite, e per di più ho notato la cosa perchè ho impostato manulmente CIS e poi ne ho verificato il funzionamento. In qualunque altro modo non mi sarei mai accorto di nulla.
Ora mi domando e ti domando se vale la pena segnalare la cosa a chi di dovere, fatto salvo che non sia già stata messa in luce da qualche altro utente.
Mi dispiace di aver in qualche modo denigrato la risposta più che valida di sirio ed anche sottovalutato la tua segnalazione ma, in genere, l’esperienza mi ha insegnato di fare sempre come San Tommaso, ossia verificare di persona e quindi, non ho potuto fare altro che constatare il problema ed ora ne rendo atto a voi.
Il problema però, secondo me, non sta tanto nel fatto di segnalarlo (non saprei se gli sviluppatori ne siano già a conoscenza), il che ci vuole poco.
Quanto, credo, al fatto che risieda di più nella politica stabilita dalla dirigenza di Comodo, ad essere disposta nello stravolgimento di un software per adattarlo ad un altro, ossia: dovrebbe essere Comodo a fare delle pesanti modifiche software per adattarsi al NOD o viceversa?
Questo lo dico perchè essendo uscito l’ultimo NOD successivamente a CIS, gli sviluppatori del NOD potevano anche tenere conto di queste incompatibilità, ma hanno scelto la strada, secondo me egoista, della gestione “esclusiva”, per tagliare fuori tutta la concorrenza, il che certo non giova all’utente finale.
Ciò non toglie che la segnalazione andrebbe fatta e che magari le mie sono solo illazioni. Il futuro ce lo dirà
yeiazel nessun problema!
99/100 ad essere come S. Tommaso si scopre che malfunzionamenti e/o problemi di varia natura sono in definitiva bolle di sapone. L’importante è stato evidenziare nel modo più chiaro possibile la questione, in modo che anche altri utenti possano esserne informati.
Mi rendo perfettamente conto che per gli sviluppatori di Comodo sistemare questa faccenda, rappresenti un impegno non indifferente che potrebbe scontrarsi con le strategie di sviluppo adottate, ma credo vada almeno segnalato questo dettaglio durante l’installazione di CIS, in modo che gli utenti possano decidere consapevolmente se preferiscono “dare precedenza” al firewall o all’antivirus. Ovviamente lo stesso tipo di attenzione dovrebbe metterlo anche ESET segnalandolo opportunamente in fase di installazione.
Al di là del caso specifico, nell’ipotesi che anche AVIRA, come forse altri AV, stiano seguendo questo tipo di strada, occorre da parte di Comodo una riflessione seria a rigurado; riflessione che in questo caso non sarebbe più specifica al caso in questione, ma assolutamente strategica e di lungo periodo.
Sono pienamente d’accordo con te sulla scelta arbitraria fatta da ESET sulla gestione esclusiva del traffico. Di certo non aiuta l’utente finale e non fa altro che creare inutile confusione. Una delle ragioni di questo atteggiamento da parte di ESET, e forse di altri, potrebbe essere nella forte spinta che si vuole dare alle Security Suite, dove evidentemente il problema viene risolto alla radice. Peccato che al momento, non ci siano prodotti in grado di conuigare efficacia, semplicità d’uso, modeste risorse di sistema impiegate e stabilità operativa.
Per quanto rigurada la segnalazione, sono d’accordo con te, credo sia utile farla, sarà poi il pool di sviluppatori a decidere il da farsi. Come è possibile farlo? Me ne occupo io o tu, in quanto moderatore, hai un “accesso preferenziale”?
Intanto grazie della pazienza e per aver fatto un po’ di prove per testare personalmente il problema!
Io credo che, in finale, ognuna delle aziende voglia tirare l’acqua al proprio mulino, ossia cercare il più possibile di indurre l’utente all’uso di una sola suite ed a stabilire un rapporto di dipendenza esclusivo e quindi, anche economico.
Solamente che Comodo, a differenza di altri, offre un ottimo prodotto di base gratuitamente, (cosa che la concorrenza, riguardo le suite di sicurezza, non fa) e potrebbe permettersi di ignorare gli altri (ma credo che non lo faccia).
Sono d’accordo con te che il prestigio e l’apertura di una software house al mondo circostante, alla lunga, paga e gli utenti smaliziati sanno apprezzare e quindi premiare chi ha scelto in tal senso, senza obbligarli ad un vincolo di tipo economico e quindi di sfruttamento.
Per quanto riguarda la segnalazione, sono d'accordo con te, credo sia utile farla, sarà poi il pool di sviluppatori a decidere il da farsi. Come è possibile farlo? Me ne occupo io o tu, in quanto moderatore, hai un "accesso preferenziale"?
Credo che se poni loro la questione nella giusta maniera non fa differenza. Lo scopritore sei stato tu, quindi procedi pure
Cmq per me non dipende da CIS che fa il suo lavoro egregiamente ma da una funzione degli AV che andrebbe messa in evidenza da loro stessi spiegando bene quello che fa.
Appena mi sarà possibile segnalerò quanto emerso a COMODO e alla ESET in modo che entrambe queste software house prendano i necessari provvedimenti, se lo ritengono opportuno.
Per il problema da cui siamo partiti, bloccare a Getright uno specifico IP, ho trovato una soluzione, efficace, anche se un po’ macchinosa, per mantenere attiva la protezione dell’antivirus e permettere al firewall di agire correttamente.
Ecco come fare:
Impostare nel NOD la funzione di Protocol Filtering su Ports and application marked as Internet browsers or email clients
Aggiungere, se non già presente, l’eseguibile da non filtrare, nel mio caso getright.exe, tra i Browser da monitorare. (La voce Web browsers nel setup di NOD)
Escludere il controllo dell’AV cliccando 2 volte sul quadratino accanto all’applicazione appena inserita. Comparirà una crocetta rossa, all’interno del quadratino, per segnalare che il NOD non controllerà il traffico di quell’applicazione.
Ora il firewall funziona e riconosce il traffico TCP perfettamente.
Questa soluzione, che in effeti è solo un blando rimedio, non diminuisce la pericolosità di tutta questa faccenda. Infatti è stato possibile intervenire solo perchè ero a conoscenza dell’applicativo su cui intervenire e quindi ho potuto rimediare. In caso di software indesiderati installati a mia insaputa non avrei potuto fare nulla.
Oltre a questo credo che la maggior parte degli utenti non si preocupi minimamente di personalizzare l’antivirus e/o il firewall, ma si accontenti delle impostazioni predefinite perchè non ne vede la necessità o non ha le competenze per farlo. Nonostante questo sia NOD che COMODO si propongono come programmi di largo consumo, mettendo potenzialmente a rischio numerosi utenti.
