Discussion :

[ngmsky]

Bonjour,

Voici l'extrait de l'article sur wikipédia :

source : pare-feu à états

C'est à la fin de la page :

Vulnérabilités
Il existe un risque que les vulnérabilités dans les décodeurs de protocole individuels pourraient permettre à une personne malveillante de prendre le contrôle du pare-feu. Cette préoccupation souligne la nécessité de maintenir un logiciel de pare-feu à jour. ‏‏
Certains pare-feu à états soulèvent également la possibilité que les hôtes individuels peuvent être trompés en sollicitant les connexions externes. Cette possibilité ne peut être complètement éliminée par l'audit du logiciel hôte.
Certains pare-feu peuvent être vaincus de cette manière par la simple visualisation d'une page web (soit avec Javascript activé, ou après avoir cliqué sur un bouton)4.

Si je comprends bien, le but du pirate c'est de pousser l'utilisateur à initier une connexion (en cliquant sur un lien dans email, par exemple). Ensuite, le le pirate (son script) pourra donc donc se connecter au réseau privé puisque le pare-feu verra que la connexion a un statut ESTABISHED.

On voit bien, comme le souligne wikipédia que dans ce cas, le pare-feu devient une passoire (voir dernière phrase).

La question quels sont les solutions pour ce genre de contournement ?
Je souligne qu'en réalité, ce n'est pas une faille du firewall puisqu'il ne laisse vraiment passé que les requette obéissant aux règles fixées par l'admin.
Et là, la règle : "si la connexion était déjà ÉTABLIE, accepte" est bien respecté, le firewall a donc bien fait son travail. Mais c'est l’utilisateur qui s'est fait trompé.
C'est un peu comme un utilisateur qui donne le code d'accès ou le double des clefs à un voleur qui l'a trompé.
Si le voleur accède à la pièce privée, ce n'est pas la faute de la serrure mais de l'utilisateur.


La question est donc :
Comment faire pour empêcher cela, TECHNIQUEMENT, svp (en dehors de la vigilance des utilisateur, dont personne ne peut vraiment compter dessus) ?

- Je ne pense pas non plus que la mise à jour du pare-feu corrige ce problème, puisqu'il ne s'agit pas d'une faille du firewall.
- Travaille dans une machine virtuelle complètement isolée, me semble pas très pratique pour une utilisation à long-terme.


Merci d'avance pour vos propositions.

A bientôt

[BufferBob]

ce n'est pas "wikipédia qui dit que", faut-il ré-expliquer le principe de wikipédia en 2016 ? n'importe qui peut y écrire n'importe quoi, seule la vigilance des autres utilisateurs permet d'assurer la qualité et la pertinence des articles

en l'occurrence l'utilisateur qui a écrit quasiment toute la page à lui tout seul -et c'est bien peu de contenu pour parler des firewall à états- c'est un certain NourSlt33, dont on peut citer le passage dans le code source de la page :

Il existe un risque que les vulnérabilités dans les décodeurs de protocole individuels pourraient permettre à une personne malveillante de prendre le contrôle du pare-feu. Cette préoccupation souligne la nécessité de maintenir un logiciel de pare-feu à jour. <ref> [http://lwn.net/Articles/369367/ The Grumpy Editor’s Tomato review – Jonathan Corbet – 11 Janvier 2010 – consulté le 16 décembre 2013 - "...both L7-Filter and IPP2P are explicitly unmaintained. Given the steady stream of security updates for protocol dissectors in WireShark, your editor has a hard time believing that these other classifiers can be completely free of security issues."] </ref>

la partie en rouge :

• n'est pas visible sur le rendu de l'article, et montre par là à la fois que l'utilisateur connait mal la syntaxe mediawiki et également qu'il ne se relit pas lui-même suffisamment, et probablement que peu ou personne ne l'a relu depuis
• met en évidence la logique du propos soutenu par l'auteur, à savoir que sur le site lwn.net, un auteur du nom de "The Grumpy Editor" ("l'éditeur grincheux" littéralement) a acheté un routeur spécifique et en fait l'analyse, et il dit en substance que comme les L7-filter et IPP2P (deux packages additionnels permettant de faire de l'inspection DPI à bas coût, mais aucun rapport avec les firewalls stateful) ne sont pas maintenus, et vu le nombre de vulnérabilités dans les dissecteurs wireshark (aucun rapport ici non plus), il pense que les deux (L7-filter et IPP2P) doivent possiblement avoir des trous de sécurité
  en clair un article moyennement éclairé sur lwn.net et qui parle d'un produit spécifique, repris par un utilisateur sur Wikipédia pour généraliser le fait que dans les firewalls à états il y a des possibilités de contournement, autant dire que le premier s'il connait un peu la sécurité informatique ne fait que donner son avis -pessimiste- sur une chose, là où le deuxième généralise sans manifestement rien y connaitre ni à la sécurité informatique ni aux firewalls à états

en somme il s'agit d'un article Wikipédia de mauvaise qualité, ça arrive. c'est aux utilisateurs avertis () d'être vigilants, en l'occurrence je ne sais pas trop ce qu'il conviendrait de faire à minima, peut-être tagger la page comme nécessitant une relecture ou étant de piètre qualité, à voir si ça existe
pour le reste c'est au lecteur d'exercer son esprit critique et sa sagacité intellectuelle, je ne connais pas de tuto pour ça en revanche.

Edit: il semble que la page sur Wikipédia FR soit ni plus ni moins qu'un re-sucé de la page EN

[ngmsky]

Bonjour,
merci à toi (BufferBob) pour ta contribution.

Moi, non plus je ne connais pas assez bien les pare-feu mais je continu d'apprendre. Voila pourquoi, en lisant cet article, j'ai voulu mieux comprendre en demandant l'avis des experts sur developpez.net.

Par contre, ta réponse n'est pas trop claire, pour moi.
A part le faite de préciser que l'article n'a pas été écrit par Wikipédia mais par un simple utilisateur (peu expérimenté en plus, selon toi), donc hors mis cela, je n'ai pas saisi exactement ta réponse à ce problème.

Que veut-tu dire, "clairement", "concretement" ?
- c'est un faux problème ?
- c'est négligeable ?
- c'est lié à quelque models bien précis de matériel ?
...
- Et enfin, selon toi, la seule et unique solution c'est à l'utilisateur d'être très très vigilant et c'est tous ?

Je me demande, cequi se passera après s'être fazit piraté (par cette faille) 3 ou 4 fois de en une année. Est-ce qu'il faut licenicer les utilisateurs pour leur manque de vigilance, sans compter les coûts que le piratage + les licenciements + reambauche représenteront au niveau de la trésorerie de l'entreprise !

-----------

Autre chose, si ce problème ne serait pas réellement général à tous les pare-feu d'état (selon toi) et même s'il serait très rare (car lié à un model précis de modem), mais du moment où c'est un problème (faille), alors que faire ?


Je précise bien que ma question ne concerne pas les solutions au niveau utilisateur, car tant que c'est l'utilisateur, la faille sera toujours là et le risque de se faire tromper sera toujours à 100% car les technique de tromperie ne font qu'évoluer.

Bref, j'aimerai qu'on se concentre surtout sur les solutions d'ordre "technique" et ne pas compter sur la vigilance des utilisateurs.

- 1/ Pourquoi j'insiste sur cette question et pourquoi je ne veux pas compter sur la vigilance ?
- 2/ Pourquoi ce problème (cette faille est réellement à prendre au serieux) ?

Réponse à 1/ et 2/ :
Exemple d'un cas concret parmis des centaines voir milliers d'autres (rien que pour cette faille) : Pourquoi les ransonwares font-ils plus peur que les autres types de virus ?

En lisant donc ce 2eme article,
- Comment pourrai-je banaliser ou sous-estimer une telle faille (il s'agit bien du pare-feu à état) ?
- Si les grandes structures comme les hôpitaux, des PME, etc sont facilement touchés, comment pourrai-je vraiment croire que ce problème (faille) ne concerne pas tous les par-feu à état, de façon général ? et pourquoi continuer à compter sur la vigilange des utilisateurs (qui peuvent d’ailleurs, eux-même, être complices ou auteur de l'attaque, on ne sait jamais) ?

Encore une fois, comme je l'ai dis, je ne connais pas bien le monde de la sécurité informatique, donc, ma compréhension ou mes analyses pourront sont peut-être erronées mais j'aimerai juste mieux comprendre.

Merci d'avance pour la contribution de chacun.

[BufferBob]

• RIRI écrit un article sur son blog en disant qu'il n'aime pas les épinards
• FIFI écrit contribue sur wikipedia en affirmant que les épinards sont nocifs pour la santé, en prenant RIRI comme référence
• LOULOU pose une question sur un forum pour demander où on peut se procurer des gilets pare-balle pour se protéger contre les épinards zombies, en citant FIFI

tu vois où est le problème ou vraiment pas du tout ?

le meilleur conseil que je peux te donner c'est d'abord de continuer à lire (et comprendre) autour des firewalls et de la sécurité informatique tout en continuant d'exercer ton sens critique et la qualité de ta logique interne

source(s): bibi, certifié Checkpoint CCSA/CCSE sur Firewall-1

[ngmsky]

Bonjour,
merci pour ta réponse.
Mais encore une fois, je suis d'accord avec toi sur le principe que le contenu d'un article n'est pas prendre comme une confirmation mais comme une affirmation, à vérifier, approuver, ... car l'auteur peut être en erreur.
Ok.

Par contre, tu ne m'a rien dis du tout sur l'exemple concret et surtout récent (3 semaines) des dégâts causé apr ce problème (fail sur pare-feu d'état).

Cet article Pourquoi les ransonwares font-ils plus peur que les autres types de virus ?

a été par Victor Vincent, Ingénieur développement logiciels.
Il est un Chroniqueur Actualités sur developpez.net

- Nous sommes donc tous, qu'il ne s'agit pas d'un utilisateur du genre RIRI ou FIFI, à moins que mon sens d’appréciation soit vraiment erroné !
- En dehors des cas concrets qu'il cite, on voit bien plusieurs intervenants confirmer avoir eu ce même problème (enfin leu clients).
Ce qui montre que malgré le manque de fiabilité de l'article de RIRI (sur wikipédia), le problème évoqué par RIRI est quand même là et semble de faire des gros dégâts au point de pénaliser une structure comme un hôpital ! Je ne sais pas si vous imaginer les dégat sur la santé des malades nécessitant un suivi sévère et régulier, ou ce qui pourrait se passer si le système de chirurgie à distance serait bloqué en plein intervention médicale, à cause d'un verrouillage du system informatique par le pirate ?
C'est sur cette réalité que j'aimerai avoir des réponse, pas trop sur RIRI (on est tous d'accord, ok) mais puisque les ransomwares exploitent cette même faille, doit-on ne rien faire "TECHNIQUEMENT" ?

Je rappel que la solution de la vigilance des utilisateur est une méthode aussi ville que les problème d'insécurité, enfin, depuis la création du monde.
Et nous voyons bien que l'on ne peux plus continuer à compter sur la vigilance, car l'être humain est toujours faillible
NB : les utilisateurs finaux du système informatique ne sont pas des informations, ils ont leur métier, et l'informatique n'est qu'un outils. Donc il ne passeront pas leur temps à faire de la sécurité informatique et ils n'ont jamais la vigilance d'un expert en sécurité en informatique, et encore, même-ci c’était le cas, ils restent humains donc potentiellement corruptible.

[BufferBob]

Mais encore une fois, je suis d'accord avec toi sur le principe que le contenu d'un article n'est pas prendre comme une confirmation mais comme une affirmation, à vérifier, approuver, ... car l'auteur peut être en erreur.
Ok.

tu sembles dire ça comme si c'était anodin, un simple fait sans gravité ni vraiment de conséquence, alors que c'est un pilier de la non-problématique qui t'amènes ici
c'est ton choix.

Par contre, tu ne m'a rien dis du tout sur l'exemple concret et surtout récent (3 semaines) des dégâts causé apr ce problème (fail sur pare-feu d'état).

Cet article Pourquoi les ransonwares font-ils plus peur que les autres types de virus ?

de quel "cas concret" parles-tu ? si tu fais référence à l'article, il ne traite nulle part de firewalls (le mot n'est même pas cité une seule fois)

ça tend à se confirmer avec la phrase suivante...

le problème évoqué par RIRI est quand même là et semble de faire des gros dégâts au point de pénaliser une structure comme un hôpital !

...qui semble faire référence à la réponse de Fagus, qui parle d'infection par un malware et non de firewalling, de la même façon qu'on achète pas de déodorant chez le charcutier, les deux n'ont rien à voir

tu n'as donc pas compris le rôle d'un firewall, son champ d'application, ce qui ne t'empêche pas dans la foulée de spéculer allègrement :

Je ne sais pas si vous imaginer les dégat sur la santé des malades nécessitant un suivi sévère et régulier, ou ce qui pourrait se passer si le système de chirurgie à distance serait bloqué en plein intervention médicale, à cause d'un verrouillage du system informatique par le pirate ?

et d'affirmer :

Nous sommes donc tous (?), qu'il ne s'agit pas d'un utilisateur du genre RIRI ou FIFI (...)
En dehors des cas concrets (...) plusieurs intervenants confirmer (...)
C'est sur cette réalité que (...)

du coup :

à moins que mon sens d’appréciation soit vraiment erroné !

envisager cette éventualité sincèrement est une bonne idée

je te réitère donc mon conseil en deux points :

• continuer d'apprendre la technique, la sécurité informatique, le fonctionnement des systèmes d'exploitation, le développement, incluant le fonctionnement des firewall
• exercer ton sens critique et ta sagacité, et particulièrement éviter la tentation de se laisser aller aux fantasmes, ce qui mène inexorablement à des logiques de type complotiste

le premier se comble assez aisément à l'aide de tutoriels et de patience, le deuxième est beaucoup plus intime, personnel et néanmoins absolument nécessaire lorsqu'on s’intéresse à l'informatique sur le plan technique

[ngmsky]

Bonjour,
merci pour ta reponse.
Oui, c'est vraie que je dois continuer à apprendre. Mais les tutos sont redigés par n'importe qui. J'ai justement parfois des difficultés d'appréciation avec certitude de la compétence de l'auteur du tuto (ce qui explique un peu ma considération de l'article de wikipédia).
Si bien, qu'au final, l'apprentissage par les tutos/forum, etc devient un peu moins rassurant (qualitativement).

En passant, si tu pourrai m'aiguiller vers quelques tutos (ou autre documents) ou formations à distance que tu juge très fiable, ça m'aiderai vraiment.

...
de quel "cas concret" parles-tu ? si tu fais référence à l'article, il ne traite nulle part de firewalls (le mot n'est même pas cité une seule fois)
...

J'ai compris qu'il s'agissait du firewall (pare-feu) par simple raisonnement logique.

en gros, pour sécuriser une machine, on a besoin :

1/ d'une protection contre les "LOGICIELS" malveillants (présents sur la machine) tels que virus, cheval de trois, etc.
Il faut une application du type : anti-virus/anti-malware, anti-xxx


2/ dune protection contre les "CONNEXIONS/COMMUNICATIONS" malvaillantes entre 2 machine s situées sur un même reseau ou non (selon les régle de filtrage).
IL faut utiliser une application de type pare-feu (firewall), qui selon nos régles filtrera les flux des données entre notre machine et les autres (en réseau local ou à distance, sur internet).

C'est donc bien le firewall et non l'anti-virus (anti-malware, anti-xx) qui est "RESPONSABLE" du filtrage des paquets entrant ou sortant de notre machine (ou de notre reseau local, par rapport à internet).

Et d'après cette règle de iptable (pour contrôler netfilter) :

Autorise le trafic entrant,pour une connexion déjà établie
permet à une connexion déjà ouverte de recevoir du trafic :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

source doc.ubuntu-fr.org/iptables


Cette règle est bien claire.
Si une connexion "ENTRANTE" a l'etat "Déja établi", alors Accepte la connexion
Sinon Refuse la connexion.

- Il s'agit bien d'un pare-feu à état (puis qu'il filtre selon l'etat etabli ou non du paquet)

Par simple logique, on comprends très bien qu'avant de réussir à chiffrer les données du pc piraté (par un virus, malware, etc), il faut bien que ce virus "ENTRE" dans notre réseau (ou pc).

Et c'est là que la règle iptable cité précédemment intervient.
Le pirate sait très bien que tant qu'il n'aura pas une connexion avec l’état "ESTABLISHED", toute ces tentative d'injection du virus seront refusées (par le pare-feu).

Voila pourquoi, le pirate incite un utilisateur lambda à cliquer sur un lien, une image, etc contenu dans un mail par exemple.
Une fois cliqué sur ce lien, l'utilisateur vient (sans se rendre compte) d'initier une connexion qui finira par avoir l’état "ESTABLISHED" par le pare-feu.

Les connexions du pirate vers notre machine (ou réseau) seront maintenant Acceptée (Autorisée) par le pare-feu puisqu'il qu'elles auront bien le statut "ESTABLISHED" et respecteront la règle iptable cité la haut.

Or en lisant l'article sur les ronsomwares,

on a :

... les attaquants par cheval de Troie s’en prenaient aux systèmes dès lors que ces derniers pouvaient être accessibles depuis internet.

Ils auront donc besoins d'ENTRER dans notre reseau. Et ce n'est pas l'anti-virus qui s'occupe des entrée sorties, mais bien un pare-feu.

Un autre aspect qui rend les ransonwares particulièrement redoutables est le fait qu’ils utilisent la méthode de phishing, réussissant à convaincre des utilisateurs pas souvent très avisés de cliquer sur des liens ou des pièces jointes.

Il suffit de se poser la question : Pourquoi poussent-ils l'utilisateur à cliquer sur un liens ?

La reponse logique c'est : Pour que l'utilisateur puisse initier une connexion avec la machine du pirate. Et cette connexion aura un etat "ESTABLISHED". cequi permettra au pirate d'ENTRER dans notre reseau/pc, en contournant ainsi la reglè du pare-feu cité la haut.

=>> C'est bien le "pare-feu à état" qui est ciblé par le pirate.

Voila pourquoi, même-ci l'article ne mentionne pas le mot "firewall", j'ai conclus qu'il agissait quand même du firewall "à état" qui à été vaincu (contourné).

Bon, je fais très long surement, mais j'aime bien donner assez de détails, pour m'assurer de bien expliquer ma pensée.

Que penses-tu de cette analyse ?

Je précise bien que si ce cas concret (article ronsomware sur developpez.net) n'avait rien à avoir avec le firewall (à état") pourquoi les pirates poussent-ils leurs victimes à cliquer sur un lien ?

[BufferBob]

Que penses-tu de cette analyse ?

Je précise bien que si ce cas concret (article ronsomware sur developpez.net) n'avait rien à avoir avec le firewall (à état") pourquoi les pirates poussent-ils leurs victimes à cliquer sur un lien ?

j'en pense qu'elle est fausse, que tu prétends poser une -ou plusieurs- questions concernant les firewalls à état mais que tu restes borné sur ton idée sans tenir compte de ce qu'on peut te dire, que tu communiques sur un mode où tu affirmes n'importe quoi et te mets en attente qu'on te démontre le contraire, et que ce type de discussion ne m'intéresse pas suffisamment pour que je m'échine à essayer de te prouver que tu te trompe (4 réponses c'est déjà bien assez, vraiment...)

s'il y a bien une certitude que j'ai acquise ces dix dernières années, c'est qu'on "aide" jamais les autres, ceux qui profitent de quelque aide qu'on leur apporte font en réalité la très grande majorité du boulot par eux-même de par leur ouverture d'esprit, leurs efforts pour comprendre, pour changer leur point de vue, là où les autres estiment en général qu'on ne les a pas bien ou pas assez aidé

[ngmsky]

Oh, c'est vraiment dommage que tu prennes mal le faite que je ne fasse pas du "oui-oui" !

Curieusement, tout ce que tu m'as dis (pour m'aider à comprendre qu'il ne s'agissait pas du firewall) c'est que le mot "firewall" n'est pas cité dans l'article. Est-ce sincèrement un argument suffisant pour que je dise "oui" d'accord, il ne s'agit pas de firewall.

... de quel "cas concret" parles-tu ? si tu fais référence à l'article, il ne traite nulle part de firewalls (le mot n'est même pas cité une seule fois)

