MemoEfix.com

En milieu professionnel, les utilisateurs peuvent exprimer le besoin d’accéder en Wi-Fi au réseau Internet depuis leurs postes nomades (ordinateurs portables et smartphones). Cette tendance « Bring Your Own Device (BYOD) pose des problèmes de sécurité de l’information. Le réseau Wi-Fi étant destiné à faire circuler les mêmes informations sensibles que les réseaux filaires, il est indispensable de s’assurer qu’il ne constitue pas un maillon faible de l’infrastructure systèmes et réseaux.

Ce billet a pour objectif de décrire la mise en place une architecture réseau sans fil sécurisée de type Wi-Fi. Comme toute démarche de projet, il est nécessaire de définir un périmètre, d’identifier les exigences générales de la maîtrise d’ouvrage et les choix techniques en réponse à ces exigences.

Concernant le périmètre, seuls les utilisateurs équipés de micro-ordinateurs portables ou de smartphones seront autorisés à se connecter au réseau sans fil.

Ils pourront :

- se connecter au réseau Internet dans le respect de la charte informatique mise en place au sein de l’organisation ;
- se connecter à certains services numériques internes clairement identifiés.

Pour ce lab. j’ai fixé un certain nombre d’exigences générales :

- le choix d’une solution économique ;
- une architecture simple à mettre en oeuvre et intégrable à un environnement système Microsoft existant ;
- une infrastructure réseau sécurisée (confidentialité, intégrité et disponibilité) ;
- l’identification des utilisateurs connectés au réseau et une journalisation des connexions ;
- une autorisation de l’accès Wi-Fi aux jours et aux horaires d’ouverture de l’organisation.

Pour les choix techniques, j’ai opté pour :

- une architecture sans fil sécurisée ;
- une méthode d’authentification à partir du login/mot de passe de l’utilisateur ;
- un mécanisme de chiffrement des données.

L’architecture sécurisée envisagée, n’est pas de restreindre l’utilisation professionnelle de l’Internet mais d’en faciliter l’usage tout en définissant des contrôles d’accès entre les segments de réseaux et de diminuer le nombre de services et/ou de machines visibles sur le réseau local.

J’ai fait le choix de sécuriser l’architecture en segmentant le réseau. Le réseau est segmenté par une politique de filtrage pertinente avec d’un côté le réseau dit “Wi-Fi” et d’un autre côté, le réseau interne de l’organisation. J’ai opté pour une zone de confinement dans un VLAN dédié et sur une interface particulière d’un pare-feu (zone “wifi” sur laquelle se trouvent les points d’accès).
Cette politique de sécurité repose sur une double protection : un premier pare-feu R1 qui protège la zone interne du réseau Internet et sur un second pare-feu/routeur R2 (pfSense) qui protège la zone interne de la zone Wi-Fi.

Schéma simplifié de l’architecture décentralisée

Cette architecture segmentée est nécessaire pour des questions d’administration, afin d’isoler des dysfonctionnements et pour se prémunir des attaques réseau ou virales.
Les points d’accès seront sécurisés selon les préconisations explicitées dans la partie 4.1 du document “Sécurité des réseaux sans fil (Wi-Fi)“.
La politique de filtrage réseau mise en place sur R2 est « tout est interdit sauf des services que l’on connaît et maîtrise vers certaines machines ». Ce modèle est adaptable rapidement par ajout/modification des règles de pare-feu pour prendre en compte des nouveaux besoins.

Sous pfSense, tout est interdit sauf les services que l’on connaît et maîtrise vers certaines machines.

Les services auxquels tout nomade doit pouvoir accéder seront définis selon les besoins et l’infrastructure existante. Voici une liste non exhaustive :

- autoriser les services WEB, non sécurisés (HTTP) et sécurisés (HTTPS) ;
- autoriser les services de messagerie (consultation et soumission) sous différents protocoles sécurisés ou non (25, 110, 465, 587, 993, …) afin de ne pas contraindre l’utilisateur à passer par un service de type WebMail pour gérer son courrier électronique ;
- autoriser l’accès vers un serveur proxy situé sur le réseau local ;
- autoriser les mises à jour programmées” ou “manuelles” initiées par les clients vers un serveur anti-virus situé sur le réseau local ;
- autoriser des accès au serveur d’authentification RADIUS (Remote Authentication Dial-In User Service) situé sur le réseau local ;
- interdire des accès aux zones démilitarisées sur R1 à l’exception de certains services (HTTP, Messagerie, DNS, etc.) ou applications locales ;

