Quelles mesures dois-je prendre pour sécuriser Tomcat 6.x?

Je suis en train de configurer un nouveau déploiement Tomcat et je souhaite qu'il soit aussi sécurisé que possible.

J'ai créé un utilisateur «jakarta» et ai jsvc exécutant Tomcat en tant que démon. Des conseils sur les autorisations de répertoire et autres pour limiter l'accès aux fichiers de Tomcat?

Je sais que je devrai supprimer les applications Web par défaut - documents, exemples, etc ... y a-t-il des meilleures pratiques que je devrais utiliser ici? Qu'en est-il de tous les fichiers XML de configuration? Des conseils là-bas?

Vaut-il la peine d'activer le gestionnaire de sécurité pour que les applications Web s'exécutent dans un bac à sable? Quelqu'un a-t-il eu l'expérience de la mise en place de cela?

J'ai vu des exemples de personnes exécutant deux instances de Tomcat derrière Apache. Il semble que cela puisse être fait en utilisant mod_jk ou avec mod_proxy ... des avantages / inconvénients de l'un ou l'autre? Vaut-il la peine?

Au cas où cela importerait, le système d'exploitation est Debian Lenny. Je n'utilise pas apt-get car lenny ne propose que tomcat 5.5 et nous avons besoin de 6.x.

Merci!

Vous pouvez installer Tomcat 6 pour exécuter sous en jsvctant qu'utilisateur tomcat (pas en tant que root ). Voici ce que j'ai fait la dernière fois que je l'ai configuré:

J'ai installé l'application Tomcat sous /usr/java/tomcat( CATALINA_HOME) et une instance sous /var/lib/tomcat( CATALINA_BASE):

cd /usr/java
sudo tar xzvf ~/downloads/apache-tomcat-6.0.18.tar.gz
sudo ln -s apache-tomcat-6.0.18 tomcat
sudo /usr/sbin/useradd -d /var/lib/tomcat -c "Apache Tomcat" -m -s /sbin/nologin tomcat
cd /var/lib/tomcat
sudo mkdir logs work temp
sudo chown tomcat:tomcat logs temp work
(cd /usr/java/tomcat && sudo tar cvf - conf webapps) | sudo tar xvf -
sudo chmod -R g+rw webapps conf
sudo chown -R tomcat:tomcat webapps conf
cd webapps/
sudo rm -rf docs examples manager host-manager
cd ../conf
sudo chmod g+r *

Ensuite, j'ai construit le jsvcwrapper:

cd
tar xzvf downloads/apache-tomcat-6.0.18.tar.gz
tar xzvf apache-tomcat-6.0.18/bin/jsvc.tar.gz
cd jsvc-src
chmod +x configure
./configure --with-java=$JAVA_HOME
make
./jsvc --help
sudo cp jsvc /usr/local/sbin/ 

Enfin, j'ai resserré les autorisations sur les répertoires d'instance:

cd /var/lib/tomcat
sudo chmod -R 0700 conf
sudo chmod -R 0750 logs
sudo chmod -R 0700 temp
sudo chmod -R 0700 work
sudo chmod -R 0770 webapps/
sudo chown -R tomcat:tomcat conf
sudo chown -R tomcat:tomcat logs

Lorsque vous exécutez Tomcat maintenant, vous devez le démarrer à l'aide de jsvc, alors ajoutez ce script en tant que /etc/init.d/tomcatet créez un lien symbolique approprié:

#!/bin/sh
#
# tomcat       Startup script for the Apache Tomcat Server running under jsvc
#
# chkconfig: 345 85 15
# description: Apache Tomcat
# pidfile: /var/run/jsvc.pid

JAVA_HOME=/usr/java/jdk1.6.0_13
CATALINA_HOME=/usr/java/apache-tomcat-6.0.18
CATALINA_BASE=/var/lib/tomcat
JAVA_OPTS="-Djava.awt.headless=true"
JMX_OPTS="-Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

DAEMON_APP=/usr/local/sbin/jsvc
TOMCAT_USER=tomcat

# Everything below should be okay
PID_FILE=/var/run/jsvc.pid
LOCK_FILE=/var/lock/tomcat

PATH=/sbin:/bin:/usr/bin
. /lib/init/vars.sh

. /lib/lsb/init-functions

[ -x $JAVA_HOME/bin/java ] || exit 0
[ -x $DAEMON_APP ] || exit 0
[ -d $CATALINA_HOME/bin ] || exit 0
[ -d $CATALINA_BASE ] || exit 0

RETVAL=0
prog="jsvc"