Si j'ai donné assez de details (poste précedent), c’était pour d'une part pour répondre à ta question et aussi pour expliquer pourquoi j'ai pu dire qu'il s'agit bien d'un firewall à état, même-ci ce terme n'a pas été cité dans l'article.

C’était à toi de m'expliquer tout simplement où était mon erreur dans cette analyse (explication). En faisant cela, tu m'aurait surement mieux aider qu'en mettant fin à la discussion !


Et pourtant, d'une part, que tu dis bien qu'il faut un esprit de critique mais d'autre part, tu n'accepte pas (ou ne supporte pas) que ta réponse (abscence du mot "firewall dans l'article") soit contestée ou non acceptée automatiquement, facilement et naïvement.

> S'il fallait accepter automatiquement un traitement médical juste parce que :
1/ l'autre c'est un médecin (donc expert)
2/ et que le patient n'a pas son niveau de connaissance,
Je te laisse imaginer les dégâts.

En effet, nous savons tous qu'il y'a eu (par exemple) plusieurs médicaments retirés du marchés (pour leur dangerosité) mais qui ont été et qui ont continuer à être prescrit par certains médecins, pour expert dans la matière !

Si donc un patient a un doute sur la fiabilité d'un médication prescrit par le médecin,
- ne devrait t-il pas essayer de s'assurer que la prescription du médecin est à revoir ?
- devrait t-il accepter automatiquement et consommer ce médicament juste parce qu'il a été prescrit par un médecin, un expert (alors qu'il lui semblerait que ce médicament ait été retiré du marché) ?



