Partage d’une connexion en utilisant SQUID & IPTABLES

Ce TP permet de découvrir et de mettre en œuvre le partage d’une connexion Internet à l’aide du serveur proxy SQUID et du firewall logiciel IPTABLES. Il enseigne la configuration d’un proxy cache, l’authentification, le filtrage, la mise en place d’un proxy transparent, ainsi que la gestion des règles de translation d’adresses et de filtrage réseau avec IPTABLES. Pour réaliser ce TP, il est nécessaire de disposer d’un environnement avec plusieurs machines virtuelles Linux (Fedora, OpenSuse, Ubuntu) et un serveur Windows, avec les paquets SQUID, IPTABLES, htpasswd, et les outils réseau comme Wireshark et Telnet installés.

Objectifs

• Mettre en place un serveur proxy SQUID pour partager une connexion Internet.
• Configurer le cache SQUID et comprendre son fonctionnement.
• Mettre en œuvre l’authentification et le filtrage avec SQUID.
• Utiliser IPTABLES pour rendre un proxy transparent et améliorer le filtrage.
• Configurer la translation d’adresses source et destination avec IPTABLES.
• Comprendre la hiérarchie de caches et la liaison inter-cache avec SQUID.

Prérequis et installation

• Quatre machines virtuelles en réseau sur un même ordinateur (via VMware) : Fedora (Squid1), OpenSuse (Squid2), Ubuntu (client 192.168.1.2), et un serveur Windows (193.95.0.1).
• Paquets SQUID et IPTABLES installés sur Squid1 et Squid2.
• Serveur Web IIS installé sur le serveur Windows.
• Paquet htpasswd pour la gestion des mots de passe.
• Navigateurs Web installés sur toutes les machines.
• Serveur Telnet installé sur Fedora.
• Connaissances de base en administration Linux, réseau IP, et utilisation de la ligne de commande.

Consultation et vérification des fichiers de configuration SQUID

Commencez par consulter le fichier /etc/squid/squid.conf sur Squid1. Recherchez la directive cache_dir pour déterminer :

• Le chemin vers le répertoire de cache.
• La taille totale du cache (en Mo), somme des occurrences.
• Le nombre de répertoires et sous-répertoires utilisés pour le cache.

Cette organisation en répertoires et sous-répertoires permet à SQUID de répartir uniformément les objets dans le cache, accélérant ainsi leur recherche grâce à une fonction de hachage.

Vérifiez que les répertoires de cache existent avec la commande ls. Si nécessaire, supprimez et recréez le cache avec :

