jump to navigation

Comment une mauvaise configuration d’application peut affecter la sécurité de votre réseau … 16 juillet 2012

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , , ,
add a comment

Développer et déployer des applications est bien plus facile depuis quelques années et la tendance ne fait que s’accélérer avec les kits d’outils de développement, le cloud computing et les plateformes de services (Paas). De ce fait, les problèmes d’erreur de configuration augmentent proportionnellement en particulier pour les applications Web.

Il faut garder en mémoire que le fonctionnement logique et le contrôle de l’application doivent être (et rester) au niveau du serveur lors que l’interface utilisateur est elle doit être gérée du coté clients. Pour faire une analogie, pensez à un supermarché : même si le client peut se promener le long des allées et placer des articles dans son chariot, l’essentiel du business se passe à la caisse qui est, dès lors, un passage obligé.

Les exemples ne manquent pas !

Par exemple en 2009, les Pizza Domino’s ont lancé une campagne d’actions marketing et publicitaire pour gagner de nouveaux clients. Une application écrite en Flash fut ajoutée au site en ligne pour permettre aux clients de passer commande en ligne. Cette application, affichait un champ permettant d’entrer un coupon pour recevoir une pizza pour 5$.

Une nuit du week-end, un pirate a désassemblé l’application Flash pour voir comment elle fonctionnait et s’aperçu que la validité du coupon était contrôlée par l’application elle même. Pire encore, il a constaté que le plan marketing prévoyait même un coupon pour obtenir gratuitement une pizza. Comme le code se trouvait dans l’application Flash, il l’essaya sans délai et moins de 30 minutes plus tard, il se régalait d’une pizza gratuite. Le pirate s’empressa alors de poster le code coupon sur un forum. Ce n’est que le lundi matin que l’entreprise se rendit compte que son secret avait été percé et qu’elle avait livré gratuitement 11.000 pizza pour un coût d’environ 50.000$. Heureusement pour une compagnie de cette taille, cela n’a pas porté de préjudice majeur, mais cela reste une somme qui aurait pu ne pas être perdue si le contrôle des coupons avait été réalisé sur le serveur.

De nombreux exemples similaires peuvent être trouvés où une substitution relativement simple dans un formulaire de soumission (de commande en ligne) ont permis à un pirate de modifier le prix : Le serveur envoi une page web sur le poste utilisateur avec le prix de chaque article … et le bouton ‘Ajouter au panier’ renvoi la quantité et le prix au serveur … Un expert en sécurité a fait la démonstration d’achat d’un article coutant plusieurs milliers de dollars, pour 1 unique dollars. Pourtant cette faille était simple à éviter : il suffisait à l’application de retourner le code article, et non pas le prix, depuis le poste utilisateur vers le serveur, ce dernier se chargeant de trouver le prix de l’article dans sa base de données.

Ces 2 exemples portent sur des solutions de vente en ligne, mais ce type de faille peut affecter n’importe quelle application web. Lorsqu’une application compte de telles failles, cela affaiblit directement la sécurité réseau et rend l’entreprise vulnérable. Ces vulnérabilités offrent potentiellement un accès au système d’information voir même à la configuration système. Dans le mesure ou les attaques de type DoS (Denial of Service) visent justement à mettre à terre un système, les failles applicatives sont une incitation au piratage.

L’une des principale méthode d’attaque en 2012

Une mauvaise implémentation de l’application peut rendre le système vulnérable aux attaques du type injection de code SQL. En 2012, l’injection de code SQL fut l’une des méthodes les plus utilisées selon un rapport de Verizon Data Research Investigations. Le scénario type d’une injection SQL survient lorsque le pirate est à même d’inclure des instructions de contrôle SQL dans les champs d’un formulaire. Lorsque le formulaire est validé, le serveur SQL ne se contente pas de stocker les informations, il reconnait et exécute les instructions SQL. Les résultats peuvent être dramatiques : En juin 2012, plus de 6 millions de mots de passe de LinkedIn ont été postés en ligne. Même si la société n’a pas souhaité faire de commentaires, un article de SC Magazine indique de le site a été victime de ce type d’attaques depuis plusieurs mois. D’un certain point de vue, LinkedIn a eu de la chance : les injections de code SQL auraient pu permettre aux pirates d’effacer la plus grande partie des informations du site. En conséquence, le site a pu analyser et corriger ses failles de sécurité … A comparer avec Nortel Networks  dont les données sont restées vulnérables pendant plus de 10 ans …

