How to secure your Internet domains

Intro

What would you do if the following happened to your organisation?

  • Your web sites have gone offline.
    or
    Your web sites have been replaced with malicious or offensive ones.

  • Your inbound emails have stopped being delivered.
    or
    Your inbound emails have have started being maliciously intercepted. This is allowing the attackers to, among other things, gain access to other accounts via password resets which can be considered as a data breach [1] and can even go as far as destroying someone’s digital life [2] or quite possibly identity theft.

  • Your outbound emails have stopped being delivered.

  • Attackers are sending emails as your staff members and systems to your staff members and customers / clients.

  • You’re unable to access your web-based systems.

We don’t like to scaremonger but that is the reality of what can happen if attackers get administrative access to your Internet domains. Granted, there are recovery processes but they take time and money and, by that point, the financial and reputational damage is already done. That’s why it’s so crucial to proactively secure your Internet domains.

Unfortunately, many don’t know where to start and most don’t even know what they don’t know.

Fortunately, these are the kinds of problems that we love to help with!

To understand how to secure Internet domains (as opposed to Active Directory domains, for example), we must first understand how the Internet DNS works, both at the technical and organisational levels.

However, if you search for information on the DNS hierarchy tree, you’ll find a lot of graphics depicting the generic technical side of things (root domain → Top-Level Domain → Second-Level Domain, etc) but little, if anything, on the Internet-specific and organisational side of things.

So, we decided to invest the time in creating a graphic of our own - one that depicts how the Internet DNS works [3] at the technical and organisational levels (in a relatively simplified way - it’s actually much more complicated). After many versions, we settled on the following:

Astrix’s graphic of the Internet Domain Name System (DNS) technical and organisational management hierarchy tree.

Any subsystem of the Internet DNS can be attacked and the chances of success tend to increase towards the bottom of the hierarchy because they’re the ones which are mostly likely to be fragmented, vulnerable, and administered by people who aren’t skilled in cybersecurity.

↑ Back to Index.

In hierarchies, entities towards the top have the most power and this is no different. We’ll be focusing on the user-controlled ones, what capabilities can be seriously abused if they get compromised, and what security features can differ between providers.

If your first thought was “What?!” then you’re not alone. That’s what we thought when we first discovered this and we’re still surprised that we’ve never seen anyone else report on this before.

As you can see in our Internet DNS hierarchy tree, the TLD registry account is the highest and most powerful user-controlled subsystem there is.

As we’re based in the United Kingdom, we’ll be focusing on “our” TLDs for now. You can find out who is the manager for your TLD at https://www.iana.org/domains/root/db.

When a UK second-level domain name (astrix.uk, for example) is registered or its registrant email address is changed, the system will automatically add it to a Nominet account (whether it previously existed or not) with a username that matches the registrant email address. MFA is available via one or more Time-based One-Time Password (TOTP) apps and brought to the user’s attention on sign-in but it is not mandatory.

Fortunately, registrant email addresses for UK domain names are not allowed to be in the public Whois databases [4] so no one can easily determine what the username is for your Nominet account but that doesn’t mean they can’t still be easily breached. If you’re unsure what the Nominet username / registrant email address is for your domain name then you can find out by signing into your registrar account.

Once signed into a Nominet account, you have the power to transfer its domain names to different registrar accounts and even different Nominet accounts with no additional verification - all that’s required is the payment of a £10 fee. We have personally tested this.

If you lose access to your registrar and your registry account then Nominet have a recovery process: Re-establish Identity [5].

The information on Nominet’s web page about the Re-establish Identity process (screenshots above) suggested that, as with the registrar change, no additional verification is performed so we reached out them for clarification who advised the following:

“As part of the re-establish of identity process, we will ask you to provide documentation to confirm that the request is being made by the domain name registrant. For example:

• For registered organisations, we will require a signed letter on business letterhead, which needs to include the domain name and the new email address that needs adding onto our database.

• For individuals we will require a proof of ID showing name and address, including a signed letter, which needs to include the domain name and the new email address that needs adding onto our database.
”
— Email from nominet@nominet.org.uk on 2019/12/30 at 17:15

Due to the sheer number of TLDs and registries, we’re unaware of any others that offer registry-level management but if you are then please let us know and we will be more than happy to investigate and update this post.

Once signed into a registrar account such as GoDaddy or namecheap, you effectively have the keys to the castle. Specifically, you have the power to:

  • Change the account’s credentials.

  • Add new administrators.

  • Transfer a domain name’s registration to a different account or registrar.

  • Change a domain name’s registrant information.

  • Change a domain name’s authoritative name servers.

  • Change DNS Resource Records (RRs) if the registrar’s authoritative name servers are being used.

Also, bear in mind that more advanced features such as Domain Name System Security Extensions (DNSSEC) are not supported by all registrars.

You can find out who is the registrar for your domain by using Whois web sites such as https://who.is/ or https://mxtoolbox.com/SuperTool.aspx?action=whois:.

