Apps – Tomcat – erwan.guillemard

C’est marrant, je veux parler d’une techno et voilà que je me retrouve à implémenter une serveur Tomcat. Je me dis « Nan mais ça va passer je vais pas faire un article… » Hé ba force est de constater que si, j’ai fait un article.

Mais alors pourquoi faire un article sur Tomcat ?

Parce que premièrement cela aurait rendu l’article indigeste déjà qu’en temps normal ce n’est pas ouf et que deuxièmement en creusant un peu le sujet cela ne se résume pas à juste un dnf install tomcat…

Bref, ce billet sera technique car j’ai hâte de revenir à mon article initial. Mais cela vaut le coup car j’ai appris encore énormément de chose 🙂

Tommy the Cat is my name and I say unto thee

Avant-Propos

L’étude de Tomcat vient simplement de l’implémentation d’un billet qui sera publié prochainement qui nécessite la présence d’un serveur d’applet Java. Je garde volontairement une part de mystère, sinon ce n’est pas marrant non ? 🙂

De mon passé, d’étudiant, j’ai appris la POO¹ lors de mes études en BTS² d’info industrielle sur C++. J’avoue que je n’ai pas bien saisie la pratique… C’est lors de ma licence en sécu logicielle que j’ai unlock et appliqué tous les pratiques de la POO sur le langage JAVA.

Cool ta life mon gars, ça aurait mérité un post Facebook en 2012 avec en premier commentaire « Ba moi hier j’ai mangé une pomme »

Ouai peut-être mais cela a été pour moi une révélation. J’ai trouvé ce langage magnifique et je pensais avoir trouvé ma voie. Et pourtant JAVA est loin d’être un langage des plus fiable et ergonomique. Des IDEs³ NetBeans, Eclipse, Android Studio sans oublier le serveur d’applet web GlassFish je trouvais ça top. Et puis je me suis rendu compte que les applets c’étaient lourds, les applications Java difficilement ergonomique, des failles de sécurités qui doivent être patché avec des updates de la JDK⁴ côté développeur de la JVM⁵, JRE⁶ côté client, le code qui ne devient plus compatible…

Voilà, les raisons de pourquoi j’ai délaissé mon amour de JAVA par dépit à la suite de ces frustrations. L’une des autres raisons et la difficulté de jongler entre la sécurité des versions clients et les progicielles. Accepter de mettre à jour et ne plus travailler car au lancement de l’application ou de fonctionnalité ça crash ou retourne des erreurs de stack traces dans tous les sens ou accepter d’avoir des failles de sécurité partout et pouvoir travailler ?

Bref, encore une fois, un article pour installer un service au premier abord simple mais qui nécessite d’être bien sécurisé.

Prérequis

SE :
- Rocky Linux 9.4 et versions ultérieures
Apps :
- Tomcat 10.1.54
Autres :
- Hardenned Linux

Théorie

Un peu d’histoire

Il était une fois, un meunier ne laissa pour tous biens, à trois enfants qu’il avait, que son moulin, son âne et son chat...

Bien joué Charles 😉 Je ne vais pas vous compter le conte du Chat Botté de Perrault mais bien celle de Tomcat, je vous rassure, mais la tentation était trop grande <3

Ce qu’il est important de retenir, c’est que ce dernier reste un projet OpenSource maintenu par une communauté très active. Tomcat reste également un serveur d’application léger très populaire et de base (et c’est pourquoi il est fortement lié à JAVA) la référence de l’implémentation JAVA.

Structure

Il est important comme pour toutes applications de savoir comment cette dernière est structurée et comment elle fonctionne.

Ainsi, nous pouvons différencier 9 répertoires distincts au sein du daemon Tomcat :

bin : L’ensemble des scripts et exécutables propre au daemon pour démarrer ou arrêter le serveur.
common : Nous pourrions dire que ce répertoire contient le code (classes et méthodes) commun utilisé par le service Catalina et certaines applications web.
conf : Le répertoire qui stocke les fichiers de configuration du server.
lib : Répertoire qui stocke l’ensembles des bibliothèques (les .jar)
logs : Dossier qui va stocker l’ensemble des journaux d’événement. Attention à ce que ce dernier ne prenne pas trop de place sinon BOUM plus de service. Le mieux serait de le déplacer sur un disque dédié.
server : Code contenant les méthodes et classes systèmes utilisés uniquement de Catalina.
shared : Les classes partagées utilisées par toutes les applications
webapps : Répertoire qui va contenir les applications web (le fichier .war)
work : Répertoire qui va contenir les répertoires et fichiers temporaires (le cache)

