Updating Exchange 2013 Anti-Malware Agent From A Non-Internet Connected Server

Posted on Leave a commentPosted in 2013, 64 bit, antivirus, exchange, Exchange Online Protection, IAmMEC, malware, mcm, mcsm, powershell, x64

In Forefront Protection for Exchange (now discontinued) for Exchange 2010 it was possible to run the script at http://support.microsoft.com/kb/2292741 to download the signatures and scan engines when the server did not have a direct connection to the download site at forefrontdl.microsoft.com.

To achieve the same with Exchange 2013 and the built-in anti-malware transport agent you can repurpose the 2010 script to download the engine updates to a folder on a machine with internet access and then use a script from Exchange Server 2013 to download from a share on the first machine that you downloaded the files to, and that the Exchange Servers can reach.

So start by downloading the script at http://support.microsoft.com/kb/2292741 and saving it as Update-Engines.ps1.

Create a folder called C:\Engines (for example) and share it with Authenticated Users / Read access and full control to the account that will run Update-Engines.ps1

Run Update-Engines.ps1 with the following

Update-Engines.ps1 -EngineDirPath C:\engines -UpdatePathUrl http://forefrontdl.microsoft.com/server/scanengineUpdate/  -Engines “Microsoft” -Platforms amd64

The above cmdlet/script downloads just the 64 bit Microsoft engine as that is all you need and places them in the local folder (which is the shared folder you created) on that machine. You can schedule this script using standard published techniques for scheduling PowerShell.

On your Exchange Server that has no internet connectivity, start Exchange Management Shell and run the following:

Set-MalwareFilteringServer ServerName –PrimaryUpdatePath \\dlserver\enginesShare

Then start a PowerShell window that is running as an administrator – you can use Exchange Management Shell, but it too needs to be started as an administrator to do this last step. In this shell run the following:

Add-PSSnapin microsoft.forefront.filtering.management.powershell

Get-EngineUpdateInformation

Start-EngineUpdate

Get-EngineUpdateInformation

Then compare the first results from Get-EngineUpdateInformation with the second results. If you have waited 30 or so seconds, the second set of results should be updated to the current time for the LastChecked value. UpdateVersion and UpdateStatus might also have changed. If your Exchange Server has internet connectivity it will already have updated automatically every hour and so not need this script running.

Exchange DLP Rules in Exchange Management Shell

Posted on Leave a commentPosted in 2013, cloud, DLP, EOP, exchange, exchange online, Exchange Online Protection, IAmMEC, IFilter, mcm, mcsm, Office 365

This one took a while to work out, so noting it down here!

If you want to create a transport rule for a DLP policy that has one data classification (i.e. data type to look for such as ‘Credit Card Number’) then that is easy in PowerShell and an example would be as below.

New-TransportRule -name “Contoso Pharma Restricted DLP Rule (Blocked)” -DlpPolicy ContosoPharma” -SentToScope NotInOrganization -MessageContainsDataClassifications @{Name=”Contoso Pharmaceutical Restricted Content”} -SetAuditSeverity High -RejectMessageEnhancedStatusCode 5.7.1 -RejectMessageReasonText “This email contains restricted content and you are not allowed to send it outside the organization”

As you can see, and highlighted in red, the data classification is a hashtable and the single classification is mentioned.

To add more than one classification is much more involved:

$DataClassificationA = @{Name=”Contoso Pharmaceutical Private Content”}
$DataClassificationB = @{Name=”Contoso Pharmaceutical Restricted Content”}
$AllDataClassifications = @{}
$AllDataClassifications.Add(“DataClassificationA”,$DataClassificationA)
$AllDataClassifications.Add(“DataClassificationB”,$DataClassificationB)
New-TransportRule -name “Notify if email contains ContosoPharma documents 1” -DlpPolicy “ContosoPharma” -SentToScope NotInOrganization -MessageContainsDataClassifications $AllDataClassifications.Values -SetAuditSeverity High -GenerateIncidentReport administrator -IncidentReportContent “Sender”,”Recipients”,”Subject” -NotifySender NotifyOnly

And as you can see, shown in red above, you need to make a hashtable of hashtables and then use the value of the final hashtable in the New-TransportRule

Highly Available Office 365 to On-Premises Mail Routing

Posted on 22 CommentsPosted in 2010, 2013, cloud, DNS, EOP, exchange, exchange online, Exchange Online Protection, hybrid, IAmMEC, MX, Office 365, smarthost, smtp

This article looks at how to configure mail flow from Office 365 (via Exchange Online Protection – EOP) to your On Premises organization to ensure that it is highly available and work in disaster recovery scenarios with no impact. It is based on exactly the same principle to that which I blogged about in 2012: http://c7solutions.com/2012/05/highly-available-geo-redundancy-with-html on creating redundant outbound connections from Exchange on premises.

