TagISA/TMG

Szabálylista nyomtatása

Egyik ügyfelünknél megérett a helyzet arra, hogy gatyába rázzuk az ISA 2004 szerverük szabálylistáját. Évek hosszú során a tűzfal konfigurációja használhatatlanná evolválódott, bátran növelve ezzel az univerzum entrópiáját.

Ez egyben azt is jelentette, hogy nem halogathattam tovább a dokumentálás problémáját.

Az természetes, hogy az ISA konfig rendesen (automatikusan) mentve van. De ami nem igazán jött össze, az a szabályrendszer kiexportálása valami ember által emészthető formába. Fel is raktam anno az ISA Best Practice Analyzer-t, a Health Check része működött is, de az Isainfo a legváltozatosabb hibaüzenetekkel szállt el. Egy ideig még foglalkoztam is vele, de nem sok sikerrel. Más tool meg nem volt.
Maradtunk a mentéseknél.

De most nagyon kellett egy átlátható forma, mert konszolidálni monitorról, azt bizony nem lehet. Szöveges fájl, excel tábla… bármi, amit ki lehet nyomtatni, össze lehet firkálni.

Az első áttörés az volt, hogy az Isainfo-t kell használni. Nem, nem hülyültem meg… a helyzet az, hogy két Isainfo van. Az egyik az, melyet le lehet tölteni Jim Harrison oldaláról, a másik az, melyet beleintegráltak az ISA BPA-ba. A kettő között van egy árnyalatnyi különbség: az előbbi működik. Illetve van még egy: a két változat nem ugyanazt az xml struktúrát használja, azaz nem tudják egymás riportjait felolvasni.

Oké, feltelepítettem külön is (nem nagy ügy, javascript, fel kell csak másolni), elkészült az xml, majd a mellécsomagolt hta alkalmazással meg is tudtam jeleníteni. 1:0.

De hogy lesz ebből papír alapú lista? Hiába kerestem a ‘print’ nyomógombot, az istennek sem találtam. Hmm… hmm… Na jó, a gugli a barátunk (szószerint, mert egy igazi baráthoz méltóan már mindent tud rólunk), keressünk. Találtam is egy fórumot, ahol ezzel foglalkoznak. Odáig elmentek, hogy levelet írtak az alkotónak, hogy ugyan tegyen már bele egy ‘print’ gombot a programba. Erre ugyan nem jött válasz, de hamarosan megszületett a megoldás:

I sent Jim Harrison a suggestion to add printing to the HTA but got no reply. What I did was to hack out the right-click handler so that I can at least right-click => Print.

Azaz nyomj az alkalmazáson belül egy jobbklattyot és válaszd ki a menüből a print opciót.

Ugyanis mindenki ezerrel felejtette el, hogy ez nem exe, hanem hta alkalmazás. Azaz önállóan futtatható, web alapú. Azaz mindazon opciók működnek a jobbklattyra, mint amelyek egy böngészőben.

Innentől persze már egyszerű az élet. Jobb kattintás, Select All, majd az egész szöveg mehet át egy txt fájlba, melyet utána már úgy faragok, ahogy akarok.

Proxycfg

Csak jelzem, hogy élek.

Apró feljegyzés, leginkább magamnak.

Windows Server 2008. SP2-t felraktam. Már csak a maradék hotfixek hiányoztak. Windowsupdate, azt mondta, szétnéz… majd hibaüzenet.
Rutinos öreg róka már gépelte is be, hogy: proxycfg. Erre jött a válasz, hogy: miről beszélsz?
Hmm. Nincs. Végre egy kis izgalom. (Ezt tessék ironikusan érteni.)

De van helyette netsh. Így:

netsh
winhttp
show proxy

És igen, a beállított érték ‘direct access’ volt.

set proxy isaserver:8080
show proxy

És kész. Innentől már söpört is a windowsupdate.

Trükkös HTTPS

Az ember már azt hiszi, ismeri az ISA szervert – aztán az mégis meg tudja lepni.