rm -rf /var/spool/squid/*
squid -z

Enfin, vérifiez si SQUID est déjà lancé :

ps aux | grep [s]quid
# ou
/etc/init.d/squid status

Notez les informations suivantes :

• Chemin vers le répertoire de Swap : …
• Taille du répertoire de Swap : …
• Noms des répertoires : …
• Noms des sous-répertoires : …

Configuration simple d’un serveur proxy SQUID

Dans le fichier squid.conf de Squid1, configurez le proxy pour permettre à toutes les machines du réseau 192.168.0.0 d’accéder à Internet via Squid1 (IP 192.168.0.2). Reproduisez les définitions suivantes :

##############################
# SERVEUR PROXY CACHE – Squid1
##############################

# Port du proxy
http_port 192.168.0.2:8080

# Paramétrage du cache
cache_dir ufs /var/spool/squid 100 16 256
cache_log /var/log/squid/cache.log

# Taille mémoire vive utilisée pour cache
cache_mem 16 MB

# Taille maximale des objets stockés dans le cache
maximum_object_size 4 MB

# Taille minimale des objets stockés dans le cache
minimum_object_size 0 KB

# Messages d'erreurs du proxy en français
error_directory /usr/share/squid/errors/fr

# Nom visible dans les messages d'erreurs
visible_hostname Squid1

# Déclaration des ACL
acl localhost src 127.0.0.1/32
acl reseau1 src 192.168.0.0/24
acl all src all

# Protocoles d'accès au cache et ports
acl manager proto cache_object
acl Safe_ports port 80
acl Safe_ports port 21
acl Safe_ports port 443 563
acl Safe_ports port 70
acl Safe_ports port 210
acl Safe_ports port 1025-65535

# Autorisation d'accès
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access allow localhost
http_access allow reseau1
http_access deny all

Redémarrez SQUID :

/etc/init.d/squid restart

Sur Squid2 (OpenSuse), configurez le navigateur pour utiliser Squid1 comme proxy (IP 192.168.0.2, port 8080). Tentez d’accéder à l’URL http://193.95.0.1/. Si l’accès échoue, vérifiez la configuration réseau et les règles d’accès dans squid.conf.

Utilisez Wireshark sur Fedora pour observer les échanges entre le client, Squid1, et le serveur Web. Notez les messages échangés :

• Entre la machine cliente et Squid1 : requêtes HTTP via le proxy.
• Entre Squid1 et le serveur Web : requêtes HTTP directes.

Arrêtez la capture après observation.

Configuration de l’authentification avec SQUID

Nous allons utiliser ncsa_auth pour authentifier les utilisateurs du proxy.

Créez un fichier de mots de passe :

touch /etc/squid/passwd

Ajoutez un utilisateur :

htpasswd -b /etc/squid/passwd <nom_utilisateur> <mot_de_passe>

Modifiez squid.conf en remplaçant :

http_access allow reseau1

par :

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
acl pass proxy_auth REQUIRED
http_access allow pass reseau1

Redémarrez SQUID et testez l’authentification via le navigateur. Seuls les utilisateurs authentifiés pourront accéder au proxy.

Filtrage avancé avec SQUID (question bonus)

Pour limiter le nombre de connexions simultanées par utilisateur, ajoutez dans squid.conf :

# Limite du nombre maximal de sessions simultanées par utilisateur
acl maxauth max_user_ip -s 1

# Limite du nombre de connexions simultanées à 5
acl numconn maxconn 5

# Durée de validité de l'authentification
authenticate_ttl 30 minute

# Règles d'accès
http_access deny maxauth
http_access deny reseau1 numconn
http_access allow pass reseau1

Testez ces règles en ouvrant plusieurs connexions simultanées. Vous pouvez aussi configurer des restrictions horaires :

# Restriction journalière/horaire
acl semaine time MTWHF 08:30-17h30

# Restriction par mots interdits dans l'URL
acl mots_interdits urlpath_regex "/etc/squid/mots_interdits"

# Restriction par URLs interdites
acl urls_interdites url_regex "/etc/squid/url_interdites"

# Application des restrictions
http_access deny !semaine
http_access deny mots_interdits
http_access deny urls_interdites

Testez ces règles et proposez une alternative utilisant allow au lieu de deny pour la restriction horaire avec authentification et uniquement pour le réseau 192.168.0.0/24.

Mise en place d’un proxy transparent

Le proxy transparent permet d’intercepter les requêtes HTTP sans configurer les navigateurs. L’authentification n’est plus possible et seul le protocole HTTP (port 80) est supporté.

Sur Squid1 (passerelle par défaut), activez le routage :

echo "1" > /proc/sys/net/ipv4/ip_forward

Redirigez le port 80 vers le port 8080 de SQUID :

iptables -t nat -I PREROUTING -p TCP --dport 80 -j REDIRECT --to-port 8080

Modifiez la directive http_port dans squid.conf :

http_port 192.168.0.2:8080 transparent

Redémarrez SQUID. Videz le cache du navigateur sur les clients. Testez l’accès à Internet sans configurer le proxy dans le navigateur. Décrivez les étapes restantes pour valider le fonctionnement du proxy transparent.

Hiérarchie de caches et liaison inter-cache

Pour améliorer les performances, plusieurs caches SQUID peuvent coopérer selon une hiérarchie :

• Relation parent-fils : le cache parent répond aux requêtes si possible, sinon il les cherche et les transmet au fils.
• Relation frère (sibling) : les caches frères ne relayent pas les requêtes, chaque cache cherche lui-même les objets.

Configurez Squid1 comme cache père et Squid2 comme cache fils :

• Dans squid.conf de Squid2, ajoutez :

cache_peer 192.168.0.2 parent 8080 3130

• Dans squid.conf de Squid1, activez le port ICP :

icp_port 3130

Videz les caches avec squid -z sur les deux machines. Depuis Ubuntu, accédez à http://193.95.0.1/lien1. Consultez les fichiers access.log sur Squid2 et Squid1 et notez les événements correspondants.

Depuis OpenSuse, accédez à la même URL et consultez le access.log de Squid1.

Configurez ensuite Squid2 comme cache frère :

cache_peer 192.168.0.2 sibling 8080 3130

Depuis Ubuntu, accédez à http://193.95.0.1/lien2. Décrivez et illustrez les résultats obtenus pour les accès aux URLs /lien1 et /lien2.

Introduction à IPTABLES

IPTABLES est un firewall logiciel qui permet la translation d’adresses (NAT), le filtrage et la modification des entêtes TCP/IP. Contrairement à SQUID, IPTABLES agit au niveau réseau et transport, indépendamment des protocoles applicatifs, et ne propose pas de cache.

Les points d’accès (hooks) dans le traitement des paquets sont :

• PREROUTING : avant routage
• FORWARD : durant le routage
• POSTROUTING : après routage
• INPUT : paquets destinés à la machine locale
• OUTPUT : paquets issus de la machine locale

Les règles sont organisées en chaînes et tables (FILTER, NAT, MANGLE). Chaque règle a une cible : ACCEPT, DROP, REJECT, MASQUERADE, SNAT, DNAT, LOG, etc.

Gestion des règles IPTABLES

Quelques commandes utiles :

iptables -L           # liste les règles actuelles
iptables -F           # vide toutes les règles
iptables-save > /etc/iptables-save   # sauvegarde les règles
iptables-restore < /etc/iptables-save # restaure les règles
iptables -P INPUT ACCEPT    # définit la politique par défaut (ici permissive)
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Pour une politique restrictive, remplacez ACCEPT par DROP.

Filtrage simple avec IPTABLES

Sur OpenSuse, activez le routage :

echo "1" > /proc/sys/net/ipv4/ip_forward

Interdisez que des machines du réseau 192.168.1.0 puissent envoyer des requêtes ping (ICMP echo-request) vers le réseau 192.168.0.0 :

iptables -A FORWARD -p icmp --icmp-type echo-request -s 192.168.1.0/24 -d 192.168.0.0/24 -j REJECT

Vérifiez que le ping fonctionnait avant la règle et qu’il est bloqué après. Testez si Fedora peut pinger 192.168.1.2 et expliquez.

Translation d’adresse source avec IPTABLES

SQUID ne traduit pas les adresses source pour le trafic ICMP ou POP/SMTP. Sur OpenSuse, ajoutez une route par défaut via 192.168.0.2.

Sur Squid1, ajoutez la règle :

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -p icmp --icmp-type echo-request -j SNAT --to-source 193.95.0.2

Cette règle modifie l’adresse source des paquets ICMP émis par le réseau local pour qu’elle corresponde à l’adresse publique 193.95.0.2, permettant ainsi la communication avec l’extérieur.

Vérifiez les règles NAT :

iptables -L POSTROUTING -t nat

Testez que le ping depuis OpenSuse vers 193.95.0.1 fonctionne.

Translation d’adresse destination avec IPTABLES

Pour permettre l’accès à une machine privée depuis Internet, utilisez la translation d’adresse destination (DNAT). Sur Fedora, activez le routage. Sur OpenSuse, ajoutez une route par défaut via 192.168.0.2.

Sur Fedora, ajoutez la règle :

iptables -t nat -A PREROUTING -s 0.0.0.0/0 --protocol tcp --dport 2222 -j DNAT --to 192.168.0.1:80

Cette règle redirige les connexions TCP entrantes sur le port 2222 vers la machine interne 192.168.0.1 sur le port 80 (serveur Web).

Depuis Windows, accédez à l’URL http://193.95.0.2:2222 et vérifiez l’accès au serveur Web interne.

Inspection d’état (stateful inspection) avec IPTABLES (question bonus)

Pour autoriser les utilisateurs du réseau 192.168.1.0 à faire du telnet vers 192.168.0.0, mais pas l’inverse, vérifiez que Telnet est activé sur Fedora, que le routage est activé sur OpenSuse, et que les routes sont configurées.

Videz toutes les règles IPTABLES sur OpenSuse, Fedora et Ubuntu.

Sur OpenSuse, saisissez :

iptables -P FORWARD DROP
iptables -A FORWARD -p TCP -s 192.168.1.0/24 -d 192.168.0.0/24 --dport 23 -j ACCEPT
iptables -A FORWARD -p TCP -s 192.168.0.0/24 --sport 23 -d 192.168.1.0/24 -j ACCEPT

Testez si un ping de 192.168.1.2 vers 192.168.0.2 est possible et si un telnet de 192.168.1.2 vers 192.168.0.2 fonctionne. Expliquez les problèmes rencontrés.

IPTABLES permet le suivi des états des connexions :

• NEW : premier paquet d’une connexion
• ESTABLISHED : paquets liés à une connexion existante
• RELATED : paquet initiant une nouvelle connexion liée à une existante (ex : FTP)
• INVALID : paquet non associé à une connexion connue

Remplacez la dernière règle par :

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Cette règle autorise les paquets appartenant à des connexions déjà établies ou liées, améliorant ainsi la gestion des communications bidirectionnelles.

Résultats attendus

• Le proxy SQUID doit permettre l’accès Internet aux machines du réseau local via Squid1.
• Le cache SQUID doit être correctement configuré et visible dans les répertoires spécifiés.
• L’authentification doit restreindre l’accès aux utilisateurs autorisés.
• Le proxy transparent doit fonctionner sans configuration spécifique dans les navigateurs.
• La hiérarchie de caches doit permettre le partage efficace des documents entre Squid1 et Squid2.
• Les règles IPTABLES doivent filtrer correctement les paquets ICMP et TCP selon les règles définies.
• La translation d’adresses source et destination doit permettre l’accès aux ressources internes depuis l’extérieur.
• La gestion d’état IPTABLES doit permettre un contrôle fin des connexions telnet entre réseaux.

Pièges courants

• Ne pas créer ou reconstruire les répertoires de cache avant de démarrer SQUID empêche le service de démarrer.
• Oublier d’autoriser les ports nécessaires dans les ACL SQUID bloque l’accès.
• Ne pas redémarrer SQUID après modification de squid.conf empêche la prise en compte des changements.
• Ne pas vider le cache du navigateur lors des tests fausse les résultats.
• Configurer un proxy transparent sans ajouter le paramètre transparent dans http_port empêche le bon fonctionnement.
• Oublier d’activer le routage IP sur les machines jouant le rôle de passerelle bloque le trafic.
• Ne pas vérifier les politiques par défaut IPTABLES peut laisser passer ou bloquer trop de trafic.
• Confondre les règles SNAT et DNAT dans IPTABLES peut entraîner des erreurs d’acheminement.
• Ne pas utiliser la gestion d’état dans IPTABLES empêche les communications bidirectionnelles correctes.