Ransomware Linux

Il est loin le temps où avoir une machine  sous Linux protégeait des attaques des Virus. Quand j’ai commencé à héberger mon site web, au début des années 2000 j’avais utilisé un serveur Web dédié  (Savant Web serveur) sur Windows et j’avais été très étonné de constater le nombre de tentative  d’accès à des répertoires système de L’OS.  Ces tentatives échouaient car le serveur Web n’était pas IIS….

Depuis j’ai passé toutes mon informatique personnelle en GNU/Linux et je n’ai jamais été confronté à des attaques…. jusqu’à la semaine dernière.

Les pirates ciblent désormais également les machines Linux. Ainsi mes fichiers de disques de VM se sont mis à être renommés avec des suffixes .enc ! Ce que je pensais être un problème d’espace dans ma VM était bel et bien une attaque d’un virus de type ransomware. Tous mes fichiers personnels ainsi que la configurations apache et celle du serveur DNS étaient cryptées.

Heureusement que j’ai des sauvegardes… mais le désagrément causé est certain: rupture de service, éventuelle perte de données (de quand date la dernière sauvegarde?). On ne pense jamais assez aux sauvegardes ! La première chose à faire façe à une infection que l’on ne peut pas éradiquer (manque de littérature et désintérêt des éditeurs) est de limiter la casse. Arrêter le système car le virus à réussi à obtenir les droits root ou du groupe root puisqu’il chiffre des fichiers en écriture à root. Donc arrêter le système puis débrancher le câble d’alimentation ! Ensuite démarrer depuis une clé usb de type live-cd pour récupérer ce qui peut l’être. Enfin réinstaller le système complètement.

Après l’incident il faut également cherchez à s’en prémunir. Comment une telle infection à pu survenir ? Il y a 2 ou 3 semaines mon  serveur n’a pas redémarré sur échec de montage d’un Volume logique. Suite à cet étrange incident je n’avais trouvé comme solution que de démarrer sur un kernel précédent: coïncidence ou la première étape de l’attaque ? M’obliger à utiliser un kernel ancien contenant des failles ?

Ne jamais utiliser de kernel non à jour !

Leçon à retenir: Linux n’est plus sous les radars. Il faut donc s’équiper d’antivirus et d’antispam. Les solutions existent:clamav et spamassasin.

Juste pour le plaisir… CC-BY-SA

Compression de log Tomcat 6 avec log4j 1.2

Le sujet est largement débattu mais il n’est pas trivial de trouver la solution de bout en bout. Diversité des cas, obsolescence de Tomcat 6 ou de log4j 1.2 ? En tout cas voici comment on peut mettre en place la compression de log de Tomcat 6 à l’aide de log4j 1.2.15 !

D’abord pourquoi mettre en place de la compression de log ? La log de Tomcat (ex catalina.out) ne devrait contenir que peu de messages et seulement de rare erreurs, non ? La diversité des programmeurs peut amener ces log à grossir et les framework qui génèrent des URL mal formées existent (caractère illégal). La rotation des fichiers de log si elle limite la taille ne permet pas de garder un historique c’est pourquoi je lui préfère la compression.

La documentation de Tomcat 6 permet de mettre en place rapidement log4j 1.2.17 et de disposer de la log de  Tomcat configurée par un fichier log4j.properties. L’activation de la compression des log se fait par l’utilisation de l’appender RollingFileAppender mais il ne s’agit pas de celui du paquet log4j mais plutôt du sous-paquet rolling (en gras dans l’exemple suivant). Ensuite il faut choisir la politique de rotation basée sur le temp TimeBasedRollingPolicy et enfin en spécifiant un motif de nom de fichier avec extension gz ou zip, le fichier sera compressé. Pour tester immédiatement la compression des log catalina.out, vous pouvez utiliser le fichier de configuration suivant où le niveau de log est passé à DEBUG et génère un fichier compressé par seconde.

log4j.rootLogger=DEBUG, CATALINA

