Thursday, September 13, 2012

Spam en malware bij Exchange 2013. Is er leven na FPE?

Update 19-9-2012: Hoofdstuk Deadlines toegevoegd.

Microsoft heeft onlangs aangekondigd om te stoppen met de ontwikkeling van Forefront Protection for Exchange, de bekende multi-engine malwarescanner die voorheen door het leven ging onder de naam Antigen. Als alternatief noemt Microsoft twee oplossingen: enerzijds haar hosted oplossing FOPE (voor de gelegenheid ‘rebranded’ tot Exchange Online Protection) en anderzijds naar de ingebouwde malware scanning van Exchange 2013. Hoogste tijd om op die laatste eens in te zoomen.

Wat is nieuw?

Als we naar Exchange 2013 kijken dan moeten we onderscheid maken tussen antimalware en antispam. Onder malware wordt verstaan virussen en spyware, voor de term antimalware mag je dus ook gerust antivirus lezen. Maar wat krijg je nu eigenlijk precies, en is het een geschikt alternatief voor FPE of 3rd party oplossingen? Laten we eerst eens kijken naar de antispam functionaliteit van Exchange 2013.

Antispam

Als we naar de antispam mogelijkheden van Exchange 2013 kijken dan zijn die grotendeels vergelijkbaar met wat we al kennen uit eerdere versies van Exchange. De verschillende taken worden uitgevoerd door zogenaamde agents die in de transportpijplijn inhaken. Het grootste verschil heeft te maken met de nieuwe architectuur van Exchange 2013, laten we eerst eens even naar de Exchange rollen kijken. Bij vorige versies van Exchange vond spamfiltering plaats op de Edge Transport of de Hub Transport rol. In Exchange 2013 bestaat de Edge Transport rol niet meer en is de functionaliteit van de oude Hub Transport rol verdeeld over de enige twee overgebleven rollen: Client Access en Mailbox.

Op de Client Access server wordt deze functionaliteit verzorgd door de Edge Transport service, op de Mailbox server is dat de Hub Transport service. Als we deze agents installeren, standaard staan ze uitgeschakeld namelijk, dan is dit hoe ze verdeeld worden:

image

Net als bij vorige versies installeren de we agents met een script wat standaard aanwezig is in de \scripts directory. Op een Client Access server doen we dat als volgt:

cd $exscripts
./Install-FrontEndAntiSpamAgents.ps1
Restart-Service MSExchangeFrontendTransport

De volgende stap is dat we de interne SMTP servers op moeten geven. Denk bijvoorbeeld aan een SMTP gateway die je in de DMZ hebt staan, het IP-adres van deze server wordt dan als ‘veilig’ beschouwd bij het beoordelen van de herkomst van een mailbericht. Hier is nieuw dat de Mailbox server ook geldt als een interne SMTP server die mail aflevert bij de Client Access server. Minimaal voegen we hier dus één interne SMTP server aan toe:

Set-TransportConfig –InternalSMTPServers 10.1.2.3

Op een server met de Mailbox rol installeren we de antispam agents als volgt:

cd $exscripts
./Install-BackEndAntiSpamAgents.ps1
Restart-Service MSExchangeTransport

Op een server waar zowel de Client Access als Mailbox rol geïnstalleerd is kunnen we de agents allemaal in één keer installeren:

cd $exscripts
./Install-AntiSpamAgents.ps1

Ook in dat geval moeten we nog de IP-adressen van interne SMTP servers opgeven. Dit is dan weer minimaal het IP-adres van de server met de Mailbox rol waarop je deze agents aan het installeren bent:

Set-TransportConfig –InternalSMTPServers 10.1.2.3

Het beheren en verder configureren van de antispam-agents is verder ongewijzigd ten opzichte van hoe dit in Exchange 2010 werkt.

Antimalware

Waar we zien dat antispam slechts op details afwijkt van wat er al kennen, is het ingebouwde scannen op virussen en spyware nieuw voor Exchange. En waar de antispam agents standaard niet geïnstalleerd zijn op een Exchange 2013 server, is antimalware filtering standaard ingeschakeld.

