Chess industry this pool of water how deep, engaged in the people understand. DDoS attacks that are commonplace, but the most people's scalp numb is often the kind of “silent” tricks - such as DNS hijacking. Players obviously enter your official website address, but the results were directed to an identical phishing site, account passwords, recharge amount instantly be raked over. This is more disgusting than directly paralyzing the service, belonging to the murder of the heart.
I ate this kind of loss in the early years. At that time, I thought that the server security to do iron bucket general, all kinds of high defense, WAF pile full, the result of the attacker did not touch my server, direct detour, on my DNS parsing tampering. Users simply can't get to the door of my server, halfway to be abducted. During that period of time, the complaints were overwhelming, all of them said that the recharge did not arrive at the account, logging in abnormally, and only after half a day of investigation did they react: the DNS was poisoned.
DNS is the “phone book” of the Internet, responsible for translating domain names into IP addresses. However, the traditional DNS query process is basically in plaintext and lacks authentication mechanisms - it's like asking a random person on the street for directions, and then the other person points you in the wrong direction and you don't even know it. A hijacker can tamper with the results of a DNS query at any point in the process (local cache, recursive resolver, authoritative server).
Especially in the chess business, the motivation to attack is too strong. Hijacking by black-ops gangs is directly profitable, and hijacking by competitors can pry away your users. I have actually tested, even just a short time to resolve to the wrong IP, within half an hour can lose a lot of active users and recharge flow. Don't believe in the “just use public DNS” nonsense, 8.8.8.8 and 114.114.114.114 are still at risk of being contaminated.
To really prevent DNS hijacking, you have to start at two core levels: aRedundant resolution of multiple DNS linesThe other isDNSSEC signature verificationThe combination of these two tactics is equivalent to both multiple insurance policies for your domain and digital fingerprinting of the resolution process. The combination of these two tactics amounts to both multiple insurance policies for your domain name and digital fingerprinting verification of the resolution process.
Let's start with multi-DNS lines. These days, it's a gamble to host resolution services with only one provider. My current strategy is to use at least two or more DNS service providers at the same time, and require a high defense CDN to support multiple lines of resolution switching. For example, I use CDN5 for primary resolution, CDN07 for backup resolution, and another 08Host as a backing. Note that it is not simply set a few NS records and that's it, but configure thePrioritization and health screening。
Taking the configuration of CDN5, I would set up failover automation in its console:
This configuration means that the primary DNS line will do a health check every 30 seconds, and if the test fails for 2 consecutive times, it automatically switches to the backup line. In the real test, even if the main line is hijacked or polluted, the backup line can hold up to normal resolution. But the core of multi-line isheterogeneous service--Don't go with multiple brands from the same company, that's likely to share infrastructure and hang it all together.
However, multiple lines are just “redundancy” and cannot prevent “tampering”. What can really prevent resolution forgery from the root is DNSSEC (Domain Name System Security Extensions). DNSSEC (Domain Name System Security Extensions), which digitally signs DNS records through asymmetric encryption, and the recursive server verifies that the signature passes before returning the resolution result. If the signature does not match, it means that the record has been tampered with, and the response will be rejected directly.
Deploying DNSSEC is slightly more of a gateway, but definitely worth it. You need to enable DNSSEC support at the domain registrar first (some domestic vendors hide it a bit deeper, you have to find customer service to open it), and then generate key pairs:
After generating, you get the public and private keys, the private key is kept by yourself and the public key needs to be uploaded to the DNS console and added to the DS record (Delegation Signer) of the domain name. The registrar needs to submit the DS record to the registry of the top level domain (e.g. .com). The complete chained authentication is set up.
But DNSSEC has a pit: not all CDNs support it perfectly. Some small factory high defense CDN in order to save resources, recursive servers do not verify DNSSEC signatures. I have stepped on the mine, and I will definitely use the dig command to test it when I choose a model later:
If there is `ad` (authentic data) flag in the return result, it means that the CDN node fully supports DNSSEC authentication. At present, CDN5 and 08Host have the most stable DNSSEC support, and CDN07 is occasionally lazy in some edge nodes without verification.
In addition to the technical tools, you have to stay behind on the business level. I've made business-critical (e.g., top-up pages)Secondary resolution checking: After the client acquires an IP for the first time, it verifies that the IP is legitimate in reverse through an encrypted channel to the business server. If it is hijacked, at least it will alert and block the transaction in time. The code level probably looks like this:
Lastly, to be honest, the essence of DNS security is the chain of trust, and high-defense CDN in this ring can never be dragged behind. I must look at three points when selecting: whether to support multi-DNS provider access, whether the whole node to open DNSSEC authentication, whether the resolution of anomalies in real-time alarms. Those who do not even let you configure the DS record CDN vendors, directly pass out.
The chess industry itself is sensitive, and attackers are always looking for shortcomings. The server defense is again hard, and the DNS leakage is also in vain. Multi-line parsing + DNSSEC + business layer verification, these three axes down, not to say foolproof, but at least can make 99% DNS hijacking gangs take the initiative to bypass. The rest of the 1%, that may have to be physically super.
Oh yeah, and regularly measure your domain resolution health with tools like `dnsviz.net` or `cloudflare-dns.com/check`. Don't wait for users to complain - these days, even CDNs have to be “teammate-proof”.