Les risques de sécurité sont en constante évolution et de nouvelles techniques visant à contourner les contrôles de filtrage des flux sortants, sont découvertes régulièrement. Aussi, ces règles de filtrage sont préventives, mais ne garantissent pas une solution fiable à 100 %.

Pour limiter les risques d’une intrusion depuis la voie radio, on peut mettre en place d’autres mesures de protection :

- la temporisation de session. On ne souhaite pas de connections permanentes sans vérification régulière de l’identité de celui qui est connecté pour des raisons évidentes de sécurité. Les clients seront déconnectés automatiquement après un laps de temps de 120 minutes indépendamment de l’activité en cours. L’utilisateur pourra se reconnecter immédiatement après ;
- l’autorisation de l’accès Wi-Fi aux jours et aux horaires d’ouverture de l’organisation ;

Le protocole RADIUS propose une fonctionnalité d’accounting assurant la journalisation des accès. La traçabilité est devenue un enjeu important.

- la mise en œuvre d’une politique de journalisation des connexions du réseau Wi-Fi ;
- l’enregistrement des demandes d’authentification utilisateur dans un fichier journal ou une base de données SQL Server ;

Si l’on souhaite ajouter une restriction d’usage de la messagerie instantanée, on pourra activer (sous pfSense) le module IMSpector. Il s’agit d’un proxy transparent qui permet de monitorer et bloquer l’utilisation de la messagerie instantanée tels que MSN, Jabber/XMPP, AIM, ICQ, Yahoo, IRC, etc.

Après l’association au point d’accès du réseau sans fil, l’utilisateur est authentifié à travers une connexion sécurisée pour pouvoir disposer du service Wi-Fi. L’accès sans fil repose sur une authentification par mot de passe sécurisé.
Dans l’architecture 802.1x, le client d’accès sans fil IEEE 802.11 s’authentifie à partir des informations d’identification basées sur un nom d’utilisateur et un mot de passe plutôt que des certificats. Cette authentification vise à offrir des accès réseau sans fil aux utilisateurs à partir de leur nom d’utilisateur et mot de passe habituels.

J’ai restreint au niveau du serveur RADIUS la liste des utilisateurs du domaine (les membres du groupe “Allowed Wi-Fi users”) ayant le droit de se connecter au réseau sans fil. Seul le serveur d’authentification (de type RADIUS) possède un certificat pour prouver son identité au client. Le serveur d’authentification contrôle l’accès au réseau Wi-Fi d’entreprise depuis le niveau 2 du modèle OSI.

J’ai employé la méthode d’authentification PEAP (Protected Extensible Authentication Protocol), utilisée conjointement avec la méthode d’authentification interne EAP-MS-CHAPv2 (inner-authentication).
L’annuaire de comptes est sous environnement Microsoft Windows et le serveur RADIUS est un composant (Network Policy Server) de la famille Windows Server.

La méthode PEAP sur le framework protocolaire 802.1x, distribue automatiquement les clés de chiffrement (Key Generating), ce qui simplifie considérablement la gestion du système. En outre, elles sont différentes pour chaque utilisateur et pour chaque session. Elles sont changées automatiquement en cours de session. Les points d’accès WiFi seront configurés pour changer la clé de groupe temporaire GTK (Group Transient Key) toutes les 30 minutes. Ceci permet de garantir une sécurité bien plus élevée qu’avec des clés partagées.
PEAP utilise TLS (Transport Level Security) pour créer une connexion chiffrée de bout en bout (du client EAP au serveur d’authentification) après avoir vérifié l’identité de l’authentificateur EAP.

