Linux et la sécurité

Denis Ducamp / Hervé Schauer Consultants

Avril 2000

Reproduction strictement interdite

1. Introduction

Cette présentation va aborder quatre points :

Linux et la sécurité
La sécurité du système
La sécurité du noyau Linux 2.2
La sécurité réseau

2. Linux et la sécurité

La sécurité de Linux
Les applications de Linux pour la sécurité

2.1 La sécurité de Linux

Sécurité au niveau du système
- Tous les mécanismes de sécurité des Unix nouveaux
Sécurité au niveau du réseau
- Pile IP de qualité
- Rapidité de parution des correctifs
- Possibilité d'utiliser des logiciels connus
  (Postfix, Bind, Apache, tcp_wrapper, etc.)
Sécurité de l'administration et de l'exploitation
- Administration sécurisée distante (SSH, SSF)
- Surveillance du système, scellement des fichiers (Tripwire)
- Gestion et centralisation simple de la journalisation
Système fiable qui permet la confiance

2.2 Les applications de Linux pour la sécurité

Pour la sécurité du courrier électronique
Pour les passerelles de sécurité
Pour les consultants en sécurité
Pour les services sécurité (des entreprises)
Pour les administrateurs
Pour les réseaux bureautiques
Pour des postes de travail sécurisés

2.3 Application : la sécurité du courrier électronique

