LéaBook
, Chapitre :
Réseau
par tous les amis de Léa
Le copyright de chaque article est détenu
par son auteur.
Le copyright du livre lui-même est détenu par Léa
(Association Loi 1901).
Les articles de ce livre sont diffusés selon la license GPL (GNU
General Public License), sauf mention explicite dans l'article.
Copyright (c) 2003 Association Léa.
This documentation is free documentation; you can redistribute it
and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
This documentation is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of
the GNU General Public License along with this program; if not,
write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, USA.
For the purpose of applying the GPL to this document, I
consider "source code" to refer to the html source.
Pour cette partie, en plus des documents présents ici, je vous renvoie au très bon site de Julien Danjou, LER (Linux En Réseau), ou à la page Linux de Funix, qui vous explique comment mettre votre Linux en réseau.
29/5/2000 : un IP-Masquerade HOWTO [lien mort ?] est sorti ! Il met à jour l'ancien mini-HOWTO... en attendant la traduction anglaise...
Nous avons besoin de correcteurs ! Si vous voulez nous aider, prenez le fichier source (voir lien en bas de chaque page), corrigez-le et envoyez-le moi par mail !
Voici les documents qui concernent le réseau (local
et internet) :
par Serge (quelques modifications par Fred et Jicé)
ou comment faire communiquer tous vos ordinateurs entre eux
Entre le 10 Mb ou le 100 Mb il suffit d'avoir le matériel qu'il faut, c'est a dire carte réseau, HUB ou SWITCH à 100 Mb. Seul les SWITCH permettent effectivement un "vrai" réseau en étoile. Certains HUBs ou SWITCH permettent de mélanger les deux types de vitesse, alors qu'en général, une carte 10 Mb/s oblige toutes les machines à communiquer en 10 Mb/s.Remarque : On trouve maintenant sur le marché des KITS carte réseau + HUB + câblage pour pas cher du tout (3 cartes, 1 HUB les câbles pour 400 fr), si vous devez faire un achat, prenez plutôt ça, attention quand même à ce que les cartes soient supportées par Linux (cf. : Hardware HOWTO).
Pour les cartes plus exotiques, regardez le Hardware-HOWTO et/ou demandez dans des listes de diffusion ou dans les news si quelqu'un a déjà réussi à faire marcher cette carte sous Linux.
alias ethX nom_module
Avec: X=0 pour la première carte réseau,
1 pour la seconde etc. (si vous n'avez qu'une seule carte réseau
- sur cette machine - alors X=0, soit eth0, est votre seule
possibilité)
nom_module : le nom du module (driver)
de la carte (ne2k-pci par exemple)
Pour savoir si des options sont nécessaires (cas des cartes NE 2000 ISA) voir la rubrique modules.
Adresse, classe d'adresse et masque réseau
Bon vous devez sûrement vous demander comment deux machines entre elles arrivent à communiquer. Et bien, tout simplement avec une adresse. C'est comme pour le courrier-escargot (merci la francophonie), quand quelqu'un veut vous envoyer un courrier il envoie une lettre et le facteur vous trouve grâce à l'adresse que vous avez pris soin d'écrire sur celle-ci. Bon et bien pour comprendre ce qui suit vous gardez ça en tête, en remplaçant trame réseau par courrier, et carte réseau par boîte à lettres. Si notre analogie n'est pas trop farfelue (elle ne l'est pas ;) chaque carte doit avoir une adresse réseau (i.e. adresse IP) , mais comme pour les grandes villes où il y a beaucoup de maisons, on découpe souvent un réseau en plusieurs sous-réseaux (le meilleur exemple est Internet lui-même qui est constitué de divers - et nombreux - réseaux plus locaux), pour permettre de les reconnaître facilement, on leur donne un "bout d'adresse" en commun. Puis, comme on classe les maisons par rues et numéros, on classe les réseaux par adresse de réseau (le "bout d'adresse" en commun) et adresse de carte (adresse complète comprenant l'adresse de réseau ainsi qu'une partie spécifique à la carte). Comment cela s'exprime-t-il ? Par une adresse qui comporte une partie "réseau" et une partie "hôte" (la partie spécifique à la carte) tout cela sur 4 octets (si vous savez pas ce qu'est un octet, ce n'est pas grave, dites vous que c'est un nombre compris entre 0 et 255). On représente alors l'adresse complète comme ceci :
W.X.Y.Z (où chaque lettre peut prendre une valeur entre 0 et 255 donc)
Bon d'accord, j'ai une adresse mais comment je reconnais le réseau et l'hôte? Et bien, on a coupé en classe de réseau toutes les adresses possibles suivant les valeurs de W. Je vous donne ce découpage, puis je l'explique:
Classe A: adresse comprise entre 1.0.0.0 à 126.255.255.255
Classe B: adresse comprise entre 128.0.0.0 à 191.255.255.255
Classe C: adresse comprise entre 192.0.0.0 à 223.255.255.255
Il existe la classe D aussi mais qui n'est pas utilisable, elle sert en fait au protocole lui-même dans son fonctionnement pour "atteindre" plusieurs machines à la fois (on appelle ça le multicast), on ne va pas détailler ça ici :-). Si vous avez bien suivi, vous avez pu constater que les adresses 0.x.x.x (utilisées pour l'adresse de route par défaut, c'est à dire le chemin à prendre pour aller sur un autre réseau), et 127.x.x.x (adresse interne de chaque machine pour les applications) ne sont pas utilisables non plus ...bref même si vous ne comprenez pas ce que je dis, rappelez vous simplement qu'elles sont tout simplement INUTILISABLES. Utilisez les adresses dans les plages ci-dessus (i.e.: correspondant aux classes A, B et C).
Chaque classe d'adresse a aussi son masque de sous réseau :
Classe A: 255.0.0.0
Classe B: 255.255.0.0
Classe C: 255.255.255.0
Bon maintenant j'explique. Quand vous voulez faire un réseau local IP, vous choisissez d'abord une classe. Bon laquelle choisir ? Ça va dépendre du nombres de machines que vous comptez connecter à votre réseau.
Pour comprendre, on ne va s'occuper que des réseaux de classe C (i.e.: ceux ne pouvant contenir que peu de machines), mais tout ce qui va suivre s'applique très simplement aux autres classes. Le masque réseau de la classe C est : 255.255.255.0. Cela veut dire que la partie W.X.Y de l'adresse W.X.Y.Z sert à adresser (contacter) le réseau (i.e. toutes les machines du sous-réseau auront le même W.X.Y) et le Z sert à adresser les machines. La partie du masque contenant les 0 nous donne la partie de l'adresse qui correspond à la machine. Donc cela nous donne :
Si le masque est 255.225.255.0 et que l'adresse d'une carte réseau est W.X.Y.Z alors W.X.Y.0 est l'adresse du réseau. Ce réseau peut être constitué de toutes les cartes W.X.Y.Z ou Z varie entre 0 et 254 (pas 255 car c'est là encore une adresse spéciale).
Quand on veut désigner l'adresse du réseau , on remplace par des 0 les identifiants machines.
Pour la classe C, chaque réseau a donc 254 (de 1 à 254 pour Z) machines possibles. De même pour la classe B on a 65 000 (et quelques) machines possibles. Pour la classe A on dispose de plus de 16 millions de machines possibles.
Pour configurer un réseau local, il vous faut de choisir l'adresse réseau que vous voulez. Bon on prend un exemple, je choisis 192.1.3.0 comme adresse de réseau donc classe C. Je peux alors numéroter mes machines de 192.1.3.1 à 192.1.3.254.
Bon vous allez me dire : On peux choisir n'importe quelle adresse ?
Je ne vais jamais avoir besoin de classe A : je n'ai pas 16 millions de
machines ? Etc... En fait ces classes ont été inventées
pour l'internet, on a attribué alors les classes A aux très
grandes organisations comme l'armée américaine (ça
été fait pendant la guerre froide hein) pour leur permettre
de relier toutes leurs machines. La B était pour les grand organismes
(université, industrie, etc...) et les classes C pour les petits
groupes. Comme vous vous en doutez, ces adresses sont attribuées
par un organisme international qui régit tout ça pour que
deux adresses ne soit pas dupliquées sur internet.
Donc en résumé si vous restez en local, sans aucune sortie
vers l'extérieur (même pas un modem vers le net), vous utilisez
l'adresse
que vous voulez en respectant son masque et la numérotation
réseau/machine.
Comme on a vu que les adresses sont attribuées sur le net, que ce passe-t-il si vous utilisez une adresse déjà utilisée sur le net ? Et bien, dans un premier temps, toutes les machines de votre réseau qui vont vouloir aller sur les sites internet qui possèdent la même adresse de réseau IP que vous ne pourront pas y accéder, car pour elles c'est l'adresse de chez vous donc elles ne vont pas chercher l'adresse sur le Net. Dans un second temps, vous allez être en relation avec d'autres machines qui vont forcément confondre votre réseau avec celui qui est enregistré sur internet. Mais alors, quelle adresse je choisis afin de ne pas entrer en conflit avec d'autres machines sur Internet ? Et bien l'organisme international a réservé des adresses qui ne seront JAMAIS utilisées (tous les routeurs du monde les ignorent !) sur le net pour que vous puissiez les utiliser en local ! Elle est pas belle la vie ! Ces adresses sont :
classe A: 10.0.0.0
classe B: 172.16.0.0 à 172.31.0.0
classe C: 192.168.0.0 à 192.168.255.0
Comme aucun site du net n'a cette adresse, si vous l'utilisez chez vous, vous ne risquez pas de ne pas pouvoir atteindre un site parce qu'il possède cette adresse vu qu'il n'en existe pas ! Donc pas de conflit entre votre réseau et le réseau des réseaux.
Donc, si vous avez un modem ou modem câble ou ADSL (voir rubrique ADSL) et si vous comptez surfer sur la toile un jour : UTILISEZ une des adresses réseau ci-dessus !!
Vous voulez que l'une de vos machines soit sur le net avec un beau site etc... : il vous faut alors acheter une adresse IP à votre fournisseur d'accès, soit pour un réseau complet et là vous n'avez pas le choix : on vous impose l'adresse, soit juste pour une machine, là votre machine connectée au NET a l'adresse que votre fournisseur vous impose et votre réseau local une des adresses réservées vue plus haut. En plus il va falloir faire du "masquerading" pour pouvoir utiliser l'accès au NET depuis toute les machines, voir pour cela la rubrique "masquerade" ou le HOWTO : vu d'internet, toutes les machines de votre réseau local ont l'adresse de la seule machine connectée au net (en fait, vu d'internet on ne voit que cette machine) :
En fait, vous pouvez aussi utilisez le système précédant pour créer des sous-réseaux à l'intérieur d'un sous-réseau de classe A, B ou C. Bon je ne vais pas expliquer ça ici non plus, reportez vous au site www.linuxenrezo.org pour plus de détail, de toute façon si vous devez faire de telles choses c'est que vous savez ce que vous faites._ ---- _ +---> PC2 ( ) | ( INTERNET )<-----> PC1 <---+---> PC3 (_ _) | ---- +---> PC4
Bon maintenant on va apprendre d'autres termes utile à une configuration réseau TCP/IP :
La carte est configurée au niveau HARD (module qui se charge bien), on a choisi/obtenu une adresse IP de réseau, on a décidé comment on adresse chaque machine : on peut réellement attribuer les adresses aux machines. Des utilitaires comme "netcfg", "netconfig" ou "linuxconf" permettent de configurer très facilement une carte réseau (voir www.linuxenrezo.org) mais bon je trouve plus ludique/instructif de vous l'apprendre à la main, comme ça on sait ce que l'on fait, de plus des distribution comme la Slackware ne possèdent pas ces outils par défaut.
Supposons, que l'on souhaite attribuer l'adresse X.X.X.X à la carte eth0 sur le réseau dont le masque de sous réseau du LAN est Y.Y.Y.Y (c'est pareil pour les autres cartes...). Rien de plus simple, on tape (en root) :
# ifconfig eth0 X.X.X.X netmask Y.Y.Y.Yet votre réseau est configuré ! (Il faut bien le reconnaître : c'est pas la mort). Bon pour ne pas avoir à configurer ça à chaque reboot, ajoutez cette commande dans un script de démarrage comme par exemple /etc/rc.d/rc.local.
IPADDR="192.168.1.1" (remplacez par l'adresse de votre machine)
NETMASK="255.255.255.0" (mettez votre masque de réseau, ici classe C)
NETWORK="192.168.1.0" (mettez votre adresse de réseau)
BRODCAST="192.168.1.255" (votre adresse de broadcast, c'est a dire votre adresse réseau avec les identifiants machines à 255)
Vérifiez que plus bas dans ce fichier il y a bien 'DHCP="no"'.
Le reste du fichier est OK. Toujours pour la Slackware, pour charger votre
module automatiquement, éditez le fichier /etc/rc.d/rc.modules,
decommentez la ligne (c'est à dire enlever le # en début
de ligne) qui correspond au module de votre carte réseau, par exemple
pour une pci ne2000:
/sbin/modprobe ne2k-pci
Maintenant il reste à dire au démarrage de Linux que cette carte va être configurée par un serveur DHCP, pour cela il faut un client DHCP, je traite ici de dhcpd (en fait il fait serveur et client à la fois). Il existe aussi pump et dhclient mais bon pour des goûts personnels que beaucoup partagent, je traite ici de dhcpd. Récupérez le donc (allez sur freshmeat par exemple ou rpmfind). Pour les kernels 2.2.X prenez une version au moins égale à la 1.3.x.
Il suffit alors de taper une ligne de commande du type :
dhcpd -d ethXPuis vérifier que votre carte à bien une adresse ip par:
ifconfigVous devrez voir une ligne avec lo et une autre avec ethX. Vérifiez que ethX n'a pas pour adresse 0.0.0.0, cela voudrait dire que cela n'a pas marché.
Bon après on automatise ça en incluant cette commande dans un script de démarrage de la machine (/etc/rc.d/localou rc.local etc...). Pour les RedHat et Mandrake, linuxconf permet ça, pour la Slackware, éditer /etc/rc.d/rc.inet1d et mettez l'option yes pour DHCP
DHCP="yes"
par Hervé J. Lombaert
10 Janvier 2001
permettre à votre LinBox de partager une connexion internet.
La distribution à choisir devra être alors légère, autant en espace mémoire qu'en ressources matérielles. Une installation graphique ainsi que d'autres gadgets superflus ne feraient qu'alourdir inutilement l'exploitation du gateway. Le choix s'est donc dirigé vers la distribution Debian Potato. Elle a été choisie pour sa légèreté, sa robustesse et surtout pour la rigueur demandée par sa configuration.
Sous Windows, ou même sous DOS, allez dans le répertoire D:\boot de votre premier cdrom Debian et lancez le programme rawrite2.exe. Créez dans un premier temps une disquette à partir de l'image rescue.bin, et dans un second temps une disquette à l'aide de l'image root.bin :
D:\install> rawrite2.exeVos deux disquettes en main, il est maintenant possible de commencer l'installation.
enter image file : rescue.bin
enter target drive : a:
Insérez la disquette rescue et lancez l'ordinateur. Après avoir démarré le processus d'amorçage, il vous sera demandé d'insérer la disquette root contenant les programmes d'installation.
À ce stade l'ordinateur est bootable, l'installation des programmes pourra débuter.
Dans ces deux modes, il faudra installer un serveur DHCP, DNS et Samba. Il faudra installer les logiciels de forwarding : ipchains et ipwadm.
Par la suite, je vous laisse découvrir les différentes manipulations que vous devrez effectuer afin d'avoir tout ces serveurs installés. C'est à vous de voir quels programmes vont être installés ; il est impossible de choisir à votre place et de fournir dans ce document toutes les manipulations pas à pas que vous aurez à effectuer. Gardez en tête que les choix par défaut font l'affaire la plupart du temps, et que chaque choix est correctement expliqué.
# /.bashrc: executed by bash(1) for non-login shells.À vous ensuite de rajouter les alias que vous souhaitez. L'alias clean='rm * -f' pourra par exemple être utile pour supprimer les fichiers de sauvegarde *.export PS1='\h:\w\$ '
umask 022# You may uncomment the following lines
# if you want `ls' to be colorized:
export LS_OPTIONS='-color=auto'
eval `dircolors`
alias ls='ls $LS_OPTIONS'
alias ll='ls $LS_OPTIONS -l'
alias l='ls $LS_OPTIONS'# Some more alias to avoid making mistakes:
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
Mis à part l'ordinateur, vous vous doutez bien qu'il faut deux cartes réseau (ou une carte réseau et un modem dans le cas d'un partage de connexion internet par modem). Les explications suivantes se baseront sur mon matériel, vous aurez donc à vérifier les drivers ou modules1 respectifs à utiliser dans votre cas.
bash# insmod 3c59xAucun paramètre supplémentaire n'est nécessaire : l'IRQ et le port IO seront trouvés automatiquement. Sous Debian, pour que ce module soit chargé automatiquement au démarrage, il faudra rajouter une ligne contenant "3c59x" au fichier /etc/modules :
bash# echo "3c59x" >> /etc/modulesou bien utilisez un éditeur de texte quelconque pour rajouter votre ligne vous même. N'oubliez pas de mettre à jour votre fichier /etc/modules.conf à l'aide de la commande :
bash# cat /etc/modules
bash# update-modulesNote de Jicé : pour un partage de connexion par modem, le modem remplace cette première carte. Il faut donc s'assurer de la présence du support PPP dans le noyau, ainsi que du paquetage pppd.
En vérifiant le fichier /proc/interrupts et /proc/ioports, il a été possible de trouver un canal IRQ et un port IO disponibles. Dans mon cas, l'IRQ 5 et le port IO 0x300 ont été choisis. Le module se charge donc comme suit :
bash# insmod depca "irq=5" "io=0x300"Comme vous devinez peut-être, le driver de la carte réseau DE201 est le module depca.o. Ce module supporte d'ailleurs plusieurs vieux modèles de cartes réseaux de marque Digital. J'ai remarqué également que si les paramètres n'étaient pas fournis, l'auto-détection ne fournissait pas le bon canal IRQ, ni le bon port IO, et qu'en plus de cela, l'ordinateur gelait ! Faites donc attention à fournir les bons paramètres.
Pour que ce module soit correctement chargé au démarrage avec les bons paramètres, il a fallu rajouter la ligne contenant "depca" au fichier /etc/modules et créer un fichier /etc/modutils/depca contenant les paramètres à prendre en compte :
bash# echo "depca" >> /etc/moduleset mettez à jour le fichier /etc/modules.conf à l'aide de :
bash# cat /etc/modules
bash# echo "options depca irq=5 io=0x300" > /etc/modutils/depca
bash# update-modulesVoilà en ce qui concerne pour la configuration des cartes réseau. Vous pourrez vérifier quel module utiliser pour vos cartes réseaux respectives dans un ethernet howto.
La première carte, la 3Com sera branchée à l'internet,
elle recevra automatiquement tous les paramètres par un serveur
DHCP situé chez le fournisseur internet. Il faudra donc rajouter
la ligne "iface eth0 inet dhcp" au fichier /etc/network/interfaces.
Note de Jicé : dans le cas du partage d'une connexion
par modem, vous devez configurer de manière classique cette connexion
à votre fournisseur d'accès.
La seconde carte, la Digital, sera branchée au réseau local. Il faudra lui attribuer les paramètres IP manuellement. L'adresse IP réservée de classe A, 192.168.1.1 sera celle choisie pour notre ordinateur. Cela se configure également dans le fichier /etc/network/interfaces.
Voilà donc de quoi aura l'air le fichier /etc/network/interfaces :
# /etc/network/interfaces - configuration file for ifup(8), ifdown(8)Pour brancher une carte réseau, il faut se servir de la commande ifup, pour la débrancher, la commande ifdown sera d'usure. La commande ifconfig permettra de vérifier les paramètres des cartes réseau branchées :# The loopback interface
iface lo inet loopback# eth0 - Reseau internet
iface eth0 inet dhcp# eth1 - local network
iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0
broadcast 192.168.1.255
bash# ifup eth0
bash# ifup eth1
bash# ifconfig
# dhcpd.confNotre réseau nommé ch19231.rez, il s'agit dans mon cas de la chambre 19231 d'une résidence universitaire, possède l'adresse 192.168.1.0. Notre ordinateur principal nommé headquarters possède l'adresse IP 192.168.1.1. Il est possible de monter 10 ordinateurs sur notre réseau, les adresses IP disponibles vont de 192.168.1.11 à 192.168.1.20. Le masque étant de 255.255.255.0 pour ne tenir compte que du dernier triplet de l'adresse IP.
# Herve J. Lombaert, 01/05/2001default-lease-time 600;
max-lease-time 7200;option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option domain-name "ch19231.rez";
option domain-name-servers 192.168.1.1;
option routers 192.168.1.1;subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.11 192.168.1.20;
}subnet 132.204.210.0 netmask 255.255.254.0 {
}
Après la configuration du serveur, il faudra l'activer. Il est possible de l'activer manuellement à l'aide de l'appel au serveur dhcpd. L'option -d permettra d'afficher à l'écran ce qu'il se passe au niveau de ce serveur :
bash# dhcpd -d eth1Lancez un ordinateur sur votre réseau local et vous vous remarquerez que le serveur DHCP affecte une adresse IP à l'ordinateur du réseau.
Lors du démarrage du système, le serveur est lancé par /etc/init.d/dhcp. Lorsqu'on démarre le serveur, un message explique qu'il faut modifier le fichier de lancement /etc/init.d/dhcp à la ligne 11, afin de mettre l'option run_dhcpd à 1. Par la même occasion, il faudra spécifier sur quelle interface le serveur DHCP doit écouter. Dans les modes start et restart, l'interface eth1 sera donc spécifié :
ligne 10: # Set run_dhcpd to 1 to start dhcpd at boot or 0 to disable it.À présent, lorsque le script /etc/init.d/dhcp est redémarré à l'aide du paramètre start, le serveur DHCP se met en route.
ligne 11: run_dhcpd=1 ligne 35 : -exec /usr/sbin/dhcpd eth1
ligne 44 : -exec /usr/sbin/dhcpd eth1
Il est possible de passer au travers de cette étape en entrant tous les ordinateurs présents sur le réseau local dans le fichiers /etc/hosts, mais il est souhaitable de mettre en route un serveur DNS pour que chacun des ordinateurs sur le réseau puisse communiquer entres eux à l'aide de noms concrets. Le serveur DNS à mettre en route doit donc en plus de servir des noms de domaines de l'internet, les noms des ordinateurs du réseau.
Note de Jicé : si vous disposez de seulement 2 ou 3 ordinateurs sur votre réseau local, il est plus facile de simplement entrer les coordonnées de ces ordinateurs dans le fichier /etc/hosts de chaque ordinateur (c:\windows\hosts sous windows).
Le fichier de configuration principal est le fichier /etc/bind/named.conf ; voici de quoi il doit avoir l'air :
// This is the primary configuration file for the BIND DNS server named.Il faut distinguer les fichiers de configuration qui serviront à traiter les résolutions de noms de domaine en adresse IP, et également la résolution d'adresses IP en nom de domaine. Par rapport à la configuration d'origine, il a fallu prendre en compte notre réseau, il y a eu donc rajout de la configuration du nom de domaine local ch19231.rez. Ces configurations étant référés au fichier /etc/bind/db.ch19231.rez et /etc/bind/db.192.168.1, il faudra alors créer ces fichiers.
//
// Please read /usr/share/doc/bind/README.Debian for information on the
// structure of BIND configuration files in Debian for BIND versions 8.2.1
// and later, *BEFORE* you customize this configuration file.
//
options {
directory "/var/cache/bind";// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.//forwarders {
// 0.0.0.0;
//};};
// reduce log verbosity on issues outside our control ;
logging {
; category lame-servers { null; };
; category cname { null; };
;};
// prime the server with knowledge of the root servers zone "." {
type hint;
file "/etc/bind/db.root";
};// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912zone "localhost" {
type master;
file "/etc/bind/db.local";
};zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};// Local Network
zone "ch19231.rez" {
type master;
file "/etc/bind/db.ch19231.rez";
};zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.1";
};zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};// add entries for other zones below here
Il faudra commencer par modifier le fichier /etc/bind/db.127 :
;Et également modifier le fichier /etc/bind/db.local :
; BIND reverse data file for local loopback interface
;
@ IN SOA headquarters.ch19231.rez. root.ch19231.rez. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
NS headquarters.ch19231.rez
1.0.0PTR localhost.
;À partir de ce moment, il est possible de créer les fichiers /etc/bind/db.ch19231.rez et /etc/bind/db.192.168.1. Voici le premier fichier :
; BIND data file for local loopback interface
; $TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
;@ IN NS localhost.
;@ IN A 127.0.0.1
;
NS localhost
localhost A 127.0.0.1
headquarters A 192.168.1.1
; db.ch19231.rezEt voici le fichier /etc/bind/db.192.168.1 :
; Herve J. Lombaert, 01/05/2001
; configuration file for the local network
; This file puts names on various IPs
;
@ IN SOA headquarters.ch19231.rez. root.ch19231.rez. (
1
8H
2H
1W
1D)
NS headquarters
;
; headquarters computer (the gateway)
;
localhost A 127.0.0.1
headquarters A 192.168.1.1
headquarters HINFO "Pentium 166MHz" "Linux 2.2.17"
;
; hosts on the network using dhcp
;
comp-one A 192.168.1.11
comp-two A 192.168.1.12
comp-three A 192.168.1.13
comp-four A 192.168.1.14
comp-five A 192.168.1.15
comp-six A 192.168.1.16
comp-seven A 192.168.1.17
comp-nine A 192.168.1.18
comp-height A 192.168.1.19
comp-ten A 192.168.1.20
;
; end of file
; db.192.168.1Le fichier /etc/bind/db.root contient les serveurs DNS principaux, il ne faudra pas toucher à ce fichier.
; Herve J. Lombaert, 11/28/2000
; configuration file for the local network (reverse name)
;
@ IN SOA headquarters.ch19231.rez. root.ch19231.rez. (
1
8H
2H
1W
1D)
NS headquarters.ch19231.rez
;
; headquarters computer
;
1 PTR headquarters.ch19231.rez.
;
; hosts on the local network (using dhcp)
;
11 PTR comp-one.ch19231.rez.
12 PTR comp-two.ch19231.rez.
13 PTR comp-three.ch19231.rez.
14 PTR comp-four.ch19231.rez.
15 PTR comp-five.ch19231.rez.
16 PTR comp-six.ch19231.rez.
17 PTR comp-seven.ch19231.rez.
18 PTR comp-height.ch19231.rez.
19 PTR comp-nine.ch19231.rez.
20 PTR comp-ten.ch19231.rez.
;
; end of file
Une attention particulière est portée sur le point (.) après les noms de machines dans les lignes SOA, son oubli est grave, et il peut parfois être long avant de trouver d'où peut bien provenir l'erreur.
Il faudra ensuite indiquer quel serveur DNS utiliser. On crée pour cela le fichier /etc/resolv.conf :
search ch19231.rez nameserver 127.0.0.1Il est également possible de modifier 127.0.0.1 pour 192.168.1.1, il s'agit en effet de la même machine.
Il restera ensuite à lancer le serveur DNS :
bash# /etc/init.d/bind restartPour vérifier si le serveur fonctionne comme il faut, on peut utiliser le programme nslookup. En entrant différents noms de domaine, le programme nous retourne l'adresse IP du nom de domaine entré :
bash# nslookup comp-sixN'oubliez pas non plus de tester la conversion d'adresse IP vers des noms de machine, à la place d'entrer comp-five, entrez par exemple 192.168.1.15, vous devriez avoir une réponse adéquate. Pour de plus amples informations sur nslookup, vous pouvez consulter ses pages man (man nslookup), vous y découvrirez par exemple qu'en entrant "set query=ANY", vous aurez tous les détails possibles fournis par le serveur de noms.
Server : localhost
Address : 127.0.0.1
Name : comp-six.ch19231.rez
Address : 192.168.1.16
La configuration du serveur samba est rien de plus simple, le fichier de configuration /etc/samba/smb.conf par défaut contient tous les commentaires nécessaires à la compréhension du serveur. Voici un exemple de fichier /etc/samba/smb.conf :
;
; /etc/smb.conf
;
; Sample configuration file for the Samba suite
; for Debian GNU/Linux
;
; Please see the manual page for smb.conf
; for detailed description of ; every parameter.
;
[global]
; Interface configuration
interfaces = eth1
bind interfaces only = yes
; interfaces = 192.168.1.0/24 127.0.0.1/32; Authorized computers to gain access to samba server
hosts allow = 192.168.1. 127.; time out in minutes
deadtime = 2; printing = bsd
; printcap name = /etc/printcap
; load printers = yes
guest account = nobody
invalid users = root; "security = user" is always a good idea.
; This will require a Unix account
; in this server for every user accessing the server.
; share -> everyone can access samba server
security = share; Change this for the workgroup your Samba server will part of
; workgroup = WORKGROUP
workgroup = KLAN-SPECIALserver string = %h server (Samba %v)
; If you want Samba to log though syslog only then set the following
; parameter to 'yes'. Please note that logging through syslog in
; Samba is still experimental.
syslog only = no; We want Samba to log a minimum amount of information to syslog. Everything
; should go to /var/log/{smb,nmb} instead. If you want to log through
; syslog you should set the following parameter to something higher.
syslog = 0;; This socket options really speed up Samba under Linux, according to my
; own tests.
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=4096 SO_RCVBUF=4096; Passwords are encrypted by default. This way the latest Windows 95 and NT
; clients can connect to the Samba server with no problems.
encrypt passwords = yes; It's always a good idea to use a WINS server. If you want this server
; to be the WINS server for your network change the following parameter
; to "yes". Otherwise leave it as "no" and specify your WINS server
; below (note: only one Samba server can be the WINS server).
; Read BROWSING.txt for more details.
wins support = no; If this server is not the WINS server then specify who is it and uncomment
; next line.
; wins server = 172.16.0.10; Please read BROWSING.txt and set the next four parameters according
; to your network setup. There is no valid default so they are commented
; out.
; os level = 0
; domain master = no
; local master = no
; preferred master = no; What naming service and in what order should we use to resolve host names
; to IP addresses
name resolve order = lmhosts host wins bcast; This will prevent nmbd to search for NetBIOS names through DNS.
dns proxy = no; Name mangling options
preserve case = yes
short preserve case = yes; This boolean parameter controlls whether Samba attempts to sync. the Unix
; password with the SMB password when the encrypted SMB password in the
; /etc/samba/smbpasswd file is changed.
unix password sync = false; For Unix password sync. to work on a Debian GNU/Linux system, the following
; parameters must be set (thanks to Augustin Luton
; <aluton@hybrigenics.fr> for sending the correct chat script for
; the passwd program in Debian Potato).
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n \ *Retype\snew\sUNIX\spassword:* %n\n .; The following parameter is useful only if you have the linpopup package
; installed. The samba maintainer and the linpopup maintainer are
; working to ease installation and configuration of linpopup and samba.
; message command = /bin/sh -c '/usr/bin/linpopup "%f" "%m" %s; rm %s' &; The default maximum log file size is 5 MBytes. That's too big so this
; next parameter sets it to 1 MByte. Currently, Samba rotates log
; files (/var/log/{smb,nmb} in Debian) when these files reach 1000 KBytes.
; A better solution would be to have Samba rotate the log file upon
; reception of a signal, but for now on, we have to live with this.
max log size = 1000;[homes]
; comment = Home Directories
; path = /home
; browseable = yes; By default, the home directories are exported read only. Change next
; parameter to "no" if you want to be able to write to them.
; read only = no; File creation mask is set to 0700 for security reasons. If you want to
; create files with group=rw permissions, set next parameter to 0775.
; create mask = 0700; Directory creation mask is set to 0700 for security reasons. If you want to
; create dirs. with group=rw permissions, set next parameter to 0775.
; directory mask = 0700;[printers]
; comment = All Printers
; browseable = no
; path = /tmp
; printable = yes
; public = no
; writable = no
; create mode = 0700;
-------------------------------
; SHARED PATH
;
-------------------------------; A sample share for sharing your CD-ROM with others.
[cdrom]
comment = Samba server's CD-ROM
writable = no
locking = no
path = /cdrom
public = yes; The next two parameters show how to auto-mount a CD-ROM when the
; cdrom share is accesed. For this to work /etc/fstab must contain
; an entry like this:
;
; /dev/scd0 /cdrom iso9660 defaults,noauto,ro,user 0 0
;
; The CD-ROM gets unmounted automatically after the connexion to the
;
; If you don't want to use auto-mounting/unmounting make sure the CD
; is mounted on /cdrom ;
preexec = /bin/mount /cdrom
postexec = /bin/umount /cdrom; /tmp on debian for temporary transfers
[tmp]
comment = /tmp on debian (erased at each reboot)
writable = yes
path = /tmp
public = yes; configuration files
[etc]
comment = configuration files
writable = no
path = /etc
public = yes; whole system
[all]
comment = whole system
writable = no
path = /
public = yes
Avant toute chose, il faudra s'assurer que la redirection de paquet d'information est possible, il faudra donc que le fichier /proc/sys/net/ipv4/ip_forward contiennent le chiffre 1 et non 0 qui le désactive. Pour que ce fichier soit toujours à 1, il faudra également modifier le fichier /etc/network/options pour que la modification soit prise en compte à chaque démarrage de l'ordinateur. Voici de quoi aura l'air le fichier /etc/network/options :
ip_forward=yesPour rendre possible la redirection, nous avons expliqué qu'il fallait modifier le fichier /proc/sys/net/ipv4/ip_forward :
spoofprotect=yes
syncookies=no
bash# echo "1" > /proc/sys/net/ipv4/ip_forwardLa seule et unique règle ipchains nécessaire à la redirection d'internet consiste à forwarder les paquets d'information provenant du réseau vers l'extérieur. Ceci ce fait à l'aide de la commande :
bash# ipchains -A forward -j MASQ -s 192.168.1.0/24 -d 0.0.0.0/0La règle s'inscrit dans la chaîne forward, elle s'applique aux paquets d'information provenant de votre réseau local, 192.168.1.xxx sur 24 bits, allant n'importe où, 0.0.0.0 sur 0 bit. Son état est MASQ pour masquer le paquet, c'est-à-dire que l'entête du paquet IP traité sera modifié pour contenir à la place de l'adresse IP locale, l'adresse IP de votre gateway.
À ce stade, vous pourrez vérifier que vous êtes bien capable d'accéder à l'extérieur depuis un ordinateur sur votre réseau local. Pinger par exemple un ordinateur quelconque :
bash# ping info.polymtl.caCeci montre bien qu'il est possible d'accéder à l'extérieur.
PING info.polymtl.ca (132.207.12.85):
56 data bytes 64 bytes from 132.207.12.85:
icmp_seq=0 ttl=250 time=4.7 ms 64 bytes from 132.207.12.85:
icmp_seq=1 ttl=250 time=2.7 ms
Pour remédier à ces problèmes, il existe des modules qui apporteront les modifications nécessaires au bon fonctionnement de certains logiciels tels que ICQ, ou des clients FTP. Ces modules se chargent comme nous l'avions expliqué pour le chargement des modules des cartes réseau :
bash# insmod ip_masq_ftpPour le module ICQ, il n'est pas inclus dans la distribution Debian 2.2, de plus, ce module est experimental. Il faudra donc recompiler le noyau pour qu'il puisse accepter des modules expérimentaux. Veuillez pour cela vous referez à des kernel-howtos ou à l'article sur le noyau, ce n'est pas si sorcier que ça peut en avoir l'air.
bash# insmod ip_masq_irc
Pour que toutes ces règles soient prises en compte dès le démarrage, il faudra créer un script de démarrage dans le répertoire /etc/init.d. Créons par exemple le fichier /etc/init.d/ip_masquerade :
#! /bin/shIl faudra également penser à affecter les bons droits à ce script :
# ip_masquerade : setup ip_masquerade
# Herve J. Lombaert, 01/05/2001# Rules
start_rules() {
ipchains -P forward DENY
ipchains -A forward -j MASQ -s 192.168.1.0/24 -d 0.0.0.0/0
return 0
}# Install
modules install_modules() {
insmod ip_masq_ftp
insmod ip_masq_icq
insmod ip_masq_irc
insmod ip_masq_cuseeme
insmod ip_masq_quake
insmod ip_masq_raudio
insmod ip_masq_user
insmod ip_masq_vdolive
return 0
}# Flush
rules flush_rules() {
ipchains -F input
ipchains -F output
ipchains -F forward
return 0
}# Remove
modules remove_modules() {
rmmod ip_masq_ftp
rmmod ip_masq_icq
rmmod ip_masq_irc
rmmod ip_masq_cuseeme
rmmod ip_masq_quake
rmmod ip_masq_raudio
rmmod ip_masq_user
rmmod ip_masq_vdolive
return 0
}case "$1" in
start)
echo -ne "\033[1;32m
Starting ip_masquerade\033[0m\n"
start_rules
install_modules
;;stop)
echo -ne "\033[1;31m
Stoping ip_masquerade\033[0m\n"
flush_rules
remove_modules
;;restart)
echo -ne "\033[1;32m
Restarting ip_masquerade\033[0m\n"
flush_rules
remove_modules
start_rules
install_modules
;;*)
echo "Usage : /etc/init.d/ip_masquerade {start|stop}"
exit 1esac
exit 0
# End of file
bash# chmod uga+x /etc/init.d/ip_masqueradeLe script de lancement étant maintenant créé, il va falloir créer les bons liens symboliques dans les répertoires /etc/rcN.d/ correspondant à chaque runlevel où sera exécuté le script. La distribution Debian déconseille de rajouter ces liens symboliques manuellement, mais suggère plutôt d'utiliser la commande :
bash# update-rc.d ip_masquerade defaultsCela mettra le script crée dans les initialisations des runlevels 0 1 2 3 4 5 et 6.
Note de Jicé : pour d'autres distributions, vous pouvez utiliser des programmes en mode graphique comme ksysv pour faire ce travail.
Voilà ! À ce stade, vous avez un gateway opérationnel, vous pouvez redémarrer votre ordinateur et le laisser allumé aussi longtemps que vous voulez.
Pour pouvoir l'utiliser, il vous faudra connaître les numéros de ports et le protocole utilisé par le serveur que vous voulez rendre accessible à l'extérieur de votre réseau local. L'exemple d'un serveur de page web sera pris. Il fonctionne sur le port 80 et utilise le protocole TCP. Voici donc la ligne de commande que vous aurez à taper :
bash# ipmasqadm portfw -a -P tcp -L 132.204.210.10 80 -R 192.168.1.11 80Ceci aura pour but de retransmettre tout ce qui arrive sur le port 80 de votre gateway, sur la machine 192.168.1.11, également sur le port 80.
Vous pourriez rajouter vos règles dans un fichier placé dans /etc/init.d/, ou également le placer dans le fichier créé, /etc/init.d/ip_masquerade
Ci-dessous les étapes à suivre pour partager sa connexion au moyen de iptables. Pour plus d'infos sur iptables, conulter iptables par l'exemple.
Pour partager sa connexion avec iptables, rien de plus simple. Il suffit de suivre les 2 étapes ci-dessous :
par Anne
Ou lorsque votre pingouin se met à communiquer avec le monde entier
Ce document se veut être un document synthétique qui vous permettra de répondre aux questions suivantes :
Attention : la liste des commandes fournies n'est pas exhaustive et plutôt orientée sur des distributions Redhat / Mandrake. Quelques précisions sont toutefois apportées concernant Debian et Slackware pour les plus grosses différences (merci à Prae et ses connaissances Debian)
Le nom de machine, ou hostname en bon français, est extrêmement important et a des conséquences non seulement sur la configuration réseau mais aussi sur le fonctionnement (ou dysfonctionnement) du serveur X et donc de l'interface graphique.
Pour connaître l'adressage IP de la machine, quelle que soit la nature du réseau, une commande à connaitre : ifconfig
la commande vous retourne quelque chose comme ça :
eth0 Lien encap:Ethernet HWaddr 00:10:5A:DA:D3:47 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2006397 errors:0 dropped:0 overruns:0 frame:0 TX packets:1863082 errors:0 dropped:0 overruns:0 carrier:0 collisions:3679 lg file transmission:100 RX bytes:1283974990 (1224.4 Mb) TX bytes:590947572 (563.5 Mb) Interruption:10 Adresse de base:0xe800 eth1 Lien encap:Ethernet HWaddr 52:54:05:F5:BB:9B inet adr:192.168.0.3 Bcast:192.168.0.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1841782 errors:0 dropped:0 overruns:0 frame:48 TX packets:1984028 errors:0 dropped:0 overruns:0 carrier:0 collisions:6607 lg file transmission:100 RX bytes:579039163 (552.2 Mb) TX bytes:1261892485 (1203.4 Mb) Interruption:9 Adresse de base:0xe400 lo Lien encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:442 errors:0 dropped:0 overruns:0 frame:0 TX packets:442 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:278720 (272.1 Kb) TX bytes:278720 (272.1 Kb) ppp0 Lien encap:Protocole Point-à-Point inet adr:213.41.132.215 P-t-P:62.4.16.248 Masque:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:2001693 errors:2006395 dropped:0 overruns:0 frame:0 TX packets:1858378 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:3 RX bytes:1238624343 (1181.2 Mb) TX bytes:549766984 (524.2 Mb)
Les informations fournies par la commande :
eth0, ppp0, lo... | nom de l'interface réseau |
HWaddr | adresse MAC ou matérielle |
inet adr | adresse IP liée à l'interface réseau |
Bcast | adresse de broadcast |
Masque | masque de réseau |
UP | état de l'interface réseau - un 1er élément de diagnostic d'une panne réseau (non fonctionnement : DOWN) |
MTU | taille maximum des trames physiques |
RX / TX packets | nombre de paquets arrivés à destination, perdus ou non reçus à cause de débordements (arrivent de manière trop rapide pour pouvoir être traités par le noyau) - autre élément de diagnostic notamment lorsque les transmissions deviennent très lentes voire inexistantes. |
collisions | se produit lorsque 2 machines émettent en même temps sur le réseau. Il n'y a pas lieu de s'inquiéter tant que le rapport (nombre de paquets total / nombre de collisions) reste inférieur à 30%. |
Pour de plus amples informations concernant le fonctionnement de l'adressage IP, lire l'article sur TCP/IP.
Dans quels fichiers trouver la configuration IP ?
L'avantage de ce script : il fonctionne soit avec un argument, soit en récupérant la sortie standard.root@pingu# cat ifip #!/bin/bash if [ -z "$1" ] then IF=`cat` else IF=$1 fi ifconfig $IF|grep inet|tr -s " "|cut -f3 -d" "|cut -f2 -d:
root@pingu# ifip eth1 192.168.0.3 root@pingu# echo eth1 | ifip 192.168.0.3
(selon la version de la distribution, l'un ou l'autre est utilisé, xinetd étant le plus récent). inetd (ou xinetd) agit comme un standardiste. Dès qu'un client fait appel à un service autorisé, il passe la ligne au dit service.
<service_name> <endpoint-type> <protocol> <wait-status>
<uid> <server_program> <server-arguments>
avec :
- service_name : nom du service
- endpoint-type : type de socket (stream pour TCP, dgram pour UDP)
- protocol : protocole de transport utilisé
- wait-status : soit l'option est wait et le service est dit mono-thread
(une seule connexion par service peut être gérée), soit l'option est nowait et le
service est dit multi-thread (chaque requête vers le service génère un nouveau serveur)
- uid : utilisateur sous lequel est lancé le service
- server_program : nom du programme à lancer pour activer le service
- server-arguments : arguments éventuels pour le lancement du service
Exemple :
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
En cas de dysfonctionnement d'un service, vérifier la syntaxe de la ligne. De plus, pour désactiver l'accès à un service il suffit simplement de commenter la ligne le concernant. Pour réactiver un service, il suffit donc de supprimer le # démarrant la ligne.
Dans ce cas de figure, le service telnet est désactivé. Pour l'activer, 2 étapes :root@pingu# vi /etc/xinetd.d/telnet service telnet { flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID disable = yes }
root@pingu# ps -ef | grep xinetd root 973 1 0 Oct09 ? 00:00:00 xinetd -stayalive -reuse -pidfil root@pingu# kill -HUP 973 root@pingu#
Standalone : votre service tourne sans être lancé et contrôlé par le super démon inetd (ou xinetd).
exemple :
- mon serveur Apache ne fonctionne pas.
root@pingu# /etc/rc.d/init.d/httpd status
httpd est arrêté
- on démarre le serveur Apache
root@pingu# /etc/rc.d/init.d/httpd start
Démarrage de httpd : [ OK ]
- on vérifie l'état du serveur
root@pingu# /etc/rc.d/init.d/httpd status
httpd (pid 14113 14112 14111 14110 14109 14106) en cours d'exécution
root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc0.d/K05bidule
root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc1.d/K05bidule
root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc2.d/K05bidule
root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc3.d/S95bidule
root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc4.d/S95bidule
root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc5.d/S95bidule
root@pingu# ln -s /etc/rc.d/init.d/bidule /etc/rc.d/rc6.d/K05bidule
Ajout d'un service à la base :
root@pingu# chkconfig --add service
Suppression d'un service de la base :
root@pingu# chkconfig --del service
Configuration des niveaux auxquels le service doit démarrer/s'arrêter :
root@pingu# chkconfig --level <niveaux> service on|off
Permet de visualiser et modifier la table arp stockée en cache. La table arp est une table de correspondance entre adresses IP et adresses matérielles (ou MAC). Elle est générée au fur et à mesure grâce au protocole ARP et stockée en cache.
La commande permet de détecter 2 types de problèmes : le fonctionnement au niveau hardwarede la carte et la bonne correspondance entre une adresse IP et une carte réseau au moyen de son adresse MAC. (cf. double attribution d'une adresse IP sur un réseau, spoofing, ...).
Exemple : Vous voulez vérifier que la seconde carte réseau appelée eth1 est opérationnelle. Dans un 1er temps, on va pinger la carte, ce qui va permettre d'alimenter la table arp.
root@pingu# ping 192.168.0.4
Une fois la table alimentée, on vérifie son contenu : la présence de l'adresse IP ET de l'adresse MAC
root@pingu# arp -a ? (192.168.0.4) at 52:54:05:F5:AD:0C [ether] on eth1 ? (192.168.0.1) at 00:04:76:8E:B2:90 [ether] on eth1
En cas d'erreur dans la table, il est inutile de pousser plus avant le diagnostic... On est face à un problème matériel (certainement le plus pénible à détecter).
Véritable outil à tout faire, à connaitre absolument ! Il permet de détecter bon nombre de problèmes concernant votre configuration IP : adressage de votre carte réseau (adresse IP, adresse de réseau, routage, configuration de la résolution de nom).
Exemple : Mon réseau ne fonctionne pas. Je vais donc tester l'adresse avec la
commande ping
root@pingu# ping 192.168.0.3
PING 192.168.0.5 (192.168.0.5) from 192.168.0.3 : 56(84) bytes of data.
From 192.168.0.3 icmp_seq=1 Destination Host Unreachable
Plusieurs causes de non-fonctionnement : je vérifie
- que l'adresse IP existe
- que le masque de sous-réseau est cohérent (ifconfig)
- que ma résolution de nom est opérationnelle (/etc/resolv.conf)
- que le routage est correctement configuré (commande route vue plus loin)
Si la commande ping fonctionne alors ce n'est ni un problème matériel, ni un problème de configuration IP. Toutefois le réseau peut subir des dysfonctionnements tout simplement parce qu'il est chargé. On augmente alors la taille des paquets envoyés.
Exemple :
root@pingu# ping -s 128 192.168.0.1
PING 192.168.0.1 (192.168.0.1) from 192.168.0.3 : 128(156) bytes of data.
136 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=0.583 ms
136 bytes from 192.168.0.1: icmp_seq=2 ttl=128 time=0.598 ms
136 bytes from 192.168.0.1: icmp_seq=3 ttl=128 time=0.640 ms
136 bytes from 192.168.0.1: icmp_seq=4 ttl=128 time=0.578 ms
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3008ms
rtt min/avg/max/mdev = 0.578/0.599/0.640/0.038 m
Ceci permet d'approfondir le test. On vérifiera :
- les numéros de séquences (icmp_seq) : ils sont séquentiels et numérotent les
paquets envoyés. Une surcharge réseau ou un câblage de mauvaise qualité par exemple
entraine la perte de paquets (voir % loss).
- le temps de transmission (time) : plus il est long, plus le réseau est chargé.
Attention : si vous lancez un ping sur un serveur et que celui-ci ne répond pas, cela ne signifie pas forcément qu'il y ait un problème. En effet, les firewalls peuvent bloquer toute réponse à un ping et faire échouer toute tentative de ping sur eux.
Permet d'afficher la table de routage en cache. Une commande équivalente est netstat -r. La commande affiche la table de routage et effectue la résolution de nom dès que possible. Les commandes route -n ou netstat -rn affichent le table de routage sans résolution de nom.
Exemple :
root@pingu# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
loopback1-lns10 * 255.255.255.255 UH 0 0 0 ppp0
thepingu * 255.255.255.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default loopback1-lns10 0.0.0.0 UG 0 0 0 ppp0
root@pingu# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
62.4.16.253 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 62.4.16.253 0.0.0.0 UG 0 0 0 ppp0
Pour info : U = routeur installé et opérationnel ; G = passerelle distante ; H = destination est un hôte et non un réseau.
Un examen de la table de routage vous permet de vérifier par exemple que la machine sur laquelle vous travaillez et qui se situe derrière une passerelle a bien une route par défaut qui lui permet d'aller vers l'extérieur (Destination : default).
Vous ne pouvez pas atteindre l'extérieur car vous n'avez pas cette route, 2 solutions :
Vous ne pouvez pas atteindre l'extérieur car vous avez une route erronée, 2 solutions :
Vous ne parvenez pas à atteindre une URL ou un poste donné... La commande traceroute, comme son nom l'indique, vous établit la route suivie par les paquets de données vers la destination. La route est constituée de tous les routeurs traversés pour arriver à destination.
Exemple :
root@pingu# traceroute 192.168.0.4 traceroute to 192.168.0.4 (192.168.0.4), 30 hops max, 38 byte packets 1 192.168.0.4 (192.168.0.4) 0.638 ms 1.016 ms 0.667 ms
Il s'agit d'une machine locale. Elle est située sur le même réseau, aucun routeur n'est traversé, l'adresse de destination est donc atteinte directement.
root@pingu# traceroute lea-linux.org
traceroute to lea-linux.org (80.67.179.10), 30 hops max, 38 byte packets
1 loopback1-lns103-tip-telehouse.nerim.net (62.4.16.253) 152.218 ms 51.991 ms 48.179 ms
2 hsrp1-telehouse.nerim.net (62.4.16.9) 77.410 ms 48.695 ms 66.830 ms
3 feth0-0-julo.nerim.net (62.4.16.37) 135.323 ms 55.336 ms 47.656 ms
4 placenet.freeix.net (213.228.3.223) 48.269 ms 144.190 ms 54.287 ms
5 charon.placenet.org (80.67.178.242) 115.933 ms 58.049 ms 55.553 ms
6 web.t2.tuxfamily.net (80.67.179.10) 1079.365 ms 949.915 ms 578.333 ms
On a ici une adresse située à l'extérieur, tous les routeurs traversés sont indiqués et numérotés.
Là où traceroute devient un outil de diagnostic :
Exemple :
root@pingu# traceroute 192.168.0.5 traceroute to 192.168.0.5 (192.168.0.5), 30 hops max, 38 byte packets 1 192.168.0.3 (192.168.0.3) 2999.119 ms !H 2994.720 ms !H 2999.823 ms !H
Cette fois-ci la commande nous donne des informations différentes : il lui est impossible de trouver la route et il affiche directement la destination avec un des codes d'erreur suivant :
!H : host unreachable
!N : network unreachable
!P : protocol unreachable
On a déjà vu la commande netstat dans le cadre de l'affichage de la table de routage. La commande permet également d'obtenir des informations détaillées sur l'état des interfaces réseau :
Exemple :
root@pingu# netstat -i
Table d'interfaces noyau
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 20103 0 0 0 18666 0 0 0 BMRU
eth1 1500 0 18453 0 0 0 19879 0 0 0 BMRU
lo 16436 0 466 0 0 0 466 0 0 0 LRU
ppp0 1492 0 20056 20103 0 0 18619 0 0 0 MOPRU
RX | paquets reçus |
TX | paquets envoyés (transmis) |
OK | paquets reçus/envoyés correctement |
ERR | paquets reçus/envoyés avec des erreurs |
DRP | paquets reçus/envoyés droppés |
OVR | paquets reçus/envoyés retransmis |
D'autres options de la commande permettent notamment de visualiser les ports ouverts : netstat -tu (tcp et udp).
Exemple :
root@pingu# netstat -tu
Connexions Internet actives (sans serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 pingu.linuxeries.:32771 132.248.32.28:46503 ESTABLISHED
tcp 0 0 pingu.linuxeries.:32773 64.12.25.127:5190 ESTABLISHED
tcp 0 0 pingu.linuxeries.:33012 217.174.201.37:ircd ESTABLISHED
tcp 0 0 192.168.0.3:netbios-ssn ouaichland:1177 ESTABLISHED
tcp 1231 0 pingu.linuxeries.:34140 193.201.103.96:http ESTABLISHED
Il s'agit d'un outil à réserver aux utilisateurs avertis (il nécessite quelques connaissances sur les protocoles) qui va vous permettre de visualiser les paquets qui circulent vers et/ou à partir d'une interface réseau et ce, en temps réel. C'est à la fois un outil de diagnostic sécurité mais aussi un outil de détection d'anomalies de la configuration IP ou matérielle.
Le fonctionnement en est relativement simple : la commande, sans aucun filtre, permet d'afficher le contenu des paquets et leur description qui transitent sur les interfaces réseau. On peut ensuite élaborer des filtres en fonction des informations recherchées. En voici quelques uns :
De cette manière, vous pouvez utiliser tcpdump si vous essayez de diagnostiquer un problème comme des erreurs de protocole, ou des déconnexions bizarres, ceci car il vous permet de voir en temps réel ce qui arrive sur le réseau. Pour bien utiliser tcpdump, vous devez avoir quelques connaissances sur les protocoles et comment ils fonctionnent, mais il est aussi utile pour quelques services simples comme vérifier que les paquets quittent bien votre machine par le bon port si vous essayez de diagnostiquer des problèmes de routage et pour voir si vous recevez des paquets en provenance de destinations éloignées.
Exemple :
root@pingu# tcpdump -i eth1 port 23
tcpdump: listening on eth1
00:53:58.230287 192.168.0.4.1497 > pingu.linuxeries.org.telnet: S 1074459360:1074459360(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
00:53:58.230477 pingu.linuxeries.org.telnet > 192.168.0.4.1497: S 607927502:607927502(0) ack 1074459361 win 5840 <mss 1460,nop,nop,sackOK> (DF)
00:53:58.230820 192.168.0.4.1497 > pingu.linuxeries.org.telnet: . ack 1 win 17520 (DF)
00:53:58.741012 pingu.linuxeries.org.telnet > 192.168.0.4.1497: P 1:13(12) ack 1 win 5840 (DF) [tos 0x10]
00:53:58.741608 192.168.0.4.1497 > pingu.linuxeries.org.telnet: P 1:7(6) ack 13 win 17508 (DF)
.....
La commande ici nous permet de visualiser les paquets liés à l'activité telnet sur l'interface réseau eth1.
Il s'agit d'un scanner de ports, à utiliser par simple curiosité ou pour s'assurer du niveau de sécurité effectif sur sa machine. Les options de cette commandes sont très nombreuses et je ne les détaillerai pas ici.
La syntaxe : nmap <options> adresse_IP
Exemple :
# nmap -sS -O 192.168.0.3 Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ ) Interesting ports on (192.168.0.3): (The 1544 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 53/tcp open domain 80/tcp open http 3306/tcp open mysql Remote operating system guess: Linux Kernel 2.4.0 - 2.4.17 (X86) Uptime 2.279 days (since Fri Oct 4 16:24:45 2002) Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds:!
Le scan réalisé ici permet de vérifier quels sont les ports ouverts et donc potentiellement vulnérables (grâce aux options -sS) et le système d'exploitation de la machine testée (grâce à l'option -O).
nmapfe est quant à lui une interface graphique (front end) à nmap.
La commande lsof (list opened files) permet de lister les fichiers ouverts par les processus tournant sur le système. On peut aussi l'utiliser pour ce qui nous concerne et ce de différentes manières. Là encore le traitement ne sera pas exhaustif.
Voir les fichiers utilisés par un processus réseau :
root@pingu# lsof|grep proftpd
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
proftpd 2136 root cwd DIR 22,2 4096 2 /
proftpd 2136 root rtd DIR 22,2 4096 2 /
proftpd 2136 root txt REG 22,2 236456 244504 /usr/local/sbin/proftpd
proftpd 2136 root mem REG 22,2 89547 1661383 /lib/ld-2.2.5.so
proftpd 2136 root mem REG 22,2 23575 1661394 /lib/libcrypt-2.2.5.so
proftpd 2136 root mem REG 22,2 35340 1661460 /lib/libpam.so.0.75
proftpd 2136 root mem REG 22,2 12102 1661396 /lib/libdl-2.2.5.so
proftpd 2136 root mem REG 22,2 45415 1661416 /lib/libnss_files-2.2.5.so
proftpd 2136 root mem REG 22,2 46117 1661424 /lib/libnss_nisplus-2.2.5.so
proftpd 2136 root mem REG 22,2 89424 1661400 /lib/libnsl-2.2.5.so
proftpd 2136 root mem REG 22,2 16051 1661413 /lib/libnss_dns-2.2.5.so
proftpd 2136 root mem REG 22,2 68925 1661428 /lib/libresolv-2.2.5.so
proftpd 2136 root mem REG 22,21401027 651528 /lib/i686/libc-2.2.5.so
proftpd 2136 root 0u IPv4 19073 TCP *:ftp (LISTEN)
proftpd 2136 root 1u IPv4 19074 TCP *:46000 (LISTEN)
proftpd 2136 root 2u IPv4 19075 TCP *:47000 (LISTEN)
proftpd 2136 root 3u unix 0xc4a6c0a0 16891 socket
proftpd 2136 root 4r REG 22,2 1585 213675 /etc/passwd
proftpd 2136 root 5r REG 22,2 657 212895 /etc/group
COMMAND | nom du processus |
PID | numéro de processus (obtenu aussi par la commande ps |
USER | identité sous laquelle est lancé le processus |
FD | file descriptor - mem : memory-mapped file ; txt : program text (code and data)... plus de détails dans le man de lsof |
TYPE | type de noeud (ou inode) - CHR : fichier spécial en mode caractère ; DIR : répertoire... plus de détails dans le man de lsof |
DEVICE | major et minor number pour un fichier spécial, protocole... |
SIZE | taille du fichier |
NODE | numéro d'inode |
NAME | nom du fichier ou point de montage |
Voir si un fichier est utilisé par un processus réseau
Permet éventuellement de surveiller l'utilisation de fichiers dits sensibles pour la sécurité
du système.
Exemple : je veux vérifier les éventuels accès au fichier /etc/passwd
root@pingu# lsof | grep /etc/passwd
proftpd 12586 root 4r REG 22,2 1585 213675 /etc/passwd
Lister les processus liés à un protocole et un port
On obtient alors une fonctionnalité similaire à la commande netstat -a filtrée en
fonction d'un protocole et/ou d'un port.
Exemple : je souhaite lister les informations liées au protocole TCP et au port 80
(donc mon serveur web).
# lsof -i tcp:80 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME httpd 1136 root 16u IPv4 1963 TCP *:http (LISTEN) httpd 1139 root 16u IPv4 1963 TCP *:http (LISTEN) httpd 1140 root 16u IPv4 1963 TCP *:http (LISTEN) httpd 1141 root 16u IPv4 1963 TCP *:http (LISTEN) ....
Note
Sur la remarque tout à fait justifiée de Jicé (mais non je ne fayotte pas :), on
peut en parallèle à la commande lsof, citer fuser. Elle est vous donnera
moins d'informations mais peut vous permettre d'obtenir le même genre de renseignements.
Une restriction toute fois spécifée dans le man de fuser :
" fuser ne dispose de toutes les informations que s'il est exécuté avec les
privilèges de root. Ainsi, des fichiers ouverts par des processus appartenant à
d'autres utilisateurs n'apparaîtront peut-être pas"
Exemple : je veux savoir quels sont les fichiers utilisés par mon serveur apache :
root@pingu# fuser -auv -n tcp 80
USER PID ACCESS COMMAND
80/tcp root 1136 f.... httpd
root 1139 f.... httpd
root 1140 f.... httpd
root 1141 f.... httpd
root 1142 f.... httpd
root 1144 f.... httpd
root 1145 f.... httpd
root 1146 f.... httpd
root 1147 f.... httpd
root 6434 f.... httpd
Le problème ici est que httpd fonctionne avec l'identité apache et non root. D'où le manque d'informations sur les fichiers utilisés.
Ce fichier permet la configuration d'un client DNS. C'est lui qui permet l'utilisation de serveurs DNS pour la résolution de noms en adresse IP (ce qui vous permet par exemple de taper une URL dans un navigateur et non une adresse IP). Un fichier mal configuré vous empêchera notamment de surfer.
Rappel de la syntaxe :
root@pingu# cat /etc/resolv.conf
domain nom_de_domaine
nameserver adresseIP_DNS_Primaire
nameserver adresseIP_DNS_Secondaire
Attention : nameserver est un mot-clé à recopier tel que.domain contient le nom de domaine du provider qui vous a fourni les DNS ou celui de votre domaine, si vous disposez d'un serveur DNS.
On connait telnet en tant qu'outil prise de contrôle à distance. Ce n'est pas là sa seule utilité, il est aussi très utile pour établir un diagnostic et vérifier le fonctionnement ou non d'un service en se connectant sur son port. Il permet également de vérifier la validité d'une règle de firewall.
La syntaxe : telnet <adresse IP ou nom de machine> <numéro de port du service à tester>
Exemple :
Je souhaite vérifier le bon fonctionnement de mon service ftp. Après vérification dans
/etc/services, je sais que le port correspondant au serveur ftp est le 21.
root@pingu# telnet 192.168.0.3 21 Trying 192.168.0.3... Connected to 192.168.0.3. Escape character is '^]'. 220 ProFTP Linuxerie's Server ReadyLa connexion est réussie, le serveur est opérationnel.
root@pingu# telnet 192.168.0.3 21 Trying 192.168.0.3... telnet: connect to address 192.168.0.3: Connection refused
Vous avez récupéré des informations sous forme d'IP ou de nom dans vos logs ou sur une sortie écran de tcpdump, vous voulez savoir qui se cache derrière cette IP.
Exemple:
root@pingu# whois lea-linux.org
Whois Server Version 1.3
Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information.
Domain Name: LEA-LINUX.ORG
Registrar: GANDI
Whois Server: whois.gandi.net
Referral URL: http://www.gandi.net
Name Server: NS1.TUXFAMILY.NET
Name Server: NS2.TUXFAMILY.NET
Updated Date: 11-feb-2002
Last update of whois database: Tue, 8 Oct 2002 05:00:23 EDT
The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and Registrars.
.....
root@pingu# nslookup > lea-linux.org Server: 194.149.160.9 Address: 194.149.160.9#53 Non-authoritative answer: Name: lea-linux.org Address: 80.67.179.10
# dig www.lea-linux.org
; DiG 9.2.0 www.lea-linux.org
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 25724
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;www.lea-linux.org. IN A
;; ANSWER SECTION:
www.lea-linux.org. 86400 IN A 80.67.179.10
;; AUTHORITY SECTION:
lea-linux.org. 604800 IN NS ns1.tuxfamily.net.
lea-linux.org. 604800 IN NS ns2.tuxfamily.net.
;; ADDITIONAL SECTION:
ns1.tuxfamily.net. 86400 IN A 80.67.177.2
ns2.tuxfamily.net. 86400 IN A 80.67.179.2
;; Query time: 325 msec
;; SERVER: 194.149.160.9#53(194.149.160.9)
;; WHEN: Fri Oct 11 00:12:30 2002
;; MSG SIZE rcvd: 132
# host www.lea-linux.org www.lea-linux.org has address 80.67.179.10
Mon objectif en écrivant cette contribution était de débroussailler quelque peu la jungle
des outils de configuration et diagnostic réseau. J'espère qu'il vous donnera envie
d'approfondir encore plus ce domaine passionnant.
N'hésitez pas à m'envoyer vos remarques ou ajouts éventuels.
Un grand merci à Fred, Prae et Jice qui ont accepté de prendre du temps pour relire et corriger cet article (Jice : je promets de faire des efforts en html :p)
par Serge et JCC
tout savoir sur la connection de Linux avec l'Internet.
ATTENTION : Si vous avez un modem interne, lisez ceci : si votre modem est un "WinModem" (voir glossaire) (son nom sur la boîte de l'emballage), ou un modèle PCI (toutes marques sauf Olitec qui devrait dans un futur que l'on espère proche faire quelque chose pour Linux, ainsi que quelques modems internes basés sur certains chipsets (voir http://www.linmodems.org/)), votre modem ne pourra pas être installé sous Linux. C'est pas la faute à Linux, mais celle du constructeur qui ne fournit pas de drivers pour Linux, et/ou qui ne donne pas les spécifications du modem. Bref achetez-en un autre ou faites un forcing auprès du constructeur (mailez-leur tous les jours, vous et vos amis aussi).
Pour le reste des modems, la plupart des "VRAIS" modems internes (carte ISA émulant un vrai port série en hardware) et tous les modems externes peuvent être installés sous Linux.
Tout d'abord on va vérifier que votre modem est bien reconnu. Si c'est un modem externe vous devez savoir sur quel port série il est connecté (les ports COM sous windows), souvent indiqué sur votre machine (style sérial 1 ou COM1 ou série 1, etc...). Pour le tester, allez dans une console (ou un terminal si vous êtes sous X) et tapez au prompt:
$ echo "ATZ" > /dev/ttySx $ echo "ATDT3611" > /dev/ttySxen remplaçant /dev/ttySx ci-dessus (et dans toutes les commandes suivantes) par :
$ echo "+++" > /dev/ttySxBon maintenant que votre modem est reconnu, on va créer un lien pour le modem, par la commande (là aussi bien mettre le bon ttySx) :
$ ln -s /dev/ttySx /dev/modemSi la réponse est que /dev/modem existe déjà, suprimez-le (rm -f /dev/modem) et recommencez.
Maintenant appliquons les droits qu'il faut :
$ chmod 777 /dev/modemA ce stade on peut dire que votre modem est configuré sous Linux.
Remarque : Si vous avez une erreur de port série, reconfigurez vos ports séries par la commande :
setserial /dev/ttySw uart 16450 port 0xyyy irq zpour le port ou se trouve le modem, avec w, yyy et z suivant le tableau :
Port série N° : | 1
(/dev/ttyS0 ou COM1) |
2
(/dev/ttyS1 ou COM2) |
3
(/dev/ttyS2 ou COM3) |
4
(/dev/ttyS3 ou COM4) |
w : | 0 | 1 | 2 | 3 |
yyy : | 3F8 | 2F8 | 3E8 | 2E8 |
z : | 4 | 3 | 4 | 3 |
Placez cette commande dans un script de démarrage (/etc/rc.d/rc.local
par exemple).
Pour la Slackware, il vous suffit de décommenter ces lignes
dans le fichier /etc/serial.conf (je sais pas si ce fichier existe
aussi dans les RH et Mandrake).
Bon maintenant plusieurs solutions s'offrent à vous :
ATTENTION : moi-même et d'autres utilisateurs avons eu des problèmes avec kppp et la Mandrake 7.0 : la connexion s'arrête toute seule sans raison apparente. Allez voir sur le site de Mandrake et dans les liste d'aide de leur site, ou alors utilisez linuxconf pour configurer votre interface ppp0.
Il vous demande (dans l'ordre) : le numéro de téléphone de votre fournisseur d'accès, le port série où est branché le modem, la vitesse du port (prenez 115 KBPS maximum, 57,6 par sécurité) , NO pour le callback, validez l'init sans rien taper, le nom de domaine de votre fournisseur d'accès (du style free.fr ou wanadoo.fr, etc...) , l'adresse IP du serveur DNS de votre fournisseur d'accès, PAP pour l'authentification, votre user et votre mot de passe, et enfin exit.
Puis pour vous connecter, tapez dans un terminal : "ppp-go", et pour vous déconnecter : "ppp-off".
Si rien ne marche, regardez les log de syslog (/var/log/messages) pour voir déjà si pppd se lance, et si oui quel est le message d'erreur (authentication failed: mauvais mot de passe ou mauvais username). Si la connexion se coupe sans de raison vraiment apparente, esayez une vitesse de port série inférieure.
Dans ce cas, allez sous la console ou sous un terminal et essayez un ping sur un serveur connu :
$ ping www.netscape.com
si ça ne répond pas, essayez alors :
$ ping 205.188.247.66
si ça répond : alors vous avez mal configuré les
serveurs DNS de votre fournisseur d'accès, ouvrez le fichier /etc/resolv.conf
dans votre éditeur de texte favori et ajoutez autant de lignes que
de serveurs DNS de la forme :
nameserver 123.456.789.012 |
Attention de bien avoir au début de ce fichier la ligne :
search nom.domaine |
Si le ping sur 205.188.147.66 ne passe pas, tapez dans une console la ligne :
$ ifconfigvous allez voir une ligne du style :
tapez alors:
$ route add default gw yyy.yyy.yyy.yyy ppp0Retentez le ping et ça devrait passer.
Si lors du ifconfig vous n'avez AUCUNE ligne pppX , la connexion est mal configurée, revoyez le tout.
par Martial
Ce document explique comment compiler la dernière version de pengaol sans support de QTKylix, et la configuration de base de pengaol.
Cet article n'a rien d'officiel, et ne décrit pas nécessairement la «bonne méthode» pour installer pengaol. Rapellez vous que des versions précompilées existent déjà dans de nombreux formats (deb, tgz, rpm), et que pour profiter de l'interface graphique, il vaut mieux lire la très bonne documentation officielle sur le site pengaol.org. Le but ici est de compiler pengaol sans avoir besoin de QTkylix pour configurer les options de compilations, et utiliser pengaol uniquement en ligne de commande.
Suite à certains mails, je precise que je n'ai rien à voir dans le développement de pengaol; contactez plutot son auteur: birdy57 chez pengaol point org, et visitez leurs forums qui sont prévus à cet effet.
Comme d'habitude, il vous faut un système prêt à compiler, c'est à dire g++, ainsi que les fichiers d'entête (paquets -devel en rpm) et les utilitaires classiques comme autoconf, make etc... passons, c'est hors-sujet.
J'ai utilisé exactement cette version: peng1.0a01.tar.gz prise sur le site officiel.
On désarchive:
tar zxvf peng1.0a01.tar.gz &&
cd peng
Puis on va génerer un configure
plus classique,
qui ne cherche pas à lancer une GUI en QTKylix:
mv configure configure- &&
mv configure.ori configure
On peut alors configurer:
./configure \
--prefix=/usr \
--mandir=/usr/share/man \
--infodir=/usr/share/info &&
echo "#define WITH_PPP" >> config.h &&
echo "#define WITH_MODEM" >> config.h &&
echo "#define WITH_TUNTAP" >> config.h &&
echo "#define WITH_CABLE" >> config.h
On crée d'avance les répertoires requis:
mkdir -p /etc/Pengaol
chmod 770 /etc/Pengaol
mkdir -p /usr/share/sound
Et on installe simplement (hum):
make INSTALL="/bin/install -c" install &&
cp peng/PengMessages.txt /etc/Pengaol &&
cp peng/Dns /etc/Pengaol &&
chown root.peng /etc/Pengaol/PengMessages.txt /etc/Pengaol/Dns &&
chmod 660 /etc/Pengaol/PengMessages.txt /etc/Pengaol/Dns &&
mv /usr/bin/peng /usr/bin/pengaol &&
chmod 755 /usr/bin/pengaol &&
chmod +s /usr/bin/pengaol &&
cp wavplay-1.4/wavplay /usr/bin &&
cp wavplay-1.4/*.wav /usr/share/sound
Au besoin remplacez /bin/install -c par /usr/bin/install -c. On met les les permissions sur /etc/Pengaol comme ceci, pour que, lancé par un utilisateur normal, peng puisse y écrire lors de l'activation du dns.
Pour que cela marche, créez un nouveau groupe peng avec vigrp ou une autre commande, pour avoir quelquechose dans ce goût là :
peng:x:19:martial
En modifiant 19 par un mumero de groupe libre sur votre système, et martial (c'est moi, lol) par une liste d'utilisateurs normaux autorisés à se servir de pengaol, séparés par des virgules.
Ce sont les deux drivers possibles - ppp est sans doute un
peu plus rapide. En tous cas, il vous faut soit le module tun.o
,
soit les modules ppp_generic.o et ppp_synctty.o. Le module
ppp_synctty.o n'étant pas le plus courant,
il se peut que votre distro soit configurée pour charger ppp_asynctty.o
à la place, il faut alors modifier /etc/modules.conf.
Pour ne pas avoir d'erreur de détection des drivers, il faut que les devices soient accesibles par peng, donc pensez à ajuster si besoin les permissions de ppp et du modem dans /dev (modules.conf peut automatiser cela avec post-install)
Pour vérifier que tout est bien configuré, tapez pengaol -ListDriver, ce qui doit donner quelque chose comme ceci (au moins):
Load language : fr
Nom du driver : CPppDriver
Auteur : Birdy57
Message inclus : Vers 0.55 Linux
Guid : 3812
Le pilote fonctionne sur cette configuration :Oui
Nom du driver : CTunTapDriver
Auteur : birdy57
Message inclus : Vers 0.5 Linux
Guid : 4212
Le pilote fonctionne sur cette configuration :Non
Nom du driver : CCableDriver
Auteur : birdy57 & surfufu
Message inclus : Vers 0.5 Multi
Guid : 8301
Le pilote fonctionne sur cette configuration :Non
Nom du driver : CModemDriver
Auteur : Birdy57
Message inclus : Vers 0.5 Linux
Guid : 1711
Le pilote fonctionne sur cette configuration :Oui
Il faut que CModemDriver et au moins un des CTunTapDriver CPppDriver soit à oui pour que ca marche. Si ce n'est pas le cas, vérifiez (modprobe) les modules chargés, vérifiez que les devices requis existent dans /dev, et avec les bonnes permissions.
Ensuite, tapez simplement pengaol -User [login] [Pass]. Mais il est conseillé de stocker votre mot de passe une fois pour toute avec: pengaol -AddUser [login] [Pass], et de se connecter ensuite avec: pengaol -Connect [login], ceci évite de dévoiler votre mot de passe dans les logs système et avec la commande top. Une petite ligne genre xterm -T AOL -e pengaol -Connect monlogin dans un menu de gnome, kde, wmaker et on y est.
Load language : fr serveur en attente ! signifie que vous n'avez pas rentré une option valide pour la version en ligne de commande, et cherche donc à lancer la GUI qui dans notre cas n'existe pas. Lire la doc incluse dans le répertoire doc des sources pour toutes les options.
Sous linux il y'a plein de manière d'arriver au même résultat, surtout concernant le chargement des modules du noyau et des permissions, donc ne prenez ce qui est dit ici que comme un exemple; essayez, modifiez selon ce que vous souhaitez obtenir.
Par Fred
Avant de pouvoir nous connecter à internet via
tous nos providers, voyons déjà comment établir une
connexion à Internet.
Établir une liaison à internet c'est relier votre ordinateur au réseau des réseaux via votre modem. C'est-à-dire connecter le modem de votre PC à celui de votre ISP par une liaison téléphonique en utilisant un protocole de communication particulier. Le protocole retenu dans ce document se nomme "Point to Point Protocol" ou ppp ; c'est le plus souvent employé... l'exception étant AOL ! Le programme chargé d'établir cette connexion se nomme pppd (pour ppp daemon, ppp pour Point to Point Protocol). Mais avant d'établir la liaison avec internet, vous devez contacter votre fournisseur d'accès (j'utiliserai désormais l'abréviation ISP : Internet Service Provider), le programme chargé de communiquer avec votre modem est chat.
Voyons comment configurer chat, le programme qui discute ("to chat" en anglais) avec le modem :
Les scripts chat se composent d'une série de paire de chaînes de caractère. La première chaîne de chaque paire est ce que l'on attend du modem, la seconde ce que l'on doit alors envoyer au modem. Pour configurer très finement votre modem, vous devez posséder la documentation technique de celui-ci mais en général ce n'est pas nécessaire.
Un premier script élémentaire pourrait être :
Explications :
Appelons ce script /etc/ppp/chat/connexion0. Comme vous pouvez
vous en douter, connexion0 peut être changé en n'importe
quoi.
Pour tester ce script, nous devons d'abord configurer pppd.
Pour pouvoir initialiser cette connexion, pppd a besoin de 3 (de mon point de vue) fichiers de configuration (au moins) :
lock | # la connexion est exclusive |
ttyS0 115200 crtscts | # la connexion est sur /dev/ttyS0 (i.e. com1) en 115200 bauds avec contrôle de flux matériel (c'est le modem qui le fait !) |
noauth | # l' isp ne doit pas s'authentifier pour nous donner une adresse |
defaultroute | # ppp fourni la route par défaut |
usepeerdns | # pour que pppd demande les DNS au provider, cela ne marche peut-être pas toujours mais chez moi : si ! |
idle 300 | # pour demander à pppd de raccrocher votre téléphone au bout de 300 secondes d'inactivité. (Si vous ne voulez pas utiliser cette option, ne la mettez pas du tout.) |
Ensuite, pour activer la connexion il suffit de faire :
/usr/sbin/pppd call connexion0Pour voir comment tout cela ce passe faite : tail -f /var/log/messages. Vous devez suivre au fur et à mesure l'établissement de la connexion ainsi que l'affection de votre nouvelle adresse IP.
Pour cela nous allons configurer la "résolution des noms" :
Testons cela : rétablissez votre liaison : /usr/sbin/ppp
call connexion0 puis lancez nslookup (ce que vous devez tapez
est en gras, les réponses ne sont pas nécessairement les
mêmes) :
[root@becane home]# nslookup
Default Server: ns3.wanadoo.fr
Address: 193.252.19.3> www.free.fr
Server: ns3.wanadoo.fr
Address: 193.252.19.3Non-authoritative answer:
Name: www.free.fr
Address: 212.27.32.114> exit
/usr/sbin/pppd call connexion0(évidemment connexion0 doit être remplacé par le nom du fichier de configuration dans /etc/ppp/peers). Pour que n'importe quel utilisateur ait le droit d'activer la connexion, je vous conseille de rendre pppd suid (c'est à dire que n'importe quel urilisateur peut le lancer, mais que ce programme possède les droits de root) par :
chmod +s /usr/sbin/pppdCouper la connexion n'est pas aussi simple : il n'existe pas de programme s'en chargeant ! Nous devons tuer le processus de pppd. Mais heureusement c'est simple car il sauve son 'pid' dans /var/run/ppp*.pid. Donc, pour fermer la connexion, la commande est :
kill `cat /var/run/ppp*.pid`Si cette commande vous retourne un message d'erreur, c'est sans doute parce que pppd n'est pas actif à ce moment !
Dans l'article suivant, nous allons voir comment configurer la messagerie.
par Fred
Avant de pouvoir nous connecter à internet via tous nos providers, voyons déjà comment configurer la messagerie.
Pour que notre machine puisse récupérer des mails sur des comptes pop (ceux de votre provider par exemple) il faut configurer fetchmail.
$ cd install-sendmail-xxxxxLa première chose que l'on vous demande c'est la langue que vous souhaitez utiliser (parmi 8), choisissez le danois si c'est votre langue maternelle ;).
$ ./install-sendmail -c
divert(-1)
dnl il faut que le générateur de macro sache où trouver les fichiers de configuration :
include(`/usr/lib/sendmail-cf/m4/cf.m4')
dnl comme identifiant (8:12) vous pouvez sans doute mettre ce que vous voulez :
define(`confDEF_USER_ID',``8:12'')
dnl mon pc s'appelle gros.tux, mettez le nom de votre machine
VERSIONID(`gros.tux nodns')
Cwgros.tux localhost
dnl vous utilisez linux oui ou non ?
OSTYPE(`linux')
dnl on n'utilise pas UUCP (c'est antédiluvien)
undefine(`UUCP_RELAY')
dnl quelqu'un connaît bitnet ?
undefine(`BITNET_RELAY')
dnl autant ajouter automatiquement le nom de domaine qui va bien (celui d'un de nos providers)
FEATURE(always_add_domain)
dnl on utilise un fichier d'alias
FEATURE(use_cw_file)
dnl ????
FEATURE(nocanonify)
dnl ????
define(`confAUTO_REBUILD')
dnl ????
define(`confTO_QUEUEWARN', `')
dnl on ne relaie que les hôtes ????
FEATURE(relay_hosts_only)
dnl on utilise un fichier d'alias
define(`confCW_FILE', `-o /etc/mail/sendmail.cw')
dnl ????
define(`confCON_EXPENSIVE', `True')
dnl ????
define(SMTP_MAILER_FLAGS, e)
dnl les accès smtp sont restreint par ce fichier
FEATURE(access_db, `hash -o /etc/mail/access.db')
dnl les domaines génériques sont dans :
GENERICS_DOMAIN_FILE(`/etc/mail/genericsdomain')
dnl on va changer les adresses venant de chez nous par celle de notre provider
FEATURE(redirect)
dnl si y'a pas de nom de domaine c'est :
MASQUERADE_AS(`free.fr')
dnl tous les mails en provenance de gros.tux sont changés
MASQUERADE_DOMAIN(`gros.tux')
dnl tous les mails on a dit !
FEATURE(masquerade_entire_domain)
dnl donc il faut changer l'enveloppe :
FEATURE(masquerade_envelope)
dnl on va utiliser procmail pour trier les mails des utilisateurs :
FEATURE(`local_procmail',`/usr/bin/procmail')
dnl on mail en local
MAILER(local)
dnl en smtp (??)
MAILER(smtp)
dnl et via procmail
MAILER(procmail)
dnl notre serveur de mail relais est : smtp.free.fr
define(RELAY_HOST, smtp:smtp.free.fr)
define(SMART_HOST, smtp:smtp.free.fr)
dnl il utilise TCP/IP ;)
define(RELAY_MAILER, TCP)
dnl cela n'est utile que pour les portables qui ont des adresses parfois insolubles
FEATURE(`accept_unresolvable_domains')
$ m4 sendmail.mc > /etc/sendmail.cf(enfantin), évidemment install-sendmail fait tous les choix convenables pour nous, mais au cas ou certains choix serait inappropriés, vous savez quoi faire : éditez sendmail.mc (après avoir lu la doc de sendmail) et régénérez sendmail.cf.
Il n'est absolument pas envisageable de créer de toute pièce un fichier /etc/sendmail.cf complet, par compte, on peut envisager de modifier légèrement celui-ci.
FEATURE(`relay_based_on_MX')dnlet d'enlever les règles :
define(RELAY_HOST,...)puis en régénérant sendmail.cf par
define(SMART_HOST,...)
m4 /usr/share/sendmail-cf/m4/cf.m4 sendmail.mc > sendmail.cfde cette façon, sendmail se basera sur le champ MX de votre DNS (ie: celui de votre FAI:fournisseur d'accès internet) pour le relai des mails : c'est très utile dans le cas ou vous avez plusieurs fournisseurs d'accès ça évite d'utiliser un script perl pour rechercher/modifier la ligne fautive dans sendmail.mc.
Pour pouvoir utiliser un tel fichier de configuration, il faut impérativement avoir le droit d'écrire dans le compte mail (/var/spool/mail) de tous les utilisateurs indiquer (ici bibi et fred) : le mieux est d'être root, et donc que le fichier ci-dessus soit en fait : /root/.fetchmailrc !
Il est bien entendu possible à chaque utilisateur de se créer un fichier /home/user/.fetchmailrc (même syntaxe) pour récupérer son courrier sur des comptes non connus du root. Mais il devra récupérer lui-même son mail. On pourrait imaginer, à chaque connexion de créer le fichier /root/.fetchmailrc (pour le compte de root) avec les fichiers .fetchmailrc des différents utilisateurs du système, mais cela permettrait à n'importe qui de mettre des mails sur le compte de n'importe qui d'autre... Une autre solution serait d'utiliser "su user -c fetchmail" pour chaque utilisateur, à chaque connexion (sans doute une bonne solution si l'on a beaucoup d'utilisateurs). La solution proposée ici, est pratique si seulement quelques personnes on accès à un serveur (genre : moins de 10).
Pour ceux que install-sendmail rebute, qui veulent configurer fetchmail séparément, ou qui veulent ajouter des comptes pop, il existe un programme de configuration graphique relativement compréhensible : fetchmailconf (pensez à installer le paquetage correspondant).
/usr/sbin/sendmail -qAvant d'utiliser cette commande, vous pouvez vérifier qu'effectivement vous avez des mails en attente par :
mailq
fetchmail -v(l'option -v n'est pas obligatoire, mais elle permet de voir que tout va bien). Et c'est tout.
par Fred
Jusqu'à maintenant nous avons vu comment nous connecter à Internet et comment recevoir nos mail, mais la connexion reste une procédure complexe pour l'utilisateur moyen.
/usr/sbin/pppd call connexion0Nous savons nous déconnecter d'Internet par la commande :
kill `cat /var/run/ppp*.pid`qui doit être lancée par l'utilisateur qui a établi la connexion.
Nous savons récupérer nos mails par la commande :
fetchmail -vqui, elle, doit être lancée depuis le compte de root.
Nous savons comment envoyer nos mails en attente :
/usr/sbin/sendmail -qComment faire pour automatiser 'tout' cela ?
Souvant, votre distribution fournit déjà un tel script qui se charge d'executer /etc/ppp/ip-up.local. Si c'est le cas (lisez le contenu du script) vous pouvez pour faire ce qui va suivre :
Voilà ce que l'on peut mettre dans /etc/ppp/ip-up :
#!/bin/sh# le paramètre $6 correspond au paramètre
# ipparam du fichier /etc/ppp/peers/script# ---Configuration du DNS---Début---
# ceci nécessite que l'option usepeerdns
# soit activée dans /etc/ppp/peers/script
# dans ce cas DNS1 et DNS2 reçoivent les
# adresse des deux dns du provider.
# sinon mettez ici vos deux dns :
#DNS1=123.123.123.123
#DNS2=213.213.213.213
echo "# fichier généré par ip-up." > /etc/resolv.conf
echo search org >> /etc/resolv.conf
echo nameserver $DNS1 >> /etc/resolv.conf
echo nameserver $DNS2 >> /etc/resolv.conf
# ---Configuration du DNS---Fin---# récupération des mails :
/usr/bin/fetchmail
# et envoie des mails en attente :
/usr/sbin/sendmail -q# on récupère automatiquement les mails toutes les 11 minutes
# (11 minutes car netcourrier n'aime pas qu'on consulte
# les comptes pop trop souvent !)
/usr/bin/fetchmail --daemon 660# le plus de la semaine :
# mettre son pc à l'heure :
ntpdate ntp-sop.inria.fr# on est connecté, on le dit :
export DISPLAY=:0
/opt/apps/bin/Xdialog --title "Information" --center\
--infobox "La connexion est maintenant active." 0 0 3000
Il faut savoir, avant de mettre n'importe quoi dans ce fichier, que celui-ci est toujours exécuté avec les droits de root, donc prudence. De plus ce script est exécuté avec un PATH minimal (PATH=""), donc vous devez préciser le chemin complet des exécutables.
#!/bin/sh# comme on n'est plus connecté au net, on quitte fetchmail
/usr/bin/fetchmail --quit# ---Configuration du DNS---Début---
echo "# fichier généré par ip-down." > /etc/resolv.conf
# mon domaine local est tux !
echo search tux >> /etc/resolv.conf
# ---Configuration du DNS---Fin---# on est déconnecté, on le dit :
export DISPLAY=:0
/opt/apps/bin/Xdialog --title "Information" --center\
--infobox "La connexion est maintenant inactive." 0 0 3000
par Fred
Nous allons, dans ce chapitre, voir comment il est possible de rendre "simple" pour l'utilisateur la gestion de plusieurs connexions (plusieurs ISP) à internet
Avec la prolifération actuelle des ISP, notamment les gratuits, nous sommes souvent tentés de nous connecter via un nouvel ISP, ne serait-ce que pour l'essayer (vérifier l'état de sa ligne, sa rapidité, etc.).
En utilisant ce que nous avons vu, il n'est pas très difficile de créer plusieurs scripts de connexion à Internet. Mais cette méthode oblige l'administrateur à modifier ou créer plusieurs scripts (en tout au moins 4 par fournisseur d'accès) pour pouvoir ajouter un nouvel ISP. Ce n'est pas très souple. De plus il nous faut modifier pour chaque ISP le fichier /etc/sendmail.cf ; en effet dans celui-ci nous avons mis l'adresse de notre serveur de mail sortant, mais le serveur de mail sortant n'accepte pas en général de connexion depuis un PC qui n'est pas relier localement au réseau "local" de l'ISP. Il est assez évident que la modification de ce fichier devra se faire depuis /etc/ppp/ip-up, car elle doit se faire à chaque connexion.
Note : tout ce qui suit, sauf indication contraire, est exécuté avec les droits de root.
L'établissement de la connexion à Internet se fera par un seul script : /etc/ppp/scripts/pppconnect. Celui-ci devra ouvrir une boite de dialogue dans laquelle on pourra choisir l'une quelconque des connections configurées dans /etc/ppp.conf.
La rupture de la liaison se fera via le script /etc/ppp/scripts/pppdisconnect.
{wanadoo name}wanadoo (max 36h)
{wanadoo smtp}smtp.wanadoo.fr
{wanadoo search}wanadoo.fr
{wanadoo dns}193.252.19.3
{wanadoo dns}193.252.19.4
{wanadoo login}yyyyyyyyyyy
{wanadoo password}xxxxxxxx
{wanadoo telephone}0860888080
{offline smtp}
{offline search}tux
{global modeminit}ATM0L0
{ident motclef}valeurident peut être n'importe quoi (du moment que ça ne contient pas d'espace), mais il y a deux valeurs particulières :
Mot clef | Type de la valeur | Utilisation |
name | chaîne de caractère quelconque | le nom de la connexion ident |
dns | une adresse IP | adresse d'un DNS (serveur de noms de domaine), vous pouvez en mettre autant que vous le souhaitez (sur des lignes distinctes). |
autodns | rien | si vous précisez cette option pour une connexion (ou pour toutes via global), pppd demandera à votre ISP les adresses de deux DNS. Dans ce cas (que cela fonctionne ou pas) les DNS que vous précisez par l'option dns sont ignorés. |
search | nom de domaine (valide ?) | un nom de domaine qui sera ajouté automatiquement aux noms qui n'auront pu être résolus sans celui-ci. |
smtp | nom d'un serveur smtp ou une adresse IP | ce nom doit alors être le nom du serveur de mails sortant de l'ISP correspondant à cette connexion. |
login | chaîne de caractère | le login correspondant à cet ISP. |
password | chaîne de caractère | le mot de passe de ce login (attention au propriétaire de ce fichier : il doit être en clair !) |
telephone | numéro de téléphone | de l'ISP |
modeminit | chaîne de caractère | ce doit alors être une chaîne d'initialisation de votre modem renvoyant 'OK' ; vous pouvez avoir autant de chaîne d'initialisation que vous le souhaitez. |
Attention : le parseur distingue les majuscules des minuscules.
Attention : l'ordre des différentes lignes de ce fichiers
sont essentielles : elles détermine la validité des diverses
options (c'est à dire : si vous préciser deux fois la même
option, seule la dernière valeurs est prise en compte).
# lecture du fichier de configuration /etc/ppp.conf pour
# la création des paramètres de configurations
!
# /etc/ppp/chat/auto
# /etc/ppp/peers/auto
# /etc/ppp/pap-secrets
# /etc/resolv.conf
($cnx,$ipup) = @ARGV ;
open(PPPCONF,"/etc/ppp.conf") ;
@modeminit = () ;
@resolv = () ;
$search = "org" ;
$autodns = 0 ;
while (<PPPCONF>) {
if (($p) = /{$cnx login}(.*)/) { $login = $p ; }
if (($p) = /{global login}(.*)/) { $login = $p ; }
if (($p) = /{$cnx password}(.*)/) { $password = $p ; }
if (($p) = /{global password}(.*)/) { $password = $p ; }
if (($p) = /{$cnx smtp}(.*)/) { $smtp = $p ; }
if (($p) = /{global smtp}(.*)/) { $smtp = $p ; }
if (($p) = /{$cnx telephone}(.*)/) { $telephone = $p ; }
if (($p) = /{global telephone}(.*)/) { $telephone = $p ;
}
if (($p) = /{$cnx modeminit}(.*)/) { push(@modeminit,$p)
; }
if (($p) = /{global modeminit}(.*)/) { push(@modeminit,$p)
; }
if (($p) = /{$cnx dns}(.*)/) { push(@resolv,$p) ; }
if (($p) = /{global dns}(.*)/) { push(@resolv,$p) ; }
if (($p) = /{$cnx search}(.*)/) { $search = $p ; }
if (($p) = /{global search}(.*)/) { $search = $p ; }
if (($p) = /{$cnx autodns}(.*)/) { $autodns = 1 ; }
if (($p) = /{global autodns}(.*)/) { $autodns = 1 ; }
}
if ($autodns) {
$resolv = () ;
}
if ($ENV{"DNS1"} ne "") {
push(@resolv,$ENV{"DNS1"}) ;
}
if ($ENV{"DNS2"} ne "") {
push(@resolv,$ENV{"DNS2"}) ;
}
open(CHAT,">/etc/ppp/chat/auto") ;
print CHAT "'ABORT' 'BUSY'
'ABORT' 'ERROR'
'ABORT' 'NO CARRIER'
'ABORT' 'NO DIALTONE'
'ABORT' 'Invalid Login'
'ABORT' 'Login incorrect'
'' 'ATZ'
'OK' " ;
foreach (@modeminit) { print CHAT "'$_'\n'OK'
"
; }
print CHAT "'ATDT$telephone'
'CONNECT' ''
'TIMEOUT' '5'
'~--' ''
" ;
close CHAT ;
open (PEERS,">/etc/ppp/peers/auto");
print PEERS "connect '/usr/sbin/chat -v -f
/etc/ppp/chat/auto'
user $login
ipparam $cnx
" ;
if ($autodns) {
print PEERS "usepeerdns\n" ;
}
close PEERS ;
open (PAP,"/etc/ppp/pap-secrets") ;
$file = "" ;
while (<PAP>) { $file .= $_ ; }
close PAP ;
open (PAP,">/etc/ppp/pap-secrets") ;
# on supprime les occurrences précédentes :
$file =~ s/#AUTOBEGIN#.*#AUTOEND#//s
;
if ($login ne "") {
$file .= "#AUTOBEGIN#\n$login * $password\n#AUTOEND#";
}
print PAP $file ;
close PAP ;
open (SENDSRC,"/etc/sendmail.BASE") ;
open (SENDDST,">/etc/sendmail.cf") ;
while (<SENDSRC>) {
s/{MAILHOST}/$smtp/g ;
print SENDDST ;
}
close SENDSRC ;
close SENDDST ;
# on modifie le ns :
open (RESOLV,">/etc/resolv.conf") ;
print RESOLV "search $search\n" ;
foreach $nameserver (@resolv) {
print RESOLV "nameserver $nameserver\n"
;
}
close RESOLV ;
# on relance sendmail (seulement si
# c'est ip-up ou ip-down qui à lancé le
# script, en effet il faut être root) :
if ($ipup =~ /ip(up|down)/) {
`/etc/rc.d/init.d/sendmail restart`
} ;
Le script n'appel pas de commentaire particulier, si ce n'est pour les 12 lignes en gras. Ce sont ces lignes qui vont demander à l'isp des adresses de ses dns. Les 9 premières regardent si les variables d'environnement DNS1 et DNS2 existent (quand on est en mode autodns). Les 3 dernières ajoutent au script de commande de pppd l'option qui lui réclame ces information.
Pour que ce script puisse fonctionner, il faut que vous créiez un fichier /etc/sendmail.BASE dont le nom de serveur smtp est {MAILHOST} (à la place du nom du serveur de mail sortant d'un de vos isp). Si votre serveur de sendmail est configuré et fonctionne, il suffit de copier /etc/sendmail.cf dans /etc/sendmail.BASE et cherchez dans /etc/sendmail.BASE la ligne (ou quelque chose de semblable...) :
DSsmtp:smtp.isp.fret vous la changez en :
DSsmtp:{MAILHOST}Attention : le fichier /etc/sendmail.cf est très sensible, ne le modifiez que si vous savez ce que vous faites.
# ceci nécessite que l'option usepeerdns
# soit activée dans /etc/ppp/peers/script
# dans ce cas DNS1 et DNS2 reçoivent les
# adresse des deux dns du provider.
# dans le cas où ces variables ne sont pas
# initialisées, les options {connexion dns}***
# doivent être utilisées pour préciser le dns
!
# en lieu et place de autodns
export DNS1
export DNS2
/etc/ppp/scripts/initcnx $6 ipup
# récupération des mail et envoie des mails en attente
:
/usr/bin/fetchmail
/usr/sbin/sendmail -q
# on récupère automatiquement les mails toutes les
11 minutes
# (11 minutes car netcourrier n'aime pas qu'on consulte
# les comptes pop trop souvent !)
/usr/bin/fetchmail --daemon 660
# mettons notre pc à l'heure :
ntpdate ntp-sop.inria.fr
# comme on n'est plus connecté au net, on quitte fetchmail
/usr/bin/fetchmail --quit
# y'a plus de dns a priori...
export DNS1=""
export DNS2=""
/etc/ppp/scripts/initcnx offline ipdown
# on peut effacer les fichiers auto :
rm -f /etc/ppp/chat/auto
rm -f /etc/ppp/peers/auto
open(PPPCONF,"/etc/ppp.conf") ||
`/opt/apps/bin/Xdialog --title Erreur --msgbox\
"impossible d\'ouvrir /etc/ppp.conf\nchangez\
les droits de ce fichier\nou bien créez le."\
0 0` ||
die "/etc/ppp.conf illisible.\n" ;
# on cherche les lignes : {connexion name}isp
while (<PPPCONF>) {
if (($tag,$name) = /{(.*?) name}(.*)/) {
$cnx{$tag} = $name ;
}
}
$cmdline = "" ;
$num = 0 ;
foreach $key (sort keys %cnx) {
$cmdline .= "\"$key\" \"$cnx{$key}\" false " ;
$num++ ;
}
$cnx = `/opt/apps/bin/Xdialog --stdout\
--radiolist Connexion 0 0 $num $cmdline` ;
chop($cnx);
if ($cnx ne "") {
# initialisation (sauf le dns !) qui est fait par
# ip-up
`/etc/ppp/scripts/initcnx $cnx` ;
# connexion !
`/usr/sbin/pppd call auto` ;
# ce qui suit n'est pas nécessaire, mais
# agréable :
# attendons l'établissement de la liaison
`sleep 60s`
# et rapatrions les mails de l'utilisateur
# pour peu qu'il ai configuré fetchmail
`fetchmail`
# ceci permet à un utilisateur de se configurer
# un compte que le root ne connait pas.
} else {
`/opt/apps/bin/Xdialog --title Information\
--infobox "Aucune connexion n'a été sélectionnée."\
0 0 1500` ;
}
pour faire appartenir tout ce que contient /etc/ppp à pppusers
:
chown -R root:pppusers /etc/ppp/*
pour autoriser les membres du groupe pppusers à modifier
les fichiers /etc/ppp/peers/auto etc. :
chmod -R g+rwx /etc/ppp/scripts/ /etc/ppp/chat /etc/ppp/pap-secrets
pour que les étrangers le reste :
chmod -R o-rwx /etc/ppp/* /etc/ppp.conf /etc/sendmail.BASE
Attention : seuls les utilisateurs ayant établi la connexion auront le droit de la coupée : ce qui est somme toute assez logique. Le root ayant lui, comme toujours, tous les droits.
Voilà, bon surf.
Reste le problème des spammers ! La suppression automatique des mails dits "spam", mails de publicité non sollicités, fera l'objet d'un prochain article.
par Serge (révisions par Jice)
L'accès internet haut débit sous Linux.
Il existe trois protocoles différents pour les connexions ADSL : PPTP (Point to Point Tunneling Protocol), PPPOE (PPP Over Ethernet : modems ethernet...) et PPPOA (PPP over ATM : modems USB...). Les kits founis jusqu'au début de l'année 2001 environ (par France Télécom ou autre) étaient basés sur PPTP. Maintenant ils sont généralement basés sur PPPOE ou PPPOA.
Si vous avez une debian, lisez plutot ce document.
Ce document traite principalement des modems ADSL avec interface ethernet, pour les modems USB voir à la fin du document.
Il existe aussi des modems PCI pour se connecter avec ADSL.
Ce document s'inspire largement du HOWTO ADSL.
Le protocole pptp permet de créer un "tunnel" ppp au travers d'une connexion ethernet.
Tout d'abord vérifions la configuration du noyau : vous devez avoir le support PPP soit dans le noyau, soit en module. Une méthode simple est de lancer en root un :
pppd
Si vous voyez une réponse du style "%!/:." c'est que c'est bon, arrêtez le alors via un CTRL-C, ou ouvrez un autre terminal (ou changez de console virtuelle) et tapez un :
killall pppd
Autrement recompilez votre noyau avec le support ppp (en natif ou en module). Voir la section noyau.
Bon il va falloir avant tout ajouter le support pptp. Récupérons donc le package comprenant le client pptp patché : pptp-linux-1.0.2-patched.tar.gzpptp-linux-1.0.2-patched.tar.gz
Pour installer pptp:
tar zxf pptp-linux-1.0.2-patched.tar.gz
cd pptp-linux-1.0.2
make install -b pptp pptp_callmgr /usr/sbin/
Et voilà, nous avons le support pptp !
Comme je l'ai indiqué plus haut, pptp se sert de ppp et d'une interface ethernet, donc il est logique de configurer ppp. Nous allons donc modifier les fichiers de configuration de ppp, les fichiers /etc/ppp/options et /etc/ppp/pap-secret :
Pour /etc/ppp/options :
noauth
name "login" # mettre ici le login que vous a fourni votre provider
noipdefault
defaultroute
mtu 1492
mru 2400
Et pour /etc/ppp/pap-secret :
"login" * "password" * # login et password fourni par votre provider, à mettre entre guillemets.
Il nous reste maintenant à configurer l'interface ethernet qui est reliée au modem ADSL. Je n'explique pas comment la prendre en charge par le noyau, voir la rubrique connexion réseau local de cette même section pour ça. Je suppose que cette interface est eth0, adaptez suivant votre configuration bien sûr.
Affectons l'adresse IP 10.0.0.10 à cette interface, attention à bien mettre une adresse de ce réseau IP privé et pas d'un autre !
ifconfig eth0 10.0.0.10
Et voilà !
N'oubliez pas non plus de configurer votre /etc/resolv.conf pour qu'il contienne les adresses de serveurs DNS (serveurs de nom) de votre fournisseur d'accès :
/etc/resolv.conf :
search nom_domain_local.com
nameserver adresse_ip_dns_primaire
nameserver adresse_ip_dns_secondaire
Nous allons créer maitenant les scripts de connexion / déconnexion.
Script de connexion : appelons le adsl-start, il contient :
#!/bin/bash
/usr/sbin/pptp 10.0.0.138
sleep 20
echo "Ajout de la route par défaut : "
/sbin/route add -net 0.0.0.0 netmask 0.0.0.0 dev ppp0
Et un adsl-stop
#!/bin/bash
killall pptp
sleep 1
killall pppd
rm -rf /var/run/pptp/
Il suffit alors de lancer les scripts pour se connecter / déconnecter. Vous pouvez aussi mettre dans /etc/rc.local une ligne appelant adsl-start pour lancer la connexion au boot de la machine. Ou alors faites un script pour gérer la connexion/déconnexion en sysVinit.
France Télécom vous fournit normalement un CD contenant le support pppoe pour votre modem sous Linux. Comme ce logiciel n'est ni libre ni gratuit, je ne détaille pas ici comment s'en servir. Sachez juste qu'il faut en gros copier le binaire pppoed-2.x (x dépendant de la version de votre kernel, 2.0.x ou 2.2.x) dans /usr/sbin, ainsi que les scripts ppoe-start et ppoe-stop, et le fichier de configuration ppoe.options dans /etc. Un fichier d'aide est fourni avec ce logiciel.
Comme nous sommes dans le monde du logiciel libre, nous allons voir comment utiliser votre connexion ADSL PPPOE via le support libre sous Linux : rp-pppoe.
Téléchargez celui-ci à cette adresse: http://www.roaringpenguin.com/pppoe/ .
J'explique ici son installation à partir des sources tarball (tar.gz) car cela est applicable à toutes les distributions. On détarre / dégzip les sources dans un répertoire de votre choix et on lance le script go qui s'occupe de tout :
# tar xvfz rp-pppoe-3.3.tar.gz
# cd rp-pppoe-3.3
# ./go
À partir de ce moment, répondez juste aux questions que l'on vous pose.
En cas de problème avec le script go, vous pouvez essayer de compiler / installer "à la main" (comme dans les anciennes versions de rp-pppoe) :
# tar xvfz rp-pppoe-2.8.tar.gz
# cd rp-pppoe-2.8
# ./configure
# make && make install
# /usr/sbin/adsl.setup
Vérifiez après dans le fichier /etc/pppoe.conf les lignes :
ETH=ethx # mettre l'interface sur laquelle est reliée votre modem ADSL
USER=login # mettre le login fourni par le FAI
Il ne faut pas cette fois ci configurer votre carte ethernet, c'est à dire que vous devez quand même charger le module de votre carte mais n'affectez pas d'adresse à cette carte. C'est les scripts de connexion qui s'en chargeront.
N'oubliez pas non plus de configurer votre /etc/resolv.conf pour qu'il contienne les adresses de serveurs DNS (serveurs de nom) de votre fournisseur d'accès :
/etc/resolv.conf :
search nom_domain_local.com
nameserver adresse_ip_dns_primaire
nameserver adresse_ip_dns_secondaire
Il nous reste à configurer ppp. Editez /etc/ppp/pap-secrets et ajoutez ces deux lignes :
nom_login * password # login et password fournis par le provider
netissimo@netissimo.fr * netissimo
Copiez aussi ce fichier en chap-secrets (cp pap-secrets chat-secrets)
Pour lancer alors la connexion : adsl-start
Pour la stopper : adsl-stop
Vous pouvez là aussi mettre dans votre /etc/rc.local un appel a adsl-start pour lancer votre connexion ADSL dès le boot du PC, ou ecrire un petit script pour les lancer via l'init sysV (aidez vous des scripts existants !).
Ce modem fonctionne grâce à un driver opensource. L'installation est extrêmement simple sur une Mandrake 8.x notamment (voir cet article) et doit bien se passer aussi sur les autres distributions (voir l'article sur l'Alcatel Speedtouch USB).
Alcatel fournit aussi des drivers Linux pour ses modems USB : http://www.alcatel.com/consumer/dsl/dvrreg_lx.htm, mais ils sont moins stables que le driver opensource (à préférer). On les récupère juste pour avoir le microcode du modem.
Décembre 2001 : un driver opensource pour ce driver est également sorti. Voir http://eciadsl.flashtux.org. Il est maintenant assez stable pour pouvoir être utilisé.
Voici la liste des modems supportés par ce driver (modems basés sur le chipset Globespan).
Un article sur Léa explique maintenant comment installer ce modem.
Voir l'article correspondant sur Léa.
par Serge (légèrement modifié par Jicé)
Protégez vous derrière un mur de feu.
Ce document a été inspiré du Firewall-HOWTO, de l'IPCHAINS-HOWTO et du IP-Masquerade-HOWTO. C'est la synthèse de ces trois documents pour permettre la mise en place des techniques de Firewalling. Je vous conseille quand même de lire ces HOWTO pour plus de compréhension. Je suppose que vous savez configurer un réseau IP, au cas où jeter un coup d'oeil sur la rubrique réseau local. Il se peut que des erreurs se soient glissées dans cette présentation, de plus je ne pourrai être tenu responsable d'une mauvaise configuration de votre système. La sécurité est un sujet vaste, toujours en évolution et je ne prétends pas vous fournir ici une solution exempte de tout danger. Ce document est à prendre comme une présentation de ces techniques.
ATTENTION: rubrique non finie, le filtrage plus fin et les techniques de proxy ne sont pas encore décrits.
Bon qu'est un Firewall ? Si on traduit, cela nous donne « pare-feu » , vous allez me dire « ha bon mon micro me protège du feu ? », bien sûr que non, un Firewall sert en fait à protéger un réseau vis à vis d'un autre ou d'autre réseaux.
Plusieurs types de Firewall existent et ne travaillent pas de la même façon et n'offrent pas les mêmes sécurités.
Les Firewall sont de plus en plus utilisés pour protéger les réseaux locaux d'entreprises vis à vis de l'internet. Il s'agit en fait d'une machine qui est reliée vers l'extérieur (Internet) et vers le réseaux local aussi et qui en quelque sorte analyse le trafic réseau qui la traverse pour savoir si oui ou non elle laisse passer ce trafic que ça soit dans un sens ou dans l'autre :
_ ---- _ ________ +---> PC2
( ) | | |
( INTERNET )<---->|FIREWALL|<---+---> PC3
(_ _) |________| |
---- +---> PC4
Le Firewall le plus simple est une machine qui possède une connexion vers l'extérieur et une autre sur le réseau local et qui ne transmet pas le trafic réseau d'un réseau à l'autre. Si une machine du réseau local veut accéder vers l'extérieur, elle ouvre en fait une session sur le Firewall, et travaille directement sur cette machine pour accéder vers l'extérieur. De ce fait aucun trafic réseau de l'extérieur ne peut rentrer sur le réseau local.
Vous avez compris les problèmes que cela engendre :
Ils travaillent sur les paquets réseaux eux-même. Pour les personnes qui ont des connaissances réseaux, ce type de Firewall travaille sur la couche réseau du modèle OSI. Ils analysent les paquets entrants/sortants suivant leur type, leurs adresses source et destination et les ports. Comme ils travaillent directement sur la couche IP, ils sont très peu gourmands en mémoire.
Avec Linux ce style de filtrage au niveau de la couche IP est intégré directement dans le noyau, il suffit donc d'avoir un 486 avec 8 Mo de mémoire et d'une distribution Linux avec juste un kernel de base et la couche IP pour faire un tel Firewall.
De plus ils sont totalement transparents pour les utilisateurs, pas d'authentification pour aller vers l'extérieur et pas de paramétrages spécifiques sur les machines des utilisateurs. Un désavantage, c'est qu'il n'y a pas d'authentification possible par utilisateur mais par adresse IP. C'est à dire que si l'on veut en interne interdire à certaine personnes d'aller vers l'extérieur ce n'est possible que si l'on connaît l'adresse de la machine de cet utilisateur, on ne peut pas empêcher que la personne aille sur une autre machine et il faut de plus que les machines aient toujours la même adresse, ce qui peut poser problème lorsqu'on on utilise du DHCP.
Les Proxy serveur sont utilisés pour contrôler et analyser tout trafic avec l'extérieur. Certains proxies utilisent en plus un cache, c'est à dire qu'ils stockent des données en local, ce qui permet de réduire le trafic réseau, en effet si une même donnée est demandée plusieurs fois, au lieu d'aller la chercher au nouveau vers l'extérieur c'est le proxy lui même qui la fournit. Leur fonctionnement dépend de leur type :
Leur fonctionnement ressemble un peu au fonctionnement du premier Proxy, c'est à dire quand une application d'une machine locale va vers l'extérieur, en fait elle se connecte sur le Proxy et c'est le Proxy lui-même qui va chercher l'information puis la renvoyer vers la machine demandeuse.
Un exemple : vous voulez récupérer un fichier via FTP sur internet, en fait votre client FTP vas se connecter sur le proxy qui va faire serveur FTP, le Proxy va en même temps ouvrir une session FTP sur le serveur distant, il va récupérer le fichier cible et vous le renvoyer via son serveur FTP. En fait c'est toujours le Proxy qui récupère les données et vous les renvoie.
Ça à l'avantage d'être très sécurisé pour la machine cliente, ça fait cache la plupart du temps donc ça réduit le trafic réseau, ça peut permettre l'authentification aussi si l'on oblige une authentification sur les applications du Proxy. Par contre ça demande des configurations spéciales sur les clients, ça demande aussi d'installer sur le proxy les applications serveur de chaque protocole que l'on souhaite fournir aux utilisateurs et ça consomme énormément de ressources.
Il ne travaille pas sur les applications, en fait il « refait » en quelque sorte les connexions. Le client passe par le Proxy qui lui en interne refait la connexion vers l'extérieur. Comme les Firewalls filtrants, ils ne font pas d'authentification, mais peuvent quand même enregistrer l'utilisateur qui a demandé la connexion.
On va dans cette partie configurer le kernel pour préparer notre système à devenir un Firewall filtrant.
Comme je l'ai dit plus haut, les Firewall filtrants sont facilement configurables sous Linux car ils sont pris en charge directement dans le noyau de Linux. Ce type de Firewall étant très léger, il vous suffit d'un 486 avec 16 voire 8 Mo de RAM. Vous avez besoin aussi suivant la version du kernel :
Pour ce document je décris la manière de mettre en place tout ça pour un kernel de version 2.2.X car à mon goût le Firewall est beaucoup plus sûr avec ce kernel (stack IP plus sûre et ipchains bien plus puissant que ipwadm), de plus il est facile de trouver une distribution à base de kernel 2.2.X, les 2.0.X deviennent rare.
Si vous voulez de plus faire un Proxy, récupérez l'un de ces programmes :
Une recherche sur freshmeat vous trouvera ça :) Mais bon pour l'instant ce document ne traite que des Firewall filtrant, j'ajouterais une rubrique Proxy plus tard.
Bon il faut maintenant configurer le kernel pour activer ce filtrage. Cochez les options suivantes :
<y> Enable experimental
<y> Enable loadable module support
<*> Packet socket
[ ] Kernel/User netlink socket
[y] Network firewalls
[ ] Socket Filtering
<y> Unix domain sockets
[y] TCP/IP networking
[ ] IP: multicasting
[y] IP: advanced router
[ ] IP: kernel level autoconfiguration
[y] IP: firewalling
[y] IP: always defragment (required for masquerading)
[y] IP: transparent proxy support
[M] IP: masquerading
--- Protocol-specific masquerading support will be built as modules.
[M] IP: ICMP masquerading
--- Protocol-specific masquerading support will be built as modules.
[Y] IP: masquerading special modules support <- Choisir tout les modules en répondant M
[y] IP: optimize as router not host
< > IP: tunneling
< > IP: GRE tunnels over IP
[y] IP: aliasing support
[y] IP: TCP syncookie support (not enabled per default)
--- (it is safe to leave these untouched)
< > IP: Reverse ARP
[y] IP: Allow large windows (not recommended if <16Mb of memory)
< > The IPv6 protocol (EXPERIMENTAL)
Cochez également toutes les autres options nécessaires (voir la rubrique noyau).
Bon vous recompilez le noyau (make dep; make clean; make bzImage), déplacez votre ancien répertoire de module (mv /lib/module/votre_version /lib/module/votre_version.old), puis compilez et instakllez les modules (make modules; make modules_install), copiez alors le nouveau kernel (cp /usr/src/linux/arch/i386/boot/bzImage /boot) et si vous utilisez LILO, reconfigurez le pour qu'il pointe sur votre nouveau kernel (editez /etc/lilo.conf) et relancez lilo (/sbin/lilo), sinon reconfigurez votre loader (CHOS, LOADLIN, etc.). Enfin on reboute (reboot). Ouf ! :)
Assurez-vous d'avoir bien la configuration précédente pour votre kernel (validez les lors de la configuration du kernel).
Compilez le kernel puis les modules. Une fois tout ça réalisé, ajouter dans le fichier /etc/rc.d/rc.local (vérifiez le chemin, il peut être différent suivant les distributions) le chargement des modules de masquerade :
/sbin/depmod -a (n'ajoutez cette ligne que si elle n'est pas déjà présente)
/sbin/modprobe ip_masq_ftp (pour ftp)
/sbin/modprobe ip_masq_raudio (pour real audio)
/sbin/modprobe ip_masq_irc (pour IRC)
et tout autre module comme ip_masq_cuseeme, ip_masq_vdolive, etc. que vous pouvez récupérer sur le net, si vous voulez bien sûr que de tels services soit accessibles par votre réseau local.
Avant de continuer vérifiez bien que votre LAN (réseau local) est bien sur une adresse réservée privé, c'est a dire du type:
10.0.0.0 - 10.255.255.255 Classe A
172.16.0.0 - 172.31.255.255 Classe B
192.168.0.0 - 192.168.255.255 Classe C
Pour plus de simplicité, je considère que votre LAN est sur l'adresse réseau 192.168.1.0 et que votre « passerelle » (le firewall Linux) a comme adresse 192.168.1.1
Configurez aussi les autres machines de votre LAN avec bien sûr une adresse IP valide (de 192.168.1.2 jusqu'à 192.168.1.254), l'adresse de passerelle et de DNS, celle du Firewall (192.168.1.1).
Bon maintenant sur le Firewall, on va activer le masquerade avec:
# ipchains -P forward DENY
# ipchains -A forward -s yyy.yyy.yyy.yyy/x -j MASQ
avec x qui correspond au masque et yyy.yyy.yyy.yyy l'adresse réseau de votre LAN (ici 192.168.1.0)
Masque | Valeur de x | Classe |
---|---|---|
255.0.0.0 | 8 | A |
|
|
|
|
|
|
|
|
|
Si pour vous ce style de notation de masque vous gêne vous pouvez aussi utiliser la notation xxx.xxx.xxx.xxx du masque pour remplacer x.
Pour notre exemple on tape alors:
# ipchains -P forward DENY
# ipchains -A forward -s 192.168.1.0/24 -j MASQ
ou
# ipchains -P forward DENY
# ipchains -A forward -s 192.168.1.0/255.255.255.0 -j MASQ
Bon on a fait quoi au juste là ?
Donc en fait notre Firewall Linux ne laissera passer au travers de lui que les communications LAN<->Extérieur.
Au lieu de laisser la possibilité à toutes les machines de notre LAN d'avoir accès vers l'extérieur, on aurait pu aussi ne spécifier que certaines machines, par exemple on veut que juste le patron de notre société ainsi que l'administrateur réseau par exemple qui ont des machines avec adresse IP 192.168.1.3 et 192.168.1.10. Pour cela il faut jouer sur le masque, ça nous donne:
# ipchains -P forward DENY
# ipchains -A forward -s 192.168.1.3/32 -j MASQ
# ipchains -A forward -s 192.168.1.10/32 -j MASQ
Pour rendre ces règles « permanentes » après
chaque reboot, ajoutez-les aussi dans un fichier que vous appelez par exemple
rc.firewall
que vous placez dans
/etc/rc.d, sinon vous allez devoir les taper
à chaque reboot du système.
On résume alors ce qui peut se trouver dans un tel fichier:
#
# Firewall.rc
#
# Script de démarrage des règles du firewall
#
# Tchesmeli serge , Version 0.2
#
# Lea : http://www.lea-linux.org
#
echo "Démarrage FIREWALL :"
echo "- Activation de l'IP forwarding..."
echo "1" > /proc/sys/net/ipv4/ip_forward# D'abord on bloque tout
echo -n "- Arrêt total des transmissions réseau..."
if [ -x /sbin/ipchains ]; then
/sbin/ipchains -P forward DENY
echo "OK"
else
echo "Erreur !"
echo "Votre noyau n'est pas configuré pour\
permettre le filtrage.... veuillez le recompiler."
exit
fi
# On charge les modules de masquerade
echo -n "- Chargement des modules de masquerade... "
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_raudio
/sbin/modprobe ip_masq_irc
echo "OK"# Puis on applique les règles
echo -n "- Chargement des règles de filtrage... "
# ipchains -P forward DENYipchains -A forward -s 192.168.1.0/255.255.255.0 -j MASQ
echo "OK"
echo
"Firewall prêt."
On peut alors appeler ce script depuis /etc/rc.d/rc.local en y ajoutant une ligne :
source rc.firewallVoilà ! Votre firewall est configuré ! A vous de jouer sur les règles afin d'optimiser la sécurité sur votre réseau local...
Arnaud de Bermingham
IpTables par l'exemple
Contact : duracell chez apinc point org
révision par Jice <jice
chez lea-linux point org>
révision par Fred <fred
chez lea-linux point org>
IpTables est fiable et dispose de très nombreuses options qui permettent de faire du filtrage très fin.
IpTables a besoin d'un kernel de génération 2.4 compilé avec des options spéciales. Ceci ne pose pas de problèmes avec les noyaux 2.4 génériques des principales distributions basées sur cette génération de kernel.
Si vous désirez re-compiler votre kernel, il faut spécifier les options nécessaires au fonctionnement d'iptables.
Les options suivantes doivent êtres activées en module (M) ou dans le kernel (Y) :
CONFIG_PACKET
CONFIG_NETFILTER
CONFIG_IP_NF_CONNTRACK
CONFIG_IP_NF_FTP
CONFIG_IP_NF_IRC
CONFIG_IP_NF_IPTABLES
CONFIG_IP_NF_FILTER
CONFIG_IP_NF_NAT
CONFIG_IP_NF_MATCH_STATE
CONFIG_IP_NF_TARGET_LOG
CONFIG_IP_NF_MATCH_LIMIT
CONFIG_IP_NF_TARGET_MASQUERADE
et éventuellement :
CONFIG_IP_NF_COMPAT_IPCHAINS pour garder la compatibilité
avec ipchains.
CONFIG_IP_NF_COMPAT_IPFWADM pour garder la compatibilité
avec ipfwadm.
CONFIG_IP_NF_TARGET_REDIRECT indispensable, pour les proxies
transparents par exemple.
CONFIG_IP_NF_MATCH_MAC permet de matcher avec les adresses
MAC.
Ne pas oublier le support réseau et TCP/IP et compiler le kernel
comme d'habitude :
make dep && make clean && make bzImage &&
make modules && make modules_install
# modprobe ip_tables
selon les besoins, on peut éventuellement charger les modules suivants :
# modprobe ip_nat_ftp
# modprobe ip_nat_irc
# modprobe iptable_filter
# modprobe iptable_mangle
# modprobe iptable_nat
Si on a besoin de pouvoir forwarder* les paquets IP (dans la plupart des cas), il sera nécessaire d'exécuter cette commande :
# echo 1 > /proc/sys/net/ipv4/ip_forward
afin de l'indiquer au noyau.
Nota Bene : tous les modprobe semblent inutiles car le kernel les chargent automatiquement si l'on se sert de l'une des fonctionnalités d'iptables.
-D --delete : Permet de supprimer une chaîne. On peut
la matcher de 2 manières, soit en spécifiant le numéros
de la chaîne a supprimer, soit en
spécifiant la règle à retirer.
Exemples :
# iptables -D INPUT --dport 80 -j DROP
# iptables -D INPUT 1
-R --replace : Permet contrairement à --delete
de remplacer la chaîne spécifiée.
Exemple :
# iptables -R INPUT 1 -s 192.168.0.1 -j DROP
-I --insert : Permet d'ajouter une chaîne dans un endroit
spécifié de la chaîne.
Exemple :
# iptables -I INPUT 1 --dport 80 -j ACCEPT
-L --list : Permet d'afficher les règles.
Exemples :
# iptables -L
# Affiche toutes les règles des chaînes de FILTER
# iptables -L INPUT #
Affiche toutes les règles de INPUT (FILTER)
-F --flush : Permet de vider toutes les règles d'une
chaîne.
Exemple :
# iptables -F INPUT
-N --new-chain : Permet de créer une nouvelle chaîne.
Exemple :
# iptables -N LOG_DROP
-X --delete-chain : Permet d'effacer une chaîne.
Exemple :
# iptables -X LOG_DROP
-P --policy : Permet de spécifier au kernel la target
par défaut d'une chaîne DENY, ACCEPT, REJECT, DROP ...
Exemple :
# iptables -P INPUT DROP
Le "!" peut être utilisé pour certaines commandes afin
de spécifier le contraire (on peut le traduire par "sauf"). Par
exemple une commande qui doit refuser tout trafic TCP sauf ce qui provient
de l'adresse IP 10.42.42.42 sera traduite par la commande suivante :
Exemple :
# iptables -A INPUT -p tcp --source ! 10.42.42.42
-j DENY
Les adresses IP peuvent optionnellement être spécifiées avec le masque associé sous la forme [adresse ip]/[masque].
-p --protocol : Spécifier un protocole : tcp,
udp,
icmp,
all
(tous)
Exemple :
# iptables -A INPUT -p icmp -j DENY
-s --source : Spécifier une adresse source à
matcher
Exemple :
# iptables -A INPUT -p tcp -s 192.168.42.42
-j ACCEPT
-d --destination : Spécifier une adresse destination
Exemple :
# iptables -A FORWARD -p tcp -d 10.1.0.1
-j ACCEPT
-i --in-interface : Spécifier une interface d'entrée
Exemple :
# iptables -A INPUT -p icmp -i eth0 -j DENY
-o --out-interface : Spécifier une interface de sortie
Exemple :
# iptables -A OUTPUT -p icmp -o eth0 -j DENY
-f --fragment : Paquet fragmenté
Exemple :
# iptables -A INPUT -p icmp -f -j DENY
--sport --source-port : Spécifier le port source ou
une plage de ports, fonctionne aussi en udp, -m multiport permet
de
spécifier plusieurs ports à matcher.
Exemples :
# iptables -A INPUT -p tcp --sport 80 -j
ACCEPT
# iptables -A INPUT -p udp --sport 80 -j
DROP
# iptables -A OUTPUT -p tcp -m multiport
--sport 3128,21,1000 -j DROP
# iptables -A OUTPUT -p tcp --sport 1024:2042
-j ACCEPT
--dport --destination-port : Spécifier le port destination
ou une plage de ports, fonctionne aussi en udp, -m multiport
permet de spécifier plusieurs ports a matcher.
Exemples :
# iptables -A INPUT -p tcp --dport 110 -j
DENY
# iptables -A INPUT -p udp --dport 110 -j
DENY
# iptables -A INPUT -p tcp -m multiport --dport
110,4242,119 -j DROP
# iptables -A INPUT -p tcp --sport 4925:4633
-j ACCEPT
--tcp-flags : Spécifier un flag tcp à matcher
: SYN ACK FIN RST URG PSH ALL NONE
Exemple :
# iptables -A INPUT -p tcp --dport 42 --tcp-flags
SYN,ACK -j ACCEPT
--icmp-type : Spécifier un type de paquet icmp à
matcher
Exemple :
# iptables -A INPUT -p icmp --icmp-type 8
-j DROP
--mac-source : Spécifier l'adresse MAC à matcher
Exemple :
# iptables -A INPUT --mac-source 42.42.AA.42.42.AA
-j DROP
--state : Permet de spécifier l'état du paquet
à matcher parmi les états suivants :
ESTABLISHED : paquet associé à une connexion
déjà établie
NEW :
paquet demandant une nouvelle connexion
INVALID : paquet associé
à une connexion inconnue
RELATED : Nouvelle connexion
mais liée, idéal pour les connexions FTP
Exemples :
# iptables -A INPUT -i eth0 -p tcp --dport
80 -m state --state NEW,ESTABLISHED -j ACCEPT
# iptables -A OUTPUT -o eth0 -p tcp --sport
80 -m state --state ESTABLISHED -j ACCEPT
Spécificités NAT :
--to-destination : Utilisé en target pour le DNAT, permet
de spécifier l'adresse de destination de la translation, on peut
également spécifier un port s'il est différent du
port source.
Exemples :
# iptables -t nat -A PREROUTING -d 42.12.42.12
-p tcp --dport 110 -j DNAT --to-destination 192.168.1.2:6110
# iptables -t nat -A PREROUTING -d ! 42.12.42.12
-p tcp --dport 80 -j DNAT --to-destination 192.168.2.1:3128
--to-source : Utilisé pour en target pour le SNAT, permet de spécifier l'adresse source de la translation.
Spécificités pour les LOGS :
--log-level : Level, niveau de log
Exemple : Cf. chapitre 3
--log-prefix : Permet de spécifier un préfixe
pour les logs.
Exemple : Cf. chapitre 3
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -N LOG_DROPEt ensuite, plutôt que de mettre -j DROP, il faut mettre -j LOG_DROP et les trois dernières règles doivent être :
iptables -A LOG_DROP -j LOG --log-prefix '[IPTABLES DROP] : '
iptables -A LOG_DROP -j DROP
iptables -A FORWARD -j LOG_DROP
iptables -A INPUT -j LOG_DROP
iptables -A OUTPUT -j LOG_DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT
iptables -A OUTPUT -d 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -i ppp0 --protocol udp --source-port 53 -j ACCEPT
iptables -A OUTPUT -o ppp0 --protocol udp --destination-port 53 -j ACCEPT
iptables -A INPUT -i ppp0 --protocol tcp --source-port 53 -j ACCEPT
iptables -A OUTPUT -o ppp0 --protocol tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -i ppp0 --protocol tcp --source-port 80 -m state --state ESTABLISHED -j LOG_ACCEPTLa première ligne pour accepter ce qui entre sur notre interface ppp0 sur le port 80 (le port http) si c'est une connection déjà établie, la seconde pour accepter ce qui sort sur ppp0 sur le port 80 si c'est une nouvelle connection ou si c'est une connection déjà établie.
iptables -A OUTPUT -o ppp0 --protocol tcp --destination-port 80 -m state --state NEW,ESTABLISHED -j LOG_ACCEPT
Pour autoriser le ssh, il faut préciser le port 22; pour autoriser l'irc, le port 6667 (ou celui que vous utilisez pour vous connecter à votre serveur); pour le smtp (envoi d'emails), le port 25; pour le pop3 (réception d'emails), le port 110; pour le imap (réception d'emails), les ports 143 et 220 (imap3) ; pour le cvs, le port 2401 ; pour le https, le port 443. De manière générale, le numéros de port se trouvent dans /etc/services.
modprobe ip_conntrack_ftpEnsuite, il faut taper les commandes suivantes :
# éventuellement : modprobe ip_nat_ftp
iptables -A INPUT -i ppp0 -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPTCela pour que la connection puisse s'établir. Ensuite (et c'est la qu'on a besoin de ip_conntrack_ftp) :
iptables -A OUTPUT -o ppp0 -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPTPour que serveur puisse établir la connection pour les données (en mode actif). Et enfin :
iptables -A OUTPUT -o ppp0 -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPTPour que le serveur puisse établir la connection pour les données (en mode passif). Ici aussi ip_conntrack_ftp est nécessaire.
iptables -A OUTPUT -o ppp0 -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -F FORWARDet enfin, cacher les machines forward-ées par le firewall :
iptables -A FORWARD -j ACCEPT
iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADESur chaque machine devant être cachée par le firewall (ou devant partager la connection avec la machine qui est connectée à internet), il faut ajouter une route par defaut :
route add default gw 192.168.1.1Si la machine connectée à internet a comme ip : 192.168.1.1. Il suffit avec une redhat/mandrake d'éditer :
/etc/sysconfig/networket d'ajouter dedans :
GATEWAY=192.168.1.1puis de redémarer le réseau :
/etc/rc.d/init.d/network restart
Pour cet exemple, le firewall aura la connexion à Internet (interface eth2) et disposera de 2 pattes sur des réseaux privés (eth0 et eth1) :
____ eth1 .-> ---+------+------+---La classe d'adresse IP 192.168.2.0 correspond au réseau interne sur l'interface eth1.
_/ \_ ____ 3128/ [PC1] [PC2] [PC3]
( ) eth2| |<--' réseau local 198.168.2.0
(INTERNET)<--->|Fire|
(_ _) ppp0|wall|
\____/ |____|<--. DMZ serveurs 198.168.1.0
eth0\ [WEB] [NEWS] [FTP]
'-> ---+------+------+---
ASCIIArt (c) Jice
Go !
Fichier de chargement /etc/init.d/firewall :
#!/bin/bash
# # Lancement du script de Firewall # Arnaud de Bermingham . /etc/init.d/functions RETVAL=0 # Fonction pour le lancement du firewall
# Fonction pour arrêter le firewall (on flush)
case "" in
exit |
C'est tout simple non ?
#!/bin/sh
# # Script pour vider les règles iptables # Arnaud de Bermingham # duracell@apinc.org #
#
#
#
iptables -X
# Message de fin
|
Bon, on va enfin commencer les choses sérieuses : le script du firewall :)
Et voilà ! le firewall de compèt' est prêt et fonctionnel.
Ceci était bien évidemment un exemple, vous pouvez dès
à présent préparer votre propre firewall personnalisé
!
Vous pouvez l'adapter à vos besoins, votre connexion vers internet
(par ADSL par exemple), etc.
Installation d'un firewall basé sur SmoothWall
Surfer sur Internet de manière sûre ? C'est possible, en réalisant avec un vieux PC un "mur de feu" (Firewall). Et c'est gratuit ! SmoothWall est en effet un firewall distribué sous licence GNU/GPL, avec son code source. Et c'est bien plus ! Interface web de management à distance (sécurisée : https), fichiers de log, NAT, DNS, Proxy, VPN, SSH, IPSEC sont aussi au menu... Le tout avec une abondante documentation, essentiellement en anglais...
Et si cela ne vous suffit pas, il existe aussi une version commerciale professionnelle de SmoothWall, avec plus d'options et un support professionnel, disponible auprès de SmoothWall Ltd.
A noter : lors de sa première connection, ce firewall enverra quelques informations non-personnelles comme le processeur utilisé, la taille de la RAM, la date et l'heure, la version de SmoothWall installée sur votre système aux auteurs. Les auteurs précisent que ce n'est pas un Spyware.
SmoothWall est manageable à distance, donc, une fois installé, il n'y a vraiment besoin que d'un PC, sans écran, sans souris, sans clavier... SmoothWall supporte les cartes réseaux les plus courantes (3com, Realtek, NE 2000...) et les modes de connexion internet les plus courants (Modem, ISDN, ADSL, USB ADSL, Ethernet).
Nota :Il est possible de définir trois zones réseaux différentes : verte (Zone totalement sûre : votre réseau local), orange (Zone partiellement sûre : DMZ, De-Militarised Zone, c'est sur cette branche du réseau que sera branché votre serveur HTTP par exemple) et rouge (Internet et ses pirates...). Ceci veut dire que vous pouvez avoir jusqu'à trois cartes réseaux sur votre Firewall : une verte sur laquelle seront reliés votre réseau local et votre serveur local de fichier par exemple, une orange sur laquelle sera relié votre serveur web Apache ou votre serveur de jeu en réseau, et la dernière (rouge) sur laquelle sera relié votre modem ethernet ADSL par exemple...
La configuration requise est vraiment minimale :
Ceci est le minimum pour faire fonctionner une connection par Modem. Pour une configuration multi-utilisateurs (partage de connexion) et l'ADSL, il faudra étoffer un peu cette configuration...
Enfin, SmoothWall est basé sur un noyau Linux 2.2.19, et sa mascotte est un ours polaire du nom de Smoothie...
!!! ATTENTION !!!
L'INSTALLATION DE SMOOTHWALL PARTITIONNE ET FORMATE COMPLETEMENT LE DISQUE DUR
DU SYSTEME SUR LEQUEL IL S'INSTALLE.
TOUTE LES DONNEES PRESENTES SUR CE SYSTEME SERONT DONC PERDUES IRREMEDIABLEMENT.
!!! ATTENTION !!!
Il est bien sûr conseillé de lire les documentations officielles
de SmoothWall pour avoir plus d'informations. Notamment la FAQ... ( j'ai bien
aimé l'humour british des chapitres "On Not Reacting Like A Looser"
et "Questions Not To Ask"...). C'est essentiel pour ne pas reposer
aux auteurs ou à la communauté SmoothWall des questions dont la
réponse figure déjà dans la documentation...
Nota :
Il est judicieux de brancher votre firewall sur un onduleur : le système
de fichier du noyau linux 2.2.19 est ext2 et n'est pas journalisé. Il
supporte très mal les reboot brutal...
Il faut d'abord télécharger l'image Iso (21 Mo environ) sur le site de SmoothWall, puis graver cette image sur un cdrom.
Nota :
Si votre bios n'accepte pas le boot sur cdrom, il est possible de créer
une disquette de boot (avec l'utilitaire rawritewin figurant dans le répertoire
dosutils du cdrom, sous Windows, et en sélectionnant l'image boot-1.0.img).
En fait c'est comme pour n'importe quelle distribution Linux... Il est même
possible de l'installer depuis un serveur ftp/http distant... Que demander de
plus !
Pour installer Smoothwall, Il faut insérer le cdrom dans votre lecteur puis rebooter la machine.Les étapes sont :
Nota :
Vous pouvez choisir la configuration de votre firewall : vert + modem, vert
+ orange + modem, vert + rouge, vert + orange + rouge... puis configurer chaque
carte réseau : pour une configuration constituée d'un modem relié
au port série du firewall et une carte réseau reliée par
un câble croisé à votre PC, choisir la configuration verte
(GREEN)
Conseils de configuration :
Nota :
L'utilisateur "root" a le control total du firewall
L'utilisateur "setup" peut réaliser la mise à jour du
firewall ou toute configuration post-installation
L'utilisateur "admin" peut changer les paramètres du firewall,
effectuer le contrôle journalier du firewall et des fichiers de log, changer
le mot de passe de l'utilisateur "dial", démarrer ou arrêter
un service
L'utilisateur "dial" a l'autorisation de lancer une connection à
Internet mais est configuré (ainsi que son mot de passe) par l'interface
web de management du firewall.
Une fois l'installation terminée, il faut redémarrer le firewall (après avoir retiré cdrom et disquette d'installation).
Votre firewall est alors autonome et peut être administré à distance par une interface web, à partir d'un poste relié au réseau vert, en vous connectant comme utilisateur "admin" :
https://192.168.1.1:445 (accès sécurisé)Il est alors nécessaire de télécharger les patchs disponibles, et cela peut se faire à partir de l'interface d'administration.
Et voilà ! Maintenant, vous pouvez surfer tranquille... ou presque ! D'après ses auteurs, SmoothWall n'a pas de failles de sécurité connues...
Il y a aujourd'hui deux possibilités de travail, en local (local work) ou à distance (remote work). Ce dernier est permis par l'utilisation du réseau, qu'il soit local (LAN) ou réellement éloigné, comme par Internet (WAN). De nombreux outils ont été fournis pour utiliser la capacité du réseau. Échanger, copier, utiliser des shells à distance. Les noms de ces outils sont respectivement FTP, rcp, telnet, etc... Bien que ces outils, utilisés pendant des années et même encore aujourd'hui dans certaines entreprises, soient très pratiques, ils comportent une faiblesse importante. Leurs transactions sont transmises en clair via le réseau. De ce fait, l'informatique devenant ouvert à un grand nombre, n'importe quelle personne mal intentionnée peut être en mesure d'observer ce que vous faîtes, allant même jusqu'à subtiliser vos données personnelles et mots de passe.
Le problème par la pratique
Pour pouvoir appuyer cette notion de non-confidentialité, nous allons regarder ce qui se passe
lors de l'établissement d'une connexion d'une session telnet. Le logiciel utilisé pour tracer les
connexions est ethereal.
Établissons la connexion sur un serveur telnetd fonctionnant sous GNU/Linux. Après quelques
échanges de paquets, nous obtenons la bannière d'accueil :
on constate que la connexion s'effectue sur le port 23 (en 22 et 23 dans la trame).
Les données quant à elles commencent clairement en 42, avec la bannière d'accueil :
Debian GNU/Linux testing/unstable centaur
Les données ont été envoyées en clair et la bannière permet de définir le système d'exploitation sur lequel nous sommes accueillis. Continuons notre étude, la demande d'identification est proposée par le système distant :
Il faut maintenant se faire reconnaître auprès du système. Nous supprimerons tout echo local doublant l'envoi de caractères, un pour le système distant et un pour voir ce que nous écrivons. Il en résulte une suite d'échange avec notre interlocuteur :
Nous envoyons notre identifiant à la machine distante, les trames ne sont pas utilisées
à l'économie puisque chaque paquet contient seulement un et un seul caractère comme
données (data). On retrouve ici notre identifiant, jop, envoyé pour nous loguer. Ce qui est inquiétant,
c'est que la même chose va également se produire pour notre mot de passe censé être privé et inviolable.
Le mot de passe est ici clairement exprimé. On peut lire bobo, la dernière trame transmet un retour chariot.
Nota : Notre étude ne se portant pas sur le service telnet, nous ne rentrerons pas sur le détail des transmissions et considérons que ces quelques remarques suffisent pour notre étude.
De la même manière, tout comme on vient de vous dérober votre mot de passe, on peut récupérer vos conversations, vos fichiers. La confidentialité est rompue, la porte est ouverte à l'insertion non-chalente de personnes non autorisées dans le système...
Afin de ne plus être ouvert au monde entier, nous avons la possibilité de chiffrer nos échanges. Pour ce faire, nous allons installer un client ssh, Openssh. Client libre et gratuit. Par la même occasion, vous pourrez installer le serveur, afin que votre ordinateur puisse aussi être contacté par d'autres utilisateurs, vous permettant de délivrer des services sécurisés.
Nous allons continuer notre étude dans le cadre de ce logiciel, libre à vous d'adapter à vos préférences par la suite, sachant que le principal est ici transcrit.
Afin de mieux comprendre le comportement et l'utilité de chaque programme, décomposons les différents paquets ainsi que l'usage fait des exécutables.
Mémo |
---|
sshd : Serveur ssh |
scp : Copie distante sécurisée |
ssh-keygen : génération de clefs d'authentification, management et conversion |
sftp : Transfert sécurisé de fichiers |
slogin/ssh : Client ssh |
ssh-add : Ajoute les identités DSA ou RSA à l'agent d'authentification |
ssh-agent : Agent d'authentification |
ssh-keyscan : Recueille les clefs publiques ssh |
Nous traiterons chacune de ces applications afin de comprendre dans quels conetxte elles peuvent être utilisés.
Le client ssh opère selon un ordre défini :
Le fichier ssh_config :
Ce fichier représente la configuration du client ssh.
#$OpenBSD: ssh_config,v 1.15 2002/06/20 20:03:34 stevesk Exp $
# Ceci est le fichier de configuration par défaut des clients ssh du système. Voir
# ssh_config(5) pour de plus amples informations. Ce fichier fournit les paramètres par défaut
# pour les utilisateurs, ces valeurs peuvent être changées pour chaque utilisateur dans leur propre
# fichier de configuration ou sur la ligne de commande.
# Les données de configuration sont analysées comme ci-dessous :
# 1. Les options de la ligne de commande
# 2. Le fichier spécifique de l'utilisateur
# 3. Le fichier par défaut
# N'importe quelle valeur de configuration est uniquement changée la première fois qu'elle est mise.
# Ainsi, les définitions spécifique d'hôte doivent être au début du fichier de configuration
# et les options par défaut à la fin.
# Options par défaut
# Pour que les options soient prises en compte, il vous faut enlever le dièse précédent la ligne.
# Host permet de spécifier que la configuration qui suit concerne un ou plusieurs hôtes précis.
# Il est possible d'employer des caractères joker tels que * ou ?.
# Host *
# Specifie si la connexion à l'agent d'authentification doit être renvoyé vers la machine distante
# ForwardAgent no
# Autorise ou non la redirection du serveur graphique
# ForwardX11 no
# Autorise la méthode d'authentification par Rhosts. Peu sûr.
# RhostsAuthentication no
# Autorise la méthode d'authentification par Rhosts sur du RSA. Ne fonctionne que dans la version
# première du protocole et nécessite un setuid root. De préférence à ne pas utiliser.
# RhostsRSAAuthentication no
# Méthode d'authentification par RSA, ne fonctionne qu'avec la première version du protocole. Il
# faut que le fichier identity existe.
# RSAAuthentication yes
# Autorise la connexion par mot de passe, comme on pouvait la trouver dans rlogin ou telnet.
# PasswordAuthentication yes
# Si l'indicateur est positionné à yes, la demande de passephrase ou de mot de passe sera annulée.
#Cette option est utilisée dans le cas où seul des scripts interviennent et où il n'y a pas d'utilisateur
# présent pour insérer le mot de passe.
# BatchMode no
#Vérification de l'adresse IP de l'hôte qui se connecte dans le fichier known_hosts
# CheckHostIP yes
#Cette option permet de gérer l'ajout et le changement des clefs hôtes dans known_hosts.
#Si la clef a changé, la connexion vous sera refusée, vous indiquant le motif.
# StrictHostKeyChecking ask
#Localisation des fichiers identity, id_rsa, id_dsa
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
#Port de connexion à l'hôte distant.
# Port 22
#Version des protocoles supportés et désirés. Ici, on préfèrera employer la deuxième version si
#elle est disponible.
# Protocol 2,1
#Protocole de chiffrement (ssh v1) et protocoles disponibles par ordre de préfèrerance (ssh v2).
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#Caractère d'échappement.
# EscapeChar ~
Il existe différentes options pour se connecter à un hôte via ssh. Libre à vous de les utiliser ou non.
-l login : Identifiant de l'utilisateur.
-v -vv -vvv : Mode verbeux, permet d'obtenir les messages de debugage plus ou moins complets (plus il y a
de v, plus vous obtenez d'information, le nombre maximum étant 3).
-1 ou -2 : version de ssh employé. Il est déconseillé d'employer la version 1 du protocole. Bien qu'aucun
exploit public ne circule, les faiblesses cryptographique du protocole ont été prouvée. De plus, la version 2
est reconnue par l'IETF
-p port : Numéro du port distant
Exemple d'utilisation :
ssh -vv -l utilisateur -p port -(1|2) hôte
ou
ssh utilisateur@hôte
L'hôte distant doit avoir un serveur ssh, nommé sshd, qui permet la connexion.
Ssh s'appuie sur des algorithmes à paire de clefs, ce qui signifie que vous disposez d'une clef publique, disponible pour tout un chacun et une clef privée dont vous gardez jalousement l'entrée. Ce système va nous permettre de nous identifier auprès des hôtes que nous désirons contacter. Il nous faut au préalable créer le trousseau.
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/jop/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/jop/.ssh/id_dsa.
Your public key has been saved in /home/jop/.ssh/id_dsa.pub.
The key fingerprint is:
4a:0b:3b:eb:ed:05:47:56:cb:23:28:d3:d7:81:69:08
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/jop/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/jop/.ssh/id_rsa.
Your public key has been saved in /home/jop/.ssh/id_rsa.pub.
The key fingerprint is:
52:65:28:9a:8b:64:cb:b7:6e:70:75:10:d9:0a:01:d9
Pour les deux algorithmes (dsa, rsa), le système nous demande dans quel fichier nous désirons sauvegarder la clef. Les fichiers par défaut semblent une bonne solution. Par la suite, une passphrase nous est demandée. Celle-ci est un « mot de passe amélioré », car non limité à un mot ou une petite suite de caractères. Il faut cependant prendre des précautions, car en cas de perte de la passphrase, vous ne pourriez plus vous authentifier en tant que propriétaire authentique.
Nous allons maintenant voir trois méthodes de connexion via ssh.
La première des méthodes, la plus connue et la plus usitée, reposant sur le modèle employé par rlogin ou rsh; l'hôte distant demande un mot de passe pour s'assurer de votre identité.
$ ssh -p 222 -l root 192.168.0.1
The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established.
RSA key fingerprint is 74:4c:57:fd:c2:2c:0d:c3:3f:09:01:7d:e8:b7:21:24.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts.
root@192.168.0.1's password:
Last login: Thu Dec 26 03:37:03 2002 from centaur
$
Je me connecte au port 222 sur une machine de mon réseau local, demandant de m'identifier comme root. La machine n'est pas connue dans mon fichier known_hosts. Ce fichier contient les clés hôte DSA des serveurs SSH auxquels l'utilisateur s'est connecté. Cette méthode de connexion est intéressante, mais minimise les capacités que vous avez avec ssh. Pour des connexions telles que vers un serveur CVS, un tunnel pour votre courrier, il serait fastidieux de s'authentifier à chaque fois par ce moyen.
Puisque nous utilisons des algorithmes à paire de clefs (rsa, dsa), c'est à dire composée d'une clef secrète
et d'une clef publique, il faut bien que cela nous serve à quelque chose. Nous allons donc automatiser
la connexion. Pour ce faire, votre hôte contient un fichier authorized_keys dans le répertoire .ssh où
vous vous connectez (en général un home directory). Il suffit de copier l'identifiant ou les identifiants
de vos clefs publiques pour que vous soyez reconnu du serveur.
Attention, il faut que PubkeyAuthentication soit positionné à yes dans vos fichiers de configuration.
Pour insérer ma clef, j'ai plusieurs méthodes à ma disposition. Je peux employer des moyens
conventionnels tels que le ftp ou le mail (à l'administrateur par exemple), ou je peux le faire au moyen
d'outil sécurisé. Puisque c'est notre sujet, profitons en pour donner un exemple de scp sur lequel nous
reviendrons ultérieurement.
$scp .ssh/id_dsa.pub jop@scipc-jpg:/home/jop/.ssh/dsa2connex
Warning: Permanently added 'scipc-jpg' (RSA) to the list of known hosts.
jop@scipc-jpg's password:
id_dsa.pub 100% |*****************************| 613 00:00
Mon fichier est maintenant copié sur l'hôte distant, il me reste à inclure la clef dant le fichier authorized_keys.
Une simple commande suffira :
$ cat dsa2connex >>authorized_keys
Je peux maintenant me connecter, l'hôte distant me reconnaît. Je peux me connecter sans mot de passe et avec une passphrase si j'en ai désiré une.
Nous savons maintenant nous connecter à un hôte distant connaîssant notre identité par l'intermédiaire de notre clef publique. Nous avons vu précédement que nous étions libre de mettre ou non une passphrase afin de chiffrer notre identification et compliquer l'usurpation qui pourrait en être faite [mode parano on]. S'il paraît fastidieux d'insérer un mot de passe à chaque connexion, cela l'est d'autant plus lorsque l'on doit rentrer une phrase entière. L'agent ssh est là pour nous simplifier la vie. Lancé au début de la session (terminal ou graphique), il retient la passphrase le temps où ssh-agent sera actif (le temps d'une session).
Pour une session en mode terminal :
$ssh-agent screen
$ssh-add
Après avoir lancé l'agent ssh, on ajoute la passphrase à l'agent par l'intermédiaire de ssh-add ; tous les hôtes distants disposant de votre clef publique ne vous demanderons alors plus la passphrase puisque gérée par l'agent ssh.
De même, en mode graphique :
$ssh-agent startx
Il vous suffit ensuite d'ouvrir un terminal et de taper
$ssh-add
L'agent sera actif pour toutes les applications utilisées en mode graphique.
Une dernière méthode consiste à lancer l'agent-ssh qui fournit un certains nombre de variables à exporter,
puis demander l'action de ssh-add :
$ssh-agent
On récupère les variables fournies et on les exporte :
$SSH_AUTH_SOCK=/tmp/ssh-XXy0hiXW/agent.2019; export SSH_AUTH_SOCK;
$SSH_AGENT_PID=2020; export SSH_AGENT_PID;
$echo Agent pid 2020;
On ajoute :
$ssh-add
Pour tuer l'agent ssh, il suffit de faire :
$ ssh-agent -k
unset SSH_AUTH_SOCK;
unset SSH_AGENT_PID;
echo Agent pid 2020 killed;
Invalidité des clefs d'un hôte connu
Comme nous l'avons vu précédement, lors de votre connexion, il vous est possible d'enregistrer l'emprunt (fingerprint) fournit par le serveur distant. Dans le cas où celle-ci serait modifiée, vous seriez immédiatement prévenu. Cela peut découler de quatre choses :
La seule solution fiable demande de contacter l'administrateur en question et lui demander ce qu'il en est. Dans la pratique, peu de personnes usent de cette assurance de sécurité.
$ ssh 127.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
8b:d5:26:a3:79:ed:25:0f:3b:6f:fe:30:1f:ed:89:ae.
Please contact your system administrator.
Add correct host key in /home/jop/.ssh/known_hosts to get rid of this message.
Offending key in /home/jop/.ssh/known_hosts:13
RSA host key for 127.0.0.1 has changed and you have requested strict checking.
Host key verification failed.
$
Comme nous avons pu le voir plus haut, ssh fournit un outil de copie sécurisée en standard, sous le nom de scp pour SecureCoPy. Il remplace son ancêtre rcp. Son usage est très simple :
scp hôte_d_ou_je_veux_copier:source_copie hôte_destination:cibleLorsque l'hôte correspond à la machine où vous vous trouvez, il n'est pas nécessaire de l'inscrire.
$scp iptables scipc-jpg:/home/jop/download
iptables 100% |*****************************| 27654 00:00
Vous pouvez également faire des copies récursives, comme nous le ferions avec n'importe quel autre utilitaire de copie.
$scp -r download scipc-jpg:/home/jpg/dl
img2.png 100% |*****************************| 277 00:00
internals.pl 100% |*****************************| 188 00:00
labels.pl 100% |*****************************| 271 00:00
images.pl 100% |*****************************| 624 00:00
portscanning.css 100% |*****************************| 891 00:00
index.html 100% |*****************************| 56753 00:00
Tout comme on peut copier des fichiers à distance par l'intermédiaire de scp, il est également possible
de transférer des fichiers par l'intermédiaire d'un ftp sécurisé nommé SecureFTP.
Bien que l'outil soit encore trivial (pas de reprise de chargement en cas de coupure, pas d'indication du temps
restant, pas de telechargement ou de chargement réccursif, ...), il vous permettra de faire toutes les manipulations
basiques disponibles sur un ftp non sécurisé.
cd path lcd path chgrp grp path chmod mode path chown own path help get remote-path [local-path] lls [ls-options [path]] ln oldpath newpath lmkdir path lpwd ls [path] lumask umask mkdir path put local-path [remote-path] pwd exit quit rename oldpath newpath rmdir path rm path symlink oldpath newpath version !command ! ? |
Change le répertoire distant vers 'path' Change le répertoire local vers 'path' Change le groupe de fichier 'path' par 'grp' Change les permissions du fichier 'path' à 'mode' Change le propriétaire du fichier 'path' par 'own' Affiche ce message d'aide Télécharge le fichier Affiche le listing du répertoire local Crée un lien symbolique du fichier distant Crée un répertoire local Affiche le répertoire courant Affiche le listing du répertoire distant Positionne l'umask local à 'umask' Crée le répertoire distant Charge le fichier Affiche le répertoire courant distant Quitte sftp Quitte sftp Renomme le fichier distant Supprime le répertoire distant Supprime le fichier distant Crée un lien symbolique du fichier distant Affiche la version de sftp Exécute la 'commande' dans un shell local Sort vers un shell local Affiche ce message d'aide |
$ sftp jop@scipc-jpg
Connecting to scipc-jpg...
$sftp> lpwd
Local working directory: /home/jop
$sftp> lcd download
$sftp> lpwd
Local working directory: /home/jop/download
$sftp> put iptables
Uploading iptables to /home/jop/iptables
$sftp> quit
$
Tout au long de cet article, vous avez pu découvrir des applications connues, il nous manque cependant l'exportation des applications distantes. En effet, à l'aide de telnet, vous pouviez utiliser un logiciel non présent sur votre machine, mais présent sur l'ordinateur distant. Il suffisait de taper :
$export DISPLAY=mon_adresse:0.0Comme par magie, l'application arrivait plus ou moins rapidement selon votre connexion sur votre écran. C'est ce qu'on appelle du Xforwarding. L'avantage une fois de plus d'utiliser ssh réside dans la connexion chiffrée et l'impossibilité à un agresseur éventuel de lire ce que vous faîtes via le réseau.
$ssh jop@scipc-jpg geditDans l'exemple donné, nous demandons d'ouvrir la connexion ssh pour inscrire Gedit à l'intérieur
(bloc-notes de Gnome). En fermant Gedit, nous fermerons la connexion ssh.
Pour que cela soit réalisable, n'oubliez cependant pas d'activer l'option X11Forwarding dans les fichiers
de configuration.
Toujours dans la même idée de tunneler des applications, ssh vous permet d'encapsuler des protocoles. Cela est très intéressant lorsque vous avez recours à des protocoles tels que smtp, pop, ... Vous courriers, pour l'exemple, ne serons plus à l'indiscrétion de vos fournisseurs, ni des fouines du réseau.
ssh -L port_local:hôte_distant:port_distant nom_utilisateur@nom_hôte Mettons que je veuille encapsuler les ports 25 (smtp) et 110 (pop) $ssh -L 2025:scipc-jpg:25 jop@scipc-jpgIl vous suffit de configurer votre logiciel de messagerie favori aux ports 2025 pour le smtp et 2110 pour le pop pour recevoir correctement votre courrier, et ce de manière sécurisée.
Georges Orwell écrivait 1984 bien des années plus tôt et nommait un ennemi invisible Big Brother en avançant le slogan « Big Brother is watching you ». Non loin de cette réalité, nous avons atteint avec Internet l'ouverture de l'outil informatique aux masses. Ne pouvant être en mesure de s'assurer que personne ne s'introduit dans votre intimité, le conseil reste d'être prudent avec vos données sensibles et personnelles. Oubliez donc les vieux protocoles non sécurisés et travaillez en toute sécurité...
Je remercie tout particulièrement Anne pour le temps qu'elle a passé à la relecture de cet article ainsi qu'à sa correction et sa mise en forme.
Un firewall totalement invisible
Un pont est un équipement réseau qui permet de relier deux sous-réseaux de manière totalement
transparente. Pour ceux qui connaissent un peu le modèle OSI, il effectue une interconnexion
au niveau 2, c'est-à-dire qu'il travaille au niveau des trames.
En gros, un pont écoute toute l'activité de chaque sous-réseau auquel il est connecté, les stocke
en mémoire et les redirige vers le (ou les) sous-réseaux concernés.
Il n'a pas besoin d'adresse MAC (donc pas besoin d'adresse IP non plus) pour fonctionner,
et est donc totalement indétectable.
Réseau 1 -------| eth0 Pont eth1 |-------- Réseau 2
Un pont filtrant, lui, est un pont comme décrit plus haut, mais va en plus appliquer des régles de filtrage (firewalling) sur les trames qui vont le "traverser". On vas donc obtenir un firewall qui ne posséde pas d'adresse réseau, donc indétectable. Difficile pour un "pirate" d'attaquer une machine qui n'est pas visible sur un réseau, et qui ne permet aucune connexion réseau car elle n'as pas d'adresse réseau.
Un pont filtrant a aussi un autre avantage : il s'interconnecte de façon totalement transparente sur votre réseau, vous n'avez absolument pas besoin de modifier la topologie de votre réseau (routage, passerelle,...) pour l'ajouter. Il se comporte en gros comme un simple cable réseau intelligent qui filtrerait le traffic qui le traverse.
Tout d'abord vous devez avoir un ordinateur avec deux cartes réseaux pour pouvoir interconnecter
/filtrer les deux réseaux.
Le support du "pont" est intégré à partir du kernel 2.4. , mais vous devez prendre le dernier kernel
à jour (2.4.19 lors de la rédaction de ce document) pour avoir le meilleur support du pont.
Vous devez aussi appliquer un patch kernel, pour ajouter le support du pont à iptable
(pour pouvoir filtrer les paquets qui vont traverser le pont):
bridge-nf-0.0.7-against-2.4.19.diff
Ceci est le patch pourle kernel 2.4.19. Si lors de la lecture de ce document, le dernier kernel
n'est plus le 2.4.19, récupérez alors le patch pour la version du kernel actuelle que vous
trouverez ici:
Site officiel "pont filtrant" pour Linux
Appliquez alors le patch à votre kernel, pour le 2.4.19 par exemple, allez dans le répertoire
des sources du kernel et faites un :
patch -p1 < bridge-nf-0.0.7-against-2.4.19.diff
Recompilez alors votre kernel, en activant dans la partie Network Options :
Network Packet Filtering (remplace ipchains) (em module ou en natif)
Passez en module (ou en natif) toutes les options de :
IP: Netfilter Configuration
et activer aussi le support du pont :
[*] 802.1d Ethernet Bridging
A partir de ce moment, notre machine peut faire office de pont, et filtrer les paquets du pont.
Il vous faut aussi les utilitaires de configuration, c'est à dire les programmes pour configurer
le pont lui-même, que vous téléchargez ici:
bridge-utils-0.9.6.tar.gz
Comme avec n'importe quelle source de programmes, vous "détarballez" et compilez le tout :
tar zxvf bridge-utils-0.9.6.tar.gz
cd bridge-utils
./configure
make
make install
Comme nous l'avons dit plus haut, le pont en lui-même n'a pas besoin d'adresse IP (ni même
d'adresse MAC) pour fonctionner. Donc dans un premier temps, nous enlevons toute adresse IP des
deux cartes réseaux qui constituent notre pont, et les passons en mode "promisc" pour
qu'elles puissent écouter tout le réseau et donc transférer les trames réseaux d'un réseau à l'autre.
ATTENTION Si vous etes en telnet ou ssh sur cette machine, la connection va
être coupée, faites donc ces manipulations en console sur la machine elle-même.
ifconfig eth0 0.0.0.0 promisc
ifconfig eth1 0.0.0.0 promisc
Maitenant nous mettons en place le pont lui-même, c'est-à-dire nous donnons un nom au bridge
lui-même (mon-pont) et déclarons les interface réseaux qui vont servir au pont (eth0 et eth1):
brctl addbr mon-pont
brctl addif mon-pont eth0
brctl addif mon-pont eth1
Pour certains équipement actifs (switch, routeur, etc) le pont doit se "déclarer" pour que
tout fonctionne bien. Si la connexion entre les deux réseaux ne fonctionne pas, essayez ces
commandes (mais dans 90% des cas cela n'est pas nécessaire) :
brctl sethello mon-pont 1
brctl setfd mon-pont 4
Pour vérifier que tout marche, normalement toute machine du réseau1 doit pouvoir pinguer toutes
les machines du réseau2 et inversement. Et si vous faites un "traceroute" d'une machine du réseau1
vers le réseau2 (ou inversement), vous ne verrez PAS le pont. Il se comporte là comme un simple
"fil" reliant les deux réseaux.
Par contre, vous avez peut-être besoin d'accéder en réseau à la machine qui sert de pont
(pour faire du ssh ou autre), il faut donc lui donner une adresse IP. Mais comment faire étant donné
que les deux interfaces réseaux servent au pont ? Il y a deux solutions :
- Soit vous ajoutez une 3éme carte réseau a cette machine, que vous configurez normalement, avec une adresse IP etc....
- Soit vous configurez le pont lui-même AVEC une adresse Ip. Le pont se comporte donc exactement
comme une interface réseau et pour lui affecter une adresse IP, on le fait de la même manière
que pour une interface "normale", par exemple :
ifconfig mon-pont 192.168.1.50 netmask 255.255.255.0
Et si vous refaites des traceroute, vous ne le verrez toujours PAS sur le résultat du traceroute.
Placez toute ces commandes dans un fichier de démarrage de votre machine bien sur, pour ne pas
avoir à tout retaper à chaque reboot.
Maitenant que notre pont est opérationnel, il ne reste plus qu'à lui appliquer les règles de
filtrage que l'on souhaite. Comme le traffic réseau ne fait QUE le traverser, les règles de filtrage
ne sont que des règles de forwarding bien sûr (pas de INPUT ni OUPUT). On applique les règles
comme pour un firewall de type "gateway" sauf la chaîne "FORWARD".
Je vous donne ici un exemple de filtrage (à vous d'adapter, suivant votre réseau, vos applications
- voir la rubrique iptable pour cela).
Appeler ce fichier rc.firewall par exemple et lancez-le au boot de la machine.
#!/bin/bash # Script Firewalling exemple PATH="/usr/sbin:$PATH" # On vide les chaines iptables -F #On efface toute les chaines utilisateurs iptables -X #Notre réseau que l'on sécurise: LANS="192.168.0.0/255.255.255.0" # Adresse de notre serveur web et ftp WEB="192.168.0.10" FTP="192.168.0.20" #On créé la chaine KEEP_STATE pour suivre l'état des connexions iptables -N KEEP_STATE iptables -F KEEP_STATE #On drop les paquets non valides iptables -A KEEP_STATE -m state --state INVALID -j DROP #On accepte les paquets provenant bien #d'une connexion et dont l'etat est correct iptables -A KEEP_STATE -m state --state RELATED,ESTABLISHED -j ACCEPT #On drop et log tout paquet dans un état incorect et #qui permet des scans/Denial of service iptables -A FORWARD -p tcp --tcp-flags ALL FIN,URG,PSH \ -m limit --limit 5/minute \ -j LOG --log-level notice --log-prefix "NMAP-XMAS: " iptables -A FORWARD -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP iptables -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN \ -m limit --limit 5/minute \ -j LOG --log-level notice --log-prefix "SYN/FIN: " iptables -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST \ -m limit --limit 5/minute \ -j LOG --log-level notice --log-prefix "SYN/RST: " iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -A FORWARD -p tcp --tcp-flags RST RST,ACK \ -m limit --limit 5/minute \ -j LOG --log-level notice --log-prefix "RST/ACK: " iptables -A FORWARD -p tcp --tcp-flags RST RST,ACK -j DROP #On passe les paquets valides dans notre chaine KEEP_STATE iptables -A FORWARD -j KEEP_STATE #On permet le controle de "time exceeded" #et de "port not found" sur notre réseau iptables -A FORWARD -p udp -s $LANS --dport 11 -j ACCEPT iptables -A FORWARD -p udp -s $LANS --dport 3 -j ACCEPT #On permet le http sur notre serveur web iptables -A FORWARD -p tcp -d $WEB --dport 80 -j ACCEPT #On permet le Ftp sur notre serveur FTP iptables -A FORWARD -p tcp -d $FTP --dport 21 -j ACCEPT # Tout notre réseau a le droit de "sortir" vers l'internet iptables -A FORWARD -s $LANS -j ACCEPT # Tout ce qui n'est pas déclaré doit etre bloqué iptables -A FORWARD -j DROP
par Anne
Où comment utiliser xinetd pour sécuriser encore plus votre pingouin préféré
Cet article a pour objectif d'expliquer le fonctionnement et la configuration du super démon xinetd. Pourquoi particulièrement celui-ci ? Parce qu'il est utilisé fréquemment pour l'accès à nombre de services réseau et devient un outil non négligeable de sécurisation de celui-ci (en plus d'un bon firewall bien sûr). Cet article n'a pas pour objectif d'être complètement exhaustif mais de présenter les configurations les plus courantes de xinetd. Pour plus d'infos, consulter le man (on s'en serait douté ;) )
Selon la distribution vous trouverez soit un démon inetd, soit un démon xinetd. La tendance est tout de même d'utiliser de plus en plus ce dernier.
Dans l'absolu, inetd et xinetd ont le même rôle, à savoir de piloter l'accès à un ou plusieurs services réseaux. Ils agissent comme une standardiste. Ils reçoivent des requêtes de clients, extérieurs pour la plupart, qui demandent un accès à un service réseau déterminé (ex : ftp, telnet, ssh...). Le super démon va, en fonction des instructions qu'on lui aura données (fichiers de configuration) transmettre ou rejeter l'appel.
inetd, jusque là utilisé, permettait, grâce au fichier /etc/inetd.confet au wrapper tcpd, de paramétrer l'accès aux services en l'autorisant/interdisant totalement ou partiellement. (cf. les fichiers /etc/hosts.allow et /etc/hosts.deny).
xinetd apporte des fonctionnalités bien plus importantes et permet d'affiner les paramétrages d'accès aux services. On citera dans le désordre :
Si votre distribution préférée utilise inetd et qu'après avoir eu le courage de lire cet article, vous souhaitez utiliser xinetd, il existe un script qui vous permettra de transformer le fichier inetd.conf en fichier xinetd.conf, utilisable par xinetd
Ce script, xconv.pl, est un script perl fourni avec xinetd. Attention si ce script peut vous donner la structure générale du fichier de configuration, il ne vous permettra pas de profiter des apports de xinetd. Rien de tel qu'un bon éditeur de texte et ce qui suit ci-dessous.
On entre dans le vif du sujet :). Pour configurer xinetd, vous aurez à connaître la syntaxe, commune de /etc/xinetd.conf et, selon les cas de figure, les fichiers situés dans le répertoire /etc/xinetd.d.
L'arborescence de la configuration de xinetd est relativement simple. On en rencontre 2 types :
C'est ce deuxième cas de figure qui est le plus couramment utilisé dans les distributions.
Le fichier de configuration de xinetd est un ensemble d'une ou plusieurs directives dont la
syntaxe est la suivante :
service nom_du_service
{
...
}
Le nom de la directive est soit defaults et la configuration porte alors sur l'ensemble des
services gérés par xinetd, soit le nom d'un des services géré par xinetd.
A l'intérieur de chacune de ces directives on trouvera des attributs, un par ligne, écrits de la
manière suivante :
<attribut> <assignement> <valeur> <valeur> ...
Les attributs seront détaillés plus loin. Les assignements peuvent prendre différentes valeurs :
=, -=, +=.
Exemple :
root@pingu# cat /etc/xinetd.d/telnet
service telnet
{
...
server = /usr/sbin/in.telnetd
...
}
avec :
attribut : server
assignement : "="
valeur : /usr/sbin/in.telnetd
Pour reprendre l'arborescence de xinetd et les 2 cas de figure exposés ci-dessus, on obtiendra les fichiers suivants :
un seul fichier de configuration | un fichier de configuration par service |
/etc/xinetd.conf defaults { ... } service service1 { ... } service service2 { ... } |
/etc/xinetd.conf defaults { ... } /etc/xinetd.d/service1 service service1 { ... } /etc/xinetd.d/service2 service service2 { ... } |
Nous allons lister les différents attributs utilisables pour configurer xinetd. Certains sont facultatifs et vous permettent d'affiner son rôle. Toutefois d'autres sont obligatoires et s'ils ne sont pas présents, empêcheront tout ou partie des services de fonctionner.
Avant de les lister, petit point de vocabulaire : on distingue les services dits internes et externes. A quoi ? A xinetd bien sur :). Les services internes, comme servers, services, xadmin sont des services propres à xinetd qui fournissent des informations sur le fonctionnement du super-démon. Il vaut mieux ne pas utiliser ces services car ils exposent la machine inutilement et les fichiers de log de xinetd vous fourniront les mêmes informations.
Voilà donc les attributs que vous devrez utiliser :
Attribut | Définition |
socket-type | type de socket utilisé pour le service : dgram s'il utilise le protocole UDP, stream s'il utilise le protocole TCP - consulter le fichier /etc/services pour avoir l'information. |
user | identité sous laquelle le service sera lancé |
server | chemin et nom du serveur |
wait | Définit le comportement du service dans le traitement des threads : yes pour un service mono-thread (une connexion simultanée par service et une seule), no pour un service multithread (possibilité d'avoir plusieurs connexions simultanées au service) |
protocol | Protocole utilisé par le service. Si rien n'est précisé, c'est le protocole spécifié dans le fichier /etc/services qui sera utilisé. |
rpc_version rpc_number |
Ne concerne que les services basés sur les RPC (exemple : NFS) |
port | Port associé au service. Là encore, s'il n'est pas précisé, c'est le port spécifié pour le service dans le fichier /etc/services. |
Une des fonctionnalités de xinetd est de permettre d'affiner ce que vous voulez loguer et dans quel(s) fichier(s) vous voulez le loguer.
C'est l'attribut log_type qui va donner cette localisation. Il peut prendre 2 valeurs :
Outre la localisation des logs, il est possible également de paramétrer le contenu des logs. On utilisera les attributs log_on_success et log_on_failure qui, comme l'intitulé l'indique, listent ce qui sera logué en cas de succès et d'échec de l'accès au service. Les valeurs sont :
Les 4 valeurs sont utilisables avec l'attribut log_on_success. Seuls HOST et USERID sont utilisables avec log_on_failure.
Exemple :
service trucmuche
{
...
log_type = FILE /var/log/xinetd/trucmuche.log
log_on_success = PID USERID HOST DURATION
log_on_failures = HOST USERID
...
}
Dans ce cas de figure, le fichier de log du service trucmuche sera /var/log/xinetd/trucmuche.log. Les informations recueillies dans tous les cas seront l'adresse du client et son identité et en cas de succès, on aura également le PID du serveur et la durée de la session
Xinetd dispose de nombreux attributs complémentaires, facultatifs mais qui vont permettre d'en faire un outil de sécurisation des services réseaux et du système dans son ensemble. Ci-dessous, les principales fonctionnalités proposées.
Avec des attributs supplémentaires, vous allez pouvoir filtrer les clients qui vont pouvoir ou non se connecter à vos serveurs.
Filtrer des adresses : only_from = valeur [valeurs...].Vous pouvez bien sûr panacher les valeurs.
Exemple : configuration des accès ftp sur ma machine :
service proftpd
{
...
only_from = citrouille 192.168.1.0 lea-linux.org
...
{
Les seuls autorisés à utiliser mon serveur ftp seront : la machine "citrouille", les machines du réseau 192.168.1.0 et celles du domaine lea-linux.org.
Un attribut qui a également pour effet de filtrer les accès est no_access = valeur [valeurs...]. Il fonctionne exactement de la même façon que only_from sauf qu'il détermine les machines, adresses IP, hostnames, adresses réseaux et/ou noms de domaine pour lesquels vous voulez interdire l'accès à votre service.
Attention, encore une fois, xinetd utilisé seul ne vous garantira pas la sécurité de votre système. Il est essentiel d'y adjoindre un bon firewall.
Vous pouvez choisir le moment auquel vous autoriserez les accès à tout ou partie de vos services réseaux. On utilisera l'attribut access_times. Il vous permet de définir une ou plusieurs plages horaires pendant lesquelles la connexion sera possible.
Syntaxe : access_times = interval [interval...]
L'intervalle de temps s'écrit : heures:minutes-heures:minutes
Exemple : Je veux limiter l'accès de mon ftp de 9h à 12h et de 14h à 16h.
service proftpd
{
...
access_time = 9:00-12:00 14:00-16:00
...
{
Véritable couteau suisse de la configuration de services réseau, xinetd vous permet de "chrooter" un service. Rappel : la commande chroot permet de lancer un programme en restreignant ses accès disques à une sous arborescence. En fait pour le processus, la racine du disque est la racine de l'arborescence dans laquelle il a été restreint.
L'attribut server_args va nous permettre d'automatiser le chroot : la commande chroot est considérée comme le serveur et le service est passé en argument.
Exemple : Je veux chrooter mon serveur ftp.
service proftp
{
...
server = /usr/sbin/chroot
server_args = /opt/proftpd/proftpd
...
{
Lorsqu'un client tente un accès ftp, chroot est exécuté en tant que serveur et proftpd en tant qu'argument, ce qui revient à la commande connue : /usr/bin/chroot opt/proftpd/proftpd.
Dans la plupart des distributions, les services installés et gérés par xinetd sont désactivés d'office, pour des raisons de sécurité. D'autre part vous pouvez, pour un temps, choisir de désactiver complètement un service. Tout ceci est lié à l'utilisation de l'attribut disable.
Syntaxe : disable = yes|no
Exemple : Je veux désactiver telnet.
service telnet
{
disable = yes
...
{
flags = SENSOR
deny_time = minutes
SENSOR empêche toute connexion au service concerné et stocke l'adresse IP pendant un temps déterminé par l'attribut deny_time. Si cette même adresse tente de se connecter à n'importe quel service géré par xinetd, il sera automatiquement bloqué. Le temps est déterminé en minutes, mais vous pouvez utiliser également la valeur FOREVER : l'IP restera blacklistée jusqu'au prochain redémarrage de xinetd.
Je ne verrai pas ici toutes les possibilités offertes par xinetd mais 2 en particulier : la redirection de port et l'attribution d'un service à une interface réseau.
Même si ce n'est pas sa fonction principale, xinetd peut vous permettre de faire de la redirection de port, si vous ne souhaitez pas approfondir iptables. On utilisera pour cela l'attribut redirect.
Syntaxe : redirect = adresseIP port
Exemple : Je dispose d'une passerelle vers Internet et une machine sur le même réseau local dont l'adresse IP est 192.168.0.3. Je souhaite installer un serveur telnet sur cette dernière machine. Je vais donc faire en sorte que les requêtes qui arrivent de l'extérieur pour mon serveur telnet soient redirigées vers cette machine.
root@pingu# cat /etc/xinetd.d/telnet
service telnet
{
...
server = /usr/sbin/in.telnetd
redirect = 192.168.0.4 23
}
On teste maintenant la connexion :
root@pingu# telnet 217.11.12.13
Trying 217.11.12.13...
Connected to 217.11.12.13.
Escape character is '^]'.
Red Hat Linux release 8.0 (Psyche)
Kernel 2.4.18-14 on an i586
login: anne
Password:
Last login: Fri Nov 8 12:26:44 on :0
[anne@citrouille anne]$ hostname
citrouille
La connexion telnet est établie et la commande hostname nous confirme que je ne suis pas sur la passerelle mais sur la machine citrouille dont l'adresse IP est 192.168.0.4
xinetd va vous permettre de lier un service à une adresse IP grâce à l'attribut bind.
Pour éclaircir la description de cet attribut, nous allons nous appuyer sur un exemple. Je vais reprendre mes 2 machines de l'exemple précédent. Mon objectif : je veux construire 2 serveurs ftp bien différenciés. L'un sera réservé à mes machines en local (serveur de fichiers interne) l'autre mettra à disposition d'autres fichiers sur un serveur ftp réservé aux connexions externes. (Après tout je ne partage pas tout :)).
Ma machine pingu (ma passerelle) a 2 interfaces réseau avec les adresses IP respectives : 192.168.0.3 et 217.11.12.13. Je vais donc effectuer les attributions grâce au fichier suivant :
root@pingu# cat /etc/xinetd.d/proftpd
service proftpd
{
id = ftp_public
...
server = /opt/proftpd/proftpd
bind = 217.11.12.13
}
service proftpd
{
id = ftp_privé
...
server = /opt/proftpd/proftpd
bind = 192.168.0.3
}
L'attribut id sert uniquement à différencier les 2 configurations du service. Tout ceci bien sûr doit s'accompagner d'une configuration de votre serveur ftp.
Pour finir, xinetd vous permet également d'afficher des messages lors de la connexion à un service grâce aux attributs suivants :
Ci-dessous quelques exemples de fichiers de configuration de services, issus entre autres du man de xinetd.conf
Le 1er exemple est un fichier de configuration du service ftp.
root@pingu# cat /etc/xinetd.d/ftp
service ftp
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.ftpd
server_args = -l
instances = 4
log_type = FILE /var/log/ftp.log
log_on_success = DURATION HOST USERID
access_times = 2:00-9:00 12:00-24:00
}
Le serveur ftp, hormis les paramètres génériques de configuration, autorise des connexions entre 2h et 9h et entre midi et minuit. Son fichier de log est /var/log/ftp.log et contient, en cas de connexions réussies, la durée de la connexion, le nom de la machine cliente et l'UID de l'utilisateur connecté. Seules 4 instances simultanées sont autorisées
.Le 2e exemple est un fichier de configuration du service telnet.
root@pingu# cat /etc/xinetd.d/telnet
service telnet
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.telnetd
rlimit_as = 8M
rlimit_cpu = 20
}
Le dernier exemple se compose de 2 fichiers de configuration pour la gestion de samba. par xinetd. En effet, le service samba lance 2 démons, nmbd et smbd
root@pingu# cat /etc/xinetd.d/netbios-ssn
service netbios-ssn
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/smbd
only_from = 192.168.0.0
disable = no
}
root@pingu# cat /etc/xinetd.d/netbios-ns
service netbios-ns
{
socket_type = dgram
protocol = udp
wait = no
user = root
server = /usr/sbin/nmbd
only_from = 192.168.0.0
disable = no
}
Hormis les paramètres génériques de configuration de smbd et nmbd, on a configuré samba de manière à ce qu'il ne soit utilisable que sur le réseau interne 192.168.0.0.
Je n'ai pas exploré ici l'intégralité des possibilités de xinetd. La meilleur des choses à faire pour cela est de se reporter au man. Si vous disposez encore une distribution utilisant inetd, et au vu de toutes les fonctionnalités de xinetd, il semble opportun d'abandonner le premier pour le deuxième. Bien exploité, il devient véritablement un outil de sécurisation de votre système, dès lors que vous mettez en place un certains nombres de serveurs qui, ouvrant votre machine sur l'extérieur, ouvre également la voie aux vilains hackers ;).
N'hésitez pas à me faire parvenir vos remarques et ajouts divers sur le contenu de cet article.
Jean-Marc LICHTLE
Installation d'un serveur Apache/PHP/MySQL en environnement Mandrake 8.0
L'avènement de la distribution Mandrake 8.0 marque un net progrès puisque, du moins pour une première mise en place il est possible de tout faire fonctionner sans retoucher le moindre fichier de configuration, simplement en installant les rpm !
Rappelons brièvement que:
Pour ma part je trouve plus rapide et au moins aussi efficace de travailler
en mode ligne de commande en utilisant directement la commande rpm. Voir
l'article rpm sur Léa.
Le package apache-conf contient en particulier les fichiers de configuration /etc/httpd/conf/httpd.conf et /etc/httpd/conf/commonhttpd.conf qui définissent les paramètres de fonctionnement du serveur Note 1
Eventuellement vous aurez également à installer le package mm. Tout dépendra de ce qui aura été installé dans la configuration initiale. Si besoin est, ne vous inquiétez pas, LINUX saura réclamer !
En principe l'installation d'Apache a modifié les fichiers de configuration du lancement de LINUX. Le démon httpd devrait donc démarrer systématiquement et automatiquement à chaque boot. L'installation a par ailleurs démarré immédiatement ce démon, il n'est donc pas nécessaire de rebooter comme on le ferait avec un autre système d'exploitation très connu avec lequel le moindre changement de mulot passe par un reboot...
Nous pouvons par ailleurs passer immédiatement au test du serveur sans passer par la moindre phase de configuration. Pour cela chargez votre navigateur préféré (pour ma part j'utilise Konqueror). Saisir ``http://localhost'' dans la barre d'URL. Vous voyez apparaître après quelques instant une page de présentation d'Apache. En fait le serveur Apache vient d'envoyer la page /var/www/html/index.shtml, affirmation que vous pourrez facilement vérifier en tapant ``file:/var/www/html/index.shtml'' dans la barre d'URL de votre navigateur. Attention: il n'y a qu'un slash après file: alors que par habitude vous pourriez être tentés (comme moi!) d'en mettre deux.
La page affichée dans ce cas est bien la même que la première. Les différences d'affichage dans les parties graphiques s'expliquent par le fait que l'affichage a été demandé en direct au lieu de passer par le serveur Apache.
Si vous préférez utiliser Lynx (un navigateur en mode
texte ultra rapide puisqu'il ne charge pas les parties graphiques) vous
pouvez même vous contenter de taper ``lynx localhost''.
Lynx ajoutera automatiquement ce qui manque. Merveilleux de simplicité
non ?
L'installation de mod_php se termine par un script de configuration. Vous verrez en particulier passer une commande d'arrêt, puis une autre de redémarrage du démon httpd.
<html>
<? echo 'premier test php<br><br>'; phpinfo(); ?> </html> |
Sauvegardez et chargez dans un navigateur (URL http://localhost/test/test.php).
Voilà votre première page web dynamique ! Vous avez, en quelques lignes, créé du code html (les balises <html> et </html>), faite générer du html par PHP (echo 'premier test php<br><br>';), les <br> sont des retours chariots, et fait appel à l'une des nombreuses fonctions de PHP, phpinfo() qui donne les principales informations sur le configuration actuelle de PHP.
Vous pourrez réaliser d'autres tests, l'aide nécessaire est à votre disposition dans les bouquins, les revues et sur le net.
Lorsque vous aurez constitué un petit groupe de fichiers de test vous pourrez alors faire l'expérience suivante :
En principe après l'installation de mysql vous devriez disposer d'un serveur MySQL opérationnel (et en marche). Pour le vérifier tapez ps -ax | grep mysql. Vous devriez voir s'afficher quelques lignes relatives à autant de serveurs en attente de requêtes. Si tel n'est pas le cas tapez (comme root) "safe_mysql &" dans une fenètre texte. Cette commande devrait démarrer le serveur MySQL.
Attention : l'installation du rpm mysql se termine par un script qui installe les fichiers d'administration de MySQL (définition des autorisations). Vous êtes invités à lancer la commande mysqladmin de façon à configurer le mot de passe administrateur. Ne le faites surtout pas à ce stade ! En mettant un mot de passe maintenant vous allez bloquer le script de connexion de phpMyAdmin ! La sécurité ce sera pour plus tard, quand vous aurez atteint ce niveau de connaissance qui conduira ceux qui vous cotoyent à penser que vous êtes un gourou de MySQL ! Faites donc un essai de fonctionnement du serveur MySQL en utilisant simplement le client MySQL en mode texte. Tapez simplement mysql à l'invite de la ligne de commande, vous devriez obtenir une réponse positive du serveur (positive, sans plus, ne vous attendez pas à un acceuil éloquant et en fanfare!). Tapez alors quit à l'invite mysql (qui est >) et vous voilà sorti.
Il va falloir faire fonctionner tout ce petit monde ensemble! Apache et PHP sont déjà opérationnels. Ils communiquent ensemble, l'essai a été fait. MySQL est en route également. Pour que PHP puisse entrer en contact avec MySQL il lui faut un minimum de connaissances qui lui sont apportées par le module :
Récupérez le .tar.gz (tout moteur de recherche vous donnera immédiatement la bonne adresse) et décomprimez le dans /var/www/html/. Cette décompression va créer un sous répertoire /var/www/html/phpMyAdmin qui contiendra tous les scripts. Bon, je vais pousser l'amabilité jusqu'à vous donner l'URL du site sur lequel vous pouvez télécharger. Essayez : http://www.phpwizard.net/projects/phpMyAdmin ou alors ce miroir , simple non ?
Enfin, lisez l'article suivant, concernant
la sécurisation de l'environnement que l'on vient de créer.
par serge
Mettez un serveur Web dans votre LinBox.
S'il est très souvent disponible en standard sur les distributions mais on
doit souvent le configurer pour ses propes besoins.
Je vais donc essayer de
vous détailler le fichier httpd.conf, fichier de configuration d'apache.
Attention: Utilisez une version récente d'apache car:
- De nombreux bugs
de sécurité ont été corrigé
- Cette documentation traite de la configuration
des derniers serveurs apaches. Dans les anciennes versions, il y avait trois
fichiers (httpd.conf, srm.conf, access.conf) mais maitenant tous sont regroupés
dans un même fichier: httpd.conf.
Même si la compabilité avec les anciennes
versions a été conservée (on peut toujours utiliser les anciens fichiers) je ne
traite ici QUE du fichier httpd.conf.
De plus cette documentation n'est pas encore tout à fait complète, il manque encore quelques options à expliquer, mais certaines me semblent obscures (je ne connais pas tout) ou difficiles à expliquer. J'espère compléter ce document assez vite (de même si vous voulez ajouter vos connaissances à ce document, n'hésitez pas à me mailer
Je ne traite pas de l'installation d'apache, car il est présent dans toutes les distributions. De plus son installation et sa compilation ne sont pas aisées du tout suivant le support que l'on veut lui intégrer. Il existe en effet plusieurs dizaines de facons de le compiler suivant les options que l'on veut lui passer. Mais dans la plupart des distributions, apache est configuré de telle facon que l'on peut y inclure des fonctionalités facilement grâce à des modules "DSO".
ServerType standalone
Cette ligne indique si apache se lance en 'autonome' (standalone) ou
via inetd.
Pour la plupart des configurations, c'est en standalone.
Si vous ne l'avez pas réinstallé, qu'apache était déja installé, ne modifiez pas
cette ligne. Ceux qui ont créé votre distrib ont bien configuré cette ligne
normalement. Si vous n'êtes pas sur, éditez le fichier /etc/inted.conf , si
aucune ligne ne comporte httpd et que par contre vous avez un fichier du
style rc.httpd ou Sxxhttpd ou Sxxapchectl dans un
sous-répertoire de /etc/rc.d alors c'est qu'il se lance en autonome.
Inversement si une ligne httpd existe dans /etc/inetd.conf, alors il se lance en
inetd.
ServerRoot "/var/lib/apache"
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 /var/run/httpd.lock
Laissez cette ligne comme elle est , c'est-à-dire commentée, pour 90% des cas (# devant).
PidFile /var/run/httpd.pid
Vérifiez bien que cette ligne soit décommentée. Elle indique au script de démarrage d'enregistrer le numéro de process d'apache pour que, lors de l'arrêt du sytème apache soit stoppé correctement.
ScoreBoardFile /var/run/httpd.scoreboard
Idem. Cette ligne doit exister, ce fichier stocke des informations pour le bon fonctionnement d'apache-lui même.
RessourceConfig /conf/srm.conf
AcessConfig
/conf/acess.conf
Les anciens fichiers de configuration d'apache, qui ne sont plus utilisés maitenant (en fait tout est maintenant intégré dans httpd.conf pour simplifier). Ces options sont normalement commentées (# devant).
Timeout 300
Temps en millisecondes avant que le serveur n'envoie ou recoive un "timeout".
En fait quand le serveur attend une réponse d'un programme externe (parseur
PHP, script CGI, etc..), si au bout de 3s il ne recoit pas cette réponse, il va
envoyer un timeout au programme pour l'arrêter et renvoyer un timeout à
l'utilisateur pour le prévenir d'une erreur. Laissez cette valeur par défaut à
moins que vous vous aperceviez que des traitements prennent plus de temps que 3s
et que le serveur n'attend pas assez longtemps. Ne montez pas trop haut cette
valeur non plus car si le programme externe a "planté" ou si une erreur s'est
produite, vous risquez de rendre inacessible le serveur apache pour trop de temps
(toujours désagréable d'attendre 30s pour rien).
KeepAlive on
Autorise ou pas les connections persistantes (plusieurs requêtes par connection). En fait cela permet aux utilisateurs de votre serveur de lancer plusieurs requêtes à la fois. Cela permet d'accélérer les réponses du serveur. Laissez cette valeur par défaut la plupart du temps. Mais dans un environement très sollicité (serveur Web trés fréquenté) cela peut rendre le serveur indisponible pour d'autres utilisateurs ou faire monter le système en ressource. En gros pour de petits serveurs, laissez cette option sur "on". Pour un serveur très sollicité dont le système ralenti énormément ou devient indisponible asez souvent, essayez avec la valeur "off". Mais avant, essayez de baisser la valeur de l'option suivante.
MaxKeepAliveRequests 100
En combinaison avec l'option précédente, indique le nombre de requêtes pour une connection. Laissez cette valeur assez haute pour de très bonnes performances. Si vous mettez 0 comme valeur, vous autorisez en fait un nombre illimité (attention donc). Laissez la valeur par défaut là aussi.
KeppAliveTimeout 15
Valeur en seconde d'attente pour la requette suivante d'un même client sur une même connection avant de renvoyer un timeout. Là aussi, laissez la valeur par défaut.
MinSpareServers 5
MaxSpareServer 10
Ces valeurs servent à l'autorégulation de charge du serveur.
En fait
apache contrôle lui-même sa charge, suivant le nombre de clients qu'il sert et
le nombre de requêtes envoyées par chaque client. Il fait en sorte que tout
le monde puisse être servi et ajoute tout seul un certain nombre d'instances
apaches pour servir de nouveaux clients qui se connecteraient. Si ce nombre est
inférieur à MinSpareServers, il en ajoute un. Si ce nombre dépasse la
valeur de MaxSpareServer, il en arrête. Ces valeurs par défaut conviennent
à la plupart des sites.
StartServers 5
Nombre de serveurs à démarrer au lancement d'apache.
MaxClients 150
Contrôle le nombre maximum de serveurs pouvant etre lancés simultanément.
Laissez donc cette valeur assez haute. Toutefois attention à son niveau pour ne pas qu'en
cas de trop forte sollicitation, le serveur apache fasse "tomber" en ressource votre système.
Cette valeur ne modifie pas la valeur de MaxKeepAliveRequests car ici
Maxclients indique le nombre de clients maximum alors que MaxKeepAliveRequests
indique le nombre de requêtes pour UN client.
Remarque: Apache par défaut ne peut servir plus de 254 clients à la fois (c'est a dire si au même moment 254 clients
se connectent simultanément, le serveur sature et certains clients doivent attendre avant de pouvoir accéder à votre site), donc la valeur de cette
directive ne peut excéder 254 (apache vous signale un warning à son démarrage si vous dépassez cette valeur). Pour pouvoir
servir plus de 254 clients simultanément, il faut recompiler apache et modifier dans les sources d'apache la valeur max de clients
simultanés. Voir la documentation officielle d'apache pour cela.
Listen 3000
Listen 12.34.56.78
Indique au serveur des ports ou des adresses où il doit "écouter" pour
des connections EN PLUS de l'adresse et port par défaut. Voir l'option
VirtualHost plus loin.
BindAdress *
Vous pouvez ici inclure un hôte virtuel en indiquant une adresse, toutes les adresses (*) ou un nom de domaine où le serveur va attendre des connections. Voir là aussi l'option VirtualHost .
LoadModule xxxxxx.mod libexec/yyyyyy.so
.....
AddModule zzzz.c
Support pour les modules DSO. Si vous devez ajouter des modules à prendre en compte (par exemple pour ceux qui installent PHP en module dynamique), attention à l'ordre de chargement des modules qui a son importance car souvent un module dépend d'un autre module. Voir les documentations des modules que vous souhaitez ajouter.
ExtendedStatus on
Indique si le serveur doit renvoyer des informations complètes de status
(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 débuggage.
Port 80
Port d'écoute du serveur par défaut. Vous pouvez le changer si vous désirez mais attention les clients cherchent normalement sur le port 80.
User nobody
Group nobody
User et group system avec lesquels le serveur est démarré. Pour des
questions de sécurité laissez toujours ces options! Ne jamais spécifier
root!
En fait si quelqu'un arrive à "exploiter" votre serveur (par
exemple 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 user réel, il aura alors les droits de ce user/group et
pourra endommager grandement votre système.
ServerAdmin root@localhost.domainname
Adresse E-mail réelle de l'administrateur du site. Cette adresse est affichée par le serveur en cas d'erreur par exemple pour que les utilisateurs puissent en avertir l'administrateur. Mettez votre E-mail donc.
ServerName www.domainname
Adresse que le serveur va renvoyer au client Web. Il est astucieux de mettre www au lieu du nom de la machine réelle, comme cela les visiteurs ne voient pas le nom réel de votre machine (utile pour la sécurité aussi).
DocumentRoot "/var/lib/apache/htdocs"
Répertoire racine où se trouvent vos pages Web.
<Directory />
Options
FollowSymLinks
AllowOverride
None
</Directory>
Pour des questions de sécurité, laissez cela par défaut. Cela laisse les permissions de tous les répertoires par défaut et n'autorise pas d'accès spéciaux même si un .htaccess existe (AllowOverride None). De ce fait, personne ne peux modifier les droits que vous avez imposés sur les répertoires où apache a accès. Voir plus bas les explications de chaque option passée.
<Directory "/var/lib/apache/htdocs">
Options Indexes FollowSymlinks Multiviews
AllowOverride None
Order allow,deny
allow from all
</Directory>
Bon là, ce qu'on a fait, c'est qu'on définit cette fois les règles pour le répertoire /var/lib/apache/htdocs (pour notre exemple c'est le repertoire racine des pages Web), on autorise le serveur apache à suivre les liens symboliques (FollowSymlinks) , on empêche quiconque de changer ces règles (AllowOverride None) , puis on définit dans quel ordre appliquer les règles d'autorisation/refus de connection (order allow,deny) et on autorise les connections venant de n'importe quel hôte (Allow from all).
Bon détaillons un peu comment ça marche. On commence toujours par:
<Directory xx>
Pour définir sur quel répertoire (xx) on applique ces règles.
Options : on définit les options pour ce répertoire qui
sont pour les plus importantes :
None | Désactive toutes les options. |
All | Active toutes les options SAUF Multiviews. |
Indexes | Permet aux utilisateurs d'avoir des indexes générés par le serveur. C'est à dire si l'index du répertoire (index.htm le + souvent) est manquant, cela autorise le serveur à lister le contenu du répertoire (dangereux suivant les fichiers contenus dans ce répertoire). |
FollowSymLinks | Autorise à 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 les includes mais empêche la commande EXEC (qui permet d'exécuter du code). |
Multiviews | Autorise les vue multiples suivant un contexte. Cela permet par exemple d'afficher les pages dans un language suivant la configuration du language du client. |
SymLinksIfOwnerMatch | Autorise à suivre les liens seulement si le user ID du fichier (ou répertoire) sur lequel le lien pointe est le même que celui du lien. |
AllowOverride : définit comment sont gérés les fichiers
.htaccess de ce répertoire:
All | Gère tout ce qui est dans .htaccess |
AuthConfig | Active les directives d'autorisations AuthDBMGroupFile,
AuthDBMUserFile, AuthGroupFile, AuthName, AuthType,
AuthUserFile, require |
FileInfo | Active les directives d'autorisations AddEncoding, AddLanguage,
AddType, DefaultType, ErrorDocument,
LanguagePriority |
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 |
Order : Donne l'ordre d'application des règles Allow
Deny:
deny,allow | Applique les règles deny puis allow |
allow,deny | Applique les règles allow puis deny |
Allow (ou deny):
Nom d'hôte | Autorise les hôtes spécifié, les adresses IP, le nom de domaine, etc..(ou les refuse si la règle est deny) |
All | Autorise tout le monde (ou refuse) |
</Directory> : Indique la fin des règles pour ce répertoire.
A vous de placer vos règles suivant le contenu de vos répertoire accessibles
par le Web. Il existe les mêmes règles pour les fichiers (<Files>
</Files>) et les locations (<Location>
</Location>). Voir un exemple pour les fichiers (file) plus
bas.
AccesFileName .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">
Order allow,deny
Deny from all
</Files>
pour interdire aux visiteurs la possibilité voir le contenu des fichiers .ht qui contiennent les règles de sécurité.
#CacheNegotiatedDocs
Autorise ou pas les proxies à mettre en cache les documents (pour autoriser, enlevez le commentaire # en début de ligne)
UseCanonicalName On
Sur on, remet l'url par rapport aux valeurs "Server" et "Port" spécifié plus haut dans le fichier httpd.conf, sur off utilise l'url que le client a utilisée. Attention , mettre 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 text/plain
Type mime par défaut que le serveur renvoie aux clients. Convient dans la
plupart des cas. Si par-contre votre serveur web envoie principalement des
images, du streaming, etc... modifiez la valeur par
"application/octet-stream" pour éviter que les clients essaient
de visualiser du binaire (ce qui va leur donner comme résultat des
"ù*$kfdPmm%ù" au lieu d'afficher une video par exemple. Le client doit
pouvoir prendre en compte alors le fichier grâce à un plugin et il doit avoir
ses types mimes configurés pour lancer l'application associée.
HostNameLookups off
Indique si le serveur enregistre le nom (sur on) du client ou l'adresse IP (sur off)
ErrorLog /var/log/error_log
Chemin complet du fichier où les erreurs apaches seront enregistrées
LogLevel warn
Niveau d'enregistrement des erreurs avec comme valeurs possibles:
emerg | Enregistre seulement les erreurs qui rendent le serveur inutilisable |
Alert | "emerg" + erreurs nécessitant une intervention. |
Crit | "emerg" + "Alert" + erreurs critiques (accès réseau impossible par exemple) |
error | "ermerg" + "Alert" + "Crit" + erreurs dans les pages, les scripts |
warn | "ermerg" + "Alert" + "Crit" + "error" + erreurs non bloquantes (pages mal codées, scripts comportant des erreurs non bloquantes...) |
info | "ermerg" + "Alert" + "Crit" + "error" + "Warn" + toutes les informations générées |
debug | Enregistre TOUT ce qui peut se passer sur le serveur (un client demande une page: on enregistre) |
La plupart du temps, le niveau warn suffit (info et debug fournissent trop
d'informations)
ServerSignature on
Si 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 nontre que l'erreur, et sur Email ajoute un lien vers l'email définit plus haut dans ce fichier.
Alias faux_nom nom_réel
permet de faire des alias de répertoires (des liens en quelque sorte)
ScriptAlias /cgi-bin/ chemin_complet_des_cgi
Alias pour les scripts CGI
AddType type extensions
Permet de définir des extensions de fichiers pour des applications (mime type). Si on veut ajouter le support PHP4, on doit ajouter ici:
AddType application/x-httpd-php
.php
AddType
application/x-httpd-php-source .phps
Ou pour du PHP3:
AddType application/x-httpd-php3
.php3
AddType
application/x-httpd-php3-source .phps
Il faut en plus que vous ayez compiler PHP en module DSO (module dynaique) et
ajouter les lignes modules comme décrit plus haut pour activer
le support PHP (voir la doc d'installation de PHP).
AddHandler cgi-script .cgi
Pour utiliser les scripts CGI.
Et enfin les définitions de "virtual host" pour faire des serveurs virtuels suivant des répertoires, etc...
<VirtualHost ip_ou_adresse_virtuelle>
ServerAdmin email_webmaster@hoste_virtuel
DocumentRoot racine_hote_virtuel
ServerName nom_server_virtuel
ErrorLog chmein_complet_errorlog
</VirtualHost>
Explication sur les VirtualHost:
Les virtualhosts permettent de mettre plus d'un site web par IP, en les appelant par nom de domaine ou par IP. Ce qui permet d'avoir
des centaines de sites sur un serveur n'ayant qu'une seule IP (c'est comme cela que font tous les hébergeurs, ils ne prennent pas une nouvelle IP pour chaque nouveau client hébergé).
Par exemple, votre serveur web héberge deux sites web d'url: www.domaine1.com et www.domaine2.com, et a comme adresse IP: 80.10.20.30, voici comment définir les deux VirtualHost:
NameVirtualHost 80.10.20.30
<VirtualHost 80.10.20.30>
ServerAdmin webmaster@domain1.com
DocumentRoot /home/domain1/www
ServerName www.domain1.com
ErrorLog /var/log/apache/domain1-error.log
CustomLog /var/log/apache/domain1-access.log combined
ServerAlias domain1.com
</Virtualhost>
<VirtualHost 80.10.20.30>
ServerAdmin webmaster@domain2.com
DocumentRoot /home/domain2/www
ServerName www.domain2.com
ErrorLog /var/log/apache/domain2-error.log
CustomLog /var/log/apache/domain2-access.log combined
ServerAlias domain2.com
</Virtualhost>
NameServer permet de définir sur quelle IP les virtualhosts sont définis.
<VirtualHost> permet de définir un nouvel hôte virtuel apache, avec son
adresse IP associée. En combinaison avec la directive ServerName il définit
aussi le nom avec lequel le serveur doit etre appelé. Cela signifie que si le serveur
reçoit une requête sur son IP 80.10.20.30 avec le nom "www.domain1.com", le serveur va
donc fournir les pages webs contenues dans /home/domain1/www (grâce à la directive
DocumentRoot).
De la même facon, il va fournir les pages de /home/domain2/www
si on appelle celle-ci avec l'url www.domain2.com.
Pour que cela fonctionne, il faut bien sur qu'un serveur DNS soit configuré pour faire
pointer www.domain1.com et www.domain2.com sur l'IP 80.10.20.30.
Les directives ErrorLog et Customlog permettent de définir les fichier logs
de chaque hôte virtuel (autrement les logs s'ajouteront aux logs principaux du
serveur défini dans les directives en dehors de la directive <VirtualHost>.
ServerAlias permet d'indiquer sous quel autre nom l'hôte virtuel peut etre appelé
(ici domainX.com en plus de www.domainX.com), bien sur là aussi le serveur DNS doit être
configuré pour faire pointer domainX.com sur 80.10.20.30
Une autre facon de faire des hôtes virtuels, si on n'a pas plusieurs noms de domaine, est de
la faire par IP ou par IP et Port.
Par IP, il suffit de faire des <VirtualHost ip1> et <VirtualHost ip2> etc... ,
et par port il suffit de faire des <VirtualHost ip:port1> <VirtualHost ip:port2>
Il faut aussi des directives de Bind et Listen sur chaque IP et port supplémentaire
(voir les directives Listen et Bind plus haut dans ce document).
Dans chaque virtualhost, vous pouvez aussi ajouter d'autres directives, comme les directives
de ScriptAlias (pour l'exécution de cgi), de Directory
(option des répertoires du site), ... En gros, toutes les directives peuvent être redéfinies
dans chaque VirtualHost pour configurer le site web virtuel. Voir pour cela la documentation
officielle d'apache. Pour chaque directive, il est spécifié si elle peut être utilisé dans
un contexte de VirtualHost ou pas.
Voilà donc pour les principales directives utilisées dans httpd.conf. D'autre
directives existent (voir la doc officielle), et les modules chargés par apache ajoutent eux
aussi des directives spécifiques (voir la documentation du module ajouté).
Jean-Marc LICHTLE
Protection d'un serveur Apache PHP MySQL contre les visites non souhaitées
L'objectif est de décrire comment protéger un serveur constitué de la trilogie Apache + PHP + MySQL des ``visites inopportunes''. La description est relative à une installation LINUX, plus spécifiquement la version 8.0 de MANDRAKE.
Exemple de problème de sécurité posé : vous avez installé phpMyAdmin. Il est souhaitable d'interdire qu'un visiteur non autorisé accède à ce script ce qui lui donnerait des droits dangereux sur toutes les bases de données installées.
Il n'entre pas dans les vues de l'auteur de transformer le lecteur en spécialiste de la sécurité informatique. Ce document veut être :
Pour plus d'informations on pourra se reporter à l'importante littérature qui existe sur la question, notamment ``Pratique de MySQL et PHP'', édition O'REILLY.
Il importe de comprendre que la protection d'un site Apache + PHP + MySQL prend des facettes multiples, chaque logiciel ayant ses ``protections'' propres. De plus comme nous le verrons bientôt avec phpMyAdmin, ces systèmes de protections dialoguent entre eux.
Ce fichier de mots de passe peut porter un nom quelconque. Habituellement ce dernier est rangé dans /etc/httpd/auth/, répertoire qu'il convient éventuellement de créer puisqu'il n'existe pas après l'installation de base. Il est assez logique que tous les fichiers d'authentification seront rangés dans le même sous-répertoire. Il est de ce fait judicieux de choisir des noms de fichiers qui soient parlant et qui rappellent l'objet de la protection, par exemple test.users pour le fichier qui définira les droits d'accès des diféfrents utilisateurs au sous répertoire test. L'emploi de /etc/httpd/auth/ pour ranger les fichiers d'autorisation est une pure question de convention. Ces fichiers pourraient aussi bien être rangés n'importe ou ailleurs. Il va toutefois sans dire (mais mieux en le disant) que ces fichiers doivent être hors de portée des visiteurs, en clair ne doivent pas faire partie de l'arborescence /var/www/html/...
Avec un éditeur quelconque (de préférence emacs =;-) créer le fichier minimum suivant:
AuthUserFile /etc/httpd/auth/test.users AuthName ``Accès restreint'' AuthType Basic require valid-user
|
Sauvegardez...
AuthUserFile définit quel est le fichier chargé de contenir les autorisations. La Mandrake 8.0 suppose par défaut que les fichiers d'autorisation sont rangés dans /etc/httpd/. La première partie de l'adresse AuthUserFile peut donc être omise éventuellement.
AuthName précise le message qui sera affiché dans la boite de dialogue, dans ce cas ``Accès restreint à localhost'' si la machine est nommée localhost. Nous verrons plus loin l'intérêt de choisir un message aussi explicite que possible.
Syntaxes:
Pour mettre en place ce renvoi éditez ce fichier et ajoutez (par exemple tout à la fin) les lignes suivantes :
<Directory /var/www/html/test>
AuthName "Accès limité" AuthUserFile /etc/httpd/auth/test.users AuthType Basic require valid-user </Directory> |
Pour protéger plusieurs répertoires créez plusieurs paragraphes <Directory> </Directory>.
Sauvegardez puis relancez le démon Apache (comme root : /etc/rc.d/init.d/httpd restart). En effet dans ce cas vous venez de modifier un des fichiers de configuration du serveur, fichier qui est lu au moment du chargement de Apache. Il convient donc de forcer Apache à relire ce fichier pour prendre en compte les modifications.
Par contre, il cherchera à chaque requête d'un navigateur, à lire un éventuel fichier .htaccess contenu dans le sous-répertoire concerné par la demande. S'il le trouve les informations contenues dans ce fichier remplaceront, pour la durée de la requête, celles qui sont contenues dans httpd.conf. En clair vous pouvez ``masquer'' la configuration officielle contenue dans httpd.conf en proposant une nouvelle configuration dans un .htaccess. Faites l'essai en mettant en place une protection double :
L'intérêt de cette petite démonstration ne semble pas évident. Trois éléments méritent toutefois d'être retenus :
La protection par .htaccess décrite ci-dessus s'applique à l'ensemble d'un sous-répertoire. En fait vous pouvez différencier, si vous le souhaitez, les accès aux fichiers. La syntaxe de .htaccess s'en trouve légèrement modifiée, par exemple pour protéger un fichier nommé common.php :
<Files common.php>
AuthName "Accès limité au fichier common.php par .htaccess" AuthUserFile /etc/httpd/auth/common.users AuthType Basic require valid-user </Files> |
L'intérêt de libeller AuthName de façon explicite apparaît ici de façon nette. Lors des essais vous pourrez en effet savoir immédiatement quels sont les contrôles d'accès qui sont en place.
Vous pouvez souhaiter protéger plus spécifiquement l'accès à un fichier particulier. La solution consiste à créer un fichier .htaccess libellé comme suit :
Exemple pour protéger un fichier common.php :
<Files common.php>
Order Deny,Allow Deny from All </Files> |
Pour protéger plusieurs fichiers il suffit de créer plusieurs rubriques <Files> </Files>.
Attention: cette méthode interdit l'accès via le serveur Web pour tout le monde, y compris le propriétaire du fichier, l'administrateur, etc.
Lorsque Apache accède à un sous-répertoire pour satisfaire à la demande d'un navigateur client il commence par vérifier les autorisations d'accès (voir ci-dessus). S'il ne rencontre pas de veto alors il part à la recherche d'un éventuel fichier index.html ou index.php (si PHP est installé). S'il ne trouve pas ce fichier alors il affiche le contenu du sous-répertoire qui apparaît donc en clair pour le visiteur.
Pour éviter que le contenu du sous-répertoire ne s'affiche il suffit donc de créer un fichier index.html ou index.php. Concevoir le contenu de ce fichier de telle sorte qu'il réponde à votre attente, du simple message d'avertissement au script PHP qui va renvoyer de force le visiteur dans le droit chemin. C'est simple et relativement efficace pour un environnement non critique. La solution la plus simple consiste simplement à créer un fichier index.html vide. Le navigateur recevra donc une page blanche. Pas très explicite mais simple et efficace !
Attention, il s'agit là simplement de créer une dissuasion. Nous ne sommes plus dans le domaine de la protection gérée comme ci-dessus. Un utilisateur qui connaîtrait un ou plusieurs noms de fichiers contenus dans ce sous-répertoire pourrait y accéder sans le moindre problème en tapant simplement leurs URL complets ! De grâce, ne construisez pas un site central de banque avec de telles méthodes !
Pour commencer ouvrez une fenêtre texte (xterm, rxvt, terminal ou autre) et lancez le client MySQL par :
# mysql -u root (on suppose que vous êtes logué comme root).
La réponse devrait être immédiate ``Welcome to the MySQL Monitor ....'' et se terminer par l'invite de commande de MySQL qui est modestement mysql>. Je reproduirais cette invite pour tous les exemples de syntaxe SQL donnés ci-dessous.
Attention, vous êtes logué comme administrateur, tout ce que vous allez faire pourra devenir dramatique en cas d'erreur !
tapez mysql>use mysql; pour préciser au serveur d'utiliser dans ce qui suit la base de données nommée mysql.
La réponse devrait se terminer par ``Database changed''.
Ces droits sont différenciés, consultation, mise à jour, etc.
La base de données qui décrit la structure des autorisations d'accès est contenue dans /var/lib/mysql/mysql/ (dans l'installation Mdk8.0). Cette BDD est créée automatiquement par le script d'installation du package MySQL. Vous pouvez consulter la liste des tables de cette base par mysql>show tables;
Cette commande affiche la liste des tables constituant la BDD.
L'objet du présent document étant de constituer une aide de départ (et non de remplacer la documentation spécialisée) nous ne nous intéresseront dans ce qui suit qu'à une seule table de cette base de données, la table user qui défini les droits d'accès globaux des utilisateurs à l'ensemble des BDD. De même nous n'étudierons que le cas d'une machine isolée servant à la fois de serveur et de client. La configuration en réseau n'est guère plus complexe mais dépasserait le cadre de la présente étude.
La structure de la table user est assez simple. Elle contient les champs suivants:
Host char(60) | nom de la machine depuis laquelle est fait l'appel |
User char(16) | login de l'utilisateur |
Password char(16) | mot de passe codé |
Select_priv | droits d'effectuer des requêtes sélect (valeur Yes ou No) |
Insert_priv | ... |
Update_priv | ... |
Delete_priv | ... |
Create_priv | droits d'effectuer une création de table |
Drop_priv | droits de suppression d'une table |
Reload_priv | droits de relancer le serveur MySQL |
Shutdown_priv | droits d'arrêter le serveur MySQL |
Process_priv | |
File_priv | |
Grant_priv | |
References_priv | |
Index_priv | |
Alter_priv |
Cette structure peut être consultée très simplement par mysql>desc user; Son contenu peut être affiché par mysql>select * from user;
La première étape va consister à supprimer les lignes qui sont inutiles de telle sorte à ne conserver qu'une seule ligne, celle qui correspond à l'administrateur root depuis localhost.
Tapez donc :
mysql>delete from user where Host='localhost.localdomain';
mysql>delete from user where User='';
mysql>select * from user;
Cette fois la liste devrait contenir le seul enregistrement relatif à root depuis localhost.
Pour ajouter un utilisateur lambda procédez comme suit :
mysql>insert into user values('localhost','lambda',password('mdp_lambda'), 'Y','Y','Y','Y','N','N','N','N','N','N','N','N','N','N');
Ne comptez pas, il y a 4 'Y' et 10 'N' !
Vous venez de créer un nouvel utilisateur nommé lambda et dont le mot de passe est mdp_lambda (vous mettez bien sûr ce qui vous convient).
La syntaxe de cette ligne mérite quelques commentaires :
Pour cela tapez dans un terminal :
# mysqladmin flush-privileges
Cette commande demande à MySQL de recharger les tables définissant les autorisations d'accès depuis le disque sans pour autant arrêter le serveur.
Une autre solution plus brutale serait d'arrêter le serveur et de le redémarrer en tapant (compte root) # /etc/rc.d/init.d/mysql stop puis # /etc/rc.d/init.d/mysql start.
On peut enfin arrêter complètement LINUX et relancer mais là c'est la honte, n'est-ce pas ? Nous ne sommes pas sous Window$ que diable !
Il peut paraître lourd, alors que LINUX vous a déjà demandé de vous identifier correctement au login, de se re-identifier à nouveau à chaque lancement d'un client MySQL.
Cette procédure est heureusement contournable.
A chaque lancement d'un client MySQL celui-ci va en effet vérifier la présence des fichiers suivants:
Les données les plus récentes iront à chaque fois écraser les plus anciennes ce qui permet de personnaliser très finement le comportement du client MySQL en fonction des besoins de l'utilisateur. Et parmi ces données, mais vous l'aurez déjà deviné, figurent le mot de passe de connexion au serveur MySQL !
Dans une installation de base aucun de ces fichiers n'existe. Par contre le sous-répertoire /usr/share/mysql/ contient un certain nombre de fichiers exemples nommés my-small.cnf, my-medium.cnf, etc. qui correspondent à des propositions de fichiers de configuration pour différents cas d'utilisation. Les premières lignes de chacun de ses fichiers précisent les domaines d'application.
Pour automatiser le login MySQL pour un utilisateur lambda en se basant sur le modèle medium procéder comme suit :
Le login de connexion ainsi que le mot de passe apparaissent donc en clair dans le script de connexion ce qui est moyennement satisfaisant. Aspect positif le script lui-même n'est jamais envoyé au client puisque PHP s'exécute entièrement sur le serveur (contrairement à JAVA). Il n'y a donc aucune raison pour qu'un visiteur puisse lire ce mot de passe. Oui, mais... il n'y a pas que des visiteurs ``normaux'' !
Une protection supplémentaire (et aussi une simplification si on rédige beaucoup d'applications PHP) est de définir ses variables $host, $user et $password dans un fichier extérieur au script lui-même et d'incorporer ces valeurs au moyen d'une directive include. Avantage : le fichier qui contient les variables peut être stocké en dehors des sous-répertoires consultés normalement par Apache (hors de l'arborescence /var/www/html/), et protégé par un fichier .htaccess.
Finalement le contrôle d'accès à MySQL via un script
PHP découle directement de ce qui a été exposé
au chapitre précédent et s'appuie directement sur les règles
d'accès à MySQL définies dans la base de données
/var/lib/mysql/mysql/. Il peut donc s'avérer souhaitable de créer
un compte utilisateur MySQL spécifique aux applications PHP qui
tournent sur le serveur. On pourrait aussi imaginer d'en créer plusieurs,
1 par famille de scripts par exemple.
L'installation par défaut conduit à faire de phpMyAdmin un client MySQL avec un login root sans mot de passe (d'où l'intérêt de ne pas mettre, dans un premier temps, de mot de passe au compte root faute de quoi phpMyAdmin ne serait plus en mesure d'accéder au serveur MySQL).
En fait le fonctionnement de phpMyAdmin est réglé par le fichier /var/www/html/phpMyAdmin/config.inc.php3
Ce fichier, assez court, contient notamment les lignes suivantes :
// The $cfgServers array starts with $cfgServers[1]. Do
not use $cfgServers[0].
// You can disable a server config entry by setting host to ''. $cfgServers[1]['host'] = 'localhost'; // MySQL hostname $cfgServers[1]['port'] = ''; // MySQL port - leave blank for default port $cfgServers[1]['adv_auth'] = false; // Use advanced authentication? $cfgServers[1]['stduser'] = 'root'; // MySQL standard user (only needed with advanced auth) $cfgServers[1]['stdpass'] = ''; // MySQL standard password (only needed with advanced auth) $cfgServers[1]['user'] = 'root'; // MySQL user (only needed with basic auth) $cfgServers[1]['password'] = ''; // MySQL password (only needed with basic auth) $cfgServers[1]['only_db'] = ''; // If set to a db-name, only this db is accessible $cfgServers[1]['verbose'] = ''; // Verbose name for this host - leave blank to show the hostname |
Le texte de ce fichier semble assez explicite. Il nécessite toutefois une analyse plus détaillée pour bien en comprendre certaines finesses.
$cfgServers[1] désigne le premier serveur MySQL, le seul qui nous intéresse ici (il semblerait qu'il y ait des vicieux qui démarrent plusieurs serveurs.. imaginez un peu ;-)).
Le paramètre important est [adv_auth]. Il peut prendre deux valeurs, false (défaut à l'installation) et true.
mysql> update user set Password=password('mdp_root') where user = 'root';
Un petit coup de # mysqladmin flush-privileges (y'en a qui avaient oublié !?) et voilà le mot de passe administrateur pris en compte par le serveur MySQL. Pour la petite histoire c'est la dernière fois que vous tapez cette commande avec cette syntaxe simple. Maintenant que root a un mot de passe dans MySQL il faudra utiliser la syntaxe # mysqladmin -u root -p flush-privileges, ce qui va provoquer la demande du mot de passe par le serveur.
Et maintenant adieu phpMyAdmin, ça ne marche plus ! Seulement voilà, arrivé à ce stade de notre étude nous savons comment faire prendre en compte ce mot de passe par phpMyAdmin. Il suffit de l'incorporer au fichier de configuration /var/www/html/phpMyAdmin/config.inc.php3 à la ligne $cfgServers[1]['password'] = ''.
Au prochain lancement de phpMyAdmin le fichier de configuration va être pris en compte et tout va rentrer dans l'ordre, la connexion s'effectuant à nouveau de façon directe...
Bon, ça ne marche pas ? Ne vous affolez pas ! Je fais le pari que vous avez fait des essais de .htaccess ou de httpd.conf sur le sous répertoire de phpMyAdmin et qu'il reste des traces des essais effectués précédemment. Supprimez (ou renommez) l'éventuel fichier .htaccess situé dans le sous répertoire /var/www/html/phpMyAdmin/ et/ou mettez des commentaires (#) aux éventuelles lignes ajoutées à /etc/httpd/conf/httpd.conf. Attention de relancer Apache si vous modifiez httpd.conf !
Il faut toutefois établir une première connexion de façon à avoir un accès temporaire à la table user. C'est à cette fin que la configuration prévoit un compte défini par $cfgServers[1]['stduser'] et $cfgServers[1]['stdpass'], ces deux variables devant permettre la vérification des droits d'accès. Il va sans dire que le [stduser] désigné ici devra avoir des droits suffisants pour lire la table user.
Cette authentification offre au minimum deux avantages :
Vous pouvez même aller plus loin dans le raisonnement et limiter les droits strictement à la table user. Mais là c'est une autre affaire, je sens que vous allez passer quelques heures sur l'étude détaillée des droits d'accès MySQL.
Parmi les informations qu'il me semble intéressant de résumer
ici je dresse à toutes fins utiles la liste des fichiers et répertoires
qui ont été évoqués ci-dessus (dans leur ordre
d'apparition en scène):
Répertoire /fichier | Fonction |
/var/www/html/ | Base arborscence site Web |
/var/www/html/phpMyAdmin/config.inc.php3 | Configuration de phpMyAdmin |
/var/lib/mysql/mysql/ | Base de données des droits d'accès |
/var/lib/mysql/my.conf | Configuration de base de MySQL (optionnel) |
/etc/httpd/auth/ | Rangement des fichiers d'authentification par .htaccess |
/etc/httpd/conf/httpd.conf | Configuration serveur Apache |
/etc/rc.d/init.d/httpd | Lancement du serveur Apache option restart |
/etc/rc.d/init.d/mysql | Lancement du serveur MySQL opt stop ou start |
/etc/my.conf | Configuration de base de MySQL (optionnel) |
/.my.conf | Configuration de base de MySQL (opt. spécif. util.) |
/usr/share/mysql/ | Contient des exemples de fichier my.cnf |
/var/log/httpd/ | Contient les fichiers log |
Je précise à nouveau que ce document s'applique au cas d'une installation en environnement LINUX Mandrake 8.0 telle que décrite dans un document identifié plus haut. Un système qui serait basé sur une autre distribution et/ou qui utiliserait des versions d'Apache, PHP ou MySQL qui auraient été compilées par l'utilisateur pourrait utiliser d'autre répertoires pour stocker les différentes informations. L'essentiel est d'obtenir un ensemble cohérent.
J'espère sincèrement que ce document servira un jour à
quelqu'un. Sa rédaction est de toute façon justifiée
par le simple fait que l'exercice m'a obligé à mettre mes
connaissances et mes notes au propre, à tester pas à pas
toutes mes propositions. J'en suis donc le premier lecteur. N'hésitez
pas à me faire part de votre avis sur l'intérêt de
cette étude. Toute suggestion d'amélioration sera bienvenue.
par Fred, mis à jour par Anne
Comme moi, vous avez une belle machine et vous aimeriez bien que celle-ci puisse partager ces ressources avec d'autres machines dans un réseau hétérogène. Mais, laisser cette tâche à Win$$$ vous déplait, ne le faites pas. Une nouvelle fois, les logiciels libres viennent à votre secours, ils sont plus souples et gratuits.
Les informations contenues dans cette page ne sont aucunement garanties. J'apprécierai grandement toutes les critiques constructives, en particulier, celles liées à mon orthographe déplorable, à ma syntaxe difficile à suivre et aux erreurs qui se sont certainement glissées subrepticement au sein de ce texte. Si vous voyez quelque chose à ajouter, je vous serais reconnaissant de bien vouloir me mailer les modifications que vous voulez apporter à ce document.
Ce document concerne l'installation d'un serveur SAMBA au sein d'un réseau TCP/IP hétérogène (des machines Linux/UN*X et Win$$$). Il décrit uniquement les paramètrages élémentaires ! Pour ce qui est de la sécurité : allez sur les newsgroup. Nous supposerons ici que vous n'êtes pas reliés à l'internet.
Pour installer un serveur SAMBA sous Linux vous aurez besoin de :
Avant propos : Pour que tout ceci puisse fonctionner, il faut que tout votre réseau (même - surtout - les machines Win$$$) soit configuré de manière à utiliser TCP/IP comme protocole réseau : SAMBA fonctionne en effet au dessus de TCP/IP. Pour ma part, j'ai désactivé tous les autres protocoles (sauf IPX/SPX pour pouvoir jouer à Warcraft...) des machines Win$$$ connectées à mon réseau (4 machines : 1 PII 350 configuré en serveur SAMBA - il peut fonctionner en dualboot Win/Linux-, 2 P75 sous Linux (éléments d'une étude de cluster), 1 P166 en dualboot Win/Linux, les ressources du serveur sont accessible au P166 sans aucun changement que le serveur soit sous Linux ou Win$$$ vu que j'ai donné les mêmes noms aux ressources sous Win$$$ et Linux). Normalement ce ne doit pas être la peine, mais si ce que j'écris ici ne fonctionne pas chez vous : faites comme moi avant de m'écrire ;-).
[root@etoile-noire home]# rpm -qa | grep samba samba-2.0.5a-3mdkSi vous obtenez quelque chose de similaire, c'est que tout est déjà près, passez à la section suivante. Sinon il faut installer les packages depuis le CD de votre distribution (ou tout autre support contenant votre distribution) :
Normalement, si vous avez fait ce qui est écrit (et si je ne me suis pas trompé ;-) vous ne devez avoir aucun message d'erreur (peut-être quelques avertissements... mais rien d'autre !). Si rpm vous signale que des dépendances manquent : à vous de les résoudre (en installant les rpms qui manquent).
Remarque : Si vous avez perdu le CD de votre distribution ou si vous voulez installez la toute dernière version allez :
[root@etoile-noire home]# /etc/rc.d/init.d/smb start Starting SMB services: Starting NMB services:On lance les deux démons nécessaire au fonctionnement de SAMBA. (Même si SAMBA est déja lancée, normalement, il n'y a pas d'erreur...)
[root@etoile-noire home]# /etc/rc.d/init.d/smb status smbd (pid 970) is running... nmbd (pid 972) is running...On vérifie que SAMBA est bien en train de fonctionner. Vous devez voir apparaitre les deux dernières lignes. Si tout va bien (ce qui devrait être le cas) vous pouvez passer à la suite ; sinon vous pouvez tout recommencer.
A partir de maintenant SAMBA fonctionne sur votre machine.
SAMBA ne doit pas fonctionner dans les "runlevels" 0, 1, 2 et 6 (en effet dans ces "runlevels" le réseau n'est pas activé) :
# ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc0.d/K35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc1.d/K35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc2.d/K35smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc6.d/K35smbSAMBA peut (et devrait) fonctionner dans les "runlevels" 3, 4 et 5 :
# ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc3.d/S91smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc4.d/S91smb # ln -s /etc/rc.d/init.d/smb /etc/rc.d/rc5.d/S91smbA partir de maintenant, dès que vous démarrerez Linux, SAMBA sera démarré par init. C'est la méthode à préférer si votre serveur SAMBA doit etre toujours actif.
Pour ceux qui utilisent une distribution Mandrake (voire peut-être d'autres, c'est à tester chez vous), vous pouvez remplacer toutes ces commandes par :
# chkconfig --level 0126 smb off
# chkconfig --level 345 smb on
C'est un peu plus simple.
netbios-ns 137/tcp # NETBIOS Name Serviceainsi que le fichier /etc/inetd.conf qui doit contenir :
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
netbios-ssn stream tcp nowait root /usr/sbin/smbd smbdpuis vous redémarrez le super démon inetd par :
netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
/etc/rc.d/init.d/inet restartEt c'est tout.
Le problème de cette méthode, c'est que le serveur SAMBA
à très peu de chance de devenir le MASTER BROWSER du réseau,
si ce n'est pas nécessaire pour vous, cette méthode convient
très bien. Si votre serveur SAMBA n'a pas besoin d'etre actif en
permanence, préférez cette méthode.
De plus en plus, les distributions remplacent inetd par
xinetd. Il vous faut donc créer deux fichiers appelés netbios-ssn et
netbios-ns dans le répertoire /etc/xinetd.d. Ci-dessous un exemple de
configuration, à adapter à votre cas :
root@pingu# cat /etc/xinetd.d/netbios-ssn
service netbios-ssn
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/smbd
disable = no
}
root@pingu# cat /etc/xinetd.d/netbios-ns
service netbios-ns
{
socket_type = dgram
protocol = udp
wait = no
user = root
server = /usr/sbin/nmbd
disable = no
}
Puis pour prendre en compte les modifications, relancer xinetd.
root@pingu# /etc/rc.d/init.d/xinetd restart
donc, on crée un groupe spécifique :
# groupadd smbusersPuis, on peut crée cet utilisateur spécifique (appartenant au groupe smbusers):
# useradd -g smbusers -p "passwd" -s /bin/false smbuserComme le shell de cet utilisateur est /bin/false : personne ne pourra pas se connecter sur votre Linux sous ce nom (même en connaissant le mot de passe : je vous déconseille quand même d'utiliser password comme mot de passe ;-)).
SAMBA est livré avec un outil de configuration assez puissant : SWAT. Son rôle est l'édition du fichier de configuration de SAMBA : /etc/smb.conf et le contrôle de SAMBA. Il fonctionne via un browser de page WEB (par exemple netscape).
Pour cela il faut autoriser les transactions de SWAT et donc, modifier le fichier /etc/inetd.conf de façon que celui-ci contienne la ligne :
Il est judicieux de modifier cette ligne pour utiliser tcpd de façon à n'autoriser les accès au serveur SAMBA que depuis certains endroits (en modifiant les fichiers /etc/hosts.allow et /etc/hosts.deny), vous pouvez par exemple remplacer la ligne précédante par :swat stream tcp nowait.400 root /usr/sbin/swat swat
Il faut aussi modifier /etc/services de façon que celui-ci contienne la ligne :swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat
Maintenant que SWAT est correctement configuré, il faut redémarrer le super daemon inetd pour recencer ses services.swat 901/tcp
Note : SWAT est correctement configuré parce que l'installation via paquetage RPM copie un fichier /etc/smb.conf de base. Si ça ne marche pas c'est que celui-ci est corrompu, réinstallez le paquetage...
Pour rédemarrer inetd avec la Mandrake il faut taper :
[root@etoile-noire home]# /etc/rc.d/init.d/inet restart
Tout comme mentionné plus haut, il est fréquent que votre distribution fournisse plutôt xinetd. Il vous faudra donc modifier /etc/xinetd.d/swat pour activer le service. 2 étapes à suivre :
root@pingu# cat /etc/xinetd.d/swat
service swat
{
port = 901
socket_type = stream
wait = no
only_from = 127.0.0.1
user = root
server = /usr/sbin/swat
log_on_failure += USERID
disable = yes
}
root@pingu# /etc/rc.d/init.d/xinetd restart ou
root@pingu# service xinetd restart
Votre browser va vous demander un mot de passe (le login sera déja rempli), tapez votre mot de passe root habituel. SWAT est maintenant lancé. Ce que vous voyez est la page d'accueil de SWAT, elle s'appelle Home : c'est une page d'aide (en fait ce sont des renvois aux manpages relatives à SAMBA).http://root@localhost:901
Nous voulons autoriser certains utiliateurs à se connecter à notre serveur SAMBA. C'est assez simple puisqu'il suffit de cliquer sur l'icône <Password Management>.
Seule, la partie <Server Password Management> nous intéresse. Supposons que vous souhaitiez que machin puisse se connecter sur votre serveur :
Zone de saisie : | Valeur : | Commentaires : |
User Name | machin | n'importe quel nom valide sur votre système. |
New Password | ******* | Un mot de passe est impératif (pour l'instant). |
Re-type New Password | ******* | Le même mot de passe (évidemment) |
Quand vous avez renseigné tous les champs de cette partie (ne touchez pas à ce qui concerne <Client/Server Password Management> qui ne nous concerne pas... encore), cliquez sur <Add New User>. Vérifiez que SAMBA accepte votre nouvel utilisateur. Si ce n'est pas le cas, cela peut-être pour trois raisons (au moins) :
Et c'est tout. Recommencez pour tous les utilisateurs auxquels vous souhaiter autoriser les connections SAMBA sur votre serveur.
A partir de maintenant les utilisateurs que vous avez ajouté seront connus de SAMBA et ils ont donc la possibilité (dès que nous les y autoriserons) de se connecter au serveur.
Ne quittez pas SWAT (pas encore...).
Zone de saisie : | Valeur : | Commentaire : |
workgroup | WORKGROUP | mettez ce que vous voulez. Sachez simplement que c'est plus agréable de mettre un nom connu de vos machines Win$$$. Par exemple vous pouvez laisser WORKGROUP |
serveur string | Serveur Libre Linux/Samba | mettez ce que vous voulez. C'est un commentaire, un truc du style Serveur Libre Linux/Samba sera le bien venu. |
interfaces | (rien) | il faut indiquer les adresses IP des interfaces qui serviront à établir la liaison entre SAMBA et les machines clientes ainsi que le masque réseau (par exemple, si vous avez deux cartes ethernet - adresses 192.168.1.1 et 192.168.2.1 connectées respectivement aux réseaux 192.168.1.0 et 192.168.2.0 - mettez 192.168.1.1/24 192.168.2.1/24. Si vous n'avez qu'une seule carte ethernet, vous pouvez ne rien mettre, SAMBA la trouvera tout seul comme un grand) |
security | SHARE | sélectionnez le mode SHARE : c'est le mode de fonctionnement de Win$$$ 9$ |
encrypt password | Yes | sélectionnez <Yes> (sauf cas très particuliers... Win$$$ 95 avant l'OSR2 et ses bogs multiple de sécurités etc...) |
guest account | ftp | mettez ftp ou un nom d'utilisateur valide sur votre système : ce sera le compte sur lequel seront connectés les invités si vous les autorisez. Il faut donc mettre un compte qui possède très peu de droit comme ftp ou nobody |
hosts allow | 192.168.1. | mettez les adresses IP des machines ou des réseau (séparée
par des espaces) que vous souhaitez autoriser à se connecter à
votre serveur (essayez de faire cela avec Win$$$ 9$...) par exemple pour
autoriser les machines du réseau 192.168.1.0 ttapez 192.168.1.
(le point final est important). Vous pouvez autoriser toutes les machines
de ce réseau sauf 192.168.1.10 en tapant :
|
hosts deny | ALL | mettez les adresses IP des machines auxquelles vous souhaitez interdire
l'accès à votre serveur SAMBA par exemple : ALL
pour interdire tout le monde sauf les machines autorisées
par
<hosts allow>. (Ici aussi le mot clef EXCEPT fonctionne).
Note: cf note précédante. |
character set | ISO8859-1 | Si vous utilisez Win$$$ en France (avec des accents par exemple), mettez
ISO8859-1.
Note : Normalement, dans ce cas vous devez aussi fixer la valeur de client code page à 850 (la code page par défaut de Win$$$ en france) dans la Advanced view. Mais, chez moi ce n'est pas la peine, c'est la valeur par défaut. |
Dans toutes les autres zones vous pouvez laissez les valeurs par défaut, sinon lisez l'aide disponible.
Cliquez alors sur <Commit Changes> pour activez ces changements.
Maintenant on va pouvoir activer des partages (au sens de Win$$$). Cliquez sur <SHARES>. Nous allons autoriser chacun des utilisateurs que nous avons enregistré, à se connecter à son répertoire home. Dans la boîte déroulante située entre les boutons <Choose Share> et <Delete Share>, sélectionnez <homes> et cliquez sur <Choose Share>.
Les seules zones que vous devez fixer sont :
Zones de saisie : | Valeur : | Commentaires : |
guest ok | No | les invités ne sont pas autorisés dans les répertoires maison (home). Si vous souhaitez les autoriser ... mettez Yes, mais ce n'est pas très logique. |
create mask | 0750 | la meilleur valeur est 0750 qui signifie que seul l'utilisateur aura le droit de lire et écrire et que seuls les utilisateurs appartenant au groupe pourront lire les fichiers qui seront créés dans ce répertoire par le biais de SAMBA. |
available | Yes | sinon au quoi sert que fred il se décarcasse ! |
A partir de maintenant, on peut vérifier que SAMBA nous autorise à nous connecter à notre home ! (plus précisément, si l'on demande la ressource \\\\etoile-noire\\machin et que l'on n'est pas machin, SAMBA s'en fiche, il fera comme si !) Pour cela nous allons utiliser smbclient pour nous connecter à notre serveur. Supposons que l'utilisateur fred souhaite se connecter sur le compte home de machin (dont il connait le mot de passe SAMBA), il devra taper :
[fred@awing /home/fred]$ smbclient \\\\etoile-noire\\machin -U machin Added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0 Password: ******* (rien ne s'affiche, mes mots passe sont perso!) Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.5a] smb: \> exit (pour quitter smbclient)Hourra ! Ca marche !
Mais, il n'y a pas que les maisons dans la vie. On peut souhaiter partager autre chose que sa maison :
On obtient une page à remplir. Voici les valeurs que je suggère
:
Zone de saisie : | Valeur : | Commentaire : |
Comment | Le beau partage | tapez ce qu'il vous plaira |
path | /c: | ce doit être le chemin complet d'un répertoire accessible par l'utilisateur smbuser et/ou le groupe smbusers |
guest account | ftp | si vous souhaitez autotoriser les accès aux invités, vous devez spécifier ici un utilisateur ayant très peu de droit comme l'utilisateur ftp sur un système Linux de base. |
valid users | machin bidule truc | entrez la liste (séparée par des espaces) des utilisateurs qui auront le droit de se connecter à cette ressource. |
force user | smbuser | entrez le nom sous lequel nous nous connectons au ressources partagé par SAMBA (vous pouvez ne rien mettre, en ce cas l'utilisateur qui se connectera le sera avec tous ses droits). |
force group | smbusers | idem précédemment. |
read only | No | Mettez Yes si vous voulez empêcher l'accès en écriture. (Je vous conseille de créer deux noms par ressource : un premier interdisant les écritures, dont beaucoup d'utilisateurs auront les droits d'accès - ie: par valid users - , et un second autorisant les écritures mais à un minimum d'utilisateur - ayant des mots de passe !) |
guest ok | No | Mettez Yes si vous souhaitez autoriser des invités à accéder à cette ressource. |
browseable | Yes | Mettez No si vous souhaitez cacher cette ressource lors de l'affichage par le voisinage réseau de Win$$$ |
available | Yes | pour partager une ressource, celle-ci doit être disponible. |
Puis validez, en cliquant sur <Commit Changes>. On peut alors tester notre partage :
[fred@bwing /home/fred]$ smbclient \\\\etoile-noire\\partage_samba -U truc
Added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0
Password: ******* (en fait rien ne s'affiche)
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.5a]
smb: \> exit (pour quitter smbclient)
[machin@bwing /home/machin]$ smbclient \\\\etoile-noire\\partage_samba
Added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0
Password: ******* (en fait rien ne s'affiche)
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.5a]
smb: \> exit (pour quitter smbclient)
Pour tester plus avant votre serveur SAMBa il faut alllez voir les commandes de smbclient.
Zone de saisie : | Valeur : | Commentaires : |
comment | Les belles imprimantes | sans commentaires ;-) |
path | /tmp | vous devez mettre un répertoire qui devra être accessible à l'utilisateur connecté à cette ressource : par exemple vous pouvez mettre n'importe quel répertoire qui est accessible en écriture par tout le monde - chez moi c'est le cas de /tmp) |
guest account | (rien) | ne mettez rien ou un utilisateur qui a le droit d'imprimer (sinon mettez guest ok à false). |
guest ok | True | on va imprimer en tant qu'invité. |
available | True | sauf si vous ne souhaitez pas imprimer ! |
Puis validez vos changement en cliquant sur Commit Changes. Pour voir si cela fonctionne tapez, depuis n'importe compte utilisateur :
[darkvador@etoile-noire home]$ smbclient -L etoile-noire Added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0 Password: (Aucun mot de passe : validez par <Entrée> !) Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.5a] Sharename Type Comment --------- ---- ------- zipdrive Disk Lecteur Zip samba-public Disk Repertoire public IPC$ IPC IPC Service (Serveur Linux/Samba) deskjet Printer lp Server Comment --------- ------- ETOILE-NOIRE Serveur Linux/Samba WINDAUBE98 Workgroup Master --------- ------- WORKGROUP WINDAUBE98Hourra ! Hourra ! Et dire que certains pensent encore que Linux est plus compliqué que Win$$$ ! ;-)
Si vous ne voyez pas votre machine : c'est que WINDAUBE est mal configurée : vous devez l'avoir configurée pour qu'elle utilise TCP/IP comme protocole réseau ! Il faut par exemple que le masque de réseau soit le même que celui de votre serveur SAMBA (Ce n'est peut-être pas une obligation, mais je n'ai pas assez de PC pour faire le test!)
Voilà c'est tout ! Lisez des fichiers, essayez d'écrire là où vous avez le droit, installez l'imprimante comme d'habitude (en cliquant avec le bouton droit sur la ressource imprimante), imprimez des fichiers depuis votre traitement de texte favoris, des images depuis votre programme de dessin chéri : tout doit fonctionner !
Attention : Les ressources d'impression de SAMBA n'effectue aucune traduction, elle envoie directement à l'imprimante les données reçues du client. Si vous souhaitez que cela change, je vous conseille de rajouter une entrée dans le fichier /etc/printcap de façon cette nouvelle entrée fasse systèmatiquement une traduction (par exemple passe par ghostscript), et d'imprimer sur cette imprimante.
En ce qui concerne le mot de passe qui va vous être demandé, vous pouvez mettre n'importe quoi : il ne sera pas vérifié ! Cette connection semble avoir lieu en tant qu'invité.smbclient -L serveur-samba
Pour vous connecter à la ressource ressource-samba du serveur serveur-samba tapez :
ousmbclient \\\\serveur-samba\\resource-samba -U utilisateur
Ne précisez pas d'utilisateur si vous lancez cette commande avec les droits nécessaires. Après vous être connecté à cette ressource, vous pouvez envoyer des fichier par put, en récupérer par get. Si la ressource est une imprimante, vous pouvez imprimer en utilisant print.smbclient "\\serveur-samba\resource-samba" -U utilisateur
Attention : quand vous imprimer sur une ressource Win$$$ ou SAMBA, le fichier n'est pas interprété par le serveur ! Donc, si vous voulez imprimez un document, il faut le transformer pour le rendre compatible avec votre imprimante ! Avec Linux, c'est habituellement le travail de ghostscript. Supposons, par exemple, que vous souhaitiez imprimer depuis votre machine qui tourne sous Linux sur une imprimante qui est partagé par un serveur smb (SAMBA ou Win$$$), il faut que vous sachiez quel est le type de l'imprimante (marque, et numéro etc...), puis vous devez transformer les données que vous souhaitez imprimer pour cette machine, puis envoyer le résultat à la ressource partagée par smbclient. Comme ce n'est pas d'un grand intérêt (pour nous autres fans de Linux) d'imprimer sur un serveur NT (d'autant que je ne possède pas NT), je n'ai jamais fait l'expérience, mais la documentation de SAMBA prétend que ce n'est pas très compliqué (voir la HOWTO)
On quitte smbclient par quit.
Evidemment elle ne marche pas seulement avec les serveurs SAMBA, vous pouvez, avec cette commande rapatrier un fichier depuis une machine Win$$$ sans installer sur cette dernière un serveur ftp (ce qui est problèmatique si vous n'avez que le CD de Win$$$, puisque Win$$$ ne fourni pas en standard de serveur ftp, les rats...)
Une autre utilisation de cette commande : vous êtes root, et souhaitez qu'un utilisateur particulier ait un mot de passe vide : SWAT ne l'acceptera pas ! En tant que root, tapez :
Et modifiez le fichier /etc/smb.conf de façon que la section [global] contienne la ligne :smbpasswd -n utilisateur
Maintenant, utilisateur a un mot de passe vide !null passwords = Yes
A propos de mot de passe, si vous vous êtes connecté sous Win$$$ avec un nom d'utilisateur qui n'est pas reconnu par Linux, mais que vous connaissez un login/password du serveur SAMBA vous pouvez demander de vous connecter à la ressource "\\serveur\ressource%utilisateur". (Attention à <"> et <">) S'il y a un mot de passe, il vous sera demandé, et dans tous les cas vous serez connecté à cette ressource comme si vous étiez utilisateur.
# mount \\\\etoile-noire\\ressource /mnt -o username=truc password=**
Puis vous pouvez utiliser votre ressource smb comme si c'était une partie normal de votre système de fichier. Evidemment, le système des permissions UN*X ne fonctionne pas sur ce type de montage (ne perdons pas de vue que, à la base, on utilise un protocole destiné à Win$$$), préférez leur un montage nfs qui permet de monter un vrai système de fichiers Linux.
S'il vous dit que tout est Ok, vous pouvez relancer SAMBA pour prendre vos modifications en compte.testparm
Et vous saurez tout.testparm /etc/smb.conf machine
Note: Avec SAMBA 2.0.7 j'ai un problème, tesparm me répond que l'hote depuis lequel j'utilise SWAT est autorisé, mais SWAT refuse la connection, alors je ne comprends pas ... si quelqu'un connait la réponse à ce mistère.
tar xzf LinNeighborhood-0.4.4.src.tar.gzEt voilà c'est tout, ce n'est pas la mer à boire et la version que vous avez maintenant sur votre machine est compilé spécialement pour elle (ça lui fait une belle jambe...). Evidemment, vous pouvez préférer installer une version précompilée, en ce cas reportez vous à l'installation d'un paquetage pour votre distribution.
cd LinNeighborhood-0.4.4.src/src
make
cp LinNeighborhood /quelque/part/dans/le/path
LinNeighborhoodLa configuration se fait en utilisant le bouton : <Prefs>. Le plus simple est de préciser WORKGROUP dans la zone : Scan\Workgroup (où WORKGROUP est le nom du group de travail de votre serveur SAMBA). Les autres options de la boite de dialogue s'expliquent toutes seules. Puis sauvez la configuration, cliquez sur l'onglet <Programs> et choisissez la version de SAMBA que vous utilisez. Sauvez la configuration. Cliquez sur l'onglet <Post Mount> , choisissez un gestionnaire de fichier prédéfini (en cliquant sur la flèche noire) ou bien définissez le votre. Sauvez une dernière fois la configuration. Et quittez la boite de dialogue de configuration.
A partir de là, vous pouvez, depuis la fenetre de LinNeighborhood, parcourir le réseau comme vous le feriez avec Win$$$ (ou presque). Mais, vous allez etre confronté à un problème : pour accéder à une ressource réellement, LinNeighborhood vous envoie le message : "smbmount not found", la raison est simple : smbmount ne peut fonctionner qu'avec les privilèges de root. Donc, pour que cela fonctionne depuis un compte utilisateur il faut rendre SUID les programmes : smbmount, smbumount et smbmnt.
chmod +s /usr/sbin/smbmountMais cela ne suffit pas, le programme smbmount essaie de lancer le programme smbmnt mais celui-ci ne ce trouve pas dans le PATH d'un utilisateur standard (il est dans /usr/sbin !). Solution créer un petit script que vous metterez dans un répertoire de votre PATH :
chmod +s /usr/sbin/smbmnt
chmod +s /usr/sbin/smbumount
#!/bin/shque vous appelerez : smbmount-user. Et un autre :
export PATH=$PATH:/usr/sbin
smbmount $*
#!/bin/shque vous appelerez : smbumount-user. Puis vous cliquez à nouveau sur le bouton <Prefs> de LinNeighborhood et dans l'onglet <Programs>, vous modifiez les entrées concernant smbmount et smbumount de façon à ce qu'elles deviennent respectivement smbmount-user et smbumount-user. Et là tout fonctionnera comme sur des roulettes.
export PATH=$PATH:/usr/sbin
smbumount $*
smb://user@serveur/pour accéder au serveur "serveur" en tant que "user".
ou
smb://user:password@serveur/
Guillaume Pierronnet
NFS, ou le partage des ressources selon Unix.
ATTENTION !
Comme toute application réseau, NFS ouvre des trous dans la sécurité
du système. Je t'invite donc à consulter les liens à
la fin de cet article pour des précisions sur la sécurité.
NFS file system support et Provide NFSv3 client support
CONFIG_NFS_FS=y ou m CONFIG_NFS_V3=y
NFS server support et Provide NFSv3 server support
CONFIG_NFSD=y ou m CONFIG_NFSD_V3=y
On va aussi installer le wrapper TCP pour un minimum de sécurité. Toujours sur ma Debian, le paquet s'appelle tcpd. Les sources se trouvent ici.
répertoire machine1(option11,option12) machine2(option21,option22)
par exemple :
/home 192.168.0.10(rw) 192.168.0.25(ro)
signifie que l'on autorisera la machine 192.168.0.10 à accéder à notre répertoire /home en lecture et écriture (rw) ainsi que la machine 192.168.0.25 mais uniquement en lecture (ro).
Un point important, pour un bon fonctionnement : tu dois avoir les mêmes
numéros de groupes et d'utilisateurs sur les deux machines.
Des systèmes permettent de gérer çà, NIS
(assez ancien) ou LDAP (plus récent). Avec peu d'utilisateurs, tu
peux tout simplement éditer /etc/group et /etc/passwd
pour synchroniser ces numéros.
Il n'est pas recommandé d'exporter un système DOS ou VFAT
à cause de leurs absences de gestion multi-utilisateurs ; ils ne
sont pas fait pour être partagés avec NFS.
portmap:ALL lockd:ALL mountd:ALL rquotad:ALL statd:ALL
[service]: [IP de la machine client]Donc pour autoriser 192.168.1.34 à se connecter à un partage NFS, on écrira :
portmap:192.168.1.34 lockd:192.168.1.34 mountd:192.168.1.34 rquotad:192.168.1.34 statd:192.168.1.34On va pouvoir lancer les services ; sur ma Debian, je lance :
# /etc/init.d/nfs-server startLa commande rpcinfo -p permet de vérifier que les services fonctionnent. Elle devrait produire un résultat dans cet esprit :
cacahuete:~# rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 737 status 100024 1 tcp 739 status 100011 1 udp 851 rquotad 100011 2 udp 851 rquotad 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs 100005 1 udp 872 mountd 100005 2 udp 872 mountd 100005 1 tcp 875 mountd 100005 2 tcp 875 mountd cacahuete:~#Pour recharger les services NFS (par exemple après une modification du fichier de config) :
cacahuete:~# killall -HUP nfsdle serveur est prêt !
cacahuete:~# mount -V mount: mount-2.11h cacahuete:~#On va maintenant pouvoir monter notre partage!
cacahuete:~# mount mon.serveur.nfs:/home /mnt/home cacahuete:~#En principe tout devrait bien se dérouler.
Pour monter ce partage définitivement à chaque démarrage de la machine, éditons notre /etc/fstab:
# device mountpoint fs-type options dump fsckorder ... master.foo.com:/home /mnt nfs rw 0 0 ...
par DuF
Un exemple de configuration de proftpd
Tout d'abord, si je rédige cet article, c'est tout simplement que
j'ai moi-même eu des difficultés à me servir de ce logiciel
et j'ai eu énormément de problèmes pour trouver une
documentation précise, claire et en français pour ce logiciel.
J'en écris donc une qui même si elle n'est pas aussi claire
ou précise que voulue, a au moins le mérite d'être en
français, soyez conscient que ce n'est pas si mal :). Je tiens aussi
à préciser que dans cet article je vais parler de proftpd
et de sa configuration seulement par rapport aux besoins que j'ai eu à un moment donné, qui
étaient avant tout liés à une utilisation personnelle
et non professionnelle, afin de remplacer wu-ftpd
qui est par défaut
avec la plupart des distributions, si ce n'est tout les distributions (c'est
proftpd avec la Mandrake 8.2 que j'avais ;-). Donc pour moi, le besoin par rapport à un serveur FTP, c'était de pouvoir partager des
ressources que j'ai sur mon ordinateur et qui sont sur une partition FAT32
(ce fut un besoin à un instant T) mais aussi de donner la possibilité à un utilisateur de pouvoir
écrire dans un endroit bien précis, restreint en essayant de
suivre quelques règles de sécurité de base (qui sont vraiment de base)...
Je reprends cette documentation aujourd'hui pour prendre en compte quelques changements, remplacements de certains directives, pour corriger des erreurs (si si il y en avait :) ) et ajouter une partie concernant le mod_tls pour faire des transferts chiffrés (à ne pas confondre avec du transfert FTP over SSH). La version actuelle de proftpd servant de support à cette mise à jour, est la version 1.2.8.
Bon et bien là c'est vraiment simple, il faut une connexion internet (disons que c'est mieux pour récupérer la dernière version de proftpd sur le site www.proftpd.org ) et sinon si jamais il vous manque quelque chose, lors de l'installation tout ce qui vous manque sera indiqué et donc vous pourrez allez récuperer tout ce dont vous avez besoin sur internet. Pour ma part il me manquait 2 choses, comme il indique à la fin précisément ce qui manque, avec même un lien internet de la ressource manquante, il faut juste quelques minutes pour répondre aux besoins de proftpd. Si je ne rentre pas plus dans le détail pour cette partie c'est tout simplement que les ressources nécessaires à proftpd dépendent totalement de votre configuration et de votre distribution, donc je pourrai en mentionner alors que vous n'en aurez pas besoin et en oublier alors que vous en aurez besoin... Donc pas la peine de vous envoyer sur de mauvaises pistes, lisez juste le message d'erreur lors de l'installation et il n'y aura pas de souci.
Je vous conseille de prendre la dernière version (actuellement la 1.2.8 est la dernière version stable), pour l'installer, c'est comme d'habitude :
tar zxvf proftpd-1.2.8.tar.gz
Ensuite on se place dans le répertoire nouvellement créé,
on lit bien le fichier d'installation (INSTALL ou README) et on lance les
commandes habituelles.
Il est possible de récuperer le package proftpd sous la
forme de package, il n'est pas la peine d'expliquer cela.
Tout d'abord dans la configuration de proftpd il n'y a qu'un seul
fichier qui rentre en ligne de compte, c'est : /etc/proftpd.conf
(le chemin peut être différent suivant votre distribution et/ou distribution).
C'est dans ce fichier que vous allez "tout" définir (enfin presque) concernant la configuration du serveur. Mais attention, cela concerne la configuration du serveur, ce n'est pas ici que vous allez définir les utilisateurs qui ont accès ou non au serveur (du moins en parti). Occupons nous tout d'abord des utilisateurs !
Attention, tous les utilisateurs se connectant sur le serveur proftpd doivent exister réellement sur le système (avec un uid). Il est cependant de faire un
alias d'un utilisateur n'existant vers un utilisateur existant, pour cela regarder l'exemple concernant le contexte de configuration
anonyme. avec l'explication sur le UserAlias
. Noter aussi que pour ma part j'ai fait le choix de créer les utilisateurs avec un "faux shell"
plutôt que de faire des alias, mais j'explique cela juste après.
Avec proftpd on a le choix dans sa stratégie. J'ai choisi
d'utiliser le fichier /etc/ftpusers
pour définir tous les
utilisateurs qui n'ont pas accès au service FTP. Tous les utilisateurs
présent dans ce fichier ne pourront donc en aucun cas se connecter
au service FTP.
Vous pouvez indiquer à proftpd d'utiliser le fichier /etc/ftpusers avec la directive :
UseFtpUsers
Mais par défaut il le fait, donc vous pouvez vous servir de /etc/ftpusers
sans dire explicitement dans le fichier proftpd.conf
que vous souhaitez
vous en servir, sans utiliser la directive UseFtpUsers
donc (j'espere
que vous suivez, toute façon j'y reviendrai après).
Pour ma part j'ai laissé le fichier /etc/ftpusers
comme il était
en ajoutant tous les utilisateurs qui ont un shell sur ma machine, voici
un exemple de fichier /etc/ftpusers
:
root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
gopher
postgres
squid
gdm
htdig
dhcpd
...
...
...
nobody
anonymous
DuF
ftp
Vous remarquerez que l'utilisateur anonymous
est indiqué,
c'est tout simplement que je ne souhaite pas donner un accès anonyme,
si vous n'avez pas utilité d'un accés anonyme, je vous conseille
d'ajouter, vous aussi, anonymous
dans le fichier /etc/ftpusers
.
Sinon comme je l'ai dit plus haut, j'ai choisi que tous mes utilisateurs ayant un shell (ksh, bash...) n'aient pas accès à mon serveur FTP, je vais donc créer des utilisateurs spécifiquement pour l'utilisation du FTP. Ces utilisateurs que je vais créer n'auront pas de shell leur permettant de se connecter en telnet, etc... Pour cela, j'indique le shell suivant :
/bin/false
Pour que ce shell soit "valide", il faut indiquer dans le fichier /etc/shells
la ligne /bin/false
si cela n'a pas déjà été
fait. Car proftpd par défaut n'accepte pas la connexion si
le shell de l'utilisateur n'est pas "valide" donc indiqué dans
/etc/shells
(bien sûr on se sera assuré que le shell en question existe effectivement dans l'arborescence). Si le fichier /etc/shells
n'existe pas, par contre
il accordera la connexion (personnellement j'ai trouvé ça étonnant,
mais il doit y avoir des raisons à cela, il faut donc en tenir compte).
De plus vous pouvez spécifiez lors dans la configuration de proftpd.conf
si vous souhaitez que proftpd vérifie que les utilisateurs
aient oui ou non un shell valide. Cela se fait par la directive : RequireValidShell
(qui prend comme argument on ou off !)
Sinon concernant la création des utilisateurs, pour cela je vous
renvoie aux tutoriaux déjà présents sur léa, si
je devais faire une recommandation, c'est de créer un groupe unique
qui servira à placer tous les utilisateurs avec le shell /bin/false
dedans, cela peut s'avérer utile par la suite, et de toute façon
il n'est pas utile de créer un groupe pour chaque nouvel utilisateur.
Pour la création pur et dur des utilisateurs, vous pouvez faire un adduser ou useradd, pour plus d'options c'est très simple, il faut faire man adduser :) ou sinon maintenant, il existe des outils graphiques qui le font aussi, donc en récapitulant, vous créez les "users" par exemple user1 et user2 et vous les mettez dans le groupe ftptest.
Voilà déjà pour la partie spécifiques aux utilisateurs
(users), je vais en reparler dans la partie du fichier proftpd.conf
.
On entre dans le vif du sujet.
Tout d'abord le fichier proftpd.conf
se divise en plusieurs parties, qui ne sont pas toutes nécessaires (vitales). Je vais essayer,
pour garder une cohérence avec la documentation en ligne du site www.proftpd.org de reprendre les mêmes
terminologies, on a donc plusieurs contextes de configuration :
server config, <Global>, <Anonymous>, <VirtualHost>, <Limit>, <Directory>, .ftpaccess
Donc pour résumé sur les contextes de configuration, on peut avoir un fichier proftpd.conf avec seulement le contexte : server config.
Si le contexte "server config" n'est pas entre <> c'est tout simplement qu'il est implicite, ce n'est pas utile de le mentionner. Notez aussi que les options qui sont à l'intérieur des contextes de configuration sont les directives !
On commence par un fichier proftpd.conf ne contenant qu'une directive et le contexte de configuration obligatoire qu'est "server config".
#début du fichier profptd.conf
UseFtpUsers off
#fin du fichier proftpd.conf d'exemple, pour info ce fichier en l'état n'est pas valide
On peut dire que tous les contextes de configuration sont forcément inclus dans le contexte "server config" et que l'on peut avoir un contexte comme <Directory> qui soit dans un "sous" contexte comme <Anonymous>. C'est un principe de configuration imbriquée.
Les premieres directives que l'on va avoir dans le fichier proftpd.conf
vont concerner le mode de lancement du serveur et les infos le
concernant.
ServerName "Server
FTP du DuF"
ServerType standalone
DefaultServer on
ServerName
=> je ne reviens pas dessus
ServerType
=> est important (indispensable) car il indique si le serveur est démarré par vos soins en faisant :
/etc/init.d/proftpd start
(ou /etc/rc.d/init.d/proftpd start
).
Ou alors si il a la valeur inetd
il est démarré par le meta-daemon du même nom (qui peut selon les distributions être
xinetd
au lieu d'inetd
, mais il faut quand même laisser inetd
dans le fichier proftpd.conf
,
car xinetd
sera interprété comme un mauvais paramètre).
DefaultServer
=> cela est utile si vous faites des virtualhost,
si vous n'utilisez qu'un "server config" sans virtualhost alors ce n'est
pas utile de l'indiquer. En fait cette directive vérifie qu'elle configuration
du serveur sera prise en compte (soit server config ou un des virtual hosts,
ou anonyme....) Si il n'y aucune configuration de prévue, "l'inconnu"
aura le message suivant : "no server available to service your request"
et déconnecté.
Ensuite nous passons à des options dont l'utilité est très simple à comprendre :
AllowStoreRestart on
Port 45000
Umask 022
MaxInstances 30
AllowStoreRestart
=> permet d'autoriser les clients
à reprendre les uploads vers vous, ce n'est pas cette directive qui
leur permet de reprendre quand ils téléchargent depuis votre
serveur. Donc cette option, AllowStoreRestart n'est utile que si
vous autorisez au moins une personne à écrire chez vous.
Port
=> je passe, simple à comprendre sinon je me demandes
ce que vous faites là :) c'est bien évidemment le numéro
de port sur lequel le client se connecte.
Umask
=> c'est comme dans unix en général, 022
est une valeur qui est bien, donc laissez-là à 022, si vous
voulez en savoir plus sur umask en général, consultez notre
ami à tous : www.google.fr/linux
MaxInstances
=> comme c'est indiqué dans le fichier par
défaut de proftpd.conf
, cela sert à spécifier
le nombre de processus fils maximum que va gérer (utiliser) proftpd
, et comme indiqué, au delà d'une valeur de 30 vous être
vulnérable à des attaques de type Ddos, donc laissez à
30, pour une utilisation, sincèrement c'est largement suffisant.
Ensuite viennent 2 paramètres très important, on va indiquer sous quel utilisateur le serveur FTP est lancé, il ne s'agit donc pas de mettre root :)
Le user nobody
et le group nogroup
sont les paramètres par défaut et à mon avis ils sont très bien,
donc on n'y touche pas car il faut que l'utilisateur qui lance le serveur n'ai pas trop de privilèges.
Ensuite il est question de l'option PersistentPasswd
, dont l'utilité ici est pas évidente à expliquer étant
donner que je n'ai pas compris l'explication sur le site de proftpd, je l'ai laissé à off
. En fait si je me trompes pas, en le
mettant à on
cela permet à proftpd de chercher lui même dans /etc/passwd
la validité des mots de passe,
mais c'est à vérifier.
Ensuite vient une option qui a mon avis est très importante pour les personnes qui comme moi veulent partager une petite connexion adsl, il faut limiter le nombre de tentatives de logins (l'adsl ça sature vite :p) :
MaxLoginAttempts 3
Ensuite nous avons une option pas du tout vitale mais sympa je trouve, cela concerne la personnalisation de votre serveur, tout du moins le message d'accueil :
AccessGrantMsg "Bienvenue %u chez DuF...."
Vous remarquerez le %u, c'est un paramètre qui recupère le user qui se connecte et le remplace en lieu et place de %u. Cette option indique le message de bienvenue quand l'utilisateur a réussi à se connecter.
Pour ne pas donner d'info précise sur le serveur, je conseil de mettre à on l'option suivante :
DeferWelcome on
Maintenant on va indiquer un contexte de configuration Limit qui va s'appliquer au contexte de configuration server config (partie générale du serveur) plus concrètement, c'est à dire tous ceux qui vont se connecter et qui ne seront pas concernés par un virtualhost. En fait ce contexte de configuration est utile (très important) pour tous ceux qui souhaitent partager des données sur des partitions FAT32 par exemple tout en limitant les possibilités (écriture, création de repertoires...)
Pour cela j'ai utilisé le contexte de configuration Limit avec les directives suivantes :
<Limit MKD RNFR RNTO DELE RMD STOR CHMOD SITE_CHMOD SITE XCUP WRITE XRMD XPWD>
DenyAll
</Limit>
Bon moi j'en ai mis beaucoup pour l'exemple, je vais juste en expliquer certaines :
MKD
: création de répertoireRNFR
: (rename from) empêche de pouvoir renommerRNTO
: (rename to) c'est la suite de RNFR en fait, donc si RNFR est interdit, ce n'est pas util de le mettre, mais bonDELE
: suppression de fichiersSTOR
: écriture de fichiers depuis un client vers notre serveur proftpdCHMOD
: changement de permission sur les fichiers (et répertoires)RMD
: suppression de répertoireIl est aussi possible d'utiliser des mots clefs comme READ
et WRITE
qui englobent plusieurs commandes, et vont limiter
l'accès en lecture et en écriture. Pour le reste des options vous pouvez consultez les commandes de la section
Limit sur le site de www.proftpd.org
Là on arrive à une section relativement importante, le contexte de configuration <Global>
En effet ce contexte de configuration peut être utilisé à l'intérieur de la "server config" et du contexte de configuration <VirtualHost>
Tout ce qui va être défini dans <Global> va être appliquer à l'ensemble du contexte de configuration dans laquelle <Global> se trouve. Cela est donc très pratique lorsque l'on a défini des <VirtualHost> car nous n'aurons pas à redéfinir plusieurs fois les mêmes paramètres.
Le mieux est de passer directement à un exemple de contexte de configuration <Global> :
<Global>
DefaultRoot ~
AllowOverwrite yes
MaxClients 3
MaxClientsPerHost 1
UseFtpUsers on
AllowForeignAddress on
ServerIdent on "ProFTP
DuF's Server Ready"
AccessGrantMsg "Bienvenue
%u sur le serveur du DuF"
</Global>
DefaultRoot
=> Limite le user à son home directory, si
son home directory est par exemple /home/user, il pourra se ballader dedans,
mais ne pourra remonter plus haut, il ne pourra pas aller dans /home par
exemple et quand il se connecte, le user voit comme path dans son client
FTP le chemin /
AllowOverwrite
=> Cela permet de remplacer d'anciens fichiers
par les nouveaux, option inutile si vous interdisez l'écriture. J'indique
différentes possibilités pour l'option, mais c'est à
vous d'être cohérent. De toutes façons, si vous interdisez
l'écriture, cette option ne prendra pas le dessus, vous ne pourrez
pas écraser les fichiers.
MaxClients
=> C'est pour dire le nombre de clients différents
qui peuvent se connecter en même temps sur le serveur, si vous avez
une connexion ADSL, pas la peine de mettre 50...
MaxClientsPerHost
=> Option que je trouve très utile,
elle limite le nombre de clients pour la même personne, si vous utilisez
l'option MaxClients, il faut forcément que MaxClientsPerHost soit
strictement inférieur (ou <=) à MaxClients sinon cela ne
sert à rien.
UseFtpUsers
=> C'est dire que l'on utilise ou non le fichier /etc/ftpusers
pour savoir qui a le droit
d'utiliser le service FTP. Par défaut proftpd utilise le fichier, donc l'option n'est pas utile si on la met à on, mais moi
j'ai préféré la mettre, c'est un choix ;-)
AllowForeignAdress
=> Alors cette option sert à autoriser
ou non le fait que quelqu'un envoie ou télécharge des fichiers
sur notre serveur FTP depuis un autre ordinateur que le sien. Pour faire
simple, on va dire que la personne A veut transférer des fichiers
entre le serveur B et notre serveur C car A n'a pas de serveur mais il a
accès à B. Sans cette option mise à on cela n'est pas
possible que A puisse passer les commandes.
ServerIdent
=> Cette option permet d'indiquer quel sera le premier
message affiché quand quelqu'un essaiera de se connecter sur notre
serveur, et cela même si sa connexion échoue. Si vous mettez
cette option à "off" le client verra le message suivant : "[hostname]
FTP server ready.". Le hostname sera souvent localhost.localdomain si vous
ne l'avez pas modifié. Moi je vous invite à mettre cette option
à on et mettre la chaine de caractere que vous souhaitez mais qui
ne donne pas trop d'indication non plus sur votre serveur. Dans mon exemple
j'ai mis un message explicite, mais c'est juste un exemple, un message comme
"Server Ready" sera tout aussi bien.
AccessGrantMsg
=> C'est là que vous définissez
le message d'accueil lorsque la connexion a réussie, donc si vous
le mettez dans un contexte de configuration <Global>
pas la peine de le mettre à un autre endroit (server config, virtual
host....)
Voilà pour la partie Globale, avec déjà toutes ces infos, vous êtes en mesure de partager grâce à votre serveur FTP des données en ayant bien le contrôle de ce qui se passe. Et surtout vous pouvez donnez l'accès à des données qui sont sur des partitions FAT32 (mais aussi n'importe quel type de patition ext2, reiserfs etc...), partitions qui normalement vous empêche de définir une stratégie utilisateur, car si vous avez besoin d'écrire sur des partitions FAT32, et donc que vous les montez en lecture/écriture, vous seriez embêté lors de l'accès par FTP car tout le monde pourrait écrire, supprimer, créer, faire ce qu'il veut en somme sur ces partitions, ce que pas grand monde souhaite. Donc grâce au contexte de configuration <Limit> des commandes, vous empêchez que l'on puisse toucher à vos données (autrement qu'en lecture) ce qui est intérêssant pour ceux qui ont encore un multiboot.
Maintenant vous vous dites mais j'aimerai quand même qu'une personne puisse accéder en écriture chez moi, même sur une partition ext2, mais vous dites que maintenant ce n'est plus possible, car on ne peut plus passer les commandes comme MKD, STOR, DELE.... Et bien trompez vous, nous allons créer un VirtualHost, terme que certains doivent connaître car c'est le même principe pour le serveur Web Apache.
Maintenant on sait comment marche le fichier, donc dans <VirtualHost> le principe va être le même que pour Global etc... On va définir des options à l'intérieur du contexte de configuration <VirtualHost>.
Premièrement il faut savoir que <VirtualHost> à la base est prévu pour un serveur par exemple qui pourra être accessible d'un côté par des personnes s'y connectant depuis internet et d'autres qui s'y connecteront depuis le réseau local et l'on souhaite que ceux qui s"y connectent depuis internet n'aient pas accès aux même données que ceux qui s'y connectent depuis le réseau local. Donc ces différents personnes vont se connecter sur le serveur en indiquant une adresse différente. Par exemple l'utilisateur A est chez lui sur internet, il veut se connecter, pour cela il indique l'adresse suivante : ftp.serveur_proftpd_internet.com
Une autre personne, B, va elle se connecter sur ce serveur depuis le lieu de travail, donc depuis le réseau local, elle va utiliser l'adresse interne qui sera l'adresse : ftp.serveur_proftpd_local.com
On a donc ftp.serveur_proftpd_local.com qui dirige vers l'adresse IP 192.168.10.10
et le ftp.serveur_proftpd_internet.com qui dirige vers l'adresse IP 159.159.159.159.
Ces 2 adresses IP dirigeant vers la même machine. Il est possible de
spécifier le même port (ou de ne pas le spécifier, le
port sera celui défini dans le contexte de configuration
server config
, cela ne posant pas de problème car proftpd
va regarder dans son <VirtualHost> et tout se fera par rapport à
l'adresse qui aura été indiquée pour la connexion.
Il est aussi possible de faire plusieurs <VirtualHost> qui travaillent sur la même adresse IP mais qui ont un port différent ce qui peut être très pratique aussi. Mais attention, cela d'après le site www.proftpd.org est incompatible avec "ServerType inetd" c'est à dire lorsque l'on lance le serveur par le démont inetd, personnellement je n'ai pas testé donc je ne pourrai pas vous en dire plus, moi je l'ai juste testé en "ServerType standalone"
# Serveur Virtuel pour écriture
<VirtualHost ftp.serveur_proftpd.com>
ServerName "Mon
serveur FTP virtuel"
Port 46000
Maxclients 3
MaxClientsPerHost 1
DefaultRoot ~
AccessGrantMsg "Bienvenue
%u sur le serveur virtuel du DuF"
<Limit LOGIN>
AllowUser ToTo
DenyAll
</Limit>
</VirtualHost>
Bon alors les options vous les connaissez toutes, par contre je vais expliquer le contexte de configuration <Limit LOGIN> :
Avec ce contexte de configuration on va indiquer quel(s) utilisateur(s) va(ont) pouvoir se connecter dans ce virtual Host, c'est à dire que ceux qui ont accès par exemple au service FTP en lecture par une connexion sur le port 45000 ne peuvent pas se connecter sur ce virtualhost, dans notre exemple, il n'y a que l'utilisateur ToTo qui puisse le faire.
Donc pour que ToTo se connecte il doit indiquer l'adresse IP ftp.serveur_proftpd.com
et le port 46000, ce sont les deux conditions à remplir, sinon cela
ne marchera pas. Il faut savoir donc qu'il y a un ordre entre AllowUser
et DenyAll
à ne pas négliger. Mais il est possible
de l'inverser.
En fait ProFTPD va examiner les autorisations explicites, puis les interdictions. Si une connexion ne correspond à aucun des critères, elle est autorisée. Il est possible d'inverser cela en utilisant la commande Order deny,allow. Si elle est présente, le serveur va d'abord prendre en compte les commandes Deny, suivi des commandes Allow, et interdire toute autre connexion ce qui peut être pratique, car dans ce cas là, si jamais votre rêgle n'est pas infaillible ou que vous avez oubliez une possibilité, et bien vous êtes sûrs que de toute façon la connexion sera refusée.
A noter aussi qu'il existe des options comme AllowGroup
etc.... je vous invite à visiter le site de proftpd pour plus de
renseignements.
Sinon juste pour l'exemple, un autre virtualhost, dans le cas ou le serveur est en type standalone
et qu'on a donc sur la même IP
plusieurs virtuelhost mais sur des ports différents.
<VirtualHost ftp.serveur_proftpd.com>
ServerName "Mon serveur FTP virtuel"
Port 47000
MaxClients 3
MaxClientsPerHost 1
DefaultRoot ~
<Limit LOGIN>
AllowUser Foo
DenyAll
</Limit>
</VirtualHost>
Contextes de configuration : <Anonymous>
et <Directory>
Le contexte de configuration <Anonymous>
comme son nom l'indique sert à configurer un accès anonyme
au service FTP et le contexte de configuration <Directory>
, permet de définir un contexte pour les
répertoires, il est possible de les utiliser comme suit :
<Anonymous /home/ftp>
MaxClients 5 "Nombre de clients maximum atteints : 5"
User ftp
Group ftp
<Limit WRITE>
DenyAll
</Limit>
<Directory uploads/*
<Limit READ>
DenyAll
</Limit>
<Limit STOR>
AllowAll
</Limit>
</Directory>
</Anonymous>
Suite à une remarque de Drinou, voici une précision sur le contexte de configuration <Anonymous>
et surtout sur la directive
UserAlias
, si jamais vous voulez que la connexion anonymous se fasse avec un user qui n'existe pas sur votre système, vous devez utiliser
les UserAlias, vous pouvez vérifier votre configuration avec l'exemple suivant :
<Anonymous /home/e-smith/files/primary/html/download>
Group public
User public
UserAlias anonymous public
UserAlias ftp public
AnonRequirePassword off
MaxClients 10
<Limit WRITE>
DenyAll
</Limit>
<Directory upload/*>
<Limit READ>
DenyAll
</Limit>
<Limit STOR>
Allow All
</Limit>
</Directory>
</Anonymous>
Donc dans cette exemple nous voyons que les users anonymous et ftp n'existant pas sous notre OS sont "aliasés" avec le user public qui lui existe réellement. Cela permet donc aux clients de se connecter avec le compte anonymous sans que celui-ci n'existe réellement sur le système.
Contexte de configuration : .ftpaccess
Pour ce dernier je n'aurai pas d'info à vous donner n'ayant pas trouvé son utilité et la manière de s'en servir (surtout que je n'en ai pas eu besoin...)
Il faut savoir qu'il est possible de filtrer pas adresse IP, cela est pratique dans un réseau local à IP fixe ou lorsque le client a une IP fixe, mais je ne saurai que trop vous déconseillez de mettre une filtre sur un nom de domaine, ou un redirecteur pour des raisons évidentes de sécurité même si cela peut paraitre une solution de facilité.
Voici un exemple de filtrage par adresse IP sur une IP (172.16.18.5) et une classe d'adresse IP (192.168.10.x) :
<Limit LOGIN>
Allow 172.16.18.5 192.168.10.
Deny all
</Limit>
Depuis la version 1.2.8 de proftpd, la gestion de la Bande Passante n'est plus la même. Auparavant on utilisant des directives comme RateReadBPS
et ReadWriteBPS
notamment (il y en avait d'autres), maintenant il existe en fait une seule directive (TransferRate
) qui sert à la
fois à définir l'upload et le download par exemple.
Voici un exemple de gestion de la Bande Passante avant la version 1.2.8 :
(.....)
MaxClientsPerHost 1
RateReadBPS 12000
RateWriteBPS 63000
(.....)
A noter que la valeur était défini en octets, mais maintenant cela a changé, depuis la version 1.2.8 c'est TransferRate qu'il faut utiliser. Plutôt que de parler longuement, voici un exemple comment l'utiliser :
(.....)
MaxClientsPerHost 1
TransferRate RETR 12
TransferRate APPE,STOR 63
(.....)
Pour essayer de faire clair, en fait les 2 exemples font la même chose, le premier dans le cas des versions strictement inférieures à proftpd-1.2.8 et dans le second exemple, c'est pour les versions supérieures ou égales à la version proftpd-1.2.8. Donc RETR signifie Retrieve, ce qui correspond au fait de "récupérer" un fichier depuis le serveur, donc c'est le cas lorsqu'un utilisateur download. Pour APPE et STOR cela correspond à append et store, ce qui correspond au fait de "résumer" et "enregistrer" un fichier sur le serveur. Vous remarquez aussi que maintenant la valeur est en KiloOctets, et sachez que cette directive est valable dans tous les contextes de configuration.
Il faut noter que TransferRate ajoute d'autres options très intéressantes, comme le fait de d'allouer un seuil d'octets transférés avant que le contrôle du taux de transfert soit appliqué. Cela permet pour les clients transfèrant de petit fichier de ne pas être touché, mais ceux qui transfèrent de gros fichiers d'être limités pour donner la priorité à ceux qui transfèrent les petits fichiers. En gros ceux qui vont transfèrer des fichiers textes ne seront pas contrôlés à l'inverse de ceux transfèrant des fichiers de type iso par exemple. N'ayant pas testé je ne peux vous dire concrêtement si le transfert est stoppé ou seulement limité. Il est aussi possible de créer des groupes d'utilisateurs et de définir des limites de transferts pour ces groupes seulement. Cela permet de limite la BP pour certains mais pas par exemple l'administrateur, ce qui évite de faire plusieurs contextes de configuration.
Cette partie est totalement optionnelle et non nécessaire pour la plupart d'entre nous. Donc ici il va être question de chiffrer les communications (commandes, transferts...) lors de la session FTP, mais il ne s'agit pas réellement de crypter de bout en bout la connexion avec SSL, car dans l'exemple suivant il n'y aura pas d'échanges de certificats (clés) entre le client et le serveur, mais seulement authentifier, lister et transférer le tout de manière chiffré.
Première étape, créer les certificats, pour cela je vous renvoi vers d'autres articles que vous pourrez trouver en cherchant avec google ou alors directement en lisant le How-TO SSL Certificates. Une fois que vous avez créer votre certificat (le fichier .pem) nous pouvons configurer proftpd.
Tout d'abord il faut indiquer dans le contexte de configuration "Server Config" le type du protocole TLS ainsi que le chemin vers le certificat et aussi
ajouter la section concernant le module mod_tls
. Voici en exemple le type de configuration que vous devez avoir :
(...)
TLSProtocol SSLv23
TLSRSACertificateFile /home/proftpd/certs/cert-rsa-duf.pem
TLSRSACertificateKeyFile /home/proftpd/certs/cert-rsa-duf.pem
TLSCACertificateFile /home/proftpd/certs/cert-rsa-duf.pem
(...)
<IfModule mod_tls.c>
TLSEngine on
TLSLog /var/log/proftpd-tls.log
# Are clients required to use FTP over TLS when talking to this server?
TLSRequired on
</IfModule>
Là nous avons donc spécifier les différents chemins nécessaires vers le certificat, le protocole utilisé, l'activation du moteur TLS, le chemin vers le log spécifique au mod_tls et à quel type de requête le client doit répondre.
TLSProtocol
: Cela sert à définir quelle version de protocole mod-tls doit utiliser. A noter que cette directive ne peut être utiliser que dans
le contexte de configuration 'Server Config'. Les choix possibles ici sont TLSv1 (autorise seulement TLSv1), SSLv3 (autorise seulement SSLv3) et SSLv23 qui
autorise les deux (SSLv3 et TLSv1).TLSEngine
: Cela permet d'activé ou non le mod_tls
avec "on" pour "actif" et "off" pour "inactif" naturellement. Par défaut il
est désactivé à la fois pour le serveur principal et les virtualhosts.TLSLog
: Chemin vers le fichier log spécifique au mod-tls.TLSRequired
: Cela sert à définir une politique sécuritaire basique, si il est à "ctrl" alors SSL/TLS est requis sur le canal de contrôle, si
il est à "data" alors SSL/TLS est requis sur le canal de données (transfert des données), si il est à "on" alors SSL/TLS est requis sur les 2 canaux (données et
contrôle) et si il est à "off" alors SSL/TLS n'est requis sur aucun des 2 canaux.Voilà pour la partie configuration par défaut dans le contexte Server Config
, maintenant si vous avez en plus des virtualhosts et que vous
voulez faire des configurations spécifiques, par admettons que le mod_tls
soit désactivé pour l'ensemble du serveur, mais que vous voulez juste
l'activer pour un virtualhost précis, vous aurez alors une configuration proche de celle qui suit :
(...)
<VirtualHost ftp.duf_tls.com>
ServerName "FTP duf"
Port 6240
MaxClients 2
MaxClientsPerHost 1
TransferRate APPE,STOR 63
AllowForeignAddress on
AllowStoreRestart on
DefaultRoot ~
TLSRSACertificateFile /home/proftpd/certs/cert-rsa-duf.pem
<IfModule mod_tls.c>
TLSEngine off
TLSLog /var/log/proftpd-tls.log
</IfModule>
<Limit LOGIN>
AllowUser user_tls
DenyAll
</Limit>
<LIMIT MKD RNFR RNTO DELE RMD STOR WRITE SITE XCUP>
AllowAll
</Limit>
</VirtualHost>
Vous remarquez donc que la valeur de TLSProtocol n'est pas indiqué dans le contexte "virtualhost" car comme j'ai dit sa place est exclusivement dans le contexte "Server Config". Sinon comme vous pouvez le constater, afin de chiffrer une communication FTP, cela ne demande pas une grosse configuration dans le fichier proftpd.conf.
Attention, cette partie est très très succinte sur le sujet, et à moins que vous ne soyez pas déjà familier avec la création de certificats,
l'utilisation de mod_tls avec apache par exemple, cette partie sera très grandement insuffisante. Donc ne vous aventurez dans cette configuration que si vous
vous y connaissez déjà un minimum et documentez-vous au maximum avec les liens fournis tout en bas de cette page. De même un lien est fourni pour obtenir une
liste de client permettant de se connecter sur un serveur avec le mod_tls
activé.
Pour finir sur le fichier proftpd.conf
voici en grande partie le mien modifié :).
Je rappelles que moi je cherchai à la base (il y a longtemps maintenant :) ) pouvoir donner accès par service FTP à des ressources sur partition de type FAT32 et cela à la fois en lecture pour certains et en écriture pour d'autres et que je me suis vu confronté au problème qu'il n'est pas possible de définir de droits pour les utilisateurs sur les partitions FAT32.
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 DuF 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 :
TransferRate RETR 11
# To prevent DoS attacks, set the maximum number of child processes # to 30. If you need to allow more than 30 concurrent connections # 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 processes 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'acceuil après une connexion réussie
AccessGrantMsg "Bienvenue %u chez moi !"
# Pour ne pas donner d'info sur le serveur
DeferWelcome on
#Regles pour limiter les commandes...
<Limit MKD RNFR RNTO DELE RMD STOR CHMOD SITE_CHMOD SITE XCUP WRITE XRMD PWD XPWD>
DenyAll
</Limit>
<Global>
DefaultRoot ~
AllowOverwrite yes
MaxClients 3
MaxClientsPerHost 1
UseFtpUsers on
AllowForeignAddress on
ServerIdent on "ProFTP DuF's Server Ready"
AccessGrantMsg "Bienvenue %u sur le serveur du DuF"
</Global>
# Serveur Virtuel pour écriture
<VirtualHost ftp.duf.com>
ServerName "Mon serveur FTP virtuel numero 1"
Port 46000
Maxclients 3
MaxClientsPerHost 1
DefaultRoot ~
AccessGrantMsg "Bienvenue %u sur le serveur virtuel du DuF"
<Limit LOGIN>
AllowUser ToTo
DenyAll
</Limit>
</VirtualHost>
<VirtualHost ftp.duf.com>
ServerName "Mon serveur FTP virtuel numero 2"
Port 47000
MaxClients 3
MaxClientsPerHost 1
DefaultRoot ~
<Limit LOGIN>
AllowUser Foo
DenyAll
</Limit>
</VirtualHost>
Voilà pour ce qui est du fichier proftpd.conf
.
Alors là c'est plutot simple, deux cas de figure ! Soit vous avez indiqué dans le fichier proftpd.conf
que le serveur
démarre en standalone
ou par inetd
. Si c'est en inetd il faut relancer le démon inetd ou xinetd suivant votre
distribution. Pour le redémarrer faites :
/etc/rc.d/init.d/xinetd restart ; ftp localhost
Si votre serveur est en standalone vous faites simplement :
/etc/init.d/proftpd start
Sachez que vous pouvez passer les commandes start, restart, stop, status... à /etc/init.d/proftpd.
Sinon pour ceux qui veulent utiliser proftpd avec xinetd, voilà une marche à suivre :
il faut copier le fichier ftp.d vers proftpd en faisant :
cp /etc/xinet.d/wu-ftpd /etc/xinet.d/proftpd
Ensuite il faut éditer le fichier /etc/xinet.d/proftpd, comme l'exemple suivant :
service ftp
{
disable = no
flags = REUSE
socket_type = stream
instances = 10
wait = no
protocol = tcp
user = root
server = /usr/local/sbin/in.proftpd
}
Cette partie là je ne l'ai pas testé, donc si vous avez un problème renseignez-vous sur l'utilisation de xinetd
,
personnellement je n'en sais pas plus.
Lors de l'installation si vous rencontrez un problème de librairie,
avant de vous jeter sur votre navigateur web et de les chercher, il se peut
que cela vienne juste du fait de ne pas avoir /usr/local/lib
dans
votre chemin des librairies, ce qui fut mon cas. Dans ce cas ajoutez-le donc
dans votre /etc/ld.so.conf
et une fois ld.so.conf editez faites
un ldconfig -v
.
Si vous n'avez pas pris proftpd en package rpm/debian mais en source,et bien les chemins sont différents , le chemin d'installation est
/usr/local
et le fichier de configuration se retrouve dans /usr/local/etc/proftpd.conf
.
"J'ai des erreurs quand je veux installé proftpd, il me manque plein de choses..." Comme je l'ai dit, lisez les messages, ils sont très explicites, allez récuperer ce qui vous manque, n'essayez pas de forcer quoi que ce soit, ce ne sera jamais bon pour votre système de faire ça, et vous risqueriez de mordre la queue en somme.
Vous êtes sûr d'avoir correctement créé vos utilistateurs
mais ils ne peuvent pas se connecter, l'accès au service FTP leur
est interdit : vérifiez qu'ils ne soient pas dans la liste du fichier /etc/ftpusers
.
Vos utilisateurs ne sont pas dans le fichier /etc/ftpusers
mais
ils ne peuvent toujours pas se connecter, ils ont une erreur d'accès
refusé au password, cela peut venir soit d'un mot de passe erroné,
ou de leur répertoire home (leur path où ils sont censés
se connecter et arriver) qui est soit invalide, ou même non existant
sur votre système.
Je rappelle que cet article n'est pas la solution unique à l'utilisation de proftpd, surtout pas. Si vous voulez donner accès à des centaines d'utilisateurs, ayez une stratégie d'ensemble et utilisez les paramètres lié aux systèmes de fichiers, les permissions etc... Ce sera beaucoup plus simple à gérer et à mettre en place. Je le répète, cet article vous donne une idée des informations nécessaire à la configuration de proftpd et donne à mon avis toutes les informations nécessaires à la mise en place d'un serveur personnel pour le partage de ressources qui ne sont pas forcément toutes sur des partitions ext2 (linux). Voilà j'espère que cet article vous aura aidé !
Si jamais vous avez des précisions, des corrections à ajouter sur la partie concernant le mod_tls
n'hésitez pas car j'ai juste fait une
présentation très très légère du sujet, très incomplète et qui mérite d'être améliorer, alors si vous êtes expert en la matière, n'hésitez pas à corriger,
améliorer cette partie.
Ressources concernant le mod-tls
:
par DuF
Présentation rapide de profxp
tar zxvf profxp-v3-pre1-linux-glibc.tar.gzIl est possible que le nom du répertoire et/ou le nom de l'exécutable ne soit pas tout à fait le même, cela n'a aucune importance.
cd profxpv3
./profxp
Par Serge
Pour cette rubrique, des connaissances sur TCP/IP sont nécessaires, ainsi qu'un minimum de savoir-faire sur la configuration des paramètres TCP/IP d'une machine Linux/Unix (bien que j'essaye d'expliquer au maximum toutes les étapes).
C'est tout simplement ce qui sert à convertir des adresses noms en adresses
IP. Par exemple, quand vous tapez dans votre navigateur préféré l'adresse :
http://lea-linux.org
celui-ci va tout d'abord faire une requête à un
serveur DNS (généralement le serveur DNS que vous avez
configuré pour votre connexion à l'Internet, donc les serveurs DNS de votre
fournisseur d'accès) en lui demandant :
C'est quoi l'adresse IP de
lea-linux.org ?
Et le serveur DNS lui donne l'adresse IP et le navigateur va alors
se connecter à cette adresse IP et afficher le site.
Ceci est valable pour
toute autre application qui manipule des noms DNS (ftp, telnet, mail, ....).
Tout d'abord, il faut savoir que l'on peut remplir à la main un fichier, qui
s'appelle /etc/host, avec les correspondances "adresse IP et nom DNS des
machines". Donc si l'on a un petit réseau local de quelques machines, on peut
remplir ce fichier à la main. Mais dans le cas d'un réseau beaucoup plus
conséquent, il vaut mieux installer un serveur DNS.
Là où un
serveur DNS peut être utile aussi, c'est si vous partagez une connexion internet sur votre réseau
local. Vous installez sur la machine qui partage la connexion internet un
serveur DNS qui fait cache. De ce fait, toutes les machines qui vont se connecter via ce serveur à
l'internet vont demander la résolution d'adresse à votre serveur en interne
plutôt qu'aux serveurs DNS externes, ce qui va permettre de réduire le traffic réseau sortant. Bon, en fait pour les
premières connexions cela ne va servir à rien, car comme votre serveur DNS sera presque
vide, celui-ci va demander aux serveurs externes les réponses afin de remplir sa
base DNS. Mais comme votre serveur va stocker les réponses, au bout d'un moment, cela va accélérer
les réponses DNS, car c'est votre serveur local et non pas les serveurs externes qui vont répondre à ces
requêtes DNS.
Même dans le cas où vous n'avez qu'une machine "poste de travail" sous linux et que
vous vous connectez très souvent à l'internet, le fait d'installer là aussi un
serveur DNS sur votre poste va accélérer votre connexion, ce qui est assez agréable, surtout si vous
êtes en RTC (connexion via le téléphone). De plus, mon FAI avait fréquemment des
problèmes de serveurs DNS, ce qui m'empêchait régulièrement d'atteindre certains sites, alors je me suis décidé à
installer un serveur DNS qui fait cache des serveurs DNS de référence de l'internet. Depuis je n'ai plus aucun probléme.
Bon, avant de configurer le tout, il faut vérifier que vous avez sur votre machine ce qu'il faut pour faire votre serveur DNS, c'est-à-dire le package bind. Vérifiez donc que ce package est installé sur la machine qui va faire serveur DNS, dans le cas d'une Mandrake ou Red Hat, vérifiez avec un utilitaire pour les RPM, dans le cas d'une Slackware, vérifiez avec pkgtool, ou dans tous les cas rechercher un fichier nommer "named" qui se trouve dans la plupart des cas dans /usr/sbin/named. Si vous ne trouvez pas de package "Bind...." ou si vous ne trouvez aucun fichier "named", installez alors le package "Bind....", qui doit sûrement se trouver sur le CD d'install de votre distribution.
Pour comprendre la configuration d'un serveur DNS, un minimum de théorie sur le fonctionnement de celui-ci est nécessaire. Tout d'abord, il faut savoir que les noms DNS sont organisés de façon hiérarchique. Le haut de la hiérarchie est le root (la racine), désigné par ".", puis viennent les "Top Level Domains" (TLD) que vous connaissez : .com, .net, .fr, .org, .... En fait, quand un nom est recherché, par exemple lea-linux.org, la "question" est posé dans l'ordre hiérarchique, tout d'abord on demande à un serveur racine (un serveur connu sur internet et déclaré comme étant un serveur racine) la liste des serveurs pouvant répondre au TLD ".org", puis on descend d'une hiérarchie et on recommence. Donc à partir de la liste de serveurs obtenue, on demande ceux qui répondent à "lea-linux.org", puis de même pour lea-linux.org. C'est en gros le fonctionnement du service DNS.
On va voir ici une première configuration possible, un serveur DNS qui fait cache. Vous avez besoin de ce type de serveur si votre serveur DNS ne vous sert que pour accélérer votre connexion internet (très utile si vous étes connecté via un modem RTC), ou si vous partagez une connexion internet via votre machine.
Tout d'abord, éditons le fichier /etc/named.conf (créez ce fichier s'il n'existe pas) :
// Fichier /etc/named.conf // pour serveur DNS cache options { // Répertoire des fichiers de configuration directory "/var/named"; // Si vous traversez un firewall // et que vous avez des problèmes DNS // décommentez la ligne ci-dessous // query-source port 53; version "SECRET"; //permet de masquer la version de Bind - voir précisions ci-dessous }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; //Zone racine (root) zone "." { type hint; file "root"; }; //Zone locale zone "0.0.127.in-adr.arpa" { type master; file "zone/127.0.0"; };
Explication de ce fichier :
Toutes les lignes qui débutent par "//" sont des lignes de commentaires,
elles ne sont là que pour documenter le fichier.
La ligne "directory" indique
à named où il doit trouver tous ses fichiers de configurations. Tous les autres
fichiers auront donc un chemin relatif à celui-ci. On a ensuite la déclaration
de la zone ".", la zone racine (root en anglais), avec son fichier de description que l'on va voir plus bas.
Ensuite, on a la zone qui peut vous paraître bizarre, la zone "0.0.127.in-adr.arpa". En fait
la zone "in.adr.arpa" est une zone "spéciale" qui nous permet de faire des
recherches inverses, c'est-à-dire trouver le nom d'une machine à partir de son
adresse IP cette fois-ci. Ce fonctionnement est identique à celui qui permet de trouver
les noms. Pour trouver une machine d'adresse IP 192.168.1.1 par exemple, la
requête va être de trouver en premier in-adr.arpa (en quelque sorte le root) , puis
192.in-adr.arpa, puis 168.192.in-adr.arpa, etc... En fait, dans notre fichier,
on déclare ici la zone de recherche inverse sur le domaine 127.0.0 qui est la
zone de notre domaine local (rappelez-vous que les adresses IP 127.0.0.x sont
des adresses IP spéciales, 127.0.0.1 est l'adresse de loopback d'une machine),
ce fichier est détaillé aussi plus bas.
version "SECRET" : permet de masquer la version de Bind utilisée et de limiter ainsi
l'exploitation de failles e sécurité.
Exemple :
[root admin]# dig @digital-connexion.info version.bind txt chaos ; <<>> DiG X.x <<>> @digital-connexion.info version.bind txt chaos ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: VERSION.BIND. 0S CHAOS TXT "SECURED" ;; Total query time: 1 msec ;; FROM: ns1.cfdpublications.com to SERVER: digital-connexion.info 213.186.35.124 ;; WHEN: Sun Mar 2 20:12:56 2003 ;; MSG SIZE sent: 30 rcvd: 62
Comme nous avons vu au-dessus, il nous faut d'autres fichiers, qui sont /var/named/root
et /var/named/zone/127.0.0
/var/named/root :
; Fichier de zone des serveurs root ; A vérifier et à maintenir réguliérement . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT.SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS F.ROOT.SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS I.ROOT.SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT.SERVERS.NET. . 6D IN NS M.ROOT.SERVERS.NET. A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
Comme décrit précédemment, ce fichier contient la liste des serveurs DNS root (racine).
/var/named/zone/127.0.0:
$TTL 3D @ IN SOA nom_machine.votre_domaine.votre_TLD. ( 1 ; Serial 8H ; Refresh 2H ; Retry 1W ; Expire 1D) ; Minimum TTL NS nom_machine.votre_domaine.votre_TLD. 1 PTR localhost.
Remplacez bien sur "nom_machine.votre_domaine.votre_TLD" par les valeurs réélles de votre machine (par exemple azizlinux.icebox.org). Les "." après les noms de domaines ne sont pas une erreur et doivent être présents. J'insiste bien sur ce fait, car l'erreur typique du débutant et de ne pas mettre le "." (j'avoue que ca m'arrive encore parfois).
Si vous regardez a nouveau le fichier named.conf que l'on a fait précédement, vous avez vu deux sections appelées "controls" et "key". Ces deux directives permettent le controlle de votre serveur de nom via le programme "rndc". La ligne "controls" définit les adresses IP des machines autorisées à contrôler le serveur de nom (dans notre exemple il s'agit de la machine 127.0.0.1), et la ligne "keys" définit un couple algorythme/clef qui est en fait une sorte de mot de passe pour autorisé là aussi le contrôle à distance. Pour que la machine puisse alors s'identifier, il faut qu'elle envoie ce mot de passe. Pour cela, il faut créer un fichier /etc/rndc.conf contenant la clef :
/etc/rndc.conf:
key rndc_key { algorithm "hmac-md5"; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; options { default-server localhost; default-key rndc_key; };
Faite bien attention à ce que les informations entres les fichiers named.conf et rncd.conf
soient cohérents, c'est à dire que "algorithm", "secret", "default-key" aient exactement
les même valeurs, autrement l'identification entre le serveur et rndc echouera.
Pour la valeur de "default-server" dans le fichier rndc.conf, vous mettez là l'adresse ou le nom de
la machine que vous voulez controler à distance (dans notre exemple c'est la même machine).
Changez au moins la valeur de la key que je donne ici, elle est issue du fichier exemple de BIND, c'est à dire que
tout le monde possède cette clef par défaut, donc si vous ne voulez pas que quelqu'un contrôle votre serveur
à votre insu, modifiez la!
rndc permet de stopper, démarrer, recharger la configuration du serveur BIND à distance. Voir la documentation de rndc, ou les autres parties de ce document.
Bon maintenant que votre DNS est configuré en tant que serveur cache, il reste encore deux fichiers systèmes à configurer pour indiquer à notre machine que nous avons un serveur DNS et que nous pouvons nous en servir. Commençons par /etc/resolv.conf :
search votre_domaine.votre_TLD nameserver 127.0.0.1
Remplacez votre_domaine.votre_TLD par les valeurs de votre machine bien sûr
(par exemple icebox.org). Ne pas mettre que votre TLD sans spécifier le
domaine.
En fait, à quoi sert ce fichier ? Lorsqu'une application va lancer une requête DNS, elle ne fait
pas appel directement à votre serveur DNS mais au
"résolveur". Celui-ci lit ce fichier et regarde la ligne search pour
savoir dans quel domaine chercher en premier. Cela peut paraître stupide, mais
quand vous lancez une requête sur "www.netscape.com", via le résolveur vous
allez chercher en premier "www.netscape.com.votre_domaine.votre_TLD". Pourquoi ?
me demanderez-vous. Tout simplement parce que les personnes qui ont inventé
cela pensaient que la plupart des requêtes de noms seraient en interne sur un
réseau et rarement vers l'extérieur, donc par défaut, il cherche en premier dans
votre nom de domaine.
La ligne nameserver indique l'adresse à laquelle
on peut contacter un serveur de nom.
Aussi bien pour search que pour nameserver, on peut spécifier plusieurs entrées de cette façon :
search domaine1.tld1 domaine2.tld2 .... nameserver adresse1 nameserver adresse 2 nameserver adresse 3 ...
Attention tout de même à ne pas surcharger en nombre d'entrées dans la ligne search car ca va prendre du temps à chercher dans tous les domaines spécifiés. Différentes entrées sur cette ligne ne servent que si vous êtes sur un réseau local avec plusieurs noms de domaines et que vous avez l'habitude d'appeler les machines juste par leurs noms d'hôte. Dans le cas d'une machine reliée au net, mettre juste le nom de domaine de votre machine et rien de plus.
Il reste encore un fichier à configurer, le fichier /etc/host.conf, éditez ce fichier et vérifiez que la première ligne de ce fichier comporte :
order hosts,bind
Cette ligne oblige le résolveur à regarder en premier les entrées du fichier /etc/hosts puis de faire appel au serveur de nom qui est spécifié dans /etc/resolv.conf.
Nous allons tester maintenant que la configuration fonctionne. Lancez votre connexion à l'internet. Vérifiez que le serveur DNS n'est pas déjà démarré par un :
ps -aux | grep named
Si la seule ligne que vous renvoie cette commande est "grep named", c'est que named n'est pas lancé. Sinon relevez le numéro de PID de named et killez-le (kill numéro_du_PID). Relancez ou lancez named par la commande :
/usr/sbin/ndc start
(remplacez /usr/sbin par le répertoire ou ndc est installé, si vous ne le trouvez pas, lancez alors named la commande "named&" ).
Exécutez alors la commande "nslookup" et vous devriez voir apparaître:
olio@azizlinux:~$ nslookup Default Server: localhost Address: 127.0.0.1
Ca veut dire que tout marche bien, du moins que le serveur named est lancé et est prêt à répondre aux requêtes DNS (allez voir plus bas si ce que vous obtenez n'est pas la même chose que ce qui est affiché ci-dessus).
On va tester que le cache marche vraiment en tapant maintenant:
> lea-linux.org
et vous devez voir apparaîitre quelque chose comme:
Server: localhost Address: 127.0.0.1 Name: lea-linux.org Address: 212.73.209.252
Puis retapez exactement la même commande et cette fois ci, le résultat devrait être :
> lea-linux.org Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: lea-linux.org Address: 212.73.209.252 >
La ligne "Non-authoritative answer" signale justement que l'information a
été récupérée via le cache du serveur DNS, et nous
avertit donc que cette adresse peut être fausse si l'adresse a changé depuis, ce
qui est très improbable. Quittez alors l'utilitaire nslookup par
"exit".
Voilà, votre serveur "DNS cache" est opérationnel. Il ne vous reste
qu'à ajouter le "/usr/sbin/ndc start" dans un script de démarrage (par exemple /etc/rc.local).
Bon, soit c'est votre serveur DNS qui n'est pas lancé, soit vos fichiers systèmes sont mal configurés. Pour le savoir, lancez la commande suivant pour voir si named tourne en tâche de fond :
ps -aux | grep named
Si named ne tourne pas en tâche de fond, éditez alors le fichier /var/log/messages et repérez les lignes qui comporte named[xxxx]: ...... , elles devraient vous indiquez les erreurs de configuration que vous avez faites (fichier de zone non trouvé, etc...).
Si named tourne, vérifiez alors que le résolveur se connecte bien à votre
serveur DNS et pas sur un autre. Pour cela, quand vous lancez nslookup, celui-ci doit vous répondre que le
serveur par défaut est bien localhost, avec comme adresse "127.0.0.1". Si ce
n'est pas le cas, revérifiez les fichiers /etc/resolv.conf et /etc/host.conf.
Vérifiez aussi le fichier de zone 127.0.0.
par serge
Un serveur de mail gérant plusieurs domaines, sécurisé et protégé contre les virus.
Nous allons voir dans cet article comment installer un serveur de mail pouvant gérer plusieurs domaines (des centaines, voir plus), sécurisé contre l'open relay mais permettant aux utilisateurs authentifiés d'envoyer des mails. De plus, les mails entrant seront scannés à la recherche de virus. Car même si sous linux la plupart des virus mail n'ont aucun effet, il se peut que certains des utilisateurs récupèrent leurs mails sous windows.
Ce serveur de mail comprend aussi un gestionnaire de mailing list et une interface web d'admin des domaines mails.
Pour la compréhension de cet article, vous devez avoir des notions assez avancées sur Linux et son utilisation (commandes shell en ligne, compilation, etc...), et des notions sur les réseaux TCP/IP et de l'internet.
Cet article est une "compilation" d'articles trouvés sur l'internet (en partie l'article qmail sur toolinux), d'HOWTO, et de mon expérience professionelle de Qmail.
Récupérez tout d'abord les sources de ces différents programmes (attention, vérifiez les liens et versions, je vous donne les versions à jour, à l'heure où j'écris cet article, c'est-à-dire en avril 2002):
- qmail-1.03
- autorespond-2.0.2
-
daemontools-0.76
-
ucspi-tcp-0.88
- ezmlm-0.53
- ezmlm-idx
-
maildrop-1.3.8
- qmail-scanner-1.10
- vpopmail-5.2
- F-PROT (version linux gratuite pour un
usage privé, prenez aussi les mises à jours des définitions de virus sur la page
download du site).
- Qmailadmin
Oui je sais, ca fait beaucoup de chose à récupérer, j'espére que vous avez un
bon modem :)
Bon on va commencer par installer Qmail lui même. Détarrez / dégzippez les
sources de qmail ( tar zxvf qmail-1.0.3.tar.gz ). Nous allons devoir
patcher légèrement les sources de Qmail pour notre besoin.
Entrez dans le répertoire des sources de Qmail, et éditez le fichier
Makefile, et remplacez :
- La ligne 1486 auto_split.o par auto_split.o
env.a
- La ligne 1491 substdio.a
error.a str.a fs.a auto_qmail.o auto_split.o par substdio.a error.a str.a fs.a auto_qmail.o auto_split.o
env.a
De même, éditez le fichier qmail.c et :
-ajoutez en dessous de la
ligne 8 #include "env.h" en dessous de la
ligne #include "auto_qmail.h"
-remlacez la
ligne 10 static char *binqqargs[2] = {
"bin/qmail-queue", 0 } ; par static char
*binqqargs[2] = { 0, 0 } ;
-Ajoutez juste au-dessous de la ligne que vous venez de modifier les lignes
suivantes:
static void
setup_qqargs()
{
if(!binqqargs[0])
binqqargs[0]
= env_get("QMAILQUEUE");
if(!binqqargs[0])
binqqargs[0]
= "bin/qmail-queue";
}
et enfin au-dessous des lignes (vers la ligne 23)
int
qmail_open(qq)
struct qmail *qq;
{
int
pim[2];
int pie[2];
vous ajoutez:
setup_qqargs();
Remarque: Ce patch est uniquement nécessaire pour pouvoir utiliser
qmail-scanner, qui va nous permettre de scanner tout mail entrant à la recherche
de virus. En fait, ce patch ajoute une variable d'environnement QMAILQUEUE.
Si cette variable est vide, Qmail utilise son propre programme de "queue" (file
d'attente des mails entrant et sortant), autrement cette variable contient le
nom du programme de queue de remplacement à utiliser. Nous utiliserons alors
la "queue" de qmail-scanner qui appellera notre programme antivirus (F-PROT)
pour scanner tous les mails.
Maitenant que Qmail est patché, nous allons pouvoir le compiler. Mais avant
cela, nous devons créer des comptes utilisateurs, qui de plus vont servir pour
le chemin d'installation de Qmail. Dans cet article, le chemin d'installation
est celui par défaut, c'est à dire /var/qmail
Nous créons ces comptes utilisateurs par les commandes
(en root bien sur):
groupadd nofiles
useradd -g
nofiles -d /var/qmail/alias alias
useradd -g nofiles -d /var/qmail
qmaild
useradd -g nofiles -d /var/qmail qmaill
useradd
-g nofiles -d /var/qmail qmailp
groupadd qmail
useradd
-g qmail -d /var/qmail qmailq
useradd -g qmail -d /var/qmail
qmailr
useradd -g qmail -d /var/qmail
qmails
Remarque: Si vous souhaitez installer Qmail dans un
autre répertoire que /var/qmail, modifiez les commandes ci-dessus avec
le chemin souhaité.
Il nous reste plus qu'à compiler Qmail:
make setup check
Configurons maintenant Qmail, via
la commande :
./config-fast `hostname
--fqdn`.
Vous devez voir apparaître quelque chose du style :
Your fully qualified host name is
mailhub.lea-linux.org
Putting tarsier.lea-linux.org into
control/me...
Putting lea-linux.org into
control/defaultdomain...
Putting lea-linux.org into
control/plusdomain...
.....
Si avez une erreur ou autre
insulte de la sorte, essayez en remplaçant "`hostname --fqdn`" par votre
nom d'hôte complet (par exemple ./config-fast
mailhub.lea-linux.org)
Qmail utilise deux styles de mailbox (boîte aux lettres) différents :
le mbox traditionel comme sendmail (un fichier nommé comme le login de
l'utilisateur contenant tout les mails de l'utilisateur dans /var/mail) ou un
répertoire Maildir à structure spéciale contenant les mails dans des fichiers
séparés. Pour notre cas nous utiliserons Maildir, car vpopmail se base dessus.
Pour cela, il suffit de copier un fichier:
cp
/var/qmail/boot/home /var/qmail/rc
Qmail n'est pas tout à fait complètement installé, mais pour la
suite nous allons devoir installer les daemontools et ucspi de façon à avoir
des performances optimales pour notre serveur de mails.
De façon à avoir de meilleures performances pour notre serveur de mails et
pour une plus grande souplesse, pour "logger" les évements mails, nous devons
installer les outils développés par Dan Bernstein : daemontools
et ucspi-tcp.
Pour les installer, rien de plus simple, vous dégzippez / détarrez les sources
comme d'habitude.
Pour les daemontools, un répertoire admin a été créé lors du "détarrage":
cd
admin/daemontools/
./package/install
Il ne reste plus qu'à compiler / installer uscpi:
cd ucspi-tcp-0.88
make
setup check
Comme d'habitude, on dégzippe / détarre les source de Vpopmail. Avant de lancer
la compilation, il faut, comme pour Qmail, créer les comptes utilisateurs de
vpopmail, qui vont aussi déterminer le chemin d'installation de vpopmail.
Pour ma part, pour des questions de "cohérence" avec Qmail, je l'installe dans
/var/vpopmail. De plus je trouve logique de l'installer dans /var, car c'est
le repertoire où l'on trouve normalement tout les fichiers qui varient
en permanence (mail, logs, pid, etc...). Donc, nous faisons (en root
bien sur) :
groupadd -g 89 vchkpw
useradd -g vchkpw -u 89 -d /var/vpopmail vpopmail
Remarque: changez le chemin /var/vpopmail par le chemin d'installation
que vous désirez bien sur
Vous devez créer le répertoire de Vpopmail avant de continuer, pour notre exemple:
mkdir /var/vpopmail
Vpopmail possède un script de configuration avant la compilation (le
bien connu ./configure), auquel nous allons passer les options nécessaires
à notre cas.
Voici les options que nous allons utiliser, avec une brève explication
pour chaque option:
--prefix=/var/vpopmail
Répertoire de base de vpopmail
--enable-clear-passwd=y
Ce qui permet de stocker une copie des mots de passe POP des utilisateurs en
clair. C'est peut-être moins sécurisé, mais c'est toujours pratique pour retrouver
le mot de passe de l'un de vos utilisateurs qui l'aurait perdu. Si vous êtes
parano, n'activez pas cette option.
--enable-valias=y
Permet d'utiliser les alias mails (plusieurs noms possibles pour un même compte
POP)
--enable-default-domain=votre domaine
Indique le domaine primaire de votre machine. A mettre absolument, autrement
vous allez devoir créer le compte de chaque utilisateur pour le domaine principal
du serveur de mail.
--enable-roaming-users=y
Permet une authentification POP before SMTP pour activer le relaying.
Explication sur cette option:
Vous avez sûrement entendu parler du "relaying" pour les serveurs mails,
l'open relay, etc... Pour résumer ce probléme, normalement un serveur de mail
(comme la plupart des serveurs de mails des FAI) interdisent aux utilisateurs
d'envoyer des mails si l'IP de l'utilisateur n'est pas une IP du même réseau
que le serveur de mail.
Par exemple, les serveurs de mails wanadoo refusent que vous envoyiez des mails
si vous n'avez pas une IP wanadoo (c.a.d si vous ne vous etes pas connecté à
l'internet via leur propre service), cela pour des raisons de sécurité, de lutte
anti-spam, de charge serveur et aussi économique.
La plupart des sociétés ayant leur propre serveur de mail font de même. Si vous
ne faites pas ça, votre serveur est considéré comme un "open-relay", ce qui
n'est pas bien du tout (je vais pas expliquer pourquoi ici, ca prendrait trop
de temps).
Mais se pose alors un probléme: vous êtes une grosse société, avec 5 000
collaborateurs. Vos collaborateurs voyagent beaucoup et ont besoin d'utiliser
le serveur de mail de la société. Comme ils sont en déplacement à l'extérieur
de la société, ils n'ont pas d'IP de la société (ils sont connectés via un FAI
quelquonque ), et le serveur de mail n'autorise pas le relaying (c'est à dire
envoyer un mail d'un utilisateur dont l'IP n'est pas une IP de la société).
Comment faire alors ?
On a alors inventé le POP before SMTP pour permettre le relaying. Comment ca
marche? Très simple. L'utilisateur doit tout d'abord "popper" sa boîte
aux lettres (c'est à dire relever ses mails, c'est la chose que vous faites
chaque fois que vous regardez avec votre client mail si vous avez reçus un nouvel
e-mail). Lorsque l'utilisateur "poppe" sa boîte au lettre, il s'identifie
sur le serveur en fait (le POP demande obligatoirement un nom d'utilisateur
et un mot de passe). Si l'identification est OK, le serveur distribue les mails
.
Comme l'utilisateur est identifié, on va alors se dire "ok l'utilisateur est
connu, il est de chez nous", on va alors enregistrer son adresse IP actuelle
et permettre a cette adresse IP d'envoyer des mails pendant un certain temps
que l'on peut définir (voir plus bas dans l'article). Donc en résumé (si vous
n'aviez rien compris), si vous voulez que votre serveur de mail soit utilisable
pour envoyer des mails à partir de n'importe où dans le monde, à
partir du moment où l'on aune boîte aux lettres sur votre serveur,
activez cette option.
Donc, je vous redonne les options que nous utilisons ici :
./configure --enable-clear-passwd=y --enable-valias=y --enable-default-domain=lea-linux.org
--enable-roaming-users=y
Puis on le compile / installe:
make
make install-strip
Comme les "headers" de vpopmail sont nécessaires pour la compilation
d'autres programmes (qmailadmin par exemple), nous devons les copier dans un
répertoire d'include. Pour cela:
cp /var/vpopmail/include/* /usr/include
Pour que vpopail trouve bien les fichiers de tcpserver, il faut refaire le repertoire
etc/ de vpopmail:
mv /var/vpopmail/etc/* /etc
rmdir /var/vpopmail/etc
ln -s /etc /var/vpopmail/etc
Avant d'installer Qmail-scanner, vous devez vous assurez d'avoir Perl
5.005_03 (ou supérieur) sur votre machine (c'est le cas avec toutes les distrib
récentes) et les modules Perl:
Time::HiRes
DB_File
Sys::Syslog
Pour vous en assurer, installez-les via CPAN. Pour se faire, vous devez être
connecté à internet, et lancez alors la commande:
perl -MCPAN -e
shell;
Remarque: Si c'est la premiére fois que vous lancez CPAN, vous allez
devoir le configurer. Je ne vous explique pas ici comment configurer CPAN.
Toutefois, la plupart du temps il suffit de valider les options proposées par
défaut
Une fois CPAN lancé, demandez
l'installation des modules via:
install
Time::HiRes
install DB_File
install
Sys::Syslog
exit (pour sortir du CPAN)
Nous allons aussi dès à présent installer F-PROT. Dgzippez / Détarrez
f-prot dans le répertoire /usr/local et installez le via:
cd
/usr/local
tar zxvf
/ou/se/trouve/votre/fp-linux_sb.tar.gz
ln -fs fp-linux_312/
f-prot
ln -fs /usr/local/f-prot/f-prot.sh bin/f-prot
ln
-fs /usr/local/f-prot/f-prot.8 man/man8/
chmod +x
/usr/local/f-prot/f-prot*
Mettez aussi à jour les signatures antivirales de F-PROT ( Faites-le le plus
souvent possible si vous voulez un bonne protection antivirale de vos mails!)
Téléchargez les deux zip de mise à jour de signature de f-prot et dézipé-les
dans /usr/local/f-prot.
Avant d'installer Qmail-scanner, nous devons
installer Maildrop, indispensable pour Qmail-scanner.
tar zxvf
maildrop-1.3.8.tar.gz
cd
maildrop-1.3.8
./configure
make
make
install
Passons maitenant à Qmail-scanner.
Dégzippé / Détarré
Qmail-scanner, puis son répertoire de source lancez ./configure avec
les options suivantes:
--admin user
(voir en-dessous pour la valeur de user)
--domain votre_domaine
Pour comprendre les valeurs à mettre dans ces options, prenons le cas où
nous voulons que tous les mails d'alerte de détection virale soient envoyés
à admin@lea-linux.org, vous devez alors mettre admin pour le user et lea-linux.org
pour le domaine.
--notify all
Pour prévenir l'administrateur, l'envoyeur et la personne qui auraient dû
recevoir le mail, qu'un mail contaminé a été intercepté
--redundant yes
Permettre le scan des
fichiers zips, etc...
Pour notre exemple, nous lançons
donc:
./configure --admin admin --domain lea-linux.org --notify all
--redundant yes --install
Attention: Vous risquez
d'avoir une erreur du type:
YOU HAVEN'T DISABLED SET-ID SCRIPTS IN
THE KERNEL YET!
FIX YOUR KERNEL, PUT A C WRAPPER AROUND THIS SCRIPT,
OR USE -u AND UNDUMP!
******* FATAL ERROR
*******
Cette erreur est "normale" si votre distribution comporte une version de Perl
qui interdit que des script Perl soient lancés en SET-ID pour des raisons de
sécurité (cas de la slackware par exemple).
En effet, lancer les scripts en SET-ID signifie que le script est lancé avec
les droits d'un utilisateur spécifique. Certaines distributions interdisent
cela (pour empêcher de lancer des script Perl qui prendraient les droits
root par exemple et pourraient faire des choses pas très gentilles).
Dans ce cas (et que dans ce cas-là, c'est-à-dire que vous avez
l'erreur énoncée ci-dessus) vous devez:
cd contrib
make
make
install
Vous devez voir apparaître alors:
install -o
qmailq -g qmail -m4755 qmail-scanner-queue
/var/qmail/bin/qmail-scanner-queue
Revenez dans le répertoire des sources de Qmail-scanner (cd ..)
et vous éditez le fichier qmail-scanner-queue.pl et vous remplacez:
#!/usr/bin/suidperl
-T
par:
#!/usr/bin/perl
Copiez enfin ce fichier dans /var/qmail/bin en placant les bons droits
:
cp qmail-scanner-queue.pl /var/qmail/bin/
chown
qmailq.qmail /var/qmail/bin/qmail-scanner-queue*
Dans tout les cas, il faut initialiser qmail-scanner maitenant.
Si vous n'avez pas eu l'erreur ci-dessus, tapez ces commandes:
qmail-scanner-queue.pl -g
qmail-scanner-queue.pl -z
Si vous avez eu l'erreur lors de l'installation, les commandes alors sont celles-ci:
qmail-scanner-queue -g
qmail-scanner-queue -z
Ezmlm est le gestionnaire de mailing de Qmail. Pour l'installer, détarrez /
dgzippez ezmlm et ezmlm-idx.
Puis copiez le contenu de ezmlm-idx dans le
répertoire de ezmlm:
tar zxvf ezmlm-0.53.tar.gz
tar zxvf
ezmlm-idx-0.40.tar.gz
mv ezmlm-idx-0.40/*
ezmlm-0.53/
Patchez alors ezmlm:
cd
ezmlm-0.53
patch < idx.patch
et compilez, installez
le tout:
make clean
make
make man
Ce programme permet de répondre automatiquement aux mails reçus (pour
signaler une absence par exemple).
Pour l'installer, c'est très simple:
tar zxvf autorespond-2.0.2.tar.gz
cd
autorespond-2.0.2
make
make install
Je vous donne ici brièvement les commande pour créer un nouveau domaine
mails, les comptes, etc...
Je suppose bien sûr que vous savez gérez vos DNS pour que le champ
MX du domaine pointe vers le serveur de mails.
- Ajouter un nouveau domaine que votre serveur de mails va héberger :
/var/vpopmail/vadddomain domaine.com
Vous allez devoir rentrer le mot de passe du "postmaster", c'est-à-dire de l'administrateur
mails de ce domaine.
Pour créer les comptes pop, utiliser qmailadmin. Tapez l'url dans votre navigateur
pour pointer sur le cgi de qmailadmin, dans user laissez "postmaster", dans
domaine, mettez le domaine que vous voulez gérer et pour le mot de passe, mettez
le mot de passe du postmaster.
Dans l'interface se trouvent tout les liens pour créer les mails etc...
-
Effacer un domaine:
/var/vpopmail/vdeldomain
domaine.com
Quand vous configurez votre client mail pour lire les mails reçus, faites attention
dans la partie "nom utilisateurs" de mettre de la forme:
utilisateur@domaine.com
car les logiciels de mail mettent par défaut "utilisateur" tout court.
Si lors du démarrage des services vous avez des erreurs du style:
unable to bind: adresses in
use
ou quelque chose de similaire, c'est que vous avez déjà un serveur
de mail et/ou pop3 de lancé. Désinstallez tout autre serveur de mail/pop3 (sendmail,
gnu-pop3d,...), vérifiez aussi dans .etc/inetd.conf ou dans /etc/xinet.d/ que
les services smtp, pop3 ne sont pas utilisés par d'autres programmes.
Lisez les documentations d'utilisation de ezmlm, ezmlm-idx pour la gestion des
mailing lists.
Qmailadmin vous permet de "fabriquer" vos propres pages d'administration mail,
etc... avec de nombreux exemples installés dans /usr/local/share/qmailadmin
Pour que vous puissiez gérer les mails d'un domaine, vous devez configurer un
MX dans le fichier de zone de ce domaine qui pointe vers votre serveur. Lisez
les documentions des serveurs DNS.
Installer une interface graphique de messagerie pour serveur Postfix, basée sur Horde et IMP
Ce guide est basé sur l'excellent travail original en anglais de Olivier Schulze L, site web http://www.geocities.com/oliversl/imp/, et sur sa traduction (tout aussi excellente) en français par Fred, site web http://www.media-nova.fr/.
Dans ce document, nous allons décrire étape par étape les instructions nécessaires pour configurer une interface graphique pour un serveur local de messagerie, basé sur POSTFIX, sur un serveur Mandrake Linux 9.0.
Vous devez auparavant récupérer les paquetages nécessaires à l'installation de l'interface web HORDE 2.1 (Architecture PHP), IMP 3.1 (Client IMAP pour Horde), TURBA 1.1 (Gestionnaire de contacts pour Horde) et PEAR 4.1.0 sur le site de Horde. Le tout est diffusé sous licence libre GNU/GPL.
L'équipe de développement de horde, imp et turba développe aussi un calendrier et organiseur journalier nommé "kronolith", un gestionnaire de tâches nommé "nag" et un mémo électronique nommé "mnemo". Le tout est interfaçable avec l'interface web, et aussi disponible sur le site de Horde.
Si vous souhaitez autoriser le changement en ligne de mot de passe pour la boîte à lettres, ce guide décrit aussi l'installation de poppassd, téléchargeable sur rpmfind et de passwd, téléchargeable ici.
Ce guide vous aidera à configurer une installation standard, uniquement testée pour un réseau local, non relié à Internet. Cela doit vous permettre de réaliser un petit serveur de messagerie interne, pour une petite structure, avec une interface graphique ergonomique accessible depuis un navigateur Internet.
Il est ensuite possible de "tuner" votre configuration pour qu'elle corresponde à vos souhaits, ou/et pour réaliser un serveur de messagerie Internet (Le webmail de Free est basé sur horde/imp), mais cela sort du cadre de ce guide et de mes compétences : une attention particulière doit être notamment accordée à la sécurité.
Pour suivre les instructions ci-dessous, vous aurez besoin d'un minimum de connaissances relatives à Linux, notamment sur l'usage de la console, si vous installez un serveur de messagerie minimum (sans interface graphique type KDE ou Gnome).
Vous pouvez vérifier le nom de domaine de votre machine avec l'instruction
:
hostname
Si vous n'avez pas tout, il faut installer les paquetages manquants :
rpm -Fvh nom_du_paquetage.rpm pour mettre à jour un paquetage déjà installé
rpm -ivh nom_du_paquetage.rpm pour installer un nouveau paquetage
Pour mettre en marche un service (exemple avec apache) :
service httpd stop (Arrêt d'Apache)
service httpd start (Mise en marche d'Apache)
service httpd restart (Redémarrage d'Apache)
Pour faire en sorte qu'à chaque démarrage de votre poste, le service Apache
fonctionne :
chkconfig apache on
Il faut notamment veiller à bien lancer le service dépendant de xinetd imap
:
chkconfig imap on
service xinetd restart
Pour savoir où vous vous situez dans l'arborescence de linux :
pwd
Enfin, n'oubliez pas que l'appui sur la touche de tabulation "tab" permet de
compléter un nom :
cd /v "tab" donne automatiquement cd /var
Le répertoire d'installation sera : /var/www/html/mail/
Modifier le fichier /etc/httpd/conf/httpd.conf :
DocumentRoot /var/www/html/mail
ServerName mail.example.com
Modifier le fichier /etc/httpd/conf/commonhttpd.conf :
<directory /var/www/html/mail>
Ajouter la ligne suivante dans le fichier /etc/hosts :
192.168.10.1 mail.example.com
Remarque : une autre méthode consiste à configurer un VirtualHost.
mkdir -p /var/www/html/mail
Rdémarrer Apache pour que les changements prennent effet :
service httpd restart
créer un fichier temporaire :
touch /var/www/html/mail/essai.html
puis à l'aide d'un navigateur, aller à l'adresse Internet :
http://mail.example.com/essai.html
Remarque : On peut utiliser un navigateur texte comme Lynx pour tester la configuration,
si l'on n'a pas installé d'interface graphique sur le serveur ou si aucun poste
distant n'est connecté au serveur :
lynx mail.example.com/essai.html
Une fois Apache configuré, vous avez besoin d'installer et de configurer Horde.
A partir du répertoire où vous avez stocké le paquetage
Horde, récupéré sur le site Internet de Horde
:
tar zxvf horde-2.1.tar.gz -C /var/www/html/mail
cd /var/www/html/mail
mv horde-2.1 horde
A partir du répertoire où vous avez stocké le paquetage
Pear :
cd /usr/share
rm php
tar zxvf pear-4.1.0.tar.gz -C /usr/share
cd /usr/share
mv pear-4.1.0 php
chown root.root -R php
Tester si mysql est lancé :
service mysql restart
cd /var/www/html/mail/horde/scripts/db
choisissez un mot de passe pour la base Horde :
vi mysql_create.sql
Créer la base Horde :
mysql < mysql_create.sql
Tester si vous pouvez vous connecter à la base :
mysql -h localhost -u horde -p
Un mot de passe vous est demandé : rentrer celui choisi ci-dessus.
Quitter mysql avec la commande 'exit'
cd /var/www/html/mail/horde/config
Renommer tous les fichiers :
for fichier in *.dist; do cp -v $fichier $(basename $fichier .dist); done
Modifier le fichier /var/www/html/mail/horde/config/horde.php :
// utiliser la compression. Mandrake PHP supporte zlib
$conf['compress_pages'] = true;
// utiliser IMAP pour authentifier les utilisateurs
$conf['auth']['driver'] = 'imap';
$conf['auth']['params'] = array();
$conf['auth']['params']['dsn'] = '{localhost:143/imap}INBOX';
// utiliser MySQL pour stocker les données de Horde
$conf['prefs']['driver'] = 'sql';
$conf['prefs']['params'] = array();
$conf['prefs']['params']['phptype'] = 'mysql';
$conf['prefs']['params']['hostspec'] = 'localhost';
$conf['prefs']['params']['username'] = 'horde';
$conf['prefs']['params']['password'] = 'my_passwd';
$conf['prefs']['params']['database'] = 'horde';
$conf['prefs']['params']['table'] = 'horde_prefs';
// Le SMTP postfix, pour envoyer les emails
$conf['mailer']['type'] = 'smtp';
Remarque : my_passwd est à remplacer par le mot de passe de la base horde mysql choisi au paragraphe Configurer mysql
Modifier le fichier /var/www/html/mail/horde/config/lang.php :
$nls['defaults']['language'] = 'fr_FR';
Modifier le fichier /etc/php.ini :
include_path = "/usr/share/php"
Activer l'extension php_xml si ce n'est pas déjà fait en supprimant le ; situé en début de ligne
Redémarrez le service apache :
service httpd restart
Vous pouvez tester la configuration initiale de Horde en allant avec un navigateur
web sur :
http://mail.example.com/horde/test.php
A partir du répertoire où vous avez stocké le paquetage
IMP :
tar zxvf imp-3.1.tar.gz -C /var/www/html/mail/horde
cd /var/www/html/mail/horde
mv imp-3.1 imp
Déclarer IMP dans Horde :
Modifier le fichier /var/www/html/mail/horde/config/registry.php :
// Décommentez les lignes suivantes
$this->registry['auth']['login'] = 'imp';
$this->registry['auth']['logout'] = 'imp';
// Décommentez les lignes suivantes
$this->applications['imp'] = array(
'fileroot' => dirname(__FILE__) . '/../imp',
'webroot' => $this->applications['horde']['webroot'] . '/imp',
'icon' => $this->applications['horde']['webroot'] . '/horde/imp/graphics/imp.gif',
'name' => _("Mail"),
'allow_guests' => false,
'show' => true
);
cd /var/www/html/mail/horde/imp/config
Renommer tous les fichiers :
for fichier in *.dist; do cp -v $fichier $(basename $fichier .dist); done
Modifier le fichier /var/www/html/mail/horde/imp/config/servers.php :
// Modifier ces lignes
$servers['imap'] = array(
'name' => 'IMAP Server',
'server' => 'localhost',
'protocol' => 'imap/notls',
'port' => 143,
'folders' => 'mail/',
'namespace' => '',
'maildomain' => 'example.com',
'smtphost' => 'mail.example.com',
'realm' => '',
'preferred' => 'true'
);
Remarque : Il doit être possible à ce niveau de configurer le service sécurisé d'imap (protocol imap/ssl, port 993).
Modifier le fichier /var/www/html/mail/horde/imp/config/pref.php :
// langage de l'utilisateur
// regarder dans /horde/config/lang.php pour les alias de langue
$_prefs['language'] = array(
'value' => 'fr_FR',
'locked' => false,
'shared' => true,
'type' => 'select',
'desc' => _("Select your preferred language:")
);
// boite postale de l'utilisateur par défaut
// la valeur par défaut INBOX ne peut être changée
$_prefs['mailbox'] = array(
'value' => 'INBOX',
'locked' => true,
'shared' => false,
'type' => 'implicit'
);
// Utiliser IMAP
// Montre seulement les répertoires souscrits par IMAP
$_prefs['subscribe'] = array(
'value' => 1,
'locked' => true,
'shared' => false,
'type' => 'checkbox',
'desc' => _("Use IMAP folder subscriptions")
);
// Répertoire des courriers envoyés
// Utilise le même nom que Mozilla, Outlook Express, etc
$_prefs['sent_mail_folder'] = array(
'value' => 'Sent',
'locked' => false,
'shared' => true,
'type' => 'implicit'
);
// Répertoire poubelle
// Utilise le même nom que Mozilla, Outlook Express, etc
$_prefs['trash_folder'] = array(
'value' => 'Trash',
'locked' => false,
'shared' => false,
'type' => 'implicit'
);
Vous pouvez tester la configuration initiale de IMP en allant avec un navigateur
web sur :
http://mail.example.com/horde/
Se logger avec un utilisateur/passe valide (en l'occurrence un compte pop valide).
Essayer d'envoyer des mails à un autre compte et à vous même.
Utiliser une adresse mail du type utilisateur@mail.example.com Nous verrons
plus loin (paragraphe 8) comment configurer postfix pour utiliser une adresse
mail du type utilisateur@example.com
Pour créer un compte sans possibilité de connection sur votre
serveur, uniquement destiné à la messagerie :
useradd -c "nom_utilisateur ou commentaire" -s /bin/false -g popusers
nom_utilisateur
Puis définir le mot de passe du compte nouvellement créé
avec passwd :
passwd nom_utilisateur
Remarque 1 : Avec un poste Windows distant, il faut configurer le fichier hosts. Dans le répertoire : C:\WINNT\SYSTEM32\DRIVERS\ETC), rajouter la ligne : 192.168.10.1 mail.example.com Ceci est probablement inutile si votre serveur de messagerie est aussi serveur de nom (DNS).
Remarque 2 : Vous pouvez aussi modifier le fichier 'trailer.txt' situé dans /horde/imp/config/. Ce fichier vous permet d'ajouter un texte à la fin de tous les mails qui seront envoyés par IMP. Par défaut, le texte suivant est ajouté à tous les messages : This mail sent through IMP: http://horde.org/imp/. Si vous ne voulez rien ajouter, effacer tout ce qu'il y a dans ce fichier.
Maintenant que vous pouvez lancer Horde et IMP, vous avez besoin d'un carnet d'adresses afin de gérer vos contacts.
A partir du répertoire où vous avez stocké le paquetage
IMP :
tar xzf turba-1.1.tar.gz -C /var/www/html/mail/horde
cd /var/www/html/mail/horde
mv turba-1.1 turba
Renommer tous les fichiers :
for fichier in *.dist; do cp -v $fichier $(basename $fichier .dist); done
Déclarer Turba dans Horde :
Modifier le fichier /var/www/html/mail/horde/config/registry.php
:
// Décommenter les lignes suivantes
$this->applications['turba'] = array(
'fileroot' => dirname(__FILE__) . '/../turba',
'webroot' => $this->applications['horde']['webroot'] . '/turba',
'icon' => $this->applications['horde']['webroot'] . '/horde/turba/graphics/turba.gif',
'name' => _("Addressbook"),
'allow_guests' => false,
'show' => true
);
Configurer dans IMP l'icône pour Turba :
Modifier le fichier /var/www/html/mail/horde/imp/config/conf.php :
$conf['menu']['apps'] = array('turba');
Configurer dans Turba l'icône pour IMP :
Modifier le fichier /var/www/html/mail/horde/turba/config/conf.php :
$conf['menu']['apps'] = array('imp');
Modifier le fichier /var/www/html/mail/horde/turba/config/prefs.php :
// Language de l'utilisateur
// Règler le même langage par défaut que Horde et IMP
$_prefs['language'] = array(
'value' => 'fr_FR',
'locked' => false,
'shared' => true,
'type' => 'select',
'desc' => _("Select your preferred language:")
);
Configurer Turba pour utiliser MySQL pour enregistrer les données des contacts
:
Modifier le fichier /var/www/html/mail/horde/turba/config/sources.php :
// Compléter cette partie de la configuration avec les données
// de la base de données comme dans /horde/config/horde.php
// Configurer aussi le titre dans votre langue
$cfgSources['localsql'] = array(
'title' => 'IMP Address Book',
'type' => 'sql',
'params' => array(
'phptype' => 'mysql',
'hostspec' => 'localhost',
'username' => 'horde',
'password' => 'my_passwd',
'database' => 'horde',
'table' => 'turba_objects'
),
);
Remarque : my_passwd est à remplacer par le mot de passe de la base horde mysql choisi au paragraphe Configurer mysql
Créer la base dans MySQL que Turba utilisera :
cd /var/www/html/mail/horde/turba/scripts/drivers/
mysql < turba.sql
Vous pouvez tester la configuration initiale de Turba en allant avec un navigateur
web sur :
http://mail.example.com/horde/
Créer une nouvelle entrée dans le carnet d'adresse et aller dans IMP, puis Options et choisissez d'utiliser le carnet d'adresses avec le nom "IMP Address Book".
Maintenant que vous avez configuré Horde avec IMP et Turba, vous avez besoin de fournir à vos utilisateurs une méthode pour changer leur mot de passe au travers de Horde.
rpm -ivh poppassd-ceti-1.8-3mdk.i586.rpm
Activer le service poppassd :
chkconfig poppassd on
service xinetd restart
A partir du répertoire où vous avez stocké le paquetage
IMP :
tar zxvf passwd.tgz -C /var/www/html/mail/horde/
cd /var/www/html/mail/horde/
cd passwd
cd /var/www/html/mail/horde/passwd/config
Renommer tous les fichiers :
for fichier in *.dist; do cp -v $fichier $(basename $fichier .dist); done
Modifier le fichier /var/www/html/mail/horde/config/registry.php :
$this->applications['passwd'] = array(
'fileroot' => dirname(__FILE__) . '/../passwd',
'webroot' => $this->applications['horde']['webroot'] . '/passwd',
'icon' => $this->applications['horde']['webroot'] . '/passwd/graphics/lock.gif',
'name' => _("Password"),
'allow_guests' => false,
'show' => true
);
Configurer l'icône pour Passwd dans IMP :
Modifier le fichier /var/www/html/mail/horde/imp/config/conf.php :
$conf['menu']['apps'] = array('turba', 'passwd');
Configurer l'icône pour IMP dans Passwd :
Modifier le fichier /var/www/html/mail/horde/passwd/config/conf.php :
$conf['menu']['apps'] = array('imp');
Vous pouvez tester la configuration initiale de Turba en allant avec un navigateur
web sur :
http://mail.example.com/horde/
Changez votre mot de passe. Attention : n'importe quel mot de passe de n'importe quelle longueur sera accepté car poppassd est lancé sous l'identité root.
En réseau local, lorsque machin@mail.example.com envoie un mail à truc@mail.example.com, l'adresse de réponse est machin@example.com. Postfix ne peut envoyer la réponse.
Pour que cela fonctionne correctement, il faut rajouter (ou décommenter) les
lignes suivantes du fichiers /etc/postfix/main.cf :
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, $mydomain
Sécurisation des mails : TLS, IMAPS,..
Il serait en effet fort intéressant de pouvoir ouvrir sa boite de courrier électronique
sans que le mot de passe ne circule en clair sur le réseau.
Pour finir, beaucoup d'informations intéressantes, permettant de configurer plus finement l'ensemble, sont disponibles dans la faq administrateur du site de Horde.
par Jonesy
Installer, configurer et utiliser VNC.
Cela permet de se connecter à une machine distante de sa propre machine, comme telnet ou openSSH, mais à la différence que vous êtes sous l'interface graphique du système hôte, et que vous avez la main sur le clavier et la souris.
Note de Jicé : On dit que VNC permet de "déporter" l'affichage d'une machine sur une autre.VNC rend ceci possible quelque soit le système d'exploitation de la machine distante et/ou le système de votre machine.
Sachez qu'entre 2 machines dotées de serveurs X, VNC ne sert à rien, car c'est une fonctionnalité native des serveurs X. Il suffit de lancer votre application sur la machine jouant le rôle de serveur en lui spécifiant sur quel écran elle doit s'afficher.
Par exemple, je lance xeyes depuis la machine taz avec affichage sur l'écran 0 (par défaut) de la machine papoune :
[jice@taz jice] xeyes -display papoune:0
Pour information, il existe d'autres solutions pour utiliser l'interface
graphique d'une machine distante.
Note de Jicé : allez Jonesy, dis-le que c'est similaire
à ce que fait PCAnywhere® qui, lui, ne fonctionne qu'avec des
serveurs et des clients Windows © Microsoft ;)
Bien sûr, il existe des clients/serveurs VNC pour différents
systèmes d'exploitation : Windows (9x/NT/2000/CE), Linux, Solaris,
Macintosh et DEC.
Dans notre exemple, le serveur sera à installer sur Linux et
le client sur Windows. Bien entendu, vous installez la version Linux du
serveur sur Linux et la version Windows du client sur Windows. Comme toutes
les versions utilisent le même protocole de communication, cela ne
pose aucun problème.
Vous pouvez trouver le client et le serveur, fournis ensemble, ici :
http://www.uk.research.att.com/vnc/download.html
Ou allez voir sur vos CDs d'installation ou ici pour le RPM :
http://rpmfind.net/linux/rpm2html/search.php?query=vnc&submit=Search+...
et là pour le DEB :
http://packages.debian.org/stable/x11/vncserver.html
Installez votre RPM, DEB, tarball ou l'éxécutable. C'est tout bête, il n'y a rien de particulier à savoir, je vous le jure... ;-)
Important : Pour le serveur VNC sous Linux, surtout ne l'ajoutez
pas dans les services à démarrer automatiquement ! Cela bloquerait
la machine au cours du démarrage et vous seriez obligé d'aller
le désactiver d'une facon ou d'une autre.
Lorsque que cela m'est arrivé, j'ai "mounté" la partition
Linux concernée avec mon deuxième système Linux.
Note de Jicé : j'ai aussi eu ce problème, surtout
quand j'utilisais Aurora (knterface graphique de boot). Il suffit en fait
de démarrer sans Aurora (depuis je l'ai supprimé) en mettant
textboot (heu... ou boottext ?) sur la ligne de commande
du noyau (ex : linux textboot à l'invite LILO). Ensuite,
on voit qu'où vient le problème (en général,
c'est VNC qui demande un mot de passe la première fois, ce qui bloque
Aurora).
Lorsqu'on lance le serveur VNC, celui-ci vous retourne un numéro
sous cette forme :
New 'X' desktop is pingouin.pingouin.fr:1
Starting applications specified in /home/jonesy/.vnc/xstartup
Log file is /home/jonesy/.vnc/pingouin.pingouin.fr:1.log
Ici, le numéro est 1. Gardez le bien, car vous en aurez besoin.
Pour lancer le serveur VNC
vncserver
Pour arrêter le serveur VNC
vncserver -kill :X
X étant le numéro renvoyé lorsque vous
avez lancé le serveur.
La première fois que vous lancerez le serveur pour un utilisateur, il vous demandera un mot de passe, pour des raisons de sécurité évidentes, n'utilisez pas le mot de passe du compte Linux ! Et il créera sous le $HOME de l'utilisateur le répertoire .vnc avec différents fichiers. Dont xstartup, qu'il est intéressant de modifier afin de choisir votre environnement graphique et d'autres petites choses.
Chez moi, $HOME/.vnc/xstartup ressemble a ceci :
#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
rxvt -ls -title "$VNCDESKTOP Desktop" &
starticewm &
rxvt -ls -title "$VNCDESKTOP Desktop" & : Lance automatiquement
un terminal rxvt à la connection.
starticewm & : Je choisis iceWM comme environnement
graphique.
Pour Gnome ou KDE, il suffit de modifier la dernière ligne comme
ceci:
startgnome &
ou
startkde &
Pour que les modifications de xstartup soient prises en compte, il faut arrêter et relancer le serveur VNC.
Note : Je ne sais pas pour quelle raison, mais chez moi, VNC ne marche pas avec KDE !
Et bien entendu, il faut que l'interface graphique soit installée
sous Linux, VNC ne va pas la simuler. ;-)
Pour quitter le client, c'est comme d'habitude. Sachez tout de même,
que si vous fermez votre session X avant de quitter le client, il vous
faudra relancer le serveur VNC pour la prochaine fois.
Si vous ne fermez pas votre session X et que vous quittez le client
VNC avec Netscape ouvert, la prochaine fois que vous vous connecterez à
VNC, vous retrouverez votre Netscape toujours ouvert. Bien sûr, si
la machine hôte avec le serveur n'a pas été arrêtée.
Note : N'oubliez pas, vous êtes sur le serveur ! C'est
comme un telnet ou openSSH. Donc vous n'avez pas accès à
votre disque dur local, CDROM ou lecteur de disquette. Sauf si le serveur
y a accès via le réseau...
Installer le proxy Junkbusters
Junkbusters est un proxy http (web) qui bloque les bannières de publicité des sites web.
Il est facile à mettre en oeuvre, et est très pratique puisque vous ne perdez plus de temps à télécharger ces bannières.
Vous pouvez trouver Junkbusters à cette adresse : http://www.junkbusters.com
Un proxy est une "passerelle" entre vous et le web (pour le http).
Il gère les requêtes http et, pour Junkbuster, bloque les requêtes indésirables.
Téléchargez-le, puis décompressez-le où vous le voulez.
Compilez les sources (si vous n'avez pas l'exécutable) par
./configure && make && make install
Vous pouvez, si vous le souhaitez, effacer le fichier junkbusters.exe, puisque c'est la version pour Windows 9x.
Bien maintenant, on a 3 fichiers de configuration à écrire :
On va commencer par cookiefile puisqu'on veut recevoir TOUS les cookies.
Ouvrez votre éditeur et mettez-y :
*
Enregistrez votre fichier en cookiefile.
Maintenant config :
listen-address localhost:8080 | # machine locale port 8080 |
blockfile /etc/junkbusters/blockfile | # où est le fichier blockfile |
cookiefile /etc/junkbusters/cookiefile | # où est le fichier cookiefile |
Comme vous le voyez les fichiers sont tous dans /etc/junkbusters ; créez ce repertoire et déposez y les fichiers que vous avez créés.
Le dernier c'est blockfile, c' est une liste de sites (là où sont les bannières) à bloquer. Ecrire ce fichier serait ridicule puisqu'on le trouve tout prêt sur internet.
Evidemment vous devrez voir comment il marche pour éventuellement ajouter des sites. Je vous en laisse un en téléchargement : cliquer ici.
enregistez le aussi dans /etc/junkbusters.
Voilà, maintenant il faut qu'il se lance automatiquement à chaque boot de Linux.
Pour cela éditez /etc/rc.d/rc.local, et ajoutez ces lignes :
echo junkbusters loadling...
/usr/sbin/junkbusters /etc/junkbusters/config &
Pour que ça marche copiez l'executable junkbusters dans /usr/sbin.
Bien, c'est presque fini, il faut juste dire à votre navigateur d'utiliser le proxy.
Pour Netscape:
Ouvrez les péférences, et choisissez "proxy",
Puis configuration manuelle du proxy.
Entrez localhost pour la machine, et 8080 pour le port.
Si vous utilisez un autre navigateur, réglez le de façon à utiliser le proxy de la même façon.
Voilà c'est tout, pour vérifier que Junkbusters fonctionne, rebootez votre machine, et ouvrez Netscape sans être connecté ; tapez une adresse, et regardez si vous voyez le message de Junkbusters, tout marche !
c' est bon, les pubs seront filtrées !!!
(c) 2001 BRARD Emmanuel, emman@agat.net
Ce document est sous license GNU FDL .
par Fred
Ce document explique comment constuire un mur pare feu, pas à pas, sans théorie, sans blabla.
Il n'est pas question d'expliquer ici le fonctionnement d'iptables
,
il existe pour cela de très bons articles dont celui de Léa. Le mur pare feu que je vous propose
de construire sera adapté à vos besoins. Il ne comportera
aucun gadget, aucune optimisation du réseau. Ce sera un mur pare feu
rien qu'un mur pare feu.
Vous devrez mettre dans le fichier /usr/bin/startfirewall
tout ce
qui va suivre.
Comme tout script, le script de notre mur pare feu doit commencer par :
#!/bin/sh
Mais, pour être facilement modifiable, nous allons définir en plus quelques variables :
# (suite du script...)
# mettez ici l'emplacement d'iptables :
IPTABLES=/sbin/iptables
# mettez ici le nom de l'interface réseau vers internet :
EXTERNAL_IF="ppp0"
# mettez ici le nom de l'interface réseau vers votre lan :
INTERNAL_IF="eth0"
Ensuite, il nous faut charger les modules dont nous aurons besoin :
# (suite du script...)
# si vous voulez pouvoir autoriser les connections ftp :
modprobe ip_conntrack_ftp
# si vous voulez pouvoir autoriser le DCC sous IRC :
modprobe ip_conntrack_irc
Suivant votre configuration, il peut être nécessaire de charger un autre module, pour en avoir la liste :
ls /lib/modules/`uname -r`/kernel/net/ipv4/netfilter/
Un mur pare feu correctement configuré se doit de
rejeter tout ce qui n'a pas été explicitement
autorisé. C'est le rôle de la politique par défaut (default
policy
). Pour fixer celle-ci, nous utilisons les 3 règles
suivantes :
# (suite du script...)
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
La dernière règle peut être omise si vous souhaitez tout transmettre [aux]/[depuis les] machines de votre réseau local.
Pour ne pas être ennuyé, il faut tout autoriser pour ce
qui est du traffic réseau local (sur 'lo
' et '$INTERNAL_IF
'
aka: 'eth0
') :
# (suite du script...)
# "On accepte le traffic sur 'lo'"
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
$IPTABLES -A FORWARD -i lo -j ACCEPT
$IPTABLES -A FORWARD -o lo -j ACCEPT
# "On accepte le traffic sur le réseau local"
$IPTABLES -A INPUT -i $INTERNAL_IF -j ACCEPT
$IPTABLES -A OUTPUT -o $INTERNAL_IF -j ACCEPT
$IPTABLES -A FORWARD -i $INTERNAL_IF -j ACCEPT
$IPTABLES -A FORWARD -o $INTERNAL_IF -j ACCEPT
Ceci n'est pas vraiment obligatoire.
Si vous ne regardez pas régulièrement les logs de votre mur pare feu, celui-ci a toutes les chances de devenir inefficace. Nous allons donc 'logguer' une partie des connections que nous refuserons :
# (suite du script...)
# On loggue les packets DROPés
$IPTABLES -A LOG_DROP -j LOG --log-prefix "[IPT] "
$IPTABLES -A LOG_DROP -j DROP
Le texte [IPT]
peut être remplacé par
n'importe quel texte de votre choix. Vous pouvez, de la même
façon, créer plusieurs cibles 'DROP
' pour les
logguer différemment.
Le mur pare feu peut aussi servir à partager la connection, pour cela il faut faire deux choses :
# (suite du script...)
echo 1 > /proc/sys/net/ipv4/ip_forward
# (suite du script...)
$IPTABLES -A POSTROUTING -t nat -o $EXTERNAL_IF -j MASQUERADE
A partir de maintenant je vais vous donner des recettes de cuisine.
Tout d'abord, il faut savoir que vous pouvez au choix utiliser un
numéro de port ou son nom dans le fichier /etc/services
.
J'utiliserais, dans la mesure du possible, cette dernière
solution. Je ne détaillerais pas tous les ports, si vous
souhaitez utiliser un port que j'aurais omis, consultez /etc/services
. Dans ce fichier, vous constaterez que
certains ports sont indiqués comme utilisant le protocol tcp
, udp
ou autre. Pour autoriser
ces protocols vous devrez changer le "-p tcp
" par "-p udp
" ou autre dans les exemples qui vont
suivre.
Pour la plupart des connections, tout ce que je vais dire ici s'applique (exceptions notables : l'irc/dcc, le ftp/actif).
Pour autoriser les machines de votre réseau local (si le masquerading est activé) ainsi que votre serveur mur pare feu à se connecter à
un port sur internet, il faut procéder de la maniére suivante (dans l'exemple j'autorise la connection au WEB : www
):
# (suite du script...)
$IPTABLES -A INPUT -i $EXTERNAL_IF -p tcp --sport www -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp --dport www -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Chaque commande $IPTABLES
doit être tapée sur une seule ligne depuis le $IPTABLES
jusqu'au
-j ACCEPT
ou -j DENY
(dans la suite...).
Une petite explication, la règle $IPTABLES -A INPUT
s'applique au traffic entrant (tous les paquets IP entrant seront
soumis à cette règle). Comme on a précisé -p tcp
, la règle s'applique aux paquets utilisants le protocol tcp
.
On a aussi préciser --sport www
, donc la règle s'applique au paquet qui proviennent (sport
est mis
pour source port
, le port d'entrée) du port www
(le web quoi !). Puis on a mis -m state --state ESTABLISHED,RELATED
pour préciser que cette règle ne s'applique qu'aux paquets IP qui proviennent soit d'une liaison "établie" (ESTABLISHED
), soit
d'une liaison en relation (RELATED
) avec une liaison déjà établie. Enfin on précise -j ACCEPT
pour dire qu'on accepte
tous les paquets qui vérifient toutes ces conditions : les paquets venant d'une liaison WEB déja établie.
La seconde règle est symétrique de la première : elle autorise la paquets IP à sortir (-A OUTPUT
), sauf qu'elle précise en plus que
les paquets sortants ont le droit d'initier une nouvelle connection (--state NEW
).
Sinon la premiére règle aurait trés peu de chance de fonctionner : aucune liaison ne serait jamais 'établie'.
Pour autoriser plusieurs ports en même temps, on peut soit taper plusieurs règles comme la précédente (une par port) ou alors utiliser la syntaxe (exemple pour le http et le https):
# (suite du script...)
$IPTABLES -A INPUT -i $EXTERNAL_IF -p tcp -m multiport --sports www,https -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp -m multiport --dports www,https -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Pour autoriser les machines d'internet à se connecter à votre serveur local (dans l'exemple j'autorise la connection à votre serveur WEB : www
):
# (suite du script...)
$IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp --sport www -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -i $EXTERNAL_IF -p tcp --dport www -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Si vous voulez autoriser une connection d'internet vers l'un des serveurs de votre réseau local à la place du serveur qui
joue le rôle de mur pare feu, alors il faut faire du port forwarding
en utilisant les cibles
SNAT
et DNAT
en plus d'ACCEPT
, mais cela dépasse le cadre de cet article.
Il existe des cas particuliers, ce sont les protocoles qui ouvrent plusieurs liaisons en même temps : le DCC(pour irc), le ftp
passif, les protocole vidéo (comme le h323). Ils fonctionnent souvent (mais pas tous) sur le principe suivant : le client (vous)
réclame quelque chose (un fichier) au serveur (le serveur ftp) ; celui-ci répond à la demande en ouvrant une nouvelle connection (aléatoire en général : c'est ce qui nous pose problème, on ne sait pas quel port ouvrir)
réseau sur le client (vous). Pour ne pas ouvrir n'importe quel port (plus précisément, pour ne pas ouvrir TOUS les ports) pour être
en mesure de répondre à la demande du serveur, il faut que nous soyons capable de "tracer" (to track en anglais) la provenance de
la demande de connection pour être sur que la demande de connection provient d'une liaison que nous avons nous méme initié. C'est le
rôle du module "ip_conntrack
" et de ses acolytes : "ip_conntrack_ftp
" (pour le ftp) et
"ip_conntrack_irc
" pour l'irc. Pour que cela (ce qui va suivre) fonctionne, il faut donc que ces modules soient chargés.
C'est ce que nous faisons au début du script, donc plus besoin de nous en occuper, si ce n'est pour autoriser les connections qui sont
en relation avec celles déja établies sur les ports qui sont utilisés par irc et ftp :
# (suite du script...)
$IPTABLES -A INPUT -i $EXTERNAL_IF -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
Voilà, c'est tout, le ftp passif doit maintenant pouvoir bien passer votre mur pare feu.
Par contre pour le DCC, il faut encore ajouter une règle, autoriser les liaisons sortantes à initier une connection. Je ne vois pas pourquoi, mais chez moi c'est nécessaire ;-) :
# (suite du script...)
$IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state NEW -j ACCEPT
Pour le DCC, j'ai comme l'impression que le module 'ip_conntrack_irc' a du mal à suivre les connections et c'est pour ça qu'il faut ajouter la troisième régle. Ce n'est pas une trop grande faille de sécurité puisque c'est nous qui initions la connection, mais tout de même ce serait mieux si ce n'était pas obligé. Si quelqu'un trouve mieux, je serais content qu'il m'en fasse part.
Pour l'instant, si vous avez ouvert quelques port, vous avez du remarquer que vous n'avez plus accès au ping. Nous allons remédier à cela :
# (suite du script...)
$IPTABLES -A OUTPUT -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A INPUT -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
ou alors, vous pouvez vouloir limiter les ping entrant (pour éviter d'être floodé) et vous remplacez la seconde règle par les deux suivantes :
# (suite du script...)
$IPTABLES -A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A INPUT -p icmp -m state --state NEW -m limit --limit 10/min -j ACCEPT
Vous pouvez remplacer 10/min
par 1/s
etc...
Il est un port que vous êtes obligé d'autoriser dans le sens 'réseau local' vers 'internet' : le port "domain
"
(aka: 53) en udp
ET tcp
. Sinon vous serez dans l'impossibilité d'utiliser la résolution de nom
(aka: l'identification d'un nom de domaine avec son IP).
Sinon, moi j'autorise, dans le sens 'reseau local' vers 'internet' en tcp
:
Et en udp
:
Et dans le sens : 'internet' vers 'reseau local' en tcp
:
Rappel : tous ces noms de 'ports' se trouvent dans le fichier /etc/services
Pour finir, on loggue tout via syslogd
:
$IPTABLES -A FORWARD -j LOG_DROP
$IPTABLES -A INPUT -j LOG_DROP
$IPTABLES -A OUTPUT -j LOG_DROP
Il n'est en général pas nécessaire d'arrêter le mur pare feu, mais, sait-on jamais ? Pour faire les tests, il est nécessaire de l'arrêter et de le redémarrer (parce que l'ordre des règles est important). Voici un petit script pour arrêter le mur pare feu (celui qui est proposé ici, il ne fonctionnera pas avec tous les murs de feu) :
#!/bin/sh
# Script d'arrêt du mur pare feu
# mettez ici l'emplacement d'iptables :
IPTABLES=/sbin/iptables
echo "On vide toutes les régles."
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F POSTROUTING
$IPTABLES -F LOG_DROP
$IPTABLES -X
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
echo "On décharge les modules."
rmmod `lsmod | grep -E "^ip" | cut -d" " -f 1`
Ce mur pare feu n'est certainement pas parfait, mais j'espere qu'il vous permettra de mieux comprendre comment sont fabriqués les murs de feu que vous trouvez dans des scripts tous faits.
par julien Lecubin
Avant de commencer l'installation de SNORT, vous devez avoir installé :
PACKAGES | REMARQUES |
MySQL
|
La base de données MySQL |
MySQL-client
|
La partie cliente de mysql (connexion BD) |
php-mysql
|
le module php de mysql |
Apache
|
Le serveur web Apache |
mod_php
|
Le module php pour Apache |
libpcap/libpcap0-devel
|
Librairie utilisée par SNORT pour capturer les paquets (rpm téléchargeable sur rpmfind.net) |
gcc
|
indispensable pour compiler les sources de SNORT |
Si vous n'avez pas encore installé le trio Apache/PHP/MySQL, il y a un article sur Lea vous expliquant comment le faire. C'est ici.
Les étapes pour l'installation de SNORT sont les suivantes :
Téléchargez la dernière release de SNORT à l'adresse suivante : http://www.SNORT.org/dl . La compilation de ce programme reste traditionnelle :
COMMANDES | REMARQUES |
cd /usr/local/snort
|
... |
tar -xvzf SNORT-1.9.*.tar.gz
|
Décompacte l'application |
./configure --with-mysql=/usr/lib/mysql
|
Retirez l'argument --with-mysql si vous ne souhaitez pas
rediriger les logs SNORT vers une base de données mysql
*
|
make
|
Compilation |
make install
|
Installation |
Pour l'argument --with-mysql
, vous pouvez l'adapter si vous
utilisez une base de données autre que MySQL :
--with-odbc=$PATH_ODBC
: pour une base de données
Microsoft SQL server--with-postgresql=$PATH_POSTGRE
: pour une base
PostegreSQL--with-oracle=$ORACLE_HOME
: pour une base de données
Oracle.Maitenant, il faut télécharger les règles
de SNORT. En effet, SNORT utilise des règles pour
détecter les intrusions. Il existe aujourd'hui environ 1200
règles différentes. Ces règles se
caractérisent par un ensemble de fichiers (ftp.rules,
p2p.rules,telnet.rules etc...). Vous devez
téléchargez les sources de ces règles à
l'adresse suivante :
http://www.SNORT.org/dl/signatures
Créez le répertoire de configuration SNORT, et installez-y les règles :
COMMANDES | REMARQUES |
mkdir /etc/snort
|
Création du répertoire contenant la configuration SNORT |
cp /usr/local/snort*/etc/snort.conf /etc/snort
|
Copie du fichier de config snort dans /etc/snort |
cp snortrules.tar.gz /etc/snort
|
Mise en place des règles dans le répertoire de configuration SNORT |
cd /etc/snort
|
On se place dans le répertoire de configuration SNORT |
tar -xvzf snortrules.tar.gz
|
Décompactage des règles |
Les règles SNORT sont alors placées dans le
répertoire /etc/snort/rules
.
Maintenant, Il faut éditer le fichier de configuration
snort (/etc/snort/snort.conf
) et spécifier le réseau
sur lequel l'IDS travaille. Il faut pour cela modifier la variable
HOME_NET
:
var HOME_NET [10.1.1.0/24] # SNORT
travaille sur le réseau 10.1.1.0
var HOME_NET
(10.1.1.0/24,192.168.1.0/24] # Si votre carte réseau
possède 2 alias
Dans le fichier de configuration de SNORT
(/etc/snort/snort.conf
), vous avez toute une série de
include. Il s'agit des règles utilisées par SNORT
pour détecter d'éventuelles intrusions. Il y a des
règles de telnet, ICMP, FTP, ... Bref, commentez celles que
vous ne voulez pas et décommentez celles qui vous parait
utile. Conseil : Décommentez les règles ICMP, car
elles ne cessent pas de vous remonter des alarmes très
souvent inutiles.
Pour des explications plus détaillées concernant les règles SNORT, allez voir ici.
Deux possibilités s'offrent à nous. Soit vous lancez SNORT tout seul, et dans ce cas, il génerera ces logs dans un fichier plat. Soit vous décidez de l'interfacer avec une base de données. Suivant le cas, SNORT ne se lancera pas de la même façon.
Sans Mysql :
/usr/local/snort*/src/snort -c /etc/snort/snort.conf -i
eth0 -D
Avec Mysql :
/usr/local/snort*/src/snort -c
/etc/snort/snort.conf
Remarque : Si vous souhaitez interfacer SNORT avec une base de
données, ne lancez pas SNORT avec l'argument -L
qui
spécifie l'emplacement des logs.
Maintenant, nous allons éditer le fichier de
configuration de SNORT afin de lui indiquer qu'il faut rediriger
les logs dans une base de données (ici MySQL). Avec vos yeux
de lynx, retrouvez la ligne suivante dans le fichier de
configuration SNORT /etc/snort/snort.conf
:
#output database:log,mysql,user=root password=test dbname=SNORT host=localhost
Décommentez et modifiez cette ligne par :
output database:log,mysql,user=user_snort password=snort_pwd dbname=snort host=localhost
Ici, l'utilisateur MySQL accédant à la base de données s'appelle "user_snort", son password associé est "snort_pwd", le nom de la base MySQL utilisée par snort est "snort" et la machine qui fait tourner la base Mysql est la même que celle où SNORT tourne.
Au préalable, assurez-vous d'avoir installé :
PACKAGES | REMARQUES |
MySQL-client-*
|
partie cliente de MySQL |
MySQL-devel-*
|
Astuce : La commande "rpm -qa | grep client" vous permet de vérifier que votre station Linux possède bien ces packages installés.
Suivez alors les instructions suivantes :
COMMANDES | REMARQUES |
cd /usr/local/snort*/contrib
|
on se place à l'endroit du fichier contenant les tables SQL de SNORT |
mysql -u root -p
|
Connexion à la base de données en tant qu'administrateur (au passage, si ce n'est pas encore fait, définissez un password pour l'administrateur de la base par la commande 'set password for root@localhost=PASSWORD('totomdp'); |
create database SNORT;
|
Création de la base de données SNORT |
use mysql;
|
On se place ici pour créer l'utilisateur MySQL qui gérera la base de données snort |
insert into user values('localhost', 'user_snort',
password('snort_pwd'), 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y',
'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', '', '',
'', '', 'Y', 'Y', 'Y');
|
Création utilisateur MySQL "user_snort". Attention
le nombre de 'Y' dépend de votre version de MySQL. (faites
un select * from user; pour voir combien il faut en
mettre)
|
grant ALL PRIVILEGES ON SNORT.* TO user_snort@localhost
IDENTIFIED BY 'snort_pwd' WITH GRANT OPTION;
|
Attribution des droits de la base "snort" à l'utilisateur "user_snort" |
flush privileges;
|
Recharge les tables de droits pour prendre en compte les nouvelles modifications |
use snort;
|
on se place dans la base où l'on veut créer les tables pour SNORT |
Source create_mysql
|
Création des tables pour SNORT |
Vérifiez que les tables sont bien créées.
Allez voir dans /var/lib/mysql/snort
et vous y verrez tout un tas
de fichiers correspondant au nom des tables de la base de
données SNORT (il doit y avoir 3 fichiers par tables).
Lancez SNORT. Désormais, SNORT envoie les informations dans la base de données (astuce : installez PhpMyAdmin, et vérifiez la taille de la base de données SNORT. Si tout fonctionne, vous la voyez augmenter si bien évidemment il y a du trafic !).
ACID est une interface PHP qui permet de visualiser les remontées d'alarmes générées par SNORT. Cette partie sous-entend que vous avez une base de données qui récupère les informations envoyées par SNORT. Avant de suivre l'installation de cette application, assurez-vous d'avoir téléchargé :
/var/www/html/adodb par exemple
)Le téléchargement de ACID se fait ici. Imaginons que la racine de votre serveur web est /var/www/html. Installez ACID dans la racine d'apache :
COMMANDES | REMARQUES |
cd /var/www/html
|
Placez-vous dans la racine du serveur web |
tar -xvzf acid*
|
Décompactage de ACID |
tar -xvzf adodb*
|
Décompactage de AdoDB |
tar -xvzf phplot*
|
Décompactage de PHPlot |
vi /var/www/html/acid/acid_conf.php
|
Renseignez les champs suivants :
|
Voilà, maintenant vous pouvez vérifier que ACID est bien configuré (allez voir sur http://localhost/acid). Si vous le souhaitez, L'accès peut se faire via certificat SSL de manière à crypter l'échange entre vous et le détecteur d'intrusions.
Sachez que ce document a pour but de vous apporter quelques éléments de réponse concernant l'installation et la configuration de l'IDS SNORT. Il est loin d'être parfait. Vos remarques sont les bienvenues. Je prévois de modifier le présent document suivant les remarques que vous y apporterez.
Pour me contacter : guitarparts chez fr point st
par Dimitri Clatot
Supervision de réseaux avec SmokePing
SmokePing
permet de mesurer et d'afficher sous forme graphique les temps de
réponse aux ping, http, https, smtp d'une machine ou d'un groupe de
machines, et de déclencher des alertes si une machine ne
répond pas aux tests.
Cet article se veut seulement être un moyen de mise en place
rapide de cet outil et non un substitut à la documentation
officielle.
Voici la liste de ces programmes :
Je vais détailler l'installation de tous ces programmes à l'exception d'Apache et de Perl qui sont fournis généralement avec votre distribution. Il est à noter que les programmes FPing IPV6 et le module perl Socket6 seront à installer si vous souhaitez gérer l'IPV6 (non développé ici).
RRDtool permet de stocker les résultats des mesures faites et de les afficher sous forme graphique :
$ wget
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/rrdtool-1.0.42.tar.gz
$ tar zxvf rrdtool-1.0.42.tar.gz
$ cd rrdtool-1.0.42
$ ./configure
$ make
$ su
Password:
# make install
# ln -s /usr/local/rrdtool-1.0.42 /usr/local/rrdtool
FPing est une version améliorée de la commande ping :
$ wget
http://people.ee.ethz.ch/~oetiker/webtools/smokeping/pub/fping-2.4b2_to.tar.gz
$ tar zvxf fping-2.4b2_to.tar.gz
$ cd fping-2.4b2_to
$ ./configure
$ make
$ su
Password:
# make install
echoping permet de tester les services echo, http, https, smtp... d'une machine :
$ wget
ftp://ftp.internatif.org/pub/unix/echoping/echoping-5.0.1.tar.gz
$ tar zxvf echoping-5.0.1.tar.gz
$ cd echoping-5.0.1
$ ./configure --with-ssl=/usr/include (pour Openssl)
$ make
$ su
Password:
# make install
# ln -s /usr/local/bin/echoping /usr/bin/echoping
SpeedyCGI dope la vitesse d'exécution de SmokePing :
$ wget
http://daemoninc.com/SpeedyCGI/CGI-SpeedyCGI-2.21.tar.gz
$ tar zxvf CGI-SpeedyCGI-2.21.tar.gz
$ cd CGI-SpeedyCGI-2.21
$ perl Makefile.PL
Optional mod_speedycgi support.
Mod_speedycgi increases performance under Apache by avoiding the
fork/exec
overhead associated with each request under normal SpeedyCGI. However,
it
requires a working copy of "apxs" in your path, Apache with mod_so
support, and additional Apache configuration.
Compile mod_speedycgi (default no)? no
Checking if your kit is complete...
Looks good
Writing Makefile for src
Writing Makefile for speedy_backend
Writing Makefile for speedy
Writing Makefile for CGI::SpeedyCGI
$ make
$ su
Password:
# make install
Une fois toutes les dépendances installées, il ne reste plus qu'à faire celle de SmokePing :
$ wget
http://people.ee.ethz.ch/~oetiker/webtools/smokeping/pub/smokeping-1.20.tar.gz
$ tar zxvf smokeping-1.20.tar.gz
$ cd smokeping-1.20
$ su
Password:
# mkdir /var/www/html/smokeping/data/.simg -p
# ln -s /var/www/html/smokeping/data/.simg /var/www/html/.simg
# mkdir /usr/lib/smokeping
# cp lib/* /usr/lib/smokeping -R
# mkdir /etc/smokeping
SmokePing est composé de plusieurs fichiers qu'il faut adapter à la configuration de votre installation et copier dans les répertoires les plus adaptés à votre système.
Le premier d'entre eux est smokeping.dist, c'est l'éxecutable :
# cp bin/smokeping.dist /usr/bin/smokeping
# vi /usr/bin/smokeping
#!/usr/bin/perl -w
# -*-perl-*-
use lib qw(/usr/local/rrdtool/lib/perl);
use lib qw(/usr/lib/smokeping);
use Smokeping 1.20;
Smokeping::main("/etc/smokeping/config");
----------Suite du fichier----------
Le suivant est le script CGI qui permet d'accéder à l'interface HTML de SmokePing :
# cp htdocs/smokeping.cgi.dist
/var/www/cgi-bin/smokeping.cgi
# vi /var/www/cgi-bin/smokeping.cgi
#!/usr/bin/speedy -w
# -*-perl-*-
use lib qw(/usr/local/rrdtool/lib/perl);
use lib qw(/usr/lib/smokeping);
use Smokeping 1.20;
Smokeping::cgi("/etc/smokeping/config");
----------Suite du fichier----------
Le suivant, basepage.html, est le fichier template qui permet de personnaliser l'interface HTML :
# cp etc/basepage.html.dist /etc/smokeping/basepage.html
Le fichier config est comme son nom l'indique le fichier de configuration principal de SmokePing. Dans celui-ci on déclare les machines que l'on souhaite pinger (via fping) et/ou tester les services echo, http, https, smtp... (via EchoPing)
# cp etc/config.dist /etc/smokeping/config
Voici un exemple de configuration de fichier dans lequel on teste le ping ainsi que les services echo, http, https et smtp :
# cat /etc/smokeping/config
# Note that all IP addresses in
this file are false, to prevent some
# machine falling uder a deadly
DOS storm because all users keep
# the same addresses in their
config.
*** General ***
owner = Joe
Random
contact =
joe@some.place.xyz
mailhost = smtp.mailhost.abc
sendmail = /usr/lib/sendmail
imgcache =
/var/www/html/smokeping/data/.simg
imgurl = ../.simg
datadir =
/var/www/html/smokeping/data
piddir = /var/run
cgiurl =
http://127.0.0.1/cgi-bin/smokeping.cgi
smokemail =
/etc/smokeping/smokemail
# specify this to get syslog
logging
syslogfacility = local0
*** Database ***
step =
300 # Le temps en secondes entre
chaque test
pings =
20 # Le nombre de tests
lancé à chaque fois
# consfn mrhb steps total
AVERAGE 0.5
1 1008
AVERAGE 0.5
12 4320
MIN
0.5 12 4320
MAX
0.5 12 4320
AVERAGE 0.5
144 720
MAX
0.5 144 720
MIN
0.5 144 720
*** Presentation ***
template =
/etc/smokeping/basepage.html
+ overview
width = 600
height = 50
range = 10h
+ detail
width = 600
height = 200
unison_tolerance = 2
"Last 3
Hours" 3h
"Last 30 Hours" 30h
"Last 10
Days" 10d
"Last 400 Days" 400d
*** Probes ***
+ FPing
binary = /usr/local/sbin/fping
+ EchoPing # uses TCP or
UDP echo (port 7)
+ EchoPingHttp # HTTP (80/tcp)
for web servers and caches
+ EchoPingHttps # HTTPS
(443/tcp) for web servers
+ EchoPingSmtp # SMTP (25/tcp)
for mail servers
*** Alerts ***
to = joe@some.place.xyz
from = joe@some.place.xyz
+lossdetect
type = loss
# in percent
pattern =
==0%,==0%,==0%,==0%,>20%,>20%,>20%
comment = suddenly there is
packet loss
+rttdetect
type = rtt
# in milli seconds
pattern =
<10,<10,<10,<10,<10,<100,>100,>100,>100
comment = routing mesed up
again ?
*** Targets ***
probe = FPing
menu = Top
title = Network Latency Grapher
remark = Welcome to the
SmokePing website of Linux Company. \
Here you will learn all about the latency of our network.
+ Machine1
menu = Machine1
title = Titre Machine1
host = Machine1.com
+ Machine2
menu = Machine2
title = Titre Machine2
++ icmp
menu = icmp
title = Icmp Server
probe = EchoPing
alerts = lossdetect
host = Machine2
++ http
menu = http
title = Web Server (www-server)
/ HTTP
probe = EchoPingHttp
alerts = lossdetect
host = www.Machine2.com
++ https
menu = https
title = Https Server
probe = EchoPingHttps
alerts = lossdetect
host = www.Machine2.com
++ smtp
menu = smtp
title = Smtp Server
probe = EchoPingSmtp
alerts = lossdetect
host = smtp.Machine2.com
# cp etc/smokemail.dist /etc/smokeping/smokemail
# vi /etc/syslog.conf
------Rajouter la ligne en fin de fichier--------
# Save smokeping messages
local0.info /var/log/smokeping
# touch /var/log/smokeping
# chmod 600 /var/log/smokeping
# /etc/rc.d/init.d/syslog restart
# /usr/bin/smokeping
Une fois l'exécution terminée, on peut visualiser le résultat de votre travail :
$ mozilla http://127.0.0.1/cgi-bin/smokeping.cgi
Voici un exemple de ce l'on peut faire avec Smokeping : ici
Un script est disponible ici pour lancer SmokePing au démarrage de votre système
# cp smokeping-start-script-rh72
/etc/rc.d/init.d/smokepingd
# vi /etc/rc.d/init.d/smokepingd
#!/bin/sh
#
# smokeping This starts and stops the smokeping daemon
# chkconfig: 345 98 11
# description: Start/Stop the smokeping daemon
# processname: smokeping
# Source function library.
. /etc/rc.d/init.d/functions
SMOKEPING=/usr/bin/smokeping
LOCKF=/var/lock/subsys/smokeping
CONFIG=/etc/smokeping/config
----------Suite du fichier----------
# cd /etc/rc.d/init.d/
# chmod 755 smokepingd
# /sbin/chkconfig --add --level 345 smokepingd
J'espère vous avoir fait découvrir ou redécouvrir cet outil. Pour ma part je compte l'utiliser pour tester la qualité de liaisons à Relais de Trame ainsi que les services http de serveurs intranet. Je vous encourage très fortement à consulter la documentation officielle afin de découvrir les nombreuses possibilités offertes par cette application.
par Franck Paillaret
Ou comment installer sa connexion IPv6
Bienvenue dans un monde parallèle, un monde en 128bits. Vous allez maintenant affronter la configuration de votre machine. Cachez vos peurs, ignorez votre flemmardise et chaussez vos bottes, nous y allons. Si jamais vous avez des problèmes ou quoi que ce soit, n'oubliez pas que les newsgroups et irc sont les meilleurs remèdes.
Je suppose à la base que vous avez déjà
configuré vos interfaces, (voir votre réseau) en ipv4 ou
que vous savez le faire (
http://lea-linux.org/reseau/lan.php3)
La première chose à faire est de configurer le noyau pour
qu'il prenne en charge le v6. Je me baserai sur un noyau 2.4.x.
Détectons déjà si l'ipv6 est configuré (ce
qui doit être le cas pour la plupart des distributions
récentes). Je ne parlerai pas également des kernel USAGI
ni Vanilla, à tout casser allez voir http://www.linux-ipv6.org.
test -f /proc/net/if_inet6 && echo "IPv6.. ca roule ma
poule"
S'il est compatible, passez à la section 2. Sinon continuez
à lire :)
Networking options --->
<M> The IPv6 protocol (EXPERIMENTAL)
IPv6: Netfilter Configuration --->
IPv6: Netfilter Configuration
< > Userspace queueing via NETLINK (EXPERIMENTAL)
<M> IP6 tables support (required for filtering/masq/NAT)
<M> limit match support
<M> MAC address match support
< > Routing header match support (EXPERIMENTAL) (NEW)
< > Hop-by-Hop and Dst opts header match
(EXPERIMENTAL) (NEW)
< > Fragmentation header match support (EXPERIMENTAL)
(NEW)
< > HL match support (NEW)
<M> Multiple port match support
<M> Owner match support (EXPERIMENTAL)
<M> netfilter MARK match support
< > IPv6 Extension Headers Match (EXPERIMENTAL) (NEW)
< > AH/ESP match support (EXPERIMENTAL) (NEW)
< > Packet Length match support
<M> EUI64 address check (EXPERIMENTAL)
<M> Packet filtering
<M> LOG target support
<M> Packet mangling
<M> MARK target support
Dans le menu Networking options, mettez en module ou en dur (dur=intégré au noyau) l'option The IPv6 protocol (EXPERIMENTAL) et ensuite mettez en module ou en dur toutes les options du menu IPv6 : Netfilter Configuration si vous n'etes pas sûr (ça ne risque rien). Dès que nous avons un noyau en état d'accepter l'ipv6 (c'est à dire après recompilation et reboot - http://lea-linux.org/kernel/kernel.php3), passons à la section 2.
Il faut réinstaller les net-tools (ifconfig, route...). Vous pouvez les trouver à http://www.tazenda.demon.co.uk/phil/net-tools/ (en n'oubliant pas de préciser bien-sûr le support ipv6).
Lancer le module ipv6 si jamais vous avez configuré le kernel
avec le support ipv6 en module, avec: modprobe ipv6
(pour
vérifier: lsmod |grep -w 'ipv6' && echo "IPv6.. ça
roule ma poule"
)
Il faut recompiler en décommentant HAVE_INET6 dans
pppd/Makefile.linux (pour les flemmards: perl -pi -e
"s/#HAVE_INET6/HAVE_INET6/;" pppd/Makefile.linux
), ensuite un
./configure && make && make install.
Ensuite, pour une connexion pppd simple, il vous faut changer les
chap-secrets/pap-secrets avec votre login et ajouter à votre
/etc/ppp/options ipv6 ,
(Attention la virgule est
très importante !!!).
Pour une connexion pppoe, vous devez aussi éditer votre
chap-secrets/pap-secrets avec votre login (login@net1.dual.nerim par
exemple) puis éditez votre /etc/ppp/pppoe.conf et là-aussi
remettez votre login et ajoutez l'option PPPD_EXTRA="ipv6 ,"
.Nous
voilà déjà bien avancés (poil au nez).
Lançons la connexion, comme vous avez l'habitude de faire. Si
tout se passe bien, en faisant un ifconfig ppp0 | grep inet6
vous devriez avoir un truc du genre: inet6 addr:
fe80::fc75:ecb8:7e35:1c75/10 Scope:Link.
Puis, il faut attribuer l'adresse ipv6 à l'interface avec /sbin/ifconfig
ethX inet6 add votre:bloc::/48
(2001:7a8:6ee8::/48 par exemple).
Enfin mettre la route par défaut: /sbin/route add -A inet6
2000::/3 ppp0
.
Pour ajouter une adresse à votre interface: /sbin/ifconfig
eth0 inet6 add 2001:7a8:2569::2
par exemple.
Maintenant il vous reste à réinstaller les logiciels dont
vous vous servez avec le support ipv6 (apache, XChat...) En
général un --enable-ipv6
au script configure
suffit, mais il faut toujours lire les READMEs !!!
Maintenant dans le cas où la machine qui vous sert à vous connecter est une passerelle, il faut la configurer en tant que tel...normal en fait :)
Sur le gateway, hop! un p'tit forwarding des paquets: echo 1
> /proc/sys/net/ipv6/conf/all/forwarding
Ensuite le routage des packets gateway<=>clients, on va se servir de ip (comme on aurait pu se servir de ifconfig, c'est kif-kif bourrico)
Sur le gateway:
ip -6 addr add 2001:mon:bloc::1 dev eth0
ip -6 ro add 2001:mon:bloc::/48 dev eth0
ip -6 ro add 2000::/3 dev ppp0
Sur le client:
ip -6 addr add 2001:mon:bloc::2 dev eth0
ip -6 ro add 2001:mon:bloc::/48 dev eth0
ip -6 ro add 2000::/3 via 2001:mon:bloc::1
Pour ceux qui voudraient utiliser radvd, voici un exemple de configuration:
interface eth0
{
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:mon:bloc:1::0/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
De même, réinstallation pour les clients des softs avec le support ipv6.
Vous êtes maintenant une autre personne. Changez de travail, changez d'amis, changez de chaussettes aussi. Vous pouvez surfer l'esprit....et humm...aussi.....heu ouais ! Si vous avez des problèmes ou quoi que ce soit, n'oubliez pas que les newsgroups et irc sont les meilleurs remèdes (j'ai déjà entendu ça quelque part...)
Fin du chapitre