Les injections de code SQL sont pourtant relativement simples à éviter. Lorsque le serveur reçoit des informations de l’utilisateur, il doit encapsuler les données de sorte que le serveur SQL ne reçoive/perçoive que des données. (autrement dit, aucune instruction SQL).  Si par malheur chaque page web peut se connecter directement au serveur SQL plutôt que d’envoyer ces données à une fonction (sur le serveur) qui s’assurera d’analyser (et de nettoyer le cas échéant) les données reçues, la phase de correction peut être titanesque et fort couteuse. C’est la raison pour laquelle, ces réflexions de sécurisation doivent être menées en amont, dès la phase de conception de l’application web.

Alors, même si les exemples cités sont caricaturaux, la plupart des entreprises sont de tailles plus modeste.

Une récente étude auprès de 501 PME, montrent que 85% d’entre elles ne prennent aucune précaution, en estimant, À TORD, qu’elle sont trop petite pour être une cible. Si vous même qui lisez ce billet pensez que votre entreprise est trop petite pour être la cible d’actes de piratage ou de vandalisme gardez en mémoire qu’un très grand nombre de pirates utilisent des logiciels automatiques qui scanner l’internet à la recherche de vulnérabilités ou de failles applicatives. Certains de ces logiciels se concentrent sur des sociétés de plus petites tailles car elles ont le plus souvent des protections moindres que les géants du marché. La prise de contrôle d’une petite société peut être un point d’entré idéal pour en attaquer d’autres. Les hackers utilisent parfois des sites d’entreprises pour diffuser des informations illégales comme des malwares ou des contenus pornographiques illicites. Pire encore, ces piratent utilisent parfois votre serveur pour envoyer du spam. Etre une entreprise de taille modeste ne vous protège pas ! cela fait juste de vous une cible d’un autre type (que les mastodontes de l’internet) et mettre en œuvre un minimum de sécurité est un excellent investissement.

Utiliser des outils comme OmniPeek pour contrôler la bonne application des règles de sécurité de part et d’autre des firewall est essentiel pour renforcer votre sécurité. OmniPeek simplifie également la visualisation des échanges « poste client » <-> « serveur » pour vous permettre de contrôler les informations échangées. (par exemple que notre serveur ne devrait pas recevoir le prix de l’article mais son code produit).

En fait votre sécurité informatique est comme une porte blindée … plus elle est résistante, et plus vous avez de chance que les hackers abandonnent les attaques à votre encontre, une une porte blindée trop longue à forcer décourage les visiteurs indésirables.

•  •

Librement inspiré de l’article : How Application Flaws Can Affect Your Network Security

Publicités

Identifier et corriger les problèmes de migration IPv6 les plus courants 9 juillet 2012

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , ,
add a comment

Le 6 juin 2012 était le jour officiel du lancement du protocole IPv6 !

L’année passée, lors du jour IPv6 mondial ( Word IPv6 Day), plusieurs sociétés majeures d’internet ont activé l’IPv6 pour une journée de tests. Cette année, lors de l’évènement, les sociétés participantes ont à nouveau activé IPv6 et espéraient ne plus le désactiver. Certains participants, comme Google et FaceBook, ne l’ont d’ailleurs plus jamais désactivé après la première édition de cette journée IPv6. L’année passé, il s’agissait pour la plupart des entreprises d’une journée de tests en grandeur réelle dans le but d’un basculement réussi des fournisseurs d’accès internet, des fabricants de matériels réseau et autres sociétés du web.