Serveurs de mail sous Linux
- Sendmail ( www.sendmail.org)
- Postfix : serveur de messagerie sécurisée ( www.postfix.org)
- Serveur POP3/APOP ou IMAP
Clients sous Linux
- Gros volume (ex : centres d'appel)
- Traitement automatique : procmail et/ou scripts en perl
- Mutt ( www.mutt.org)
  (Avec intégration de PGP www.pgpi.com)

2.4 Application : les passerelles de sécurité

Système de détection d'intrusion
- libres
  - BRO
  - SHADOW
  - SNORT
- commerciaux
  - NFR
Supervision de réseau
- TRINUX
  - Mini distribution linux disposant d'outils de sécurité et de surveillance du réseau

2.5 Application : les consultants en sécurité

Fiabilité, souplesse et configuration
- Aucun problème bloquant
Sécurité des données sur le disque
Sécurité du courrier électronique (gros volume)
- Jamais de perte de courrier
Pour les tests d'intrusion
- Changement d'adresse IP sans réamorçage
- Ecoute du réseau avec des "sniffer"
- Nombreux programmes d'exploitation disponibles
- Facilité de création de datagrammes IP
  en C (libnet) ou en Perl (netrawip)
Pour accélérer les audits
- Pas de clicodrome superflux
Pour l'indépendance

2.6 Application : les services sécurité (des entreprises)

Même raisons que les consultants
- Le service sécurité doit être le plus libre possible
Gérer quotidiennement la journalisation
- Développer ses propres scripts
Détecter les attaques et les dysfonctionnements
- Utilisation possible de shadow ( www.nswc.navy.mil/ISSEC/CID/)
Refaire ce que font les consultants
- Maintenir un niveau de sécurité élevé
Utilisation de nessus ( www.nessus.org)
- Faire régulièrement des tests de vulnérabilités

2.7 Application : les administrateurs

Poste d'administration sécurisé
L'administrateur peut :
- Sécuriser (vraiment) une machine
- Automatiser de nombreuses tâches (mise à jour, ...)
- Gérer un grand parc de machines
  en toute sécurité et à distance : SSH ou SSF
  ( www.ssh.org et www.in2p3.fr/secur/ssf/)
Laissez aux administrateurs la possibilité d'utiliser Linux !
- Même pour gérer un parc de machines sous d'autres systèmes

2.8 Application : les réseaux bureautiques

SAMBA ( www.samba.org)
- Serveur de fichiers
- Serveur d'impression
Très bonne intégration
Serveur sécurisé et fiable
Très bonnes performances
- Au delà de 12 clients, il est préférable d'utiliser Linux
- Haute disponibilité (disques RAID)
Administration légère à distance
- Pas de réamorçage intempestif
But : remplacer les PDC et BDC
- (PDC et BDC : contrôleurs principaux et secondaires de domaines Windows NT)

2.9 Application : des postes de travail sécurisés

Linux peut être utilisé sur les postes de travail
- Un VRAI filtre IP par poste
Sur les postes de développement
- Sécurité et centralisation des sources (CVS + SSH)
Utilisation possible de PAM
- PAM : Pluggable Authentication Module
Peu de problèmes de virus
Bonne séparation utilisateur / administrateur

3. La sécurité du système

Identification / Authentification
PAM (Pluggable Authentication Modules)
Droits d'accès aux ressources
Surveillance et journalisation

3.1 Identification / Authentification

La liste des utilisateurs du système est généralement dans le fichier /etc/passwd accessible en lecture à tous les utilisateurs.
Le mot de passe chiffré est rangé dans le fichier /etc/shadow
Le fichier /etc/shadow ou son équivalent n'est pas accessible aux utilisateurs.
- Le mot de passe même chiffré n'est plus accessible à la lecture.
Le changement de mot de passe s'effectue par la commande passwd (yppasswd dans le cas de NIS) qui demande l'ancien mot de passe avant de demander deux fois le nouveau.

3.2 Identification / Authentification (suite et fin)

Le mot de passe n'existe qu'en version chiffrée avec un algorithme non réversible.
Le chiffrement du mot de passe peut utiliser différents algorithmes :
- DES (Data Encryption Standard) modifié avec une graine de 2 caractères et 25 iterations.
  - les mots de passe sont limités à 8 caractères.
- MD5 (Message Digest 5) avec une graine de 2 à 8 caractères et 32 itérations.
Durant la vérification du mot de passe, la comparaison s'effectue toujours sur le mot de passe chiffré.

3.3 PAM (Pluggable Authentication Modules)

Historiquement, l'authentification des utilisateurs sous Unix se basait sur la saisie d'un mot de passe et sa vérification à partir du fichier /etc/passwd .
A chaque amélioration de ce schéma (/etc/shadow , One-Time-Passwords, etc.) tous les programmes (login, ftpd...) devaient être réécrits pour supporter les nouvelles fonctionnalités.
PAM se veut un mécanisme flexible d'authentification des utilisateurs.
Les programmes supportant PAM doivent pouvoir se lier dynamiquement à des modules chargés d'effectuer l'authentification.
L'ordre d'attachement des modules et leurs configurations sont à la charge de l'administrateur système qui gère cela de façon centralisée.
PAM est défini par l'OpenGroup dans XSSO
OSF-RFC 86.0 V. Samar, R. Schemers, "Unified Login with Pluggable Authentication Modules (PAM)", Oct 1995
- disponibles en HTML : < http://www.opengroup.org/onlinepubs/8329799/>
- ou payant sous tout autre format : < http://www.opengroup.org/public/pubs/catalog/p702.htm>

3.4 PAM : Configuration

Chaque application PAM doit posséder un fichier de configuration dans le répertoire /etc/pam.d . Chacun de ces fichiers est composé de 4 colonnes :
- type de module :
  - auth : authentification de l'utilisateur (Unix, SMB, LDAP...)
  - account : gestion des utilisateurs (ex : restrictions horaires)
  - session : tâches à effectuer en début et fin de chaque session
    ex : montage de répertoires, contrôle des ressources
  - password : mise à jour du jeton d'authentification de l'utilisateur
- contrôle de réussite :
  - required : la réussite d'au moins un des modules required est nécessaire
  - requisite : la réussite de tous les modules requisite est nécessaire
  - sufficient : la réussite d'un seul module sufficient est suffisant
  - optional : la réussite d'au moins un des modules required est nécessaire si aucun autre n'a réussi
- chemin du module, en général dans /usr/lib/security .
- arguments optionnels.
Le fichier /etc/pam.d/other fournit les configurations par défaut pour tout type de module non spécifié dans le fichier de configuration de l'application.

3.5 PAM : Quelques modules intéressants

pam_cracklib : ce module utilise la bibliothèque cracklib pour vérifier la solidité d'un nouveau mot de passe. Il peut également vérifier que le nouveau mot de passe n'est pas construit à partir de l'ancien.
pam_limits : ce module permet de limiter les ressources accessibles à un utilisateur et/ou à un groupe comme le nombre de processus simultanés et leurs temps CPU, le nombre de fichiers ouverts simultanés et leurs tailles, le nombre de connexions simultanées, etc.
La configuration se fait via le fichier /etc/security/limits.conf
pam_rootok : permet à root l'accès à un service sans avoir à rentrer de mot de passe. A n'utiliser qu'avec chfn ou chsh, surtout pas avec login.
pam_time : permet de limiter les horaires d'accès. La configuration se fait via le fichier /etc/security/time.conf
pam_wheel : ne permet l'accès au compte root qu'aux seuls membres du groupe wheel. A n'utiliser qu'avec su.
pam_cap : ce module permet de forcer l'ensemble des privilèges accordés à un utilisateur.

3.6 Droits d'accès aux ressources

Sur un système Unix, l'utilisateur possède :
- un login,
- un UID : numéro d'identification de l'utilisateur (compris entre 0 et 65535),
- un GID principal : numéro d'identification du groupe (aussi sur 16 bits).
- zéro, un ou plusieurs GID secondaires : numéros d'identification de groupe
Tout utilisateur d'UID 0 (zéro) est considéré comme administrateur et possède un accès sans restriction à l'ensemble du système. Les autres utilisateurs sont astreints aux contrôles d'accès.
La définition des droits d'accès pour un utilisateur repose essentiellement sur son UID et ses GID.
Il est possible de changer de groupe principal par la commande newgrp
Il est possible de changer d'identité par la commande su

3.7 Droits d'accès aux ressources : permissions des fichiers

Les permissions permettent de contrôler l'accès aux fichiers
Les permissions sont composées :
- un propriétaire
- un groupe
- un type d'objet
- les droits d'accès au propriétaire
- les droits d'accès au groupe
- les droits d'accès aux autres
un fichier peut être de type normal (-), répertoire (d), bloc (b), caractère (c), tube nommé (p), socket (s) ou lien symbolique (l)
les droits d'accès sont composés de 3 bits : lecture (r), écriture (w), exécution (x).
Un quatrième bit peut être présent : s pour l'utilisateur et le groupe, t pour les autres.

3.8 Surveillance et journalisation

La surveillance :
- comptabilité (accounting)
- audit : en cours de développement
La journalisation (logging)

3.9 La comptabilité

Enregistrement automatique par le noyau des ressources utilisées par chaque processus lors de leurs terminaisons :
- date de création
- utilisateur propriétaire
- nom de la commande
- utilisation de la mémoire
- terminal contrôlé
- temps processeur utilisé
- nombre d'entrées/sorties réalisées

3.10 La comptabilité : les utilitaires

Les utilitaires nécessaires à l'utilisation des données de comptabilités sont ceux édités par GNU < www.gnu.org> : acct-6.3.2.tar.gz
Cette archive renferme entre autres les utilitaires suivants :
- accton : active et désactive la comptabilité
- lastcomm : affiche des informations à propos des dernières commandes
- sa : résume les informations de comptabilité

3.11 La comptabilité : mise en route

Pré-requis : le support noyau doit être activé
- (sélectionner l'option "BSD Process Accounting" dans le menu "General setup")
La comptabilité est activée par la commande accton /var/account/pacct
Le journal doit exister avant l'appel à cette commande,
- Il peut être préférable de restreindre les droits d'accès au journal.
Le comportement de la comptabilité peut être modifié via l'entrée /proc/sys/kernel/acct qui contient 3 entrées :
- limite basse : espace libre nécessaire pour que la comptabilité reste active.
- limite haute : espace libre nécessaire pour que la comptabilité se réactive.
- fréquence : temps en secondes entre deux vérifications de l'espace libre.

3.12 La comptabilité : les statistiques

Les deux commandes suivantes permettent de synthétiser les données :
- sa : totalise pour chacune des commandes
  - Peut appliquer différents ordres de tris (entrées/sorties, temps processeurs et nombres d'appels).
  - Peut également totaliser les temps processeurs pour chacun des utilisateurs.
- lastcomm : affiche les dernières commandes exécutées
  - peut limiter l'affichage à un nom de commande, un nom d'utilisateur, un nom de terminal ou toute combinaison de plusieurs de ces trois précédents éléments.
La commande dump-acct /var/account/pacct exporte au format texte le contenu du fichier de comptabilité.
- Il est ainsi possible de réaliser de façon simple ses propres statistiques avec des languages comme awk et perl.

3.13 La journalisation

La journalisation est l'enregistrement des événements des applications via un démon central : syslogd
syslogd est configuré via le fichier /etc/syslogd.conf par la définition de niveaux, de services et de destinations.
Remarques :
- il est important que tous les événements soient enregistrés, vérifier la présence d'une ligne analogue dans le fichier /etc/syslogd.conf :
  *.debug /var/log/full-log
- les journaux doivent être tournés de façon périodique, les plus anciens étant effacés, afin que la journalisation ne soit en aucun cas interrompue
- afin de pouvoir confronter les journaux de plusieurs systèmes, il est nécessaire que leurs horloges soient synchronisées (NTP).
Exception : les événements du noyau son récupérés par klogd et envoyés à syslogd

4. La sécurité du noyau Linux 2.2

Les privilèges (capabilities)
Les modules
Chiffrement de systèmes de fichiers

4.1 Les privilèges (capabilities)

Définition
Les privilèges linux
Les privilèges des processus
Gestion des processus
Exemples de processus
Les privilèges des fichiers exécutables
Exemples de fichiers exécutables

4.2 Les privilèges : définition

Sur un système Unix classique, le compte root (UID égal à 0) possède tous les droits.
- Il peut ainsi lire tous les fichiers et tuer tous les processus.
Si un programme a besoin d'un privilège alors le processus devra avoir l'identité de root.
Par exemple un programme de sauvegarde n'a besoin que de pouvoir lire tous les fichiers.
- En s'exécutant en tant que root, il obtient le contrôle total du système et peut donc tuer tous les processus.
Les privilèges (capabilities) sont le partitionnement des privilèges du compte root (UID = 0) en droits unitaires.
- Il est ainsi possible d'allouer à des processus les seuls droits dont ils ont besoin.

4.3 Les privilèges : Linux

Le système de privilèges utilisé est celui défini par le draft POSIX 1003.1e "POSIX capabilities"
Actuellement seuls les processus sont associés aux privilèges.
- Deux implémentations sont en cours de réalisation pour gérer les privilèges au niveau des fichiers exécutables.
Chaque processus possède trois ensembles de privilèges :
- permitted(P) : les privilèges que le processus courant possède
- effective(E) : les privilèges que le processus courant peut exécuter
- inheritable(I) : les privilèges qui seront hérités par un processus fils

4.4 Les privilèges : les processus

L'implémentation du noyau 2.2 ne fait aucune référence à l'UID d'un processus pour savoir quels sont ses droits, seul l'ensemble de ses privilèges effectifs (E) est consulté.
Sur un système Unix classique les processus appartenant à root possèdent tous les privilèges, les autres processus n'en possèdent aucun.
Le privilège CAP_SETPCAP permet de changer les privilèges d'autres processus.
- Cette fonctionnalité n'existant pas sur un système classique, ce privilège n'est donné à aucun processus sous Linux 2.2 .
- Afin d'avoir un système fonctionnel à base de privilèges il est nécessaire de modifier deux lignes dans les sources du noyau pour que les processus appartenant à root acquièrent ce privilège (voir FAQ < ftp://ftp.guardian.no/pub/free/linux/capabilities/>).
Il est possible depuis la version 2.2.11 d'utiliser le fichier /proc/sys/kernel/cap-bound pour consulter l'ensemble des privilèges du système.
- Il est possible de supprimer des privilèges du système qui n'ont pas ou plus de raison d'être :
  CAP_NET_ADMIN , CAP_NET_RAW , CAP_SYS_MODULE , CAP_SYS_CHROOT
- L'utilitaire lcap disponible sur le site <http://pweb.netcom.com/~spoon/lcap/> permet de supprimer aisément des privilèges du système.

4.5 Les privilèges : gestion des processus

Les deux utilitaires à connaître sont :
- execcap <caps> <command-path> command-args...
  permet d'exécuter un programme avec des privilèges réduits
- sucap <user> <group> <caps> <command-path> command-args...
  permet d'exécuter un programme avec des privilèges réduits en spécifiant l'utilisateur et le groupe d'exécution.
Note : utiliser les utilitaires fournis avec une version 1.92 ou plus récente de la bibliothèque libcap (voir < ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.3/>)

4.6 Les privilèges : exemples de processus

Dans les exemples ci-dessous, le programme lancé est un serveur de tamagoshi qui ouvrira une socket sur un port privilégié (999).
- execcap cap_net_bind_service=eip /usr/local/bin/tama 999
  - Le processus est exécuté en tant que root mais ne possède que le droit d'ouvrir des ports privilégiés.
  - Si le programme possède une vulnérabilité, alors il pourra toujours être utilisé pour accéder à des fichiers appartenant à root.
- sucap tama tama cap_net_bind_service=eip /usr/local/bin/tama 999
  - Le processus est exécuté en tant que tama mais possède le privilège d'ouvrir des ports privilégiés.
  - Si le programme possède une vulnérabilité, alors il ne pourra être utilisé que pour accéder à des fichiers appartenant à tama.
  - Il existe des conditions dans lesquelles le programme aura commencé à être exécuté par le système alors que ses privilèges ne lui auront pas encore été accordés.

4.7 Les privilèges : les fichiers exécutables

Deux implémentations sont en cours de développement :
- fcaps : VFS layer patchs for capabilities
  - Permet d'accorder à tout fichier exécutable des privilèges.
  - L'ensemble de ces privilèges sont enregistrés au niveau du système de fichiers.
- elfcap : Elf capabilities hack < http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html>
  - Permet de retirer des privilèges à tout fichier exécutable au format elf.
  - L'ensemble de ces privilèges sont enregistrés au niveau de l'en-tête elf.

4.8 Les privilèges : exemples de fichiers exécutables

Les exemples ci-dessous comparent les deux solutions pour le programme ping qui nécessite le privilège CAP_NET_RAW pour ouvrir une socket en mode raw.
- fcaps :
  - ping n'a pas besoin d'être SUID root
  - Le processus a pour identité celle de l'utilisateur qui l'a lancé.
- elfcap
  - ping doit être SUID root
  - Le processus peut avoir pour identité celle de l'utilisateur qui l'a lancé si l'option adéquate a été utilisée lors de la définition des privilèges accordés; sinon il sera root.
Notes :
- le patch fcaps n'est pas suffisamment avancé pour être utilisé sur des systèmes en production : risques de corruptions de systèmes de fichiers.
  Les utilitaires nécessaires sont ceux fournis avec la libcap.
- le patch elfcap est suffisamment avancé pour être utilisé sur des systèmes en production.
  Les utilitaires nécessaires doivent être récupérés avec le patch.
  Ce système est actuellement limité aux fichiers au format elf.

4.9 Les modules

Définitions
Les risques
Avantages pour l'administrateur
Avantages pour les pirates

4.10 Les modules : définition

Un module est un morceau de code permettant d'ajouter des fonctionnalités au noyau : pilotes de périphériques matériels, protocoles réseaux, etc.
Il peut être chargé dynamiquement sans avoir besoin de recompiler le noyau ou de redémarrer le système.
Les modules sont exécutés dans l'espace mémoire du noyau :
- ils possèdent le contrôle total de la machine
- ils peuvent détourner ou créer un appel système

4.11 Les modules : les risques

Les modules ne rentrent pas en jeu dans la sécurité d'un système
Les modules possèdent le contrôle total de la machine et peuvent :
- permettre aux administrateurs d'améliorer la sécurité du système
- permettre aux pirates d'affaiblir la sécurité du système.

4.12 Les modules : avantages pour l'administrateur

Mettre à jour un pilote sans recompiler le noyau ni redémarrer le système.
Détourner certains appels systèmes pour surveiller l'activité du système :
- rediriger ou journaliser les accès à certains fichiers
- journaliser les ajouts et les suppressions de modules;
  fonctions pouvant être soumises à l'authentification préalable de l'utilisateur.

4.13 Les modules : avantages pour les pirates

Prendre le contrôle total de la machine en détournant des appels systèmes :
- modifier la configuration apparente de la machine : mode promiscuous
- cacher des fichiers :
  rendre invisible les fichiers commençant par un mot clé
- filtrer le contenu d'un fichier :
  ôter des journaux, les lignes contenant l'adresse IP du pirate
- détourner les demandes de changement d'identité :
  un compte utilisateur donné peut devenir administrateur
- sortir d'un environnement restreint (chroot)
- cacher un processus :
  rendre invisible les processus commençant par un mot clé
- rediriger l'exécution de programmes :
  installer des portes dérobées sans modifier les programmes originaux

4.14 Les modules : références

"(nearly) Complete Linux Loadable Kernel Modules"
< http://www.infowar.co.uk/thc/files/thc/LKM_HACKING.html> par pragmatic / THC : descriptions de nombreuses utilisations des modules sous Linux avec les sources pour Linux 2.0.3x
Le même document existe pour FreeBSD (par pragmatic) et Solaris (par plasmoid)
"stealth.c" et "ex3.c" < http://kalug.lug.net/stealth/> par Stealth :
deux exemples de modules pour noyaux 2.2 .
"lcamtuf::pliki" < http://dione.ids.pl/~lcamtuf/pliki.html> par Michal Zalewski <lcamtuf@ids.pl> : de nombreux sources de modules ou de patchs noyaux pour Linux 2.0.3x ou 2.2.x - la majorité en polonais.
Phrack Magazine < http://www.phrack.com> :
- "Weakening the Linux Kernel" (Issue 52 article 18)
  par plaguez < dube0866@eurobretagne.fr> : description et sources d'un cheval de Troie s'initialisant par un module.
- "btrom" (Issue 54 article 03) par riq : description et sources d'un programme de détection et de désactivation de chevaux de Troie fonctionnant sur le modèle précédent.

4.15 Chiffrement de systèmes de fichiers

Fonctionnement
Notes
Algorithmes
Exemple

4.16 Chiffrement de systèmes de fichiers : fonctionnement

La commande losetup associe un loopback (périphérique virtuel) à une partition. Si un algorithme de chiffrement est sélectionné alors un mot de passe est demandé.
L'opération de montage de la partition se fait en indiquant le loopback associé à la partition désirée.
Toutes les données envoyées au loopback sont écrites chiffrées dans la partition. Lors d'une lecture dans le loopback, les données correspondantes sont lues dans la partition et déchiffrées en mémoire.

4.17 Chiffrement de systèmes de fichiers : notes

les fonctionnalités de chiffrement de Linux ne sont pas incluses dans la distribution standard.
Des patches officiels sont disponibles pour ajouter ces fonctions aux sources du noyau.
Ces patches sont hébergés sur le site < www.kerneli.org> (actuellement en Norvège).
les commandes losetup, mount et umount doivent être patchées pour supporter ces fonctionnalités.
Les patchs nécessaires sont fournis avec les patchs des sources du noyau.
un fichier peut être associé à un loopback. Cela permet :
- de créer de petites partitions chiffrées qui peuvent être montées seulement lorsqu'elles sont nécessaires.
- de sauvegarder de façon sécurisée une partition vers un fichier chiffré.

4.18 Chiffrement de systèmes de fichiers : algorithmes

Deux algorithmes ont été implémentés pour chiffrer des partitions :
- CAST-128 défini dans le RFC 2144;
  voir www.entrust.com/downloads/pdf/cast-256.pdf et www.ietf.org/rfc/rfc2144.txt
  utilisé en mode ECB
- Twofish défini par Bruce Schneier, Doug Whiting, John Kelsey, Chris Hall et David Wagner; voir www.counterpane.com/twofish-paper.html
  utilisé en mode CBC
Une option permet d'utiliser en mode CBC n'importe lequel des sept algorithmes présents dans la bibliothèque pour chiffrer une partition.
- Blowfish, DES, DFC, IDEA, MARS, RC5, RC6 et Serpent.
Les algorithmes de hachage MD5 et SHA1 sont également disponibles.

4.19 Chiffrement de systèmes de fichiers : exemple

Sauvegarde de fichiers dans un fichier chiffré :

# dd if=/dev/urandom of=~/mon_fichier bs=1k count=100
# losetup -e twofish /dev/loop0 ~/mon_fichier
Password:
# mkfs -t ext2 /dev/loop0
# mount -t ext2 /dev/loop0 ~/mnt
# cp -pr ~/prive ~/mnt 
# umount /dev/loop0
# losetup -d /dev/loop0

Sauvegarde d'une partition dans un fichier chiffré :

# dd if=/dev/zero of=/jazz/ma_partition_hda1 bs=1k count=923296
# losetup -e twofish /dev/loop0 /jazz/ma_partition_hda1
Password:
# dd if=/dev/hda1 of=/jazz/ma_partition_hda1
# losetup -d /dev/loop0

4.20 Divers

Les fonctions présentées font partie du patch secure-linux <http://www.openwall.com/linux/>
- développé par Solar Designer <solar@false.com>.
- ces fonctions sont disponibles pour les versions 2.0.38 et 2.2.14 .
Les distributions Linux présentées sont soit en cours de développement, soit en cours d'étude.
subterfugue est une nouvelle fonctionnalité de restriction d'accès du noyau 2.4 .

4.21 Divers : patchs de sécurité

partition /proc restreinte :
- tout utilisateur n'a accès qu'aux données concernant ses propres processus, un groupe spécial permet d'accéder aux données de tous les processus.
- <http://underley.zakopane.top.pl/linux/restricted-procfs.html>
  par Daniel Podlejski <underley@zakopane.top.pl>
liens et tubes nommés restreints dans /tmp :
- un processus n'a accès à un lien ou à un tube nommé dans /tmp seulement s'il lui appartient ou qu'il appartient à root.
- <http://www.sekure.org/english/resources.html>
  par Sekure SDI <http://www.sekure.org/> (Brazilian Info Security Team)
création des descripteurs de fichiers 0, 1 et 2 pour les programmes SUID
- ces fichiers possèdent des significations spéciales pour les librairies
- de nombreux programmes y accèdent en utilisant leurs numéros usuellement affectés
pile non exécutable :
- la pile est rendue non exécutable afin d'empêcher la majorité des exploitations par débordement de buffer de fonctionner
- le principal problème est la gestion des programmes en glibc2.x qui utilisent les sauts par trampoline :
  - le noyau doit détecter et émuler les sauts par trampoline
  - il est possible de duper cette fonctionalité et d'exécuter un débordement de buffer

4.22 Divers : distributions sécurisées

nmrcOS <http://www.nmrc.org/nmrcOS/> : le but est de fournir un système stable et sécurisé.
- Basée sur une distribution SlackWare avec un noyau 2.0.36, il intègre plusieurs patchs de sécurité pour le noyau : "Solar Designer's patch", "Trusted path support", "Probe Detection Patch", etc.
- Un script durcit les droits d'accès sur de nombreux fichiers sensibles.
- En cours de portage sous Linux 2.2.12
Nexus Linux <http://www.lemuria.org/Nexus/> : distribution s'adressant aux administrateurs dont la première préocupation est la sécurité, elle fournit par défaut openssh et apache avec le support ssl.
- Cette distribution se trouve à l'état de développement : v0.3
- Disponible sur le site <ftp://ftp.lemuria.org/pub/Nexus/>
- Il s'agit en fait de l'ancienne distribution kha0s <http://www.kha0s.org/>.
bastille-linux <http://bastille-linux.sourceforge.net/> : basée sur une distribution RedHat, le but est de constituer une distribution utilisable dans les universités et les établissements éducatifs.
- Le projet consiste aujourd'hui en un script de durcissement d'un système sous Redhat 6.0 et 6.1 .
- La version 1.0.4 est disponible depuis le 3 avril 2000.
securelinux <http://www.reseau.nl/securelinux/> : le but est de fournir une distribution sécurisée "à tous les niveaux". Plus complète que les autres distributions, elle devrait fournir toutes les fonctions comme la gestion des privilèges, le chiffrement de partitions, etc.
- A l'heure actuelle, le développement de cette distribution n'a toujours pas commencé.
Stack-Guard <http://www.immunix.org/> : il s'agit d'un patch au compilateur gcc 2.7.2.3 afin de générer du code auto-immune aux exploitations de buffers par exécution de code dans la pile.
- Cette méthode a montré à de maintes reprises son efficacité :
  - les exploitations de faille de sécurité sont dans la quasi totalité de ce type.
- Une version de RedHat 5.2 entièrement recompilée est disponible.
- Il s'agit d'une approche complémentaire à :
  - l'utilisation d'une pile non exécutable
  - l'audit des codes sources.

4.23 Divers : subterfugue

subterfugue permet de limiter les accès d'un processus et de ses descendants.
il est possible :
- d'étendre les arguments à des noms de fichiers complets et d'y appliquer des expressions rationelles (regexp)
- de comptabiliser le nombre d'appels systèmes et de signaux
- d'interdire ou de limiter les accès réseaux
- d'interdire la fermeture des entrées / sorties standards et d'erreur
- d'interdire l'envoi de signaux à des processus "étrangers"
- de tracer les appels systèmes (en se limitant éventuellement à certains appels seulement)
- de restreindre les positionnements de droits d'accès (interdire les SUID, l'écriture pour tous...)
- de restreindre les accès disques en spécifiant :
  - les arborescences non accessibles
  - les arborescences accessibles en lecture seulement
  - les arborescences accessibles en lecture et écriture
http://www.subterfugue.org/ par Mike Coleman <mkc@subterfugue.org>
téléchargement : http://sourceforge.net/project/?group_id=1951
Le noyau Linux supporte nativement subterfugue depuis 2.3.99-pre1 .

5. La sécurité réseau

TCP/IP
Messagerie
tunnels (ssh, CIPE, IPsec)
Samba
NFS
L'utilisation de Linux en FireWall avec IP-Chains

5.1 TCP/IP

TCP/IP est une suite de protocoles standardisés.
Seuls les fichiers fondamentaux sont communs à toutes les implémentations Unix.
- /etc/hosts : indique la correspondance nom de machine <-> numéro IP.
- /etc/inetd.conf : fichier de configuration des services TCP/IP gérés par le démon inetd,
- /etc/services : définit les ports utilisés par les services TCP et UDP
- /etc/rpc : définit les ports rpc utilisés par les services RPC
- /etc/securetty : interdit la connexion directe des administrateurs comme root par le réseau sur les pseudos-tty non listés.
- /etc/ftpusers : interdit la connexion via ftp des utilisateurs listés.
- /etc/hosts.equiv : permet de rendre les machines équivalentes avec les R-commandes.
- $HOME/.rhosts : permet à un utilisateur de demander un service avec une R-commande sans se ré-authentifier.
- $HOME/.netrc : permet à un utilisateur de demander un service ftp sur d'autres machines avec une identification automatique.
- /etc/hosts.ldp : interdit les demandes d'impression depuis les adresses non listées.
- D'autres fichiers plus spécifiques à d'autres protocoles comme NIS, NFS, ftp, etc.
- Chaque distribution utilise un fichier différent pour initialiser le système réseau :
  - redhat : /etc/rc.d/init.d/network et /etc/sysconfig/network-scripts
  - slackware : /etc/rc.d/rc.inet1 et /etc/rc.d/rc.inet2
  - debian : /etc/init.d/network et /etc/init.d/netbase
  - /etc/pcmcia/network.opts : les portables utilisant le système PCMCIA

5.2 TCP/IP : TCP_WRAPPER

TCP_wrapper est un outil qui :
- s'installe en frontal des démons TCP/IP lancés par inetd,
- ajoute les fonctionnalités de filtrage par adresse IP source,
- permet la journalisation des accès.
Les versions récentes de TCP Wrapper peuvent être récupérées sur le site de Wietse Venema :
< ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz>
Les services non internes à inetd sont lancés via /usr/local/sbin/tcpd en modifiant le fichier /etc/inetd.conf :
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Les droits d'accès peuvent être configurés en mettant ALL:ALL dans /etc/hosts.deny et les autorisations dans /etc/hosts.allow :
in.telnetd:127.0.0.1,192.168.1.1

5.3 Messagerie

La messagerie internet est basée sur plusieurs protocoles :

SMTP : Simple Mail Transfert Protocol
- SMTP est le protocole d'échange de courrier électronique au-dessus de TCP/IP
  Il s'agit d'un protocole simple sans fonctionnalité de vérification d'authentification
  - ni du site émetteur
  - ni de l'utilisateur émetteur
- De nombreux logiciels de transferts existent : sendmail, postfix, qmail, mailx, etc.
  - Il est important de garder sa version logicielle à jour afin de ne pas être victime d'attaques
  - Il est important de mettre en place une gestion anti-relayage et anti-spam
POP (Post Office Protocol) et IMAP (Internet Message Access Protocol)
- Permettent à un utilisateur de récupérer ses messages.
- L'utilisateur est authentifié, le plus souvent en clair
- Possibilité d'encapsulation ssl, utiliser stunnel côté serveur : mike.daewoo.com.pl/computer/stunnel/

5.4 tunnels

Encapsulation de PPP dans SSH
CIPE
IPSec

5.5 tunnels : PPP dans ssh - présentation

PPP = Protocole Point à Point
- Protocole de liaison de données assurant l'échange de données sur une liaison point à point
Caractéristiques PPP
- Transport de données en provenance de plusieurs protocoles (IP, IPX, etc.)
- Attribution dynamique d'une adresse IP
SSH = Secure Shell
- Remplaçant sécurisé de rlogin, rsh et rcp
- Authentification mutuelle de l'utilisateur et du serveur
- Chiffrement de l'ensemble de la session

5.6 tunnels : ssh dans PPP - mise en place

Le poste nomade exécute un script qui, à l'aide d'une session SSH, lance PPP sur la passerelle et redirige les entrées / sorties de façon à faire passer PPP dans SSH
Les données à destination du réseau interne sont routées vers l'interface PPP résultante
La passerelle joue le rôle de proxy-ARP pour le nomade, qui semble ainsi appartenir au réseau interne

5.7 tunnels : CIPE

Prévu pour la création de VPN avec Linux 2.x, simple et bien documenté
Chiffrement au niveau IP, encapsulation des paquets IP chiffrés dans des datagrammes UDP
Installation et configuration
- Génère deux composants : un module noyau qui se chargera du chiffreement et un pilote
- Fichiers de configuration dans /etc/cipe
Utilisation
- Charger le module noyau
- Lancer le démon ciped, qui crée un périphérique spécial (même principe que pppd)
sites.inka.de/~bigred/devel/cipe.html

5.8 tunnels : IPsec - présentation

Sécurisation des échanges au niveau IP : chaque paquet échangé est chiffré et / ou authentifié
Mis en oeuvre sur tout équipement ayant accès au réseau : routeur, serveur, station de travail...
Modes
- Transport : sécurisation de bout en bout, en-tête non modifiée
- Tunnel : encapsulation dans un nouveau paquet IP

5.9 tunnels : IPsec - FreeS/WAN

IPsec n'est pas disponible par défaut dans les piles TCP/IP, il faut ajouter un élément spécifique
FreeS/WAN :
- www.xs4all.nl/~freeswan
- Pour linux version >= 2.0.36 et 2.2.x
- Groupe de développeurs actif, nouvelles versions fréquentes
Etapes :
- Installation de FreeS/WAN sur les machines extrémités du tunnel
  (nécessite une recompilation du noyau)
- Configuration des paramêtres du ou des tunnels
- Transparent pour l'utilisateur une fois en place

5.10 Samba

Samba est un ensemble de programmes qui implémentent le protocole SMB (Server Message Block) pour des systèmes Unix :
- smbd fournit les services de partage de fichiers et d'impression
- nmbd fournit le service de noms NetBIOS
- smbclient : implémente un client à la ftp pour accéder à des partages SMB et permet à un système Unix d'imprimer via n'importe quel serveur d'impression SMB
Samba peut jouer le rôle de PDC pour un domaine.
- Il ne peut pas (encore) se synchroniser avec un serveur Windows NT
Samba supporte les mots de passe chiffrés LanMan et NTLM
Prochainement Samba :
- permettra d'établir des relations de confiance
- supportera totalement les ACL Windows NT
- permettra les synchronisations BDC <=> PDC avec des serveurs Windows NT
Samba est disponible sur www.samba.org

5.11 NFS

NFS est un protocole de gestion de fichiers répartis proposé par SUN.
Il est devenu standard de par ses capacités de fonctionnement en milieu hétérogène.
Aucune authentification n'est possible.
Par défaut, aucune sécurité n'est installée et il est nécessaire de reconfigurer NFS via le fichier /etc/exports
- Limiter les adresses IP ayant accès à chaque export : adresse IP, sous-réseau et noms de machine complètement qualifiés
- Limiter les accès privilégiés à chaque export
  - par défaut root est traduit en nobody mais il est préférable de restreindre :
    bin, daemon, adm, lp, mail, news, uucp, operator, man, postmaster, ftp, guest, ...
  - n'accorder l'accès root qu'à des machines sûres.
- Limiter les accès à la lecture seule si l'écriture n'est pas nécessaire.

5.12 L'utilisation de Linux en FireWall avec IP-Chains

Possibilités
Mise en service
Architectures

5.13 IPChains - Possibilités

ipchains est l'un des systèmes de filtrage utilisable
Il est dérivé de ipfw un système présent sur d'autres Unix
Il est très puissant :
- Comptage de traffic
- Blocage de traffic non souhaité
- Masquage d'adresses (n : 1)
- Détournement vers un service local

5.14 IPChains - Possibilités - 2

Chaque règle sélectionne les paquets sur les critères :
- Adresse IP source du paquet
- Adresse IP destination du paquet
- Type de protocole (TCP, UDP, ICMP)
- Port de protocle adressé (source, destination)
- Interface IP traversée
- Type de paquet (connexion, transfert)

5.15 IPChains - Possibilités - 3

Chaque règle permet les actions suivantes :
- Autorisation du paquet
- Destruction du paquet
- Rejet du paquet avec message d'erreur
- Détournement du paquet sur un serveur local

5.16 IPChains - Possibilités - 4

ipchain s'organise par chaines
Une chaine est l'équivalent d'un programme
Il est possible d'écrire des sous-programmes
Ces trois sous-programmes doivent exister :
- input
- forward
- output

5.17 IPChains - Mise en service

Un support noyau est obligatoire
Il faut insérer des options :
- "Network firewalls" ( CONFIG_FIREWALL=y )
- "IP: firewalling" ( CONFIG_IP_FIREWALL=y )
En standard depuis le noyau 2.1.102

5.18 IPChains - Mise en service - 2

Les règles peuvent être éditées dynamiquement
Il faut sauvegarder une version de filtrage
Il faut installer la version sauvegardée au boot
Ne pas oublier :
- De mettre les filtres avant d'activer les interfaces réseau
- De mettre les filtres avant d'activer le routage de paquets IP

5.19 Architectures - Filtrage

Filtrage IP possible sous Linux avec IPChains
- masquage d'adresse
- analyse de session de base (à implémenter avec des relais transparents)
Le futur d'IPChains : NetFilter (noyaux 2.4)
- filtrage évolué : filtrage dynamique tcp, udp et icmp
- analyse de session : ftp
- traduction d'adresses :
  - masquage d'adresse
  - redirection de ports
  - relayage transparant
  - traduction d'adresse statique/dynamique
  - partage de charge simple

5.20 Architectures - Web : Accès

Relais applicatifs sous Linux (NSM, FWTK, Delegate)
DMZ "privée"
Cache WEB sous Linux (SQUID)
DMZ "publique"

5.21 Architectures - Web : Serveur

Serveur Web sous Linux (APACHE)
DMZ "publique"

5.22 Architectures - DNS

Serveurs DNS
- DNS privé sous Linux (BIND)
  DMZ "privée"
- DNS publique sous Linux (BIND)
  DMZ "publique"

5.23 Architectures - Mail

Serveur de messagerie (POSTFIX et CUCIPOP)
- serveurs SMTP et POP3 dans la DMZ "publique"
- relais SMTP dans la DMZ "publique" ; serveurs SMTP et POP3 internes

6. Conclusion

Linux permet de sécuriser un système et le réseau
Du travail est nécesssaire mais de nombreux outils sont disponibles gratuitement : packetstormsecurity.org
Le résultat est très honorable

® © Hervé Schauer Consultants 1999 - 142, rue de Rivoli - 75001 Paris
Téléphone : +33 141 409 700 - Télécopie : +33 141 409 709 - Courriel : <secretariat@hsc.fr>