There is so much out there about securing your websites, update everything, patch everything, latest everything, and then there are the settings in the web server itself.
Clearly, keeping everything patched is a must, but these web server settings are key.
Email has been around, in some form, since 1972, so its about time that it had all the updates needed to make it a modern secure system. It gets used many millions of times a week and is deemed a critical infrastructure by many business. So what can be done to make it just that little bit better
SPF
Sender Framework Policy (SPF) came about in early 2000’s and its a simple DNS record which lists all email servers who can authoritatively send email on behalf of a domain. The records give each server a rating of pass, neutral, soft fail or fail. The receiving email server is expected to check for SPF records and ensure it weights its SPAM score based on the returned rating for the sending server.
Unfortunately SPF has a issue with the modern way of forwarding email, if the return-path is not re-written. This could lead to a lot of false-positive SPAM detections being made. The way to solve this is rely on SRS to sort out your return path.
"v=spf1 ip4:192.192.192.0/24 ip4:100.100.100.100 a -all"
The above is a typical example of an SPF record which would be added as a TXT resource to the root email domain. Before any of the attributes, the following symbol can be used to determine the rating.
+ for a PASS rating. This can be omitted.
? for a NEUTRAL rating interpreted like NONE.
~ (tilde) for SOFTFAIL, somewhere between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
– (minus) for FAIL, the mail should be rejected.
The following attributes can be used to make up the record, an “all” should only appear as the last entry. Others are available but not common nor recommended.
ALL
Matches always; used for a default result like -all for all IPs not matched prior.
A
Match against an address record (A or AAAA) for the sending email domain.
IP4
Match if the sender is in the given IPv4 address range.
IP6
Match if the sender is in the given IPv6 address range.
MX
Match against the MX record for the sending domain to the sender’s address.
INCLUDE
Reference the policy of another domain. If that domain’s policy passes, this is a pass match. However, if the included policy fails, checking against further attributes continues.
The real power of SPF only comes when combined with DMARC.
SRS
Sender Rewriting Scheme (SRS) was introduced in 2003 to allow emails for be forwarded without breaking SPF. This scheme rewrites the originating email domain on forwarding to match that of the forwarding MTA. I will leave most of the details on this one, but the following shows the format.
Original incoming headers
sender: john@example.org
recipient: amanda@example.com
Rewritten headers to be forwarded
sender: SRS0=HHH=TT=example.org=john@example.com
recipient: amanda@example.net
The prefix of SRS0 indicates this is a rewritten address.
The hash-based message authentication code (HHH) is calculated against a local server secret, but only part of it is set. The hash can be checked by the forwarding domain should a bounce return.
The timestamp (TT) is used to mark the address invalid after a few days.
The recipient, in this case john, is removed from the source sender because it may contain an equal signs. It is left only on the re-written email as it can be processed there.
DKIM
DomainKeys Identified Mail (DKIM) is an authentication method used to sign an email to prove its origin. It came about in 2011 and is a more modern version of SPF.
The authentication is achieved by the sending MTA attaching a digital signature to each mail using its private key. The receiving MTA can check the authenticity of this against the public key, which is stored in a DNS record. It is best practice to have multiple keys recorded at one time and to rotate the keys, replacing one every few months. The multiple keys allows for historic check back should delivery be delayed.
The full technical details of this one are best left for a time when you are implementing this method. It is important to note that the digital signing does not attest to the contents of the message remaining unmodified since transmission.
DMARC
Domain-based Message Authentication, Reporting and Conformance (DMARC) came about in 2015, and is an extension to both SPF and DKIM. It allows the owner of a sending domain to publish a policy in their DNS records which will specify if DKIM, SPF or both is employed. It specifies how to check the from field in the source email, how the receiving MTA should deal with failures, and a reporting process for actions performed under those policies.
The power really comes from pulling all both SPF and DKIM together, along with the ability to produce a report back to the originating MTA on how your domain is being used. This is a great tool for working out if your email domains are being spoofed by others, however, as is usual, there are some downsides. Not every receiving MTA will honour the reporting process (like Microsoft O365), and the XML format of the return reporting requires software to fully analyse your email situation.
The above example shows the reporting being listed for aggregated daily reports, which is simple enough if the report is being sent to an address within the same domain. It is possible to send to a third party domain, but both sides must have matching records to accept this.
The full technical complexities are best left to any of the main sites out there that check and construct these records for you. I like using https://dmarcian.com/dmarc-record-wizard/ but there are others.
As a free option, the above site also offers a report reviewer to take the XML and show it in a human readable format, great for a one off, but much more is needed to check all the daily reports from your main domains.
Overall
I would recommend using all four of the above systems, as I know it will reduce the amount of phishing emails that will go around in your name. It may not reduce the amount of SPAM you receive, but it will allow others to ensure that emails coming from you really are from you.
Clearly start small, put your SPF record in, but ensure a ~all at the end so as not to block things you have not found out about yet.
Then add DMARC in report only mode, and see over period of a month, how your domain is being used. Once you have bottomed out all the surprises, look to turn on DKIM on your sending MTAs, and firm up your policies into Quarantine mode.
After another month I would then recommend turning on to full reject mode.
I hope this will help give you some peace of mind that if the receive wants to check, they will know for certain if the email came from a place you trust to send your email.
On the 27th January 2020, the UK Government announced its plans to introduce a new law which will control the security of any IoT device sold within the UK.
All consumer internet-connected device passwords must be unique and not re-settable to any universal factory setting
Manufacturers of consumer IoT devices must provide a public point of contact so anyone can report a vulnerability and it will be acted on in a timely manner
Manufacturers of consumer IoT devices must explicitly state the minimum length of time for which the device will receive security updates at the point of sale, either in store or online
Clearly the wait is now on to see when the new law will appear, what this will actually mean for the market, and exactly what will happen to all the imports from foreign markets.
The above proposals are all really sound foundation principals, so it should be a small change for any legitimate company looking to market a serious device.
What are the main things that have been seen in an email to make us think its a Phishing email…
Asking us to do something urgently
Asking us to do something that we normally wouldn’t do
Making spelling and grammar mistakes
Sending the email from an unusual address
Not sounding like they normally do when they send you an email
Asking for lots of personal details
I have no idea who you are, why are you sending me this?
What should we do then?
I go with the simple, just don’t answer and delete the email, if it is important they will send another one or make contact another way. If you really do want to follow up on this, don’t email back, pick up the phone and ring them to check that its valid.
Of course not, you don’t have any rules on your Azure NSG’s which allow access to your services or data without control. Or do you?
There has been so much in the news around TravelEx of late, its hard to avoid it. Even thought the details are still not known, speculation surrounds the exploitation method. The most common so far are
Vulnerability in the VPN Gateway
RDP Service left fully open to the Internet
Phishing campaign which initiated the compromise
Sticking with RDP being open to the Internet, its pretty easy in Azure to secure services – NSG’s or WAF’s or even an ASG and you are sorted.
These rules are now spanning over many different resources, possibly in separate resource groups, locations or subscriptions. How are these tracked and audited? Who is making sure a mistake has not taken place and an unexpected hole has been left.
Make sure that the file “c:\temp\nsg-rules.csv” does not exist before running this. Connect to your Azure Subscription using “Connect-AzConnect” and clearly have the new AZ Powershell module installed, and this should list every single NSG rule that exists in all subscriptions you have access to.
I wish this was the first question that everyone asked themselves before they happily enter their passwords whenever they are asked. Sadly, the reality is anything but.
So, what can we do to help the users make a sensible choice, and work out if it is safe to enter their password
Awareness, Awareness, Awareness – Lets try and get the message through to everyone that their password is a key, and they must keep them safe and secure.
Double Check – Look at the screen, check out the wording, if its a web page then make sure the URL is correct.
If we are in a corporate environment, lets turn on all the branding we can to help the user identify that its a safe place to enter their password.
All of this is much easier said than done. Even if we are sure the message is out there, we can also guarantee that there will be times when we as a human forget, so seems we are just going to have to have a backup plan – technology…
So, at long last, ive decided to make a public blog of a few of the things that I find out, stumble across, or re-engineer from the vast wealth of information that comes back from those search engines.
I have been around in the IT and Electronics space for over 20 years now, more recently in the Cyber Security arena. It is a great area to be in, although it may have an interesting image from the outside, I can confirm that the vast majority of people within are truly friendly professionals.
I will detail more on my thoughts, and maybe feelings, as I fill this blog up. I have lots of links from my internal wiki, so it will take a long time to clean these up and make them presentable.