Exchange 2003 Implementatie

[thamoosio]

Hallo,

Ik heb even wat advies nodig mbt het implementeren van Exchange.

Situatie op dit moment is een klein bedrijf (minder dan 10 man) welk een server heeft staan, DL380. Tot voorkort werd alle mail vanuit de client zelf via POP3 bij de provider vandaangetrokken. Nu is de wens ontstaan om een exchange bak te implementeren, en daarbij ook te zorgen dat de externen (groep van ongeveer 20 mensen) hun email van afstand kunnen lezen. Een firewall is daarbij ook nodig.

Ik heb even gekeken naar de juniper NetScreen 5GT. Hier zit een dedicated DMZ poort op, waarop ik dan de Exchange bak wilde aansluiten. Hier wilde ik zowel de internen als de externen (OWA) bedienen met mail.

Mijn probleem is dan een beetje, dat ik denk dat de exchange bak niet helemaal veilig staat. Het liefste zou ik een front-back end config willen maken, maar ik moet voorkomen dat ik twee servers nodig heb (kosten standpunt)
Als het echt nodig is, dan kan ik ze wel overtuigen, maar mijn vraag; is het echt zo onveilig als dat ik denk?

Bij voorbaat dank!

[Verwijderd]

> valt reuze mee.

heb je een 2003 sbs of een 2003 standard met een losse exchange?

wat je kunt doen is op je netscreen ( gebruik deze router/firewalls nu een jaar of 6 en buiten de prijs, altijd erg tevreden over )geweest)):
zorg dat je eerst firmware 5.3.0r3.0 (Firewall+VPN) er op zet ( mocht je deze willen hebben/niet meer op de juniper support site kunnen inloggen, dan laat het maar even weten , email staat in m'n profiel

maak een MIP aan op je untrust , vervolgens in je policy's mapje port 25 ( mail ) en port 443 (https) door naar je exchange, liefste met deep packet inspection.
zet vervolgens bij screening alles op je untrust aan , behalve de 4 Block HTTP Components
maak geen gebruik van de DMZ port ( anders moet je of een hele boel porten doormappen naar je domain controller waardoor een DMZ eigenlijk geen zin meer heeft, of moet je 2x een AD creeren met 2x gebruikersaccounts) maar map deze 2 poorten lekker door naar je trust

als je een sbs heb draai je de internet connect wizzard ( deze creeert een ssl certificaat en locked je IIS), ander ga je op i-net opzoek naar self-cert( ff googlen) om een certificaat te creeren).

mocht je geen https poort willen doormappen, dan kun je altijd nog een PPTP of L2TP of NETSCREEN IPSEC vpn opzetten, wat als voordeel heeft dat ook je externe medewerkers gewoon de normale outlook kunnen gebruiken.

mocht je vragen hebben laat hier maar vallen

[Bor]

