Resultados 1 a 8 de 8
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,000

    [FR] OVH inclui proteção DDoS em todos os planos

    Bonjour,
    Il y a 2-3 mois nous avons annoncé les travaux sur les
    protections Anti-DDoS:
    http://forum.ovh.com/showthread.php?t=89081

    Depuis nous avons travaillé sur la mise en place de ces
    protections dans le but de vous offrir un service par
    défaut, non limité dans le temps, non limité en taille
    de l'attaque ni en type de l'attaque. Nous avons mis en
    place 3 infrastructures qu'on appelle "VAC" qui ont une
    capacité 480Gbps/480Mpps couplées à la backbone où nous
    avons plus de 2Tbps de bande passante excédentaire pour
    recevoir les attaques puis les mitiger.

    C'est beaucoup mais dans les protections Anti-DDoS il
    n'y a pas de marketing. Soit ça fonctionne et ça tient
    soit tout est en panne. Nous avons donc voulu protéger
    vos serveurs sans mettre en panne notre backbone ni
    les autres clients. Et donc il fallait concevoir une
    protection qui est capable de vous protéger contre
    n'importe laquelle attaque. Bref, il fallait voir grand
    dés le départ. A ce jour, nous avons la plus grande
    infrastructure de mitigation qui a été publiquement
    annoncée, probablement parce que nous sommes les seuls
    sur le marché à pratiquer la transparence même lorsqu'il
    s'agit de sujets aussi sensibles que les attaques DDoS.

    Le défi que nous nous sommes lancé a été de concevoir
    une infrastructure de mitigation capable de prendre les
    attaques de de 0.5Tbps tout en la proposant à un prix
    incroyablement pas cher: le target a été mis à +1e/mois
    par service. Nous avons remis en question les solutions
    techniques pour une fois encore innover et faire autrement,
    plus grand, moins cher et plus rapidement.

    En effet, à l'opposé du marché, nous estimons que les
    protections Anti-DDoS doivent faire parti du service
    inclue et protéger totalement tous les clients, sans
    exception et sans difference de service réellement proposé.
    On ne voulait pas avoir des options payantes sur l'Anti-DDoS
    car le nombre d'attaque depuis 2 ans a fortement augmenté,
    et on ne peut plus réellement se dire que d'être à l'abri.

    Il y a 2 mois nous avons annoncé que nous avons choisi de
    mutualiser les coûts du service Anti-DDoS sur tous les
    clients et de réduire l'augmentation de prix de service pour
    les anciens clients comme pour les nouveaux. Nous sommes
    heureux de vous annoncer que nous avons pu tenir cet engagement.

    A partir d'aujourd'hui, le service Anti-DDoS passe en STABLE
    et nous intégrons le coût d'Anti-DDoS dans le prix pour les
    services suivants:

    VPS
    ===
    - VPS: +0.5e/mois

    Serveurs dédiés
    ===============
    - KS: +1.0e/mois
    - SP: +1.0e/mois
    - FS: +1.0e/mois
    - EG: +2.0e/mois
    - MG: +2.0e/mois
    - mHG: +3.0e/mois
    - HG: +3.0e/mois

    pCC
    ===
    - host S +2.0e/mois
    - host S++ +2.0e/mois
    - host M +2.0e/mois
    - host L +2.0e/mois
    - host L+ +2.0e/mois
    - host L++ +2.0e/mois
    - host L2 +3.0e/mois
    - host L2+ +3.0e/mois
    - host XL +3.0e/mois
    - host XL+ +3.0e/mois

    Ainsi, tous ces services ont la protection Anti-DDoS qui
    protège contre toutes les attaques et sans limitation.

    Pour un paiement annuel du serveur, nous avons mis en place
    une remise équivalente au montant annuel de l'augmentation
    du prix.

    Nous avons mis au point 3 innovations exclusives que
    nous avons inclue dans l'utilisation professionnelle:

    - la mitigation permanente, au lieu d'auto-mitigation
    c'est à dire qu'il est possible d'activer la mitigation
    24/24 au lieu de laisser Ovh détecter les attaques,
    activer la mitigation et la désactiver après l'attaque.

    - le firewall network qui permet d'autoriser tous les
    ports où vous avez le service et bloquer tout le reste.

    - l'accès aux l'archive de flux qui sont passés par le
    VAC sur 7J avec une possibilité d'extraction des logs
    pour l'analyse avec les informations sur ce qui a été
    bloqué et ce qui a été accepté.

    Comme annoncé, le prix de l'utilisation professionnelle
    sur le EG et le MG passe de 15e/mois à 30e/mois. Aucun
    changement sur le SP et le HG.

    Pour les VPS, les KS et le pCC qui n'ont pas l'utilisation
    pro, nous allons proposer l'option "Anti-DDoS PRO" dans
    quelques jours.

    En terme de SLA, nous ajoutons l'engagement en terme
    de temps de détection de l'attaque et de la mise sous
    l'auto-mitigation qui est inférieur à 90 secondes.

    En savoir plus sur les protections Anti-DDoS:
    Anti-DDoS : Nos solutions Anti-DDoS - OVH

    Amicalement
    Octave

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,000
    Octave Klaba, fondateur et directeur général d'OVH.com, revient en détail sur le nouveau service de protection contre les attaques DDoS que l'hébergeur a mis au point.


    Pourquoi avez-vous fait évoluer la protection anti-DDoS chez OVH ?

    Suite à l’affaire Wikileaks, les Anonymous ont mis en évidence certaines faiblesses de l’Internet. En démocratisant les attaques DDoS, ils ont démontré qu’il est très facile de faire tomber un site web. Certains adolescents ont trouvé ainsi un nouveau type de jeux vidéo où l’arme est le LOIC (Low Orbit Ion Cannon) et la cible est un site web prestigieux.


    Et comment cela se passait-il avant ?

    Avant 2011, les attaques DDoS étaient très souvent lancées par des groupes de hackers pour récupérer un réseau de robots (botnet) en reprenant la main sur un serveur IRC. Aussi, nous avons eu des clients attaqués par un groupe de cybercriminels payés par leurs concurrents. Le but était de faire tomber le site web et de récupérer les visiteurs.


    S’agit-il d’une activité mafieuse ?

    Comme dans la vraie vie, les attaques DDoS sur Internet ont été et seront toujours liées au cyberbanditisme. Ces attaques sont réalisées par des hommes qui sont payés pour faire ce job. Et en face, il faut mettre les hommes qui vont protéger les infrastructures des clients. On refait le monde tel qu’il est aujourd’hui mais sur le Net.


    Comment les protections ont-elles évolué ?

    Jusqu’en 2011, les protections anti-DDoS se basant sur la limitation de certains types de trafic par IP source ou/et IP destination permettaient ainsi de limiter 99 attaques sur 100. Les protections étaient disponibles pour tout le monde et ne coûtaient rien aux clients. Après 2011, beaucoup de nouvelles personnes ont été initiées aux DDoS et se sont intéressées à cette activité.


    Quelles ont été les conséquences ?

    La démocratisation des attaques. Les nouveaux types d’attaques ont été écrits et déployés sur l’Internet. Puis enfin les sites web permettant d’acheter ces ressources pour générer une attaque vers une cible durant 5 minutes ou 10 minutes. Pour un oui ou un non, n’importe qui avec un compte Paypal peut aujourd’hui lancer une attaque vers une cible. À notre niveau nous avons vu qu’à partir de fin 2012, nos protections n’étaient plus assez efficaces pour bloquer ces nouveaux types d’attaques.

  3. #3
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,000
    Comment avez-vous fait pour protéger à nouveau vos clients ?

    Nous avons toujours voulu voir les protections Anti-DDoS comme un service standard et non comme une option. Se protéger contre toutes sortes d’attaques ne doit pas être un luxe que seuls certains clients peuvent se payer. En même temps, avec des protections anti-DDoS efficaces, nos clients sont la cible d’attaques de plus en plus fortes, différentes et illimitées dans le temps, parce que les hackers s'adaptent et augmentent la taille de leurs attaques en conséquence. Donc il fallait prévoir gros dès le départ.


    Cette équation paraît impossible à résoudre…

    À première vue, oui, c’est impossible. Mais si les investissements sont mutualisés sur tous les clients, le prix du service anti-DDoS par client restera faible. L’idée est donc de faire le contraire de tous nos concurrents, ne pas proposer une option chère, mais intégrer le service anti-DDoS dans le prix du service. L’objectif initial était d’augmenter le prix général de seulement 1 euro par mois.


    Combien les infrastructures anti-DDoS coûtent-elles ?

    Si on utilisait uniquement les solutions du marché, il faudrait investir environ 2 millions d’euros pour 100 Gbps/100 Mpps de protection. Aujourd’hui une capacité de protection de 100Gbps n’est pas suffisante. Puis nous avons cinq zones de datacentres : Paris (P19, GSW, DC1), Roubaix (RBX), Strasbourg (SBG), Gravelines (GRA), les quatre en France et la zone Montréal (BHS) en Amérique du Nord.


    Il faudrait alors investir cinq fois 2 millions d’euros pour avoir une protection dans tous vos datacentres ?

    En effet, il aurait fallu investir environ 10 millions d’euros pour avoir 500 Gbps/500 Mpps de capacité totale capable de protéger nos cinq zones de datacentres. Si nous ajoutons l’équipe support 24/24, cela se traduirait par une augmentation de prix, non pas de 1 euro par mois par serveur, mais d’environ 10 euros par mois. Beaucoup trop importante à nos yeux.


    Pourquoi tous les clients doivent-ils payer alors que seuls certains en ont besoin ?

    Les protections anti-DDoS concernent tous les clients. Si un client est visé par une attaque, il y a des effets de bord sur ses voisins de baie, puis finalement sur un sous-réseau, un routeur, puis enfin pourquoi pas sur le datacentre complet. On pourrait même imaginer les attaques en effet de bord : pour atteindre une cible on attaque ses voisins. Bref, la probabilité d’une attaque, justifiée ou effet de bord, est réelle. Payer une sorte d’assurance de 1 euro par mois pour ne pas avoir à gérer ce genre de problème nous a semblé une excellente idée de mutualisation de risques et de coûts.


    Revenons à la technique, comment avez-vous fait finalement ?

    Depuis 2011, nous avons développé quelques fonctionnalités réseau, sans aucun rapport avec le DDoS, sur les puces Tilera. Il s’agit des processeurs avec 48 ou 64 cores programmables et qui permettent d’obtenir le même niveau de performance que les algorithmes écrits en hardware sur les ASIC* (Application Specific Integrated Circuit).


    Pourquoi Tilera a-t-il changé l’équation de protection anti-DDoS ?

    En termes d’investissement, au lieu de 2 millions d’euros pour 100 Gbps/100 Mpps, il faut compter 75 000 euros pour obtenir la même capacité de protection ! Les coûts d’investissement sont réduits par 26 ! C’est juste énorme. Mais les boîtiers Tilera fournissent simplement du hardware capable de gérer beaucoup de paquets par seconde. Il n’y a aucun software dessus et il faut tout écrire depuis le début avec des développeurs pointus


    Combien de temps faut-il pour réécrire tout sous Tilera ?

    Deux ans. C’est beaucoup et nos clients n'avaient pas le temps d’attendre autant de temps pour profiter de protections anti-DDOS. Nous nous sommes donc concentrés sur les protections anti-DDoS qui permettent de bloquer les attaques les plus gourmandes en bande passante. Nous avons ainsi réduit le temps de développement à 2 mois.


    Et pour tous les autres type d’attaques ?

    Et pour le reste qui ne nécessite pas de grosse capacité de bande passante, nous utilisons les solutions standards du marché. Notre valeur ajoutée a été d’imaginer et de mettre en place ce mix de technologies qui permet de réduire l’investissement et qui rend la protection anti-DDoS accessible à tous.


    Hum, un mix... ?! Expliquez-nous ?

    En effet, nous avons fait un mix de plusieurs technologies dans le but d’avoir une protection d’environ 500 Gbps/500 Mpps, accessible pour nos clients, c’est-à-dire à environ 1 euro par mois supplémentaire et disponible en 3 à 6 mois. Nous avons aussi choisi de déployer trois infrastructures anti-DDoS dans trois zones et de protéger les deux autres zones à travers ces trois zones.


    Où avez-vous déployé les infrastructures anti-DDoS ?

    Nous avons mis en place une protection de 160 Gbps à Strasbourg (SBG), Roubaix (RBX) et Montreal (BHS). Soit 480 Gbps en tout. En cas d’attaque sur une IP à Paris ou Gravelines, mais aussi vers une IP à Roubaix, Strasbourg ou Beauharnois, le trafic est nettoyé sur les trois infrastructures en même temps.


    D’où vient le nom « VAC » ?

    Chaque infrastructure de 160 Gbps est appelée « VAC ». Le VAC vient de « vacuum », aspirateur en anglais. Nous avons le VAC1, le VAC2 et le VAC3 dans trois endroits différents de l’Europe et de l'Amérique du Nord. Les trois VAC travaillent en parallèle en gérant toutes les attaques vers tous les clients.


    Comment les attaques sont-elles gérées ?

    Si l’attaque vient de l’Europe centrale et de l’Est, comme de Russie, Pologne, Roumanie, Italie, Suisse et Allemagne, elle est aspirée par le VAC2 qui se situe à Strasbourg. Si l’attaque vient de l’Europe de l’Ouest et du Nord c’est-à-dire de France, de Belgique, des Pays-Bas, du Royaume-Uni ou d’Espagne, elle est gérée par le VAC1 qui se situe à Roubaix. Enfin si l’attaque vient d'Amérique du Nord, d’Amérique du Sud, d’Asie et d'Australie, elle passe par le VAC3 qui se situe dans la zone de Montréal (BHS) au Québec.


    De quelles tailles sont les attaques que vous recevez ?

    Avant de parler de la taille des attaques, il faut que le réseau ait un excédent de capacité pour pouvoir accepter l’attaque et la rediriger sur les VAC. Si l’attaque est très forte, une belle infrastructure anti-DDoS ne servira à rien, puisque le réseau va saturer en amont et le service sera dégradé pour tous les clients.


    Quelle est la capacité du réseau d’OVH ?

    Aujourd’hui nous avons environ 2,5 Tbps de capacité d’interconnexion entre notre réseau et Internet. À la fin de l’année nous aurons 3,5 Tbps et nous pensons qu’à la fin de 2014 nous devrions avoir 5 Tbps.


    Oui mais le réseau est déjà utilisé par tous les clients, non ?

    Oui, mais notre réseau est exploité dans le sens « OVH vers Internet ». Or les attaques nous arrivent dans le sens « Internet vers OVH ». En un mot, nous disposons réellement d’une capacité excédentaire supérieure à 2 Tbps dans le sens qui nous intéresse pour gérer les attaques DDoS.


    Donc, quelle est la taille des attaques que vous gérez ?

    Nous recevons parfois des attaques à destination de nos clients dont la taille dépasse 70-80 Gbps. Ce type d’attaque est mitigé sans problème et le client ne voit aucun impact sur le service.


    Comment assurez-vous que les opérateurs avec lesquels vous êtes connectés ne sont pas, eux, limités en termes de capacité réseau ?

    La capacité excédentaire de plus de 2 Tbps est répartie dans 20 PoP (points de présence) disséminés en Europe et en Amérique du Nord. Paris, Francfort, Varsovie, Amsterdam, Madrid, New York, Chicago, Los Angeles, Miami... où notre réseau est physiquement présent. Dans ces PoP, nous avons des liens avec différents opérateurs.


    Et alors ?

    Une attaque DDoS qui vient de milliers d’IP sources arrive de toutes les parties du monde. À l’opposé de nos concurrents, on ne concentre pas l’arrivée de l’attaque sur notre réseau via un PoP dans une ville. Chez nous, une attaque DDoS entre sur notre réseau au plus près de la source de l’attaque, c’est-à-dire via Miami, via Los Angeles, via Toronto, via Prague, via Vienne, via Madrid, via Paris, etc. L’attaque utilise ainsi toutes les capacités du réseau déployé partout dans le monde, ne sature ni les opérateurs en face, ni notre réseau. Et ensuite, elle est aspirée et nettoyée par le VAC le plus proche.

    En quoi le nettoyage de l’attaque consiste-t-il ?

    Le VAC est composé de plusieurs équipements en série qui regardent tous chaque paquet IP, puis décident en fonction du contenu du paquet s’il est légitime, si c’est un paquet lié à l’attaque ou s’il faut déclencher un algorithme d'authentification du paquet.




    Que se passe-t-il dans ces trois cas ?

    Dans le cas d’un paquet légitime, le paquet est accepté et routé vers l’équipement suivant, puis le dernier équipement du VAC le redirige vers le serveur du client. Dans le cas d’un paquet qui, à l’évidence, fait partie de l’attaque, le paquet IP est effacé. Dans le troisième cas, il s’agit des paquets qu’il faut authentifier puisqu’il peut s’agir d’un paquet légitime ou d’un paquet de l’attaque. Le VAC déclenche alors un algorithme d’authentification pour savoir ce qu’il doit faire.
    Última edição por 5ms; 03-09-2013 às 11:36.

  4. #4
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,000
    Un exemple ?

    Par exemple, nous utilisons un algorithme appelé « Syn Auth » pour bloquer les attaques de type Synflood qui consistent à envoyer plein de paquets SYN avec des IP source spoofées (usurpées). Le fonctionnement est le suivant : quand le VAC reçoit un paquet SYN, il l’efface et envoie à l’IP source un paquet RST qui ré-initie la connexion de l’IP source. Ce mécanisme standard de reprise de connexion est interprété par l’IP source, et il répond avec un nouveau paquet SYN contenant le même numéro de la séquence SYN que le premier paquet. Le VAC se souvient du premier paquet et constate que le deuxième paquet renvoie le même numéro de séquence. Conséquence : l’IP source est ajoutée sur la « white list » du VAC durant une heure. Toutes les connexions à partir de l’IP source vers l’IP de destination sont automatiquement acceptées. Par contre si l’IP source renvoie à nouveau des paquets SYN qui n’ont aucun rapport avec les paquets précédents, le VAC fait exactement le même algorithme pour tous ces paquets SYN et donc efface tous les paquets SYN. L’attaque est ainsi bloquée et les paquets légitimes continuent à passer.


    N’y a-t-il pas de faux positifs avec cet algorithme ?

    En dehors du client « SSH » qui rejoue la séquence correctement mais qui ne sait pas refaire ensuite la nouvelle connexion automatiquement, tous les autres clients TCP gèrent sans aucun problème cet algorithme.


    Que faut-il faire alors avec le SSH ?

    Il suffit de relancer le client « SSH » une deuxième fois et la connexion se fait.


    Ce n’est pas vraiment propre.

    C’est la contrepartie du choix que le client a fait en activant l’option « mitigation permanente ». En effet, si le client choisit d’être protégé 24/24, la mitigation fonctionne tout le temps. Et étant donné que le SSH est utilisé exclusivement par le client pour administrer le serveur, c’est un compromis qu’il a choisi d’avoir sur son serveur.



    Sinon peut-il choisir l’auto-mitigation ?

    Oui, dans le cas de l’auto-mitigation, OVH détecte l’attaque puis active l’aspiration sur les VAC. Après la fin de l’attaque, OVH arrête la mitigation 15 minutes. A la place de 15 minutes, le client peut choisir « immédiatement », « 1H », « 6H » ou « 26H ». Dans le cas de la « mitigation permanente », le client choisit d’utiliser le VAC 24/24.


    Avec la mitigation permanente que se passe-t-il en cas d’attaque ?

    Si le client a activé la mitigation permanente et s’il y a, réellement, une attaque, nous la détectons et activons de notre côté l’auto-mitigation, en plus de la mitigation permanente. Il n’y a aucun changement dans le fonctionnement, mais si durant l’attaque le client désactive la mitigation permanente, la mitigation continue quand même grâce à l’auto-mitigation.


    Quelle est la différence entre anti-DDoS et anti-DDoS Pro ?

    En Pro, le client dispose de la mitigation permanente. Il a aussi le Firewall Network qui lui permet d’autoriser certaines IP ou applications à se connecter sur le serveur et de bloquer tout le reste. Enfin, nous stockons toutes les informations sur les flux qui ont été acceptés et effacés par le VAC pour chaque IP mitigée et ceci durant 7 jours. Le client peut ainsi récupérer un échantillon de ce flux en choisissant la date et l’heure puis le nombre de lignes à récupérer. C’est un service à très haute valeur ajoutée pour analyser une attaque a posteriori.


    C’est tout ?

    Oui, c’est tout, mais c’est énorme. OVH est le seul sur le marché à proposer de la mitigation permanente pour l’ensemble de ses services. La mitigation permanente est très coûteuse puisqu’elle utilise les ressources du VAC 24/24, même quand il n’y a pas d’attaque. Dans le cas de l’auto-mitigation, le client utilise les ressources d’une protection anti-DDOS uniquement durant l’attaque.


    Mais en termes de qualité de la mitigation, y-a-t-il une différence dans les deux offres ?

    En ce qui concerne le service lui-même, il est strictement identique. Par défaut et en Pro, le client dispose de toutes les protections contre toutes les attaques, quelle que soit la durée de l’attaque, quelle que soit la taille de l’attaque et quel que soit le type de l'attaque. Nous intégrons dans le service les alertes avec le début de la mitigation, la fin de la mitigation, les rapports des mitigations avec les courbes du trafic qui est entré sur le VAC et est sorti du VAC. Nous ajoutons aussi un échantillon de 10 lignes du trafic qui a été effacé et qui a été accepté.


    Quelle est la capacité du VAC ?

    Notre réseau excédentaire a une capacité supérieure à 2 Tbps. Nous avons 3 VAC en production et donc nous savons gérer jusqu’à 480 Gbps/480 Mpps.


    Combien de temps le développement a-t-il duré ?

    Les tests du VAC1 et le développement sur Tilera ont duré trois mois. Suite à la validation du premier VAC, nous avons lancé le déploiement des deux VAC suivants. Le tout réalisé en cinq mois.


    Cinq mois, ce n’est pas une grande expérience?

    Nous gérons les attaques depuis le premier jour d’OVH, soit depuis 14 ans, aussi bien au niveau de la backbone, des serveurs dédiés que de l’hébergement mutualisé. Nous avons une très longue expérience dans les protections L7 des sites Web contre toutes sortes d’attaques appréciatives. Nous développons en interne le software qui fait les protections L3/L4 que nous tournons sur les Tilera. Pour écrire un algorithme qui s'exécute jusqu’à 10 millions de fois par seconde sur chaque port 10G de Tilera, il faut savoir coder mais aussi savoir comment fonctionne l’Internet dans le détail de chaque paquet. Enfin, si un client utilise l’auto-mitigation et si elle est buggée, mal réglée ou tout simplement ne fonctionne pas bien, le client ne le voit pas forcement puisque la mitigation est activée uniquement durant l’attaque, soit quelques minutes par ici ou par là. Avec la mitigation permanente, nous gérons des cas très complexes, pour des clients très différents qui ont des services tous différents. C’est une expérience que nos concurrents ne peuvent pas avoir puisqu’ils ne font que de l’auto-mitigation.


    Quels sont les résultats ?

    Durant les bêtas, nous avons cherché les bons réglages et nous avons pu vérifier le bon fonctionnement global du VAC. Nous avons ensuite affiné les réglages avec les cas particuliers de certains clients et nous les avons intégrés dans la configuration finale. Nous avons aussi fixé des bugs. Les VAC fonctionnent désormais parfaitement bien.


    Et au niveau du Manager ?

    Le VAC est couplé à l’API v6 qui permet d’automatiser les mitigations. Ajouter les nouvelles règles Firewall Network, activer la mitigation, la désactiver sur une IP ou toutes les IP se fait très simplement avec l’API v6. En parallèle, le Manager rattrape les fonctionnalités disponibles dans l’API v6 pour les rendre utilisables via de simples clics.


    Quelle est la suite ?

    Le VAC actuel est une protection unidirectionnelle, alias asymétrique et certaines attaques nécessitent une protection bidirectionnelle, alias symétrique.


    Expliquez-nous la différence ?

    En unidirectionnel, le VAC aspire uniquement les paquets dans le sens "Internet vers le serveur du client", mais laisse le serveur répondre dans l'autre sens directement. Pour toutes les protections de niveau L3/L4 c'est parfait, vérifier les checksum de paquets … Si on parle de la couche 7 (L7) par exemple le Web, on ne parle plus uniquement de l'entête du paquet IP ou du contenu du premier paquet, mais on parle de la connexion qui se compose de plusieurs dizaines de paquets.


    Comment l'algorithme fonctionne-t-il dans ce cas-là ?

    La décision de savoir si c’est une attaque ou pas ne peut parfois être prise qu'après la connexion. Pour mitiger en unidirectionnel du L7, le VAC doit donc autoriser l’attaque à arriver sur le serveur du client pour ensuite déterminer si la connexion est légitime ou pas. Les ressources du serveur sont donc prises par l’attaque pour être libérées ensuite seulement.


    Quelle est la solution pour éviter cela ?

    Les protections bi-directionnelles c’est-à-dire symétriques. Nous travaillons actuellement sur la mise en place de protection L7 WebB et DNS activables « on the fly » sans aucune reconfiguration sur le serveur du client et qui permettent de bloquer les attaques applicatives, comme par exemple un DDoS sur une URL d’un site ou le slowloris qui consiste à ouvrir un maximum de connexions sur un serveur, puis à écrire tout doucement la requête. On sait mitiger ce genre d’attaques sur notre infrastructure et ne laisser passer jusqu’au serveur que les connexions légitimes.


    Quand cette protection sera-t-elle disponible ?

    Les bêtas sont en cours et nous pensons que le service sera STABLE pour la fin du mois de septembre et disponible pour le Web/SSL. Ensuite, nous allons travailler sur le DNS et peut-être d’autres protocoles.


    Le monde des Fournisseurs d’Infrastructures Internet (FII) a donc changé ?

    Nous faisons en effet bouger les lignes sur ce marché en rendant la protection anti-DDoS accessible à tous les clients alors qu’habituellement c’est un service qui est hors de prix. Une fois encore, nous l’avons fait en remettant en cause les technologies utilisées et en mettant en œuvre une solution technique innovante, totalement différente et qui répond mieux aux besoins de nos clients en termes de prix et de capacité de mitigation.


    http://www.ovh.com/fr/a1164.protecti...rvice-standard
    Última edição por 5ms; 03-09-2013 às 11:39.

  5. #5
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,000

    The anti-DDoS protection is a standard service, not an option

    Octave Klaba, founder and CEO of OVH. Com, returns in detail on the new service protection against DDoS attacks that the host has developed.


    Why did you change the anti-DDoS protection OVH?

    Following the Wikileaks case, the Anonymous revealed some weaknesses in the Internet. Democratizing DDoS attacks, they have shown that it is very easy to get a website. Some teens and found a new type of game where the weapon is the LOIC (Low Orbit Ion Cannon) and the target is a prestigious website.


    And how this happened before?

    Prior to 2011, DDoS attacks were often launched by groups of hackers to get a botnet (botnet) by taking hold of an IRC server. Also, we have had clients attacked by a group of criminals paid by their competitors. The aim was to bring down the website and get visitors.


    Is it a mafia activity?

    As in real life, DDoS attacks on the Internet have been and will always be linked to cyberbanditisme. These attacks are carried out by men who are paid to do this job. And face it, there must be men who will protect customer infrastructures. The world as it is today, but on the Net is redone.


    How protections have evolved?

    Until 2011, the anti-DDoS protection based on the limitation of certain types of traffic by IP source and / or destination IP and allowed limit of 100 99 attacks. The protections were available to everyone and cost nothing to customers. After 2011, many new people were introduced to DDoS and are interested in this activity.


    What were the consequences?

    The democratization of attacks. New types of attacks have been written and deployed on the Internet. Then finally the websites to purchase these resources to generate an attack to a target for 5 minutes or 10 minutes. For a yes or a no, anyone with a Paypal account can now launch an attack towards a target. At our level we saw at the end of 2012, our coverage was not effective enough to block these new types of attacks.


    How did you do to protect your new customers?

    We always wanted to see the Anti-DDoS protection as a standard service, not as an option. Protect themselves against all kinds of attacks should not be a luxury that only some customers can afford. At the same time, with effective anti-DDoS protection, our customers are under attack more and more strong, different and unlimited in time, because hackers adapt and increase the size of their attacks accordingly. So it was necessary to provide big from the start.


    This equation seems impossible to solve ...

    At first glance, yes, it's impossible. But if the investments are shared on all customers, the price of anti-DDoS service customer will remain low. The idea is to do the opposite of all of our competitors do not offer an expensive option, but integrate the anti-DDoS service in the service price. The initial objective was to increase the overall price of just 1 euro per month.


    How anti-DDoS infrastructure cost?

    If market solutions were used alone, it would invest around € 2 million to 100 million pps Gbps/100 protection. Today a protection capacity of 100Gbps is not sufficient. Then we have five areas of data centers: Paris (P19, GSW, DC1), Roubaix (RBX), Strasbourg (SBG), Gravelines (GRA), four in France and Montreal area (BHS) in North America.


    It would then invest five times 2 million for protection in all your data center?

    Indeed, it would have to invest about 10 million euros for 500 Mpps Gbps/500 total capacity capable of protecting our five areas of data centers. If we add the support team 24/24, this would result in a price increase, not one euro per month per server, but about 10 euros per month. Far too important to us.


    Why all the customers have to pay while only some need?

    Anti-DDoS protections apply to all customers. If a client is referred by an attack, there are side effects on neighboring bay, and finally on a subnet, a router, and finally why not on the entire data center. One could even imagine the attacks side effect: to reach a target attack on its neighbors. In short, the probability of an attack, justified or side effect is real. Pay a kind of insurance of 1 euro per month for not having to deal with this kind of problem seemed an excellent idea of pooling of risks and costs.


    Returning to the technique, how did you finally?

    Since 2011, we have developed some network features unrelated to the DDoS on the Tilera chips. These processors with 48 or 64 programmable cores and that achieve the same level of performance as the algorithms written in hardware on * ASIC (Application Specific Integrated Circuit).


    Tilera why he changed the equation of anti-DDoS protection?

    In terms of investment, instead of 2 million euros to 100 million pps Gbps/100, it takes 75 000 euros for the same protection capacity! The investment costs are reduced by 26! It's just huge. But Tilera boxes simply provide hardware can handle many packets per second. There is no software on it and you have to write everything from scratch with sharp developers


    How long does it take to rewrite everything under Tilera?

    Two years. That's a lot, and our clients do not have time to wait so long to take anti-DDOS protection. We therefore focused on the anti-DDoS protection which block the most demanding bandwidth attacks. We cut development time in two months.


    And for all other types of attacks?

    And for the rest who do not require large bandwidth capacity, we use the standard market solutions. Our added value was to imagine and implement the mix of technologies that reduces investment and making the anti-DDoS protection for all.

    Um, a mix ... ! Explain?

    In fact, we have a mix of technologies in order to have protection of approximately 500 Mpps Gbps/500 accessible for our customers, that is to say approximately 1 per additional month available 3 to 6 months. We also chose to deploy three anti-DDoS infrastructure in three areas and to protect the other two zones across these three areas.


    Where have you deployed DDoS infrastructure?

    We have implemented a protection of 160 Gbps in Strasbourg (SBG), Roubaix (RBX) and Montreal (BHS). Or 480 Gbps in total. In case of an attack on a Paris or IP Gravelines, but also to an IP in Roubaix, Strasbourg and Beauharnois, traffic is cleaned on three infrastructure at the same time.


    Where does the name "VAC"?

    Each 160 Gbps infrastructure is called "VAC". VAC has "vacuum" cleaner English. We MAV1, MAV2 and MAV3 in three different locations in Europe and North America. The three VAC work in parallel by managing all attacks to all clients.


    How attacks are they managed?

    If the attack comes from Central and Eastern Europe, such as Russia, Poland, Romania, Italy, Switzerland and Germany, it is drawn by the MAV2 which is in Strasbourg. If the attack comes from Western Europe and North that is to say, France, Belgium, the Netherlands, the United Kingdom and Spain, it is managed by the MAV1 that is located in Roubaix. Finally, if the attack comes from North America, South America, Asia and Australia, it goes through the MAV3 which lies in the area of Montreal (BHS) in Quebec.


    What sizes are the attacks that you receive?

    Before talking about the size of attacks, it is necessary that the network has excess capacity in order to accept the attack and redirect it to the VAC. If the attack is very strong, a good anti-DDoS infrastructure will not help, since the network will saturate upstream and service will be degraded for all customers.


    What is the capacity of the OVH network?

    Today we have about 2.5 Tbps of capacity interconnection between our network and the Internet. At the end of the year we will have 3.5 Tbps and we believe that at the end of 2014 we should have 5 Tbps.



    Yes but the network is already used by all customers, right?

    Yes, but our system is operated in the direction "OVH to Internet." But the attacks happen to us in the sense of "Internet to OVH." In a word, we actually have a higher excess capacity to 2 Tbps in the sense that we are interested to handle DDoS attacks.


    So, what is the size of the attacks that you manage?

    We sometimes get attacks to customers whose size exceeds 70-80 Gbps. This type of attack is mixed smoothly and the customer sees no impact on service.

  6. #6
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,000
    How do you ensure that the operators with whom you are connected are not, themselves, limited in terms of network capacity?

    The excess over 2 Tbps capacity is distributed in 20 PoPs (points of presence) spread in Europe and North America. Paris, Frankfurt, Warsaw, Amsterdam, Madrid, New York, Chicago, Los Angeles, Miami ... where our network is physically present. In these PoP, we have links with different operators.


    So what?

    A DDoS attack that has thousands of IP sources come from all parts of the world. In contrast to our competitors, we do not focus the arrival of the attack on our network via a PoP in a city. For us, a DDoS attack between our network closer to the source of the attack, that is to say, via Miami via Los Angeles, via Toronto via Prague via Vienna, via Madrid via Paris etc.. The attack and use all the capabilities of the deployed worldwide network is saturated or operators face or our network. And then she sucked and cleaned by the nearest VAC.


    How to clean the attack he is?

    VAC is composed of several serial devices that all look each IP packet, and then decide based on the contents of the package if it is legitimate, if it is a package linked to the attack or whether to trigger algorithm authentication package.



    What is happening in these cases?

    In the case of a legitimate packet, the packet is accepted and routed to the following equipment, and the latest equipment VAC redirects the client to the server. In the case of a package that, of course, is part of the attack, the IP packet is deleted. In the third case, there is need to authenticate packets since it can be a legitimate packet or a packet attack. VAC then triggers an authentication algorithm to know what to do.

    An example?

    For example, we use an algorithm called "Syn Auth" to block attacks Synflood type that involves sending lots of SYN packets with spoofed source IP (spoofed). The operation is as follows: when the VAC receives a SYN packet, it deletes it and sends it to the IP source a RST packet re-initiates the connection to the source IP. The standard recovery mechanism is performed by connecting the source IP, and he responds with a new SYN packet containing the same number sequence as the first SYN packet. VAC remembers the first packet and the second packet finds that returns the same sequence number. Consequence: the source IP is added to the "white list" of VAC for one hour. All connections from the source to the destination IP IP are automatically accepted. By cons, if the source IP address sends back SYN packets which have no connection with the previous packages, the VAC did exactly the same algorithm for all these SYN packets and thus erases all SYN packets. The attack is thus blocked and legitimate packets continue to pass.


    Are there no false positives with this algorithm?

    Outside the customer "SSH" which replays the sequence correctly but does not know then again the new connection automatically, all other TCP customers manage without any problems this algorithm.


    What should I do then with SSH?

    Simply restart the "SSH" customer a second time and the connection is made.


    It is not really clean.

    This is the counterpart of the customer choice by activating the "permanent mitigation" option. Indeed, if the customer chooses to be protected 24/24, mitigation works all the time. And given that SSH is used exclusively by the customer to administer the server, it is a compromise that has chosen to have on its server.

    Otherwise it may choose self-mitigation?

    Yes, in the case of self-mitigation, OVH detects the attack and active aspiration of the VAC. After the end of the attack, OVH mitigation stops 15 minutes. Instead of 15 minutes, the customer can choose "immediately", "1H", "6H" or "26H". In the case of "permanent mitigation", the customer chooses to use the VAC 24/24.


    With the permanent mitigation what will happen in case of attack?

    If the customer has activated the permanent mitigation and if, actually, stroke, we detect and activate our self-mitigation side, in addition to the permanent mitigation. There is no change in the operation, but if the customer during the attack disables permanent mitigation, mitigation continues still through self-mitigation.


    What is the difference between anti-DDoS DDoS Pro?

    In Pro, the client has permanent mitigation. It also has the Firewall Network that allows it to allow certain applications or IP to connect to the server and block everything else. Finally, we store all the information about the flows that have been accepted and cleared by the VAC for each mixed IP and this for 7 days. The customer can get a sample of this stream by choosing the date and time, then the number of rows to retrieve. This is a service with high added value to analyze an attack afterwards.


    That's it?

    Yes, it is, but it's huge. OVH is the only one on the market to offer the permanent mitigation for all its services. Permanent mitigation is very expensive because it uses resources VAC 24/24, even when there is no attack. In the case of self-mitigation, the client uses the resources of anti-DDOS protection only during the attack.




    "We are indeed moving lines on the market by making the anti-DDoS available to all customers so usually it is a service that is overpriced protection. "





    But in terms of quality of mitigation, are there any difference in the two bids?

    Regarding the service itself, it is identical. Default and Pro, the customer has all the protections against all attacks, regardless of the duration of the attack, regardless of the size of the attack and whatever the type of the attack. We integrate in the service alerts with early mitigation, the end of the mitigation, reporting mitigations with the curves of the traffic entered and exited the VAC VAC. We also add a sample of 10 lines of traffic that has been deleted and that was accepted.


    What is the capacity of the VAC?

    Our network has a surplus greater than 2 Tbps capacity. We have 3 VAC production and therefore we can manage up to 480 Mpps Gbps/480.


    How long did it last development?

    The testing and development MAV1 Tilera lasted three months. Following the validation of the first VAC, we launched the deployment of two VAC. All made ​​in five months.


    Five months is not a great experience?

    We manage attacks from the first day of OVH or 14 years, both at the backbone, dedicated than shared hosting servers. We have a very long experience in the L7 protections Web sites against all sorts of judgmental attacks. We develop in-house software that makes L3/L4 protections we turn on Tilera. To write an algorithm that runs up to 10 million times per second on each 10G port Tilera must know how to code but also how the Internet works in the details of each package. Finally, if a customer uses the self-mitigation and if it is buggy, improperly adjusted, or simply does not work well, the customer does not see it necessarily as mitigation is enabled only during the attack, a few minutes here or there. With the permanent mitigation, we manage very complex cases, for very different customers with all different services. It is an experience that our competitors can not do that because they have self-mitigation.


    What are the results?

    During the beta, we sought the right settings and we could check the overall operation of the VAC. We then refined with individual settings for some customers and we have incorporated into the final configuration. We also fixed some bugs. The VAC now work perfectly.


    And at the Manager?

    VAC is coupled to the v6 API that automates the mitigations. Add new rules Network Firewall, enable mitigation, off on an IP or all IP is easily done with the v6 API. In parallel, the Manager catches the features available in the v6 API to make them usable through simple clicks.


    What's next?

    The VAC is a unidirectional current protection, aka asymmetric attacks and some require bidirectional protection, aka symmetrical.


    Explain the difference?

    Unidirectional, VAC sucks packets only in the sense of "Internet to the customer's server", but leave the server address directly the other way. For any protection level L3/L4 is perfect, check the checksum of packets ... If we talk about Layer 7 (L7), for example the Web, we no longer speak only of the IP packet header or content the first packet, but we talk about the connection that consists of dozens of packages.


    What algorithm does it work in this case?

    The decision of whether it is an attack or not can sometimes be taken only after the connection. To mitigate unidirectional L7, the VAC must allow the attack to happen on the client server and then determine if the connection is legitimate or not. Server resources are taken by the attack only to be released later.


    What is the solution to avoid this?

    The bi-directional protection is to say symmetrical. We are currently working on the implementation of protection and L7 WebB activated DNS "on the fly" without any reconfiguration on the server and the client can block application attacks such as a DDoS on a URL of a site or the slowloris of opening up connections to a server, then write the query slowly. We know mitigate such attacks on our infrastructure and pass to the server that the legitimate connections.

  7. #7
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,000
    When this protection be available?

    Betas are ongoing and we believe that the service will STABLE the end of September and available for Web / SSL. Then we will work on the DNS and perhaps other protocols.


    The world of Internet Providers Infrastructure (FII) has changed?

    We do indeed move the lines in this market by making anti-DDoS protection available to all customers so usually it is a service that is overpriced. Once again, we did by questioning the technologies and implementing a totally different innovative technical solution, and that better meets the needs of our customers in terms of price and capacity mitigation.


    * For Application Specific Integrated Circuit (Application Specific Integrated Circuit) is an electronic circuit integrated onto a single chip all the assets necessary for the realization of a function or an electronic assembly.
    ASIC integrates several functions of a map, see replace and even incorporate new features in a smaller package.

  8. #8

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens
  •