Érvek az ISA2004 mellett IV.
2004/11/27 15:12
518 megtekintés
A cikk már legalább egy éve nem frissült, az akkor még aktuális információk lehet, hogy mára elavultak.
ISA 2000 szerverünk van és elégedetlenek vagyunk? Éppen a frissítést fontolgatjuk? Ideje megismerni az új változatot? Ebből a cikksorozatból választ kaphatunk néhány kérdésre.

Az e cikkben felsorolt újdonságok

  1. Port átirányítás a web- és szerver publikáló szabályoknál egyaránt
  2. A forrás IP-k megőrzése a web publikálásnál
  3. Forms-based hitelesítés generálása az Exchange-től függetlenül

1. Port átirányítás a web- és szerver publikáló szabályoknál egyaránt

Az egyik leggyakrabban emlegetett kifogás az ISA 2000-el kapcsolatban a szerver publikálásnál használatos port átirányítás gyengeségéire vonatkozott. Például egy SMTP szerver publikálás esetén (az ISA külső lábán), nem volt lehetőségünk a 25-ös porttól eltérőt használni a belső levelezőszervernél sem, pedig ma már ezt a funkciót még az egyszerű, pártízezer forintos, hardveres SOHO tűzfalak is tudják. Persze az ISA 2004 is tudja, sőt mostantól nagyon egyszerűem megoldható ez a probléma a "Server Publishing Rule" varázslóval. Azaz bármilyen bejövő portot, bármilyen belső port felé át lehet irányítani. A webszerver publikálásnál sok változás nincs a fentiek érvényén kívül, annyit viszont ehhez a részhez még érdemes elmondani, hogy tetszőleges számú, egyéni "listener" ("figyelő"?) felvételére van lehetőségünk, amelyeket egyesével használhatunk is a kulönböző szabályoknál.

2. A forrás IP-k megőrzése a web publikálásnál

ISA 2000 esetén ha egy publikált webszerverrre érkezik kívülről, azaz az internetről egy kérés, akkor a kérés forrását nehézkes kideríteni. Ez azért van, mert a naplóállományokban a tűzfal IP címe fog látszani, mivel a webszerver a kérést a tűzfaltól kapja és neki is küldi vissza a választ, így a webszerver elvileg nincs is kapcsolatban a távoli kérővel, a tűzfal intézi a nevében az összes tennivalót. Ez legalább két okból is probléma lehet:

  1. amennyiben szeretnénk egy-egy pillantást vetni a látogató címére,
  2. ha a webszerver statisztikát kívánnánk készíteni.

Persze a tűzfal naplóállományából kideríthetjük, hogy honnan, milyen kérés jön, de ez nehézkes és fárasztó folyamat is lehet, mondjuk egy hatalmas naplóállománynál. Az ISA 2004-ben viszont egyszerűbb a helyzet, van lehetőségünk arra, hogy megadjuk, mi legyen a forrás IP címével, azaz a távoli gép IP címe szerepeljen a webszervernek továbbküldött kérésben vagy a tűzfalé. Meg kell jegyeznünk még azt is, hogy nemcsak a webszervereknél, hanem bármilyen más publikálási szabálynál is rendelkezésre áll ez a lehetőség (a képen pl. egy FTP szerver publikálás részletei láthatóak), illetve akár azonos típusú publikálási szabályonként külön-külön is változtatható.

3. Forms-based hitelesítés generálása az Exchange-től függetlenül

Az Exchange Server 2003 volt az első Exchange szerver, amelyben az OWA-val (Outlook Web Access = a népszerű webes levelező kliens) kapcsolatban megjelent a cookie alapú, ún. Forms-based (űrlapos) hitelesítési lehetőség. A megszokott felhasználónév/jelszó felugró panel helyett egy weblapot kapunk az OWA-ba bejelenkezéskor, amelyen a felhasználónevet tartomány/felhasználónév alakban kell megadnunk, valamint lejhetőségünk van választani az OWA felületét illetően. Két választási lehetőség van:

  • a Premium (IE-ből, komplexebb lehetőségek, ám nagyobb sávszélességet igényel),
  • Basic (bármilyen böngészőből, egyszerűbb, de gyorsabb felület).

Választhatunk még az alapján is, hogy mennyire biztonságos helyről próbálunk belépni az OWA-ba, azaz "Public or shared computer" (nyilvános vagy mások által is használt), vagy "Private computer", azaz olyan számítógép amelyhez más nem férhet hozzá rajtunk kívül. A két beállítás közötti különbség az x idő utáni automatikus kiléptetésben és a csatolások kezelésében van. A nagy durrranás az, hogy az ISA 2004-ben az Exchange-től függetlenül is beállíthatjuk ezt az azonosítást, pl. egy Exchange 5.5 esetén is, mivel ebben az esetben az ISA "átveszi" a hitelesítést az Exchange szervertől. Így aztán az ISA-n szabályozhatjuk például a következőket:

  • az egyes biztonsági szintekhez tartozó time-out (időtúllépés) értéket,
  • az egyes biztonsági szintekhez tartozó csatolás kezelést,
  • az ISA legkülső rétegében végzett azonosítást.

Saját tapasztalatom alapján viszont egy további kellemes előnyét is kiemelhetem ennek az új lehetőségnek, ugyanis megtehetjük azt, hogy az ISA-án beállítjuk ezt a fajta hitelesítést, a belső Exchange szerverben viszont nem. Ekkor az a kellemes helyzet adódik, hogy belül semmi nem változik (nem is kell, hiszen a biztonsági szintekkel és a sávszélességgel sincs gond), viszont külső használatkor biztonságosabbá tehetjük és felgyorsíthatjuk az OWA szerverünket. Az utóbbira főleg szükség van a Közháló esetében, ahol a tipikus uplink 96 Kbit/s, ami borzasztóan kevés bármilyen szolgáltatás publikálásához.

A Forms-based hitelesítés további feltételei:

  • SSL engedélyezése a listener-en és a webszerveren,
  • Nem variálható más azonosítási módszerrel (Basic, Integrated), de ez az OWA esetén nem gond,
  • Az Exchange kiszolgálón a Basic authentikációt engedélyezni kell.

Csatlakozz hozzánk!

Ajánljuk

European Schoolnet Academy Ingyenes online tanfolyamok tanároknak
School Education Gateway Ingyenes tanfolyamok és sok más tanárok számára
ENABLE pilot Program iskoláknak a bullying ellen
eBiztonság Minősítés Minősítési rendszer oktatási intézményeknek