Skip to content →

Catégorie : Sécurité

Perfect Forward Secrecy pour Postfix/Dovecot

Après mon article sur PFS pour Apache, j’ai mis également en place PFS sur mon serveur de messagerie Postfix/Dovecot, le client K9-Mail pour Android supportant désormais des versions plus récentes de TLS, TLSv1.1 et v1.2.

Voici ici quelques éléments pour réaliser cette configuration et augmenter la sécurisation des flux chiffrés.

One Comment

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

Apache et Roundcube, sécurisation et obfuscation de version

Après installation d’un serveur de mail pour remplacer Google Apps sur mon domaine perso, j’ai trouvé que Roundcube était le seul webmail qui me plaisait à peu près.

Quelques tips et tricks sur la sécurisation de Apache / PHP et Roundcube, pas sur les serveurs Postfix / Dovecot, qui je l’espère, viendront ici alimenter le blog avec du fail2ban …

  • Configuration du vHost et sécurisation dossiers “sensibles”
<VirtualHost *:443>
        ServerAdmin postmaster@beufa.net
        ServerName  x.beufa.net
        DocumentRoot /var/www/x
        SSLEngine on
        SSLCipherSuite ALL:!ADH:RC4+SHA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
        SSLProtocol all -SSLv2
        SSLStrictSNIVHostCheck on
        SSLOptions StrictRequire
        SSLCertificateFile     cert.pem
        SSLCertificateKeyFile  cert.pem
        #GnuTLSEnable on 
        #GnuTLSPriorities SECURE:!ANON-DH:!MD5
        #GnuTLSCertificateFile cert.pem
        #GnuTLSKeyFile cert.pem
        #GnuTLSCertificateChainFile cert.pem
        #GnuTLSCACertificatePath /

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

        <Directory /var/www/roundcube/config>
                Options -FollowSymLinks
                AllowOverride None
        </Directory>

        <Directory /var/www/roundcube/temp>
                Options -FollowSymLinks
                AllowOverride None
        </Directory>

        <Directory /var/www/roundcube/logs>
                Options -FollowSymLinks
                AllowOverride None
                Order allow,deny
                Deny from all
        </Directory>

        <Directory /var/www/roundcube/plugins/enigma/home>
                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 ${APACHE_LOG_DIR}/05.x.beufa.net_error.log
        CustomLog ${APACHE_LOG_DIR}/05.x.beufa.net_access.log combined

</VirtualHost>
  • Supprimer les headers de mail PHP verbeux dans /etc/php5/apache2/php.ini
; Decides whether PHP may expose the fact that it is installed on the server
; (e.g. by adding its signature to the Web server header).  It is no security
; threat in any way, but it makes it possible to determine whether you use PHP
; on your server or not.
; http://php.net/expose-php
expose_php = Off
; Add X-PHP-Originating-Script: that will include uid of the script followed by the filename
; Example for Roundcube : X-PHP-Originating-Script: 33:main.inc in each mail sent 
mail.add_x_header = Off
  • Avoir des logs Apache / PHP dans un fichier spécifique
; The path to a log file that will log all mail() calls. Log entries include
; the full path of the script, line number, To address and headers.
;mail.log = /var/log/mail.apache-php.log

Bientôt d’autres tips sur le couple Postfix / Dovecot / Roundcube !

Comments closed
fr_FRFR