Skip to content →

Category: Linux

Rsyslog : Dériver les messages syslog dans un fichier particulier

Depuis pas mal de temps, je me casse les dents sur la dĂ©rivation des logs envoyĂ©s au dĂ©mon rsyslog, utilisĂ©s pas dĂ©faut dans Ubuntu. En effet, j’ai installĂ© un tvheadend sur mon serveur / media center pour avoir Ă  la TV dans tous mes XBMC/Kodi, et le mode debug est un peu trop verbeux Ă  mon goĂ»t.

La configuration de base de rsyslog est fait par dĂ©faut dans “/etc/rsyslog.d/50-default.conf”. Pour qu’un fichier particulier soit traitĂ© en premier, comme dans Apache, il faut en crĂ©er un nouveau.

Par exemple, j’ai crĂ©er les fichiers suivants :

[19:54 user@home ~] > ll /etc/rsyslog.d/*
-rw-r--r-- 1 root root  483 Apr  9 21:40 /etc/rsyslog.d/10-tvheadend.conf
-rw-r--r-- 1 root root  465 Apr  9 21:40 /etc/rsyslog.d/11-dhcpd.conf
-rw-r--r-- 1 root root  469 Apr  9 21:50 /etc/rsyslog.d/12-postfix.conf
-rw-r--r-- 1 root root  311 Mar 17  2012 /etc/rsyslog.d/20-ufw.conf
-rw-r--r-- 1 root root 1.7K Apr  9 21:52 /etc/rsyslog.d/50-default.conf

Ces fichiers contiennent les dérivations suivantes :

[19:54 user@home ~] > cat /etc/rsyslog.d/10-tvheadend.conf
# Put tvheadend log in a specific log file
if $programname == 'tvheadend' then /var/log/tvheadend/tvheadend.log
& stop

[19:54 user@home ~] > cat /etc/rsyslog.d/11-dhcpd.conf
# Put isc-dhcpd-server log in a specific log file
if $programname == 'tvheadend' then /var/log/dhpcd.log
& stop

[19:54 user@home ~] > cat /etc/rsyslog.d/12-postfix.conf
# Put postfix log in a specific log file
if $programname == 'tvheadend' then /var/log/postfix.log
& stop

Il faut ensuite simplement reloader/restarter le service rsyslog pour prendre en compte ces changements, et vérifiez que vos fichiers sont bien crées (il peut subsister des problèmes de droits, surtout lorsque vous avez créer un dossier spécifique comme dans le cas de tvheadend).

A noter qu’il existe beaucoup d’options pour filtrer par programname, severity, ou de manière plus puissante par regex. Dans le cas ou vous souhaiteriez faire ceci, RFTM !

Ensuite, il ne faut oublier de configurer la rotation des logs (dans mon cas, j’ajoute un restart du process, car je n’ai pas de ‘status‘ pour le dĂ©mon tvheadend dans mon init.d) :

[20:05 user@home ~] > cat /etc/logrotate.d/tvheadend
/var/log/tvheadend/*.log {
        daily
        missingok
        rotate 7
        compress
        delaycompress
        notifempty
        create 640 syslog adm
        sharedscripts
        postrotate
                /etc/init.d/tvheadend restart
        endscript
}

Puis forcer la rotation (-f) ou débuguer (-d)

[20:09 user@home ~] > sudo logrotate -d /etc/logrotate.conf
reading config file /etc/logrotate.conf
[...]
reading config file tvheadend
[...]

rotating pattern: /var/log/tvheadend/*.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
switching euid to 0 and egid to 104
considering log /var/log/tvheadend/tvheadend.log
  log does not need rotating
not running postrotate script, since no logs were rotated
switching euid to 0 and egid to 0

Vous trouvez alors la rotation des logs :

[20:11 user@home ~] > ll /var/log/tvheadend/
 
-rw-r----- 1 syslog adm  12K Apr 11 20:11 tvheadend.log
-rw-r----- 1 syslog adm  48K Apr 11 09:50 tvheadend.log.1

Bon amusement !

Comments closed

Perfect Forward Secrecy pour Apache

Lors de l’utilisation d’un protocole comme SSL/TLS pour le chiffrement et la sĂ©curisation des donnĂ©es sur des rĂ©seaux non sĂ»rs, il est important de garantir la confidentialitĂ© totale des communications, mĂŞme en cas de capture du trafic chiffrĂ©.

TLS n’est en effet pas un protocole unique, mais une multitude de briques permettant la sĂ©curisation des Ă©changes, grâce Ă  :

  • L’authentification du serveur (et optionnellement du client). On utilise en gĂ©nĂ©ral un certificat x509v3 dĂ©livrĂ© par une autoritĂ© de certification.
  • La confidentialitĂ© des donnĂ©es, en utilisant les suites de chiffrement disponibles dans les CipherSpecs.
  • L’intĂ©gritĂ© des donnĂ©s, en utilisant des fonctions de hachage disponibles dans les CipherSpecs.

Un des problèmes de TLS est que pour que cela fonctionne, il faut bien un clĂ© master symĂ©trique dĂ©finie dans l’Ă©tape client key exchange. Heureusement, celle-ci est chiffrĂ©e par la clĂ© publique du certificat serveur, empĂŞchant sa lecture par un tiers autre que le serveur.

Un des problèmes est que si l’on rĂ©cupère la clĂ© master et la clĂ© privĂ©e du serveur, mĂŞme Ă  postĂ©riori, il est techniquement possible (mĂŞme si cela n’est pas Ă  la portĂ© de quiconque !) de dĂ©chiffrer l’ensemble d’une capture du trafic par exemple. On perd ainsi la confidentialitĂ© des donnĂ©es transmises, ce qui n’est pas acceptable pour un protocole de sĂ©curisation de donnĂ©es. Quand on connait les impacts potentiels de la faille HeartBleed, on se rend compte que l’obtention de la clĂ© privĂ©e est possible (mĂŞme si encore une fois, cela reste une attaque très complexe et non garantie, cela reste possible et envisageable).

Afin d’Ă©viter cela, nous allons utiliser la propriĂ©té Perfect Forward Secrecy, qui va faire appel Ă  des suites de chiffrement basĂ©es sur les Ă©changes de clĂ© DH (au lieu de RSA) qui ne sont pas faillibles (en thĂ©orie) Ă  ce principe, car les clĂ©s Ă©changĂ©es sont Ă©phĂ©mères et signĂ©es. Cette propriĂ©tĂ© permet d’Ă©viter le dĂ©chiffrement Ă  postĂ©riori d’une capture, mĂŞme en possession de la clĂ© privĂ©e du serveur. Attention, ceci est vrai si le groupe DH est suffisamment grand et valide, et uniquement sur des communications antĂ©rieures Ă  l’obtention de la clĂ© privĂ©e.

Il est possible de renforcer ce mĂ©canisme de Perfect Forward Secrecy en utilisant la cryptographie basĂ©e sur des courbes elliptiques (ECDHE pour l’Ă©change de clĂ©s Ă©phĂ©mères, et ECDSA pour l’authentification du serveur), rĂ©putĂ©e plus sĂ»re que la cryptographie par factorisation.

Par exemple, sur le logiciel Apache, on peut utiliser les CipherSuites suivantes pour renforcer la sécurité de nos échanges basés sur TLS :

# Activation du mod_ssl dans Apache
SSLEngine on

# On désactive SSLv2 et SSLv3 pour n'utiliser que TLS v1.x
SSLProtocol all -SSLv2 -SSLv3

# Au lieu de préférer les suites du client (mécanisme par défaut), on privilégie les suites proposées par le serveur
SSLHonorCipherOrder on

# On propose les suites avec ECDHE, ECDSA uniquement pour PFS
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
 
# On autorise les clients non compatibles SNI à accéder à ce vhost
SSLStrictSNIVHostCheck on

# Certificat, clé et chîne de certification
SSLCertificateFile      /etc/ssl/certs/cert_beufa.net.cert
SSLCertificateKeyFile   /etc/ssl/private/cert_beufa.net.key
SSLCertificateChainFile /etc/ssl/certs/CAcert_chain.pem

Ces options sont bien sĂ»r Ă  activer avec prĂ©caution en cas de forte charge sur vos serveurs Apache. En effet, la baisse de performances liĂ©es Ă  l’usage de la propriĂ©tĂ© Perfect Forward Secrecy entraĂ®ne des baisses de performances importantes, de l’ordre de 15% Ă  20% en fonction de la longueur des clĂ©s et CipherSpecs utilisĂ©s.

Comments closed

Bloquer le brute force sur une authentification Apache

Toujours et encore du fail2ban !

Pour bloquer des tentatives d’authentification et donc de l’Ă©numĂ©ration d’utilisateur type brute force sur des authentifications Apache / httpd, il existe dĂ©jĂ  le fichier de filtre suivant :

[20:18 user@server ~] > vim /etc/fail2ban/filter.d/apache-auth.conf
 
Fail2Ban apache-auth filter
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# apache-common.local
before = apache-common.conf

[Definition]


failregex = ^%(_apache_error_client)s (AH01797: )?client denied by server configuration: (uri )?\S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01617: )?user .*? authentication failure for "\S*": Password Mismatch(, referer: \S+)?$
            ^%(_apache_error_client)s (AH01618: )?user .*? not found(: )?\S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01614: )?client used wrong authentication scheme: \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH\d+: )?Authorization of user \S+ to access \S* failed, reason: .*$
            ^%(_apache_error_client)s (AH0179[24]: )?(Digest: )?user .*?: password mismatch: \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH0179[01]: |Digest: )user `.*?' in realm `.+' (not found|denied by provider): \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01631: )?user .*?: authorization failure for "\S*":(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01775: )?(Digest: )?invalid nonce .* received - length is not \S+(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01788: )?(Digest: )?realm mismatch - got `.*?' but expected `.+'(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01789: )?(Digest: )?unknown algorithm `.*?' received: \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01793: )?invalid qop `.*?' received: \S*(, referer: \S+)?\s*$
            ^%(_apache_error_client)s (AH01777: )?(Digest: )?invalid nonce .*? received - user attempted time travel(, referer: \S+)?\s*$

ignoreregex =

Il suffit ensuite d’activer le filtre fans la configuration globale de fail2ban :

[20:53 user@serveur ~] > vim /etc/fail2ban/jail.conf

[apache]
enabled  = true
port     = http,https
filter   = apache-auth
logpath  = /var/log/httpd/*/*error_log
action = iptables-multiport[name=Apache-auth, port="http,https", protocol=tcp]
         sendmail-whois[name=Apache-auth, dest=user@beufa.net, sender=sender@beufa.net]