# Define all the appenders
log4j.appender.CATALINA=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.CATALINA.File=${catalina.base}/logs/catalina.
log4j.appender.CATALINA.RollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy
log4j.appender.CATALINA.RollingPolicy.ActiveFileName =${catalina.base}/logs/catalina.log
log4j.appender.CATALINA.RollingPolicy.FileNamePattern=${catalina.base}/logs/catalina.%d{yyyyMMdd.HHmmss}.gz
log4j.appender.CATALINA.Append=true
log4j.appender.CATALINA.Encoding=UTF-8
log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout
log4j.appender.CATALINA.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

log4j.appender.LOCALHOST=org.apache.log4j.DailyRollingFileAppender
log4j.appender.LOCALHOST.File=${catalina.base}/logs/localhost.
log4j.appender.LOCALHOST.Append=true
log4j.appender.LOCALHOST.Encoding=UTF-8
log4j.appender.LOCALHOST.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout
log4j.appender.LOCALHOST.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

log4j.appender.MANAGER=org.apache.log4j.DailyRollingFileAppender
log4j.appender.MANAGER.File=${catalina.base}/logs/manager.
log4j.appender.MANAGER.Append=true
log4j.appender.MANAGER.Encoding=UTF-8
log4j.appender.MANAGER.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.MANAGER.layout = org.apache.log4j.PatternLayout
log4j.appender.MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

log4j.appender.HOST-MANAGER=org.apache.log4j.DailyRollingFileAppender
log4j.appender.HOST-MANAGER.File=${catalina.base}/logs/host-manager.
log4j.appender.HOST-MANAGER.Append=true
log4j.appender.HOST-MANAGER.Encoding=UTF-8
log4j.appender.HOST-MANAGER.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.HOST-MANAGER.layout = org.apache.log4j.PatternLayout
log4j.appender.HOST-MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Encoding=UTF-8
log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

# Configure which loggers log to which appenders
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=INFO, LOCALHOST
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]=\
  INFO, MANAGER
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager]=\
  INFO, HOST-MANAGER

Cette configuration fonctionne avec log4j 1.2.17 mais pas seulement. En remplaçant le jar log4j.jar par celui de la version 1.2.16, cela fonctionne aussi. En rétrogradant en version 1.2.15 il faudra utiliser un fichier de configuration au format XML (car le support du fichier dde conf en propriété a été introduit dans la version suivante 1.2.16). Voici un exemple de fifichier de configuration au format XML:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="//jakarta.apache.org/log4j/">
  <appender name="console"> 
      <param name="file" value="${catalina.base}/logs/catalina."/>        
       <rollingPolicy>
      <param name="FileNamePattern" value="${catalina.base}/logs/catalina.%d{yyyyMMdd.HHmmss}.gz"/>
      <param name="ActiveFileName" value="${catalina.base}/logs/catalina.log" />
    </rollingPolicy>
    <layout> 
      <param name="ConversionPattern" value="%-5p %c{1} - %m%n"/> 
    </layout> 
  </appender> 

  <root> 
    <priority value ="debug" /> 
    <appender-ref ref="console" /> 
  </root>
  
</log4j:configuration>

Passons à TLS

Bien que SSL soit supplanté par son successeur TLS, il reste quand même encore utilisable car bien des serveurs le garde comme protocole au cas où un client ne supporterait pas TLS. L’enfer est pavé de bonnes intentions…. si SSLv2 est aujourd’hui considéré comme défaillant, ce n’est pas le cas de SSLv3 qui reste encore dans les bonnes grâces de la configuration de apache2 sous Debian 7. En effet dans le fichier /etc/apache2/mods-enabled/ssl.conf on trouve:

SSLProtocol all -SSLv2

Ce qui indique l’utilisation possible de  TLS et de SSLv3. Malheureusement une information parue sur le site américain NVD qui recense les vulnérabilités des logiciels, SSL est intrinsèquement vulnérable (y compris SSLv3) à l’attaque de l’homme du milieu. Cela veut dire qu’il faut absolument ne plus utiliser SSL mais son successeur TLS.

La mise en place du banissement de SSL dans nos serveurs web consiste à le supprimer de la liste des protocoles utilisables par apache. Dans le fichier ssl.conf il suffit de mettre:

SSLProtocol all -SSLv2 -SSLv3

On pourra également en profiter pour hausser si n’est déjà fait le niveau de cryptage (algorithmes utilisés) que le serveur accepte de faire. Le monde libre (et donc gratuit) ne laisse aucune excuse au client qui n’utilise pas un logiciel récent et supportant les algorithmes de chiffrement les plus sûrs. Toujours dans le fichier ssl.conf il suffit de mettre:

SSLCipherSuite HIGH:!ADH:!MD5

Configuration minimale de Mutt | hidden.bressure.net

Mutt est devenu depuis peu mon client email préféré. Légèreté et fonctionnalités attendues sont délivrés avec brio par cette application en mode console.  Mutt contient tout ce qu’il faut pour écrire/recevoir des mails. Il faut juste penser à installer l’application carnet d’adresse: abook. Ce dernier a été développé à l’origine comme une extension de Mutt et est donc bien intégré à Mutt.

La suite sur mon blog avec Tor:

Configuration minimale de Mutt | hidden.bressure.net.

Vive la console | hidden.bressure.net

Les interfaces graphiques sont nécessaires quand on a besoin d’allumer les pixels de l’écran indépendamment les uns des autres. Cela arrive par exemple quand on veut travailler sur des images (DAO, PAO, CAO…) ce qui arrive dans peu de cas pour un usage courant car la plupart des informations – intéressantes – que l’on traite sont textuelles. Quand au multifenêtrage, il n’est réellement nécessaires que si on a besoin d’afficher simultanément (côte à côte) deux fenêtres ou plus. Quand est-ce que vous l’avez fait pour la dernière fois ?  Finalement dans la plupart des cas on affiche qu’une seule application à l’écran à la fois… Les interfaces graphiques sont souvent inutiles. On doit donc pouvoir s’en passer.

La suite sur mon blog caché en utilisant Tor:

Vive la console | hidden.bressure.net.

Debian/LXDE changement d’utilisateur

Quand une machine avec est partagée par plusieurs utilisateurs, il est agréable de pouvoir changer d’utilisateur sans déconnecter le précédant. Malheureusement comme l’objectif du bureau LXDE est la légèreté, la connexion simultanée de 2 utilisateurs va à l’encontre de l’économie des ressources. Comment faire alors si on veut quand même dans certaines circonstances pouvoir connecter 2 utilisateurs ?

La suite sur mon blog caché en utilisant Tor:

Debian/LXDE changement d’utilisateur – hidden.bressure.net

Client mail pour Debian/LXDE | hidden.bressure.net

Mon nouveau système Debian/LXDE est livré d’office avec un navigateur web (iceweasel a.k.a firefox) et une suite bureautique libre. Pour un usage courant il manque un client mail. Le bureau LXDE n’en fournit pas. Ce n’est pas grave. Le distribution TAILS m’ayant habitué au client mail léger Claws, ce dernier semble tout indiqué pour contenir la consommation des ressources de mon système tout en fournissant des fonctionnalités essentielles comme l’envoi et la réception de mail cryptés/signés en OpenPGP.

La suite sur mon blog caché en utilisant Tor:

Client mail pour Debian/LXDE | hidden.bressure.net.

Debian/LXDE un compromis entre bureau et serveur | hidden.bressure.net

Après avoir pu me familiariser avec le LVM sur disque RAID, j’ai sauté le pas en migrant ma machine perso, qui fait également office de serveur, sous DEBIAN/LXDE. Depuis l’année dernière, je ne jure que par Debian après que Ubuntu ait changé la durée du support LTS et que l’apparition du bureau Unity grève les performances de ma machine. De son côté bureau GNOME3 de Debian est lui-même consommateur excessif de ressouces. Ma combinaison favorite est aujourd’hui Debian pour la pérénité et LXDE pour le bureau léger.

La suite sur mon blog caché en utilisant Tor:

Debian/LXDE un compromis entre bureau et serveur | hidden.bressure.net.

Chiffrage GPG dans Claws mail pour N900 | hidden.bressure.net

Le client mail intégré du N900 ne fait pas de cryptographie. Pas de S/MIME (X509) ni de GPG avec lui. Heureusement que claws mail existe dans le dépot du N900. Moins bien intégré à l’interface du N900 à cause de la taille de l’écran mais il permet surtout de pouvoir envoyer et recevoir des mails cryptés/signés.

La suite sur mon blog caché:

Chiffrage GPG dans Claws mail pour N900 | hidden.bressure.net.