Jött a kérés az ügyféltől, hogy egy kollégájuk szeretne elérni egy weblapot a 8443-as porton. – Na, megint egy istentől, embertől elrugaszkodott webmester – gondoltam – akinek túl kerek szám a 80-as.

De gond egy szál se, pillanatok alatt összedobtam a megfelelő szabályt.
– Teszteljetek! – írtam vissza.

Nem működött.

Ekkor néztem meg jobban, miről is van szó. Jé, ez https. Persze, csaptam a fejemre, csak én lehetek annyira vak, hogy nem ismerem fel, hogy a portszám csak egy számjegyben különbözik a 443-as https porttól.
– Aha, szóval ez egy szupertrükkös webmester – konstatáltam – aki így akarja átvágni a rosszfiúkat. Szvsz elég béna megoldás, ha én portszkennelnék, simán felvenném ezt is a listára, oszt jól van. Cserébe szopatják a tűzfal mögül érkezőket.

Na, mindegy, nézzük, mi van a logban.

The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests.

Kösz, Csoki. Most, hogy már tudom, hogy a legtöbb böngésző a 443-as portot használja az SSL-hez, most már biztosan nyugodtabban fogok aludni.

Némileg persze bosszantott, hogy nagyon nem értettem ezt az egészet. Miért nem engedélyezett? Hiszen tettem rá szabályt. Nehogymár ne lehessen tűzfalszabállyal egy tetszőleges portot kiengedni? A webproxy nem fogadná el? Azon lehet ugyan https portot állítani, de az nagyon nem erről szól. (Akar a fene proxykat láncolni.)

Irodalmazás. Azaz google.

Nos, kérem a megoldás az, hogy az a kis egyszerű webproxy fogadja a kéréseket a saját bekonfigurált portján – általában 8080 – majd ha https-re kell továbbmennie, akkor bepróbálkozik a 443-as porton. Ha ettől eltérő portot adok meg az URL-ben – mint ahogy a szorgos user ezt is tette – akkor döbbenet és lefagyás következik. Az a port nincs engedélyezve a webproxy számára, mint kimenő ssl port.
Természetesen létezik rá megoldás, Shinder bácsi – ki más – írt is róla: el kell menni a www.isatools.org oldalra, le kell tölteni az isa_tpr.js szkriptet (van 2006-os is)… aztán a többit már lásd ott.

Azért ez a rész külön tetszett :

Note that if you have unbound the Web Proxy filter from the HTTP protocol, then Firewall and SecureNAT client connections made through the ISA firewall will not be redirected to the Web Proxy Filter. In this case, you can create a Protocol Definition for the alternate SSL port and then create an Access Rule allowing outbound access to that protocol.

Pislant a hálókártya

Erre az esetmegoldásra nem leszek büszke, de tanulság azért akad benne.

Nagyon fontos ügyfél (habár hülyeség, mindegyik az) telefonál, hogy megállt a cégnél az internetelérés. Különböző okok miatt az ISA webproxy-ra gyanakszik. Mivel internet nélkül nincs élet, így a bejelentés magas prioritású.
A megoldást nehezíti, hogy magát a belső hálózatot nem mi üzemeltetjük, abszolút semmi hozzáférésünk sincsen. Csak az ISA-t kezeljük mi.

Megnéztem a logokat, mi is a helyzet a webforgalommal: a 80-as porton remekül hasítottak a bitek, még a vizsgálat közben is. Leellenőriztem, hogy ez valós forgalom-e. Az volt. Ment vissza a levél: Kedves Ügyfél, te valamit nagyon benéztél, az ISA-n gyönyörűen megy a http.

Amire jött az indignált válasz, hogy márpedig ez nem megy. Biztos, hogy jó forgalmat néztem?

Bakker. Nem. Hiszen a böngészők webproxy kliensek, akik a webproxy filter listening portján érik el az ISA-t. A 80-as porton csak akkor megy webes forgalom, ha nem webproxy kliens forgalmaz. A konkrét esetben a webproxy filter egy lehetetlen porton (na jó, annyira nem, de akkor sem írom le) figyelt, arra rákeresve rögtön dőltek is a denied connection üzenetek.

Hát, ez már mindjárt más. Akkor itt tényleg baj van.

