Dla potrzeb tworzonej dokumentacji dla jednego z moich klientów pojawiła się potrzeba zebrania w jednym dokumencie wszystkich ról użytkowika. Najłatwiejszym sposobem osiągnięcia żadanego efektu jest uruchomienie poniższego skryptu PowerShell, który pozwala na wyeksportowanie wszystkich User Role do pliku.

Skrypt został zaczernięty z bloga Jonathana Almquist  – zachęcam do zapoznania się z przemyśleniami oraz praktycznymi rozwiązaniami, które są tam prezentowane.

##————————————————–##
#   Use this script to export User Roles to a text
#   file.  The output file from this script can be
#   used in conjunction with the ImportUserRoles
#   script.
#   Author: Jonathan Almquist
#   Name: ExportUserRoles.ps1
#   Ver: 6.0.6278.0-2
#   Date: 03/20/2008
#   Revisions:
#   -Added user input prompt for RMS server name
#   -Added user input prompt for file path & name
#   –quotes not required for path with spaces
#   -Added pssnapin checking
#   -Added psdrive checking
#   -Management Group connectivity from PS
##————————————————–##
##  Get user input
$rms = read-Host "Enter the RMS server name"
$filename = read-Host "Enter path and filename for output file (ex: c:\user_roles.txt)"
##  Check for Operations Manager Snap-in
$snapin = pssnapin | select-Object name
$added = 0
##  Loop through each instance of Snap-in
foreach ($pssnapin in $snapin)
    {
    if ($pssnapin -like "*Microsoft.EnterpriseManagement.OperationsManager.Client*")
        {
        $added = 1
        }
    }
if ($added -eq 0)
    {
    add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"
    write-Host "Operations Manager Snap-in added."
    }
else
    {
    write-Host "Operations Manager Snap-in already added."
    }

set-location "OperationsManagerMonitoring::"
##  Check for Monitoring Drive
$drive = psdrive | select-Object name
$added = 0
##  Loop through each instance of Drive
foreach ($psdrive in $drive)
    {
        if ($psdrive -like "*Monitoring*")
        {
        $added = 1
        }
    }
if ($added -eq 0)
    {
    New-PSDrive -Name: Monitoring -PSProvider: OperationsManagerMonitoring -Root: \
    write-Host "Monitoring Drive added."
    }
else
    {
    write-Host "Monitoring Drive alreaded added."
    }
##  Connect to Management Group
New-ManagementGroupConnection -ConnectionString: $rms
cd Monitoring:\$rms
##  Gather information
$mgName = (get-item .).ManagementGroup.name
$date = get-date -uformat "%Y-%m-%d"
$userroles = get-userrole | select-object name,displayname,description,monitoringprofile,users
##  Write output file
foreach ($role in $userroles)
    {
    "Profile: " + $role.monitoringprofile.name + "`r`n" + "Name: " + $role.name + "`r`n" + "DisplayName: " + $role.displayname + "`r`n" + "Description: " + $role.description + "`r`n" + "Users: " + $role.users + "`r`n" | out-file $filename -append
    }
write-Host "Process complete"
##
##

 “Z terminem Security Identifier (SID, identyfikator zabezpieczeń), zetknął się przynajmniej raz każdy administrator systemu Windows. Zazwyczaj każdy wie, że jest on reprezentacją numeryczną każdego podmiotu zabezpieczeń, który został określony bądź utworzony w ramach systemu. Wiadomo także, że jest on unikalny oraz składa się z długiego ciągu cyfr. Jednak zdarza się, że wiedza na temat znaczenia poszczególnych sekwencji tego ciągu pozostaje większą lub mniejszą niewiadomą…”

W czasopiśmie SecurityMag by Hakin9 ukazał się mój artykuł na temat Security Identifier w systemach Windows.

Czasopismo w postaci pliku pdf można pobrać ze strony http://securitymag.pl  lub z mojego SkyDrive.

Chętnych zapraszam do lektury!

Zapraszam do przeczytania mojego tekstu o bezpieczeństwie Bluetooth, który ukazał się na portalu HCSL. Tekst opowiada o architekturze stosu Bluetooth, aplikacjach na platformę Windows Mobile, Java oraz prezentuje kilka praktycznych przykładów ataków. Miłej lektury!

Na portalu wss.pl ukazał się mój artykuł dotyczący Security Templates w Windows Server 2003. W artykule zostało wyjaśnione, co to są szablony bezpieczeństwa, ich podstawowe rodzaje oraz kilka narzędzi pozwalających na pracę z szablonami zabezpieczeń w Windows Server 2003. Życzę przyjemnej lektury.