2/ S'il fallait accepter automatiquement, tous ce que le prof de maths donne comme solutions juste parce que :
- il est expert en maths
- et que son élève n'a pas le même niveau de connaissance que lui,
Je te laisse imaginer les dégâts.

En effets, il arrive bien qu'un prof se trompe dans son raisonnement jusqu'à donner une mauvaise solution.
Mais grâce à l'esprit critique de certains élèves, qui n’étant pas convaincu de la réponse du prof, du "MAÎTRE", vont proposer une autre solution qui au final aboutit à la vérité.

Dans plusieurs domaines de la vie, on voit très bien que la discussion contradictoire (dans le bons sens bien sûre) conduit souvent à l’éclaircissement et une meilleure compréhension du problème. Et donc à de meilleures solutions aussi.


Bon, on ne va pas ce compliquer la tache inutilement. Je te comprends et je te remercie sincèrement pour le temps que tu as pris pour me répondre, même-ci je n'ai pas été convaincu (dans le bon sens du terme, en toute humilité) par ta réponse.

Mais si toi ou quelqu'un d'autre voudrait apporter un éclairage à ce sujet, ça ne sera que du bonheur.

Merci d'avance

[transgohan]

Voila pourquoi, le pirate incite un utilisateur lambda à cliquer sur un lien, une image, etc contenu dans un mail par exemple.
Une fois cliqué sur ce lien, l'utilisateur vient (sans se rendre compte) d'initier une connexion qui finira par avoir l’état "ESTABLISHED" par le pare-feu.

