Discussion :

[Artemus24]

Salut à tous.

Depuis quelques jours, je m'intéresse plus sérieusement à la sécurité de mon ordinateur et en particulier au pare-feu de Windows 10 pro.
J'avais déjà créé quelques règles, entre autre celles d'apache, de MySql et de FireBird.

J'ai activé le fichier pfirebird.log afin de recevoir toutes les règles, et j'essaye de comprendre les flux entrants et sortants.
Pour mieux analyser, j'ai chargé ce fichier dans une table MySql et j'ai créé des requêtes (select) pour extraire ce qui m'intéresse.

J'ai plusieurs questions à vous soumettre :

1) j'ai parfois du mal à comprendre les flux entrants et sortants.
Je croyais que l'IP destinataire d'un flux entrant représente l'adresse IP de mon ordinateur ?
Et vice-versa, l'adresse IP source d'un flux sortant représente aussi l'adresse IP de mon ordinateur ?

Est-il normal sur mon ordinateur de voir des flux qui ne lui sont pas destinés ?

2) j'ai analysé les flux de OUTLOOK (Microsoft Office), et je constate que je n'ai que les flux sortants sur le port destinataire 995.
Les flux entrants sont-ils sur les ports 80 ou 443 ?

Merci !
@+

[sevyc64]

Est-il normal sur mon ordinateur de voir des flux qui ne lui sont pas destinés ?

Ton ordinateur va recevoir les flux qui lui sont destinés mais aussi ceux qui sont destinés à quelqu'un, à priori inconnu du switch.
En effet, le switch garde en mémoire cache une correspondance entre adresse IP et n° de son interface de sortie. Quand le switch ne trouve pas de correspondance, il ne sait pas sur quelle interface faire transiter le paquet en question, alors il l'envoie sur toutes les interfaces à la fois.
C'est une des explications que ta machine reçoive des paquets qui ne lui sont pas destinés.

Une autre, beaucoup plus rare maintenant, est l'utilisation d'un hub à la place d'un switch. Le hub, à la différence du switch, n'isole pas chacune de ses interfaces de sortie, elles sont toutes en parallèle. La conséquence est qu'une machine connectée sur une interface d'un hub, voit la totalité du trafic de toutes les autres machines connectées à toutes les autres interfaces du même hub.
Mais l'utilisation du hub est de plus en plus rare depuis de nombreuses années.

2) j'ai analysé les flux de OUTLOOK (Microsoft Office), et je constate que je n'ai que les flux sortants sur le port destinataire 995.
Les flux entrants sont-ils sur les ports 80 ou 443 ?

Outlook est un client, ce n'est pas un serveur. Il ne reçoit pas de flux entrant autre que les réponses aux flux sortant qu'il lui même initié. Le port 995 est le port de connexion au serveur distant, pas le port de sortie d'outlook, qui, lui est (pseudo)aléatoire

[Artemus24]

Salut sevyc64.

1) Je utilise ni switch ni hub. J'ai juste la box de chez SFR.
J'ai oublié de précisé que ce sont des flux de mon réseau local que je voyais.

Donc c'est normal !

2) pour OUTLOOK, j'utilise les ports suivants : 25, 110, 143, 465, 587, 993, 995
Dans le fichier pfirebird.log, je voie seulement les ports 995 & 587 mais tous en flux sortant.
Dans les déclaratives de OUTLOOK, le flux entrant est POP3 (port 995) et le flux sortant est SMTP (port 589).

Si je comprends bien, c'est OUTLOOK qui ouvre un socket vers le serveur messagerie que j'utilise.
Et chaque programme à sa façon de gérer les flux entrants et sortants (avec ou sans socket).

3) j'ai un doute.
Quand je visualise les flux dans le fichier pfirebird.log, j'ai deux indicateurs, dont l'un se nomme "IP source" et l'autre "IP destinataire".
Quand je visualise une règle dans le pare-feu, dans l'onglet "étendue", j'ai "IP local" et "IP distante".

Si mon flux est entrant, dois-je comprendre que :
--> IP local = IP destinataire.
--> IP distant = IP Source

Et si mon flux est sortant, dois-je comprendre que :
--> IP local = IP Source.
--> IP distant = IP destinataire.

Autrement dit, on inverse les rôles.

