Friday, 18 January 2019

Finally, a good but concise explanation of DMARC, DKIM and SPF - email security!

 

 

I’ve found that the information that’s out there about email authentication is either too detailed or too high level.  So I wanted to produce a quick guide for administrators that’s somewhere in between.

We have three principle technologies at play. These technologies work together to provide an email security foundation.


They are:

1.    Domain-based Message Authentication, Reporting & Conformance (DMARC)

2.    Sender Policy Framework (SPF)

3.    DomainKeys Identified Mail (DKIM)

These technologies protect the recipient of the email more than the sender.  That is the validate the authenticity of the email that you are SENDING.  However large scale adoption means that the online community is able to come together to authenticate each other’s email traffic to help eliminate the effectiveness of phishing and spam emails.

SPF

There are two ‘from’ addresses in an email.  The ‘header from’ (AKA friendly from) and the ‘envelope from’ (AKA return path).  An organisation hosts its own SPF record in DNS.  This record can be used by the receiving organisation to confirm that mail received is from a valid source.  That is the receiving organisation will check the DNS records for domain in the ‘envelope from’ field within the email header.  Eg “contoso.com” to see if there is an SPF record.  If there is, then the server will check to see whether the mail was received from a server matching this record.  An example SPF record would be as follows:

v=spf1 ip4:232.198.111.122 include:mail.contoso.com -all

 

If you’d like more information please look at this article.

DKIM

DKIM adds a digital signature the header section of an email.  This uses public key cryptography to ensure that the email was from a genuine source and that the message hasn’t been tampered with or altered en-route.

The sending server creates a signature using it’s private key.  This can be decrypted using the public key, which is stored in a text file within the sender’s DNS.  Due to the high level of security provided by public key cryptography, this method gives those receiving the email peace of mind that the email is genuine.

An example DKIM record would be as follows:

v=DKIM1; p=Es34dfgRGE55ehYRJ54JYRsfMTYesfsdNTNJSRefdgGg54t35tJSR

 

DMARC

This relatively recent authentication method was developed in 2007 by PayPal, with collaboration later being offered by Yahoo! and Google.  DMARC is like the ‘digital doorman’ ensuring that every email’s name is on both the SPF and DKIM list. DMARC will match the ‘header from’ domain name with the ‘envelope from’ domain name obtained from the SPF check, and will also match the ‘header from’ domain name with the ‘d= domain name’ in the DKIM signature.  As well as carrying out these tests, DMARC is also used to inform recipient mail servers on what to do with any email that is suspected of not being genuine.

The sender can choose to:

·        Monitor all mail to gain an understanding of misuse of their brand name through spam email and to ensure genuine mail is authenticating properly.

·        Quarantine messages that fail DMARC ie ensure it lands in the recipient's spam folder

·        Reject messages that fail DMARC authentication ie request that the recipient's email server doesn't deliver the message at all.

An example DMARC record would be as follows:

"v=DMARC1; p=reject; pct=100; rua=mailto:postmaster@contoso.com"

 

It is a combination of SPF, DKIM and DMARC together that offers confidence and security to businesses, customers and other internet users that an email is genuine and not a phishing attempt or spam.

 

 

Wednesday, 16 January 2019

Extract Office 365 License information for all users using Powershell

 

 

This script gathers O365 license information for all active users.  It will populate fields within a csv for import into Excel which includes UPN, Licenses, whether it is a shared mailbox or not and whether or not the user is blocked.

 

A separate row will be created for each license, with the user’s UPN detailed on each row.  Once the export is complete, you can filter this list in excel to get whichever granular information you need.

 

 

$LogFilePath = $env:LOCALAPPDATA + "\Cloudwyse\Logs\user_license_report_" + $(get-date -Format ddMMyy_HHmmss) + ".log"

Start-Transcript -Path $LogFilePath -NoClobber

$365Pass = cat C:\cloudwyse\securestring365.txt | convertto-securestring

$365Cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "admin@contoso.onmicrosoft.com",$365Pass

$DateTime = (Get-Date -Format "ddMMyyyy-HHmmss")

 

$365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $365cred -Authentication Basic -AllowRedirection

Import-PSSession $365Session

Connect-Msolservice -Credential $365Cred

 

 

Write-Host  -ForegroundColor Magenta "Pulling mailbox information for all users, please be patient..."

$JobStart = Get-Date

$getmailbox = get-Mailbox

$JobEnd = Get-Date

$JobSecondsTaken =($JobEnd - $JobStart)

Write-Host  -ForegroundColor Yellow "Extract complete.  The Job took" $JobSecondsTaken.Seconds "seconds."

$total = $null

$Job2Start = Get-Date

$userList = @()

foreach ($user in $getmailbox) {

    $lookup = get-msoluser -userprincipalname $user.userprincipalname

    Write-Host  -ForegroundColor Magenta "Current user is" $user.userprincipalname

    $licenses = $lookup.licenses

    foreach ($license in $licenses) {

        $us = New-Object PSObject

        $us | Add-Member -type NoteProperty -Name 'UPN' -Value $lookup.userprincipalname

        $us | Add-Member -type NoteProperty -Name 'License' -Value $license.accountskuid

        $us | Add-Member -type NoteProperty -Name 'IsShared' -Value $user.IsShared

        $us | Add-Member -type NoteProperty -Name 'Blocked' -Value $lookup.BlockCredential

        Write-Host  -ForegroundColor Cyan $license.accountskuid "was added to the list for" $lookup.userprincipalname

        $userList += $us

        }

    $total = $total +1

   

    }