La borne WiFi composant l’ossature du réseau sans fil se comporte comme un mandataire entre le système à authentifier et le serveur d’authentification. Il représente le point d’entrée au réseau grâce au point d’accès appelé PAE (Port Access Entity). Ce point d’accès est un port physique scindé en deux ports logiques. Lorsque le client tente une authentification, l’ensemble des trames d’authentification EAP passent par le port non contrôlé qui ne sait gérer que ce type de trames. Une fois authentifié, le port dit contrôlé, jusqu’à présent fermé, s’ouvre pour donner l’accès au réseau.

Le processus d’authentification PEAP entre le client et l’authentificateur EAP est divisé en deux étapes.

La première étape établit un canal sécurisé (tunnel TLS) entre le client sans fil PEAP et le serveur d’authentification.
La seconde étape fournit une négociation EAP “interne” entre le client et l’authentificateur EAP au sein de ce tunnel. C’est dans cette étape que débute le protocole EAP-MS-CHAP version 2 pour l’échange de l’identité du client.
Une fois que la négociation EAP “interne” est terminée par un paquet EAP de type succès ou échec, que le contrôleur d’accès voit passer, le tunnel TLS est fermé et le serveur renvoie un nouveau paquet de succès ou d’échec au client, en clair cette fois-ci. Sans cela, le contrôleur d’accès ne saurait pas s’il faut ou non laisser passer le client, car toute l’identification interne était chiffrée.

La méthode d’authentification PEAP utilisée apporte plusieurs avantages :

• la méthode d’identification interne est rendue plus sûre ;
• il n’est pas nécessaire de déployer des certificats sur des clients d’accès sans fil en vue d’assurer l’authentification des utilisateurs et des postes clients (EAP-TLS).

Toutefois, cette méthode s’appuie sur une authentification à simple facteur. Ici, la sécurité repose sur ce que l’utilisateur connaît, à savoir son mot de passe.

Dans la mesure où le système est vulnérable à des attaques de dictionnaires en ligne, le risque de sécurité est fortement lié à la politique de gestion des mots de passe mise en place par l’administrateur réseau et système.
En laissant l’utilisateur choisir son mot de passe, le risque du choix d’un mot de passe à résistance faible facilite alors considérablement l’action des attaquants informatiques. En imposant un mot passe complexe aux utilisateurs, le mot de passe a toutes les chances de finir sur un « Post-It » collé sur l’écran d’un ordinateur, sauvegardé sur l’ordinateur ou inscrit dans un document numérique non stocké dans un conteneur chiffré et donc non sécurisé.
Le fait que les attaques de dictionnaires ne soient possibles qu’en se connectant au système permet de réduire les exigences concernant la complexité des mots de passe.

Pour compléter le niveau de sécurité, on pourra aussi :

- configurer le serveur d’authentification pour qu’il refuse toute nouvelle tentative de connexion d’un même utilisateur après trois tentatives infructueuses (entrée MaxDenials dans le Registre) et ce pendant 5 minutes (entrée ResetTime dans le Registre) ;
- vérifier régulièrement les historiques (les « logs ») de connexion, afin de détecter les éventuelles tentatives d’intrusion.

Cependant, il est encore possible de s’exposer à une attaque de type Rogue AP (points d’accès non désirés). Rien n’empêche un attaquant de se déclarer avec le même SSID (Service Set Identifier) que celui du réseau sans fil cible, mais avec un signal plus fort et un serveur RADIUS modifié pour « dumper » l’échange MS-CHAPv2. Il désauthentifie ensuite le client. Si ce dernier accepte le faux certificat, une attaque Man-In-the-Middle peut avoir lieu et l’échange MS-CHAPv2 est capturé. Sachant que le nom d’utilisateur passe en clair avant la mise en place du tunnel TLS, l’attaquant va pouvoir alors tester différents mots de passe par dictionnaire (source MISC n°39, Benjamin Charles, « MS-CHAP-V2 et 802.11i, le mariage risqué ? »).

Dans ce contexte, il est important que les utilisateurs se connectent au bon serveur d’authentification. Il faut donc absolument que le poste utilisateur vérifie l’authenticité du certificat électronique du serveur d’établissement et refuse la connexion en cas de doute.

Concernant la protection des données, l’absence de chiffrement dans un réseau sans fil laisse l’ensemble des informations qui transitent sur ce réseau en clair. Il est donc nécessaire de protéger le réseau Wi-Fi par un chiffrement approprié.