Chacun des répertoires joue un rôle clé et donc selon le contexte doit être sécurisé.

Fonctionnement

Le fonctionnement de Tomcat peut paraitre complexe au premier abord. Toutefois avec un bon schéma, cela devient aussi divin que les croquettes Ultima Saumon pour chat stérilisé (« Sale Histoire » que mon avocat garde sous silence en reprenant la citation d’un membre de la famille).

L’utilisateur exécute une requête HTTP⁸, cette même requête se présente au connecteur sur le port 8080. Le connecteur va alors transformer la requête en objets JAVA, deux pour être précis :

Les données entrantes : HttpServletRequest
Les données sortantes : HttpServletResponse

Les données sortantes sont vides et seront complétées à la fin du traitement de la requête d’entrée.

Les données d’entrées sont soumises au moteur de décision de son petit nom Catalina. Il va analyser l’en-tête de la requête (header) pour orienter cette dernière vers le bon host virtuel.

Un peu comme la tour de contrôle, nous pouvons voir ce dernier comme un aiguillage. Ainsi, si nous avions plusieurs domaines, le host va identifier le bon domaine et aiguiller le flux vers l’application, le context.

C’est l’application web spécifique (le .war) qui va alors traiter la demande. Nous pouvons donc avoir une multitude d’application sur le même serveur.

Le wrapper va appeler notre servlet correspondant. Tomcat charge alors la classe JAVA, l’instancie et appelle la méthode Service(), doGet() ou doPost().

Le code va alors s’exécuter et retourner la réponse dans l’objet en attente, HttpServletResponse dissocier de la requête à l’étape 1.

Tomcat récupère l’objet réponse et va alors transformer cette dernière en flux de données HTTP (texte, HTLM, JSON) et renvoyer par le biais du connecteur la réponse au navigateur du client.

/!\ Attention : Cette architecture reste valable, mais Tomcat 10 a migré vers Jakarta EE en rendant incompatible les applications basées sur javax.servlet. Donc si usage des Servlets c’est Tomcat 9…

Pour faire simple, si lors du lancement de votre application ne se lance pas et que dans les logs localhost ou catalina vient fleurir l’erreur ClassNotFoundException: javax.servlet, et bien c’est que vous l’avez dans l’OS bien profond et que vous êtes marron… Votre application n’est pas compatible Tomcat 10. Vous êtes bon pour un downgrade <3 Ca fait du bien de temps en temps de se prendre un bon coup de nerf de bœuf sur l’arrière train, ça fait circuler le sang !

Cette structure modulaire d’encapsulation, permet de garantir une certaine souplesse sans avoir à changer la logique des applications.

Je pense qu’il n’y a pas besoin d’en savoir plus pour installer le service sur notre serveur. Passe à la pratique.

Pratique

J’ai pris le parti de sortir pour une nouvelle fois des sentiers battu et de ne pas me limiter à l’installation de Tomcat depuis le repo source. J’ai choisi de déployer ce dernier depuis le site officiel.

Ce choix est motivé par les versions spécifiques nécessaire à certaines applications. De ce fait, l’installation depuis le repo n’est pas d’une grande utilité. Et une nouvelle fois de par mon expérience, il est plus probable de passer par le site officiel.

Dépendances

En termes de dépendance, ce n’est pas bien compliqué, il nous faut la JDK pour faire tourner notre serveur Tomcat. Donc ?

On installe la JDK 🙂

#Install Java
$ sudo dnf install java-21-openjdk-headless

Je passe encore et toujours mon tour sur cette étape qui devient un incontournable des billets que je rédige sous GNU/Linux.

Installation

Bien. Maintenant que notre dépendance est installée, commençons par le début.

