Quais etapas devo tomar para proteger o Tomcat 6.x?

Estou no processo de configurar uma nova implantação do Tomcat e quero que ela seja o mais segura possível.

Eu criei um usuário 'jakarta' e tenho o jsvc executando o Tomcat como um daemon. Alguma dica sobre permissões de diretório e outras para limitar o acesso aos arquivos do Tomcat?

Sei que precisarei remover os aplicativos da web padrão - documentos, exemplos, etc ... existem práticas recomendadas que devo usar aqui? E todos os arquivos XML de configuração? Alguma dica aí?

Vale a pena ativar o gerenciador de segurança para que os webapps sejam executados em uma sandbox? Alguém já teve experiência em configurar isso?

Vi exemplos de pessoas executando duas instâncias do Tomcat atrás do Apache. Parece que isso pode ser feito usando mod_jk ou com mod_proxy ... algum prós / contras de qualquer um? Vale a pena o trabalho?

Caso isso importe, o sistema operacional é o Debian Lenny. Não estou usando o apt-get porque o lenny oferece apenas o tomcat 5.5 e precisamos do 6.x.

Obrigado!

Você pode instalar o Tomcat 6 para executar jsvccomo usuário tomcat (não como root ). Aqui está o que eu fiz da última vez que o configurei:

Instalei o aplicativo Tomcat em /usr/java/tomcat( CATALINA_HOME) e uma instância em /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 *

Então eu construí o 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/ 

Por fim, reforcei as permissões nos diretórios da instância:

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

Quando você executa o Tomcat agora, é necessário iniciá-lo jsvc, adicione este script como /etc/init.d/tomcate faça o link simbólico apropriado:

#!/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 $?

O Departamento de Defesa dos EUA tem um bom guia que combina as orientações de segurança do Tomcat em um Guia de Segurança do Servidor da Web (SRG) geral. Você pode encontrar mais guias de segurança aqui:

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

O Open Web Application Security Project ( OWASP ) oferece uma página wiki sobre a proteção do Tomcat , que você pode achar útil. No momento da redação deste artigo, ele parece mais focado no Tomcat 5.x, mas espero que seja atualizado com o passar do tempo.

Eu consideraria seriamente fazer o backport dos pacotes tomcat6 dos testes. Você pode se inscrever no pacote para receber notificações de novas versões sendo carregadas no arquivo morto. (Eu sou um pouco tendencioso, pois trabalhei na embalagem do debian).

Não tentei executar webapps sob um gerenciador de segurança, pois nenhum aplicativo vem com uma política e, francamente, é uma operação demorada criar você mesmo. Se você é paranóico, certamente pode fazê-lo. Envolve principalmente a execução do tomcat, a espera de alguma falha e a adição de uma exceção à política e a reinicialização do tomcat novamente. Enxágüe, repita, etc.

Obviamente, não execute o tomcat como root. O usuário do tomcat não deve poder gravar em nada fora do diretório de log ou do diretório de trabalho. Você deve se certificar de que seu diretório webapps contenha apenas os aplicativos web que deseja executar.

Eu sempre corro o tomcat atrás do apache. Isso ocorre em parte porque eu gostaria de pensar que mais pessoas usam apache, para que os erros sejam encontrados mais rapidamente. Esse é um pensamento bastante positivo e você não deve confiar nisso como uma melhoria de segurança. O que o Apache traz para você é a configurabilidade. Existem muitos módulos que o tomcat simplesmente não possui ou não pode fazer com a mesma eficiência. mod_cache, mod_ssl, mod_security tudo vem à mente. Você tem a opção de mod_jk, mod_proxy (e mod_proxy_http ou mod_proxy_ajp). mod_jk (e mod_proxy_ajp) usam o protocolo AJP binário em vez do protocolo http menos eficiente. Eu recomendo usar o mod_jk.

Não se esqueça de alterar a senha padrão da função de administrador no tomcat-users.xml É muito importante, caso contrário, uma pessoa mal-intencionada pode implantar aplicativos sem permissão restrita, como backdoor, no servidor tomcat e tentar fazer muitas coisas ruins.