Élet a TMG után

Az Exchange rendszerekkel foglalkozók különösen rossz néven vették, amikor a Microsoft kilőtte a TMG-t. Akárhogy is nézzük, az Exchange publikálásához ez egy remek eszköz volt: csont nélkül vitte az összes protokollt, már a DMZ-ben előautentikált, azaz a belső hálóra csak autentikált forgalmat engedett be, ráadásul magát a használt protokollokat is szűrte. A TMG után nem is maradt értelmes opció. Mi rengeteget szívtunk opensource megoldásokkal, de valamin mindegyik elhasalt. Maradt a hardveres loadbalancer, mint egyetlen szóbajöhető megoldás. Igaz ugyan, hogy ez nem autentikál és nem foglalkozik túl sokat a használt protokollok ellenőrzésével, de egyfajta packet filter tűzfal és persze forgalmat oszt.
A Microsoft a TMG kinyírása után hosszú ideig nem mondott semmt. Háát, izé… majd csak lesz valahogy.

A héten indult el egy sorozat az Exchange blogon, ahol immár részletesen körbejárják a lehetőségeket.

Az első írást Greg Taylor követte el és általánosságban járja körül a helyzetet. Hogy kell-e egyáltalán protokollszűrés és előautentikáció? Az nyert, aki arra tippelt, hogy immár nem kell. Természetesen kiosztja a fejlődésben elmaradt szekuritis embereket, sőt, tippeket ad, miket mondjon nekik az Exchange adminisztrátor, ha kötekednének. Ezzel túl sokat nem akarok foglalkozni, számomra a kulcs mondanivaló az, hogy már az MS sem használ preautentikációt a felhőiben – ellenben használ IDS-t. (Gondolom, itt némi slendriánság forog fenn, hiszen IPS-nek valamivel több értelme lenne.)
Illetve, mégis. Greg írja, hogy a CAS már DMZready, azaz nyugodtan mehet rá autentikálatlan forgalom. Oké, de mi van akkor, ha van rajta Mailbox szerepkör is? Mert szép az, hogy négy Exchange szerverrel meg tudjuk oldani a terheléselosztást, de a legtöbbünk azon sportol, hogy maximum két szerver van. Ekkor viszont nagyon hiányzik a TMG.
A lényeg, hogy a szerző bemutatja a versenyzőket: kiket küld a ringbe a Microsoft? Az egyik az ARR (Application Request Routing) – legalább annyira hülye név, mint az ISA vagy TMG, szóval a vonulat megvan – a másik a WAP (Web Application Proxy). Az első egy loadbalancer, a második már egy autentikálni is képes eszköz, igaz, ez csak OWA-t képes publikálni. (És persze kitart még az UAG is, de azt az Exchange esetében jobb hanyagolni.)
Még valami. Most nem kerestem utána, de nekem úgy rémlik, hogy az ARR eredetileg nem támogatta az Exchange-t. Jó látni, hogy most már igen.
Life in a Post TMG World

A második cikkben – mely egy háromrészes sorozat első írása – B. Roop Shankar kezdi el kivesézni, mi is ez, hogyan is működik ez a bizonyos ARR. Nagy vonalakban: ez egy IIS-be épülő modul. A trükkje az, hogy ismeri – és proxyzni is tudja – azokat a Microsoft által megerőszakolt protokollokat, melyeket más webproxyk nem tudnak. Természetesen képes több szerver között terheléselosztásra is.
Egy résznél jót vigyorogtam.

Then click on “Edit Feature Settings” and change the settings for “Maximum allowed content length” to the below.

Azaz a bűvös szám: 2147483648, azaz 2 a 31-ediken. A legtöbb, mi adható.
Vesdd össze ezt az alábbi idézettel, innen:

(Update 17 Apr 2012: Looks like there’s a content-length encoding disagreement between Microsoft and Apache that breaks Outlook anywhere.)

De ez is érdekes írás. Hogy miért is olyan fontos az a content length. Cuki. Hibakódot a ‘bytes’ mezőben küldeni. Ennyit a szabványokról.

