Le futur sur les dénis de service

Posté par  . Modéré par oliv.
Étiquettes : aucune
0
24
oct.
2001
Sécurité
Le centre de coordination du CERT (Computer Emergency Response Team) vient de publier un document sur les étendues que pourraient prendre les attaques par déni de service (DoS). Il ne propose pas de solution, mais permet d’alerter tout le monde sur les risques que nous encourrons.
Ce rapport insiste particulièrement sur les dénis de service distribués (DDoS).

En 2001 nous avons vu l’explosion des DDoS utilisant des outils automatisés (par exemple Code Red contenait une attaque sur www.whitehouse.gov). Mais la plus grande préoccupation vient du fait que ces attaques utilisent à présent des ordinateurs fonctionnant sous Windows ou en s’appuyant sur des routeurs.

Il est à noter que les outils de détection d’intrusion (IDS) permettent de limiter les attaques par déni de service. Si certains ont une expérience à ce sujet les commentaires sont les bienvenues...

Aller plus loin

  • # Autre DoS avec CodeRed

    Posté par  (site web personnel) . Évalué à 10.

    CodeRed crée aussi un DoS sur les LAN (via une tempête ARP) : il attaque au hasard les machines du LAN, très rapidement, via leur IP ; du coup il fait énormèment de requêtes ARP. J'ai vu une machine représenter 90% du trafic du réseau, en faisant seulement de l'ARP. CodeRed surcharge énormèment les réseaux locaux.

    Et un paquet de vers/virus surchargent les serveurs de mail.
    • [^] # Re: Autre DoS avec CodeRed

      Posté par  . Évalué à 6.

      Moi ct pareil sur ma machine connectée au reseau cable wanadoo sur la plage 213.56.X.X

      Environ 95% du trafic reseau. G ralé chez FT mais que dalle pas meme une reponse. rien à battre que leur reseau se casse la geule alors qu'il sont sensé fournir une bp mimi.
      • [^] # Re: Autre DoS avec CodeRed

        Posté par  . Évalué à 2.

        Tu ne dois pas être le seul à raller, en effet j'ai reçu un mail de Wanadoo-cable expliquant qu'il y avait peu y avoir des perturbations du a certains virus.
        Ils conseillaient de mettre de antivirus (WinWin bien entendu) en donnant de liens sur des pages Wanadoo.
        Ils ont rajouté que par soucis d'équité que l'upload du mois de septembre ne serait pas compté..

        Je trouve que c'est un bel effort mais qui arrive un peu tard et ils ne parlent pas de la diminution de la bande passante.

        Note: j'ai aussi regardé un peu ce qu'il passait sur la câble : plein de requêtes ARP :-(
        • [^] # Re: Autre DoS avec CodeRed

          Posté par  . Évalué à 2.

          Tu ne dois pas être le seul à raller, en effet j'ai reçu un mail de Wanadoo-cable expliquant qu'il y avait peu y avoir des perturbations du a certains virus.
          Ouais sauf que j'ai commencé à raler en aout et j'ajoute que j'ai reçu egalement ce mail.
          Ils ont rajouté que par soucis d'équité que l'upload du mois de septembre ne serait pas compté..
          C'est surtout pour la mep de pppoe que l'upload n'est pas compté.
          ils ne parlent pas de la diminution de la bande passante
          Et des machine qui en attaque un autre à la frequence de 2 requete/sec ça bouffe pas de bp ???
      • [^] # Re: Autre DoS avec CodeRed

        Posté par  . Évalué à 5.


        Environ 95% du trafic reseau. G ralé chez FT mais que dalle pas meme une reponse. rien à battre que leur reseau se casse la geule alors qu'il sont sensé fournir une bp mimi.


        Que dalle !
        FT ne garantit aucun debit minimal sur le cable, relis ton contrat.
        C'est peut etre des encules, mais ils font bien attention a ne pas se faire griller sur les clauses de contrat.

        En fait il n'y a qu'un seul debit assure par FT et c'est sur le RTC (si je me rapelle bien c'est 2400 bauds, dommage pour le 56K ;)
    • [^] # Re: Autre DoS avec CodeRed

      Posté par  . Évalué à -1.

      Mouarf.
      Ici, on a vu des logs contenant une attaque toutes les 3 minutes.
      En moyennant la probabilité& de moyenner et la répartition des machines de par le monde, ca turlupine pas mal.

      En gros, c'est ENORME, qu'un serveur pris au hasard se fasse attaquer toutes les 3 mn...
      • [^] # Re: Autre DoS avec CodeRed

        Posté par  (site web personnel) . Évalué à 1.

        "En gros, c'est ENORME, qu'un serveur pris au hasard se fasse attaquer toutes les 3 mn..."

        Sur Internet oui c'est rare. Mais sur un LAN c'est pas le trafic TCP/IP qui pose problème mais le trafic ARP.
  • # Un rapport avec la sortie imminente de Windows XP ?

    Posté par  . Évalué à 10.

    On peut se poser la question...

    Je me rappelle un article de je-sais-plus-qui qui avait subi un DDoS et réussi à le contrer en bloquant certaines IPs sur ses routeurs, mais qui se faisait du souci quant à l'avenir à cause de XP, qui met à portée de tout le monde le forgeage de paquets IP.

    Il expliquait qu'avec le Windows grand public actuel (95, 98, Me), il n'est pas possible de modifier l'adresse source dans les paquets IP émis, alors que c'est possible avec XP.

    Du coup, un DDoS meutrier pourrait être lancé avec moins de machines.

    Par contre, je n'ai pas lu à fond le dossier, mais j'ai pas l'impression qu'il y soit fait allusion...
    • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

      Posté par  . Évalué à 4.

      C'est cet article ci, il avait fait l'objet d'une news ici à l'époque :

      http://grc.com/dos/grcdos.htm(...)

      A noter un dossier complet sur les DDoS :
      http://grc.com/dos/intro.htm(...)
    • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

      Posté par  (site web personnel) . Évalué à 8.

      Avec le bon agent (genre dll) de stack IP sous windows, il a toujours été possible de forger des paquets sur windows. On trouvait auparavant ce genre d'outil sur les CD Back Office windows.
    • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

      Posté par  (site web personnel) . Évalué à 8.

      Je ne vois pas le rapport entre les attaques type Distributed-DOS et la falsification d'adresses IP (IP spoofing). On peut avoir soit l'un, soit l'autre, soit les deux, mais ce n'est pas lié.

      Le fait d'avoir des routeurs bien configurés (anti-spoofing koi) empeche des paquets n'appartenant pas au LAN routé de sortir. Déjà ça embete pas mal de kiddies.

      Pour les DDOS les mesures à prendre dépendent de chaque type d'attaque, et c'est pas gagné.
      • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

        Posté par  . Évalué à -1.

        Ben en fait, le rapport est assez simple...

        Pour éviter de venir avec tes gros sabots et tes 50 connections depuis la même IP, tu viens avec un faible nombre de connections, mais depuis des IPs différentes.

        Pour ce qui est de l'anti-spoofing, tous les providers ne le mettent pas en place, si tu utilises un cheval de troie et que tu sais pas d'où ça va partir, tu peux toujours parier qu'il y aura des gens qui passeront par de tels providers.

        Qui plus est, tu peux très bien forger en utilisant les adresses du sous-réseau dans lequel tu es. Ca en fait plusieurs, et l'anti-spoofing ne marche pas...
        • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

          Posté par  (site web personnel) . Évalué à 8.

          Pour éviter de venir avec tes gros sabots et tes 50 connections depuis la même IP, tu viens avec un faible nombre de connections, mais depuis des IPs différentes.
          Oui, ça c'était dans le temps. Quand il n'y avait pas les DDOS.

          Avec les DDOS, plus besoin de forger son IP, il suffit de commander à distance le lancemement du DDOS (principe maître/esclave). Comme ce n'est pas ta machine qui participe à l'attaque, mais les machines esclaves, on s'en fout de forger les IP. A la limite tu forges l'IP du maître, mais ce n'est pas celle que va voir la victime de l'attaque.
          • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

            Posté par  . Évalué à -1.

            Justement, le principe, c'est que tu peux faire un DDoS efficace avec moins de machines, puisque chacune des machines esclave peut forger les IP.
            • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

              Posté par  (site web personnel) . Évalué à 2.

              Je crois que tu confonds DDOS avec l'attaque par réseau amplificateur... Un DDOS n'utilise par forcément ce type d'attaque, j'essayais de rester dans le cas général.
              • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

                Posté par  . Évalué à -1.

                Et moi je parle de l'évolution possible des DDoS (et vu le principe, AMHA, on peut encore parler de DDoS) décrit par http://grc.com/dos/grcdos.htm(...)
                • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

                  Posté par  . Évalué à 1.

                  Ce que tu dis, c'est que c'est plus facile de lancer un DDos quand il est possible de forger les paquets... ce qui n'a rien à voir: le DDos est violent parce que l'attaque provient de plusieurs machines à la fois (ça cumule la bande passante disponible sur chaque machine), pas parce qu'on ne sait pas d'où provient l'attaque.
                  • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

                    Posté par  . Évalué à -1.

                    Quand il est possible de forger les paquets, la contre-mesure qui consiste à bloquer les IPs qui attaquent ne marchent plus... Le DDoS est plus efficace...
                    • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

                      Posté par  . Évalué à -1.

                      Ce n'est pas malin de mettre une telle contre-mesure en place: si je ne veux pas que mon voisin ai accès à un site "protégé" ainsi, je lance plein de paquets spoofés avec l'IP du voinsin sur des ports différents du site (simulation de scan) et pan, le voisin est bloqué...

                      Ce que tu nous proposes, c'est tout sauf de la sécurité, et les sites protégés ainsi sont administrés par des ______ qui ont appris la sécurité en lisant 01 Informatique.
                      • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

                        Posté par  . Évalué à 2.

                        Quand tu subis un DDoS, que tes serveurs sont pas encore totallement HS, et que tu veux continuer à servir les utilisateurs du site, et que les IPs qui attaquent sont fixes, tu les filtres...

                        Ce genre de contre-mesure n'est bien évidemment à prendre qu'en cas d'extrême urgence... (c'est ce qu'avaient fait les gars de GRC)
                      • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

                        Posté par  (site web personnel) . Évalué à 0.

                        tu as un meilleurs idee, je veux dire un solution rapide, pour parer immediatement, en attrendant que le petit malin en face se calme ?

                        Qu'est ce que tu propose pour filtrer ce type de probleme ?
          • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

            Posté par  (site web personnel) . Évalué à 7.

            Rappelons que lorsque l'on est victime d'un DDoS un solution rapide, et plutot efficace, et de black-lister les IP mechantes.
            Avec des paquets forges, ca devient TRES difficile, car tu as une _multitude_ d'adresse IP _changeantes_ et dangeureux ( je blacklister Internet peut etre considere comme un DoS ? ;))
      • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

        Posté par  . Évalué à 9.

        Si les IPs sont souvent spoofées dans une attaque de type DoS, ce n'est pas seulement pour ne pas se faire repérer, ni pour éviter de se faire black-lister. C'est aussi parce que les attaques DoS sont en général basée sur le principe du SYN-flooding : c'est bien parce que l'IP est spoofée que personne ne reçoit jamais le SYN-ACK, et que la connexion reste pendante sur la machine attaquée. Si au contraire une machine physique recevait ce SYN-ACK, elle retrounerait un RST qui fermerait la connexion chez le serveur cible... Ce qui est précisément le contraire de l'effet recherché.

        Ca c'est pour le principe de base. Maintenant certaines attaques DoS un peu plus évoluées (cf. les attaques de type "Naptha", très bien décrites d'ailleurs sur le site du CERT) nécessitent justement que l'on (ou mieux un collègue) reçoive le fameux SYN-ACK, pour répondre à notre convenance et laisser la connexion serveur dans un état arbitraire (LISTEN ou LAST-ACK en général). Dans ce cas, le spoofing d'IP sert justement à ce que la SYN-ACK du serveur soit routée jusqu'à la machine du copain. Ici l'attaquant doit donc spoofer une IP du domaine de son "complice".
        • [^] # Re: Un rapport avec la sortie imminente de Windows XP ?

          Posté par  . Évalué à 5.

          Une autre possibilité, sans passer par un complice et une éventuelle IP spoofée qui existe vraiment, c'est de faire de la prédiction du ISN (Initial Sequence Number), et de forger une réponse à notre convenance (un ACK suivi de paquets de requêtes HTTP par exemple) "à l'aveugle".

          C'est tout à fait possible, dans une certaine limite. En gros, ça dépend du facteur aléatoire de cet ISN dans l'OS de la machine attaquée. Mais on atteint le piratage qui n'est pas réservé aux script-kiddies...

          nmap donne d'ailleurs une indication sur le facteur aléatoire des ISN (je ne me souviens plus de l'intitulé exact).

          Une étude statistique des ISN de pas mal d'OS :
          http://razor.bindview.com/publish/papers/tcpseq.html(...)

          Evidemment, connaître ce facteur aléatoire ne suffit pas, il faut connaitre les ISN qui ont été donnés précédemment. C'est pourquoi il faut établir des connexions (des vraies) pour avoir des valeurs d'ISN permettant de "déduire" la suivante.

          Pour une explication de l'établissement d'une connexion TCP/IP :
          http://www.info.univ-angers.fr/pub/pn/poly/node44.html#fig:tcp:conn(...)
          (en l'occurence, selon la terminologie utilisée, il s'agirait de deviner le nombre P)
  • # IPv6 ?

    Posté par  (site web personnel) . Évalué à 10.

    Ca va peut être obliger les gens du réseau à se bouger le c.l pour IPv6. Ce genre d'attaque serait alors beaucoup moins trivial, et il y aurait au moins une période calme le temps que les outils de script kiddies sortent.
    Si y'a des gens forts en IPv6 qui peuvent confirmer...
    • [^] # Re: IPv6 ?

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      En fait, ce sera possible sur un réseau local avec les adresses locales mais bon, j'en suis pas tout à fait sûr.
      En y réfléchissant, je pense qu'on doit pouvoir faire une tempête de Router advertisement en IPV6. Mais je suis pas un pro, faudrait que je vérifie.
      • [^] # Re: IPv6 ?

        Posté par  . Évalué à 0.

        normalement, ce type de pb est pris en compte dans le protocole de routage lui-même, c'est une priorité de la création de nouveaux protocole, maintenant, j'ai pas été voir les protocoles associés à IPV6.

        nraynaud, la flemme de s'authentifier
      • [^] # Re: IPv6 ?

        Posté par  (site web personnel) . Évalué à 7.

        Le router advertisement n'est pas routable, donc ça limite les attaques.
        Et puis le router advertisment n'est pas interessant. Le router solicitation lui peut-être interessant, car lui est lancé par les clients (et pas par le routeur).
  • # Linux aussi !!

    Posté par  . Évalué à 8.

    euh.. dans mon expérience, j'ai eu un serveur linux qui s'était fait "RootKitté" par un méchant "ToRn" ..

    Ce root kit exploitait une faille du daemon telnet qui j'avais oublier de refermer apres une intervention ....

    Tout ca pour dire que linux n'est pas exant de participer à des DDOS, et que la fiabilité des systèmes dépend également de ces administrateurs !! IL FAUT ETRE VIGILANT !!

    En relativisant, le nombre de failles ou rootkits dispo sur linux ent quand même moins inportant ....

    ND
    • [^] # Re: Linux aussi !!

      Posté par  . Évalué à 5.

      Et en général pour un DDoS efficace, comme tu as besoin d'un nombre assez important machines attaquantes, tu préfères utiliser un cheval de troie que des gentils gens vont lancer comme des boulets (cf. virus Sircam ; ce virus aurait eu pour but un DDoS, ça aurait bien marché...)
  • # IDS

    Posté par  . Évalué à 6.

    Je conseille à ceux qui veulent en savoir un peu plus sur les IDS de lire "Détection des Intrusions Réseaux" ISBN 2744010480.

    Sinon au niveau des IDS, probablement le meilleur du genre (et en GPL), je conseille Snort : http://www.snort.org(...) . Il dispose d'un grand nombre de signatures, est facilement upgradable (les règles sont dans des fichiers textes) et fonctionne avec des bases de données (genre MySQL ou Oracle).
    • [^] # Re: IDS

      Posté par  . Évalué à 0.

      En parlant d'IDS...

      Il est à noter que les outils de détection d'’intrusion (IDS) permettent de limiter les attaques par déni de service

      Quelqu'un peut m'expliquer comment un dispositif qui détecte, donc, par nature, qui n'entreprend aucune action, peut limiter les attaques ?
      • [^] # Re: IDS

        Posté par  (site web personnel) . Évalué à 2.

        C'est pasque c quand t'as un backdoor que le cracker y peut faire des attacks DDoS avec ta babasse. Si t'as détecté l'intrusion et que tu vires le backdoor, il peut normalement plus s'en servir...
        Mais bon.
        Avec un pauvre modem et sous réseau de classe C ouvert, tu faire à toi tout seul une attack DoS, avec des ping flood et IP source forgée vers l'IP de l'attaqué ;-)
        • [^] # Re: IDS

          Posté par  . Évalué à 3.

          Pour faire un DDoS, pas besoin d'une backdoor...

          Suffit de voir comment les sites de news se sont écroulés le 11 septembre. Ce qui s'est passé peut être appelé un DDoS...
      • [^] # Re: IDS

        Posté par  . Évalué à 5.

        L'IDS pourra détecter automatiquement que le nombre de requêtes sur un port en particulier est _anormalement_ élevé, notamment grace à ses propres statistiques.

        Si l'abus est évident, alors l'IDS pourra jouer dynamiquement avec les options du firewall : par exemple, iptables permet de limiter le nombre de paquets par seconde sur un port, un type de service ou un protocole.

        Une série de requêtes invalides peuvent quant à elle n'être analysées correctements que par un reverse proxy ou d'après les log des services eux même. L'analyse par un IDS du contenu de chacun des paquet est gourmand en ressource, et va faire basculer un IDS comme un moyen de créer des DDos plutôt que de les éviter.

        Un exemple d'exploitation en temps réel des log peut vous servir :
        l'exemple que je vais vous donner est basé sur des logs Apache sans nslookup (il est recommander de ne pas activer le nslookup dans les options apache) l'addresse IP est donc représentée par le champ $1 avec un séparateur de champ standard : l'espace.

        nohup (tail -n10000 -f access_log | awk '/root.exe|default.ida/{system("/sbin/ipchains -A input -j DENY -i eth0 -p tcp -s " $1 " --destination-port 80")}' ) &

        avec iptables, remplacer la commande system() par "/sbin/iptables -A INPUT -i eth0 -s "$1" --protocol tcp --destination-port 80 -j REJECT"

        --
        • [^] # Re: IDS

          Posté par  . Évalué à -1.

          Dans ce cas, la terminologie IDS (Intrusion Detection System) ne suffit pas, puisqu'il ne s'agit pas uniquement de détecter... ;-)
          • [^] # Re: IDS

            Posté par  . Évalué à 3.

            >Dans ce cas, la terminologie IDS (Intrusion Detection System) ne suffit pas, puisqu'il ne s'agit pas uniquement de détecter... ;-)

            En fait, un IDS détecte, oui, mais seul il ne sert à rien d'autre que de dire : "Tiens, on se fait attaquer...".

            C'est pourquoi ils sont généralement liés à un système de réponse automatisée, afin d'être pro-actif sur les actions entrantes douteuses. Mais le Package s'appelle IDS par extension, car le plus gros du travail est l'intelligence artificielle nécessaire à l'IDS pour savoir si un pic de traffic est normal ou pas : il est 08h00 du mat', c'est normal qu'il y ait plus de traffic qu'à 06h00, on est lundi, c'est normal qu'il y ait plus de fréquentation que la veille, on est en septembre, c'est normal qu'il y ait plus de requêtes qu'en août... mais dans quelles mesure est-ce normal ? Voilà l'analyse que l'on demande à un IDS digne de ce nom. appliquer une règle sur le firewall est une action simpliste par rapport à l'analyse effectuée pour en arriver là.
            • [^] # Re: IDS

              Posté par  . Évalué à 1.

              Avec un IDS de ce genre ça risque de crée de gros problème de gestion. Si un site très connu met un lien sur une societe, et que tous les surfeur vont visiter le site de ladite societe, ça risque de faire hurler l'IDS inteligent qui deduira que cette hausse de traffic est non conforme à la normale.

              Snort (et d'autres IDS) possede une option qui lui permet de réagir à une attaque "flex-resp".
              Donc maitenant si il remarque qu'un gentil S.K tente un BoF sur le serveur, Snort coupe la connexion.

              Les modules ajoutent automatiquement une règle dans le firewall pour bloquer une ip c'est assez ennuyeux pour le gens qui passent par une passerelle.
            • [^] # Re: IDS

              Posté par  . Évalué à 1.


              C'est pourquoi ils sont généralement liés à un système de réponse automatisée, afin d'être pro-actif sur les actions entrantes douteuses.


              Totalement faux.
              Glandium a raison de rappeller la definition d'un IDS, car son but n'est que de detecter.
              Le nombre de systeme d'auto-protection qui utilisent un IDs pour adapter la securite d'une machine est bien moindre par rapport au nombre de "vrais" IDS.

              De plus il faut bien comprendre que ce genre de systeme auto-gere n'est pas suffisement "intelligent" pour parer un DoS par contre attaque.
              Si une personne se rend compte que a tel endroit il se trouve un firewall pilote par ce genre de systeme automatique, il peut etre simple d'envoyer certains styles de requetes afin que le firewall coupe de lui meme un traffic important.
              Genre il te bloque le port 80 est plus personne ne vient sur le site web.

              Par contre quand tu parles d'intelligence artificielle pour ce genre de systeme tu devrais mettre des guillemets, parce que du pattern matching c'est loin d'etre de l'intelligence artificielle :)
        • [^] # Re: IDS

          Posté par  . Évalué à 0.

          Le module ipt_limit d'iptable (kernel 2.4) permet de faire bien mieux que cela. Il joue le role d'une bascule a hysterisis. Il a donc 2 etats et, transite de l'un vers l'autre lorsque le debit depasse un seuil max ou, devient inferieur a un planche.

          En le combinant avec un -j LOG, il detecte les depassements de seuil.

          En le combinant avec -j REJECT, il prend une decision et rejette les paquets pendant l'attaque (debut de l'attaque lorsque le seuil max est depasse et fin lorsque le debit passe en dessous du seuil planche).

          Dans la table, on peux creer une suite de regles pour limiter le debit dans des cas de figures specifiques (ping, arp , syn flood, requetes http, ... ) en combinant le module limit et les autres modules de pattern matching.

          Puis, a la suite de ces regles, on peux ajouter une autre regle pour limiter le debit global (aucunes precisions sur la nature du paquet).

          iptable est dynamique et, a un etat (egal au debit instantane sur une regle). Le fait d'utiliser une reponse automatique est tres dangeureux et, peux se retourner contre le systeme de protection. Cet algorithme me semble etre la meilleure solution.

          J. de Vivie.
      • [^] # Re: IDS

        Posté par  . Évalué à 2.

        Paske, tu peux par ex. connecter les règles de filtrage sur les résultats de l'IDS.

        Ou envoyer un sms à l'admin.

        Tu peux fonder tes décisions sur l'analyse, il y a un exemple intéressant pour snort, il classifie (Markov, recuit simulé)les évènements "anormaux" du réseau (par des dépendance statistique, adresse source, port, temps ...) et s'il trouve un "grumeau" un peu gros de "scories", il déclenche l'alarme.
        Ce type d'analyse, permet de découvrir des trucs imprévus et de 'rallonger' la sauce genre analyse de plusieurs sites (les vers déclenchent des trafics corrélés sur plusieurs sites différents) etc..

        nraynaud, toujours la flemme.
    • [^] # Re: IDS

      Posté par  (site web personnel) . Évalué à 5.

      A propos, qui c'est qu'a lu entièrement le rapport PDF du premier lien avant de poster des commentaires ? ;-))
      Tous ceux qui ne l'ont pas fait méritent une bonne fessée !
      • [^] # Re: IDS

        Posté par  . Évalué à -6.

        > Tous ceux qui ne l'ont pas fait méritent une bonne fessée !

        Franchement ... pas le temps. Et ce n'est que 20 pages.
      • [^] # Re: IDS

        Posté par  . Évalué à -6.

        Hey, c'est linuxfr ici, pas smfr.org :+)
    • [^] # Re: IDS

      Posté par  . Évalué à 4.

      Quant à moi, je conseille Prelude, qui "comprend" les rulesets Snort.
      Prelude est 300% plus rapide que Snort et offre un *vrai* générateur de rapports.
      Un must pour les administrateurs réseaux.
      Direction http://prelude.sourceforge.net(...) !
      • [^] # Re: IDS

        Posté par  . Évalué à 1.

        Je vois pas en quoi le generateur de rapport de prelude est si exceptionnel.

        Des outils externes a snort permettent d'avoir des rapport bien meilleurs a ceux de prelude.

        C'est dingue mais j'ai comme l'impression que c'est de l'auto-pub ce message ...
        • [^] # Re: IDS

          Posté par  . Évalué à 1.

          Et alors ???

          En supposant que ce soit lui qui ait créé ce soft. Dans le mesure ou celui-ci est libre (licence GPL v2) pourquoi ne pourrait-il pas en faire de la pub? Ca permets à des gens qui connaissent pas (dont moi :) de savoir que ce soft existe.
          • [^] # Re: IDS

            Posté par  . Évalué à 0.

            Faire de la pub en rabaissant snort avec de faux arguments je trouve ca minable ...
            • [^] # Re: IDS

              Posté par  . Évalué à 0.

              ouais, sauf que la, ce ne sont pas de faux arguments (je ne suis pas le mec qui a ecrit plus haut), prelude est mieux, si tu n'es pas convaincu, testes le et tu verra par toi même.

              Sinon, question proprete de code (et ca compte pour du GPL) regarde le code source de snort et celui de prelude, tu me diras lequel tu lis le mieux.

              Cependant je ne cherche pas la gueguerre entre les deux IDS, snort a quand même fait une petite révolution et est très fournit côté doc.
        • [^] # Re: IDS

          Posté par  (site web personnel) . Évalué à 1.

          effectivement la personne aurait put s autentifier
          mais je doute fortement que ce soit le createur de prelude qui est poste en anonyme, c est vraimment pas son genre.
          sinon effectivement il doit avoir des outils 'externe' qui sont peut etre meilleur, mais comme il sont independant de snort il pourront je pense facilement utilise les sorties de prelude, voir cree leur plugins de sortie specifique
  • # IDS contre DoS

    Posté par  . Évalué à -3.

    Un IDS peut a la rigueur detecter un DoS, mais je ne vois pas comment il peut l'arreter (a part peut-etre limiter l'impacte en reconfigurant le firewall).
  • # Pipotron

    Posté par  . Évalué à -10.

    Mais bordel qu'ils arretent de nous pondre des rapports pipo tout le temps.

    plonk (-1)
  • # ON S'EN FOUT !!!!!!!

    Posté par  . Évalué à -10.

    Non, mais c'est quoi cette news?
    Qu'est-ce qu'elle fait en première page?
  • # Pas de solution

    Posté par  . Évalué à 1.

    En fait, il n'y a pas de solution pour se prémunir
    des DDoS : quand la bande passante est bouffée, on
    a beau filtrer/detecter, etc. on n'y peut rien,
    sauf de convaincre son FAI de filtrer en amont :
    bon courage.

    La seule << solution >> est que chaque possesseur
    de système/réseau connecté à Internet fasse en
    sorte que ses ressources ne soient pas utilisées
    pour des DDoS. Autant dire qu'avec 'daube c'est
    pratiquement sans espoir :-(

    D'ailleurs, vous aurez pu constater que quand
    Nimda est sorti, la BP global d'Internet s'est
    effondrée : même sous 'nux 'daube nous emm...

    M$ a inventé un nouveau concept : le polluware.

    Ça c'est de l'innovation innovante !!!!!

    François
    • [^] # Re: Pas de solution

      Posté par  . Évalué à 3.

      Deux idées pour limiter les possibilités de DoS depuis un LAN :

      - Ne pas router vers l'extérieur les paquets dont l'adresse source n'appartient pas au domaine (j'imagine que c'est fait en général)
      - Configurer autant que faire se peut des tables ARP statiques, pour éviter l'utilisation d'outils du style arpspoof. En plus c'est à peu près la seule manière d'empêcher les sniffers sur un lan.

      -1 parce que finalement je sais pas ce que ça vaut :-P

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.