Archives de catégorie : Sécurisation

La catégorie Sécurisation contient différents principes permettant de sécuriser un objet informatique, de façon théorique (par rapport à un concept) ou pratique (en réponse à une actualité).

Gestionnaire de mots de passe

L’utilisation d’un gestionnaire de mot de passe est une très bonne pratique, à condition de choisir un bon outil. Je ne dirai pas le bon outil, car selon ses exigences, ses usages, différents outils peuvent convenir.

Les critères de choix

Il faut souvent faire des compromis sur les points suivants :

  • L‘ergonomie question de goût et de facilité d’utilisation, sans incidence sur la sécurité (sauf si cela vous incite à faire de fausses manip’) ;
  • La sécurité intrinsèque, qui peut être bonne ou mauvaise, en utilisant de bons algorithmes ou de mauvais, ou en les employant mal, etc.
  • L‘intégration avec le système d’exploitation, les navigateurs web, etc. Autant cela facilite l’usage, autant cela nuit à la sécurité puisque cela multiplie la surface d’attaques.
  • Le type de stockage en local ou en ligne. La différence est énorme : en ligne, vous avez plus de fonctionnalités et de facilité à l’utiliser, mais vous augmentez considérablement le risque de vol de vos mots de passe.
  • Le mode de licence ouvert ou non. En sécurité, on considère qu’un code accessible (à défaut d’être open source) a l’avantage de pouvoir être examiné, amélioré et audité. Avec un code propriétaire, il faut faire confiance à l’éditeur.

Après, tout dépend de si vous êtes paranoïaque ou pas. Sur le site Pixel1 (du journal Le Monde), cinq outils ont été regardés, en se basant sur un article de NextInpact2. Étonnamment, le meilleur en termes de sécurité est le moins bon en termes d’ergonomie, et réciproquement. En pratique, la facilité d’usage et l’ergonomie sont souvent inversement proportionnels au niveau de sécurité.

Le niveau de sécurité maximal n’est pas non plus automatiquement la solution la plus adaptée : une ergonomie simple et efficace peut faciliter l’adoption d’un outil et, même si son niveau de sécurité intrinsèque est insuffisant, cela peut permettre de lutter contre de mauvaises pratiques et réduire malgré tout le risque résiduel. Cela peut également convenir si l’impact d’une compromission reste faible et limité.

Il faut donc bien définir ses priorités lors du choix d’un outil, et donc savoir quel est le ou les risques que l’on souhaite couvrir.

Quelques éléments

DashLane et LastPass font partie de la catégorie des outils en ligne. Un spécialiste de sécurité a dézingué3 la qualité de leurs codes (au niveau sécurité), ce qui n’est guère rassurant, alors que KeePass ne présentait pas de faille apparente, et a même eu droit à plusieurs inspections (un audit de code encadré par la commission européenne4 et une certification de premier niveau par l’ANSSI, sur une version ancienne).

Du point de vue d’un attaquant, un gestionnaire de mots de passe en ligne est une cible de choix ! LastPass en a fait les frais en 20155 puis en 20176, en plusieurs temps78, au travers des extensions pour navigateurs web. Plus anecdotique, une nouvelle faille assez gênante a été vue (et corrigée) en 20199.

Keeper met l’accent sur une solution dite « sans connaissance », mais des chercheurs en sécurité10 remettent en cause ces affirmations. Keeper aussi a eu les mêmes ennuis que LastPass dans son extension pour navigateur en 201611 ainsi qu’en 201712, en même temps que LastPass. Il est également connu pour ne pas être enclin à aider les chercheurs en sécurité, en les poursuivants en justice pour diffamation13, ce qui n’est pas pour entretenir un climat serein pour les échanges avec la communauté SSI.

Encore des failles

Liste d’outils

Outil Editeur Licence OS Client lourd ou web Stockage Intégration navigateur
LastPass LogMeIn Commerciale Smartphones, PC Client Externe Oui
DashLane DashLane Commerciale PC (Mac, OS) Client Local + cloud sync Oui
KeePass D. Reichl GPL v2+ PC Client Local Non
Keeper Keeper Security Commerciale Smartphones, PC Client Local + cloud sync Oui
RoboForm Siber Systems Commerciale Smartphones, PC Client Local, Externe Oui
Sticky Password Lamantine Software Commerciale Smartphones, PC Client, web Local, Externe Oui
EnPass Sinew Software Systems Moteur AES open source Smartphones, PC Client Local + cloud sync Oui
1Password AgileBits Commerciale Smartphones, PC Client Local + cloud sync Oui
Norton Identity Safe Norton Commerciale nc Web Externe Oui
Intuitive Password     Smartphones, PC Web Externe Oui
Encryptr SpiderOak GPL v3 Smartphones, PC Client nodejs Externe Non
LockPass LockSelf Commerciale Ubuntu, CentOS (serveur) Web Externe, Interne Oui
PassBolt PassBolt AGPL v3 nc Web (PHP) Local, Externe  