W pierwszej części artykułu dowiedzieliście się czym są security templates, gdzie można je znaleźć oraz które z nich są domyślne dla Windows Server 2003. 

Link do pierwszej części: http://frezjadg.spaces.live.com/blog/cns!4643E2C3C1C2AE49!374.entry

Narzędzia, które pozwalają zrobić “coś” z szablonami zabezpieczeń są wylistowane poniżej:

• Security Templates snap-in
• Security Configuration and Analysis snap-in
• Narzędzie wiersza poleceń: secedit.exe
• Security Extensions to Group Policy
• Hfnetchk.exe
• Microsoft Baseline Security Analyzer (MBSA)

Dzisiaj pokażę 2 pierwsze narzędzia.

1. Narzędzie nr 1: Przystawka Szablony Zabezpieczeń (Security Templates) – to jest przystawka, która służy do tworzenia, przeglądania i modyfikacji szablonów zabezpieczeń. Taki szablon można potem zastosować na komputerze lokalnym, przypisać do konkretnego GPO albo użyć go do analizy bezpieczeństwa (np. żeby porównać, jak bardzo zabezpieczenia naszego komputera odstają od tych które powinny zostać wdrożone. O analizie za chwilę).

Przystawki Security Templates i Security Configuration and Analysis nie mają własnych skrótów (jak np. Services – services.msc), dlatego trzeba dodać je do konsoli ręcznie. Dodajmy do konsoli obie przystawki.

Aby uruchomić tę przystawkę należy:

Kliknąć Start i wybrać Run
W otwartym oknie wpisać mmc
W konsoli mmc wybrać File –> Add/Remove Snap-in

W oknie Add/Remove Snap-in należy wybrać Add, a następnie nawigować do przystawki Security Templates.

Następnie należy dodać przystawkę i kliknąć OK.

Nowo uruchomione okno pozwala na przejrzenie i zmodyfikowanie ustawień możliwych do skonfigurowania. Jest z czego wybierać.

2. Narzędzie nr 2: Przystawka Security Configuration and Analysis – to jest przystawka, która służy do stosowania gotowego szablonu zabezpieczeń. Pozwala też na analizowanie obecnej konfiguracji bezpieczeństwa komputera oraz porównywania jej z dowolnym szablonem zapisanym jako baseline. Za chwilę zrobimy takie porównanie. Przystawka działa tylko lokalnie. Nie można jej użyć na zdalnej maszynie. Zazwyczaj administratorzy używają tej przystawki do projektowania i testowania konfiguracji lokalnie, żeby nie musieć potem wycofywać zmian z poziomu domeny czy jednostki organizacyjnej (OU). Procedura dodawania przystawki do konsoli jest opisana powyżej.

Analizowanie systemu:

Aby przystąpić do analizy systemu należy zacząć od stworzenia bazy danych zawierającej aktualny zestaw zabezpieczeń zaimplementowany na naszym komputerze. W tym celu należy wykonać 2 zestaw poleceń sugerowanych przez przystawkę:

Klikamy prawym przyciskiem myszy na Security Configuration and Analysis i wybieramy Open Database.

Nadajemy nazwę bazie danych, która będzie przechowywać aktualny zestaw zabezpieczeń komputera. Baza zapisuje się z rozszerzeniem sdb.

Importujemy szablon, z którym chcemy porównać aktualny zestaw zabezpieczeń. Ponieważ ja analizuję testowy kontroler domeny, wybrałam hisecdc.inf (High Secure Domain Controller).

Wybrany szablon jest importowany. Następnie otrzymujemy garść informacji: ścieżkę do pliku z bazą danych przechowującą aktualny zestaw zabezpieczeń oraz wiadomość, gdzie należy szukać pliku z logami. Dowiadujemy się również, aby podejrzeć informacje z utworzonej bazy danych konieczne jest wykonanie analizy.

Analiza sprowadza się do kliknięcia na Security Configuration and Analysis i wybrania Analyze Compiter Now…

Zostajemy jeszcze poproszeni o potwierdzenie ścieżki do pliku z logiem zawierającym błędy.

Przeglądającwyniki analizy można zobaczyć klika oznaczeń:

– wybrane ustawienie jest skonfigurowane w szablonie i naszej bazie danych i wartości pasują do siebie
– wybrane ustawienie jest skonfigurowane w szablonie i naszej bazie danych ale wartości nie zostały do siebie dopasowane
– ustawienie jest skonfigurowane w szablonie ale nie istnieje w naszej bazie danych
– wybrane ustawienie nie jest skonfigurowane w szablonie i w naszej bazie danych

Uwaga: Aby móc zaimportować szablon wymagane jest członkostwo w grupie Administratorów.

Na kontrolerze domeny do folderu z Szablonami Zabezpieczeń nie da się dodać i usunąć użytkowników, nie da się przypisać im wyższych uprawnień, nie da się zrobić dziedziczenia z folderu nadrzędnego nad ..Templates, nie da się przejąć folderu z Szablonami na własność. Inspekcja uprawnień wynikowych jasno informuje, że jako Authenticated Users lub Server Operators mam prawo Read&Execute.

Na serwerze członkowskim nie ma wprawdzie ograniczeń odnośnie dodawania i usuwania użytkowników do grupy uprawnionych do modyfikacji szablonów, niemniej jednak próba analizy obecnego baseline z wybranym szablonem kończy się odmową dostępu:

Trudno. Jak mus to mus.

Na dziś to wszsystko, co dla Was przygotowałam. C.d.n 🙂

Security, security… temat modny i na topie. Bo jakże może być inaczej, kiedy słyszy się o kompromitacji danych, wycieku wrażliwych informacji odgrywających kluczową rolę w funkcjonowaniu firmy a każdy dzień przynosi informacje o nowo odkrytych lukach w bezpieczeństwie systemów. Każdy system można zabezpieczyć {lepiej lub gorzej}, warto zatem zapoznać się z Szablonami Zabezpieczeń (Security Templates).

Co to jest Security Template?

Security Template to nic innego jak plik tekstowy z rozszerzeniem inf, który opisuje zestaw ustawień konfiguracyjnych. Ustawień powiązanych z bezpieczeństwem, rzecz jasna. Template zawiera ustawienia pozwalające na skonfigurowanie poziomu bezpieczeństwa dla polityk kont, polityk lokalnych, dzienników zdarzeń, systemu plikowego, ustawień rejestru, usług systemowych i grup z ograniczeniami. (Restricted Groups).

Rys. 1: Obszary podlegające zabezpieczaniu za pomocą Security Templates

Windows Server posiada predefiniowane szablony (o tym później) ale nic nie stoi na przeszkodzie, by przygotować własny szablon, skonfigurowany zgodnie z politykami bezpieczeństwa obowiązującymi w firmie.

Gdzie można to wykorzystać?

Do sporządzenia zestawu zabezpieczeń, które mogą być przygotowane pod konkretny serwer lub stację kliencką (Serwer SQL, kontroler domeny, serwer IIS, serwer plików, stacja kliencka firmowego grafika, programisty, księgowego…. Whatever!).

Trzeba jednak pamiętać, że im bardziej wymagający zestaw zabezpieczeń przygotujemy, tym więcej dostaniemy telefonów od użytkowników, którzy będą potrzebowali pomocy. Dlatego rozsądnie zaplanowane security zawsze jest pewnego rodzaju kompromisem. Użytkownicy dzwoniący z pytaniami typu: „Przepraszam, a dlaczego ja muszę zmieniać hasło co 2 tygodnie?” „Dlaczego nie mam dostępu do plików z katalogu …?” „Źle wpisałem hasło i zablokował mi się komputer” i tak dalej, i tak dalej … nie wpływają dodatnio na efektywność i wydajność administratora i samych użytkowników.

Domyślne Security Templates

Security Templates rezydują w katalogu %systemroot%:WindowsSecurityTemplates.

Rys. 2: Domyślne Security Template dostępne w Windows Server 2003

W katalogu…Templates znajdują się następujące rodzaje szablonów:

1. setup security.inf (default security) – jest to szablon stosowany podczas instalacji „świeżego” systemu operacyjnego na komputerze. Zawiera domyślny zestaw zabezpieczeń dla systemu, obejmujący m.in. uprawnienia do systemu plikowego dla dysku podstawowego (root). Można użyć go na systemie klienckim lub serwerze ale nie na kontrolerze domeny. Dla kontrolera domeny przewidziany jest inny szablon– DC security. Zakłada się, że każdy stworzony własny szablon będzie wdrożony na komputerze, który używa setup security.inf.

1. DC security.inf (domain controller default security) – jest to szablon, który jest automatycznie używany, kiedy komputer zostaje wypromowany do roli kontrolera domeny. Zawiera zestaw domyślnych zabezpieczeń dla kontrolera domeny.

