Ik kan je geen 100% andwoord geven omdat ik hem zelf bij ons niet geconfigureerd heb...

Ik weet wel dat wij een certificaat gebruiken die eigenlijk al lang verlopen is maar ook nog steeds werkt zonder dat anderen dat merken. (en we hebben er niks voor betaald)

Ik heb webmail alleen maar aangezet voor gebruikers die het nodig zouden kunnen hebben als ze voor werk op reis zijn enz, maar voor alle overige gebruikers heb ik het uit gezet zodat ik de kans kleiner maak dat accounts gehackt kunnen worden.

Ik denk in combinatie met goede ISA server dat je je aardig moet kunnen beveiligen.

Misschien dat inderdaat andere mensen hier iets meer ervaring in hebben, ik hou me er ook voor aanbevolen...

Een SSL Certificaat beveiligd de verbinding zodat de informatie welke wordt ontvangen of verzonden niet kan worden afgeluisterd, dit geeft dus al veel extra veiligheid.

Een goed wachtwoord is natuurlijk een must!, maar vergeet ook je server niet met grote regelmaat te updaten.

Verder zou je kunnen kijken naar client authentificatie met behulp van certificaten, het nadeel is echter dat dit erg veel administratie met zich mee brengt.

De meeste gebruikers kiezen van een SSL beveiligde verbinding in combinatie met een goed wachtwoord! Ik koop zelf mijn certificaten altijd bij Networking4all, hier hebben ze een aantal specialisten op dit gebied welke je vast en zeker beter kunnen adviseren.

https://www.networking4all.com/nl/helpdesk/ssl+certificaten/handleidingen/microsoft/exchange+2007/

De SSL verbinding (certificaat kost tussen de 30 en 1500 euro afhankelijk van het 'merk') versleuteld de gebruikersnaam en wachtwoorden tijdens het inloggen en gebruik van de webmail omgeving. Neem een echt certificaat en geen self-signed. Die paar euro PER JAAR zorgen er in ieder geval voor dat je je browsers en OS niet hoeft te vertellen dat de root vertrouwd moet worden.

Op zich kan je best met wachtwoorden werken. Of het veilig/verantwoord is, is een tweede. Hoe groot is het risico en wat heb je (je bedrijf) te verliezen als iemand een wachtwoord 'guessed'? Dat zal je zelf in moeten schatten en daar je password policy op af moeten stemmen.

De certificaten en wachtwoorden zijn maar een klein onderdeel waar men op moet letten. Zijn alle security maatregelen genomen op de configuratie van de exchange server bijv. file permissions, draaien er nog andere services op de zelfde server die bereikbaar zijn van buitenaf. Zijn alle security patches van Exchange 2003 and SB geinstalleerd. Staan de mailboxen op de zelfde machine of werkt de exchange server als tussenstap.

Wat zijn de risico's als de medewerkers in een internet cafe hun mail lezen, en attachments open met belangrijke bedrijfsinformatie. Deze worden geached en niet automatisch gedelete. Draait er een virusscanner op de mailserver om de attachment op de server af te vangen.

Dit zijn een paar zaken waar men rekening kan houden. Het belangrijkste is een risico analyse en of je de risico's accepteerd. Wat betreft het moeilijk raden van wachtwoorden zit een gevaar dat men deze wachtwoorden weer op gaat schrijven en ik ga ervan uit dat de gebruiker het wachtwoord bepaald ipv de systeem beheerder.

Om de beveiliging te verhogen kun je ervoor kiezen om externe alleen toegang te verlenen met een verplicht persoonlijk certificaat. Het is mogelijk om in IIS in te stellen dat een persoonlijk certificaat vereist is voor toegang.
Je kunt tevens de firewall zo instellen dat externe toegang tot je server alleen over poort 443 mag lopen. I.p.v. Outlook Web Access kun je ook overwegen om Outlook te gebruiken in combinatie met RPC over HTTPS en de toegang tot OWA uit te schakelen.

"Beveiliging mag niet veel kosten. Is het gebruik van een certificaat voor een ssl-beveiligde verbinding in combinatie met een moeilijk te raden wachtwoord van de accounts voldoende ? ( extra info Exchange Server 2003 op een sb-installatie versie 2003 ! ) Tips, ervaringen, ik verneem ze graag!"

