How to set your first SWG Per-Request Policy with 11.6 release
Hi, Please find below an how-to explaining how to set your first SWG Policy on 11.6 release with the latest feature "Per-Request Policy". In this scenario, I control on each request if the website is part of Financial category in order to bypass SSL inspection. Video here :http://youtu.be/zp269s5fQ-8Per-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.
Nouveauté n°2 dans TMOS 11.6 : L’estampillage OCSP
Dans la continuité du précèdent article sur les nouveautés autour de SSL/TLS, j’aborde cette fois-ci la fonctionnalité d’estampillage OCSP nouvellement prise en charge dans la version TMOS 11.6. Petit rappel sur OCSP OCSP (Online Certificate Status Protocol) est un protocole qui permet de vérifier en ligne (auprès d'une Autorité de Validation) la validité d’un certificat numérique et ce, sans recourir aux listes de révocation de certificats (CRL). Pour un navigateur web qui se connecte à un serveur web en SSL/TLS, cette vérification s’effectue durant la phase de handshake SSL en établissant une connexion auprès de l’Autorité de Validation (répondeur OCSP) qui a émis le certificat serveur. OCSP : des plus, des moins Comparé au mécanisme de vérification basé sur des CRL, l’OCSP apporte plus de sécurité (les statuts de révocations sont mis à jour plus fréquemment) et fait que le client consomme moins de bande passante et de ressources pour télécharger et parser des fichiers CRLs qui peuvent avoir une taille conséquente. En revanche, du fait de cette centralisation sur le répondeur OSCP, ce protocole ralentit les nouvelles connexions. En effet, lorsque le navigateur web s’adresse à un serveur web dont le certificat n’est pas connu, le navigateur contacte le ou les serveurs OCSP afin de vérifier la validité du certificat serveur ainsi que le certificat de l’Autorité de Certification émettrice. Cela ajoute de la latence dans le processus du handshake SSL. Cela passe par une ou plusieus requêtesen résolution de nomainsi que l’établissement de connexions TCP au répondeurs OCSP des Autorité de Certification présentes dans la chaine de certificat. Le fait que l’Autorité de Validation ait connaissance des sites HTTPS auxquels accède le navigateur est un autre inconvénient d’OCSP car pouvant porter atteinte au respect de la vie privée. L’estampillage OCSP améliore OCSP L’estampillage OCSP (ou agrafage OCSP) est une extension à TLS 1.2 et gomme les inconvénients cités plus haut en introduisant un modèle dans lequel c’est le serveur Web – et non plus le navigateur- qui récupère et envoie la réponse OCSP. Ainsi, lors du SSL handshake, le serveur web -en plus d’envoyer son certificat serveur- attache aussi une réponse OCSP signée et horodatée par l’Autorité de Validation. Le bénéfice immédiat de l’estampillage OCSP est le gain en temps de latence et la disponibilité des réponses OCSP puisque le BIG-IP proxifie et cache les réponses OCSP. Grâce à ce mécanisme, l’autorité de validation reçoit désormais les requêtes OCSP directement du serveur Web pour qui elle a émis le certificat et non plus des navigateurs, respectant ainsi la vie privée des utilisateurs. Cinématique de fonctionnement de l’estampillage OCSP avec BIG-IP BIG-IP requête le répondeur OCSP à intervalles réguliers pour avoir un statut de révocation pour le certificat TLS utilisé par le Virtual Server Le répondeur OCSP signe et horodate une réponse OCSP et la renvoie au BIG-IP Le client (navigateur web) effectue une connexion au Virtual Server et initie un SSL handshake en utilisant l’extension Certificate Status Request dans le message ClientHello Pour le Virtual Server en question, BIG-IP envoie au client le certificat serveur ainsi que la réponse OCSP horodatée et signée par le répondeur OCSP Le client vérifie la signature de la réponse OCSP et termine le handshake SSL La connexion HTTPS est établie entre BIG-IP et le navigateur web BIG-IP maintient dans un cache le statut de révocation du certificat TLS pour pouvoir servir d'autres clients Est ce que l’estampillage OCSP est pris en charge par tous ? Ce mécanisme en est à ses début et commence à être de plus en plus supporté par les serveurs web (Apache 2.3.3, Nginx, IIS) et les navigateurs web (FireFox, Opéra, Chrome, IE sur Windows Vista) F5 BIG-IP est le seul ADC du marché (à date) à prendre en charge l’estampillage OCSP. Comment cela se configure dans BIG-IP ? La configuration se fait assez simplement en définissant d’abord un profil OCSP stapling puis en assignant ce profil au profil Client SSL. Vous trouverez plus de détail ici.Protection DDoS L7 avec le BIGIP ASM
Le module BIGIP ASM (Application Security Manager) est équipé d'une brique de protection Anti-DDoS de niveau 7. Celle-ci est indépendante des briques WAF du module ASM. Il est donc possible de mettre en place une protection DDoS L7 indépendamment de la sécurité positive et négative de l’ASM. Ce profile DoS L7 permet de faire une analyse comportementale des utilisateurs et de déclencher des mécanismes de protection. Cette analyse comportementale peut être réalisée à la fois côté client (nombre de requêtes par secondes) ou côté serveur (latence induite par l’attaque). Une fois l’attaque détectée, le BIGIP commencera sa protection en utilisant plusieurs mécanismes : Client Side Integrity Captcha Blocking ou Rate Limit Voici une vidéo présentant la solution.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 ...Solution Anti-Phishing - F5 Websafe
F5 Networks enrichit son portfolio de sécurité avec la solution Websafe (Fraud Protection Service). Ce service a pour mission de protéger vos utilisateurs contre : Les malwares Le phishing Le vol d'identité (credentials) Ces 3 briques sont assurées par le module/service FPS de F5 Networks. Aucun client ni agent n'est installé sur le poste client. Tout se passe entre le navigateur de l'utilisateur et le BIGIP. Le module FPS protège au fil de l'eau les pages web concernées et permet d'informer le SOC en cas d'attaque, de phishing ou de vol d'identité. Le but de cet article est de vous présenter la brique Anti-Phishing de Websage. Celle-ci vous permet d’être informé lorsque votre site est “copié” et lorsqu’un de vos utilisateurs cliquent malencontreusement sur le lien renvoyant sur le site “copié”. De plus, Websafe est capable de vous remonter l’ensemble des utilisateurs ayant fournir intentionnellement leur credentials au hacker via ce phishing. Dans cette vidéo, je vous présente le service et le résultat obtenu :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.
Access Control in the New Mobile, Hybrid World
There is a brave new world dawning for the corporate world. There are many “new norms” – and a gold rush of new opportunities, but also new challenges with which they come – streaking like lightning throughout organizations. The workforce of today and into the future is, and will continue to be mobile. Consider that according to analyst IDC, 37 percent of the worldwide workforce will be mobile by the end of 2015. That’s about 1.3 billion mobile workers, worldwide – not to mention there will be two or more times as many mobile devices as mobile workers! – by the end of this calendar year! Then, consider this: According to Orange Business Services, 55 percent of worldwide business IP traffic will be mobile business Internet traffic by 2018. Mobility is here, and it’s here to stay. (In the Asia Pacific region, IDC anticipates the bring your own device (BYOD) market will continue its robust growth. There were an estimated 155 million smartphones and over 4 million tablets in use supporting BYOD initiatives across the region last year (2014), with year-on-year growth of 40.4 percent and 62.7 percent, respectively. And, that’s not even considering the burgeoning area of wearable devices, either.) As the mobile workforce accelerates like a rocket into the stratosphere, cascading torrents of smartphones, tablets, and wearables across organizations in its wake, the number of cloud- and SaaS-based applications used within organizations is also skyrocketing at a breakneck pace. According to a recent study sponsored by SkyHigh Networks, there are on average 759 cloud services in use by today’s organizations. The most puzzling piece isn’t the magnitude of in use cloud apps and services. Instead, its that, according to a Cloud Security Alliance study, most organization IT teams believe they have fewer than 50 cloud-based apps in use. That means that over 700 cloud apps and services on average are in use within enterprises – but no one (but the user) has control over those apps and services, and any corporate information shared with them! The problem is, you cannot defend what you don’t know about! Finally, the last piece of the “new norm” puzzle for organizations is the hybrid network, an eclectic mix of data center and cloud-based apps and data, with a stew of hosted private, public and cloud infrastructures. According to analyst Gartner, “while actual hybrid cloud computing deployments are rare, nearly three-fourths of large enterprises expect to have hybrid deployments by 2015.” Consider that a mobile workforce will drive infrastructure changes, needed to address a more diverse device ecosystem. Then consider that infrastructure addressing mobility requires greater investment in cloud-based apps and services to support that expanding device ecosystem. So, as you can see, the future of the network fabric for the foreseeable future will be hybrid. So, with a “new norm” of mobility, cloud, and hybrid networks, how can organizations address network, application, and data accessibility? With so many new devices that are mobile and are under limited corporate control, and applications and data scattered about the network and in various clouds and SaaS deployments, how can an enterprise be assured of fast, appropriate, authenticated and authorized access? With so many variables, there is one constant that remains: Identity. The user – and their identity – is, arguably, the “new perimeter” for the enterprise, today and onward. As the traditional network perimeter has been broken, fragmented, and in many instances shattered into many pieces, identity has become the new perimeter. As applications, data, and even networks move faster toward the cloud, and the user-controlled, BYOD-driven mobile ecosystem expands exponentially, corporate control has become more difficult, dispersed, and dependent on others – and many times, that’s the security uninformed and apathetic user. User identity, though, never changes. And, backed by authentication, authorization, and accounting (AAA), identity is now the first line of defense for secure corporate access. But, identity is just the tip of the spear for controlling the new parameters of access. The context of a user’s access request, and their environment at the time of access request, follow identity; inarguably, they have as much to do with securing appropriate access as identity. The ability to address the 5 w’s and 1 h (who, what, when, where, why, and how) assures, enhances, and differentiates secure access to networks, clouds, applications and data – wherever they may reside and however they are comprised. Insuring user identity is efficiently, securely shared between networks, clouds, applications, and data – wherever they live – is now a necessity. Yet, there are challenges: Identity silos, on-premise identity with cloud- and SaaS-based apps and data, and user password fatigue leading to weak user names and passwords – which are easily compromised. That’s where building an identity bridge comes in. Federation builds a trusted chain of user identity between two entities – networks, clouds, applications, etc. – through industry standards, such as SAML. The cumbersome duplication and insertion of identity directories becomes unnecessary. Identity and access is controlled by an enterprise, with authentication occurring between the enterprise, and cloud and SaaS providers. Instant user authentication and its termination is centralized and under enterprise control. Identity federation delivers access visibility and control together. Leveraging identity for access control, and building identity bridges are now imperative for organizations, as applications move outside the enterprise domain, the workforce and their devices are more mobile and leave the enterprises in droves, and the enterprise domain, too, has moved. It’s the “new norm”.Se protéger des IP frauduleuses grâce à IP Intelligence de F5 Networks
Le meilleur moyen de se protéger des attaques est de les contrer au plus proche - c'est à dire au moment de l'initialisation de la connection (plus communément appelé le 3-Ways-Handshake). F5 Networks propose à ses clients une souscription nommée “IP Intelligence”. Cette souscription permet au BIGIP, quelque soit le module (LTM, ASM, APM, AFM, GTM …), de pouvoir vérifier avant l’initialisation de la connexion si l’IP source est frauduleuse ou non. Pour cela, le BIGIP télécharge toutes les 5 minutes la base de données d’IP frauduleuses. Cette base de données classifie les IP sous plusieurs catégories telles que les scanners, les botnets, les proxy anonymes, les sites illégaux … Dans la vidéo ci-dessous je vous présente cette souscription et comment la mettre en place. Vous y verrez les reporting obtenus.SSO par Kerberos Constrained Delegation sur APM - Best Practices
Mettre en place un SSO sur APM par Delegation Kerberos n'est pas chose aisée. Voici 5 recommandations ou best practices pour réussir votre SSO par Kerberos Constrained Delegation, surtout lorsque l’on souhaite authentifier des utilisateurs venant de plusieurs domaines. 1. Le compte de délégation AD pour l’APM doit être dans le même domaine que la ressource demandée. Par exemple, si vous avez 2 domaines, ALPHA.COM et BRAVO.COM, et que votre serveur Sharepoint est dans ALPHA.COM, le compte de délégation AD pour APM doit se trouver dans ALPHA.COM. Les utilisateurs quand à eux, peuvent se trouver dans l’un ou l’autre domaine. Ceci est du à un prérequis de la RFC sur le Kerberos Contraines Delegation qui ne permet pas de traverser les domaines. 2. La valeur du Logon Name du compte de délégation (userPrincipalName) doit être dans le format d’un servicePrincipalName (SPN), et vous devez utiliser cet SPN dans la configuration du Account Name du SSO. Par exemple, vous avez un compte de délégation nommé « krb.srv » dans le domaine ALPHA.COM. Le Logon Name de l’utilisateur (userPrincipalName) peut être « host/krb.srv.alpha.com ». Le compte de servicePrincipalName doit être aussi « host/krb.srv.alpha.com ». Si vous utiliser un format non-SPN dans le champs Logon Name, ou pour la valeur du Pre-Windows 2000 (sAMAccountName) dans le profile SSO Kerberos, vous aurez une erreur du type « service principal unknown » quand vous essaierez d’authentifier des utilisateurs venant de domaines différents. 3. Les domaines doivent avoir une relation d’approbation bi-directionnelle (bi-directional transitive trust). L’extension Kerberos Protocol Transition (KPT) l’impose. Vous ne pourrez pas faire de KPT/KCD avec un trust non transitif et/ou une relation uni-directionnel. 4. L’APM doit être capable de joindre chaque KDC de chaque domaine sur le port 88 en TCP et en UDP. En deux mots, l’APM doit discuter avec chaque KDC : a. A son KDC local pour avoir un ticket pour l’autre KDC b. A l’autre KDC pour avoir un ticket pour l’utilisateur c. Et finalement à son KDC local pour avoir un ticket pour la ressource applicative. 5. Vous devez injecter le realm du domaine de l’utilisateur dans la configuration SSO pour que cela fonctionne. Pour cela, il faut le récupérer. Donc soit l’utilisateur le définit dans la page de login (via une selection box ou directement dans le login name sous le format domain\user), soit vous allez le récupérer via un Query AD/LDAP par exemple. Une fois le domaine connu, vous n’avez plus car remplir la variable session.logon.last.domain → session.logon.last.domain = expr { "BRAVO.COM"}. Source : Thanks to my colleague Kevin Stewart
