# Contrôle d'accès par les tcpwrappers

Marie-Claude Vialatte
1999-2000

## 1 - Qu'est-ce qu'un tcpwrapper ?

### 1.1 - Principes

> Le tcpwrapper est un logiciel qui filtre les accès à certains serveurs d'application, telles telnet, FTP...

> Pour que l'accès à un serveur puisse être ainsi filtré, il faut que le serveur ne soit lancé que lorsque'une demande arrive, à la différence de serveurs lancés au démarrage du système (comme `mountd`).
> Le lancement de tels serveurs est effectué par le processus `inetd` qui est en attente sur tous les ports décrits dans son fichier de configuration `/etc/inetd.conf`.

### 1.2 - Fonctionnement

> Lorsqu'il démarre, le processus `inetd` se met en attente d'appel sur tous les ports correspondants aux applications qu'il doit prendre en charge, applications dont la liste de trouve dans `/etc/inetd.conf`.
> La correspondance entre nom d'application (service) et n°port TCP se trouve dans `/etc/services`.
> (Note : la modification d'un de ces fichiers nécessitent d'envoyer un signal HUP au processus `inetd`)

> Lorsqu'une demande arrive, elle est reçue par le processus `inetd`, qui crée un processus fils pour exécuter le programme donné dans la ligne de `/etc/inetd.conf` correspondant au n°port TCP appelé.

> > protégé par tcpwrapper | ligne de /etc/inetd.conf
> > --- | ---
> > non | `telnet stream tcp nowait root in.telnetd`
> > oui | `telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd`

> > service protégé par tcpwrapper

> Si le tcpwrapper n'est pas activé, c'est le programme du serveur de l'application.

> Si le tcpwrapper est actif, `inetd` lance un processus `tcpd`, en lui passant en paramètres la ligne de commande de lancement du serveur.
> Le processus `tcpd` confronte la demande (service, @IP de l'appelant) aux règles de filtrage précisées dans les fichiers `hosts.allow` et `hosts.deny` du tcpwrapper :

> 1. si la demande apparait dans le fichier `hosts.allow`, le tcpwrapper la passe au serveur correspondant.
> 2. si la demande apparait dans le fichier `hosts.deny`, le tcpwrapper la refuse.
> 3. si la demande n'apparait dans aucun de ces deux fichiers, le tcpwrapper la passe au serveur correspondant.

> Dans tous les cas, le tcpwrapper journalise la demande par `syslog`, selon `/etc/syslog.conf`, par exemple dans `/var/log/secure`.

> Si la demande est acceptée, le processus `tcpd` le programme indiqué en paramètre, c'est-à-dire le serveur.

### 1.3 - Configuration

> Activation /désactivation du tcpwrapper
>   dans la ligne de `/etc/inetd.conf` correspondant au serveur
> Les règles
>   dans les fichiers `hosts.allow` et `hosts.deny`, dont les lignes ont le format (voir hosts.access(5)):

>   > `serveurs: liste de systèmes-clients [: commande-shell]`

>   `serveur(s)` | un ou plusieurs noms de serveurs (argv[0]) auxquels s'applique la règle ou un mot-clé : `ALL`, ``
>   `système-client` | un nom de système, une adresse de système, avec possibilité de regroupement de noms ou d'adresses ou un mot-cle : `ALL`, `LOCAL`, `UNKNOWN`, `KNOWN` ou`PARANOID` et avec possibilité d'exceptions à la règle

## 2 - Manipulation des tcpwrappers

> Mode opératoire :
>   Le système `zuta` est le système de l'opérateur, qu'il configure selon ses choix.
>   Pour tester sa configuration de `zuta`, l'opérateur fait un telnet sur un autre système (`zutb`, `zutc`...ou `se1`), et tente de lancer une session FTP avec son système.
>   Après chaque modification de la configuration, vérifier si le lancement d'une session-FTP est possible ou non.

> Opérations à effectuer
> 1. désactiver le tcpwrapper
> 2. activer le tcpwrapper, sans rien mettre concernant FTP dans les fichiers `hosts.allow` et `hosts.deny`
> 3. interdire toute session FTP, y compris du système lui-même
> 4. autoriser une session seulement à partir d'un système `zut`, de plusieurs
> 5. autoriser tous les systèmes de l'ISIMA
> 6. autoriser tous les systèmes, sauf ceux du réseau `192.54.142.0`, et ceux du domaine-Internet `hacker.com`

# Restaurer les fichiers modifiés