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 94 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 <refresh <expire).
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 doit avoir au moins 2 serveurs SMTP selon le RFC. Note : Vous pouvez utiliser un service comme altospam pour résoudre ce problème. Cliquez sur le lien ci-dessous pour en savoir plus
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 connexion sécurisée. Note : Vous pouvez utiliser un service comme altospam pour résoudre ce problème. Cliquez sur le lien ci-dessous pour en savoir plus
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.
Le PTR doit être placé obligatoirement avant l'entrée all: Le mécanisme "PTR" 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: Il est fortement recommandé de configurer DKIM. Remarque : Vous pouvez utiliser un service comme Mailout pour résoudre ce problème. Cliquez sur le lien ci-dessous pour en savoir plus
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.

Domaine

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.