Forum général.général sécurité réseau chez OVH

Posté par  .
Étiquettes : aucune
4
27
mai
2009
Bonjour,

Cela fait maintenant plus d'un mois que je me bats avec les interlocuteurs OVH pour leur expliquer un problème simple :

Nous sommes plusieurs abonnés à recevoir les données réseaux d'autres abonnés OVH sur nos cartes réseaux.

Nous sommes donc à même d'analyser les flux réseaux d'autres abonnés. (cool diraient certains)

OVH trouve cela normal et argue du fait qu'il s'agit de messages de diffusions, ou de routes mal configurés sur nos serveurs.

Que nenni, il s'agit de flux web, de torrent etc (pas du broadcast) et nos routes sont bien configurées.

J'ai déjà éclusé 3 interlocuteurs chez eux, si quelqu'un avait un contact compétent.

Merci.

Nicolas

  • # commutateur

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

    Une attaque de commutateur ?

    Système - Réseau - Sécurité Open Source

    • [^] # Re: commutateur

      Posté par  . Évalué à 1.

      Bonne hypothèse, mais nous on a rien attaqué hein ;) , pas de arp spoofing, man in the middle ou autre si tu penses à ça de notre fait, ou alors un autre abonné sur le même équipement que nous c'est fait plaisir ! et je ne vois pas comment cela aboutirait à recevoir en copie les paquets des autres.

      Plus précisément on reçoit les paquets en copie (bizarre) à destinations des autres serveurs. Exemple, je surfe sur le site d'un autre abonné OVH depuis chez moi (perso), et j'analyse le réseau depuis mon serveur OVH, le site web de l'autre abonné réponds parfaitement, et j'ai vu passer mes paquets perso vers lui depuis mon serveur hébergé. Par contre on ne voit pas passer les paquets en retour.

      • [^] # Re: commutateurww

        Posté par  . Évalué à 3.

        p'tet qu'ils ont voulu se rattraper sur le matos réseau vu ce que doit leur couter leurs connexions entre roubaix-city et amsterdam, et que tu n'est pas sur un switch, mais sur un hub :D

    • [^] # Re: commutateur

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

      Blague à part,
      J'ai déja vu cela sur des commutateurs 6co.
      Qd le commutateur rame le traffic n'est plus switché entre les différents ports.

      Système - Réseau - Sécurité Open Source

  • # Machines virtuelles ?

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

    Bonsoir,

    les serveurs des autres abonnés ainsi que le tiens sont peut-être hébergés sur la même machine physique, que vous partagez via de la virtualisation (vmware, virtualbox, etc...).

    Peut-être que c'est cette virtualisation qui ne marche pas correctement, et donc que le soft de virtualisation vous envoie à tout les deux (le site officiel et le tiens), les paquets destinés au site officiel. Il est alors assez logique que tu ne vois pas pas les réponses du site officiel à son client (par exemple, lors du test que tu as fait dans la discussion au-dessus).

    J'imagine que c'est faisable (bien que anormal) si les deux machines virtualisées ont la même adresse MAC réseau (carte réseau virtualisé, bien sûr).

    • [^] # Re: Machines virtuelles ?

      Posté par  . Évalué à 3.

      Hello,

      Bien tenté aussi ;) ,
      mais non, vu le prix et la gamme de serveurs, ils sont bien physiques !

      Nicolas.

  • # Forums OVH

    Posté par  . Évalué à 7.

    Le plus efficace est d'en parler sur les forums d'OVH.

    Comme (presque) partout ailleurs, la ligne chaude d'OVH est principalement uniquement constituée de personnes sachant répondre aux cas simples (traduire par: qui savent lire leur base de connaissance interne).

    Exemple tout frais de la semaine dernière: je demande si il y a une limite au nombre d'hôtes déclarés sur leur dns dynamique. Je résume:
    Question: quelle est votre limite du nombre d'hôtes de dns dynamique ? Peut-on mettre des adresses privées ? (10.x.y.z par exemple)
    Réponse: Les IP fail over seront limiter a 30 par serveur et celle ci aurons des IP ou les 3 premiers champs seront prédéfini par OVH
    (les fautes sont d'origine)

    Aucun rapport avec la choucroute donc. Je demande qu'une autre personne réponde... Réponse: votre demande concerne un serveur dédié ou un mutualisé ?
    Re-aucun rapport avec la choucroute :-)


    Exemple d'il y a environ 2 mois:
    Question: le serveur FTP pour la sauvegarde de notre serveur xxxxx semble poser problème car le débit est d'environ 10 Go par heure la nuit (contre 150 Go / heure la journée). Par contre pour notre serveur yyyy le débit est normal dans les deux cas.
    Réponse: 10Go / heure me semble une valeur correcte

    C'est sûr que pour sauvegarder 1 To (quota du ftp), 10 Go de l'heure c'est correct puisqu'il ne faut que 4 jours :-)

  • # broadcast != flood

    Posté par  . Évalué à 7.

    Salut

    Ca ressemble beaucoup à de l'unicast flooding.
    En clair, quand le switch a une entrée dans ca table ARP correspondant à un quelconque serveur mais qu'il ne l'a pas dans sa table MAC, alors il flood sur tous ses ports appartenant au VLAN de ce serveur.
    Ca arrive entre autre sur du traffic asymétrique (chemin différent à l'allée et au retour).
    C'est du au fait que les tables MAC et ARP n'ont pas par défaut le même timeout.

    http://www.cisco.com/en/US/products/hw/switches/ps700/produc(...)

    La solution: initialiser le timeout des tables des différents switchs avec la même valeur.
    Reste plus qu'à convaincre OVH... Bon courage ;)

    Nicolas

    • [^] # Re: broadcast != flood

      Posté par  . Évalué à 2.

      Hum, ça voudrait dire que les paquets arrivent via un switch et partent via un autre. Donc des switches redondants sur les mêmes segments Ethernet. Tordu mais c'est effectivement la seule explication convaincante pour l'instant. Mais tordu.

      • [^] # Re: broadcast != flood

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

        Pourquoi serait-ce tordu?

        Le problème existe que sur des machines avec deux cartes réseaux.
        De ce que j'ai compris de l'explication d'OVH, le problème arrive effectivement quand elles sont mal configurées sur la machine d'en face, et envoient alors par une carte pour recevoir par une autre.

        Donc l'explication se tient non?

        • [^] # Re: broadcast != flood

          Posté par  . Évalué à 1.

          J'y crois, ca me semble ok, puis-je diffuser ton message dans le forum ovh ?
          (cela n'arrive que sur les serveurs ayant 2 cartes réseaux)

        • [^] # Re: broadcast != flood

          Posté par  . Évalué à 6.

          Non, ça n'est pas tordu (c est assez classique en fait) et les serveurs n'ont pas a avoir plusieurs interfaces.
          Je vais essayé de faire un petit schéma en espérant que ça passera bien:

          serveur1 ----- switch1 ------------------
                                    |                        |
                                    |                        |
                              Rocade              Routeur -------- WAN
                                    |                        |
                                    |                        |
          serveur2 ----- switch2 ------------------

          tu essaies de joindre le serveur 2, sauf que switch1 est mettre VRRP sur ce VLAN donc ca part vers lui, ca passe par la rocade pour aboutir au serveur2.
          Le retour, par contre, est directe: serveur2 - switch2 - routeur - WAN
          Le problème c'est que les entrées de la table mac (faisant le lien entre @MAC et port du switch) disparaissent (timeout) beaucoup plus vite que celles de la table ARP (@MAC - @IP).
          Et donc parfois, si le switch1 recoit un paquet a destination de serveur2 il a encore dans sa table ARP mais pas dans sa table MAC.
          Il n'envoie pas de requete ARP, ca servirait à rien vu qu'il l'a toujours l'entrée dans sa table ARP, mais il ne sait pas par quelle interface balancer le paquet: méthode bourrin: il flood sur toutes les interfaces, y compris la rocade et donc serveur2 obtient bien son paquet. Par contre, serveur1 (qui est dans le même VLAN) l'a également reçu.
          C'est assez effrayant qu'OVH dise que c'est "normal" qu'un client reçoive des paquets (peut-être confidentiel) d'un autre client...

          Nicolas

          • [^] # Re: broadcast != flood

            Posté par  . Évalué à 1.

            Ca parrait top, mais je vois quand même tous les paquets d'une personne (dans un seul sens soit, mais timeout genre à zéro quoi ;) ), on doit pas être loin quand même, faudrait leur
            schéma réseau !

            • [^] # Re: broadcast != flood

              Posté par  . Évalué à 2.

              C'est normal que tu ne vois les paquets que dans un seul sens, pour le retour l'adresse destination est une adresse du WAN et elle est routée vers l'extérieur.
              Quant au fait que tu reçoives beaucoup de paquets, c'est normal aussi :) ç'est parce que ça floodera tant que l'entrée sera présente dans la table ARP du switch (mais pas dans sa table MAC).
              Pour Info, sur Cisco, c'est (de mémoire):
              timeout table ARP: 4 heures
              timeout table MAC: 5 minutes ...

              normalement si tu ping le flooder, ça devrait s'arrêter (temporairement...)

              Bon courage, je sais pas s'ils vont être très chaud pour modifier tous leurs switchs aussi facilement... mais normalement c est sans danger

              Nicolas

              • [^] # Re: broadcast != flood

                Posté par  . Évalué à 1.

                ok, bingo, un ping stoppe le flood temporairement, le coup des deux cartes aurait du me mettre la puce à l'oreille,
                pas top de laisser la config en l'état (je vois aussi passer les petits malins qui scannent le réseau ovh lol, et un serveur torrent assez consommateur, genre laisser un ping dans ma crontab vers lui lol)
                mais en effet je ne pense pas qu'ils feront la bascule :( , ok pour donner le lien forum ovh vers linuxfr ?

                • [^] # Re: broadcast != flood

                  Posté par  . Évalué à 1.

                  pas de problème

                  • [^] # Re: broadcast != flood

                    Posté par  . Évalué à 1.

                    ok, timeout à moins de 20 minutes, le flood est reparti sur l'ip "pinguée" ...,
                    bravo ;) et merci.

                    • [^] # Re: broadcast != flood

                      Posté par  . Évalué à 3.

                      On se sent mieux ici quand même, la conclusion,

                      Diffamation en publique avec des faux pseudos de la part de l'opérateur,
                      dénigrement du client,
                      Modification des configs en cachette pour corriger le problème !

                      Comment jugez-vous ces méthodes ?

                      J'aurais au moins appris ce qu'est l'unicast flooding.

                      Nicolas

                      PS: il y aura encore quelques épisodes, mais plus sur le forum OVH

                      • [^] # Re: broadcast != flood

                        Posté par  . Évalué à 2.

                        Le forum est exactement du même niveau que la ligne chaude d'OVH, sauf que se paye en plus les lèches-cul qui rendent le rapport signal/bruit minuscule.

                        Problème: les autres prestataires sont aussi nuls, sauf à payer le triple. Alors bon, on s'y fait. je ne paye pas le triple et régulièrement notre VPN saute car les paquets UDP ne passent plus certains routeurs. Ce matin même nous avons eu un filtrage de paquets UDP en dessous d'une taille donnée. Toute la signalisation d'OpenVPN était par terre.

                        Je ne contacte plus le support technique lorsque ces problèmes arrivent car leur seule réponse est "c'est normal". Si tu insistes ils demandent "des preuves".

                        OVH reste le moins cher, et de loin. Je fais avec.

                        • [^] # Re: broadcast != flood

                          Posté par  . Évalué à -5.

                          --Le forum est exactement du même niveau que la ligne chaude d'OVH, sauf que se paye en plus les lèches-cul qui rendent le rapport signal/bruit minuscule.

                          Le forum est un forum d'entraide pour usagers, pas pour du support. Si tu es pas content des usagers qui félicitent certains du staff pour les avoir dépanné alors qu'ils n'en étaient pas obligés, tu es un bon.
                          Il est vrai que le support en première ligne n'est vraiment pas top, on dirait Free des fois, heureusement qu'en housing c'est autre chose.

                          Qu'il y ait un problème c'est bien possible.
                          A vous lire, on remarque bien un problème clair de configuration et oui OVH est assez bouché de ce côté la.
                          Donc tant que personne ne montre clairement qu'il a prit le control total d'un serveur grace à ce problème, ils feront rien.
                          Et c'est peut-être bien dommage.

                          Par contre, quand dans le sujet bizarrement ya eu mass nouveaux profils qui se prennent pour des dieux du réseau et de l'informatique, incendie OVH et le peu de staff présent bénévolement sur le forum, ca énerve vite du monde.
                          Faut pas s'étonner qu'il soit très très vite partit n'importe comment.

                          Vous avez qu'a louer vos emplacements directement dans le DC, ovh fera un routage très simple et à vous de configurer vos switchs avec vos options. Hein Kerro :).

                          • [^] # Re: broadcast != flood

                            Posté par  . Évalué à 4.

                            Hooo... un profil créé justement quelques minutes avant de répondre, exactement comme ce que tu reproches :-)

                            Il est vrai que le support en première ligne n'est vraiment pas top

                            on remarque bien un problème clair de configuration et oui OVH est assez bouché de ce côté la

                            tant que personne ne montre clairement qu'il a prit le control total d'un serveur grace à ce problème, ils feront rien

                            C'est vrai que ça respire la qualité :-)

      • [^] # Re: broadcast != flood

        Posté par  . Évalué à 3.

        Ce n'est pas tordu, c'est un fonctionnement "logique" d'un point de vue purement technique (mais pas optimal en terme de sécurité c'est clair).
        J'ai déjà vu le cas en réel aussi, mais en ayant la chance d'avoir accès aux switches pour tout vérifier (genre pas de remplissage de la table de MAC addresses, ...), c'était exactement le phénomène que tu décris.

        • [^] # Re: broadcast != flood

          Posté par  . Évalué à 2.

          Je ne comprends cependant pas comment les paquets peuvent ressortir par une autre interface et être acceptés par TCP: ils ont une adresse IP différente.

          J'envoie une demande de connexion pour mon.serveur.com
          mon.serveur.com = 1.1.1.1
          la réponse revient depuis 2.2.2.2 (qui est la seconde interface de mon.serveur.com)
          --> la connexion ne se fait pas

          • [^] # Re: broadcast != flood

            Posté par  . Évalué à 2.

            ils ont une adresse IP différente.
            Et non!
            Ils ont une mac différente, mais l'adresse IP est la bonne.

            En gros, la table de routage dis juste "tout les paquets en sorties passent par eth0", plutot que "les paquets en sortie ayant l'ip X passent par eth0, et ceux ayant l'ip Y passent par eth1".

            la carte réseau fait ce pourquoi elle est concu : elle encapsule des données couche 3 et + (donc ip etc...) dans de l'ethernet.

            • [^] # Re: broadcast != flood

              Posté par  . Évalué à 2.

              Sauf erreur de ma part, chez OVH tu ne peux pas modifier l'adresse IP de tes cartes réseau car les switches et/ou routeurs vérifient les paires d'adresses IP et MAC.

              Ensuite les deux cartes réseau sont sensées être connectées à des équipements différents afin d'assurer la redondance. Si les routeurs sont correctement configurés, ils ne laisseront pas sortir des adresses IP qui ne font pas partie de leur sous-réseau.

              Lorsque que je fais sortir une adresse MAC incorrecte (depuis une machine virtuelle), je suis blacklisté pendant plusieurs minutes sur cette carte réseau. Je n'ai pas testé en faisant sortir un adresse IP modifiée.

              Bref, je ne suis pas convaincu :-)

              • [^] # Re: broadcast != flood

                Posté par  . Évalué à 2.

                Sauf erreur de ma part, chez OVH tu ne peux pas modifier l'adresse IP de tes cartes réseau car les switches et/ou routeurs vérifient les paires d'adresses IP et MAC.
                1°) normalement les acl au niveau des switchs, c'est plus une mac sur un port, qu'une correspondance mac/ip (le switchs ne comprennent pas forcément l'IP).
                Et les acl niveau routeurs, c'est souvent "sous réseau sur tel brin", que l'allocation précise.

                2°) tu peux avoir plusieurs ips sur ovh, que tu peux attribuer _comme tu veux_ a tes deux interfaces (si tu en as deux) si je ne m'abuse.
                Pour chaque nouvelle ip ils s'amusent à mettre à jour, à chaque fois , tous les switchs/routeurs du path ?
                dans leur guide, aucun avertissement qu'il faut imperativement la mettre sur la bonne interface http://guides.ovh.net/AjouterAliasIp, mieux ils indiquent que la route par défaut est sur une interface précise si je ne m'abuse pas (regarde HG) (ce qui est à l'origine du problème)
                3°) tu peux avoir des VIP, idem que plus haut.


                Ensuite les deux cartes réseau sont sensées être connectées à des équipements différents afin d'assurer la redondance. Si les routeurs sont correctement configurés, ils ne laisseront pas sortir des adresses IP qui ne font pas partie de leur sous-réseau.
                Ca se contredit :
                Si un des switchs tombent, alors tu perd la moitié de ta connectivité (vu que ton ip ne peut pas etre routé).
                Si tu utilise une ip en VIP, tu peux pas la migrer...
                etc...


                Normalement tu attribues plutôt un vlan par client, comme ça tu es sur qu'il risque pas de faire mumuse avec les autres clients. Bon si tu as beaucoup de client ça peut devenir compliqué parce que tu as un nombre limite de vlan (1024 ou 4096, je me souviens plus trop).
                La vérification de "pas de spoofing" se fait ensuite à la sortie du vlan.


                Ps on peut remarquer que "l'aide d'ovh" n'est pas bonne, vu qu'ils ont oublié dans leur conf de faire un "/sbin/ip route add default via ??? dev eth? table 127" , enfin moi je dis ça, je dis rien hein Xd

                • [^] # Re: broadcast != flood

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

                  Ce qui n'est pas bon dans l'aide d'ovh c'est surtout qu'en 2009 il recommandent encore
                  de faire des alias d'interfaces type eth1:1 malgré les recommandation contraires.

                  Ex: http://fixunix.com/networking/11256-ip-addr-add-vs-interface(...)
                  Actually
                  aliases have inconsistent syntax and behaviour, exactly as you pointed.
                  Sometimes they behave like different device, sometimes like just one
                  another address. Anyway avoid them...

                  • [^] # Re: broadcast != flood

                    Posté par  . Évalué à 1.

                    J'ai pas mal communiqué avec un autre client OVH, dès qu'il a changé son routage
                    (paquets sortants par la même carte que par laquelle ils sont entrés),
                    je n'ai plus vu ses données passer par le réseau.

Suivre le flux des commentaires

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