Certains ici ont tentés de m'eSpliquer comment il est pas possible de
filtrer les flux, trop de charge toussa, sans vraiment a voir donné d'autres
explication technique que celle que "eux" connaissent le fonctionnement
d'internet et sans avoir le moins du monde rebondit que la répartition de
charge et la mutualisation que représente la technologie a la mode que l'on
nomme le Cloud ...
D'autres, agaces par cette perspective qui pourrait leur donner du boulot
(ce qui les empêcherait de jouer a l'helicoptere dans les couloirs), ont
préférés se moquer.
Je rappelle mon point de vue :
- L'internet devrait être filtré, soit depuis les noeuds majeurs soit depuis
les serveurs des FAI. Cela nettoierait ce qui parvient a notre prise
gigogne** et serait sans doute plus efficace que les misérables applications
clientes que l'on installe sur chaque poste.
** Gigogne car je parle de la France bien sur.
Et bien je suis heureux de vous faire part de ce lien
http://cert.lexsi.com/weblog/index.php/2010/11/05/396-filtrage-2-les-initiatives-de-filtrages-de-malware-par-les-fai
qui indique que je ne suis pas le seul a le penser ;-)
C'est juste dommage que ces grands esprits ne pense qu' en faire une
récupération commerciale (service payant) et que des techniciens "inventent"
des "pop-up pour prévenir le client du FAI qu'il est infecté" de la même
façon que le font des rogues comme la très célèbre série des Win Antivirus
et plus récemment les truc genre registry booster qui inquiètent
l'utilisateur pour lui faire acheter le produit en échange d'une promesse de
nettoyage.
Enfin les rogues ne sont pas nouveau, c'est juste pour donner 1 exemple...
L'idée d'un internet limité, voire scindé en réseaux parallèles et
distincts, est peut être une solution.
Par exemple, tout ce qui est pilotage d'appareils électro
ménager/alarmes/vidéo surveillance ne devrait pas être interconnecté au
reste de l'internet comme le web ou la messagerie qui représentent l'immense
majorité des usage de l'internet pour les particuliers.
De même il ressort de cet article que la tendance est de "dire au client
qu'il est infecté". Personnellement je ne suis pas d'accord, pour être
infectée, la machine du client a reçu les codes malicieux que le FAI lui a
transmis ! Or cela revient a lui dire qu'il est coupable et que c'est a lui
de prendre en charge nettoyage et protection.
C'est l'inverse qui est vrai : le responsable n'est pas l'utilisateur final,
avec son savoir au mieux parcellaire et ses outils, au mieux abordables,
mais celui qui délivre le paquet.
Imagine t on que les avions transporteraient des explosifs dans leurs soutes
?
le 13/12/2010 à 20:18, Stephane Catteau a écrit dans le message :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il suffit juste de chercher la faille. Un peu comme l'absence de réponse sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP soit sous Windows. C'est une information aussi importante à prendre en compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ; C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels comme par exemple la documentation officielle : <http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-HOWTO-5.html>.
-- Benoit Izac
Bonjour,
le 13/12/2010 à 20:18, Stephane Catteau a écrit dans le message
<mn.6cc27dac48bec207.30736@sc4x.org> :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que
l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il
suffit juste de chercher la faille. Un peu comme l'absence de réponse
sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP
soit sous Windows. C'est une information aussi importante à prendre en
compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ;
C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels
comme par exemple la documentation officielle :
<http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-HOWTO-5.html>.
le 13/12/2010 à 20:18, Stephane Catteau a écrit dans le message :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il suffit juste de chercher la faille. Un peu comme l'absence de réponse sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP soit sous Windows. C'est une information aussi importante à prendre en compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ; C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels comme par exemple la documentation officielle : <http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-HOWTO-5.html>.
-- Benoit Izac
Stephane CARPENTIER
Benoit Izac wrote:
Bonjour,
le 13/12/2010 à 20:18, Stephane Catteau a écrit dans le message :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il suffit juste de chercher la faille. Un peu comme l'absence de réponse sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP soit sous Windows. C'est une information aussi importante à prendre en compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ; C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels comme par exemple la documentation officielle : <http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-
HOWTO-5.html>.
Malheureusement, il y a beaucoup trop de sites qui mettent en avant l'absence de réponse au ping. C'est plus facile pour eux de montrer comment croire être invisible que d'expliquer comment sécuriser le bousin de façon intelligente.
Benoit Izac wrote:
Bonjour,
le 13/12/2010 à 20:18, Stephane Catteau a écrit dans le message
<mn.6cc27dac48bec207.30736@sc4x.org> :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que
l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il
suffit juste de chercher la faille. Un peu comme l'absence de réponse
sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP
soit sous Windows. C'est une information aussi importante à prendre en
compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ;
C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels
comme par exemple la documentation officielle :
<http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-
HOWTO-5.html>.
Malheureusement, il y a beaucoup trop de sites qui mettent en avant
l'absence de réponse au ping. C'est plus facile pour eux de montrer comment
croire être invisible que d'expliquer comment sécuriser le bousin de façon
intelligente.
le 13/12/2010 à 20:18, Stephane Catteau a écrit dans le message :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il suffit juste de chercher la faille. Un peu comme l'absence de réponse sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP soit sous Windows. C'est une information aussi importante à prendre en compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ; C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels comme par exemple la documentation officielle : <http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-
HOWTO-5.html>.
Malheureusement, il y a beaucoup trop de sites qui mettent en avant l'absence de réponse au ping. C'est plus facile pour eux de montrer comment croire être invisible que d'expliquer comment sécuriser le bousin de façon intelligente.
Stephane Catteau
Benoit Izac devait dire quelque chose comme ceci :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il suffit juste de chercher la faille. Un peu comme l'absence de réponse sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP soit sous Windows. C'est une information aussi importante à prendre en compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ; C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels comme par exemple la documentation officielle : <http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-HOWTO-5.html>.
Il me semblait que "les bonnes pratiques" avait changée, mais il n'est pas impossible que je me sois trompé. Quoi qu'il en soit, tout bon admin réseau, fut-il amateur, sait que le drop d'une requête mène à un time-out et que celui-ci à une influence sur le réseau, puisque le logiciel à l'origine de la requête attendra patiement le time-out. De même qu'il est censé savoir que le comportement de la pile IP est au contraire de répondre que le port est fermé. En conséquence de quoi, si lors d'un scan il y a alternance de RST et de time-out, il faut en déduire[1] que les ports qui génèrent le time-out sont filtrés, ce qui implique un service à l'écoute derrière, et que le filtre IP est aux mains d'une personne qui ne sait pas forcément ce qu'elle fait. Pour autant cela ne veut pas dire qu'il y aura une faille quelque part, mais cela reste une indication utile.
[1] La déduction ne doit pas être immédiate évidement, d'autres facteurs entre en ligne de compte et il faut les vérifier d'abord.
Benoit Izac devait dire quelque chose comme ceci :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que
l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il
suffit juste de chercher la faille. Un peu comme l'absence de réponse
sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP
soit sous Windows. C'est une information aussi importante à prendre en
compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ;
C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels
comme par exemple la documentation officielle :
<http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-HOWTO-5.html>.
Il me semblait que "les bonnes pratiques" avait changée, mais il n'est
pas impossible que je me sois trompé.
Quoi qu'il en soit, tout bon admin réseau, fut-il amateur, sait que le
drop d'une requête mène à un time-out et que celui-ci à une influence
sur le réseau, puisque le logiciel à l'origine de la requête attendra
patiement le time-out. De même qu'il est censé savoir que le
comportement de la pile IP est au contraire de répondre que le port est
fermé.
En conséquence de quoi, si lors d'un scan il y a alternance de RST et
de time-out, il faut en déduire[1] que les ports qui génèrent le
time-out sont filtrés, ce qui implique un service à l'écoute derrière,
et que le filtre IP est aux mains d'une personne qui ne sait pas
forcément ce qu'elle fait. Pour autant cela ne veut pas dire qu'il y
aura une faille quelque part, mais cela reste une indication utile.
[1]
La déduction ne doit pas être immédiate évidement, d'autres facteurs
entre en ligne de compte et il faut les vérifier d'abord.
Benoit Izac devait dire quelque chose comme ceci :
C'est beaucoup plus simple que ça, bloquer (tout) ICMP c'est dire que l'on ne connait rien du tout à la configuration d'un filtre IP et qu'il suffit juste de chercher la faille. Un peu comme l'absence de réponse sur les ports bloqués signifie qu'il y a 90% de chance que le filtre IP soit sous Windows. C'est une information aussi importante à prendre en compte que les autres.
Je croyais que la plupart des utilisateurs d'iptables utilisait DROP ; C'est en tous cas c'est ce que l'on peut voir dans de nombreux tutoriels comme par exemple la documentation officielle : <http://www.netfilter.org/documentation/HOWTO/fr/packet-filtering-HOWTO-5.html>.
Il me semblait que "les bonnes pratiques" avait changée, mais il n'est pas impossible que je me sois trompé. Quoi qu'il en soit, tout bon admin réseau, fut-il amateur, sait que le drop d'une requête mène à un time-out et que celui-ci à une influence sur le réseau, puisque le logiciel à l'origine de la requête attendra patiement le time-out. De même qu'il est censé savoir que le comportement de la pile IP est au contraire de répondre que le port est fermé. En conséquence de quoi, si lors d'un scan il y a alternance de RST et de time-out, il faut en déduire[1] que les ports qui génèrent le time-out sont filtrés, ce qui implique un service à l'écoute derrière, et que le filtre IP est aux mains d'une personne qui ne sait pas forcément ce qu'elle fait. Pour autant cela ne veut pas dire qu'il y aura une faille quelque part, mais cela reste une indication utile.
[1] La déduction ne doit pas être immédiate évidement, d'autres facteurs entre en ligne de compte et il faut les vérifier d'abord.
Stephane Catteau
Stephane CARPENTIER devait dire quelque chose comme ceci :
Malheureusement, il y a beaucoup trop de sites qui mettent en avant l'absence de réponse au ping. C'est plus facile pour eux de montrer comment croire être invisible que d'expliquer comment sécuriser le bousin de façon intelligente.
Il suffit de voir le succès du test de Steve Gibson[1] et comment il présente les résultats pour s'en convaincre. Tout d'abord il y a le beau tableau en trois couleurs, rouge pour les ports ouverts, bleu pour les ports non ouverts et vert pour les ports dit "stealth", c'est-à-dire les ports qui time-out. Lorsque je fais le test c'est tout bleu, alors que la couleur du succes c'est vert non ? Seulement voilà, si le filtre IP envoie un RST (pour TCP), il n'est pas possible de différencier un port non ouvert d'un port filtré, il n'y a donc aucune information à fournir. L'utilisateur ne veut pas entendre, "regardez, vous ne voyez rien, c'est normal", mais quelque chose comme "vous voyez, ça marche".
Qui plus est, parce que justement c'est tout bleu chez moi, j'ai droit à un beau "FAILED" : "Solicited TCP Packets: RECEIVED (FAILED) — As detailed in the port report below, one or more of your system's ports actively responded to our deliberate attempts to establish a connection. It is generally possible to increase your system's security by hiding it from the probes of potentially hostile hackers." <traduction vite fait> Paquets TCP demandés : Reçu (Echec) - Comme détaillé dans le magnifique dessin au dessus, un ou plusieurs des ports a répondu à notre demande de connexion. Il est généralement possible d'accroitre la sécurité de votre système en les cachant des tentatives de découverte de la part des vilains garçons. </> Par "répondu à notre demande", il veut dire qu'un RST a été reçu, puisqu'aucun port n'est marqué comme ouvert dans son graph.
Même chose pour le ping, la machine répondant, il considère que c'est un échec. Il va même plus loin : "Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers." <traduction vite fait> Votre système répond aux ping, ce qui rend votre machine visible sur le réseau. La plus part des filtre IP permettent de bloquer, droper ou ignorer ces requêtes de façon à mieux se cacher des vilains garçons." </>
Hum, excusez-moi de vous déranger monsieur Gibson, mais les RFC n'indiquent-elles pas qu'en cas d'absence de la machine cible, le dernier routeur doit renvoyer un ICMP 3-1 (host unreachable/machine injoignable) pour toute requête ICMP et UDP ? Une absence de réponse indique donc la présence d'une machine, aussi surement que le ferait une réponse.
[1] <https://www.grc.com/x/ne.dll?rh1dkyd2>
Stephane CARPENTIER devait dire quelque chose comme ceci :
Malheureusement, il y a beaucoup trop de sites qui mettent en avant
l'absence de réponse au ping. C'est plus facile pour eux de montrer comment
croire être invisible que d'expliquer comment sécuriser le bousin de façon
intelligente.
Il suffit de voir le succès du test de Steve Gibson[1] et comment il
présente les résultats pour s'en convaincre.
Tout d'abord il y a le beau tableau en trois couleurs, rouge pour les
ports ouverts, bleu pour les ports non ouverts et vert pour les ports
dit "stealth", c'est-à-dire les ports qui time-out. Lorsque je fais le
test c'est tout bleu, alors que la couleur du succes c'est vert non ?
Seulement voilà, si le filtre IP envoie un RST (pour TCP), il n'est pas
possible de différencier un port non ouvert d'un port filtré, il n'y a
donc aucune information à fournir. L'utilisateur ne veut pas entendre,
"regardez, vous ne voyez rien, c'est normal", mais quelque chose comme
"vous voyez, ça marche".
Qui plus est, parce que justement c'est tout bleu chez moi, j'ai droit
à un beau "FAILED" :
"Solicited TCP Packets: RECEIVED (FAILED) — As detailed in the port
report below, one or more of your system's ports actively responded to
our deliberate attempts to establish a connection. It is generally
possible to increase your system's security by hiding it from the
probes of potentially hostile hackers."
<traduction vite fait>
Paquets TCP demandés : Reçu (Echec) - Comme détaillé dans le magnifique
dessin au dessus, un ou plusieurs des ports a répondu à notre demande
de connexion. Il est généralement possible d'accroitre la sécurité de
votre système en les cachant des tentatives de découverte de la part
des vilains garçons.
</>
Par "répondu à notre demande", il veut dire qu'un RST a été reçu,
puisqu'aucun port n'est marqué comme ouvert dans son graph.
Même chose pour le ping, la machine répondant, il considère que c'est
un échec. Il va même plus loin :
"Your system REPLIED to our Ping (ICMP Echo) requests, making it
visible on the Internet. Most personal firewalls can be configured to
block, drop, and ignore such ping requests in order to better hide
systems from hackers."
<traduction vite fait>
Votre système répond aux ping, ce qui rend votre machine visible sur
le réseau. La plus part des filtre IP permettent de bloquer, droper ou
ignorer ces requêtes de façon à mieux se cacher des vilains garçons."
</>
Hum, excusez-moi de vous déranger monsieur Gibson, mais les RFC
n'indiquent-elles pas qu'en cas d'absence de la machine cible, le
dernier routeur doit renvoyer un ICMP 3-1 (host unreachable/machine
injoignable) pour toute requête ICMP et UDP ? Une absence de réponse
indique donc la présence d'une machine, aussi surement que le ferait
une réponse.
Stephane CARPENTIER devait dire quelque chose comme ceci :
Malheureusement, il y a beaucoup trop de sites qui mettent en avant l'absence de réponse au ping. C'est plus facile pour eux de montrer comment croire être invisible que d'expliquer comment sécuriser le bousin de façon intelligente.
Il suffit de voir le succès du test de Steve Gibson[1] et comment il présente les résultats pour s'en convaincre. Tout d'abord il y a le beau tableau en trois couleurs, rouge pour les ports ouverts, bleu pour les ports non ouverts et vert pour les ports dit "stealth", c'est-à-dire les ports qui time-out. Lorsque je fais le test c'est tout bleu, alors que la couleur du succes c'est vert non ? Seulement voilà, si le filtre IP envoie un RST (pour TCP), il n'est pas possible de différencier un port non ouvert d'un port filtré, il n'y a donc aucune information à fournir. L'utilisateur ne veut pas entendre, "regardez, vous ne voyez rien, c'est normal", mais quelque chose comme "vous voyez, ça marche".
Qui plus est, parce que justement c'est tout bleu chez moi, j'ai droit à un beau "FAILED" : "Solicited TCP Packets: RECEIVED (FAILED) — As detailed in the port report below, one or more of your system's ports actively responded to our deliberate attempts to establish a connection. It is generally possible to increase your system's security by hiding it from the probes of potentially hostile hackers." <traduction vite fait> Paquets TCP demandés : Reçu (Echec) - Comme détaillé dans le magnifique dessin au dessus, un ou plusieurs des ports a répondu à notre demande de connexion. Il est généralement possible d'accroitre la sécurité de votre système en les cachant des tentatives de découverte de la part des vilains garçons. </> Par "répondu à notre demande", il veut dire qu'un RST a été reçu, puisqu'aucun port n'est marqué comme ouvert dans son graph.
Même chose pour le ping, la machine répondant, il considère que c'est un échec. Il va même plus loin : "Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers." <traduction vite fait> Votre système répond aux ping, ce qui rend votre machine visible sur le réseau. La plus part des filtre IP permettent de bloquer, droper ou ignorer ces requêtes de façon à mieux se cacher des vilains garçons." </>
Hum, excusez-moi de vous déranger monsieur Gibson, mais les RFC n'indiquent-elles pas qu'en cas d'absence de la machine cible, le dernier routeur doit renvoyer un ICMP 3-1 (host unreachable/machine injoignable) pour toute requête ICMP et UDP ? Une absence de réponse indique donc la présence d'une machine, aussi surement que le ferait une réponse.