4) j'ai un problème un peu plus complexe que je n'arrive pas à résoudre concernant les protocoles "ICMPv4" et "ICMPv6".
J'utilise le site http://ipv6-test.com/ pour vérifier la connectivité en IPv6 (IPv6 connectivity).
Je tiens à préciser que si je ne bloque pas, dans le pare-feu windows, les flux sortants, le test fonctionne.

Mon but est de bloquer les flux sortant du pare-feu windows afin que soit interdit tout ce que je ne précise pas en tant que règles.
De ce fait, je suis obligé de déclarer des règles sortantes pour le protocole ICMP.
J'ai donc déclaré deux règles, l'une pour "ICMPv4" et l'autre pour "ICMPv6", en acceptant tous les cas.
Quand je refais le test, il m'indique "not tested".

Si je déclare une règle sur tous les programmes avec uniquement le protocole TCP pour tous les ports, cela fonctionne.
Je précise que j'ai fait aussi les tests sur les packages et les services, cela n'a pas fonctionné.
Je conclu, pour un programme donné que j'ignore, que je dois autoriser le flux sortant pour le protocole TCP.

J'ai fait plusieurs essaies (system, explorer.exe, svchost.exe, dashost.exe, ping.exe ...) sans succès.
Comment puis-je identifier ce programme ?

Je suppose que cela doit être lié, car j'ai le même problème avec "windows update".

@+

[jaffommopeff-9757]

Si je comprends bien, c'est OUTLOOK qui ouvre un socket vers le serveur messagerie que j'utilise.

Dans le modèle client-serveur, le plus utilisé, c'est au client, le programme, de démarrer la connexion.

Et chaque programme à sa façon de gérer les flux entrants et sortants (avec ou sans socket).

Les développeur font un peu ce qu'il veulent ... Surtout que certains environnements peuvent être complexe, a cause des pare-feu, et certains logiciels contourne les problèmes avec des ports non définis. Skype est fait de tel manière à qu'aucun pare-feu le bloque (utilisation des ports http et https, ...).

Si mon flux est entrant, dois-je comprendre que :
--> IP local = IP destinataire.
--> IP distant = IP Source

Et si mon flux est sortant, dois-je comprendre que :
--> IP local = IP Source.
--> IP distant = IP destinataire.

A priori oui.

4) j'ai un problème un peu plus complexe que je n'arrive pas à résoudre concernant les protocoles "ICMPv4" et "ICMPv6".
J'utilise le site http://ipv6-test.com/ pour vérifier la connectivité en IPv6 (IPv6 connectivity).

Alors, la vrai question est : As tu besoin absolument de l'IPv6 ?
A l'heure actuelle tout fonctionne en IPv4 et protéger sa couche IPv6 est plus complexe. Si tu veux plus de sécurité bloque tout l'IPv6 !

Mon but est de bloquer les flux sortant du pare-feu windows afin que soit interdit tout ce que je ne précise pas en tant que règles.

Quel courage

De ce fait, je suis obligé de déclarer des règles sortantes pour le protocole ICMP.
J'ai donc déclaré deux règles, l'une pour "ICMPv4" et l'autre pour "ICMPv6", en acceptant tous les cas.
Quand je refais le test, il m'indique "not tested".

Quel test ? test-IPv6 ? not supported non ?
Si tu n'as que l'ICMP qui est ouvert c'est normal. Je ne sais pas comment le service fonctionne mais je suppose qu'il commence par un http redirect vers le serveur IPv6. Donc pas de http ou de tcp en IPv6, pas de test en ICMPv6.
Si tu veux tester l'ICMP en IPv6, ping les DNS google en IPv6 : 2001:4860:4860::8888 et 2001:4860:4860::8844.

Je conclu, pour un programme donné que j'ignore, que je dois autoriser le flux sortant pour le protocole TCP.

Oui, la quasi totalité des programme ont besoin de leur port TCP pour fonctionner.

Comment puis-je identifier ce programme ?

Netstat est ton ami.
https://windows.developpez.com/cours.../?page=page_11
et par exemple :
https://windows.developpez.com/cours...age_11#LXI-B-2

En gros, tu regarde qui écoute sur quel port en t'aidant les Process ID (tu les trouves dans le gestionnaire des taches (si tu active l'option de mémoire)).

