Étiquette : securité

Catégories
Open-source Planet-libre Reseau Systeme

Installation et prise en main d’OpenVAS, le fork de Nessus

Depuis sa version 3, Nessus, le logiciel phare dans le petit monde des scanners de vulnérabilités des systèmes d’information est passé sous licence propriétaire. Comme c’est souvent ce genre de cas un fork de sa version 2 (qui était sous licence GPL) a rapidement vu le jour: OpenVAS. Nous allons dans ce billet en détailler l’installation et la première utilisation.

Scanner de vulnérabilités ? Kezako ?

Tout comme Nessus, OpenVAS est donc un scanner de vulnérabilités. On pourrait aussi l’appeler un logiciel d’aide aux audits de sécurités. Il se présente sous la forme d’un client / serveur.

OpenVAS4-Software

Le client permettant de définir le périmètre (plage d’adresse, type de machine) et les paramètres de l’audit (audit externe ou interne). Il se décline en CLI (ligne de commande), GUI (interface graphique) et API (Python notamment). Il est disponible sous GNU/Linux et Windows.

Le serveur effectuant le scan des différentes vulnérabilités (appelés NVT pour « Network Vulnerability Test ») disponibles dans sa base (plus de 25.000 NVTs à l’heure de rédaction de ce billet). Le serveur existe uniquement sous GNU/Linux.

Installation du serveur OpenVAS

Pour mes tests, je dispose d’une machine sous Ubuntu 12.04 LTS. La procédure suivante est donc donnée à titre indicatif pour ce système d’exploitation.

On commence par installer le package OpenVAS Serveur disponible dans les dépôts d’Ubuntu:

sudo apt-get install openvas-server

On doit ensuite créer un couple login/password pour limiter l’accès au serveur:

sudo openvas-adduser
sudo service openvas-server restart

Il est possible que le premier lancement du serveur prenne un peu de temps car il charge l’ensemble des NVTs.

Installation du client OpenVAS

Il est possible d’installer le client sur n’importe quelle machine du réseau ou bien directement sur le serveur (c’est ce que j’ai fait pour mes tests).

On installe les packages:

sudo apt-get install openvas-client htmldoc

Note: le module htmldoc sert uniquement pour l’export au format HTML des rapports.

Première utilisation d’OpenVAS

Le client graphique OpenVAS se nomme openvas-client, il faut donc le lancer via un terminal ou votre launcher Unity/Gnome. Au premier lancement, il faut commencer par se connecter au serveur via le menu Fichier > Connecter. On doit saisir le login/password.

Pour créer son premier audit de sécurité, le plus simple est de passer par le wizard disponible via le menu Fichier > Scan assistant.

Il est alors possible de choisir le contexte de l’audit (description) et la cible (une machine, un réseau…).

Le lancement de l’audit se fera automatiquement. Le temps d’exécution dépend du nombre de machines, de la rapidité de votre réseau et du nombre de services à tester sur vos cibles.

capture_085

 

A la fin, un rapport est généré et accessible en archive:

capture_086
Il est bien sur possible d’exporter le rapport (format XML, HTML, PDF…) via le menu Rapport > Exporter.

Si l’interface de GUI est pratique pour des audits « one shot », il peut être également utile de regarder du cité de l’API Python qui permet une utilisatino avancé du serveur OpenVas et pourquoi pas une automatisation des lancements.

Configuration avancée d’OpenVAS

C’est dans le fichier de configuration /etc/openvas/openvasd.conf que l’on trouve la définition du chemin vers les NVT (sortes de plugins pour OpenVAS):

# Directory where plug-ins are to be found
plugins_folder = /var/lib/openvas/plugins

Ce répertoire contient des fichiers au format .nasl avec:

Si vous souhaitez développer vos propres scripts, il va falloir se plonger dans la documentation officielle. Le plus simple est de partir du template.nasl de référence et de tester pas à pas mais avant cela, je vous conseille de regarder la base des 25.000 NVT disponibles, régulièrement mise à jour, vous trouverez sûrement votre bonheur.