Als we eens onder de motorkap kijken dan zien we bij de gebruikte executables namen langs komen als Forefront Information Protection Filtering Server en Forefront Filtering Server. Op zich zou je denken dat we het hier over nieuwe Forefront producten hebben die misschien nog aangekondigd moeten worden, maar aangezien Microsoft heeft aangegeven definitief te stoppen met de ontwikkeling van FPE zal het hier niet om een opvolger gaan.

Update: De gebruikte engine is de Microsoft AV engine, dezelfde die we ook al kennen uit FPE en Microsoft Security Essentials.

image

Als we kijken naar de functionaliteit die de nieuwe malware filtering biedt dan zijn we snel klaar. We kunnen mailware filtering uitschakelen of weer aanzetten, deze tijdelijk bypassen of de opties voor notificaties aanpassen. Het uitschakelen en weer inschakelen doen we met een script wat standaard op de Exchange 2013 server aanwezig is:

cd $exscripts
.\Disable-Antimalwarescanning.ps1

En weer inschakelen:

cd $exscripts
.\Enable-Antimalwarescanning.ps1

Als we tijdelijk iets willen troubleshooten dan kunnen we malware filtering even omzeilen:

Set-MalwareFilteringServer -BypassFiltering $true

En uiteraard weer ongedaan maken met:

Set-MalwareFilteringServer -BypassFiltering $false

De rest van de beheermogelijkheden is beperkt tot het finetunen van de het updaten van de signatures en het aanpassen van de notificaties en precieze acties welke Exchange moet nemen als een fout item wordt gevonden. Deze laatste kunnen we vinden in het Exchange Administration Center (EAC):

image

In de Exchange Management Shell kunnen we dit uiteraard ook, de cmdlets hiervoor zijn:

  • Get-MalwareFilteringServer
  • Get-MalwareFilterPolicy
  • Get-MalwareFilterRecoveryItem
  • New-MalwareFilterPolicy
  • Remove-MalwareFilterPolicy
  • Remove-MalwareFilterRecoveryItem
  • Resume-MalwareFilterRecoveryItem
  • Set-MalwareFilteringServer
  • Set-MalwareFilterPolicy

Dat is allemaal leuk en aardig, maar hoe werkt dit in de praktijk? Wat als we Exchange 2013 malwarescanning gebruiken en er per ongeluk een false-positive was? Hier wordt het tricky. We kunnen de filtering alleen inn- of uitscakelen, indien ingeschakeld dan wordt het verdachte attachment altijd verwijderd. Het is niet mogelijk om deze in quarantaine te zetten. Ook is het niet mogelijk om met een whitelist te werken waarop we bijvoorbeeld de naam van een afzender, de naam van een attachment of een attachmenttype zouden kunnen zetten zodat deze nooit gefilterd of verwijderd worden. Microsoft raadt aan om in dat geval het attachment opnieuw te laten verzenden in een ZIP-bestand met wachtwoordbeveiliging.

En als er nou een attachment doorgekomen was wat wel gefilterd had moeten worden? Vrijwel alle leveranciers van dit soort software hebben een laagdrempelige manier om je bestand aan te leveren zodat zij het kunnen analyseren en waar mogelijk hun scanengine of signatures kunnen aanpassen. Microsoft heeft er voor gekozen om hier hun Technical Support kanaal voor in te zetten. Het is op dit moment ook al mogelijk om Forefront issues via dit kanaal aan te melden maar veel klanten vinden de formele afhandeling van deze cases omslachtig. Hoe dit uitwerkt zal in de praktijk moeten blijken.

Tenslotte ontbreekt het aan andere dashboard, logging en report mogelijkheden die je bij 3rd party oplossingen en bij FPE vaak voor ziet komen.

Deadlines

Alles goed en wel, maar wanneer gaat er voor bestaande klanten effectief iets veranderen? Als eerste de producten die je in abonnementsvorm afneemt:

  • Forefront Protection 2010 for Exchange Server (FPE)
  • Forefront Protection 2010 for SharePoint (FPSP)
  • Forefront Security for Office Communications Server (FSOCS)
  • Forefront Threat Management Gateway Web Protection Services (TMG WPS)