Les connexions du pirate vers notre machine (ou réseau) seront maintenant Acceptée (Autorisée) par le pare-feu puisqu'il qu'elles auront bien le statut "ESTABLISHED" et respecteront la règle iptable cité la haut.

Le parefeu ne peut en effet rien pour cela.
C'est le rôle de l'antivirus / antimalware de traiter cette menace une fois qu'elle est arrivée sur le PC.

Le parefeu n'est pas là pour bloquer des paquets dangereux, mais des connexions non souhaitées.
L'antivirus est là pour bloquer des comportements dangereux.

[ngmsky]

Le parefeu ne peut en effet rien pour cela.
C'est le rôle de l'antivirus / antimalware de traiter cette menace une fois qu'elle est arrivée sur le PC.

Le pare-feu n'est pas là pour bloquer des paquets dangereux, mais des connexions non souhaitées.
L'antivirus est là pour bloquer des comportements dangereux.

Bonjour er Merci pour ta contribution.

Quand tu dis : "... cette menace une fois qu'elle est arrivée sur le PC".
Je suis tout à fait d'accord.

Mais "AVANT" que ce virus n'arrive sur le PC, il était bien sur un serveur distant (machine contrôlée par le pirate). On est bien d'accord ?

Il y'a bien un moment/mécanisme/événement/une action qui favorise l'introduction de ce virus sur le PC de la victime.

