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 05/12/2010 à 12:45, Aeris a écrit dans le message <4cfb7b56$0$24495$ :
Petite remarque en passant, Postfix ne fait pas serveur IMAP.
Pardon j'ai fourché, il s'agit bien de SMTP
SMTP est normalisé. Je pensais que tu comparais le protocole propriétaire d'Exchange (que je ne connais pas) et celui d'IMAP (qui est normalisé aussi) qui ne sont effectivement pas compatibles.
-- Benoit Izac
Bonjour,
le 05/12/2010 à 12:45, Aeris <aeris@imirhil.fr> a écrit dans le message
<4cfb7b56$0$24495$426a74cc@news.free.fr> :
Petite remarque en passant, Postfix ne fait pas serveur IMAP.
Pardon j'ai fourché, il s'agit bien de SMTP
SMTP est normalisé. Je pensais que tu comparais le protocole
propriétaire d'Exchange (que je ne connais pas) et celui d'IMAP (qui est
normalisé aussi) qui ne sont effectivement pas compatibles.
le 05/12/2010 à 12:45, Aeris a écrit dans le message <4cfb7b56$0$24495$ :
Petite remarque en passant, Postfix ne fait pas serveur IMAP.
Pardon j'ai fourché, il s'agit bien de SMTP
SMTP est normalisé. Je pensais que tu comparais le protocole propriétaire d'Exchange (que je ne connais pas) et celui d'IMAP (qui est normalisé aussi) qui ne sont effectivement pas compatibles.
-- Benoit Izac
Aeris
Kevin Denis wrote:
"Cette catégorie d'équipements doit donc être capable d'encaisser d'importants débits (plusieurs Gbits/s), de gérer plusieurs centaines de sessions simultanées et d'analyser à un niveau applicatif les flux pour ensuite les classifier."
Niveau applicatif, j'appelle ça du DPI.
Le but du CleanPipe est uniquement de nettoyer un flux d'une attaque DDOS. Il ne s'agit que d'une mesure temporaire et les analyses à effectuer sont très limitées dans le cadre d'un DDOS.
A la limite une simple comparaison binaire des paquets avec un paquet de référence (n'importe quel paquet de la session DDOS fait l'affaire) peut suffir, les paquets de DDOS étant généralement tous les mêmes (même URL appelée, même port attaqué, etc).
En plus de cela, la réaction en cas de détection d'un paquet DDOS est aussi très simple: black-holing du destinataire pour toute la durée du DDOS. A la limite, iptables avec l'option --string peut très bien faire ce travail.
Et puis la latence générée par le pseudo-DPI n'est pas génant dans ce cas: il vaut mieux un site qui rame qu'un site HS tout court!
Une autre différence est que la protection ne concerne que 1 seul serveur ou un groupe de serveurs, donc un flux extrèmement limité.
Pour finir, le nombre de protocoles de la couche 7 à connaître est très limité. Il n'y a que les protocoles servi par le serveur à analyser, HTTP uniquement suffit pour nettoyer 90% du flux des serveurs.
Certes, appelle ça du DPI si tu veux, mais on est très loin du vrai DPI sujet de cette discussion qui doit cibler tous les protocoles, pour une durée illimitée, avec des critères d'analyses extrèment fins et dynamiques et sur un trafic concernant des millions d'usagers et à destination de tous les serveurs d'Internet.
Kevin Denis wrote:
"Cette catégorie d'équipements doit donc être capable d'encaisser
d'importants débits (plusieurs Gbits/s), de gérer plusieurs centaines
de sessions simultanées et d'analyser à un niveau applicatif les
flux pour ensuite les classifier."
Niveau applicatif, j'appelle ça du DPI.
Le but du CleanPipe est uniquement de nettoyer un flux d'une attaque DDOS.
Il ne s'agit que d'une mesure temporaire et les analyses à effectuer sont
très limitées dans le cadre d'un DDOS.
A la limite une simple comparaison binaire des paquets avec un paquet de
référence (n'importe quel paquet de la session DDOS fait l'affaire) peut
suffir, les paquets de DDOS étant généralement tous les mêmes (même
URL appelée, même port attaqué, etc).
En plus de cela, la réaction en cas de détection d'un paquet DDOS est aussi
très simple: black-holing du destinataire pour toute la durée du DDOS.
A la limite, iptables avec l'option --string peut très bien faire ce
travail.
Et puis la latence générée par le pseudo-DPI n'est pas génant dans ce cas:
il vaut mieux un site qui rame qu'un site HS tout court!
Une autre différence est que la protection ne concerne que 1 seul serveur ou
un groupe de serveurs, donc un flux extrèmement limité.
Pour finir, le nombre de protocoles de la couche 7 à connaître est très
limité. Il n'y a que les protocoles servi par le serveur à analyser, HTTP
uniquement suffit pour nettoyer 90% du flux des serveurs.
Certes, appelle ça du DPI si tu veux, mais on est très loin du vrai
DPI sujet de cette discussion qui doit cibler tous les protocoles, pour une
durée illimitée, avec des critères d'analyses extrèment fins et dynamiques
et sur un trafic concernant des millions d'usagers et à destination de
tous les serveurs d'Internet.
"Cette catégorie d'équipements doit donc être capable d'encaisser d'importants débits (plusieurs Gbits/s), de gérer plusieurs centaines de sessions simultanées et d'analyser à un niveau applicatif les flux pour ensuite les classifier."
Niveau applicatif, j'appelle ça du DPI.
Le but du CleanPipe est uniquement de nettoyer un flux d'une attaque DDOS. Il ne s'agit que d'une mesure temporaire et les analyses à effectuer sont très limitées dans le cadre d'un DDOS.
A la limite une simple comparaison binaire des paquets avec un paquet de référence (n'importe quel paquet de la session DDOS fait l'affaire) peut suffir, les paquets de DDOS étant généralement tous les mêmes (même URL appelée, même port attaqué, etc).
En plus de cela, la réaction en cas de détection d'un paquet DDOS est aussi très simple: black-holing du destinataire pour toute la durée du DDOS. A la limite, iptables avec l'option --string peut très bien faire ce travail.
Et puis la latence générée par le pseudo-DPI n'est pas génant dans ce cas: il vaut mieux un site qui rame qu'un site HS tout court!
Une autre différence est que la protection ne concerne que 1 seul serveur ou un groupe de serveurs, donc un flux extrèmement limité.
Pour finir, le nombre de protocoles de la couche 7 à connaître est très limité. Il n'y a que les protocoles servi par le serveur à analyser, HTTP uniquement suffit pour nettoyer 90% du flux des serveurs.
Certes, appelle ça du DPI si tu veux, mais on est très loin du vrai DPI sujet de cette discussion qui doit cibler tous les protocoles, pour une durée illimitée, avec des critères d'analyses extrèment fins et dynamiques et sur un trafic concernant des millions d'usagers et à destination de tous les serveurs d'Internet.
Nicolas George
Eric Masson , dans le message , a écrit :
Et tiens, une petite phrase anodine que tu devrais lire et essayer de comprendre : "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety"
Je lui avais cité la même une des dernières fois où il avait fait sa crise, sans effet notable.
Eric Masson , dans le message
<32ass7-edv.ln1@srvbsdfenssv.interne.associated-bears.org>, a écrit :
Et tiens, une petite phrase anodine que tu devrais lire et essayer de
comprendre :
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety"
Je lui avais cité la même une des dernières fois où il avait fait sa crise,
sans effet notable.
Et tiens, une petite phrase anodine que tu devrais lire et essayer de comprendre : "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety"
Je lui avais cité la même une des dernières fois où il avait fait sa crise, sans effet notable.
Aeris
Az Sam wrote:
les paquetes sont reassembles et le fichier est scanné dans son enesemble. Seuls les octets d'en tete et d'encpsulation de transport lié au protocole Ethernet sont eliminés. Le dpi a donc cette charge/fichiers supplementaire c'est vrai.
Non, il n'y a pas que les en-têtes. Le réassemblage est totalement impossible au niveau routeur! Déjà un routeur peut ne pas vour passen tous les morceaux, routage dynamique oblige. Ensuite, tu imagines si chaque routeur devait reconstituer ta vidéo Youtube ou ton .exe de 4Mo? Déjà il devrait se taper exactement le même téléchargement que toi donc avoir une quantité pharamineuse de RAM (oui, tu n'es pas le seul à télécharger…) et ne pourrait te transmettre le paquet qu'une fois qu'il l'a lui même téléchargé intégralemet au lieu d'envoyer les paquets au fil de l'eau. Et ça CHAQUE routeur devra le réaliser! Une vidéo Youtube de 2min, 8 routeurs = 16 min avant de voir la moindre image!
Avec les debits actuels, la puissance de calcul actuelle, la rapidite des bus actuelle et les espaces de stockage actuels, on peu se permettre de ralentir un peu la mise a disposition vers l'internaute final et on peut se permettre de realiser ce travail.
Un peu? Si tu appelles « un peu » des latences de l'ordre de la 20aine de minutes…
Pour les boucliers web, le site est betement comparé a une liste noire, ca ne coute rien. Tous les AV avec cette fonction on un avantage sur ceux ne la possedant pas.
Même pour faire de la détection d'URL, cela nécessite de réassempler les paquets. Et oui, l'URL n'est pas dans les en-têtes IP…
De meme que l'on remplit nos hosts avec des adresses ou des nomls de domaines, tout cela pourrait/devrait etre en place deja chez le FAI.
Cette protection est totalement inutile car contournable en 8h par les pirates (TTL moyen des DNS). C'est pour cela qu'ils veulent des botnets…
Le pki devrait aussi deja etre en place par le FAI, comme le WPa2 par exemple.
Je ne vois pas ce que vient faire WPA2 ici. Nous on te parle de la connexion avec ta banque ou le site du Trésor Public. Ton FAI n'a pas à connaître ces clés de cryptage et n'a donc aucun moyen de décrypter ces flux.
Si ce systeme de filtrage est insufisant pour les echanges confidentiels, il reste l'idee d'une scission en reseaux distincts, dont l'un d'eux au moins serait VERITABLEMENT securisé en fonction de ce qu'il transporte.
Et tu crois vraiment que les pirates n'iront pas sur ce réseau? Si tout le trafic bancaire est sur un réseau différent, tes pirates n'ont plus rien à faire sur le réseau kikoolol. Ton réseau kikoolol sera donc très sûr et ton réseau sécuritaire extrèmement dangeureux, sans parler qu'il facilite la vie des pirates (tout le flux est intéressant) et empêche le travail du DPI (tout le flux risque fort d'être crypté).
Le Cloud, il le vendent comment ? par pré commande ? Ils achèteront le matériel (et le bâtiment) et brancherons la prise quand ils auront atteint leur quota de rentabilité ?
Oula, tu rèves toi. Je ne connaît aucune entreprise qui va acheter du matos et des infrastuctures en se disant que ça servira plus tard / toujours.
non, tu veux du Cloud, tu l'a immédiatement, les ressources sont déjà dispo. Donc en attendant que tu l'achètes, elles dorment (restent sous exploitées si tu préfères)...
Non, en attendant que tu les achètes, c'est un autre client qui les utilise… C'est tout le principe du Cloud! D'ailleurs la plupart du temps le Cloud repose sur de la virtualisation, et le virtualiseur tourne bien H24!
Le Cloud est un gros mot hein. Ça n'a strictement rien changé à ce qui se faisait déjà avant. Sauf que ça fait plus classe de dire « Cloud » que « SaS », « Cluster » ou « Virtualisation ».
Az Sam wrote:
les paquetes sont reassembles et le fichier est scanné dans son enesemble.
Seuls les octets d'en tete et d'encpsulation de transport lié au protocole
Ethernet sont eliminés. Le dpi a donc cette charge/fichiers supplementaire
c'est vrai.
Non, il n'y a pas que les en-têtes.
Le réassemblage est totalement impossible au niveau routeur!
Déjà un routeur peut ne pas vour passen tous les morceaux, routage dynamique
oblige.
Ensuite, tu imagines si chaque routeur devait reconstituer ta vidéo Youtube
ou ton .exe de 4Mo? Déjà il devrait se taper exactement le même
téléchargement que toi donc avoir une quantité pharamineuse de RAM (oui, tu
n'es pas le seul à télécharger…) et ne pourrait te transmettre le paquet
qu'une fois qu'il l'a lui même téléchargé intégralemet au lieu d'envoyer les
paquets au fil de l'eau. Et ça CHAQUE routeur devra le réaliser!
Une vidéo Youtube de 2min, 8 routeurs = 16 min avant de voir la moindre
image!
Avec les debits actuels, la puissance de calcul actuelle, la rapidite des
bus actuelle et les espaces de stockage actuels, on peu se permettre de
ralentir un peu la mise a disposition vers l'internaute final et on peut
se permettre de realiser ce travail.
Un peu? Si tu appelles « un peu » des latences de l'ordre de la 20aine de
minutes…
Pour les boucliers web, le site est betement comparé a une liste noire, ca
ne coute rien. Tous les AV avec cette fonction on un avantage sur ceux ne
la possedant pas.
Même pour faire de la détection d'URL, cela nécessite de réassempler les
paquets. Et oui, l'URL n'est pas dans les en-têtes IP…
De meme que l'on remplit nos hosts avec des adresses ou
des nomls de domaines, tout cela pourrait/devrait etre en place deja chez
le FAI.
Cette protection est totalement inutile car contournable en 8h par les
pirates (TTL moyen des DNS). C'est pour cela qu'ils veulent des botnets…
Le pki devrait aussi deja etre en place par le FAI, comme le WPa2 par
exemple.
Je ne vois pas ce que vient faire WPA2 ici.
Nous on te parle de la connexion avec ta banque ou le site du Trésor Public.
Ton FAI n'a pas à connaître ces clés de cryptage et n'a donc aucun moyen de
décrypter ces flux.
Si ce systeme de filtrage est insufisant pour les echanges confidentiels,
il reste l'idee d'une scission en reseaux distincts, dont l'un d'eux au
moins serait VERITABLEMENT securisé en fonction de ce qu'il transporte.
Et tu crois vraiment que les pirates n'iront pas sur ce réseau?
Si tout le trafic bancaire est sur un réseau différent, tes pirates n'ont
plus rien à faire sur le réseau kikoolol.
Ton réseau kikoolol sera donc très sûr et ton réseau sécuritaire extrèmement
dangeureux, sans parler qu'il facilite la vie des pirates (tout le flux est
intéressant) et empêche le travail du DPI (tout le flux risque fort d'être
crypté).
Le Cloud, il le vendent comment ? par pré commande ?
Ils achèteront le matériel (et le bâtiment) et brancherons la prise quand
ils auront atteint leur quota de rentabilité ?
Oula, tu rèves toi.
Je ne connaît aucune entreprise qui va acheter du matos et des
infrastuctures en se disant que ça servira plus tard / toujours.
non, tu veux du Cloud, tu l'a immédiatement, les ressources sont déjà
dispo. Donc en attendant que tu l'achètes, elles dorment (restent sous
exploitées si tu préfères)...
Non, en attendant que tu les achètes, c'est un autre client qui les utilise…
C'est tout le principe du Cloud!
D'ailleurs la plupart du temps le Cloud repose sur de la virtualisation, et
le virtualiseur tourne bien H24!
Le Cloud est un gros mot hein. Ça n'a strictement rien changé à ce qui se
faisait déjà avant. Sauf que ça fait plus classe de dire « Cloud » que « SaS
», « Cluster » ou « Virtualisation ».
les paquetes sont reassembles et le fichier est scanné dans son enesemble. Seuls les octets d'en tete et d'encpsulation de transport lié au protocole Ethernet sont eliminés. Le dpi a donc cette charge/fichiers supplementaire c'est vrai.
Non, il n'y a pas que les en-têtes. Le réassemblage est totalement impossible au niveau routeur! Déjà un routeur peut ne pas vour passen tous les morceaux, routage dynamique oblige. Ensuite, tu imagines si chaque routeur devait reconstituer ta vidéo Youtube ou ton .exe de 4Mo? Déjà il devrait se taper exactement le même téléchargement que toi donc avoir une quantité pharamineuse de RAM (oui, tu n'es pas le seul à télécharger…) et ne pourrait te transmettre le paquet qu'une fois qu'il l'a lui même téléchargé intégralemet au lieu d'envoyer les paquets au fil de l'eau. Et ça CHAQUE routeur devra le réaliser! Une vidéo Youtube de 2min, 8 routeurs = 16 min avant de voir la moindre image!
Avec les debits actuels, la puissance de calcul actuelle, la rapidite des bus actuelle et les espaces de stockage actuels, on peu se permettre de ralentir un peu la mise a disposition vers l'internaute final et on peut se permettre de realiser ce travail.
Un peu? Si tu appelles « un peu » des latences de l'ordre de la 20aine de minutes…
Pour les boucliers web, le site est betement comparé a une liste noire, ca ne coute rien. Tous les AV avec cette fonction on un avantage sur ceux ne la possedant pas.
Même pour faire de la détection d'URL, cela nécessite de réassempler les paquets. Et oui, l'URL n'est pas dans les en-têtes IP…
De meme que l'on remplit nos hosts avec des adresses ou des nomls de domaines, tout cela pourrait/devrait etre en place deja chez le FAI.
Cette protection est totalement inutile car contournable en 8h par les pirates (TTL moyen des DNS). C'est pour cela qu'ils veulent des botnets…
Le pki devrait aussi deja etre en place par le FAI, comme le WPa2 par exemple.
Je ne vois pas ce que vient faire WPA2 ici. Nous on te parle de la connexion avec ta banque ou le site du Trésor Public. Ton FAI n'a pas à connaître ces clés de cryptage et n'a donc aucun moyen de décrypter ces flux.
Si ce systeme de filtrage est insufisant pour les echanges confidentiels, il reste l'idee d'une scission en reseaux distincts, dont l'un d'eux au moins serait VERITABLEMENT securisé en fonction de ce qu'il transporte.
Et tu crois vraiment que les pirates n'iront pas sur ce réseau? Si tout le trafic bancaire est sur un réseau différent, tes pirates n'ont plus rien à faire sur le réseau kikoolol. Ton réseau kikoolol sera donc très sûr et ton réseau sécuritaire extrèmement dangeureux, sans parler qu'il facilite la vie des pirates (tout le flux est intéressant) et empêche le travail du DPI (tout le flux risque fort d'être crypté).
Le Cloud, il le vendent comment ? par pré commande ? Ils achèteront le matériel (et le bâtiment) et brancherons la prise quand ils auront atteint leur quota de rentabilité ?
Oula, tu rèves toi. Je ne connaît aucune entreprise qui va acheter du matos et des infrastuctures en se disant que ça servira plus tard / toujours.
non, tu veux du Cloud, tu l'a immédiatement, les ressources sont déjà dispo. Donc en attendant que tu l'achètes, elles dorment (restent sous exploitées si tu préfères)...
Non, en attendant que tu les achètes, c'est un autre client qui les utilise… C'est tout le principe du Cloud! D'ailleurs la plupart du temps le Cloud repose sur de la virtualisation, et le virtualiseur tourne bien H24!
Le Cloud est un gros mot hein. Ça n'a strictement rien changé à ce qui se faisait déjà avant. Sauf que ça fait plus classe de dire « Cloud » que « SaS », « Cluster » ou « Virtualisation ».
Kevin Denis
Le 05-12-2010, Aeris a écrit :
"Cette catégorie d'équipements doit donc être capable d'encaisser d'importants débits (plusieurs Gbits/s), de gérer plusieurs centaines de sessions simultanées et d'analyser à un niveau applicatif les flux pour ensuite les classifier."
Niveau applicatif, j'appelle ça du DPI.
Le but du CleanPipe est uniquement de nettoyer un flux d'une attaque DDOS.
Dans cet exemple donné par l'auteur du blog. Néanmoins, cela prouve que ces équipements existent, sont mis en oeuvre et savent faire de l'analyse niveau7 pendant un DDoS. Dernier DDOS dont on parle, celui de wikileaks. 10Gb/s. Cela donne donc un ordre de grandeur de ce que ces machines peuvent encaisser et filtrer au niveau applicatif.
L'auteur du post de blog explique même qu'il faut choisir son équipement selon plusieurs critères (utilisabilité, coût, perfs, etc..). Donc cela prouve qu'il y a de l'offre, et des acheteurs, qui sont les FAIs.
Conclusion: la DPI est une réalité _aujourd'hui_.
Pour finir, le nombre de protocoles de la couche 7 à connaître est très limité. Il n'y a que les protocoles servi par le serveur à analyser, HTTP uniquement suffit pour nettoyer 90% du flux des serveurs.
et des clients.
Certes, appelle ça du DPI si tu veux, mais on est très loin du vrai DPI sujet de cette discussion qui doit cibler tous les protocoles,
qui dit ça? Le DPI est un outil qui n'est pas censé s'appliquer partout. Pourquoi cette condition? La protection parfaite n'existe pas. Si le DPI filtre le HTTP/SMTP alors ça sera "suffisant".
Ecoutes les parlementaires pendant les discussions hadopi. "si ça bloque 80% du trafic illégal alors ça va". Le but est seulement de diminuer le problème, pas de l'éradiquer. Et un DPI HTTP/SMTP qui touche 80% des clients ne sera pas efficace à 100% (par construction) mais me pose suffisement de problèmes (éthiques, etc..)
pour une durée illimitée, avec des critères d'analyses extrèment fins et dynamiques et sur un trafic concernant des millions d'usagers
16millions d'abonnés ADSL en france. Divisé par le nombre de FAI. Ca me parait être des ordres de grandeurs gérables. -- Kevin
Le 05-12-2010, Aeris <aeris@imirhil.fr> a écrit :
"Cette catégorie d'équipements doit donc être capable d'encaisser
d'importants débits (plusieurs Gbits/s), de gérer plusieurs centaines
de sessions simultanées et d'analyser à un niveau applicatif les
flux pour ensuite les classifier."
Niveau applicatif, j'appelle ça du DPI.
Le but du CleanPipe est uniquement de nettoyer un flux d'une attaque DDOS.
Dans cet exemple donné par l'auteur du blog.
Néanmoins, cela prouve que ces équipements existent, sont mis en oeuvre
et savent faire de l'analyse niveau7 pendant un DDoS.
Dernier DDOS dont on parle, celui de wikileaks. 10Gb/s. Cela donne donc
un ordre de grandeur de ce que ces machines peuvent encaisser et
filtrer au niveau applicatif.
L'auteur du post de blog explique même qu'il faut choisir son équipement
selon plusieurs critères (utilisabilité, coût, perfs, etc..). Donc cela
prouve qu'il y a de l'offre, et des acheteurs, qui sont les FAIs.
Conclusion: la DPI est une réalité _aujourd'hui_.
Pour finir, le nombre de protocoles de la couche 7 à connaître est très
limité. Il n'y a que les protocoles servi par le serveur à analyser, HTTP
uniquement suffit pour nettoyer 90% du flux des serveurs.
et des clients.
Certes, appelle ça du DPI si tu veux, mais on est très loin du vrai
DPI sujet de cette discussion qui doit cibler tous les protocoles,
qui dit ça? Le DPI est un outil qui n'est pas censé s'appliquer partout.
Pourquoi cette condition?
La protection parfaite n'existe pas. Si le DPI filtre le HTTP/SMTP
alors ça sera "suffisant".
Ecoutes les parlementaires pendant les discussions hadopi. "si ça bloque
80% du trafic illégal alors ça va". Le but est seulement de diminuer
le problème, pas de l'éradiquer. Et un DPI HTTP/SMTP qui touche 80% des
clients ne sera pas efficace à 100% (par construction) mais me pose
suffisement de problèmes (éthiques, etc..)
pour une
durée illimitée, avec des critères d'analyses extrèment fins et dynamiques
et sur un trafic concernant des millions d'usagers
16millions d'abonnés ADSL en france. Divisé par le nombre de FAI.
Ca me parait être des ordres de grandeurs gérables.
--
Kevin
"Cette catégorie d'équipements doit donc être capable d'encaisser d'importants débits (plusieurs Gbits/s), de gérer plusieurs centaines de sessions simultanées et d'analyser à un niveau applicatif les flux pour ensuite les classifier."
Niveau applicatif, j'appelle ça du DPI.
Le but du CleanPipe est uniquement de nettoyer un flux d'une attaque DDOS.
Dans cet exemple donné par l'auteur du blog. Néanmoins, cela prouve que ces équipements existent, sont mis en oeuvre et savent faire de l'analyse niveau7 pendant un DDoS. Dernier DDOS dont on parle, celui de wikileaks. 10Gb/s. Cela donne donc un ordre de grandeur de ce que ces machines peuvent encaisser et filtrer au niveau applicatif.
L'auteur du post de blog explique même qu'il faut choisir son équipement selon plusieurs critères (utilisabilité, coût, perfs, etc..). Donc cela prouve qu'il y a de l'offre, et des acheteurs, qui sont les FAIs.
Conclusion: la DPI est une réalité _aujourd'hui_.
Pour finir, le nombre de protocoles de la couche 7 à connaître est très limité. Il n'y a que les protocoles servi par le serveur à analyser, HTTP uniquement suffit pour nettoyer 90% du flux des serveurs.
et des clients.
Certes, appelle ça du DPI si tu veux, mais on est très loin du vrai DPI sujet de cette discussion qui doit cibler tous les protocoles,
qui dit ça? Le DPI est un outil qui n'est pas censé s'appliquer partout. Pourquoi cette condition? La protection parfaite n'existe pas. Si le DPI filtre le HTTP/SMTP alors ça sera "suffisant".
Ecoutes les parlementaires pendant les discussions hadopi. "si ça bloque 80% du trafic illégal alors ça va". Le but est seulement de diminuer le problème, pas de l'éradiquer. Et un DPI HTTP/SMTP qui touche 80% des clients ne sera pas efficace à 100% (par construction) mais me pose suffisement de problèmes (éthiques, etc..)
pour une durée illimitée, avec des critères d'analyses extrèment fins et dynamiques et sur un trafic concernant des millions d'usagers
16millions d'abonnés ADSL en france. Divisé par le nombre de FAI. Ca me parait être des ordres de grandeurs gérables. -- Kevin
Aeris
Jean-Francois BILLAUD wrote:
Sasser (à quoi d'insister contre l'évidence ?) JFB
Sasser ne peut se propager que si l'utilisateur a ouvert son port 445. Or tout firewall digne de ce nom devrait bloquer tous les ports par défaut et n'ouvrir que les ports nécesaires. Sur une machine bureautique standard, il n'y a aucune raison d'avoir un seul port en écoute accessible depuis le web. La contamination par Sasser résulte donc uniquement d'un défaut de connaissance et de bonnes pratiques.
Je suis connecté à Internet et mon firewall doit bloquer un truc comme
une attaque à la minute
Alors le firewall est mal configurer. Il devrait bloquer l'ensemble des ports par défaut et fonctionner en mode black-hole, sauf sur les ports réellement asociés à un service qui doit être accessible par Internet (web, ssh, smtp, etc), ce qui est extrèmement rare sur une machine bureautique.
Exemple avec iptables
iptables -t filter -P INPUT DROP iptables -t filter -P OUTPUT DROP iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport http -j ACCEPT
Avec ça je suis un véritable trou noir vu du net et aucune attaque ne peut venir de l'extérieur (sauf faille dans le pare-feu) sans m'empécher l'accès à Internet.
Jean-Francois BILLAUD wrote:
Sasser (à quoi d'insister contre l'évidence ?)
JFB
Sasser ne peut se propager que si l'utilisateur a ouvert son port 445.
Or tout firewall digne de ce nom devrait bloquer tous les ports par défaut
et n'ouvrir que les ports nécesaires.
Sur une machine bureautique standard, il n'y a aucune raison d'avoir un seul
port en écoute accessible depuis le web.
La contamination par Sasser résulte donc uniquement d'un défaut de
connaissance et de bonnes pratiques.
Je suis connecté à Internet et mon firewall doit bloquer un truc comme
une attaque à la minute
Alors le firewall est mal configurer.
Il devrait bloquer l'ensemble des ports par défaut et fonctionner en mode
black-hole, sauf sur les ports réellement asociés à un service qui doit être
accessible par Internet (web, ssh, smtp, etc), ce qui est extrèmement rare
sur une machine bureautique.
Exemple avec iptables
iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport http -j ACCEPT
Avec ça je suis un véritable trou noir vu du net et aucune attaque ne peut
venir de l'extérieur (sauf faille dans le pare-feu) sans m'empécher l'accès
à Internet.
Sasser (à quoi d'insister contre l'évidence ?) JFB
Sasser ne peut se propager que si l'utilisateur a ouvert son port 445. Or tout firewall digne de ce nom devrait bloquer tous les ports par défaut et n'ouvrir que les ports nécesaires. Sur une machine bureautique standard, il n'y a aucune raison d'avoir un seul port en écoute accessible depuis le web. La contamination par Sasser résulte donc uniquement d'un défaut de connaissance et de bonnes pratiques.
Je suis connecté à Internet et mon firewall doit bloquer un truc comme
une attaque à la minute
Alors le firewall est mal configurer. Il devrait bloquer l'ensemble des ports par défaut et fonctionner en mode black-hole, sauf sur les ports réellement asociés à un service qui doit être accessible par Internet (web, ssh, smtp, etc), ce qui est extrèmement rare sur une machine bureautique.
Exemple avec iptables
iptables -t filter -P INPUT DROP iptables -t filter -P OUTPUT DROP iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport http -j ACCEPT
Avec ça je suis un véritable trou noir vu du net et aucune attaque ne peut venir de l'extérieur (sauf faille dans le pare-feu) sans m'empécher l'accès à Internet.
Tout à fait, mais encore une fois il s'agit d'une mauvaise configuration. Les bons lecteurs de mail (thunderbird, kontact…) bloquent le HTML et les références externes par défaut
Stephane CARPENTIER wrote:
Et dans ce cas cette affirmation est discutable.
Tout à fait, mais encore une fois il s'agit d'une mauvaise configuration.
Les bons lecteurs de mail (thunderbird, kontact…) bloquent le HTML et les
références externes par défaut
Tout à fait, mais encore une fois il s'agit d'une mauvaise configuration. Les bons lecteurs de mail (thunderbird, kontact…) bloquent le HTML et les références externes par défaut
Aeris
Benoit Izac wrote:
SMTP est normalisé. Je pensais que tu comparais le protocole propriétaire d'Exchange (que je ne connais pas) et celui d'IMAP (qui est normalisé aussi) qui ne sont effectivement pas compatibles
Au niveau SMTP, Exchange n'est pas conforme à la norme. La fermeture de la connexion est parfois erronée (pas de caractère de fin de ligne et socket fermé sans attendre l'acquitement)
Au niveau IMAP, oui ils ne sont pas standard aussi
Benoit Izac wrote:
SMTP est normalisé. Je pensais que tu comparais le protocole
propriétaire d'Exchange (que je ne connais pas) et celui d'IMAP (qui est
normalisé aussi) qui ne sont effectivement pas compatibles
Au niveau SMTP, Exchange n'est pas conforme à la norme.
La fermeture de la connexion est parfois erronée (pas de caractère de fin de
ligne et socket fermé sans attendre l'acquitement)
Au niveau IMAP, oui ils ne sont pas standard aussi
SMTP est normalisé. Je pensais que tu comparais le protocole propriétaire d'Exchange (que je ne connais pas) et celui d'IMAP (qui est normalisé aussi) qui ne sont effectivement pas compatibles
Au niveau SMTP, Exchange n'est pas conforme à la norme. La fermeture de la connexion est parfois erronée (pas de caractère de fin de ligne et socket fermé sans attendre l'acquitement)
Au niveau IMAP, oui ils ne sont pas standard aussi