Event log. Tele volt gyönyörű kövér 14118-as hibákkal. Azt mondja:

Description: The Web Proxy filter failed to bind its socket to IP address port xxxx. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.

A részletes hibakód: 0x80072740.

Néhány perc keresgélés után meg is lett a magyarázat. (Komolyan mondom, ma egy informatikusnál az internetes keresési képesség a második legfontosabb készség. Az első az angol nyelv ismerete.) Itt van a KB cikk.
(Ne keverjük össze ezzel a másik cikkel: habár a hibaüzenet ugyanaz, de ez az írás arra az esetre vonatkozik, amikor IIS is fut az ISA mellett.)

Akkor most mi is a hipotézisünk? A hétvégén valószínűleg volt egy rövid időszak, amikor leesett a link az ISA szerver belső lábáról. Ekkor a Windows Server 2003 le is kapcsolta a konkrét hálózati kártyát. Ezt hívják úgy, hogy Media Sense… és feature. Igenám, de amikor visszajön a link és feléled a hálózati kártya, az ISA szerver webproxy filtere nem képes rákapaszkodni a kijelölt portjára. Támadhatják őt a böngészőkből a kliensek, nincs bind. (A pikáns az, hogy a netstat szerint persze ott figyel a megadott porton.) Megoldás? Újra kell indítani a Microsoft Firewall klienst.
Majd.
Eddigre ugyanis az ügyfél morogva beröffentett egy linux proxy-t, mondván ők nem érnek rá. Annyiból igazuk is volt, hogy az ISA nem csak az internet felé forgalmaz, hanem a nagyon fontos anya- és társvállalatok felé is, azt a forgalmat meg még egy percre sem lehet megszakítani szolgáltatás újraindításával.
Majd este.

Addig volt időm körbenézni – és sikerült be is igazolnom a hipotézist: abban a 10 percben, amikor az ISA log szerint megállt a webproxy filter, ott figyelt két bejegyzés a system event logban is:
Warning Event 4: Adapter xxxxxxx Adapter Link Down.
Majd pár perccel később:
Information: Adapter xxxxxxx Adapter Link Up.

A többi már annyira nem érdekes, késő este újra lett indítva a szervíz, minden a helyére került.

Ja, a tanulság: ISA szerveren lehet, hogy nem hülyeség letiltani a Media Sense opciót.
(Windows Server 2008-ban alaphelyzetben le is van.)

Sorvezető

Ha ISA 2006 szerveren keresztül szeretnénk Exchange 2007 webszolgáltatásokat kipublikálni, ahhoz ma már nem kell remegő kézzel nekifogni. Az internet tele van cikkekkel, írásokkal, tényleg minden információ begyűjthető. Konkrétan itt van egy MS cikk, ez alapján nem lehet semmi gond.

Vagy mégis?

Nos, amennyiben az Exchange szervered alatt Windows Server 2008 fut, akkor azért fognak érni meglepetések.

Nem akarom végig leírni a folyamatot, az említett cikk tényleg nagyon jó. Itt inkább csak a buktatókat gyűjteném össze.

Először is, a Windows 2003-as CA szerver nem fog tudni neked SAN tanúsítványt gyártani. A következő paranccsal lehet erre rábeszélni:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Majd újra kell indítani a Certification szolgáltatást.

Oké. Fogod, elindítod a böngészőt az Exchange szerveren, rácsatlakozol a http://ca-server.cegnev.hu/certsrv/ weblapra – és már nem emlékszem pontosan, mit kapsz válaszul, de nem a megszokott nyitólapot. Valami olyasmit mond, hogy ez a tartalom a számodra nem érhető el.
Kedves.
A magyarázat itt található: http://support.microsoft.com/kb/922706.
A Windows Server 2003 alatti tanúsítványosztogató weblap olyan activex kontrollt használ, melyet a Windows Server 2008 / Vista undorral lök el magától. A megoldás: fel kell telepíteni egy patch-et a CA szerverre, hogy úgy is tudjon tanúsítványt osztogatni, ahogy az újabb fiúk kérik.

