J’ai testé pour vous: la sécurité web grâce à mon routeur ISR G2
J’avais annoncé dans un post en septembre dernier la disponibilité d’un connecteur Scansafe intégré à nos routeurs d’accès ISR G2. A ce moment là je n’avais pas donné beaucoup de détails mais j’avais mis dans un coin de ma tête de tester cette feature et de vous faire un petit compte-rendu… Nous y sommes!
Commençons par expliquer ce qu’est Scansafe: il s’agit du service de sécurité web en mode SaaS de Cisco. Au lieu d’acheter une appliance pour faire le filtrage web et l’enregistrement des activités (attention vous êtes fichés!), on va juste envoyer le trafic web vers des proxies dans l’Internet qui vont effectuer cette action. Pour garantir de bonnes performances Scansafe est présent un peu partout dans le monde. La France fait parti des heureux élus, profitons-en! 🙂
Matériel et IOS utilisé
Un routeur Cisco 2951 avec un IOS 15.2(2)T1 (c2951-universalk9-mz.SPA.152-2.T1.bin)
Une carte etherswitch 24 ports Ethernet 10/100 pour raccorder les hosts (mais sans réel intérêt dans notre contexte)
Topologie du lab
Comme on peut le voir ici, j’ai simplement connecté mon routeur 2951 sur le réseau Cisco (qui simulera mon WAN) via l’interface Gi0/0 sur laquelle j’ai juste configuré une adresse IP 192.168.100.100/24 et une route par défaut. Sur le LAN où j’ai mis les postes de travail j’ai simplement configuré l’adresse IP 10.153.200.1/24 sur le routeur, qui est également configuré comme serveur DHCP pour configurer automatiquement les hosts du site (adresse, route par défaut et serveur DNS). Le routeur sera resolver DNS pour les hosts du LAN. Ci dessous la configuration de base avant d’appliquer les configurations Scansafe.
ip dhcp pool TOTO network 10.153.200.0 255.255.255.0 default-router 10.153.200.1 dns-server 10.153.200.1 ! interface GigabitEthernet0/0 ip address 192.168.100.100 255.255.255.0 duplex auto speed auto ! interface GigabitEthernet1/0.10 encapsulation dot1Q 10 ip address 10.153.200.1 255.255.255.0 ! ip dns server ip route 0.0.0.0 0.0.0.0 192.168.100.1
Notez que je n’ai pas configuré de NAT. Les flux web étant proxifiés vers Scansafe le NAT est inutile! Maintenant si on veut faire autre chose que du web ca ne marche pas en effet… Vous comprenez maintenant pourquoi j’ai déclaré mon routeur comme resolver DNS. Mais recollons au sujet…
Configuration
La configuration est très simple. Cela suppose bien évidemment qu’on a contractualisé avec Cisco un service Scansafe! A ce moment là on récupère quelques paramètres, notamment des urls de proxys et des informations d’authentification pour la connexion. Il suffit de renseigner ces informations dans le routeur:
parameter-map type content-scan global server scansafe primary name proxyAAA.scansafe.net port http 8080 https 8080 server scansafe secondary name proxyBBB.scansafe.net port http 8080 https 8080 license 0 1287619829081720971092701987 source interface GigabitEthernet0/0 timeout server 30 server scansafe on-failure block-all
La dernière commande indique qu’en cas de mauvais fonctionnement de Scansafe, on souhaite bloquer tous les flux web. On aurait pu imaginer l’inverse. On note qu’il faut bien spécifier l’interface qui va être utilisée pour proxyfier vers Scansafe (source interface Gi0/0, notre interface côté WAN). Ensuite on applique notre “scan” sur notre interface WAN en sortie. Tout les flux web qui passeront par là vont donc être analysés puis envoyés vers nos serveurs Scansafe pour analyse. On note les commandes “ip virtual-reassembly” nécessaires pour permettre fragmentation/réassemblage sur l’interface. Cela est indispensable puisque l’on va envoyer les flux aux Proxies Scansafe avec quelques octets pour l’authN et divers paramètres: la MTU peut largement être dépassée. Les commandes additionnelles à appliquer sur l’interface WAN ci-dessous:
interface GigabitEthernet0/0 ip virtual-reassembly in ip virtual-reassembly out content-scan out
Et voilà c’est terminé!
Tests
Regardons les résultats. Je connecte mon poste de travail derrière mon routeur de test et fais 2 recherches sur Google. On voit que la page de résultats est légèrement modifiée par Scansafe et intègre déjà les règles de sécurité appliquées par l’administrateur.
Ma première recherche montre des pages autorisées (on s’en serait douté) alors que la seconde (téléchargement de vidéos) indique que certaines pages retournées par le moteur de recherche sont interdites d’accès. Si malgré l’avertissement je clique pour visualiser la page je tombe sur une nouvelle page m’expliquant que le contenu est filtré. Dans ce test je n’ai pas souhaité montrer la configuration de Scansafe qui offre beaucoup de flexibilité à l’administrateur pour la définition des règles de filtrage.
Conclusion
En quelques minutes j’ai pu ajouter sur mon routeur d’accès un filtrage de contenu très poussé, via la simple mise en place d’un connecteur. La mise en place de connecteurs pour accéder aux services dans le cloud fait parti de la stratégie de Cisco pour le WAN: les routeurs deviennent des “cloud service gateways”, bien au-delà de la simple capacité d’accueillir des interfaces de tout type.
Dans un contexte où les applications partent de plus en plus dans le cloud on peut réfléchir à nos architectures WAN. Pourquoi tout faire remonter vers notre site principal si notre trafic part majoritairement dans le cloud? On peut songer à mettre en place des accès directs vers l’Internet et dans ce contexte des mécanismes de sécurité comme le connecteur Scansafe sont indispensables.
Tags:
1 commentaires