Je suppose que cela doit être lié, car j'ai le même problème avec "windows update".

C'est possible, le flux update doit être ouvert. Tu doit avoir un règle déjà défini dans ton pare-feu Windows qui devrait ouvrir le nécessaire d'une simple clic.

[sevyc64]

1) Je utilise ni switch ni hub. J'ai juste la box de chez SFR.

LEs ports en sortie de la box sont des ports de sortie d'un switch intégré à la box

2) pour OUTLOOK, j'utilise les ports suivants : 25, 110, 143, 465, 587, 993, 995
Dans le fichier pfirebird.log, je voie seulement les ports 995 & 587 mais tous en flux sortant.

Outlook n'a pas de flux entrant autre que les réponses à ses propres requêtes. Les flux seront entrant donc sur des ports aléatoires supérieur à 1024, ports qui auront été utilisés au préalable pour faire sortir la requête.
Les ports que tu indique sont des ports distants, les ports des serveurs contactés.

Dans les déclaratives de OUTLOOK, le flux entrant est POP3 (port 995) et le flux sortant est SMTP (port 589).

Là tu confond la notion de flux, et la notion de services. Il n'y a aucune relation.
POP3 est utilisé pour le serveur (comprendre service) entrant. Le serveur POP3 tu donne accès aux messages qui sont entrés (reçus) dans ta boite aux lettres, cela n'à rien à voir avec un quelconque flux de données qui transite sur ton réseau.

[Artemus24]

Salut à tous.

Alors, la vrai question est : As tu besoin absolument de l'IPv6 ?

L'IPv6 va devenir une vrai nécessite et donc je ne désire pas faire une impasse. Donc la réponse est OUI !

A l'heure actuelle tout fonctionne en IPv4 ...

Que dois-je comprendre ? Sans l'IPv4 rien ne fonctionne ?

J'ai l'IPv6 natif. Je peux bloquer ou l'IPv4 ou l'IPv6 et continuer d'accéder à l'internet.
Sauf qu'il y a des sites qui travaillent exclusivement en IPv4.

Je préfère ne rien bloquer du tout et continuer d'accéder aux deux IP.

Quel courage

Je suis un peu inconscient de bloquer les flux sortants, mais j'ai du temps à perdre.
J'ai déjà traité les navigateurs, l'outlook, WampServer, candy crush saga, hubic, soit 22 règles.
J'ai ajouté une règle pour interdire certaines adresses IP.

Quel test ? test-IPv6 ? not supported non ?

Oui, il s'agit bien de test-ipv6.com.
J'ai trois cas de figures pour la ligne ICMP :
--> not tested
--> filtered
--> Reachable

Je suis dans le cas "not tested".
Je supporte le IPv6 puisque depuis longtemps, donc quand je ne bloque pas les flux sortants, j'ai un 20/20.
C'est juste que je n'arrive pas à comprendre quel programme qui nécessite le protocole TCP qui me bloque.

Si tu n'as que l'ICMP qui est ouvert c'est normal.

J'ai créé deux règles, l'une pour l'ICMPv4 et l'autre l'ICMPv6 pour le flux sortant.
Comme je l'ai dit, quand je débloque le flux sortant dans le pare-feu, tout fonctionne normalement pour l'ICMP.
Quand je le bloque le flux sortant dans le pare-feu, l'ICMP ne fonctionne plus. C'est le test de test-ipv6.com qui me le dit.
quand je créé une règle sortante sur tous les programmes, en mettant uniquement protocole tcp, ça fonctionne à nouveau.
Sauf que j'ignore le programme en question qui a besoin de cette autorisation.

Je ne sais pas comment le service fonctionne mais je suppose qu'il commence par un http redirect vers le serveur IPv6. Donc pas de http ou de tcp en IPv6, pas de test en ICMPv6.

Non, je ne suis pas dans ce cas là.
L'IPv6 fonctionne indépendamment de mon problème avec le protocole ICMP.
De plus, je voie les accès se faire en IPv6 vers mon site qui est hébergé sous wampserver.
Je ne suis pas bloqué lorsque je teste depuis mon ordinateur, l'accès à mon site en Ipv6 (voir http://ipv6-test.com/validate.php).

Netstat est ton ami.

Je connais puisque j'utilise "netstat -ano" pour visualiser ls ports d'écoutes.

