Authoritative DNS server audit completed by Assured AB
We are now running our own self-hosted authoritative DNS servers which we have spread around the world for redundancy, trust and performance.
These servers were audited by Assured AB who verified that they adhered to the best practices for authoritative DNS servers prior to being put into production.
We invite you to read the final report of our first security audit on Mullvad’s authoritative DNS servers, concluded in May 2022, with fixes deployed during early June 2022 , servers were deployed to production during August 2022.
These servers were audited prior to being used in production, we are releasing this report now that the servers are fully deployed.
We gave Assured AB full access via SSH to copies of our production servers, with separate credentials and asked them to verify the security and setup of them.
The audit report is available on Assured AB's website https://www.assured.se/publications/Assured_Mullvad_DNS_server_audit_report_2022.pdf
Overview of findings
- Assured AB found no zero critical or high issues
- Service and application configurations generally followed best practices
- Assured AB identified ten (10) issues that ranged from “low“ to “medium“
- Assured AB identified zero (0) issues in the “critical“ or “high“ category
Key takeaway: Our self-hosted authoritative DNS service is fully audited for security issues!
Identified vulnerabilities of interest
MUL006-3.1.2 Shared SNMP credentials (Medium)
To quote Assured AB: “We recommend that each deployed machine recieve its own unique credentials for inbound services, to enable revocation in case of a detected compromise“
Our comments: We have altered the SNMP authentication method by adding unique credentials per server type, which in this instance means that authoritative DNS servers get their own credentials compared to WireGuard VPN servers, compared to OpenVPN servers, and so on.
We have also added the SNMP connectivity to be within our own WireGuard based overlay network, by which all health monitoring and metrics are transferred.
MUL006-3.1.3 Permissive firewall policy (Low)
To quote Assured AB: “We recommend that the default policy for INPUT is set to DROP to make sure no services are exposed by accident“
Our comments: In general we are ensuring that all servers use a default DROP policy. This was initially implemented on our VPN servers during their audit, and is spreading to all server types.
MUL006-3.1.6 DNS Logging (Low)
To quote Assured AB: “No configuration is specified for the default category. The result of this is that BIND implicitly sends several log categories to syslog with a severity of info“
Our comments: We have a company policy that ensures that we do not log anything. Before this service went into production we set category default { null; }; in the named.conf.logging configuration file.
Integrating it into our deployments
After our authoritative DNS servers were fully audited we started deploying them for production usage and integrating them into our workflow.
By implementing our own authoritative DNS servers, we are able to control the uploading of DNS records using the same Ansible codebase that we use to deploy the rest of our infrastructure.
Our DNS servers get records added or updated when servers are provisioned for the first time, and then updated when required, or removed when servers are decommissioned.
Trust, reliability and a little bit of time gained
This migration to our own hardware meant we have full control over what runs on them. Although no customers will ever interact with them, we do have full knowledge of their configuration and know that the set up is audited and approved, at least during this initial audit.
We are grateful to Assured AB for auditing our servers, and we will include these servers in our next audit cycle.
For the universal right to privacy,
Mullvad