Guide de la sécurité des systèmes

Table des matières

Introduction

• La sécurité n’est pas un état, c’est une démarche permanente ⇒ définition d'une politique de sécurité
• La sécurité ne se limite pas à l'utilisation d'un outil (pare-feu, anti-virus, … )
• La sécurité à 100 % n’est pas possible : il n’y a pas de solution magique, juste un ensemble de pratiques à perfectionner.
• La sécurité n'est possible sans maîtrise des fondamentaux du réseau et de l'informatique
  

La sécurite

Il y a 3 (+1) éléments fondamentaux :

• Disponibilité : garantie que ces éléments considérés sont accessibles au moment voulu par les personnes autorisées.
• Intégrité : garantie que les éléments considérés sont exacts et complets.
• Confidentialité : garantie que seules les personnes autorisées ont accès aux éléments considérés.
• Traçabilité (ou « Preuve ») : garantie que les accès et tentatives d'accès aux éléments considérés sont tracés et que ces traces sont conservées et exploitables.
  

En anglais, on parle de CIA (Confidentiuality, Integrity, Avalaibility).

Les principes de base d'Eric Cole

1. connaissez votre système : c'est la base !! (Quid d'une machine avec les ports 80, 443, 22 ouverts ?)
2. principe de moindre privilège : fournir le minimum de privilèges pour exécuter une tâche
3. défense en profondeur : plusieurs niveaux de défense basés sur des principes différents
4. prévention importante mais détection (rapide) aussi importante
   

Les menaces

• Les utilisateurs du système
• Des personnes malveillantes
• Un programme malveillant
• Un sinistre
  

La notion de risque

• humains : maladresse, inconscience, malveillance, ingénierie sociale, espionnage
• techniques : liés au matériel, au logiciel, à l'environnement
  

Pour élargir

La quête de la sécurité dans une installation présente de nombreuses analogies avec la conduite de la guerre et la stratégie. Les curieux pourront lire :

• L'art de la guerre – Sun-Tzu
• De la guerre – Karl von Clausewitz
• Le Prince - Nicholas Machiavel
  

Des agressions de plus en plus élaborées

