[SMSI] Evalsmsi install

Je continue mes péripéties sur l'étude des SMSI mais je fais une pause sur les normes pour vous présenter un outil permettant l'évaluation des SMSI : evalsmsi. Cet outil avait été présenté par Michel Dubois pendant les rump sessions du SSTIC 2009. Une telle solution, libre qui plus est, je n'en connais pas d'autre : il me paraît donc important de s'y intéresser.

En fait, ce poste sert peut-être à rien !

Le but de ce post est d'installer la solution mais la réalité, c'est qu'il existe déjà une image virtuelle toute faite et alors, il n'y a rien à faire si ce n'est de l'importer dans sa virtual box. Sauf que me concernant, j'avais des erreurs avec le fichier *.ova alors je ne me suis pas découragé pour autant et j'ai pris le tar.gz (on est joueur ou on l'est pas ;)).
Pour faire cela, je suis parti d'une nouvelle image Ubuntu 10.10 donc je reprends tout depuis e début. Certaines choses ne vous seront donc certainement pas utiles. En tout cas, même si l'auteur a pensé à faire un README.txt, je pense qu'un tuto pourra faciliter la vie de certains.


Donc ce post va peut-être servir finalement ...

Étape 1 : Installation des packages

La solution repose sur un architecture LAMP. Nous installons les packages en conséquence. Notez que nous devons créer la base de données avant l'installation de phpmyadmin :

jer001@ubuntu:~$ sudo apt-get install apache2
jer001@ubuntu:~$ sudo apt-get install mysq-server
jer001@ubuntu:~$ mysql -u root -p create evalsmsi
jer001@ubuntu:~$ sudo apt-get install phpmyadmin

Étape 2 : Apporter les restrictions principales

Ce serait un outrage de parler de hardening mais un minimum de mesures de sécurité me paraît nécessaire :

• On commence par changer l'alias pour atteindre l'interface d'administration de phpmyadmin, histoire qu'elle soit moins visible :

jer001@ubuntu:~$ sudo vi /etc/phpmyadmin/apache.conf (rajouter cette ligne) :

• On évite de fournir la version de PHP, question de principe (variable expose_php à Off) :

jer001@ubuntu:~$ sudo vi /etc/php5/apache/php.ini

• On passe à la configuration d'Apache pour cacher empêcher l'accès au fichier config.inc.ini de phpmyadmin, cacher les bannières, limiter les accès à l'application par filtrage IP :

jer001@ubuntu:~$ cd /etc/apache2
jer001@ubuntu:~$ sudo vi apache2.conf #rajouter ces lignes ...

jer001@ubuntu:~$ sudo vi conf.d/security #vérifier/changer la valeur de ces variables

jer001@ubuntu:~$ sudo vi sites-available/default #rajouter les lignes
jer001@ubuntu:~$ sudo /etc/init.d/apache2 reload

Étape 3 : Installation et configuration de la solution

# Nous installerons la solution dans un répertoire accessible par le serveur WEB
jer001@ubuntu:~$ cd /var/www
jer001@ubuntu:~$ sudo wget http://downloads.sourceforge.net/project/evalsmsi/evalsmsi_2.3.1.tar.gz
jer001@ubuntu:~$ sudo tar -xzvf evalsmsi_2.3.1.tar.gz
jer001@ubuntu:~$ sudo rm evalsmsi_2.3.1.tar.gz
# On attribue les droits du serveurs WEB au répertoire où est localisée la solution
jer001@ubuntu:~$ sudo chown -R www-data:www-data evalsmsi/
# On récupère le fichier SQL pour configurer la base de données.
jer001@ubuntu:~$ sudo gunzip -d /var/www/evalsmsi/docs/evalsmsi.sql.gz

Pour lancer les requêtes SQL de ce fichier, j'ai fait simple un copier du contenu du fichier et un coller dans phpmyadmin (onglet SQL) et "Go" (cliquer) :


On crée un nouvel utilisateur dans MySQL pour la gestion de la base "evalsmsi". Je le fais via phpmyadmin de nouveau (onglet "Privileges") :


On fournit les données de connexions de la BDD à la solution (renseigner les comptes notamment) :

jer001@ubuntu:~$ sudo vi /var/www/evalsmsi/functions.php

On vérifie que tout fonctionne dans l'interface d'Evalsmsi > Cliquer sur "Accès établissement" ...

... et entrer les crédences d'un admin (ex : compte admin1). Si ça marche, vous verrez cette page :

Success!


Conclusion

Rares sont ceux qui maîtrise la technique et l'organisation de la sécurité. Or, le SMSI est destiné avant tout à cette 2e catégorie de personnes. Alors autant leur permettre d'utiliser une telle solution sans qu'ils soient bloquer par la technique.
Il resterait beaucoup à dire comme la sécurisation de la plateforme et surtout, l'utilisation de la solution. Peut-être l'objet d'un prochain post ?

[SECURITY TOOL] SSL power with SslNetcat!

Le protocole SSL est largement utilisé et il n'est plus besoin aujourd'hui de le présenter. Mais dans la pratique, il nous est indispensable pour sécuriser les communications par exemple. Aussi, lors de l'audit comme celui d'un site WEB en HTTPS, il nous sera très utile de communiquer via ce protocole pour effectuer nos tests. Un outil va nous servir de couteau-suisse ici, il s'agit de SslNetCat.

0 - Préparation et contexte

Pour la suite de nos travaux pratiques, nous commençons par télécharger le script SslNetCat disponible ici. Puisqu'il s'agit d'un script perl, soyons explicite et il sera enregistré ici en tant que scnc.pl. Il faut le télécharger sur une machine cliente ET une machine serveur.

Pour exécuter le script perl, nous aurons besoin de modules perl. Attention, la liste peut être différente pour votre machine :

# perl -MCPAN -e 'install "Net::SSLeay"'
# perl -MCPAN -e 'install "IO::Socket::SSL"'
# perl -MCPAN -e 'install "Net::Telnet"'
# perl -MCPAN -e 'install "IO::Socket::INET6"'

Concernant le contexte, nous avons donc besoin de deux machines. L'OS est indépendant, le tout est que vous puissiez exécuter le script perl téléchargé. Dans notre cas, nous aurons :

• Une machine serveur sous Linux, 192.168.0.10 (valeur modifiée) ;
• Une machine cliente sous Linux, 192.168.0.20 (valeur modifiée) ;

Dans la suite de ce post, nous allons reprendre les exemples de l'auteur mais en expliquant de bout en bout les cas pratiques afin que vous puissiez facilement utiliser l'outil. C'est ainsi que nous débuterons dès la génération du certificat par exemple. A noter cependant que si le but est seulement de s'exercer, l'auteur de l'outil propose des certificats et des clés de test.


1 - Créer un tunnel SSL pour sécuriser ses communications

NB : Aller directement à la partie 1.2 si vous utilisez les certificats proposés par GomoR.

1.1 - Création des certificats

1.1.1 - Etablissement de la CA

Nous utilisons openssl (que vous devez avoir mis à jour si vous êtes sous Debian !!! cf. vulnérabilité critique). Aussi, nous devons déterminer une autorité de certification (dénommée ensuite CA) pour signer le certificat mais ici, il s'agira d'un certificat auto-signé, quand bien même cela n'a aucune valeur d'un point de vue sécurité, le principe reste identique.

# openssl req -new -x509 -keyout ca-msblog.key -out ca-msblog.crt

Nous obtenons deux fichiers : ca-msblog.crt (certificat) et ca-msblog.key (clé privée) de la CA.

1.1.2 - Génération du certificat côté serveur

# openssl req -new -keyout server-msblog.key -out server-msblog.csr

Puisque le certificat sera signé localement par la CA, nous n'utilisons pas les attributs supplémentaires ("extra"). Deux nouveaux fichiers sont générés : server-msblog.key et server-msblog.csr. Envoyer ce dernier au CA s'il ne s'agit pas de la même machine.

Commençons par préparer le magasin de certificats pour la CA :

# vi /usr/lib/ssl/openssl.conf

Trouvez la ligne commençant par dir et modifiez ./demoCA par ./msblogCA.

# mkdir ./msblogCA
# cd msblogCA
# touch index.txt
# mkdir newcerts
# echo "01" > serial

Puis créons le certificat serveur lui-même :

# cd ..

# openssl ca -cert ca-msblog.crt -keyfile ca-msblog.key -out server-msblog.crt -in server-msblog.csr

Acceptez le certificat en tapant 'y' quand cela est demandé (deux fois) :

Nous venons de créer le certificat server-msblog.crt. Nous avons tous les fichiers nécessaires ;)