- activation de la norme de sécurité 802.11i mode WPA2-Enterprise. L’algorithme de chiffrement symétrique AES (Advanced Encryption Standard) est utilisé pour le chiffrement des données et l’échange des clés. Le contrôle de sécurité de la couche 2 est assuré par le protocole CCMP (Counter-mode/CBC-MAC-Protocol) préféré à TKIP, qui présente plus de faiblesses.

- choix d’une clé secrète longue (64 octets) et complexe, partagée par le point d’accès (AP) et le serveur d’authentification RADIUS. Cette clé est différente pour chaque AP. Elle est utilisée pour calculer un hash de type HMAC-MD5 sur les paquets RADIUS échangés. “Chaque paquet RADIUS contient un champ Request Authenticator, qui est un hash de type HMAC-MD5 du paquet, calculé avec ce secret. Ce champ est inséré par le serveur RADIUS et vérifié par le point d’accès. Dans l’autre sens de communication, le serveur RADIUS vérifie l’attribut Message-Authenticator présent avec l’attribut EAP-Message. Ces deux attributs offrent la possibilité d’une authentification mutuelle par paquet et préservent l’intégrité de la communication entre le serveur RADIUS et le point d’accès” (1).

Par ailleurs, il sera important d’informer les utilisateurs :

- de leur obligation de se conformer à la charte informatique de l’organisation ;
- des moyens mis à leur disposition pour protéger leurs flux réseau : soit par le chiffrement au niveau applicatif par l’utilisation des protocoles comme POPS, IMAPS, HTTPS, …, soit par l’utilisation d’un chiffrement de bout à bout via le mode WPA2-Enterprise ;
- du plan de couverture radio et du SSID diffusé sur l’ensemble des points d’accès composant l’infrastructure sans fil ;
- à propos des risques liés aux réseaux sans fil et des solutions préconisées par la politique de sécurité de l’organisation. Lorsqu’on ouvre un service Wi-Fi aux utilisateurs, le support est partagé. On met en place un réseau/zone Wi-Fi sur lequel les machines clientes vont pouvoir communiquer sur une même plage d’adresses. Un réseau Wi-Fi est un réseau ouvert et hostile.

• écoute du trafic
• attaques de niveau 2 et 3
• attaque directe des clients
• manipulation du trafic Wi-Fi

Pour mon lab, j’ai utilisé les équipements suivants :

- un point d’accès réseau sans fil Cisco WAP200, matériel conforme à la norme 802.11i et permettant la mise en oeuvre de tous les mécanismes de sécurité définis par la norme 802.11i ;
- un switch PoE (Power over Ethernet) HP V1905-8-PoE ;
- un serveur virtualisé Windows 2008 sous environnement VMware ;
- un routeur/pare-feu virtualisé pfSense sous environnement VMware.

Concernant l’acquisition du matériel actif et des AP, je privilégie la technologie PoE. L’intérêt est de pouvoir installer les points d’accès dans les endroits qui sont dépourvus d’alimentation électrique (sous plafond par exemple).

Pour un déploiement dans des réseaux multisites, une solution d’infrastructure centralisée sera plus adaptée :

- gestion centralisée des configurations
- mise à jour centralisée
- solution de supervision (ex. surveillance des AP et détection des faux équipements pour éviter qu’un utilisateur se connecte par erreur sur une borne “malicieuse”)

L’architecture est alors composée d’un contrôleur ou plusieurs (en HA) et de points d’accès légers. A chaque démarrage, les AP récupèrent leur configuration (paramètre réseau, fréquence utilisée, SSID, etc.) en se connectant aux contrôleurs présents dans une DMZ dédiée. Une connexion sécurisée est établie entre le point d’accès et le contrôleur avec un protocole de contrôle et de gestion d’accès sans fil (CAPWAP par exemple).