C'est bien de ce moment là, de cet "événement" que je parle. Et non du virus lui même (qui n'est pas encore sur le pc de la victime).

cet événement n'est rien d'autre que le déclenchement d'une communication (ou CONNEXION Réseau) Établie entre le pc de la victime et la machine du pirate.

a) Est-ce jusque là, je nous sommes d'accord ?

Si oui, alors, qu'elle est l'utilitaire de sécurité prévu pour empêcher cet événement (Etablissement d'une CONNEXION Reséau) de produire ?

Est-ce l'antivirus ? l'anti-malware, anti-xxx ?
ou plutôt le firewall, le "MUR de feu" ?


Je crois que tu as déja donné la bonne reponse :

Le pare-feu n'est pas là pour bloquer des paquets dangereux, mais des connexions non souhaitées.

Je suis d'accord que si l'utilisateur "Télécharge" un virus caché dans un fichier normal,
(par exemple dans un fichier excel contenant des macros),
ce n'est pas du tout la faute du firewall, car le virus est déjà dans la boite email de la victime, attaché en pièce jointe.
C'est plutot à l'antivirus du serveur mail de tester les fichier joint au message avant de les livrer.

Mais le fait de cliquer sur un lien ne signifie pas automatiquement "Téléchargement"
Et d’après l'article de developper.net sur les ronsomwares, j'ai compris que ces pirates poussent, incitent leurs victimes à "cliquer" sur un lien (mais pas nécessairement de télécharger un fichier).

Le faite de cliquer sur ce lien, enverra une demande de connexion à la machine du pirate (requette SYN) qu'elle acceptera pour au finale aboutir à une connexion avec état Established (sur le serveur du pirate et aussi sur le réseau du pc piraté, car c'est pc piraté qui a initiée la connexion).