En gros, tu regarde qui écoute sur quel port

Sauf que ICMP utilise aucun port, puisque ce protocole utilise la couche IP.

Je vais analyser les programmes visualisés par cette commande.

C'est possible, le flux update doit être ouvert.

Windows Update est un service.
Comme je l'ai dit, j'ai fait le test sur tous les services et sur tous les packages et cela ne fonctionnent pas.
Il s'agit bien d'un programme !

Les flux seront entrant donc sur des ports aléatoires supérieur à 1024, ports qui auront été utilisés au préalable pour faire sortir la requête.

Comment je peux les identifier ?

Là tu confond la notion de flux, et la notion de services. Il n'y a aucune relation.

C'est fort possible !
Pour l'instant, ce qui m'intéresse, c'est d'identifier d'une part les ports qui sont utilisés et d'autre part, les adresses IP, si elles ne sont pas trop nombreuses.

Autrement dit, je désire créer des règles entrantes et sortantes au plus près de l'application.
Et non, comme je le voie dans le pare-feu de Windows, une règle générale sans protocole d'identifié, ou bien une règle pour TCP et une autre pour règle pour UDP, sans préciser les ports utilisés.

@+

[Artemus24]

Salut à tous.

J'ai résolu mon problème 4). En fait, j'avais deux problèmes que voici :

4-a) le problème venait des navigateurs. J'avais limité mes navigateurs seulement aux ports 80 et 443 Il faut aussi ajouter le port 8080.
Sans ce port 8080, je ne pouvais pas non plus, me rendre sous : http://www.60millions-mag.com/le-tes...-consommateurs

4-b) j'ai mis une règle trop restrictive pour ICMPv6 sortante.
Au départ, j'avais mis "requête d'écho".
C'est utile pour la règle ICMPv6 entrante, mais pas pour la règle ICMPv6 sortante.
Il faut mettre les types ICMP suivantes :
--> requête de l'écouteur de multidiffusion.
--> rapport de l'écouteur multidiffusion
--> sollicitation de routeur.
--> sollicitation de découverte du voisin.
--> publication de découverte du voisin.
--> rapport d'écouteur de multidiffusion v2

Je suppose que je vais devoir revenir sur ICMP quand je devrai attaque le groupement résidentiel.

J'attaque maintenant le problème suivant :
5) Windows Update !
J'ai pourtant créé une règle d'autorisation sur le programme "WUAUCLT.exe", sans succès.
J'ai créé une règle sur le service "WUAUSERV", sans succès.

Est-ce que quelqu'un sait comment autoriser Windows Update, quand le pare-feu bloque les flux sortants ?
Je n'ai rien trouvé sur internet concernant Windows 10.

@+

[sevyc64]

Il n'y a pas grand chose à bloquer en ICMPv6 pour que l'IPv6 marche correctement. En effet, en IPv6, le protocole ICMP est devenu central.
Plusieurs fonctions et protocoles IPv4 ont été modifiés voire abandonnés, c'est le cas de l'ARP notamment, pour être intégrés dans le protocole ICMP en v6
Le fonctionnement d'IPv4 et d'IPv6 est totalement différent, c'est la raison pour laquelle les config des parefeu ne peuvent pas être partagées. Il faut une série de règles propres au protocole IPv4, et une nouvelle série propre au protocole IPv6


Pour ce qui concerne WindowsUpdate, le process fait intervenir de nombreux executables, dll, et services. WUAUCLT.exe n'est pratiquement au final qu'un superviseur
Personnellement, j'ai pu identifier un autre service, qui participe notamment au téléchargement en tache de fond des updates, c'est le service "transfert intelligent en arrière plan".
Lorsque tu as une grosse mise à jour qui se télécharge, c'est généralement ce service qui te bouffe la bande passante. L’arrêter résout momentanément le problème, mais le désactiver n’empêche pas le téléchargement de toutes les updates, certaines prennent d'autres chemins. De plus, WindowsUpdate n'est pas le seul à utiliser ce service.

[Artemus24]

Salut sevyc64.

Il faut une série de règles propres au protocole IPv4, et une nouvelle série propre au protocole IPv6

J'ai bien deux séries de règles différentes pour ICMPv4 et ICMPv6.
Pour ICMPv4 entrante et sortante, j'ai juste mis "requête d'écho".