Outils moins pertinents

Outil Editeur Commentaires
Password Manager Pro Manage Engine Solution d’authentification et de protection, trop riche.
RED identity mngt Lieberman Software Solution d’authentification, trop complète (et trop complexe).

Sources

LAMP

Comment faire pour sécuriser une installation LAMP « standard » ? Voici quelques informations, à adapter ou à compléter.

Mise-à-jour automatique du système

Pour tout système informatique, la meilleure des hygiènes est de faire les mises-à-jour du système et des logiciels importants dès que possible.

Installer un pare-feu

Bien que cela ne garantisse aucunement une sécurité absolue, tout comme un antivirus, cela reste une protection de base indispensable. Pour ma part j’aime bien shorewall, mais il n’est qu’une interface d’iptables qu’on peut trouver pratique (ou pas ) ; ufw fait aussi bien l’affaire.

Durcir le système

Cela consiste à désactiver voir désinstaller tous les services et applications dont on ne se sert pas. Cela réduit la surface d’attaque, c’est-à-dire le nombre de possibilités d’attaquer le système.

Installer un HIDS/HIPS

ossec, psad…

Installer des anti-rootkit

Tout comme un [[HIDS|HIDS/HIPS]], cela n’a de sens que si on surveille l’activité de ces outils. Plusieurs outils sont présents dans les distributions Ubuntu : rkhunter, chkrootkit, unhide…

Installer l’essentiel

$ apt install apache2
$ apache2ctl configtest
$ apt install mysql-server
$ apt install php libapache2-mod-php php-mcrypt php-mysql

Installer les modules utiles

C’est là que ça se complique. Pour les modules PHP, on fait son choix dans :

$ apt-cache search php- | less

Pour voir ce qui est installé :

$ dpkg -l | grep php

Sécuriser apache

Cacher les informations sensibles

Dans le fichier de configuration apache, modifier ou ajouter les valeurs suivantes :

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Options all -Indexes
Header unset ETag
Header always unset X-Powered-By
FileETag None

En production, il est toujours préférable de minimiser les informations fournies car elles peuvent être utilisées par des attaquants. Par contre, en développement, c’est l’inverse car cela facilite le débogage. Les headers font parties des informations à cacher.

Attention : certaines directives peuvent être modifiées par la configuration de chaque hôte virtuel ou même de modules (tels que modsecurity !). Il faudra peut-être les reporter ou les supprimer, pour éviter les conflits de paramétrage.

Désactiver l’affichage des répertoires
$ a2dismod autoindex

C’est radical. Curiosité : il ne faut pas répondre yes/no mais 'Yes, do as I say!‘. Trop marrant.

Autres commandes utiles
$ a2query -m : Liste des modules apache activés
Vérifier les accès aux répertoires
Désactiver les modules et fonctions inutiles (CGI, SSI)
Installer un WAF, tel que mod_security
$ apt install libapache2-modsecurity
$ a2enmod security2
$ cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

vvv

vi conf-available/security.conf

Modifier modsecurity.conf en ajout ou modifiant :

SecRuleEngine On
SecResponseBodyAccess Off ??? On me paraît une meilleure option... SecRequestBodyLimit 8388608 (ou plus)
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 262144

Dans le fichier /etc/apache2/mods-enabled/security2.conf, ajouter les règles minimales, ou ajouter les règles OWASP si vous les avez récupérées.