Les techniques mises en œuvre sont de plus en plus sophistiquées et mettent en œuvre des techniques de plus en plus complexes (cryptographie, virus polymorphiques). On assiste à une forte recrudescence des attaques de vers (Blaster, …, des spywares et du phishing. Les attaques sur DNS sont de plus en plus nombreuses car elles peuvent rapporter beaucoup au plan financier.

Il y a peu, on estimait que la durée de vie d’un poste de travail Windows XP SP1 non patché et connecté directement à l’internet était d’une vingtaine de minutes environ, durée supérieure à la durée du téléchargement d’un patch …
Les réseaux de machines zombies ou botnet peuvent comporter plusieurs centaines de milliers de machines à disposition d'une personne pour envoyer du spam ou commettre une attaque en déni de service. Des pirates iraniens ont réussi il y a peu de temps à créer de faux certificats google pour espionner les comptes de messagerie.

Les programmes malveillants

• le virus : programme qui se duplique sur d'autres machines
• le ver : programme qui se duplique lui-même par le réseau
• le cheval de Troie (Trojan) : logiciel nuisible déguisé en programme légitime
• la porte dérobée (Backdoor) : accès frauduleux caché
• le logiciel espion (spyware) : collecte illégale d'informations
• l'enregistreur de frappe (keylogger)
• l'exploit : permet d'exploiter une faille de sécurité pour obtenir une élévation des privilèges
• le rootkit : permet de mettre en place une porte dérobée
  

Les types d'agressions

Il en existe plusieurs types :

• agression opportuniste (scripts-kiddies) : outils standards et technicité limitée
• agression ciblée : discrète et efficace. Recherche d'information ciblée sur des maillons faibles. Elle peut être interne ou externe.

Les techniques d'agressions

• Blocage des entrées (surcharge par des DOS)
• SPAM (utilisation du relais de messagerie)
• Intrusion dans un système (récupération de mots de passe, application ancienne ou mal configurée, …
• Ecoute du réseau avec des renifleurs (Ethereal, Wireshark)
• Attaques par rebond en prenant d’abord la main sur le routeur/pare-feu d’entrée pour ensuite attaquer le réseau intérieur (attaque par rebond)
• podsurfing avec une clé USB (autorun et U3)
• recherches des trous de sécurité
• utilisation de scanners permettant de détecter les adresses IP et les ports utilisés (NMAP) -
• certains permettent de détecter l’OS grâce aux numéros de séquence TCP
• connexion aux serveurs applicatifs pour récupérer le numéro de version et les vulnérabilités connues (sendmail, bind, apache…
• mise en place d'un rootkit
• Et enfin attaque par débordement de buffer avec un “exploit” spécifique pour obtenir des privilèges root
  

Les intrusions

Modes de contrôle d’un système :

• ingénierie sociale (pratique relationnelle)
• mot de passe récupéré (crackage ou reniflage) ou prêté
• Installation avec paramètres par défaut non adaptés
• application mal installée ou configurée
• application trop ancienne
  

Les mises hors de service ou déni de service (DOS)

On les appelle encore attaques par saturation. Elles consistent à surcharger le système pour le rendre incapable de fonctionner ou trop lent, à remplir les journaux (rendre la recherche plus complexe) ou une partition système, ou encore multiplier le nombre de connexions (x10, x100 ou plus )

Ces attaques; peuvent être émises depuis une seule source ou mutualisée avec amplification (facteur 1:1000) très difficile à contrer (DDOS)? Elles peuvent être de source falsifiée ou utiliser des intermédiaires (rebonds) : http://www.certa.ssi.gouv.fr/site/CERTA-2002-INF-002/index.html

Voici quelques exemples :

• (win)nuke, ping of death, land, teardrop, jolt, pepsi, bo(i)nk, nestea(2), naptha (et dérivés), 3wahas, stream, fraggle, ou une combinaison de plusieurs « techniques » (targa/rape)
• fork bomb
• en TCP : SYN Flood
• avec ICMP : echo et echo reply
• avec UDP : fausses connexions TCP (SYN sans ACK) → saturation des buffers → explosion de la pile
  

Vulnérabilités

Les vulnérabilités peuvent provenir de plusieurs causes :

• installation des OS et des applicatifs avec les paramètres par défaut
• Comptes utilisateurs sans mot de passe ou avec mots de passe trop faibles
• Sauvegardes inexistantes ou incomplètes
• Nombre trop élevé de port ouverts
• Aucun filtrage de paquets
• Journalisation des évenements inexistante ou incomplète
• Programmes CGI vulnérables
  

Voici quelques exemples pour Unix

• Débordements de buffers dans les RPC (Remote Procedure Call)
• Vulnérabilités dans Sendmail
• faiblesses BIND
• Commandes R (Rexec, rsh, rlogin …
• LPD (démon d’impression)
• démon de montage
• Chaines SNMP par défaut
  

Stratégie

L'infrastructure

Un principe de base : n'autoriser que ce qui est strictement indispensable et n'exposer que ce qui est strictement nécessaire.
Il faut définir strictement les différents périmètres ou zones (partie publique, partie privée, … avec les règles adaptées. La topologie est importante : la partie publique devra être limitée au maximum.

L'infrastructure DNS

Un serveur DNS ne doit renseigner que le minimum utile. Il faut penser à la mise en place d’ACL pour les requêtes et le transfert de zones.
Un DNS maître externe : dangereux ! On peut éventuellement mettre deux DNS : un serveur DNS interne et un DNS externe
Attention aux empoisonnements du cache DNS !

L'infrastructure DHCP

Le DHCP : service très sensible et facile à rendre inopérant: un script très simple permet d'épuiser tous les baux disponibles. Il devient alors très simple de mettre en place son propre serveur DHCP.
On peut alors riposter de la sorte HCP distribuant des baux uniquement aux adresses MAC répertoriées (facile sous Unix).

L'infrastructure

Attention à la couche liaison : elle est peu sécurisée et facile à mettre en défaut !
L'usurpation d'adresse MAC (ARP Spoofing) est facile à mettre en œuvre. Un switch (commutateur) se comporte comme un simple HUB (concentrateur) si on épuise sa table d'adresses MAC au moyen d'une ARP storm (outils arp-sk, arpspoof, … ) .
L'utilisation de VLAN par ports pour séparer les réseaux. En effet, les VLAN par adresse MAC ou par adresse IP sont faciles à mettre en défaut.

Les routeurs sont également sensibles.
Il faut faire attention aux mots de passe, ainsi qu' aux protocoles utilisés: RIP V1 ne dispose d'aucun élément de sécurité par exemple.
Désactiver les protocoles d'accès non sécurisés tels que telnet au profit de SSH.

La stratégie de protection

La défense en profondeur. Il s'agit de mettre en oeuvre plusieurs lignes de défense adaptées opérant de façon différente (OS (MacOs, OpenBSD)/processeur différents) en séparant les tâches.
Que se passe-t-il si la première ligne (de défense) tombe ?
Il faut tenir compte de l’architecture OSI : un pare-feu est opérationnel aux niveaux 3 et 4 mais pas au niveau applicatif. Voir alors les proxys inverses ou de solutions pouvant remonter jusqu'au niveau 7.

Une machine exposée ne doit assurer qu’une seule fonction pour limiter les dégâts en cas de compromission.
Disposer d'une architecture ad-hoc : DMZ ,filtrage à plusieurs niveaux (plusieurs pare-feu)/
Plusieurs sous-réseaux (séparation niveaux OSI 3/4) avec filtrage et ACL sur les routeurs.

La stratégie de la virtualisation

Un petit point sur la virtualisation : Elle est amenée à jouer un rôle de plus en plus important pour des raisons évidentes. En revanche, les hôtes hébergeant les machines virtuelles doivent être considérés avec un soin tout particulier sous peine de voir compromises l’ensemble des machines virtuelles de l'hôte.

La stratégie des hôtes bastions

Un bastion est une machine exposée dans la DMZ. Elle doit donc être configurée en conséquence :

• Machine dégraissée : uniquement les applicatifs et services nécessaires
• noyau minimal recompilé sans modules (Linux)
• pas de compilateur installé : il permet de créer un rootkit
  

Sous Linux, possibilité d’installer une distribution minimale et sécurisée (Trustix, Debian ou Gentoo…

Accès Physique

Attention aux paramètres de démarrage de la machine. Elle doit démarrer sur le premier disque uniquement et non pas sur CD, USB ou disquette : sinon il suffit d’un Live-CD Linux (Knoppix, System Rescue CD … pour démarrer une machine Linux ou même Windows et d’accéder aux partitions (NTFS, Linux….
Le BIOS doit être protégé par mot de passe pour la raison précédente.

Sur une machine Linux, le démarrage doit imposer un mot de passe pour passer des paramètres au noyau (configurer lilo ou grub en conséquence)
A noter que sois Linux : linux init single permet de démarrer en run-level 1 donc de se connecter en root sans saisie de mot de passe depuis le chargeur d'amorçage.

Les PC portables

Ce type de matériel implique des modes opératoires spécifiques : en cas de vol, le disque dur est lisible par tout le monde.

Il est donc nécessaire de mettre en place des systèmes de fichiers cryptés :

• Windows : utiliser EFS ou TrueCrypt (sur Linux aussi)
• Linux/Unix : utiliser crypto-loop ou dmcrypt avec des algorithmes de cryptage sûrs (BlowFish, …
  

Cette stratégie est également valable pour les clés USB.
Les paranoïaques peuvent également mettre en place des partitions de swap cryptées.

Le réseau sans fil

Il peut poser de sérieux problèmes de sécurité s'il est mal configuré.

Quelques pistes :

• Ne pas diffuser les SSID
• Changer les noms de SSID par défaut (linksys, …
• Mettre en place le cryptage ( WEP résiste 10 mn à un outil comme aircrack (airsnort, …, privilégier le WPA2, plus robuste avec des clés longues)
• Utiliser la norme 802.1x avec un serveur WPA/Radius ce qui permet de bloquer un port physique dans de bonnes conditions de sécurité
• Utiliser un contrôleur sans fil gérant plusieurs SSID et les VLAN : solutions d'authentification différenciées ( Une faible pour les visiteurs, Une forte 802.1x et WPA pour les utilisateurs de l'entreprise)
  

Stratégie de mise à jour

Il peut être utile de s’abonner aux listes de diffusion de l’éditeur et des organismes de sécurité (CERT) et de lire (!!!) les mises en gardes diffusées
Utiliser urpmi pour Mandriva, yum pour Redhat, apt-get/aptitude pour Debian/Ubuntu, emerge pour Gentoo
S’assurer de la fiabilité de la source d'un logiciel ou autre paquet.
Vérifier la signature des pièces téléchargées.
Vérifier la somme de contrôle MD5 (avec md5sum sous Linux ou les signatures de packages)

Récupérer les patches et mises à jour pour les systèmes Windows (Windows Update ou WSUS; Services packs et Correctifs)

Stratégies de mots de passe

Limiter le nombre de comptes privilégiés (root, administrateur)
Règle importante : on ne devrait donner un accès administrateur qu’aux personnes capables de réparer les dégâts qu’elles auront causé en mode administrateur !!!
N’accorder que les droits minimaux pour effectuer une tâche donnée (sudo sous Linux permet de donner l’autorisation d’effectuer certaines taches à des utilisateurs “ordinaires” : relancer Apache, …
Utiliser les shadow passwords beaucoup plus sécurisés que les mots de passe classiques.
Écrire une note concernant la création de mots de passe
Éviter le mots (craquage par dictionnaire)
Longueur efficace minimale : 8
Utiliser un alphabet varié avec caractère de ponctuation et chiffres, minuscule/majuscule.

Définir une stratégie de vieillissement de mots de passe avec PAM ou stratégie de mot de passe Windows.
Utiliser les outils de crackage (Crack, “John the Ripper”, L0Pht (Windows) ) pour évaluer la résistance des mots de passe.

Désactiver les services non utilisés

Le principe de base en sécurité : ne lancer que les services réellement utilisés. La plupart des distrib. Linux lancent au démarrage plus d’une vingtaine de services !!!!

Sous Linux :chkconfig, systemctl, update-rc.d ou rc-update.
Sous Windows : Gestionnaire de services.

Audit (loging)

La totalité des applications peut envoyer des informations dans les fichiers de log.
Attention à adapter une stratégie pour ne pas générer des volumes trop importants.
Nécessité de disposer d’outils pour exploiter ces logs : grep, script bash ou perl...

Le filtrage de paquets, mais attention au volume : le filtrage de paquets peut générer des volumes très importants : il est fortement recommandé que le répertoire /var soit stocké dans sa propre partition pour ne pas remplir la partition racine.
S’assurer par ailleurs du paramétrage de logrotate qui permet de faire “tourner” et compresser les fichiers de log. Les conserver 52 semaines comme le demande la loi.
Il est également recommandé d’envoyer les logs sur une machine dédiée pour les centraliser et éventuellement les graver sur DVD pour les archiver.
On pourra utiliser rsyslog syslog-ng

Attention à l’intégrité des logs : une des premières tâches d’un intrus qui aura réussi à pénétrer un système consistera à masquer ou effacer les traces de ses méfaits en effaçant ou épurant les logs.
On peut positionner l’attribut Append avec la commande chattr pour autoriser seulement l’ajout en fin de fichier



On peut générer des sommes de contrôle pour les fichiers sensibles (avec md5sum ou des outils comme tripwire).

La sécurité interne

Généralités : un processus Unix dispose d'un utilisateur (UID) et d'un groupe (GID), son accès aux objets système est tributaire de ces propriétés : un utilisateur “normal” ne pourra pas accéder à un répertoire s'il ne dispose pas des droits adaptés.
Mettre en place une stratégie de sécurité consiste à jouer sur les droits d'accès aux fichiers (RWX)

• 700 : limité au seul possesseur
• 777 : toute utilisation pour tout le monde
  

Les droits associés aux processus

• droits associés à l'utilisateur
• droits associés au programme lui-même
• généralement différents
• identiques si le bit Set-UID est positionné
• droits réels : celui qui lance le processus
• droits effectifs : propriétés du programme si le Set-UID est positionné
  

Les programmes Set-UID et Set-GID

De nombreuses tentatives d’intrusions proviennent de processus lancés à partir de programmes Set-UID.
Un fichier dont le bit Set-UID est positionné dispose des droits du possesseur du fichier et non de ses droits de simple utilisateur (/bin/passwd est possédé par root et est Set-UID par exemple)
Ces fichiers sont des parfaits candidats pour les pirates . La plus grande partie des intrusions provient des programmes SetUID.

Il suffit qu’un programme Set-UID récele un bug ou qu’on essaie de l’attaquer avec un débordement de buffer pour pouvoir lancer un processus avec les droits de root !!!
Recherche des fichiers Set-UID :



Il conviendra d'établir la liste des fichiers Set-UID du système et de détecter chaque jour les changements.
Une des sources de problèmes sont les utilisateurs et groupes dont les UID et GID ne sont pas dans /etc/passwd et /etc/group : il peuvent provenir d’archives tar externes au système.
Pour enlever les attributs SUID et SGID :



Pour info : valeur octale : 4000 (Set-UID) et 2000 (Set-GID).

Le Sticky Bit

Le bit collant permet de gérer les droits d'écriture d'un fichier (modification et suppression)
Sur un répertoire : interdit la suppression des fichiers qu'il contient à tout utilisateur autre que le propriétaire.
Sur un fichier : indique que le fichier doit rester en mémoire après son exécution (utilisé pou sh et vi à l'époque).
Flag : T sur les droits UNIX , valeur octale : 1000

L'attribut immuable

On peut également rendre immuables certains fichiers système importantes (ls, ps, cp , … : on ne pourra alors plus les changer, les renommer ni faire de liens sur eux avec la commande :

Seul root peut positionner ou enlever cet attribut.

Sécurité Interne

• consiste à “durcir” la configuration pour éviter les failles de sécurité
• application de droits restrictifs
• limitation des droits d'execution
• limiter le nombre de démons
  

Les outils

Bastille Linux : application permettant de “durcir “ un système Linux (RedHat, Debian) - Très formateur car sa configuration se fait à l’aide d’un script qui pose des questions très pertinentes.
lynis : application permettant de faire un audit de sécurité d'un système Linux et de faire des suggestions utiles quant à la sécurité.
Msec (Mandriva) : définit plusieurs niveaux de 1 (securité faible) à 5 (paranoiaque).

Unix : chroot

• Consiste à lancer un démon dans une cage “chroot” ne permettant pas à celui-ci d’accéder aux données extérieures ce qui limite les dégâts en cas de compromission.
• Il est en revanche nécessaire que la nouvelle arborescence comporte toutes les bibliothèques et répertoires nécessaires au fonctionnement du démon.
• On installe souvent bind, postfix ou les démons ftp en chroot
  

Unix : les démons et utilisateurs

De plus en plus les démons (serveurs et autres) sont conçus (si possible) pour fonctionner avec des utilisateurs spécifiques (apache, named, etc.) et non en tant que root ce qui limite les conséquences en cas de compromission du démon: l’utilisateur "normal" ne dispose que peu de droits de nuire.
Ainsi un seul démon Apache est lancé en tant que root, ce processus lance les processus Apache chargés de répondre aux requêtes Web avec un utilisateur "normal" appelés www-data ou httpd ou encore apache.

Les intrusions

La plus grande partie des intrusions dans les système Unix provient des programmes SetUID. On provoque un débordement de buffer (buffer overflow) avec des données calculées spécialement pour infecter la pile et obtenir une élévation de privilèges.
On remplace alors l’adresse de retour qui se trouve dans la pile par l’adresse d’un processus shell (/bin/sh) ou une copie SUID de /bin/sh cachée sur le système. Le shell est inséré dans le buffer. L’attaquant dispose alors d’un shell avec les droits root !!!

Scénario d'une attaque avec prise de contrôle

1. Scan des ports pour déterminer les ports ouverts (avec nmap)
2. Ouverture de session pour identifier les serveurs et leur N° de version
3. Recherche de l'exploit adapté à l'application, la version et à l'OS détecté
4. Lancement d'un exploit avec débordement de buffer pour obtenir des privilèges administrateur
5. Depuis cette session, mise en place d'un rootkit permettant mettre en place une backdoor.
   

--- Les débordements de buffers ---

Principe : mise en œuvre avec des données spécialement formatées pour écraser la pile (souvent dans les chaînes de format C : « %s %2d »)
Ces débordements de buffers sont fréquents dans les applications de type RPC (Portmapper, NFS, NIS, ...) ainsi que dans le serveur Ftp Wu-ftpd
Une attaque de type débordement de buffer est spécifique :

• à l’application (sendmail, apache) et à sa version
• au format des exécutables du système considéré (ELF pour Linux, BSD ou Windows)
• et bien sûr à l’architecture de la machine (X86, PowerPC, ...)
  

Une attaque pourra être efficace sur un processeur Intel mais pas sur un processeur PowerPC.
Pour protéger une infrastructure sensible, certains utilisent les solutions suivantes :

• OS OpenBSD (l’Unix réputé le plus sûr !)
• architecture non Intel (Alpha ou Motorola) car très peu de risques de débordement de buffers.
  

Il existe maintenant des mécanismes mise en œuvre dans le noyau Linux interdisant d'exécuter des données dans la pile (PAX).
Les processeurs modernes disposent d'un bit non exécutable (NX bit => paramétrage BIOS)

Il existe maintant des outils comme Metasploit pour forger (pour tests!) des outils d'exploit.
C'est un véritable environnement de développement permettant des forger des shellcodes adaptés à des cibles données. (Disponible dans Kali Linux)

Exemple :

Les Rootkits

Après avoir compromis un système, un intrus va essayer de garder une porte ouverte lui permettant de continuer à utiliser le système (backdoor)
Il installe des outils lui permettant de garder cette porte ouverte et de camoufler son intrusion. Le rootkit contient des versions spéciales des commandes de base (ls, ps, netstat, find, sshd, telnet, kill, killall, last, … modifiées pour ne pas faire apparaître la trace des données modifiées.
Par exemple, la commande netstat ne fera pas apparaitre une connexion distante avec la machine de l’attaquant !! Le démon sshd acceptera une session sans mot de passe avec un nom d’utilisateur particulier ou sur un port spécifique...

Les module Kernel (Loadable Kernel Modules)

Le kernel permet de charger dynamiquement des modules (insmod) permettant d’effectuer diverses actions des modules infectés peuvent avoir le même effet qu’un rootkit.

Les chevaux de Troie (Trojan)

Un cheval de Troie est un programme permettant d’obtenir le mot de passe administrateur. On le réalise facilement en shell Unix.
Ne jamais utiliser un PATH faisant appel à un chemin relatif ou faisant référence au répertoire courant :
PATH=.:/bin/:/usr/bin
Faire plusieurs fois <Entree> ou Ctrl-D avant une ouverture de session
Un cheval de Troie peut également déclencher des connexions réseaux sortantes qui ne seront par forcément détectée par les pare-feu.

Les Spyware (Windows principalement)

Ce sont des logiciels malicieux qui, profitant de faiblesses dans un navigateur, s'installent sur une machine et déclenchent des actions dangereuses (connexions sortantes) inventaires, et peuvent prendre la main sur une machine.
Ils sont de plus en plus répandus sur les machines Windows
On pourra utiliser des outils comme SpyBot ou Ad-Aware.

Les Pots à Miel (HoneyPots)

C’est un serveur installé dans la DMZ pour servir de leurre pour les intrus. Il permet à l’administrateur d’étudier les modes d’attaque.
Il peut contenir volontairement des failles de sécurités.

Les Pare-Feu Linux

Les pare-feu

Depuis le noyau 2.4 : Iptables : filtrage de paquets stateful : tient compte de la connexion TCP pour prendre des décisions plus pertinentes.
Attention : il est également recommandé d'effectuer du filtrage sortant permettant de bloquer les éventuels chevaux de Troie !


Exemple : accepte les connexions entrantes sur les ports www et ssh pour la destination 192.168.1.100


De nombreux outils existent qui permettent de simplifier la conceptions de fichiers de configuration de pare-feu qui peut être assez pénible :

• firehol : basé sur un langage de description
• firestarter : génère un script à partir de questions simples (X Windows)
• shorewall : dispose de préconfigurations (1 carte, 2 cartes, 2 cartes + DMZ)
• ferm : permet d'utiliser un langage de plus haut niveau qu'iptables
  

Les tests

Il est impératif de tester la configuration d’un pare-feu dans les conditions réelles.

nmap (Network Mapper) est le plus connu des scanners de ports. Il permet de :

• rechercher les adresses IP sur un réseau ainsi que les ports ouverts
• détermine l’OS utilisé (option -O), le filtrage de paquet utilisé et d’autres caractéristiques
• faire des scans furtif (-sS), lent (paranoid) ou avec leurres (decoy)
• il existe un front-end en mode graphique (nmapfe)
  

Il existe d’autres outils du même genre comme SendIp.
Un outil de test de firewall : Firewall Tester (Open Source)
Outil le plus réputé : nessus (nessus.org) permet de faire des tests de détection d'intrusion (détecte plus de 5600 faiblesses)

Les serveurs FTP Linux

Le protocole FTP est fréquement utilisé en raison de son efficacité et de sa simplicité.En revanche, il n’est absolument pas sécurisé (le mot de passe circule en clair)
FTP non-anonyme : fortement déconseillé . Utiliser le couple ssh/scp beaucoup plus sûr, ou SFTP.
FTP anonyme : utilisé pour le téléchargement.

Les solutions :

• WU-FTPD : à éviter -
• vsFTPD : très sécurisé et très simple
• ProFTPD : sécurise mais un peu complexe
  

Les serveurs de messagerie

Les différents serveurs SMTP :

• Sendmail : passé chargé en terme de sécurité et complexe à configure mais des progrès notables ont été effectués.
• Postfix : modulaire, peu de trous de sécurité.
• Exim : moins répandu
  

Il est fortement recommandé d'installer un relais de messagerie dans la DMZ et de laisser le serveur principal dans le réseau interne.

Une couche sécurisée est maintenant fortement conseillée (SSL/TLS) pour le SMTP ainsi que pour les
serveurs POP (pop3s) et IMAP (imaps). Cette couche s'installe sans difficulté sur la quasi totalité des serveurs SMTP et POP/IMAP. Le serveur de messagerie doit de plus en plus intégrer des outils d'analyse anti-virus et anti-spam.

Serveur SSH

Service stratégique sur une machine Unix !!
Suelques points concernant le fichier sshd_config :

• ListenAddress 192.168.0.1 # écoute sur 1 seule IP
• PermitRootLogin no # important
• Port 666 # changement de port (ou régler la redirection de port du routeur de 666 sur 22)
• PermitEmptyPasswords no
• AllowUsers adrien
• AllowGroups wheel admin
• Protocole 2 # plus sur !
  

Il est également possible de désactiver l'authentification par mot de passe et de n'utiliser que les clés publiques (avec ssh-keygen) ! Il est recommandé d'utiliser une passphrase avec les clés publiques (avec ssh-agent et ssh-add).

Des utilitaires comme denyhosts ou fail2ban permettent le blocage d'adresses IP à l'origine d'attaques SSH répétées.
Contrôler régulièrement le fichier /var/log/auth.log (peut changer de nom).
Utiliser la commande suivante pour vérifier les connexions sur la machine :

Les proxy

Attention aux ACL pour éviter que le proxy soit utilisé pour commettre des actes délictueux : Accès réservé au réseau local...). Mettre en place de l'authentification ci-nécessaire et utiliser des outils d'analyse de logs (calamaris, prostat, webalizer) pour obtenir des statistiques.

Les outils de l'administrateur

• Nessus : outil de test de hôtes – fonctionne en mode graphique (Linux ou Windows)
• Wireshark : analyseur de protocole (Linux/Win.)
• Nmap : scanner de ports (Linux)
• OpenSsh/ssh/PuTTY : serveur/clients Secure Shell
• Tcpdump : renifleur réseau
• Nc : Network Cat : permet de rediriger un commande sur le reseau : nc host 110
• Tripwire: Host IDS – permet de vérifier l’état de fichiers à partir de calcul de sommes md5
• Snort : Network Intrusion Detection System (GPL) – Linux – permet à partir de plugins de détecter des motifs arrivant sur les interfaces réseau
• ntop, cacti, munin, rrdtools, zabbix : les outils de statistiques réseau (volumétrie) nécessaires pour mettre en évidence les pics
• Kali Linux : Distribution Live CD (Installable) orientée sur la sécurité (incorpore beaucoup d'outils)
• Airsnort : renifleur réseau Wifi
• Et bien sûr netstat, traceroute, arpwatch, ...
  

Après une intrusion

• Débrancher le câble réseau !
• Sauvegarder le disque ou la partition (depuis un Live CD pour conserver les traces).
• Relever les preuves : utiliser un outil du genre Tripwire pour vérifier la compromission des fichiers.
• Examiner les logs : /var/log/messages, syslog, wtmp (last)
• Il pourra être utile de monter la partition sauvegardée en loopback en lecture seule pour ne rien détruire.
• Examiner éventuellement les fichiers core avec la commande strings pour extraire les chaîne permettant de donner des informations
• Audit post-mortem avec des outils spécifiques comme le Coroner Toolkit
• cf : http://www.certa.ssi.gouv.fr/site/CERTA-2002-INF-002/index.html
  

Voilà c'est terminé ! Ouf !