Dans les faits, on assiste à une pénurie d’adresses IPv4, , l’Asie a d’ailleurs déjà effectué son basculement … aussi le changement définitif approche à grands pas. IPv6 apportera plusieurs améliorations importantes ( plus de détails :  IPv6: Is It Finally Time ). En fait IPv6 a commencé a apparaitre lors des Jeux Olympiques de 2008.

Dans ce billet nous allons mettre un peu les mains dans le cambouis et voir quels problèmes vous pouvez rencontrer lors de la mise en oeuvre de l’IPv6 dans votre société et comment régler les problèmes.

Connectivité

Historiquement, le plus gros problème avec Ipv6 est justement d’établir la connectivité IPv6. Jusqu’à ces derniers temps il y avait assez peu de fournisseurs d’accès internet qui proposaient IPv6 et moins encore pour un usage personnel. L’un des buts principaux de la manifestation World IPb6 Launch était de fournir l’option IPv6 au plus grand nombre possible grâce aux fournisseurs d’accès internet et à son support dans les routeurs domestiques. Même si il est évident que l’IPv6 ne peut pas encore être disponible pour tout le monde, l’Internet Society visait un objectif de 1% de connectés en IPv6.

Après s’être assuré de la disponibilité effective de l’IPv6, le problème suivant est de savoir comment configurer l’IPv6 en respectant l’IPv4. Doit-on utiliser un mécanisme de tunneling ou l’une des méthode de translation IPv4 ? La réponse tient en 3 mots : Aucune des deux pour la bonne raison qu’IPv6 n’interfère pas avec l’adresse « classique » IPv4. Historiquement, des solutions temporaires aillant eu recours au tunneling n’ont plus vraiment de raison d’être : Le support natif de l’IPv6 par les fournisseurs d’accès internet permet d’utiliser la méthode du « Dual Stack » qui autorise le fonctionnement des 2 versions du protocole de concert.

Avant même d’imaginer activer la connectivité IPv6, n’oublier pas les règles « d’hygiène de base » : Utilisez un firewall !

La plupart des équipements modernes, disposent à minima d’un support basique des polices de sécurisation du trafic.

La bonne nouvelle c’est qu’IPv6 ne nécessite plus l’utilisation du NAT (et ne le supporte pas) les polices de sécurité seront beaucoup plus simples à configurer (et beaucoup plus claires).

Les adresse IPv6 sont assez différentes des adresses IpV4, aussi il est assez difficile de savoir ce que doivent être les « Bonnes Pratiques ».

Il est bien sur tentant d’utiliser Stateless Address Auto-Configuration (SLAAC) pour simplifier la mise en œuvre,  mais ce n’est pas forcément la meilleure idée : SLAAC utilise la MAC address pour générer l’adresse IPv6 afin de limiter le risque d’adresses dupliquées. En plus du soucis d’absence de confidentialité en incluant l’identifiant d’un adresse hardware dans l’adresse routable, SLAAC allonge la taille de l’adresse IPv6 plus que nécessaire. Il est bon de se souvenirs des difficultés rencontrées avant l’apparition du DHCP. Lorsqu’une adresse générée par SLAAC aura un format du type :  2001:db8::7ee9:d3ff:ffe46:86bb, une adresse DHCP pour le même host aura un format comme : 2001:db8::1c. Même si l’utilisation de DHCPv6 prend un peu de temps à mettre en oeuvre, cela rendra l’administration au quotidien bien plus simple.

MTU, fragmentation et ICMP

Le premier problème IPv6 survient avec les mauvaises habitudes contractées avec IpV4 concernant le MTU, la fragmentation et ICMP.

En IPv4, les paquets de grande taille, sont fragmentés en plus petits paquets par les routeurs disponibles sur le cheminement des trames.

Il en va tout autrement en IPv6 ou les routeurs vont retourner un paquet ICMPv6 d’erreur pour les paquets trop grands. C’est au poste émetteur de gérer sa propre fragmentation.  Pourquoi un poste devrait il gérer une fragmentation layer 3 peu fiable lorsque TCP c’est charge parfaitement au layer 4? Si un programmeur n’interroge pas l’OS pour s’enquérir de la MTU, et se base sur la MTU standard Ethernet de 1500 octets, moins 20 octets pour l’IPv4 et 20 autres pour TCP, le calcul laisse penser que 1.460 octets sont disponible pour les données TCP dans chaque datagramme. Malheureusement l’entête IPv6 est à minima de 40 Octets soit 20 Octets de moins disponibles !

