Administrateur Système UNIX / Linux

Comme je l’avais évoqué dans un billet précédent, le nouveau build de développement d’hbIRCS intègre une fonctionnalité majeure : le support des connexions sécurisées SSL/TLS. Le reste du travail a porté sur la réécriture du code existant avec comme objectif l’optimisation du temps d’exécution des cycles lecture/écriture, des algorithmes de parsing et un allocation optimisées des buffers.

hbIRCS-0.2.0-UNSTABLE-20090726
– support des connexions sécurisées SSL/TLS.
– optimisation de la gestion des buffers : allocation par pool, support des vues et des buffers systèmes.
– optimisation des algorithmes I/O : cycles de lecture/décodage/process et encodage/écriture.
– optimisation d’exécution des tâches planifiées.
– tuning des paramètres Listener, Connection, SSLEngine, AcceptExecutor/ReadExecutor & ThreadPool.
– fix bug commandes RESTART & DIE.
– fix bug socket bind.

Voici l’ensemble des options de configuration d’un écouteur réseau  :

<Listener>
   ListenAddress ::1
   ListenPort 9999
   ListenBackLog 128

   MaxConnections 256
   ACL local_client

   <Connection>
      UseSSLEngine true
      <SSLEngine>
         KeyStoreFile ./hbircs.keystore
         KeyStorePassword "my$ecret"
      </SSLEngine>
      ReadBufferSize 4096
      WriteBufferSize 4096
      UseDirectBuffers true
      UseBufferFactory true
      WriteRetryAttempts 2
      WriteRetryTimeout 250
   </Connection>

   <AcceptExecutor>
      SelectorTimeout 0
      QueueTaskSize 64
      TaskRecycle true        
      UseThreadPool true
      <ThreadPool>
         MaxTasks 64
         MinThreads 1
         MaxThreads 4
         ThreadIncrement 1
         ThreadPriority 5
         ThreadTimeout 60000
      </ThreadPool>        
   </AcceptExecutor>

   <ReadExecutor>
      Executors 1
      SelectorTimeout 0
      QueueTaskSize 1024
      TaskRecycle true        
      UseThreadPool true
      <ThreadPool>
         MaxTasks -1
         MinThreads 4
         MaxThreads 16
         ThreadIncrement 2
         ThreadPriority 5
         ThreadTimeout 60000
      </ThreadPool>
   </ReadExecutor>
</Listener>

Java utilise ses propres outils pour générer et utiliser les certificats sécurisés. Tout se base sur un stockage propriétaire dans un fichier keystore, regroupant des certificats/clés accessibles par des alias. Un keystore est protégé par mot de passe. Si aucun keystore n’est spécifié, le keystore personnel de l’utilisateur est utilisé (~/.keystore). Il est bien sûr possible d’importer et exporter des certificats / clés pour les utiliser dans des applications Java ou non.

Je vous propose ici un mémo des commandes les plus utilisées :

Afficher le contenu du keystore personnel :

$ keytool -list

Afficher le contenu d’un fichier keystore :

$ keytool -list -keystore my.keystore

Générer un certificat X509  auto-signé et le nommer mycert dans le keystore :

$ keytool -genkey -keystore my.keystore -alias mycert -keyalg RSA

Supprimer un certificat d’un keystore :

$ keytool -delete -keystore my.keystore -alias mycert

Afficher le contenu d’un keystore :

$ keytool -list -keystore my.keystore

Exporter le certificat d’un keystore :

$ keytool -list -keystore my.keystore -export -alias mycert -rfc

Importer un certificat externe et le protéger par mot de passe :

$ keytool -import -keystore my.keystore -alias myimport -storepass mypass -file mycertif.crt

Documentation de keytool : http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html

Un petit mémo concernant la configuration du filtre antispam SpamAssassin, afin que celui-ci ne flag pas tous les mails générés par un Outlook en tant que SPAM.

# bugs Outlook
score FORGED_MUA_OUTLOOK 0
score MSGID_MULTIPLE_AT 0

Concernant l’histoire de la règle MSGID_MULTIPLE_AT, cela ne touche qu’Outlook 2007 et c’est expliqué ici : https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5707

Pour rebondir sur le futur d’Outlook, vous pouvez participer ici : http://fixoutlook.org/ contre çà : http://blogs.msdn.com/outlook/archive/2009/06/24/the-power-of-word-in-outlook.aspx.

Avec Postfix, il est possible de constituer une blacklist pour bloquer à l’envoi (sender) ou à la réception (recipient) une adresse électronique.

Il faut ajouter ces options dans le fichier de configuration main.cf :

<pre>smtpd_sender_restrictions =
     check_sender_access hash:/etc/postfix/block_sender
smtpd_recipient_restrictions =
     check_recipient_access hash:/etc/postfix/block_recipient

Les blacklists sont donc les fichiers block_sender et block_recipient auxquels seront associès leurs fichiers  hashtable (même nom de fichier mais avec l’extension .db) à générer et régénérer après chaque modification avec postmap :

# postmap /etc/postfix/block_sender
# postmap /etc/postfix/block_recipient

Au niveau du contenu des fichiers, il faut spécifier la valeur REJECT àprès chaque adresse sinon elle sera autorisée (par défaut valeur OK) :

# cat /etc/postfix/block_sender

someuser@somedomain.com REJECT

L’erreur de rejet par défaut sera envoyée, mais il est possible de s’amuser un peu en spécifiant une erreur et un message particulier :

# cat /etc/postfix/block_sender

someuser@somedomain.com 554 Désolé, j'ai piscine !