Working with MasterKeys
Author : Arnaud Fauvel (Obiane – Orange Group – France) Introduction : As explained in “SOL9420: Installing a UCS file containing an encrypted passphrase”: Passphrases used for configuration items, such as monitors, profiles, and Secure Sockets Layer (SSL) keys, are stored in the configuration file in encrypted format. The BIG-IP system uses a hardware-key encrypted master key to encrypt and decrypt passphrases contained in the configuration file. These hardware-key encrypted passwords can be identified with a prefix of $M$. Prior to BIG-IP 11.5.0, only the passphrases used for SSL private keys are stored in encrypted format. In BIG-IP 11.5.0 and later, passphrases used for other configuration objects, such as monitors and profiles, are also stored in encrypted format. To complete the description, the master key unit is: - Different on each standalone device but shared within a cluster. - Different on each vCMP guest and is dissociated from vCMP host. How to modify MasterKey As explained in the SOL it’s possible to modify the master key of the device with the following command: f5mku -r There are two bad behaviors of this command: - If there are already configuration items with encrypted parameter, the bigip is unable to load the configuration. We have to remove SSL key passphrase encryption as explained in the SOL14302: Replacing a VIPRION chassis that has one or more blades installed. - On a vCMP Host or Guest after executing the command the device become unstable. F5 support provides me the following commands explained in the following “SOL13508: ConfigSync operations fail to complete and generate a validation message”: modify /sys crypto master-key prompt-for-password This command is magic: - A new masterkey is defined based on a provided password - Saving the configuration automatically re-encrypts any encrypted-SSL-key passphrases, using the new master key, prior to saving them in the configuration file. - It works on BIGIP or vCMP guest. Considering the masterkey of the vCMP Host it’s not so simple. The precedent command can be used but all vCMP Guest will be unable to retrieve their master key: notice mcpd[6230]: 01071029:5: Cannot open unit key store notice mcpd[6230]: 01070406:5: Removed publication with publisher id ha_table_publish warning mcpd[6230]: 012a0004:4: halStorageRead: unable to read storage on this platform The masterkey of the vCMP host seems to be used for a unit key store shared with all vCMP Guest. You will find bellow a scheme which tries to represent the master key architecture: How to restore archive configuration without removing SSL key passphrase encryption The “SOL9420: Installing a UCS file containing an encrypted passphrase” is not really satisfactory because as explained before the f5mku -r commands doesn’t work with vCMP guest. But by using the magic commands it’s works very well J. 1. After installing a BIGIP or vCMP Guest, log in on to de device and force the master key with a password by typing the following command: # tmsh # modify /sys crypto master-key prompt-for-password enter password: password again: # save /sys config Saving running configuration... /config/bigip.conf /config/bigip_base.conf /config/bigip_user.conf 2. Save regulary the configuration (using iApp or remote expect script): save /sys ucs passphrase 3. Log in to the RMA BIG-IP system command line. 4. Install the master key with the password you enter in step 1 to the RMA BIG-IP system using the following command syntax: # tmsh # modify /sys crypto master-key prompt-for-password enter password: password again: # save /sys config Saving running configuration... /config/bigip.conf /config/bigip_base.conf /config/bigip_user.conf 5.Restore the UCS file to the RMA BIG-IP system using the following command syntax: tmsh load sys ucs .ucs no-license
Comment se protéger des cyberattaques DDOS ?
De nombreux sites Web institutionnels et de Presse Français connaissent actuellement des cyberattaques visant à les rendre indisponibles ou à en défigurer le contenu. Cyberattaques en défiguration Dans le cas d’attaques en défiguration (ou défacement), les cyberattaquants exploitent soit des vulnérabilités des sites web ou de leurs outils de gestion de contenu (CMS) pour en prendre le contrôle afin d’en modifier le contenu. Cyberattaques en DDOS Les attaques en Deni de Service Distribuées ou DDOS ont pour but de saturer les ressources du système d’information de la victime, soit en saturant par exemple les infrastructures et les liens réseaux (attaque dite volumétrique) soit en épuisant la capacité des services applicatifs (attaque dite en épuisement de ressources). Une attaque DDOS n’a pas besoin d’être volumétrique pour faire tomber un site web. Elle peut tout à fait être lente et silencieuse au niveau réseau mais ne toucher que la couche L7 applicative. Techniques d'exploitation des vulnérabilités En résumé, je citerais: Attaque en injection (par exemple sur SQL ou sur le système d’exploitation) visant à exposer les informations confidentielles, à corrompre les données ou à forcer l’interpréteur à exécuter des commandes non désirées. Attaque en Cross-Site Scripting (XSS) qui permet d’exécuter un script dans le but de pirater les sessions web des utilisateurs, défigurer les sites web ou rediriger l’utilisateur vers des sites malicieux. Attaques sur l’authentification, le contrôle d’accès et la gestion de sessions : un système d’authentification ou de gestion de session mal implémenté peut conduire à une compromission de mots de passes, de jetons, de clés de sessions visant à usurper l’identité numérique. Attaque sur les références directes au objets (comme les fichiers, répertoires, clé de base de données, etc) : sans contrôle d’accès ou autre protection, un attaquant peut manipuler ces références afin d’accéder à des données non autorisée. Manipulation des cookies, de paramètres ou des champs cachés. Attaque en Buffer Overflow : Exploitations malicieuses des buffers mémoire pour arrêter des services, avoir les accès au Shell et pour propager des programmes malicieux. Attaque en Cross-Site Request Forgery (CSRF) : qui exploite un accès authentifié en usurpant l’identité d’un utilisateur authentifié. Attaque sur des URLs non restreintes Attaque par dictionnaire sur le contrôle d’accès au système Attaques en déni de service sur la couche 7, attaques en brute force et les attaques de type Web Scrapping. Attaque sur les couches de transport Attaques sur les Redirects ou les Forward non contrôlés. Des projets comme OWASP,WASCou leSANSfont un tour d'horizon des menaces et des techniques d'exploitations. Anatomie d’une cyberattaque sur HTTP ou HTTPS Généralement, une cyberattaque sur un site Web se déroule en 3 étapes : Ciblage et reconnaissance : des robots ou des scripts effectuent des scans pour identifier et récolter des informations sur le site web (les URLs), ses ressources (capacités CPU) ainsi que ses ressources réseaux (bande passante) Sélection des vecteurs d’attaques et exploitation des vulnérabilités Bascule sur une attaque en DDOS si l’exploitation de vulnérabilités ou si le brute force sur le contrôle d’accès n’aboutissent pas. Les contre-mesures Pour les cyberattaques en défiguration, il est possible de les empêcher en appliquant les bonnes pratiques rappelées par l’anssi ainsi que les recommandations sur les contre-mesures ici, tel que la mise en place de pare-feu Applicatif Web (WAF) comme F5 ASM. Comme le rappelle le Gartner, un FireWall réseau ou un IPS ne protègent pas contre les attaques visant les services web. Seul un WAF apporte cette protection. En revanche, il est plus difficile de contrer une cyberattaque DDOS et on ne pourra qu’en atténuer son effet, en absorbant la charge durant l’attaque. Bien sûr, il y a des bonnes pratiques à suivre pour parer aux attaques en DDOS à mettre en place avant l’attaque de façon préventive (l’architecture, la capacité, la détection, etc) mais aussi de façon réactive (l’analyse, les mesures techniques, la reprise sur incident, etc). Dans le scénario d’attaque en déni de service distribué, très souvent quand les mesures techniques sont appliquées durant l’attaque, il est très difficile de différentier les utilisateurs légitimes des attaquants alors le site web est déjà fortement impacté voire déjà tombé. Je vous invite à lire le livre blanc F5 pour atténuer les attaques DDOS. La réponse F5 aux cyberattaques DDOS Face aux cyberattaques DDOS, qu’elles soient de type réseau (L3 / L4), sessions (L5 / L6) ou applicatives (L7), F5 Networks possède la technologie qui permet non seulement d’atténuer ces attaques mais aussi de protéger contre les outils de reconnaissance, les bots et les attaques lentes. La solution de protection anti-DDOS de F5 combine des services à déployer dans le Datacenter (in situ) et dans le Cloud. Le service dans le Cloud appelé Silverline est un service à la demande qui empêche les attaques volumétriques d’atteindre le réseau du Datacenter et fourni une protection anti-DDOS multi-vecteurs et multi-niveaux. Une fois, les attaques volumétriques atténuées, c’est la solution in-situ qui prends le relai pour atténuer les attaques de volume moyen, les attaques sur les sessions (SSL et DNS par exemple) ainsi que les attaques applicatives avancées. Cette solution in-situ fait appel à plusieurs modules F5 : AFM, LTM, GTM et ASM. L’architecture de référence F5 anti-DDOS Elle permet aux administrateurs sécurité réseau d’étendre leurs règles afin d’atténuer les risques d’attaques zéro-day. Cette architecture combine de manière transparente le service F5 Silverline avec les solutions Application Delivery Controller (ADC) de F5 pour offrir la solution de protection DDoS la plus complète. Silverline : un service anti-DDOS à la demande F5 propose différents niveaux de protection, personnalisables en fonction des besoins spécifiques des entreprises et des profils des attaques potentiels : Always On ™ - Première ligne de défense. Cet abonnement permet de bloquer de manière continue le trafic corrompu. Le trafic réseaux du client passe par le service de scrubbing Silverline et seule le trafic légitime est envoyé sur le réseau du client. Always Available ™ - Protection primaire sur demande. Cet abonnement permet de bloquer le trafic malveillant en cas d'attaque. ASM : des protections anti-DDOS avancées A partir de la version 11.6, ASMembarque un mécanisme de défense proactif contre les attaques par des robots web (bot). Il protège contre les attaques en déni de service distribuées (DDoS), le webscrapping, la reconnaissance et les attaques en brute force. Ce mécanisme appelé «Proactive Bot Defense» a pour rôle de compléter les méthodes existantes d’atténuation. Quand cette fonctionnalité est activée, lorsqu’un client accède au site web pour la première fois, le système injecte un challenge Javascript en lieu et place de la réponse initiale, dans le but de valider si le client est un navigateur web légitime ou s’il s’agit d’un robot (bot). Le navigateur web légitime répond au challenge correctement et renvoie la requête avec un cookie signé qu’ASM valide. Il est alors autorisé à accéder au serveur. Parmi les autres techniques de détection de robot web dans ASM, on peut citerles mécanismes de Détection d’activité suspecte clavier et Souris, la Détection de surf rapide. De même, pendant la cyberattaque, ASM active des mécanismes d'atténuation spécifiques comme le Client-Side Integrity Defense ou le Captcha avec du rate limiting en hardware. De la visibilitépendant l'attaque Le graphique ci-dessous montre comment le trafic a été géré par le système, avec des données agrégées et mises à jour toutes les 5 minutes. Un fort pourcentage de requêtes hostiles ont été bloquée conformément à la politique de prévention définie dans le profile DoS. Cette politique utilise du Request Blocking avec du rate limiting basé sur l’URL et l’IP source. Lorsque le trafic est normal, on constate typiquement plus de trafic en passthourgh et moins de trafic bloqué. Pour en savoir plus On organise un Webinar sur le sujet anti-DDOS, le Jeudi 29 Janvier à 11h. Inscriptions ici.F5 Networks - Silverline WAF Express overview
Silverline Web Application Firewallis a cloud-based service built on BIGIP Application Security Manager (ASM) – to help organizations protect web applications and data, and enable compliance with industry standards, such as PCI DSS. F5 Networks proposes 2 service options, provided by Silverline cloud-based application service platforms: A fully managed service, set up, deployed, managed, and maintained by experts in our Security Operations Center (SOC) with 24x7x365 support. This service is named Silverline WAF Managed An express service option, enabling rapid self-service deployment of expertly maintained policies across hybrid environments to protect apps, anywhere. This service is named Silverline WAF Express. Both services allow you to remove the complexity of WAF management, increase the speed to deploy new policies, and decrease operational expenses. This article covers the Silverline WAF Express option.In this video, I demonstrate how to deploy a WAF policy in front of a web application in less than 5 minutes. I demonstrate: How to push certificates and keys How to create the service in Silverline How to check logs, violations … How to get reports on HTTP, SSL …Per-App VPN AirWatch et F5 BIGIP APM
Nowadays, with MDM, we can push VPN configurations to mobiles devices. A new kind of VPN called Per-APP VPN (Android 5.0 or iOS 7.0 minimum) is available on MDM like AirWatch, MobileIron ... Per-APP is a brand new VPN tunnel concept. This Per-App VPN tunnel is started only for a specific application on the mobile terminal. All flow from this app are routed into this tunnel. All other trafic uses local NIC (WIFI, 3/4G without VPN). It's a little bit different from On-Demand VPN. On-Demand start when a specific network is requested and all trafic goes through this tunnel whatever the application. This video explains how to set AirWatch side and APM side ///////////////////////////////////////////////////////////////////////////////////////// Avec un MDM (Mobile Device Manager), il est possible de pousser sur vos terminaux mobiles (iOS 7.x et Android 5.0 minimum) un profile de configuration VPN dit "Per-App VPN". Un Per-App VPN est un VPN monté à la demande par une application sur le terminal mobile. Cela se rapproche du "On-Demand" à la différence que seul le flux en sortie de l'application ira dans le tunnel SSL. Contrairement à un tunnel On-Demand où tous les flux transitent dans le tunnel SSL. Dans cet article (vidéo en anglais), je vous présente la mise en place d'une solution Per-App VPN avec le MDM AirWatch et la gateway SSL F5 BIGIP APM. Pour cela : AirWatch intègre dans son MDM les briques VPN SSL F5 afin de simplifier la configuration des profiles VPN SSL. Aucun code XML n'est nécessaire car le EDGE client est déjà connu du MDM AirWatch. F5 intègre les API avec les solutions MDM telles que AirWatch.Comment se protéger des Ransomwares ?
Le problème des ransomwares se développe à grande vitesse. Ces derniers sont de plus en plus utilisés par les hackers car ceux-ci ont besoin de plus en plus d’argent et cela de plus en plus souvent. Si ceux-ci ne bloquent souvent que certains postes, l’ampleur du phénomène et sa récurrence pourrait en faire une menace plus importante que prévue. Un ransomware cryptographique est un outil malveillant chiffrant une partie des donnés d’un poste de travail. Pour cela, les hackers utilisent des mécanismes de clés publiques et clés privées (générées et téléchargées au moment de l’installation du ransomware). La clé privées étant en possession du hacker, ce dernier exigera de la victime attaquée le paiement d’une rançon, généralement en Bitcoin, afin de disposer de cette clé privée. Le ransomware cryptographique le plus connu s’appelait CryptoLocker. Il a été éradiqué suite à la dissolution du botnet Gameover Zeus en 2014. Mais un petit nouveau arrive sous le nom de Cryptowall (version 3.0). Il est très proche de CryptoLocker mais surtout apporte de nouveaux mécanisme de non-détection par les outils de protection. Ce matin, jeudi 28 janvier 2016, le record de rançon a été battu avec le ransomware "7ev3n" pour la modique somme de 13 bitcoins soit presque 5000$. Il est quasiment impossible pour une victime - particulier ou entreprise - de récupérer ses données une fois le ransomware installé - hormis payer et récupérer la clé privée. Toutefois, le paiement de la rançon ne garantit en aucun cas que les criminels fourniront à la victime la clé qui lui permettra de retrouver ses données. Il est donc très important de se protéger contre ce type d’outil malveillant. 1. Pour cela, il faut en tout premier lieu, former et sensibiliser les utilisateurs au bonnes pratiques : - Ne jamais ouvrir un document venant d’un émetteur inconnu - Vérifier l’émetteur et son adresse. Il est très facile de se faire passer pour quelqu’un lors de l’envoi d’un email. - Faire des sauvegardes régulières de ses données 2. Ensuite, il est très important de disposer d’outils de protection à jour : - Antivirus à jour - Système d’exploitation à jour - Navigateur internet à jour. Enormément d’entreprises sont encore dans des versions d’Internet Explorer non corrigées et disposant de failles de sécurité exploitées par les malwares. 3. Dernier point, pour que le ransomware puisse récupérer ses binaires et les clés de chiffrement, il devra accéder à Internet pour joindre son serveur. Il est donc important de disposer d’outil de filtrage internet à jour (liste de domains, d’URL et d’IP frauduleuses). Très souvent, les ransomware passent par le réseau Tor pour accéder à leur serveurs. Des outils de filtrages tels que les Passerelles Internet et les pare-feu permettent de contrôler l’accès à ce type de réseaux. F5 Networks dispose d’une solution de Passerelle Internet nommée Secure Web Gateway, disposant du moteur d’analyse et de catégorisation de Websense. Cette passerelle permet de contrôler l’accès aux sites distants pour chaque utilisateur et dispose d’outils d’analyse temps réels permettant de s’assurer qu’aucun appareil n’aille se connecter sur un réseau ou un site frauduleux. De plus, la Secure Web Gateway permet de contrôler le flux retour en cas de téléchargement d’un malware venant d’un site classé comme frauduleux.HTTP/2 : quels sont les nouveautés et les gains ?
Depuis le 15 Mai 2015 - date de la ratification de la RFC 7540 - HTTP/2 est officiellement devenu le nouveau standard du Web. Il faut dire qu’après 16 ans de bons et loyaux servicesremplis par HTTP1.1, cette mise à jour était très attendue pour répondre aux besoins du web d’aujourd’hui. En effet, les dernières tendances montraient un accroissement continu du nombre et de la taille des requêtes web. En moyenne, une page Web pèse 2Mo et contient 80 éléments ! Temps de chargement: quand tu nous tiens ! Qui n’a pas pesté contre les pages web qui mettent une éternité à se charger ? Le dernier speed index montrait un temps de chargement moyen de l’ordre de 11s pour les 40 ténors du web et du e-commerce en France. HTTP1.1 est très sensible à la latence réseau et c’est justement cette latence –plus que la bande passante- qui influe sur les temps de chargement. Un autre point faible d’HTTP1.1 affectant le temps de chargement est le traitement des requêtes qui se fait séquentiellement en FIFO: le navigateur est obligé d’attendre la réponse du serveur Web avant de pouvoir soumettre une autre requête. Bien sûr, le pipelining a amélioré–partiellement- les choses en permettant de lancer plusieurs requêtes en même temps mais cela n’empêchait pas qu’une requête demandant un traitement long puisse bloquer la file d’attente (Head of Line Blocking). HTTP1.1 avait aussi une fâcheuse tendance à consommer les connections TCP. Alors que les navigateurs sont limités à 6-8 connections TCP par hostname cible, une des techniques pour améliorer les performances, le sharding (où le découpage de la ressource Web sur plusieurs hosts cibles) a permis d’outrepasser la limitation des 6 connections TCP en parallélisant en quelque sorte le chargement d’une page web, mais au prix d’une explosion du nombre de connections TCP. Aujourd'hui, une page web requiert du navigateur web d’établir en moyenne 38 connections TCP ! Ce qui ne change pas avec HTTP/2 HTTP/2 a été conçu pour ne pas impacter le Web, de faire en sortequ’il puisse prendre en charge nativement des clients HTTP1.1 et de proxifier les serveurs en HTTP1.1. Il est ainsi complètement retro-compatible avec HTTP1.1. Cela veut dire que : - Les méthodes HTTP1.1 restent les mêmes: GET, POST, PUT, HEAD, TRACE, DELETE, CONNECT … - Les schémas URI http:// et https:// restent inchangés. - Codes de statuts, les entêtes, la négociation restent le mêmes. Ce qui change Par rapport à HTTP1.1, HTTP/2décorrèle le protocole lui mêmede la couche de transport TCP, en introduisant unecouche d’abstractionquia pour objectif d’optimiser le transport des sémantiques HTTP. L’objectif étant de réduire le nombre d’allers retours, la taille des entêtes échangés,de lever le problème du Head of Line Blocking…bref, de faire un meilleur usage du réseau. L’autre objectif d’HTTP/2 est de normaliserles extensionsoptionnellesde HTTP1.1 telles quele pipelining, l’inlining, le sharding, la concaténation. Il faut dire que les 4 façons normalisées de parser un message HTTP1.1ou les extensions optionnelles -pas toujours bienou toutes implémentées- pouvaient poser des problèmes d’interopérabilité. Par exemple, le pipelining est désactivé par défaut sur les navigateurs web afin de garantir une interopérabilité large. L’approche choisie sur HTTP/2 est à l’opposé de ce qui a été fait sur HTTP1.1: il n’y a plus d’options, ni d’extensions.Les spécifications sont obligatoires et le protocole est désormais binaire (fini au passage le telnet sur le port 80), et donc plus compact et plus facile à décoder. Multiplexage C’est la nouveauté phare du protocole. HTTP/2utilise la notion de trames binaires et permet l’envoi des requêtes et la réception des réponsesen parallèle et indépendamment l’une de l’autre, sur une seule connexion TCP. Une réponse qui requiert du temps de traitement ne bloque plus les autres. Celase fait via des “streams” qui sont des séquences de trames bi-directionnelles échangés entre le client et le serveur. Une connexion http/2 peut contenir une centaines de streams ouverts sur une seule connexion TCP et chaque stream possède une notion de priorité qui peut être modifiée dynamiquement par le navigateur web. Compression d’entêtes Avec HTTP1.1, il fallait en moyenne 7 à 8 échanges TCP pour charger les entêtes d’une page web contenant 80 objets.Les entêtes étantsouvent répétitifs et de plus en plus volumineux, la compression est un bon moyen de réduire les échanges. Pour HTTP/2, HPACK a été développé pour être plus rapide que deflate ou gzip, autorisant la ré-indexation par un proxy et surtout non vulnérable à l’attaque CRIME et BREACHqui touchaient la compressiondans TLS et SPDY. Avec HTTP/2, les entêtes vont regroupés et servis en une seule fois via une trame et un stream spécifiques. Pour tout ce qui est payload HTTP,le protocole proscrit l’utilisation de la compression (y compriscelle deTLS) dès qu’il s’agit de confidentialité (secure channel) etque la source de données n’est pas de confiance. Server Push Sur HTTP 1.1,le navigateur récupère les données du serveuren lui demandant explicitement la ressource souhaitée.au fur et à mesure du chargement de la ressource HTTP, le navigateur va parser le DOM etdemander au serveur de lui fournirles objets associés(CSS, JS, images, etc). Avec le Server Push,lorsque lenavigateur va demander au serveur la ressource HTTP (par exemple /default.html), le serveur va bien sûr servir la première requête mais il va aussi lui pousser préemptivement tous les objets associés et qui seront placés dans le cache du navigateur (ils faut quand même que les objets servis soient “cacheables”). Quand celui-ci devra faire le rendu de la page, les objets étant déjà présent dansle cache,le temps de d’affichage en sera accéléré. Le Server Push est une fonctionnalitéactivée par défaut coté serveur mais quireste désactivable et contrôlableparle navigateur. Lors de l’établissement de la connexion, si le navigateur envoi au serveur le paramètreSETTINGS_ENABLE_PUSH avec la valeur 0, le serveur s’abstient de pousser les objets et bascule sur l’ancien mode où la navigateur va récupérer objet par objet (client pull). Même si le Server Push est actif entre le serveur et le navigateur,celui-cipeut aussi à tout moment envoyer au serveur une trameRST_STREAM pour lui dire d’arrêter de pousser du contenu. Chiffrement en TLS HTTP/2 prévoit deux mode de transports: HTTP/2 sur TLS (h2) pour les URIs en https:// et HTTP/2 sur TCP (h2c) pour les URIs en http://. Concernant les URI http:// (en clair sur le port 80) etaprès des débats houleux au sein du groupe de travail, le protocole prévoit un mécanisme où le clientenvoie au serveurune requête avec l’entêteUpgrade et la clé h2c. Si le serveur parle HTTP/2 en clair, il envoie au client une réponse “101 Switching” etbascule sur HTTP/2. Même si la RFC ne l’impose pas, les implémentations actuelles d’HTTP/2 sur les navigateurs et les serveurs web ne se font que sur du TLS (l’exception est avec les implémentationsde Curl et de nghttp2) Dansle mode h2 (chiffré), HTTP/2 impose un profil TLSdont les caractéristiques sont lessuivantes: -TLS en version 1.2 à minima - une liste noire (blacklist) de suites de chiffrement à ne pas utiliser (en particulier, les algorithmes d’échange de clés qui sont non éphémères sont exclus) - les extensions SNI et ALPN doivent utilisées. Le protocole ALPN(Application LayerProtocol Negociation) normalisé pour HTTP/2 remplace le NPN de SPDY et permet de négocier le protocole qui va être utilisé au dessus de TLS. La différence entre ALPN et NPN est qu’avec ALPN, c’est le serveur qui choisit le protocole utilisé parmi une liste de protocoles proposéspar le client. - la compression TLS doit être désactivée (à cause des attaques BREACH et CRIME) - la renégociation TLS doit être désactivée - les échanges de clés doivent se faire en crypto éphémère: DHE en 2048 bits minimum et ECDHE en 224 bits minimum. - le socle commun à respecter est : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256avec leP-256 Elliptic Curve Support de HTTP/2 sur BIG-IP Le F5 BIG-IP a étéle premier ADC du marchéà prendre en charge HTTP/2 et la version 11.6 sorti en septembre 2014 supportait déjà le draft 14 en mode expérimental. Le support d’HTTP/2 dans sa spécification finale est pris en charge dans la version 12.0 de TMOS. Démonstration Une vidéo de démonstration de HTTP/2 sur BIG-IP vaut mieux qu’un long discours. On y voit une page web contenant 100 objets mettant 17 secondes à se charger en HTTP1.1 et seulement 6 secondes de chargement en HTTP/2 ...Azure Security Center - How to protect your Web Applications in Azure
Azure Security Center allows you to asses your security in Azure. To do so, Azure Security Center can advise you on several layers : Network Security Application Security Rest of the security For the Application layer security, Azure will propose you to protect your Web Application with a WAF. F5 Networks is fully integrated in this process and Azure will propose you to deploy the F5 WAF automatically. Nothing to know !!!! Azure will deploy the WAF and configure the WAF based on the Web Applications you want to protect. When done, Azure will change the network security on new protected Web Applications in order to disallow direct access to the Web Application and only allow trafic via the WAF. Please find below a 5 minutes video demonstrating the ease to protect a Web Application with F5 WAF in Azure.Attaque DNS DYN, ou comment se protéger du malware Mirai
En quelques semaines, le monde de l’Internet vient de subir une série d’attaques DDoS ciblée et encore inconnue. Inconnue par la technique utilisée et par le volume. Ces attaques ont une particularité : le nombre de sources utilisées pour chaque attaque. Ce nombre dépasse les 100 000. Mais il est très difficile de savoir ce qui se cache derrière une adresse IP à cause du Spoofing et du NAT. Comment un BotNet de plusieurs centaines de milliers de machines (ou objets) a pu être constitué aussi rapidement et ceci sans être détecté ? Tout simplement grâce à un « simple » malware nommé « Mirai ». Mirai, comme tout malware, est très bien pensé et peut donc faire de très gros dégâts. Sa particularité est de s’efforcer à s’installer cibler les objets connectés (IoT ou Internet Of Things) telles que les caméras IP grâce à un outil appelé Loader. Rechercher un IoT sur Internet est très simple, via Shodan par exemple (https://www.shodan.io/). Une fois ces objets ciblés, ce «Loader» teste les diverses vulnérabilités connues afin de pénétrer l’objet. En effet la sécurité de ces objets est souvent la dernière roue du carrosse par rapport aux enjeux que représentent la course à l’innovation et la disponibilité de ces objets sur le marché. En conséquence beaucoup de ces objets ne sont pas ou peu protégés et sont bien souvent configurés avec les identifiants par défaut du constructeur. Mirai et son loader va donc essayer les différents identifiants connus pour se connecter aux objets. Une fois connecté sur l’équipement IoT, le Malware Mirai s’installe et se connecte à son centre de commandes (Command And Control) afin de recevoir ces éventuels ordre d’attaques. Ci-dessous, un schéma (source Level3) qui résume le fonctionnement de Mirai en expliquant les différents acteurs impliqués lors des 2 phases de ciblage des IOT puis d’attaque une fois le BotNet constitué. Quelles sont les vecteurs d’attaques utilisés par MIRAI? A la suite des attaques OVH et Krebs, le code source de Mirai a été délibérément mis en ligne par son créateur. F5 Networks, via ses F5 labs, a donc analysé le code source de Mirai afin de comprendre les différentes attaques que celui-ci pouvait générer. Il y a plusieurs attaques possibles, certaines n’étant pas encore totalement codées. La principale utilisée ces dernières semaines s’appelle «DNS Water Torture». La technique est très simple mais diffère des techniques de «DNS reflection» habituelles. Celle-ci nécessite beaucoup moins de ressources de la part du Botnet, en s’appuyant sur le serveur DNS récursif de l’opérateur (le resolver ou tout simplement le DNS sur lequel la box internet du botnet se connecte). Ce sont ces Resolvers DNS qui vont s’occuper de l’attaque en ciblant le serveur DNS de la victime. Dans cette attaque, le Botnet envoie une requête «légitime», c’est-à-dire bien formée et donc conforme à la RFC, contenant le nom de domaine de la cible à résoudre, mais en y ajoutant un nom de machine aléatoire et non-existant dans la zone DNS du domaine visé. Ainsi, le résolveur DNS de l’opérateur transfèrera cette demande au DNS cible. Le DNS cible répondra que ce nom de machine n’existe pas. Ce type de réponse n’étant pas cacheable par l’infrastructure DNS l’attaquant est sûr d’atteindre le serveur cible. L’attaque est déterminée , il ne reste plus qu’à y ajouter la puissance de tir apportée par le BotNet MIRAI. L’attaque devient efficace lorsque le serveur DNS de la cible ne répond plus. Automatiquement, le résolveur DNS basculera sur le second serveur DNS de la cible. Et ainsi de suite. A l’aide d’un BotNet puissant, l’attaquant fera tomber tous les serveurs DNS de la cible comme des dominos. En analysant les logs , la société Dyn s’est aperçue que 24% du trafic provenait de 4 serveurs DNS récursifs particuliers: Google, Hurricane Electric, Verisign, et Level 3. Ce sont les mêmes configurés dans Mirai lorsque les objets connectés n’ont pas de resolver DNS configuré. Comment se protéger? Cette attaque comporte deux difficultés : Les requêtes sont légitimes et non cacheable (car le hostname de la zone DNS n’existe pas) La volumétrie du flux DNS généré Il est impossible de demander à un serveur DNS récursif de ne plus vous envoyer de requêtes, vous bloqueriez des réquêtes légitimes, même si ce serveur est un serveur DNS récursif ouvert. Le fait de laisser des serveurs récursifs ouverts sur Internet est un débat ouvert depuis plusieurs , mais là n’est pas le sujet de cet article. Donc pour faire simple, il y a 2 facteurs qui peuvent rendre un service DNS indisponible: Trop de requêtes par secondes, donc le serveur ne peut plus répondre Trop de volume, donc le lien est saturé Sur le premier facteur, la solution est de disposer d’une solution hautement disponible et ayant les capacités de traitement suffisante pour supporter la charge lors d’une attaque DNS. Les requêtes DNS utilisent quasi exclusivement le protocole UDP, donc une sécurité de type TCP StateFull ne peut aider. La solution F5 DNS Express permet de déporter une zone DNS sur le BIGIP afin que celui-ci se charge directement de la réponse DNS. Un BIGIP peut supporter jusqu’à 10 millions de QRPS (Query Response Per Second). Le BIG-IP devient serveurs DNS Secondaire de votre zone DNS Primaire. Ainsi, lors de l’attaque «DNS Water Torture», toute requête «légitime» mais dont le hostname (le préfix) est inconnu, sera automatiquement traitée par le BIGIP lui-même. Plus d’informations sur DNS Express: https://devcentral.f5.com/s/articles/dns-express-and-zone-transfers F5 Networks dispose d’une offre beaucoup plus large sur la protection DNS permettant de protéger les infrastructures DNS contre tout type d’attaque de type réflexion, amplification avec des technologies telles que RPZ (Response Policy Zone), IP réputation, DNSSEC… Sur le deuxième facteur (la volumétrie), il va falloir s’appuyer sur une solution de délestage afin de re-router le trafic vers un centre de traitement disposant de suffisamment de bande passante. La solution F5 Silverline DDoS, en mode Always Available, permet à ses clients de disposer d’une «assurance» en cas d’attaque DDoS dépassant leur capacité de traitement. Ainsi, le trafic est re-routé vers les centres de traitement F5 Silverline afin de traiter et dépolluer le flux. Le flux propre est ensuite envoyé à l’infrastructure cliente. Plus d’informations sur F5 Silverline: https://f5.com/products/deployment-methods/silverline Pour finir, une attaque évolue et se répète. Krebs, OVH et Dyn en sont les témoins et un SOC est aujourd’hui indispensable pour adapter sa protection en fonction de l’évolution de l’attaque. Pour cela, dans son offre Silverline, F5 Networks intègre son SOC et ses équipes d’analyse. Une approche hybride est devenue aujourd’hui indispensable afin de pouvoir se protéger des attaques volumétriques et ciblées. Les protections dans le Cloud (off-premises) se chargeront de prendre la charge volumétrique et de nettoyer le flux le mieux possible. Ensuite, les solutions on-premises se chargeront d’une analyse plus fine et se chargeront de protéger au plus près l’infrastructure IT. Pour cela, F5 Networks propose ses solutions de protection hybride permettant aux solutions on-premises d’information les off-premises d’une attaque en cours. Ainsi, lorsque la solution off-premises reprend le trafic, celle-ci dispose déjà d’informations pertinentes lui permettant de bloquer l’attaque le plus tôt possible. Le code source de MIRAI ayant été mis en ligne, il est fort probable dans les semaines et mois à venir que des attaques semblables ou encore plus puissantes voient le jour en utilisant la source du malware MIRAI et ses capacités à constituer de manière très rapide un BOTNET très important en ciblant les équipements IOT. Sources: http://hub.dyn.com/traffic-management/recent-iot-based-attacks-what-is-the-impact-on-managed-dns-operators https://f5.com/about-us/news/articles/mirai-the-iot-bot-that-took-down-krebs-and-launched-a-tbps-ddos-attack-on-ovh-21937?adbsc=social66693476&adbid=785189347087659008&adbpl=tw&adbpr=438688096 https://github.com/jgamblin/Mirai-Source-Code http://blog.level3.com/security/grinch-stole-iot/Quelle ressource consomme une CCU ?
Cette question revient très souvent. Or, il est très facile de savoir quelle ressource consommera une CCU. Premièrement, il faut savoir que la CCU est consommée lors de la présentation du webtop. Si ce webtop présente des ressources consommant des CCU, alors une CCU sera consommée pour la session APM en cours. Pour les usages sans webtop (portal access seulement), alors une CCU sera consommée par session APM. Il existe un article présentant la liste des ressources concernées sur ASKF5 : http://support.f5.com/kb/en-us/solutions/public/13000/200/sol13267 Cas d’usage “Application Web” : Si l’application est présentée via un Portal Access, c’est à dire avec de la réécriture (f5-w-xxxxxxxx dans l’URI), alors une CCU est consommée Si l’application est présentée via le mode LTM+APM, c’est à dire qu’il n’y a pas de réécriture et que l’appli se trouve sur un membre d’un pool du virtual server hébergeant la politique APM, alors pas de CCU. Ce mode est utilisé avec les applications “on the shelves” telles que OWA, ActiveSync, Sharepoint, Citrix Web Interface, interface View … qui sont plutôt bien codées et ne nécessitent pas de réécriture. Cas d’usage tunnel / VPN-SSL : App Tunnel –> CCU consommée VPN SSL tunnel (client lourd ou léger) –> CCU consommée Cas d’usage VDI : Citrix XenApp: Si l’énumération des applications et hosts se fait dans le webtop, alors aucune CCU n’est consommée (objet VDI créé et assigné dans la policy) Si l’énumération est faite via la Web Interface (ou le StoreFront) En mode LTM + APM, pas de CCU En mode Portal Access, une CCU est consommée VmWare View : Si l’énumération des applications et hosts se fait dans le webtop, alors aucune CCU n’est consommée (objet VDI créé et assigné dans la policy) Si l’énumération est faite via le connection server ou le security server En mode LTM + APM, pas de CCU En mode Portal Access, une CCU est consommée Le fait de supprimer ou de garder le security server ne change rien En conclusion, seuls les tunnels VPN et les portal access consomment des licences CCU.