C'est bien en ce moment là que le firewall de la victime est trompé.

Et ce n'est qu'après ce moment (cet événement) que le virus sera transféré (et non téléchargé par pièce jointe) du pc du pirate vers le pc piraté, grâce à la connexion établie précédemment.

L'antivirus (de la victime) n'est pas fait empêcher une connexion non désiré, mais le pare-feu oui. Sinon, quel est son but ?
Et dans le piège des ronsomware, n'y a t-il pas d'etablissement de connexion non désirée (entre les deux machines ?)

Merci encore pour le partage.

A bientôt

[BufferBob]

pour faire simple, si un paquet arrive depuis dehors avec comme adresse IP source une IP de mon réseau local, le firewall doit être capable de détecter qu'il s'agit d'une tentative de spoofing et bloquer le(s) paquet(s)
en revanche, si une connexion est chiffrée (comme c'est le cas des connexions https), le firewall voit passer des paquets mais il n'est pas capable de lire ce qu'il y a dedans, il n'a aucun élément à priori pour émettre un diagnostique "pour" ou "contre" le blocage de ces paquets

par ailleurs quand le "virus" transite sur le réseau il ne tient pas dans un seul et unique paquet, il est découpé en petits morceaux dans plusieurs paquets qui arrivent dans l'ordre qu'ils veulent, ce n'est que lorsqu'ils sont passés par le driver réseau qu'ils sont dépouillés de leurs headers TCP/IP et que le virus est reconstitué
on ne peut donc identifier un virus qu'une fois qu'il a été écrit en mémoire (pour rappel le disque dur est une mémoire)
du coup ce n'est plus du ressort du firewall, mais de l'antivirus/anti-malware qui va poser des hooks sur les fonctions critiques/pertinentes du système (comme NtCreateThread ou NtWriteVirtualMemory par exemple) et lorsqu'une de ces fonctions sera appellée il ira vérifier le contenu du fichier/de la zone mémoire pour tenter d'identifier un virus connu

quant à l'introduction du virus sur la machine, dans l'absolu il n'y a pas forcément besoin du concours de l'utilisateur, c'est précisément le propos des failles/vulnérabilités dans les programmes, une erreur de programmation fait que le logiciel va dérailler si on lui donne des informations crado (ça peut être une page HTML foireuse, une image volontairement mal faite qui va faire "planter" la lib JPEG sur le pc de la victime, ça peut être tout et n'importe quoi) et ces informations crado contiennent du code machine spécialement conçu pour éviter que le programme plante, télécharger un virus plus gros ou ouvrir une connexion sur le serveur central d'un botnet etc. etc. etc.