$Job2End = Get-Date

$Job2SecondsTaken =($Job2End - $Job2Start)

Write-Host -ForegroundColor Yellow "$total users processed in" $Job2SecondsTaken.Minutes "minute(s) and" $Job2SecondsTaken.Seconds "second(s)."

Remove-PSSession $365Session

$userlist | export-csv C:\Cloudwyse\user_license_report$datetime.csv

Write-Host -ForegroundColor Yellow "Report exported to C:\Cloudwyse\user_license_report$datetime.csv"

 

 

Stop-Transcript

 

 

 

I’m happy to post the script as a text file if that will help anyone.

 

 

 

Wednesday, 19 December 2018

Windows 10 NLA Public vs Private profiles - what's the difference?

In a recent post I described how I used Powershell to configure a dual-homed Radius server where I wanted to firewall everything on the DMZ interface but not affect the production interface.  I did this using a Windows feature known as NLA – Network Location Awareness – which has been around in one form or another since Windows XP, although many people still know very little about it.
NLA in Windows 10 uses 3 different network profiles: Domain, Public and Private.  Windows assigns the network connection to one of these profiles when a new network is discovered.  It’s important to know the differences because this actually provides us with a really powerful tool to lock down our machines using the built in Windows Firewall.

How the appropriate location is determined

Domain

Microsoft explain that Windows checks the connection specific DNS name against “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” (although on my test machine this was an empty key but “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\MachineDomain” contained the domain DNS name).  If this matches and the machine is able to go on and contact a Domain Controller via LDAP, then you are assigned the Domain profile.

Public vs Private

This is the bit most people get confused about and it is a distinction which appeared from Windows Vista onwards (in XP the profiles were Domain and Standard).  The way that the location is determined is via the prompt that you receive when connecting to a new network ie “Do you want to allow your PC to be discoverable by other PCs and devices on this network?”.  Selecting “Yes” assigns the Private profile whilst “No” assigns the Public profile.

It’s useful to know of this distinction as it will allow you to configure specific rules on the firewall which will behave differently depending on whether you are connected to a trusted or untrusted network.

Wednesday, 12 December 2018

Connect to O365 exchange with powershell using session import

 

It seems fairly obvious but a lot of people are unsure how to import a remote powershell session to O365. Simply do the following:

 

 

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session

 

 

 

Friday, 30 November 2018

Disable inbound advanced firewall rules on public interface only with Powershell for a Windows Radius/NPS server

 

 

Recently I built an NPS server for Radius authentication, and had to dual home it with one NIC in the DMZ and one on the production network.  I wanted to firewall everything on the DMZ interface but not affect the production interface.  That way I could then allow the traffic I wanted to enable on the DMZ interface port by port.  Assuming windows has correctly detected the profile on the two interfaces as “Domain” and “Public”, which it should based on the resources visible on each network, you can run the following script to disable traffic just on the public interface.

 

 

 

$LogFilePath = $env:LOCALAPPDATA + "\Cloudwyse\Logs\adv_firewall" + $(get-date -Format ddMMyy_HHmmss) + ".log"

Start-Transcript -Path $LogFilePath -NoClobber

 

$rules = Get-NetFirewallRule

$total = 0

foreach ($rule in $rules) {

if (($rule.Profile -like "any" -or $rule.Profile -match "public") -and $rule.enabled -like "True" -and $rule.direction -like "Inbound") {

if ($rule.Profile -like "any") {

  Set-NetFirewallRule -Name $rule.Name -Profile "Domain, Private"

  write-host "Setting" $rule.DisplayName "Domain, Private" }

elseif ($rule.Profile -match "Domain" -and $rule.Profile -match "private" -and  $rule.Profile -match "public" ) {

  Set-NetFirewallRule -Name $rule.Name -Profile "Domain, Private"

  write-host "Setting" $rule.DisplayName "Domain, Private" }

elseif ($rule.Profile -match "Domain" -and  $rule.Profile -match "public" ) {

  Set-NetFirewallRule -Name $rule.Name -Profile "Domain"

  write-host "Setting" $rule.DisplayName "Domain" }

elseif ($rule.Profile -match "Private" -and  $rule.Profile -match "public" ) {

  Set-NetFirewallRule -Name $rule.Name -Profile "Private"

  write-host "Setting" $rule.DisplayName "Private" }

elseif ($rule.Profile -like "public" ) {

  Disable-NetFirewallRule -Name $rule.Name

  write-host "Disabling" $rule.DisplayName }

else {write-host -ForegroundColor Red "Error - check logs"}

$total = $total +1  }}

write-host -ForegroundColor Yellow "$total rules processed"

 

stop-transcript

 

 

 

 

Monday, 19 November 2018

Very Simple Powershell Ping test or IP scanner script

 

 

This simple Powershell script will carry out a quick check against each IP in a 24 bit subnet and return a value of true or false dependent on whether or not it receives a reply.  It’s similar to using an IP scanner or a ping script.

 

 

$subnet = "10.20.6."

1..254 | Foreach-Object {write-host "$Subnet$_..." (Test-Connection -ComputerName "$Subnet$_" -Quiet -Count 1 ) }

 

 

It’s simple and does the job as it is however you could obviously make it more fancy by exporting to csv or an array or emailing the output etc etc.