Polski TechNet Blog

Windows 8.1 na horyzoncie

2013-06-04T06:28:10Z

Jako, że świat IT idzie do przodu, to i w Windows od czasu do czasu pojawiają się pewne nowości. Choć ostatnia wersja nie jest jeszcze bardzo wiekowa, to podczas odbywającej się właśnie w Nowym Orleanie konferencji TechEd, powiedziano parę oficjalnych słów na temat jej aktualizacji. Ciężko jednoznacznie wskazać czy to nowa wersja systemu (poniekąd tak jest) czy pakiet poprawek (bo i tak jest przecież) czy jeszcze coś innego. Ważne jest to, że dostaniemy parę nowych funkcjonalności, poprawi się trochę już istniejących a przynajmniej część płynących od użytkowników postulatów dotyczących zmian zostanie zaimplementowana. Nie da się chyba wszystkich zmian prosto opisać – trzeba sobie nowy system zainstalować i pobawić się nim przez parę chwil, żeby go móc naprawdę ocenić. Nie powinno to być trudne z trzech powodów:

Nowy system będzie w pełni zgodny z Windows 8. Ten sam sprzęt, te same aplikacje. Aktualizacja powinna być bezproblemowa.
Nowy system będzie bezpłatną aktualizacją Windows 8. Aspekt finansowy również nie będzie przeszkodą.
Oficjalna wersja testowa pojawi się pod koniec czerwca. Czas jest na tyle nieodległy, że da się poczekać i skorzystać z oficjalnej ścieżki zdobycia aktualizacji jeszcze przed wakacjami.

Próbując opisać nowości, tym razem skoncentruję się wyłącznie na funkcjonalnościach skierowanych do większych organizacji. Czyli niekoniecznie zmiana tła czy rozmiaru kafelków, ale to, co rozwiązuje pewne bolączki przedsiębiorstw.
Pierwsze, co rzuca się w oczy, to poważne podejście do problemów wynikających z faktu, że jakiś czas temu komputery stały się mniejsze niż szafa i wiele osób używa ich prywatnie a niektórzy nawet przynoszą je ze sobą do pracy. Czasem w teczce, czasem w kieszeni... nieistotne. Taki użytkownik ma często ochotę podłączyć się ze swoim urządzeniem do firmowej sieci. Z wielu różnych powodów. Bo firmowe WiFi jest tańsze niż GPRS, bo ma większy ekran niż służbowy laptop i może efektywniej pracować, bo w pracy dostał złom z WindowsXP i nie może na niego patrzeć... Powodów może być wiele, ale z punktu administratora sieci i tak każde takie podłączenie powinno jeżyć włosy na głowie. Przecież dział IT nie ma żadnej kontroli nad elementami "swojego" systemu. Bo tak tylko można traktować podłączone przez użytkowników urządzenia.

Do tej pory, możliwe podejścia były dwa: pozwólmy użytkownikom na wszystko albo nie pozwólmy im na nic. Jak to z każdą skrajnością bywa – umiarkowanie uszczęśliwiały tak użytkownika jak i administratorów czy właścicieli systemów IT. Windows 8.1 próbuje to jakoś ogarnąć udostępniając funkcjonalność Workplace Join, czyli coś na kształt niepełnego podłączenia prywatnego urządzenia do domeny. Urządzenie nie jest aż tak kontrolowane jak urządzenia w domenie a z drugiej strony – staje się znane i rozpoznawalne dla działu IT, dzięki czemu możliwe staje się zarządzanie dostępem z niego do zasobów firmowych. Śladowe zarządzanie urządzeniem jednak istnieje i pozwala narzucić kilka reguł na jego konfigurację. W efekcie, można w praktyce zrealizować na przykład politykę, która wprawdzie pozwala na dostęp prywatnych urządzeń do poczty firmowej, ale tylko pod warunkiem, że mają założone hasło ograniczające dostęp (do urządzenia, ale w efekcie i do poczty) osobom postronnym.

Kolejnym usprawnieniem jest świadome podejście do współdzielenia plików służbowych z prywatnymi urządzeniami. Ilość "wynalazków", którą w takich zastosowaniach widziałem jest przerażająca. Od przesyłania samemu sobie firmowych danych przez prywatną pocztę, poprzez pseudotunele aż po instalację klienta skydrive’a, mesha czy innych zbliżonych rozwiązań. Od Windows 8.1 jest prościej. Dostajemy Work Folders i możemy sobie synchronizować służbowe dane do niekoniecznie służbowego urządzenia. Oczywiście w sposób zedfiniowany przez administratora, bo całe rozwiązanie jest w pełni zarządzalne.

Zauważalne zmiany zachodzą również w obszarze VPN. Choć idea VPN nieco już jest staroświecka, to nadal wielu administratorów woli obudowywać VPN ułatwieniami zamiast przełączyć się na nowoczesne rozwiązanie takie jak na przykład DirectAccess. W Windows 8.1 ciekawostką może być zestawianie połączenia VPN wykonywane automatycznie przy otwarciu jakiejś aplikacji albo przy próbie sięgnięcia do zasobów firmowego intranetu. Czyli możemy teoretycznie na domowym komputerze bawić się w Internecie, a z VPN połączyć się automatycznie, gdy tylko zechcemy chwilę popracować. Da się, a od prywatnej oceny faktu, że pojawiają się kolejne dodatki do VPN zamiast zmian w kierunku usunięcia go z żywych systemów – spróbuję się powstrzymać.

A co jeżeli prywatne urządzenie ze służbowymi danymi zostanie skradzione albo zgubione? Do tej pory, dział IT (o ile w ogóle wiedział, że tam były służbowe dane!) musiał grzecznie prosić użytkownika o zdalne wymazanie urządzenia. A użytkownik mógł się opierać, bo nie był pewny czy tablet zgubił, czy tylko zostawił u kolegi. Teraz problemu nie ma – administrator może zdalnie wymazać dane firmowe nie dotykając danych prywatnych. W końcu urządzenie należy do pracownika, a dane – do organizacji.

