Cette section contient toutes les informations et les questions fr�quemment pos�es que je ne pouvais faire entrer dans la structure ci-dessus.
Cette question n�cessite un peu de r�flexion. Vous pouvez tenter de les organiser pour optimiser la vitesse (minimiser le nombre de v�rifications de r�gles pour la plupart des paquets) ou pour augmenter la maniabilit�.
Si vous avez une connexion intermittente, disons une connexion PPP, vous
pouvez configurer la premi�re r�gle de la cha�ne d'entr�e pour �tre `-i ppp0
-j DENY' au lancement, puis avoir quelque chose comme ceci dans votre script
ip-up :
# Re-cr�e la cha�ne "ppp-in"
ipchains-restore -f < ppp-in.firewall
# Remplace la r�gle DENY par un saut vers la cha�ne se chargeant du ppp
ipchains -R input 1 -i ppp0 -j ppp-in
Votre script ip-down pourrait ressembler � �a :
ipchains -R input 1 -i ppp0 -j DENY
Il y a un certain nombre de choses auxquelles vous devez faire attention avant de commencer � filtrer quelque chose que vous n'auriez pas voulu filtrer.
Les paquets ICMP sont utilis�s (entre autres choses) pour indiquer des probl�mes aux autres protocoles (comme TCP et UDP). Les paquets "destination-unreachable" (destination non accessible) en particulier. Le bloquage de ces paquets signifie que vous n'obtiendrez jamais les erreurs "Host unreachable" ou "No route to host" ; toute connexion attendra une r�ponse qui ne viendra jamais. C'est irritant, mais rarement fatal.
Un probl�me plus inqui�tant est le r�le des paquets ICMP dans la d�couverte MTU. Toutes les bonnes impl�mentations de TCP (y compris celle de Linux) utilisent la recherche MTU pour tenter de trouver quel est le plus grand paquet qui peut atteindre une destination sans �tre fragment� (la fragmentation diminue les performances, principalement lorsque des fragments occasionnels sont perdus). La recherche MTU fonctionne en envoyant des paquets avec le bit "Don't Fragment" mis, et en envoyant ensuite des paquets plus petits s'il re�oit un paquet ICMP indiquant "Fragmentation needed but DF set" (`fragmentation-needed'). C'est un paquet de type "destination-unreachable", et s'il n'est jamais re�u, l'h�te local ne r�duira pas le MTU, et les performances seront abyssales ou inexistantes.
Notez qu'il est commun de bloquer tous les messages ICMP de redirection (type 5) ; ils peuvent �tre utilis�s pour manipuler le routage (bien que les piles IP bien con�ues disposent de gardes-fou), et sont donc souvent consid�r�s comme quelques peu risqu�s.
Si vous tentez de bloquer toutes les connexions TCP sortantes, rappellez vous que le DNS n'utilise pas toujours UDP ; si la r�ponse du serveur d�passe les 512 octets, le client utilise une connexion TCP (allant toujours sur le port num�ro 53) pour obtenir les donn�es.
Ceci peut �tre un pi�ge car le DNS fonctionnera "en gros" si vous interdisez de tels transferts TCP ; vous pouvez exp�rimenter des d�lais longs et �tranges, et d'autres probl�mes li�s au DNS si vous le faites.
Si les demandes de votre DNS sont toujours dirig�es vers les m�mes sources
externes (soit directement en utilisant la ligne nameserver dans
/etc/resolv.conf ou en utilisant un serveur de noms cache en mode de
redirection), alors vous n'aurez besoin d'autoriser que les connexions du
port domain sur ce serveur de nom � partir du port local domain
(si vous utilisez un serveur de nom cache) ou d'un port �lev� (> 1023) si
vous utilisez /etc/resolv.conf.
L'autre probl�me classique du filtrage de paquets est celui pos� par le FTP. Le FTP a deux modes ; le mode traditionnel est appel� mode actif et le plus r�cent est appel� mode passif. Les navigateurs web utilisent souvent le mode passif par d�faut, mais les programmes de ftp en ligne de commmande utilisent en g�n�ral par d�faut le mode actif.
En mode actif, lorsque l'h�te distant d�sire envoyer un fichier (ou m�me les
r�sultats d'une commande ls ou dir), il essaye d'ouvrir une
connexion TCP sur la machine locale. Cel� signifie que vous ne pouvez filtrez
ces connexions TCP sans supprimer le FTP actif.
Si vous avez comme option l'utilisation du mode passif, alors tout va bien ; le mode passif fait passer les connexions de donn�es du client au serveur, m�me pour les donn�es arrivantes. Autrement, il est recommend� de n'autoriser que les connexions TCP vers les ports sup�rieurs � 1024 et de les interdire entre 6000 et 6010 (6000 est utilis� par X-Windows).
Les machines Linux sont maintenant immunis�es du fameux Ping of Death, qui implique l'envoi de paquets ICMP ill�galement grands qui font d�border les buffers de la pile TCP du r�cepteur et causent de gros d�g�ts.
Si vous voulez prot�ger des machines qui peuvent �tre vuln�rables, vos pouvez simplement bloquer les fragments ICMP. Les paquets ICMP normaux ne sont pas assez gros pour n�cessiter la fragmentation, et vous ne casserez rien � part les gros pings. J'ai entendu parler (non confirm�) de rapports comme quoi quelques syst�mes ont seulement besoin du dernier fragment d'un paquet ICMP d�form� pour les corrompre, donc bloquer seulement le premier fragment n'est pas recommand�.
M�me si tous les programmes exploitant cette erreur que j'ai vu utilisent l'ICMP, il n'y a pas de raisons qu'un fragment TCP ou UDP (ou d'un protocole inconnu) ne puisse �tre utilis� pour cette attaque, donc le bloquage des fragments ICMP est seulement une solution temporaire.
Teardrop et Bonk sont deux attaques (principalement contre les machines sous Microsoft Windows NT) qui reposent sur des fragments superpos�s. Avoir votre routeur Linux d�fragmenter, ou interdisant tous les fragments vers vos machines vuln�rables sont d'autres options.
Quelques piles TCP moins fiables sont connues pour avoir des probl�mes � g�rer de larges ensembles de fragments de paquets lorsqu'elles ne re�oivent pas tous les fragments. Linux n'a pas ce probl�me. Vous pouvez filtrer les fragments (ce qui peut casser les utilisations l�gitimes) ou compiler votre noyau avec l'option "IP: always defragment" mise sur "Y" (seulement si votre machine Linux est la seule route possible pour ces paquets).
Il y a quelques probl�mes de temps qui sont impliqu�s dans la modification des r�gles pare-feu. Si vous n'y faites pas attention, vous pouvez laisser entrer des paquets lorsque vous avez fait la moiti� de vos changements. Une approche simpliste serait de faire la suite :
# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY
... Mise en place des changements ...
# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#
Ceci supprime tous les paquets pour la dur�e des changements.
Si vos changements sont restreints � une cha�ne simple, vous pouvez cr�er une nouvelle cha�ne avec les nouvelles r�gles, et ensuite remplacer ("-R") la r�gle qui pointait sur la vieille cha�ne par une qui pointe sur la nouvelle cha�ne ; ensuite, vous pouvez supprimer la vieille cha�ne. Le remplacement se fera � vitesse atomique.
L'IP spoofing est une technique dans laquelle un h�te envoie des paquets qui pr�tendent venir d'un autre h�te. Puisque le filtrage des paquets prend ses d�cisions sur la base de cette adresse source, l'IP spoofing est utilis� pour abuser les filtres de paquets. Elle est �galement utilis�e pour cacher l'identit� d'un attaquant utilisant les techniques SYN, Teardrop, Ping of Death et autres d�riv�s (ne vous inqui�tez si vous ne savez pas ce que c'est).
Le meilleur moyen de se prot�ger de l'IP spoofing est la v�rification de
l'adresse source, et il est r�alis� par le code de routage, et non par le
pare-feu et autres.
Cherchez un fichier nomm� /proc/sys/net/ipv4/conf/all/rp_filter.
S'il existe, alors l'activation de la
v�rification de l'adresse source � chaque lancement est la bonne solution pour
vous. Pour se faire, ins�rez les lignes suivantes quelque part dans vos
scripts d'initialisation, avant l'initialisation des interfaces r�seau :
# This is the best method: turn on Source Address Verification and get
# spoof protection on all current and future interfaces.
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n "Setting up IP spoofing protection..."
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1> $f
done
echo "done."
else
echo PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED.
echo "CONTROL-D will exit from this shell and continue system startup."
echo
# Start a single user shell on the console
/sbin/sulogin $CONSOLE
fi
Si vous ne pouvez faire ceci, vous pouvez ins�rer manuellement les r�gles pour
prot�ger chaque interface. Ceci n�cessite la connaissance de chaque interface.
La s�rie des noyaux 2.1 et sup�rieurs rejette automatiquement les paquets qui
pr�tendent venir des adresses 127.* (r�serv�es pour l'interface de loopback,
lo).
Par exemple, disons que vous avez trois interfaces, eth0, eth1 et
ppp0. Nous pouvons utiliser ifconfig pour nous donner les adresses
et les masques de r�seau de chaque interface. Disons que eth0 est
rattach�e � un r�seau 192.168.1.0 avec le masque de sous-r�seau 255.255.255.0,
eth1 est raccord�e � un r�seau 10.0.0.0 avec le masque de sous-r�seau
255.0.0.0, et ppp0 connect�e � l'Internet (o� toutes les adresses sauf
les adresses IP priv�es r�serv�es sont autoris�es), nous ins�rerions les
r�gles suivantes :
# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#
Cette approche n'est pas aussi bonne que l'approche par v�rification de l'adresse source, parce que si votre r�seau change, vous devrez changer vos r�gles pare-feu pour �tre � jour.
Si vous utilisez un noyau de s�rie 2.0, vous pouvez �galement vouloir prot�ger l'interface loopback, en utilisant une r�gle telle que :
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#
Il y a une biblioth�que dans l'espace utilisateur que j'ai �crit et qui est inclue avec la distribution source, nomm�e "libfw". Elle utilise la capacit� de IP Chains 1.3 et suivants pour copier un paquet vers l'espace utilisateur (via l'option du noyau IP_FIREWALL_NETLINK).
La valeur "mark" peut �tre utilis�e pour sp�cifier les param�tres de Qualit� de Service pour les paquets, ou pour sp�cifier comment les paquets doivent �tre renvoy�s. Je ne l'ai cependant jamais utilis�e, mais si vous voulez �crire sur ce sujet, contactez moi.
Des choses comme le stateful inspection (je pr�f�re le terme "pare-feu dynamique") peuvent �tre impl�ment�es dans l'espace utilisateur en utilisant cette biblioth�que. D'autres id�es g�niales peuvent �tre le contr�le des paquets sur une base "par utilisateur" en faisant une demande sur un d�mon r�sidant dans l'espace utilisateur. Ceci devrait �tre relativement simple.
ftp://ftp.interlinx.bc.ca/pub/spf est le site du projet SPF de Brian Murrell, qui permet le suivi de connexion dans l'espace utilisateur. Ceci ajoute une dose significative de s�curit� pour les sites � faible bande passante.
Il y a peu de documentation pour le moment, mais voici un message que Brian a envoy� � la liste de diffusion en r�pondant � quelques questions :
> Je pr�sume qu'il fait exactement ce que je veux~: installer une r�gle de> "retour" temporaire pour laisser entrer des paquets en r�ponse � une> requ�te ext�rieure.
Yup, c'est exactement ce � quoi il sert. Plus il comprendra de protocoles,
plus il obtiendra de r�gles de retour exactes. Pour l'instant il supporte
(de m�moire, excusez les erreurs ou les omissions) le FTP (� la fois actif et
passif, int�rieur et ext�rieur), un peu de RealAudio, de traceroute, d'ICMP et
d'un ICQ basique (transmission des serveurs ICQ, connexions TCP directes, mais
h�las la seconde connexion directe TCP pour des trucs comme le transfert de
fichiers, etc., ne sont pas encore pr�sentes)> S'agit-il d'un rempla�ant pour ipchains ou d'un ajout~?
C'est un ajout. Pensez � ipchains comme �tant le moteur pour autoriser et
emp�cher les paquets de traverser une machine Linux. SPF est le pilote, g�rant
et surveillant constamment le traffic et disant � ipchains comment changer ses
polices pour refl�ter les changements dans les sch�mas du traffic.
Michael Hasenstein de SuSE a cod� un correctif pour le noyau qui ajoute le suivi des connexions ftp � ipchains. Celui-ci peut �tre trouv� sur http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz
Les codes de pare-feu et de NAT sont en cours de remise � jour pour le 2.3. Les plans et les discussions sont disponibles sur l'archive de netdev, et sur la liste ipchains-dev. Ces extensions doivent nettoyer de nombreux probl�mes d'utilisation (r�ellement, la mise en place du pare-feu et le camouflage ne devrait pas �tre aussi dur, et devrait autoriser une croissance pour un pare-feu beaucoup plus flexible).
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:35