Det kom ett mail…

från en av mina kunder med funderingar kring varför ISA skall stå på ett DMZ och om den kan ersätta en Exchange FE server.

Jag vill här delge Er alla mitt svar. Som kanske kommer att reta någon men förhoppningsvis väcker en del tankar.

Hej!

Låt oss först konstatera vad en FrontEnd Exchange 2003 server gör för nytta…

Den behöver man om man har ”flera” mailbox servrar (BE) då man kan låta användare accessa FE och den routar / hämtar data från rätt mailbox server.

Det betyder att om man har flera mailboxservrar och vill publicera OWA, ActiveSync o RPC/HTTPs så måste man ha en FE vare sig man har ISA eller inte.

Alternativet är att användare på olika mailbox servrar måste använda olika URL:er.

Har man ”bara” en mailbox server behöver man tekniskt ingen FE utan kan publicera de webbaserade tjänsterna direkt mot BE.

ISA ersätter INTE FE de två gör inte samma sak.

ISA ser till att man säkert kan publicera tjänsterna medans FE ser till att vi bara behöver en URL även om vi har många BE servrar.

Notera nu att Edge servern i Exchange 2007 har ett helt annat syfte.

Om man vill låta användare komma åt de webbaserade tjänsterna som exchange tillhandahåller är det dock många som föredrar att göra denna publicering i en ISA, p.g.a. dess http applikationsfilter och SSL bridging förmåga.

I de flesta fall skulle jag vilja påstå att huruvida det står en brandvägg framför/bakom ISA servern är helt egalt ur säkerhets synvinkel då trafiken som släpps fram till ISA är SSL och den trafiks om går mellan ISA och Exchange är SSL, ingen brandvägg som inte i likhet med ISA kör SSL bridging adderar något säkerhetsvärde. Den släpper ju bara fram TCP443 utan vidare analys.

Om man vill publicera andra exchange tjänster så beror ISAns värde på om den har ett applikationsfilter eller inte för trafiken.

Den har ju t.ex. ett ”basalt” SMTP filter där man t.ex. kan blockera VRFY kommandot, om den ”yttre” brandväggen saknar appfilter för SMTP utan bara släpper fram TCP25 till ISAn gör den i detta läge ingen nytta och adderar enligt min mening ingenting till säkerheten.

—Ang Single NIC—-

Det är ett väldigt tjafsande med att sätta ISA på DMZ och bara ha ett NIC.

Att trafiken går upp o vänder i ISA är ju bra om det för att utnyttja ISAns filter, därför stödjer man bara trafik som baseras på webproxy filtret i single nic läge.

Dessutom är det så att de flesta ju vill låta ISA autentisera emot ett AD. Detta kan man naturligtvis göra i ISA 2006 utan att ISA är med i domänen men det ökar komplexiteten och man kan då t.ex. inte välja att delegera med Kerberos. Att då låta ISA vara med i domänen är enligt klassiskt synsätt att kortsluta sitt DMZ, jag brukar därför rekommendera kunder som ”måste” har en brandvägg framför ISAn att sätta den med ett ben i den yttre brandväggens DMZ och ett ben in i LANet så att den kan vara med i domänen. Helst skall då också ISAns externa interface vara ett routat interface i den yttre så att man har full frihet att utnyttja ISAns alla funktionaliteter om man så önskar.

När den är placerad så kan man sedan välja att den används för utgående trafik, VPN osv om man så önskar utan att ändra infrastrukturen.

Att ”kräva” att trafiken till LAN:et från ISA går genom ytterligare en brandvägg som ändå bara är en ”dum” portgenomsläppare adderar inget till den ökade säkerheten.

Men kan ibland bli ett ”krav” som man uppfyller genom att låta ISA’n inre interface ta vägen via den ”stora” (dumma o dyra 😉 ,,) brandväggen man har på vägen till LAN:et.

—Varför då två brandväggar…—

Detta är den stora frågan.

I de flesta fall sätter man flera brandväggar av ”gammal” vana, men det är också så att man inte kan opponera sig mot att även en ”dum” brandvägg som ”bara” släpper fram en port inte faktiskt kan addera värde i form av att t.ex. kunna stoppa denial of service attacker.

Frågan brukar ju till stor del handla om att man inte ser ISAns som en av de bästa brandväggarna på marknaden utan som en ”proxy”.

Be dom berätta hur deras brandvägg löser ISA 2006s ”Flood Mitigation” eller hur de gör för att i deras brandvägg skanna SSL trafik.

(Idag finns till ISA addon som gör detta även för utgående trafik!)

Den har ju inte prioritering säger då belackarna. Nä inte inbyggt men köp till t.ex. Digirains Quota hanterare och se om inte de flesta klarar sig med det.

Hoppas du blivit lite klokare och som du förstår så är detta mina privata åsikter och ingen ”officiell” syn på saken från Microsoft.

Mvh

/Kent

ISA 2006 Supportability Update

Microsoft verkar ha dragit ut på SP1 till ISA 2006, men släpper nu en supportability pack för ISA 2006 så att vi kan få samma “snygga” logg och felsökning som i ISA 2004 med SP3.

http://www.microsoft.com/downloads/details.aspx?FamilyId=6F629EAC-D8C6-4437-9D20-B47B02DB413A&displaylang=en

Bara att installera!

ISA 2004 SP3 o Nitrogen

Microsoft har beslutat släppa en SP3 till ISA Server 2004. Detta ser jag som ett litet bakslag eftersom det antagligen innebär att man upptäckt, precis som jag, att kunderna inte skyndat att uppgradera till ISA 2006.

Någon kod finns ännu inte att testa men det talas om förbättrad diagnostisk hantering. Dvs förbättrad logghantering och felsökning.

Eller som det står i den engelska texten:
“ISA Server 2004 SP3 provides increased security, new troubleshooting options and tools available directly from the ISA Server Management console, new diagnostic logging functionality, and enhanced log viewer and log filtering options for ISA Server 2004 Standard Edition and Enterprise Edition. In addition, this service pack adds support for publishing Microsoft Exchange Server 2007 with ISA Server 2004.”

Man kan väl också misstänka att detta kommer att innebära att vi får se en SP1 till ISA 2006 med ungefär samma innehåll.

Så fort jag fått kod och hunnit testa återkommer jag med rapport om de faktiska förbättringar som ingår.

TAP programmet för ISA 2008 (Nitrogen) är också i startgroparna, även där hoppas jag löpande kunna rapportera om de nyheter som kommer. Jag deltar i detta på två fronter, dels själv men också som tekniskt ansvarig tillsammans med en  kund.

Verisign och ActiveSync

De flesta väljer att köpa ett certifikat från t.ex. Verisign när man börjar prata om att köra ActiveSync.

Tanken är att man inte ska få några problem med att telefonen inte “litar” på certifikatet.
Döm om förvåning när det visar sig att man kan få samma problem även med ett köpt certifikat!

Detta kan inträffa om man t.ex. köper ett certifikat utfärdat att “VeriSign Class 3 Secure Server CA”, detta är nämligen en s.k. intermediate CA och har en RootCA som heter “VeriSign Class 3 Public Primary CA”

Root CA”n finns i Mobile 5 som trusted men inte den intermediate som utfärdat den.
Detta gör att Mobile 5 kan uppfatta certifikatet som icke trusted.

Om man ska publicera ActiveSync i ISA och har ett sådant certifikat (kan tänka mig att det gäller för fler som använder intermediate CA) MÅSTE man i ISA lägga in “VeriSign Class 3 Secure Server CA” som en Intermediate CA i samband med att man imorterar certifikatet.

När man exporterar Certifikatet från den IIS där man gjorde requesten bockar man lämpligen i att ta med alla certifikat i pathen så får man med sig både intermediate certifikatet och rootcertifikatet att installera på ISA”n.

ISA kan nu ge Mobile 5 “hela” pathen för certifikatet och telefonen kan se att den kommer från en “trusted” root CA.

Kan man ha för många regler?

En kund undrade i veckan om man kunde ha för många regler och jag sa lite “självsäkert” att antalet regler inte spelar någon roll i ISA Server. Dom påstod då att “någon” sagt att vid ca 250 regler så “bryter” den ihop.

Upp till bevis tänkte jag och har igår testat.

Jag gjorde ett litet script (maila om ni vill ha en kopia) som genererade ett antal regler av normal karaktär (specifikt protokoll, UserSet med 2 st domänkonton, internal to external).
Jag satte det att på min ISA Server 2006 (P4 2,8Ghz, 1GB RAM) generera 500 regler.
Det tog lite tid för jag gjorde apply efter varje ny regel så vartefter tog det längre och längre tid att skapa nya regler.
Totalt jobbade skriptet i ca 2 timmar och datorn låg då på en jämn 50-70% CPU belastning.

Under skapandet satt jag och surfade, lyssnade på radio kikade på mediasändningar och fick inte ens ett hack i en film. Jag kunde alltså inte se att jag fick någon prestanda-påverkan.

När det var klart kontrollerade jag återigen prestandan och kunde då se att den inte drog nämnvärt mer RAM än innan och inga prestandaproblem trots att den regel som jag nu använde för att t.ex. kunna surfa var regel nr. 520.

En liten försämring kunde man se när man gjorde ändringar i regelverket, apply tog nu lite längre tid 15-20 sek.

Jag kan sammanfattningsvis bara konstatera att antalet regler inte spelar någon som helst roll för prestandan i en ISA Server.

Att administrera 500 regler däremot är en helt annan sak Wink

Det förargliga frågetecknet

Har i ett kundprojekt sprungit på ett “dumt” beteende hos ISA.

Om ni vill göra mer avancerade Path regler så kommer ni att upptäcka att ni inte kan ha ? med i pathen.

I hjälpen nämns att man kan avsluta med ett * wildcard och att detta endast kan finnas i slutet av en path. Men i övrigt ser det ut att vara en strängjämförelse.

Mitt problem kom när jag ville filtrera på den path som ActiveSync genererar.
Där är pathen alltid i stil med
HTTP://mail.company.com/Microsoft-Server-ActiveSync?User=kent&DeviceId=12345654321A01234*
Idéen var att med hjälp av denna begränsa vilken kombination av UserID och DeviceID som kunde användas, och samtidigt göra det lite svårare för en hacker som nu måste lista ut den device-unika GUID som en device använder som DeviceID.

Denna idé kom alltså till korta när det visar sig att ISA inte läser bortom det lilla frågetecknet.
Tyvärr för min del så har detta dokumenterats på bl.a.
http://www.microsoft.com/technet/isa/2000/plan/faq-urldomainnamesets.mspx och gäller som det verkar även för ISA 2004 0ch ISA 2006.