Warto też wspomnieć o bardziej konsekwentnym podejściu do uwierzytelniania biometrycznego. Widać dość wyraźnie, w którą stronę wszystko zmierza. W Windows 7 pojawił się Biometric Framework, w Windows 8.1 biometria może być używana do potwierdzania tożsamości użytkownika nie tylko podczas logowania do systemu, ale wszędzie tam, gdzie bywa to potrzebne: do uwierzytelniania w aplikacjach, do certyfikatów, do zestawiania VPN czy choćby do podniesienia przywilejów mechanizmem UAC. Dzięki temu jest i wygodnie i bezpiecznie.

Powyższe funkcjonalności to tylko mały kawałek tego, czego możemy spodziewać się za trzy tygodnie. Jeżeli dodamy jeszcze do tego nowy serwer – 2012 R2 czy nowy System Center, to robi się naprawdę ciekawie. Dlatego najlepiej już teraz zaopatrzyć się w potrzebną wiedzę (portal SpringBoard na TechNet będzie chyba najlepszym źródłem) i instalować. Może niekoniecznie wersję beta w produkcyjnym systemie, ale na prywatnym laptopie – czemu nie?

Autor: Grzegorz Tworek [MVP]

Reverse proxy w IIS

2013-05-14T16:38:58Z

Idea reverse proxy nie jest specjalnie skomplikowana. Mamy serwer, do którego trafiają zapytania ze świata, ten serwer odpytuje jakiś inny serwer http (serwer aplikacyjny) a otrzymaną odpowiedź przekazuje klientowi tak, jakby wygenerował ją sam. Po co tak kombinować? Powodów może być wiele, wśród których wymienić warto chociażby:

Serwery aplikacyjne nie muszą być "wystawione" do świata a reverse proxy zadba o odfiltrowanie niepożądanych zapytań. Sam IIS ma sporo ciekawych filtrów (włącznie z ModSecurity) a dalej przekazane zostaną tylko "grzeczne" zapytania.
Stosunkowo prosty reverse proxy może znajdować się u providera wyposażonego w łącza o potężnej przepustowości, dzięki czemu to na nim skupią się ataki DDoS. Wystarczy to połączyć z Dynamic IP Filtering (wbudowanym w ISS8, dodatkowym w starszych wersjach) i już mamy całkiem ładne zabezpieczenie a serwery aplikacyjne zostają u nas w firmie.
Informacja z wielu serwerów aplikacyjnych może być przedstawiana klientowi tak, jakby znajdowała się na jednym – adres dla klienta pozostaje ten sam i jest adresem reverse proxy.
Wystarczy jeden zewnętrzny adres IP i adres URL do pokazania światu zawartości dowolnej ilości serwerów aplikacyjnych. Również takich, które działają na jednym serwerze, ale na różnych portach TCP.
Za reverse proxy można "schować" szczegóły budowy rozwiązania. Adresy wystawione do świata mogą być ładne i przyjazne, podczas gdy serwer aplikacyjny w adresie URL wymaga podania danych, których nie chcemy pokazywać publicznie.
Reverse proxy pokazuje klientom swoją wersję, oprogramowanie, nagłówki i inne potencjalnie wrażliwe szczegóły.
Reverse proxy może (nie musi) buforować informacje otrzymane od serwerów aplikacyjnych, dzięki czemu zmniejsza ich obciążenie.
Na reverse proxy można przerzucić całą robotę związaną z obsługą SSL.

Podobnych powodów możnaby wymieniać wiele.

Jeżeli ktokolwiek chce to zrobić w swoim środowisku, może przebierać w rozwiązaniach. Od mniej lub bardziej zaawansowanych rozwiązań Open Source aż po specjalizowane urządzenia. Tymczasem, zupełnie dobrze reverse proxy można zbudować w oparciu o IIS. Potrzebne będą:

Serwer IIS. Najlepiej wersja 7 (Windows Server 2008) lub nowsza.
Opcjonalny moduł Advanced Request Routing (do pobrania ze stron Microsoft)
Opcjonalny moduł URL Rewrite (również do pobrania z Microsoft)

Warto wiedzieć, że wymienione powyżej moduły można instalować przez mechanizm Web Platform Installer (WebPI) – dzięki temu instalacja jest znacząco prostsza i przebiega bezproblemowo.

Po instalacji, na poziomie serwera należy włączyć funkcjonalność reverse proxy, opcjonalnie ustawiając parametry buforowania.

Na poziomie site’ów i folderów wirtualnych, w ramach modułu URL Rewrite trzeba skonfigurować inbound rules, służące do tłumaczenia zapytań przychodzących ze świata na zapytania do serwerów aplikacyjnych.

Oczywiście, reguły tłumaczenia zapytań są dość elastyczne (match, wildcard i regexp) i pozwalają na realizację całkiem zaawansowanych scenariuszy.

I gotowe! Warto pamiętać o jeszcze jednym module do IIS: Advanced Logging. Może się przydać, ponieważ serwer aplikacyjny dostaje zapytania od reverse proxy, przez co informacja w jego logach nie zawiera danych na temat faktycznie pytającego klienta. Pytającym jest przecież zawsze reverse proxy. Reverse proxy dodaje jednak kilka swoich specjalnych nagłówków, wśród których warto wymienić:

X-Forwarded-For – zawierający informację o tym, kto przysłał zapytanie do reverse proxy zanim ten przekazał je dalej
X-Original-URL – służący do przekazania zapytania w formie, którą miało zanim zostało przetłumaczone na postać służącą do przesłania do serwera aplikacyjnego.

Pozostaje odpowiedzieć sobie na dwa pytania: czy reverse proxy mi się przyda i czy znajdę cokolwiek lepszego i prostszego niż IIS. A potem po prostu działa.

Autor: Grzegorz Tworek [MVP]

Konfiguracja środowiska PowerShell - cz. I. Inicjalizacja.

2013-04-24T10:03:00Z

Powoli Startujemy

