Documentation Ns.Tools

Cette page vous explique l'ensemble des tests qui sont réalisés sur NStools. Les tests sont catégorisés en 7 sections. Ns.Tools va analyser l'IP ou domaine avec pas moins de 93 tests.

Dns

La version BIND est caché
La version Bind ne doit pas être visible car il y a un risque qu'une personne malveillante fasse une recherche sur des éventuelles failles de sécurité propre à la version trouvée.
Le domaine a au moins 2 serveurs DNS
Dans le but d'obtenir une très haute disponibilité, il est fortement recommandé par la RFC d'avoir au moins 2 serveurs pour les DNS.
Tous les serveurs DNS répondent
Tous les serveurs DNS doivent être accessible et accepter une requête publique.
Tous les serveurs retournent un succès
Il est important que tous les serveurs retournent un code de succès.
Les réponses ne sont pas de type CNAME ou A
La réponse ne doit pas être de type CNAME ou A.
Les IPs des serveurs DNS sont différentes
Les IPs des serveurs DNS doivent être différentes dans le but d'augmenter le taux de disponibilité afin que celui-ci soit au plus haut.
Les IPs des serveurs DNS sont d'une class C différente
La classe C de chaque IP doit être différente pour que les serveurs ne se trouvent pas dans la même baie et qu'il y ait un risque d'indisponibilité.
Les serveurs DNS sont synchronisés
La synchronisation des serveurs DNS se doit d'être parfaite pour éviter tout problème de résolution dns. Les serveurs doivent donc donner la même réponse lorsqu'on leur demande "quels sont les serveurs DNS du domaine?".
Les SOA sont synchronisés
Le SOA répondu par les serveurs DNS doit être identique pour chaque serveur. Les informations les plus importantes sont le serveur maître, l'adresse e-mail du contact et le serial.
L'email dans le SOA est valide
Une adresse e-mail doit respecter certaines conditions pour être valide, conformément à la RFC 5322.
La valeur du Refresh dans le SOA est valide
La valeur de rafraîchissement doit être comprise entre 1200 et 43200.
La valeur de Retry, Refresh et Expire est correcte
La valeur de Retry doit être inférieur à celle de Refresh qui elle même doit être inférieur à Expire (retry
Les serveurs DNS ne sont pas Open Relay
Les résolveurs DNS qui autorisent les requêtes provenant de toutes les adresses IP et qui sont exposés à Internet peuvent être attaqués et utilisés pour mener des attaques par déni de service (DoS) par des personnes malveillantes.
Le transfert de zone n'est pas activé
Un attaquant peut utiliser un transfert de zone contenant un code malveillant ou un format inapproprié qui bloque un serveur DNS vulnérable à ce type d'attaque, ce qui entraîne un DoS qui déstabilise les services DNS. Cela permet la récupération de l'ensemble des informations de la zone DNS. Le test peut être effectué à l'aide de la commande : #host -T axfr ou #dig axfr.
Les requêtes récursives sont désactivées
Avoir un serveur DNS qui autorise les requêtes récursives est un risque de sécurité, une attaque DDOS peut être effectuée.
Les mêmes enregistrement MX sont retournés
Il est extrêmement important que chaque DNS renvoie les mêmes enregistrements MX afin d'éviter de contacter un serveur SMTP qui n'existe plus.
Les enregistrements GLUE sont configurés pour les NS de ce domaine
Si le DNS est un hôte de son domaine, il est obligatoire de définir le GLUE. Ceci évite alors les références circulaires.
Les serveurs DNS ne sont pas des CNAME
L'enregistrement CNAME, autre que d'être obligé de pointer vers un nom au lieu d'une adresse IP, a une autre limitation importante: un enregistrement CNAME n'est pas autorisé à coexister avec d'autres données.
Les IPs des serveurs DNS ne sont pas privées
Il est strictement interdit d'avoir des IPs privées dans ses DNS
Est-ce que la version BIND est visible depuis Nmap ?
La version Bind ne doit pas être visible car il y a un risque qu'une personne malveillante fasse une recherche sur des éventuelles failles de sécurité propre à la version trouvée.

Mail

Les enregistrements MX sont FQDN
Le champ MX doit être un domaine et non une IP.
Les enregistrements MX ne sont pas des CNAME
Selon les RFC 1034 et 2181, les enregistrements CNAME ne doivent pas être utilisés avec NS et MX
Nombre de serveur SMTP
Le domaine devrait avoir au moins 2 serveurs SMTP selon le RFC
Les serveurs SMTP sont accessible
Les serveurs SMTP répertoriés dans la zone DNS doivent être accessibles. Dans le cas contraire, les e-mails risquent d'être perdus
Les IPs des MX sont différentes
Si le domaine comporte plusieurs serveurs SMTP, ceux-ci doit posséder une adresse IP différente car si une adresse IP n'est plus accessible c'est l'ensemble des serveurs de messagerie qui ne le seront plus.
Les IPs des MX sont d'une class C différente
La classe C de toutes les IPs doit être différente afin que les serveurs ne se retrouvent pas sur la même baie
Les IPs des MX ont un Reverse
Lorsqu'un serveur d'envoi établit une connexion avec le serveur destinataire, le serveur destinataire note l'adresse IP d'envoi et effectue une recherche inversée, appelée recherche PTR, portant le nom du type d'enregistrement DNS utilisé. Si le résultat de la recherche inversée correspond au résultat d'une recherche DNS directe, il est beaucoup plus probable que le message soit légitime. Si l'adresse IP ne correspond pas, il est beaucoup plus probable que l'adresse d'envoi ait été usurpée et donc beaucoup plus susceptible d'être indésirable et pourrait être considérée comme du spam.
La HELO est acceptée
Selon la RFC 2181, le serveur SMTP devrait accepter la commande HELO
La EHLO est acceptée
Selon la RFC 2181, le serveur SMTP devrait accepter la commande EHLO
La STARTTLS est acceptée
STARTTLS transforme une connexion non chiffrée en une connexion sécurisée et donc chiffrée.
La EXPN est refusée
La commande EXPN est maintenant considérée comme un risque de sécurité, les spammers pouvant récupérer des adresses e-mail valides via chaque liste de diffusion.
La VRFY est refusée
Comme la commande EXPN, VRFY est utilisé par les spammeurs pour vérifier une adresse.
Les serveurs MX ne sont pas OPEN RELAY
Si un serveur est Open Relay, il existe un risque que les spammeurs utilisent votre serveur pour envoyer des messages illégitimes.
Les serveurs MX acceptent l'adresse abuse@
Selon la RFC 2142, le serveur SMTP doit accepter abuse@yourDomain en tant que destinataire.
Les serveurs MX acceptent l'adresse postmaster@
Selon la RFC 5321, le serveur SMTP doit accepter postmaster@yourDomain en tant que destinataire.
Le banner retourne un code 2xx ou 4xx
La bannière doit renvoyer un code valide(2xx) ou temporaire (4xx).
Le banner retourne le nom du serveur
La bannière doit contenir le nom du serveur
Le type du serveur SMTP est caché
Il existe un risque d'afficher le type et la version du serveur, car les utilisateurs peuvent trouver une faille pour une version spécifique et l'utiliser
Un SPF est configuré pour ce domaine
Pour éviter l'usurpation d'identité, il est fortement recommandé de configurer un SPF.
Le SPF est un enregistrement TXT
L'enregistrement SPF est devenu obsolète et est donc à proscrire. Le SPF doit être configuré dans un enregistrement TXT car de nombreux serveurs ne prennent plus en charges l'enregistrement SPF
Le domaine n'a qu'un seul enregistrement SPF
Pour éviter les problèmes avec le SPF, il est fortement recommandé de n'en configurer qu'un seul.
Les enregistrements SPF de type TXT et SPF sont les mêmes
L'enregistrement SPF est devenu obsolète, s'il est configuré, il doit être le même que celui présent dans l'enregistrement TXT
La version du SPF est indiquée
Selon la RFC, la version du SPF doit être spécifiée.
La position de la version est correcte
Le SPF doit commencer avec la version.
Le paramètre "all" existe dans le SPF
Selon la RFC, le mécanisme "all" doit être spécifié dans l'enregistrement SPF sauf si le mécanisme "redirect" est présent.
Le paramètre "all" est en dernière position dans le SPF
Le mécanisme "all" doit être le dernier paramètre du champ SPF. Vérifiez que vous n'ayez pas de doublons dans le champ SPF.
La syntaxe des IPv4 et des IPv6 est correcte
Les IPs indiquées dans le SPF doivent être valide sinon le SPF devient inutile.
Le SPF n'a pas de paramètre PTR
Le paramètre PTR est devenue obsolète, on ne devrait pas le trouver dans le SPF.
Le paramètre "redirect" est en dernière position dans le SPF
Le mécanisme "redirect" doit être le dernier paramètre du champ SPF. Vérifiez que vous n'ayez pas de doublons dans le champ SPF.
Un DMARC est configuré pour ce domaine
Pour éviter l'usurpation d'identité, il est fortement recommandé de configurer un DMARC.
Le domaine possède un seul DMARC
Pour éviter les problèmes avec le DMARC, il est fortement recommandé de n'en configurer qu'un seul.
Validation du DMARC
Si le DARMC est mal configuré, il y a un risque que les serveurs destinataires n'acceptent pas vos mails.
La version du DMARC existe
Selon la section 6.3 de la RFC 7489, la version DMARC est requise.
La position de la version est correcte
Selon la section 6.3 de la RFC 7489, la version DMARC doit être le premier paramètre du champ.
La procédure du DMARC existe
Selon la section 6.3 de la RFC 7489, le paramètre Procedure est requis.
Le champ DMARC "p" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre Procedure doit être none, quarantaine ou reject.
Le champ DMARC "sp" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre Subdomain Procedure doit être none, quarantaine ou reject.
Le champ DMARC "pct" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre Percentage doit être comprise entre 0 et 100.
Le champ DMARC "adkim" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre Adkim doit être R ou S.
Le champ DMARC "aspf" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre Aspf doit être R ou S.
Le champ DMARC "rf" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre RF doit être AFRF ou IODEF.
Le champ DMARC "ri" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre RI doit être un entier.
Le champ DMARC "ruf" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre RUF doit être un adresse email valide.
Le champ DMARC "rua" est valide
Selon la section 6.3 de la RFC 7489, la valeur du paramètre RUA doit être un adresse email valide.
Un DKIM est configuré pour ce domaine
Pour éviter l'usurpation d'identité, il est fortement recommandé de configurer un DKIM.
La version du DKIM existe
Selon la section 3.6.1 de la RFC 6376, la version DKIM est requise.
Le paramètre Service Type est valide
Ce paramètre est optionnel mais s'il est utilisé, il doit être égal à "*" ou "email".
Le paramètre Testing est valide
Ce paramètre est optionnel mais s'il est utilisé, il doit être égal à "s", "y" ou "y:s".
La clé publique est valide
Selon la section 3.6.1 de la RFC 6376, la clé publique est requis et doit être valide.
La clé publique est sécurisée
La taille de la clé doit être supérieur à 1024 bits.

Domain

Les serveurs DNS sont les mêmes dans la descente de l'arbre DNS et dans le Whois
Il est primordial que les DNS trouvés dans le WHOIS soient identiques à ceux retournés par une requête de résolution DNS.
Le domaine n'est pas blacklisté
Un domaine ne doit pas être blacklisté sinon celui-ci il sera pénalisé pour le référencement et la délivrabilité des emails.
Le domaine n'est pas listé dans VirusTotal
Virus Total analyse votre domaine ou votre adresse IP avec 66 antivirus.
Le domaine n'est pas listé dans Google Safe Browsing
Google Safe Browsing catégorise un domaine comme étant mauvais si un élément suspect est détecté.
Le domaine possède une bonne réputation sur Web Of Trust
Web Of Trust évalue des milliers de sites Web et trouve des menaces si elles existent.

Ip

L'IP n'est pas blacklistée
Une IP ne doit pas être blacklistée sinon celle-ci sera pénalisée pour le référencement et la délivrabilité des emails.

Web

Le domaine possède un champ A
Le domaine doit avoir un champ A pour que le site soit accessible.
Le domaine possède un champ AAAA
Il est fortement recommandé d'avoir un IPv6 pour le site Web.
L'hôte WWW possède un champ A
L'hôte WWW n'est pas requis pour un site Web, mais il vaut mieux en avoir un.
L'hôte WWW possède un champ AAAA
Si vous configurez un hôte WWW pour votre site Web, il est recommandé d'ajouter une adresse IPv6.
Le port HTTP (80) est ouvert
Ce test vérifie la présence d'un site internet pour l'IP ou le domaine donné. Puis scanne le port 80(HTTP). Si le domaine ou l'IP renvoient vers un site web alors le port 80 doit être ouvert afin qu'il puisse être accessible depuis un navigateur. Sinon le port 80 doit être fermé.
Le port HTTPS (443) est ouvert
Ce test vérifie la présence d'un site internet pour l'IP ou le domaine donné. Puis scanne le port 443 (HTTPS). Si le domaine ou l'IP renvoient vers un site web alors le port 443 doit être ouvert afin qu'il puisse être accessible depuis un navigateur. Sinon le port 443 doit être fermé.
La version du serveur est caché
Pour éviter de donner des détails aux personnes malveillantes, la version de la technologie qui prend en charge l'application ne doit pas être visible.
La technologie pour faire tourner l'application est cachée
Pour éviter de donner des détails aux personnes malveillantes, la version de la technologie qui prend en charge l'application ne doit pas être visible.
Les cookies sont sécurisés
L'utilisation de l'instruction "HttpOnly" empêche quelqu'un d'accéder aux cookies via Javascript. Le paramètre "Secure" vous permettra d'empêcher qu'un cookie ne soit jamais communiqué en HTTP simple. (RFC 6265 section 8.3).
L'entête X-XSS-Protection est présente
L'entête de réponse HTTP X-XSS-Protection est une fonctionnalité d'Internet Explorer, de Chrome et de Safari qui empêche le chargement des pages lorsqu'elles détectent des attaques XSS (Cross-Site Scripting).
L'entête Content Security Policy est présente
L'entête HTTP Content-Security-Policy permet aux administrateurs de site Web de contrôler les ressources que l'agent utilisateur est autorisé à charger pour une page donnée. À quelques exceptions près, les stratégies impliquent principalement la spécification des origines du serveur et des points de terminaison du script. Cela permet de se prémunir contre les attaques de script XSS.
L'entête Content Type Options est présente
Les navigateur ont la possibilité "d'aspirer" des fichiers qui n'ont pas de type MIME correct afin de les exécuter. Si un fichier contient du javascript cela pourrait créer une faille XSS. Il est possible d'empêcher cela en ajoutant la valeur "nosniff" à l'entête X-Content-Type-Options.

Whois

Les DNS du WHOIS sont-ils les mêmes que ceux trouvés via l'arbre DNS ?
Il est primordial que les DNS trouvés dans le WHOIS soient identiques à ceux retournés par une requête de résolution DNS.