Catégories
Open-source Planet-libre Reseau Systeme Web

Protéger son serveur en utilisant Fail2Ban

Comme toutes les machines exposées au réseau Internet, mon serveur Web est continuellement la cible de tentatives d’attaques basiques de type brute force et DOS. J’avais déjà abordé le sujet sous la forme de billets tel que « Sécuriser son blog WordPress » ou « Détection des attaques DOS/DDOS avec Nagios« . Nous allons aujourd’hui parler d’une solution de protection active se déclenchant automatiquement lors d’une de ces attaques: Fail2Ban.

Comment marche Fail2Ban ?

Développé en langage Python, Fail2Ban est un logiciel libre permettant d’analyser des fichiers de logs et de déclencher des actions si certaines choses suspectes sont détectées. La grande force de Fail2Ban est sa grande modularité que cela soit au niveau des mécanismes de détections basées sur les expressions régulières ou sur les actions à mener qui peuvent aller de l’expédition d’un mail à la mise en place de règles de Firewall.

Fail2Ban se base sur un système de prisons (jails) que l’on peut définir, activer ou désactiver dans un simple fichier de configuration (/etc/fail2ban/jail.conf).

Une prison (jail) est composée, entre autres, des éléments suivants:

  • Nom du fichier de log à analyser.
  • Filtre à appliquer sur ce fichier de log (la liste des filtres disponibles se trouve dans le répertoire /etc/fail2ban/filter.d). Il est bien sûr possible de créer ses propres filtres.
  • Paramètres permettant de définir si une action doit être déclenchée quand le filtre correspond (« match »): Nombre de « matchs » (maxretry), intervalle de temps correspondant (findtime)…
  • Action à mener si nécessaire. La liste des actions se trouve dans le répertoire /etc/fail2ban/action.d. Il est également possible de créer ses propres actions.

Installation de Fail2Ban

On commence par installer Fail2Ban sur son système. Il se trouve dans la grande majorité des distributions GNU/Linux et BSD. par exemple pour l’installer sur une machine Debian 6, il suffit de saisir la commande suivante (en root ou bien précédée d’un sudo):

apt-get install fail2ban

Protection contre les attaques « brute force » SSH

Un exemple étant toujours plus parlant, nous allons configurer notre Fail2Ban pour bloquer automatiquement les adresses IP des machines essayant des attaques de type « brute force » sur notre port SSH (cette attaque est à la portée de n’importe quel « neuneu ». On trouve de très bon tutoriaux sur le sujet sur le net).

Si une machine cliente échoue 3 fois de suite lors de la saisie du couple login/password sur le serveur SSH alors on bloque l’accès au port TCP/SSH pendant 15 minutes. On analyse pour cela le fichier de log /var/log/auth.log en lui appliquant le filtre /etc/fail2ban/filter.d/sshd.conf puis, si nécessaire, l’action /etc/fail2ban/action.d/iptables.conf. La définition de cette prison (jail) est à faire dans le fichier /etc/fail2ban/jail.conf:

# SSH
# 3 retry ? > Ban for 15 minutes