maxretry = 6

Ceci permet de bloquer l’IP source sur le port 80 et 443 dans la chaĂ®ne iptables dĂ©diĂ©e (ici : fail2ban-Apache-auth), ainsi que d’envoyer un mail contenant un whois de l’IP source au bout de 6 authentifications Ă©chouĂ©es :

[20:56 user@serveur ~] > iptables -L fail2ban-Apache-auth
Chain fail2ban-Apache-auth (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Malheureusement avec fail2ban, toujours pas de compatibilité IPv6 native (cela est possible, mais via un patch fourni sur le wiki de fail2ban).

 

Comments closed

Auditer la configuration sécurité de votre Unix avec Lynis

Lynis est un outil d’audit de votre système Unix/Linux (et d’autres systèmes type AIX).

L’objectif est d’amĂ©liorer la sĂ©curitĂ© de votre système par une vĂ©rification de certains Ă©lĂ©ments de sĂ©curitĂ©. Bien sĂ»r, il ne faut pas s’attendre Ă  une vĂ©rification complète de votre système d’un point de vue applicatif, mais il s’agit d’un bon dĂ©but pour auditer ce qui pourrait poser un problème de sĂ©curisation de votre machine, en cas d’attaque sur un de vos applicatifs par exemple.

Pour téléchargez Lynis, rendez vous ici : http://cisofy.com/lynis/ (http://rootkit.nl/software/lynis/)

Comments closed

Installation de mailpile et de RainLoop

Après recherche de solutions remplaçant un Roundcube pour mon webmail perso, je suis tombé sur plusieurs projets :

  • MailPile, un webmail python, en cours de dĂ©veloppement
  • RainLoop, un webmail PHP/Ajax, qui semble plus fini

 

Installation de RainLoop

L’installation de RainLoop est assez simple :

cd /var/www/html/rainloop/
find . -type d -exec chmod 777 {} ;
find . -type f -exec chmod 666 {} ;
wget -qO- http://repository.rainloop.net/installer.php | php

Ensuite, il suffit de créer un vhost sur votre apache (ici en SSL sur myhost.beufa.net) :

<VirtualHost *:443>
        ServerAdmin postmaster@beufa.net
        ServerName  myhost.beufa.net
        DocumentRoot /var/www/html/rainloop
        SSLEngine on
        SSLCipherSuite ALL:!ADH:RC4+SHA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
        SSLProtocol all -SSLv2
        SSLStrictSNIVHostCheck on
        SSLOptions StrictRequire
        SSLCertificateFile      /etc/ssl/certs/myhost.cert
        SSLCertificateKeyFile   /etc/ssl/private/myhost.key
        #GnuTLSEnable on
        #GnuTLSPriorities SECURE:!ANON-DH:!MD5
        #GnuTLSCertificateFile cert.pem
        #GnuTLSKeyFile cert.pem
        #GnuTLSCertificateChainFile cert.pem
        #GnuTLSCACertificatePath /

        <Directory /var/www/html/rainloop>
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        <Directory /var/www/html/rainloop/data>
                Options -FollowSymLinks
                AllowOverride None
                Order allow,deny
                Deny from all
        </Directory>

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        ErrorLog /var/log/httpd/myhost.beufa.net/error_log
        CustomLog /var/log/httpd/myhost.beufa.net/access_log combined

</VirtualHost>

Et vous obtiendrez alors le webmail après une configuration sur https://myhost.beufa.net/?admin (Le login / mot de passe par défaut est admin :: 12345, il faut donc le changer !)

Une version de démonstration est disponible ici : http://rainloop.net/try-now/

Installation de MailPile

MailPile est encore en dĂ©veloppement, et honnĂŞtement, ca a l’air loin d’ĂŞtre fini. Curieux, j’ai quand mĂŞme gratter pour l’installer :

# Installation des dépendances (suivant votre système, ici en CentOS 6.5)
yum install python-imaging python-jinja2 python-lxml python-devel python-pip python-setuptools

# Clone git du repository github
cd /opt/
git clone https://github.com/pagekite/Mailpile.git 
cd Mailpile

# Installation des dépendances pip (upgrade de jinja2 pour éviter l'erreur sur les templates)
pip install -r requirements.txt
pip install jinja2 --upgrade

# Setup de Mailpile
./mp --setup

# On ajoute un compte et son dossier de stockage
./mp --set "profiles.0.email = mymail@beufa.net"
./mp --set "profiles.0.name = My Name FirstName"
./mp --add /opt/vmail/mymailhost.net/myname/  --rescan all

# On démarre le démon www
./mp --www

Le démon écoutant sur localhost et le port 33441, le plus simple est de créer un Reverse Proxy Apache pour le test :

<VirtualHost *:443>
        ServerAdmin postmaster@beufa.net
        ServerName  myhost.net
        #DocumentRoot /var/www/html/mailpile
        SSLEngine on
        SSLCipherSuite ALL:!ADH:RC4+SHA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
        SSLProtocol all -SSLv2
        SSLStrictSNIVHostCheck on
        SSLOptions StrictRequire
        SSLCertificateFile      /etc/ssl/certs/myhost.net.cert
        SSLCertificateKeyFile   /etc/ssl/private/myhost.net.key
        #GnuTLSEnable on
        #GnuTLSPriorities SECURE:!ANON-DH:!MD5
        #GnuTLSCertificateFile cert.pem
        #GnuTLSKeyFile cert.pem
        #GnuTLSCertificateChainFile cert.pem
        #GnuTLSCACertificatePath /

        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>

        ProxyRequests Off
        ProxyPreserveHost On
        ProxyPass / http://localhost:33411/
        ProxyPassReverse / http://localhost:33411/

        <Location />
                Order allow,deny
                Allow from all
        </Location>
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        ErrorLog /var/log/httpd/myhost.net/error_log
        CustomLog /var/log/httpd/myhost.net/access_log combined

</VirtualHost>

Vous pouvez alors tester sur le vhost reverse proxy ainsi créé. Par contre, par encore de formulaire d’authentification, ce qui fait que votre mail est accessible “all around the world” ! ProtĂ©gez l’interface Ă  minima avec un htaccess ou une authentification basique dans le vhost.

En résumé

RainLoop semble un produit fini, mais il y a certaines choses manquantes :

  • Pas d’import possible des contacts
  • FonctionnalitĂ©s et configuration très très basiques
  • Gestion des threads de conversation limitĂ©e et pas forcĂ©ment pratique
  • Pas d’affichage des headers mail comme sur Roundcube
  • Pas de vĂ©rification des sous dossiers IMAP

Pour MailPile, mĂŞme si le projet est prometteur (Support OpenPGP, chiffrement des pièces jointes …), il manque encore :

  • Un formulaire d’authentification !!!
  • Une interface d’administration Ă  minima comme sur RainLoop
  • La gestion des dossiers IMAP
  • Un produit fini et utilisable tout simplement.

Je vais suivre donc ce dernier plus spĂ©cifiquement, RainLoop me semblant agrĂ©able pour l’instant en plus de RoundCube, que je garde pour l’usage avancĂ© (gestion des filtres Sieve/ManageSieve). La bonne nouvelle de ces 2 projets est qu’ils supportent tous les deux mon serveur Dovecot / Postfix avec SASL pour IMAPS et SMTP/STARTTLS.

Bref, deux produits intéressants à suivre !

2 Comments
en_USEN