Sécurisation du service Services internes

Risques de sécurité susceptibles de nuire au service :

Résolveur

• DNS Cache poisonning (ou DNS spoofing): attaque le DNS pour enregistrer une fausse information dans son cache et ainsi rediriger les utilisateurs vers un mauvais site web.
• Attaque DoS ou DDoS : empêche l'utilisation le serveur d'utiliser ces ressources (et donc de fournir le service) en surchargeant ce derniers de requêtes.

web interne

• Attaque DoS ou DDoS : empêche l'utilisation le serveur d'utiliser ces ressources (et donc de fournir le service) en surchargeant ce derniers de requêtes.
• Injection SQL: modifie une requête SQL en injectant un autre morceau de requête. Le pirate peut ainsi avoir accès à la db.
• Cross-Site Scripting (ou XSS): est comme l'injection SQL mais ici le SQL est remplacer par un script malveillant.

NextCloud

Le service Nextcloud étant direcetement lié au web interne ce dernier dépend entièrement de la sécurité apporter au web interne.

SOA interne

• DNS Cache poisonning (ou DNS spoofing): attaque le DNS pour enregistrer une fausse information dans son cache et ainsi rediriger les utilisateurs vers un mauvais site web.
• Attaque DoS ou DDoS : empêche l'utilisation le serveur d'utiliser ces ressources (et donc de fournir le service) en surchargeant ce derniers de requêtes.

Contre-mesures:

SOA interne

Pour évitez tout DNS spoofing et que le SOA interne ne soit attaquer et redirige vers des sites frauduleux nous allons lui installer un DNSSEC qui grâce à des certificats échanger au début et fin de connexion nous permettent de valider l'authenticité des données et donc évite toute redirection frauduleuse. De plus nous allons limiter l'accès du service aux IPs de l'entreprise pour protéger le services des attaques extérieurs.

Installer DNNSEC

1. Activer DNSSEC Ouvrer le fichier /etc/bind/named.conf et ajouter ces deux lignes :

dnssec-enable yes;
dnssec-validation auto;

2. Créer un dossier etc/bind/keys dans lequel vous générer la paire de clé ZSK et KSK

dnssec-keygen -a RSASHA256 -b 2048 -n ZONE intranet.woodytoys
dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE intranet.woodytoys

3. Renommer ensuite les 4 clés (les clés vont par pair, la privée et la publique) en intranet.woodytoys.zsk/ksk.key/private en fonction de ce que vous avez besoin.
4. Signer la zone grâce à la commande (toujour dans le dossier etc/bind/keys):

dnssec-signzone -g -k ./intranet.woodytoys.ksk.key -o intranet.woodytoys ../db.intranet.woodytoys  ./intranet.woodytoys.zsk.key

5. Redémarrer le service Bind:
   service bind9 reload

Limiter l'accès

1. Aller dans le dossier contenant le fichier named.conf grâce à la commande:
   cd /etc/bind
2. Autoriser les IPs souhaiter en ajoutant au fichier:

allow-query {
		198.20.0.0/24; 
		198.20.1.0/24; 
		198.20.2.0/24; 
		198.20.3.0/24; 
		198.20.4.0/24; 
		198.20.5.0/24; 
};

résolveur

Le résolveur fonctionnant de la même manière que le SOA interne tous se qui est dit pour le SOA interne est aussi valable pour se dernier.
Ici nous allons simplement limiter l'accès de ce services aux IPs de l'entreprise car nous jugeons l'ajout d'un DNSSEC que peut utile car le service n'a aucun contact avec l'extérieur mais pour plus de sécurité il est possible d'en rajouté un en suivant la même procédure que pour le SOA interne.

Limiter l'accès

1. Aller dans le dossier contenant le fichier named.conf grâce à la commande:
   cd /etc/bind
2. Autoriser les IPs souhaiter en ajoutant au fichier:

allow-query {
		198.20.0.0/24; 
		198.20.1.0/24; 
		198.20.2.0/24; 
		198.20.3.0/24; 
		198.20.4.0/24; 
		198.20.5.0/24; 
};

web interne

Tout comme pour le SOA interne, l'environnement qu'utilise le Web interne étant un environnement de confiance (l'intranet), il n'est pas nécessaires d'installer des mesures de sécurité tel que HTTPS. Nous allons cependant limiter l'accès de ce service aux IPs de l'entreprise.

Limiter l'accès

1. Aller dans le dossier contenant le fichier intranet.conf grâce à la commande:
   cd /etc/
2. Autoriser les IPs souhaiter en ajoutant au fichier:

<RequireAny>
   Require ip 192.168.0.0/24
   Require ip 192.20.0.0/24
   Require ip 192.20.1.0/24
   Require ip 192.20.2.0/24
   Require ip 182.20.3.0/24
   Require ip 192.20.4.0/24
   Require ip 192.20.5.0/24
</RequireAny>

Mesures générales

Pour évité un maximum le DDOS ou le brut force des mots de passes il est important que le couple Firewall/Fail2ban protèges l'intégralité de nos services. Ici se serra le cas car nous les avons déjà installé sur nos VPS voir Sécurisation prototype.

De plus les services internes se trouvent en "trusted zone" et ne sont donc accessible que par les employés de l'entreprise. Ainsi le plus gros risque est en réalité une attaque interne. Il faut donc donné des droits seulement à des personnes de confiances et limiter l'accès de chaque utilisateur et ne leurs données accès seulement aux services qui leurs sont nécessaire.