[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3
bantime = 900

Un fois le filtre activé en relançant Fail2Ban avec la commande (en root):

service fail2ban restart

On peut rapidement voir son efficacité en regardant le fichier de log (par défaut sous /var/log/fail2ban.log):

Protection contre les attaques DOS (HTTP/GET)

Dans ce deuxième exemple nous allons voir comment lutter efficacement contre les attaques de type DOS ciblant vos serveurs Web. Ces attaques se caractérisent par un nombre inhabituel de requêtes HTTP venant d’un même client (du moins d’une même adresse IP source).

Le plus difficile est de trouver les bons paramètres correspondants à un comportement « inhabituel ». Dans l’exemple suivant, je considère comme « inhabituel » le fait qu’un client effectue plus de 360 requêtes en 2 minutes (soit une moyenne de supérieurement à 3 req/sec) sur mon serveur Web. Dans ce cas, je bloque l’accès au port HTTP pendant une durée de 10 minutes.

La prison (jail) correspondante est la suivante (à ajouter dans votre fichier /etc/fail2ban/jail.conf):

# Protect against DOS attack
# 360 requests in 2 min > Ban for 10 minutes

[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/varnish/varnishncsa.log
maxretry = 360
findtime = 120
action = iptables[name=HTTP, port=http, protocol=tcp]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
bantime = 600

En regardant de plus près cette prison, on remarque qu’elle utilise en entrée le fichier de log au format NCSA généré par le système de cache Varnish que j’utilise en frontal sur mes serveurs Web (/var/log/varnish/varnishncsa.log). Il est bien sûr possible d’utiliser directement le log de votre serveur Apache ou Nginx. Le filtre http-get-dos n’est pas fourni par défaut. Il faut donc éditer le fichier /etc/fail2ban/filter.d/http-get-dos.conf avec le contenu suivant:

# Fail2Ban configuration file

#

# Author: http://www.go2linux.org

#

[Definition]

# Option: failregex

# Note: This regex will match any GET entry in your logs, so basically all valid and not valid entries are a match.

# You should set up in the jail.conf file, the maxretry and findtime carefully in order to avoid false positives.

failregex = ^<HOST>.*\"GET

# Option: ignoreregex

# Notes.: regex to ignore. If this regex matches, the line is ignored.

# Values: TEXT

#

ignoreregex =

Enfin, en cas de « match », on applique deux actions:

  1. blocage du port HTTP avec l’action iptables définie dans /etc/fail2ban/action.d/iptables.conf
  2. envoie d’un mail signalant le blocage avec l’action mail-whois-lines. L’adresse du mail est défini dans la variable destemail à modifier dans le fichier jail.conf.

Un fois le filtre activé:

service fail2ban restart

On peut regarder le fichier de log (/var/log/fail2ban.log)…:

$ tail -f /var/log/fail2ban.log

2012-02-22 11:36:59,134 fail2ban.actions: WARNING [http-get-dos] Ban 107.---.---.---

… et/ou attendre la réception des mails:

Conclusion

Ce billet est une simple introduction à l’utilisation de Fail2Ban qui peut être configuré de manière beaucoup plus personnalisé et en fonction de vous besoins. Si vous avez d’autres exemples d’utilisation, les commentaires ci-dessous sont fait pour cela !

Catégories
Blog Open-source Planet-libre Reseau Systeme Web

Sécuriser son blog WordPress #3

WordPress n’a pas forcement bonne presse au niveau de la sécurité. Le coeur PHP du moteur WordPress est pourtant surveillé de très près et les corrections des failles sont assez rapides (voir par  exemple la publication de la version 3.0.4).

Par contre les plugins, qui sont un avantage indéniable de WordPress par rapport aux autres CMS, sont également un talon d’Achille… En effet, WordPress dispose d’une base de plugins impressionnante (plus de 12.700 au moment de l’écriture de ce billet) dont les développeurs sont plus ou moins sensibilisés à la problématique de la sécurité… Ajouter des plugins à votre blog, c’est multiplier les risques au niveau de la sécurité.

Dans ce billet, nous allons voir comment installer puis configurer WordPress pour compliquer la tache des personnes voulant attaquer votre blog.

Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #3):

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).

Partir sur de bonnes bases

Nous allons détailler l’installation, la configuration initiale puis la gestion des mises à jours de WordPress.

    Installation de WordPress

    Personnellement j’utilise sur mon serveur deux versions de WordPress en parallèle.

    La première est celle du blog « de production » (celui que vous êtes en train de lire) utilise la version stable SVN (c’est à dire la 3.0.4 au jour d’aujourd’hui). J’utilise la commande suivante pour effectuer l’installation (dans le répertoire racine de mon serveur Web: /var/www/blog):

    svn co http://core.svn.wordpress.org/branches/3.0/

    La seconde, dite « de validation » me sert pour tester mon blog (thème et plugins) sur les futures versions de WordPress (3.1 par exemple). Elle n’est pas publique, seul les administrateurs peuvent y accéder. Pour installer cette version de WordPress, j’utilise la commande suivante dans un deuxième répertoire de mon serveur Web (/var/www/blogfutur):

    svn co http://core.svn.wordpress.org/trunk/

    Avant de suivre la fameuse installation en 5 minutes de WordPress, je vous conseille de changer le préfixe des tables MySQL en éditant la ligne suivante dans votre fichier de configuration wp-config.php et en remplacant wp_ par une chaine aléatoire (par exemple apvbty_):

    $table_prefix  = ‘apvbty_’;

    Attention, cette manipulation est à faire seulement sur un nouveau blog. En effet, si vous avez déjà une base de donnée SQL existante il faut d’abord changer le nom du préfixe des tables dans MySQL (voir hack en fin de billet) sous peine de ne plus pouvoir accéder à vos données.

    Une fois l’installation de WordPress finalisée, nous allons commencer par fixer les droits au niveau des fichiers dans ces répertoires. En partant sur l’hypothèse ou votre serveur Web tourne sous l’utilisateur www-data et dans le répertoire /var/www/blog, j’utilise les commandes suivantes:

    chown -R www-data:www-data /var/www/blog

    find /var/www/blog -type d -exec chmod 755 {} \;

    find /var/www/blog -type f -exec chmod 644 {} \;

    chmod 640 /var/www/blog/wp-config.php

    find /var/www/blog/wp-content/themes -type d -exec chmod 775 {} \;

    find /var/www/blog/wp-content/themes -type f -exec chmod 664 {} \;

    Pour vous simplifier la vie, je vous conseille de mettre ces commandes dans un script shell afin de pourvoir rapidement les appliquer sur votre arborescence.

    Mise à jour de WordPress

    Comme nous l’avons vu, les développeurs de WordPress sont assez réactifs sur la correction des failles de sécurité. Encore faut-il que vous pensiez à mettre à jour votre instance de WordPress…

    J’utilise un script shell pour mettre à jour WordPress à partir de SVN:

    #!/bin/bash

    # Simple script pour mettre a jour WordPress

    # Test que le script est lance en root

    if [ $EUID -ne 0 ]; then

    echo « Le script doit être lancé en root: # sudo $0″ 1>&2

    exit 1

    fi

    WPPATH= »/var/www/blog »

    echo « 1) Mise a jour de WordPress »

    cd $WPPATH 2>&1 /dev/null

    CURRENTVERSION=`svn info | grep « Revision:  » | awk ‘{ print $2 }’`

    svn update

    rm $WPPATH/wp-admin/install.php

    cd – 2>&1 /dev/null

    echo « 2) Verification des droits des fichiers »

    chown -R www-data:www-data $WPPATH

    find $WPPATH -type d -exec chmod 755 {} \;

    find $WPPATH -type f -exec chmod 644 {} \;

    chmod 640 $WPPATH/wp-config.php

    find $WPPATH/wp-content/themes -type d -exec chmod 775 {} \;

    find $WPPATH/wp-content/themes -type f -exec chmod 664 {} \;

    echo « 3) Fin de la mise a jour »

    echo « En cas de pb: svn update -r$CURRENTVERSION »

    Il est possible de lancer ce script toutes les nuits (par exemple par crontab) pour éviter de se retrouver avec un blog hacké quand vous partez en congés…

    Le .htaccess

    Ce fichier qui doit se trouver à la racine de votre site Web, contient des entrées utiles à la sécurité de votre site. Le mien commence par:

    # MAIN

    RewriteEngine On

    ServerSignature Off

    Options All -Indexes

    Options +FollowSymLinks


    # SVN protect

    RewriteRule ^(.*/)?\.svn/ – [F,L]


    # Secure .htaccess

    <Files .htaccess>

    Order Allow,Deny

    Deny from all

    </Files>


    # Secure wp-config.php

    <Files wp-config.php>

    Order Deny,Allow

    Deny from all

    </Files>


    # FILTER REQUEST

    <IfModule mod_rewrite.c>

    RewriteBase /

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule . /index.php [L]

    </IfModule>

    Certains plugins ajoutent pas mal de chose dans ce fichier (notamment W3 Total Cache, le plugin d’optimisation des performances que j’ai abordé dans ce billet).

    Un peu de bon sens…

    Vous avez donc entre les mains une installation toute propre et sécurisée de WordPress, c’est normalement à partir de ce moment là que les choses se gâtent…

    On commence par l’erreur de base: ne pas utiliser un mot de passe « strong » pour le compte admin. Encore mieux, créer un nouveau compte administrateur et supprimer le compte admin par défaut.

    L’installation des plugins apportent également son lot de failles de sécurité. C’est là qu’il faut se faire violence et n’installer que les plugins indispensables au bon fonctionnement de votre blog. Il faut également veiller à mettre à jour régulièrement vos plugins (l’interface d’administration de WordPress permet de faire cela très simplement).

    Enfin vos thèmes peuvent également fragiliser votre blog en insérant des codes PHP ou JS. Si vous avez les compétences il faut faire un audit de votre thème ou au minimum utiliser des thèmes connus et validés.

    Des plugins pour la sécurité

    Parmis ces plugins, j’en utile trois dédiés à la sécurisation:

    • Secure WordPress permet d’automatiser certaines actions pour sécuriser votre blog.

    • WordPress File Monitor: Surveille les fichiers du moteur WordPress et vous alerte (par mail et/ou directement dans l’interface d’administration de WordPress) en cas de modification.
    • On peut également citer WordPress Security Scan qui permet de faire un audit de votre blog en testant notamment les droits de vos fichiers, les mots de passes, la base de données…

    Quelques hacks en bonus

    Compliquer la tache des attaques par force brute en supprimant l’indicateur (« mauvais mot de passe ») lors d’une tentative de connexion à l’interface d’administration. Il faut juste ajouter la ligne suivante à votre fichier functions.php (thème):

    add_filter(‘login_errors’, create_function(‘$a’, « return null; »));

    Si vous avez une base de données MySQL existante avec le préfixe par défaut (wp_) et que vous souhaitez le changer, il est possible de faire celà directement à la main par une requête MySQL ou alors plus simplement en utilisant le plugin WP-Security-Scan.

    Tester votre WordPress

    Pour tester la sécurité de votre blog, rien ne vaut une simulation d’attaque. Pour celà vous pouvez utiliser le logiciel libre Nikto.

    On commence par installer Nikto sur un PC client sous Ubuntu (qui va simuler l’attaque):

    sudo aptitude install nikto

    Puis on lance le test (remplacer URL par l’URL de votre blog WordPress):

    nikto -h URL

    Le rapport devrait ensuite s’afficher.

    Sources:

    Catégories
    Blog Open-source Planet-libre Reseau Systeme

    Sécuriser son blog WordPress #2

    Dans ce deuxième billet, nous allons aborder la pierre angulaire de la sécurisation de votre site/blog: la sécurisation du couple infernal Apache/PHP.

    Bien qu’il existe d’autres serveurs Web (par exemple le très rapide NGinx ou le très simple Cherokee), Apache reste, à ce jour, le plus répandu. Un des reproche que l’on peut lui faire est sa lourdeur de configuration. Cette lourdeur et l’utilisation de fonctions pas forcement utiles à votre site peut rapidement entraîner des failles de sécurité. Nous allons donc détailler la sécurisation du serveur Web ainsi que celle du moteur de langage PHP qui est utilisé par WordPress.

    Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #2):

    Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).

    Serveur Web Apache

    Sécuriser l’installation par défaut d’Apache2

    Apache est développé en tenant compte de la sécurité mais dévoile, dans le header HTTP, son identité (son nom et son numéro de version) à chaque client qui se connecte. Ne pas divulguer ces informations permet d’éviter aux scripts kiddies de connaitre directement les failles connues pour la version d’Apache utilisée et peut compliquer le travail des crackers.

    Pour cacher ces informations aux clients HTTP, il suffit d’éditer le fichier /etc/apache2/conf.d/security et d’y ajouter/modifier les variables suivantes:

    ServerTokens Prod
    ServerSignature Off
    TraceEnable On

    Module de securité IDS pour Apache

    Il existe dans Apache un module optionnel nommé ModSecurity2 qui permet de détecter et de protéger son serveur contre des attaques touchant vos applications Web (notamment les « SQL injections », « cross-site scripting », « path traversal attacks »…).

    On commence par l’installation de mod-secure:

    sudo aptitude install libapache2-mod-security2

    Par défaut, aucune règle n’est appliquée. Il faut donc partir du fichier de configuration qui est donné en exemple:

    sudo cp /usr/share/doc/mod-security-common/examples/modsecurity.conf-minimal /etc/apache2/conf.d/mod-security.conf

    On édite ensuite le fichier /etc/apache2/conf.d/mod-security.conf:

    # Basic configuration options
    SecRuleEngine On
    SecRequestBodyAccess On
    SecResponseBodyAccess Off

    # Handling of file uploads
    # TODO Choose a folder private to Apache.
    SecUploadDir /tmp/
    SecUploadKeepFiles Off

    # Debug log
    SecDebugLog /var/log/apache2/modsec_debug.log
    SecDebugLogLevel 0

    # Serial audit log
    SecAuditEngine RelevantOnly
    SecAuditLogRelevantStatus ^5
    SecAuditLogParts ABIFHZ
    SecAuditLogType Serial
    SecAuditLog /var/log/apache2/modsec_audit.log

    # Maximum request body size we will
    # accept for buffering
    #SecRequestBodyLimit 131072
    SecRequestBodyLimit 8192000

    # Store up to 128 KB in memory
    SecRequestBodyInMemoryLimit 131072

    # Buffer response bodies of up to
    # 512 KB in length
    SecResponseBodyLimit 524288

    # Verify that we’ve correctly processed the request body.
    # As a rule of thumb, when failing to process a request body
    # you should reject the request (when deployed in blocking mode)
    # or log a high-severity alert (when deployed in detection-only mode).
    SecRule REQBODY_PROCESSOR_ERROR « !@eq 0 » \
    « phase:2,t:none,log,deny,msg:’Failed to parse request body.’,severity:2 »

    # By default be strict with what we accept in the multipart/form-data
    # request body. If the rule below proves to be too strict for your
    # environment consider changing it to detection-only. You are encouraged
    # _not_ to remove it altogether.
    SecRule MULTIPART_STRICT_ERROR « !@eq 0 » \
    « phase:2,t:none,log,deny,msg:’Multipart request body \
    failed strict validation: \
    PE %{REQBODY_PROCESSOR_ERROR}, \
    BQ %{MULTIPART_BOUNDARY_QUOTED}, \
    BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
    DB %{MULTIPART_DATA_BEFORE}, \
    DA %{MULTIPART_DATA_AFTER}, \
    HF %{MULTIPART_HEADER_FOLDING}, \
    LF %{MULTIPART_LF_LINE}, \
    SM %{MULTIPART_SEMICOLON_MISSING}, \
    IQ %{MULTIPART_INVALID_QUOTING}' »

    # Did we see anything that might be a boundary?
    SecRule MULTIPART_UNMATCHED_BOUNDARY « !@eq 0 » \
    « phase:2,t:none,log,deny,msg:’Multipart parser detected a possible unmatched boundary.' »

    On relance ensuite Apache pour prendre en compte le plugin:

    sudo /etc/init.d/apache2 restart

    Ce module contient un ensemble d’expressions rationnelles dont l’objectif est de bloquer les requêtes jugées dangereuses. Il bloquera une partie des tentatives de piratage. C’est  tout de même une barrière de protection faillible mais qui peut empêcher l’exploitation de certaines failles. Dans tout les cas, cela n’empêche pas le développeur de coder correctement, en prenant en compte la sécurité au moment du développement des sites.

    Module anti DOS

    Nous allons installer le module Apache mod_evasive qui permet d’atténuer les attaques DOS faite en utilisant le protocole HTTP en bloquant les adresses IP des clients trop gourmand, c’est à dire ceux qui demandent trop rapidement des pages webs.

    Contrairement à ce que l’on peut lire sur certains sites, ce module ne protège pas des DDOS, seulement des DOS (lire ici une explication des attaques DOS et DDOS). Autrement dit, il bloque les reqêtes venant d’une adresse IP (DOS).

    Si un très grand nombre d’IPs font une seule requête : votre serveur sera saturé et le mod_evasive n’aura pas servi (DDOS). Bloquer les DDOS est très difficile car les requêtes sont difficilement reconnaissables des requêtes autorisées.

    On commence par installer le module:

    sudo aptitude install libapache2-mod-evasive

    On édite le fichier /etc/apache2/conf.d/mod-evasive:

    <IfModule mod_evasive20.c>
    DOSHashTableSize 3097
    DOSPageCount 2
    DOSSiteCount 50
    DOSPageInterval 1
    DOSSiteInterval 1
    DOSBlockingPeriod 10
    </IfModule>

    C’est la configuration par défaut qui va bloquer pendant 10 secondes (DOSBlockingPeriod) les requêtes HTTP venant de l’adresse IP source si une des assertions suivantes est vérifiée:

    • il y a plus de 2 requêtes (DOSPageCount) sur la même page dans un intervalle de 1 seconde (DOSPageInterval)
    • il y a plus de 50 requêtes (DOSSiteCount) sur l’ensemble du site dans un intervalle de 1 seconde (DOSSiteInterval)

    On relance ensuite Apache pour prendre en compte le plugin:

    sudo /etc/init.d/apache2 restart

    Sécurisation du moteur PHP

    PHP est un langage interprété, largement utilisé pour générer dynamiquement des pages HTML. C’est le langage utilisé par le moteur de CMS WordPress. La génération des pages de votre blog se faisant directement sur votre serveur, il est important de protéger l’environnement d’exécution des scripts PHP.

    Il est donc conseillé d’utiliser suphp. Il est relativement facile à installer et permet d’exécuter vos scripts PHP sous un utilisateur autre que www-data et donc protéger votre système.

    Cela permet aussi de servir plusieurs sites internet sur un même serveur. Si un pirate atteint un site, il ne pourra pas toucher aux autres.

    Ce module fournit aussi la possibilité de disposer d’un fichier PHP.ini par site web, et offre donc plus de flexibilité que l’installation standard de PHP.

    La sécurité a néanmoins un coup: la performance. Attendez vous à des pertes de performances sur vos applications. Dans le cas d’une application codée correctement et d’un serveur non surchargé, cette perte devrait cependant être minime.

    Il est également possible de désactiver certaines fonctions sensible de PHP (system, exec…) en éditant le fichier php.ini (voir exemple dans l’étape n°3 de ce billet).

    Pour installer  suPhp sur votre serveur je vous conseille la lecture de cet article. (si vous voulez/devez faire cohabiter deux versions de PHP, par exemple la 4 et la 5, vous pouvez également consulter ce billet).

    Conclusion (temporaire)

    On dispose donc maintenant d’un système et d’un serveur Web sécurisé. Il ne reste plus qu’à attendre la suite de cette série de billets pour s’attaquer à la sécurisation du moteur de blogging WordPress.

    Catégories
    Open-source Reseau Web

    Cracker un réseau Wifi sous GNU/Linux

    Article supprimé le 31 janvier 2015 à la demande de la gendarmerie nationale.

    Catégories
    Open-source Reseau

    Installation de BASE (reporting snort)

    Avoir un Firewall c’est bien, y installer un logiciel de détection d’intrusion (IDS) c’est encore mieux. Mais pour atteindre les sommets de la sécurité informatique, il faudra passer par une étape ingrate: l’analyse des logs générés par votre IDS…

    SNORT est un IDS libre facile à installer sur les OS GNU/Linux et BSD. Il produit en sorti des logs avec les alertes repérées sur votre réseau. Ces logs peuvent devenir très volumineux et donc impossible à analyser. Heureusement, BASE (de SecureIdeas) est là pour vous donner un coups de main.

    BASE est une interface Web permettant d’analyser les logs de SNORTS stockés dans une base de données MySQL (ou PgSQL).

    capture_200810095414.jpg

    Installation de base sous une GNU/Linux Fedora

    On commence par installer la librairie AdoDB pour permettre à l’application BASE de communiquer avec la base de donnée.

    cd /var/www

    wget http://ovh.dl.sourceforge.net/sourceforge/adodb/adodb505.tgz

    tar zxvf adodb505.tgz

    ln -s adodb5 adodb

    rm adodb505.tgz

    On récupère ensuite la dernière version de BASE sur le site officiel (http://base.secureideas.net/).

    wget http://ovh.dl.sourceforge.net/sourceforge/secureideas/base-1.4.1.tar.gz

    tar zxvf base-1.4.1.tar.gz

    ln -s base-php4 base

    chown -R apache:apache base base-php4

    rm base-1.4.1.tar.gz

    On finalise l’installation en se rendant, à l’aide d’un navigateur Web, vers la page suivante: http://<adresse-ip-serveur>/base/

    Puis on suit le wizard avec en premier la vérification des pré-requis:

    capture_200810095022.jpg

    on choisit ensuite la langue (1), le chemin d’accès à AdoDB (2) puis on continu (3):

    capture_200810095101.jpg

    on configure la base de donnée (1 et 2) puis on continu (3):

    capture_200810095139.jpg

    on force une authentification sur les accès à BASE (1), le login/password (2) et on continu (3):

    capture_200810095241.jpg

    On finalise l’installation :

    capture_200810095305.jpg

    capture_200810095329.jpg

    Et voilà, il ne reste plus qu’a consulter régulièrement les rapports générés par ces beaux outils.

    Utilisation de BASE

    Il suffit de se rendre à l’URL suivante: http://<adresse-ip-serveur>/base/

    Les rapports sont disponibles par jours, derniers 24h, derniers 72h, alertes les plus récentes, les plus fréquentes…

    Catégories
    Blog

    Protéger son répertoire WordPress/Plugins

    Les plugins font le succès de WordPress. Ce sont aussi des trous potentiels en terme de sécurité. En effet, ces codes PHP développés pour la plupart sous licence GPL ne sont que rarement étudiés en terme de faille informatique.

    Il est donc important de mettre à jour régulièrement ces plugins. Mais ce n’est pas tout. En effet, si une personne mal attentionnée (un méchant hackeur) essaye d’exploiter une de ces failles, il doit d’abord en connaître la liste exhaustive. C’est pour cela qu’il est important de protéger le répertoire plugins de votre blog. Pour cela, Bill Hartzer donne une méthode simple et efficace.

    Il faut d’abord vérifier s’il est possible de connaître la liste de vos plugins à partir d’un simple navigateur Web. Pour cela, il faut saisir l’URL:

    http://addressedevotreblog/wp-contents/plugins

    Si votre répertoire est protégé, vous devriez voir le message suivant:

    Forbidden
    You don’t have permission to access /wp-content/plugins/ on this server.

    Si ce n’est pas le cas et que vous voyez l’arborescence de vos plugins, il faut effectuer les taches suivantes:

    • Editer un fichier nommé index.html avec le contenu suivant.
    • Enregistrer le fichier.
    • Télécharger le fichier dans le répertoire /wp-content/plugins/ de votre serveur Web.

    Et voilà le travail !