Pour conclure, il n’y a aucun moyen simple et efficace de sécuriser et de contrôler tous les clients sans fil pouvant se connecter à une architecture Wi-Fi. Sachant par exemple, qu’IPv6 est activé par défaut sur les terminaux iPhone ou iPad, un attaquant peut se faire passer pour un routeur IPv6, envoyer un message RA (Router Advertisement) et devenir ainsi la gateway IPv6 de tous ces équipements sur le réseau. Fernando Gont a rédigé un draft sur le sujet, qui décrit un système de filtrage des RA.
Certes, il existe d’autres solutions techniques qui permettent de sécuriser un réseau Wi-Fi d’entreprise. L’arbitrage entre ces solutions reste une question d’équilibre entre risques, simplicité/coût de mise en oeuvre et d’exploitation et qui appartient aux décideurs.

(1) Les réseaux, Edition 2011, de Guy Pujolle

Mise en place d’une architecture réseau sans fil sécurisée de type Wi-Fi bit.ly/Z6VjmU #infosec #sécurité #security

— Alain BERNARD (@abernard1) 14 mars 2013

L’état d’un système ESXi est entièrement décrit par des fichiers de configuration. Ces fichiers contrôlent des fonctions telles que la configuration des réseaux virtuels et du stockage, les clés de chiffrement SSL, les paramètres réseau du serveur et les informations des utilisateurs locaux. Ces fichiers de configuration sont chargés en mémoire et sont régulièrement sauvegardés (on le verra plus loin) sur un système de fichiers persistant.

L’objectif de ce billet est d’expliquer comment créer, sous environnement Unix et VMware vSphere 5, une sauvegarde automatique des configurations de serveurs ESXi.

Si un serveur physique tombe en panne (panne de carte mère par exemple), il sera alors possible de restaurer sur un serveur de secours et à partir d’une « fresh install », la configuration système de l’ESXi antérieure à la panne. En environnement de production, il est important d’activer vSphere HA car en cas d’un tel événement, le HA identifiera la panne de l’hôte et tentera de redémarrer les machines virtuelles protégées sur un hôte fonctionnel du cluster.
Dans un autre contexte, on pourrait également télécharger un fichier de sauvegarde qui contient toutes les informations de l’état d’un système ESXi et le répliquer sur un environnement système similaire.

Pour commencer, voici quelques rappels :

- le système ESXi implémente deux architectures de boot avec deux partitions indépendantes : une partition de boot dite primaire (« Boot bank » partition) contiendra l’image du système actif, chargée en mémoire dans un bloc alloué et une partition de boot dite alternative (« Alt boot bank » partition), vide initialement, gardera une copie de l’image active suite à une mise à jour.

Lors du déploiement d’une nouvelle image, l’image du système actif est copiée vers la partition de boot “alternative” et la nouvelle image est installée sur la partition de boot “primaire”. Avec cette approche « double image », si un problème est détecté pendant le processus de démarrage, le système ESXi redémarrera et chargera en mémoire l’image du système situé sur la partition de boot “alternative”. Il est également possible d’interrompre un processus de démarrage du système hôte en appuyant sur la combinaison des touches “shift + R”. Cela obligera le système hôte à charger l’image antérieure à la mise à jour.

La commande suivante permet d’afficher l’UUID de la partition de boot “primaire” :

- le système de fichiers root (FHS) est stocké sur un disque virtuel peuplé au démarrage à partir de fichiers situés sur la partition bootbank ;

L’exécution de la commande vdf -h nous donne des détails sur l’utilisation de l’espace du disque virtuel. La commande affiche également les “tardisks” que l’ESXi a extrait pour créer les systèmes de fichiers correspondants aux entrées du fichier boot.cfg.

- le fichier de configuration du chargeur de démarrage boot.cfg spécifie le noyau, ses options et les modules de démarrage séparés par 3 traits d’union (—)

C’est l’archive compressée state.tgz (« state tardisk ») qui nous intéresse ici. Il s’agit du backup de la configuration actuelle de l’ESXi.

VMware utilise un bit collant (sticky bit) pour marquer les fichiers sous /etc qui doivent être ajoutés à l’archive compressée state.tgz. Ce seront des fichiers persistants et rechargés au redémarrage de l’ESXi.

L’archive compressée state.tgz est regénérée automatiquement sous 2 conditions :

1) toutes les heures et 1 minute, le script /sbin/auto-backup.sh est exécuté. Si la configuration de l’hôte ESXi a été modifiée, le script recrée l’archive compressée state.tgz.

