Modèle:SEServicesInternet

Services Internet

Le but est ici de configurer sur votre machine des services fonctionnels et sécurisés. Les accès IPv6 doivent être directement gérés par la machine virtuelle de services. Les accès IPv4 doivent être gérés par la machine mandataire.

Serveur SSH

Votre machine virtuelle Xen de services doit être accessible par SSH. Autorisez les accès par l'utilisateur root via le fichier de configuration /etc/ssh/sshd_config et l'option PermitRootLogin.

Pour l'accès avec l'adresse IPv4, effectuez une rediction de ports vers vos machines de services. Vous pouvez utiliser le port 2201 pour la première machine de services et 2202 pour la seconde. La redirection de ports s'effectue en utilisant iptables/nftables.

Serveur DNS

Vous allez réserver un nom de domaine pour associer un nom DNS à chacune de vos adresses IP (les zones inverses devraient, elles aussi, être gérées mais nous n'avons pas la délégation pour ce faire). Il est suggéré d’utiliser le registrar Gandi [http://www.gandi.net}. Une fois le nom de domaine reservé, configurez bind (paquetage bind9) sur votre serveur virtuel de services pour donner les adresses IPv4 et IPv6 correspondant à vos noms de machines. Utilisez l’interface web de votre registrar pour paramétrer votre machine comme serveur DNS principal. Utilisez le serveur DNS de votre binôme comme serveur DNS secondaire.

Comme votre serveur DNS ne peut pas être contacté en IPv4 vous allez configurer la machine mandataire pour servir votre zone en tant que serveur DNS secondaire. Le serveur mandataire se met à jour via le réseau privé du mandataire. Du coup au niveau du registrar vous déclarerez un "glue record" avec l'adresse IPv4 du mandataire et l'adresse IPv6 de la machine de services.

Sécurisation de site Web par certificat

Sur la machine virtuelle de services , configurez apache2 (paquetage du même nom) en mode sécurisé à l’aide d’une clef asymétrique et d’un certificat signé par une autorité de certification (CA). Comme CA, il est conseillé d’utiliser aussi Gandi. Le CA signe un CSR (Certificate Signing Request), vous allez créer vos clefs et le CSR en utilisant l'utilitaire openssl (vous pouvez vous aider du Wiki de Gandi). Une fois le CSR signé par le CA et donc transformé en un certificat vous pourrez configurer apache2 pour gérer du HTTPS sur le port 443. Dans la définition du serveur virtuel pour ce port, il faut insérer la ligne de configuration SSLEngine on. Il faut aussi préciser où se trouve la clef privée du serveur via le mot clef SSLCertificateKeyFile et où se trouve le certificat via le mot clef SSLCertificateFile. Il faut aussi définir la chaîne de certification avec SSLCertificateChainFile.

Faites très attention à la clef privée générée avec openssl si vous la perdez, votre certificat devient inutile. Il est conseillé de la stocker de façon pérenne dans votre machine de services.

Là encore seuls les accès IPv6 peuvent se faire en direct sur votre machine de services. Pour IPv4 vous devez configurer apache2 comme mandataire inverse pour votre site. Pour la fonction mandataire inverse, activez les modules Apache proxy et proxy_http. Dans le fichier de configuration du site vous devez ajouter les directives SSLProxyEngine, ProxyPass et ProxyPassReverse (utilisez l'URL avec le nom de domaine dans les deux dernières directives).

Sécurisation de serveur DNS par DNSSEC

Sécurisez votre serveur DNS en signant la zone correspondant à votre nom de domaine.

Deux méthodes sont disponibles : la gestion manuelle des clefs de chiffrement ou la gestion automatique de ces clefs par bind.

Gestion manuelle des clefs

Vous pouvez vous appuyer sur le document [1] pour réaliser la sécurisation. Testez votre configuration avec l’outil [2].

Pour entrer dans les détails, vous allez devoir effectuer les opération suivantes.

• ajoutez l’option dnssec-enable yes; dans le fichier named.conf.options ;
• il est conseillé de créer un répertoire de nom <nom_de_zone>.dnssec pour y générer les clefs ;
• créez la clef asymétrique de signature de clefs de zone (pour accélerer la génération sur un système de test vous pouvez utiliser l’option -r /dev/urandom) ;

dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE <nom_de_zone>

• créez la clef asymétrique de la zone pour signer les enregistrements (pour accélerer la génération sur un système de test vous pouvez utiliser l’option -r /dev/urandom) ;

dnssec-keygen -a RSASHA256 -b 1024 -n ZONE <nom_de_zone>

• renommez les deux paires de clefs obtenues en utilisant le nom de la zone comme préfixe puis en suffixant d’abord par la destination de la clef (-ksk pour la KSK ou -zsk pour la ZSK) puis par le type de clef (.key pour la clef publique ou .private pour la clef privée) ;
• incluez les clefs publiques dans votre fichier de zone, incrémentez le numéro de version de la zone ;

$include /etc/bind/<nom_de_zone>.dnssec/<nom_de_zone>-ksk.key
$include /etc/bind/<nom_de_zone>.dnssec/<nom_de_zone>-zsk.key

• signez les enregistrements de la zone ;

dnssec-signzone -o <nom_de_zone> -k <nom_de_zone>-ksk ../<nom_de_zone> <nom_de_zone>-zsk

• modifiez le fichier named.conf.local pour utiliser la zone signée de suffixe .signed ;
• il ne reste plus qu’à communiquer la partie publique de la KSK (présente dans le fichier <nom_de_zone>-ksk.key) à votre registrar (par exemple Gandi, regardez à "Manage DNSSEC" dans la section "DNS servers").

Gestion automatique des clefs

Rajoutez le bloc suivant dans la définition de vos zones :

 key-directory "/etc/bind/keys";
 dnssec-policy "dnspol";
 inline-signing yes;

La ligne dnssec-policy "dnspol"; fait référence au bloc global ci-dessous.

 dnssec-policy "dnspol" {
   keys {
       ksk key-directory lifetime unlimited algorithm 13;
       zsk key-directory lifetime unlimited algorithm 13;
   };
   nsec3param;
 };

Vous avez aussi à communiquer la partie publique de la KSK à votre registrar comme pour la gestion manuelle.

Filtrage des services

Vérifiez dans les fichiers de contrôle de vos machine virtuelle que le port ssh est bien sujet à des attaques par force brute.

Installez un système pour bannir les machines sources des attaques les plus patentes (avec l’utilitaire fail2ban par exemple).

Traitez aussi les attaques sur votre serveur DNS (via le protocole TCP uniquement).