1.2 - Créer un tunnel de communication chiffré

1.2.1 Mettre le serveur en écoute sur le port 12345 et rediriger le trafic sur le port 80

# perl scnc.pl -vc -a ca-msblog.crt -f server-msblog.crt -k server-msblog.key -p 12345 -r localhost:80

12.2 Lancer la connexion du client vers le serveur

# perl scnc.pl -v -s localhost -p 6789 -r server:12345::ssl

2 - Audit d'un serveur Web en HTTPS

Il s'agit ici de faire de notre client un proxy SSL qui nous servira à auditer le serveur Web.

2.1 - Préparation

Nous avons besoin d'un certificat et d'une clé privée pour ce client. Ces deux éléments seront générés de la même manière que nous l'avons fait pour le serveur précédemment (cf. 1.1.2). Ainsi, nous obtenons client-msblog.crt et client-msblog.key.

2.2 - Tests pour l'audit

Pour commencer l'audit, il suffit de se connecter (sur le client avec serveur audité, 192.168.0.10) :

# perl scnc.pl -v -r 192.168.0.10:443::ssl -a ca2-msblog.crt -f client-msblog.crt -k client-msblog.key -s localhost -p 1234

NB : il faudra retourner sur la "machine-proxy", entrer éventuellement la passphrase.

