windows operating system e system

In entrata le regole globali sono le prime che CIS controlla e poi passa a quelle dell’utente in Regole Applicazoni, quindi avere la rete configurata con permetti sopra a quelle di blocco nelle regole globali è fondamentale perchè i pc si vedano, in uscita invece cis legge prima le regole dell’utente presenti in Regole applicazioni e poi le screma con le regole globali, in quel caso system è permesso in uscita e questo non contrasta neppure con le regole globali ergo la rete va benissimo, non serve fare una regola ulteriore per system a mano da mettere in Regole Applicazioni

Svchost che CIS conosce ha un percorso del tipo C:\Windows\System32\svchost.exe, quindi è lui e solo lui autorizzato ad uscire via IP (e non udp o tcp) e ricevere di conseguenza anche dati ma solo da quel ip da lui contattato e via porta di uscita.
Fare una regola Blocca IP in/out da mettere sotto a quella delle applicazioni di sistema che è consenti IP out sarebbe come bloccare solo gli IP in entrata che onestamente non serve a nulla, anzi forse porterebbe problemi in sede di aggiornamento, se la si mettesse sopra ad applicazioni di sistema direi che non si naviga proprio, insomma per me non serve, tanto la regola solo uscita per le applic. di sistema è fatta per acconsentire entrata solo da IP a cui il tuo svchost punta (diamo per scontato che il pc non è infetto e svchost è quello sano di mamma microsoft)
Quindi meglio toglierla

Un eventuale attacco da un pc remoto credo proprio verrebbe visto come" IP numero xxx" e non come svchost.

Per Tiberyus occorre un log altrimenti non si capisce se quei windows op system passano da porte di emule o da una altra porta come avevi detto inizialmente, senza quello è un po’ come fare una diagnosi al telefono, nun se po’
Se whindows op sysytem avviene quando emule è spento e passa dalle sue porte allora è normalissimo, sono gli utenti che stavano scaricando dai tuoi file che fanno richiesta e cis le blocca visto che emule e le sue regole sono chiuse

Ciao Romagnolo 1973,

Grazie per la spiegazione.

Saluti

fuco

Ciao, vi posto il log.
Ho controllato, scvhost è lui, sta al suo posto C:\Windows\System32\ ed ha la dimensione giusta e non ce ne sono altri

[attachment deleted by admin]

è il mulo che ha quelle porte 4661 e 4671, se sì allora ti compaiono alla chiusura dello stesso o anche molto dopo e il motivo l’ho già indicato, gente che prova a scaricare dal tuo pc
con mulo aperto dovrebbero avere nome emule e non win.op.system

Lo so che il mulo ha quelle porte, ma i blocchi che vedi ci sono durante l’uso del mulo…

Vi posto il log. dove si vedono anche i blocchi generati dalle regole per eMule durante il suo uso.
Sono sempre più perplesso…

[attachment deleted by admin]

Ciao tiberyus,

Secondo me, leggendo il log che hai allegato a questo messaggio, quelle sono tutte connessioni che compaiono alla chiusura di emule perchè alcune persone provano ancora a scaricare dal tuo mulo.
Concordo quindi con Romagnolo 1973.
Questo è confermato dal fatto che la porta di destinazione è la porta TCP di emule.

Secondo me, leggendo il log che hai allegato a questo altro messaggio, le connessioni “Windows operating system” qui bloccate sono indipendenti da emule. (la porta di destinazione è sempre diversa).

Saluti

fuco

Per Romagnolo1973

Quindi secondo te, ogni qualvolta svchost mi chiede di acconsentire una connessione proveniente da internet io dovrei accettare in quanto è stato lui a contattare per primo.
Però se guardi il mio ultimo log. postato ci sono un paio di svchost bloccati in entrata da un IP sconosciuto su porta TCP…

…dipende dal tipo di Regole Globali, con quelle “avvertimi caso per caso”, sarà visto da CIS sul PC B come svchost.exe sta tentando di ricevere una connessione… sia che questo venga dalla LAN configurata (per Romagnolo: ecco perché le Regole a default anche per CIS 5 non sono sufficienti per una LAN) sia che venga dall’esterno della LAN. Invece con le Regole Globali “Blocca tutte le connessioni in ingresso” la richiesta di svchost del PC A verrà bloccata da esse, e verrà “loggata” col nome “Windows Operating System”.
Spero di essermi spiegato.

Hello my friend :slight_smile: how are you?
E’ vero molte cose sono cambiate da quando h scritte quelle regole, però…

Ti ricordi il telifilm Arnold?
Quando Arnold non era d’accordo col fratello gonfiava le sue “labbrone” e diceva: "che cosa stai dicendo Willis? ;D

A default, via IP (Internet Protocol e non indirizzi IP) per CIS significa qualsiasi protocollo (TCP, UDP, ICMP, IGMP, ecc.) a meno che non sia specificato nei Dettagli IP della regola.

Dici questo così, tanto per, oppure hai fatto delle prove?

Ciao bello :stuck_out_tongue: :wink:

Assolutamente no, devi negare sempre. Quello che voleva dire Romagnolo sono le connessioni in uscita che a loro volta contattando un’altro computer per avere dati, li ricevono con una trasmissione in entrata. Però se tu controlli il tipo di connessione (anche per la trasmissione di dati in entrata) vedrai che il tipo di connessione sarà in uscita.
Scusa per la spiegazione un po’ frettolosa e poco chiara.

Per fortuna che ci sono, la porta 135 va protetta. :wink:

Gli eventi che hai postato al reply 22 avvengono col mulo chiuso, quelli postati al reply 25 sono bloccati perché il mulo sta usando le porte privilegiate dette pure WKP cioè da 0 a 1023, mentre per i blocchi Windows Operating System, prima di rispondere ti volevo chiedere se hai sempre le Regole Globali postate al Reply 7 e se hai configurato la porta 4661 nelle regole del mulo.