Once signed into authoritative name servers such as GoDaddy, Cloudflare, or Amazon Route 53, you have the power to modify DNS Resource Records (RRs) and in turn:

  • Change which web sites are loaded (via A or CNAME).

  • Change where inbound emails are delivered (via MX).

  • Change what outbound systems are allowed to send emails (via @ and _dmarc TXT).

  • Digitally sign outbound email (via _domainkey TXT or CNAME).

  • Get publicly-trusted Certificate Authorities (CAs) to issue SSL / TLS certificates (via TXT or CNAME).

  • And more…

You can find out what the authoritative name servers are for your domains by using lookup tools such as https://www.whatsmydns.net/#NS.

Also, bear in mind that more advanced features such as Domain Name System Security Extensions (DNSSEC) are not supported by all name server providers [6].

Some authorities have a list of non-user-customisable email addresses that they consider as administrative for the domain. For example:

  • admin@. This one is commonly assigned to secretaries because they carry out “admin” (business administrative) work.

  • administrator@. This one is commonly used by IT support because they carry out system administrative work.

  • webmaster@.

  • postmaster@.

  • hostmaster@.

  • Registrant email address.

This is another thing that can be used to get SSL / TLS certificates issued by publicly-trusted Certificate Authorities (CAs).

Many organisations choose a TLD for aesthetic and usability reasons - it looks good in combination with their second-level domain and it’s easy to type and remember. Here are some common examples:

  • aka.ms (Microsoft)

  • db.tt (Dropbox)

  • last.fm

  • youtu.be

  • t.co (Twitter)

  • bit.ly

Usually, this won’t really be an issue but the choice could come with unexpected implications down the road. Country-code Top-Level Domains (ccTLDs) such as .uk and generic Top-Level Domains (gTLDs) such as .photography are managed by many different organisations [7] and, as such, their policies, operations, features, even potential sustainability, and, ultimately, security differ. For example:

  • .us (ccTLD for the United States of America) has Whois privacy forbidden but .uk (ccTLD for the United Kingdom) has Whois privacy enabled by default [8].

  • .uk is operated by Nominet who, as covered above, don’t require MFA on their registry account and who don’t require any additional verification to make changes to an account’s domains.

  • .ai (ccTLD of Anguilla) doesn’t support DNSSEC.

  • .bible is operated by the American Bible Society who apply a strict Acceptable Use Policy (AUP) and “reserves the right to discontinue, suspend or modify the services provided to any Domain Name in response to violations of this AUP” [9].

  • Conflict could impact the ability of an operator and, therefore, the ccTLD itself [10].

Now, here’s the first, aesthetically-pleasing list of domain names again but now with who the TLDs belong to and are managed by:

  • aka.ms (Microsoft): Uses ccTLD of Montserrat.

  • db.tt (Dropbox): Uses ccTLD of Trinidad and Tobago.

  • last.fm: Uses ccTLD of Federated States of Micronesia.

  • youtu.be: Uses ccTLD of Belgium.

  • t.co (Twitter): Uses ccTLD of Colombia.

  • bit.ly: Uses ccTLD of Libya.

Once a domain has been established, it is difficult to migrate away from it so it’s worth giving consideration to this from the start if possible.

↑ Back to Index.

After reading the systems section, hopefully you now understand why it’s critical to have strong security controls in place.

The security controls that we have detailed below should be applied to each and every one of the aforementioned systems. The underlying principle is the same as the proverb “A chain is only as strong as its weakest link”.

If your provider doesn’t offer or properly implement the security controls then that strongly suggests a lack of consideration for security in general and, as such, we strongly recommend migrating to one that does.

While this may seem like an odd security control, it is incredibly important and simple yet very difficult to implement.

One thing that our previous years as an IT Managed Service Provider (MSP) taught us was that organisations’ senior management make uninformed decisions and bring in the IT and security people too late.

When that is still the case, any attempts to improve security will probably be undermined so it’s important to get the right culture in place to begin with.

As we touched on in our post “Improving Cyber Essentials” → section “Improvement #6 of #7: Full cloud cover”, passwords are no longer sufficient to protect accounts. This is especially true for administrative accounts and when the authentication mechanism is publicly-accessible, as is the case with most cloud services.

The reason for this is that data breaches keep happening more and more frequently and the exposed credentials (hundreds of millions of real-life usernames and passwords) fuel the devastatingly-successful attacks such as credential stuffing and password spraying. After all, we all use different keys for our doors in part because we know what could happen if we didn’t.

This problem is largely solved by utilising Multi-Factor Authentication (MFA), also known as the subset Two-Factor Authentication (TFA / 2FA) or, somewhat erroneously, Two-Step Verification (TSV / 2SV). Basically, the strength of an authentication system is significantly increased each time that an additional factor is added:

  1. Knowledge. This is something that the user knows. The most common form of this factor are usernames, passwords, and PINs.

  2. Possession. This is something that the user physically owns. The most common form of this factor are mobile phones.

  3. Inherence. This is something that is integral to the user themselves. The most common forms of this factor are fingerprints and faces.

The most common form of TFA is knowledge + possession so this is what we’ll be focusing on.