1. compatws.inf (compatible workstation) – szablon zabezpieczeń setup security.inf pozwala członkom grupy Użytkownicy (Users) uruchomić aplikacje certyfikowane (takie, które mają logo Windows Logo for Software). Niecertyfikowane aplikacje często wymagają do działania podniesionych uprawnień – członkostwa w grupie Użytkownicy Zaawansowani (Power Users). Szablon modyfikuje więc uprawnienia dla użytkowników, którzy takowe aplikacje muszą uruchamiać nie naruszając przy tym zabezpieczeń dla stacji  klienckiej, na której pracuje użytkownik.

1. rootsec.inf (system root security) – domyślnie ten szablon określa uprawnienia do dysku systemowego. Należy użyć tego szablonu, jeśli istniejące uprawnienia na dysku root zostaną przypadkowo zmienione lub zaistnieje potrzeba zastosowania szablonu na innych woluminach niż systemowy. Szablon nie nadpisuje jawnych uprawnień, jakie są zdefiniowane dla obiektów potomnych (child objects), a jedynie uprawnienia, które są przez nie dziedziczone.

1. securews.inf (secure workstation) – jest to szablon podnoszący zabezpieczenia dla komputerów, które nie są kontrolerami domeny. Zawiera mocniejsze opcje zabezpieczeń i polityki audytu niż setup security.inf.

1. securedc.inf (secure domain controller) – szablon podnoszący zabezpieczenia w obszarach systemu operacyjnego poprzez ograniczanie użycia starszych protokołów uwierzytelniania niż NTLM. Konfiguruje również podpisywanie pakietów SMB dla plików udostępnionych (ustawienie to jest domyślnie wyłączone na serwerach) oraz usuwa wszystkich członków z grupy Power User.

1. hisecdc.inf (highly secure domain controller ) – szablon jest przeznaczony dla komputerów, które działają w domenie i tryb domeny jest ustawiony jako natywny. Zastosowanie szablonu wymusza podpisywania pakietów SMB i szyfrowania całej komunikacji sieciowej za pomocą protokołu NTLMv2 oraz zabezpiecza rejestr i pliki. Ponadto wyłącza wszystkie dodatkowe usługi i usuwa wszystkich członków z grupy Power Member.

1. hisecws.inf (highly secure workstation) – jest to szablon, który zawiera ustawienia zabezpieczeń dla serwera lub stacji roboczej. Ustawienia są podobne jak w przypadku hisecdc.inf.

1. iesacls.inf (Internet Explorer ) – jest to szablon pozwalający audytować wpisy w rejestrze dotyczące zabezpieczenia Internet Explorera. Zastosowanie tego szablonu nie poprawi zabezpieczeń IE ale można go wykorzystać jako baseline – do tworzenia własnego szablonu. Daje również możliwość podglądu co działo się z IE od momentu włączenia audytu.

Zanim zaczniesz coś robić …

1. Domyślny szablon z zasady jest domyślny, predefiniowany i NIE NALEŻY nic w nim zmieniać. Zamiast tego trzeba skopiować wybrany szablon i na nim wykonywać wszystkie zmiany. Trzeba mieć świadomość tego, na kopii jakiego szablonu dokonujemy zmian, np. tworzenie zaawansowanych zabezpieczeń dla kontrolera domeny na podstawie szablonu compatws.inf jest złym pomysłem.
2. Szablon setup security.inf ustanawia minimalny baseline security dla sieci Windows Server 2003. Jeśli kiedykolwiek wymagane będzie przywrócenie domyślnych ustawień bezpieczeństwa, trzeba będzie wykorzystać ten template. Setup security.inf powinien być używany tylko poprzez przystawkę Security Configuration and Analysis lub poprzez narzędzie secedit (nie powinniśmy przypinać go przez GPO, ponieważ zawiera on ponad 1000 różnych ustawień konfiguracyjnych (czyli bardzo dużo) a polisy GPO domyślnie odświeżają się co 90 minut na klientach i co 5 minut na kontrolerach domeny).
3. Wszystkie modyfikacje dokonane na szablonie powinny zostać zapisane pod inną nazwą niż oryginalny plik bazowy.
4. Przygotowany szablon przez wdrożeniem w środowisku produkcyjnym powinien zostać przetestowany. Dopisuję po namyśle jako przypomnienie.

W drugiej części pokażę narzędzia, które służą do modyfikacji, tworzenia i stosowania szablonów zabezpieczeń