Audit et definition de la politique de sécurité du réseau informatique de la first bank

7. RECOMMANDATIONS

Les recommandations de cette partie ne sont qu'une conséquence des scans, des tests d'intrusions effectués dans les précédentes sections ainsi que de notre expérience en audit de sécurité.

R1 : FERMETURE DES PORTS NON UITLISES

Les ports non utilisés peuvent être exploités à tout moment par les attaquants comme porte d'entrée dans le système.

C'est le cas des ports 21 (ftp) et 3306 (mysql) du serveur web/mail qui étaient ouverts au moment de notre scan mais aucun service à l'écoute.

C'est le même constat pour les ports Telnet et SSH qui sont ouverts en même temps sur les VPN des différentes agences. Il faut dire que SSH a été crée pour pallier les insuffisances de Telnet et donc, le port Telnet doit être fermé en cas d'utilisation de SSH.

De même les ports, pop3 et pop3s, imap et imaps sont ouverts au moment de notre scan. Ceux de ces ports qui ne sont pas utilisés doivent être fermés parce qu'ils présentent un risque pour la sécurité.

R2 : RENDRE LES SERVEURS FURTIFS

Les configurations par défaut doivent être évitées au niveau des serveurs. Les informations comme le type et la version du système d'exploitation utilisé, les versions des services qui écoutent sur les différents ports doivent être cachées et rendues inaccessibles lors des scans. Les sections réservées à cet effet se trouvent dans les fichiers de configuration des différents services.

Les fichiers de configuration des différents serveurs doivent être édités et modifiés pour éviter d'avoir des serveurs dits « bavards ».

Pour le serveur Apache par exemple, il faut ajouter les lignes suivantes dans le fichier http.conf :

ServerTokens Prod
ServerSignature Off

R3 : DESARMER LA METHODE TRACE DE HTTP

La méthode TRACE du serveur http est utilisée pour le débogage des connections au niveau du serveur web. Le diagnostic de Nessus propose un processus pour désarmer cette méthode.

R4 : LA MISE A JOUR DES APPLICATIONS

L'évolution des applications ne concerne pas seulement les commodités d'utilisation au niveau de l'interface et l'ajout des fonctions supplémentaires mais aussi la sécurité de ces applications. Ce dernier aspect n'est pas souvent perçu par l'utilisateur non averti qui est de ce fait insensible à la mise à jour des applications. Ainsi plusieurs versions d'une même application offrent souvent les mêmes fonctions ainsi que les mêmes commodités d'utilisation mais les dernières versions corrigent souvent certains détails de sécurité qui ne sont pas facilement perceptibles.

Le diagnostic fait à travers Nessus plus haut dans ce document a notamment indiqué que les serveurs Apache et SSL étaient exposés à certaines vulnérabilités du simple fait que ces derniers n'étaient pas à jour.

R5 : RENFORCEMENT DE LA SECURITE DES MOTS DE PASSE ET CLES CRYPTOGRAPHIQUES

SECURITE DES MOTS DE PASSE

Les mots de passe par défaut au niveau des serveurs, des routeurs ainsi que des applications réseaux doivent être supprimés et remplacés par des mots de passe plus sûrs dès la première utilisation de ces derniers. Bien plus, les mots de passe doivent être choisis de manière à échapper aux attaques de type dictionnaire (noms, prénoms, date de naissance, mots du langage courant) et aux attaques de force brute.

Pour combattre ce type d'attaques il est recommandé de :

§ ne pas utiliser des mots de votre langage courant,

§ choisir des mots de passe longs (souvent au moins 8 caractères), avec une suite de caractères totalement aléatoires et avec des caractères spéciaux,

§ alterner les majuscules et les minuscules.

CRYPTOGRAPHIE

L'algorithme de cryptographie utilisé lors de l'envoi des données sur le réseau est DES. Ce qui pose un problème de sécurité car cet algorithme a été cassé en 1998 et remplacé par AES.

Nous proposons l'utilisation d'un protocole de cryptographie basé sur AES et RSA. AES est le nouvel algorithme de cryptographie symétrique non encore cassé. RSA est le meilleur algorithme de cryptographie asymétrique recommandé en ce moment.

L'utilisation RSA nécessite pour autant la mise en place d'une infrastructure à clefs publiques (PKI) pour garantir l'authenticité des clés publiques. La banque doit pour cela choisir une autorité de certification sûre et reconnue mondialement.