Deze subscribtions worden ondersteund tot 31 december 2015. Ook voor klanten van wie het abonnement al eerder afloopt geldt deze datum, zo hebben zij meer tijd om een alternatief te zoeken. Updates voor spam- en virusfilters worden uitgebracht tot 1 januari 2016.

Dan de ondersteuning voor ForeFront TMG 2010 Server licenties. De ‘mainstream support’ loopt tot 14 april 2015 waarna het  tot 14 april 2020 in de ‘extended support’ fase is. Hier is overigens niets aan veranderd, dit was al te lezen op de Lifecycle Support pagina’s.

Minstens zo belangrijk is om te weten dat nieuwe licenties tot 30 november 2012 aangeschaft kunnen worden, daarna zijn deze niet meer te bestellen. Wanneer er dus een project in de pijplijn zit waar deze producten deel van uitmaken, is het aan te bevelen om de software alvast aan te schaffen.

Conclusie

Exchange 2013 beschikt over ingebouwde antispam en antimalware functionaliteit, die laatste is nieuw. Waar Exchange met antispam een goede reputatie heeft schat ik in dat de functionaliteit van antimalware voor veel organisaties onvoldoende blijkt. Met name het feit dat false-positives niet te voorkomen zijn, anders dan een met een wachtwoord beveiligd ZIP-bestand, zal veel voor veel organisaties onacceptabel zijn.

Zelf zal ik met mijn klanten blijven kijken naar een geschikte enterprise-oplosing voor het scannen op virussen. Daarbij zal Exchange Online Protection zeker meegenomen worden.

9 comments:

Bert Loedeman said...

Ha Jetze,

Grappig om via Google een bericht te vinden van je neef ;) ...

Ik zit met hetzelfde probleem als jij in je blog beschrijft m.b.t. anti-spam met Microsoft Exchange Server 2013. Ik vraag me af: heb jij inmiddels een goed alternatief gevonden?

Hartelijke groeten,

Bert Loedeman

Jetze Mellema said...

Ha neef!

Dat is inderdaad grappig zeg.:)

Zelf heb ik nog niet naar alternatieven gekeken, maar ben wel steeds meer gecharmeerd van Microsofts hosted oplossing Exchange Online Protection. Zie http://office.microsoft.com/en-us/exchange/microsoft-exchange-online-protection-email-filter-and-anti-spam-protection-email-security-email-spam-FX103763969.aspx

Werkt prima, maar dat geldt natuurlijk ook voor een paar andere diensten. Laat me horen wat jouw bevindingen zijn!

Anthony said...

Hallo Jetze,

moet je zowel op de client access als op de mailbox server de antispam agents installeren of niet. Kan je daar wat meer uitleg over geven. Ook het aanmaken van een antispam quarantaine mailbox interesseert me. Super informatieve blog trouwens heb je.

Cheers
Anthony

Jetze Mellema said...

Dag Anthony, bedankt voor het compliment.

Normaal gesproken wil je de agents op zowel de CAS als de Mailbox rol installeren want elke agent heeft zijn eigen taak. Daarvoor zijn dus ook de twee scripts die ik in het artikel gebruikte.

Een andere vraag is waarom je de rollen op verschillende servers zou installeren...

Erwin said...

Hallo Jetze,

Ik vroeg me af, zo tegen het eind van de lifecycle, heb je uiteindelijk een keuze gemaakt? En zijn er al FPE achtige (store level + HT) oplossingen te krijgen voor Exchange 2010/2013?

Ik voel zelf niets voor FOPE met het oog op security. Al onze gevoelige mail langs MS sturen vind ik eigenlijk geen geschikte optie.

gr
Erwin

Erwin said...

Hallo Jetze,

Ik vroeg me af, zo tegen het eind van de lifecycle, heb je uiteindelijk een keuze gemaakt? En zijn er al FPE achtige (store level + HT) oplossingen te krijgen voor Exchange 2010/2013? Heb zelf weinig kunnen vinden.

Ik voel zelf niets voor FOPE met het oog op security. Al onze gevoelige mail langs MS sturen vind ik eigenlijk geen geschikte optie.

gr
Erwin

Jetze Mellema said...