PS powoli staje się podstawą całego zarządzania serwerami Microsoft. Wszystkie większe produkty dostarczają już commandlety, a większość w ogóle jest pisana na bazie PS – okienka zarządzania to zwykłe formatki uruchamiające skrypty. To oznacza, iż bez znajomości PS będzie ciężko – dużo ciężej niż kiedyś, bez znajomości CMD. Zgodnie z powiedzeniem “jak sobie
pościelisz - tak się wyśpisz” [bardziej wolę tę drugą wersję - “to mnie zawołaj”, ale tutaj nie pasuje (; ] – jak sobie skonfigurujesz środowisko PS, tak Ci się będzie pracowało. ‘Z pudełka’ niestety[?] nie powala na kolana – standardowe kolory i kłopoty z fontami utrudniają pracę, skryptów nie da się uruchamiać, nie da się również nigdzie połączyć zdalnie. Jak już się doda możliwość zdalnego połączenia, to jest się zsandboxowanym do lokalnego środowiska.

Pomijając filozoficzne rozterki dotyczące decyzji takich a nie innych ustawień standardowych [większość tłumaczona jest bezpieczeństwem], pozostaje je zmienić po swojemu. Uczynić środowisko przyjaznym. Oto podstawowe kroki, które postaram się opisać w tej części:

włączenie skryptów
uruchomienie zdalnych połączeń

Tylko dwa punkty – te najważniejsze, bez których środowisko jest praktycznie nie-do-użytku dla administratora.

Żeby nie przepisywać Internetu, wszystkie informacje są w bardzo podstawowej formie – zakładam, że chodzi o automatyzację i globalną konfigurację, a nie pojedynczy serwer. Dla tych, którzy potrzebują więcej szczegółów, na końcu znajdują się linki do dalszej lektury.

Powłączaj Skrypty

Aby obronić system przed administratorem, zakłada się, że jest on ... niemądry. Biorąc pod uwagę statystyki, to wcale nie jest złe założenie (; Aby zatem
przekonać system, że wiesz, co robisz, musisz zmienić politykę uruchamiania skryptów, która standardowo nie pozwala na ich uruchamianie. Opcję można
włączyć dla wszystkich serwerów via GPO:

Computer Configuration (lub User Configuration) | Administrative Templates | Windows Components | Windows PowerShell | Turn On Script Execution

Trochę smutne, że to jest jedyna opcja dla PS, jaką można skonfigurować bezpośrednio w GPO ): Mam nadzieję, że za jakiś czas w tej części pojawią się dodatki, ułatwiające życie administratorom. Do wyboru są 3 poziomy bezpieczeństwa:

Allow only signed: to niewątpliwie najbezpieczniejsze ustawienie i jak to z bezpiecznymi rozwiązaniami bywa, tak i tutaj, nie jest przyjazne w codziennej pracy. Aby korzystać ze skryptów, należy wygenerować certyfikat z użyciem ‘code signing’ i każdy skrypt podpisać. Aby przy każdej drobnej zmianie nie musieć w kółko podpisywać skryptu – co zwłaszcza w procesie tworzenia jest co najmniej uciążliwe – prawidłowo, powinno się skonfigurować ‘serwer roboczy’. Na takim serwerze skrypty można tworzyć i testować, na koniec
podpisać i umieścić w repozytorium. Na pozostałych serwerach korzystać z owego repozytorium. Piękne, ale bardzo wymagające.
Allow local scripts and remote signed scripts: skrypty napisane lokalnie uruchamiają się, natomiast te ściągnięte z Internetu tylko, jeśli są podpisane zaufanym certyfikatem. To IMHO najbardziej ‘ludzkie’ podejście [jeśli ufa się samemu sobie (; ] i wygodne. Trzeba oczywiście wziąć pod uwagę również zaufanie do współpracowników. Jeśli skrypty mają wymóg podpisywania, możemy zdefiniować, kto je tworzy, wydając lub nie odpowiedni certyfikat. Natomiast przy tej opcji nie mamy już kontroli nad źródłem skryptu.
Allow all scripts: niezalecane nawet przy poluzowanej polityce bezpieczeństwa. Każdy zassany skrypt, zawsze warto najpierw przejrzeć.

#Pomocne Skróty

aby dowiedzieć się więcej o podpisywaniu: get-help About_Signing
konfiguracja podpisywania certyfikatem: scripting guy

Połączenia Sdalne

Możliwość korzystania z PS tak, jak z SSH, wymaga trochę więcej wysiłku. Do zdalnej sesji wykorzystywany jest winRM. Aby móc zestawić zdalną sesję PS trzeba włączyć tzw. listener dla usługi - czyli usługa musi w ogóle oczekiwać na połączenia. Operacja jest tak samo prosta jak w przypadku polityki podpisywania, z tą jednak różnicą, że w tym przypadku warto [wręcz trzeba!] zainwestować chwilę w konfigurację certyfikatów tak, aby sesje były szyfrowane. Windows Remote Shell (winRS) wykorzystuje połączenie HTTP:5985 lub HTTPS:5986. W celu zestawienia kanału szyfrowanego niezbędny jest certyfikat SSL oraz konfiguracja przy pomocy skryptów - to opiszę w przyszłości. Należy:

włączyć listenera:
- Computer Configuration | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service | Allow automatic configuration of listeners
- Computer Configuration | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service | Turn On Compatibility HTTP Listener - DISABLED
zrobić wyjątek dla Firewall w

Computer Configuration | Windows Settings | Security Setting | Windows Firewall with Advanced Security
jest predefiniowana reguła dla winRM podczas konfiguracji polisy Firewall, więc nie trzeba ręcznie wpisywać portów.

Kolejnym krokiem jest konfiguracja wymiany uwierzytelnień credSSP. CredSSP to provider uwierzytelniający, wprowadzony wraz z Vista, który zastąpił starą GINA. Standardowo delegacja uprawnień jest wyłączona i po zdalnym zalogowaniu nie da się np, skopiować czegoś na zdalny serwer. Jest się uwięzionym lokalnie na zdalnym serwerze. To mocno utrudnia pracę, warto zatem ułatwić sobie życie i włączyć delegację. Opcję trzeba włączyć dla obu końców - klient musi ich używać, a serwer musi je akceptować:

Computer Configuration | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Client | Allow CredSSP authentication
Computer Configuration | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service | Allow CredSSP authentication

Post Scriptum

Tyle na początek. W kolejnej części chciałbym przekazać kilka wskazówek jak skonfigurować samo środowisko – czyli kolory, aliasy itd. Oczywiście centralnie – tak, żeby czas
poświęcić raz i pracować wygodnie w całym środowisku.

#Pomocne Skróty

konfiguracja winRM z certyfikatami – liczne linki prowadzące dalej do konfiguracji autoenrollmentu itd.
konfiguracja winRS bez GPO – włączenie z linii poleceń
więcej o credSSP

eN.

autor: nExoR

MC*

2013-04-24T08:13:00Z

Dawno, dawno temu, (gdy nowością był tak zwany OSR2 do systemu Windows 95) stwierdziłem, że może warto bawić się poważnymi zabawkami i "wsiąkłem" w świat Windows NT. Jakiś czas później, po przygodach z grupą pl.comp.os.winnt i z portalem nt.faq.net.pl uznałem, że poza świadczeniem innym wsparcia 24h/dobę, dobrze byłoby znaleźć jakąś obiektywną metodę pokazania innym, że naprawdę znam się na rzeczy. Potrzebowałem jednoznacznego i niepodważalnego dowodu, że tematy dotyczące systemów Microsoft są mi bliskie i w efekcie zacząłem się przyglądać certyfikatowi Microsoft Certified Professional. Po naprawdę długich przygotowaniach zebrałem się na odwagę i w końcu zdałem swój pierwszy egzamin. Czemu o tym piszę? Bo uświadomiłem sobie niedawno, że mija właśnie 15 lat od tego (naprawdę znaczącego w mojej karierze zawodowej) wydarzenia. 24.04.1998 zdałem (nie pamiętam już z jakim wynikiem) egzamin 70-073 - Implementing and Supporting NT 4.0 Workstation. I od tej pory to prawie jak uzależnienie, bo tylko przez ostatni rok egzaminów zdałem kilkanaście... Do dzisiaj nazbierałem literki: MCP, MCSE, MCDBA, MCT, MCTS, MCITP, MCSA i MTA. Kolejne pewnie w drodze. Poza samym chwaleniem się (w końcu 15 lat ciągłego bycia na bieżąco z technologią to nienajgorszy wynik), mogę powiedzieć tylko jedno: nie żałuję ani wyboru ścieżki rozwoju ani przyjętego sposobu dowodzenia znajomości zagadnienia.

Jeżeli ktokolwiek z Was chciałby mieć jasne potwierdzenie swojej biegłości w tematach związanych z Microsoftową wizją IT – egzaminy są świetną metodą pokazania tej biegłości reszcie świata. Wprawdzie zdarzają się czasem sytuacje, w których słyszę "Admin z praktyką wie więcej niż obwieszony certyfikatami konsultant, więc z definicji MCcośtam nie ufam.", ale mogę zawsze przemilczeć fakt, że ja jestem jednym z tych obwieszonych. Jeżeli rozmówca faktycznie w taki sposób ocenia mój poziom kompetencji, to pozostaje tylko uznać, że to on ma problem a nie ja. Od posiadania certyfikatów ani wiedza ani doświadczenie nie zmniejsza się na pewno.

Na koniec ciekawostka: zamiast trzymać potwierdzenia w postaci papierowej, od pewnego czasu certyfikowani specjaliści korzystają z dobrodziejstw strony dla MCP, z której pobrać można odpowiednie certyfikaty. Mój pierwszy certyfikat też oczywiście tam jest, ale po jego pobraniu okazuje się, że jest podpisany przez Steve’a Ballmera. A tymczasem papierowy oryginał miał podpis Billa Gatesa i wyglądał nieco inaczej.

A jeżeli ktoś jeszcze się waha, czy warto egzaminy zdawać – przypomnę, że trwają ostatnie dni promocji Second Shot. I nawet, jeżeli w pierwszym podejściu zdać się nie uda, pozostaje drugie, bezpłatne.

Autor: Grzegorz Tworek [MVP, MCP, MCSE, MCDBA, MCT, MCTS, MCITP, MCSA, MTA]

EMET v4

2013-04-19T10:29:17Z

Powszechnie uważa się, że nie istnieje oprogramowanie, w którym nie ma błędów. Choć to mocno uproszczony sposób patrzenia na świat, to zwraca uwagę na ważną rzecz: fakt, że nie wiemy o jakimś błędzie, wcale nie oznacza, że go nie ma. Jeżeli błąd dotyczy krzywego drukowania tabelek na sto siedemnastej stronie dokumentu – nie musimy zwykle nadmiernie się nim przejmować. Jeżeli jednak wiąże się on z zagrożeniem bezpieczeństwa, to prędzej czy później, fakt jego wykrycia sprawi, że ktoś pokusi się o utworzenie exploita – potencjalnie skutecznej metody ataku mającego na celu uzyskanie w systemie jakichś nienależnych uprawnień. Kończy się to różnie: od dokumentu PDF, który "wywraca" aplikację mającą go wyświetlić, po przejęcie pełnej kontroli nad systemem w wyniku wejścia na jakąś zupełnie niepozornie (albo wręcz przeciwnie) wyglądającą stronę internetową.

I tu pojawia się oczywiste pytanie: jak się bronić przed takimi atakami?

Generalnie przyjmuje się, że aktualizacja oprogramowania (wszelkiego, nie tylko systemu) jest tym, co powinno zmniejszyć ryzyko do poziomu akceptowalnego przez typowego użytkownika. Zazwyczaj, skoro pojawia się błąd, pojawia się i poprawka i nawet skuteczna dotąd metoda ataku przestaje działać. Problem tylko w tym, że zdarza się, że skuteczna metoda ataku istnieje w przyrodzie zanim pojawi się poprawka. Nie jest to częste, bo najpierw trzeba znaleźć niezałataną usterkę a potem opracować proof of concept i stworzyć exploit. Ze względu na potencjalne korzyści dla sił Ciemnej Strony Mocy, exploit taki (określany zwykle jako 0day) ma ogromną wartość, dochodzącą na czarnym rynku do setek tysięcy dolarów. Skoro istnieje wymierna finansowa korzyść ze skutecznego ataku, to istnieje popyt na exploity. Takie czasy... Warto jednak zdawać sobie sprawę z realnego ryzyka. Jeżeli ktoś posiada narzędzie warte majątek – prawdopodobnie będzie używał go z rozwagą. Zaatakowanie miliona przypadkowych komputerów w Internecie jest kuszące, ale zwiększa prawdopodobieństwo, że ktoś taki atak wykryje i przeanalizuje. Nie dość, że sam będzie mógł się zabezpieczyć, to jeszcze pewnie prędzej czy później poinformuje MSRC albo inną ekipę działającą po stronie tych dobrych. W efekcie, wkrótce powstanie poprawka, która posiadaczowi exploita 0day odbierze całą przewagę nad resztą świata. Można więc przyjąć, że konkretny komputer zostanie zaatakowany raczej w sytuacji, gdy dla atakującego, korzyści z ataku będą wyższe niż poniesione koszty.

A co, jeżeli moje dane są naprawdę cenne? Co jeżeli, to właśnie ja mam pecha i na mnie zostanie skierowany atak? Wtedy pojawia się poważniejszy problem, ale nie pozostajemy bezbronni. Mamy szanse na obronę dlatego, że mimo pozornej różnorodności większość współczesnych ataków (również tych 0day) w środku używa praktycznie tych samych technik. Wiedząc to, możemy próbować zastosować jedną z metod przeciwdziałania takich, jak:

SEHOP – Structured Exception Handler Overwrite Protection http://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx
DEP – Data Execution Prevention http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx
ASLR – Mandatory Address Space Layout Randomization http://en.wikipedia.org/wiki/Address_space_layout_randomization
Bottom-up randomization – losowe (0-255) przesunięcie początku obszaru pamięci, w którym alokowane są struktury takie jak sterty, stosy itp. Idea jest zbliżona do ASLR i podobnie skuteczna.
Cała seria zabezpieczeń przed atakami bazującymi na Return Oriented Programming http://kryptoslogic.com/download/ROP_Whitepaper.pdf

Warto też wspomnieć o technikach aktywnie przeciwdziałających współczesnym mechanizmom stosowanym w malware. Nie zabezpieczają one systemu bezpośrednio, jednak sprawiają, że udany atak jest dodatkowo utrudniony:

EAF – Export Address Table Access Filtering
Heapspray Allocations

Tyle teorii. Tylko jak zastosować ją w praktyce typowego profesjonalisty IT, który niekoniecznie chce wiedzieć co się dzieje na stosie czy w chronionych obszarach pamięci? I tu z pomocą przychodzi tytułowy EMET czyli Enhanced Mitigation Experience Toolkit. Rozwijany od wielu lat pakiet oprogramowania Microsoftu, który nadal istnieje w wersji Beta, jednak wyraźnie dojrzewa do postaci dającej się na poważnie zastosować w skali dużej sieci, nawet zawierającej muzealne Windowsy XP. Wersja oznaczona numerem 4 właśnie pojawiła się na portalach Microsoft i zdecydowanie warto przyjrzeć jej się bliżej.

Autor: Grzegorz Tworek [MVP]

To już tylko rok...

2013-04-07T20:14:52Z

Dawno, dawno temu, gdy Windows Vista był nowością, zostałem zaproszony do udziału w kilku projektach, które miały na celu migrację do tego nowego (choć uparcie niedocenianego) systemu. O ile zmigrowanie własnego komputera przez osobę mającą jakieś pojęcie o temacie nie było nigdy specjalnym wyzwaniem, o tyle takie działanie w skali większej organizacji staje się już całkiem poważnym projektem. Powodów, dla których projekt "migracja" może pójść mniej gładko niż oczekujemy jest sporo:

Nasze aplikacje nie są w pełni zgodne z nowym systemem, albo po prostu nie wiemy czy są zgodne czy nie,
Nasze urządzenia nie są w pełni zgodne z nowym systemem, albo po prostu nie wiemy czy są zgodne czy nie,
Aplikacje webowe (głównie intranetowe) nie działają poprawnie z nowszą wersją przeglądarki,
Dział IT wie, że migrację można zautomatyzować, ale nie do końca wie jak, więc w efekcie ani nie migruje ręcznie ani nie przygotowuje się do migracji automatycznej,
Użytkownicy nie znają nowego systemu i sprawia im on problemy. Faktyczne albo tylko psychologiczne,
Wsparcie techniczne w organizacji nie jest gotowe na obsługę nowego systemu u użytkowników,
Nie mamy jeszcze tylu licencji ile potrzebujemy,
Przeniesienie ustawień, dokumentów i aplikacji użytkownika jest bardziej czasochłonne niż się spodziewaliśmy,
Menedżerowie znają Windows XP i uważają, że skoro działa poprawnie, to nie będą wydawać pieniędzy na nowinki techniczne.

Prawdopodobnie każdy, kto do poważniejszego projektu migracji podchodził (nie tylko w obszarze systemów operacyjnych), o takie lub zbliżone przeszkody się potknął.

Czy to oznacza, że migracja jest trudna...? Według mnie nie. Jest jednak czasochłonna. Prawidłowo przygotowana sprawia ogromną radość administratorom, bo wszystkie żmudne działania wykonują się same. Wystarczy tylko dobrze podejść do tematu i zaplanować cały proces. O pewne rzeczy trzeba z wielomiesięcznym wyprzedzeniem "powalczyć" z kadrą kierowniczą, trzeba zadbać o potrzebne zasoby, o środowisko testowe, o czas...

Czas potrzebny na migrację może być bardzo różny, w zależności od podejścia:

Jeżeli wpuścimy do firmy grupę doświadczonych konsultantów, to w trzy-cztery miesiące powinno im się udać. Wystarczy mieć na to budżet, którego pozyskanie może zająć niemało czasu.
Jeżeli uznamy, że jakoś to będzie i po prostu któregoś dnia zaczniemy biegać z pendrive od komputera do komputera, to miesięczny wynik na poziomie 20-30 komputerów na administratora jest osiągalny w sytuacji, gdy ten administrator nie ma wiele ciekawszych zajęć a użytkownicy mają ochotę współpracować.
Możemy też zrobić migrację systemu równolegle z migracją sprzętu. Nowy system z nowym komputerem. Wtedy migracja taka zajmie tyle czasu jakie w firmie jest czas życia komputera. Trzeba podejść jednak do sprawy konsekwentnie i nie pozwolić nikomu na odstępstwa. Inaczej, bardzo szybko okazuje się, że plan migracji to jedno a realizacja – zupełnie coś innego. Warto zdawać sobie sprawę, że w większych firmach, nawet taka migracja będzie wymagać sporo przygotowań zanim się na serio rozpocznie.
Można wreszcie zbudować porządny projekt migracji i później "hurtem", dział po dziale czy lokalizację po lokalizacji przestawić komputery na nowszy system operacyjny. W mojej ocenie, takie podejście sprawi najwięcej satysfakcji administratorom. Może niekoniecznie właśnie satysfakcja jest celem biznesowym w organizacji, ale nie warto jej tak całkiem ignorować. Informacje o tym jak podejść do takiego projektu są prosto dostępne choćby na portalu SpringBoard, ale znowu – potrzebny jest czas. W normalnym środowisku sporej wielkości całość musi zająć rzetelne kilka miesięcy i zaangażować administratorów w stosunkowo poważnym wymiarze.

Dlaczego o tym piszę? Dlatego, że gdy mamy do czynienia z firmą średniej lub dużej wielkości, to jak byśmy nie kombinowali, dojdziemy do wniosku, że nadszedł ostatni moment na zajęcie się migracją systemu naprawdę serio. 8.04.2014 to już za rok a ta data oznacza koniec wsparcia dla Windows XP. Przestaniemy otrzymywać poprawki, skończy się wsparcie techniczne i po kilkunastu latach dzielnej służby, system (nie tylko z powodów technologicznych) stanie się antykiem.

Autor: Grzegorz Tworek [MVP]

tajemnice certyfikatów cz.3 - wracamy do podstaw

2013-03-01T14:17:00Z

Obsługa certyfikatów

Bry!

Kolejny kawałek dotyczący certyfikatów i zgodnie z tematem - opiszę bardzo podstawową czynność: samą operację żądania certyfikatu. Ponieważ jednak jestem z natury przewrotny, skomplikuję trochę scenariusz:

Zwykły użytkownik [tudzież niezwykły admin] potrzebuje specjalnego certyfikatu - np. certyfikat SAN, certyfikat dla serwera WWW z nazwą inną, niż domenowa, certyfikaty KRA itd... w pierwszej kolejności na serwerze musi być przygotowany i opublikowany szablon, ale to, co odróżnia takie certyfikaty to wymaganie zatwierdzenia przez managera certyfikatów

...oczywiście można utworzyć szablon i wyłączyć tą opcję, ale to mało rozsądne, a nie chcąc zapędzać się w dyskurs filozoficzny - po prostu przyjmijmy, że ta opcja jest włączona.

Jak teraz wygląda proces enrollmentu?

użytkownik żąda certyfikatu
cert pojawia się jako oczekujący na serwerze
manager musi go zatwierdzić
użytkownik musi zaciągnąć zatwierdzoną część publiczną i sparować z prywatną.

Trywialne? pozostaje odpowiedzieć - jak każdy z tych kroków zrobić. Oto jakie pojawiają się problemy i możliwości:

ad.1. Są co najmniej trzy sposoby aby wygenerować żądanie:

Za pomocą interfejsu WWW. Problemy jakie się pojawiają to:

trzeba znać adres - wcale nie takie oczywiste!
wynikają niekompatybilności - problematyczne zwłaszcza, jeśli ktoś jeszcze nie zmigrował CA co najmniej do Windows 2oo8
nie wszystkie szablony da się opublikować na WWW

Za pomocą narzędzi generujących request PKCS#10. Z tą metodą są same problemy - od samego wygenerowania poprawnego żądania, przez jego dostarczenie aż po wybór narzędzi. To metoda dobra jeśli rozmawiamy z zewnętrznym CA na jakimś paskudnym, opensource'owym systemie (; ogólnie raczej dla sys adminów/developerów niż użytkowników.
Za pomocą MMC 'certificates'. Łatwe, proste, przyjemne, na każdym komputerze, automatycznie zaciąga dostępne szablony - same zalety! czy aby napewno? do tego problemu za chwilę wrócę.

ad.2. Skąd manager certyfikatów ma wiedzieć, że pojawił się nowy certyfikat? Tutaj założę, że po prostu pełniący funkcję jest rzetelny i sprawdza czy są nowe żądania. W żyjącym środowisku przydałby się jednak jakiś automat powiadamiający... trzeba oprogramować CA. nie ma niestety standardowych mechanizmów.

ad.3. Tutaj nasz CM ma co najmniej dwa sposoby:

może skorzystać z GUI w postaci snap-ina "Certification Authority". Łatwe, przyjemne, dostępne na każdej stacji z RSAT - nie ma co się rozwodzić.
dla geeków jest certutil, który pozwala certyfikat zatwierdzić. znów skryptowanie.

ad.4. W zasadzie pomysł na ten wpis pojawił się właśnie dla tego punktu - jak taki certyfikat pobrać?! jeśli żądanie było przez stronę WWW, to wystarczy potem sprawdzić czy już został zatwierdzony i stamtąd pobrać. Ale w MMC Certificates nie ma opcji 'pobierz certyfikat'. Jedynym ze sposobów jest oczywiście aby CM wyeksportował certyfikat i przesłał nam mailem. Okazuje się, że użytkownik - nawet ambitny i świadomy, nie jest w stanie takiego certyfikatu pobrać bez pomocy. w sukus znów przychodzi kombinacja skryptowania i linii poleceń... to jeszcze za chwilę.

Linia poleceń

Ten wpis ma status 'podstawy' więc nie będzie tego dużo. Opiszę tylko kilka podstawowych operacji związanych z rządaniem certyfikatów.

Zatwierdzony przez administratora certyfikat można tak na prawdę pobrać - nawet zwykły user. trzeba jednak znać Request ID.

Jeśli mamy uprawnienia administratora na Issuing CA, to możemy się go zdalnie odpytać o 'pending certificates'. Tu jednak kolejna niespodzianka - niestety aby polecenie zadziałało wymagane jest zainstalowanie RSAT dla CA ): a w takim przypadku, jeśli nie wymagamy autoamtyzacji, wygodniej to zrobić z GUI. niemniej:

certutil -view -config "<CA_SERVER_NAME>\<CA_NAME>" -Restrict "Request Disposition=9" -out "Request ID, Request Submission Date, Request Common Name, Requester Name, Request Email Address, Request Distinguished Name, CertificateTemplate, Request Disposition"

Znając ID można pobrać certyfikat za pomocą drugiego, podstawowego narzędzia - certreq:

certreq.exe -retrieve -config "<CA_SERVER_NAME>\<CA_NAME>" <OutPutCertFile.cer>

I na koniec zostaje sklejenie tak otrzymanej częsci publicznej z prywatną. Oczywiście aby to zrobić musimy być zalogowani na tym samym koncie i komputerze, na którym generawany był request:

certreq -accept <OutPutCertFile.cer>

W Windows 8/Server 2o12 jest nowy moduł Powershell - PKI. Jak to z powershell - jest łatwiej i przyjemniej. Jest również polecenie get-Certificate, które również wiele automatyzuje - niestety statystyki pokazują, że póki co w8 stanowi mały procent klientów w domenach firmowych. Trzeba zatem jeszcze chwilę poczekać - i migrować ASAP (:

Drobna ciekawostka na koniec - gdzie przechowywany jest klucz prywatny po wygenerowaniu requestu?

a fizycznie są to dwa miejsca:

$env:userprofile\AppData\Roaming\Microsoft\SystemCertificates\Request\Certificates
HKCU\Software\Microsoft\SystemCertificates\REQUEST\CRLs

Podsumowanie

Z windows 8/Server 2o12 świat staje się prostszy
Brakuje standardowych automatów dla CA.
Najlepszym wyborem dla użytkownika pozostaje interfejs WWW

Refs

eN.

autor: nExoR

Windows To Go – chcesz?

2013-02-24T09:57:26Z

Pisałem kiedyś o Windows To Go, i od tego czasu zmieniło się tyle, że sam jestem aktywnym użytkownikiem tej funkcjonalności. Krótko podsumowując dotychczasowe doświadczenie, napiszę tylko: podoba mi się. Pewnie, gdybym nie miał takiej możliwości jakoś poradziłbym sobie inaczej, ale skoro mam – jestem zadowolony. Działa, sprawdza się, Office 2013 śmiga... czego chcieć więcej?

Do zmian dotyczących WTG, które zaszły przez ostatnie miesiące, dodać można jeszcze jedną: istnieje więcej oficjalnie wspieranych urządzeń. Bo choć niemal każdy odpowiednio duży pendrive jest fizycznie zdolny do obsłużenia Windows To Go, to jednak wsparcie otrzymują tylko te, które są odpowiednio wydajne. Tak naprawdę, myśląc o pendrive do WTG, raczej należy traktować go jako opakowany w postać pendrive dysk SSD niż jako typową pamięć flash. Różnica prędkości potrafi być znacząca i choć nie przyszło mi dotąd do głowy sprawdzić tego samodzielnie, to widziałem "screenshoty", na których ciągły transfer wynosił około 200MB/s.

Jak pewnie część z Was wie, w tym tygodniu, w Redmond odbywa się MVP Summit – coroczna konferencja, w ramach której pasjonaci technologii Microsoft pompowani są nową wiedzą i różnymi innymi rzeczami. Jak zapewne wie inna część z Was – jestem jednym z ekspertów w programie Springboard Technical Experts Panel. I złożenie jednego faktu z drugim sprawiło, że dostałem nowy, ładny i superszybki pendrive DataTraveler Workspace. I choć bardzo mnie to ucieszyło, to jednak dwa pendrive z WTG, to trochę za dużo. Dlatego mam propozycję: może ktoś chce taki pendrive? Oddam w dobre ręce temu, kto:

Pobierze z portalu Springboard dziewięćdziesięciodniową wersję ewaluacyjną Windows 8 Enterprise x64
Zapisze ją w pliku C:\WTG\Win8Eval.iso
W komentarzu do niniejszego wpisu pierwszy opublikuje skrypt (preferowany PowerShell), który uruchomiony na świeżo zainstalowanym Windows 8 Enterprise x64 zawierającym plik C:\WTG\Win8Eval.iso sprawi, że wetknięty w port USB DataTraveler Workspace stanie się dyskiem Windows To Go, zabezpieczonym przy pomocy BitLockera z hasłem "TechNet". Można dla uproszczenia założyć, że w komputerze jest tylko jeden dysk twardy skonfigurowany domyślnie podczas instalacji Windows 8.

Ktoś chętny? Zapraszam :)

I jeszcze tak zwany drobny druk:

Po raz kolejny podkreślam, że nie jestem w żaden formalny sposób związany z Microsoft. To co tu piszę i jaki konkursy wymyślam, to czysta prywata. Pendrive dostałem w prezencie i chętnie przekażę go komuś, kto go potrzebuje i potrafi coś w Windows 8 "wystrugać".
Komentarze do bloga są moderowane, co oznacza, że całkiem sporo skryptów może zostać przesłanych a żaden się nie pojawi online. Jak je zatwierdzę, to nagle będzie ich na przykład dziesięć na raz. Oznacza to, że ktoś może nic nie widzieć, opublikować swój skrypt a potem dowiedzieć się, że wcale nie był pierwszy.
Wygra ten skrypt, który ocenię jako wystarczająco dobry. Ostateczną weryfikacją poprawności rozwiązania będzie przetestowanie go na systemie opisanym wcześniej. Jeżeli powstanie działający dysk WTG, to pewnie skrypt jest OK.
Skrypt uruchamiać będę z uprawnieniami administracyjnymi.
Zakładam, że Windows 8 ma wbudowane sterowniki pozwalające na pracę na moim sprzęcie.
Istniejąca na pendrive zawartość nie jest dla mnie istotna i może zostać usunięta przez skrypt, jeżeli jego autor ma taką potrzebę.
Powstały dysk WTG nie musi być aktywowany ani skonfigurowany. Stan, w którym po zabootowaniu wyświetla się kreator instalacji, jest dla mnie akceptowalny pod warunkiem, że końcowy użytkownik może sobie "doklikać" instalację do końca na dowolnym wspieranym przez Windows 8 x64 komputerze mającym łączność z Internetem.
Konfiguracja środowiska nie będzie zawierała celowych utrudnień (na przykład nie wyłączę obsługi USB w polisach) ale i nie zamierzam w żaden sposób jej zmieniać tylko po to, żeby stworzyć skryptowi dogodne warunki, bez których cośtam nie zadziała.
Nie planuję odwoływania mojego mini-konkursu, ale zastrzegam sobie do tego prawo. A nuż pendrive spali się w czasie testów? Albo wydarzy się coś innego, czego nie potrafię teraz przewidzieć?
Komentarze postaram się regularnie akceptować, ale ewentualne przesłane rozwiązania sprawdzę najwcześniej za parę dni. Niestety moja doba też ma tylko 24h...

Powodzenia!

Autor: Grzegorz Tworek [MVP]

PS Z komentarzy widzę, że wymagane hasło BitLockera może być zbyt proste. Zgadzam się na inne, choćby takie jak "TechNet123".

tajemnice certyfikatów cz.2 - przypisanie klienta do konkretnego CA

2013-02-06T10:16:14Z

takie pytanie na rozgrzewkę: jeśli jest kilka issuing CA w domenie, skąd klient wie do którego się zgłosić?

podobne, ale trochę trudniejsze: jak zmusić klienta do skorzystania z konkretnego CA?

scenariusz: duża korporacja, która posiada wiele oddziałów na całym świecie. projekt PKI zakłada, żeby użytkownicy dostawali certyfikaty z autoenrollmentu. lokalizacje połączone są ze sobą różnymi łączami. chcemy zaprojektować strukturę tak, aby użytkownicy z danej lokalizacji geograficznej dostawali certy z CA 'gdzieś w pobliżu'. zdefiniowanie CA w Azji i powiedzenie że 'to w pobliżu' może brzmieć trochę śmiesznie (; ale załóżmy że podział na kontynenty wystarczy.

najpierw więc trzeba odpowiedzieć na pytanie pierwsze - jak klient wybiera CA? po pierwsze w GPO definiuje się właściwości enrollmentu... w zasadzie to się go po prostu włącza. klient sprawdza w AD [zakładam scenariusz z pełną integracją z AD] szablony a następnie szuka CA, które dany szablon obsługuje. AFAIK - jest to losowy algorytm i jeśli jeden serwer jest niedostępny, skorzysta z innego.

czas więc na więcej szczegółów, które dadzą odpowiedź na drugie pytanie. układankę trzeba złożyć z kilku elementów:

na każdym CA publikuje się szablony, które wydaje - np. jeden CA może wydawać certyfikaty NAP a inny dla użytkowników
szablony mają zdefiniowane uprawnienia. m.in. jest tam uprawnienie 'autoenroll'
uprawnienia przypisuje się grupom w AD

finalnie więc należy:

założyć grupy dla regionów - np. 'ASIA', 'EU', 'S_AMERICA' itd.
utworzyć szablony dla użytkowników i komputerów dla każdego regionu - np. 'ASIA Users', 'EU Users'... szablony mogą być niemal identyczne - poza nazwą i uprawnieniami
należy dla szablonów zdefiniować adekwatne uprawnienia 'autoenroll' dla grup regionalnych
należy utworzyć issuing CA dla regionu i opublikować na nim konkretny szablon.

jest też drugi sposób, który jednak uważam za 'brudny'. 'brudny' bo przypomina raczej workaround niż rozwiązanie i posiłkuje się mechanizmem z zupełnie innej warstwy - sieciowej a nie aplikacyjnej. no i ma swoje skutki uboczne, które mogą mieć trudne do przewidzenia konsekwencje:

ponieważ klienci poszukują pierwszego CA jaki odpowie, publikującego dany szablon... wystarczy pomiędzy lokalizacjami blokować ruch sieciowy do pozostałych CA.

eN.

autor: nExoR

A czy TY chcesz mieć Internet Explorer 10?

2013-01-31T09:51:13Z

Nie wiem czy osobiście używasz Internet Explorera, ale jeżeli zarządzasz jakimś nie całkiem małym systemem, to pewnie IE tam jest. Jest, a programiści w Microsoft nie śpią i na horyzoncie majaczy już wersja 10 dla najpopularniejszych obecnie systemów czyli Windows 7. Gdy pojawi się wersja finalna – systemy automatycznego aktualizowania wrzucą ją na komputery klienckie i serwery. Dla pojedynczego użytkownika to pewnie dobrze. Ale dla dużej firmy, w której dookoła przeglądarki zbudowane są rozwiązania biznesowe, z całej masy różnych powodów może okazać się to kłopotem. Rada tak naprawdę jest jedna: przetestować wszystkie rozwiązania z nową przeglądarką. Ewentualnie unowocześniając je tak, żeby działały bez problemów. Bo zgodność wstecz to jedna sprawa ale programiści potrafią "wystrugać" takie cuda, że najlepiej nie dotykać stacji klienckiej, bo wszystko się zawali.

A jeżeli nie zrobiłeś jeszcze testów? Jeżeli nie możesz spać w nocy, myśląc nad tym jak skończy się automatyczna przesiadka na nową wersję IE? Albo po prostu nie masz ochoty jej oglądać, bo liczba 10 źle Ci się kojarzy? Pozostaje zrobić tylko jedno: zabronić aktualizacji twoim komputerom. Robi się to tak samo, jak przy poprzednich wersjach przeglądarki: uruchamiając specjalny, przygotowany przez Microsoft program, który w rejestrze zabroni instalacji IE10 - Internet Explorer 10 Blocker Toolkit.

Warto wiedzieć, że nawet, jeżeli zabroniłeś już instalacji IE8 czy IE9 (o Blocker Toolkitach do nich pisałem gdy były nowością), Internet Explorer 10 wymaga swojej blokady i tak. To jest oddzielnie zarządzane.

Tak więc, jeżeli nie chcesz aktualizować systemów do IE10 – czym prędzej pobierz Blocker Toolkit i przygotuj mniej lub bardziej zautomatyzowaną jego dystrybucję na zarządzane komputery.

Autor: Grzegorz Tworek [MVP]

PS Jeżeli użytkownik ma odpowiednie prawa i poczuje się mądrzejszy niż jego administrator, to nową przeglądarkę zainstaluje i tak. Blocker Toolkit uniemożliwia instalacj�� automatyczną a nie ręczną.

PS2 Jeżeli używasz WSUS czy SCCM, to oczywiście sam określasz co ma się instalować i kiedy. Blocker Toolkit broni przed instalacją przez "goły" Windows Update.