Créons notre groupe tomcat et notre utilisateur de service tomcat. Pour répondre au bonne pratique, un service = un compte applicatif. Cela permet de faciliter le debug et surtout en termes de sécurité c’est bien mieux que de tout faire tourner avec le compte root.

$ sudo groupadd tomcat
$ sudo useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat

Naturellement, l’utilisateur tomcat est membre du groupe tomcat…

L’installation se fait de deux manières. Soit par la commande curl qui est nativement présente sur notre SE⁹. Soit par wget qui devra être installé. Il conviendra d’adapter l’URL¹⁰ selon la version recherchée. J’ai décidé de télécharger le .tar.gz directement dans le répertoire /tmp.

Créons-le répertoire /opt/tomcat puis décompressons notre archive stocké sous /tmp dans le répertoire fraichement créé.

$ curl -L --output-dir /tmp -O  https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.54/bin/apache-tomcat-10.1.54.tar.gz
$ mkdir /opt/tomcat
$ tar -xf /tmp/apache-tomcat-10.1.54.tar.gz -C /opt/tomcat --strip-components=1

Bon, si on regarde du côté de l’ANSSI¹¹, ces derniers nous recommandent que notre compte de service tomcat ne doit pas propriétaire des binaires (exécutables). Pourquoi ? Admettons qu’il y est compromission, le compte ne sera pas en possibilité de s’altérer lui-même. Ainsi, nous pouvons voir une sorte de silotage.

$ sudo chgrp -R tomcat /opt/tomcat
$ sudo chmod -R g+r /opt/tomcat/conf
$ sudo chmod g+x /opt/tomcat/conf
$ sudo chown -R tomcat /opt/tomcat/{webapps,work,temp,logs}

Le groupe utilisateur tomcat a donc les droits de lecture et d’exécution sur l’ensemble des sous éléments du répertoire /opt/tomcat. L’utilisateur tomcat sera propriétaire uniquement des sous répertoires et leurs contenus :

webapps : Répertoire qui va contenir les applications web (le fichier .war)
work : Répertoire qui va contenir les répertoires et fichiers temporaires (le cache) persistant. C’est à dire utiliser par les servlets.
temp : Le répertoire va stocker les fichiers à déplacer. Il joue le rôle de passe plat. Les fichiers qui viendraient à persister sont automatiquement supprimés à chaque redémarrage du service.
logs : Les journaux d’événements, il faut bien que le service puisse écrire ce qui se passe non ?

Sécurité

Niveau sécurité, les actions vont se concentrer et se définir dans le fichier server.xml ainsi que dans le fichier web.xml.

L’objectif sera de se prémunir des attaques classiques MIM¹², Clickjacking, XSS¹³ et de masquer l’identité de notre serveur le plus possible. Parce qu’on ne dévoile pas tout le premier soir 😉

Audit et divulgation d’identité

Commençons par éditer le fichier server.xml.

$ sudo vim /opt/tomcat/conf/server.xml

Un truc qui pourrait être tout bête, appliquons le principe :

Vivons heureux, Vivons cachés !

C’est à dire outre mon langage (car peu parle le Erwan première langue), masquons la version de notre serveur tomcat dans les trames d’entêtes (le header…) HTTP. Ainsi il est possible de savoir que je suis un serveur tomcat, mais de connaitre ma version. 🙂

Malinx le Lynx. D’un autre côté c’est Tomcat… Voilà voilà, il est content de sa vanne…

Dans le connecteur HTTP, ajouter server= » «

Tiens, tu ajoutes un secure= »true ». C’est cool, du coup tu forces les connexions chiffrées ? 🙂 Et bien pas du tout ! Je me suis fait k*n aussi. Je suis allé regarder la documentation pour mieux comprendre. Par défaut, secure est à false. Nos applications par le biais de notre server peuvent refuser de délivrer les cookies sensibles ou vouloir rediriger les utilisateurs vers le protocole HTTPS¹⁴. Dans le meilleur des cas ça créé des lenteurs au pire c’est l’infinity loop… Alors que si nous le forçons à true, Tomcat va confirmer auprès de l’application que la requête vient d’un canal sécurisé (ce qui n’est pas le cas. Où le vilain menteur !) même s’il vient d’un canal non sécurisé.