Heureusement, la plupart des applications réseau comme les navigateurs web, ont tous été testés en IPv6, il peut rester des applications qui ne sont pas codés pour utiliser ces valeurs dynamiques pour la pile réseau. D’autant également, que les politiques de sécurité restrictives en IPv4 bloquent les paquets ICMP à l’exception du ping. De la sorte, la conjonction des entêtes trop long, l’absence de fragmentation par les routeurs associé au blocage partiel des trames ICMPv6 va générer des paquets qui n’atteindront pas leur destination et ne permettront pas le retour (au poste émetteur) des messages de diagnostic d’erreur. Ce problème sera particulièrement difficile à identifier sur switches des réseaux locaux qui autorisent les jumbo frames ethernet puisque les dépassement de taille y sont autorisés et gérés. Les paquets transiteront sans problèmes sur les sous réseaux locaux entre les switches L2 et L3 … mais seront bloqués par les routeurs.

HTTP Compliance

Le dernier problème lié à la transition IPv6 est quelque peu plus subtil … HTTP est un protocole plutôt simple de part sa conception, mais qui cache en fait une grand complexité parce que la plus grand majorité des pages web incluent des tags pour indiquer au navigateur de charger des contenus additionnels qui peuvent provenir de différents serveurs.

Les pages web sur les serveurs hébergés sur des hosts IPv6 pourront être amenés à charger des contenus sur des serveurs IPv4. Durant la phase de cohabitation, les pages web seront alors chargées bien plus lentement si un DNS non compatible IPv6 ignore les requêtes des enregistrements AAAA IPv6, provoquant un time out sur le poste utilisateur qui essayera d’accéder à l’enregistrement A en IPv4. Et comme ce problème n’existe pas pour le serveur … il risque fort de persister jusqu’à la mise à jours des DNS ou des infrastructures de l’hébergeur. Fort heureusement ce type de problème est déjà survenu par le passé depuis 2005 ( voir RFC 4074). Le choix du format de requête AAAA ou A est sous le contrôle du navigateur et ce problème est sérieusement à l’étude en ce moment même.

Les études d’APNIC Labs fin 2011 ont montré qu’Internet Explorer 9 à une timeout de 21 secondes, mais Chrome utilise une méthode qui réduit ce timeout à 0,3 seconde ! (et les versions de FireFox sont encore moins bien loties). D’autres solutions peuvent passer par un filtrage et l’utilisation d’un serveur DNS local qui fera le lookup pour le poste utilisateur, ce qui résoudra le problème grâce à une combinaison caching et forced failback. Le paradoxe d’internet est qu’HTTP a été la clé de voûte de l’adoption massive d’IPv4 mais qu’il sera sans doute le dernier des protocoles majeurs a devenir compatible avec l’IPv6.

Le bon coté des choses est que les utilisateurs ne verront pas la différence lorsqu’ils utiliseront IPv6. IPv6 est supporté par l’ensemble des acteurs majeurs d’internet, y compris les par les navigateurs Web. Et même si il reste de petits problèmes, comme indiqué ci-dessus pour les sites web IPv6 faisant appel à des contenus hébergés sur des serveurs en IPv4, la plus grande partie du web ne posera aucun soucis en IPv6.

Pour les applications plus anciennes et les utilisateurs comme les développeurs qui ont besoin d’utiliser de nombreuses adresses IPv4 il n’y a rien à craindre non plus. IPv6 est un nouveau protocole : il ne modifie en rien le fonctionnement d’IPv4 et les deux vont pouvoir tourner en parallèle jusqu’à ce que les administrateurs réseau décident de désactiver l’IPv4 … très certainement dans plusieurs décennies.

