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.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.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 ...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.Vérifier le nombre de CCU consommées sur APM
A partir de la version 11.4, il est possible d’interroger les TMM pour connaitre le nombre de licences CCU et le nombre de licences ACCESS maximum et consommées. Pour cela, nous avons mis à disposition des variables de session. Ces variables remontent plusieurs informations : - session.count.connectivitycurrent = return [mcget -license {tmm.license.global_connectivity#}] –> CCU consommées - session.count.connectivitymax = return [mcget -license {tmm.license.global_connectivity}] –> CCU max - session.count.userscurrent = return [mcget -license {tmm.license.global_access#}] –> ACCESS consommées - session.count.usersmax = return [mcget -license {tmm.license.global_access}] –> ACCESS max Pour pouvoir récupérer ces information, il faut utiliser une box Variable Assingn suivi d’une boxe Logging dans la VPE. Commencer par créer la variable de session souhaitée. Dans mon cas, je veux connaitre le nombre de CCU consommées : Ensuite, configurer la boxe Logging afin d’afficher le contenu de la variables dans les logs /var/log/apm Et pour finir, visualiser les logs via la commande “tail –f /var/log/apm”. A chaque nouvelle connexion, vous verrez le log apparaitre, avec le nombre de CCU consommées. Le compteur commence à 0, il faut incrémenter le nombre de 1 pour avoir la valeur exacte.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.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 StewartHow 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-8
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”.
