Ceci est la version imprimable de Administration réseau sous Linux.

Si vous imprimez cette page, choisissez « Aperçu avant impression » dans votre navigateur, ou cliquez sur le lien Version imprimable dans la boîte à outils, vous verrez cette page sans ce message, ni éléments de navigation sur la gauche ou en haut.
Cliquez sur Rafraîchir cette page pour obtenir la dernière version du wikilivre.
Pour plus d'informations sur les version imprimables, y compris la manière d'obtenir une version PDF, vous pouvez lire l'article Versions imprimables.

Administration réseau sous Linux

Une version à jour et éditable de ce livre est disponible sur Wikilivres,
une bibliothèque de livres pédagogiques, à l'URL :
https://fr.wikibooks.org/wiki/Administration_r%C3%A9seau_sous_Linux

Vous avez la permission de copier, distribuer et/ou modifier ce document selon les termes de la Licence de documentation libre GNU, version 1.2 ou plus récente publiée par la Free Software Foundation ; sans sections inaltérables, sans texte de première page de couverture et sans Texte de dernière page de couverture. Une copie de cette licence est incluse dans l'annexe nommée « Licence de documentation libre GNU ».

Configuration réseau

Installation de la carte réseau

Les cartes réseau sont souvent détectées au démarrage. Si ce n'est pas le cas il faudra charger les modules correspondants.

Pour obtenir la liste des interfaces réseau qui ont été détectées, on peut utiliser dans l'invite de commandes :

ifconfig -a

Les sections qui commencent par ethX correspondent aux cartes Ethernet, où X est le numéro de la carte.

Si la carte n'est pas détectée, il faudra charger le module avec la commande

modprobe <nom du module>

Parmi les modules courants on peut noter : ne2k-pci pour les cartes NE2000, via-rhine, rtl8139...

Les modules disponibles pour votre noyau se trouvent dans /lib/modules/<nom du noyau>/kernel/drivers/net/. La commande suivante affiche les modules réseau disponibles pour le noyau en cours d'utilisation :

ls /lib/modules/`uname -r`/kernel/drivers/net/

Pour connaître le nom du module en fonction du nom commercial d'une carte, une recherche sur l'internet est souvent la meilleure solution.

Le noyau donne parfois des informations utiles sur les cartes réseau. On peut rechercher les messages contenant "eth0" pour avoir plus d'informations sur la première carte réseau détectée :

dmesg | grep eth0

La commande suivante permet d'afficher les cartes réseaux reliées au bus PCI :

lspci | grep Ethernet

Configuration de l'interface réseau

Une fois votre carte reconnue par le noyau, vous devez au moins préciser son adresse IP et son masque de sous-réseau. Dans le cas d'un réseau local connecté à l'internet, vous devez aussi ajouter l'adresse IP de la passerelle et l'adresse IP d'un ou plusieurs serveurs DNS.

Adresse IP

>Pour attribuer une adresse IP à une interface réseau, on peut utiliser la commande ifconfig :

ifconfig <interface> <adresse ip>

>Par exemple :

ifconfig eth0 192.168.1.12

Le masque de sous-réseau est déterminé automatiquement en fonction de la classe de l'adresse IP. S'il est différent on peut le spécifier avec l'option netmask :

ifconfig eth0 192.168.1.12 netmask 255.255.255.128

>Pour voir si la carte réseau est bien configurée, on peut utiliser la commande :

ifconfig eth0

Passerelle et routage

Pour ajouter une passerelle, on peut utiliser la commande route :

route add default gw <adresse ip>

Pour afficher les routes vers les différents réseaux :

route -n

Tester le réseau

Pour vérifier que la carte réseau fonctionne, on peut essayer de communiquer avec une autre machine avec la commande

ping <adresse ip>

La commande ping envoi un paquet à l'adresse IP puis attend que la machine réponde. Elle affiche ensuite le temps qu'a pris toute l'opération, en millisecondes.

Informations sur les interfaces

Pour vérifier les ports ouverts, on peut utiliser la commande

netstat -a

>Nom d'hôte (hostname)

Le fichier /etc/hostname contient le nom de la machine. Il suffit de l'éditer pour changer le nom d'hôte de la machine. Cette modification n'est pas prise en compte immédiatement par le système, elle le sera au prochain démarrage de la machine ou après avoir lancé :

/etc/init/hostname.sh (ubuntu)

/etc/hostname (debian)

Le fichier est vide par défaut. Si le fichier n'existe pas, il faut le créer.

On peut également changer le nom d'hôte avec la commande suivante, mais il ne sera pas conservé au prochain démarrage :

hostname <nom d'hôte>

>Configuration automatique au démarrage

Le fichier /etc/network/interfaces permet de configurer les cartes réseau de manière permanente.

Par exemple :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
  address 192.168.1.2
  netmask 255.255.255.0
  gateway 192.168.1.1
  dns-nameservers 8.8.8.8

Cette configuration initialisera automatiquement les interfaces "lo" et "eth0".

L'interface "lo" est souvent indispensable au système, il est important de l'initialiser. Elle aura systématiquement l'adresse IP 127.0.0.1.

L'interface "eth0" sera configurée avec l'adresse IP 192.168.1.2, le masque de sous réseau 255.255.255.0 et la passerelle 192.168.1.1 (ce paramètre est facultatif).

Dans le cas d'une IP fixe, il vaut mieux renseigner un serveur DNS (ci-dessus celui de Google). Sinon, si l'interface eth0 doit être configurée automatiquement par un serveur DHCP, il faut indiquer :

auto eth0
iface eth0 inet dhcp

Pour que les modifications de ce fichier soient prises en compte, il faut redémarrer ou utiliser les commandes ifup et ifdown. Par exemple :

ifup eth0

ATTENTION : Avant de redémarrer la configuration réseau (systemctl restart networking, ou ifup/ifdown, ...) déconfigurez manuellement les interfaces réseaux via la commande ip addr flush ethX (X valant 0 puis 1 puis 2 pour r2).

Résolution de noms d'hôte

Le fichier /etc/host.conf indique comment les noms doivent être résolus (c'est à dire comment passer d'une adresse IP à un nom, et inversement). Par exemple :

# D'abord traduire avec les serveurs DNS et ensuite avec /etc/hosts.
order bind,hosts

# Il existe des machines avec plusieurs adresses
multi on

# Vérifie l'usurpation d'adresse IP
nospoof on

Serveurs DNS

Le fichier /etc/resolv.conf contient les adresses IP des serveurs DNS. Par exemple :

nameserver 208.164.186.1
nameserver 208.164.186.2
search foo

La commande search indique que si un nom de domaine n'est pas trouvé, il faudra essayer en lui ajoutant .foo.

Fichier hosts

Le fichier /etc/hosts contient une liste de résolutions de noms (adresses IP et noms de machine). Par exemple:

192.168.105.2 sasa

Ce fichier indique que sasa correspond à l'adresse IP 192.168.105.2, qui sera accessible par cet alias.

Problèmes connus

ping: unknown host

Vérifier en renseignant le DNS mentionné ci-dessus.
La commande ping permet de tester la joingnabilité d'une adresse ip disponible dans un même réseau. Essayons de voir les options de la commande ping :
ping Adaptive -A. intervalle Interpacket adapte à temps aller-retour, de sorte que effectivement pas plus d'un (ou plus, si la précharge est set) sonde sans réponse est présent dans le réseau. inter- Minimal val est 200msec pour ne pas super-utilisateur. Sur les réseaux à faible rtt ce mode est essentiellement équivalent au mode d'inondation. -b Autoriser pinger une adresse de diffusion. -B Ne pas laisser ping pour changer l'adresse source de sondes. le l'adresse est liée à celle sélectionnée lorsque ping commence. -c count Arrêt après l'envoi de paquets de comptage ECHO_REQUEST. Avec délai option ping attend les paquets de comptage ECHO_REPLY, jusqu'à ce que le Time- expire out.
Cette section est vide, pas assez détaillée ou incomplète. Votre aide est la bienvenue !

Pour éviter que ceci se produise en passant du DHCP en IP statique, il faut tester aupavavant la résolution DNS :

Tester le pare-feu : telnet 8.8.8.8 53.
Si dig google.fr fonctionne mais pas dig @8.8.8.8 google.fr, vérifier que le sous-réseau de la machine a bien accès au DNS.

NFS

Le protocole NFS (Network file system) permet de partager des fichiers entre des machines Unix, et donc Linux. C'est un modèle client-serveur : une machine met à disposition (exporte) des répertoires de son système de fichier local sur le réseau à des clients. Suivant les droits d'accès donnés, des stations du réseau peuvent monter ces répertoires, qui seront alors vus comme des répertoires locaux. Un ordinateur peut être à la fois client et serveur NFS.

Installation côté serveur

Installation sur Debian :

# apt install nfs-kernel-server

Vérifier que les demons NFS (nfsd) ne sont pas déjà lancés avec, par exemple, la commande

ps ax | grep nfsd

Pour lancer les démons manuellement sous Debian :

/etc/init.d/nfs-kernel-server start

ou, si c'est le serveur NFS en espace utilisateur qui est installé :

/etc/init.d/nfs-user-server start

On peut remplacer start par restart pour redémarrer le serveur.

Configuration

Pour partager (ou exporter) des répertoires, il faut renseigner le fichier /etc/exports. Il indique la liste des répertoires partagés et le nom des machines qui y ont accès.

Chaque ligne correspond à un répertoire et a la forme :

<répertoire local> <nom ou IP des machines autorisées à se connecter>(<options>) <autres machines>(<options>)...

Par exemple :

/home/name  station0(rw) station1(ro)
/projet    station1(rw) (ro)
/brouillon

Le serveur exporte son répertoire /home/name. La machine station0 pourra le monter en lecture/écriture (rw read-write), station1 en lecture seule (ro read-only), et les autres machines ne pourront pas se connecter.

De même, station1 pourra accéder en lecture/écriture au répertoire projet et toutes les autres stations en lecture seule.