j'ai pu identifier un autre service, qui participe notamment au téléchargement en tache de fond des updates, c'est le service "transfert intelligent en arrière plan".

C'est le service BITS pour "background intelligent transfer service".

5) En ce qui concerne "windows Update" pour la version windows 10 PRO, cela ne fonctionne plus comme dans les version antérieurs.
Dans Windows Vista, il était dit de créer deux règles, que voici :
--> SVCHOST.exe + BITS
--> SVCHOST.exe + Windows Update
Or cela ne fonctionne plus ainsi !

J'ai donc fait quelques tests :
--> en sélectionnant uniquement tous les services, cela ne donne rien.
--> en sélectionnant uniquement tous les packages, cela ne donne rien.
--> uniquement tous les programmes, cela fonctionne !

La seule règle restrictive que j'ai pu trouvé, consiste à sélectionner SVCHOST.exe (version 32 bits).
Sauf que j'ai un message d'alerte lors de la création de cette règle :

les services windows ont été limités par des règles qui autorisent uniquement le comportement attendu. Les règles qui spécifient des processus hôtes, par exemple svchost.exe, risquent de ne pas fonctionner comme prévus car elles peuvent entrer en conflit avec les règles de sécurisation renforcée des services windows.
Voulez-vous vraiment créer une règle référençant ce processus ?

On peut restreindre la règle en mettant TCP avec les ports 80 & 443.
En mettant que le port 443, cela ne fonctionne pas. Cela sous entend que les mises à jours ne sont pas sécurisées.

Cela ne me plait pas car j'aurai aimé sélectionner que sur windows update.

Il y a au total, 70 règles sortantes sur svchost.exe, donc 36 sont activées et toutes sur un service donnée, parfois plusieurs fois sur le même service.
Aucune concerne le service Windows Update (wuauserv) ou le programme wuauclt.exe. Aucune concerne aussi le service Bits.
Et cela, aussi bien sur les règles sortantes et entrantes.

Avez-vous une solution à me proposer pour windows update ?

6) je me pose aussi la question sur la sélection des règles par le pare-feu ?
Est-ce que les règles bloquantes sont prioritaires par rapport aux règles autorisées ?
Si j'ai deux règles dont l'une autorise et l'autre interdit, laquelle sera traitée ?

@+

[Artemus24]

Salut à tous.

Après beaucoup de tests, je suis arrivé à configurer le pare-feu afin d'avoir les flux entrants et sortants bloqués.
Pour la base comme les programmes, les protocoles (ICMP, DNS, DHCP, IGMP), et les services, je n'ai pas vraiment rencontré de gros problèmes.
Une recherche à parfois été nécessaire sur le net, en plus des tests de mise au au point, mais rien de bien difficile.
Il n'est pas toujours évident de connaitre les ports qui sont utilisés par tel programme, ou tel service.

Mais là où je ne suis pas arrivé à résoudre les problèmes sont :

5) Windows Update.
C'est un service, et je pensais comme je l'ai indiqué précédemment dans ce sujet que l'association svchost.exe et wuauserv suffisait largement.
J'ai donc créé une règle comprenant svchost.exe avec les ports 80 et 443 pour le protocole TCP.
Ça fonctionne parfaitement et je peux utiliser Windows Update.

7) le voisinage réseau ou découverte réseau.
A vrai dire, cela n'a jamais vraiment fonctionné correctement sur mon ordinateur, même avant que je bidouille dans mon pare-feu.
Par contre, si je désactive le pare-feu, cela fonctionne et je voie tous mes périphériques.
J'ai aussi constaté que si j'active le pare-feu, et que je mets autorisé aussi bien pour l'entrant et le sortant, cela ne fonctionne pas.
Je pensais que c'était équivalent à la désactivation du pare-feu !
A moins de me tromper, le problème concerne bien le pare-feu windows 10.

Ce que je désire, c'est obtenir les périphériques de mon réseau local, en utilisant le panneau qui se nomme "réseau" (network) sous windows 10.

D'après ce que j'ai pu comprendre, les ports utilisés sont : TCP 139 & 445, UDP 137 & 138 (protocole netbios).
Ainsi que les services suivants :
--> Assistance Netbios sur TCP/IP.
--> Client DNS.
--> Découverte SSDP.
--> Hôte de périphérique UPnP.