Akkor most már mehetünk is vissza a weblapra. De mégsem. Azt mondja, immár a helyi böngésző, hogy a CA weblapjának https-en keresztül kellene jönnie. Addig ő nem fogja megmutatni a tartalmat.

Kitérő: Szeneslapáttal igazítanám meg a frizuráját annak, aki ezt az egész nevetségesen idióta ‘Enhanced Security’ módú Internet Explorert kitalálta. Tipikusan az, amikor átesünk a ló túloldalára: használhatatlanná tesszük a terméket és a végtelenségig elbonyolítjuk az egyébként is meglehetősen érthetetlen konfigurálást. Ráadásul úgy tudom, W2k8 szerver alatt kikapcsolhatatlan – miközben ott már épp elég védelmet jelentene az UAC is. Amióta ez van, azóta az az első, hogy telepítem a Firefox-ot a szerverekre is. Szerveren úgyse nézeget az ember pornó oldalakat.

Fogcsikorgatás. Nyilván valahol át kell kattintani valamit, melynek a neve még csak nem is utal arra, hogy mit befolyásol. Szerencsére itt van a net, ahol egy sorstárs már megtalálta rá a workaround-ot.
Hurrá. Elérhető lett a CA weblapja.

Lehetne igényelni az Exchange tanúsítványát… de ez mégsem ennyire egyszerű. Amennyiben az Exchange szerverünk Windows Server 2003 alatt fut, akkor – ahogy a cikk is írja – powershell-ből tudunk tanúsítványt generálni. Csakhogy jelen esetben már W2k8 az alap, ezen már van grafikus felület is. Összedobunk egy custom MMC konzolt, felvesszük bele a Certificates (local machine) snapin-t. A Personal folderen jobbkattintunk, majd a lenti képen elmegyünk a ‘Create Custom Request’ menüponthoz.

Nagyítás

Tulajdonképpen mehetnénk a ‘Request New Certificate’ menüpontba is, hiszen itt van, LAN-on belül a CA szerver, mindenki domaintag, ne kelljen már bináris fájl tartalmát kopipasztázgatni. Mehetnénk… de nem működik. A varázsló második ablakán minden szürke – és közli, hogy nekem bizony nincs lehetőségem webserver tanúsítványt igényelnem. Márpedig hidd el nekem, hogy ha nekem nincs meg ez a jogom, akkor senki másnak sem.
Marad a custom request.

Maga az igény összerakása nem túl bonyolult, egy kicsit szokni kell az újfajta grafikus elemeket, de nem vész. Rá kell kattintani minden izére, meg bigyóra, megnézni, mi is van mögöttük. (Shinder bácsi írása elég jól képbe rakhat bárkit.)
Az alábbi ábrán azt a részt emelném ki, amitől SAN lesz a tanúsítvány.

Nagyítás

Igen, az alternatív nevek. Ahogy az előző linken is van – meg máshol is – beírtam a Subject mezőbe CN-ként a külső nevet, az Alternative Name alá meg az összes szóbajöhető lehetőséget, beleértve azt is, hogy bentről esetleg rövid névvel nyomul valaki. Amit a Subject mezőbe írtam, azt nyilván már nem írtam be az Alternative Name alá is. Aztán végigmentem a láncon, igényeltem, kiadtam, importáltam, majd exportáltam végül megint importáltam… szóval ahogy az első linken szépen le van írva – végül jött kintről az OWA teszt.

Nem sikerült. Azt írta ki, hogy a tanúsítvány nem erre a weblapra szól. A Firefox ennél imformatívabb volt, kiírta azt is, hogy mely weblapokra lenne jó ez a tanúsítvány: csak azokra, amelyek az Alternative Name mezőben szerepeltek. A Subject, az nem jött szóba.

Hozzáteszem, nem vagyok tanúsítvány guru. Fogalmam sincs, mennyire kötelező a Subject alatt CN tipusúnak megadni a nevet, nem tudom, lehet-e ott is DNS formátumot használni. Mindenesetre az egyszerűbb utat választottam, az Alternative Name alá is bedobtam a külső nevet – ahogy az ábrán is láthatod. Működött.