mais tout ça n'a rien à voir avec le sujet initial des firewalls stateful, qui plus est chaque firewall est différent et les vulnérabilités qui affectent CheckPoint FW-1 ou Commodo n'affectent pas NetFilter ou WPF et réciproquement, donc en ce qui concerne la vulnérabilité de certains firewalls elle est complètement dépendante de l'implémentation et il convient de se renseigner sur les failles existantes et passées avant d'affirmer quoique ce soit (en général elles sont passées/corrigées très vite)

[transgohan]

Mais le fait de cliquer sur un lien ne signifie pas automatiquement "Téléchargement"

Bien sûr que si.

Si tu cliques sur un lien .html tu vas télécharger la réponse HTTP.
Cette réponse c'est un fichier dans tous les cas.
Après cela peut être une page internet, ou bien un fichier autre suivant le type d'entête retourné par le serveur.
Dans tous les cas quand tu communiques avec quelqu'un tu récupères forcément sa réponse sur ton ordinateur en tant que fichier temporaire ou bien en cache.
Ce qui fait que la seule défense c'est l'antivirus ou l'antimalware. Car le parefeu n'a pas à t'interdire de communiquer, il n'est là que pour bloquer des traffics non souhaités.

[Chuck_Norris]

Après il est aussi important de mentionner que ce n'est pas parce qu'on a une connexion en ETABLISHED sur la machine cible (parce que la cible a cliqué sur le lien) que tu as soudainement le contrôle sur la machine cible !

En effet la connexion se fait sur un port bien déterminé ; derrière ce port il a un logiciel et c'est avec ce logiciel que l'échange est possible, suivant un protocole bien déterminé.

Le protocole en question ne permet pas de manière générale d'avoir le contrôle sur l'ordinateur, sauf bien sûr si c'est le rôle même du protocole (par exemple SSH).

Donc avant de paniquer, il faut savoir que le pare-feu autorisera les connexions sur certains ports, et du coup effectivement le port est ouvert ; mais l'ordinateur n'est pas non plus en danger. Sauf bien sûr s'il y a une faille au niveau du logiciel qui est accessible derrière le port en question. Par exemple une faille sur Apache, qui permettrait de détourner le protocole de manière à provoquer une élévation de privilège.

A ce niveau on peut estimer que l'anti-virus est là quand le pare-feu a laissé passé et que le logiciel a failli.

Après les pare-feu qui se contentent de masquer des ports ne sont pas forcément très utiles sur un serveur. En effet le plus dangereux c'est bien les failles dans les logiciels serveurs. Et seulement les ports requis sont exposés à Internet. Par exemple sous Linux on peut faire écouter MySQL sur l'IP 127.0.0.1, ce qui permet les connexions locales au serveur mais rend le serveur invisible depuis Internet, sans avoir besoin de pare-feu.