maak geen gebruik van de DMZ port ( anders moet je of een hele boel porten doormappen naar je domain controller waardoor een DMZ eigenlijk geen zin meer heeft

Zou je dat willen onderbouwen?

[thamoosio]

De huidige DC is een Windows 2003 bak.
De nieuwe Exchange bak wordt ook een losse windows 2003 met exchange. Géén SBS omdat daar toch wat beperkingen opzitten qua aantal connecties e.d. waar we niet aan vast willen zitten. Uiteindelijk moet de server zo'n 100 ~ 150 mailboxen kunnen bedienen.

Ik wil de externen niet laten connecten met een VPN verbinding.

Maar wat ik dus van je begrijp, is dat ik me geen zorgen hoef te maken over de veiligheid van het domein, ookal hangt de exchangebak in het domein met poortjes wagenweid open? mijn voorzichtigheid werd getriggered door een collega die zich daar nogal over opwond.. (eenmaal binenn op de exchange bak, hele domain voor het grijpen etc.)

overigens dank mbt de uitleg op de netscreen. Zal zeker gebruik maken van je hulp wanneer alles zover is, maar dat is niet direct op korte termein (paar maanden zeker..)

kan je dat gedeelte van de self-cert even toelichten voor me?

[ Voor 17% gewijzigd door thamoosio op 03-06-2006 12:04 ]

[Verwijderd]

@ bor de wolf:

zie http://www.windowsnetwork...changeServerintheDMZ.html
of
http://www.experts-exchan...ge_Server/Q_21257369.html

wat je eigenlijk dient te doen is je AD in je DMZ beschikbaar maken.
vanuit mij beleving wil je dat helemaal niet, simpelweg om het feit dat server die in een dmz hangen vaak veel meer taken krijgen dan alleen mail of https:// ( er word bij voorbeeld ook nog een "normale website"op gedraait, waardoor ze veel eerder het doelwit van vervelende ding zullen zijn.

wat wel een idee zou zijn als er gebruik gemaakt dient te worden van een dmz , is appart bakkie die smtp voor zijn rekening neemt waar je vervolgens een virus/spam scanner en een rule processor op los laat, zodat geen "vervuilde mail" je exchange binnenkomt ( zie http://www.marshal.com/pages/mailmarshalsmtp.asp of http://www.crypsys.nl voor meer info), en daarna poort 24 vanuit dmz richting trust laat gaan.

[Verwijderd]

thamoosio schreef op zaterdag 03 juni 2006 @ 12:00:


kan je dat gedeelte van de self-cert even toelichten voor me?

zie : http://www.petri.co.il/co...your_website_with_iis.htm
of
http://www.petri.co.il/configure_ssl_on_owa.htm

[alt-92]

Verwijderd schreef op zaterdag 03 juni 2006 @ 10:59:
mocht je geen https poort willen doormappen, dan kun je altijd nog een PPTP of L2TP of NETSCREEN IPSEC vpn opzetten, wat als voordeel heeft dat ook je externe medewerkers gewoon de normale outlook kunnen gebruiken.

Met de NS Remote VPN client kun je ook niet altijd uit de voeten, PPTP ook niet.
Sommige thuisnetwerkjes of nog erger: hotel-netwerken laten geen ipsec door.
Ook niet met NAT-T.

Je zou zelfs kunnen overwegen RPC-over-HTTPS te doen, kost wel wat voorbereiding maar dan heb je wel een transparante omgeving voor je eindgebruikers

[Verwijderd]

BackSlash32 schreef op zondag 04 juni 2006 @ 13:03:
[...]

Je zou zelfs kunnen overwegen RPC-over-HTTPS te doen, kost wel wat voorbereiding maar dan heb je wel een transparante omgeving voor je eindgebruikers

je hebt helemaal elijk, hoewel ik moet zeggen dat ik weinig ervaring heb met rpc-over-https en de beveiliging er van.
Bovendien is het maar de vraag of de hoeveelheid werk die je er mee op je hals haald de moeite is voor 30 man...

[Rolfie]

Als je nu eens gewoon ISA2004 gebruikt, eventueel in een DMZ of gewoon meteen als firewall.
Je maakt een Pubish rule aan voor richting je OWA server. Als authenticatie methode kan je of Radius gebruiken, of Formbased authenicatie (FBA). Radium heeft als voordeel zeer veilig (alleen Radius hoeft maar open gezet te worden voor authenicatie, maar als nadeel dat je 2 keer moet inloggen. Als je FBA gebruikt moeten er wel meer porten open gezet worden op je firewall, maar het voordeel is dat je maar 1 keer hoeft in te loggen, en dat je niet meteen op IIS komt vanaf het Internet. Security technisch is dit een goede en secure oplossing.

[Verwijderd]

Rolfie schreef op zondag 04 juni 2006 @ 17:09:
Als je nu eens gewoon ISA2004 gebruikt, eventueel in een DMZ of gewoon meteen als firewall.
Je maakt een Pubish rule aan voor richting je OWA server. Als authenticatie methode kan je of Radius gebruiken, of Formbased authenicatie (FBA). Radium heeft als voordeel zeer veilig (alleen Radius hoeft maar open gezet te worden voor authenicatie, maar als nadeel dat je 2 keer moet inloggen. Als je FBA gebruikt moeten er wel meer porten open gezet worden op je firewall, maar het voordeel is dat je maar 1 keer hoeft in te loggen, en dat je niet meteen op IIS komt vanaf het Internet. Security technisch is dit een goede en secure oplossing.

Klopt, maar zoals topic starter al aangaf gaat dit om 30 man....

als er een apparte ISA server + hardware aangeschaft dient te gaan worden dan gaat naar mijn idee het een beetje voorbij aan de doelstelling, maar misschien heb ik het mis..

[alt-92]

Nou ja, hij geeft zelf ook al aan dat ie liever geen VPNs wil laten maken met de externe users..
thamoosio in "Exchange 2003 Implementatie"

Dus dan vallen de NSRs en l2tp verbindingen al af.
Blijft over: OWA, IMAP en RPC over HTTPS.

[thamoosio]

inderdaad.. en dan gaat mijn voorkeur uit naar OWA omdat het de bedoeling is dat ze overal hun mail kunnen bekijken, en daarbij niets hoeven te configureren in bijv. outlook. Op deze manier voorkomen we ook dat er companymail op thuis pc's wordt opgeslagen (neem ik aan..)

Super die links van SSL op OWA.!

Is de FBA genoeg authenticatie voor een veilige verbinding? Zo ja, dan is mijn keuze denk ik gemaakt.

Hoe kwetsbaar is de exchange server, en vooral mijn interne netwerk met poort 443 en 25 open naar het internet?

[Equator]

Zolang er geen exploit wordt gevonden in OWA of de SMTP service van Exchange ben je niet kwetsbaar.
Letop dat SSL implementatie op OWA alleen ervoor zorgt dat het verkeer tussen server en client versleuteld is.. De website is (op je authenticatie na) gewoon door iedereen bereikbaar.
De webserver is er niet minder kwetsbaar door bedoel ik hiermee te zeggen..

[thamoosio]

Equator schreef op dinsdag 06 juni 2006 @ 11:54:
Zolang er geen exploit wordt gevonden in OWA of de SMTP service van Exchange ben je niet kwetsbaar.
Letop dat SSL implementatie op OWA alleen ervoor zorgt dat het verkeer tussen server en client versleuteld is.. De website is (op je authenticatie na) gewoon door iedereen bereikbaar.
De webserver is er niet minder kwetsbaar door bedoel ik hiermee te zeggen..

Je pinpoint een beetje waar ik 'angst' voor heb.. maar als ik daar dus aan ga sleutelen, zorg ik er volgens mij in elke vorm voor dat mensen niet meer vanuit elke locatie en op elk moment extern hun mail kunnen lezen. (ik denk dan even aan de firewall bijvoorbeeld dicht te zetten behalve voor bepaalde IP's etc.)

zijn er andere methoden voor die ik vergeet?

[alt-92]

Equator schreef op dinsdag 06 juni 2006 @ 11:54:De website is (op je authenticatie na) gewoon door iedereen bereikbaar.
De webserver is er niet minder kwetsbaar door bedoel ik hiermee te zeggen..

Tenzij je poort 80 (oftewel: de UFBP, universal firewall bypass port) open hebt staan omdat je je CRL wil publishen, heb je alleen 443 open toch?
En dan krijg je je certificate prompt.
En dan?

[Verwijderd]

backslash32> vandaar ook mij opmerking over self-cert, dan hoef je dus niet je poort 80 open te laten staan. je cert komt gewoon over 443 mee

[thamoosio]

Heren, ik zeg mijn dank.
Ik denk dat ik hier genoeg info heb om mee te beginnen. Mochten er nog overige wensen zich aandienen als ik bezig ben en ik kom er niet uit, zal ik dit draadje weer omhoog schoppen.

Nogmaals dank!