De toute façon, nous allons passer par un reverse proxy nginx et en frontal nous aurons une publication avec une règle de proxy.

Toutefois cela ne suffit pas. Quand est-il des pages d’erreurs ? En creusant un peu il va falloir fermer les valves… 🙂

L’objectif est de supprimer la mention « Apache Tomcat/<version> » dans les pages d’erreurs ainsi que la description des erreurs (la stacktrace. Que de nostalgie…). L’objectif est de donner le moins d’information possible à un potentiel attaquant qui souhaiterai exploiter une CVE¹⁵ en relation avec la version de notre produit. L’objectif est de rendre aveugle l’attaquant le temps que les mécanismes en place ce déclenche ou nous alertes.

Niveau Audit, nous pouvons également renforcer la verbosité si nous suivons les recommandations de l’ANSSI.

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b %D &quot;%{User-Agent}i&quot;" />

%h : l’adresse IP distante
%l : Identifiant logique
%u : Utilisateur authentifié
%t : horodatage
%r : Ligne de requête (la méthode et l’URL appelé)
%s : Code de retour du protocole HTTP
%b : Taille de la réponse en octet
%D : Le temps de traitement en ms
%i : Le User-Agent pour repérer les outils automatisés (nmap et autres) et surtout les navigateurs « chelou » comme diraient mes enfants…

Par exemple :

/!\ Attention : L’activation de l’audit n’est pas anodine en termes d’espace. Il faut penser à mettre en place une rotation des logs. Sinon… BOUM !!!

Toutes les applications par défaut, ça dégage ! Pourquoi garder les éléments de bases qui sont d’autant plus des vecteurs d’attaque et des points de vulnérabilité ?

