Quelle est la profondeur de l'eau dans l'industrie des échecs, ceux qui s'y sont engagés comprennent que les attaques DDoS sont monnaie courante, mais ce qui engourdit le cuir chevelu des gens, c'est souvent le genre d'astuces “silencieuses” - telles que le détournement de DNS. Les joueurs entrent évidemment l'adresse de leur site web officiel, mais les résultats sont dirigés vers un site de phishing identique, les mots de passe des comptes, le montant de la recharge sont instantanément ratissés. C'est plus dégoûtant que de paralyser directement le service, cela relève de l'assassinat du cœur.
J'ai subi ce type de perte dans les premières années. À l'époque, je pensais que la sécurité du serveur pour faire le seau de fer en général, toutes sortes de défense élevée, WAF pile pleine, le résultat de l'attaquant n'a pas touché mon serveur, détour direct, sur ma résolution DNS tampering. Les utilisateurs ne peuvent tout simplement pas accéder à la porte de mon serveur, à mi-chemin d'être enlevés. Pendant cette période, les plaintes étaient nombreuses, toutes disaient que la recharge n'arrivait pas, login anormal, et ce n'est qu'après une demi-journée d'enquête qu'ils ont réagi : le DNS était empoisonné.
Le DNS est l“”annuaire" de l'internet, chargé de traduire les noms de domaine en adresses IP. Cependant, le processus traditionnel de requête DNS est essentiellement en clair et manque de mécanismes d'authentification - c'est comme si vous demandiez votre chemin à une personne au hasard dans la rue et que cette personne vous indiquait la mauvaise direction sans que vous le sachiez. Un pirate peut altérer les résultats d'une requête DNS à n'importe quel stade du processus (cache local, résolveur récursif, serveur faisant autorité).
Dans le domaine des échecs en particulier, la motivation pour attaquer est trop forte. Le détournement par des groupes de chantage est directement rentable, et le détournement par des concurrents peut vous priver de vos utilisateurs. J'ai en fait testé que même s'il ne s'agit que d'un court laps de temps pour résoudre la mauvaise IP, en l'espace d'une demi-heure, on peut perdre un grand nombre d'utilisateurs actifs et de flux de recharge. Ne croyez pas à l'absurdité du “il suffit d'utiliser les DNS publics”, 8.8.8.8 et 114.114.114.114 risquent toujours d'être contaminés.
Pour empêcher réellement le détournement de DNS, il faut commencer à deux niveaux fondamentaux : aRésolution redondante de plusieurs lignes DNSL'autre estVérification de la signature DNSSECLa combinaison de ces deux tactiques équivaut à la fois à des polices d'assurance multiples pour votre nom de domaine et à une vérification par empreinte numérique du processus de résolution. La combinaison de ces deux tactiques équivaut à la fois à des polices d'assurance multiples pour votre nom de domaine et à une vérification par empreinte digitale du processus de résolution.
Commençons par les lignes multi-DNS. De nos jours, il est risqué d'héberger des services de résolution chez un seul fournisseur. Ma stratégie actuelle est d'utiliser au moins deux fournisseurs de services DNS en même temps, et d'avoir besoin d'un CDN à haute défense pour prendre en charge la commutation de résolution multi-lignes. Par exemple, j'utilise CDN5 pour la résolution primaire, CDN07 pour la résolution de secours, et un autre 08Host pour la résolution de secours. Notez qu'il ne s'agit pas simplement de mettre en place quelques enregistrements NS et c'est tout, mais de configurer l'ongletPriorités et bilans de santé。
En prenant la configuration de CDN5, je mettrais en place l'automatisation du basculement dans sa console :
Cette configuration signifie que la ligne DNS principale effectuera un contrôle de santé toutes les 30 secondes, et si le test échoue deux fois de suite, elle basculera automatiquement sur la ligne de secours. Dans le test réel, même si la ligne principale est détournée ou polluée, la ligne de secours peut maintenir une résolution normale. Mais le cœur de la multi-ligne estservice hétérogène--N'optez pas pour plusieurs marques de la même entreprise, qui sont susceptibles de partager l'infrastructure et de tout mélanger.
Cependant, les lignes multiples ne sont qu'une “redondance”, et non une protection contre la “falsification”. Ce qui peut réellement empêcher la falsification de la résolution à partir de la racine est DNSSEC (Domain Name System Security Extensions). Il utilise le cryptage asymétrique pour signer numériquement les enregistrements DNS, et le serveur récursif vérifie que la signature est valide avant de renvoyer le résultat de la résolution. Si la signature ne correspond pas, cela signifie que l'enregistrement a été falsifié et la réponse sera rejetée directement.
Le déploiement de DNSSEC est un peu plus difficile, mais il en vaut vraiment la peine. Vous devez d'abord activer le support DNSSEC auprès du bureau d'enregistrement du domaine (certains fournisseurs nationaux le cachent un peu plus profondément, vous devez trouver le service clientèle pour l'ouvrir), puis générer des paires de clés :
Après la génération, vous obtenez les clés publique et privée, la clé privée est conservée pour vous-même et la clé publique doit être téléchargée dans la console DNS et ajoutée à l'enregistrement DS (Delegation Signer) du nom de domaine. Le bureau d'enregistrement doit soumettre l'enregistrement DS au registre du domaine de premier niveau (par ex. .com). L'authentification en chaîne complète est mise en place.
Mais DNSSEC présente un inconvénient : tous les CDN ne le prennent pas parfaitement en charge. Afin d'économiser des ressources, certains serveurs récursifs de CDN haute-défense de petite taille ne vérifient pas du tout les signatures DNSSEC. J'ai marché sur la mine, et j'utiliserai certainement la commande dig pour la tester lorsque je choisirai un modèle plus tard :
S'il y a un drapeau `ad` (données authentiques) dans le résultat de retour, cela signifie que le nœud CDN supporte entièrement l'authentification DNSSEC. Actuellement, CDN5 et 08Host ont le support DNSSEC le plus stable, et CDN07 est occasionnellement paresseux dans certains nœuds de bordure sans vérification.
En plus des outils techniques, il faut rester en retrait au niveau de l'entreprise. J'ai fait en sorte que les pages critiques pour l'entreprise (par exemple, les pages de recharge) soient accessibles à tous les utilisateurs.Contrôle de la résolution secondaireAprès avoir acquis une adresse IP pour la première fois, le client vérifie que l'adresse IP est légitime en sens inverse, par l'intermédiaire d'un canal crypté vers le serveur commercial. S'il est détourné, il sera au moins alerté et bloquera la transaction à temps. Le code se présente comme suit :
Enfin, pour être honnête, l'essence de la sécurité DNS est la chaîne de confiance, et le CDN de haute défense ne doit pas traîner les pieds dans ce domaine. Je dois me pencher sur la sélection de trois points : la prise en charge de l'accès multi-fournisseurs DNS, l'ouverture de l'authentification DNSSEC pour l'ensemble du nœud, la résolution des anomalies par des alarmes en temps réel. Ceux qui ne vous permettent même pas de configurer l'enregistrement DS des fournisseurs CDN, passent directement à la trappe.
Le secteur des échecs lui-même est sensible et les attaquants sont toujours à la recherche de failles. La défense du serveur est encore une fois difficile, et la fuite de DNS est également vaine. Multi-line parsing + DNSSEC + business layer verification, ces trois axes en bas, sans dire infaillible, mais au moins peut faire 99% gangs DNS hijacking prendre l'initiative de contourner. Le reste du 1% devra peut-être être dépassé physiquement.
Oh oui, et mesurez régulièrement la santé de votre résolution de domaine avec des outils comme `dnsviz.net` ou `cloudflare-dns.com/check`. N'attendez pas que les utilisateurs se plaignent - de nos jours, même les CDN doivent être “à l'épreuve des mats”.