2) durant un arrêt ou redémarrage “graceful” de l’ESXi, le script /sbin/shutdown.sh s’exécute avec la valeur 1 passée en paramètre (mise à jour du fichier state.tgz). Ce script détermine quels sont les fichiers qui seront archivés.

Après ces quelques rappels, nous allons nous intéresser à la sauvegarde automatique des configurations de serveurs ESXi.

Pour cela, rien de plus simple que d’utiliser un client pour se connecter sur chaque serveur ESXi et effectuer un transfert sécurisé du fichier state.tgz vers un répertoire local en utilisant le protocole de communication SSH.

Pour une question de sécurité informatique, la connexion sera établie par un utilisateur système avec des droits restreints. Son nom d’utilisateur est “bckupuser”.

Un script shell sera nécessaire pour automatiser les connexions et maintenir une rotation des sauvegardes (durée de rétention à déterminer en fonction de ses besoins).

Depuis le client vSphere, on se connecte à l’ESXi et on créé un nouvel utilisateur local (onglet “Local Users & Groups“) :

Sur le serveur ESXi, on active le service SSH et on ajoute la clé publique de l’utilisateur “bckupuser” sous /etc/ssh/keys-<user>/authorized_keys

Pour rendre nos modifications persistantes lors du prochain redémarrage du serveur, on modifie le fichier /etc/rc.local et on sauvegarde l’état du système :

En cas de panne, on utilisera un master CD ESXi (avec le même “build number”) pour effectuer une nouvelle installation sur un serveur de secours ou sur le serveur hôte réparé.

Oups ! mon environnement lab n’est pas à jour …

On active l’ESXi Shell à partir de l’interface DCUI (Troubleshooting Mode Options –> Enable ESXi Shell) et on appuie sur Alt-F1 pour ouvrir une console sur le système hôte.

On arrête le service usbarbitrator :

On redémarre le serveur :

On connecte un périphérique USB (FAT16) qui contiendra notre sauvegarde (backup.tgz).

Par défaut, l’emplacement du périphérique sera /vmfs/devices/disks/mpx.vmhbaXX:C0:T0:L0.

On copie le fichier de sauvegarde de l’ESXi (backup.tgz) sur la partition de boot “primaire” et on modifie le fichier boot.cfg pour spécifier le nouveau fichier à charger en mémoire. On redémarre l’ESXi.

Après un redémarrage, l’ESXi se retrouvera avec la configuration de notre sauvegarde et dans son état avant la panne. On veillera à supprimer “— backup.tgz” du chargeur de démarrage /bootbank/boot.cfg.

Sauvegarde automatique des configurations de serveurs ESXi bit.ly/12cXYAo #vmware #vsphere

— Alain BERNARD (@abernard1) 28 février 2013

ITIL (Information Technology Infrastructure Library) définit la résilience comme "la capacité d’un service informatique ou un élément de configuration de continuer à fonctionner correctement après une défaillance d’une partie d’un composant". L’objectif de ce billet est de présenter une solution technique permettant de diminuer le risque de sécurité en diminuant les impacts liés à la menace de "défiguration" d’un site web par un pirate informatique. 

Les exemples d’impacts de sécurité associées à la compromission d’un serveur web sont multiples :

- destruction de données ;
- corruption ou falsification de données ;
- vol ou espionnage de données ;
- usage illicite du système compromis pour attaquer d’autres cibles (utilisation de la bande passante, SPAM, etc.) ;
- atteinte à l’image de l’organisation ;
- atteinte à la disponibilité du système (interruption et rétablissement du service après incident).

Les failles applicatives sur les serveurs web sont exposées au regard du réseau Internet. Ainsi, la moindre faille de sécurité peut-être rapidement découverte et exploitée.

L’épilogue d’une attaque est relativement simple :

- recherche d’une signature (Google est notre ami) ;
- repérage de vulnérabilités ;
- exploitation d’une faille et intrusion dans le système.

Sur un plan juridique, le Code pénal sanctionne les atteintes aux systèmes de traitement automatisé de données. Issu de la loi Godfrain du 5 janvier 1988, l'article 323-3 précise :