Par ailleurs, le stockage des certificats nécessaires au fonctionnement de HTTPS, IMAPS, ... doit être effectué avec la plus grande prudence (le responsable devra éviter d'en conserver une copie dans un dossier mail par exemple).

R6 : DETECTION D'INTRUSIONS

Il faut installer à divers points stratégiques du réseau des IDS pour détecter les tentatives d'intrusions (scan des ports, scan des vulnérabilités). Un processus d'installation et de configuration de Snort a été proposé dans ce document. L'entreprise pourra acquérir la version commerciale de ce produit pour bénéficier des mises à jour de la base des vulnérabilités en temps réel.

Bien plus, l'installation d'une sonde Ntop au coeur du réseau est nécessaire pour visualiser facilement les machines qui utilisent le réseau. C'est juste visuel mais très pratique.

R7 : ATTAQUES SUR LES PROTOCOLES

Nous allons proposer dans cette section les parades à prendre pour éviter les attaques sur certains protocoles : ARP, DHCP.

ARP-POISONING

La solution la plus immédiate consiste à saisir manuellement sur chaque poste la table de toutes les adresses physiques présentes sur le réseau local. Si elle est immédiate, cette solution est quasiment inapplicable compte tenu du nombre d'hôtes connectés au réseau local.

Une solution correcte consiste à mettre en place un serveur DHCP avec une liste «fermée» de correspondance entre adresses physiques (MAC) et IP. Relativement à la solution précédente, la liste exhaustive des adresses physiques est centralisée sur le serveur DHCP. On peut ensuite configurer la journalisation du service pour que toute requête DHCP relative à une adresse MAC inconnue génère un courrier vers l'administrateur système ou réseau. Pour cela, l'administrateur réseau peut utiliser sous Windows l'outil DHCPCMD pour configurer le serveur dhcp à la ligne de commande.

Cette deuxième solution convient également pour pallier les attaques sur le serveur DHCP.

DNS ID SPOOFING ET DNS CACHE POISONING

Pour éviter ces diverses attaques sur le serveur DNS, il faut :

§ configurer votre serveur DNS pour qu'il ne résolve directement que les noms de machine du réseau sur lequel il a autorité.

§ autoriser seulement des machines internes à demander la résolution de noms de domaines distants.

§ mettre à jour ou changer les logiciels assurant le service DNS pour qu'ils vous protègent de ces diverses attaques.

R8 : VEILLE SECURITE

Face aux multiples failles de sécurité des systèmes d'information et des réseaux informatiques en particulier, seule la veille permet de répondre aux objectifs de continuité de service. Pour assurer cette veille, les responsables sécurité et veille doivent surveiller l'apparition de nouvelles vulnérabilités et alerter sur les menaces ciblant les systèmes et réseaux informatiques.

La veille sécurité permet aux RSSI et à leurs équipes d'anticiper les incidents de sécurité : intrusion, attaque virale, DoS, ...

La DARPA (Defense Advanced Research Projects Agency) a décidé la mise en place en 1988, à la suite d'une attaque sur Internet, des centres d'alerte et de réaction aux attaques informatiques. Ces CERT proposent une base de données sur les alertes de sécurité. Ces bases publiques sont accessibles à travers le site internet du CERT/CC www.cert.org.

En France, plusieurs CSIRT ont été crées :

§ le CERTA est le CERT dédié au secteur de l'administration française ;

§ le CERT-IST est le CERT dédié au secteur de l'Industrie, des Services et du Tertiaire (IST) ;

§ le CERT-RENATER est le CERT dédié à la communauté des membres du GIP RENATER (Réseau National de télécommunications pour la Technologie, l'Enseignement et la Recherche).

Enfin, l'entreprise peut acquérir la version commerciale du logiciel d'analyse des vulnérabilités connues Nessus dont l'installation, la configuration ainsi que l'utilisation ont été effectués dans le présent document.

R9 : AUDITS INTERNES DE SECURITE

Des audits internes de sécurité doivent être réalisés de manière permanente et les recommandations intégrées à la politique de sécurité.

La politique de sécurité doit être ainsi animée par des personnes différentes de celles qui l'appliquent.

La séparation des responsabilités est essentielle pour l'application du cadre commun de la Sécurité. En effet, une personne ne doit pas se trouver à la fois en position de donneur d'ordre, de réalisateur et de contrôleur de bon achèvement. Cela permet d'éviter à ces personnes d'être en même temps juge et partie.