De meeste, zo niet alle, bekende AV fabrikanten hebben een versie die geschikt is voor Exchange 2010, 2013 en 2016. Mijn ervaring gaat niet veel verder dan de installatie van de producten, als consultant ben ik helaas amper betrokken bij het dagelijks gebruik.

Je zorg over FOPE (heet EOP tegenwoordig) kan ik niet helemaal plaatsen, ik denk dat Microsoft één van de beste partijen ter wereld is om je data aan toe te vertrouwen. De knappe koppen daar hebben de beveiliging van je data beter op orde dan veel andere bedrijven, laat staan hoe je het zelf in je eigen omgeving geregeld hebt. Denk aan beveiliging tegen verlies van data, de integriteit van je data, up to date houden van de software, etc.

Maar dan nog steeds is EOP maar een deel van de oplossing omdat het alleen in- en uitgaande mail kan scannen en niet kan optreden bij bijvoorbeeld een interne uitbraak.

Erwin said...

Ik hoor je argument vaker betreffende betrouwbaarheid, maar dat kan de zorgen niet wegnemen. Je data niet toevertrouwen aan een derde partij is mijns inziens altijd beter dan toevertrouwen aan een 'betrouwbare' partij. Je hebt simpelweg geen controle meer over je data en weet niet 100% zeker wat er mee is gebeurd in de handen van de derde partij.

Ik ben wel met je eens, dat als je dan toch voor zo'n constructie kiest, dat Microsoft wel een van de beste keuzes is hierin.

Jetze Mellema said...

Als ik zo vrij mag zijn (en is het mijn blog, dus ik neem die vrijheid maar even :) ) vind ik dat anno 2015 eigenlijk niet meer zo'n sterk argument. Ten eerste heb je een stuk meer controle over je data dan je zelf denkt, Microsoft voldoet aan zo'n beetje elke certificering die er op dit gebied haalbaar is en wordt daarop ook regelmatig ge-audit. Waaraan ze voldoen en welke zekerheid dat je geeft staat hier: https://products.office.com/nl-nl/business/office-365-trust-center-cloud-computing-security

Als je erg sceptisch bent dan kun je natuurlijk denken: dat zal allemaal wel, maar als mijn concurrent nu eens geld biedt aan Microsoft om mijn data in te mogen zien... Vergeet dan niet dat Microsoft, Amazon, Google en de andere spelers miljarden geïnvesteerd hebben in clouddiensten en voor het succes hiervan bijna volledig afhankelijk zijn van het vertrouwen van hun klanten. Het is dus totaal niet in het belang van Microsoft om iets met jouw data te doen wat niet afgesproken is. Voor Google ligt dit in principe iets anders omdat dit bedrijf zijn geld grotendeels verdient met gericht adverteren, maar hetzelfde geldt dat ze er meer belang bij hebben om het vertrouwen van hun klanten te laten groeien dan om het te schaden.

En dan heb je natuurlijk de praktische kant van de zaak. Ik durf met zekerheid te stellen dat de fysieke toegang tot de servers van Microsoft beter geregeld is dan die van de gemiddelde MKB-er. Natuurlijk staat mijn data ook in de cloud maar als een inbreker een rondje door het pand maakt zal hij al snel met een server onder de arm weglopen. Hetzelfde geldt voor de elektronische beveiliging, ik als vanmorgen nog het zoveelste verhaal over een Crypto Locker die bestanden in het hele bedrijfsnetwerk versleutelde. Ik denk dat de kans groter is dat deze ook in onze netwerken actief wordt dan in de cloud-omgeving van Microsoft. Of over controle gesproken, kun jij met 100% zekerheid stellen dat er op dit moment geen derde is die toegang heeft tot jouw server? Denk aan je mobieltje met wachtwoorden en openbare niet-versleutelde netwerken?

Maar uiteindelijk komt het inderdaad op vertrouwen neer. Als je het allemaal niet gelooft dan kun je het beter niet doen. Maar dan zou je eigenlijk ook nog eens na moeten denken over je andere processen, waarom dan bijvoorbeeld wel de loonadministratie uitbesteden aan een ander bedrijf, WhatsApp gebruiken, etc. Interessante discussie!