Monday 11th May 2020
Sender Policy Framework (SPF) provides a way to restrict the mail servers that are permitted to send as your domain, and is particularly effective when used with DMARC.
However, maintaining an SPF policy for a large or complex infrastructure with numerous distinct mail servers can pose a significant operational challenge. Some of the most common issues include:
- SPF record is too long
- Maximum number of DNS lookups has been reached
- Keeping your SPF record up-to-date when mail is sent by third-parties
- Keeping track of which whitelisted senders are for what, who put them there, and removing them when they're no-longer needed
- Having to globally whitelist third-party systems when they only need to send-as a single or small number of addresses
- SPF record syntax becoming messy or breaking when it is maintained by multiple different people
SPF macros, a seldom used yet widely supported feature of the SPF specification, provide a potential solution to some of these challenges.
This article includes an introduction to SPF macros, as well as several examples of how they can be used to solve the various operational complications that SPF so often poses. Continue reading...
Tuesday 31st March 2020
Decentralized Network 42, known as DN42, is a private overlay network built using thousands of distinct nodes interconnected with each other via VPN tunnels. DN42 employs routing protocols such as BGP and OSPF in order to route packets, allowing users to deploy services such as websites, IRC servers and DNS servers in a way very similar to the real internet.
The landing page for DN42, available at dn42.us.
The DN42 network is primarily used by network and security engineers in order to provide a safe and accessible environment to practise using network technologies, as well as allowing isolated networks, such as those behind strict firewalls or NAT, to communicate with each other directly.
However, the primary selling-point for DN42 is that it provides free and realistic access to a production-like BGP environment, which is something usually reserved for network operators responsible for large enterprise networks or ISPs who are also often paying expensive registry fees. Continue reading...
Thursday 13th February 2020
Certificate Authority Authorisation (CAA) is a security control that can be used to restrict the Certificate Authorities (CAs) that are permitted to issue certificates for your domain. The purpose of this is to help ensure that only explicitly whitelisted CAs are able to issue certificates, and also to report on any attempted violations of this policy.
CAA policies are set using the
CAA DNS resource record type, and it has been mandatory for issuing CAs to check for and comply with CAA policies since 8th September 2017. The CAA specification is defined in RFC8659.
The following sample CAA policy marks Let's Encrypt as the only CA authorised to issue certificates for
example.com, while requesting that violations are reported to the
example.com IN CAA 0 issue "letsencrypt.org"
example.com IN CAA 0 iodef "mailto:firstname.lastname@example.org"
This policy will then be checked by CAs when a certificate request is submitted for your domain. Continue reading...
Sunday 12th January 2020
A screenshot of the Lookalike Domain Names Test app.
The app displays the domain name of a well-known website, with a random set of permutations applied to it. You must then select whether the domain is 'Real' or a potential 'Lookalike'.
Lookalike domain names are a very effective phishing technique, as they exploit the natural way that the human brain interprets writing. The brain will automatically make assumptions and fill in gaps when reading, allowing users to be easily fooled if a phishing domain looks almost identical to the legitimate domain. Continue reading...