Wat is in jouw optiek een 'moeilijk te raden wachtwoord' ?

Stel je dit in doordat je zelf deze wachtwoorden kiest, of doordat gebruikers t.g.v. technisch afgedwongen policies een 'moeilijk wachtwoord' moeten instellen ?

Hoe vaak forceer je de gebruikers om hun wachtwoord aan te passen ?

Heb je een goede procedure om accounts af te sluiten zodra een medewerker uit dienst gaat, en om te zorgen dat distribution lists up to date blijven ?

Heb je alle overbodige services uitgeschakeld, en heb je door middel van port scans gekeken of er nog overbodige zaken op de machine draaien ?

Heb je een procedure om security updates uit te rollen, en heb je m.b.v. vulnerability scanning tools zoals mbsa, nessus of retina gekeken of je nog problemen aantreft ?

etc...

Bedankt voor de reacties !!

Met een moeilijk wachwoord bedoel ik bijv. P2q5rto34,
Het is de bedoeling om alleen poort 443 open te zetten !
De mailserver heeft een spam en virusfilter tevens is de IIS-server volledig geupdate.
Tevens dacht ik aan logging van alle benaderings pogingen met ip-adressen om toegang te kunnen controleren !
Ik zat te denken aan een ssl123 certificcat van Thawte.

Graag jullie gedachten/meningen over mijn ideen !

Waarom niet zelf een PKI bouwen? Dit is niet echt moeilijk. Via GPO's de benodigde trusttree op de clients plaatsen, heb je dat probleem al weer getackeld. Verder in je domain policy je passwordinstellingen aantrekken, en gebruikers hun ww laten aanpassen.
De keuze voor OWA of outlook mbv RPC over HTTPS zul je zelf moeten maken.

Door zelf een PKI te bouwen ben je vaak meer geld kwijt aan uren dan dat je gewoon een SSL Certificaat van een vertrouwde CA koopt welke je al voor een paar tientjes hebt.

Daar kunnen de meeste mensen 15 minuten voor werken.