Puis de lancer nos commandes (sur le client toujours - exemple) :

# perl scnc.pl -v localhost 1234
# GET / HTTP/1.0

De même, utiliser l'adresse loopback dans les outils utilisés pour l'audit du serveur HTTPS.

[Security Solution] [Ops Mgr 2007] Be careful to not be catched!

Operations Manager (Ops Mgr) est l’outil de supervision proposé par Microsoft. Anciennement appelé MOM (pour Microsoft Operations Manager), cette nouvelle version propose des fonctions de sécurité dont le chiffrement de bout en bout. Si cette solution est capable d’auditer des événements de toute nature, l’article focalisera sur les aspects sécurité.

Etape 0 : Définition du traitement de l’information

Afin de cadrer notre sujet, il est important de distinguer les différentes étapes du traitement de l’information :

• La collecte qui consiste à récupérer les informations par des agents généralement.
• L’agrégation qui consiste à rassembler les informations et de les transférer vers un composant d’exploitation des données.
• La consolidation qui consiste à exploiter les informations (statistique, reporting, …) qui sont rassemblées et enregistrées dans une base de données associée ;
• La corrélation qui consiste à exploiter l’information de manière intelligente, basée sur des règles et une intelligence artificielle. Cela permet par exemple de déterminer une attaque grâce à la corrélation de plusieurs alertes.

En l’occurrence, la supervision d’un Système d’Information va de la collecte des données à leur consolidation.


Etape 1: Classification des données

Ce sont les données auditées qui détermineront la suite, c'est-à-dire le choix de l’outil, l’architecture, l’installation des composants et les configurations par exemple. Les questions suivantes devraient aiguiller le choix de l’entreprise :

• Quel est le but de la collecte ? (détection d’attaque, statistiques, reporting, …) ;
• Quel est l’existant de l’entreprise ? (solution de supervision déjà mise en place, logs déjà centralisés, alertes déjà remontées, incidents déjà traités, …) ;
• L’entreprise est-elle exposée ? (accès Internet, serveurs applicatifs en frontal, accès VPN, …) ;
• L’entreprise est-elle ciblée ? (peu ou de nombreux incidents ont-il été détectés ? Quelle est la criticité de ces incidents ?) ;
• Quelles sont les moyens mis à disposition ? (Espace disque, bande passante, et autre performance matérielle) ;
• Quelle est la nature des données transitant sur les réseaux de l’entreprise ? (informelle, critique, top secret, …) ;
• Etc.

La liste établie, l’étape suivante consiste à déterminer des catégories d’information comme :

• Les contrôles d’accès (ex : les tentatives de connexion) ;
• La sécurité de l’administration des serveurs (ex : gestion du domaine) ;
• La sécurité des ressources (ex : l’accès aux données sensibles) ;
• La sécurité des traces (ex : les règles de traçage) ;
• Etc.

Pour terminer, nous classons l’information par criticité :

• Le niveau critique qui demande une action urgente pour éviter un risque de compromission et de propagation ;
• Le niveau intermédiaire pour les évènements à traiter dès que possible et les preuves dans le cadre d’une investigation ;
• Le niveau basic pour les évènements additionnels qui nous apporterons des éléments nécessaires pour une action de forensics ou d’incident sécurité général.

Etape 2: Le choix de l’architecture

Nous supposons maintenant que le choix de la solution est Operations Manager 2007 qui nous servira donc d’exemple dans le reste de cet article. En voici les composants de sécurité :

