TP – Partage d’une connexion en utilisant SQUID & IPTABLES

Objectifs :
SQUID est un proxy (mandataire) capable de réaliser :
- la translation d’adresses permettant l’utilisation d’une seule adresse routable,
- l'optimisation de la bande passante en utilisant un mécanisme de cache (notamment utile lorsque les utilisateurs
accèdent aux mêmes objets statiques),
- le contrôle et le filtrage de l'accès, particulièrement, l’authentification qui n’est pas possible avec IPTABLES.
IPTABLES est un firewall logiciel capable de réaliser les fonctions de translation d’adresses et de filtrage, mais aussi,
il permet la modification de champs dans les entêtes TCP/IP. Grâce à IPTABLES, il est possible de réaliser la
translation d’adresses indépendamment des protocoles applicatifs (contrairement à SQUID qui se limite à des
protocoles bien déterminés comme HTTP ou FTP). Grâce Il est aussi possible de réaliser la translation d’adresse sur
l’adresse source mais aussi sur l’adresse destination (ce qui n’est pas le cas avec SQUID). IPTABLES et SQUID
peuvent être utilisés conjointement pour mettre en place un serveur proxy transparent.
Sans chercher à couvrir toutes les possibilités qu’offrent ces deux outils, à travers un certain nombre de manipulations,
nous allons nous familiariser avec ces deux outils et apprendre à utiliser et mettre en place certaines configurations
usuelles :
- mise en place d’un serveur proxy SQUID pour le partage d’une connexion à l’Internet,
- configuration du cache SQUID,
- authentification et filtrage avec SQUID,
- consultation des fichiers logs et
- utilisation d’IPTABLES pour rendre un proxy transparent, pour améliorer les possibilités de filtrage et pour
permettre l’accès à partir de l’internet à un serveur ayant une adresse privée.
Barème : 2.5 par question.
Environnement matériel et logiciels
Quatre machines dont trois virtuelles, en réseau, sont installées sur un même ordinateur de travail (en utilisant
VMware) : trois machines Linux et une MS Windows Server. Ces machines sont les mêmes utilisées que pour le TP
déploiement des réseaux IP avec les mêmes mots de passe. Il faut savoir que dans le cadre d’une exploitation réelle, la
configuration matérielle de la machine (en termes notamment d’espace mémoire et d’espace disque), sur laquelle est
déployé un serveur proxy SQUID influe considérablement sur les temps de réponses de ce serveur.
Configurer les différentes machines comme le décrit la figure suivante (appliquer le masque par défaut) :

- Squid1 devrait être la machine Fedora, Squid2 la machine OpenSuse et le client [Link] la machine Ubuntu,
- Paquetages SQUID et IPTABLES installés à la fois sur Squid1 et Squid2
- Serveur Web (IIS) installés à la fois sur [Link] (Windows Server),
- Le paquetage htpasswd pour la gestion des mots de passe,
- Navigateur Web installé sur toutes les machines,
- Serveur Telnet installé sur Fedora.
Nous allons commencer par se familiariser avec certains fichiers et effectuer certaines vérifications.

TP RL/ II2-ENSI Page :1