Als je goed wil doen is er maar een manier. (Deze staat haaks op "niet te veel kosten", maar beveiliging
en goedkoop gaan nu eenmaal niet samen.

- gebruik altijd SSL voor de tunnels
- gebruik alleen echte certificaten
- Gebruik een Exchange box als een front end server. Hierbij zet je alles uit op die server. Deze Exchange Front end server
re directs naar de mailbox servers. Op de FE server laat je alleen het hoog nodige draaien zoals IIS en een aantal noodzakelijke Exchange services. De e-mail staat hier dus op
-FE server moet in de dmz geplaatst worden en netwerkverkeer tussen FE en de Mailbox server ( back end) wordt beveiligd
met SSL

- gebruik moeilijke wachtwoord => dit altijd, ook voor intern gebruik
- password policy met lock out na aantal pogingen, plus logging hierop
- hoog nivo logging op de server


Let op dat SSL encryptie veel resources kan vereisen op je omgeving. Door toepassing van de Front End server wordt dit
door de Front End over genomen.

RPC over HTTPS is mogelijk maar erg traag in de praktijk. Hiervoor moet je Outlook client aanpassen en is eigenlijk
niet een oplossing voor bijvoorbeeld toegang vanuit een internet cafe.


Al met al is dit een dure oplossing maar als je bezuinigd op een OWA oplossing neem je veel risico.

De eerste vraag van mij uit is: Wat vind je goedkoop? Wat bedoel je precies met: het mag niet teveel kosten?

Een mogelijke oplossing welke je zoekt is al beschikbaar vanaf ongeveer EUR 18,- per gebruiker per jaar als je een ASP gebruikt om je van deze oplossing te voorzien en het gaat om een kleine gebruikers gemeenschap.
Als je een grotere gebruikers gemeenschap hebt, liggen de kosten (veel) lager.

Het gebruik van SSL certificaten server-side is feitelijk een must-have, maar waarom ook niet client-side?

Je hoeft geen "echt" certificaat te gebruiken (zoals uitgegeven door Verisign etc) maar wordt zo te lezen in eerdere reacties vooral aangeraden omdat je anders met een beheers-uitdaging zit, om alle werkplekken van je gebruikers je eigen CA-tree te laten vertrouwen etc.

Er zijn echter gerenomeerde partijen welke een gemanagde PKI omgeving aanbieden. Uiteraard kan je er voor kiezen om het zelf te hosten (implementatie duurt ongeveer 3-5 dagen inclusief client roll-out). Deze omgevingen kunnen jouw gebruikers volledig secure en geautomatiseerd voorzien van client side certificaten, welke kort levend zijn (bijv 1 uur of 4 uur geldig). Je gebruikers kunnen vervolgens op de door jouw gehoste webmail omgeving inloggen, op basis van client certificate authenticatie.

De certificaten worden verstrekt op basis van een door jouw gehoste identity-store, zoals een LDAP/AD, welke bijvoorbeeld middels LDAPS of een andere vorm van encryptie met de gehoste PKI omgeving communiceert, voor het verifieren van authenticatie gegevens.

Daar het jouw eigen LDAP/AD is, kan je zelf bepalen aan welke eisen het wachtwoord moet voldoen om het certificaat te verkrijgen. Je kan er zelfs voor kiezen om zogenaamde "device-fingerprint" te combineren met de wachtwoorden. Kortweg kan een gebruiker dan enkel een certificaat krijgen als deze zijn username/wachtwoord opgeeft vanaf zijn geregistreerde pc/laptop (dit werkt op veel meer dan enkel het device MAC/IP). In dit geval zou je kunnen volstaan met een relatief eenvoudig of door de gebruiker zelf verzonnen wachtwoord, daar een derde die beschikt over het username/wachtwoord (phishing) zeer waarschijnlijk(!!) niet beschikt over de geburiker zijn/haar device. Het vaststellen van een gebruiker zijn/haar device fingerprint is over het algemeen een eenmalige aktie welke geautomatiseerd kan worden en ook opgeslagen word in je eigen LDAP/AD.

In een standaard PKI omgeving krijg je te maken met veel zaken welke het leven van een PKI beheerder een redelijke hel kunnen maken. Certificaat uitgifte, Certificaat installatie, revocatie, heruitgifte, CRL-lijsten, vertrouwen van de CA-tree op de gebruikers pc/laptop/pda etc. De eerder omschreven gemanagde PKI omgeving heeft al dit beheer zelfs uit handen gehaald van de ASP aanbieder.
- CRL is niet nodig omdat certificaten al vervallen voordat je de tijd hebt om een CRL te updaten
- CA tree vertrouwen gebeurd automatisch door een benodigde client installatie (5-8MB), welke de tree importeerd in je cert stores, waardoor zowel de ASP zijn user als server certificaten vertrouwd worden.
- (Her)uitgifte en installatie van certificaten gebeurd automatisch op basis van deze zelfde client.
- Wissen van vervallen certificaten bij de gebruiker gebeurd automatisch via dezelfde client

Vanuit security point of view, loggen je gebruikers zeer veilig in. 2 Zijdige SSL verbindingen zijn defacto bestand tegen bijvoorbeeld Man-in-the-Middle attacks. Omdat elk certificaat slechts zeer kort geldig is, is de kans dat een 1024 bits sleutel gekraakt wordt nagenoeg nul, waardoor de data-stroom tussen webmail omgeving en user device gegarandeerd is.

De aannames zijn uiteraard wel dat het device van de gebruiker secure is (Geen trojans/virusen, afdoende anti malware/firewall) en dat je netwerkomgeving waar je mailserver etc draait voldoende beveiligd is.

EDIT: Een aantal spelfouten gecorrigeerd. Tevens verwijzing naar externe url's verwijder, ik wi natuurlijk niet spammen :)

CaCert.org. Gratis certificaten aanmaken. Moet je wel op browser waarmee je verbinding wilt maken met Outlook eerst CaCert root certificaat installeren. Ander nadeel is dat certificaat dat je hebt aangemaakt telkens na 6 maanden vernieuwd moet worden.
Voor de rest werkt het prima.

sorry hoor, maar dit is eigenlijk basiskennis voor iemand die exchange beheert.
misschien wordt het eens tijd dat je op cursus gaat. (baas laten betalen natuurlijk)
Cursus met examen nummer: 70-284

een simpel CA-tje installeren en exchange beschikbaar maken via OWA middels SSL is in een half uurtje ingesteld.
alleen 443 hoeft dan nog maar open te staan voor de buitenwereld.
(ps bij voorkeur dit op een frond-end server installeren)

Groeten,
B.