Még egy észrevétel. Az ARR Vistától a Windows Server 2012-ig minden IIS-be belerakható, és ez jó. Amit nem tudok, az az, hogy képes-e korábbi Exchange szervereket is publikálni. (A cikk csak a 2013-assal foglalkozik.) Elméletileg működnie kellene, de nálam a nappali fala karón varjúkkal van kidekorálva: én már csak akkor hiszek el valamit, ha explicit leírva látom. (Pedig gugliztam, de így sem egyértelmű a helyzet.)
Reverse Proxy for Exchange Server 2013 using IIS ARR – Part 1

16 Comments

  1. Épp egy jövőbeli ügyféllel vitatkozom a rakjunk DMZbe valamit az Exchange-ből körön. Ennek kapcsán jót mosolyogtam a DMZ ready CAS megjegyzésen. Jó lenne, ha a kedves Exchange team legalább a saját bejegyzéseit elolvasná:
    http://blogs.technet.com/b/exchange/archive/2013/02/18/exchange-firewalls-and-support-oh-my.aspx
    „Starting with Exchange Server 2007 and current as of Exchange Server 2013, having network devices blocking ports/protocols between Exchange servers within a single organization or between Exchange servers and domain controllers in an organization is not supported. A network device may sit in the communication path between the servers, but a rule allowing “ANY/ANY” port and protocol communication must be in place allowing free communication between Exchange servers as well as between Exchange servers and domain controllers.”

  2. A két állítás nem zárja ki egymást. Azt mondják, hogy:
    – A CAS-t ki lehet tenni a DMZ-be, meg tudja védeni magát.
    – A CAS és a többi Exchange/DC közé any-any rule kell.

    Az más dolog, hogy ki vállal be ilyet. 🙂

  3. Pont tegnap olvastam én is az 1. részt, és tippeltem h. itt is szóba fog kerülni. Mivel csak félamatőr szinten vagyok exchange expert, a cikk nagy részét kihagytam. Azonban a bevezetőbe beleolvasva megint felment bennem a pumpa a szokásos corporate bullshittől amit az MS nyom minden generációváltáskor. Mindig ugyanaz a lemez, így 20 év után már nagyon unalmas:
    az xy termék éppen aktuális product managere előadja miért volt szar régen: mert ugyanis akkor még rosszul(?) kódoltUNK, nem figyeltÜNK a szekuritire, különbenis elavult volt az egész, stb. Az én szememben ezek mind szimplán fizetett bohócok, kivéve talán azt a 3-4 nagy szakit az MS berkeiben akiket tényleg feltétel nélkül el lehet ismerni mert már letettek valamit az asztalra. Az aktuális majom még nem is volt az MS alkalmazottja, mikor elkezdék a fejlesztést, mégis olyan beleéléssel T/1-ben fogalmaz, mintha ő is ott kódolt volna az indiaiakkal a pincében hajnalokig. Nademajdmost! Most már tökéletes, ez lesz az igazi, ennél jobb sohasenem lesz. Aztán 2 év múlva kitolnak a színpadra egy teljesen másik nevenincs marhát, aki ugyanezt előadja, ugyanezek az indokok, szinte szóról szóra, csak lecserélték a verziót +1-re. Legalább akkor konzekvensen mindig ugyanaz a madzagon rángatott bábu hazudjon szemrebbenés nélkül a képembe. Agyatlan barom cég az egész Microsoft, fejétől a lábáig rohad. Előadják a mesét, aztán mégsem tanulnak belőle soha, mindig ugyanazokat a hibákat követik el. Mégis miért vegyem meg a vackotokat, ha -utólagosan -bevallottan mindig szart csináltok? Két év múlva úgyis kiderül, h. ez is szar volt. A pénzt visszaadjátok, ha beismeritek 2 évente h. ilyen kerül ki a kezetek közül? Teljesen hülyének nézik a híveiket. Jól fogalmazott az “I contribute to the windows kernel” fickó, csak gondolom az ő seggét elkapták ezért jött a “kiigazító” posztja.

  4. a wap tudja publikalni a tobbit is, de csak az owa tamogatott (egyelore). varjuk meg az ev veget, madridban a wap eloado csako azt mondta h gozerovel dolgoznak a cuccon, minden mas kapcsolod termek (pl. uag) le van sz*rva a fejlesztesben, es rengeteg otletuk van a kovetkezo verziora is 🙂

  5. miert kell az uag-ot hanyagolni az xchg eseten?

  6. Az Exchange szkénában meglehetősen elterjedt nézet, hogy Exchange szervert UAG-gal publikálni az kábé olyan, mint sajtreszelővel recskázni. Meg lehet oldani, de meglehetősen fájdalmas. Ebben nyilván benne van az a keserűség is, hogy kilőtték a TMG-t és maradt helyette az UAG, ami egyrészt nem tud annyit, mint a TMG (Exchange szempontból), ráadásul sokkal bonyolultabb és drágább.

  7. sztem legalabb annyit, vagy inkabb többet tud exchange szempontbol (is), csak tenyleg lenyegesen bonyolultabb és drágább.

  8. Biztosan ismered Greg Taylor tanulmányát: Publishing Exchange Server 2010 with Forefront UAG and Forefront TMG. (Ilyen nevek vettek benne részt, mint Jim Harrison, Ross Smith.) Rögtön az elején van egy összehasonlító táblázat, miket tud a TMG és miket az UAG. Márpedig a táblázat alapján az UAG áll vesztésre.

  9. csakhogy ez egy regi cucc lehet, mert pl. az uag sp1 ota van teljeskoru multifaktoros es cert auth is. es ha a veget megnezed, az ent kategoriaban az uag nyerobb. az uag endpoint policyja mellett pl. a tmg malware inspectionja kispalya, 3000 outlook mellett a tmg-vel le fog allni az outlook anywhere, es stb. 🙂

  10. Szia,

    Arra lennék kíváncsi hogy oldjátok meg 3rd party megoldásokkal preauth nélkül, hogy ne lehessen OWA-n kereszűl lockolni a felhasználót a belső tartományban is egy jó kis brute-forceal?

  11. Ez nem egy lefutott vita, az írásban igyekeztem is érzékeltetni, hogy én sem értek mindennel egyet a hivatkozott írásban. Az előautentikációval kapcsolatban az a véleményem, hogy ha elkezdenek egy rendszert brute force-szal feltörni, akkor egyáltalán nem baj, ha a támadás idejére a megcélzott felhasználók kilockolódnak. A támadás elhárítása pedig már egy másik történet. (Erre hivatkoztam az írásban is, az IPS/IDS rendszerek említésével.)
    De nem vagyok security guru, szóval ez tényleg csak magánvélemény.

  12. Alapból igaz, hogy legyen kitiltva, de sok cégnél használnak “kiszámítható” felhasználói neveket, így az egész cég megbénítható egy publikus felületen keresztül. A rendszer accountokról nem is beszélve. Milyen szép, ha egy cluster accountot kilockolnak 🙂 (ez érdekes szó lett…). Persze IDP/IPS… csak az még sok helyen nincs.

  13. Nem egészen. Ha a kiss.janos@cegnev.hu-t kilövik, az azért nem szabad, hogy leültessen egy céget. A támadást pedig illik észrevenni és blokkolni mondjuk network szinten, hogy azért Kiss János se maradjon örökké kizárva. Az administrator account-ot nem használjuk, a többieknek (pl. service account) pedig tudunk olyan nevet adni, hogy ne találják el egykönnyen. Másfelől az olyan cégek, melyek célpontjai lehetnek egy ilyen támadásnak (mert pusztán jópofizásból biztosan nem támadnak meg senkit), be kell kalkulálják az erősebb védelmet, azaz nem realitásoktól elszakadt dolog IDS/IPS-t feltételezni.

  14. A lényeg a lehetőség, illetve annak a blokkolása. Ez TMG-vel működik. De azért 3rd party téren érdemes elgondolkodni..

  15. Csak érdekességképpen benéztem, történt-e érdemi reakció azokra, amiket 8 hónapja írtam ide és nem lepődtem meg a strucc feje+homok eseten.

Leave a Reply to Richard Cancel reply