tuto3: text done
This commit is contained in:
parent
959aa8a4a8
commit
8007b0d85a
|
|
@ -0,0 +1 @@
|
|||
tutorial.pdf
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
SOURCES = tutorial.md what.md netfilter.md wks.md rendu.md
|
||||
PANDOCOPTS = --latex-engine=xelatex \
|
||||
--standalone \
|
||||
--normalize \
|
||||
--number-sections \
|
||||
--smart \
|
||||
-M lang=fr-FR \
|
||||
-M fontsize=12pt \
|
||||
-M papersize=a4paper \
|
||||
-M mainfont="Linux Libertine O" \
|
||||
-M monofont="FantasqueSansMono-Regular" \
|
||||
-M sansfont="Linux Biolinum O" \
|
||||
--include-in-header=../header.tex
|
||||
|
||||
|
||||
all: tutorial.pdf
|
||||
|
||||
tutorial.pdf: ${SOURCES}
|
||||
pandoc ${PANDOCOPTS} -o $@ $+
|
||||
|
||||
clean::
|
||||
rm tutorial.pdf
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
\newpage
|
||||
|
||||
Netfilter
|
||||
=========
|
||||
|
||||
Le projet `netfilter`[^netfilter] est l'implémentation de pare-feu au sein du
|
||||
noyau Linux. Il s'agit d'un mécanisme de filtrage des paquets réseau basés sur
|
||||
des règles, chargées par l'espace utilisateur dans le noyau. On utilise pour
|
||||
cela les programmes `nft` (du projet `nftables`), ou de manière historique
|
||||
`iptables`.
|
||||
|
||||
[^netfilter]: <https://netfilter.org/>
|
||||
|
||||
Les deux projets ont une manière de fonctionner très similaire, mais il est
|
||||
important de ne pas les utiliser en même temps, sous peine de voir apparaître
|
||||
des problèmes incompréhensible à déboguer, plus ou moins aléatoirement.
|
||||
|
||||
|
||||
Réseau fonctionnel ?
|
||||
--------------------
|
||||
|
||||
Première étape : avez-vous vérifié l'état du réseau sur le routeur ?
|
||||
|
||||
* Peut-il accéder à Internet ?
|
||||
* Peut-il accéder aux serveurs ?
|
||||
* Peut-il accéder aux stations de travail ?
|
||||
|
||||
Dans la configuration initiale attendue de la machine virtuelle, les réponses
|
||||
que vous devriez obtenir sont :
|
||||
|
||||
* Oui, le routeur a accès à Internet, mais ne peut pas résoudre de noms de
|
||||
domaine.
|
||||
* Oui, les serveurs répondent aux ping et sont joignables.
|
||||
* Non, les stations de travail n'obtiennent pas d'IP, on ne peut pas les
|
||||
contacter.
|
||||
|
||||
|
||||
Donner accès à Internet
|
||||
-----------------------
|
||||
|
||||
Votre administrateur système vous assure que le serveur de noms est bien lancé
|
||||
et configuré comme demandé.
|
||||
|
||||
Deux éléments de configuration vont devoir être mis en place sur le routeur
|
||||
pour corriger[^fix] cette situation.
|
||||
|
||||
[^fix]: Oui, il s'agit bien ici de non configuration : ne cherchez pas de
|
||||
mesquinerie de la part de l'auteur du TP.
|
||||
|
||||
Après cette configuration, toutes les machines (serveurs et stations de
|
||||
travail) pourront accéder à Internet.
|
||||
|
||||
Test à passer :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
router$ dig +short @172.23.42.2 adlin.nemunai.re
|
||||
82.64.31.248
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
Exposer un service web sur Internet
|
||||
-----------------------------------
|
||||
|
||||
Vous avez compris comment vos machines peuvent accéder à Internet sans avoir
|
||||
pour autant d'IP routable sur Internet. Cependant, si cela répond parfaitement
|
||||
à une utilisation de type station de travail, vos serveurs web doivent être
|
||||
accessibles sur Internet.
|
||||
|
||||
En utilisant une règle de `netfilter`, rendez vos deux serveurs web accessibles
|
||||
depuis l'interface externe du routeur. Après configuration, depuis un
|
||||
navigateur sur votre poste, vous devriez pouvoir accéder à :
|
||||
|
||||
<div lang="en-US">
|
||||
* `http://$EXT_ROUTER_IP:8080/` : TinyTinyRSS
|
||||
* `http://$EXT_ROUTER_IP:8081/` : Mattermost
|
||||
</div>
|
||||
|
||||
|
||||
Deux services sur un port ?
|
||||
---------------------------
|
||||
|
||||
Sur Internet, rare sont les IP qui n'hébergent qu'un seul service. Très
|
||||
souvent, une armée de serveur est placée derrière, comme ici, et permet de
|
||||
distribuer plusieurs services sur la même IP, sans que les utilisateurs n'aient
|
||||
à changer leur port de connexion.
|
||||
|
||||
La distinction est généralement réalisée sur le nom de domaine
|
||||
accédé. Cependant, les protocoles IP, TCP ou UDP ne transportent pas cette
|
||||
information. C'est donc dans la couche applicative que le nom de domaine est
|
||||
passé.
|
||||
|
||||
Par exemple, vous pouvez observer ce comportement facilement avec `curl` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ dig +short adlin.nemunai.re
|
||||
82.64.31.248
|
||||
42sh$ curl https://adlin.nemunai.re
|
||||
<head><title>Index of /</title></head>
|
||||
|
||||
42sh$ curl -k https://82.64.31.248
|
||||
<img style="height: calc(100vh - 5px); max-width: 100vw;" src="//rhakotis.masr.nemunai.re/public/vache.svg" alt="Bienvenue sur rhakotis">
|
||||
|
||||
42sh$ curl -k -H "Host: adlin.nemunai.re" https://82.64.31.248
|
||||
<head><title>Index of /</title></head>
|
||||
```
|
||||
</div>
|
||||
|
||||
En HTTP[^https], on face un en-tête `Host`, contenant le nom de domaine. Le
|
||||
serveur web (généralement ici utilisé comme proxy inverse) oriente la
|
||||
distribution de son contenu en fonction de cet en-tête.
|
||||
|
||||
[^https]: En HTTPS, le certificat est distribué avant que le client n'ait pu
|
||||
envoyé de contenu. Le nom est alors passé dans un champ d'extension de
|
||||
TLS. Voir le [RFC 6066](https://tools.ietf.org/html/rfc6066) à propos de
|
||||
SNI.
|
||||
|
||||
À vous maintenant d'installer un reverse-proxy (`nginx` par exemple), pour vous
|
||||
permettre d'accéder aux deux services, sur le port 80.
|
||||
|
||||
En utilisant le résolveur local, vous pouvez vérifier le fonctionnement de
|
||||
votre reverse-proxy avec (soit sur une station de travail, soit sur le routeur
|
||||
directement) :
|
||||
|
||||
<div lang="en-US">
|
||||
```sh
|
||||
42sh$ curl http://news.adlin.nemunai.re/
|
||||
<title>Tiny Tiny RSS : Login</title>
|
||||
|
||||
42sh$ curl http://im.adlin.nemunai.re/
|
||||
<title>Mattermost</title>
|
||||
```
|
||||
</div>
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
\newpage
|
||||
|
||||
Rendu
|
||||
=====
|
||||
|
||||
## Modalité de rendu
|
||||
|
||||
Un service automatique s'occupe de réceptionner vos rendus, de faire des
|
||||
vérifications élémentaires et de vous envoyer un accusé de réception (ou de
|
||||
rejet).
|
||||
|
||||
Ce service écoute sur l'adresse <adlin@nemunai.re>, c'est donc à cette adresse
|
||||
et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
|
||||
envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
|
||||
sera pas pris en compte.
|
||||
|
||||
|
||||
## Tarball
|
||||
|
||||
Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
|
||||
placer dans une tarball (pas d'archive ZIP, RAR, ...).
|
||||
|
||||
Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires,
|
||||
en fonction de votre organisation ou de vos choix) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP3/router.yml
|
||||
...
|
||||
```
|
||||
</div>
|
||||
|
||||
Le seul fichier devant impérativement se trouver à la racine de votre tarball
|
||||
est `router.yml`. Le reste de l'arborescence est laissé à votre discrétion du
|
||||
moment que vous n'oubliez pas de fichiers.
|
||||
|
||||
|
||||
## Signature du rendu
|
||||
|
||||
Deux méthodes sont utilisables pour signer votre rendu :
|
||||
|
||||
* signature du courriel ;
|
||||
* signature de la tarball.
|
||||
|
||||
Dans les deux cas, si vous n'en avez pas déjà une, vous devrez créer une clef
|
||||
PGP à **votre nom et prénom**.
|
||||
|
||||
Pour valider la signature, il est nécessaire d'avoir reçu la clef publique
|
||||
**séparément**. Vous avez le choix de la téléverser sur un serveur de clefs,
|
||||
soit de me fournir votre clef en main propre, soit de l'envoyer dans un
|
||||
courriel **distinct**.
|
||||
|
||||
### Signature du courriel
|
||||
|
||||
[Enigmail](https://enigmail.net) est une extension très bien réputée pour
|
||||
signer ses courriels depuis Thunderbird.
|
||||
|
||||
Utilisez le service automatique <signcheck@nemunai.re> pour savoir si votre
|
||||
message est correctement signé et que je suis en mesure de vérifier la
|
||||
signature.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 102 KiB |
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
title: Administration Linux avancée -- TP n^o^ 3
|
||||
subtitle:
|
||||
author: Pierre-Olivier *Nemunaire* Mercier
|
||||
institute: EPITA
|
||||
date: Lundi 19 mars 2018
|
||||
...
|
||||
|
||||
Durant ce troisième TP, nous allons faire un peu de réseau !
|
||||
|
||||
Tous les éléments de ce TP (exercices et projet) sont à rendre à
|
||||
<adlin@nemunai.re> au plus tard le samedi 31 mars 2018 à 23 h 42. Consultez
|
||||
la dernière section de chaque partie pour plus d'information sur les éléments à
|
||||
rendre.
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96) faire
|
||||
signer votre clef et n'hésitez pas à
|
||||
[faire signer votre clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
|
||||
\hypersetup{linkcolor=black}
|
||||
\tableofcontents
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
\newpage
|
||||
|
||||
Démarrer sur le SI du jour
|
||||
==========================
|
||||
|
||||
Présentation du système d'information
|
||||
-------------------------------------
|
||||
|
||||
Le système d'information que vous allez avoir à gérer aujourd'hui est
|
||||
de taille moyenne : vous aurez en votre possession un résolveur DNS, un serveur
|
||||
de base de données ainsi que deux serveurs web (servant respectivement
|
||||
TinyTinyRSS que vous connaissez, ainsi que Mattermost, une plate-forme de chat,
|
||||
alternative libre de Slack).
|
||||
|
||||
Vous êtes l'administrateur réseau de l'entreprise et l'on vous demande de
|
||||
connecter tous ces services **correctement**.
|
||||
|
||||
L'image ISO que vous avez récupérée met à votre disposition tout ce système
|
||||
d'information, déjà configuré pour sa partie logicielle, il ne reste plus qu'à
|
||||
éditer la configuration du routeur.
|
||||
|
||||
|
||||
|
||||
Attention, contrairement au précédent TP, tout se fait en direct, il n'y a
|
||||
aucune sauvegarde effectuée : à chaque redémarrage de la machine virtuelle,
|
||||
vous retomberez dans l'état initial.
|
||||
|
||||
Accéder à la machine virtuelle
|
||||
------------------------------
|
||||
|
||||
Une fois la machine virtuelle démarrée, vous devriez voir apparaître l'IP qu'à
|
||||
obtenue la machine sur votre réseau :
|
||||
|
||||
```
|
||||
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
|
||||
link/ether 42:2c:63:f1:5a:49 brd ff:ff:ff:ff:ff:ff
|
||||
inet 10.42.23.211/24 brd 10.42.23.255 scope global eth0
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::4534:6558:22cf:f2cd/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
nsenter: cannot open /run/netns/wks1: No such file or directory
|
||||
```
|
||||
|
||||
Cette IP est l'IP externe de votre routeur, qu'il a obtenu par DHCP.
|
||||
|
||||
Une ligne de commande est disponible au sein de la machine virtuelle à des fins
|
||||
de débogage, si nécessaire. Vous ne devriez normalement pas avoir à interagir
|
||||
avec celle-ci.
|
||||
|
||||
Si vous assignez deux cartes réseau à la machine virtuelle, vous devriez voir
|
||||
apparaître l'IP de la carte `eth1` en dessous. Il s'agit d'une interface de
|
||||
station de travail.
|
||||
|
||||
|
||||
Objectif du TP
|
||||
--------------
|
||||
|
||||
Toutes les IP notées sur le schéma ont déjà été configurées par votre
|
||||
administrateur système en suivant vos instructions. Votre tâche est de rendre
|
||||
accessible les services web sur internet ainsi qu'aux stations de
|
||||
travails. Tout le monde doit avoir accès à internet et utiliser le serveur de
|
||||
noms local (les serveurs ayant déjà été configurés ainsi, il faudra simplement
|
||||
s'assurer que ce soit également le cas des stations de travail).
|
||||
|
||||
Étant donné le caractère éphémère de vos actions, la réalisation d'un
|
||||
*Playbook* Ansible semble plutôt adapté !
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
\newpage
|
||||
|
||||
Stations de travail
|
||||
===================
|
||||
|
||||
DHCP
|
||||
----
|
||||
|
||||
N'ayant pas, pour le moment, d'IPv6 sur votre réseau ; vous devez mettre en
|
||||
place un serveur DHCP sur votre réseau afin que vos collaborateurs puissent
|
||||
utiliser facilement le réseau.
|
||||
|
||||
Configurez un serveur DHCP, tel quel `isc-dhcp-server` ou `udhcpd` afin de
|
||||
distribuer des IP correspondant au plan d'adressage. N'oubliez pas de définir
|
||||
le chemin permettant de sortir sur Internet ainsi que d'utiliser le résolveur
|
||||
de noms de domaine local.
|
||||
|
||||
Une fois configuré, vous pouvez tenter de vous connecter aux services web (vous
|
||||
devriez avoir `wget` sur la station de travail accessible).
|
||||
|
||||
|
||||
Zone démilitarisée et filtrage
|
||||
------------------------------
|
||||
|
||||
Il est risqué d'exposer des ports d'administration sur Internet ou de permettre
|
||||
à des zones sensibles d'être accédées par rebond. Définissez quelques règles de
|
||||
filtrage sur le routeur afin notamment :
|
||||
|
||||
* d'empêcher les connexions au serveur de base de données, seule les connexions
|
||||
réalisées depuis le réseau des serveurs resteront disponibles ;
|
||||
* de n'exposer le port SSH que depuis le réseau interne (pas depuis l'interface
|
||||
connectée à Internet).
|
||||
Reference in New Issue