Suite à une mise à jour du serveur, je me suis aperçu que le serveur Tomcat n’était plus lancé.

La commande ps faux me confirmera qu’il ne se trouvait plus dans la liste des processus.

C’est finalement dans le fichier de log /var/log/syslog que se trouve le message d’erreur à propos du chargement de Tomcat :

jsvc.exec[5678]: java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.apache.catalina.startup.Bootstrap.clinit(Bootstrap.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:139)

Une rapide recherche sur le net me conduira à nouveau vers le système de bugtracking de debian toujours aussi réactif !
Référence du ticket sur le système de bugtracking de debian : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477363

Les informations importantes

Version de tomcat concernée: 5.5.26-1
Debian : Lenny
Package : tomcat5.5

Cause

jsvc ne trouve pas la librairie java commons-logging. (commons-logging-api-1.1.1.jar)

Solution

Ajouter le chemin de la librairie commons-logging dans le CLASSPATH de jsvc dans le script de démarrage de tomcat5 : /etc/init.d/tomcat5.5

Ce qui donne après modification la ligne suivante :

JSVC_CLASSPATH="/usr/share/java/commons-daemon.jar:
$CATALINA_HOME/bin/bootstrap.jar:
$CATALINA_HOME/bin/commons-logging-api.jar"

Merci à Michael Riedel pour ce correctif.
La prochaine version de Tomcat devrait prendre en compte cette modification. Vive la communauté Debian ^^

Fail2ban est un outil qui permet d’être alerté et de se protéger des attaques de types bruteforce. Ce programme analyse les logs du système à la recherche d’expressions qui indiqueraient une tentative d’attaque par dictionnaire.

Si un type d’expression prédéfini est trouvé une action est lancée. L’adresse IP source de l’attaque est bloquée par une règle iptables. Un mail peut être envoyé à l’administrateur avec des informations supplémentaires sur l’origine de la menace.

Installation

Très simplement comme toujours

apt-get install fail2ban

ou

aptitude install fail2ban

Configuration

La configuration par défaut est située dans le fichier /etc/fail2ban/jail.conf. Il n’est cependant pas recommandé de modifier ce fichier directement. Copier ce fichier et renommer le jail.local :

cp -a /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Les options principales sont les suivantes :

• ignoreip : ne pas tenir compte des adresses IP définis par cette option
• bantime : temps de bannissement en seconde
• maxretry : nombre de tentatives autorisées avec bannissement

Un exemple de fichier de configuration Fail2ban

Les services

Par défaut seule la protection de ssh est activée. Mais il est possible de surveiller bien d’autres services. Voici par exemple les sections pour postfix et courrier :

[postfix]
enabled  = true
port = smtp,ssmtp
filter = postfix
logpath = /var/log/mail.log

[courierauth]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = courierlogin
logpath = /var/log/mail.log

Conclusion

Sa simplicité d’utilisation et sa flexibilité font de Fail2ban une application indispensable pour se prémunir des attaques par bruteforce.
Voici un exemple de mail envoyé suite à une détection d’attaque : fail2ban : postfix banned

Liens vers les ressources sur fail2ban :

• Le site officiel de fail2ban
• Guide d’installation sur le blog alexdfr

Suite à la mise à jour de grub vers la version 2 : grub-pc, mon système ne démarrait plus. Je me précipite donc vers mon cd netinstall de debian. Une fois le chargement du mode rescue terminé et le système de fichier monté, j’essaie donc d’éditer un fichier à l’aide de vim.

Et la, surprise, j’obtiens le message d’erreur suivant : “Unknown terminal: bterm”. Il en va de même avec le gestionnaire de packages aptitude.

Pourquoi ?

Il se trouve que le problème proviendrait du framebuffer utilisé par le système d’installation. Le problème est connu et documenté sur le site de debian :

Certaines architectures utilisent le framebuffer du noyau afin d’offrir l’installation en un certain nombre de langues. Si le framebuffer provoque des problèmes sur votre système, vous pouvez utiliser cette option pour le désactiver. Les symptômes de ce problème sont des messages d’erreur au sujet de bterm ou bogl, un écran noir, ou un blocage quelques minutes après le début de l’installation.

Les solutions

Deux possibilités :

• Désactiver le l’utilisation du framebuffer : Au lieu d’entrer “rescue” au démarrage du cdrom, il faut saisir :

  rescue debian-installer/framebuffer=false

• Démarrer normalement en mode rescue puis en ligne de commande entrer :

  TERM=vt100; export TERM

Liens sur le sujet :

• Le forum de la distribution Ubuntu

Un petit article pour relayer l’information sur le problème de sécurité de OpenSSL sous Debian. Si vous suivez l’actualité vous aurez remarqué les nombreuses news sur les sujets ces derniers jours. Etant donné qu’un schéma vaut mieux qu’un long discours et qu’un peu d’humour est toujours le bienvenue je vous laisse savourer ce post.

edit : un nouveau dessin bien sympatique sur le blog de loldebian.

Pour faire court il s’agit d’un problème avec le générateur de nombre aléatoire utilisé par OpenSSH et OpenSSL. Toutes les clés délivrées par ces outils depuis deux ans sont affectées. Ceci rend les outils qui les utilisent vulnérables aux attaques par bruteforce et ce en un temps très court (20 minutes à une heure !).

Malgré le nombre impressionnant de services impactés et de clés à régénérer, ne cédons pas à la panique. Il est temps de passer à l’action. Il y de nombreux articles qui traitent déjà des procédures à suivre et je ne vais donc pas reprendre l’intégralité des informations ici.

Voici donc ma sélection de liens sur le sujet qui vous permettra de vous en sortir :

• Le wiki de debian pour faire un point complet sur la situation
• Branle-bas SSH/SSL sur l’excellent blog de Roland Mas
• Un bon résumé sur Debian Administration

Bonne lecture et bonne chance à tous.