Un guide pratique pour renforcer et sécuriser le serveur Apache Tomcat avec les meilleures pratiques.
Tomcat est l’un des serveurs de servlets et de conteneurs JSP les plus populaires. Il est utilisé par certains des sites web les plus fréquentés :
- LinkedIn.com
- Dailymail.co.uk
- Comcast.net
- Wallmart.com
- Reuters.com
- Meetup.com
- Webs.com
Le graphique ci-dessous montre la position de Tomcat sur le marché des serveurs d’application Java.
Techniquement, vous pouvez utiliser Tomcat comme serveur frontal pour répondre directement aux demandes de sites. Toutefois, dans un environnement de production, vous souhaiterez peut-être utiliser des serveurs web tels qu’Apache ou Nginx comme serveur frontal pour acheminer les requêtes vers Tomcat.
L’utilisation d’un serveur web pour traiter les requêtes offre des avantages en termes de performances et de sécurité. Si vous utilisez Apache HTTP comme serveur web frontal, vous devez également envisager de le sécuriser.
La configuration par défaut de Tomcat peut exposer des informations sensibles, ce qui aide les pirates à préparer une attaque contre l’application.
Les tests suivants ont été effectués sur Tomcat 7.x, dans un environnement UNIX.
Audience
Cette formation s’adresse aux administrateurs de middleware, au support applicatif, aux analystes système ou à toute personne travaillant ou désireuse d’apprendre le durcissement et la sécurité de Tomcat.
Une bonne connaissance de Tomcat et des commandes UNIX est obligatoire.
Remarques
Nous avons besoin d’un outil pour examiner les en-têtes HTTP à des fins de vérification. Vous pouvez le faire de deux manières.
Si vous testez une application orientée vers l’Internet, vous pouvez utiliser les outils suivants pour vérifier l’implémentation.
Et pour une application intranet, vous pouvez utiliser les outils de développement Google Chrome, Firefox.
En guise de bonne pratique, vous devez prendre une copie de sauvegarde de tout fichier que vous êtes sur le point de modifier.
Nous appellerons le dossier d’installation de Tomcat $tomcat tout au long de ce guide.
Passons maintenant aux procédures de durcissement et de sécurisation.
Suppression de la bannière du serveur
La suppression de la bannière du serveur de l’en-tête HTTP est l’une des premières choses à faire dans le cadre du durcissement.
La présence d’une bannière de serveur expose le produit et la version que vous utilisez et conduit à une vulnérabilité de fuite d’information.
Par défaut, une page servie par Tomcat s’affiche comme ceci.
Masquons les détails du produit et de la version dans l’en-tête du serveur.
- Allez dans le dossier $tomcat/conf
- Modifiez server.xml en utilisant vi
- Ajoutez ce qui suit au
port du connecteur
Server =” “Ex : –
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
Server =" "
redirectPort="8443" />- Enregistrez le fichier et redémarrez Tomcat. Désormais, lorsque vous accédez à une application, vous devriez voir une valeur vide pour l’en-tête Server.
Démarrer Tomcat avec un gestionnaire de sécurité
Le gestionnaire de sécurité vous protège contre l’exécution d’un applet non fiable dans votre navigateur.
Il est préférable d’utiliser Tomcat avec un gestionnaire de sécurité plutôt que sans. Tomcat dispose d’une excellente documentation sur Tomcat Security Manager.
Ce qui est bien, c’est que vous n’avez pas besoin de modifier un fichier de configuration. C’est juste la façon dont vous exécutez le fichier startup.sh.
Tout ce que vous avez à faire est de démarrer Tomcat avec l’argument -security .
[root@geekflare bin]# ./startup.sh -security
Utilisation de CATALINA_BASE : /opt/tomcat
Utilisation de CATALINA_HOME : /opt/tomcat
Utilisation de CATALINA_TMPDIR : /opt/tomcat/temp
Utilisation de JRE_HOME : /usr
Utilisation de CLASSPATH : /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar
Utilisation du gestionnaire de sécurité
Tomcat a démarré.
[root@geekflare bin]#Activer SSL/TLS
Servir les requêtes web via HTTPS est essentiel pour protéger les données entre le client et Tomcat. Afin de rendre votre application web accessible via HTTPS, vous devez mettre en place un certificat SSL.
En supposant que vous ayez déjà préparé le keystore avec le certificat, vous pouvez ajouter la ligne ci-dessous dans le fichier server.xml dans la section Connector port.
SSLEnabled="true" scheme="https" keystoreFile="ssl/bloggerflare.jks" keystorePass="chandan" clientAuth="false" sslProtocol="TLS"Remplacez le nom du fichier Keystore et le mot de passe par les vôtres.
Si vous avez besoin d’aide avec le keystore et le processus CSR, reportez-vous à ce guide.
Appliquer HTTPS
Cette option ne s’applique que si vous avez activé le protocole SSL. Si ce n’est pas le cas, l’application ne fonctionnera pas.
Une fois que vous avez activé SSL, il serait bon de forcer la redirection de toutes les requêtes HTTP vers HTTPS pour sécuriser la communication entre l’utilisateur et le serveur d’application Tomcat.
- Allez dans le dossier $tomcat/conf
- Modifiez
web.xmlen utilisantvi - Ajoutez ce qui suit avant la syntaxe
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>- Enregistrez le fichier et redémarrez Tomcat
Il est possible de voler ou de manipuler la session et les cookies d’une application web sans disposer d’un cookie sécurisé. C’est un drapeau qui est injecté dans l’en-tête de la réponse.
Pour ce faire, ajoutez la ligne suivante dans la section session-config du fichier web.xml
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>Capture d’écran de la configuration :
Enregistrez le fichier et redémarrez Tomcat pour examiner l’en-tête de réponse HTTP.
Exécutez Tomcat à partir d’un compte non privilégié
Il est conseillé d’utiliser un utilisateur non privilégié distinct pour Tomcat. L’idée est ici de protéger les autres services en cours d’exécution au cas où l’un des comptes serait compromis.
- Créez un utilisateur UNIX, disons tomcat
useradd tomcat- Arrêtez Tomcat s’il est en cours d’exécution
- Changez la propriété de $tomcat en faveur de l’utilisateur tomcat
chown -R tomcat:tomcat tomcat/Démarrez Tomcat et assurez-vous qu’il fonctionne avec l’utilisateur tomcat
Supprimez les applications par défaut ou indésirables
Par défaut, Tomcat est livré avec les applications web suivantes, qui peuvent ou non être nécessaires dans un environnement de production.
Vous pouvez les supprimer pour rester propre et éviter tout risque de sécurité connu avec l’application par défaut de Tomcat.
- ROOT – Page d’accueil par défaut
- Docs – Documentation de Tomcat
- Exemples – JSP et servlets pour la démonstration
- Manager, host-manager – Administration de Tomcat
Ils sont disponibles dans le dossier $tomcat/webapps
[root@geekflare webapps]# ls -lt
drwxr-xr-x 14 tomcat tomcat 4096 Sep 29 15:26 docs
drwxr-xr-x 7 tomcat tomcat 4096 Sep 29 15:26 examples
drwxr-xr-x 5 tomcat tomcat 4096 Sep 29 15:26 host-manager
drwxr-xr-x 5 tomcat tomcat 4096 Sep 29 15:26 manager
drwxr-xr-x 3 tomcat tomcat 4096 Sep 29 15:26 ROOT
[root@geekflare webapps]#Modifier le port et la commande SHUTDOWN
Par défaut, tomcat est configuré pour être arrêté sur le port 8005.
Savez-vous que vous pouvez arrêter l’instance de tomcat en faisant un telnet à IP : port et en émettant la commande SHUTDOWN ?
Chandans # telnet localhost 8005
Trying ::1... telnet :
connect to address ::1 :
Connexion refusée Essai 127.0.0.1...
Connexion à localhost.
Le caractère d'échappement est '^]'.
SHUTDOWN Connexion fermée par un hôte étranger.
Chandans #Dangereux !
Vous voyez, avoir une configuration par défaut conduit à un risque de sécurité élevé.
Il est recommandé de changer le port d’arrêt de tomcat et la commande par défaut pour quelque chose d’imprévisible.
- Modifiez ce qui suit dans server.xml
<Server port="8005" shutdown="SHUTDOWN">8005 – Remplacer par un autre port inutilisé
SHUTDOWN – Changez pour quelque chose de compliqué
Ex-
<Server port="8867" shutdown="NOTGONNAGUESS">Remplacer la page par défaut 404, 403, 500
Le fait d’avoir une page par défaut pour les erreurs de type “not found”, “forbidden” ou “server” expose les détails de la version.
Examinons la page 404 par défaut.
Pour l’atténuer, vous pouvez d’abord créer une page d’erreur générale et configurer web.xml pour rediriger vers une page d’erreur générale.
- Allez dans $tomcat/webapps/$application
- Créez un fichier error.jsp à l’aide de l’éditeur
vi
<html>
<head>
<title>Error Page</title>
</head>
<body> That's an error! </body>
</html>- Allez dans le dossier $tomcat/conf
- Ajoutez ce qui suit dans le fichier web.xml. Assurez-vous d’ajouter avant la syntaxe
<error-page>
<error-code>404</error-code>
<location>/error.jsp</location>
</error-page>
<error-page>
<error-code>403</error-code>
<location>/error.jsp</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/error.jsp</location>
</error-page>- Redémarrez le serveur Tomcat pour le tester
Encore mieux !
Vous pouvez également faire cela pour java.lang.Exception. Cela vous aidera à ne pas exposer les informations relatives à la version de Tomcat en cas d’exception java lang.
Ajoutez simplement ce qui suit dans le fichier web.xml et redémarrez le serveur Tomcat.
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>J’espère que le guide ci-dessus vous donne une idée de la sécurisation de Tomcat. Si vous souhaitez en savoir plus sur l’administration de Tomcat, consultez ce cours en ligne.