Protocoles avancés

1  Introduction

1.1  Tableau général

• Evolution de l’administration système et réseau
  
• Époque classique :
  • architecture et configuration réseau ;
  • installation systèmes d’exploitation ;
  • configuration système (services) ;
  • outils : minicom, ssh, (i)PXE, ansible, vi, etc.
• Époque moderne :
  • architecture et configuration réseau ;
  • création machines virtuelles et conteneurs ;
  • configuration système (services) ;
  • outils : kvm, xen, proxmox, docker, kubernetes et les précédents.
• Époque post-moderne :
  • définition logicielle de réseaux ;
  • automatisation d’infrastructure ;
  • configuration système (services) ;
  • outils : openstack (aws, azure, etc), terraform, open vswitch et les précédents.

2  Virtualisation de systèmes d’exploitation

2.1  Définition de la virtualisation

• Techniques matérielles et logicielles.
• Quelques descriptions de la virtualisation :
  • permet de faire tourner sur UNE seule machine ...
  • ... plusieurs systèmes d’exploitation ;
  • simulation logicielle d’un environnement matériel ...
  • ... pour un ou plusieurs logiciels invités/virtuels.
• Les systèmes d’exploitation (SE) sont isolés.
• Impact sur les performances des SE invités/virtuels.

2.2  Utilisations de la virtualisation

• Optimisation de ressources physiques :
  • coûts d’achat des serveurs ;
  • couts énergétiques des serveurs.
• Utilisation de logiciels propriétaires :
  • en théorie l’émulation de bibliothéque suffit (wine),
  • en théorie une machine virtuelle pour les programmes suffit (java, dotnet),
  • en pratique difficile d’émuler un SE propriétaire.
• Manipulation plus facile d’un SE :
  • accélère le développement système ;
  • facilité de déverminage (e.g. virus) ;
  • étude plus aisée (e.g. enseignement).
• Facilite la gestion des SE :
  • création de serveurs pour les clients (hébergeurs) ;
  • cohabitation de systèmes récents et anciens ;
  • migration et reconstruction facile de serveurs.

2.3  Types de virtualisation

• Emulation complète :
  • le CPU est entiérement émulé ;
  • émulation du matériel (disque, etc).
• Virtualisation matérielle/totale :
  • permet d’utiliser un SE invité/virtuel non modifié ;
  • instructions classiques :
    • code exécuté au maximum sur le CPU hôte,
    • parties critiques émulées pour l’isolation,
    • émulation du matériel (disque, etc).
  • instructions spécifiques :
    • disponibles sur CPU AMD et Intel vers 2005,
    • protection mémoire du SE virtuel gérée par le CPU,
    • entrées/sorties du SE virtuel gérées par le CPU,
    • émulation du matériel (disque, etc).
• Para-virtualisation :
  • le SE virtuel est modifié pour effectuer des hyper-appels,
  • un appel système abouti dans le noyau du SE virtuel,
  • un hyper-appel traverse le noyau et abouti à l’hyperviseur,
  • les tâches critiques sont exécutées en mode noyau par l’hyperviseur,
  • pas d’émulation du matériel mais le SE doit être modifié.

2.4  Logiciels de virtualisation