IncludeOptional /usr/share/modsecurity-crs/*.conf
IncludeOptional /usr/share/modsecurity-crs/base_rules/*.conf
Installer mod_evasive (optionnel)

Pour lutter (un peu) contre les DDoS.

Je ne suis pas persuadé qu’on puisse lutter activement contre une attaque DDoS à partir du serveur lui-même

Sécuriser MySQL

Installation sécurisée
$ mysql_secure_installation

L’utilitaire demandera plusieurs actions :

  • Utiliser le plugin de validation de mot de passe. N’activer que si vous êtes sûr de vous, les règles peuvent être un peu strictes pour un usage standard.
  • Modifier le mot de passe root. A ne faire que si le mot de passe entré lors de l’installation est trop faible.
  • Suppression des utilisateurs anonymes : oui, sans discussion.
  • Interdiction d’accès distant pour root : oui, sans discussion.
  • Suppression des bases de test et des privilèges associés : oui (recommandé)
  • Rechargement des rôles et privilèges : oui.
Accès local uniquement

Théoriquement, l’utilitaire précédent effectue ce réglage pour root.

Séparation des rôles (des utilisateurs)
Local infile

Il suffit d’ajouter une ligne dans la section [mysqld] du fichier de configuration de MySQL(/etc/mysql/mysql.conf.d/mysqld.cnf) :

local-infile = 0

A quoi sert cette option ? A charger rapidement un fichier texte dans une base MySQL. A moins d’en avoir vraiment besoin autant désactiver cette fonction qui peut introduire beaucoup de saletés dans la base de données, de façon persistante.

Sécuriser phpMyAdmin

xxx

Sécuriser PHP

Masquer les informations (si possible)

En premier lieu, il faut trouver les fichiers .ini actifs par la commande :

php --ini | grep "Loaded Configuration File"

Sans oublier les fichiers utilisés par le serveur http d’Apache… Ensuite, il fait modifier certains paramètres de façon à masquer les informations inutilement exposées.

expose_php = Off
display_errors = Off
mail.add_x_header = Off
Désactiver les modules inutiles et/ou dangereux

Dans le(s) même (s) fichier(s) .ini, on utilise le paramètre suivant :

disable_functions = show_source,system,shell_exec,passthru,exec,phpinfo,popen,proc_open,allow_url_fopen,curl_exec,curl_multi_exec

Pour ce qui est des fonctions à désactiver, c’est vous qui voyez, en fonction de ce que votre site doit utiliser ! On peut ainsi désactiver des fonctions comme phpinfo, particulièrement bavarde !

Désactiver l’exécution à distance
Contrôler les paramètres sensibles

taille upload, max exec time, open_basedir)

Sécuriser l’OS

Tripwire, tiger, SELinux/AppArmor

Sources

  • https://www.rosehosting.com/blog/how-to-secure-your-lamp-server/
  • https://tecadmin.net/security-tips-for-lamp-stack-on-linux/
  • https://gist.github.com/zachbrowne/53a1e009a8c2c8a84b82c909559dfe27
  • https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-phpmyadmin-on-ubuntu-16-04
  • https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-16-04

Rkhunter

rkhunter est un programme anti-rootkit, fonctionnant sur Linux. Il permet de vérifier l’intégrité des principaux fichiers système (dont les commandes principales) et de s’assurer qu’aucun des principaux rootkits n’est pas installé sur le système concerné.

Installation

Sur Ubuntu, le paquet est inclus dans la distribution de base. Il suffit donc de taper :

sudo apt install rkhunter

Pour lancer une analyse, c’est aussi assez simple :

sudo rkhunter -c

Quelques remarques

Il faut tout d’abord s’assurer de la mise-à-jour de l’outil, car les techniques d’attaque évoluent.

sudo rkhunter --update

Ensuite, il faut garder à l’esprit qu’un rootkit va chercher à se dissimuler, et que certains vont chercher à corrompre rkhunter pour qu’il affiche que tout va bien ! Idéalement, l’intégrité de l’outil lui-même doit être vérifiée (ainsi que de sa base de référence), manuellement, par exemple. On peut aussi réinstaller l’outil à chaque lancement, à partir du site de référence. C’est très fastidieux, mais très utile.

Au 11 avril 2018, la signature de la version 1.4.6 était :

-----BEGIN PGP SIGNATURE----- 
iQIcBAABAgAGBQJakfRfAAoJEOnF3FDROqqDFt0P/AkUyV2tBmXmiafikV3yschZ 
qr0MsTMd7X+KMFQuA+tFsnJxJBP0AzjTiRF/5QYB6uLQnwyOWGb8rKe+cLmOO3// 
uHWwEnOJba0JWGmdogbDVHOcZFzMV7UZQ2F7YrCiVzWdeW9pX1/nzP1yF7wkRaRW 
fzm0CYC3DZ4CxNzsAK3wKu84kB0UwnR4wMIDp9W5RNgOmtOEEOJMk+BErxP2NaJ8 
zC6uSlkWHT2gcEmCVNN5B4+BX1WHgkOCpobWfOEgV8dr16Np3FegZs3nBnwOvZK+ 
MuB1IefnwfhcIe1gkDlMPNTpfXv/fvIYyYy9Ki03PIG2Vk0E/s/1QnsBizAwBZMe 
LkMz4wfIeoG2pASDPi13dIO9imApUQqPKdH57asTzDhbuODJHfvW1+89LqUpOCSH 
BdleOHd425FwEmV7CFRV3rZlj92AWpCfhRJNFvT3D4mYitb/92i7bv12/vmGU/Sh 
KlQ3uHPl0mJPMyT2GYXjEr+x729zPEhxWlCiv6kht/1A8CPwGlzHjKI7shay/aX1
V87J80eUG0NaQSjbg2wwpW1U05z78EDhshyrAyq2xbSkYyujHb4YPAKieMS6edu7 
wX029+PDo343k7/D/Skoo2T6Pln542nlIlAi69S2JukC6rmSivcbpdQVKOvEkjAf 
CSR8IYmLoAgchsxuvtgu 
=aA1j 
-----END PGP SIGNATURE-----

L’identité PGP du signataire était 0xe9c5dc50d13aaa83.

Site officiel

  • http://rkhunter.sourceforge.net/

Ossec

OSSEC est un HIDS de niveau système, qui s’installe sur quasiment n’importe quelle distribution Linux du moment qu’un administrateur dispose d’un compilateur C sur la machine adéquate. Cet HIDS peut s’installer seul (il ne vérifie que ce qui se passe sur la machine) ou en tant que serveur/agent (c’est-à-dire qu’on l’installe sur une machine centrale ou serveur, qui contrôle tout un réseau de machines sur lesquelles on installe des agents ossec). Je décrirai ici l’installation dite « locale », à savoir qu’on ne surveille que son propre serveur.

Pré-requis

Il est possible que certains éléments ne soient pas installés sur le système de base. Pour Ubuntu 16 (LTS), il faut :

apt install libpcre2-dev (à compléter)

Procédure

D’abord en téléchargeant la dernière version, par exemple dans votre répertoire /home (ou tout répertoire sur lequel vous avez un droit root, car il est impértif d’installer cet utilitaire en tant qu’administrateur du système).

$ git clone https://github.com/ossec/ossec-hids 
$ cd ossec-hids 
$ ./install.sh

Vérifiez qu’il s’agit bien de la dernière version. Et sinon c’est tout ce qu’il y a à faire, à la réserve près de répondre aux questions de l’installateur. Cela suffira pour un serveur web isolé. Il est possible d’avoir aussi un serveur surveillant plusieurs autres (appelés agents)

Installation locale

Choisir le type d’installation et la langue
1- Choisir le type d'installation (local) 
... 
** Za instalaciju na srpskom, izaberi [sr]. 
** Türkçe kurulum için seçin [tr]. 
(en/br/cn/de/el/es/fr/it/jp/pl/ru/sr/tr) [en]: fr 
1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? local 
- Installation en local choisie.
Définition de l’environnement d’installation
2- Définition de l'environnement d'installation. 
- Choisissez votre répertoire d'installation de OSSEC HIDS 
[/var/ossec]: (garder la valeur par défaut comme indiqué) 
- L'installation sera faite sur /var/ossec .
Configuration de OSSEC HIDS
3- Configuration de OSSEC HIDS. 
3.1- Voulez-vous une alerte par email ? (o/n) [o]: n 
--- Alerte par email désactivée. 
3.2- Voulez-vous démarrer le démon de vérification d'intégrité ? (o/n) [o]: o 
- Lancement de syscheck (démon de vérification d'intégrité). 
3.3- Voulez-vous démarrer le moteur de détection de rootkit ? (o/n) [o]: o 
- Lancement de rootcheck (détection de rootkit). 
3.4- La réponse active vous permet d’exécuter des 
commandes spécifiques en fonction d'évènement. Par exemple, 
vous pouvez bloquer une adresse IP ou interdire l'accès à 
un utilisateur spécifique. 
Plus d'information sur : http://www.ossec.net/en/manual.html#active-response 
- voulez-vous démarrer la réponse active ? (o/n) [o]: o 
- Réponse active activée. 
- Par défaut, nous pouvons activer le contrôle d'hôte 
et le pare-feu (firewall-drop). Le premier ajoute 
un hôte dans /etc/hosts.deny et le second bloquera 
l'hôte dans iptables (sous linux) ou dans ipfilter 
(sous Solaris, FreeBSD ou NetSBD). 
- Ils peuvent aussi être utilisés pour arrêter les scans 
en force brute de SSHD, les scans de ports ou d'autres 
formes d'attaques. Vous pouvez aussi les bloquer par 
rapport à des évènements snort, par exemple. 
- Voulez-vous activer la réponse pare-feu (firewall-drop) ? (o/n) [o]: o 
- pare-feu (firewall-drop) activé (local) pour les levels >= 6 
- liste blanche (white list) par défaut pour la réponse active : 
- 212.27.54.252 
- 212.27.53.252 
- Voulez-vous d'autres adresses IP dans votre liste (white list) ? (o/n)? [n]: o 
- IPs (séparées par des espaces) : votre-ip

Puis lancez ossec via la commande indiquée en résultat /var/ossec/bin/ossec-control start, le programme sera également lancé à chaque redémarrage du serveur.

Une précaution importante à prendre

Okay, ossec est simple à installer, mais si vous voules qu’il serve à quelque chose, il faut impérativement :

  • Autoriser la réponse active lors de l’installation (ou du paramétrage) : ossec bloquera (temporairement) les adresses IP causant des problèmes.
  • Mettre les bons répertoires de logs dans le fichier de configuration.

Cet outil se base sur les logs pour trouver des anomalies : il faut donc inclure a minima les logs du systèmes et les logs de vos serveurs web !

Shorewall

Shorewall est un excellent pare-feu simple à configurer. Pour être plus précis, cet outil permet de configurer facilement des règles iptables.

Installation

Linux général

Télécharger le source, et lancer une installation classique :

$ wget http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.8/shorewall-4.4.8.2.tgz 
$ tar –xvf shore* 
$ ./install.sh

Fedora, Red Hat et CentOS

Encore une fois, des distributions récentes peuvent proposer shorewall. L’avantage est que la mise-à-jour est automatique, l’inconvénient est que vous n’avez pas toujours la dernière vesion. Dans ce cas, l’installation est cependant beaucoup plus simple :

yum install shorewall

Il ne reste plus qu’à configurer Shorewall, en comprenant un peu ce que l’on fait…

Ubuntu et Debian

C’est à peu près aussi simple que sur Red Hat like :

apt-get install shorewall

Par contre attention, pour que Shorewall démarre automatiquement, n’oubliez pas de mettre de modifier le fichier /etc/default/shorewall et de mettre startup=1.

Protections Linux

Il faut aussi penser à autoriser shorewall avec AppArmor, SELinux, etc.
Pour AppArmor : http://doc.ubuntu-fr.org/apparmor.

Configuration en hôte simple

Définissez le fichier interfaces

#ZONE   INTERFACE       BROADCAST       OPTIONS 
net     vmbr0           detect          dhcp,routefilter,nosmurfs,logmartians,tcpflags 
dmz     venet0          detect          tcpflags,routeback

Définissez le fichier zones

#ZONE   TYPE            OPTIONS         IN                      OUT 
#                                       OPTIONS                 OPTIONS 
fw      firewall 
net     ipv4 
dmz     ipv4

Définissez le fichier policy

A noter : on peut abaisser le niveau de log.

#SOURCE     DEST        POLICY          LOG             LIMIT:  CONNLIMIT: 
#                                       LEVEL           BURST   MASK 
# 
# 
à revoir

Définissez le fichier rules

Pour commencer, on met les règles de base pour permettre la connexion, ici dans le cadre d’une machine Proxmox.

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME 
#                                                       PORT    PORT(S)         DEST            LIMIT           GROUP 
#SECTION ESTABLISHED 
#SECTION RELATED 
SECTION NEW 
#

Pour Plesk, ajouter :

ACCEPT          net             dmz:IP1,IP2,IP3...               udp     8443 
ACCEPT          net             dmz:IP1,IP2,IP3...               tcp     8443,8447

Pour CPanel, ajouter :

ACCEPT         net             dmz:IP1,IP2,IP3...               tcp     2077,2078,2082,2083,2086,2087,2089,2095,2096 
ACCEPT         net             dmz:IP1,IP2,IP3...               udp     2077,2078

Si vous utilisez un collecteur de logs (par exemple Ossec) :

ACCEPT          net             dmz:votre_ip               udp     514,1514

Quelques bugs et anomalies

Le bug Ubuntu 15.04 et suivants

Sur Ubuntu 15, shorewall semble ne pas démarrer. On peut considérer cela comme très gênant. Peu d’informations sont disponibles sur le web, à part un bug ouvert1 chez Debian.
Une solution semble être l’installation d’un package supplémentaire, shorewall-init. Dans mon cas, ça a marché.

Problème de redémarrage

Il m’est arrivé d’installer shorewall, de le lancer, mais qu’après un reboot, rien ne démarre. J’avais trouvé la solution au fin fond d’un forum (launchpad), mais cela venait d’un problème dans la gestion du démarrage des services. Pour le résoudre :

 sudo systemctl enable /lib/systemd/system/shorewall.service

Mod security

mod_security est filtre (pare-feu) applicatif se présentant sous le forme d(un module que l’on peut ajouter à son serveur web Apache. Son rôle est de filtrer les requêtes bizarroïdes. Certaines distributions récentes (comme Fedora) l’intègrent et ce module peut donc être installé très facilement.

L’installation automatique convient parfaitement, mais si vous voulez avoir la toute dernière version ou si votre distribution ne la contient pas, j’ai aussi décrit la procédure manuelle.

Installation automatique

Sous Fedora 8, il suffit de taper, en mode root :

yum install mod_security

Et le toujours est joué… une fois que le serveur web aura redémarré (cf ci-dessous) :

apachectl restart

En général, les règles par défaut sont assez fines et évoluées, il n’y a pas à y toucher, sauf si cela bloque des fonctionnalités de votre site.

Si une règle vous bloque

C’est pas de chance, car il faudra alors désactiver une règle, ce qui potentiellement vous expose à une faille de sécurité. Bon, mais en pratique, il est rare qu’une règle soit cruciale à elle seule, et les autres vous permettront de conserver un niveau de sécurité acceptable. Si toutefois vous devez en désactiver plusieurs, il faudra alors se poser de sérieuses questions sur votre site, qui doit employer des techniques intrusives ou qui est conceptuellement mal sécurisé.

Comment le savoir ?

Faites un tour dans le répertoire /var/log/httpd et regardez le contenu des fichiers de logs de mod_security.

[root@host httpd]# tail -20 modsec_audit.log
GET / HTTP/1.1
Host: xx.xxx.xxx.xxx

--54705f53-F--
HTTP/1.1 400 Bad Request
Content-Length: 305
Connection: close
Content-Type: text/html; charset=iso-8859-1

--54705f53-H--
Message: Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [id "960015"] [msg "Request Missing  an Accept Header"] [severity "CRITICAL"]
Message: Warning. Operator EQ match: 0. [id "960009"] [msg "Request Missing a User Agent Header"]    [severity "WARNING"]
Message: Access denied with code 400 (phase 2). Pattern match "^[\d\.]+$" at REQUEST_HEADERS:Host.   [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"]
Action: Intercepted (phase 2)
Stopwatch: 1211041326569321 1012 (293 703 -)
Producer: ModSecurity v2.1.7 (Apache 2.x)
Server: Apache/2.2.8 (Fedora)

--54705f53-Z--

On peut aussi avoir des infos dans /var/log/httpd/modsec_debug.log :

[root@ikobox httpd]# tail -6 modsec_debug.log
[17/May/2008:18:22:06 +0200] [91.121.138.106/sid#802cace0][rid#8064f0f8][/][2] Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [id "960015"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"]
[17/May/2008:18:22:06 +0200] [91.121.138.106/sid#802cace0][rid#8064f0f8][/][2] Warning. Operator EQ match: 0. [id "960009"] [msg "Request Missing a User Agent Header"] [severity "WARNING"]
[17/May/2008:18:22:06 +0200] [91.121.138.106/sid#802cace0][rid#8064f0f8][/][1] Access denied with code 400 (phase 2). Pattern match "^[\d\.]+$" at REQUEST_HEADERS:Host. [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"]
[17/May/2008:18:27:08 +0200] [91.121.138.106/sid#802cace0][rid#806440d0][/][2] Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [id "960015"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"]
[17/May/2008:18:27:08 +0200] [91.121.138.106/sid#802cace0][rid#806440d0][/][2] Warning. Operator EQ match: 0. [id "960009"] [msg "Request Missing a User Agent Header"] [severity "WARNING"]
[17/May/2008:18:27:08 +0200] [91.121.138.106/sid#802cace0][rid#806440d0][/][1] Access denied with code 400 (phase 2). Pattern match "^[\d\.]+$" at REQUEST_HEADERS:Host. [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"]

On voit que la règle 960017 est remplie, ce qui correspond à une type d’attaque. Après, à vous de voir s’il faut la désactiver.

Comment le corriger ?

Les règles sont dans /etc/httpd/modsecurity.d dans l’installation sous Fedora 8.

[root@ikobox conf.d]# cd /etc/httpd/modsecurity.d
[root@ikobox modsecurity.d]# grep '960017' *
modsecurity_crs_21_protocol_anomalies.conf:SecRule REQUEST_HEADERS:Host "^[d.]+$" "deny,log,auditlog,status:400,msg:'Host header is a numeric IP address', severity:'2',id:'960017'"

Liens externes

Site officiel de mod-security

Serveur FTP

Pour mettre en œuvre un serveur FTP, il faut penser à quelques éléments de sécurité. Par exemple :

  • Cloisonner les utilisateurs
  • Interdire les shells
  • Contrôler la provenance des requêtes

Pure-FTPd

Il existe plusieurs serveurs FTP possibles. J’ai choisi pure-ftpd qui m’a l’air léger (~800 ko) et robuste.

Pour créer un utilisateur sous Linux :

Créer l’utilisateur Linux lui-même, de préférence sans accès au shell

$ sudo useradd ftpusr -g ftpaccess -s /usr/sbin/nologin -d /home/ftp
$ sudo pure-pw useradd ftpusr -u ftpusr -g ftpaccess -d /home/ftp 
$ sudo pure-pw mkdb

Dans la commande pure-pw useradd, utilisez l’option -r si possible, laquelle indique l’hôte depuis lequel l’utilisateur peut se connecter. Il faut aussi penser à ajouter le nologin dans la liste des shells (merci), sinon on obtient une erreur 530 bien difficile à corriger…

$ echo '/usr/sbin/nologin' >> /etc/shells

Pour pure-ftpd, on peut configurer le serveur via différents fichiers présents dans le répertoire /etc/pure-ftpd/conf.

$ ll 
total 56 
drwxr-xr-x 2 root root 4096 Aug 29 18:40 ./ 
drwxr-xr-x 5 root root 4096 Aug 29 18:35 ../ 
-rw-r--r-- 1 root root   36 Oct 29  2012 AltLog 
-rw-r--r-- 1 root root    4 Aug 29 17:57 Daemonize 
-rw-r--r-- 1 root root    4 Aug 29 17:57 DontResolve 
-rw-r--r-- 1 root root    6 Oct 29  2012 FSCharset 
-rw-r--r-- 1 root root    4 Aug 29 17:55 IPV4Only 
-rw-r--r-- 1 root root    4 Aug 29 17:56 KeepAllFiles 
-rw-r--r-- 1 root root    2 Aug 29 17:56 MaxClientsNumber 
-rw-r--r-- 1 root root    5 Oct 29  2012 MinUID 
-rw-r--r-- 1 root root    4 Oct 29  2012 NoAnonymous 
-rw-r--r-- 1 root root    4 Aug 29 18:36 PAMAuthentication 
-rw-r--r-- 1 root root   28 Oct 29  2012 PureDB 
-rw-r--r-- 1 root root    4 Aug 29 18:40 UnixAuthentication

Pour pure-ftpd, chaque fichier contient des informations de configurations. Par exemple, mettre yes dans le fichier NoAnonymous si vous voulez interdire les accès anonymes, ce qui est souvent préférable.

Passage en FTPS

Paramétrage TLS

Il faut d’abord forcer le passage par SSL/TLS via la commande :

$ echo 2 | sudo tee /etc/pure-ftpd/conf/TLS

Vérifiez ensuite les protocoles autorisés, et si vous utilisez ce serveur pour un usage personnel, visez haut et récent dans les protocoles autorisés.

$ cat TLSCipherSuite 
ALL:!aNULL:!SSLv3
Certificat
$ sudo apt install letsencrypt 
$ sudo letsencrypt certonly --agree-tos --email mail -d domaine

Le certificat et la clé privée utilisés doivent être placés dans un fichier unique nommé pure-ftpd.pem et placé dans le répertoire /etc/ssl/private/.

$ sudo cat /etc/letsencrypt/archive/domaine/cert.perm \ 
/etc/letsencrypt/live/ftp.iku.fr/privkey.pem > /etc/ssl/private/pure-ftpd.pem

Le serveur pure-ftpd doit ensuite être redémarré.
xx

  • https://www.howtoforge.com/how-to-configure-pureftpd-to-accept-tls-sessions-on-ubuntu-10.10
  • https://www.linuxbabe.com/linux-server/secure-ftp-server-pure-ftpd-ubuntu-16-04

Sources

  • https://doc.ubuntu-fr.org/pure-ftp
  • https://www.pureftpd.org

DNS

Le protocole DNS permet de connaître l’adresse réelle d’un serveur web. Plus précisément cela transforme le nom de domaine inclus dans une URL (adresse symbolique du genre https://secu.si) en adresse technique (adresse IP).

Pour cela, de très nombreux serveurs se répartissent la tâche sur toute la planète web. Pour des raisons d’efficacité, nous nous retrouvons souvent connectés directement à un serveur géré par notre fournisseur d’accès internet. Rien de bien fameux, sauf que les fournisseurs d’accès gardent souvent des traces, pour leur usage propre ou parce qu’on leur demande1.

Vie privée ?

A priori pas d’influence de l’utilisation d’un service de DNS sur sa vie privé. Et pourtant…

Transparence et traçabilité

Nous laissons des traces de notre activité dès qu’on sollicite ces serveurs DNS classiques. Même en navigation privée, le serveur DNS sait sur quels sites nous surfons. Il peut aussi interdire la navigation sur certains sites qui lui sont désignés par le pouvoir public.

Autre problème : il existe plusieurs types d’attaques sur la résolution de nom de domaine via DNS. D’où l’intérêt d’utiliser un service DNS à la fois respectueux de la vie privée mais également sécurisé. On peut par exemple savoir ce que vous faites, même si le serveur ne garde pas de traces d’activité, en écoutant les requêtes DNS circulant de façon non sécurisée, en clair.

DNSSEC

?

Les différentes options

Le serveur FAI

L’avantage premier d’utiliser le serveur du FAI est de rester dans la légalité (et donc dans la censure dans certains pays), ainsi que la simplicité d’utilisation vu que c’est le paramétrage par défaut à l’installation de votre ligne d’accès internet.

Les services dédiés

Tout dépend ensuite de la confiance que vous accordez au fournisseur que vous allez sélectionner. Il s’agit parfois d’un moindre mal : on accepte les défauts et contraintes des fournisseurs pour pouvoir contourner des blocages de type censure.

Google

Google n’est pas forcément votre ami. Oui, il vous aide à trouver presque tout ce que vous voulez, mais quand il propose des services périphériques, il y a souvent anguille sous roche. Certes il est très rapide, il y a des gens qui ont essayé, et je suppose qu’ils ont eu de problèmes. Je suppose, soyons honnête, je n’ai pas entendu de cas suspect suite à l’utilisation de Google DNS, mais si techniquement il est extrêmement rapide (c’est vrai), il appartient à Google dont le principal revenu est la publicité, et donc son fond de commerce2 est basé sur le ciblage des utilisateurs. Méfiance, donc.

Les IP du Google DNS sont :

  • 8.8.8.8
  • 8.8.4.4

Des IP simples, on n’en attendait pas moins d’un géant du web.

Quad9

Cette solution est un peu particulière, car il existe deux versions :

  • 9.9.9.9 ou 2620:fe::fe qui utilise DNSSEC et qui renvoie une liste filtrée et épurée des IP dangereuses ou malveillantes, comme celles utilisées par des botnets ;
  • 9.9.9.10 ou 2620:fe::10 qui ne filtre rien, mais qui ne fait pas de DNSSEC contrairement à 9.9.9.9.

Proposée au départ par IBM via X-Force3, elle est gérée par une association à but non lucratif. Pas mal non plus pour le choix des adresses IP.

OpenDNS

Je ne connais pas bien OpenDNS, mais le service a connu des oppositions liées à l’usage publicitaire ayant été fait des données d’utilisation. Aujourd’hui cela appartient à Cisco, la publicité a été arrêtée4, mais là encore la méfiance est de mise.

CloudFlare

CloudFlare est connu pour ses solutions industrielles, notamment anti-DDoS, ayant servi dans différents événements et attaques. Sans être philanthrope, on sait que cette société tient à garder une image propre et elle est plutôt encline à défendre la veuve, l’orphelin et l’internaute.

En avril 2018, CloudFlare a lancé un service de DNS gratuit et sécurisé sur l’adresse IP 1.1.1.1 (chapeau pour avoir mis la main sur cette adresse5).

SPOF

CloudFlare ou Quad9 sont bien placés pour emporter la mise et protéger notre vie privée. Attention toutefois au paramétrage de vos serveurs DNS : une bonne idée pourrait être de panacher les fournisseurs pour éviter le risque de déni de service, car on tombe dans le risque du SPOF si on ne choisit qu’un seul fournisseur. Par contre il faut avoir bien confiance en les deux que vous retiendrez.

Références