Dans ce labo, vous continuerez à appliquer les meilleures pratiques pour sécuriser un serveur web nginx sur serveurprof.com. Commencez par vous familiariser avec nginx en lisant ce court tutoriel.
Vous êtes prêts? Allons-y! Pour ce labo, vous n’aurez pas besoin de machine virtuelle. Le serveur nginx est déjà installé sur serveurprof.com et vous ferez toutes les manipulations directement sur le serveur. Vous pouvez ouvrir un terminal avec la combinaison des touches CTRL+ALT+T. Attention, il y aura des manipulations semblables à effectuer pour l’examen pratique de la semaine 14 et vous n'aurez pas droit à Internet. Notez toutes vos manipulations et commandes et faites la remise sur Moodle. Assurez-vous de bien comprendre ce que vous faites.
Connectez-vous maintenant en SSH à serveurprof.com avec vos identifiants.
Tip
Pour faciliter votre travail, gardez trois onglets SSH ouverts. Un premier pour le processus actif du serveur, un deuxième pour l'édition du fichier de config et finalement un troisième pour les commandes du terminal.
Voici aussi un rappel des commandes disponibles pour contrôler nginx dans le conteneur Podman :
| Commande | Usage |
|---|---|
| nginx_start -p <no de port> | Démarre ou redémarre le serveur nginx sur le port de votre choix. Utilisez le même port que dans votre configuration nginx, soit un port entre 1025 et 49151. Vous pouvez arrêter le serveur avec les touches CTRL+C. |
| nginx_reload | Recharge le serveur nginx après une modification de la configuration. |
Dans votre répertoire utilisateur, vous trouverez le fichiers
erreur.php et ref.php. Copiez ces deux
fichiers dans le répertoire public_html.
Si vous obtenez un message d’erreur
403 Forbidden lorsque vous ouvrez une
url, c’est que vous devez modifier les permissions du répertoire
public_html pour permettre la lecture et l’exécution du
répertoire et ses fichiers pour tout le monde.
Une bonne pratique en sécurité informatique consiste à conserver
la trace de tout ce qui se passe sur le serveur. Dans le cadre de ce
labo, nous voulons logger tous les accès au répertoire protégé
rapports (voir labo nginx 1) et logger les erreurs
partout sur le site.
Créez d'abord un répertoire log dans le répertoire
nginx. Modifier les droits d’accès du répertoire
log pour que tout le monde (autres) puisse écrire dans
le répertoire.
Modifiez ensuite votre configuration nginx pour que tous les
accès au répertoire rapports soient loggés dans un
fichier nommé access.log dans le répertoire
log.
Après avoir modifié la configuration, rechargez le serveur puis testez qu’une entrée de log est ajoutée pour chaque visite à la page suivante:
https://serveurprof.com:<no de port>/rapports/bilan.htmlVous n’avez pas besoin de créer le fichier de log, il sera créé automatiquement.
Modifiez maintenant la configuration nginx pour garder la trace
de toutes les erreurs dans le fichier error.log. Le
niveau de criticité doit être réglé à warn.
Ouvrez ensuite le fichier erreur.php dans votre
navigateur. Une erreur se produit. Vous devriez retrouver la trace
de l’erreur dans le fichier de log.
Allez ensuite corriger l’erreur directement dans le fichier PHP. Rechargez la page. Vous devriez maintenant voir une image de bébé avec un pouce en l’air.
Faites une saisie d’écran de l’écran au complet montrant le
navigateur et la photo. Nommez la photo etape1.jpg.
Téléversez la photo dans un nouveau répertoire nommé
screenshots sur le serveur à la racine de votre
répertoire utilisateur.
Dans le bas de la page erreur.php, vous trouverez un
lien nommé Continuez ici. Ce lien vous mène à la page
ref.php. Par défaut, lorsque vous naviguez d’une page à
une autre en utilisant des liens, le navigateur communique votre
provenance dans un en-tête nommé HTTP Referer.
Cela peut nuire à la vie privée de vos utilisateurs. Trouvez la bonne configuration nginx afin que le navigateur ne divulgue aucune information sur la provenance des requêtes.
Une fois la configuration modifiée et le serveur rechargé, vous
ne devriez plus partager l’information sur votre provenance lorsque
vous cliquez le lien dans le fichier erreur.php.
Warning
Vous aurez peut-être besoin de faire un rafraîchissement forcé de
la page erreur.php avec les touches
CTRL+MAJ+R pour que le référent ne s'affiche plus.
Il peut parfois être utile de limiter le nombre de requêtes par seconde qui peuvent être effectuées à partir d'une même adresse IP. Cela permet de protéger le serveur contre les abus et à améliorer la stabilité et la sécurité de l’application. Voici les raisons principales :
La directive suivante a été ajouté au fichier nginx principal du serveur (auquel vous n'avez pas accès) :
limit_req_zone $binary_remote_addr zone=per_ip_limit:10m rate=2r/s;Cette directive crée une zone partagée utilisée pour stocker les données de limitation de débit. Voici comment cela fonctionne:
$binary_remote_addr est la clé
utilisée pour identifier chaque client. Ici, on utilise l’adresse IP
du client, en format binaire (plus compact que la forme texte). Cela
permet de limiter individuellement chaque IP.per_ip_limit est le
nom donné à la zone, ce qui vous permettra de vous
y référer dans votre fichier nginx10m signifie que la zone utilise
10 Mo de mémoire partagée pour stocker les états
(suffisant pour environ 160 000 IP différentes).rate=2r/s fixe la limite à
2 requêtes par seconde par IP. Les requêtes au-delà
de cette limite peuvent être retardées ou rejetées selon la
configuration dans le bloc server ou location.Vous devez maintenant créer une règle dans votre configuration
nginx à l'aide de la directive limit_req afin
d'appliquer la directive nommée per_limit_ip pour tous
les urls dont le chemin d'accès commence par /api/.
Ajustez votre règle pour que le serveur autorise
temporairement jusqu’à 5 requêtes supplémentaires en
rafale, au-delà de la limite normale (rate), avant
de commencer à les refuser. Pour refuser les requêtes
au-delà de la limite permise, assurez-vous d'ajouter
nodelay à la fin de votre directive.
Pour tester votre configuration, vous pouvez utiliser le script à
la racine de votre répertoire utilisateur nommé
test_limit.sh. Ce script permet d'effectuer l'envoi de
requêtes en rafale vers une URL et d'obtenir le code de réponse pour
chaque requête. Lisez le code source du script pour vous
familiariser avec son fonctionnement.
Vous devez ensuite modifier les permissions du fichier pour que seul vous puissiez exécuter le script.
Bien! Maintenant créez un nouveau répertoire api
dans public_html. Ajoutez-y un fichier vide (avec la
commande touch) nommé test.html.
Assurez-vous de régler les permissions du répertoire et du fichier pour que tout le monde puisse les lire et les exécuter.
Une fois cela fait, vous pouvez tester que vous obtenez bien une page blanche (et non un message d'erreur) lorsque vous accédez à l'URL suivant:
https://serveurprof.com:<no de port>/api/test.htmlVous êtes maintenant prêt à exécuter le script
test_limit.sh avec votre URL.
Tip
Il faut préfixer l’exécution d’un script par ./ (par
exemple ./mon_script.sh) pour indiquer explicitement au
shell que le script se trouve dans le répertoire courant.
Quel est le résultat de l'exécution du script? Quels sont les en-têtes HTTP retournées? Cela confirme-t-il que votre règle fonctionne ?
Enlevez maintenant la règle nodelay de votre
directive et rechargez la configuration. Exécutez à nouveau le
script.
Cela change-t-il le résultat? Pourquoi?
Bravo! Vous avez terminé le labo!