1) Consulter le fichier /etc/squid/[Link]
Chercher dans ce fichier la directive cache_dir afin de déterminer l’emplacement du répertoire de cache, la taille du
cache (en Mo), le nombre de répertoires et de sous répertoires. Il est possible de trouver cette directive plusieurs
fois, la taille totale est alors la somme des différentes occurrences.
Afin d'accélérer les temps de recherche, SQUID essaie de répartir les objets qu'il place dans le cache de manière
uniforme dans plusieurs répertoires. Il utilise une fonction de répartition (fonction de « hash ») qui indique dans
quel répertoire se trouve un objet. La recherche dans ce répertoire se fait donc plus rapidement, car les objets sont
répartis de manière équilibrée dans tous les répertoires du cache, qui devraient donc être relativement peu
« peuplés ». Il utilise un découpage à deux niveaux, les répertoires du deuxième niveau étant répartis dans les
répertoires du premier niveau.
SQUID est incapable de démarrer si les répertoires de caches ne sont pas créés. Grâce à la commande ls vérifier
que ces répertoires sont bien créés. Il est possible aussi de les créer ou de les reconstruire (par exemple, à la suite
d’un arrêt brutal de squid, le cache peut devenir « corrompu » et doit être reconstruit) en tapant :
rm -rf /var/spool/squid/* // si déjà créés
squid -z
En ayant consulté [Link], préciser 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 :……………………...................................................................................................................
…………………………………………………………………………...................................................................................................................
Déterminer si SQUID est déjà lancé en utilisant l’une des commandes suivantes :
Fedora# ps aux | grep [s]quid
ou
Fedora# /etc/init.d/squid status

Une première configuration simple

2) Nous allons permettre à toutes les machines du réseau [Link] d’accéder à l’internet (représenté par le serveur
Web [Link]) via Squid1. A cet effet et dans le fichier [Link], reproduire les définitions suivantes :

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

# Port du proxy
http_port [Link]:8080

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

# Taille mémoire vive utilisée pour cache, augmenter si trop de messages Warning
#“Exceeded cache_mem…”
cache_mem 16 MB

# régler cache_mem_low et cache_mem_high qui sont les valeurs limites de remplissage du

# cache mémoire. Par défaut les valeurs sont 75 % et 90 %. A 90 % le cache se vide
# jusqu'à 75 %.

# Taille maximale des objets stockés dans le cache

maximum_object_size 4 MB

TP RL/ II2-ENSI Page :2

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

# # Messages d'erreurs du proxy en français (pas forcement nécessaire), vérifier que le

# répertoire existe et le consulter.
error_directory /usr/share/squid/errors/fr

# # Nom visible dans les messages d'erreurs

visible_hostname Squid1

# Déclaration des ACL (Access Control List)

acl localhost src [Link]/32
acl reseau1 src [Link]/24
acl all src all #Internet

# # Protocoles d'accès au cache et ports (ne pas définir les ports à interdire
# # et à autoriser présenterait une faille de sécurité)
acl manager proto cache_object
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
…

# # Autorisation d'accès

# Accès au manager à partir de localhost seulement

http_access allow manager localhost
http_access deny manager

# Interdiction des ports douteux

http_access deny !Safe_ports

# # Autorisation d'accès direct aux services du proxy

http_access allow localhost
http_access allow reseau1
http_access deny all
- Des règles multiples de http_access sont comparées par des OU, elles sont traitées dans l’ordre d’écriture et se
terminent dès qu’une correspondance est établie.
- Tous les éléments d’une même entrée d’accès sont associés par un ET.
Lancer Wireshark sur Fedora.
Démarrer/redémarrer SQUID :
/etc/init.d/squid restart
A partir de OpenSuse (Squid2 considéré en tant que client) et travers le navigateur tenter d’accéder à l’URL :
[Link] Que faut-il réaliser comme paramétrage pour que l’accès puisse se réaliser ?
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
Remarque importante : dans tous le TP ne pas accéder à des pages HTML (inutilement) tant que ceci n’a pas été
demandé. Cette recommandation est importante pour garder la mémoire cache à un état bien déterminé et
pouvoir ainsi obtenir les résultats escomptés.
Après avoir réalisé un premier accès à travers le navigateur (à partir de OpenSuse), décrire les messages échangés entre
la machine cliente et le serveur Squid1 d’une part et entre le serveur Squid1 et le serveur Web d’autre part. A cet effet
TP RL/ II2-ENSI Page :3
compléter la figure ci-dessus. Il n’est pas demandé de représenter les messages de fermeture de connexions TCP.
Arrêter la capture de trame.

Authentification
Dans cette question nous nous intéressons à la fonction d’authentification. Il existe plusieurs méthodes disponibles
pour authentifier les utilisateurs d’un proxy SQUID. Elles font appel à l’un des programmes suivants :
- ldap_auth : se base sur le protocole Linux Lightweight Directory Access
- ncsa_auth : utilise un fichier de noms d'utilisateur et de mots de passe de style NCSA
- smb_auth : utilise un serveur SMB comme SAMBA ou Windows NT
- msnt_auth : utilise l'authentification de domaine Windows NT
- PAM : utilise les modules Linux "Pluggable Authentication Modules"
- getpwam : utilise le fichier passwd de Linux.
3) Dans ce qui suit nous allons utiliser ncsa_auth.
Créer un fichier password
touch /etc/squid/passwd
Ajouter un utilisateur grâce à htpasswd:
htpasswd -b /etc/squid/passwd <nom> <mot de passe>
Dans le fichier [Link], au lieu de
http_access allow reseau1

Utiliser les directives suivantes :

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
acl pass proxy_auth REQUIRED
http_access allow pass reseau1
TP RL/ II2-ENSI Page :4
Valider le bon fonctionnement de cette règle.

Autres règles de filtrage (question bonus)

Afin de limiter le nombre de connexions différentes qu'un utilisateur peut effectue, rajouter dans /etc/squid/[Link]

# Nombre maximal de sessions simultanées à partir de différentes adresses IP à 1 (pour

# un même utilisateur)« -s » pour un fonctionnement strict (sinon aléatoire)
acl maxauth max_user_ip -s 1

# Nombre de connexion simultanés limité à 5

acl numconn maxconn 5
# duree de validite 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
Valider le bon fonctionnement de ce paramétrage. Décrire les tests effectués.
Autres restrictions typiques :
# ACL pour une restriction journalière/horaire :
# M:Monday T:Tuesday W:Wednesday H:Thursday F:Friday A:Saturday S:Sunday
acl semaine time MTWHF 08:30-17h30

# ACL de restrictions par mot passant dans l'url (utilisation d'un fichier contant les
# mots interdits))
acl mots_interdits urlpath_regex "/etc/squid/mots_interdits"

# ACL de restrictions par url (utilisation d'un fichier contenant les URLs interdites)
acl urls_interdites url_regex "/etc/squid/url_interdites"

# # Application, par le refus, de ces ACLs

http_access deny !semaine
http_access deny mot_interdit
http_access deny urls_interdites
Tester le bon fonctionnement de ces règles et donner une autre alternative à la règle qui permet la restriction
journalière/horaire avec authentification et uniquement à partir du réseau1 en utilisant « allow » et non « deny ». Tester
le bon fonctionnement de cette règle.

Proxy transparent
Dans cette question nous cherchons à mettre en place un proxy transparent. Suivant ce mode de fonctionnement,
l’authentification n’est plus possible. Seul HTTP (port 80) est supporté en mode transparent. Grâce à un tel mode, il
n’est plus nécessaire de paramétrer les navigateurs avec l’adresse IP/port du proxy.
4) Le proxy est supposé être installé sur la machine qui joue le rôle de la passerelle par défaut. Sur Squid1 :
- activer le routage :
echo "1" > /proc/sys/net/ipv4/ip_forward
- Grâce à IPTABLES, rediriger le port 80 vers le port de SQUID (8080)
iptables -t nat -I PREROUTING -p TCP --dport 80 -j REDIRECT --to-port 8080
- Reste à résoudre le problème suivant : le client envoie une requête HTTP directe à un serveur httpd et non à un
proxy. Les méthodes utilisées ne sont pas les mêmes. Afin que le proxy fonctionne de façon transparente, il faut
rajouter au niveau de la directive http_port le terme « transparent »:
##Port du proxy
http_port [Link]:8080 transparent
Décrire le reste des opérations à réaliser pour le test du fonctionnement du proxy transparent et réaliser ce test.
(Pour les tests n’oublier pas de vider le cache du navigateur)

TP RL/ II2-ENSI Page :5

……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………..………………………………………………………………………………………………………………………………….…...................................
Hiérarchie de caches et liaison inter-cache
La fonction cache permet d’éviter de ramener un document plusieurs fois.
Un document est généralement stocké dans le cache en fonction (particulièrement) de :
- une date d'expiration (en-tête HTTP expire),
- une durée de vie estimée à partir des dates de dernière modification (en-tête HTTP Last-Modified),
-la fréquence d'utilisation du document (LFU : « Least Frequently Used »),
- un rapport entre un paramètre coût (le temps de réponse du serveur d’origine) et la taille du document, les
documents ayant le plus petit rapport sont supprimés d’abord (GDS : « Greedy Dual Size »).
Les documents dynamiques ne doivent jamais être cachés (CGI, PHP,..). Lorsqu’un document est supprimé
tous les documents aussi récents ou moins récents sont supprimés.
Afin d’augmenter les performances des proxy-caches, une coopération entre caches peut-être configurée. Les
caches SQUID peuvent être organisés suivant une hiérarchie de caches. Exemple :

On distingue particulièrement 2 types de relations de parenté :

- les relations hiérarchiques « parent » où un parent (considéré comme père) répond à son fils s'il possède le
document, sinon, il cherche le document et le délivre au fils; les mises à jour s'effectuent en cascade : un
père est un point de concentration.
- les relations transversales « sibling », dans ce cas, si le document n’est pas dans le cache du parent
(considéré comme frère) la requête n’est pas relayée, le cache origine de la requête doit lui-même chercher
l’objet. Cette relation est particulièrement intéressante dans le cas où les frères sont proches.
Le taux de succès des accès au cache risquent d’être très aléatoires. Ces relations de parenté devraient être
instaurées entre caches en cas d'homogénéité de communauté (réseau de caches thématiques). Les endroits
dans le réseau (où devraient figurer les caches) et le dimensionnement des caches sont des éléments de
configuration qui font partie des problèmes à traiter dans la mise en œuvre d’une hiérarchie de caches.
5) Nous allons commencer par configurer Squid1 entant que cache père et Squid2 en tant que cache fils. Pour
simplifier la manipulation, préparer les fichiers [Link] (de Squid1 et Squid2) de façon à réduire les contrôles
d’accès (pas d’authentification …).
Remarque : la version de Squid sur Squid2 est différente de celle de Squid1, les mêmes directives déjà étudiées
existent, les paramètres par défaut sont différents. Sans devoir réécrire le fichier [Link] sur Squid2 modifier le
fichier existant en agissant sur les directives appropriées.
Dans le fichier [Link] de Squid2, taper la directive suivante (le port utilisé par le protocole inter-cache ICP,
directive icp_port, est supposé être configuré à 3130) :

TP RL/ II2-ENSI Page :6

 cache_peer [Link] parent 8080 3130

Sur Squid1 et dans le fichier [Link] activer le port 3130

icp_port 3130
Vider le cache de Squid1 et Squid2 (grâce à la commande de reconstruction, cf. plus haut). Effectuer une requête
d’accès depuis Ubuntu à l’URL [Link] Consulter le fichier [Link] de Squid2 et de Squid1.
Reproduire les lignes traduisant les différents événements conséquents à l’accès à la page.
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................

A partir d’un navigateur sur OpenSuse accéder à l’URL [Link] Consulter le fichier [Link] de
Squid1. Reproduire les lignes traduisant les différents événements conséquents à l’accès à la page.

……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................

Nous allons maintenant configurer Squid2 entant que cache frère de Squid1. Garder le cache de Squid1 non vide.
Ensuite, dans le fichier [Link] de Squid2, taper la directive suivante :

cache_peer [Link] sibling 8080 3130

A partir d’un navigateur sur Ubuntu accéder à l’URL [Link] et ensuite à l’URL
[Link] Décrire le résultat obtenu pour chacun de ces accès. Illustrer ces résultats.
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
IPTABLES : généralités
Alors que SQUID est capable de réaliser la translation d’adresse et le contrôle d’accès au niveau applicatif, IPTABLES
réalise ces fonctions aux niveaux réseaux et transport. Il est incapable d’exploiter pas les particularités des protocoles
applicatifs. De plus, il ne met pas en œuvre un mécanisme de cache. Néanmoins, grâce à IPTABLES il est possible de
réaliser la translation d’adresses sans être limité à des protocoles applicatifs bien déterminés (comme c’est le cas pour
SQUID). En outre, en plus de la translation d’adresse qui s’effectue généralement du coté client, un autre type de
translation d’adresse du coté serveur est aussi possible (sur lequel nous reviendrons dans la suite du TP).

TP RL/ II2-ENSI Page :7

Avant d’aborder les manipulations, il est nécessaire de connaître les notions de base régissant le fonctionnement de
IPTABLES. La couche réseau Linux présente plusieurs points d'accès (en anglais hook). Netfilter (module système
destiné au filtrage) dispose de fonctions de rappel (callback) sous la forme de suites d'instructions qui précisent les
traitements à réaliser lorsqu’un événement survient. IPTABLES permet la configuration de Netfilter. La figure suivante
précise les points d’accès existants.

Il est ainsi possible d’agir avant (PREROUTING), durant (FORWARD) ou après le routage (POSTROUTING), il est
aussi possible d’agir sur les paquets issus des processus locaux (OUTPUT) ou sur les paquets destinés à ces processus
(INPUT). A ces points d’accès sont associées des chaines de traitements désignées par les termes précisés ci-avant. Ces
chaines sont regroupées en 3 tables : FILITER pour le filtrage, NAT pour la translation d’adresses et MANGLES pour
pouvoir modifier certains des entêtes TCP/IP.

Une chaîne est une liste de règles. Si les conditions de la règle s’appliquent sur un paquet, la règle précise la cible
(ACCEPT, DROP, REJECT, SNAT, DNAT, MASQUERADE, LOG un saut vers une chaîne utilisateur), sinon, la
règle suivante de la chaîne est examinée. Le tableau suivant donne une description des différentes cibles prédéfinies.

CIBLE DESCRIPTION

ACCEPT un paquet envoyé vers cette cible sera accepté et pourra poursuivre
son cheminement au travers des couches réseaux.

DROP Cette cible permet de jeter des paquets

REJECT Permet d'envoyer une réponse à l'émetteur pour lui signaler que son
paquet a été refusé

MASQUERADE Cible valable uniquement dans la chaîne POSTROUTING de la table

NAT. Elle change l'adresse IP de l'émetteur par celle courante de la
machine pour l'interface spécifiée. Cela permet de masquer des
machines et de faire par exemple du partage de connexion

SNAT Également valable pour la chaîne POSTROUTING de la table NAT

seulement. Elle modifie aussi la valeur de l'adresse IP de l'émetteur en
la remplaçant par la valeur fixe spécifiée.
DNAT Valable uniquement pour les chaînes PREROUTING et OUTPUT de
la table NAT. Elle modifie la valeur de l'adresse IP du destinataire en
la remplaçant par la valeur fixe spécifiée

LOG Demande au noyau d'enregistrer des informations sur le paquet

courant.

Arrêter Squid Sur OPenSuse et Fedora.

TP RL/ II2-ENSI Page :8
6) Nous allons commencer par présenter quelques commandes utiles pour visualiser les règles, les supprimer, les
sauvegarder, les restaurer et fixer la politique par défaut :
- Pour lister les règles courantes des chaines de la table FILTER, taper
iptables –L
- Pour vider les chaines, taper
Iptables –F
- Pour sauvegarder les règles courantes, taper :
iptables-save > /etc/iptables-save
- Pour restaurer les règles à partir du fichier /etc/iptables-save, taper :
iptables-restore < /etc/iptables-save
Vider les chaines, lister à nouveau les règles et vérifier que la politique par défaut pour les différentes chaines est
ACCEPT (Policy ACCEPT) : politique permissive. Il est possible d’agir sur la politique par défaut (qui sera
appliquée en dernier ressort si aucune règle ne s’applique) :
iptables -P INPUT –j ACCEPT
iptables -P OUTPUT –j ACCEPT
iptables -P FORWARD –j ACCEPT
Pour instaurer une politique restrictive il suffit de remplacer dans les lignes (ci-dessus) ACCEPT par DROP.
IPTABLES : exemple de filtrage
7) Activer le routage sur OpenSuse et mettre-à-jour les tables de routages pour que tout équipement puisse pinger sur
tout autre équipement :
echo "1" > /proc/sys/net/ipv4/ip_forward
Nous voulons interdire qu’un équipement dans le réseau [Link] puisse « pinguer » sur un équipement se
trouvant dans le réseau [Link]. A cet effet et sur OpenSuse, saisir la règle suivante :
iptables –A FORWARD –p icmp --icmp-type echo-request –s [Link]/24 –d [Link]/24 -j REJECT

Vérifier qu’avant la saisie de la règle, le ping pouvait se faire et qu’après la saisie ceci n’est plus possible.
Est-ce qu’il est possible de pinger à partir de Fedora sur l’adresse [Link] ? Expliquer.
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
IPTABLES : Translation de l’adresse source
SQUID n’effectue pas la translation des adresses sources pour permettre aux stations locales de « pinguer » sur
l’extérieur (trafic ICMP). Ce même problème se pose pour d’autres trafics tels que POP ou SMTP. Dans ce qui suit,
nous allons utiliser IPTABLES pour permettre aux stations dans les réseaux [Link] de « pinguer » sur des
machines externes ([Link]).
Rajouter sur OpenSuse une route par défaut à travers [Link].
8) Sur le serveur Squid1 saisir la règle suivante :
iptables –t nat –A POSTROUTING –s [Link]/24 –p icmp --icmp-type echo-request -j SNAT -–to-source
[Link]
Expliquer à quoi correspond cette règle.
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
Visualiser les règles des chaines de la table NAT en tapant :
iptables –L POSTROUTING –t nat
Vérifier qu’il est possible de pinger à partir d’OpenSuse sur [Link].

TP RL/ II2-ENSI Page :9

 IPTABLES : translation de l’adresse destination
Il est possible de permettre l’accès à une machine ayant une adresse privée à partir de l’extérieur (l’internet) en utilisant
la translation le l’adresse destination (utile, par exemple, pour une caméra, munie d’un serveur Web, à domicile à
laquelle on veut accéder à partir d’un quelconque endroit sur l’Internet). A cet effet nous allons réserver le port 2222
pour désigner la machine interne (la caméra avec son serveur Web) ayant comme adresse IP [Link] (OpenSuse).
Vérifier que le serveur Web est bien activé sur OpenSuse.
9) Sur le serveur Fedora activer le routage. Sur OpenSuse, créer une route par défaut à travers [Link]. Sur
Fedora, saisir la règle suivante :
iptables –t nat –A PREROUTING –s [Link]/0 –-protocol tcp -–dport 2222 -j DNAT –-to
[Link]:80

Expliquer à quoi correspond cette règle. A partir d’un navigateur sur Windows, accéder à l’URL [Link] :2222 .
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
IPTABLES : « statefull Inspection » (question bonus)
Dans ce qui suit nous cherchons à permettre aux utilisateurs du réseau [Link] de pouvoir effectuer un telnet sur
les machines qui se trouvent dans le réseau [Link] sans que ces derniers ne puissent faire un telnet sur les
machines du réseau [Link]. Vérifier que le telnet est bien activé sinon l’activer sur Fedora. Vérifier que le routage
est bien activé sur OpenSuse. Créer les routes nécessaires pour permettre aux machines des réseaux [Link] et
[Link] d’échanger des paquets. Vider toutes les règles iptables sur OpenSuse mais aussi Fedora et Ubuntu).
10) Sur OpenSuse, saisir les règles suivantes :
Iptables –P FORWARD DROP
iptables -A FORWARD -p TCP -s [Link]/24 -d [Link]/24 --dport 23 -j ACCEPT
iptables -A FORWARD -p TCP -s [Link]/24 --sport 23 -d [Link]/24 -j ACCEPT
Est-ce qu’il est possible d’effectuer à partir de [Link] un ping sur [Link] (Fedora). Est-ce qu’il est
possible d’effectuer à partir de [Link] un telnet sur [Link] (Fedora). Quel est le problème qui se pose ?
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
IPTABLES permet le suivi des «communications» en se basant sur les états suivants:
– NEW : premier paquet,
– ESTABLISHED : réponse et suivants relatifs à une même communication,
– RELATED : signifie que le paquet initie une nouvelle connexion, mais qu'il est associé avec une
communication existante, comme un transfert de données FTP ou une erreur ICMP.
– INVALID : signifie que le paquet n'est associé à aucune connexion connue
Remplacer la dernière règle par (vider et re saisir)
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Quel est l’intérêt de cette règle ?
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................
……………………………………………………………………………………………....………………………………………………………...................................

TP RL/ II2-ENSI Page :10