Microsoft ISA Server 2004 bemutató
A Microsoft Internet Security and Acceleration Server 2004 már nem csak egyszerű kezelhetőségével, de aprólékos konfigurálási lehetőségei révén is erős ellenfele a konkurens tűzfal és proxy termékeknek, és végre bármilyen hálózati topológiára alkalmazhatóak biztonsági szolgáltatásai. Cikkünkben bemutatjuk, hogyan.
A Microsoft az utóbbi időben fokozottabb figyelmet szentel alkalmazásainak és operációs rendszereinek védelmére. A Windows XP második javítócsomagja több lényeges biztonsági rést foltozott be, és egyszerű eszközökkel segíti az átlagfelhasználó tájékozódását saját számítógépének biztonsági beállításai között. A Microsoft megoldások szerveroldalát képező Windows Server 2003 is számos biztonsági szolgáltatással rendelkezik, azonban egy teljes informatikai hálózat biztonsági problémáinak általános kezelésére ezek közel sem elegendőek.
A Microsoft közel négy éve jelentette meg az ISA Server 2000 néven ismert tűzfalmegoldását, mely egyszerű felület segítségével tette lehetővé a hálózaton átfolyó csomagok útjának szabályozását. Mint minden első generációs termék, ez is komoly hiányosságokkal rendelkezett számtalan területen; rugalmasság terén nem volt képes felvenni a versenyt a Linuxon, és más platformokon elérhető szoftverekkel. Az ISA Server 2004 már nem csak egyszerű kezelhetőségével, de aprólékos konfigurálási lehetőségei révén is erős ellenfele a konkurens termékeknek, és végre bármilyen hálózati topológiára alkalmazhatóak biztonsági szolgáltatásai.
A modern tűzfalak két alapvető módszert kínálnak a problémák leküzdésére: az általánosabb megoldás a beérkező adatcsomagok fejlécét vizsgálva, annak küldőjének és úticéljának meghatározása után dönti el, hogy az adott csomag továbbítható-e, illetve milyen -- az eredetileg meghatározottól eltérő -- célponthoz jusson el. A másik, modernebb személet a csomagok tartalmát is vizsgálja, és képes észlelni az amúgy veszélytelen csatornákon közlekedő kártékony adatokat. Utóbbi megoldással könnyedén megállíthatóak a Nimdához és a Code Redhez hasonló vírusok, amelyek kifejezetten az OSI-ISO modell alkalmazási rétegegében vernek tanyát, és ezáltal a korábbi tűzfalak számára észrevétlenek tudnak maradni.
Az ISA Server 2004 bejelentkező képernyője
Szintén gyakori probléma, hogy a veszély olyan csatornákon közelít, melyek vizsgálatára az átlagos tűzfalak képtelenek. Ilyen például az SSL-en keresztül lefolytatott kódolt adatkommunikáció; ennek tartalmi vizsgálatához az adatok dekódolására is szükség van. Mind a mai napig komoly biztonsági kockázatot jelent adott portokat nyitva hagyni a külvilág felé, ezért szintén elterjedőben van az az ötlet, hogy a két fél közt megkezdett kommunikációt egy tartományból véletlenszerűen kiválasztott porton keresztül folytatják le, ami kizárólag a kezdeményezett kommunikáció esetén nyílik meg, esetenként más-más helyen. Ez a módszer az alapja az RPC-nek (Remote Procedure Call) és az UPnP-nek (Universal Plug and Play) is. Természetesen az adatátvitel megkezdéséhez egy már ismert portra kell csatlakozni a szerveren (ez RPC-nél a 135), de a hálózati kommunikáció alkalmazás-rétegében ki lehet szűrni, hogy erre a portra olyan adat érkezik-e, ami egy RPC kezdeményezés, vagy esetleg más jellegű, támadó kód -- ezáltal az RPC port nincs tényleges veszélyben. Az RPC kérés során a kezdeményező fél megkapja a számára nyitott port számát, ezt követően a kapcsolat lezárásáig kizárólagos használati jogot élvez rá. A tradicionális tűzfalak esetében valamennyi portot folyamatosan nyitva kell tartani, amin akár csak felmerül, hogy adatkommunikáció fog zajlani, és mindre ki kell alakítani a megfelelő védelmi stratégiát -- ez még akkor is igaz, ha a használatban lévő szervertermékek képesek lennének RPC-alapú kommunikációra, de a tűzfal maga nem.
A leggyakoribb lekérések azonban továbbra is a HTTP protokolon keresztül érkeznek, jellemzően a 80-as portra, lévén ezt a legtöbb tűzfal átengedi, és ezáltal a különféle biztonsági megoldások nem akadályozzák az ezen kommunikáló szoftverek működését. Ilyen esetekben gyakorlatilag csak a tartalmat figyelve lehet megelőzni az esetleges támadásokat. A webes lekérések esetében szintén a tűzfal feladata a lekért honlapokban szereplő linkeket átalakítani, ha a külvilág számára látszó útvonalak a védett szervereken máshol találhatóak. Ezáltal a tűzfal központi helyen ad lehetőséget az engedélyezett lekérések vizsgálatára, hiszen minden egyes kérés rajta fut keresztül, és itt dől el, hogy melyik merre haladjon tovább, amennyiben a kérdéses adatfolyam nem tartalmaz veszélyes szállítmányt.
Természetesen a tartalmi vizsgálat jelentős terhet ró a tűzfalra, ennek mértéke a beállított alkalmazás-szintű vizsgálatok számával és komplexitásával arányosan növekszik.
[oldal:Felhasználói felület, szabályok, entitások]
A Microsoft ISA Server 2004-ben a felhasználói felület lényeges változásokon esett át: megmaradt ugyan a Management Console fanézete a bal oldalon, amivel a funkciócsoportok közt lehet navigálni, de ezen felül megjelent az Office alkalmazásokból ismert Task Panel. Ezen a szoftver adott területére vonatkozó, leggyakrabban használt műveletek érhetőek el, általában varázslók formájában, amik minden lépésnél részletes segítséget nyújtanak az adott feladat elvégzéséhez. A módosult felület legnagyobb előnye azonban az újragondolt felépítés, ami nagyrészt a szükséges listák és általánosan használt objektumok összevonása és rugalmasabbá tétele révén vált lehetségessé.
A szoftver telepítése után rögtön megadható az ISA Server 2004 hálózatban betöltött szerepe templatek segítségével. Ezáltal a legáltalánosabban használt tűzfalszerepekhez tartozó beállítások automatikusan érvényre lépnek, és abból kiindulva lehetséges a további testre szabás elvégzése. A templatek közt megtalálható a Single Network Adapter, a Back Firewall, a Front Firewall, a 3-leg Perimeter és az Edge Firewall. Az, hogy ezek közül melyik a számunkra hasznos, gyakran eldönti a hálózati topológia helyettünk, hiszen az ISA Serverhez csatlakoztatott hálózatok és a telepített hálózati kártyák már eleve szűkítik a lehetőségeket.
Ellentétben az ISA Server 2000-rel, az ISA Server 2004 tetszőleges számú hálózat definiálását teszi lehetővé. Ezeket IP tartományok képében kell rögzíteni. Ennek következménye, hogy már nem képezi a rendszer részét az eddig kulcsfontossággal bíró LAT (Local Address Table), hiszen az új szoftver dinamikusan kezeli a hálózatokat, és bármely kettő között engedélyezi a csomagszabályok felállítását. Mivel a hálózatok száma és típusa változhat, érvényét vesztette a korábbi módszer, miszerint minden LAT-ban szereplő hálózat és az ettől eltérő hálózatok NAT-ot (Network Address Translation), míg a külső hálózat (external network) és a demilitarizált zóna (DMZ) kizárólag Route segítségével kommunikáltak. Az ISA Server 2004-ben a hálózati szabályok révén tetszőlegesen beállítható, hogy NAT, vagy Route alapú csomagtovábbítás történjen.
Az alkalmazásszintű szűrők listája
Az ISA Server 2004 háromféle szabálytípust különböztet meg egymástól, ezek határozzák meg a tűzfalon keresztül lefolytatott kommunikáció tulajdonságait. Az általános tűzfalképességek az Access szabályokkal használhatóak ki. Minden Access szabályhoz megadható, hogy a hozzárendelt forráshálózatokból mely célhálózatokba, milyen protokolokra és feltételekre, milyen tartalomtípusra, és mely felhasználókra, csoportokra érvényesek. Amennyiben a szabály engedélyező, úgy a szabály által leírt kommunikációt az ISA Server 2004 lehetővé teszi. Tiltó szabály esetén nincs lehetőség az adattovábbítás elvégzésére.
A Server Publishing szabályok a hálózati szerverek tűzfalbeállításainak meghatározására használhatóak. A szervereken futó szolgáltatások megadásával az ISA Server 2004 engedélyezi a megadott hálózatok számára a szerver adott szolgáltatásaihoz tartozó hálózati erőforrások elérését. A szolgáltatások közül kiválasztható többek között a DNS Server, az Exchange RPC Server, az IMAP és IPSec Server, a Microsoft SQL Server, és a levelezésre használt POP3, SMTP is. Ezek némelyike SSL-lel támogatott változatban is elérhető.
A harmadik csoportot a Web Publishing szabályok alkotják. Ezekkel adható meg, hogy az ISA Serverre kötött hálózatok webszerverein futó honlapok miként, milyen URL-en érhetőek el. A rendszer támogatja az SSL kommunikációt is, amit kétféleképpen lehet igénybe venni: az SSL Tunneling választásával az ISA Server 2004 egyszerűen továbbítja a célszervernek a kódolt lekérést, míg az SSL Bridging esetében a kódolt adatmennyiség tartalmának vizsgálatára is lehetőség nyílik -- ilyenkor a beérkező adatokat az ISA Server dekódolja, megvizsgálja, és ha változtatni kellett a tartalmán (pl. link translation történik az adatokon), akkor újra is kódolja.
A szabályokat sorrendtartó listában rögzíthetjük, ezzel elérhető, hogy a lista elején található elemek fölülbírálják az alattuk találhatóakat. Nem véletlen emiatt, hogy a listában az elsőként rendelkezésre álló szabály mindent letilt, és erre építhetőek rá mindazon általunk meghatározott szabályok, amik a hálózati erőforrások elérését engedélyezik. A módszer előnye, hogy az olyan esetekben, amikor egy általános esetet szeretnénk felvinni szabály formájában, de néhány kivételt definiálunk mellé, azt egy általános engedélyező, és egy fölé elhelyezett, egyedi esetre szóló tiltó szabállyal tehetjük meg. Korábban, az ISA Server 2000-ben valamennyi packet filter és site and content tiltó szabály előbb került kiértékelésre, mint bármely engedélyező szabály -- vagyis attól függetlenül, hogy a listában elhelyeztük őket az általunk kijelölt helyre, a tényleges működés szemszögéből mindig ezek az elemek szerepeltek a lista legelején. Ez a probléma a 2004-es változatban már nem áll fenn.
[oldal:Felhasználói felület, szabályok, entitások II.]
Újdonság még a Show System Policy funkció is. Használatával megtekinthető az operációs rendszer által használt szabályok csoportja ugyanabban a listában, mint ahol a tűzfal szabályait felvesszük, és innen akár módosíthatóak is. Ezek a listaelemek nem tartoznak az eddig érintett három szabálycsoport egyikébe sem, ezért szerkesztésükre eltérő felület áll rendelkezésre (gyakorlatilag az operációs rendszer hálózati-szintű házirendjeinek szerkesztésére van itt egy helyen lehetőség). A rendszerszabályok minden esetben az általunk megadott szabályoknál nagyobb prioritással kerülnek be a listába, tehát ezeket felüldefiniálni magasabb szinten nem lehet.Az ISA Server 2004 általános konfigurációs panelján több, a szabálykezeléstől részben eltérő funkciót találhatunk meg. Itt limitálható az egy időben létrehozható kapcsolatok száma is; beállítható, hogy egy másodperc alatt hány új kapcsolat nyitható, illetve az is, hogy egy adott kliensről egyszerre hány kommunikációs csatorna lehet nyitva. Ezeket akár egyes IP címek, tartományok szintjén is meg lehet határozni. Ugyancsak itt állítható be az illetéktelen behatolás észlelésének módja, és a DNS támadások kiszűrése. A szoftver védelmet biztosít a WinNuke, Land, Ping of Death, az IP- és portszkennelések és az UDP bombák ellen.
A tűzfalszabályok listája
A ISA Server 2004-ben véghezvitt szabály és beállítás-változtatások nem lépnek azonnal életbe, csak az Apply gomb megnyomása után. Ilyenkor a rendszer elvégzi az általunk leírt tűzfal előállításához szükséges lépéseket, amihez szinte valamennyi, korábban is rendelkezésre álló hálózati szolgáltatást felhasznál. Amennyiben nem vagyunk elégedettek a módosításainkkal, és nem akarjuk a gépparkra alkalmazni, a Discard gombot választva visszatérhetünk a kezdeti állapotba. A tűzfal konfigurációja bármikor lementhető egy XML fájlba, és ezekből az állományokból egyszerűen visszaállítható a rendszer korábbi állapota. A nagyobb változtatások előtt maga az ISA Server javasolja biztonsági mentés készítését a jelenlegi tűzfalfelépítésről.
Az alkalmazás jobb oldalán található panelen megjeleníthető a ToolBox is, ami a szabályokban használható valamennyi entitás kiválasztására, felhasználására (akár drag & droppal) és módosítására, felvitelére ad lehetőséget. Lehetőség nyílik innen az összes rendelkezésre álló protokol megtekintésére, újak hozzáadására, felhasználói csoportok definiálására, tartalmi típusok meghatározására, valamint az ütemezések alapját képező információk megadására. A Network Objects szekcióban hozhatunk létre hálózati halmazokat, amikben az általunk meghatározott hálózatokat csoportosíthatjuk tetszés szerint. Ugyanígy lehetséges számítógéphalmazok, címtartományok, alhálózatok létrehozása. Itt vehetőek fel a Web Listenerek is, amiket Web Publishing szabályokhoz kell minden esetben megadni; ezek határozzák meg, hogy az ISA Server milyen IP címeken és portokon figyeli a webes lekéréseket.
Adminisztrációs lehetőségek
A rendszer karbantartását végző felhasználókat és csoportokat egy helyen, az Administration Delegation varázsló segítségével határozhatjuk meg. Számukra három különböző jogosultsági szintet adhatunk meg: Basic Monitoring, Extended Monitoring és Full Administrator.
[oldal:Webes szolgáltatások, levelezőszolgáltatások]
A Microsoft IIS (Internet Information Server) szolgál a legtöbb Windows-alapú szerver webszervereként, valamint alkalmazásszervereként. A vállalat minden IIS környezet mellé javasolja az ISA 2004 Server tűzfalas környezetének kialakítását, mivel a védelmi funkciókon kívül számos újdonság található a szoftverben, ami segíti a honlapok publikálását.
A Web Publishing szabályok segítségével megadható, hogy egyes weboldalakat a megadott hálózatokból milyen URL-en lehet elérni, ezáltal egy többszerveres, több honlapot üzemeltető szerverparkot bármely hálózat felé egyedi arculattal lehet felruházni. Korábban, az ISA Server 2000 arra nyújtott lehetőséget, hogy ha a webes lekérés egy hoston belül hivatkozik egy altartományra (pl. www.hwsw.hu/products), akkor annak egy másik hostra átirányítva ugyanilyen altartományra kell hivatkoznia. (pl. www.hwsw2.hu/products). Hasonlóképpen, az altartomány megadása nélküli linkeket kizárólag teljes hostra tudta továbbítani. Ez a 2004-es verzióban már lényegesen rugalmasabban kezelhető, hiszen bármilyen beérkező URL tetszőleges linkre továbbítható.
Igaz, hogy ezzel a megoldással egységesen konfigurálhatóak a kívülről látható URL-ek, de a lekért tartalmi oldalak nagy eséllyel olyan linkeket fognak tartalmazni, amik nincsenek tisztában azzal a ténnyel, hogy a végfelhasználó más néven éri el a kérdéses oldalt. Az ilyen oldalakon található linkek többsége nem fog működni, hiszen azok olyan címekre mutatnak, amiket a végfelhasználó gépéről el se lehet érni. Ilyen esetekben használható hatékonyan a Link Translation névre hallgató szűrő, ami a lekért weboldalakban kicseréli az általunk meghatározott siteokra mutató linkeket olyanokra, amiket a felhasználó gépéről is meg lehet nyitni. A Link Translation nem kizárólag HTML tartalomra alkalmazható; más tartalmi típusokon is képes elvégezni a szükséges átalakításokat.
A tűzfal hálózati topológiájának megadása
A SharePoint portált használók számára nagy előnyt jelent ez, mivel végre megoldható általa, hogy a vállalat belső és külső hálózatáról egyszerre el lehessen érni a tartalmi oldalakat. Az ISA Server 2004 automatikusan támogatja a http:// és a https:// kezdetű címek átalakítását, attól függően, hogy az adott webhelyet melyik protokolon keresztül érjük el. A Link Translation alapbeállítás szerint bekapcsolt állapotban van, és minden ISA Server 2004 kiadásban elérhető, ellentétben az ISA Server 2000-rel, amihez elsőként a Feature Pack 1 részeként jelent meg ez a technológia. Természetesen a be- és kikapcsolásához már nincs szükség az érintett szolgáltatások újraindítására.
A Web Listenerek módosítása sem vonja már maga után a Web Proxy szolgáltatás újraindítását a 2004-es változatban, mivel nem is módosít a szolgáltatás alapvető paraméterein, ami miatt ez korábban szükséges lépés volt. Az ISA Server 2004 funkcionalitása átcsoportosításra került a szolgáltatások között, és most a Microsoft Firewall szolgáltatás kezeli a Web Publishing, Server Publishing szabályokat, a kimenő webeléréseket, a tűzfal klienst és a SecureNAT képességeket is. A korábbi verzióban ezen modulok egy része a Web Proxy szolgáltatásban kerültek megvalósításra.
A rendszer lehetőséget biztosít a rajta HTTP protokolon keresztül átfolyó adatok cachelésére, ezáltal azokat újabb lekérés esetén nem kell újra letölteni a kérdéses szerverről. A cachelés nem csak ad-hoc lekérések esetére alkalmazható: megadható, hogy mely siteokat szeretnénk rendszeres időközönként lekérni az ISA Server köztes tárhelyére, hogy ezzel a gyakran látogatott oldalak közelebb kerüljenek a végfelhasználókhoz, ezzel is gyorsítva azok elérésének sebességét. Arra is lehetőség van, hogy ez ilyen cachelési feladatokat a rendszer akkor végezze csak el, amikor alacsony a kiterheltsége, hogy a rendszerint fontosabbnak tekinthető tűzfalfunkciókat ne lassítsa le.
Az ISA Server 2004 négy konkrét lehetőséget biztosít levelezőszerverének, a Microsoft Exchange Server távoli elérésére, hogy a levelezőrendszerek is a biztonságos tűzfalon keresztül működjenek. Mind a négy más-más felhasználási területen alkalmazható hatékonyan. Az első az Exchange képességeit szabványos SMTP és POP3 szolgáltatások képében ajánlja ki a külvilág számára. A második Exchange megjelenési felület a biztonságos protokolon keresztül elérhető Outlook Web Access (OWA). A harmadik és negyedik megoldás RPC alapú kommunikációt folytat az Exchange Server és az Outlook kliensek között. Ez mind a hagyományos, mind az RPC over HTTP (HTTP-n keresztül történő RPC kommunikáció) módszerrel igénybe vehető.
Az ezekhez mellékelt varázslók minden szükséges szabályt automatizáltan felvesznek, és minimális adminisztrátori segítséget igényelnek csak. Egyetlen kivételt ezalól az RPC over HTTP jelenti, aminek beállításához az Exchange Serveren a registry kézi módosításra is szükség van, nem is beszélve az utána szükséges rendszerújraindításról.
[oldal:VPN, monitorozás, naplózás, bővíthetőség]
Az ISA Server 2004 egységes kezelést biztosít a Windows Server 2003 Remote Access Serviceben (RAS) beállítható VPN csoportjainak adminisztrációjára is. A VPN (Virtual Private Networks) olyan kívülről történő hálózati elérést biztosít az egyes számítógépek számára, amivel a RAS vagy ISA Serverre történő bejelentkezés után a belső, védett hálózat erőforrásait is használhatják. Ilyenkor a becsatlakozó számítógépek saját IP címet kapnak a belső hálózatban, és ugyanolyan jogosultságok állíthatóak be rájuk, mint bármely belső hálózati gépre, erőforrásra. A kapcsolódásnál a PPTP, L2TP/IPSec protokolok egyaránt használhatóak.
A VPN kliensek számára egy saját Network entitás került be a rendszerbe, vagyis valamennyi szabály működése kifejezetten az ő számukra is testre szabható. Ahhoz, hogy a VPN kliensek el tudják érni a hálózat számítógépeit, megosztásait, és a rájuk csatlakoztatott eszközöket, engedélyezni kell a CIFS (NetBIOS) protokolt. Az egy időben engedélyezett belépett VPN kliensek száma az ISA Server beállításai között határozható meg.
A VPN beállítási lehetőségei
Az ISA Server 2004 képes a VPN karantén technológiát is alkalmazni, ami egy többlépcsős beléptetési rendszert takar. Segítségével a VPN-en keresztül belépni szándékozó számítógép az alapvető autentikáció után nem válik azonnal a belső hálózat részévé, hanem előbb a VPN karantén zónába lépteti be a rendszer. A VPN karanténon belül található számítógépekhez egyedi elérési jogok adhatóak meg; ilyenkor a VPN kliens a kritikus szervereket és erőforrásokat nem látja. A karanténba kerülés után az ISA Server megkísérelhet lefuttatni beállított biztonsági teszteket az érintett számítógépen, hogy ellenőrizze, megfelel-e a belépni szándékozó gép az általa támasztott követelményeknek. A rendszer megkövetelheti a tűzfal, vagy a legfrissebb patchek telepítését, esetleg a legújabb vírusdefiníciós fájlok meglétét, hogy az újonnan érkező szereplő ne fertőzhesse meg a belső hálózat többi számítógépét, és a későbbiekben hozzá került adatokat ne lopkodják el illetéktelenek backdoorokon keresztül. Ez az ellenőrzés az adminisztrátor által módosítható script formájában jelenik meg.
Amennyiben a VPN kliens a beállított időtartam alatt nem tudja biztonságosságát garantálni, a konfigurációtól függően kikerülhet a karanténból is. Ha azonban sikerül megfelelnie a követelményeknek, beléphet a belső hálózatra, és legközelebb már nem szükséges végigjátszania ezt a procedúrát. A beléptetéshez az ISA Server a Radius technológiát is támogatja.
A Microsoft ISA Server 2004-ben az aktuális adatok és események megtekintésére szolgál az alkalmazás Dashboard elnevezésű oldala. Itt egyszerre láthatóak a rendszert érintő legfontosabb állapotok, események és teljesítménymutatók. A Monitoring alrendszer további oldalain külön foglalnak helyet a figyelmeztetések, a belépett session-ök, az ISA Serverhez kapcsolódó szolgáltatások állapotjelentései, a hálózati kapcsolódást ellenőrző jelentések, és az általános célú naplózás. Készíthetőek megadott időtartamokról is összesített jelentések, melyek tényleges elkészítéséért az ISA Server felelős. A naplózásnál jól használható felület segítségével oldható meg a lementett események szűrése és visszakeresése. Külön parancsikont kapott a Start Menüben az ISA Server Performance Monitor, ami egy testre szabott Microsoft Management Console alatt futó teljesítménymérő alkalmazás.
A dashboard
A rendszer Enterprise kiadásának megjelenési dátuma még kérdéses, vagy még az idén, vagy jövő év első felére várható. Pontos specifikációja jelenleg nem ismert, de az előzetes információk alapján a magas rendelkezésre állás, hibatűrés, és a skálázhatóság terén rendelkezik majd új képességekkel.
Az ISA Serverhez érkező SDK-val a vállalatok -- és a ráérő fejlesztők -- saját ízlésüknek megfelelően szabhatják testre az ISA Server MMC beépülő modulját, felhasználhatják az a szerverszoftver COM-os menedzsment-interfészeit, írhatnak Web Filtereket a Web Proxyhoz, valamint az alkalmazás-réteget vizsgáló és módosító filtereket.
A Microsoft ISA Server 2004 használata lényegesen egyszerűbbé vált elődjéhez képest, és végre kivitelezhető vele a komplex hálózati infrastruktúrák védelme is. A tesztelés során felmerült problémák száma elenyésző volt mind számukat, mind jelentőségüket tekintve, bár mindenképpen zavarónak tekinthetőek. Az egyik hiányosság, hogy a beállítások módosítása nem vonható vissza lépésenként, csak egyben, ezáltal egy több órás konfigurálás során vétett egyetlen hiba miatt kénytelenek lehetünk újrakezdeni az egészet a legutolsó lementett állapottól. Ezenkívül bárhogyan próbálkoztunk az UPnP összehozásával a Windows Messenger audio képességeinek kipróbálására tűzfalon keresztül, nem jártunk sikerrel. Ez utóbbi azonban nagy eséllyel nem a szoftver, hanem a mellékelt dokumentáció hiányossága.