CLASSPATH=\
$JAVA_HOME/lib/tools.jar:\
$CATALINA_HOME/bin/commons-daemon.jar:\
$CATALINA_HOME/bin/bootstrap.jar

start() {
  # Start Tomcat
  log_daemon_msg "Starting Apache Tomcat"
  $DAEMON_APP \
    -user $TOMCAT_USER \
    -home $JAVA_HOME \
    -wait 10 \
    -pidfile $PID_FILE \
    -outfile $CATALINA_BASE/logs/catalina.out \
    -errfile $CATALINA_BASE/logs/catalina.out \
    $JAVA_OPTS $JMX_OPTS \
    -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
    -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \
    -Dcatalina.home=$CATALINA_HOME \
    -Dcatalina.base=$CATALINA_BASE \
    -Djava.io.tmpdir=$CATALINA_BASE/temp \
    -cp $CLASSPATH \
    org.apache.catalina.startup.Bootstrap start 2>/dev/null 1>&2
  RETVAL=$?
  if [ 0 -eq $RETVAL ]; then
    touch $LOCK_FILE
    log_end_msg 0
  else
    log_end_msg 1
  fi
}

stop() {
  # Stop tomcat
  log_daemon_msg "Stopping Apache Tomcat"
  $DAEMON_APP \
    -stop \
    -pidfile $PID_FILE \
    org.apache.catalina.startup.Bootstrap 2>/dev/null 1>&2
  RETVAL=$?
  if [ 0 -eq $RETVAL ]; then
    rm -rf $LOCK_FILE
    log_end_msg 0
  else
    log_end_msg 1
  fi
}

restart() {
  stop
  sleep 5
  start
}

# See how we were called.
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status $prog
    ;;
  condrestart)
    [ -f $LOCK_FILE ] && restart || :
    ;;
  *)
    log_action_msg "Usage: $0 {start|stop|restart|status|condrestart}"
    exit 1
esac

exit $?

Le département américain de la Défense a un bon guide qui a combiné les conseils de sécurité de Tomcat en un guide de sécurité du serveur Web (SRG) global. Vous pouvez trouver plus de guides de sécurité ici:

http://iase.disa.mil/stigs/srgs/Pages/index.aspx

L'Open Web Application Security Project ( OWASP ) propose une page wiki sur la sécurisation de Tomcat , que vous pourriez trouver utile. Au moment d'écrire ces lignes, il semble plus axé sur Tomcat 5.x, mais nous espérons qu'il sera mis à jour au fil du temps.

J'envisagerais sérieusement de rétroporter les packages tomcat6 des tests. Vous pouvez vous abonner au package pour recevoir des notifications de nouvelles versions téléchargées dans l'archive. (Je suis légèrement biaisé car j'ai travaillé sur le paquet Debian).

Je n'ai pas essayé d'exécuter des applications Web sous un gestionnaire de sécurité, car aucune application n'est livrée avec une politique et c'est franchement une opération longue de créer vous-même. Si vous êtes paranoïaque, vous pouvez certainement le faire. Cela implique principalement d'exécuter tomcat, d'attendre que quelque chose se passe, puis d'ajouter une exception à la stratégie et de redémarrer tomcat à nouveau. Rincer, répéter, etc.

Évidemment, ne lancez pas tomcat en tant que root. L'utilisateur tomcat ne doit pas pouvoir écrire sur quoi que ce soit en dehors du répertoire des journaux ou du répertoire de travail. Vous devez vous assurer que votre répertoire webapps ne contient que les webapps que vous souhaitez exécuter.

Je cours toujours tomcat derrière apache. C'est en partie parce que j'aimerais penser que plus de gens utilisent Apache, donc les bugs seraient trouvés plus rapidement. C'est à peu près un vœu pieux et vous ne devriez pas compter sur le fait qu'il s'agit d'une amélioration de la sécurité. Ce que vous apporte Apache, c'est la configurabilité. Il y a beaucoup de modules que tomcat n'a tout simplement pas, ou ne peut pas faire aussi efficacement. mod_cache, mod_ssl, mod_security me viennent à l'esprit. Vous avez le choix entre mod_jk, mod_proxy (et soit mod_proxy_http ou mod_proxy_ajp). mod_jk (et mod_proxy_ajp) utilisent le protocole AJP binaire plutôt que le protocole http moins efficace. Je recommanderais d'utiliser mod_jk.

N'oubliez pas de changer le mot de passe par défaut du rôle d'administrateur dans tomcat-users.xml.C'est très important, sinon une personne malveillante peut déployer des applications sans autorisation restreinte comme une porte dérobée sur le serveur tomcat et essayer de faire beaucoup de mauvaises choses.