Guide de durcissement et de sécurité d'Apache Tomcat

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 du site. 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 demandes vers Tomcat.

L'utilisation d'un serveur web pour traiter les demandes donne performance et sécurité avantages. Si vous utilisez Apache HTTP comme serveur web frontal, vous devez prendre en compte les éléments suivants sécuriser cela aussi.

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 est destinée 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.

Bonne connaissance de Tomcat & Commande UNIX est obligatoire.

Notes

Nous avons besoin d'un outil pour examiner les en-têtes HTTP à des fins de vérification. Il y a deux façons de procéder.

Si les tests Face à l'internet vous pouvez utiliser les outils d'en-tête HTTP suivants pour vérifier la mise en œuvre.

Et pour un Application intranetVous pouvez utiliser les outils de développement de Google Chrome et de Firefox.

En guise de bonne pratique, vous devez prendre une sauvegarde de tout fichier que vous vous apprêtez à modifier.

Nous appellerons le dossier d'installation de Tomcat $tomcat tout au long de ces lignes directrices.

Passons en revue les procédures de durcissement et de sécurisation.

Supprimer la bannière du serveur

La suppression de la bannière du serveur dans l'en-tête HTTP est l'une des premières choses à faire pour renforcer la sécurité.

La présence d'une bannière de serveur expose le produit et la version que vous utilisez et entraîne une fuite d'informations.

Par défaut, une page servie par Tomcat s'affiche comme suit.

Masquons les détails du produit et de la version dans l'en-tête du serveur.

Aller dans le dossier $tomcat/conf
Modifier server.xml en utilisant vi
Ajouter ce qui suit à Connector port

Server =” “

Ex : -

<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" 
Server =" "
redirectPort="8443" />

Enregistrez le fichier et redémarrez Tomcat. Maintenant, 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 Gestionnaire de sécurité Tomcat.

Ce qui est bien, c'est que vous n'avez pas besoin de changer de fichier de configuration. C'est juste la façon dont vous exécutez startup.sh fichier.

Tout ce que vous avez à faire est de démarrer tomcat avec –security argument.

[root@geekflare bin]# ./startup.sh -security
Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME: /usr
Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar
Using Security Manager
Tomcat started.
[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. Pour que votre application web soit 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 suivante dans le fichier server.xml sous Connector port section.

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 pour le processus de création du keystore et de la CSR, reportez-vous au document suivant ce guide.

Appliquer HTTPS

Ceci n'est applicable que si le SSL est activé. 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.

Aller dans le dossier $tomcat/conf
Modifier web.xml en utilisant vi
Ajouter ce qui suit avant </web-app> 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>

Enregistrer le fichier et redémarrer 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é. Il s'agit d'un indicateur injecté dans l'en-tête de la réponse.

Pour ce faire, il suffit d'ajouter sous la ligne 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écuter 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éer un utilisateur UNIX, disons tomcat

useradd tomcat

Arrêter Tomcat s'il est en cours d'exécution
Changer la propriété de $tomcat pour l'utilisateur tomcat

chown -R tomcat:tomcat tomcat/

Démarrer Tomcat et s'assurer qu'il fonctionne avec l'utilisateur tomcat

Supprimer les applications par défaut/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 garder le site 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 sur Tomcat
Exemples - JSP et servlets pour démonstration
Manager, host-manager - Administration de Tomcat

Elles 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 fermé sur le port 8005.

Savez-vous que vous pouvez arrêter l'instance de Tomcat en effectuant un telnet sur IP : port et en émettant la commande SHUTDOWN ?

Chandans # telnet localhost 8005
Trying ::1... telnet:
connect to address ::1:
Connection refused Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SHUTDOWN Connection closed by foreign host.
Chandans #

Dangereux !

Vous voyez, une configuration par défaut entraîne 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.

Modifier le fichier server.xml comme suit

<Server port="8005" shutdown="SHUTDOWN">

8005 - Changement vers un autre port non utilisé

SHUTDOWN - Passer à quelque chose de compliqué

Ex-

<Server port="8867" shutdown="NOTGONNAGUESS">

Remplacer les pages 404, 403 et 500 par défaut

L'existence d'une page par défaut pour les erreurs de type "non trouvé", "interdit" ou "serveur" permet d'exposer les détails de la version.

Examinons la page 404 par défaut.

Pour y remédier, vous pouvez d'abord créer une page d'erreur générale et configurer web.xml pour qu'il redirige vers une page d'erreur générale.

Allez dans $tomcat/webapps/$application
Créez un fichier error.jsp en utilisant vi éditeur

<html>
<head> 
<title>Page d'erreur</title>
</head>
<body> C'est une erreur ! </body>
</html>

Aller dans le dossier $tomcat/conf
Ajoutez ce qui suit dans le fichier web.xml. Assurez-vous d'ajouter avant </web-app> syntaxe

404
/error.jsp


403
/error.jsp


500
/error.jsp

Redémarrer le serveur tomcat pour le tester

C'est beaucoup mieux !

Vous pouvez le faire pour java.lang.Exception également. Cela permettra de ne pas exposer les informations relatives à la version de tomcat en cas d'exception java lang.

Il suffit d'ajouter ce qui suit web.xml et redémarrer le serveur Tomcat.

java.lang.Exception
/error.jsp

J'espère que le guide ci-dessus vous donnera une idée de la sécurisation de Tomcat. Si vous souhaitez en savoir plus sur l'administration de Tomcat, vous pouvez consulter le site suivant cours en ligne.
Apprenez également à configurer WAS pour qu'il ne demande plus de mot de passe lors de l'arrêt du système ici.