Warning! Ces informations ont plus de 10 ans! Elle pourraient etre imprécises et non applicables!
Dernière version: 0.31 . 24/8/2003
Warning! Ces informations ont plus de 10 ans! Elle pourraient etre imprécises et non applicables!
Vous désirez sécuriser votre installation Linux de base tout en
étant toujours capable de vous logger, de faire tourner un serveur ftp ou http publique sur Internet ?
Cette page est faite pour Vous ! 
English version here !
Vous y trouverez des astuces pour améliorer la sécurité de votre système par l'utilisation d'IPChains, IPTables, et des TCP Wrappers. Vous découvrirez aussi des options de configuration subtiles pour Sendmail, Postfix, Bind, NFS et autres.
Ces informations ont été testées sur des distributions Red Hat et Mandrake mais elles devraient être valables pour d'autre également.
Envoyez vos commentaires ou astuces ici !.
Votre système est-il sûr ? (Pour les nuls)
IP Chains (kernel 2.2.x)
IP Tables (kernel 2.4.x)
TCP Wrappers et Inetd
Mail Transport Agents:
Sendmail
Exim
Postfix
Smail
DNS, Bind
Samba
Apache
RPC et NFS
Lpd
Pour répondre à cette question, vous devez dresser la liste des trous potentiels de sécurité réseau. Chaque port Tcp ou Udp ouvert, peut étre utilisé pour attaquer votre système, et est donc un trou de sécurité potentiel. Pour voir quels ports sont ouverts, lancez 'netstat -a'. Vous obtiendrez par exemple:
Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 1 0 localhost:12653 localhost:www CLOSE_WAIT tcp 1 0 localhost:12652 localhost:www CLOSE_WAIT tcp 1 0 sone.cf.fr:12642 chaines.voila.fr:www CLOSE_WAIT tcp 81 0 sone.cf.fr:11709 graft.XCF.Berkeley.:ftp CLOSE_WAIT tcp 0 0 sone.cf.fr:1023 graft.XCF.Berkeley.o:22 ESTABLISHED tcp 0 0 *:6000 *:* LISTEN tcp 0 0 *:1024 *:* LISTEN tcp 0 0 *:22 *:* LISTEN tcp 0 0 *:www *:* LISTEN tcp 0 0 *:printer *:* LISTEN tcp 0 0 *:login *:* LISTEN tcp 0 0 *:ftp *:* LISTEN udp 0 0 *:177 *:* udp 0 0 *:syslog *:* raw 0 0 *:1 *:* Active UNIX domain sockets (including servers) .... ....
Ci-dessus, Vous pouvez voir la liste des connections ouvertes (Celles où 'State=ESTABLISHED'), et des serveurs Tcp à l'écoute des connections entrantes (State=LISTEN). Des serveurs Udp écoutent également bien que 'LISTEN' ne soit pas indiqué. La colonne 'Local Address' des serveurs à l'écoute (LISTEN) est une des plus importantes de par les informations qu'elle délivre:
Si vous lancez 'netstat -nap' vous pouvez même connaître le nom des programmes ayant ouvert ces ports (et 'fuser -n tcp [port]' peut également être utilisé pour identifier des ports ouverts).
Sur l'exemple nous avons vu, les services de login,www,ftp,printer,syslog tournaient sur le système et aussi d'autres comme ssh (port 22), X11 (port 6000). (référez-vous au fichier '/etc/services' pour les conversions nom<->numéro de port).
Lorsque l'interface réseau est '*', alors le service concerné sera certainement vu depuis votre réseau externe, et donc n'importe qui peut ESSAYER de se connecter à ce service. Ceci est un MAUVAIS signe pour votre sécurité et vous devriez essayer de trouver si le serveur permet de mettre en place une Liste de Controle d'accès (LCA) pour sécuriser les choses (pour tout savoir sur les LCA, voir plus bas).
Par contre, si l'interface réseau est une adresse IP, cela signifie que le serveur ne répond aux éventuelles connexions que sur l'interface réseau qui a CETTE adresse IP. Par exemple si nous avons 'localhost:ftp', alors le serveur ftp est lié à l'interface de localhost (le 'loopback'), et il ne sera donc pas vu depuis votre réseau Ethernet ou votre connection internet PPP. C'est CE BUT qu'il FAUT atteindre, car vous pourrez faire tourner des services sur votre machine sans que personne sur l'internet ne les voient !
Notez donc qu'un numéro d'interface réseau autre que 'localhost', est mauvais, car cela signifie certainement que le service peut être vu à l'extérieur de votre machine. Vérifiez donc alors vos LCAs !
Maintenant que vous avez identifié les services trounant sur votre machine, vous voulez certainement vérifier votre serveur de l'extérieur. Pour ceci loggez vous sur un compte distant et utilisez Nmap, LE scanneur de ports furtif (téléchargez le ici). Ensuite, par exemple, lancez 'nmap votre.adress.ip', et vous obtiendrez la liste de tous les services ouverts sur votre machine et qui peuvent être vus par n'importe qui depuis l'extérieur (Internet peut-être).
Avec toutes ces informations réunies, il est enfin temps de fermer les trous de sécurité et de désactiver les serveurs / services dont vous n'avez pas l'utilité.
Une des meilleures facons de fermer ces trous de sécurité (les ports réseau ouverts) est d'utiliser le mécanisme de parre-feu du kernel Linux 2.2: IP Chains. ('man ipchains' pour plus d'info). Les noyaux de la série 2.4.x utilisent 'iptables' qui sera couvert dans la section suivante.
Plus bas, vous trouverez un script type de configuration IPChains à ajouter au fichier '/etc/rc.d/rc.local', et qui va:
# Script IPChains generique, accepte tout par defaut
# chemin de l'executable ipchains
IPC=/sbin/ipchains
# mettez l'adresse de votre réseau local ci-dessous
mynet=10.0.0.0/24
# l'interface réseau que vous voulez sécuriser
# Ici,toute interface PPP si vous vous connectez à internet grace à une lien modem PPP.
iface=ppp+
# exclure le serveur dns, X11 , lpd
tcp="53 6000:6010 515"
# exclure dns,xdmcp,nfS;
udp="53 177 2049"
# effacer les précédentes règles
$IPC -F input
$IPC -F forward
$IPC -F output
# règles pour l'IP masquerading (utile seulement pour protéger les machines
# se connectant à internet grace à votre serveur)
$IPC -N user_msq
$IPC -F user_msq
$IPC -A user_msq -s 0/0 -d 0/0 -j MASQ
$IPC -A forward -s $mynet -d 0/0 -i $iface -j user_msq
/sbin/modprobe ip_masq_ftp
# désactive les réponses ping et les logger, vous aurez dans /var/log/messages
#les adresses IP des petits Hackers essayant de vérifier si votre serveur est en marche.
$IPC -A input -l -i $iface -p icmp -s 0.0.0.0/0 echo-request -j DENY
# amélioration des débits (0x08) et délais (0x10)
$IPC -A output -p tcp -d 0/0 telnet -t 0x01 0x10
$IPC -A output -p tcp -d 0/0 ssh -t 0x01 0x10
$IPC -A output -p tcp -d 0/0 ftp -t 0x01 0x10
$IPC -A output -p tcp -s 0/0 ftp-data -t 0x01 0x08
# blocage des tentatives d'IPspoofing (et log)
$IPC -A input -i $iface -s $mynet -l -j DENY
# blocage des ports serveurs
for p in $tcp ; do
$IPC -A input -p tcp -i $iface -s 0/0 -d 0/0 $p -j REJECT --syn
done
for p in $udp ; do
$IPC -A input -p udp -i $iface -s 0/0 -d 0/0 $p -j REJECT
done
Bien sûr, vous pouvez rejeter plus de ports si vous le désirez en ajoutant leurs numéros dans les variables tcp et udp.
Au dessus, la politique par défaut était d'ACCEPTer les paquets IP et de rejeter (REJECT) certains d'entre eux. Nous pouvons faire l'inverse. Cette dernière technique est plus sure mais elle peut conduire à de nombreux programmes ne fonctionnant plus (car on risque d'exclure alors plus de ports que necessaire). Voici le script:
# Script IPChains generique, rejette tout par defaut
# chemin de l'executable ipchains
IPC=/sbin/ipchains
# mettez l'adresse de votre réseau local ci-dessous
mynet=10.0.0.0/24
# l'interface réseau que vous voulez sécuriser
# Ici,toute interface PPP si vous vous connectez à internet grace à une lien modem PPP.
iface=ppp+
# autoriser le web et ssh
tcp="80 22"
# autoriser talk ntalk, et les requetes DNS;
udp="517 518 53"
# politique par défaut: rejeter
$IPC -P input reject
# effacer les précédentes règles
$IPC -F input
$IPC -F forward
$IPC -F output
# règles pour l'IP masquerading (utile seulement pour protéger les machines
# se connectant à internet grace à votre serveur)
...
... idem
...
# désactive les réponses ping et les logger, vous aurez dans /var/log/messages
#les adresses IP des petits Hackers essayant de vérifier si votre serveur est en marche.
...
# amélioration des débits (0x08) et délais (0x10)
...
... idem
...
# déblocage des ports serveurs
for p in $tcp ; do
$IPC -A input -p tcp -i $iface -s 0/0 -d 0/0 $p -j ACCEPT
done
for p in $udp ; do
$IPC -A input -p udp -i $iface -s 0/0 -d 0/0 $p -j ACCEPT
done
Cet outil de filtrage de nouvelle génération fait partie des nombreuses nouveautés des noyaux Linux 2.4.x. Néanmoins, vous pouvez toujours utiliser ipchains avec le 2.4 mais vous feriez mieux de l'oublier, iptables est plus rapide, plus flexible, extensible et peut faire beaucoup d'autres choses, comme: le NAT source, NAT destination, éviter plusieurs formes d'attaques par surcharge de service (DoS, Denial of Service), et plus encore...
Mais, pour l'instant nous allons voir comment modifier notre script générique ipchains pour qu'il utilise iptables. Le voilà:
# Script IPTables generique, accepte tout par defaut # chemin de l'executable iptables IPT=/sbin/iptables # mettez l'adresse de votre réseau local ci-dessous mynet=10.0.0.0/24 # l'interface réseau que vous voulez sécuriser # Ici,toute interface PPP si vous vous connectez à internet grace à une lien modem PPP. iface=ppp+ # les listes de ports a rejeter # rejeter tous les ports privilégiés (<1024) sauf ssh, + squid postgres linuxconf tcp="1:21 23:1023 3128 5432 10000" # rejeter tous les ports privilégiés (<1024) sauf dns, + nfs udp="1:52 54:1023 2049" # effacer les précédentes règles $IPT -F INPUT $IPT -F OUTPUT $IPT -F FORWARD $IPT -F POSTROUTING -t nat $IPT -F PREROUTING -t nat $IPT -F OUTPUT -t nat # règles pour l'IP masquerading $IPT -t nat -A POSTROUTING -s $mynet -o $iface -d 0/0 -j MASQUERADE # désactive les réponses ping et les logger, vous aurez dans /var/log/messages #les adresses IP des petits Hackers essayant de vérifier si votre serveur est en marche. $IPT -A INPUT -i $iface -p icmp -s 0.0.0.0/0 --icmp-type echo-request -j LOG $IPT -A INPUT -i $iface -p icmp -s 0.0.0.0/0 --icmp-type echo-request -j DROP # amélioration des débits (0x08) et délais (0x10) $IPT -t mangle -A OUTPUT -p tcp -d 0.0.0.0/0 --dport telnet -j TOS --set-tos 0x10 $IPT -t mangle -A OUTPUT -p tcp -d 0.0.0.0/0 --dport ssh -j TOS --set-tos 0x10 $IPT -t mangle -A OUTPUT -p tcp -d 0.0.0.0/0 --dport ftp -j TOS --set-tos 0x10 $IPT -t mangle -A OUTPUT -p tcp -d 0.0.0.0/0 --dport ftp-data -j TOS --set-tos 0x08 # blocage des tentatives d'IPspoofing (et log) $IPT -A INPUT -i $iface -s $mynet -j LOG $IPT -A INPUT -i $iface -s $mynet -j DROP # blocage des ports serveurs for p in $tcp ; do $IPT -A INPUT -p tcp -i $iface -s 0/0 -d 0/0 --dport $p -j REJECT --reject-with tcp-reset done for p in $udp ; do $IPT -A INPUT -p udp -i $iface -s 0/0 -d 0/0 --dport $p -j REJECT done
Une nouvelle option '--reject-with tcp-reset' permet de rendre le firewall totalement transparent vis-a-vis des scanneurs de port. (Si vous voulez faire la meme chose avec ipchains, vous aurez besoin du démon 'Return-RST'). Comme vous le voyez, un script de base IPTables n'est pas vraiment différent d'un IPChains. Et si vous voulez faire des choses beaucoup plus compliquées, iptables sera plus à l'aise qu'ipchains.
Attention ! Si vous avez des problèmes de résolution de noms, c'est que vous avez rejeté trop de ports UDP. Si vous n'utilisez pas un serveur de noms local, des ports aléatoires UDP (au dessus de 1024), vont être utilisés par la libc pour la résolution de noms, c'est pour cela que vous devez laisser ouvert les ports supérieurs à 1024, ce qui n'est pas satisfaisant d'un point de vue sécurité. Pour avoir le contrôle sur ces ports UDP, vous devez installer un serveur de noms (bind 8.x ou 9.x), et ajouter la ligne "query-source address * port 53;" dans named.conf pour fixer le port qui servira aux requêtes DNS à 53. Après cela, il vous suffit d'ouvrir le port 53 sur votre firewall (vous pouvez bien sûr utiliser un port autre que le 53).
Une des choses les plus importantes est de sécuriser les TCP Wrappers. En effet, une installation de base va activer de nombreux services (lancés par Inetd) que vous n'utiliserez jamais. Souvenez-vous que plus de services activés, signifie plus de trous de sécurité potentiels.
Donc éditez /etc/inetd.conf et effacez toute ligne qui n'est pas utile. En particulier: echo, discard, daytime, chargen, telnet, gopher, shell, login (et à la place utilisez SSH ), exec, *talk, pop-*, imap, uucp, *finger, netstat, time, linuxconf. Vous devriez laisser le service 'auth' , afin d'être capable d'obtenir quelques informations supplémentaires au cas où votre système était utilisé pour en attaquer un autre: Il permet à un serveur de connaitre l'utilisateur qui est derrière un socket ce qui aide à trouver les coupables. (ou désactivez le si vous voulez devenir un Cr4CkeR ;-)
Ensuite, si vous avez Vraiment BESOIN de certains services comme ftp, smtp, nntp, imap, pop-3, vérifiez qu'ils sont lancés par l'intermédiaire des TCP Wrappers (/usr/sbin/tcpd) et et que ces derniers sont correctement configurés. Par exemple, si ftp est lancé par les TCP Wrappers, vous devez avoir la ligne suivante dans /etc/inetd.conf :
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
Pour restreindre l'accès à un service, vous devez éditer les fichiers /etc/hosts.deny et /etc/hosts.allow. Un bon point de départ est d'ajouter la ligne suivante à /etc/hosts.deny pour refuser tout accès aux services d'Inetd:
ALL: ALL
Vous pouvez également décider de lancer un script lorsqu'un accès est refusé:
ALL: ALL: (/usr/sbin/safe_finger -l @%h -s %d-%h | mail root) &
Cette ligne va tenter un 'finger' sur la machine du cracker et va envoyer un rapport à root. Ou vous pouvez tenter d'utiliser le service ident (rfc931) de l'attaquant afin de logger son login ainsi que son IP:
ALL: ALL: rfc931
Ensuite dans /etc/hosts.allow, vous pouvez donner accès à certaines machines de votre réseau local:
ALL: LOCAL 10.0.0.
Vous pouvez ajouter une ligne par type de service:
ftp: 10.0.0.1
va autoriser l'utilisation du serveur ftp seulement depuis la machine 10.0.0.1
Ou même
ftp: linus@10.0.0.1
pour autoriser un seul utilisateur.
Pour plus d'information sur la syntaxe de ces fichiers faire un 'man hosts_acces'. Et utilisez ssh / openssh en tant qu'alternative sécurisée à rcp, rlogin, telnet, ftp...
Sendmail a été un des logiciels les plus buggés et a souvent été utilisé pour compromettre des systèmes.
La première règle de sécurité avec Sendmail est donc de toujours utiliser la dernière version (Ceci est aussi de toutes facon vrai pour les autres serveurs).
La deuxième est de bidouiller l'infâme fichier /etc/sendmail.cf:
- si vous utilisez Sendmail seulement pour envoyer du mail sans passer par la passerelle de votre FAI, alors ajoutez 'O DaemonPortOptions=Addr=127.0.0.1'. Ainsi, Sendmail
sera lié uniquement à l' interface loopback, et il ne sera donc pas vu
l'Internet ! (netstat affichera '127.0.0.1:smtp' et non pas '*:smtp').
Vous pouvez aussi mettre l'IP de votre interface ethernet à la place de 127.0.0.1
mais, cette fois vous ne pourrez pas envoyer de mail localement mais les autres machines
de votre réseau pourront utiliser votre Sendmail, sans que des hackers sur internet ne puissent le voir !
- Ajoutez 'O PrivacyOptions=goaway' pour désactiver la commande smtp VRFY qui peut
être utilisée pour découvrir des informations sur les comptes utilisateur de votre serveur.
La troisième règle est de mettre les adresses IP qui peuvent utiliser Sendmail dans le fichier /etc/mail/ip_allow.
Si votre Sendmail doit être vu depuis n'importe quelle interface et que vous n'avez pas peur de charger votre CPU, vous pouvez le faire tourner sous Inetd (avec 'sendmail -bs') , de facon à utiliser les LCA des TCPWrappers. Dans ce cas, lancez périodiquement 'sendmail -q30m' pour vider la queue.
Pour terminer, voici un petit truc pour résoudre un problème courant
si vous utilisez Netscape Communicator pour surfer et envoyer du mail: votre
email sera utilisé à la fois pour le ftp et pour l'email. Par conséquent, n'importe qui sur le WEB,
peut récupérer votre adresse email:
- Ils mettent un lien bidon en ftp sur leur page Web
- lorsque vous visualisez la page, Communicator se connecte au site ftp (pour
récupérer une image par example)
- et votre email est loggé par le serveur ftp, pret à être diffusé par les spammers !
Pour éviter ceci, mettez en place un masquage d'adresse email. Pour ce faire utilisez Linuxconf ou bidouillez 'sendmail.cf'. Si vous les lignes suivantes à 'sendmail.cf':
# Masquerading rules S1 Rwarez<@mail.net> $@ me < @ mail.net> Rwarez<@mail.net.> $@ me < @ mail.net.>
ET ensuite initialisez votre email dans Communicator à 'warez@mail.net',
-si vous vous connectez à un site ftp, vous enverrez 'warez@mail.net' et
votre véritable email ne sera pas dévoilé.
- mais si vous envoyez un mail, Sendmail va remplacer 'warez@mail.net'
par votre véritable email 'me@mail.net'.
Et à l'arrivée, tout ce que vous remarquerez, ce sera
beaucoup moins de Spam dans votre courrier.
Finalement, ne négligez pas l'option de lancer Sendmail dans une prison 'chroot' (ou de ou de le faire tourner sans les droits du superutilisateur 'root'. La plupart des serveurs (http, ftp,...) proposent ce type d'options, pour maximiser la sécurité, et pour se protéger de 'bugs pas encore découverts'.
Exim, mon MTA favori, et également le MTA choisi par défaut par le projet Debian, comporte de nombreuses options orientées sécurité. Par exemple, vous pouvez restreindre l'acces a Exim avec l'option 'host_reject' :
host_reject = !1.1.1 : *.com
La ligne ci-dessus, rejettera toute machine du domaine .com, ou n'appartenant pas au sous réseau 1.1.1 . Comme Exim est tres flexible, si vous désirez un controle d'acces plus dynamique, rien ne vous empeche d'exécuter des requettes LDAP ou MySQL :
host_reject = ${lookup ldap {user="cn=manager,o=mysite,c=com" pass=secret
ldap:///o=mysite,c=com?host?(cn=foo)} {$value}fail}
ou
host_reject = ${lookup mysql{select host from acl where id='ph10'}{$value}fail}
Dans le meme genre, avec l'option 'host_accept_relay' vous pouvez controler quelles machines peuvent utiliser votre MTA en tant que relais vers des domines arbitraires.
Et si en plus, vous desirez faire écouter Exim sur une interface réseau specifique, il vous suffit simplement utiliser l'option 'local_interfaces' comme indiqué ci-dessous:
local_interfaces = 127.0.0.1 : ::::1 # adresse IPv6
Tout ceci n'est qu'une infime partie des possibilites d'Exim, et j'espere donc que vous allez vous jeter dans la doc d'Exim et y decouvrir sa puissance (qui plus est, a la portee de tous).
Postfix a une option, 'inet_interfaces', similaire à l'option "DaemonPortOptions=Addr" de Sendmail mais ce qui est super ici est que vous pouvez spécifier plus d'une interface !
Smail posséde l'option 'listen_name' similaire au "DaemonPortOptions=Addr" de Sendmail.
De plus, avec l'option 'smtp_remote_allow' vous pouvez un controle d'accés simple basé sur le nom de la machine cliente.
Si vous jetez un coup d'oeil à des archives sécurité, vous verrez que, comme Sendmail, Bind a un lourd passé. Donc, installez toujours la dernière version.
Mais heureusement, vous pouvez facilement ajouter des LCA dans '/etc/named.conf'. Dans l'exemple plus bas vous pouvez voir l'init d'une LCA nommée 'internal' qui contient la spécification d'un réseau local. Vous pouvez ajouter autant de sections 'acl' que vous le voulez. Ensuite dans la sous-section 'allow-query' de la section 'options', vous pouvez ajouter vos LCA globales . L'option 'allow-query' peut peut aussi être locale à une zone de votre DNS.
acl internal {
10.0.0.0/24;
127.0.0.0/24;
};
options {
allow-query {
internal;
};
};
De la même facon vous devriez restreindre les transferts de zones avec la directive 'allow-transfer' dans la définition d'une zone, étant donné que la topologie de votre réseau peut être une source d'information importante pour un cracker qui voudrait s'introduire.
Ajouter l'option "query-source address * port 53;", permet de fixer le port UDP utilisé pour les requêtes DNS, et donc de n'avoir qu'un seul port UDP bien identifié à ouvrir sur le firewall (le 53, ou un autre de votre choix).
Comme avec la majorité des serveurs, vous pouvez aussi faire tourner Bind dans une prison 'chroot' (option -t en ligne de commande), et/ou sous un autre utilisateur que 'root' (option -u en ligne de commande), pour minimiser les dégâts en cas d'intrusion.
Les LCA sont ici initialisées par le paramètre 'hosts allow' . Il peut être présent soit dans la section '[global]' du fichier 'smb.conf', soit dans toute section de partage. Comme vous le voyez plus bas, la syntaxe est triviale:
hosts allow = 10.0.0., 127. , myhost.mydomain
ou
hosts allow = 10.0.0. EXCEPT 10.0.0.200
ou même,
hosts allow = 10.0.0.0/255.255.255.0
Vous pouvez aussi vous amuser avec le paramètre 'host deny' qui a l'effet inverse. Bien sur, Samba propose un support pour lié le serveur à une seule interface réseau avec le paramètre 'bind interface only' qui peut être présent dans la section 'global'.
Illustration:
bind interfaces only = True
interfaces = 192.168.0.0/255.255.255.0
Le contrôle d'accès sous Apache est extrêmement puissant et flexible.
Ci-dessous, vous pouvez voir comment protéger une seule page (ajoutez ceci dans le fichier 'httpd.conf'). Bien sur, vous pouvez protéger des répertoires entiers en remplacant '<Files' par '<Directory'. Notez que le domaine d'autorisation (chaine de caractères après AuthName) doit être unique. Pour créer le fichier de mots de passe (/home/bill/apache.htpasswd dans cet exemple), utilisez l'utilitaire 'htpasswd'.
<Directory /home/bill/public_html>
<Files thesecret.file>
AuthName "Bill secret stuff"
AuthType Basic
AuthUserFile /home/bill/apache.htpasswd
Require valid-user
</Files>
</Directory>
Ci-dessous, un exemple de configuration plus intéressant.
Il montre comment faire pour, obtenir un accès sans restrictions
à un fichier lorsque le client est sur un réseau local
(10.0.0.0/255.0.0.0), mais lors d'un accès externe,
un mot de passe devient nécessaire:
<Files foo.html>
Order Deny,Allow
Deny from All
Allow from 10.0.0.0/255.0.0.0
AuthName "Insiders Only"
AuthType Basic
AuthUserFile /home/httpd/etc/htpasswd
Require valid-user
Satisfy Any
</Files>
Au lieu d'un réseau entier (10.0.0.0/255.0.0.0), vous pouvez également rejeter une seule machine avec 'Allow from 10.2.3.4' ou 'Allow from foo.com', cependant la dernière forme peut ralentir le serveur à cause des requetes DNS inverses qu'elle entrainera.
En fait, les possibilités de sécurisation et de log d'Apache sont si puissantes, qu'une description complète dépasse le but de cette page. Referez vous au manuel d'Apache pour plus d'informations.
La dernière version de RPC (qui est utilisé par NFS) utilise les mêmes fichiers qu'Inetd pour le contrôle d'accès. Donc, pour que votre NFS soit un peu plus sûr vous pouvez ajouter une ligne de ce type à '/etc/hosts.allow'
portmap: 127.0.0.1 10.0.0.2 10.0.0.1 255.255.255.255 0.0.0.0
et ceci, à '/etc/hosts.deny':
portmap: ALL: (/usr/sbin/safe_finger -l @%h | mail root) &
Autre problème: les programmes utilisant les RPC, choisissent souvent un port de facon aléatoire, ce qui rend la configuration d'un pare-feu plus compliquée. Par example 'NFS' utilise la plupart du temps le port 2049 mais 'mountd' choisit un port inutilisé supérieur à 1024. Heureusement, vous pouvez forcer le port de 'mountd': ajoutez l'option '-P 909' sur la ligne de lancement de rpc.mount. Le filtrage des port UDP de mountd est maintenant trivial !
Le démon standard de gestion d'impression permet de définir des LCA de base en ajoutant les machines autorisées au fichier '/etc/hosts.lpd'. Je ne sais pas si Lprng, le 'new generation line printer daemon', propose plus d'options de sécurité réseau. Mais de toute facon il devrait être plus robuste que Ldp. Si vous pouvez, passez à Lprng.
All pages and graphics are copyrighted. copyright © 1998-2000 Ludovic Drolez.