• Le Root Management Server (RMS) : ce rôle est indispensable. C’est le point central de l’architecture et d’où seront déployées les configurations ;
• Le Management Server (MS) : rôle intermédiaire entre le RMS et les agents (ou le rôle Gateway Server). Il a le rôle de consolidation des informations ;
• L’Audit Collector Server (MS-ACS) : il s’agit d’un MS particulier chargé de traiter les informations de sécurité. Ils sont reliés à une base de données dédiées aux évènements de sécurité, l’Audit Database ;
• Le Gateway Server : ce rôle est une passerelle qui permet notamment de traverser des zones réseaux en assurant la sécurité des communications. A ce niveau, nous parlons d’agrégation de l’information ;
• Les Agents : ils ont pour but de superviser les serveurs ou les postes de travail. Ils ne sont pas indispensables car il existe un mode sans agent mais cela n’est pas recommandé d’un point de vue sécurité. Une fois l’agent installé sur une machine, nous pouvons configurés des Management Packs (MP), c'est-à-dire des modules dédiés à la supervision de machines particulières. Par exemple, il existe un MP Exchange 2007.

Etape suivante, le design de l’architecture. Il dépend de l’existant et des besoins de l’entreprise mais voici des principes de bonnes pratiques :

• Installer un rôle ACS par chaque zone cloisonnée du périmètre pour assurer que tous les évènements souhaités sont remontés ;
• Relier chaque ACS à une base Audit Database dans le même sous-réseau ;
• Installer chaque ACS sensible en cluster ;
• Relier les ACS à un RMS, le dernier devant être dans une zone sécurisée puisqu’il contient l’ensemble des informations de l’entreprise ;
• Installer le rôle Gateway Server avant de traverser un pare-feu. Ainsi, une seule connexion est à ouvrir entre les deux zones ;
• Installer des agents sur les serveurs et machines à auditer. En effet, le mode sans agents utilise des flux RPC et DCOM non protégés ;
• Eviter au mieux le déplacement d’information sensible ;
• Eviter au mieux la transmission d’information sur des réseaux externes ou non sécurisés (cas des entreprises internationales).

Etape 3 : Sécuriser les échanges

Par défaut, les authentifications reposent sur le protocole Kerberos v5. Cependant, il est possible de mettre en place une authentification mutuelle basée sur SSLv3.
Dans le cas où les agents et le MS ne sont pas installés sur le même domaine, l’authentification via Kerberos n’est plus possible. Par conséquent, seul SSL peut apporter la sécurité suffisante. A noter que l’exemple donné entre les agents et le MS est valable aussi entre les agents et un Gateway Server, deux MS dans un même domaine ou un MS et un RMS par exemple.
Si l’entreprise fait le choix de mettre en place une authentification avec SSL, il est recommandé d’utiliser les certificats de la PKI groupe de la compagnie.

Une fois les composants authentifiés, la communication repose sur la même sécurité que le protocole d’authentification, c'est-à-dire Kerberos ou SSL. En général, il est recommandé de mettre en place SSL dans les cas suivants :

• les données traversent deux zones et/ou deux domaines différents ;
• les données traversent une zone externe (comme l’Internet) ou non de confiance.

Etape 4 : La gestion des rôles, des comptes et des droits

Etape 4.1 : Au niveau de l’agent

L’agent doit disposer de droits suffisants pour récupérer les évènements de sécurité (notamment les Event logs de Windows par exemple). En fait, l’application des droits se fait sur un compte de service nommé agent action account. Pour fournir un minimum de droit, nous devons lui attribuer un compte de domaine avec les droits suivant uniquement :

• Membre du groupe Local Users ;
• Membre du groupe Performance Monitor Users ;
• Attribuer le droit Allow log on locally.

S’il s’agit des droits minima requis, en réalité, les droits nécessaires dépendent aussi des Management Packs déployés et des politiques de sécurité de l’entreprise.

Quant au déploiement des agents, ils requièrent des droits administrateurs via un compte dédié. Ce dernier peut ensuite être supprimé. En pratique, le déploiement pourra être réalisé par un outil tel que SCCM.

Etape 4.2 : Au niveau des serveurs

En premier lieu, un compte de service est aussi activé sur chaque composant de la solution de supervision. Les droits à attribuer sont similaires, la contraintes des Managements Packs en moins.

Ensuite, le rôle des administrateurs doit être défini pour chacun afin de lui attribuer l’un des rôles fournis par Ops Mgr. Il est important de profiter de la granularité des profiles proposés par la solution. Les rôles en question sont : Administrator, Author, Advanced Operator, Operator, Read-Only Operator et Report Operator.

Conclusion