$ sudo rm -Rf /opt/tomcat/webapps/*

Un truc que je ne connaissais pas et que j’ai trouvé en étudiant Tomcat, c’est le cas de « Protection du Shutdown ». Au premier abord, je me suis demandé qu’est-ce que c’est que ce truc. Le paramètre shutdown est explicite. Et bien voyez-vous c’est marrant, c’est une commande qui permet d’éteindre le daemon. Alors certes, par défaut il est sur le port 8005/tcp et normalement accessible qu’en local. Mais tapons shutdown et pouf ! Notre daemon il va à la niche.

Donc, on change le port et pour le mot de passe on utilise le bon vieux Soleil123! . Vous m’avez compris non ? 🙂

<Server port="-1" shutdown="y2Fxg@kLx4:If2L0_MD1Ccz">

Prévention des attaques

Ouvrons le fichier web.xml.

$ sudo vim /opt/tomcat/conf/web.xml

A la fin de la section <filter>, ajoutons les lignes suivantes :

<!-- Begin R-ONE Modification -->
        <filter>
                <filter-name>httpHeaderSecurity</filter-name>
                <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
                <async-supported>true</async-supported>

                <init-param>
                        <param-name>hstsMaxAgeSeconds</param-name>
                        <param-value>31536000</param-value>
                </init-param>

                <init-param>
                        <param-name>antiClickJackingOption</param-name>
                        <param-value>DENY</param-value>
                </init-param>

                <init-param>
                        <param-name>blockContentTypeSniffingEnabled</param-name>
                        <param-value>true</param-value>
                </init-param>
        </filter>
<!-- End Modification -->

Parcourons en détails chaque ligne pour comprendre ce que nous sécurisons avec les filtres. (Normal c’est du café de Java… Franchement, il ne mérite pas d’aller jouer sur l’autoroute à contre sens pour bien voir le danger ? L’auteur de ce billet est bof, il fait triste à voir.)

<!-- Modification R-ONE -->
        <filter-mapping>
                <filter-name>httpHeaderSecurity</filter-name>
                <url-pattern>/*</url-pattern>
        </filter-mapping>
<!-- End Modification -->

Un truc c*n qui m’a fait perdre une nuit de sommeil. J’avais cette put**n d’erreur… A devenir fou !

Après pas mal de recherche, c’est un truc simple. Franchement je suis vraiment un c*n… Mon nouveau fichier de conf, avait pour owner root:root et non tomcat:tomcat. La haine, vraiment. Pensez donc à bien set de nouveau les bons droits…

$ sudo chown tomcat:tomcat -R /opt/tomcat/conf/

Un petit test avant, après ?

Daemon Firewall

Côté firewall il faut publier le port 8080/tcp

$ sudo firewall-cmd --permanent --add-port=8080/tcp
$ sudo firewall-cmd --reload

Toutefois ça ne fonctionnera pas NANANANERE ! Et pourquoi ? Hein, pourquoi ? A cause du SELinux ventrebleu !

Par défaut le port 8080 n’est pas autorisé dans le SELinux pour la communication HTTP. Il est donc nécessaire de lui dire qu’il en fait partie.

$ sudo semanage port -a -t http_port_t -p tcp 8080

Configuration

Logrotate

Créons et éditons le fichier de rotation propre à tomcat sous /etc/logrotate.d.

$ sudo vim /etc/logrotate.d/tomcat

Nous allons spécifier dans notre fichier que nous souhaitons effectuer la rotation du fichier catalina.out, les fichiers localhost_access_log*.txt ainsi que l’ensemble des fichiers d’extensions .log.

C’est dernier afin de ne pas impacter la production seront vidé à chaud (copytruncate) de manière journalière en gardant 30 jours de rétention (histoire de faciliter les investigations en cas de suspicion). Nous compresserons les points de rétentions si pas de fichier nous ne faisons rien ni si les fichiers sont vides. Nous recréerons les fichiers avec les droits 0640 avec en groupe et propriétaire le compte de service tomcat.

/opt/tomcat/logs/catalina.out
/opt/tomcat/logs/localhost_access_log*.txt
/opt/tomcat/logs/*.log {
    copytruncate
    daily
    rotate 30
    compress
    missingok
    notifempty
    create 0640 tomcat tomcat
}

Une commande que je ne connaissais pas. C’est en me replongeant dans la documentation de logrotate que j’ai découvert qu’il existait un mode debug qui vient simuler notre fichier de rotation. C’est vraiment cool.

$ sudo logrotate -d /etc/logrotate.d/tomcat

Bon ba fonctionne pas. Que pasa ? Ca ne serait pas encore un coup du SELinux ? Mais si, Mais si j’ai cru voir un SELinux !

$ ls -Zd /opt/tomcat/logs
$ sudo semanage fcontext -a -t var_log_t "/opt/tomcat/logs(/.*)?"
$ sudo restorecon -Rv /opt/tomcat/logs

Après vérification du contexte de sécurité, il s’avère que logrotate est bloqué par le SELinux lorsqu’il essai d’écrire dans le répertoire /opt/tomcat/logs. Il convient donc alors d’ajouter le contexte et de restaurer le contexte de sécurité sur le répertoire /opt/tomcat/logs. 🙂

Tu vois Monsieur CHAPPINION, je ne laisse pas la sécurité au hasard et des backdoors partout comme tu aimes le crier haut et fort en te pavanant. Continu de cracher ton VENIN avec ta clic… #bisous #gratuit #faitdubien 🙂

Services

Comme j’ai choisi l’installation depuis le package et non depuis le repo, il faut se farcir à la main le fichier de service. Cela dit, c’est plutôt intéressant de se pencher sur le cas. Encore une fois et c’est mon point de vue, c’est agréable de savoir cuisiner que d’acheter des produits transformés tous les jours.

$ sudo vim /etc/systemd/system/tomcat.service

[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking

User=tomcat
Group=tomcat

Environment="JAVA_HOME=/usr/lib/jvm/jre"
Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid"
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/opt/tomcat"

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

# Sécurité Systemd (Sandboxing)
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Normalement maintenant c’est le moment de vérité… Démarrons notre service. Si tout va bien, pas d’erreur. Sinon c’est parti pour du début et avec Java ça peut vite devenir pénible et encore le paroxysme est loin. Mais je ne veux pas vous décourager…

$ sudo systemctl start tomcat
$ sudo systemctl status tomcat

Si c’est ok, le service peut être actif au démarrage du système. Ce dernier se lancera après le service réseau (cf la conf du service).

$ systemctl enable tomcat

Test

Pour vérifier que tout est fonctionnel, il est nécessaire comme nous avons supprimé l’intégralité du contenu de notre répertoire /webapps/ de générer un fichier de test :

$ sudo mkdir /opt/tomcat/webapps/ROOT
$ sudo echo "OK FINAL ROOT" > /opt/tomcat/webapps/ROOT/index.html
$ chown tomcat:tomcat -R /opt/tomcat/webapps/ROOT
$ sudo systemctl restart tomcat

Maintenant depuis un navigateur web, sous réserve d’avoir créé la règle sur votre UTM¹⁶ si vous n’êtes pas dans le même subnet rendez-vous sur l’URL http://<SERVER>:8080 ou depuis directement depuis votre server curl http://127.0.0.1:8080 vous devriez avoir en retour :

Je pense que nous avons clôt ce billet. Nous voilà avec un server Tomcat sécurisé et fonctionnel… 🙂

Conclusion

Je me suis arraché les cheveux sur ce billet.

Ecoute ma bonne Catalina, tu un engine modèle, mais si tu n’as que des qualités et en termes de verbosité tu es resté comme je l’espérai, c’est le bonheur rangé dans une armoire. Tu vois si c’était à refaire, je t’installerai de nouveau mais tu m’emmerdes !
Erwan Guillemard, revisite d’Un singe en hiver d’Henri VERNEUIL

Mais alors pourquoi je tiens ces propos ? Je me suis une nouvelle fois aventuré dans la stacktrace et dans les logs à la suite d’un 404 Not Found. D’erreur dans le fichier de configuration car sensible à la case sur UN caractère. L’absence de log par moment… Tout ce que j’aime avec JAVA, ou du moins j’aimais… Imaginons maintenant une montée de version ? J’espère que votre formulaire de CAB¹⁷ est à jour et que vous avez un environnement de production iso à votre production.

Enfin passons, si j’ai fait un billet sur Tomcat, c’est que je vais surtout en avoir besoin dans l’article prochain et qu’il était vraiment important d’étudier en profondeur ce produit de la gamme Apache. Il faut reconnaitre tout de même qu’en terme de serveur web il y a bien pire 🙂

Rien que les notions de sécurité, nous revenons une nouvelle fois autour des mêmes notions conceptuelles, moindre privilège, réduction de la surface d’attaque, audit, chiffrement et isolation. Ces points sont primordiaux pour Tomcat.

Pourquoi me direz-vous ? Parce que nous publions un service Web qui exécute du code JAVA qui si mal isolé, croyez-moi peut faire énormément de dégât dans un système d’information. Il serait bien de porter si vous utiliser ce dernier renforcer la vigilance sur ce dernier avec votre SIEM¹⁸ (c’est marrant, je n’en ai pas 🙂 )…

Le mot de la fin :

Le chat botté chevauche Tomcat pendant que Charles Perrault configure du HSTS dans une cafetière. Arabica mon chers Watson, je danse la JAVA de Broadway. A non, il y a Catalina en travers sur une requête HTTP, le firewall vous fait chapeau bas !
Erwan GUILLEMARD

Sources

POO : Programmation Orientée Objet ↩︎
BTS : Brevet de Technicien Supérieur ↩︎
IDE : Integrated Environment Development ↩︎
JDK : JAVA Development Tools ↩︎
JVM : JAVA Virtual Machine ↩︎
JRE : JAVA Runtime Environment ↩︎
JSP : JAVA Server Pages ↩︎
HTTP : HyperText Transfert Protocol ↩︎
SE : Système d’Exploitation ↩︎
URL : Uniform Resource Locator ↩︎
ANSSI : Agence National de Sécurité des Systèmes d’Information ↩︎
MIM : Man In the Middle ↩︎
XSS : Cross Site Scripting ↩︎
HTTPS : Secure HyperText Transfert Protocol ↩︎
CVE : Common Vulnerabilities and Exposures ↩︎
UTM : Unified Threat Management ↩︎
CAB : Change Advisory Board ↩︎
SIEM : Security Information and Event Management ↩︎

Avant	Après

Avant	Après

Remote	Local