« Le fait d'introduire frauduleusement des données dans un système de traitement automatisé ou de supprimer ou de modifier frauduleusement les données qu'il contient est puni de cinq ans d'emprisonnement et de 75000 euros d'amende. »

Dans une architecture de type distribuée, une première étude technique à forte résilience consisterait à rendre visible sur internet une version statique ou un miroir (en lecture seule) d’un site web dynamique.

​

Pour créer la version "statique" du site web, j’ai choisi d’utiliser l’application libre sous licence GPL HTTrack. C’est un outil configurable à souhait et très complet. Il permet de "mirrorer" un site web en construisant récursivement tous les répertoires, récupérant html, images et fichiers du serveur web. HTTrack réorganise la structure des liens en relatif. 

Pour le lab de test et la construction du miroir, j’ai codé un script shell (à adapter en fonction de sa configuration système) :

La durée de traitement du script peut-être plus ou moins long.

Elle est fonction de la taille du site et de sa profondeur. Une récursivité infinie est coûteux en temps. Dans le script, le site de test est exploré récursivement avec une profondeur de 6. En outre, l’exploration de liens profonds peut faire apparaître des effets de bord liés à des boucles sur certaines pages et avoir un effet bloquant. Il est donc important d’analyser les logs httrack.

Elle est également fonction du débit réseau et du temps consacré aux opérations d’I/O.

Enfin, il faut veiller à ce que les paramètres du script ne créent pas une surcharge CPU et n’affectent pas les performances du serveur web distant. Pour cela se référer au "Best practices" httrack : http://www.httrack.com/html/abuse.html

La mise à jour du projet courant est planifiée avec le script suivant :

En conclusion de ce billet, il est vrai que cette solution technique ne permettra pas de se prémunir de certains exploits avec élévation de privilèges. Par contre, le fait de présenter à l’attaquant, un système de fichiers en lecture seule, réduira le risque de sécurité lié à la menace (bien réelle) de "défiguration" d’un site web.

En matière de sécurité informatique, il reste important d’être informé des nouvelles vulnérabilités et de mettre en place une « politique » de mise à jour qui définit :

- les briques applicatives à mettre à jour ;
- l’identification et les responsabilités des différents acteurs dans ces mises à jour ;
- les moyens de récupération et de qualification des mises à jour.

Améliorer la résilience d’un serveur d’hébergement web bit.ly/Vv5Zhn

#infosec #sécurité #security

— Alain BERNARD (@abernard1) 17 février 2013

$ date +%s

1341211871

$ echo 1341211871|awk '{print int(($1-504921600)/30+0.5)}'

27876342

$ echo "obase=2;ibase=10;27876342" | bc

1101010010101101111110110

$ echo "obase=16;ibase=2;1101010010101101111110100"|bc

1A95BF4

Une politique de filtrage n’a pas pour objet de restreindre l’utilisation professionnelle de l’Internet mais en faciliter l’usage tout en définissant des contrôles d’accès entre les segments de réseaux et de diminuer le nombre de services et/ou de machines visibles sur le réseau interne.

Concernant les flux sortants, les réseaux sont conçus pour permettre au trafic de s’écouler à partir d’hôtes situées dans le réseau d’entreprise, vers des ressources sur le réseau Internet. Ce trafic est généralement limitée à des ports TCP|UDP et/ou à des adresses IP source et destination.

Dans ce système, la politique de filtrage est « tout interdire dans le sens flux sortant sauf des protocoles que l’on connaît et maîtrise ». Cette politique est adaptable rapidement par ajout/modification des règles de pare-feu pour prendre en compte des nouveaux besoins.

master@machineA:~$ sudo nc -n -vv -l 80

memo@machineC:~# sudo tcpdump -n dst port 80 and ‘tcp[13] & 0X02 == 2′

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

16:08:03.786475 IP 80.214.X.X.2974 > 192.168.1.6.80: Flags [S], seq 2056624716, win 512, length 0

16:08:03.786654 IP 80.214.X.X.2975 > 192.168.1.6.80: Flags [S], seq 1480487198, win 512, length 0

 Detecting and Preventing Unauthorized Outbound Traffic

Flux sortants en ligne de mire bit.ly/K7xGka

— Alain BERNARD (@abernard1) Juin 3, 2012