La supervision sécurité est un sujet indispensable pour se prémunir des attaques informatiques. Autant se faire attaquer peut être grave pour l’entreprise, autant se faire attaquer et ne pas le savoir n’est pas concevable. Aussi, il est important de savoir que la supervision demande un travail en amont (la classification des informations) et en aval (comme la corrélation et la détection d’attaque) afin que le projet fournisse un réel bénéfice à l’entreprise.

NB : Bientôt, vous trouverez sur Internet une version plus longue ... patience et bonne recherche cher agent ;)

[Security Solution] [MAIL] Exchange 2007

Exchange 2007 est la nouvelle solution de messagerie proposée par Microsoft. En comparaison avec la dernière version, datant de 2003, de nombreuses fonctionnalités ont été apportées, notamment en termes de sécurité. En tant qu’agent, vous pouvez être amenés à auditer la messagerie de l’entreprise. Alors pour avoir tous les atouts de votre côté, mieux vaut connaître l’outil et trouver les pistes d’exploitation au fur et à mesure de la lecture de cette nouvelle mission. En six étapes, nous allons étudier les points de sécurité que nous pouvons rencontrer, qu’il s’agisse d’une attaque interne ou externe. Dans la situation inverse, s’il s’agit de votre messagerie, vous connaîtrez ainsi les points qui devraient être sécurisés.

Etape 1: La sécurité de l'architecture

Exchange 2007 est constitué de cinq rôles qui sont appliqués sur les serveurs lors de l’installation. Puisqu’ils peuvent être mutualisés, prendre la main sur un rôle pourra nous donner des droits sur un autre rôle installé sur le même serveur physique. Plus précisément, ces rôles sont :

• Rôle Mailbox : Normalement placé dans le LAN interne de l’entreprise car ces serveurs hébergent les bases de données contenant les emails et les profils utilisateurs et donc les données sensibles. C’est pour cela que pour des raisons de disponibilité du service de messagerie, des clusters devraient être installés. Sinon, ils pourraient être sensibles à des attaques de type DoS. A savoir : les serveurs Mailbox sont directement et étroitement liés aux serveurs AD… Dans le pire des cas, supprimer un compte de messagerie supprime un compte AD et la création d’un compte de messagerie ? Concernant les droits des administrateurs, ils ont été séparés les droits entre la messagerie et l’AD … depuis cette version d’Exchange seulement …;
• Rôle Hub Transport : Connecté aux serveurs Mailbox, ces serveurs doivent être séparés par un pare-feu. Ils représentent en fait les relais SMTP. En général, le serveur Hub Transport est installé par domaine. Attention, mal configurés, ils peuvent être reliés directement à l’Internet … ;
• Rôle Client Access Server (CAS) : Connecté aux serveurs Mailbox, ce serveur fournit les fonctionnalités de messagerie à distance (cf. Etape 3). Selon que le rôle Edge Transport est installé ou non, le CAS est le plus exposé à l’Internet et y est installé un serveur IIS. Nous devrions donc vérifier qu’il n’existe pas de faille sur le serveur WEB ;
• Rôle Edge Transport : Rôle non obligatoire. Il sert de sas entre l’Internet et le CAS. Il sera alors placé dans une DMZ. Un grand nombre de propriétés de sécurité sont définies ici tandis qu’elles seront configurées sur le Hub Transport s’il n’est pas prévu d’utiliser le rôle Edge Transport
• Rôle Unified Messaging : Ce type de serveur a surtout pour objectif d’apporter des fonctionnalités liées à la messagerie unifiée tel que la vidéo-conférence ou la synchronisation avec la VoIP par exemple. Avis aux experts !

Etape 2: La sécurité des serveurs de messagerie

Chaque rôle devrait avoir subi un hardening. Quelque soit le rôle traité, seuls les services nécessaires devraient être lancés et seuls les programmes nécessaires devront être installés. Cela peut être fait avec le Security configuration Wizard (SCW) de Windows. Ensuite, des ACL devraient être imposées sur les dossiers créés et notamment les dossiers publiques sur les serveurs Mailbox tandis qu’ils devraient être déconnectés, ils devraient ...
Pour tous les serveurs, une politique de rôles d’administration devraient être appliquée en appliquant une gestion des droits. Six profiles différents sont prédéfinis nativement dans Exchange 2007, le but étant d’appliquer le principe de « moindre privilège ». Ici, il faut miser sur des rôles attribués de manière trop laxiste.