Je ne sais pas trop s'il y a d'autres services, mais en l'état actuel de mes recherches, je ne sais toujours pas résoudre ce problème.

@+

[Artemus24]

Salut à tous.

7) Pour le voisinage réseau, j'ai pu résoudre mon problème, mais avec des difficultés de compréhension.
Cela se résume aux points suivants qui sont les noms des groupes des règles prédéfinies dans le pare-feu Windows 10.

a) Partage de fichiers et imprimantes.
b) découverte de réseau.
c) service de partage réseau du lecteur windows media.
d) Unités Media Center Extender.
e) fonctionnalité diffuser sur un appareil

En plus de ces règles, il faut aussi s'assurer que les services associés à ces règles sont bien démarrés. Et vérifier aussi :

f) assistance Netbios sur TCP/IP.
g) client DNS.
h) client DHCP.

Mais aussi il faut désactiver :
g) groupe résidentiel (deux services).

Et créer une règle sortante sur :
h) le port 7676.

Toutes ces règles doivent être en mode privée et dans le sous réseau local.
Si cela intéresse, je peux détailler le contenu de ces règles sous forme de tableau.

En ce qui concerne la dernière règle (port 7676), je n'ai pas pu trouver avec précision quels étaient les programmes qui sont associés.
J'ai pu remarquer qu'il y avait dashost.exe, mais comme la recherche prend beaucoup de temps, je n'ai pas pu identifier les responsables.
Cette règle correspond au bouton "lire sur l'appareil", quand on clique sur une vidéo ou un morceau de musique.

En ce qui concerne le groupe résidentiel, il ne sert à rien sinon à perturber le bon fonctionnement du voisinage réseau.

En fouillant, j'ai trouvé un service dangereux "startion de travail" qui utilise SMB.
En le désactivant, j'ai mon ordinateur et ma box sfr qui ne sont plus visible dans le voisinage réseau.

Niveau sécurité, toutes ces règles sont dans le sous réseau local et donc non accessible par internet.

Si vous avez des informations à me communiquer sur le voisinage réseau, je suis preneur.

@+

[Artemus24]

Salut à tous.

Je récapitule les points suivants sur lesquels je bloque encore.

5) Windows Update.
Je n'ai toujours pas pu restreindre l'autorisation d'accès à windows update dans le pare-feu pour le flux sortant.
J'ai autorisé :
--> programme : svchost.exe
--> protocole et ports : TCP
--> ports distants : 80 & 443
J'ai essayé plusieurs services, dont windows update, sans succès.
J'aimerai avoir la liste des services et surtout comment les déclarer pour me restreindre à l'usage de windows Update.

7) le voisinage réseau ou découverte réseau.
Je suis arrivé à faire fonctionner correctement le voisinage réseau de mon réseau local.
Je rencontre deux problèmes :

7-a) lire sur l'appareil ou en anglais "Play to".
Je n'ai pas pu trouver le programme qui gère cette fonctionnalité.
J'ai créé une règle pas assez restrictive à mon gout :
--> programme : tous
--> adresse IP distante : sous-réseau local
--> protocole et ports : TCP
--> ports distants : 7676

7-b) accès à la clef USB installé sur ma BOX SFR.
A vrai dire, je n'ai aucun problème, mais j'ai constaté plusieurs choses qui ne me plaisent pas.
Tout ce qui concerne le voisinage réseau a été déclaré avec comme adresse IP distante : sous-réseau local.
En particulier les ports netbios UDP 137 & 138

J'ai aussi créé une règle interdisant l'accès à ces mêmes ports mais pour l'adresse IP distante : internet.
Et je constate que je n'ai plus accès à ma clef USB.

Les anomalies qui me paraissent bizarres sont :
--> Tout ce passe comme si l'accès ne se faisait pas en réseau local mais en réseau internet. Pourquoi ?

--> Si je ne mets pas ma règle interdisant l'accès à l'internet, j'accède normalement à ma clef USB.
Or, le flux sortant est bloqué sauf s'il existe une règle sortante.
Comment se fait-il que je sois obligé de mettre cette règle bloquante pour interdire l'accès ?
Cela devrait se faire sans que je le précise, non ?