Enfin, tout le monde pourra accéder en lecture/écriture au répertoire brouillon (l'option rw est celle par défaut).

Pour connaitre la liste des options possibles et leur signification, consultez man exports.

Notez bien que les droits via le réseau seront toujours inhibés par les droits sur le système de fichier : si un utilisateur accède via la station1 au répertoire /projet, il ne pourra pas accéder au fichier test situé dans le répertoire /projet, bien qu'il ait les droits réseaux rw, si le fichier test appartient à root avec les droits 600 (lecture/écriture pour root uniquement, aucun droit pour les autres).

Une fois le fichier /etc/exports correctement configuré, il suffit de relancer le service NFS par la commande suivante pour que les modifications soient prises en compte :

/etc/init.d/nfs-kernel-server reload

Installation côté client

installation sur Debian (Le "système de fichier réseau" NFS est intégré au noyau compilé avec sa prise en charge dans toutes les distributions récentes.)

# apt install nfs-common

Pour monter un système de fichier distant, utiliser la commande mount avec l'option nfs :

mount -t nfs <machine distante>:<répertoire partagé> <répertoire local> -o <options>

Par exemple si le serveur précédent à pour ip 192.168.105.2 :

mount -t nfs 192.168.105.2:/home/name /mnt/rep_local -o ro

Cette commande montera le répertoire /home/name, exporté par la station 192.168.105.2, dans le répertoire local /mnt/rep_local, en lecture seule.

À la place d'une adresse IP, vous pouvez aussi donner un nom de machine (nom d'hôte ou hostname : le nom figurant à droite du @ dans une console user@hostname). Pour cela, il faut que le nom de machine puisse être converti en adresse IP (en modifiant /etc/hosts par exemple, si on n'a pas de serveur DNS)

Montage au démarrage

Il est possible de monter les répertoires partagés au démarrage de la station.

Le plus simple est de renseigner le fichier /etc/fstab qui contient une liste des systèmes de fichiers connus.

La syntaxe est la suivante :

<ordinateur distant>:<répertoire distant> <répertoire local> nfs <options> 0 0

Pour reprendre l'exemple précédent, cela donnerait :

192.168.105.2:/home/name /mnt/rep_local nfs auto,rw,user,soft,(autres options…)  0 0

Les options sont décrites dans la page de man de mount. Certaines sont communes à d'autres systèmes de fichiers (ext2, vfat…) alors que d'autres sont spécifiques à NFS. Si le serveur n'est pas toujours disponible ou susceptible de ne plus l'être en cours d'utilisation il est préférable de ne pas monter automatiquement le répertoire distant au démarrage au risque de bloquer votre poste client : option noauto .

Samba

SAMBA:

Samba est un service permettant de partager des répertoires et imprimantes entre des stations Linux et des stations Windows. Un How-To très complet peut être trouvé là : http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/

Cette partie présente juste une introduction à l'utilisation de samba. Nous considérons que nous sommes en mode sécurité user (security=user, nécessite un compte utilisateur unix). L'utilisation du niveau de sécurité domain et la partie partie partage avec Windows (notamment les dernières versions) n'est pas vue. Pour un accès Windows, cette page donne les quelques commandes supplémentaires: http://www.oregontechsupport.com/samba/samba.php

Configuration du service Samba

Pour la configuration de ce service le principal fichier à modifier est smb.conf qui se trouve généralement dans /etc ou /etc/samba selon la distribution.

Il existe également des interfaces graphiques pour configurer Samba.

La section [global] contient les options communes à tous les répertoires partagés.

Voici quelques options utilisables :

workgroup: Le nom du groupe de travail. Les ordinateurs du même groupe de travail se retrouvent côte à côte dans le voisinnage réseau de Windows.
server string: La description du serveur, qui apparaitra à côté de son nom dans l'explorateur Windows. Si la description contient le terme %h, il sera remplacé par le nom d'hôte de la machine.
encrypt passwords: Détermine si les mots de passe doivent être chiffrés avant d'être transmis. C'est fortement recommandé et tous les systèmes Windows à partir de 98 et NT4 SP3 utilisent cette fonctionnalité par défaut.
log file: Le nom du fichier qui contiendra le journal des activités du serveur. On peut avoir un journal par machine client en utilisant %m dans le nom du fichier. Le %m sera remplacé par le nom de la machine client.
max log size: Taille maximale du fichier journal, en Kio.
socket options: Indique les options à mettre sur les sockets comme par exemple TCP_NODELAY pour que le système envoi immédiatement les petits paquets sans attendre d'en avoir plusieurs.

De nombreuses autres options sont disponibles. Elles sont détaillées dans la page de man de smb.conf

Exemple

[global]
workgroup = maison
server string = Serveur Samba sur %h
encrypt passwords = true
log file = /var/log/samba/log.%m
max log size = 1000
socket options = TCP_NODELAY

Configuration du partage des répertoires

Les partages Samba sont décrits dans des sections ayant la forme suivante :

[<nom du partage>]
<option> = <valeur>
...

Les paramètres principaux sont les suivantes :

comment: La description du répertoire partagé.
path: Le chemin du répertoire partagé. C'est le contenu du répertoire indiqué qui sera partagé.
read only: Détermine si les clients pourront écrire ou non dans le répertoire partagé.
public: Autoriser ou non les connexions sans mot de passe.
valid users: Liste des seuls utilisateurs autorisés à se connecter séparés par des espaces. Si on veut autoriser tous les utilisateurs il ne faut pas mettre cette option.
browseable: Détermine si le partage apparaitra dans la liste des partages du serveur.

La section [homes] est un partage particulier. Elle définit le partage des répertoires utilisateur des comptes unix de la machine.

De nombreuses autres options sont disponibles. Elles sont détaillées dans la page de man de smb.conf

Par défaut (version 3.5.6) vous pouvez accéder à samba de façon anonyme (smbclient //serveur/nom_du_partage -U compte sans mot de passe). Pour effectuer un accès plus sécurisé (avec compte et mot de passe), vous devez également ajouter un compte samba qui se référence à un compte linux existant: adduser compte (si ce n'est pas fait) smbpasswd -a compte Les droits des répertoires et fichiers doivent être correct. Exemple chmod u+rws,g+rx,o+rx .../dossier et/ou fichier

Exemples

[cdrom]
comment = Samba server's CD-ROM
read only = yes
locking = no
path = /cdrom
guest ok = yes

[partage]
path = /media/d/partage
available = yes
browsable = yes
public = yes
writable = yes

[zelinux]
comment = Site web
path = /myrep/zelinux
read only = no

Protéger les répertoires partagés

Il est possible de rendre privé un répertoire et d'autoriser ou non des utilisateurs à y accéder.

Pour cela, pour chaque répertoire partagé ajoutez les options:

public = no
valid users = <nom des utilisateurs autorisés à accéder aux répertoires>

Pour chaque nom que vous avez rentré, il faut ajouter l'utilisateur samba avec

smbpasswd -a <nom de l'utilisateur>

Un compte unix du même nom doit exister. Si ce n'est pas le cas, il faut le créer avec la commande adduser.

Lancement du service

Lancement :

/etc/init.d/samba start

Pour le stopper :

/etc/init.d/samba stop

Pour le relancer :

/etc/init.d/samba restart

Les modifications du fichier smb.conf sont prises en compte pour chaque nouvelle connexion. Pour les rendre effectives sur les connexions déjà établies, il faut relancer Samba.

Accès aux répertoires

Pour accéder aux partage sous Windows, il suffit d'ouvrir le voisinage réseaux d'une station Windows et de vérifier si la machine y est.

Pour se connecter en ligne de commande à un partage à partir de Linux, on peut utiliser la commande

smbclient //<nom du serveur>/<nom du partage> -U <utilisateur>

Il est également possible de monter un partage Samba avec

smbmount //<nom du serveur>/<nom du partage> <répertoire local>

Différentes options sont disponibles. On peut les consulter dans man smbclient et man smbmount. Généralement, il est conseillé d'ajouter les options -o username=compte,password=??? pour se connecter.

Par exemple, pour monter un répertoire "public" il faut préciser qu'il faut se connecter en guest :

smbmount //serveur/partage /point_de_montage -o guest

Il faut également que votre compte utilisateur ait des droits sur le montage. Le compte root peut utiliser smbmount sans trop de problème.

Autrement, plusieurs possibilités existent:

compléter le fichier /etc/fstab avec votre montage //<IP-ADRESS>/<folder_on share> <your_local_mountpoint cifs defaults,iocharset=utf8,codepage=cp850,uid=1000,gid=1000,noauto,user,credentials=~/.smbcredentials 0 0)
ajouter des droits dans sudoers. (par défaut sous ubuntu 10.10, sudo smbclient //<nom du serveur>/<nom du partage> <répertoire local>-o username=compte,password=??? fonctionne bien)

Apache

Apache est un serveur HTTP libre. Un serveur HTTP permet d'héberger des sites web qui seront accessibles avec un navigateur tel que Mozilla Firefox, Internet Explorer ou encore Chrome.

Un site web peut fournir tout type de contenu (des fichiers textes, HTML, Flash, zip…).

Ce contenu peut être statique (le serveur transmet un fichier au navigateur) ou dynamique (le contenu est généré par un programme exécuté par le serveur). Les sites web contiennent généralement plusieurs types de documents, certains étant statiques et d'autres dynamiques.

Nous traiterons ici d'Apache 2.2 sur un système Debian (et ses dérivés, comme Ubuntu).

Installation

LAMP

Logiciel tout-en-un pour Linux (Apache + MySQL + PHP), comme WAMP pour Windows.

commande nécessitant les privilèges root

# apt-get install tasksel
# tasksel install lamp-server

Installation manuelle

Apache sur Debian / Ubuntu

commande nécessitant les privilèges root

# apt-get install apache2

Le service peut ne pas être lancé par défaut, mais même s'il l'est on peut quand-même essayer de l'activer avec :

commande nécessitant les privilèges root

# /etc/init.d/apache2 start

On peut ensuite tester le serveur, pour voir si une page s'affiche ou s'il refuse la connexion :

commande

$ lynx http://localhost/

Cette adresse est le rebouclage, elle peut aussi être rentrée directement dans tout navigateur web.

Si Apache était déjà installé vérifier le fichier pour indiquer le démarrage automatique d'Apache 2 /etc/default/apache2 :

 # vi /etc/default/apache2
 ...
 NO_START=0

Installer PHP

On distingue principalement deux versions de PHP : celle dont le binaire est appelé par le serveur Web, et php-fpm qui possède son propre service daemon (aussi appelé par le serveur Web) testable ainsi :

telnet localhost 9000
CTRL + ALT + ]
quit

FPM signifie FastCGI Process Manager, puisque le processus PHP-fpm écoute les requêtes CGI^[1]. Cela peut se traduire soit par des requêtes TCP/IP, soit par un socket Unix (.sock dans le vhost).

PHP peut-être installé avec toutes les déclinaisons de la distribution Debian (stable, testing, unstable). Il suffit pour cela d'insérer vos lignes préférées dans le fichier /etc/apt/sources.list :

deb http://ftp.fr.debian.org/debian/ stable main non-free contrib
deb-src http://ftp.fr.debian.org/debian/ stable main non-free contrib

Ce qui suit suppose que le serveur Web a bien été installé ; exécuter les commandes suivantes :

sudo apt-get update && apt-get install php8.2 && apt-get install libapache2-mod-php8.2

Une fois ces commandes exécutées, redémarrer le serveur Web. Dans le cas d'Apache cela s'effectue avec la commande suivante :

/etc/init.d/apache2 restart

Si tout s'est bien passé, vous disposez maintenant d'un serveur Web qui a la capacité d'exécuter des scripts PHP dans votre navigateur.

Testons :

commande

$ lynx http://localhost/test.php

Pour débugger :

commande

$ tail /var/log/apache2/error.log

Mise à jour

Pour PHP 7 ou 8 sur Ubuntu :

sudo add-apt-repository ppa:ondrej/php

Sur Debian :

sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'

Puis :

sudo apt update
sudo apt install php8.2 php8.2-common php8.2-cli php8.2-fpm

sudo a2enmod php8.2

Une fois les serveurs Web installés, ils se lancent automatiquement à chaque démarrage de la machine, ce qui est souhaitable pour un serveur, mais pas toujours pour un PC. Pour éviter cela, il suffit d'y désactiver les daemons :

sudo update-rc.d apache2 disable
sudo update-rc.d mysql disable

Bibliothèques

Voici une liste de bibliothèques fréquemment utilisées dans les applications :

# apt-get install -y \
    php8.2-mysql \
	php8.2-cli \
	php8.2-gd \
	php8.2-curl \
	php8.2-mbstring \
	php8.2-xml

D'autres s'installent avec pecl au lieu de apt.

Pour les activer après installation, on peut éditer le php.ini ou lancer : phpenmod nom_du_module_php. Ex : sudo phpenmod gd.

Pour les désactiver : phpdismod nom_du_module_php

Pour détecter l'emplacement du php.ini de la version de PHP par défaut : php --ini.

Désinstaller PHP

Pour éviter de désinstaller tous les paquets PHP un par un (par exemple après une bascule de PHP7.0 vers PHP7.1), il existe "ppa-purge" :

sudo apt-get install ppa-purge
sudo ppa-purge ppa:ondrej/php-7.0

Apache sur Gentoo

Premièrement il faut installer Apache :

emerge apache

Ensuite, il faut installer PHP :

emerge dev-lang/php

Puis il faut qu'apache utilise PHP dans sa configuration.

Code : Configuration de apache

# nano -w /etc/conf.d/apache2
APACHE2_OPTS="-D PHP5"

MySQL seul

MySQL est disponible sur http://dev.mysql.com/downloads/gui-tools/5.0.html au format :

.msi (Windows)
.dmg (Mac)
.rpm (Linux)
.tar

En l'absence de gestionnaire de paquets, utiliser le .tar ainsi :

shell> groupadd mysql
shell> useradd -r -g mysql mysql
shell> cd /usr/local
shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
shell> ln -s full-path-to-mysql-VERSION-OS mysql
shell> cd mysql
shell> chown -R mysql .
shell> chgrp -R mysql .
shell> scripts/mysql_install_db --user=mysql
shell> chown -R root .
shell> chown -R mysql data
shell> bin/mysqld_safe --user=mysql &

APT

$ sudo apt-get install mysql-server mysql_secure_installation

Variante

La dénomination des paquets mentionnés peut varier légèrement selon la version. Dans un terminal, entrez :

$ sudo apt-get install mysql-server

et confirmez.

(Remarque : il semblerait qu'en installant le paquet "mysql-server-5.0", au lieu du paquet mentionné plus haut, certaines personnes rencontrent des problèmes. Il est donc préférable d'installer ce paquet, ou d'installer la dernière version 4 stable avec : $ sudo apt-get install mysql-server-4.1. Consultez le forum pour plus d'informations : [1])

Lancez ensuite la commande :

cd && sudo mysql_secure_installation

Appuyez sur Entrée lorsqu'il vous demande le mot de passe root MySQL : pour le moment il n'y en a pas.

MySQL a ses propres utilisateurs, avec leurs propres privilèges. Le root MySQL n'est donc pas le root système. Il est conseillé de ne pas mettre les mêmes mots de passes pour les utilisateurs MySQL et les utilisateur du système.

Le script vous demande alors si vous voulez mettre un mot de passe pour l'utilisateur root. Répondez Y, et entrez (2 fois le nouveau mot de passe du root MySQL). Il vous pose ensuite une série de questions. Si vous ne savez pas quoi répondre, acceptez les choix par défaut en appuyant simplement sur Enter.

Votre serveur MySQL est prêt. Par défaut il se lance à chaque démarrage du système, si vous ne le souhaitez pas, il vous suffit de lancer :

$ sudo dpkg-reconfigure mysql-server

et de répondre "Non" à la question du démarrage systématique de MySQL.

Sur Gentoo

emerge mysql

Modules

De nombreux modules complémentaires peuvent être installés sur Apache.

Pour les lister, on utilise apachectl (parfois apache2ctl) :

apachectl -t -D DUMP_MODULES

ou

apache2ctl -M

Pour activer un module :

a2enmod Nom_du_module

Un fichier est alors créé dans /etc/apache2/mods-enabled/.

Exemple pour la réécriture d'URL :

a2enmod rewrite

Pour le désactiver :

a2dismod Nom_du_module

La configuration du module reste toutefois disponible dans /etc/apache2/mods-available/.

Les extensions PHP nécessitent une autre commande. Ex :

phpenmod mbstring

Sites

Pour lister les sites du serveur :

apachectl -S

Pour activer un site :

a2ensite Nom_du_site

Le fichier du site est alors visible dans /etc/apache2/sites-enabled/.

Pour le désactiver :

a2dissite Nom_du_site

Le site est dans /etc/apache2/sites-available/.

Problème d'encodage d'Apache2

Si vous rencontrez un problème d'encodage des caractères de vos pages, par exemple les caractères accentués apparaissant sous la forme "�" (<?>), c'est probablement parce qu'Apache2 déclare dans les en-têtes HTTP qui accompagnent les pages visionnées un encodage par défaut en Unicode (UTF-8) :

 Content-Type: text/html; charset=UTF-8

Tandis que les pages visionnées utilisent un autre encodage des caractères, comme par exemple Latin1 (ISO-8859-1). Même si vos documents indiquent le jeu de caractères utilisé, le paramètre donné par le serveur dans les en-têtes HTTP est prioritaire !

Pour corriger ce problème, il faudra éditer /etc/apache2/apache2.conf :

 $ sudo gedit /etc/apache2/apache2.conf

Encodage par défaut en Latin1 (ISO-8859-1)

Cherchez la ligne suivante :

 #AddDefaultCharset	ISO-8859-1

Décommentez-la en enlevant le # :

 AddDefaultCharset	ISO-8859-1

Pour ceux qui ont la locale iso-8859-15 (sinon vous pouvez faire "sudo dpkg-reconfigure locales" pour l'ajouter) et qui désirent l'utiliser par défaut, ajoutez un 5 en fin de ligne :

 AddDefaultCharset	ISO-8859-15

ainsi que la ligne suivante dans le paragraphe en-dessous :

 AddCharset ISO-8859-15 .iso8859-15  .latin15 .fr

Il ne vous reste plus qu'à mettre "fr" en première position dans la ligne LanguagePriority (juste au-dessus), et à demander à apache de relire sa configuration :

 $ sudo /etc/init.d/apache2 reload

Aucun encodage par défaut

Il est également possible de s'affranchir de tout encodage par défaut, de la manière suivante :

Cherchez la directive AddDefaultCharset :

 AddDefaultCharset	ISO-8859-1

Remplacez l'attribut par la valeur Off :

 AddDefaultCharset	Off

Là encore, on demandera à Apache de relire sa configuration :

 $ sudo /etc/init.d/apache2 reload

Maintenant, les en-têtes HTTP ne contiendront plus d'indication d'encodage des caractères. Attention : il faudra alors que chaque page indique l'encodage utilisé, car s'en remettre à la détection automatique par les navigateurs peut s'avérer assez aléatoire !

Fichiers log

Par défaut sous Debian, Apache enregistre les erreurs dans le fichier /var/log/apache2/error.log. Quand quelque chose ne fonctionne pas, ce fichier fournit souvent des pistes pour trouver la solution.

Il enregistre également toutes les requêtes dans /var/log/apache2/access.log.

Configuration de base

Sous Debian, Apache se lance automatiquement lorsqu'on l'installe et à chaque démarrage du système. Lorsqu'on modifie sa configuration, il faut lui faire prendre connaissance des changements avec la commande

/etc/init.d/apache2 reload

Pour l'arrêter, le lancer ou le relancer on utilisera la même commande avec stop, start ou restart.

Pour d'autres systèmes il faudra consulter la documentation du système ou celle d'Apache.

Configuration du serveur

La configuration du serveur se trouve dans /etc/apache2/apache2.conf. Ce fichier contient des instructions Include qui permettent de déplacer certaines parties de la configuration dans d'autres fichiers. Debian utilise cette fonctionnalité pour les modules (comme PHP) et la gestion des serveurs virtuels :

Configuration des modules

Le répertoire /etc/apache2/mods-available contient les modules installés. Le répertoire /etc/apache2/mods-enabled contient les modules activés. Les modules activés sont des liens symboliques vers les modules installés.

Pour activer ou désactiver un module, on peut manipuler directement les liens ou utiliser les commandes a2enmod et a2dismod (voir les pages de man).

Configuration des sites

De la même manière, le répertoire /etc/apache2/sites-available contient les sites web disponibles et /etc/apache2/sites-enabled les sites activés. Il en existe un préinstallé : le site default.

Les sites peuvent s'activer ou se désactiver en manipulant les liens dans sites-enabled ou en utilisant a2ensite et a2dissite.

Quelques directives classiques

La syntaxe d'Apache est assez simple. On trouve des blocs (ou contextes) comme par exemple :

<VirtualHost ...> # début de bloc VirtualHost
  ...
  <Directory ...> # début de bloc Directory
     ...
  </Directory>    # fin de bloc Directory
  ...
</VirtualHost>    # fin de bloc VirtualHost

et des directives comme par exemple

Include /etc/apache2/sites-enabled/

Les directives qui permettent de configurer le serveur lui-même sont généralement placées dans apache2.conf. Celles qui ne concernent qu'un site web sont déportées dans le fichier de configuration du site (sites-available/mon-site-web).

La directive DocumentRoot fixe la racine du serveur Web, c'est-à-dire le répertoire de base où se trouvent les documents. Par exemple avec la directive DocumentRoot /var/www/html, si le navigateur demande la page http://serveur/repertoire/fichier.txt, le serveur cherchera le fichier /var/www/html/repertoire/fichier.txt.

UserDir permet d'indiquer le répertoire personnel des utilisateurs du système. La directive UserDir public_html signifie qu'un utilisateur peut publier ses pages web personnelles dans un sous-répertoire public_html de son répertoire personnel. Pour l'utilisateur toto, c'est généralement /home/toto/public_html. Sa page d'accueil sera alors accessible par l'URL spéciale http://serveur/~toto.

DirectoryIndex indique la liste des fichiers qu'Apache cherchera à afficher si l'URL n'en précise pas. Par exemple si la configuration contient DirectoryIndex index.html index.php et qu'on demande l'URL http://serveur/repertoire/, Apache va chercher dans le répertoire un fichier index.html ou index.php. Si un de ces fichiers existe, il sera affiché. Sinon, Apache affichera soit la liste des fichiers, soit une erreur (suivant la présence de Indexes dans la directive Options).

AccessFileName définit le nom du fichier qu'on peut placer dans un répertoire pour en modifier sa configuration. Cela permet, par exemple, d'interdire localement l'affichage de la liste des fichiers, ou de protéger par mot de passe un répertoire et ses sous répertoires.

Listen indique à Apache sur quel port TCP il doit écouter. Le port par défaut du protocole HTTP est 80.

ServerName indique à Apache son nom de domaine et éventuellement son port. Il s'en sert lorsqu'il doit communiquer son adresse au client (le navigateur). C'est le cas par exemple lorsqu'on demande l'adresse http://serveur/repertoire sans slash (/) à la fin. Comme ce n'est pas une URL valide (l'URL d'un répertoire doit se terminer par un slash), Apache utilise la directive ServerName pour reconstruire une adresse avec un slash et la renvoi au client.

Gestion du nombre d'instances d'Apache

Le serveur Apache utilise plusieurs processus et prend en charge plusieurs types de stations multi-processeurs en utilisant les modules MPM (multi processing modules)^[2].

Le premier module prefork utilise des processus (pour systèmes stables ou plus anciens), le deuxième worker utilise des threads, et le dernier des threads par processus. Le dernier module perchild est en cours de développement et n'est pas recommandé.

Celui utilisé par défaut sous Linux est prefork.

Exemple commenté

La partie du fichier de configuration traitant la gestion du nombre de processus est la suivante :

##
## Server-Pool Size Regulation (MPM specific) ##

# prefork MPM
# StartServers ......... nb de processus serveur au demarrage
# MinSpareServers ...... nb minimum de processus serveurs '''libres'''  instanciés
# MaxSpareServers ...... nb maximum de processus serveurs '''libres'''  instanciés. S'il y en a MaxSpareServers+1 on les tues
# MaxClients ........... nb maximum de processus serveurs qui peuvent demarrer
# MaxRequestsPerChild .. nb maximum de requètes gérées par processus serveur.
#                        Apres MaxRequestsPerChild requètes, le processus meurt.
#                        Si MaxRequestsPerChild=0, alors le processus n'expire jamais.

<IfModule prefork.c>
  StartServers 5
  MinSpareServers 5
  MaxSpareServers 10
  MaxClients 20
  MaxRequestsPerChild 0
</IfModule>

# pthread MPM # StartServers ......... initial  number of server processes to start
# MaxClients ........... maximum number of server processes allowed to start
# MinSpareThreads ...... minimum number of worker threads which are kept spare
# MaxSpareThreads ...... maximum  number of worker threads which are kept spare
# ThreadsPerChild ...... constant number of worker threads in each server process
# MaxRequestsPerChild .. maximum number of requests a server process serves

<IfModule worker.c>
  StartServers 2
  MaxClients 150
  MinSpareThreads 25
  MaxSpareThreads 75
  ThreadsPerChild 25
  MaxRequestsPerChild 0
</IfModule>

# perchild MPM # NumServers ........... constant number of server processes
# StartThreads ......... initial  number of worker threads in each server process
# MinSpareThreads ...... minimum number of worker threads which are kept spare
# MaxSpareThreads ...... maximum  number of worker threads which are kept spare
# MaxThreadsPerChild ... maximum  number of worker threads in each server process
# MaxRequestsPerChild .. maximum number of connections per server process (then it dies)

<IfModule perchild.c>
  NumServers 5
  StartThreads 5
  MinSpareThreads 5
  MaxSpareThreads 10
  MaxThreadsPerChild 20
  MaxRequestsPerChild 0
  AcceptMutex fcntl
</IfModule>

Pour activer le module :

 a2enmod mpm_prefork

On voit ensuite les processus d'avance :

$ ps -ef |grep apache
root     32026     1  0 15:16 ?        00:00:00 /usr/sbin/apache2 -k start
www-data 32029 32026  2 15:16 ?        00:00:00 /usr/sbin/apache2 -k start
www-data 32030 32026  0 15:16 ?        00:00:00 /usr/sbin/apache2 -k start
www-data 32031 32026  0 15:16 ?        00:00:00 /usr/sbin/apache2 -k start
www-data 32032 32026  0 15:16 ?        00:00:00 /usr/sbin/apache2 -k start
www-data 32033 32026  0 15:16 ?        00:00:00 /usr/sbin/apache2 -k start

Paramétrage des répertoires

Chaque répertoire auquel Apache accède peut être configuré indépendamment (et ses sous-répertoires en héritent).

Le paramétrage d'un répertoire se met dans un "conteneur" délimité par <Directory chemin_du_répertoire> et </Directory>. La configuration s'applique au répertoire et à tous ses sous répertoires. Si un sous-répertoire possède également sa propre configuration, elle vient s'ajouter à celle du parent.

Voici quelques exemples de contrôle d'accès. Plus de détails sont donnés dans la section "Un exemple de configuration".

# Configuration du répertoire racine du système
<Directory />
  # On n'autorise aucune option particulière
  Options None

  # Aucune modification n'est autorisé dans les fichiers .htaccess
  AllowOverride None
</Directory>

# Pour la racine du serveur:
<Directory /var/www/html>
  # Quelques options
  Options Indexes Includes FollowSymLinks

  # Les options peuvent être changées dans un .htaccess
  AllowOverride All

  # Permet à tout le monde d'accéder aux documents
  Allow from All

  # Spécifie comment appliquer la règle précédente
  Order allow,deny
</Directory>

# Le répertoire contenant des exécutables CGI
<Directory /usr/lib/cgi-bin>
  AllowOverride None
  Options ExecCGI
</Directory>

Les paramètres possibles de la directive Options sont : "None", "All", "Indexes", "Includes", "FollowSymLinks", "ExecCGI", ou "MultiViews".

Gérer les pages Web personnelles

Il est possible de permettre aux utilisateurs du système de diffuser des pages personnelles sans avoir à créer un site par utilisateur. Il faut pour cela utiliser le module userdir.

Le répertoire contenant le site web doit être créé dans le home de l'utilisateur et doit être accessible en lecture pour tous. Le nom du répertoire est défini par la directive UserDir. Par défaut il s'agit du répertoire public_html.

L'adresse pour accéder à ces sites personnels est le nom de l'utilisateur précédé d'un tilde (~).

Par exemple un utilisateur toto sur le serveur www.iut.clermont.fr peut créer les pages de son site dans le répertoire /home/toto/public_html, et on pourra y accéder avec l'adresse : http://www.iut.clermont.fr/~toto/.

Il est possible de n'autoriser que certains utilisateurs à bénéficier du UserDir. Par exemple pour n'autoriser que sasa et toto à avoir un site personnel :

UserDir disabled
UserDir enabled sasa toto

Pour définir les options de ces répertoires, on peut utiliser une clause Directory pour le répertoire /home/*/public_html :

<Directory /home/*/public_html>
  Order allow,deny
  Allow from all
</Directory>

La clause UserDir public_html ne fonctionne que pour des utilisateurs ayant un compte sur le système. L'URL http://www.iut.clermont.fr/~toto ne fonctionne que si toto est un véritable utilisateur (auquel cas l'expression Unix ~toto a un sens), pas seulement si le répertoire /home/toto/public_html existe.

On peut utiliser une autre forme de UserDir pour autoriser les répertoires sans forcément qu'il y ait un compte unix associé :

UserDir /home/*/public_html

Le CGI (Common Gateway Interface) est une norme permettant à Apache d'exécuter des programmes écrits en n'importe quel langage (Bash, C, Java, Perl, PHP, Python...), du moment qu'il est exécutable et qu'il respecte certaines contraintes d'entrées/sortie.

Configurer l'accès aux scripts CGI

Pour qu'Apache prenne en charge les scripts, il est nécessaire d'effectuer un minimum de paramétrage dans la configuration du site.

Activer le module

a2enmod cgi

ScriptAlias

La directive (de httpd.conf) :

ScriptAlias /cgi-bin/ /chemin des scripts/

précise le nom du répertoire où Apache est autorisé à exécuter des scripts CGI^[3].

Exemple Unix :

ScriptAlias /cgi-bin/ /var/www/cgi-bin/

Exemple Windows, utiliser le format URL (pas d'antislash) :

ScriptAlias /cgi-bin/ "C:/wamp/bin/apache/apache2.2.27/cgi-bin/"

En fait le chemin /cgi-bin/ n'existe pas vraiment, il est dirigé vers le chemin des scripts défini par la directive, et cela permet d'écrire des URL comme http://serveur/cgi-bin/mon_script.

ExecCGI

La clause suivante active l'option ExecCGI dans /var/www/cgi-bin, ce qui autorise Apache à exécuter les scripts sur le serveur :

<Directory /var/www/cgi-bin>
  Options ExecCGI
</Directory>

Par exemple : vous écrivez un script essai.cgi, et vous voulez que /home/httpd/cgi-bin contienne les scripts.

Il faut donc au moins écrire :

<Directory /home/httpd/cgi-bin>
  Options ExecCGI
</Directory>

L'appel à un script essai.cgi sera effectué par l'URL : http://serveur/cgi-bin/essai.cgi

AddHandler

Cette clause permet de choisir les extensions de fichiers qui seront autorisés, ex :

AddHandler cgi-script .cgi .exe .pl .py .vbs

Récapitulatif

Exemple complet sur Windows, dans la configuration Apache :

ScriptAlias /cgi-bin/ "E:/www/cgi-bin/"
<Directory "E:/www/cgi-bin/">
  Options FollowSymLinks Indexes
  AllowOverride All
  Order deny,allow
  Allow from all
  Require all granted		
</Directory>

Dans E:/www/cgi-bin/.htaccess :

AddHandler cgi-script .cgi .exe .pl .py .vbs

Écrire un programme CGI

La contrainte principale concerne la sortie du programme. Si un programme CGI génère des données sur sa sortie standard, il doit les précéder d'un en-tête HTTP permettant de les identifier.

Bash

Voici un exemple de programme CGI écrit en bash :

#!/bin/bash

# Header
echo "Content-type: text/html"

# Fin du header
echo ""

# Contenu à afficher dans le navigateur
echo "<html><body>Hello World!</body></html>"

Ce script génère une page HTML.

Perl

#!c:/perl/perl/bin/perl.exe -w
use CGI;
my $query = new CGI;
my $Name = $query->param('Name');
print $query->header();
print "Hello World!"

Python

#!C:\Program Files (x86)\Python\python.exe
# -*- coding: UTF-8 -*-
print "Content-Type: text/plain;charset=utf-8"
print
print "Hello World!"

Pour plus de détails voir : Programmation Python/L'interface CGI.

VBS

Pour Windows^[4].

'!c:/windows/system32/cscript //nologo
Wscript.Echo "Content-type: text/html" & vbLF & vbLF
WScript.Echo "Hello World!"
Wscript.Quit 0

Références

Le module PHP

PHP a normalement été intégré au serveur Apache sous forme d'un module chargeable situé comme tous les autres modules d'Apache dans /usr/lib/apache2/modules.

Les fichiers /etc/apache2/mods-availiable/php5.load et /etc/apache2/mods-availiable/php5.conf contiennent les directives LoadModule et AddType qui permettent à Apache d'exécuter du PHP quand on demande un fichier se terminant par .php. Ils doivent être liés dans /etc/apache2/mods-enabled pour activer PHP. On peut utiliser pour cela la commande a2enmod.

En marge de Apache, PHP possède lui aussi son fichier de configuration, souvent /etc/php.ini. Il n'est pas particulièrement conseillé d'y intervenir sauf si on sait ce que l'on fait. On peut néanmoins y observer que PHP prend bien en compte le module d'extension MySQL, contenant les fonctions d'accès au "moteur" de base de données MySQL (qui a dû être installé à part), par la présence de extension=mysql.so.

En cas de modification d'un fichier de configuration, comme PHP fonctionne comme module d'Apache, il faut redémarrer Apache pour qu'il réinitialise PHP par la lecture de php.ini.

/etc/init.d/apache2 restart

Principe

Pour protéger un répertoire en particulier (et ses sous-répertoires), il suffit de placer un fichier nommé .htaccess dedans. Apache appliquera instantanément ensuite les règles qu'il contient, uniquement dans cette arborescence. La syntaxe pour définit ces règles (ex : redirections ou protections) est la même que dans les vhosts, sauf que cela n'affectera que le répertoire du fichier .htaccess (donc pas de clause Directory).

L'explorateur de fichiers de Windows ne permet pas de rebaptiser des fichiers commençant par des points, il faut donc passer par un éditeur de texte.

Installation

Pour autoriser les .htaccess dans le .conf du site, utiliser AllowOverride^[1] :

AllowOverride All

Pour les interdire :

AllowOverride None

Information :

Il est possible de tester ses directives en ligne (sans redémarrer Apache), par exemple sur https://htaccess.madewithlove.be/.

Références

↑ http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride

Serveurs virtuels (virtual hosts)

Principe du vhost

Apache peut gérer plusieurs sites web simultanément. Ils seront tous accessibles à partir de la même adresse IP et du même port.

Pour les différencier, Apache se sert de l'adresse demandée par le navigateur.

Par exemple si site1.com et site2.com pointent sur la même adresse IP, les URL http://site1.com/ et http://site2.com/ aboutiront sur le même serveur.

Mais au moment de la requête, le navigateur précise qu'il a demandé l'adresse http://site1.com/ ou http://site2.com/.

Apache se sert de cette information pour savoir quel site afficher. On parle de serveur virtuel ou virtual host (vhost).

Configuration

Pour indiquer à Apache quel site correspond à un nom de domaine, on utilise une section <VirtualHost *>. Sous Debian, il y a généralement un fichier par section VirtualHost dans le répertoire /etc/apache2/sites-available.

La section devra contenir une directive ServerName^[1] qui indiquera le nom associé à ce serveur virtuel.

Elle pourra également contenir une directive ServerAlias si on veut que d'autres noms aboutissent à ce site.

Par exemple^[2] :

En Windows éditer C:\Program Files (x86)\EasyPHP\binaries\conf_files\httpd.conf
En Unix-like : /etc/apache2/httpd.conf ou /etc/apache2/apache2.conf

<VirtualHost _default_:80>
     ServerAdmin admin@site1.com
     DocumentRoot /home/site1/public_html
     ServerName site1.com
     ServerAlias www.site1.com
</VirtualHost>

<VirtualHost MonIP2:80>
     ServerAdmin admin@site2.com
     DocumentRoot /home/site2/public_html
     ServerName site2.com
     ServerAlias www.site2.com
     AccessLog /home/site2/access.log
     ErrorLog /home/site2/error.log
     <Directory /home/site2/public_html>
         AllowOverride All
     </Directory>
</VirtualHost>

Pour affecter tous les sites et ports, remplacer ceux-ci dans la première balise par *.

En cas d'erreur Apache d'ajouter une "directive" lors de sa relance, ajouter une ligne NameVirtualHost MonIP:MonPort.

La documentation d'Apache sur les serveurs virtuels^[3] contient des informations détaillées sur le sujet.

Pour que ce serveur virtuel fonctionne, il est impératif que les noms site1.com et www.site1.com soient connus par la machine qui tente d'y accéder (celle qui lance le navigateur).

Pour cela il y a plusieurs méthodes :

acheter le nom de domaine en question et le configurer pour qu'il pointe sur la bonne adresse IP
utiliser un serveur DNS qui renverra la bonne IP pour ce domaine
modifier le fichier hosts sur la machine cliente pour faire correspondre ce domaine à la bonne adresse IP (voir le livre Installation et configuration d'une carte réseau)

Include

Pour éviter de copier-coller les mêmes lignes dans plusieurs vhost, il est possible de les inclure avec la directive "include"^[4]. Exemple :

Include /etc/apache2/common.conf

ProxyPassMatch

Pour utiliser les daemons PHP-FPM (qui écoutent sur le port 9000), Apache doit rediriger les connexions avec ProxyPassMatch^[5]^[6]. Ex :

 ProxyPassMatch ^/(.*\.php)$ fcgi://127.0.0.1:9000/var/www/mon_site/$1

Références

Exemples de configuration

Voici quelques exemples de configuration. L'ensemble des directives possibles peut être consulté ici : http://httpd.apache.org/docs/2.2/mod/directives.html

Pensez que les directives doivent parfois se trouver dans apache2.conf, parfois dans le contexte VirtualHost d'un site donné.

ServerType

ServerType standalone

Cette ligne indique si le serveur Apache se lance en 'autonome' (standalone) ou via inetd (TCP_WRAPPER). Pour la plupart des configuration, c'est en standalone. Cette directive a disparu de Apache2, qui dispose d'un autre moyen pour définir cela. Le comportement est en fait choisi d'après le MTM (Multi-processing module) choisi.

ServerRoot

ServerRoot /etc/apache2

(config serveur uniquement, pas dans un VirtualHost)

Vous indiquez ici le répertoire d'installation d'Apache. Normalement les scripts d'installation ont bien renseigné cette ligne. Vérifiez quand même.

LockFile

LockFile /var/run/httpd.lock

(config serveur uniquement, pas dans un VirtualHost)

Laissez cette ligne comme elle est, c'est à dire en commenté pour 90% des cas (# devant).

PidFile

PidFile /var/run/httpd.pid

(config serveur uniquement, pas dans un VirtualHost)

Vérifiez bien que cette ligne est décommentée. Elle indique au script de démarrage d'enregistrer le numéro de processus d'Apache pour que lors de l'arrêt du système le processus Apache soit stoppé correctement.

ScoreBoardFile

ScoreBoardFile /var/run/httpd.scoreboard

(config serveur uniquement, pas dans un VirtualHost)

Ce fichier stocke des informations pour le bon fonctionnement d'Apache.

Timeout

Timeout 300

(config serveur uniquement, pas dans un VirtualHost)

Temps en secondes avant que le serveur n'envoie ou ne reçoive un timeout . Quand le serveur attend une "réponse" (ex : script CGI, connexion\ldots), si au bout de ce temps, il ne reçoit pas de réponse, il va s'interrompre et prévenir l'utilisateur de l'erreur. Laissez cette valeur par défaut à moins que vous n'effectuiez des traitements dépassant cette limite. Ne pas monter trop haut cette valeur non plus car si le programme externe à "planté", ou si une erreur est survenue, vous risquez de rendre inaccessible le serveur Apache pour trop de temps (il est toujours désagréable d'attendre pour rien).

KeepAlive

KeepAlive on

Autorise ou non les connexions persistantes (plusieurs requêtes par connexions). En fait cela permet aux utilisateurs de votre serveur de lancer plusieurs requêtes à la fois, et donc d'accélérer les réponses du serveur. Laissez cette valeur par défaut la plupart du temps. Pour de petits serveurs laissez cette option sur on . Pour un serveur très sollicité, dès que vous vous apercevez que le système ralentit énormément ou devient indisponible assez souvent, essayez avec la valeur off . Mais avant, essayez de baisser la valeur de l'option suivante.

MaxKeepAliveRequests

MaxKeepAliveRequests 100

En combinaison avec l'option précédente, indique le nombre de requêtes pour une connexion. Laissez cette valeur assez haute pour de très bonnes performances. Si vous mettez 0 comme valeur, vous en autorisez en fait un nombre illimité (attention donc). Laissez la valeur par défaut là aussi.

KeepAliveTimeout

KeepAliveTimeout 15

Valeur d'attente en secondes avant la requête suivante d'un même client, sur une même connexion, avant de renvoyer un timeout. Là aussi laisser la valeur par défaut.

MinSpareServers & MaxSpareServer

MinSpareServers 5
MaxSpareServers 10

(config serveur uniquement, pas dans un VirtualHost)

Ces valeurs servent à l'auto-régulation de charge du serveur. En fait le serveur Apache contrôle lui même sa charge, suivant le nombre de clients qu'il sert et le nombre de requêtes que demandent chaque client. Il fait en sorte que tout le monde puisse être servi et ajoute tout seul un certain nombre d'instances Apaches "idle", c'est-à-dire qui ne font rien, mais sont prêtes à servir de nouveaux clients qui se connecteraient. Si ce nombre est inférieur à MinSpareServers il en ajoute une (ou plusieurs). Si ce nombre dépasse la valeur de MaxSpareServer il en arrête une (ou plusieurs). Ces valeurs par défaut conviennent à la plupart des sites.

Listen

Listen 3000
Listen 12.34.56.78
Listen 12.34.56.78:3000

Indique au serveur des ports ou des adresses IP (il y en a une par interface réseau du serveur!), ou les deux, où il doit "écouter" les demandes de connexions, EN PLUS de l'adresse et port par défaut. Voir la directive VirtualHost plus loin.

BindAdress

BindAdress *

Redondant avec Listen, cela permet de spécifier des adresses IP d'interfaces réseau, pour écouter les requêtes. Cette directive a disparu dans Apache 2.

Port

Port 80

Redondant avec Listen, cela permet de spécifier le port d'écoute (80 par défaut). Cette directive a disparu dans Apache 2.

LoadModule, ClearModuleList & AddModule

LoadModule xxxxxx.mod libexec/yyyyyy.so
ClearModuleList
AddModule zzzz.c

(config serveur uniquement, pas dans un VirtualHost)

Support pour les modules DSO (Dynamic Shared Object). LoadModule permet de charger un module. Avant Apache 2, les directives ClearModuleList et AddModule permettaient de spécifier l'ordre d'exécution des modules, à cause de problèmes de dépendances. Apache 2 peut maintenant faire cela automatiquement, car les APIs de modules leur permet de spécifier eux-mêmes leur ordre. Sous Apache 1.*, il faut cependant y prêter une grande attention, et le maintenir à jour à l'ajout de tout nouveau module.

ExtendedStatus

ExtendedStatus on

(config serveur uniquement, pas dans un VirtualHost)

Indique si le serveur doit renvoyer des informations complètes de statut (on ) ou des informations réduites (off ). off par défaut. Laissez cette valeur par défaut sauf en cas de développement et de debuggage.

User & Group

User nobody
Group nobody

Une fois le serveur démarré, il serait dangereux de lui laisser les droits root pour répondre aux requêtes. Il est donc possible de modifier l'utilisateur et le groupe du processus pour lui donner un minimum de droits sur la machine du serveur. (En fait si quelqu'un arrive à "exploiter" votre serveur, par exemple s'il arrive à faire exécuter du code par le serveur Apache, il hérite des droits du serveur lui même. Donc si c'est nobody il n'a aucun droit spécifique. Si c'est root ou un utilisateur réel, il aura alors des droits lui permettant d'endommager votre système.)

ServerAdmin

ServerAdmin root@localhost.domainname

Adresse e-mail de l'administrateur du site. Cette adresse est affichée par le serveur par exemple en cas d'erreur, pour que les utilisateurs puissent en avertir l'administrateur.

ServerName

ServerName www.domainname

Adresse que le serveur va renvoyer au client web. Il est préférable de mettre une adresse résolue par DNS au lieu du nom de la machine réelle, pour que les visiteurs ne voient pas le nom réel de votre machine (utile pour la sécurité aussi).

DocumentRoot

DocumentRoot /var/lib/apache/htdocs

Répertoire racine ou se trouve vos pages Web.

DirectoryIndex

DirectoryIndex index.html index.htm index.php index.php5

Indique le ou les fichiers à charger lorsqu'on accède à un répertoire sans préciser de fichier. Dans cet exemple, si on accède à http://example.com/repertoire/, Apache cherchera un des fichiers mentionnés (index.html, index.htm...) et s'il en trouve un il l'affichera. S'il n'en trouve pas, il affichera la liste des fichiers ou interdira l'accès (suivant la présence ou non de l'option Indexes sur le répertoire).

AccessFileName

AccessFileName .htaccess

Nom du fichier des règles d'accès pour les règles AllowOverride. Un conseil: placez comme vu précédemment une règle file du style:

<Files .ht*>     #pour interdire aux visiteurs de voir le contenu des Order allow,deny
                 #fichiers .ht qui contiennent les règles de
  Deny from all  #sécurité.
</Files>

CacheNegotiatedDocs

#CacheNegotiatedDocs

Autorise ou pas les proxies à mettre en cache les documents (pour autoriser, enlevez le commentaire # en début de ligne)

UseCanonicalName

UseCanonicalName On

Placé sur on , réécrit l'URL par rapport aux valeurs Server et Port spécifiées plus haut dans le fichier httpd.conf.

Sur off , l'URL reste celle donnée par le client.

Attention, mettez sur on si vous utilisez des CGI avec des variables SERVER_NAME, car si l'URL du client n'est pas la même que celle du CGI, votre script CGI ne marchera pas.

DefaultType

DefaultType text/plain

Type mime par défaut que le serveur renvoie au clients. Convient dans la plupart des cas.

HostNameLookups

HostNameLookups off

Sur on , le serveur le nom du client grâce à une requête DNS inverse. Sinon, il se contente de l'adresse IP, ce qui génère beaucoup moins de trafic réseau.

ErrorLog

ErrorLog /var/log/error_log

Chemin complet du fichier où les erreurs seront enregistrées.

LogLevel

LogLevel warn

Niveau d'enregistrement des erreurs avec comme valeurs possibles, par ordre décroissant d'importance, donc croissant en bavardage:

`emerg`	urgence : le serveur devient inutilisable
`alert`	une intervention est nécessaire
`crit`	erreurs critiques (accès réseau impossible par exemple)
`error`	les erreurs dans les pages, scripts
`warn`	les erreurs non bloquantes (pages mal codées, scripts comportant des erreurs non blocantes...
`notice`	événement normal mais méritant d'être remarqué
`info`	informations utiles (comme "serveur très chargé")
`debug`	Enregistre TOUT ce qui peut se passer sur le serveur

Le niveau crit est le minimum recommandé, et on monte généralement à warn.

ServerSignature

ServerSignature on

`on`	ajoute la signature (version, OS…) du serveur lorsqu'il génère des pages lui-même (index manquant, erreur de script, etc.)
`off`	ne montre que l'erreur.
`email`	ajoute un lien vers l'email définit par `ServerAdmin`

Alias

Alias faux_nom nom_réel

permet de faire des alias de répertoires (des liens en quelque sorte) (similaire à ScriptAlias /cgi-bin chemin_complet_des_cgi

AddType

AddType type extensions

(sous Apache2, cette directive devrait être dans un fichier mods-availabe/nom_module.conf, au lieu de apache2.conf)

Spécifie que des fichiers utilisant de telles extensions sont du type précisé. Cela permet de décider quoi en faire. Pour ajouter le support PHP, le fichier mods-enabled/php5.conf contient par exemple :

  AddType application/x-httpd-php .php .phtml .php3
  AddType application/x-httpd-php-source .phps

AddHandler

AddHandler cgi-script .cgi

Pour utiliser les scripts CGI.

ProFTPD

FTP est un protocole d'échange de fichiers. Un serveur FTP met à disposition certains répertoires du disque, et gère une authentification par mot de passe. On se connecte à ce serveur avec un client FTP.

Ce document présente la configuration d'un serveur ProFTPd sous Debian^[1]. Sa gestion des droits d'accès et sa configuration sont faits pour ressembler à celles d'Apache^[2].

Installation et lancement

Sous Debian, ProFTPD est disponible dans un package et peut s'installer avec la commande

apt-get install proftpd

Il est aussi possible de le configurer pour ses propres besoins à partir des sources. Ceci permet de spécifier les modules à utiliser.

tar zxvf proftpd-1.x.x.tar.gz
cd proftpd-1.x.x
./configure --with-modules=mod_ratio:mod_sql
make
make installproftpd

Il se lance automatiquement à l'installation et au démarrage du système.

Le script qui permet de le lancer, l'arrêter ou le relancer est /etc/init.d/proftpd.

Fichier de configuration

Le principal fichier de configuration est /etc/proftpd/proftpd.conf.

Cette configuration n'affecte que le service qui écoute au port mentionné (21 par défaut). Pour affecter d'autres ports (ex : 22 pour SFTP), il est impossible de l'ajouter sur la ligne "Port 21" : voir plus bas.

L'ensemble des directives sont décrites ProFTPD^[3]. Les commandes principales sont les suivantes :

ServerName "''nom''"
description = Indique le nom du serveur qui s'affichera sur les clients

AccessGrantMsg "''message''"
description = Message de bienvenue.
commentaires = Le message peut contenir des jokers comme %u (ici le nom de l'utilisateur)

<Limit …>…</Limit>
description = Autorise ou refuse l'utilisation de certaines commandes du protocole FTP.
commentaires =
Par exemple la section suivante n'autorise la commande MKDIR qu'aux utilisateurs foo et bar :

<Limit MKDIR>
  Allow foo bar
  Deny All
</Limit>

ServerType ''type''
description = Détermine la manière dont le serveur reçoit les connexions réseau.
commentaires = 
Si le type est ''standalone'', un processus père sera lancé et écoutera sur le réseau. Si le type est ''inet'', le serveur devra être lancé par inetd (TCP_WRAPPER).
Dans tous les cas il y aura un processus de lancé par connexion FTP.

MaxInstances 30
description = Limite le nombre de processus simultanés autorisés

User nobody
Group nobody
description = indiquent que le serveur doit s'exécuter avec les identifiants de groupe et d'utilisateur nobody

ExtendedLog /var/log/ftp.log
description = spécifie le nom de fichier log

Umask 022
description = précise les droits à '''enlever'''  aux fichiers créés sur FTP. 022 signifie que les droits d'écriture sont enlevés au groupe et à ''others''  pour tout nouveau fichier.

AllowOverwrite on
description = autorise un utilisateur à écraser un fichier qui lui appartient.

UseFtpUsers on
description = active l'utilisation du fichier /etc/ftpusers qui donne la liste des utilisateur n'ayant '''pas'''  accès au serveur ftp.

AllowUser ''liste-d'utilisateurs''
description = à placer dans un contexte <Limit ...>...</Limit> définit qui est autorisé à exécuter la commande du bloc ''Limit'' courant.

DenyUser ''liste-d'utilisateurs''
description = à placer dans un contexte <Limit ...>...</Limit> définit qui n'est pas autorisé à exécuter la commande du bloc Limit courant.

AllowStoreRestart
description = autorise les clients à reprendre les uploads vers le serveur.

DefaultChdir /var/ftp
description = Indique le répertoire par défaut du serveur.
commentaires = Les utilisateurs se trouvent placés dans ce répertoire lors de la connexion.

DefaultRoot /var/ftp
description = déclare ce répertoire comme la racine du système de fichiers.

UserRatio
description = permet la gestion des ratios.
commentaires =
UserRatio ''nom''  2 10 5 4096</code> indique que l'utilisateur ''nom''  a le droit de récupérer 2 fichiers sur le serveur à chaque fois qu'il en déposera un.
On lui octroie pour commencer un crédit de 10 fichiers.
Par ailleurs, pour 1 octet déposé, il pourra recevoir 5 octets et il détient un crédit de 4ko. À la place d'un nom on peut aussi utiliser * qui définit des ratios par défaut.

SaveRatios on
description = sert à préciser que nous souhaitons sauvegarder les crédits de chaque utilisateur entre deux sessions.

RatioFile /ratio/RatioFile
RatioTempFile /ratio/RatioTempFile
description = indiquent les noms de fichiers permettant de sauvegarder des informations sur les ratios des utilisateurs.

FileRatioErrMsg "Vous n'avez pas suffisamment télédéchargé de fichiers"
ByteRatioErrMsg "Vous n'avez pas assez télédéchargé d'octets"
description = indiquent qu'un utilisateur a dépassé son quota par des messages.

<Directory ''répertoire''> … </Directory>
description = Cette section indique les droits sur le répertoire et sur tout ce qu'il contient.
commentaires =
Par exemple :

<Directory /var/ftp/ratio>
  <Limit ALL>
    Deny ALL
  </Limit>
  HideNoAccess on
</Directory>
Ici, nous interdisons toute opération sur le répertoire ratio grace à la section <Limit ALL>.

 
HideNoAccess
description = Cache tous les éléments inaccessibles aux utilisateurs.

<Anonymous ''répertoire''>…</Anonymous>
description = Configure l'accès anonyme
commentaires =
Exemple :

<Anonymous /home/ftp>
  # Après la connexion anonyme, passe sous l'utilisateur/groupe ftp.
  User ftp
  Group ftp

  # Fait correspondre le login "anonymous" au compte unix "ftp"
  UserAlias anonymous ftp

  # Autorise les comptes sans "shell", c'est souvent le cas du compte "ftp"
  RequireValidShell off

  # Interdit l'écriture partout
  <Directory *>
    <Limit WRITE>
      DenyAll
    </Limit>
  </Directory>

  # Autorise l'écriture dans "incoming" mais pas la lecture
  <Directory incoming>
    <Limit READ >
      DenyAll
    </Limit>
    <Limit STOR>
      AllowAll
    </Limit>
  </Directory>
</Anonymous>

Pour que le serveur prenne en compte le nouveau fichier de configuration, il faut recharger le démon avec: /etc/init.d/proftpd restart

Exemple de fichier proftpd.conf:

# This is a basic ProFTPD configuration file (rename it to # ’proftpd.conf’ for
# actual use. It establishes a single server
# It assumes that you have a user/group
# "nobody" for normal operation.
ServerName "ProFTPd Linux Service"
ServerType standalone
DefaultServer on

# Pour autoriser les clients à résumer les téléchargements, très utile.
# Remember to set to off if you have an incoming ftp for upload.
AllowStoreRestart on

# Port 21 is the standard FTP port.
Port 45000

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022

# Limitation de la bande passante en lecture:
RateReadBPS 14000

# To prevent DoS attacks, set the maximum number of child pro cesses
# to 30. If you need to allow more than 30 concurrent connexions
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of pro cesses per service
# (such as xinetd)
MaxInstances 30

# Set the user and group that the server normally runs at. User nobody
Group nogroup

# Nombre maximum de clients
# MaxClients 3

# Number of Max Clients per host
# MaxClientsPerHost 1

# Nombre maximums de tentatives de login
MaxLoginAttempts 3

# Message d’accueil après une connexion réussie
AccessGrantMsg "Bienvenue %u chez moi!"

#Pour ne pas donner d’info sur le serveur
DeferWelcome off

#Règles pour limiter les commandes ...
<Limit MKD RNFR RNTO DELE RMD STOR CHMOD SITE CHMOD SITE XCUP WRITE XRMD PWD XPWD>
  DenyAll
</Limit>

<Global>
  DefaultRoot /var/ftp
  AllowOverwrite yes
  MaxClients 3
  MaxClientsPerHost 1
  UseFtpUsers on
  AllowForeignAddress on
  ServerIdent on "ProFTP DuF’s Server Ready"
  AccessGrantMsg "Bienvenue sur le serveur, %u"
</Global>

# Serveur Virtuel pour écriture
<VirtualHost ftp.duf.com>
  ServerName "Mon serveur FTP virtuel numero 1"
  Port 46000
  Maxclients 3
  MaxClientsPerHost 1
  DefaultRoot /var/ftp
  AccessGrantMsg "Bienvenue"
</VirtualHost>

Dans ce fichier on peut rajouter les lignes suivantes :

  # permet à l'utilisateur même si il ne dispose pas d'un shell valide (ex: /bin/false)
  RequireValidShell    off
   
  # Verrouille l'utilisateur dans son répertoire par défaut
  DefaultRoot          ~
  
  # Pour ne pas afficher le nom du serveur FTP et son numéro de version
  ServerIdent          off
  # on peut également afficher une autre chaîne de caractères :
  #ServerIdent          on "Serveur FTP du Creufop"

Accès FTP anonyme

Pour faire un serveur FTP anonyme, il suffit de rajouter les lignes suivantes dans /etc/proftpd/proftpd.conf :

  <Anonymous ~ftp>
     User                               ftp
     Group                              nogroup
     # We want clients to be able to login with "anonymous" as well as "ftp"
     UserAlias                  anonymous ftp
  
     RequireValidShell          off
  
     # Limit the maximum number of anonymous logins
     MaxClients                 10
  
     # We want 'welcome.msg' displayed at login, and '.message' displayed
     # in each newly chdired directory.
     DisplayLogin                       welcome.msg
     DisplayChdir          .message
  
     # Limit WRITE everywhere in the anonymous chroot
     <Directory *>
       <Limit WRITE>
         DenyAll
       </Limit>
     </Directory>
  
     # Uncomment this if you're brave.
     # <Directory incoming>
     #   # Umask 022 is a good standard umask to prevent new files and dirs
     #   # (second parm) from being group and world writable.
     #   Umask                          022  022
     #            <Limit READ WRITE>
     #            DenyAll
     #            </Limit>
     #            <Limit STOR>
     #            AllowAll
     #            </Limit>
     # </Directory>
  
  </Anonymous>

Création d'un utilisateur FTP

Pour créer un utilisateur qui aura uniquement le droit de faire du FTP, on crée l'utilisateur en indiquant comme shell '/bin/false'.

Dans le cas d'un webmaster, l'idéal est de le faire directement atterrir dans le répertoire où est situé le site web qu'il administre. Pour faire ceci, on indique le répertoire contenant le site web comme étant le répertoire de travail de l'utilisateur.

 # adduser --shell /bin/false --home /var/www/site bob

Cacher un dossier / fichier

Pour rendre un dossier invisible un fichier / dossier(ex Maildir), il faut ajouter au proftpd.conf :

 <Directory ~>
     Hidefiles Maildir
 </Directory>

Clients FTP

Pour tester le serveur FTP, il convient à présent d'utiliser un logiciel client FTP, si possible depuis une autre machine pour tenir compte du pare-feu.

Il existe de très nombreux clients FTP. Certains sont en mode graphique comme FileZilla, d'autres en mode texte comme la commande shell ftp.

Commande ftp

Le client le plus simple et le plus répandu est la commande ftp. Elle existe également sous Windows en ligne de commande.

Les commandes disponibles sont décrites dans la page de man. Les principales sont : help, open, ls, get, put...

Navigateurs

Les navigateurs internet permettent également de se connecter à un serveur FTP, généralement en lecture seule.

Pour une connexion anonyme, on pourra utiliser ftp://serveur/ ou ftp://serveur/chemin.
Pour se connecter avec un mot de passe, on utilisera ftp://utilisateur:mot_de_passe@serveur/.

SFTP

Généralement c'est le service SSH qui écoute le port 22. Par exemple sur Ubuntu, OpenSSH configure un SFTP avec la même clé publique que SSH, dans :

vim /etc/ssh/sshd_config

Il utilise ainsi la commande :

/usr/lib/sftp-server

Pour tester s'il fonctionne depuis le serveur, il existe la commande :

sftp localhost

Toutefois, ProFTPD peut également fournir ce service^[4].

FTPS

Pour activer le protocole FTPS :

 vim /etc/proftpd/proftpd.conf # Décommenter la ligne "Include /etc/proftpd/tls.conf"
 vim /etc/proftpd/tls.conf     # Ajouter le code ci-dessous
      <IfModule mod_tls.c>
        TLSEngine on
        TLSRSACertificateFile /etc/proftpd/ssl/proftpd-rsa.pem
        TLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd-key.pem
      </IfModule>
 /etc/init.d/proftpd restart

Pour plus d'information sur les certificats .pem, voir Apache/HTTPS.

Problèmes connus

Logs

Proftpd stocke ses logs dans les fichiers suivants :

TransferLog /var/log/proftpd/xferlog
SystemLog   /var/log/proftpd/proftpd.log

En voici un extrait :

cat /var/log/proftpd/xferlog
 Wed Feb  6 12:16:12 2008 1 lns-bzn-51f-85-78-78-5.adsl.proxad.net 1129 /home/user1/fichier1.txt a _ i r user1 ftp 0 * c
 Thu Feb  6 15:23:49 2008 1 84-74-216-148.dclient.hispeed.ch 11743 /var/www/index.html a _ i r user2 ftp 0 * c
 Fri Feb  6 23:46:02 2008 1 69.183.30.97.adsl.snet.net 4572542 /home/user2/toto.pdf a _ i r user2 ftp 0 * c
 ...

cat /var/log/proftpd/proftpd.log
 2015-10-08 16:17:44,302 ftp.example.com proftpd[21992] ftp.example.com: ProFTPD killed (signal 15)
 2015-10-08 16:17:44,303 ftp.example.com proftpd[21992] ftp.example.com: ProFTPD 1.3.5 standalone mode SHUTDOWN
 2015-10-08 16:17:44,364 ftp.example.com proftpd[28832] ftp.example.com: ProFTPD 1.3.5 (stable) (built Fri May 22 2015 00:17:07 UTC) standalone mode STARTUP
 2015-10-08 16:18:09,365 ftp.example.com proftpd[29111] ftp.example.com (lns-bzn-51f-85-78-78-5.adsl.proxad.net): FTP session opened.
 2015-10-08 16:18:09,575 ftp.example.com proftpd[29111] ftp.example.com (lns-bzn-51f-85-78-78-5.adsl.proxad.net): user1 chdir("/home/user2") failed: Permission non accordée
 2015-10-08 16:18:09,577 ftp.example.com proftpd[29111] ftp.example.com (c233e21e.fsp.oleane.fr[194.51.226.30]): FTP session closed.

FileZilla ne voit pas la clé privée

Il faut la renommer en .ppk.

530 Authentification incorrecte

Si les logs renvoient SECURITY VIOLATION: root login attempted (en FTP avec un compte qui peut marcher en SFTP par ailleurs), c'est qu'il faut modifier /etc/proftpd/proftpd.conf avec RootLogin on.

Sinon, s'ils donnent Invalid shell il faut en définir un valide dans /etc/passwd.

Enfin, si un copié-collé du login et du mot de passe ne fonctionne pas, contacter l'administrateur du serveur pour recréer le compte.

Aucune permission

Généralement ce phénomène s'accompagne du message "425 Can't open data connection for transfer". Il peut être résolu en cochant le mode passif dans le troisième onglet du site.

clé de l'hôte inconnue ou key fingerprint is xxx. Are you sure you want to continue connecting (yes/no)?

Avertissement sur FileZilla

En SFTP, il s'agit d'un avertissement sur la clé de cryptage qui peut survenir avec ProFTPD ou OpenSSH. Il peut planter certains scripts ou logiciels de transfert comme Webdrive, qui s'arrêtent sans l'afficher. Mais avec FileZilla il suffit de l'accepter une fois pour ne plus le revoir.

EAI_NODATA - Aucune adresse associée à ce nom de nœud

Problème de DNS, ou bien /etc/hosts.

ECONNREFUSED - Connexion refusée par le serveur

Si telnet fonctionne, c'est sûrement le certificat SSL qui a expiré ou le pare-feu.

Sinon, si telnet ne fonctionne pas sans aucune règle iptables, mais passe sur le port 22, c'est peut-être la directive Port 21 de /etc/proftpd/proftpd.conf à refaire. Ou sinon, dans le client FileZilla, préciser le chiffrement pour ce site en "Connexion FTP simple (non sécurisé)".

Handshake failed (40)

Se produit depuis 2016 sur FileZilla quand une connexion FTP (par TLS ou pas) tombe sur un certificat invalide. Mais avec CoreFTP cela fonctionne.

Impossible d'établir une connexion au serveur

Voir ci-dessous : #Serveur introuvable.

Refused user root for service proftpd

Cela peut se produire après l'installation ou une mise à jour. Si un tail /var/log/proftpd/proftpd.log renvoie USER root (Login failed): User in /etc/ftpusers, commenter l'utilisateur dans ce fichier de blacklist.

Serveur introuvable

Il s’agit probablement d’une panne de DNS, il faut alors remplacer l'URL par l'IP.

Sinon, il s’agit peut-être d’une règle de pare-feu. Pour le vérifier, taper la commande telnet IP 21. Si c'est bloqué ou affiche "délai d’attente dépassé", ou "connexion refusée" il faut ouvrir le flux FTP du pare-feu client.

Sinon, il faut donc vérifier que le client FTP n’est pas configuré en SFTP (port 22 au lieu de 21) ou vice-versa.

Si un message d’erreur survient après une connexion "PASV" : il faut désactiver le mode passif. Par exemple dans Filezilla : Édition, Paramètres, FTP, décocher la case.

Sinon, il faut regarder les logs du serveur (ex : iptables).

Références

DHCP

Le protocole DHCP (pour Dynamic Host Configuration Protocol) est un protocole réseau dont le rôle est d'assurer la configuration automatique des paramètres réseau d'une station, notamment en lui assignant automatiquement une adresse IP et un masque de sous-réseau.

Le protocole DHCP est très souvent mis en œuvre par les administrateurs de parc de stations car il offre l'énorme avantage de centraliser la configuration des stations sur une unique machine : le serveur DHCP. Le principal danger de DHCP est qu'en cas de panne du serveur DHCP, plus aucune station n'accède au réseau.

Il y a deux utilisations principales d'un serveur DHCP :

attribuer une configuration fixe à certains postes (on les reconnaît grâce à leur adresse MAC)
et attribuer une configuration dynamique aux postes inconnus.

On peut par exemple donner une adresse IP fixe à certains serveurs, et attribuer des adresses variables aux autres postes. Le protocole est prévu pour qu'un poste qui revient sur le réseau récupère la même adresse qu'il avait la première fois. Elle lui est réservée un certain temps (le lease time).

Configuration

Le fichier de configuration principal est /etc/dhcp/dhcpd.conf. Sa syntaxe est décrite dans man dhcpd.conf.

Il possède des options globales, généralement placées au début, et des sections pour chaque hôte ou réseau à configurer.

Après chaque modification de la configuration, il faut relancer le serveur :

/etc/init.d/isc-dhcp-server restart

S'il ne se relance pas, le détail de l'erreur se trouve généralement dans /var/log/syslog

Interfaces

Pour choisir les interfaces sur lesquels le serveur est lancé, il faut modifier /etc/default/isc-dhcp-server en indiquant par exemple

INTERFACES="eth1 eth2"

Il est obligatoire d'avoir une section "subnet" (voir ci-dessous) pour le réseau de chaque interface.

Adresse dynamique

Pour configurer une plage d'adresses à attribuer dynamiquement aux adresses MAC inconnues, on utilise une section subnet dans dhcpd.conf. La section suivante attribuera par exemple des adresses comprises entre 192.168.1.101 et 192.168.1.199 :

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.101 192.168.1.199;
}

Adresse fixe

Pour donner une adresse fixe à un poste, il faut connaître son adresse MAC et écrire une section host. Par exemple la section suivante attribue l'adresse 192.168.0.47 au poste cobalt dont l'adresse MAC est 00:13:d4:bd:b7:9a :

host cobalt {
   hardware ethernet 00:13:d4:bd:b7:9a;
   fixed-address 192.168.0.47;
}

Options

Le serveur DHCP peut fournir d'autres informations que l'adresse IP. Ces options peuvent être définies de manière globale en les plaçant en dehors de toute section. Elles s'appliqueront alors à toutes les sections qui ne les redéfinissent pas. Si elles sont placées dans une section particulière, elles ne s'appliquent qu'à celle-ci.

L'option domain-name-servers permet par exemple d'indiquer au poste les adresses des serveurs DNS. L'option routers indique la passerelle.

Toutes les options sont décrites dans la page de man. On peut également consulter cette documentation sur internet[2].

Netfilter

Netfilter est un module qui permet de filtrer et de manipuler les paquets réseau qui passent dans le système.

Il fournit à Linux :

des fonctions de pare-feu et notamment le contrôle des machines qui peuvent se connecter, sur quels ports, de l’extérieur vers l’intérieur, ou de l’intérieur vers l’extérieur du réseau ;
de traduction d'adresse (NAT) pour partager une connexion internet (masquerading), masquer des machines du réseau local ou rediriger des connexions ;
et d'historisation du trafic réseau.

iptables est la commande qui permet de configurer Netfilter. Dans les dernières versions de Linux il existe aussi une nouvelle commande qui s'appelle nft (pour nftables).

Fonctionnement

Netfilter intercepte les paquets réseau à différents endroits du système (à la réception, avant de les transmettre aux processus, avant de les envoyer à la carte réseau, etc.). Les paquets interceptés passent à travers des chaînes qui vont déterminer ce que le système doit en faire. En modifiant ces chaînes on va pouvoir bloquer certains paquets et en laisser passer d'autres.

Filtrage

Principal cheminement des paquets à travers Netfilter

Dans son fonctionnement le plus simple, Netfilter permet de jeter ou de laisser passer les paquets qui entrent et qui sortent.

Il fournit pour cela trois chaînes principales :

une chaîne INPUT pour filtrer les paquets à destination du système,
une chaîne OUTPUT pour filtrer les paquets émis par les processus du système,
et une chaîne FORWARD pour filtrer les paquets que le système doit transmettre.

En ajoutant des règles dans ces chaînes on pourra laisser passer ou jeter les paquets suivant certains critères.

Chaînes

Une chaîne est un ensemble de règles qui indiquent ce qu'il faut faire des paquets qui la traversent.

Lorsqu'un paquet arrive dans une chaîne :

Netfilter regarde la 1ère règle de la chaîne,
puis regarde si les critères de la règle correspondent au paquet.
Si le paquet correspond, la cible est exécutée (jeter le paquet, le laisser passer, etc.).
Sinon, Netfilter prend la règle suivante et la compare de nouveau au paquet. Et ainsi de suite jusqu'à la dernière règle.
Si aucune règle n'a interrompu le parcours de la chaîne, la politique par défaut est appliquée.

Règles

Une règle est une combinaison de critères et une cible. Lorsque tous les critères correspondent au paquet, le paquet est envoyé vers la cible.

Les critères disponibles et les actions possibles dépendent de la chaîne manipulée.

Syntaxe

La syntaxe d'iptables et toutes les options sont décrites dans la page de man.

Pour chaque paramètre il existe généralement une forme longue avec deux tirets (par exemple --append) et une forme courte avec un seul tiret (par exemple -A). Utiliser l'une ou l'autre n'a pas d'importance, elles sont équivalentes. Les deux possibilités sont souvent représentées dans la documentation sous la forme --append|-A.

Les paramètres indiqués entre crochets (par exemple [-t <table>]) sont facultatifs.

Ce qui se trouve entre inférieur et supérieur (par exemple <table>) doit être remplacé par une valeur.

La forme générale pour utiliser iptables est la suivante :

iptables [-t <table>] <commande> <options>

La table par défaut est la table filter.

Commandes

Les commandes principales sont les suivantes :

--list|-L [<chaîne>]

Affiche les règles contenues dans les chaînes ou seulement dans la chaîne sélectionnée.

Si le paramètre -v est placé avant cette commande, le nombre de paquets ayant traversé chaque règle sera également affiché.

--append|-A <chaîne> <critères> -j <cible>

Ajoute une règle à la fin de la chaîne <chaine>. Si tous les critères correspondent au paquet, il est envoyé à la cible. Voir plus bas pour une description des critères et des cibles possibles.

--insert|-I <chaîne> <critères> -j <cible>

Comme --append mais ajoute la règle au début de la chaîne.

--delete|-D <chaîne> <critères> -j <cible>

Supprime la règle correspondante de la chaîne.

--flush|-F [<chaîne>]

Efface toutes les règles de la chaîne. Si aucune chaîne n'est indiquée, toutes les chaînes de la table seront vidées.

--policy|-P <chaîne> <cible>

Détermine la cible lorsqu'aucune règle n'a interrompu le parcours et que le paquet arrive en fin de chaîne.

Critères

Les critères possibles sont nombreux. En voici quelques-uns :

--protocol|-p [!] <protocole>

Le protocole est <protocole>. Les protocoles possibles sont tcp, udp, icmp, all ou une valeur numérique. Les valeurs de /etc/protocols sont aussi utilisables. Si un point d'exclamation se trouve avant le protocole, le critère correspondra au paquet seulement s'il n'est pas du protocole spécifié.

--source|-s [!] <adresse>[/<masque>]

L'adresse source est <adresse>. Si un masque est précisé, seules les parties actives du masque seront comparées. Par exemple, lorsqu'on écrit -s 192.168.5.0/255.255.255.0, toutes les adresses entre 192.168.5.0 et 192.168.5.255 correspondront. On peut aussi écrire le masque sous la forme d'un nombre de bits (/8 correspond à 255.0.0.0, /24 à 255.255.255.0, etc.) Le masque par défaut est /32 (/255.255.255.255), soit l'intégralité de l'adresse.

Un point d'exclamation ne fera correspondre le paquet que s'il n'a pas cette adresse source.

--destination|-d [!] <adresse>[/<masque>]

Comme --source mais pour l'adresse destination.

--dport [!] <port>

Le port destination est <port>. Il est obligatoire de préciser le protocole (-p tcp ou -p udp) car dans les autres protocoles il n'y a pas de notion de port.

--sport [!] <port>

Comme --dport mais pour le port source.

-i <interface>

L'interface réseau d'où provient le paquet. N'est utilisable que dans les chaînes INPUT et FORWARD.

-o <interface>

L'interface réseau de laquelle va partir le paquet. N'est utilisable que dans les chaînes OUTPUT et FORWARD.

--icmp-type <type>

Si le protocole choisi est icmp, permet de spécifier un type précis. exemples de types: echo-request pour l'envoi d'un "ping", echo-reply pour la réponse à "ping"

Cibles

Les cibles principales sont les suivantes :

-j ACCEPT

Autorise le paquet à passer et interrompt son parcours de la chaîne.

-j DROP

Jette le paquet sans prévenir l'émetteur. Le parcours de la chaîne est interrompu.

-j REJECT

Comme DROP mais prévient l'émetteur que le paquet est rejeté. La réponse envoyée à l'émetteur est également un paquet qui devra satisfaire les règles de sortie pour pouvoir passer.

-j LOG [--log-level <level>] [--log-prefix <prefix>]

Enregistre le paquet dans les logs systèmes. Au <level> par défaut, le paquet est affiché sur la console principale du système.

Cette cible est utile pour voir certains paquets qui passent (pour débugger ou pour alerter).

Utilisation simple

Le principe est assez simple à comprendre : un paquet IP arrive sur votre machine, vous devez alors choisir ce que vous en faites. Vous pouvez l’accepter (ACCEPT), le rejeter (REJECT) ou le dénier (DROP). La différence entre les deux derniers modes qu'avec REJECT on prévient l’envoyeur que son paquet a été refusé, mais pas avec DROP.

Trois types de paquets peuvent passer par le firewall. Les paquets sortant (OUTPUT), entrant (INPUT) ou « passant », c’est-à-dire qui ne font que rebondir sur le routeur qui doit les rediriger FORWARD).

Pour organiser les règles d’acceptation/rejet, on procède de la façon suivante : – INPUT, OUTPUT, FORWARD, sont appelés des chaînes – une règle est un ensemble d’attributs auxquels correspond (ou non) un paquet : IP source, IP destination, port source, port destination, protocole . . . – quand un paquet passe par le firewall, il est aiguillé vers la chaîne correspondante – ensuite, les règles de la chaîne sont testées une par une, dans l’ordre, sur le paquet. Dès que le paquet correspond à une règle, on s’arrête. Si la règle stipule ACCEPT, le paquet est accepté. Si elle stipule DROP, il est ignoré. Si elle stipule REJECT, il est refusé avec acquittement. Les règles suivantes ne sont pas testées. – si aucune règle ne correspond au paquet, la politique par défaut est appliquée. Elle peut être positionnée à ACCEPT, DROP ou REJECT.

Il est plus sécurisant (mais plus long à mettre en place) d’utiliser une politique par défaut DROP et de créer des règles ACCEPT.

La syntaxe d’iptables est la suivante :

iptables -A|I chaîne -i (ou -o) interface -p protocole
--sport [port_début[:port_fin][,autre_port...]]
--dport [port_début[:port_fin][,autre_port]]
-s adresse_source -d adresse_dest -j politique

Il y a bien sûr de nombreuses autres options.

Créer et appliquer des règles

Toutes les commandes iptables sont tapées directement sur la ligne de commande du terminal. Il est plus pratique de les inscrire dans un fichier script et de rendre ce script exécutable (chmod +x). Ne donnez que les droits minimums à ce fichier pour qu’il ne puisse pas être lu et modifié par tout le monde. Exemple de fichier :

#!/bin/sh
# Effacer toutes les règles avant toute chose, afin de partir d’une base
# propre et de savoir exactement ce que vous faites
iptables -F

# Définir une politique par défaut : le plus normal est de tout interdire par
# défaut et de n’autoriser que certains paquets.
# "DROP" ignore les paquets, "REJECT" les refuse avec acquittement pour l’envoyeur
# on met souvent "DROP" pour l’INPUT (on ne donne pas d’informations à un
# éventuel pirate) et "REJECT" pour l’OUTPUT et le FORWARD (on peut ainsi
# récupérer des infos pour soi) mais iptables n’autorise pas REJECT
# comme politique par défaut
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Autoriser le trafic sur l’interface loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Ensuite, c’est à vous d’ajouter les règles permettant de faire fonctionner
# les services que vous souhaitez utiliser sur votre machine.

Quelques exemples

Pour vider la chaine INPUT de la table filter (la table par défaut) :

iptables --flush INPUT

La politique par défaut est d'accepter tous les paquets, ce qui est généralement un mauvais choix pour la sécurité. Pour changer cette règle sur la chaine FORWARD de la table filter :

iptables -P FORWARD DROP

Pour laisser passer les paquets sur le port telnet qui viennent d'un réseau local (forme longue) :

iptables --append INPUT --protocol tcp --destination-port telnet --source 192.168.13.0/24 --jump ACCEPT

Pour ignorer les autres paquets entrants sur le Port (logiciel)|port telnet (forme courte) :

iptables -A INPUT -p tcp --dport telnet -j DROP

Pour rejeter les paquets entrants sur le port 3128, souvent utilisé par les proxies :

iptables -A INPUT -p tcp --dport 3128 -j REJECT

Pour autoriser telnet vers votre machine (serveur telnet) :

iptables -A INPUT -p tcp --dport telnet -j ACCEPT

iptables -A OUTPUT -p tcp --sport telnet -j ACCEPT

Pour autoriser telnet depuis votre machine (client telnet) :

iptables -A OUTPUT -p tcp --dport telnet -j ACCEPT

iptables -A INPUT -p tcp --sport telnet -j ACCEPT

Destination NAT :

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.0.1

Le cas FTP

Le protocole FTP est difficile à gérer avec un firewall car il utilise plusieurs connexions. Lorsqu'on se connecte par FTP sur un serveur, on créé une connexion dite de contrôle qui permet d'envoyer les commandes au serveur. Ensuite pour chaque transfert de fichier et chaque listage de répertoire, une nouvelle connexion de données sera créée.

Le firewall peut très bien gérer la connexion de contrôle, mais pas celles de transfert car elles sont faites sur des ports indéterminés. Sur certains serveurs FTP il est possible de fixer une plage de ports à utiliser, et dans ce cas on peut faire du NAT simple.

Il est également possible d'utiliser le "conntrack ftp". C'est un module pour Netfilter qui inspecte les connexions FTP de contrôle pour détecter les connexions de données. Il indique alors au noyau que ces connexions sont liées à une autre connexion (RELATED). Pour autoriser ces connexions avec iptables on utilise le module state.

Pour cela il faut charger le module ip_conntrack_ftp :

modprobe ip_conntrack_ftp

Et autoriser les connexions RELATED en entrée et en sortie :

iptables -A INPUT -m state --state RELATED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED -j ACCEPT

TCP Wrapper

Le super service inetd permet de contrôler et de restreindre l'accès à certains services réseau. Ceux-ci sont gérés par inetd et ne sont plus en mode dit "standalone".

Inetd utilise le démon tcpd qui intercepte les demandes de connexion à un service et vérifie par le biais des fichiers hosts.allow et hosts.deny si le client est autorisé à utiliser ce service. Sur les versions de linux actuelles, il est installé par défaut. Par contre il n'est pas actif dans sa partie contrôle d'accès.

Inetd est un élément à mettre en œuvre pour sécuriser une machine sous linux, il ne peut toutefois pas remplacer complétement un vrai firewall.

Le principe

Lorsque vous souhaitez vous connecter sur une machine distante avec la commande telnet par exemple, le démon inetd intercepte votre demande de connexion et vérifie dans le fichier inetd.conf si le service telnet est utilisable. Si la réponse est positive, votre demande est passée à tcpd qui vérifie dans les fichiers hosts.allow et hosts.deny si vous avez le droit de vous connecter en telnet, si cela est le cas votre demande de connexion sera autorisée, sinon vous serez rejeté. Dans tous les cas de figure et cela est l'autre fonction de TCP_wrappers, tcpd transmettra à syslogd (démon de log) votre demande (cette demande se retrouvera dans les logs, fichier /var/log/securite).

L'installation

Par défaut il est installé avec la plupart des distributions, mais au cas où, le paquet à installer est : tcp_wrappers-x.....rpm. TCP_wrappers utilise les fichiers suivants : tcpd, inetd, inetd.conf, hosts.allow, hosts.deny, tcpdchk, tcpdmatch.

Configuration : le fichier inetd.conf

Ce fichier se trouve dans le répertoire /etc. Vous pouvez activer ou désactiver ici des services, en plaçant un # devant la ligne ou en l'enlevant, puis en obligeant la relecture du fichier avec la commande killall -HUP inetd. Il est possible d'ajouter d'autres services dans ce fichier.

En voici un commenté:

# Version: \@(#)/etc/inetd.conf
# Les premières lignes sont utilisées par  inetd
#
#echo stream tcp nowait root internal
#echo     dgram     udp     wait     root internal
#discard     stream     tcp     nowait     root internal
#discard     dgram     udp     wait     root internal
#daytime     stream     tcp     nowait     root internal
#daytime     dgram     udp     wait     root     internal
#chargen     stream     tcp     nowait     root     internal
#chargen     dgram     udp     wait     root     internal
#time     stream     tcp     nowait     root     internal
#time     dgram     udp     wait     root     internal
#
#ftp et telnet sont deux services très utilisés.
#Ils ne sont pas spécialement sécurisés. telnet peut être remplacé  par ssh qui est beaucoup plus sécurisé.
#
# ftp     stream     tcp nowait     root     /usr/sbin/tcpd
in.ftpd telnet stream tcp     nowait     root     /usr/sbin/tcpd
in.telnetd
#
#Shell, login, exec, comsat et talk sont des protocoles BSD.
#Essayez de ne pas les utiliser.
#Ils présentent des failles au niveau de la sécurité.
# shell     stream tcp nowait     root /usr/sbin/tcpd
in.rshd login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream     tcp nowait     root /usr/sbin/tcpd in.rexecd
#comsat dgram udp wait     root /usr/sbin/tcpd in.comsat
talk gram udp     wait nobody.tty /usr/sbin/tcpd in.talkd
ntalk dgram     udp wait     nobody.tty /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp wait nobody.tty /usr/sbin/tcpd in.dtalkd
#
# pop3 et imap sont les serveurs de messagerie.
# À n'activer que si vous les utilisez.
# Oubliez pop2
#pop-2 stream     tcp nowait root
/usr/sbin/tcpd ipop2d
#pop-3 stream     tcp nowait root
/usr/sbin/tcpd     ipop3d
#imap stream     tcp nowait root
/usr/sbin/tcpd     imapd
#
#Le service UUCP est un moyen d'envoyer des fichiers entre machines.
#Ce service n'est pratiquement plus utilisé.
#Évitez de l'utiliser.
#uucp stream     tcp     nowait     uucp
/usr/sbin/tcpd /usr/lib/uucp/uucico -l
#ftp et bootp sont utilisés pour permettre aux machines
 clientes qui ne disposent pas
# de disque de booter, de recevoir une adresse IP, de charger le système.
#TFTP ne disposant pas de système d'authentification il
#est un énorme trou de sécurité. # Vous devez absolument éviter de
 l'utiliser
# tftp     dgram udp     wait     root
/usr/sbin/tcpd in.tftpd
# bootps     dgram     udp     wait root /usr/sbin/tcpd bootpd
#Finger, cfinger, systat and netstat ne sont pas
# dangereux en eux même, mais ils
# fournissent des informations sur les comptes
#utilisateurs et votre système.
#Il ne faut donc pas les utiliser.
# finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd     /bin/netstat -f inet

# Service d'authentification auth fournit des information sur l'utilisateur
auth stream tcp wait root /usr/sbin/in.identd in.identd -e -o
# end of inetd.conf linuxconf stream tcp wait root /bin/linuxconf linuxconf --http

Le # devant une ligne rend la ligne inactive, donc le service non disponible. Si vous ne devez pas utiliser un service, rendez le inactif.

Voici un descriptif de quelques options. Considérons la ligne suivante:

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd

ftp: nom du service, tel qu'il est déclaré dans /etc/services
stream: type de service de transport de données (il existe stream pour tcp, dgram pour udp, raw pour IP)
tcp: nom du protocole tel qu'il existe dans /etc/protocols
wait: état d'attente, si l'état est wait inetd doit attendre que le serveur ait restitué la socket avant de se remettre à l'écoute. On utilise wait plutôt avec les types dgram et raw. l'autre possibilité est nowait qui permet d'allouer dynamiquement des sockets à utiliser avec le type stream.
root: Nom de l'utilisateur sous lequel le daemon tourne
/usr/sbin/tcpd in.ftpd Chemin d'accès au programme in.ftpd lancé par inetd (il est possible ici d'ajouter les options de démarrage du programme.

Hosts.allow et Hosts.deny

Vous trouverez ces deux fichiers dans le répertoire /etc.

Le premier fichier lu est hosts.allow , puis hosts.deny. Si une requête est autorisée dans le fichier hosts.allow alors elle est acceptée, quel que soit le contenu du fichier hosts.deny. Si une requête ne satisfait aucune règle, que ce soit dans hosts.allow ou hosts.deny alors elle est autorisée. En un mot si vous ne mettez rien dans hosts.deny, alors vous n'avez rien fait.

Voici un petit exemple qui dans des cas simples est suffisant :

fichier hosts.allow

# hosts.allow
ALL : LOCAL
in.ftpd : 192.168.0.,10.194.168.0/255.255.255.0, 192.168.1.1
in.telnetd : .iut.u-clermont1.fr

On autorise tous les ports depuis un accès local, et on autorise ftp pour les machines venant du réseau 192.168.0.0, ainsi que les machines du réseau 10.194.168.0 avec une autre notation et enfin la seule machine qui a pour adresse 192.168.1.1

fichier hosts.deny

#hosts.deny
ALL:ALL

Le fichier hosts.deny est simple à comprendre, il interdit tout par défaut. Le fichier hosts.allow indique les services que je veux autoriser (Le nom du service doit être identique au nom qui se trouve dans inetd.conf). la syntaxe est la suivante :

deamon[,deamon,...] : client[,client,...] [ : option : option ...]

Cette syntaxe est identique dans les deux fichiers, hosts.allow et hosts.deny.

Les utilitaires de tcp wrappers

tcpdchk -av : permet de voir la configuration de tcp wrappers
tcpdmatch in.ftpd localhost pour simuler une connexion sur in.ftpd

voir aussi xinetd un équivalent de tcp_wrappers, mais avec plus d'options.

Tcpdump

Dans un réseau ethernet relié par un concentrateur (ou hub), chaque machines reçoit tous les paquets qui circulent sur le réseau. En fonctionnement normal, les cartes réseau ne réceptionnent que les paquets qui leur sont destinés, mais on peut faire en sorte qu'elles transmettent tous les paquets au système.

Les hub sont de moins en moins utilisés. Ils sont généralement remplacés par des commutateurs (ou switch) qui savent déterminer (en fonction de l'adresse MAC) sur quel câble il faut envoyer un paquet. Les machines ne reçoivent donc généralement que les paquets qui leur sont destinés.

L'utilitaire tcpdump permet d'inspecter les paquets qui sont reçus et transmis par une carte réseau.

Filtrage

Il est possible de sélectionner les paquets à "écouter" en fonction d'expressions. Ainsi, ne seront affichées / traitées que les informations pour lesquelles le résultat de l'expression est vérifié. Une expression est composée de primitives et d'opérateurs logiques.

Une primitive est un identifiant précédé de mots clés qui indiquent le type de l'identifiant. Par exemple la primitive src port 21 contient les éléments suivants :

le mot clé src qui indique que l'identifiant ne porte que sur la source du paquet
le mot clé port qui indique que l'identifiant est le port du paquet
l'identifiant 21

La primitive correspond donc au port source 21.

De la même manière, la primitive ether src 00:11:22:33:44:55 indique l'adresse ethernet (ou MAC) source 00:11:22:33:44:55.

Les primitives les plus courantes sont les suivantes :

src <adresse>: l'adresse source est <adresse>
dst <adresse>: l'adresse destination est <adresse>
host <adresse>: l'adresse source ou destination est <adresse>
port <port>: le port source ou destination est <port>
src port <port>: le port source est <port>
dst port <port>: le port destination est <port>
portrange <port1>-<port2>: le port est compris entre <port1> et <port2>. On peut préciser l'origine avec les mots clés src ou dst et le protocole avec les mots clés tcp ou udp.

Les primitives peuvent être reliées avec les opérateurs logiques and, or et not. Par exemple l'expression suivante va trouver tous les paquets en provenance de tiny mais dont le port n'est pas le port ssh :

src tiny and not port ssh

Il est également possible de spécifier un protocole: udp, tcp, icmp.

Options

Plusieurs options permettent de modifier le comportement de tcpdump :

-i <interface>: sélectionne l'interface réseau sur laquelle tcpdump écoute. Par défaut il prend la première active (sauf lo).
-x: affiche également les données contenues dans les paquets trouvés, sous forme hexadécimale
-X: affiche les données des paquets sous forme ASCII
-s <nombre>: par défaut, seuls les 68 premiers octets de données sont affichés. Ce paramètre permet de modifier ce nombre.
-w: pour spécifier le chemin d'un fichier où sauvegarder le dump.

Exemples

tcpdump src 192.168.0.1

Ici, les seuls paquets affichés sont ceux en provenance de 192.168.0.1. Nous pouvons également préciser nos préférences en ajoutant un critère :

tcpdump src 192.168.0.1 and port 80

Là, le seul port qui nous intéresse est 80 (http).

Voici une ligne complète qui ne laisse vraiment passer que les paquets en provenance de 192.168.0.1 vers 212.208.225.1, sur le port 53 en udp.

tcpdump -x -X -s 0 src 192.168.0.1 and dst 212.208.225.1 and port 53 and udp

Nous avons demandé l'affichage du contenu des paquets au format hexadécimal et ascii (-x -X) et ce, quelle que soit leur taille (-s 0). Nous obtenons les informations désirées :

0x0000:  4500 003b 0000 4000 4011 ca00 c1fd d9b4  E..;..@.@.......
0x0010:  c1fc 1303 80a1 0035 0027 213d 14c2 0100  .......5.'!=....
0x0020:  0001 0000 0000 0000 0377 7777 056c 696e  .........www.lin
0x0030:  7578 036f 7267 0000 0100 01              ux.org.....

SSH

SSH signifie Secure SHell. C'est un protocole qui permet de faire des connexions sécurisées (i.e. cryptées) entre un serveur et un client SSH.

On peut l'utiliser pour se connecter à une machine distante comme avec telnet, pour transférer des fichiers de manière sécurisée ou pour créer des tunnels. Les tunnels permettent de sécuriser des protocoles qui ne le sont pas en faisant passer les données par une connexion SSH.

Le système de clés de SSH

Cryptographie asymétrique

SSH utilise la cryptographie asymétrique RSA ou DSA. En cryptographie asymétrique, chaque personne dispose d'un couple de clé : une clé publique et une clé privée. La clé publique peut être librement publiée tandis que chacun doit garder sa clé privée secrète. La connaissance de la clé publique ne permet pas d'en déduire la clé privée.

Si la personne A veut envoyer un message confidentiel à la personne B, A crypte le message avec la clé publique de B et l'envoie à B sur un canal qui n'est pas forcément sécurisé. Seul B pourra décrypter le message en utilisant sa clé privée.

Cryptographie symétrique

SSH utilise également la cryptographie symétrique. Son principe est simple : si A veut envoyer un message confidentiel à B, A et B doivent d'abord posséder une même clé secrète. A crypte le message avec la clé sécrète et l'envoie à B sur un canal qui n'est pas forcément sécurisé. B décrypte le message grâce à la clé secrète.

Toute autre personne en possession de la clé secrète peut décrypter le message.

La cryptographie symétrique est beaucoup moins gourmande en ressources processeur que la cryptographie asymétrique, mais le gros problème est l'échange de la clé secrète entre A et B. Dans le protocole SSL, qui est utilisé par les navigateurs Web et par SSH, la cryptographique asymétrique est utilisée au début de la communication pour que A et B puissent s'échanger une clé secrète de manière sécurisée, puis la suite la communication est sécurisée grâce à la cryptographie symétrique en utilisant la clé secrète échangée.

Configuration du serveur SSH

Pour manipuler le daemon (le lancer, l'arrêter, recharger la configuration...), on utilise la commande

/etc/init.d/ssh

Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config. À ne pas confondre avec /etc/ssh/ssh_config qui est le fichier de configuration du client SSH.

Parmi les multiples options, on peut noter :

Port 22: Signifie que le serveur SSH écoute sur le port 22, qui est le port normal de SSH. Il est possible de le faire écouter sur un autre port en changeant cette ligne.
Protocol 2: Signifie que le serveur SSH accepte uniquement la version 2 du protocole SSH. C'est une version plus sécurisée que la version 1 du protocole. Pour accepter les deux protocoles, change la ligne en : Protocol 2,1
PermitRootLogin no: Signifie que l'on ne peut pas se logger en root par SSH. Pour se logger en root, il suffit de se logger en utilisateur normal et d'utiliser la commande su.
X11Forwarding yes: Autorise le transfert par SSH de l'affichage graphique.
LoginGraceTime 600: Temps de connexion maximum
RSAAuthentication yes: Méthode d'authentification.
AuthorizedKeysFile .ssh/authorized_keys fichier utilisé pour 'l'autologin'
PermitEmptyPasswords no: permet ou non les mots de passe vide

Si le fichier de configuration du serveur a été modifié, il faut indiquer au démon sshd de relire son fichier de configuration, avec la commande /etc/init.d/ssh restart.

Se logguer par SSH

Deux types d'authentification sont possibles : par mot de passe et par clé. Dans les deux cas on utilise une des commandes suivantes :

ssh -l <login> <adresse du serveur SSH> 
ssh <login>@<adresse du serveur SSH>

Authentification par mot de passe

C'est la méthode la plus simple. Lors de la connexion, le client ssh demande le mot de passe du compte. Dans ce cas, ssh chiffre le mot de passe ce qui évite de le voir circuler en clair sur le réseau.

Authentification par clé

Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clés privée/publique, comme le fait le serveur SSH auprès du client SSH. La clé publique est placée sur le serveur dans le home du compte sur lequel on souhaite se connecter. La clé privée reste sur le poste client. Dans ce cas, aucun mot de passe ne circule sur le réseau.

Générer une clé

Pour générer un couple de clés, on utilise la commande :

ssh-keygen -t rsa

Deux clés vont être générées, une clé publique (par défaut ~/.ssh/id_dsa.pub) et une clé privée (par défaut ~/.ssh/id_dsa). C'est la clé publique qu'il faudra copier sur le serveur.

Les clés générées ont par défaut une longueur de 1024 bits, ce qui est aujourd'hui considéré comme suffisant pour une bonne protection.

La commande demande un nom de fichier pour sauvegarder la clé privée et un nom de fichier pour sauvegarder la clé publique. Par défaut, la clé privée est stockée dans le fichier $HOME/.ssh/id_dsa.

La clé privée est enregistrée avec les permissions 600. La clé publique porte le même nom de fichier suivi de ".pub", avec les permissions 644.

Lors de la création de la clé, l'utilitaire demande une pass phrase qui est un mot de passe pour protéger la clé privée (2eme protection). Cette pass phrase sert à crypter la clé privée. La pass phrase sera alors demandée à chaque utilisation de la clé privée, c'est à dire à chaque fois que vous vous connecterez en utilisant cette méthode d'authentification. Un mécanisme appelé ssh-agent permet de ne pas rentrer le mot de passe à chaque fois (voir les docs).

Il est possible de changer la pass phrase qui protège la clé privée avec la commande ssh-keygen -p.

Autoriser sa clé publique

Pour autoriser une clé à se connecter à un compte, il faut placer sa partie publique dans le fichier $HOME/.ssh/authorized_keys du compte en question, sur le serveur SSH. Si vous souhaitez vous connecter au serveur sur le compte sasa, le fichier est /home/sasa/.ssh/authorized_keys.

Pour transférer la clé publique, on peut utiliser ftp, scp (copie de fichier par ssh), ou un simple copier/coller entre deux terminaux (c'est simplement une longue ligne de caractères ASCII).

Chaque ligne du fichier authorized_keys correspond à une clé publique autorisée à se connecter. Il faut vérifier que chaque clé est bien sur une seule ligne, sinon ça ne fonctionne pas.

Le répertoire $HOME/.ssh' devrait être protégé en écriture, avec les permissions 755 (ou 705). De la même manière, le fichier authorized_keys ne doit pas être lisible par tous (600 par exemple).

Ensuite, pour se logger, il suffit de procéder comme précédemment.

Si la clé privée a été enregistré dans un autre fichier que $HOME/.ssh/id_dsa, il faut le préciser au client ssh :

ssh -i <nom du fichier contenant la clé privée> <login>@<serveur>

Agent SSH

Un agent SSH est un programme qui garde en mémoire des clés privées. Le principe est le suivant :

on lance un agent
on lui ajoute des clés (si les clés sont cryptées, elles sont décryptées avec la passphrase avant d'être ajoutées)
à chaque connexion ssh, les clé de l'agent sont utilisées en priorité

Les avantages principaux sont :

que la passphrase n'est demandée qu'une seule fois au moment où elle est ajoutée à l'agent,
et que l'agent est capable de faire suivre la clé sur plusieurs connexions.

Pour lancer un agent on utilise généralement une commande qui ressemble à :

ssh-agent /bin/bash

L'agent SSH lance un nouveau shell ("/bin/bash") dans lequel il sera actif. Il ne sera utilisable qu'à partir de ce shell et dans les programmes qui y seront lancés.

Pour ajouter une clé on utilise

ssh-add [<fichier>]

Si on ne précise aucun fichier, il utilisera la clé par défaut ("~/.ssh/id_dsa" pour SSH 2).

Si la clé est crypté, la passphrase sera demandée et la clé décryptée sera ajoutée à l'agent.

Toutes les connexions SSH (avec ssh, scp...) lancées à partir de ce shell utiliseront l'agent et ne demanderont donc plus la passphrase.

Depuis Windows

Pour se connecter en SSH à un serveur Linux sous Windows, il existe le logiciel gratuit Putty^{Télécharger}.

Une fois lancé, dans le champ Host Name (or IP address), rentrer l'adresse IP ou le nom d'hôte du serveur distant. Le port est par défaut (et par norme) égal à 22 en protocole SSH.

Lors de la première connexion, un security warning peut être affiché, il faut juste cliquer sur oui.

Les options de connexion du menu de gauche permettent éventuellement d'enregistrer un mot de passe ou une clé SSH de connexion, afin de se connecter en quelque clics.

Sinon, des émulateurs Unix comme Cygwin ou Git Bash peuvent exécuter la commande ssh.

Créer un "tunnel" crypté entre deux stations

SSH est également capable de fournir un encryptage à d'autres services (ftp par exemple) par le biais du port forwarding.

(options -L et -R de la commande ssh), de la manière suivante:

Considérons deux stations HOST1 et HOST2. Supposons que sur la machine HOST1, vous utilisiez la commande :

ssh -L p1:HOST2:p2 HOST2

ou sur HOST2:

ssh -R p1:HOST2:p2 HOST1

alors vous obtenez un tunnel sécurisé dans lequel vous pouvez passer toute connexion, lesquelles seront automatiquement cryptées.

Sur HOST1, ssh -L p1:HOST2:p2 HOST2 signifie, que lorsqu'on se connecte au port p1, les paquets sont retransmis vers le port p2 de la machine HOST2 via HOST2.

Routage

Adresses IP et MAC

Chaque interface de chaque ordinateur sera identifiée par

Son adresse IP : une adresse IP (version 4, protocole IP V 4) permet d’identifier un hôte et un sous-réseau. L’adresse IP est codée sur 4 octets - 32 bits. (les adresses IP V 6, ou IP next generation seront codées sur 16 octets - 128 bits).
L’adresse mac de sa carte réseau (carte Ethernet ou carte wifi) sur 6 octets - 48 bits;

Une adresse IP permet d’identifier un hôte. Une passerelle est un ordinateur qui possède plusieurs interfaces et qui transmet les paquets d’une interface à l’autre. La passerelle peut ainsi faire communiquer différents réseaux. Chaque carte réseau possède une adresse MAC unique garantie par le constructeur. Lorsqu’un ordinateur a plusieurs interfaces, chacune possède sa propre adresse MAC et son adresse IP. On peut voir sa configuration réseau par ifconfig :

$ ifconfig eth0
eth0        Link encap:Ethernet HWaddr 00:B2:3A:24:F3:C4
            inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
            inet6 addr: fe80::2c0:9fff:fef9:95b0/64 Scope:Link
            UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
            RX packets:6 errors:0 dropped:0 overruns:0 frame:0
            TX packets:16 errors:0 dropped:0 overruns:0 carrier:5
            collisions:0 txqueuelen:1000
            RX bytes:1520 (1.4 KiB) TX bytes:2024 (1.9 KiB)
            Interrupt:10

On voit l’adresse MAC 00:B2:3A:24:F3:C4 et l’adresse IP 192.168.0.2. Cela signifie que le premier octet de l’adresse IP est égal à 192, le deuxième 168, le troisième octet est nul, et le quatrième vaut 2.

Sous-réseaux

Classes de sous-réseaux

Jusqu'aux années 1990, les adresses IPv4 étaient organisées en sous-réseaux. Chaque sous-réseau possède une adresse, qui est une partie de l’adresse IP des machines de ce sous-réseau.

Par exemple, l’adresse IP 192.168.4.35 appartient au sous-réseau 192.168.4, parfois aussi noté 192.168.4.0.

Les sous-réseaux sont organisés en classes. Chaque classe de sous-réseaux correspond à des réseaux pouvant contenir un certain nombre de machines.

Classe A : les adresses de 1.0.0.0 à 127.0.0.0. L’identifiant du réseau est sur 8 bits et les identifiants de machine sont sur 24 bits (plusieurs millions de machines par sous-réseau ;
Classe B : les adresses de 128.0.0.0 à 191.255.0.0. L’identifiant du réseau est sur 16 bits et les identifiants de machine sont sur 16 bits (plus de 65 000 machines par sous-réseau) ;
Classe C : les adresses de 192.0.0.0 à 223.255.255.0. L’identifiant du réseau est sur 24 bits et les identifiants de machine sont sur 8 bits (au plus 254 machines par sous-réseau, numérotées de 1 à 254) ;

Masque de sous-réseau

Un masque de sous-réseau est une donnée sur 4 octets qui, avec l’adresse du sous-réseau, caractérise les IP du sous-réseau.

Un bit du masque de sous-réseau est à 1 si pour toutes les adresses IP du sous-réseau, ce même bit est le même pour l’adresse IP et le sous-réseau.

Par exemple, pour le réseau de classe A 37.0.0.0 avec le masque de sous-réseau 255.0.0.0, les 8 premiers bits de toutes les adresses IP du sous-réseau valent 37.

Autre exemple : pour le sous-réseau de classe C 193.56.49.0 et le masque de sous-réseau 255.255.255.0, les 24 premiers bits de toutes les IP du sous-réseau sont 193.56.49.

On peut désigner un sous-réseau par son adresse et son masque, mais on peut aussi désigner le sous-réseau en donnant seulement le nombre de bits du masque. On parle alors, pour reprendre les deux exemples précédents, du sous-réseau 37.0.0.0/8 ou du sous-réseau 193.56.49.0/24.

Routage

Sous-réseaux reliés par des passerelles.

Le routage permet de faire communiquer plusieurs sous-réseaux. Une passerelle (en anglais gateway) est en communication avec différents sous-réseaux sur différentes interfaces, et assure la communication entre les différents sous-réseaux.

Routes

Une route définie sur une station est un chemin que doivent prendre les paquets à destination d’un certain sous-réseau. Prenons l’exemple d’une station, appelée station 1, d’adresse IP 112.65.77.8 sur un réseau 112.0.0.0/8.

Elle est connectée à une passerelle qui a pour IP dans ce réseau 112.65.123.3 sur son interface eth0. La passerelle est aussi connectée au réseau 192.168.0.0/24 via son interface eth1 qui a pour IP 192.168.0.1. Si la station 1 veut communiquer directement avec la station, appelée station 6, d’adresse IP 192.168.0.2 sur le réseau 192.168.0.0/24, trois condition doivent être réunies ;

Une route doit être définie sur la station 1 indiquant que les paquets à destination du réseau 192.168.0.0/24 doivent passer par la passerelle 112.65.123.3. Pour cela, on peut utiliser la commande route :

route add -net 192.168.0.0/24 gw 112.65.123.3

Une route doit être définie sur la station 6 indiquant que les paquets à destination du réseau 112.0.0.0/8 doivent passer par la passerelle 192.168.0.1 ; Pour cela, on peut utiliser la commande route :

route add -net 112.0.0.0/8 gw 192.168.0.1

La passerelle doit être configurée pour transmettre (ou forwarder) les paquets IP d’un réseau à l’autre, ce qui se fait par l'une des commandes suivantes (les deux font la même chose, inutile donc de se répéter) :

echo 1 >/proc/sys/net/ipv4/ip_forward
sysctl -w net.ipv4.ip_forward=1

Remarque : Il faut refaire ces commandes après un redémarrage. Pour éviter de relancer ces commandes manuellement, on peut les mettre dans des scripts d’initialisation au démarrage avec la commande update-rc.d (sous debian)). Pour ajouter un script my_ script à l’initialisation :

mv my_script /etc/init.d
update-rc.d my_script defaults

Si l'IP-forwarding est activé via uns sysctl, le fichier standard de configuration de ce paramètre est /etc/sysctl.conf, où la ligne est déjà en commentaire.

On peut voir l’état des routes avec la commande route -n. Par exemple, sur la station 1 :

route -n
Destination           Gateway                         Genmask               Flags Metric Ref     Use Iface
192.168.0.0           112.65.123.3                    255.255.255.0         U     0       0        0 eth2
etc...

Sur la station 6

route -n
Destination           Gateway                         Genmask               Flags Metric Ref     Use Iface
112.0.0.0             192.168.0.1                     255.0.0.0             U     0       0        0 wlan0
etc...

Pour supprimer une route, par exemple vers le réseau 193.86.46.0/24 via une passerelle 196.24.52.1, on fait :

route del -net 193.86.46.0/24 gw 196.24.52.1

Route par défaut (gateway)

Quand on a défini un certain nombre de routes sur une station, on peut définir une route spéciale pour les paquets IP à destination des réseaux non prévus dans les autres routes. On appelle une telle route une route par défaut. En général, c’est la route qu’il faut employer pour aller sur internet. On emploie le réseau 0.0.0.0 (masque 255.255.255.255). Pour définir une route par défaut on peut employer la commande route. Par exemple, pour définir la route par défaut via la passerelle 194.56.87.1 :

route add default gw 194.56.87.1

Pour supprimer cette même route :

route del default gw 194.56.87.1

NAT et masquerading

Lorsqu'un hôte ayant une adresse IP sur un réseau local cherche à se connecter sur un réseau plus vaste, par exemple sur internet, via une passerelle, cet hôte a besoin d’une adresse IP sur le réseau vaste. Pour cela, soit on demande à ce que les adresses du réseau local soient routées sur le réseau global, mais il faut alors demander à réserver une plage d’adresses sur le réseau global, soit l’administrateur de la passerelle a la possibilité de prêter l’IP de la passerelle aux machines du réseau local. Pour cela, on utilise iptables avec NAT. Par exemple, si la passerelle se connecte à internet via son interface eth0, il suffit d’exécuter la commande suivante sur la passerelle :

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Toute machine du réseau local (par exemple 192.168.0.0/24) qui se connecte à internet via cette passerelle aura alors l’adresse IP de la passerelle sur internet. On peut aussi donner aux machines du réseau local une autre adresse IP que l’on spécifie avec –to :

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 193.56.17.9

Nous aurons un aperçu plus complet des possibilités d’iptables dans la documentation sur Netfilter.

Redirection

Il est également possible de modifier la destination d'un paquet. C'est utile lorsqu'on veut cacher une machine derrière une autre : le client se connecte à un serveur, qui va transmettre tous les paquets à un autre. Pour le client c'est transparent, c'est comme si c'était le premier serveur qui répondait. On appelle cela du Destination NAT (DNAT).

Exemple pour rediriger toutes les connexions du port 22 vers le serveur 192.168.1.12 :

iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to 192.168.1.12

TP VDN

VDN est un logiciel qui permet de lancer des machines virtuelles Debian. Une machine virtuelle est un système informatique complet qui fonctionne à l'intérieur d'un autre. VDN permet ainsi de faire fonctionner sur la même machine plusieurs serveurs Linux qui vont communiquer entre eux sur un réseau virtuel.

Le schéma suivant représente les machines virtuelles que nous allons utiliser dans les TP, et les réseaux qui les relient :

Dans un premier temps, nous allons principalement utiliser bigboss et tiny.

Pour lancer VDN, ouvrez un terminal et tapez la commande :

~vdn/vdn/bin/vdn

Il configurera votre environnement pour que la prochaine fois que vous ouvrirez un terminal, vous n'aurez qu'à taper cette commande pour le lancer :

vdn

Le schéma présenté plus haut devrait apparaitre. Vous pouvez manipuler les machines virtuelles avec un clic droit sur leur icône. Les options sont les suivantes :

Start: Démarrer la machine virtuelle.
Halt: Arrêter la machine virtuelle. Vous pouvez également l'arrêter à partir de la machine virtuelle en tapant "halt".
Save: Sauvegarder les modifications faites sur la machine virtuelle. Vous pouvez également sauvegarder vos modifications en tapant "vdn-save" à partir de la machine virtuelle.
Ssh: Ouvre un terminal connecté à la machine virtuelle. Vous pouvez également vous connecter à partir d'un terminal en tapant "vdn-ssh root@<nom de la machine virtuelle>"
Config...: Ouvre un terminal pour modifier la configuration de la machine virtuelle (vous n'en aurez pas besoin).
Infos: Ouvre un terminal contenant les informations sur la machine virtuelle, et notamment les redirections de port (qui seront utiles dans certains TP).
Clean: Efface toutes les modifications faites sur la machine virtuelle. Ça ne sera effectif qu'au prochain démarrage de la machine.
Kill: Arrête brutalement la machine virtuelle. Les modification effectuées depuis son lancement ne seront pas sauvegardées ! À n'utiliser que si la machine ne répond plus du tout.

Vous pouvez également sélectionner plusieurs machines virtuelles et effectuer une action sur toutes ces machines en même temps.

TP

lancez vdn
démarrez les machines virtuelles "tiny" et "bigboss"
allez sur un "espace de travail" vierge (avec ctrl + alt + flèche bas ou en cliquant sur l'espace de travail). Vous pouvez aussi utiliser l'onglet Ssh pour ouvrir des sessions SSH sur les stations.
ouvrez 2 terminaux
sur chacun d'eux, connectez-vous sur une machine virtuelle en utilisant la commande "vdn-ssh root@nomDeLaMachineVirtuelle"

TP Configuration réseau

Dans ce TP nous allons configurer tiny pour qu'il puisse communiquer par le réseau avec bigboss.

Toutes les informations nécessaires à la réalisation de ce TP devraient se trouver dans la documentation associée : Configuration réseau.

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (dans vdn faire Scripts → baseConfigBigboss si ce n'est pas déjà fait)

Changer le nom d'hôte

Le nom d'hôte de tiny n'est pas configuré. Nous allons donner un nom à tiny.

mettez le nom d'hôte "tiny" de manière permanente
utilisez la commande "hostname" pour vérifier qu'il est pris en compte
ouvrez un nouveau terminal et connectez le à tiny avec vdn-ssh. Vérifiez que le nom apparaît dans l'invite de commande ("root@tiny:~#")
redémarrez tiny pour vérifier que le nom est initialisé au démarrage de la machine

Configurer l'interface réseau

L'interface réseau de tiny n'est pas configurée, il n'a donc pas d'adresse IP et ne peut pas communiquer avec bigboss. Le schéma de l'interface VDN suggère une adresse IP à donner à tiny et indique à quelle interface réseau il faut l'associer.

utilisez la commande ifconfig pour configurer l'interface réseau de tiny. Attention : ne modifiez pas l'interface réseau eth2 : elle sert au fonctionnement des machines virtuelles.
tapez "ifconfig" pour vérifier que l'interface est bien initialisée avec la bonne adresse IP
vérifiez que tiny peut communiquer avec bigboss en utilisant la commande "ping" (observez le schéma pour connaitre l'adresse IP de bigboss)
vérifiez que bigboss peut communiquer avec tiny

Configurer l'interface réseau de manière permanente

Utiliser ifconfig pour configurer une interface réseau est pratique et rapide, mais la configuration n'est pas conservée au prochain démarrage.

désactivez l'interface réseau que vous venez de configurer avec la commande "ifconfig <nom de l'interface> down"
configurez l'interface réseau de tiny de manière permanente
utilisez ifup pour configurer l'interface réseau
vérifiez que la communication fonctionne entre tiny et bigboss
redémarrez tiny
vérifiez que le réseau fonctionne toujours après le redémarrage

Résolution des noms d'hôtes

Il est souvent plus pratique d'utiliser des noms d'hôte à la place des adresses IP. Pour cela il faut indiquer au système comment traduire un nom en adresse IP. En général cette opération est réalisée par un serveur DNS, mais nous n'en n'avons pas sur notre réseau.

Nous allons donc utiliser un autre procédé qui permet cette traduction : le fichier hosts.

modifiez le fichier hosts de tiny pour indiquer l'adresse IP de bigboss
vérifiez que ça fonctionne avec un "ping bigboss"

TP NFS

Dans ce TP nous allons partager avec NFS un répertoire de bigboss et y accéder à partir de tiny.

Documentation associée : NFS.

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez vdn-scripts baseConfigBigboss si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)

TP

créez le répertoire /mnt/aufs/rw/partage sur bigboss et ajoutez un fichier à l'intérieur avec un contenu quelconque
exportez ce répertoire par NFS, en lecture-écriture et uniquement pour tiny. La spécificité des machines virtuelles que nous utilisons impose d'utiliser l'option fsid=<n'importe quel nombre positif non nul> pour indiquer l'intervalle virtuel de blocs du système de fichier. (séparez les options par une virgule, mais ne mettez pas d'espace !)
montez ce répertoire sur tiny (avec l'utilisateur root).
vérifiez que vous pouvez accéder au fichier créé précédemment et qu'il contient bien ce que vous avez mis dedans
modifiez ce fichier. Si ça ne fonctionne pas, c'est probablement à cause de l'option root_squash qui est activée par défaut. Consultez le man exports pour connaître sa signification et savoir comment la désactiver.
vérifiez que le changement a été pris en compte sur bigboss

TP Samba

Dans ce TP nous allons partager un répertoire de bigboss avec Samba. Les répertoires partagés avec Samba sont accessibles à des machines Windows. Nous ne disposons pas actuellement de machine virtuelle sous Windows donc nous y accéderons uniquement à partir de Linux.

Documentation associée : Samba.

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez ~reseaux/vdn-0.6/scripts/bigbossBaseConfig si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)

Partage d'un répertoire

créez un compte utilisateur sur bigboss (commande adduser) ou reprenez en un existant
créez un mot de passe samba pour ce compte utilisateur avec la commande smbpasswd
créez un répertoire sur bigboss ainsi qu'un fichier avec le contenu que vous voulez
partagez ce répertoire avec samba, avec les options lecture seule et public
connectez-vous à ce partage avec la commande smbclient à partir de tiny et vérifiez que vous pouvez lister le fichier créé précédemment
montez ce partage sur tiny et vérifiez que le fichier créé précédemment a le bon contenu (avec le compte root). Si cela fonctionne démontez avec la commande umount.
modifiez votre partage avec les option public = no et valid users , puis testez. Faites une faute de frappe sur le nom du compte dans la ligne valid users. Là vous deviez avoir une erreur en testant.

Partage des comptes utilisateur

créez un compte utilisateur sur bigboss (commande adduser) ou reprenez en un existant
créez un mot de passe samba pour ce compte utilisateur avec la commande smbpasswd
passez sous cet utilisateur avec la commande "su <nom de l'utilisateur>"
créez un fichier dans son home
sur tiny, connectez-vous avec smbclient au partage homes avec le login et le mot de passe du compte
vérifiez que vous pouvez accéder au fichier créé précédemment (en le téléchargeant par exemple)

TP Apache

Dans ce TP nous allons configurer le serveur web le plus utilisé sur Internet : Apache. Il permet d'héberger des sites webs et dispose d'une multitude de configurations et de modules complémentaires. Nous allons voir comment créer un site web, le rendre dynamique et le protéger par mot de passe.

Documentation associée : Apache.

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez ~reseaux/vdn-0.6/scripts/bigbossBaseConfig si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)

Lancement d'Apache

Essayez de lancer le démon Apache avec /etc/init.d/apache2 start sur bigboss
Si Apache est lancé tant mieux ! Dans le cas contraire:
- Vérifiez que le nom de votre machine est fixé dans /etc/hostname,
- Ajoutez dans /etc/hosts le couple adresse_ip nom_de_votre_machine
- Pour enlever le warning d'Apache concernant le nom de domaine, ajoutez dans /etc/apache2/apache2.conf la ligne ServerName nom_de_votre_machine.
- Relancez le démon Apache

Accéder à la page d'accueil du serveur

Il y a plusieurs moyens pour accéder au serveur HTTP de bigboss :

soit à partir de tiny en mode texte avec la commande lynx http://bigboss/
soit à partir de tiny en mode graphique avec la commande firefox http://bigboss/ ou iceweasel http://bigboss/
soit à partir du système hôte avec un navigateur, en utilisant l'adresse http://localhost:PORT/, où le PORT à utiliser est indiqué à côté du port 80 dans la page "Informations" du menu qui permet de lancer bigboss

Modification de la racine du serveur Web

Créez un répertoire qui hébergera votre application Web (par exemple /home/http/html)
Créez dans ce répertoire le fichier HTML index.html. Attention, ce fichier doit être un fichier HTML et doit au moins contenir <html><body> ... </body></html>.
Modifiez dans le fichier de configuration (lequel ?) la racine du site.
Définissez pour le répertoire précédent des droits d'accès dans le fichier de configuration avec:

<Directory /home/http/html>
    Options Indexes FollowSymlinks Multiviews
    AllowOverride None
    Require all granted
</Directory>

Que signifient ces lignes (voir la documentation associée) ?
Relancez le serveur Apache (au cas où ce n'est pas fait) et vérifiez le fonctionnement.

Fichier par défaut

Apache permet de spécifier des fichiers par défaut appelés lorsqu'un répertoire est demandé (URL non terminée par un nom de fichier)

Recherchez dans le fichier de configuration du module "dir" les fichiers par défaut.

Configuration des ressources

Supposons que le serveur soit hébergé par une machine aux ressources limitées, et que le nombre de requêtes qui lui sont adressées n'est jamais considérable.

Il y a 5 serveurs WEB en exécution lors du démarrage d'Apache, et 10 au maximum simultanément. Comment le vérifiez vous ?
Votre capacité mémoire est limitée; modifiez ces nombres en 3 et 15.
Redémarrez Apache
Utilisez la commande ps pour voir le nombre de démons Apache et expliquez ce que vous remarquez (il faut passer des options à ps pour voir les démons). Expliquez notamment pourquoi vous en observez plus de 3, et même plus de 4.

Création d'un script CGI

Vérifiez que votre serveur Apache possède un répertoire permettant d'accéder aux scripts cgi.
Créez le répertoire /home/http/cgi-bin.
Modifiez le fichier de configuration pour que votre serveur Apache utilise par défaut le répertoire /home/http/cgi-bin comme répertoire où placer des scripts cgi.
Créez un script shell CGI en bash (qui affiche "toto", par exemple), et essayez de le faire fonctionner. Vous pouvez vérifier que votre script fonctionne en l'exécutant directement en ligne de commande.

Configuration de PHP

Activez le module PHP.
Créez une page PHP et vérifiez qu'elle fonctionne. Par exemple /home/http/html/index.php contenant :

Nous sommes le <?php echo date('d/m/Y'); ?>, il est <?php echo date('G:i:s'); ?>.

N'oubliez pas les balises HTML autour de ce code.

Pages web personnelles

Vérifiez si le module userdir est activé

Par défaut, comment s'appelle le répertoire où un utilisateur, ayant un compte Linux, peut placer des pages html personnelles ?
Créez un utilisateur sasa, puis dans son répertoire personnel, ajoutez le nécessaire (1 répertoire et une page Web personnelle) pour avoir un accès aux pages personnelles.
Vérifiez que cette page est accessible via un navigateur.

Protection par mot de passe

Le principe :

La directive: AccessFileName .htaccess doit être activée (à votre avis, dans quel fichier de configuration ?). Les directives contenues dans ce fichier sont systématiquement interprétées avant d'autoriser l'accès au répertoire qui le contient. Voici les directives usuelles et leurs significations:

AuthType basic, type d'authentification communément adopté, fait hélas circuler les mots de passe en clair
AuthName texte, affichera le texte comme invite dans la boîte de dialogue
AuthUserFile /etc/apache2/users, indique où vont se trouver les mots de passe
AuthUserFile chemin/fichier, précise le fichier qui contient les comptes et mots de passe des utilisateurs ayant des droit d'accès
Require valid-user|liste-noms tous, ou seulement les comptes énumérés dans la liste, auront accès

On demande ici de protéger l'accès à un nouveau site pour qu'il devienne privé. Pour créer ce site, créez le répertoire /home/http/html/prive puis copiez y le fichier HTML que vous avez précédemment fait. Il ne devra être accessible qu'à un ensemble limité de comptes Apache (et non Linux) à créer. La première requête adressée à ce répertoire protégé provoquera l'affichage d'une boîte de dialogue par laquelle l'utilisateur devra s'authentifier (nom et mot de passe).

Créez dans le répertoire "prive" le fichier .htaccess suivant:

AuthType Basic
AuthUserFile /etc/apache2/users
AuthName "Accès privé"
Require user sasa

Créez le compte sasa dans le fichier users situé dans /etc/apache2 (le fichier n'existe pas, il va être créé). Pour cela, entrez dans le répertoire /etc/apache2 et tapez les commandes suivantes:

htpasswd -c users sasa
htpasswd users prof

Sur certains systèmes, la commande s'appelle htpasswd2.

Vous pourriez en réalité créer le fichier users n'importe où, du moment que vous spécifiez un chemin correct dans la directive AuthUserFile.

Examinez le fichier users ainsi créé. Qu'obtenez vous ? Qu'avez vous fait ?

Ajoutez dans le fichier de configuration d'Apache 2, si elle n'existe pas, la règle suivante de fichier. Que permet cette règle ?

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>

Testez l'accès à la page prive/index.html avec un navigateur. La protection ne devrait pas fonctionner !

Recherchez dans le fichier de configuration d'Apache le bloc <Directory /home/http/html> concernant les droits d'accès du répertoire par défaut qui fixe des directives par défaut. La valeur de l'option AllowOverride ne doit pas être None (dans ce cas la prise en compte de .htaccess est désactivée). Changez cette valeur en All.

Retestez avec succès ! N'oubliez pas de relancer le navigateur quand on change de compte.

TP FTP

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez ~reseaux/vdn-0.6/scripts/bigbossBaseConfig si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)

Configuration de base

Vérifiez si le démon /etc/init.d/proftpd est lancé sur bigboss et lancez le si ce n'est pas le cas.
Créez un répertoire /home/ftp si ce n'est déjà fait. Créez ou modifiez le fichier proftpd.conf permettant l'accès au répertoire précédent.
Déclarez le répertoire comme la racine du serveur ftp.
Ajoutez à votre configuration un message de bienvenue.
Relancer le démon ftp
Vérifiez que vous pouvez vous connecter au serveur ftp de bigboss en utilisant la commande ftp sur tiny. Les login et mdp correspondent à un compte unix sur bigboss.

Blocage des accès

Refusez l'accès à votre serveur ftp à l'utilisateur "toto" avec l'utilisation de la commande UseftpUsers (dans le fichier proftpd.conf) et du fichier /etc/ftpusers. Relancez le service et vérifiez que l'utilisateur "toto" ne peut pas se connecter à votre serveur. Si ce compte n'existe pas, créez le !
Ajoutez une commande dans le fichier de configuration pour refuser l'utilisation de la commande "cd" par les utilisateurs.

Dans ce cas, vous devez créer un contexte Limit avec la commande CWD (et non cd).

Accès anonyme

Créez le répertoire /home/ftpanonyme sur bigboss et créez un fichier dans ce répertoire.
Activez l'accès anonyme dans ProFTPD et configurez-le pour que les utilisateurs anonymes accèdent au répertoire que vous avez créé quand ils se connectent.
Connectez-vous en anonyme (login anonymous) à partir de tiny et téléchargez le fichier que vous avez créé.
Faites en sorte que les utilisateurs anonymes ne puissent pas créer ou modifier les fichiers ou répertoires

TP TCP Wrapper

Préalable

Lire le wikilivre sur TCP Wrapper
tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez ~reseaux/vdn-0.6/scripts/bigbossBaseConfig si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)
Apache doit être configuré

inetd.conf

Ouvrir le fichier /etc/inetd.conf. Puis, indiquez et commentez les services auxquels vous avez accès. En connaissez vous certains? lesquels ?

telnet

Vérifiez si dans inetd.conf vous avez accès à telnet. Puis essayez de vous connecter avec telnet bigboss. Si ça ne fonctionne pas, vous avez loupé quelque chose auparavant...

hosts

Lisez les fichiers hosts.allow et hosts.deny. Contiennent-ils des règles ? Autorisez tiny à se connecter avec telnet sur bigboss avec une règle dans le fichier hosts.allow. Créez une règle pour tout interdire dans le fichier hosts.deny.

Dans ce cas, votre règle sur telnet sera permise et tout le reste sera refusé. N'oubliez pas de redemarrer le service (/etc/init.d/inetd reload, ou si /etc/init.d/inetd, la façon brute : killall inetd, inetd).

Remarque : sous Debian Lenny le script de gestion d'inetd est /etc/init.d/openbsd-inetd.

Pour des raisons de facilités par rapport aux prochains TP, videz les fichiers hosts.allow et hosts.deny.

tcpdchk

Utilisez la commande tcpdchk -av. Que donne et fait cette commande ?

TP Tcpdump

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez ~reseaux/vdn-0.6/scripts/bigbossBaseConfig si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)
Un serveur FTP doit être configuré

Capture de trames ICMP via la commande ping

sur bigboss, lancer tcpdump sur l'interface réseau qui relie tiny et bigboss ("-i eth0")
lancer un autre terminal sur bigboss ("Shell" dans le menu de bigboss)
lancer la commande ping tiny
repérer dans l'affichage obtenu par tcpdump la source, la destination et le type de chaque paquet généré par les pings

FTP

lancez tcpdump dans une console de bigboss pour que ce dernier récupère les trames du port 21 (source ou destination) et affiche le contenu des paquets sous forme ASCII. Redirigez la sortie de tcpdump vers un fichier nommé trames (avec ">")
passez sur un autre terminal et initier une connexion ftp à partir de tiny, en entrant un login et un mot de passe
une fois la connexion ftp établie, quitter tcpdump (Ctrl+C)
repérez dans le fichier trames les paquets, leur adresse source, leur adresse destination, les options, l'entête, le message
repérez les paquets contenant le login et le mot de passe

Utilisation de wireshark

Wireshark est un outil d'analyse de trafic réseau, disponible pour de nombreux OS et possédant une interface graphique. Lancez Wireshark.

Vous trouverez une barre d'outils et 3 fenêtres:

Les différents boutons permettent de créer une nouvelle analyse du réseau, d'ouvrir un fichier d'analyse, d'en fermer un, de l'imprimer, etc etc.
La première fenêtre répertorie les trames reçues (source, destination, type de trames). La seconde décrit le contenu d'une trame sélectionnée dans la première fenêtre. Quant à la troisième fenêtre, elle donne le code hexadécimal de la même trame.

Vous pourrez aussi trouver une liste de menus : les classiques (file, edit...), un menu capture (pour démarrer et éditer les filtres de capture) et entre autre un menu analyse (affichage des filtres d'analyse, affichage des protocoles pris en compte). La liste des protocoles est plutôt longue, jetez y un œil !

Pour le reste (notamment pour les filtres) la documentation de Wireshark est disponible à www.wireshark.org.

A

Commençons par faire une nouvelle analyse.

Lancez wireshark-gtk en tache de fond à partir de tiny.

Cliquez sur le premier bouton start a new live capture. Une nouvelle fenêtre, permettant d'ajouter des options, apparaît. Vous devez commencer par choisir une interface, dans notre cas la carte Ethernet (eth1). Vous pouvez créer un filtre pour n'analyser que les trames et paquets IP qui vous intéresse. Pour les autres options voir l'aide !

Ne créer aucun filtre et cliquez sur ok. La capture de trames commence. Connectez vous à bigboss (par http ou ftp, ou samba ou ssh...) Stoppez la capture après la réception de quelques trames.

Quelles sont les trames que vous avez reçues ? type, source ? que contiennent t-elles ?

B

Effectuez une nouvelle analyse avec wireshark en créant un filtre de capture :

src <adresse ip de tiny> and tcp port 21

... ou en utilisant un filtre dans la fenêtre principale de wireshark:

ip.src == <adresse ip de tiny> && tcp.port == 21

Ce filtre permet de capturer uniquement les trames provenant de tiny contenant un flux ftp. Wireshark permet de filtrer sur les adresses MAC, IP sur les ports... (voir l'aide). Connectez vous sur votre serveur ftp. Récupérez le login et le mot de passe qu'ils ont utilisés.

TP SSH

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez ~reseaux/vdn-0.6/scripts/bigbossBaseConfig si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)
Un serveur FTP doit être configuré

Utilisation basique d'SSH

Consultez le fichier /etc/ssh/sshd_config (sur bigboss) et repérez les options décrites dans les notes et leur valeur.
Créez un compte sur bigboss (ou utilisez un précédent) et essayez de vous connecter à partir de tiny.

Capture de paquets SSH

Essayez de récupérer avec la commande tcpdump (ou wireshark) les trames provenant de tiny et faites une redirection vers le fichier trames.
Connectez vous sur tiny avec SSH à bigboss comme dans l'exercice précédent.
Pouvez vous lire le mot de passe?

Création de clé publique/privée

Créez une paire de clés publique/privée sur tiny. Ne modifiez pas le nom des clés : appuyez simplement sur "Entrée" quand il vous demande le nom du fichier. Attention: une pass phrase vous est demandée, retenez la !

Connexion par passphrase et non par mot de passe

Envoyez la clé publique sur bigboss par ftp ou avec la commande SCP.
Ajoutez cette clé publique dans le fichier /home/compte-bigboss/.ssh/authorized_keys. (J'ai bien écrit le fichier !)
Connectez vous sur bigboss avec SSH avec une authentification par clé (si cela fonctionne, on vous demande une passphrase pas un password).

Agents

Lancez un agent SSH, ajoutez-lui la clé et connectez-vous sans qu'il ne demande ni mot de passe ni passphrase.

Tunnels SSH

Créez un tunnel entre tiny et bigboss, entre les ports 1234 et 21, avec la commande ssh -N -f -L 1234:<adresse IP de bigboss>:21 <adresse IP de bigboss> -l login.
Récupérez les paquets IP provenant de tiny avec tcpdump et placez les dans le fichier trames3.
Une fois la commande tcpdump lancée, faites ftp localhost 1234 (sur tiny). Par le port forwarding, vous aboutissez en fait sur le serveur FTP de bigboss, à travers une connexion encryptée.
Entrez un login et un mot de passe, puis quittez. Recherchez le mot de passe dans le fichier trames3 ?

TP DHCP

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez le script de vdn-scripts baseConfigBigboss si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)

Le protocole DHCP (pour Dynamic Host Configuration Protocol) est un protocole réseau dont le rôle est d'assurer la configuration automatique des paramètres TCP/IP d'une station, notamment en lui assignant automatiquement une adresse IP et un masque de sous-réseau (cf. Wikipedia par exemple pour les généralités).

Le protocole DHCP est très souvent mis en œuvre par les administrateurs de parc de stations car il offre l'énorme avantage de centraliser la configuration des stations sur une unique machine : le serveur DHCP. Le principal danger de DHCP est qu'en cas de panne du serveur DHCP, plus aucune station n'accède au réseau !

Dans un exercice précédent vous aviez configuré tiny manuellement (adresse IP, masque de sous réseau, nom d'hôte). Nous vous proposons d'automatiser la configuration de tiny via DHCP. Pour cela nous avons installé pour vous sur tiny le paquet debian dhcp-client et sur bigboss le paquet dhcp-server.

Interfaces

Pour choisir les interfaces sur lesquels le serveur est lancé, il faut modifier /etc/default/isc-dhcp-server en indiquant par exemple

INTERFACES="ethx" (x étant le numéro de l'interface utilisée par le DHCP)

Il est obligatoire d'avoir une section "subnet" (voir ci-dessous) pour le réseau de chaque interface.

Récupération de l'adresse MAC

Récupérez l'adresse MAC de l'interface eth1 de tiny en effectuant un ifconfig -a (ou ip a) et notez la valeur (6 octets en hexadécimal) indiquée par le champ Ether (ou link/ether).

C'est grâce à cette adresse MAC que s'effectuera l'identification de tiny par le serveur. On rappelle que l'adresse MAC est unique pour toute carte Ethernet. On rappelle également qu'une adresse MAC peut être changée (reprogrammation de la carte) et donc qu'une authentification par adresse MAC dans un réseau n'est valable que pour les réseaux de confiance.

Configuration du serveur DHCP

Éditez le fichier /etc/dhcp/dhcpd.conf et ajoutez les lignes suivantes

subnet 192.168.30.0 netmask 255.255.255.0 {
host tiny {
                       hardware ethernet XX:XX:XX:XX:XX:XX;
                       option host-name tiny;
                       fixed-address tiny;
         }
}

La première ligne (subnet) précise le réseau géré. La seconde ligne (host) indique une nouvelle station. La troisième ligne (hardware ethernet) permet d'identifier le client via son adresse MAC. La quatrième ligne (option host-name) indique le nom d'hôte (le client fixera son nom d'hôte avec la valeur précisée). Enfin la cinquième ligne (fixed-address) précise que l'adresse IP de l'hôte est fixe et est celle de l'hôte tiny (précisée dans /etc/hosts).

Relancez le service dhcp (/etc/init.d/isc-dhcp-server restart)

Modifications sur tiny

Pour tester la configuration automatique de l'adresse IP ainsi que du nom d'hôte,

Commentez la définition actuelle de l'interface eth1 dans /etc/network/interfaces et ajoutez la nouvelle définition suivante :

     auto eth1
     iface eth1 inet dhcp

Renommez /etc/hostname en /etc/hostname.bak.

En déconfigurant eth1 (ifdown eth1) et en reconfigurant eth1 (ifup eth1) vous devez constater que l'adresse IP est bien récupérée via le serveur DHCP.

Pour un test complet redémarrez tiny. Son interface eth1 ainsi que son nom d'hôte doivent être correctement configurés.

Pour éviter que l'interface eth1 et que le nom d'hôte de tiny ne se configure pas si bigboss n'est pas démarré, repassez à la configuration "statique" antérieure.

TP Global

Préalable

Il est recommandé de repartir avec des systèmes vierges pour se mettre en situation (le TP noté sera fait sur un système vierge).

Configuration réseau

donner de manière permanente l'adresse IP 192.168.30.22 à tiny
faire en sorte qu'un "ping bigboss" de tiny fonctionne
faire en sorte qu'un "ping tiny" de bigboss fonctionne

CGI protégé par mot de passe

créer un utilisateur "bob" sur bigboss
créer dans son home un répertoire "cgi"
créer dans ce répertoire un script CGI en shell qui affiche l'espace disque (grâce à la commande "df", consulter le man)
faire en sorte que le CGI fonctionne quand on accède à "http://bigboss/bobcgi/nom_du_script" à partir de tiny
protéger ce CGI avec un mot de passe

Firewall

Créer un script de firewall qui bloque tout sur bigboss sauf :

toute communication avec le système hôte,
les connexions SSH
les accès à son serveur web,
les connexions telnet venant de tiny

Lancer le script et vérifier qu'il bloque bien ce qu'il faut.

SSH avec agent

créer un utilisateur teddy sur tiny et passer sous cet utilisateur
générer une clé SSH
autoriser cette clé à se connecter sur le compte bob de bigboss
à partir de teddy sur tiny, se connecter sur le compte bob de bigboss et vérifier qu'il demande la passphrase et pas le mot de passe
revenir sous teddy et lancer un agent ssh
ajouter la clé à l'agent
se reconnecter sur le compte bob de bigboss (à créer si ce n'est pas déjà fait) et vérifier qu'il ne demande ni le mot de passe ni la passphrase
revenir sous teddy et copier un fichier sur bigboss sans qu'il ne demande de mot de passe ou de passphrase

Capturer un mot de passe HTTP avec tcpdump ou wireshark

Trouver dans les paquets réseau (capturés avec tcpdump ou wireshark) le mot de passe envoyé lors de l'accès au CGI créé au début du TP. Utiliser un filtre qui sélectionne le minimum de paquets.

Répertoire partagé par NFS, Samba, FTP et Web

créer un répertoire sur bigboss
le partager avec NFS et le monter sur tiny, de manière à pouvoir écrire dedans à partir de tiny
le partager avec Samba de manière à pouvoir écrire dedans à partir d'XP
faire en sorte qu'il soit la racine du site web par défaut de bigboss
vérifier que les fichiers créés par NFS, Samba et FTP sont accessibles depuis un navigateur web

TP Netfilter

Préalable

tiny et bigboss doivent être lancés (voir TP VDN)
le réseau de bigboss doit être configuré (lancez ~reseaux/vdn-0.6/scripts/bigbossBaseConfig si ce n'est pas déjà fait)
le réseau de tiny doit être configuré (voir TP Configuration réseau)
Apache doit être configuré

Introduction

Lire le wikilivre sur Netfilter
Afficher les règles contenues dans les chaînes INPUT, OUTPUT et FORWARD sur bigboss. Il ne devrait y en avoir aucune.
créez des scripts pour écrire vos règles voir ici.
Attention l'interface eth1, utilisée par les systèmes virtuels ne doit pas être bloquée !

LOG

Ajoutez sur bigboss (de préférence grâce à un script) une règle dans la chaîne INPUT qui enverra sur la cible LOG toutes les trames ICMP reçues.
Affichez les règles de cette chaîne et vérifier que celle ajoutée apparaît.
Lancer un ping de tiny vers bigboss
Vérifiez que les paquets sont affichés. S'ils ne le sont pas, ouvrir un terminal sur bigboss et lancer la commande tail -f /var/log/kern.log
Faites un ping de bigboss vers une adresse IP inconnue (par exemple 1.2.3.4) et constatez le résultat.

Politique de blocage par défaut

Lancez le serveur Web et vérifiez qu'il fonctionne.
Créez un script, pour tout interdire.

ATTENTION: L’INTERFACE ETH1 NE DOIT PAS ÊTRE BLOQUÉE : si vous utilisez une police par défaut il faut ensuite re-autoriser eth1. Le plus simple est peut être d'interdire l'accès pour eth0 (2 règles). À vous de voir.

Lancez votre script et vérifiez que le serveur Web n'est plus joignable.

Autorisation d'accès

Ajouter les règles autorisant l'accès au serveur telnet sur bigboss et testez à partir de tiny (commande telnet).
Ajoutez les règles permettant l'accès au serveur Web de bigboss à partir de tiny.
Quels sont les adresses IP et les ports autorisés en source ? en destination ?
Vérifier que le serveur Web est de nouveau joignable.
Faites de même avec l'autorisation d'accès à la commande ping. Et seulement ping pas pour tout ICMP. (il faut utiliser l'option --icmp-type avec echo-request ou echo-reply).

TP Licence - Configuration réseau

Documents utiles : Configuration réseau, DHCP, Routage, Netfilter

mettre un nom d'hôte à tiny de manière à ce qu'il reste actif au prochain démarrage
mettre une adresse réseau à tiny de manière à ce qu'il puisse communiquer avec bigboss
faire en sorte que cette adresse soit définie au démarrage de tiny (si ce n'est pas déjà le cas) et vérifier que ça fonctionne
faire en sorte que tiny puisse communiquer avec bigboss en utilisant son nom d'hôte, et inversement
faire en sorte que ce soit bigboss qui attribue l'adresse IP à tiny
vérifier que bigboss peut communiquer avec le bigboss d'un autre groupe
faire en sorte que tiny puisse communiquer avec le bigboss d'un autre groupe

TP Licence - Deux sites web derrière un firewall

Documents utiles : Administration réseau sous Linux

Nous allons installer des sites web derrière un firewall. C'est une pratique courante lorsqu'on souhaite héberger des sites web. Les principes mis en pratique ici sont valables pour un hébergement en interne (sur vos propres machines) mais également avec des serveurs dédiés (le plus courant pour héberger des sites web, en dehors des hébergements mutualisés).

Nous utiliserons les machines virtuelles suivantes :

bigboss qui sera notre firewall
tiny qui hébergera les sites web derrière bigboss
surfer qui représentera un internaute voulant accéder à nos sites web
FAI qui aura le rôle d'un fournisseur d'accès à internet : il fera le lien entre bigboss et surfer

Le schéma du réseau est le suivant :

Sur internet, les noms de domaine sont gérés par des serveurs DNS. Nous utiliserons à la place le fichier /etc/hosts pour indiquer l'adresse IP des noms que nous utiliserons.

Pour accéder aux sites web dans les terminaux des machines virtuelles, nous utiliserons lynx, un navigateur en mode texte.

Préparation de l'environnement

Faire en sorte que bigboss et surfer puissent communiquer en passant par FAI.

Préparation du serveur web

Configurer deux sites web sur tiny. Ils auront chacun un nom de domaine et un répertoire racine différents.

Routage

Configurer bigboss pour qu'il redirige les requêtes web sur tiny.

Vérifier qu'on peut accéder aux deux sites web à partir de surfer.

Toujours à partir de surfer, accéder aux sites web d'un autre groupe.

Firewall

Interdire sur bigboss tous les paquets qui ne sont pas utiles à l'accès au serveur web de tiny ou aux transferts sur eth3.

Attention, il est impératif de laisser passer tous les paquets qui transitent par eth3 car c'est le seul lien entre votre terminal et bigboss. Si vous bloquez ces paquets, bigboss ne répondra plus et vous perdrez les modifications que vous avez faites.

Modification des sites par FTP

Faire en sorte qu'on puisse modifier les 2 sites web par FTP à partir de surfer. On doit avoir un nom d'utilisateur différent pour chaque site web.

Le protocole FTP étant difficile à rediriger, on fera tourner le serveur directement sur bigboss. Tiny exportera la racine des sites web par NFS et bigboss les montera dans le home des utilisateurs.

Configuration définitive

Faire en sorte que tout ceci soit paramétré au démarrage des machines.

Documents utiles :

man boot (sections boot scripts et sequencing directories)
man update-rc.d

TP Licence - Serveur intranet

Objectif

Configurer un serveur intranet pour les besoins d'une petite entreprise.

Rôles

bigboss est le serveur intranet
tiny est un poste utilisateur sous Linux
XP est un poste utilisateur sous Windows
surfer est un poste utilisateur distant sous Linux
FAI est le fournisseur d'accès à internet de surfer

Réseau

bigboss, tiny et XP sont reliés au réseau interne de l'entreprise.
bigboss et FAI sont reliés à internet
surfer est relié à FAI

Dans notre environnement, internet est le réseau qui relie tous les bigboss et FAI.

Résultat demandé

Les configurations doivent être permanentes (càd effectives au démarrage des machines).

La configuration réseau des machines reliées au réseau interne doit être automatique.
Toutes les machines du réseau interne doivent pouvoir accéder à internet.
Les machines du réseau interne (et uniquement elles) doivent pouvoir écrire et lire dans un répertoire partagé.
Le contenu du répertoire partagé doit être accessible à l'adresse http de l'entreprise (que ce soit à partir du réseau interne ou d'internet). Cet accès doit être protégé par mot de passe.
tiny doit pouvoir accéder à bigboss par SSH avec un mot de passe
surfer doit pouvoir accéder à internet.
surfer doit pouvoir accéder à bigboss en SSH avec une clé SSH.
bigboss doit bloquer tous les paquets qui viennent d'internet et qui ne sont pas utiles aux services décrits ci-dessus.

Notes

Pour configurer une adresse réseau dynamique sous Windows il faut :

aller dans le Panneau de configuration,
puis dans Connexions réseau,
puis de nouveau dans Connexions réseau,
cliquer avec le bouton de droite sur la carte réseau,
sélectionner Propriétés
afficher les propriétés du protocole TCP/IP
activer l'attribution automatique de l'adresse IP

Pour demander à windows de redemander une adresse IP au serveur DHCP, il faut

ouvrir un terminal (exécuter "cmd")
taper "ipconfig /renew"

Pour voir l'adresse IP attribuée, taper "ipconfig" dans un terminal.

GFDL

Vous avez la permission de copier, distribuer et/ou modifier ce document selon les termes de la licence de documentation libre GNU, version 1.2 ou plus récente publiée par la Free Software Foundation ; sans sections inaltérables, sans texte de première page de couverture et sans texte de dernière page de couverture.

[1] ttps://www.tecmint.com/connect-nginx-to-php-fpm/

[2] ttps://httpd.apache.org/docs/2.4/fr/mpm.html

[3] ttp://httpd.apache.org/docs/current/fr/howto/cgi.html

[4] ttp://wiki.uniformserver.com/index.php/CGI:_VBScript_CGI

[5] ttp://httpd.apache.org/docs/2.2/mod/core.html#allowoverride

[6] ttp://httpd.apache.org/docs/2.2/mod/core.html#servername

[7] ttps://httpd.apache.org/docs/2.4/fr/vhosts/examples.html

[8] ttp://httpd.apache.org/docs/2.2/vhosts/

[9] ttps://httpd.apache.org/docs/2.4/mod/core.html#include

[10] ttps://www.vincentliefooghe.net/content/configuration-apache-24-php-fpm Exemple sur machine hôte

[11] ttp://www.inanzzz.com/index.php/post/su76/creating-apache-mysql-and-php-fpm-containers-for-a-web-application-with-docker-compose Exemple avec Docker

[12] ttp://doc.ubuntu-fr.org/proftpd

[13] ttp://www.proftpd.org/docs/howto/ConfigFile.html

[14] ttp://www.proftpd.org/docs/

[15] ttps://www.digitalocean.com/community/tutorials/how-to-configure-proftpd-to-use-sftp-instead-of-ftp

[1]

[2]

[3]

[4]

[1]

[1]

[2]

[3]

[4]

[5]

[6]

[1]

[2]

[3]

[4]

None	Désactive toutes les options.
All	Active toutes les options SAUF Multiviews.
Indexes	Permet aux utilisateurs d'avoir des indexs généré par le serveur. C'est à dire si l'index du répertoire (`index.html` le + souvent) est manquant, cela autorise le serveur a lister le contenu du répertoire (dangereux suivant les fichiers contenu dans ce répertoire).
FollowSymLinks	Autorise a suivre les liens symboliques.
ExecCGI	Autorise à exécuter des scripts CGI à partir de ce répertoire.
Includes	Autorise des fichiers include pour le serveur.
IncludesNOEXEC	Permet mais les includes mais empêche la commande EXEC (qui permet d’exécuter du code).
MultiViews	Autorise les vue multiples suivant un contexte. Par exemple permet d'afficher les pages dans un langage suivant la configuration du langage du client.
SymLinksIfOwnerMatch	Autorise a suivre les liens seulement si l'user ID du fichier (ou répertoire) sur lequel le lien pointe est le même que celui du lien.

All	Gère tout ce qui est dans .htaccess
AuthConfig	Active les directives d'autorisations AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, etc.
FileInfo	Active les directives contrôlant le type de document (ErrorDocument, LanguagePriority, etc.)
Limit	Active la directive d'autorisation Limit
None	Ne lit pas le fichier .htaccess et laisse les droits "Linux" de ce répertoire.
Options	Active la directive Option

deny,allow	Si le client ne correspond à aucune règle deny , mais correspond à une règle allow , alors on autorise (allow par défaut).
allow,deny	Si le client ne correspond à aucune règle allow , mais correspond à une règle deny , on interdit (deny par defaut).\hline

Nom d'hôte	Autorise/Refuse les hôtes spécifié, les adresses IP, le nom de domaine, etc...
All	Autorise/Refuse tout le monde

Administration réseau sous Linux/Version imprimable

Configuration réseau

Installation de la carte réseau

Configuration de l'interface réseau

Adresse IP

Passerelle et routage

Tester le réseau

Informations sur les interfaces

>Nom d'hôte (hostname)

>Configuration automatique au démarrage

Résolution de noms d'hôte

Serveurs DNS

Fichier hosts

Problèmes connus

ping: unknown host

NFS

Installation côté serveur

Configuration

Installation côté client

Montage au démarrage

Samba

Configuration du service Samba

Exemple

Configuration du partage des répertoires

Exemples

Protéger les répertoires partagés

Lancement du service

Accès aux répertoires

Apache

Installation

LAMP

Installation manuelle

Apache sur Debian / Ubuntu

Installer PHP

Mise à jour

Bibliothèques

Désinstaller PHP

Apache sur Gentoo

MySQL seul

APT

Variante

Sur Gentoo

Modules

Sites

Problème d'encodage d'Apache2

Encodage par défaut en Latin1 (ISO-8859-1)

Aucun encodage par défaut

Fichiers log

Configuration de base

Configuration du serveur

Configuration des modules

Configuration des sites

Quelques directives classiques

Gestion du nombre d'instances d'Apache

Exemple commenté

Paramétrage des répertoires

Gérer les pages Web personnelles

Configurer l'accès aux scripts CGI

Activer le module

ScriptAlias

ExecCGI

AddHandler

Récapitulatif

Écrire un programme CGI

Bash

Perl

Python

VBS

Références

Le module PHP

Principe

Installation

Références

Serveurs virtuels (virtual hosts)

Principe du vhost

Configuration

Include

ProxyPassMatch

Références

Exemples de configuration