Ensuite, nous un antivirus dédié et une solution anti-spam devraient être installés. Qu’il s’agisse de la solution Forefront Security for Exchange proposée par Microsoft ou non selon ses besoins, les solutions retenues utilisent normalement une architecture 64bits et proposent des protections adéquates pour ce système de messagerie. Il faudra donc identifier la présence puis la nature de ces solutions si nous avons besoin de les contourner.
Pour terminer sur la partie serveur, ces derniers devront bénéficier d’une solution de backup, de monitoring et de haute disponibilité. Si ce n’est pas le cas, il sera plus facile de ne pas laisser de traces pour l’attaquant.


Etape 3: La sécurité des clients de messagerie

Les clients de messagerie sont Outlook 2007 (client lourd), OWA (Webmail) et Outlook Anywhere (Outlook avec accès distant).

Etape 3.1 : Authentification

Exchange 2007 peut bloquer les communications entre un serveur Mailbox et une version d’Outlook autre que 2007. Ensuite, il faut savoir que les fichiers personnels de l’utilisateur, et donc sensibles, sont présents sur chaque poste client mais non chiffrés … La solution proposée par Microsoft est d’utiliser le chiffrement EFS ou BitLocker.

Concernant OWA, l’authentification par défaut s’effectue via un mot de passe et utilise le protocole Kerberos ou NTLM en cas d’échec. Il se trouve que des outils comme rozntlm permettent de tester les connexions NTLM … Il est cependant possible d’utiliser une authentification forte reposant sur des Smart Cards avec code PIN pour chiffrer les communications via SSL.

Quant à Outlook Anywhere, l’authentification se fait par mot de passe (via NTLM ou le mode Basic) puis les flux peuvent être chiffrés avec SSL. Pour cela, il conviendra de configurer un serveur IIS sur les serveurs Edge Transport (ou les CAS si non installés).

Etape 3.2 : Limitation des risques de propagation virale et de spams

Outlook et OWA sont capables de filtrer les emails en fonction des extensions des pièces jointes. Plusieurs niveaux de blocage peuvent être configurés.

Les fonctionnalités d’anti-spam proposées reposent des listes (blanches et noires), le contenu des messages (à base de mots clés) et un filtre comportemental.

Enfin, l’Object Model Guard a pour but de vérifier qu’un programme illicite n’essaie pas d’atteindre le carnet d’adresses ou d’envoyer un email avec le profil de l’utilisateur.

Etape 4: La sécurité des communications

Etape 4.1 : La sécurité des communications serveur <-> serveur

La grande nouveauté d’Exchange 2007 est la possibilité de chiffrer les communications en utilisant le protocole SSL/TLS avec authentification mutuelle entre les serveurs via certificats. Si par défaut Exchange propose l’installation de certificats auto-signés il est recommandé de mettre en place des certificats générés par la PKI de l’entreprise et les faire signer par l’autorité de certification racine. Il est aussi possible d’utiliser IPSec à la place de ou en plus de SSL/TLS.

Etape 4.2 : La sécurité des communications serveur <-> client

Autre nouveauté d’Exchange 2007, le chiffrement des communications entre Outlook 2007 et les serveurs Exchange (les serveurs Mailbox pour être précis). Côté client, cette option devraient être appliquée et imposée au client par GPO. Si cela n’est pas le cas, nous pourrons sur le poste client désactiver les options de sécurité en nous baladant dans les menus d’Outlook.

Etape 5: Renforcer le niveau de sécurité

Etape 5.1 : Appliquer les restrictions

Pour des raisons de performance, la taille des emails entrants et sortant et le nombre de destinataires sont certainement limités. Ces restrictions peuvent être contrôlées à plusieurs niveaux : au niveau de l’entreprise, du périmètre Exchange 2007, des connecteurs, des serveurs ou des utilisateurs.

Dans un deuxième temps, il est possible que des listes d’expéditeurs soient paramétrées. Si l’expéditeur fait partie de la liste, plusieurs actions pourront de dérouler : accepter le message, refuser le message ou demander à ce que tous les expéditeurs soient identifiés.

Etape 5.2 : Le filtrage des emails

Avec Exchange 2007, il existe de nombreuses méthodes pour filtrer et/ou traiter les messages à implémenter sur les serveurs Hub Transport pour être sûr que chaque email est traité :