8) Xbox
Une des conséquences de la règle trop général du § 5) sur windows update, je peux me connecter à mon compte au travers de la XBOX, quand j'utilise "Microsoft Solitaire Collection".
J'ai pourtant fait des recherches sur les services concernant XBOX, mais comme pour Windows Update, je ne suis pas arrivé à sélectionner les bons services.
J'aimerai donc restreindre l'accès à la XBOX uniquement !

9) Server Message Block.
C'est le point de vulnérabilité des attaques mondiales Ransonware.
Je sais comment désactiver SMBv1 pour windows 10.
--> http://www.windows8facile.fr/desactiver-smb/

J'ai fait le test, mais je n'arrive plus à accéder à mon réseau local.
Ma question est de savoir s'il existe une autre façon d'accéder à un périphérique de mon réseau local sans passer par le réseau Windows ?
Autrement dit, en TCP/IP mais par le réseau local.

Je ne maîtrise pas trop les différences qui existent entre les ports 135, 137, 138, 139 & 445.
Ce que j'aimerai, c'est désactiver tout ce qui concerne les failles de sécurités qui servent au réseau windows et dont cela fait la joie de ceux qui pratiquent le ransonware.

10) comment améliorer la sécurité de mon réseau local ?
Peut-être devrais-je envisager l'achat un vrai routeur afin de mieux filtrer les flux entrants et sortants de mon réseau local.
Si vous avez des conseilles, je suis preneur !

Cordialement.
@+

[Artemus24]

Salut à tous.

J'espère que je n'écris pas ces messages pour rien.

J'ai résolu deux points :

7-a) lire sur l'appareil ou en anglais "Play to".
La difficulté repose sur l'identification du programme.
Là où j'avais tort, c'est qu'il n'y a pas un seul programme mais deux qui gère "lire sur l'appareil" au travers du pare-feu.

Le premier, c'est "c:\Windows\System32\wmpdmc.exe". Il se nomme "diffuser sur un Appareil".
Le second est moins évident. Il s'agit de "c:\Windows\System32\dashost.exe".
Il se nomme "Device Association Framework Provider Host".

Ces deux règles, respectivement sur les deux programmes ci-dessus, seront créés à l'identique, soit :
--> adresse IP distante : sous-réseau local
--> protocole et ports : TCP
--> ports distants : 7676

7-b) accès à la clef USB installé sur ma BOX SFR.
J'ai pris la décision que la clef USB sur ma BOX SFR ne me servait à rien.
Du coup, j'ai désactiver SMB1 (voir mon §9) Server Message Block).

Et j'ai interdit les règles suivantes aussi bien pour le flux entrant et le flux sortant, pour le réseau internet.
Ces mêmes règles ne sont pas interdites pour le réseau local.

--> NetBios TCP pour les ports 137, 138 et 139.
--> NetBios UDP pour les ports 137, 138 et 139.

--> Server Message Block (SMB) TCP pour le port 445.
--> Server Message Block (SMB) TCP pour le port 445.

--> RPC (Remote procedure call) TCP pour le port 135.
--> RPC (Remote procedure call) UDP pour le port 135.

Et pour finir :
--> adresses IP interdites 224.0.0.0/8
Cela comprend toutes les adresses allant de 224.0.0.0 jusqu'à 239.255.255.255.

7) le voisinage réseau ou découverte réseau.
Ce paragraphe est, pour l'instant, disons terminé puisque j'ai résolu mes deux problèmes.
J'envisage d'acheter un NAS (Network Attached Storage), afin d'avoir un serveur fichier sur mon réseau local.
Et du coup, je vais revoir les règles de mon réseau local.

9) Server Message Block.
J'ai créé un nouveau sujet sur WannaCrypt, et en particulier sur SMB et le port 445.
Je cherche à mieux comprendre comme fonctionne SMB et à mieux me protéger.

@+

[Artemus24]

Salut à tous.

J'ai pratiquement résolu tous mes problèmes sauf celui de Windows Update 5).
Mes améliorations me protègent un peu mieux que de laisser le flux sortant sans contrôle.
Le pare-feu windows est du même gabarit que les autres pare-feu (Comodo) que j'ai pu testé.
Toute la difficulté repose sur le bon paramétrage à appliquer pour augmenter la sécurité.

Je clôture le sujet.

@+