• Emulation complète : Bochs [1994] (http://bochs.sourceforge.net/).
• Virtualisation matérielle :
  • compilation au vol : Virtual PC [1997] (émule un x86 pour PowerPC) ;
  • ré-écriture de code sensible : VMWare [1999] ;
  • hardware virtual machine : Xen 3.x [2006] ;
  • utilisation des anneaux de protection x86 : VirtualBox [2007] (pour x86) ;
  • instructions spécifiques : KVM [2007] (Kernel-based Virtual Machine).
• Para-virtualisation :
  • Xen 1.0 [2003] Linux et BSD SE hôte ;
  • Xen 3.x [2007] SE virtuel linux-2.6.18-xen modifié par Xen ;
  • Xen 4.0 [2008] SE virtuel linux-2.6.24 module pvops standard ;
  • KVM 60 [2008] para-virtualisation via virtio module de Linux ;
  • VMware 6 [2008] para-virtualisation via pvops ;
  • Xen 4.1 [2011] SE hôte linux-3.x.y module pvops standard.

2.5  Etude d’un système de virtualisation totale 1/2

• Le système Kernel-based Virtual Machine (KVM).
• Compiler le module noyau (AMD ou intel).
• Créer un disque virtuel.

  qemu-img create <chemin du disque> <taille>
  

• Installer le SE virtuel (e.g. image ISO émulant un lecteur CD).

  kvm -net nic,model=ne2k_pci -net user -hda <chemin du disque> -cdrom <chemin de l'image ISO>
  

2.6  Etude d’un système de virtualisation totale 2/2

• Le système Xen en mode Hardware Virtual Machine (HVM).
• Créer un disque virtuel.
• Installer le SE virtuel (e.g. image ISO émulant un lecteur CD).
• Utilisation d’un serveur VNC.
• Definition de SE virtuel HVM (e.g. /etc/xen/scratch.cfg) :

    
  kernel      = '/usr/lib/xen-default/boot/hvmloader'
  builder     = 'hvm'
  memory      = '1024'
  disk        = [
                    'file:/usr/local/src/debian-testing-i386-netinst.iso,hdc:cdrom,r',
                    'file:/usr/local/xen/domains/simplet/simplet_disk.img,ioemu:sda,w',
                ]
  boot        = 'd'
  name        = 'scratch'
  vif         = [ 'bridge=eth1' ]
  vnc         = 1
  vnclisten   = "0.0.0.0"
  

2.7  Etude d’un système de para-virtualisation

• Le système Xen (l’éthymologie viendrait de Zen).
• Paquetages Debian nécessaires (méta-paquetage xen-linux-system) :
  • linux-image-3.2.0-4-amd64 : noyau Linux hôte et invité,
  • xen-hypervisor-4.1-amd64 : contrôle CPU et mémoire,
  • xen-utils-4.1 : utilitaires de gestion des SE virtuels,
  • xen-tools : outils pour créer facilement des SE virtuels.
• Une terminologie spécifique :
  • le Dom0 est le système d’exploitation hôte,
  • les DomU sont les systèmes d’exploitation invités/virtuels.
• Interfaces réseau à base de bridge logiciel :
  • des cartes ethernet ethX dans l’hôte,
  • des cartes ethernet ethY dans les SE virtuels,
  • cartes correspondant aux interfaces vifZ.0 de l’hôte,
  • des commutateurs virtuels bridgeB dans l’hôte,
  • certaines vifZ.0 se retrouvent dans le même bridgeB,
  • un bridgeB comporte aussi une carte ethernet de l’hôte.
• Script de configuration réseau dans /etc/xen/xend-config.sxp :

    
  ...
  (network-script 'network-bridge netdev=eth0')
  ...
  

• Definition de SE virtuel (e.g. /etc/xen/fourmies.cfg) :

    
  kernel      = '/boot/vmlinuz-2.6.32-5-xen-686'
  ramdisk     = '/boot/initrd.img-2.6.32-5-xen-686'
  memory      = '1024'
  root        = '/dev/xvda1 ro'
  disk        = [
                    'file:/usr/local1/xen/domains/fourmies/fourmies_root.img,xvda1,w',
                    'file:/usr/local1/xen/domains/fourmies/fourmies_swap.img,xvda2,w',
                    'file:/usr/local1/xen/domains/fourmies/fourmies_tmp.img,xvda5,w',
                    'file:/usr/local1/xen/domains/fourmies/fourmies_var.img,xvda6,w',
                    'file:/usr/local1/xen/domains/fourmies/fourmies_home.img,xvda7,w',
                    'file:/usr/local1/xen/domains/fourmies/fourmies_log.img,xvda8,w',
                    'phy:/dev/spool1/mail-spool,xvdb1,w',
                    'phy:/dev/spool2/mail-backup,xvdc1,w'
                ]
  name        = 'fourmies'
  dhcp        = 'dhcp'
  vif         = [ 'mac=00:16:3E:52:80:93, bridge=bridge2' ]
  on_poweroff = 'destroy'
  on_reboot   = 'restart'
  on_crash    = 'restart'
  

• Gestion des SE virtuels :

    
  xen list
  xen create fourmies.cfg
  xen console fourmies
  xen shutdown fourmies
  ...
  

3  Isolation e.g. conteneurs

3.1  Conteneurs : isolation de processus

• Utilisation du même système d’exploitation.
• Processus normaux, pratiquement aucune surchage.
• Un dispositif d’isolation des ressources ...
• ... c’est à dire processeur, mémoire et entrées/sorties.
• Multiplication des espaces de noms (structures noyau) :
  • espace table des processus ;
  • espace systèmes de fichiers ;
  • espace réseau ...
• Quid de la dépendance à la version de noyau ?
• Intérêts de l’isolation :
  • Facilité de déploiement ;
  • Structuration des applications.

3.2  Systèmes de conteneurs

• Mécanismes du noyau Linux :
  • Linux-VServer [2003] modification nécessaire ;
  • OpenVZ [2005] modification recommandée ;
  • LXC [2014] utilise le module Linux cgroups.
• Mécanismes du noyau Windows :
  • Développé sous Windows Server 2016 pour Docker ;
  • Disponible sous Windows 10 ;
  • Exécution d’un conteneur Linux sous Windows.
• Systèmes de gestion de conteneurs :
  • Docker [2013] environnement de haut niveau ;
  • Rocket [2014] plus sur, plus ouvert, ...
  • RunC [2015] outil bas niveau issu de Docker.

3.3  Création d’un conteneur "à la main"

• création d’un système de fichiers rootfs par debootstrap ;
• limitation de l’espace disque par création d’un fichier "partition" ...
• ... avec l’utilitaire dd et formatage avec mkfs ;
• préparation du montage du pseudo système de fichier /proc :

  echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab
  

• utilisation de chroot pour l’isolation du système de fichier racine ;
• création du processus isolé par unshare :
  • pour débuter : unshare -p -f -m chroot rootfs /bin/sh -c "mount /proc ; /bin/bash" ;
  • l’option -f permet de lancer la commande dans un fils, indispensable si l’option -p est utilisée ;
  • utiliser les options -n -u pour un réseau indépendant ;
  • utiliser les options -U --map-root-user pour des utilisateurs spécifiques ;
  • utiliser l’option -i pour des IPC privées.

3.4  Imposer des limitations aux conteneurs

• Un dispositif cgroups de limitation d’accès aux ressources ...
• ... c’est à dire processeurs, mémoires, entrées/sorties, périphériques, ...
• Restriction sur les processeurs utilisables :

  # mkdir /sys/fs/cgroup/cpuset/model1
  # echo "2-3" > /sys/fs/cgroup/cpuset/model1/cpus
  # echo $pid > /sys/fs/cgroup/cpuset/model1/tasks
  

• Restriction sur l’utilisation mémoire :

  # mkdir /sys/fs/cgroup/memory/model1
  # echo "128M" > /sys/fs/cgroup/memory/model1/memory.limit_in_bytes
  # echo $pid > /sys/fs/cgroup/memory/model1/tasks
  

• Limitation du nombre d’entrées et sorties :

  # mkdir /sys/fs/cgroup/blkio/model1
  # echo "8:0 10485760" > /sys/fs/cgroup/blkio/model1/blkio.throttle.write_bps_device
  # echo $pid > /sys/fs/cgroup/blkio/model1/tasks
  

• Interdiction d’accès à un périphérique :

  # mkdir /sys/fs/cgroup/devices/model1
  # echo "b 8:0 rmw" > /sys/fs/cgroup/devices/model1/devices.deny
  # echo $pid > /sys/fs/cgroup/devices/model1/tasks
  

3.5  Orchestrateur Docker / images

• Popularité : large choix d’images de conteneurs.
• Gestion des images au travers de dépôts :
  • accès anonyme pour la récupération ;
  • identification pour le stockage ;
  • recherche : docker search mail ;
  • détails sur https://hub.docker.com/ ;
  • récupération d’image, e.g. docker pull debian ;
  • stockage d’image dans un dépôt local :

    # docker images 
    REPOSITORY  TAG    IMAGE ID     CREATED      SIZE
    debian      jessie e5599115b6a6 4 weeks ago  123 MB
    ....
    # docker tag e5599115b6a6 docker.mondomaine.org:5000/my-debian
    # docker push docker.mondomaine.org:5000/my-debian
    

3.6  Orchestrateur Docker / conteneurs

• Instanciation d’une image :
  • création du conteneur, e.g. docker run -i -t debian /bin/bash ;
  • il est possible de se détacher par CTRL-P puis CTRL-Q ;
  • pour lister les conteneurs actifs : docker ps ;
  • pour reprendre docker attach ID ;
  • prendre la main sur un conteneur : docker exec -i -t NAME /bin/bash.
• Modification d’une image :
  • en direct au travers d’un shell ;
  • ou en utilisant un "fichier Docker" ;

    # cat Dockerfile
    FROM debian
    MAINTAINER Moi
    RUN apt-get update
    RUN apt-get -y install apache2
    EXPOSE 80
    CMD /usr/sbin/apache2ctl -D FOREGROUND
    # docker build -t apache .
    

  • sauvegarde de l’image modifiée :

    # docker commit 814b74435ace my-apache
    sha256:ea17999b6621fcb62b4999fbd0e23e54aef72a9418c4d0d37d411c8737bd4f8d
    # docker images
    REPOSITORY  TAG    IMAGE ID     CREATED      SIZE
    my-apache   jessie ea17999b6621 4 weeks ago  123 MB
    ...
    # docker tag ea17999b6621 docker.mondomaine.org:5000/my-apache
    # docker push docker.mondomaine.org:5000/my-apache
    

3.7  Orchestrateur Docker / restrictions

• Limitation possible de l’accès aux ressources.
• Une option marteau-pilon pour un accès complet :

  # docker run --privileged -i -t debian /bin/bash
  

• Restriction sur les processeurs utilisables :

  # docker run --cpus=0.5 -i -t debian /bin/bash
  # docker run --cpu-count=2 -i -t debian /bin/bash
  

• Restriction sur l’utilisation mémoire :

  # docker run --memory=128m --memory-swap=256m -i -t debian /bin/bash
  

• Limitation du nombre d’entrées et sorties :

  # docker run --device-write-bps=/dev/sda:10mb -i -t debian /bin/bash
  

• Autorisation d’accès à un périphérique :

  # # rwm -> read, write and mknod
  # docker run --device=/dev/sdb:rwm -i -t debian /bin/bash
  

• Beaucoup d’autres options de restriction ou d’autorisation :

  # man docker run
  

3.8  Orchestrateur Docker / réseau

• Mise en réseau via des commutateurs virtuels :
  • liste des ponts existants :

    # docker networks ls
    NETWORK ID          NAME                DRIVER              SCOPE
    422a25c7e8cf        bridge              bridge              local
    3e0f696af22b        host                host                local
    b00b2e188cb6        none                null                local
    

  • bridge pour des conteneurs avec mascarade.
  • host pour un partage des interfaces avec l’hôte.
  • none pour des conteneurs complétement isolés.
  • création possible de nouveaux commutateurs :

    # docker network create mybridge
    

  • création de conteneur sur un commutateur particulier :

    # docker run -i --net=mybridge -t my-apache /bin/bash
    

  • connexion d’un conteneur sur un commutateur :

    # docker network connect bridge 9ae343fe5609
    

• Exposition d’un port particulier :

  # docker run -i -p 80:80 -t my-apache /bin/bash
  

4  Gestion avancée des disques

4.1  Problèmes liés à l’administration des disques

• Problème de la rigidité des systèmes classiques :
  • surdimensionnement des partitions
  • sous-dimensionnement des partitions
• Problème de la lenteur des systèmes classiques :
  • accès aux disques intrinséquement lent
  • augmentation de la vitesse des bus
• Problème de la fragilité des systèmes classiques :
  • destruction possible de disque
  • baisse des prix des disques
• La solution est dans le regroupement de partition.

4.2  Solution : accélération et redondance

• Notion de redondance des données :
  • ensemble de partitions identiques,
  • redondance des données sur les partitions.
• Cas particulier du RAID logiciel :
  • RAID = Redundant Array of Inexpensive Disks
  • Différents types de RAID :
    • RAID-0 ou linéaire => plus grande souplesse
    • RAID-1 ou miroir => plus grande robustesse
      
    • RAID-4 et RAID-5 => variantes moins couteuses
      
    • RAID-6 => deux sommes de contrôle

4.3  Solution : accélération et facilité d’administration

• Notion de domaines dynamiques :
  • ensemble de partitions de disques,
  • ajout et suppression dynamiques.
• Notion de volumes logiques :
  • un ou plusieurs par domaine,
  • montage des volumes logiques.

4.4  Exemple de volume logique (Linux)

• LVM sous Linux (Logical Volume Manager).
• Le lexique de LVM en image :
  
• Exemple d’initialisation de volumes physiques :

  $ pvcreate /dev/sda
  $ pvcreate /dev/sdb
  

• Exemple de création de groupe de volumes :

  $ vgcreate volume /dev/sda
  $ vgdisplay 
  

• Exemple de création de volumes logiques :

  $ lvcreate -L10G -nroot volume ; mkfs /dev/volume/root
  $ lvcreate -L100G -nvar volume ; mkfs /dev/volume/var
  $ lvcreate -L100G -ntmp volume ; mkfs /dev/volume/tmp
  

• Ajout d’un volume physique :

  $ pvcreate /dev/sdc
  $ vgextend volume /dev/sdc
  $ lvextend -L+10G /dev/volume/root
  $ resize2fs /dev/volume/root
  

• Suppression d’un volume physique :

  $ pvmove /dev/sda /dev/sdc
  $ vgreduce volume /dev/sda
  

5  Administration système avancée

5.1  La classique gestion par ssh

• Automatisation par connexion sans mot de passe.
• Génération d’une clef asymétrique :

  # ssh-keygen -t ed25519
  

• Installation de la clef publique sur une cible :

  # cat .ssh/id_ed25519.pub | ssh cible "cat >> /root/.ssh/authorized_keys"
  

• Bonne pratique : jamais en tant que root ...
• Administration facile :

  # for m in machine01 machine02 machine03 ; do
  #   scp /etc/ntp.conf $m:/etc/
  # done
  

5.2  Ansible : l’inventaire

• Installation triviale : apt install ansible.
• Fichiers sous format yaml (YAML Ain’t Markup Language) ...
• ... parce que c’est quand même plus drôle de réinventer la roue.
• Exemple de fichier yaml :

  ---
  - élément1 # commentaire inutile
  - champ1: valeur1
    champ2: valeur2
  - élément2
  ...
  # Le code ci-dessus est équivalent à
  # [élément1,{champ1: valeur1, champ2: valeur2},élément2]
  

• L’inventaire est la liste des machines du parc :

  # cat /etc/ansible/hosts
  all:
    hosts:
      test:
        ansible_host: 192.168.0.1
      rpi:
        ansible_host: 192.168.100.1
    children:
      serveurs-prod:
        hosts:
          sandbox.insecserv.deule.net:
          brisban.insecserv.deule.net:
      serveurs-tp:
        hosts:
          chassiron.insecserv.deule.net:
          cordouan.insecserv.deule.net:
      stations:
        hosts:
          zabeth[02:22].plil.info:
  

• C’est triste à dire c’est plus clair en format INI :

  # cat /etc/ansible/hosts
  test ansible_host=192.168.0.1
  rpi ansible_host=192.168.100.1
  
  [serveurs-prod]
  sandbox.insecserv.deule.net
  brisban.insecserv.deule.net
  
  [serveurs-tp]
  chassiron.insecserv.deule.net
  cordouan.insecserv.deule.net
  
  [stations]
  zabeth[02:22].plil.info
  

• Déjà des fonctionnalités rien qu’avec l’inventaire :

  # ansible ungrouped -a "uname -a"
  ...
  # ansible stations -a "lsb_release -d"
  ...
  

5.3  Ansible : notion de "playbook"

• Un "playbook" liste des tâches à effectuer sur des machines.
• De très nombreux modules prédéfinis pour les tâches.
• Les tâches se doivent d’être idempotentes.
• Commande spécifique pour lancer un "jeu" :

  # ansible-playbook jeu.yml
  

• Exemple de "jeu" :

  ---
  - hosts: stations
    tasks:
    - name: configuration files
      copy:
        src: "{{ item.src }}"
        dest: "{{ item.dest }}"
        owner: root
        group: root
        mode: '0644'
      with_items:
        - { src: '/etc/resolv.conf', dest: '/etc/resolv.conf'}
        - { src: '/etc/apt/sources.list', dest: '/etc/apt/sources.list'}
        - { src: '/etc/default/ntpdate', dest: '/etc/default/ntpdate'}
        - { src: '/etc/ntp.conf', dest: '/etc/ntp.conf'}
    - name: network interfaces
      template:
        src: '/etc/ansible/templates/interfaces'
        dest: '/etc/network/interfaces'
        owner: root
        group: root
        mode: '0644'
      vars:
        num: "{{ inventory_hostname | regex_replace('^[^0-9]*([0-9]*).*$','\\1') }}"
        ip4: "{{ num | int + 50 }}"
        ip6: "00{{ num }}"
    - name: packages to be installed 
      apt:
        update_cache: yes
        name: "{{ packages }}"
      vars:
        packages:
         - linux-image-4.19.0-0.bpo.5-amd64
         - linux-compiler-gcc-6-x86=4.19.67-2+deb10u1~bpo9+1
         - linux-headers-4.19.0-0.bpo.5-amd64
         - ntpdate
         - ntp
    - name: packages to be removed 
      apt:
        name: "{{ packages }}"
        state: absent
        autoremove: yes
      vars:
        packages:
         - wicd
  

• Possibilité de définir plusieurs "jeux".

  ---
  - hosts: ...
    tasks:
  - hosts: ...
    tasks:
  

• Notions d’événements (mot clef "notify") :

  ---
  - hosts: serveur web
    tasks:
    - name: configuration files
      copy:
        src: web/monsite
        dest: /etc/apache2/site-enables/monsite
        owner: root
        group: root
        mode: '0644'
      notify: restart apache
    handlers:
    - name: restart apache
      service:
        name: apache2
        state: restarted
  

5.4  Ansible : gestion par rôles

• Les rôles sont sensés organiser les "playbooks".
• Cela aurait pu être fait en utilisant :
  • une structure yaml ;
  • des inclusions de fichiers.
• C’est quand même plus amusant d’ajouter une structure de répertoires :
  • un répertoire général roles ;
  • un sous-répertoire par rôle ;
  • des sous-sous-répertoires de configuration du rôle :
    • tasks listant les tâches ;
    • handlers tâches gérant les événements ;
    • vars variables ;
    • files fichiers pour le module copy par exemple ;
    • templates fichiers pour le module template par exemple ;
    • ...
  • un fichier main.yml dans chaque répertoire feuille.
• Le fichier de "jeu" est alors réduit à l’appel de rôles.
• Exemple de fichier invoquant des rôles :

  ---
  - hosts: stations
    roles:
      - ntp
      - dnsresolver
    vars:
      ntp_timezone: Europe/Paris
      dnsserveur: 8.8.8.8
  

• De nombreux rôles déjà écrits (génial pour les chevaux de Troie).
• Un utilitaire du paquetage ansible pour installer automatiquement des rôles :

  ansible-galaxy install geerlingguy.docker
  

6  Protocole IPv6

6.1  L’adressage IPv6

• Des adresses sur 128 bits (16 octets).
• Notation mots hexadécimaux double pointés.
• Plusieurs adresses par interface :
  • une notion d’adresses locales :
    
  • des adresses routées :
    
    

    Top Level Aggregator	grands opérateurs internationaux
    Next Level Aggregator	opérateurs de moindre importance
    Site Level Aggregator	gestionnaire du site

  • des adresses multicast prédéfinies :
    • un préfixe en fonction du niveau de diffusion :
      • FF02::/16 pour le lien local,
      • FF05::/16 pour le site local (obsolète),
      • FF0E::/16 pour l’ensemble d’Internet.
    • des groupes de services :
      • 0x1 pour les noeuds IPv6,
      • 0x2 pour les routeurs IPv6,
      • 0x101 pour les serveurs NTP,
      • 0x10003 pour les serveurs DHCP, ...
    • exemple des routeurs locaux : FF02::2.

6.2  Exemple d’adresse IPv6

• Adresses de douaisis.escaut.net :
  • adresse locale : fe80::210:b5ff:fe86:b6a7/64 ;
  • adresse globale : 2001:660:4401:6002:210:b5ff:fe86:b6a7/64.
• Préfixes :
  • pour l’université (65536 réseaux) : 2001:660:4401::0/48 ;
  • pour l’école (256 réseaux) : 2001:660:4401:6000::0/56.

6.3  Format des paquets IPv6

• Pas de somme de contrôle :
  • évite le recalcul lors d’un routage,
  • supports physiques de meilleure qualité.
• Identificateur de flux :
  • repérage de flux par les routeurs,
  • identificateur global sur le chemin ou ...
  • ... identificateur local aux routeurs.
• Longueur des données : entête IPv6 non incluse.
• Nombre de sauts : identique à la durée de vie IPv4.
• Un type d’entête suivante :
  • chaînage pour éviter la surcharge des routeurs,
  • un entête concerne un protocole ou une extension,
  • il faut terminer par un protocole.

6.4  Format des entêtes IPv6

• Les entêtes de type extension :

  Code	Nom
  0	Proche en proche
  43	Routage
  44	Fragmentation
  50	Identification
  51	Confidentialité
  59	Fin des entêtes
  60	Destination

• Les entêtes de type protocole :

  Code	Nom
  6	TCP
  17	UDP
  41	IPv6
  58	ICMPv6

6.5  Les extensions IPv6

• Elles remplacent certains champs IPv4 (fragmentation).
• Elles remplacent certaines options IPv4 (routage par la source).
• Des extensions examinées par tous les routeurs (jumbogrammes).
• Des extensions examinées par la destination (mobilité).
• Des extensions pour la sécurité :
  • identification de l’émetteur :
    • clef secrète partagée par les correspondants,
    • calcul d’une somme de contrôle codée par la clef,
    • décodage puis vérification de la somme par le destinataire,
    • protection optionnelle contre le rejeu.
  • confidentialité des données :
    • mode transport : entêtes de niveau 4 cryptées,
    • mode tunnel : tout le paquet est crypté.

6.6  Les protocoles IPv6

• Une somme de contrôle obligatoire :
  • prend en compte une pseudo-entête :
    • adresse IPv6 de l’émetteur,
    • adresse IPv6 du destinataire,
    • longueur des données (sur 32 bits),
    • code du protocole de niveau 4.
  • prend en compte l’entête du protocole et ses données.
  • l’algorithme somme les mots de 16 bits en complément à 1.
  • le résultat est le complément à 1 de la somme.
• Une bonne nouvelle : pas de modification d’UDP ou de TCP.
• Un nouveau protocole de contrôle : ICMPv6.

6.7  Le format de la trame

• Identique à une trame ICMPv4 :
  

6.8  Les codes utilisés

• Trois catégories de codes.
• La gestion des erreurs :
  • les différents types :

    Type	Description
    1	destination inaccessible
    2	paquet trop grand
    3	paquet trop vieux
    4	erreur de paramétre

  • Codes possibles pour le type "Destination inaccessible" :

    Code	Description
    0	Réseau inaccessible
    1	Interdiction administrative
    2	Pas un voisin
    3	Adresse inaccessible
    4	Port inaccessible

• Les codes d’information :

  Type	Description
  128	demande d’écho
  129	réponse d’écho
  130	demande de gestion multicast
  131	rapport de gestion multicast
  132	réduction d’un groupe multicast

• Codes pour la découverte des voisins :

  Type	Description
  133	sollicitation du routeur
  134	annonce du routeur
  135	sollicitation d’un voisin
  136	annonce d’un voisin
  137	redirection

6.9  Configuration automatique

• Obtention automatique d’une adresse routée.
• Plus de table de routage au niveau des machines.
• Paquets mis en oeuvre :
  • sollicitation de routeur :
    
  • annonce du routeur :
    
  • le bit M impose l’autoconfiguration avec états,
  • le bit O indique la présence d’informations réseau.
• Options des paquets :
  • options pour les adresses physiques :
    
  • option d’information sur le préfixe :
    
  • le bit L indique la correspondance réseau physique / logique,
  • le bit A autorise la fabrication d’adresse globale.

7  Administration réseau avancée

7.1  Rappel des commandes de routage sous Linux

• Regroupement des commandes => ip.
• Utilisation au niveau des interfaces :

  oleron# ip link show
  1: lo: <LOOPBACK,UP> mtu 16144 qdisc noqueue
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
      link/ether 00:10:b5:03:88:44 brd ff:ff:ff:ff:ff:ff
  oleron# ip link set eth0 down
  oleron# ip link set eth0 address 00:10:b5:03:88:44
  

• Utilisation pour affecter les adresses IP :

  oleron# ip address add dev eth0 193.48.64.200/24 broadcast +
  oleron# ip address show eth0
  5: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
      link/ether 00:10:b5:03:88:44 brd ff:ff:ff:ff:ff:ff
      inet 193.48.64.39/24 brd 193.48.64.255 scope global eth0
      inet 193.48.64.200/24 brd 193.48.64.255 scope global secondary eth0
      inet6 fe80::210:b5ff:fe03:8844/10 scope link  
  

• Contrôle de la résolution d’adresses physiques :

  oleron# ip neighbour show dev eth0
  193.48.64.1 lladdr 00:d0:bc:bf:6c:38 nud reachable
  193.48.64.47 lladdr 00:10:b5:07:36:82 nud stale
  193.48.64.45 lladdr 00:10:b5:07:34:97 nud reachable 
  oleron# ip neighbour add 193.48.64.250 lladdr 00:10:b5:03:88:44 dev eth0
  

• Mise à jour d’une table de routage :
  • le routage traditionnel (unicast) :

    oleron# ip route add 10.0.0.0/8 via 193.48.64.200
    oleron# ip route show
    193.48.64.0/24 dev eth0  proto kernel  scope link  src 193.48.64.39
    10.0.0.0/8 via 193.48.64.200 dev eth0
    default via 193.48.64.1 dev eth0  
    

  • le routage multi-chemin :

    pevele# ip route add default nexthop via 193.48.57.33
                                 nexthop via 193.48.57.62
    

  • autres types de routage :
    • un exemple avec le type prohibit :

      artois# ip route add prohibit 207.46.0.0/16
      gayant08$ ping -v www.microsoft.com
      PING microsoft.com (207.46.130.45): 56 data bytes
      112 bytes from artois.escaut.net (172.26.16.7): Packet Filtered              
      

    • un exemple avec le type nat :

      artois# ip route add nat 193.48.57.48/29 via 172.26.17.136
      

• Ajout d’une règle de stratégie de routage :

  artois# ip route add 193.48.57.32/27 dev eth0 table 100
  artois# ip route add 172.26.16.0/20 dev eth1 table 100 
  artois# ip route show table 100
  193.48.57.32/27 dev eth0 scope link
  172.26.16.0/20 dev eth1 scope link
  artois# ip rule add priority 310 from 172.26.17.128/29 lookup table 100
  0:      from all lookup local
  310:    from 172.26.17.128/29 lookup 100
  32766:  from all lookup main
  32767:  from all lookup default     
  artois# ip rule add priority 320 from 172.26.17.136/29 nat 193.48.57.48 
  artois# ip rule show
  0:      from all lookup local
  310:    from 172.26.17.128/29 lookup 100
  320:    from 172.26.17.136/29 lookup main map-to 193.48.57.48
  32766:  from all lookup main
  32767:  from all lookup default
  

• Configuration de tunnels :

  artois# ip tunnel show
  tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
  gre0: gre/ip  remote any  local any  ttl inherit  nopmtudisc
  sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc
  sit1: ipv6/ip  remote 206.123.31.102  local any  ttl 64
  

7.2  Interfaces VLAN

• Interface sur un port trunk.
• Possibilité d’interfaces virtuelles par VLAN.
• Création d’une interface virtuelle :

  vconfig add eth0 2                               # Obsolète
  ip link add name vlan2 link eth0 type vlan id 2  # Courant
  

• Destruction d’une interface virtuelle :

  vconfig rem vlan2     # Obsolète
  ip link del dev vlan2 # Courant
  

• Configuration de haut niveau :

  iface vlan2 inet dhcp
    vlan-raw-device eth0
  

7.3  Commutateur logiciel

• Matériel nécessaire : plusieurs cartes réseau.
• Applications :
  • commutateur de secours,
  • chaînage d’éléments réseau,
  • commutateurs virtuels (virtualisation).
• Création du commutateur :

  brctl addbr monpont              # Obsolète
  ip link add monpont type bridge # Courant
  

• Ajout d’interfaces dans le commutateur :

  brctl addif monpont eth0         # Obsolète
  brctl addif monpont eth1         # Obsolète
  ip link set eth0 master monpont  # Courant
  ip link set eth1 master monpont  # Courant
  

• Activation des interfaces :

  ifconfig eth0 up     # Obsolète
  ifconfig eth1 up     # Obsolète
  ip link set eth0 up  # Courant
  ip link set eth1 up  # Courant
  

• Activation du pont :

  ifconfig monpont up                                 # Obsolète
  ifconfig monpont 192.168.0.1 netmask 255.255.255.0  # Obsolète
  ip address add dev monpont 192.168.0.1/24           # Courant
  

• Configuration de haut niveau :

  auto eth0 eth1 monpont
  iface eth0 inet manual
    up ip link set $IFACE up
  
  iface eth1 inet manual
    up ip link set $IFACE up
  
  iface monpont inet static
    bridge_ports eth0 eth1
    address 192.168.0.1
    netmask 255.255.255.0
  

7.4  Création d’une interface virtuelle

• Permet de connecter des conteneurs ;
• Création de deux interfaces liées :

  ip link add vif1 type veth peer name eth0@vif1
  

• Déplacement du pair dans un espace réseau différent :

  ip link set eth0@vif1 netns /proc/<PID>/ns/net name eth0
  

• Configuration réseau dans l’espace alternatif :

  nsenter -t <PID> -n ip address add dev eth0 192.168.0.100/24
  nsenter -t <PID> -n ip route add default via 192.168.0.1
  

• Placez l’autre extrémité dans un commutateur logiciel.

7.5  Réflexion sur la translation d’adresse

• NAT signifie Network Address Translation.
• La translation peut être :
  • sans état (bijection entre les adresses),
  • ou avec état (compression possible de l’espace d’adressage).
• La translation peut concerner :
  • les adresses sources (SNAT),
  • ou les adresses destination (DNAT).

7.6  Introduction d’une notion de filtres 1/3

• But : contrôle fin de certains paquets.
• But : modification de certains paquets.
• Principe sous Linux :
  • Une table pour contrôler :
    
  • Une table pour modifier les adresses :
    
  • Une table pour des modifications particulières :
    
• Sélection des paquets suivant certains critères :
  • interface d’arrivée ou de sortie,
  • adresse de niveau liaison (ethernet),
  • type du protocole IP, adresses source ou destination,
  • plage de ports source ou destination pour TCP et UDP,
  • divers champs spécifiques de TCP, UDP ou ICMP,
  • utilisateur ou groupe émetteur des paquets, ...
• Diverses actions disponibles :
  • accepter, refuser ou tracer des paquets,
  • translation d’adresses source (niveau connexion),
  • translation d’adresses destination (niveau connexion),
  • marquer des paquets, modifier leur type de service.
• Paquetages Debian/Devuan :
  • iptables : l’utilitaire ;
  • iptables-persistent : un mécanisme pour sauvegarder les tables.

7.7  Introduction d’une notion de filtres 2/3

• nouveau filtrage de paquets nftables :
  • disponible depuis les noyaux Linux 3.13 ;
  • nouvel utilitaire nft avec une syntaxe différente (ben voyons) ;
  • un utilitaire compatible iptables peut encore être utilisé (iptables-nft) ;
  • intégration d’IPv4 et d’IPv6 ;
  • plusieurs actions possibles par règles ;
  • en résumé pas de révolution mais une réécriture.
• Paquetages Debian/Devuan :
  • nftables : l’utilitaire nft ;
  • iptables : l’utilitaire de transistion iptables-nft.
• Vous l’utilisez déjà :

  # ls -l /usr/sbin/iptables
  lrwxrwxrwx 1 root root 26  9 avril  2019 /usr/sbin/iptables -> /etc/alternatives/iptables
  # ls -l /etc/alternatives/iptables
  lrwxrwxrwx 1 root root 22  9 avril  2019 /etc/alternatives/iptables -> /usr/sbin/iptables-nft
  

• Pas de table prédéfinie, il faut en ajouter :

  # nft add table {ip|arp|ip6|bridge|inet|netdev} <nom_table>
  

• Pas de chaîne prédéfinie, il faut en ajouter :

  # nft add chain <nom_table> <nom_chaine>    \
    { type {filter|route|nat}     \
      hook {prerouting|input|forward|output|postrouting}  \
      priority <niveau_priorité> \; [ policy {accept|drop} \; ] \
    }
  

• Vous pouvez enfin ajouter ou retirer des règles :

  # nft add rule <nom_table> <nom_chaîne> <contraintes> {drop|accept|...}
  

7.8  Introduction d’une notion de filtres 3/3

• Pour filtrer les paquets routés ...
• il faut que le routage soit activé.
• Configuration temporaire :

  $ cat /proc/sys/net/ipv4/ip_forward
  0
  # echo 1 > /proc/sys/net/ipv4/ip_forward
  

• Configuration permanente :

  # echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
  # sysctl -p
  net.ipv4.ip_forward = 1
  

7.9  Pare-feu : restriction d’accès

• Interdire l’accès au réseau local.
• Principe de fonctionnement :
  
• Variante : limitation d’accès.
• Exemple d’utilisation :
  • interdire les accès FTP vers Internet ;
  • interdire les connections vers le pare-feu.
• Configuration de pare-feu avec iptables :

  # iptables -P FORWARD ACCEPT
  # iptables -A FORWARD -j DROP -p tcp -s 193.48.57.32/27 --dport ftp
  # iptables -P INPUT ACCEPT
  # iptables -A INPUT -j DROP -p tcp -d 134.206.3.60 --dport telnet
  

• Configuration de pare-feu avec nft :

  # nft add table ip FILTER
  # nft add chain FILTER FORWARD { type filter hook forward priority 0\; policy accept\; }
  # nft add rule FILTER FORWARD ip saddr 193.48.57.32/27 tcp dport 21 drop
  

7.10  Redirection de ports : ouverture d’accès

• Autoriser la connexion sur des machines non routée.
• Redirection de ports avec iptables :

  # iptables -t nat -A PREROUTING -p tcp --dport 2200 -j DNAT --to-destination 192.168.0.42:22
  

• Configuration de pare-feu avec nft :

  # nft add table ip NAT
  # nft add chain NAT PREROUTING { type nat hook prerouting priority 0\; }
  # nft add rule NAT PREROUTING  tcp dport 2200 dnat to  192.168.0.42:22
  

7.11  Pare-feu : mascarade

• Une machine se fait passer pour une autre.
• Utilisation de la mascarade :
  • piratage d’un centre informatique ;
  • accès à l’Internet d’un réseau local.
• Adresses réservées pour réseau local :
  • classe A : 10.0.0.0 ;
  • classes B : 172.16.0.0 à 172.31.0.0 ;
  • classes C : 192.168.0.0 à 192.168.255.0.
• Principe de fonctionnement :
  
• Configuration de mascarade avec iptables :

  artois# iptables -P FORWARD DROP
  artois# iptables -A FORWARD -j ACCEPT -s 172.26.16.0/20
  artois# iptables -A FORWARD -j ACCEPT -d 172.26.16.0/20
  artois# iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.26.16.0/20
  

• Configuration de mascarade avec nft :

  # nft add table ip FILTER
  # nft add chain FILTER FORWARD { type filter hook forward priority 0\; policy drop\; }
  # nft add rule FILTER FORWARD ip saddr 172.26.16.0/20 accept
  # nft add rule FILTER FORWARD ip daddr 172.26.16.0/20 accept
  # nft add table ip NAT
  # nft add chain NAT POSTROUTING { type nat hook postrouting priority 100 \; }
  # nft add rule nat postrouting ip saddr 172.26.16.0/20 oif eth0 masquerade
  

7.12  Encapsulation d’IP dans IP

• Définition de l’encapsulation (tunneling) :
  • un protocole d’encapsulation ;
  • un protocole encapsulé ;
  • encapsulation à un bout du tunnel ;
  • dé-encapsulation à l’autre bout ;
• Utilisation de l’encapsulation :
  • extension d’un réseau non routable ;
  • création d’un réseau virtuel ;
  • création d’un réseau sécurisé.
• Exemples d’utilisation :
  • encapsulation d’AppleTalk dans IPv4 (routage) ;
  • encapsulation d’IPv4 dans IPv4 (réseau privé) ;
  • encapsulation d’IPv6 dans IPv4 (transition) .
• Exemple d’utilisation (transition) :

  RG20-3640#show running-config interface tunnel0
  interface Tunnel0
   no ip address
   ipv6 address 2001:660:3000:1104:140::/64
   ipv6 enable
   ipv6 rip T0 enable
   tunnel source FastEthernet3/0.2
   tunnel destination 193.51.178.140
   tunnel mode ipv6ip
  end
  RG20-3640#show ip route
       172.26.0.0/20 is subnetted, 2 subnets
  C       172.26.224.0 is directly connected, FastEthernet3/0
  C       172.26.16.0 is directly connected, FastEthernet3/0.4
       193.48.57.0/27 is subnetted, 1 subnets
  C       193.48.57.32 is directly connected, FastEthernet3/0.2
  S*   0.0.0.0/0 [1/0] via 193.48.57.33
                 [1/0] via 172.26.224.1
  RG20-3640#show ipv6 route
  ...
  S   ::/0 [1/0] via ::, Tunnel0
  RG20-3640#
    

• Exemple d’utilisation (réseau privé) :
  • ajout d’hote fictif à l’USTL ;
  • l’hote est situé à Polytech’Lille.
• Schéma de fonctionnement virtuel :
  
• Schéma de fonctionnement réel :
  
• Commandes de configuration (Linux >= 2.2) :
  • machine albanie.ilot.org :

    albanie# ip tunnel add ustl mode ipip remote 134.206.85.135
    albanie# ip link set ustl up
    albanie# ip address add 134.206.85.136/16 broadcast + dev ustl 
    albanie# ip tunnel show ustl
    ustl: ip/ip  remote 134.206.85.135  local any  ttl inherit
    albanie# ip route add 134.206.85.135 dev eth0
    albanie# ip route add 134.206.0.0/16 dev ustl
    albanie# ip route show
    134.206.85.135 dev eth0  scope link
    193.48.57.224/27 dev eth0  proto kernel  scope link  src 193.48.57.226
    134.206.0.0/16 dev ustl  proto kernel  scope link  src 134.206.85.136
    default via 193.48.57.225 dev eth0  metric 1
    

  • machine statpc6.univ-lille1.fr :

    statpc6# echo "sysctl net.ipv4.conf.all.proxy_arp=1" >> /etc/sysctl.conf
    statpc6# sysctl -p
    statpc6# ip tunnel add epul mode ipip remote 193.48.57.226
    statpc6# ip address add 134.206.85.135/32 broadcast + dev epul
    statpc6# ip link set epul up
    statpc6# ip tunnel show epul
    epul: ip/ip  remote 193.48.57.226  local any  ttl inherit
    statpc6# ip neighbour add 134.206.85.136 lladdr 00:b0:d0:8c:91:10 dev eth0
    statpc6# ip route add 134.206.85.136 dev epul
    

7.13  Sélection de l’adresse source

• En cas d’adresse IP (IPv6) multiples.
• Comment le système sélectionne l’adresse source :
  1. même adresse que la destination ;
  2. même portée que la destination ;
  3. éviter les adresses obsolètes ;
  4. préférer l’adresse "domicile" (mobilité IPv6) ;
  5. préférer une adresse de l’interface de sortie ;
  6. préférer une adresse de même étiquette ;
  7. préférer une adresse publique ;
  8. utiliser l’adresse de préfixe le plus grand.
• Problème d’interface avec des adresses publiques multiples :

  l’interface de sortie n’aide pas (adresses sur la même interface) ;

  spécifier "domicile" ou "obsolète" sur une adresse n’aide pas ;

  les deux adresses sont publiques ;

  il ne reste plus que l’étiquette pour résoudre le problème.

• Principe : étiquetter les adresses ...
• ... étiquetter les destinations en conséquence.
• Comment étiquetter des préfixes :

  # ip -6 addrlabel add prefix ...
  

8  Sécurité réseau

8.1  Prélude : les gros mots

• Identification dans les réseaux WiFi domestiques :
  • WEP ;
  • WPA (sous-ensemble de IEEE 802.11i) ;
  • WPA2 (2004, IEEE 802.11i ou RSN) ;
  • WPA3 (2018, IEEE 802.11s) ;
  • WPA Personnel ~ WPA-PSK, WPA2-PSK (Pre-Shared Key) ;
  • WPA Personnel ~ WPA3-SAE (Simultaneous Authentication of Equals).
• Identification dans les réseaux filaires ou WiFi professionnels :
  • WPA Entreprise ~ WPA-EAP;
  • IEEE 802.1x (EAP sur IEEE 802);
  • EAPOL (à l’origine EAP sur IEEE 802.3);
  • EAP-TLS, EAP-PEAPv0, EAP-PEAPv1, EAP-TTLS ;
  • Radius.
• Le chiffrement dans les réseaux WiFi :
  • WEP ;
  • TKIP (WPA ou WPA2) ;
  • CCMP/AES (AES 128 bits avec WPA2, AES 256 bits avec WPA3).
• Le chiffrement dans les réseaux filaires :
  • Tunnels sécurisés ;
  • Certificats X509 ;
  • PKI (Public Key Infrastructure).

8.2  Tunnels sécurisés

• Création d’un tunnel sécurisé par clef symétrique ;
• SSL 1.0 à SSL 3.0 (1996), utilisés par Netscape ;
• SSL 3.0 est déclaré obsolète en 2015 (RFC 7568) ;
• TLS se base sur SSL 3.0, TLS 1.3 est proposé en 2016 ;
• HTTPS se base sur SSL/TLS ;
• SSH est un protocole équivalent mais à part.

8.3  Certificats X509

• Utilisé pour l’identification et chiffrement.
• Un certificat contient (entre autres) :
  • le Distinguished Name du certificat ;
  • un numéro de série ;
  • la période de validité ;
  • les propriétés du certificat ;
  • la clef publique ;
  • le Distinguished Name de l’autorité ;
  • la signature.
• Un certificat se trouve dans une chaine ...
• ... se terminant par une auto-signature.
• Pour l’identification le DN peut contenir :
  • le nom du serveur à certifier ;
  • l’adresse de courriel de l’utilisateur ...
• Pour le chiffrement le certificat s’utilise ...
• ... avec la clef privée correspondante.

8.4  Identification : WEP

• Pour réseau sans fil, obsolète.
• Soit aucune : "Open System Authentication".
• Soit par clef partagée : "Shared Key Authentication".
• Identification du client par le point d’accès.
• Identification du point d’accès non prévu.
• Mascarade possible (faux point d’accès).
• Principe de l’identification :
  • le point d’accès transmet une phrase en clair ;
  • le client WiFi chiffre à l’aide de la clef WEP ;
  • le point d’accès décode pour vérifier.
• Identification défectueuse à désactiver.

8.5  Identification : EAP

• Pour réseau sans fil ou filaire.
• Extensible Authentication Protocol, RFC 3748.
• Fixe un cadre pour l’identification.
• Uniquement 4 types de messages :
  • la requête ;
  • la réponse ;
  • le succès ;
  • l’échec.
• La trinité de l’identification EAP :
  • le suppliant (supplicant) ;
  • l’identifieur (authenticator) ;
  • le serveur d’identification (authentication server) ;
  • un exemple : portable, point d’accès, serveur radius.
• Format de paquets :
  

  Code	Identifier	Length	Data
  1 byte	2 bytes	4 bytes	n bytes

• Du détail : http://www.netcraftsmen.net/resources/archived-articles/429.html

8.6  Identification EAP : EAPOL

• EAP Over LAN, défini par la norme IEEE 802.1X.
• Utilisé par 802.{3,11} pour transporter de l’EAP.
• Type lorsqu’encapsulé dans Ethernet : 0x888e.
• Format de paquets pour EAPOL :
  

  Ethernet type	EAP Version	EAPOL Type	Length	EAP Packet
  2 bytes	1 byte	1 byte	2 bytes	n bytes

8.7  Identification EAP : EAP over Radius

• Remote Authentication Dial-In User Service, RFC 2865.
• Protocole générique pour l’identification (entre autre).
• La trinité de l’identification Radius :
  • the client or supplicant ;
  • the Network Access Server ;
  • the Radius server ;
  • un exemple : portable, commutateur, serveur radius.
• Uniquement 4 types de messages :
  • Access Request (NAS vers serveur) ;
  • Access Reject (réponse du serveur) ;
  • Access Accept (réponse du serveur) ;
  • Access Challenge (demande du serveur).
• Du détail : http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.1_19_ea1/configuration/guide/sw8021x.html
• Format de paquets pour Radius :
  

  Code	Identifier	Length	Authenticator	Attribute/value pairs
  1 byte	1 byte	2 bytes	16 bytes

• Exemples d’attributs Radius :
  • User-Name (1) ;
  • User-Password (2) ;
  • EAP-Message (79) ;
  • Message-Authenticator (80).

8.8  Identification : EAP-PSK

• Pour réseau sans fil.
• Définie par la RFC 4764.
• La Pre-Shared-Key (16 octets) donne lieu à :
  • la clef Authentication Key (16 octets, AK) ;
  • la clef Key-Derivation Key (16 octets, KDK).
• Un échange de clefs en 4 étapes :
  • Etape 1 : le point d’accès transmet une valeur aléatoire ;
  • Etape 2 : le client transmet sa valeur aléatoire et s’identifie;
  • Etape 3 : le point d’accès s’identifie et établit son canal ;
  • Etape 4 : le client établit son canal chiffré.
• Le client s’identifie en transmettant :
  • un message codé par AES ;
  • on utilise la clef AK ;
  • le message est la concaténation de :
    • l’adresse MAC du client ;
    • l’adresse MAC du point d’accès ;
    • la valeur aléatoire du point d’accès ;
    • la valeur aléatoire du client.
• Le point d’accès s’identifie en transmettant :
  • un message codé par AES ;
  • on utilise la clef AK ;
  • le message est la concaténation de :
    • l’adresse MAC du point d’accès ;
    • la valeur aléatoire du client.
• La KDK sert pour des clefs utilisées par EAPOL :
  • la clef Extended Master Session Key ;
  • la clef Master Session Key ;
  • la clef Transient EAP Key.
• La Pairwise Transcient Key découle de :
  • La Pairwise Master Key qui découle de la PSK ;
  • des adresses du point d’accès et du client ;
  • des valeurs aléatoire des deux correspondants.
• La PTK sert à chiffrer les paquets.

8.9  Identification : WPA/WPA2 personnel

• Pour réseau sans fil.
• Autre appelation : Robust Security Network.
• Autre appelation : IEEE 802.11i-2004.
• Messages echangés dans des paquets EAPOL.
• La Pairwise Master Key dérive du SSID et de la PSK :

  PMK = PBKDF2(PSK, SSID, 4096, 256) 
  

• Un échange de clefs en 4 étapes :
  • Etape 1 : le point d’accès transmet sa valeur aléatoire ;
    • le client construit sa Pairwise Transient Key ;
    • on utilise encore PBKDF2 pour construire la PTK ;
    • la chaîne passée à PBKDF2 est la concaténation :
      • la Pairwise Master Key calculée séparément ;
      • la valeur aléatoire du point d’accès ;
      • la valeur aléatoire du client ;
      • l’adresse MAC du point d’accès ;
      • l’adresse MAC du client.
  • Etape 2 : le client transmet sa valeur aléatoire et s’identifie ;
  • Etape 3 : le point d’accès transmet la Group Temporal Key ;
  • Etape 4 : le client transmet une confirmation.
• Identification :
  • le client s’identifie lors de l’échange 2 ;
  • le point d’accès s’identifie lors de l’échange 3 ;
  • identification par Message authentication and Integrity Code ;
  • MIC calculé par HMAC-MD5 avec une clef dérivée de la PTK ;
  • la clef dérivée est la Key Confirmation Key ;
  • La KCK provient des 128 bits de poids forts de la PTK ;
  • MIC calculé sur le message envoyé (EAP).
• La PTK chiffre entre client et point d’accès.
• La GTK chiffre les diffusions.

8.10  Identification : WPA3 personnel

• Pour réseau sans fil.
• Messages echangés dans des paquets EAPOL.
• Un échange de clefs nommé libellule (dragonfly) :
  • échange de type SPEKE (Simple Password Exponential Key Exchange) ;
  • un échange SPEKE est une extension d’échange ECDH (Diffie-Hellman Key Exchange).
• Une phase de confirmation permet de vérifier la connaissance de la clef K par le pair.

8.11  Identification : PEAP

• Pour réseau sans fil ou filaire.
• Protected Extensible Authentication Protocol.
• Méthode (complexe) pour protéger EAP.
• Chiffré par un tunnel "Transport Layer Security".
• Le serveur d’identification utilise un certificat ...
• ... le client est donc assuré de son identité.
• Dans le tunnel TLS on retouve des paquets EAP.
• L’identification EAP interne est libre.
• Pour PEAPv0 avec EAP-MSCHAPv2 :
  • l’identification est réalisée avec MSCHAP ;
  • Microsoft’s Challenge Handshake Authentication Protocol ;
  • le mot de passe doit être stocké en clair ;
  • des clients sur tous les systèmes.
• Pour PEAPv1 avec EAP-GTC :
  • l’identification est réalisée avec GTC ;
  • Generic Token Card ;
  • le mot de passe peut être stocké chiffré ;
  • pas de clients sur certains systèmes.

8.12  Chiffrement : réseaux filaires

• Pas de chiffrement, réputé sécurisé.
• Le sniffage est freiné par la commutation.
• Le sniffage est possible par insertion.
• Technique de l’homme au milieu.
• En patois "Man In The Middle" (MITM).

8.13  Chiffrement WiFi : rappels

• Trame générale :
  

  Control	Duration	Addr 1	Addr 2	Addr 3	Seq	Addr 4	Data	Check sum
  2 bytes	2 bytes	6 bytes	6 bytes	6 bytes	2 bytes	6 bytes	0-2312 bytes	4 bytes

• Drapeau de contrôle :
  

  2 bits	2 bits	4 bits	1 bit	1 bit	1 bit	1 bit	1 bit	1 bit	1 bit	1 bit
  Version	Type	Subtype	To DS	From DS	MF	Retry	Pwr	More	W	O

• Bit de contrôle W :
  • dénotait le chiffrement historique (WEP) ;
  • dénote maintenant un chiffrement quelconque.
• Informations de chiffrement dans les données.

8.14  Chiffrement WiFi : WEP

• WEP : Wired Equivalent Privacy.
• Fonctionnement :
  • un IV sur 24 bits (incrémenté ou tiré au hasard) ;
  • des clefs partagées (4 clefs possibles) ;
  • génération d’un flux d’octets aléatoire par RC4 ;
  • chiffrement par un ou exclusif bit à bit ;
  • résumé : code = RC4(IV || Clef) (+) données.
• Détail du champ données :
  

  24 bits	6 bits	2 bits	0-2304 bytes	32 bits
  Initialization Vector	Padding	Key number	Data	Integrity Check Value (CRC32)

8.15  Chiffrement WiFi : failles de WEP

• Faille de l’identification :
  • soit P la phrase envoyée en clair ;
  • soit C la réponse chiffrée d’un client ;
  • la relation est C = F (+) P ;
  • on découvre le flux aléatoire F pour un IV ;
  • le flux aléatoire est : F = C (+) P.
• Pas de dispositif anti-rejeu.
• Clefs de trop faibles tailles :
  • pour le WEP 64 bits, une clef de 40 bits ;
  • possible à trouver par force brute ;
  • des IV de 24 bits, cyclent en quelques heures.
• Intuiter des textes en clair :
  • capture de paquets C₁ et C₂ avec le même IV ;
  • ils s’écrivent : C₁ = F (+) P₁, C₂ = F (+) P₂ ;
  • on obtient P₁ (+) P₂ = C₁ (+) C₂ ;
  • on intuite un texte en clair (e.g. ARP), on obtient les autres.

8.16  Chiffrement WiFi : flux aléatoires

• Découverte par connaissance du texte :
  • on intuite un texte P en clair (e.g. requête ARP) :

    LLC	SNAP	ARP header	ARP opcode	ARP MAC source
    0xAAAA03	0x0000000806	0x000108000604	0x0001	0x010203040506

    
    

    ARP IP source	ARP MAC cible	ARP IP cible
    ...	...	...

  • ou on récupère le texte par sniffage (e.g. commande ping) ;
  • on obtient une fraction de flux aléatoire ;
  • cela s’écrit : F = C (+) P.
• Utilisation de la fragmentation :
  • possibilité d’envoyer 16 fragments ;
  • le point d’accès défragmente les diffusions ;
  • grand paquet chiffré dont le texte en clair est connu.
• Attaque chopchop :
  • capturer un paquet chiffré C = F (+) (D || ICV) ;
  • retirer le dernier octet de données D_n ;
  • le nouveau paquet chiffré est F_[0..n+3] (+) (D_[0..n−1] || ICV′) ;
  • les premiers octets sont inchangés F_[0..n−1] (+) D_[0..n−1] ;
  • les autres F_[n..n+3] (+) ICV′ sont déductibles ...
  • ... d’un octet X et de F_[n+1,n+4] (+) ICV ;
  • le point d’accès est utilisé 256 fois comme oracle ;
  • ICV₃, lui aussi, ne dépend que de ce X ;
  • on en déduit F_n+4 = ICV₃ (+) C_n+4.

8.17  Chiffrement WiFi : failles de RC4

• Attaque FMS de 2001 :
  • utilise des IV particulières (IV faibles) ;
  • permet d’intuiter le prochain octet de la clef ;
  • processus probabiliste itératif (probabilité 5%) ;
  • vérification de la clef finale obtenue ;
  • cassage en quelques heures suivant le trafic.
• Amélioration KoreK de 2004 :
  • probabilité de 14% au lieu de 5% ;
  • des optimisations pour rejeter de fausses clefs.
• Attaque PTW (2005, 2007, 2008) :
  • permet d’exploiter tous les IV ;
  • 50% de probabilité au bout de 40000 paquets ;
  • 95% de probabilité au bout de 85000 paquets ;
  • PTW 2008; 50% de probabilité avec 25000 paquets.

8.18  Chiffrement WiFi : TKIP

• WPA : WiFi Protected Access.
• TKIP : Temporal Key Integrity Protocol.
• But : meilleure protection, même matériel.
• Améliorations :
  • meilleur mécanisme de vérification d’intégrité ;
  • protection contre le re-jeu de paquets (TSC) ;
  • meilleure sélection de la graine du RC4.
• Détail du champ données :
  

  1 byte	1 byte	1 byte	5 bits	1 bit	2 bits
  TSC 1	Seed	TSC 0	Reserved	Extended ?	Key number

  
  

  1 byte	1 byte	1 byte	1 byte	0-2292 bytes	8 bytes	4 bytes
  TSC 2	TSC 3	TSC 4	TSC 5	Data	MIC	ICV

8.19  Chiffrement WiFi : TKIP

• Fonctionnement du chiffrement TKIP.
• Les données :
  • clef partagée : Pairwise Transcient Key :
    • clef de 16 octets : Key Confirmation Key (EAPOL) ;
    • clef de 16 octets : Key Encryption Key (EAPOL) ;
    • clef de 16 octets : Transcient Encryption Key ;
    • clef de 8 octets : MIC Key (un sens) ;
    • clef de 8 octets : MIC Key (l’autre sens).
  • un compteur de paquets : TKIP Sequence Counter ;
  • l’adresse de la source : Source Address ;
  • l’adresse de la destination : Destination Address ;
  • l’adresse du point d’accès : Transmitter Address.
• Les calculs :
  • la clef TKIP-mixed Transmit Address and Key ...
  • ... est fonction de TA, TEK, TSC (4 octets forts) ;
  • la clef Per Packet Key ...
  • ... est fonction de TEK, TSC (2 octets faibles) , TTAK ;
  • le calcul du Message Integrity Check (algo. Mickael) ..
  • ... est fonction de DA, SA, MK et des données.
• Le bon vieux WEP :
  • on chiffre TSC₂ à TSC₅, les données, le MIC et l’ICV ;
  • on utilise comme IV (24 bits) : TSC₀, (TSC₁|0x020)&0x7f, TSC₁ ;
  • on utilise comme clef (104 bits) : PPK.
• Des contre-mesures en cas d’attaque :
  • au niveau du déchiffrement du paquet ;
  • dans le cas où l’ICV est correct ;
  • mais où le MIC ne l’est pas ;
  • et si cela se produit plusieurs fois en 60s ;
  • arrêt pendant 60s et désassociation.

8.20  Chiffrement WiFi : faiblesses de WPA

• Faiblesse à l’identification.
• Concerne les modes WPA et WPA2 avec PSK.
• La PMK dérivée de la PSK n’est jamais transmise.
• Par contre la PTK est utilisé pour un calcul de MIC.
• Rappel : PMK, adresses, valeurs aléatoires -> PTK.
• Il est possible de capturer l’échange en 4 étapes.
• Découverte des adresses, valeurs aléatoires et MIC.
• Attaque en force brute possible :
  • génération de PSK possibles ;
  • calcul de la PMK pour cette PSK ;
  • calcul de la PTK avec adresses et valeurs ;
  • calcul du MIC avec la KCK (début de la PTK) ;
  • comparaison avec le MIC des captures.
• Un GPU ira 10 fois plus vite qu’un CPU.

8.21  Chiffrement WiFi : faiblesses de WPA

• Faiblesse du chiffrement TKIP (2008,2009,2010).
• Introduction de la qualité de service en WPA.
• Plusieurs queues pour les paquets.
• Chaque queue a son compteur TSC.
• Généralement utilisation de la queue 0.
• Nature de l’attaque :
  • pas de compromission de la clef PSK ;
  • découverte d’un flux aléatoire ;
  • permet l’injection de paquets.
• Principe de l’attaque (variante de chopchop) :
  • récupération d’un paquet ARP ;
  • suppression d’un octet au paquet ;
  • test sur une queue avec un TSC inférieur ;
  • test avec les 256 possibilités ;
  • si mauvais choix, l’ICV et MIC sont incorrect ;
  • si bon choix, l’ICV est correct mais pas le MIC ;
  • si bon choix, un paquet d’avertissement est généré ;
  • si bon choix, paquet incorrect, TSC non incrémenté ;
  • si bon choix, attendre 60s et supprimer à nouveau ;
  • on trouve 12 octets du flux (en 12 minutes) ;
  • on trouve le reste en devinant le texte en clair ;
  • la clef de Mickael peut être trouvée par essais.
• Quelques injections possibles (ARP poisoning) ;
• Méthode applicable a DHCP.
• Méthode alternative à l’exploitation de la QoS :
  • relayer les paquets entre client et point d’accès ;
  • nécessite que le client soit écranté du point d’accès ;
  • supprimer des paquets vers le client ;
  • utiliser les lacunes pour faire les tests.
• Raffinement en 2010, en utilisant la fragmentation.
• Nouvelle attaque en 2014 (Royal Holloway attack) ?

8.22  Chiffrement WiFi : faiblesses de WPA2

• 2010 : Vulnérabilité Hole 196.
  • attaque par homme au milieu possible ;
  • par un utilisateur dûment identifié ;
  • utilise la clef de groupe (GTK).
• 2017 : KRACK.
  • technique rejouant le troisième paquet d’une identification WPA ;
  • technique pouvant conduire à l’utilisation d’une clef nulle ;
  • attaque par homme au milieu possible avec wpa_supplicant ;
  • ce n’est pas un problème de norme WPA2 mais d’implantation ;
  • faille considérée comme très limitée.
• 2020 : Krook.
  • faille dans les puces WiFi Broadcom ;
  • faille lors de la déconnexion WiFi :
    • la clef de chiffrement est mise à zéro (norme) ;
    • les paquets en file d’attente sont chiffrés avec cette clef.
  • quelques paquets peuvent être déchiffrés ;
  • la phrase de passe n’est pas mise en cause.

8.23  Chiffrement WiFi : faiblesses de WPA3

• 2019 : Dragonblood.
• 2021 : FragAttacks.

8.24  Chiffrement WiFi : CCMP

• WPA : WiFi Protected Access.
• CCMP : Counter Mode with CBC MAC Protocol :
  • CBC pour Cipher Block Chaining ;
  • MAC pour Message Authentication Code.
• CCMP utilise Advanced Encryption Standard (AES).
• RC4 permettait de chiffrer des flux ...
• AES chiffre des paquets de 128 octets.
• Détail du champ données :
  

  1 byte	1 byte	1 byte	5 bits	1 bit	2 bits
  PN0	PN1	Reserved	Reserved	Extended ?	Key Number

  
  

  1 byte	1 byte	1 byte	1 byte	0-2292 bytes	8 bytes	4 bytes
  PN2	PN3	PN4	PN5	Data	MIC	ICV

• Méthode non encore attaquée, sécurité assurée ...
• ... sauf PSK et utilisation de protocoles pour les nuls (WPS).

9  Services Internet principaux

9.1  Service de nommage DNS

• Préliminaires lors de la résolution :
  • appel à une fonction de bibliothèque ;
  • lecture du fichier /etc/resolv.conf ;
  • appel au DNS spécifié (e.g. ns.plil.fr).
• Une implémentation du DNS : bind9.
• Nom du démon fournissant le service : named.
• Fichier de configuration : /etc/bind/named.conf et ses sous-fichiers.
• Extraits pour ns.plil.fr :
  • éléments de sécurité système (named.conf.options) :

    controls {
      inet 127.0.0.1 allow {localhost;} keys {dnskey;} ;
    };
    
    key dnskey {
      algorithm HMAC-MD5;
      secret dfqsfFFcYyyyU999xcsdqs==;
    };
    

  • éléments de sécurité serveur DNS (named.conf.options) :

    options {
      ...
      allow-query { any; };
      allow-query-cache { trusted; };
      allow-recursion { trusted; };
      allow-transfer{ none; };
      version "mine";
      ...
    };
    
    acl "trusted" {
      172.26.0.0/16;
      2001:660:4401:6000::0/56;
      ...
    };
    

  • les serveurs racines sont référencés (named.conf.default-zones) :

    zone "." {
      type hint;
      file "root.cache";
      }; 
    

  • le DNS est maître pour certaines zones (named.conf.local) :

    zone "plil.info" {
      type primary;  // version politiquement correcte de master
      file "/etc/bind/zones/plil.info/plil-dir.zone";
    };
    
    zone "145.26.172.in-addr.arpa" {
      type primary;  // version politiquement correcte de master
      file "/etc/bind/zones/plil.info/plil-schoolrooms-rev-IPv4.zone";
    };
    
    zone "144-159.204.101.195.in-addr.arpa" {
      type primary;  // version politiquement correcte de master
      file "/etc/bind/zones/plil.fr/plil-fiber-rev-IPv4.zone";
    };
    
    zone "8.4.0.6.1.0.4.4.0.6.6.0.1.0.0.2.ip6.arpa" {
      type primary;  // version politiquement correcte de master
      file "/etc/bind/zones/plil.info/plil-schoolserv-rev-IPv6.zone";
    };
    

  • éléments de sécurité pour les zones primaires (named.conf.local) :

    zone "plil.info" {
      type primary;
      file "/etc/bind/zones/plil.info/plil-dir.zone";
    
      allow-transfer{secondaries;};  // filtrage des secondaires
      also-notify{hiddensecondaries;}; // pour les secondaires vicieux
      notify yes;    // notification des secondaires
    
      inline-signing yes;   // DNSSEC automatique
      key-directory "/etc/bind/keys"; // répertoire des clefs, attention aux droits
      dnssec-policy "dnssecpolicy";  // politique pour les clefs de chiffrement
    };
    
    dnssec-policy "dnssecpolicy" {
      keys {
        ksk key-directory lifetime unlimited algorithm 13;
        zsk key-directory lifetime unlimited algorithm 13;
      };
      nsec3param;
    };
    
    acl "secondaries" {
      195.220.223.1;   // il était une fois Poitiers
      ...
    };
    
    masters "hiddensecondaries" {
      217.70.177.40;   // ns6.gandi.net caméléon IPv4
      2001:4b98:d:1::40;   // ns6.gandi.net caméléon IPv6
    };
    

  • le DNS est secondaire pour d’autres zones (named.conf.local) :

    zone "rex.eudil.fr"{
      type secondary; // version politiquement correcte de slave
      file "/etc/bind/backup/rex.eudil.fr";
      primaries{ 2001:660:4401:60b0:216:3eff:feb0:b140; };
    };
    

• Exemples de fichiers de zone pour plil.fr.
  • Exemple de fichier d’adresses :

    $TTL 86400
    @       IN      SOA     ns.plil.fr. postmaster.plil.fr. (
               3608           ; Version
              21600           ; Refresh secondary    (6h)
               3600           ; Retry secondary      (1h)
            2592000           ; Expire if no refresh (30j)
              86400 )         ; Negative cache       (24h)
            IN      NS      ns.plil.fr.
            IN      NS      ns6.gandi.net.
    @       IN      MX      100 vervins.plil.fr.
    @       IN      TXT     "v=spf1 mx mx:polytech-lille.fr -all"
    
    ns         IN A 195.101.204.145
    fourmies   IN A 195.101.204.146
    vervins    IN A 195.101.204.147
    ns         IN AAAA 2a01:c916:2047:c800:0216:3eff:fe82:8a5c
    fourmies   IN AAAA 2a01:c916:2047:c800:0216:3Eff:fe52:8093
    vervins    IN AAAA 2a01:c916:2047:c800:0216:3Eff:fe52:8095
    imap       IN CNAME fourmies.plil.fr.
    mail       IN CNAME vervins.plil.fr.
    

  • Exemple de fichier de noms :

    $TTL 86400
    @       IN      SOA     ns.plil.fr. postmaster.plil.fr. (
               3608           ; Version
              21600           ; Refresh secondary    (6h)
               3600           ; Retry secondary      (1h)
            2592000           ; Expire if no refresh (30j)
              86400 )         ; Negative cache       (24h)
            IN      NS      ns.plil.fr.
            IN      NS      ns6.gandi.net.
    
    145     IN PTR ns.plil.fr.
    146     IN PTR fourmies.plil.fr.
    147     IN PTR vervins.plil.fr.
    

• Les serveurs racines.
  • Fichier root.cache disponible à :

    https://www.internic.net/domain/named.root
    

  • Le contenu au 5/10/2000 :

    .                   3600000 IN NS    A.ROOT-SERVERS.NET.
    A.ROOT-SERVERS.NET. 3600000    A     198.41.0.4
    .                   3600000    NS    B.ROOT-SERVERS.NET.
    B.ROOT-SERVERS.NET. 3600000    A     128.9.0.107
    ...
    

  • Le contenu au 17/01/2024 :

    .                        3600000      NS    A.ROOT-SERVERS.NET.
    A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
    A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
    .                        3600000      NS    B.ROOT-SERVERS.NET.
    B.ROOT-SERVERS.NET.      3600000      A     170.247.170.2
    B.ROOT-SERVERS.NET.      3600000      AAAA  2801:1b8:10::b
    ...
    

• Insertion dynamique d’enregistrements DNS.
  • Exemple de déclaration de zone pour ajout dynamique :

    zone "dynamic.eudil.fr" {
      type primary;
      file "dynamic/eudil.fr";
      allow-update { key dnskey; };
    };
    

  • Ajout dynamique et manuel d’entrée dans le DNS :

    # nsupdate
    > update add toto.dynamic.eudil.fr. 3600 IN A 193.48.64.221
    > 
    #
    

  • Ajout dynamique d’entrées dans le DNS par DHCP :

    ddns-update-style interim;
    key dnskey {
      algorithm HMAC-MD5;
      secret dfqsfFFcYyyyU999xcsdqs==;
      }
    
    zone dynamic.eudil.fr. {
      primary douaisis.escaut.net; // Il était une fois l'EUDIL
      key dnskey;
      }
    
    subnet 172.26.16.0 netmask 255.255.240.0 {
      option domain-name "students.deule.net ...";
      option subnet-mask 255.255.240.0;
      option broadcast-address 172.26.31.255;
      option static-routes ...
      option routers artegau.studserv.deule.net;
      range 172.26.17.0 172.26.28.255;
      ddns-domainname "eudil.fr";
      ddns-rev-domainname "dynamic.eudil.fr";
      ddns-ptr-domainname "dynamic.reverse.eudil.fr";
      }
    

9.2  Serveur de pages HTML

• Conforme au Hyper-Text Transfer Protocol.
• Nom du démon fournissant le service : apache2 ou nginx.
• Répertoire de configuration : /etc/apache2 ou /etc/nginx.
• Extraits pour plil.fr :
  • Restriction d’accès (e.g. dans des .htaccess) :

    # Simple identification par fichiers d'utilisateurs
    
    AuthType Basic
    AuthName "Squid statistics"
    AuthUserFile "/etc/passwd.web"
    AuthGroupFile "/etc/group.web"
    
    <Limit GET POST>
      require valid-user
    </Limit>
    
    # Identification par LDAP
    
    AuthType Basic
    AuthName "Site SE"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    AuthLDAPURL ldap://auth.plil.info:389/ou=People,dc=plil.fr?uid
    
    <Files "*">
      require valid-user
    </Files>
    

  • Ports TCP d’écoute :

    artois:/etc/apache2# cat ports.conf
    Listen 80
    <IfModule ssl_module>
     Listen 443
    </IfModule>
         \item Les modules activés (utilitaires {\tt a2enmod} ou {\tt a2dismod}) :
    \begin{verbatim}
    root@webhub:/etc/apache2/mods-enabled# ls -l ssl*
    lrwxrwxrwx 1 root root 26 oct.  11  2011 ssl.conf -> ../mods-available/ssl.conf
    lrwxrwxrwx 1 root root 26 oct.  11  2011 ssl.load -> ../mods-available/ssl.load
    root@webhub:/etc/apache2/mods-enabled# ls -l proxy*
    lrwxrwxrwx 1 root root 28 oct.   3  2015 proxy.conf -> ../mods-available/proxy.conf
    lrwxrwxrwx 1 root root 33 oct.   3  2015 proxy_http.load -> ../mods-available/proxy_http.load
    

  • Les serveurs virtuels activés (utilitaires a2ensite ou a2dissite) :

    root@webhub:/etc/apache2/sites-enabled# ls -l       
    lrwxrwxrwx 1 root root 28 avril 21  2023 auth.conf -> ../sites-available/auth.conf
    lrwxrwxrwx 1 root root 34 sept. 17  2018 cambraisis.conf -> ../sites-available/cambraisis.conf
    lrwxrwxrwx 1 root root 28 mars  11  2020 chat.conf -> ../sites-available/chat.conf
    lrwxrwxrwx 1 root root 32 sept. 17  2018 clubinfo.conf -> ../sites-available/clubinfo.conf
    lrwxrwxrwx 1 root root 27 nov.  22  2019 ctf.conf -> ../sites-available/ctf.conf
    lrwxrwxrwx 1 root root 27 nov.  20  2017 rex.conf -> ../sites-available/rex.conf
    lrwxrwxrwx 1 root root 33 sept. 17  2018 tvantroys.conf -> ../sites-available/tvantroys.conf
    lrwxrwxrwx 1 root root 33 juin  26  2023 wiki-PEIP.conf -> ../sites-available/wiki-PEIP.conf
    lrwxrwxrwx 1 root root 33 juin   7  2017 wiki-PLIL.conf -> ../sites-available/wiki-PLIL.conf
    lrwxrwxrwx 1 root root 31 févr.  5  2023 wiki-SE.conf -> ../sites-available/wiki-SE.conf
    ...
    

  • Configuration d’un serveur virtuel (HTTP obsolète) :

    root@webhub:/etc/apache2/sites-enabled# cat ninja.conf 
    <VirtualHost *:80>
      ServerName ninja.bzh
      ServerAlias www.ninja.bzh
      ServerAdmin Xavier.Redon@polytech-lille.fr
    
      ErrorLog /var/log/apache2/ninja-error.log
      LogLevel warn
      CustomLog /var/log/apache2/ninja-access.log combined
    
      Header set X-DS-Systeme "Question 3.2 : réponse 42"
      DocumentRoot /var/www/html/ninja
    </VirtualHost>
    

  • Configuration d’un serveur virtuel (HTTPS) :

    root@webhub:/etc/apache2/sites-enabled# cat ninja-ssl.conf 
    <VirtualHost *:443>
      ServerName ninja.bzh
      ServerAlias www.ninja.bzh
      ServerAdmin Xavier.Redon@polytech-lille.fr
    
      ErrorLog /var/log/apache2/ninja-error.log
      LogLevel warn
      CustomLog /var/log/apache2/ninja-access.log combined
    
      Header set X-DS-Systeme "Question 3.2 : réponse 42"
      DocumentRoot /var/www/html/ninja
    
      SSLEngine On
      SSLCertificateFile /etc/letsencrypt/live/ninja.bzh/fullchain.pem
      SSLCertificateKeyFile /etc/letsencrypt/live/ninja.bzh/privkey.pem
    </VirtualHost>
    

  • Configuration d’un serveur virtuel (HTTPS et mandataire inverse HTTP) :

    root@webhub:/etc/apache2/sites-enabled# cat rex.conf 
    <VirtualHost *:80>
      ServerName rex.plil.fr
      ServerAlias rex.plil.net
      Redirect permanent / https://rex.plil.fr/
    </VirtualHost>
    
    <VirtualHost *:443>
      ServerName rex.plil.fr
      ServerAdmin Xavier.Redon@polytech-lille.fr
    
      ErrorLog /var/log/apache2/rex-error.log
      LogLevel warn
      CustomLog /var/log/apache2/rex-access.log combined
    
      SSLEngine On
      SSLCertificateFile /etc/letsencrypt/live/rex.plil.fr/fullchain.pem
      SSLCertificateKeyFile /etc/letsencrypt/live/rex.plil.fr/privkey.pem
    
      ProxyRequests Off
      ProxyPreserveHost On
      ProxyPass / http://172.26.189.7/
      ProxyPassReverse / http://172.26.189.7/
    </VirtualHost>
    

  • Configuration d’un serveur virtuel (HTTPS et mandataire inverse HTTPS) :

    <VirtualHost *:443>
      ServerName rex.plil.fr
      ServerAdmin Xavier.Redon@polytech-lille.fr
    
      ErrorLog /var/log/apache2/rex-error.log
      LogLevel warn
      CustomLog /var/log/apache2/rex-access.log combined
    
      SSLProxyEngine On
      SSLCertificateFile /etc/letsencrypt/live/rex.plil.fr/fullchain.pem
      SSLCertificateKeyFile /etc/letsencrypt/live/rex.plil.fr/privkey.pem
    
      ProxyRequests Off
      ProxyPreserveHost On
      ProxyPass / https://www.rex.plil.fr/
      ProxyPassReverse / https://www.rex.plil.fr/
    </VirtualHost>
    

Ce document a été traduit de L^AT_EX par H^EV^EA