• Le blocage des emails selon l’extension ou le contenu d’un fichier de type MIME ;
• Le filtrage des expéditeurs qui se fait sur l’analyse du contenu du champ MAIL FROM.
• Le filtrage des destinataires dont l’analyse porte sur le contenu du champ RCPT TO ;
• Identification du serveur SMTP expéditeur : Il s’agit de vérifier que le serveur SMTP envoyant le message appartient bien au domaine auquel il prétend ;
• Evaluer la réputation de l’expéditeur : grâce à un algorithme, il s’agit d’attribuer à l’expéditeur un niveau de réputation ;
• Le postmark : Il s’agit d’un marqueur qui est placé dans l’entête de l’email envoyé pour s’assurer qu’il ne s’agit pas d’un courrier indésirable ;
• Le blocage de l’affichage des images ;
• La classification des messages : l’expéditeur peut attribuer une classe à son message (ex : « confidentiel »). En fonction de cette classe, une action pourra être exécutée.

Etape 6 : La maintenance du niveau de sécurité

Selon que l’entreprise met en place ou non des actions de maintenance en termes de sécurité, il sera plus ou moins facile pour l’attaquant de percer la sécurité de la messagerie dans le temps :

• Les outils de vérification tels que Microsoft Exchange Best Practices Analyzer, MBSA, IIS Lockdown tool devraient être lancés régulièrement (ou les contrôles de SCCM) ;
• La sécurité devraient être évaluée grâce à des tests de vulnérabilité sur les serveurs de messagerie et des audits de configuration sur les serveurs et les clients ;
• Une gestion des mises à jour devrait assurer que les serveurs ne sont pas exploitables par les nouvelles failles ;
• Une gestion des traces pour des raisons légales, pour la gestion des incidents et le recouvrement des emails devrait être configurée.

Pour plus d’information, je vous laisse trouver dans quelques jours, sur Internet une version (plus !) longue de ce Post.

[SIM] MISSION: Watch everything!

Dans de nombreuses tâches de sécurité, il faut faire appel aux logs. Mais il s'agit certainement de l'une des tâches des plus difficiles car deux problématiques essentielles se posent : où chercher ? et comment ne pas manquer l'information utile parmi tous les logs fournis par l'ensemble du réseau (serveurs et équipements réseau) ? La solution existe depuis un moment maintenant et son nom de code est SIM pour Security Information Management. A travers l'exemple Open Source nommé OSSIM, nous verrons les caractéristiques et les réponses techniques apportées par ce type d'outils.

Identification :

• Définition ;
  

Un SIM est un moteur de corrélation dont la puissance peut être évaluée par le nombre de logs qu'il peut traiter à la seconde et les types d'information qu'il est capable de comprendre. A l'issue de cela, un SIM corrèle les logs selon des règles pré-établies afin de remonter des alertes en (quasi) temps réel.

• Caractéristiques basiques ;

S'il existe de nombreux SIMs sous forme d'appliance, OSSIM est entièrement software. Il a plusieurs but principaux qui sont de superviser et de piloter la sécurité d'un (sous-)réseau dans sa globalité. En effet, il prendra en compte aussi bien les serveurs (quelque soit l'OS) que les équipements réseau (pare-feu, routeurs, etc...). Pour cela, notre SIM utilise une architecture client / serveur. Nous aurons d'une part la partie serveur sur lequel tournera un service pour l'affichage de la console de pilotage et d'autre part, les clients qui sont en réalité ni plus ni moins des agents. Ces derniers auront simplement pour rôle de collecter des informations et de les renvoyer vers le serveur. Comme nous l'avons compris, OSSIM est une solution Open Source par sa conception mais aussi par les modules (appelés sensors) utilisés. En effet, pour collecter les informations nécessaires, notre corrélateur se base sur les outils les plus connus de la communauté Open Source utilisés en tant que "sensor". On parle alors de SNORT/ACID, NESSUS, NMAP, NTOP, p0f, TCPTrack, Syslog, PADS et NAGIOS.

• Caractéristiques avancées :

A - La corrélation

La corrélation se fait à partir de toutes les informations récoltées par les agents, chacun devant être disposés sur des noeuds stratégiques du réseau à superviser. Ensuite, les informations sont traitées en les confrontant. Premier avantage, on réduit le nombre de faux-positifs qu'un sensor à lui-seul fournirait (ex : SNORT). La corrélation peut être détaillée en trois étapes :

1. Cohérence des données - OSSIM commene par examiner la cohérence des données collectées pour en déterminer la pertinence. Grâce à un inventaire de matériel et de logiciels présents sur le réseau, nous saurons que tel serveur utilise IIS par exemple. Si une alerte à propos de cette même machine concerne Apache, le score de pertinence sera très faible.
2. Correspondance des données - OSSIM a aussi à sa disposition une table de correspondance alertes-versions et alertes-vulnérabilités fournies par SNORT et NESSUS. Ainsi, supposons qu'une alerte remonté par SNORT correspond à une vulnérabilité connue après un scan de NESSUS, le score de pertinence sera cette fois élevé.
3. Les directives logiques - Pour terminer, notre solution fonctionne aussi avec des directives ou règles qui permettent de corréler des anomalies, des alertes et des états (fournis via les moniteurs).