People are actually more familiar with this than they realise. The chip & PIN payment method is actually TFA (possession of the card + knowledge of the code) and it’s why the contactless method has a £30 limit (because it’s possession-only) but Apple Pay and Google Pay have significantly higher monetary limits (because it’s possession of the smartphone + knowledge of the passcode or inherence of the fingerprint or face).

Regarding IT / cybersecurity, we’ve created the following table as a quick summary of the possession methods:

MFA method → FIDO2 App notification App TOTP Cellular TOTP
Free? No Depends Yes Yes
Easy set up? Yes No No Yes
Easy use? Yes Yes No Yes
Works offline? Yes No Yes No
MITM-able? No Yes Yes Yes
Phish-able? No No Yes Yes

We have created a detailed summary of the possession methods below. If you’re already familiar with these then feel free to jump to the next section.

In decreasing order of security (but, unfortunately, also decreasing order of availability on systems), these are as follows.

FIDO2

FIDO2 is also known as a “security key”, as a “hardware token”, as its predecessor FIDO Universal 2nd Factor (U2F), or even as its web implementation WebAuthn.

The major upside of this method is that it is both more secure and more convenient - a very rare occurrence in cybersecurity! This is because (1) it cannot be phished or proxied as it uses public-key cryptography between the device and the server and (2) it’s extremely easy to use as all you have to do is plug it in and touch it (to prove physical access)!

Adding and using a security key on a Google Account in ~30 seconds.

The only downside is that you have to purchase them but they’re fairly cost-effective and certainly much cheaper than a data breach fine.

The most common form of this is Yubico’s YubiKey products which work across all sorts of devices (via USB Type A, USB Type C, Lightning, NFC, etc) and the cheapest costs as little as $20.

 

Yubico’s YubiKey product line.

 

App-based push notification

The main upsides of this method are that it’s free and, compared to other app-based methods, it tends to be slightly better because the user doesn’t have to remember the app, there’s no code to memorise, and it gives additional information on the sign-in attempt such as location and IP address.

The main downsides to this method are as follows:

  • It’s still vulnerable to Man-in-the-Middle (MITM) attacks (you can be tricked into entering your credentials into a malicious system which the attackers will silently pass on to the legitimate system and you’ll still receive and approve the sign-in request).

  • It requires a smartphone and Internet access.

  • Each service provider such as Google and Microsoft will have their own app and process so it’s inconsistent and an extra layer of complexity for users.

App-based Time-based One-Time Password (TOTP)

The main upsides of this method are that it’s free, widely supported, and works offline.

The main downsides of this method are it’s vulnerable to phishing and Man-in-the-Middle (MITM) attacks (you can be tricked into entering your credentials into a malicious system which the attackers will pass on to the legitimate system) and it requires a smartphone.

The most common form of this is Google Authenticator and Authy. Many password managers also have this functionality.

 

Google Authenticator on Android.

 

Cellular-based Time-based One-Time Password (TOTP)

This method is delivered via SMS / text message or phone call.

The main upsides of this method are that it’s free, fairly widely supported, and everyone is familiar with how to use a phone.

The main downsides of this method are it’s vulnerable to phishing and Man-in-the-Middle (MITM) attacks (you can be tricked into entering your credentials into a malicious system which the attackers will silently pass on to the legitimate system) and it requires a phone with signal.

 

A SMS / text message for a Microsoft Account.

 

Most systems have a recovery procedure to restore access for someone and how this is achieved is important because it’s a good indicator of the cybersecurity practices of the provider.

For a generic example, if you phone technical support to get a password reset done and, without any verification that you are who you say you are, they simply set a new one and read it out to you then chances are that their general cybersecurity practices aren’t good.

For a real-life example, compare GoDaddy’s recovery procedure and 123 Reg’s recovery procedure.

Any good system will have the option to use multiple admin accounts in order to comply with best practices such as not sharing accounts / passwords to preserve the audit trail, using non-shared and strong MFA, not using generic usernames, etc.

The old best practices are for passwords to be relatively short and complex. For example, “g^!4$3J!“.

These days, the new best practices are for passwords to be long and simple - passphrases. The UK’s NCSC advise using three random words [11]. For example:

  • “Abstain Squiggle Petition”

  • “Cautious Banknote Extending”

  • “Bacteria Spotlight Nickname”

  • “Relight Kerosene Dab”

  • “Freemason Energy Revenue”

(Yes, all of those were randomly-generated.)

The reason for this is that they’re actually stronger and easier to remember and, as a result, less likely to be re-used.

This is still recommended even if you’re using TFA / MFA because a weak password is effectively just Single- / One-Factor Authentication.

To assess the strength of your passwords, you can use a strength checker such as https://howsecureismypassword.net/ and https://nordpass.com/secure-password/ but take the results with a pinch of salt as every password strength checker works differently.

Also, we must reiterate that each password should be entirely unique and un-guessable.

If you’re missing security patches / updates then the aforementioned security controls could simply be bypassed so it’s critical to ensure that they’re installed (and, if required, activated / opted into) in a timely manner. The UK’s NCSC recommends within 14 days [12].

↑ Back to Index.

Social

Partners and Memberships