Saluti a tutti. :slight_smile:

Ciao Sirio,

Spiegazione perfetta.
Grazie mille.

Saluti

fuco

Ciao Sirio, no, il log. postato al replay 22 non sono col mulo chiuso ma aperto, come dico al replay 24. Per il replay 25 il mulo è ovviamente in funzione. Si, la porta 4661 è configurata così come la 4672. Le regole globali sono ancora quelle, generate di default da Comodo.

Si, per me che sono nuovo e non molto esperto è poco chiara. Come dovrei fare a proteggere la porta 135, devo creare una regola?

Ciao tiberyus,

chiedo scusa per l’intromissione sia a te che a Sirio.

Ti faccio un esempio…

Considerazioni generali:

  1. Si ha una connessione in uscita quando un’applicazione, dal tuo pc, stabilisce una connessione verso un altro pc/server

  2. Si ha una connessione in entrata quando un’applicazione da un altro pc/server tenta di connettersi al tuo pc

Lascia perdere per un momento svchost.exe e pensa ad un programma di uso quotidiano quale può essere il browser con cui si naviga in internet (es. Internet Explorer).

Un utente apre il browser, gli viene presentata la pagina iniziale (home page in inglese) e naviga tra i vari siti internet.

Senza che l’utente lo veda, per ottenere ciò accade quanto segue:

  1. Il file eseguibile del browser (nell’esempio iexplore.exe) tenta di stabilire una connessione verso il server dell’Internet Service Provider (es Telecom)

  2. Il firewall del tuo pc controlla se, tra le sue regole e vede che la connessione deve essere autorizzata (se l’utente dice al firewall di bloccare il browser, risulta impossibile navigare in internet)

  3. Dopo autorizzazione del firewall, il browser stabilisce una connessione al suddetto server. Dato che l’eseguibile del browser si trova sul tuo pc e, dato che ha stabilito una connessione verso un server esterno, si tratta di una connessione in uscita.
    Immagina ora che la connessione sia una strada sulla quale le “auto” siano i dati scambiati tra il tuo pc e il server e viceversa.

  4. Dopo aver stabilito la connessione (e quindi costruito la strada) il browser, che sa qual’è la pagina iniziale che deve visualizzare, invia al server l’indirizzo internet da contattare (ad esempio http:\www.eccettera eccettera).
    In questo momento c’è quindi un flusso di dati in uscita, che dal tuo pc è inviato al server (il nome del sito).
    Immaginando che la connessione sia una strada, vedresti un’auto partire dal tuo pc e arrivare al server.

  5. Il server riceve il nome del sito e fa il lavoro da DNS, cioè trasforma il nome inviatogli (http:\www.eccettera eccettera) in un indirizzo IP di 12 cifre.
    Questo accade perchè il browser può contattare un server solo se conosce l’indirizzo IP dello stesso.

  6. Il server invia questo indirizzo IP al tuo pc utilizzando la stessa “strada” creata in precedenza dal browser.
    Rispetto al punto 4 però, vedrai un’auto che parte dal server e arriva al tuo pc, utilizzando la strada precedentemente creata dal browser, in senso contrario.
    In questo momento si ha un flusso di dati in entrata, ma il server, non ha stabilito alcuna connessione in entrata (non ha creato una nuova strada, ma ha utilizzato quella già creata in precedenza dal browser, il quale aveva stabilito una connessione in uscita).

  7. Il browser stabilisce una connessione in uscita (quindi crea una nuova strada) per contattare, dal tuo pc, il server sul quale è presente la home page.

  8. Scarica dal server in questione i file temporanei (Internet Temporary files) per visualizzare la tua pagina iniziale.
    Si ha anche in questo caso una situazione come quella del punto 6.

  9. L’utente a questo punto “vede” l’home page.

A questo punto considera queste considerazioni generali:

1)Una qualsiasi applicazione che stabilisce una connessione in uscita può sia inviare, sia ricevere dati.
2) Questo scambio di dati serve per il corretto funzionamento dell’applicazione stessa.
3)Flusso di dati in entrata non vuol dire per forza connessione in entrata.

Torniamo ora a parlare di svchost…

Quello che intendeva Sirio secondo me era questo…

Svchost deve comportarsi come segue:

  1. Deve poter stabilire connessioni in uscita verso internet e scambiare dati con i server di internet tramite queste connessioni da lui stabilite.
    Questo serve per far funzionare in modo corretto il sistema operativo installato sul pc.

  2. Nel caso si sia in presenza di una LAN con cartelle e stampante condivise, come nel tuo caso, svchost deve essere in grado di stabilire connessioni in uscita verso la LAN e di scambire dati tramite queste connessioni da lui stabilite.

  3. Nel caso si sia in presenza di una LAN con cartelle e stampante condivise, svchost deve essere in grado di poter ricevere connessioni in entrata derivanti dalla LAN, quindi dai pc della LAN stessa che sono sicuri perchè sono comunque i tuoi, e scambiare dati con loro.

4) Svchost.exe non deve mai accettare connessioni in entrata da internet.

Per come sono impostate le tue regole la porta 135 dovrebbe essere già protetta.

Spero di essere stato d’aiuto.

Saluti

fuco

Ok, sei stato molto chiaro! :slight_smile:
Per me, fino ad ora, anche anche il flusso dati in entrata era una connessione in ingresso e quindi lo era anche una risposta ad una chiamata.
Quindi è corretto che nelle regole applicazioni per svchost siano consentite tutte le uscite, le entrate provenienti dall’IP del router e bloccato tutto il resto.
Grazie mille.

[attachment deleted by admin]