B - La prioritisation ;

Pour qu'une solution de sécurité soit efficace, il faut que celle-ci s'adapte au mieux aux particularités et aux exigences de l'environnement où nous désirons la déployer. OSSIM est capable de répondre aux questions suivantes :
1. Qu'est-ce qui est important pour la sécurité ?
2. Quelles sont les adresses sources que l'on redoute avant tout ?
3. Quelles sont les adresses de destination les plus critiques ?

Par exemple, nous admettons qu'une attaque provenant d'Internet et ayant pour cible une adresse interne de notre réseau est prioritaire, d'autant plus s'il s'agit d'un serveur financier plutôt qu'un serveur d'impression. Alors, nous pourrons via notre SIM donné un score de priorité entre 0 (priorité minimale) et 5 (priorité maximale) pour chaque équipement réseau.

C - L'évaluation des risques ;

Grâce à la combinaison de plusieurs éléments, OSSIM est capable d'évaluer le risque d'une attaque en cours. Il se base sur :

1. L'algorithme CALM (Compromise et Attack Level Monitor).
2. Les directives (pré-établies ou écrites).
3. Des seuils de tolérance.

Ce système de points fait l'objet d'un calcul qui permet d'évaluer le niveau de l'alarme :

niveau_alerte = (importance_machine * prioritisation * risque) / 10

Le tableau de bord d'OSSIM :

A travers un exemple concret d'attaque et d'investigation, voyons le tableau de bord fourni par la solution. Celui-ci est founi via un portail WEB. A noter que des fonds d'écran sont disponibles sur le site d'OSSIM.

• Le panneau de contrôle général ; Fournit les informations globales (niveau de sécurité actuel de l'ensemble du réseau, alerte la plus grave pour le réseau, les sous-réseaux, les serveurs). Aussi, on y trouve un graphe avec le nombre de machines éventuellement attaquées et attaquantes (après compromission).

• Le riskmeter. Si le premier panneau montre un problème (ex : nombre de machine attaquées en augmentation), nous nous dirigeons vers le riskmeter qui est un graphe en barre dont la valeur augmente dans le même temps qu'une attaque s'intensifie. par exemple, lors d'un scan massif, au fur et à mesure des scans, nous verrons la barre correspondant à la machine cible avancer en temps réel. Quelque chose se prépare !
  
• Le tableau d'alerte. Ici sont regroupées les alertes remontées par SNORT et visualisées avec l'interface ACID ou BASE (au choix). Chaque alerte peut correspondre à une phase de l'attaque.
  
• Le tableau d'alarme. L'ensemble des alertes relevées en 3 peuvent constituer une alarme après corrélation. Dans ce nouveau tableau, nous voyons les attaques repérées (ex : la propagation d'un vers) et le niveau de l'alarme (de 0 à 10).

• La gestion d'incident. Il est donc temps d'agir alors, on utilise l'outil de ticketing qui permettra d'alerter les personnes concernées de l'attaque en cours. La réactivité est de mise dans ce genre de situation.
  
• Les statistiques. Une fois l'incident repéré et traité, il ne faut pas que cela se reproduise. Grâce aux panneaux fournis par NTOP entre autres, nous pourrons trouver des indices par rapport à l'origine de l'attaque. Aussi des tableaux comme le top 20 des attaques nous permettront de concentrer nos efforts sur les points les plus critiques de notre S.I.
  

Les résultats fournis par OSSIM :

Un tel outil n'a de sens que s'il est en mesure de fournir différents résultats qui nous aideront à gérer les incidents, à fournir les informations nécessaires en cas de forensics, à dessiner les graphes qui vont bien pour évaluer la sécurité de son S.I et en trouver les points faibles (dans le but d'y remédier bien sûr).

C'est donc sous forme de mails, ticketing, graphes, tableaux et rapports (PDF, HTML, ...) que nous aurons à disposition toutes les informations nécessaires.
Les informations obtenues, étant de différentes natures, pourront soit être utiles à un Administrateur Sécurité (rapport technique, relevé d'incident,...) soit à un RSSI (statistiques, top20, synthèses).

D'autres information dans l'article d'Hakin9, numéro 10/2007.