Kérdés jött az ügyféltől: hát mi most mit csináljunk? A helyzet röviden: lejárt a korábbi tanúsítványuk, meg szerették volna hosszabbítani, de a szolgáltató már nem volt hajlandó olyan SAN tanúsítványt kiadni, amelyikben belső név (cegnev.local) is szerepel. Ekkor viszont összedől az Exchange publikálásuk.
Első körben az volt a reakcióm, hogy szolgáltatót gyorsan kirúgni és keresni helyette egy másikat, amelyik nem ennyire vaskalapos. De mielőtt válaszoltam volna, a biztonság kedvéért futottam egy kört a guglin, és… eltátottam a számat.
Ha jól értelmezem, akkor a tanúsítványszolgáltatók összedugták a buksijukat és arra jutottak, hogy az internet biztonságosabbá tétele érdekében legkésőbb 2016 októberéig mindegyikőjük visszavonja az összes olyan, általa kiadott tanúsítványt, amelynek akár a Primary Domain, akár a Subject Alternate Name mezőjében belső név, vagy privát IP cím szerepel.
Ezzel gyakorlatilag ki is nyírták az összes olyan Exchange publikálást, ahol a belső tartományt nem split DNS alapon hozták létre, azaz a belső tartomány neve nem egyezik meg a cég külső nevével. Azaz hiába örvendeztünk pár évvel ezelőtt, hogy vége a tengernyi szopásnak, használhatunk SAN tanúsítványt az Exchange publikálásokhoz… ennek vége. Elvették a játékunkat.
Informatikai közhely, hogy a biztonság és a kényelem egymást kizáró fogalmak: ha szigorítom a biztonságot, csökken a kényelem. Mindenki ismeri a sztorit, hogy az egyre hosszabb, egyre bonyolultabb jelszavak elméletileg növelik a biztonságot, de csak egy ideig, mert ha a felhasználó már képtelen lesz megjegyezni, akkor leírja egy papírra és kiragasztja a monitorra. Nesze neked, biztonság.
Úgy néz ki, most is elértünk erre a szintre. Mit fog csinálni az egyszeri rendszergazda? Az, amelyiket komoly felvilágosító munkával éppen nemrég sikerült meggyőzni, hogy felejtse el a saját tanúsítványt és használjon szolgáltató által kiadottat? Szó nélkül visszatér a saját tanúsítványra. Itt olyan SAN tanúsítványt állít ki, amilyet akar, a terjesztését meg megoldja valahogyan. Mert akkorát szigorítottak a biztonságon, melyet már nem tud lekezelni.
Illetve… van egy másik út, a mazochizmus útja. Nem, nem arra gondolok, hogy átnevezzük a tartományainkat, vagy létrehozunk egy új Active Directoryt és átmigrálunk bele mindent. Ez már nem mazochizmus, hanem öngyilkosság. Ellenben visszautazunk a múltba. Oda, amikor az Exchange 2003 publikálásoknál még nem volt SAN tanúsítvány. Persze azóta a világ sokkal bonyolultabb lett, de az elv maradt a régi:
- A default web site alatti virtuális könyvtárakat nem bántjuk, a site-hoz hozzárendeljük a belső tanúsítványt.
- Készítünk egy másik site-ot, ezalatt létrehozzuk az Exchange virtuális könyvtárait:
- OWA (2007): new-owavirtualdirectory
- EAS (2007): new-activesyncvirtualdirectory
- EWS (2007): new-webservicesvirtualdirectory
- OAB (2007): new-oabvirtualdirectory
- ECP (csak 2010): new-ecpvirtualdirectory
Végeztünk? Hát, ha szigorúan az Exchange könyvtáraira gondolunk, akkor igen. De mi is van az Outlook Anywhere mögött? Az RPC over HTTPS, mely gyakorlatilag két könyvtár az IIS default site alatt. Igen, default. Tehát ezeket is duplázni kell az új site alá. Létezik new-rpcvirtualdirectory parancs? Nem igazán. Mi a megoldás?
Hekk.
Meg kell keresni a default web site alatt az ApplicationHost.config fájlt, átmásolni az új site alá, majd átmásolni az rpc, rpcwithcert virtuális könyvtárakra vonatkozó részeket, értelemszerűen módosítva a sitenév bejegyzéseket. (Részletesen itt olvasható a módszer. Senkit ne tévesszen meg, hogy ez az RD Gateway szolgáltatásra vonatkozik, a gyakorlatban ugyanazokat a virtuális könyvtárakat használja, mint az Outlook Anywhere. Egy korábbi, az RD Gateway-t is érintő írásomban az egyik módszer konkrétan úgy is kezdődik, hogy a TMG-n használjuk az Exchange varázslót a publikáló szabályhoz.)
Haladjunk tovább:
- Az új site-hoz kötözzük hozzá a tanúsítványszolgáltató által kiadott tanúsítványt (melyben már nincs benne a cegnev.local név).
- A reverse proxy-n (ISA, TMG, etc) gondoskodjunk róla, hogy az új site szolgáltatásai legyenek kipublikálva. (A nevekre figyeljünk oda, amennyiben szükséges, forgassuk a könyvtárneveket is.)
Nagyjából ennyi. Az Exchange már működik. De olyan nagyon azért ne sóhajtsunk fel:
- Mi lesz a Sharepoint szolgáltatásokkal?
- Mi lesz az RD Web oldalunkkal?
- Végül mi lesz az OCS\Lync szolgáltatásokkal?
Agyhalál. Biztonságos internet. Ja.
2012-07-19 at 19:49
Kísértetiesen ugyanezzel a témával keresett meg engem is tegnap egy ügyfél (csak nem J.A. a B*F-től? :))
A CA-k ezzel gyakorlatilag piacot veszítenek: akinek volt eddig annyi pénze, h. a belső névtartományára is publikus cert-et vett, most már nem fog tudni. Nem kell az ilyen ügyfelek pénze a CA cégeknek? Az hogy olyan névtartományokra állítanak ki tanúsítványt, ami tartomány az RFC szerint is csak privát hálózatban fordulhat elő, hol zavar bárkit is? Hol van ebben a biztonsági kockázat? Nem értem én ezeket..
2012-07-19 at 23:52
Mindamellett, hogy én sem értem, hogy miért vették el ezt a lehetőséget a CA-k (bár nem is vagyok security expert) azért nem olyan nagy probléma ez számunkra. Végül is mire is van szükségünk:
1. Az internal userek számára a SAN-ban szereplő neveken elérhetőnek kell lennie CAS szervernek. Ahogy JoeP is írta, erre ott van a split DNS, hogy az internal userek ne az interneten keresztül érjék el a szervereket.
2. Át kell állítani a Virtual directory InternalURL-jét (feltételezve, hogy az external eddig is jók voltak) exchange 2010-en tehát a következőkre cmdlets-re van szükség: Set-OWAVirtualDirectory, Set-OABVirtualDirectory, Set-WebServicesVirtualDirectory, Set-ActiveSyncVirtualDirectory, Set-ECPVirtualDirectory, Set-ClientAccessServer
2012-07-20 at 00:47
@Robip: Bátor koncepció. Mérget nem mernék venni rá, de elméletileg működhet. (A kulcs az, hogy az Exchange belső folyamataiban mennyire figyelnek az internalurl paraméter értékére, illetve hány helyen próbálkoznak egyszerűen csak a tartományi név alapján elérni a CAS szervert.)
2012-07-20 at 10:22
Alternativ megoldásként beszélni kell a Pingvines emberrel, hogy rakjon fel egy Apache-os reverse proxit és konfigolja fel, hogy belül minden cert-et elfogad…
Kint a hivatalos tanúsítvány látszik (nem kell terjesztened a root ca-t), bent meg a saját cert, ami a .local-ra szól, mindenki elégedett…
Ilyet is csináltunk mostanában egy Jedi képzőben… ;-))
2012-07-20 at 10:35
Hát, Apache reverse proxy, az van máshol is, lásd a kettővel korábbi írást. 🙂
Viszont ott kulturált voltam, úgy csináltam meg, mintha TMG lenne. (Ugyanaz a cert kívül-belül.) A cikk írása előtt megkérdeztem Tamást, hogy meg lehet-e csinálni ugyanazt, amit írtál, TMG-vel, de azt mondta, hogy nem. Az meg azért szempont, hogy bármennyire is ügyes az indián, de azért nincs benne annyira erős védekezés, mint a TMG webfilterében, ráadásul az RPC over HTTPS-t nem bírja.
2012-07-20 at 10:37
Arról nem is beszélve, hogy Apache-on keresztül nem fog menni az RD Gateway kapcsolat, és nagyon nem fognak menni az OCS/Lync HTTPS-be ágyazott mindenféle stream protokolljai.
2012-07-23 at 10:05
Ha az MS nem kepes HTTP protokollt implementalni, akkor sajnos tenyleg MS szoftvereket kell hasznalni reverse proxy szerepre is. Mas kerdes, hogy a TMG meg nem tud tanusitvanyt cserelni.
JoeP, lecci a style.css 343. sorabol szedd mar ki a float: left-et, annyira csunyak a smiley-k igy 🙁
2012-08-04 at 10:52
Ez nem annyira egyszerű. Az MS – szerintem logikusan – egyre több, nehezen kezelhető protokollt (RPC, streaming protokollok) csomagol bele a https-be, hogy lehessen azokat használni, méghozzá biztonságosan, a neten. A proxyk viszont pont ellenkezőleg, nagyon konzervatívak, általában csak az alap http-t tudják. Ez örök konfliktus, amióta ilyesmikkel foglalkozok, azóta jelen van. (Ezt szokták felróni hátránynak a proxy alapú tűzfalakkal szemben is.)
Az megint más dolog, hogy az MS ezeket a becsomagolt protokollokat beépíti a saját proxyjába.
ps. style.css módosítva. 🙂
2012-08-04 at 16:55
Nem a csomagolas a baj, hanem hogy nem ugy csomagolja be, hogy az alap http-nek nezzen ki. Mert a proxy-k altalaban a payload-dal nem szoktak torodni, csak a headerrel. Itt viszont valami komolyabb gond van a headerekkel is, valszinu azert nem megy at rajta.
PS: Akkor meg a paddingnal kellene egy olyan, hogy az elso es harmadik szamot kinullazod. Ugyanott. Erdekes modon, Linux alatt enelkul is jo volt, Windows alatt viszont elmasznak a smiley-k meg mindig. 🙁
2012-08-04 at 22:22
Akkor meg a paddingnal kellene egy olyan, hogy az elso es harmadik szamot kinullazod. Ugyanott.
Huh, nagyon igényesek vagyunk. 🙂
De nem baj. Ezt is átírtam. Kösz a tippet!
ps. Nekem Windows alatt megjavult, igaz, chrome-ból megyek.
2012-08-08 at 20:43
En meg akkora ur vagyok, hogy Windows 8 / IE 10 alol neztem az oldalt. 🙂
2012-08-08 at 20:55
Nem is működik jól. 😀