The best way to explain this feature is to describe it in the way of an example:

For example MCMEmail Ltd have Hybrid set up, and delivery to the cloud first. So the DNS zone for mcmemail.co.uk has MX pointing to EOP.

They then create a new DNS zone at either a subzone (as in this example) or a different domain if they have one available. In the example this could be hybrid.mcmemail.co.uk. Into this zone they add the following records:

10 MX oxford-a.hybrid.mcmemail.co.uk

10 MX oxford-b.hybrid.mcmemail.co.uk

20 MX nuneaton.hybrid.mcmemail.co.uk

The below picture shows an example of this configured in AWS Route 53 DNS (though there are other DNS providers available)

image

In Exchange Online Protection administration pages (Office 365 Portal > Exchange Admin > Mail Flow > Connectors and modify your on-premises connector to point to the new zone. Example shown in the below picture:

image

Then all email is always delivered to the Oxford datacentre and nothing to the Nuneaton one (where the DR servers reside) unless the two Oxford datacentres (A and B) are both offline and so the 10 preference does not answer at all. At that time and that time only does the 20 preference get connected to.

Cannot Send Emails To Office 365 or Exchange Online Protection Using TLS

Posted on 12 CommentsPosted in 2003, 2007, 2010, 2013, exchange, exchange online, Exchange Online Protection, FOPE, hybrid, Office 365, spam, starttls, TLS

I have found this is a common issue. You set up an Exchange Online Hybrid or Exchange Online Protection (EOP) stand alone service and follow all the instructions for the creating of the connectors needed, only to find that your emails queue in your Exchange Server. If you turn on protocol logging you get this error in the log “Connector is configured to send mail only over TLS connections and remote doesn’t support TLS” and if you look at the SMTP protocol verbs that are recorded in the log you see that Microsoft’s servers do not offer STARTTLS as a verb.

STARTTLS is the SMTP verb needed to begin a secure and encrypted session using TLS. Communication between your on-premises servers and Microsoft for hybrid or EOP configurations requires TLS and if you cannot start TLS then your email will queue.

If you are not configuring hybrid or EOP standalone and need to send an email to someone on Office 365 then this is not an issue, because Exchange Server does not require TLS for normal email communication and so the lack of a STARTTLS verb means your email is sent in clear text.

The reason why you are not getting STARTTLS offered is that your connecting IP address is on the Microsoft block list. If you change your connector (temporarily) to allow opportunistic TLS or no TLS at all then your emails will leave the queue – but will be rejected by the Microsoft servers. The NDR for the rejection will tell you to email Microsoft’s delisting service. So now you have an NDR with the answer to the problem in, you can fix it! It takes 1 to 2 hours to get delisted from when Microsoft process your email – so they say it takes 48 hours end to end.

Therefore my recommendation when setting up Exchange Online Hybrid or stand alone EOP is to send an email over plain text to EOP before you configure your service. If you are on the blocklist then you will get back the delisting email and you can process that whilst setting up the connectors to Office 365 and so by the time you are ready to test, you are off the blocklist!

To send a test email over Telnet

  1. Install the Telnet Client feature on your Exchange Server that will be your source server for hybrid or connectivity to EOP for outbound email
  2. Type the following. This will send an email to a fake address at Microsoft, but will hit the TLS error before the message is rejected

    telnet microsoft-com.mail.protection.outlook.com 25

  3. You are now connected to Exchange Online Protection and you should get a 220 response
  4. Type the following to send the email by command line. No typo’s allowed in telnet, so type carefully. Replacing your email address where prompted so that you get the NDR back to you.

    ehlo yourdomainname.com
    mail from: youremailaddress@domainname.com
    rcpt to: madeupaddress@microsoft.com
    data
    from: Your Name <youremailaddress@domainname.com>
    to: madeupaddress@microsoft.com
    subject: testing to see if my IP is blocked

    type something here, it does not matter what, this is the body of the message you are sending
    .

  5. A few points about the above. It must finish with a . (full stop) on a line by itself followed by a carriage return. There must be a blank line between the subject line and the body. And finally, for each line of data you type, the Microsoft SMTP servers will return either a 250 or 354 response.

Whitelisting Salesforce Emails in Exchange Online Protection

Posted on 4 CommentsPosted in EOP, exchange, exchange online, Exchange Online Protection, Office 365, Salesforce, whitelist

In this article, Salesforce list three IP address ranges (by way of CIDR notation) where their emails can come from when you are a Salesforce.com user. To ensure these emails come to all users of your organization if you are using Exchange Online Protection (EOP) then you have to create a transport rule to attempt to bypass any filtering that might be applied to these messages.

The problem with this list of network ranges and EOP is that EOP only accepts CIDR ranges that are /24 or smaller (i.e. /24 to /32) when creating connectors or content filtering and the Salesforce ranges are all larger than that.

To add a range bigger than /24 you must create a Transport rule that operates on the IP address range that sets the spam confidence level (SCL) to Bypass spam filtering (meaning that all messages received from within this IP address range are set to “not spam” and no additional filtering is performed by the service). However, if any of these IP addresses appear on any of Microsoft’s proprietary block lists or on any of their third-party block lists, these messages will still be blocked. So even though it is possible to do this, the emails might still be blocked if the individual addresses are blocked.

To add the transport rule follow these steps:

  1. In the EAC, navigate to Mail flow > Rules.
  2. Click + and then select Create a new rule.
  3. Give the rule a name and then click More options.
  4. Under Apply this rule if, select The sender and then choose IP address is in any of these ranges or exactly matches.
  5. In the specify IP addresses, specify the IP address ranges provided by Salesforce, click Add +, and then click ok.
  6. Under Do the following box, set the action by choosing Modify the message properties and then set the spam confidence level (SCL). In the specify SCL box, select Bypass spam filtering, and click ok.
  7. If you’d like, you can make selections to audit the rule, test the rule, activate the rule during a specific time period, and other selections. We recommend testing the rule for a period before you enforce it. Manage Transport Rules contains more information about these selections.
  8. Click the save button to save the rule. It appears in your list of rules.

After you create and enforce the rule, spam filtering is bypassed for the IP address range you specified.

What is X-Forefront-Antispam-Report-Untrusted?

Posted on Leave a commentPosted in EOP, exchange, Exchange Online Protection, FOPE, IAmMEC

When a message arrives in Exchange Online Protection (EOP) with an existing X-Forefront-Antispam-Report header, it is renamed to X-Forefront-Antispam-Report-Untrusted.

If the message is then detected as spam and stored in the optional quarantine, upon release it will go back into EOP. Upon entering EOP the previously set X-Forefront-Antispam-Report header is renamed to X-Forefront-Antispam-Report-Untrusted.

Moving Exchange Online Protection Junk Mail to the Junk Email Folder

Posted on Leave a commentPosted in 2007, 2010, 2013, active directory, cloud, Edge, EOP, exchange, exchange online, FOPE, mcm, mcsm, spam, transport

If you use Exchange Online Protection (EOP) to filter your email in the cloud and to remove spam and malware before onward delivery to you, and if you use Exchange 2007 or later on-premises, then you need to configure Exchange to move detected spam to the Junk Email folder in Outlook.

By default EOP detects two levels of spam (malware is automatically removed) and tags them. In Exchange, you need to use Transport Rules to move these emails to the users Junk Email folder. If you wish for EOP throw away junk emails of either detection level (i.e. high junk is discarded) then you still need to configure these transport rules to move the remaining detected junk email into the Junk Email folder in Outlook. If you place all EOP detected spam in the quarantine or throw it away, you should still create these transport rules as it means they are in place for any future changes you make at EOP.

If you use Exchange Online (part of Office 365) then you do not need to create these rules as they already exist (though you cannot see them in any admin tools you have).

The Transport Rules To Create

The following four transport rules need to be created on your Exchange organization. These four rules get created with the highest priority, moving all existing rules below them. They set the Spam Confidence Level of the message to 6 in these examples, though this should be set to a value that exceeds the SCLJunkThreshold organization wide setting for your Exchange Organization, as any email that exceeds this value is placed into the Junk Email folder upon delivery to the users mailbox.

New-TransportRule "Move EOP Detected Spam (SFV:SPM) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SPM" -SetSCL 6 -Priority 0

New-TransportRule "Move EOP Detected Spam (SFV:SKS) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKS" -SetSCL 6 -Priority 1

New-TransportRule "Move Personal Block List Spam (SFV:SKB) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKB" -SetSCL 6 -Priority 2

New-TransportRule "Move Bulk Email (SFV:SKB) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SRV:BULK" -SetSCL 6 -Priority 3

Once these four rules are run, AD replication will need to be allowed to happen and then all Exchange Servers will action this rule for any email that EOP thinks is spam. The default value for SCLJunkThreshold is 4, so as long as the rules set the SCL value to greater than this value it should work. Use Get-OrganizationConfig | FL SCLJunkThreshold to get this value for your organization.

What the EOP Message Tags Mean

The X-Forefront-Antispam-Report header in the email contains many values. See http://technet.microsoft.com/en-us/library/dn205071(v=exchg.150).aspx for what EOP thinks about the spam rating of the message.

  • SFV – means Spam Filtering Verdict
  • SFV:SFE – Originated from a Safe Sender (EOP learns Outlook safe senders due to Windows Azure Directory Sync)
  • SFV:BLK – Originated from a Blocked Sender
  • SFV:SPM – Spam
  • SFV:SKB – Emails where the sender is on the users personal block list as configured in OWA or Outlook Junk Email settings
  • SFV:SKS – (SKIP) The message was marked as spam prior to being processed by the spam filter. This includes messages where the message matched a Transport rule to automatically mark it as spam and bypass all additional filtering
  • SFV:NSPM – Not Spam

Article updated in June 2016 to include new headers and go from two rules to four

Forefront Online Protection for Exchange Spam Filtering to Outlook’s Junk E-Mail Folder

Posted on Leave a commentPosted in 2007, 2010, 2013, cloud, dirsync, EOP, exchange, exchange online, FOPE, hosting

Forefront Online Protection for Exchange (FOPE) is a cloud hosted email anti-spam and antivirus filtering system. Amongst the options to filter away your spam, one of the options to to allow the email to be flagged and sent on into your on-premises email system, and then managing it there.

If you have Exchange 2007 or later it is possible to write Exchange Transport Rules to process this flagged email and move it directly to the Junk E-Mail folder in your mailbox. This allows users to have their probable spam in a different location from their inbox email, but not in a different system accessed external to their email client, for which they might need a second login account or a delay before receiving the notification email. This works for probable spam as much obvious spam is filtered out at the edge of FOPE and so cannot make it to a place where users can see it.

An additional benefit of this filtering inside Outlook or OWA to the Junk E-Mail folder is that users can mark messages as safe or blocked in the client and this is picked up by Exchange and can be sent automatically to FOPE, which means FOPE flags it as spam before it reaches the Exchange organization.

To configure this you need to set FOPE to flag spam with a X-Header. This is documented at various places online, but misses out one vital piece of information which I wrote this blog to document. The missing info is what the value of the X-Header is so that you can actually write a transport rule to process it.

In FOPE, select your email domain (under Domains) and on the domain page click Edit next to Spam Action under Service Settings. Change the Spam Action to Add X-Header and type the header name that you want to use:

image

On your Exchange organization create a transport rule (these pictures are from Exchange 2007, but 2010 or 2013 are technically the same though visibly different). The transport rule is set to apply to messages when a message header contains specific words and the name of the header is the value set in FOPE previously (X-MoveTo-JunkEmail in this example). The value of the header will always read “This message appears to be spam.”.

image

It is possible to use the when the message header contains text patterns and use the RegEx expression \w* to find emails with your header in it and containing a value (\w* means any letter or digit repeated), but as we know the value for the header is always “This message appears to be spam.” then using regular expression filtering is adding un-needed CPU cycles to the Exchange Server – only use RegEx when the value can vary.

Office 365 use this process to place your probable spam in Junk E-Mail. In their case the header is X-FOSE-spam.

The transport rule continues to set the spam confidence level to a high value of your choosing, and higher than the value we will set in OrganizationConfig below.

So this rule will take all emails the FOPE marks as spam and changes the spam confidence level (SCL) value to 9 (in this example). Finally we need to set the SCLJunkThreshold property of OrganizationConfig to a value below the value in the transport rule. Exchange will place all email that exceeds this threshold into the Junk E-Mail folder in Outlook:

Set-OrganizationConfig -SCLJunkThreshold 4

If you are running the Content Filter hygiene agent then you will also want to check the Get-ContentFilterConfig values for SCLRejectEnabled, SCLDeleteEnabled and SCLQuarantineEnabled are all set to false. This ensures that SCL values that are are high are not rejected or deleted, or sent to quarantine. As all your email should be filtered by FOPE if you are using it, and the firewalls at your company or receive connectors on Exchange should be blocking email not sent from the FOPE datacenters (in FOPE admin pages click Information tab and then the Configuration link to get the list of IP addresses). The content filtering agent can be used as a second filter on-premises but if you don’t want to throw away or reject spam at this second level (recommended in this scenario) then ensure that the filter rejection, delete and quarantine settings are disabled. If you want to delete probable spam then set the transport rule to 5 and the SCLDeleteEnabled to $true and the SCLDeleteThreshold value to 9. Don’t reject or use the on-premises quarantine features when using FOPE (the transport rule cannot process the quarantined messages for a start).

Finally for administrators, consider a Message Retention Management or Retention Policy to delete without recovery email in Junk E-Mail folder after 21 days. Also consider the FOPE Directory Sync tool to push the user lists to FOPE as this upload also includes the pushing of the safe senders information as well.

Now for your users, all probable spam is managed in their email client, integrated with safe sender lists and without resorting to another application to view and deliver false positives and spam they want to read!