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
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull
