Category: ISA

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

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!

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

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.