[gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509

Daniel Cordey dc at pxcluster.com
Wed Apr 4 17:24:38 CEST 2018


On 04. 04. 18 16:27, Frederic Dumas wrote:
> Pourriez-vous me conseiller une façon de restreindre la diffusion de son certificat X.509 par un serveur web en home hosting ?

Ben... le certificat X.509 contient la clef publique... et les données 
permettant de définir si l'on peut faire confiance à ce certificat ou 
pas. C'est aussi utilisé lorsque l'on examine la CRL (Certification 
Revocation List). Empêcher la diffusion des données contenues dans X.509 
me semble donc contre-productif. Comment alors vérifier si un certificat 
est valide ou pas ? Ou suis-je dans l'erreur ?
> Un rewrite dans la configuration d'Apache reformule toute requête HTTP reçue sur le port 80 en requête HTTPS sur le port 443.

Oui, mais la requête stipule bien https... donc il veut établir une 
connexion sécurisée en utilisant SSL :

"After the secure connection is made, the session key is used to encrypt 
all transmitted data. Browser connects to a web server (website) secured 
with SSL (https). Browser requests that the server identify itself. 
Server sends a copy of its SSL Certificate, including the server's 
public key."

> Par ailleurs, le certificat renferme le nom du domaine pour lequel il a été signé, il dit donc explicitement au visiteur quel domaine correspond à l'adresse IP que celui-ci est en train d'interroger, malgré l’absence d'enregistrement reverse dans les DNS.

Cela fait partie des données qui sont comparées entre le CA et celles 
contenues dans le CA. C'est la raison pour laquelle on ne peut 
transporter un certificat entre plusieurs serveurs avec des adresse IP 
différentes. On cherche à établir une connexion sécurisée avec un 
serveur dûment enregistré sur internet. Cela fait donc partie d'une 
information essentielle à la vérification et à l'établissement d'une 
connexion de "confiance" (trsuted).
> J’aimerai mieux sécuriser le serveur contre les balayages d’IP,

Quel genre de balayage IP ? Le scan des ports ? le "header" du serveur ? 
Le scan des ports peut  être restreint en utilisant une (ou des) règle 
'itpables' et le "header" peut être modifié dans la config d'Apache.

> et lui interdire de communiquer ce certificat X.509 à un visiteur se connectant directement sur son adresse IP ou se connectant en résolvant cette adresse IP à travers un domaine fictif.

N'importe qui faisant une requête "GET /"  en mode HTTPS va recevoir les 
données permettant de vérifier que le certificat est bien lié au serveur 
concerné. C'est un peu la base de HTTPS :-)

Installer un firewall (iptables), n'ouvrir que les ports nécessaires, ne 
pas avoir d'accès ouvert sans mot de passe (au minimum), etc. est déjà 
un bon obstacle à toutes sortes d'attaques, mais on doit bien laisser 
une porte d'entrée pour le serveur web... De toute façon, il existe des 
robots qui scannent tous les domaines existants en permanence, quoi que 
l'on fasse. Il suffit même de scanner le port 80 de chaque domaine, 
échappant ainsi au "scan detection" de 'iptables'. une fois un port 80 
reconnu, les robots/pirates essaient de toute façon de balancer 
n'importe quel type de requête au serveur. Ces requêtes sont des 
tentatives d'accéder à des services connus, comme phpmyadmin, phpbb, 
wordpress, etc. Cela représente pas mal de requêtes et ne cesse jamais. 
On peut avoir un process qui lit les logs en permanence et met 
immédiatement les adresses IP en quarantaine, mais ces tentatives 
recommencerons ensuite avec d'autres sources IP quelques heures après ou 
le lendemain... J'avais mis ce genre d'outil en place sur un serveur et 
effectivement cela limite bien le volume des requêtes, mais les pirates 
peuvent alors identifier vos blocage et décider d'utiliser alors 
d'autres techniques. Idéalement, il ne faut rejeter ces requêtes ou les 
bloquer, mais il faut les ralentir... car alors il est beaucoup plus 
difficile au pirate de reconnaître qu'il a été détecté. D'autant que les 
requêtes sont effectuées à partir de système piratés (principalement des 
PC sous W*) et faisant partie de botnets.

A noter aussi que la mise en quarantaine d'adresse ip avec 'iptables' 
passe par l'utilisation de 'ipset' qui permet de gérer des listes d'IP 
en "hasing", plutôt que de balayer une liste de manière séquentielles, 
ce qui engendre un comportement algorithmique du style O(n), plutôt que 
O(1) avec 'ipset'.

dc



	



More information about the gull mailing list