IPv6 est à notre porte, et il est prudent (essentiel) de s’y préparer dès maintenant. Dans cet optique, il est essentiel de disposer des outils temps-réels, comme OmniPeek, qui permettrons de comprendre et résoudre rapidement tout les problèmes rencontré lors de la transition.

•  •

Librement inspiré de l’article Common Deployment Pains with IPv6: How to Identify and Fix Them 

Capturer des données Wireless avec les AP Cisco en mode sniffer 2 juillet 2012

Posted by frnetworker in Diagnostic Réseau, OmniPeek, Sans, Wireless.
Tags: , , , , , , , , , , , , , , , , , ,
2 comments

Réglages d’un point d’accès Cisco (AP) en mode Sniffer et d’OmniPeek pour capturer à distance

Savez-vous que vous pouvez utiliser les WLC et LAPs Cisco en mode sniffer en conjonction avec OmniPeek ?

Gagnez en temps et en efficacité avec OmniPeek

plus besoin de vous déplacer !

Depuis OmniPeek, en passant par le réseau ethernet vous pouvez capturer des données depuis de multiples AP (Access Point), ce qui permet une grande efficacité pour la capture multi-canaux. Quand il n’y a pas itinérance, il est possible de déplacer l’AP ‘Sniffeuse’ à proximité de l’AP pour laquelle on souhaite faire un diagnotique.

Dans le cas du roaming, les APs placées en mode sniffer, doivent se trouver à proximité des différentes AP que va utiliser le poste client. Cela permettra en quelque sorte d’avoir le « point de vue » de l’AP liée au poste client.

Si l’on s’intéresse plus particulièrement au point du vue du poste utilisateur, une version d’OmniPeek installée sur un ordinateur portable avec plusieurs adaptateurs wifi (un par canal) sera un complément idéal.

Étapes de la configuration

Configuration des WLC / AP Cisco

La première étape consiste à placer l’AP en mode sniffer. ATTENTION, elle ne sera plus en mesure de servir de point d’accès pour les utilisateurs.

Configurer l’AP en mode sniffer pour capturer les paquets radio

La borne wifi va rebooter et ne sera plus disponible en tant que point d’accès, elle devient en quelque sorte votre oreille.

Pour compléter la configuration il faut :

  • activer le mode sniffer
  • sélectionner le canal
  • spécifier l’adresse IP du poste OmniPeek

Régler le canal et l’adresse IP du poste sur lequel est lancé OmniPeek

OmniPeek recevra le trafic 802.11 encapsulé en utilisant AiroPeek Protocol (ancêtre d’OmniPeek) avec comme source le port UDP 5555 et comme destination le port UDP 5000.

Configuration d’OmniPeek

Pour permettre à OmniPeek de recevoir le trafic que stream l’AP en mode sniffer, il faut en premier lieu créer un « Cisco Remote Adapter » (adaptateur Cisco distant) depuis le menu Adapter de la fenêtre Capture Options.

Créaton du Cisco Remote adapter dans le sniffer OmniPeek

Indiquez un nom vous permettant d’identifier l’adapteur et une adresse IP si vous souhaitez que cet adapter ne soit lié qu’à une AP spécifique.

Pour ma part, j’utilise toujours l’adresse IP de point d’accès qui sniffe avec un nom (Name) parlant : par exemple TLS, BAT B, 3ieme, Salle Conférence ce qui me permet de la retrouver rapidement.

Vous pouvez alors lancer la capture après avoir enregistré vos réglages.

Lancer la capture des paquets depuis l’AP en mode sniffer

La capture commence comme si vous utiliser un réseau wifi local. (L’interface d’OmniPeek est identique pour une capture locale ou distante). Le flux radio envoyé par l’AP s’affiche au fil de l’eau dans la fenêtre d’OmniPeek et vous pouvez commencer à éditer les paquets.

Un paquet reçu de l’AP décodé par OmniPeek

•   •

Librement inspiré de l’article : « Collecting a Wireless sniffer trace using the Cisco Lighweight AP in Sniffer mode« 

%d blogueurs aiment cette page :