Did you know that a startling 1 in 3 businesses experience some form of domain security breach each year? In the digital era, it’s more important than ever for companies to safeguard their domain name. That’s why Techary’s InfoSec team is here to guide you through the crucial steps to enhance your domain security, whether you’re an SME or mid-market firm still learning the ropes or a seasoned professional looking to brush up on your knowledge.
We could write a whole series on domain-related security topics, within this post, we’ll be highlighting the key considerations firms should consider for their domain name, across three key sections:
- Core Domain Privacy
- Connecting apps and services, DNS hygiene
- Best practices for BAU / internal staff
This post is also targeted at SMEs / mid-market firms, who may not have considered the security aspects of their domain extensively. For security professionals, the content may appear to cover basic points, but our aim is to increase awareness and provide helpful information for those who have not considered or implemented any domain security previously.
Core Domain Privacy
Your domain is publicly available on the internet, it needs to be available for others to navigate to your website or to e-mail your team members. This exposure to the internet means that the attack surface is expanded to anyone with access to the internet, as such, this increases the risk of domains being targeted or exploited by cybercriminals.
Domain names are regulated by ICANN and only domain “Registrars” are able to officially register domain names with the “internet”.
Domain Name ---> Registrar ---> Customer (Domain Owner)
Your domain will be registered via a registrar (such as GoDaddy, XXX), but you could also have your domain purchased on your behalf, by a third party, such as your marketing agency, IT provider or by your website developer.
There are a few considerations to make when purchasing the domain, as we progress through the blog you’ll hopefully gain some insight that it’s not as straightforward as just purchasing your domain and you start running services, at least not if you want to consider the wider security posture of your domain setup.
When a domain is registered, the registrar provides certain details to ICANN for the domain registration, including four key components of contact information:
- Registrant
- Administrative
- Technical
- Billing
When providing this information, it’s important to remember this data will be available for anyone to look up, this is one of the key considerations for domain privacy, the information associated with the domain registration is publicly available for anyone to look up and find details. You can perform a lookup, on any domain, using the ICANN Lookup tool — ICANN Lookup. This is referred to as WHOIS — and is a service supplied to be able to look up any domain registrant. The concept started with the safeguarding of domains, to allow authorities to be able to trace the ownership of domains publishing malicious content or involved in criminal activity. Lately, this has evolved to become a way for threat actors to harvest contact information and data for corporate contacts, visible as various contacts registered to the domain.
Techary Tip: If you do enter registrant details, you should anonymize any data you input, use generic business-wide contact details (such as [email protected]), and do not use or list personal contacts.
Some registrants offer a proxy service, to mask the contact information of the domain registration contacts, whilst still complying with the ICANN requirements to input data. It should be stated that it’s also very important to ensure the actual details are accurate and current for your business. Renewal notifications or genuine contact from authorities may be made to the registered contacts, and it’s important that this information will get to relevant people within your business to ensure continuity. We’ve seen cases where domains expired, when they were deployed across a live business environment, causing major disruption to a firm’s operations.
A good example is shown of the use of this privacy function below:
Techary recommends privacy is enabled for all domains registered, to reduce the exposure of any details within the domain contact information. As standard, all Techary-managed domains include privacy by default. Techary will not manage any domains where privacy is not enabled.
We’ve covered the core parts of domain privacy within this section, the high-level outcome here is to reduce the data exposure for information that is required by the domain authorities. The less information that is available to be harvested, the better.
Techary Tip: We recommend purchasing domains that will be used for core systems (like e-mail, and websites) for the maximum renewal length available. This improves the security posture of your domain, as you’ll have less chance of a renewal failing, and also helps to show longevity/investment in the domain, rather than a malicious actor that may purchase domains for the minimum possible period (1 year) to use them for fraudulent activity.
Connect Apps and Services, DNS Hygiene
So, you have your domain, it’s registered, and we’ve dealt with the privacy of the registration contact information above.
Now it’s time to connect this domain to some corporate applications that we’re intending to use it for. In this notional example, let’s imagine we want to use our domain to:
- Forward to our corporate website
- Setup with our corporate e-mail (Microsoft 365)
- Setup with our accounting software to send invoices to our customers (QuickBooks)
- Setup with our e-mail marketing platform (MailChimp)
The first concept to understand is how one domain name can be configured to communicate with multiple services. DNS (domain name system) is the technology used to match domain names to IP addresses, to essentially connect the domain to services. Consider DNS the phonebook of the internet, it connects the service with the domain name and allows everyone with an internet connection to connect to the same phonebook and match names to IP addresses of systems.
DNS comprises various records (examples above) that are saved against a domain. Let’s look at a simple DNS record for connecting the domain to your website hosting server.
Let’s say your website was hosted on a server with IP address 74.125.224.147 and your domain is “company.com“, you could connect the domain to your website server by adding an A-record entry, to your domain DNS table, this would look like the below:
Essentially, we’ve told the “phonebook” that if someone browses to the “company.com” domain, connect them to 74.125.224.147 (your website hosting server), and as long as that server is configured to handle the request, it’ll display the contents of the website on “company.com”.
Sounds straightforward, and it works, but that’s not been considered here is security. Similar to the registration point, as these details need to be available within the “phonebook” for any internet user to see and access, they are publicly available.
Anyone can perform a look-up of a DNS record for a domain, and see the underlying record information. This exposes the underlying IP address of a connected system, in this example, we’d be able to identify and gain the IP address of the domain, by simply performing a search for the A record.
If this server was not secure, it provides a vulnerability and entry point into the organisation. Website hosting servers are often maintained/purchased from hosting providers and are not directly connected to the corporate infrastructure. This approach helps to separate the web-facing, exposed addresses, from systems required in Corporate IT.
If we look at connecting applications, through different types of DNS entries, these follow a similar path to the above, adding DNS records, which in turn are then available to be searched on the domain.
If we look at the DNS records to add the services mentioned in our example, it would look something like this:
These records will allow the service to run. In this example, the Microsoft 365 Exchange application will be connected to the domain. These details are known to be related to this application, with several of the records being defaults for this application. Given that these records are publicly searchable, they are available for anyone to search against your domain.
Thinking with the mind of a malicious threat actor, we’re able to publicly see which services a domain/company is using. If we were to lookup this domain, we’d be able to ascertain that the company is using Microsoft 365 for e-mail services. Instantly, this may help an attacker look to streamline their attack and look to focus on phishing attempts that may try to impersonate the Microsoft service, knowing the users will be familiar with the system.
This is possible due to the standard records being exposed, so how can we combat that? The most standard way is to use a third-party security tool (such as Mimecast, Barracuda, or ProofPoint) to replace the MX server and act as a security layer between the public internet and the mailboxes of the users.
Example of DNS change due to security gateway
This resolves the exposure of the MX DNS record, but looking at other records, such as SPF, this can represent a similar exposure of applications used by the org.
There are further measures, that we’ll describe in a future blog, on the use of third-party CDN providers, that help to protect DNS records.
This setup mitigates the exposure risk associated with the MX DNS record. However, other records, such as SPF, can still present a similar risk of exposing the applications used by the organization.
In future blog posts, we’ll delve into additional measures, such as the use of third-party CDN providers, that can further protect DNS records.
An example SPF record is shown below:
v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 include:thirdpartyapp.com include:google.com -all
Proofpoint has a great tool to check your SPF configuration, available here.
The final example here involves flattening the SPF record to conceal the specific applications being used.
The SPF record is needed to authenticate all applications that will be sending mail within the company domain. This again exposes these applications to threat actors to launch target phishing or compromise attacks.
Essentially, by flattening the SPF, we mask the details of the applications and use a service to achieve the use of SPF, whilst removing the visibility of the services utilised.
Compared to the example above, which exposes the use of “third party app” and “google” within our domain, a flattened SFP would show something like:
v=spf1 include:_u.company.com._spf.dmarcla.com -all
In the flattened example, there are no services exposed, and essentially all the SPF is being handled by the “forwarder” that’s being publically advertised.
Domain Security and best practice can be something that’s easily overlooked. Hopefully, this blog helps you understand some of the complexities that exist in maintaining a good security posture within your org.
Stay tuned for more insightful blog posts that delve deeper into domain security and related InfoSec topics.