Jak zabezpieczyć system Windows Server? W jaki sposób wykonać bezpieczną konfigurację systemu Windows Server? Jakie kroki należy podjąć, aby zapewnić ochronę danych i zasobów w środowisku Windows Server? Jakie są najlepsze praktyki w zakresie hardeningu systemu? Jakie narzędzia i techniki można zastosować, aby zwiększyć bezpieczeństwo serwera?

Źle zainstalowane i skonfigurowane systemy operacyjne z rodziny Windows stały się przyczyną błędnego ich postrzegania za mniej bezpieczne środowiska. Microsoft poczynił ogromne postępy technologiczne od czasu pierwszych systemów operacyjnych Windows, produkt ten oddawany jest klientom w formie „out of box”. Użytkownik może łatwo samodzielnie „prze-klikać” kreator instalacyjny i przejść do dalszego użytkowania OS i to dosłownie w kilka minut. Ta pozorna prostota i masowe zastosowanie systemów operacyjnych Windows uczyniła z nich doskonały cel  potencjalnych ataków. Ekonomicznie warto pisać szkodliwe aplikacje na środowiska które są powszechnie stosowane.  Prościej jest atakować masowo systemy na które są ogólnodostępne. To tutaj jest większa szansa że ich administratorzy nie poświęcili należytej uwagi na konfiguracje. Dodatkowo sam Windows ze względu na swoją popularność stanowi doskonałą bazę dla aplikacji (są ich już obecnie miliony) od których zazwyczaj rozpoczyna się atak.

Wraz z nastaniem „ery specjalistów ds. bezpieczeństwa”, gdzie świadomość zagrożeń powinna wzrastać, tendencja jest wręcz odwrotna. Większa ilość systemów, coraz więcej usług, mnogość wersji oprogramowania przekłada się na większa ilość prac administracyjnych.

Problem w tym że po ponad 20 latach pracy w IT stale spotykam źle skonfigurowane systemy operacyjne z rodziny Microsoft. A jeszcze częściej nie są one skonfigurowane wcale, po prostu użytkownicy czy administratorzy klikają DALEJ/NEXT i cieszą się z przeprowadzonej instalacji zapominając o tym, że dopiero na tym etapie zaczyna się praca związana z przygotowanie środowiska.

Wpis ten nie przedstawia procesu instalacji systemu Windows Server, pomijamy też kwestie źródła jego instalacji (OEM/ISO). Zakładam że źródło było zaufane. Odnoszę się do środowiska serwerowego i pomijam systemy klienckie. Artykuł nie dotyczy też systemów które nie są już dostępne w sprzedaży, Skupiam się na wersji która jest aktualnie wydana i posiada najdłuższy okres wsparcia: Windows Server 2025. Samo zagadnienie dotyczące bezpieczeństwa Windows Server podzieliłem na następujące, równoważne sobie elementy:

Wpis posiada podział w/w obszary i stanowi swoisty punkt wyjścia dla bezpiecznej konfiguracji środowisk Windows Server pod docelowe aplikacje.

Odpowiadam też odrazu na pytanie czy wybieramy wersje Core czy GUI dla naszego systemu Windows. Ze względu na zgodność systemu z aplikacjami firm trzecich, wersja Core systemu powinna być stosowana tylko w przypadku gdy serwer Windows ma pełnić role z zakresu natywnyc ról i funkcji Microsoft np kontroler domeny. Jeżeli na serwerze będzie działać dedykowana aplikacja innego niż producent vendora – wybieramy GUI (chyba że jej specyfikacja jasno w dokumentacji na to zezwala)

• Konfiguracja systemu operacyjnego
  • Podstawowe czynności konfiguracyjne
  • Nazwa środowiska / HOSTNAME
  • Zapora systemowa / Firewall
  • PowerShell
  • Dostęp zdalny
  • RDP (Remote Desktop Protocol) – pulpit zdalny
  • WinRM (Windows Remote Management) – Powershell
  • Zbędne usługi
  • Wyłączenie niewspieranych rozwiązań
    • NTLM
    • SMB
    • SSL / TLS
    • WSH
  • Udziały administracyjne
• Bezpieczeństwo kont
  • Konta użytkownika
  • Konta usług
  • Pozostałe polityki kont użytkowników (hasła, logowanie)
• Utrzymanie systemu operacyjnego
  • Aktualizacje i poprawki
  • Logi
  • Realizacja dostępu zdalnego
• Pozostałe elementy
  • Oprogramowanie
  • Weryfikacja oprogramowania przed instalacją
  • Oprogramowanie antywirusowe
  • Monitoring środowiska
  • Oprogramowanie EDR (Endpoint Detection and Response) / XDR (Extended Detection and Response)
• Podsumowanie

Konfiguracja systemu operacyjnego

Podstawowe czynności konfiguracyjne

Do podstawowych czynności konfiguracyjnych zaraz po instalacji systemu Windows Server należy:

• adresacja interfejsów sieciowych (w tym nadanie im etykiet)
• przygotowanie dostępnych udziałów dyskowych (system plików, przypisanie liter, etykiety)
• ustawienia dotyczące czasu (strefa czasowa)
• ustawienia regionalne (niezwykle istotne ze względu na chociażby format czasu, format zapisu danych liczbowych, ustawienia językowe)
• nazwa środowiska (tzw. hostname)
• pobranie i instalacja aktualizacji

Jednocześnie powinna rozpocząć się ewidencja/dokumentacja środowiska. Dzięki w/w czynnością możemy przejść dalej

Nazwa środowiska / HOSTNAME

Konfiguracje systemu Windows Server zaczynamy od nazwy naszego serwera. Nie stosujemy nazewnictwa jasno określającego przeznaczenie środowiska. Jeżeli klient nie posiada własnej konwencji nazewnictwa typu SRV01, VCSERVER41, WS231110 albo chce zastosować konwencje jasno wskazująca na przeznaczenie środowiska (BACKUP54, VEEAM3, COMSERV2 ) należy go przekonać że jest to błędem i zastosować jeden z dwóch poniższych wzorców.

Najlepszym sposobem jest zastosowanie domyślnego schematu nazewnictwa dla systemów Windows Server z w pełni losowym 11 znakowym ciągiem znaków: WIN-XXXXXXXXXXX czyli np. WIN-L1HNT0IQ463. Nadal wskazuje to na zainstalowany typ systemu operacyjnego ale bez dokumentacji nie powie nic o przeznaczeniu środowiska. Drugą metodą jest celowe wprowadzanie w błąd czyli zmiana nazwy środowiska na takie które nie wzbudzi zainteresowania np. nazwa drukarki PRINTER7, czy wprost HPprinter-M476

Zapora systemowa / Firewall

Zapora musi być zawsze włączona! Najczęstszym błędem konfiguracyjnym jest wyłączenie tej usługi, brak zdefiniowanych reguł i wyjątków.

W zaporze definiujemy określone reguły dla naszych aplikacji – definiujemy reguły dla ruchu przychodzącego i wychodzącego oddzielnie!

Zestaw domyślnie zdefiniowanych reguł jest dość duży i zależy od tzw. profilu sieci. Zalecanym profilem w rozpatrywanym przez nas przypadku środowiska nie wpiętego do domeny powinien być profil Publiczny (reguły są bardziej restrykcyjne):

Zmiany profilu możemy dokonać z poziomu PowerShell:

Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Public

PowerShell

Większość nieautoryzowanych ingerencji w system operacyjny polega na wykonywaniu specjalnie przygotowanych skryptów. Powłoka PowerShell dzięki swojej oddzielnej polityce pozwala na zablokowanie wykonywania skryptów – zezwalając dalej na wykonywanie pojedynczych poleceń przez administratora. Domyślne ustawienia Windows Server 2025 pozwalają na wykonywanie skryptów podpisanych przez zaufane źródła, aby zwiększyć poziom bezpieczeństwa zmieniamy domyślnych ustawienia ExecutionPolicy na Restricted.  Zmian dokonujemy z poziomu konsoli PowerShell:

Get-ExecutionPolicy
Set-ExecutionPolicy -ExecutionPolicy Restricted
Get-ExecutionPolicy

Dostęp zdalny

Decyzja o konfiguracji dostępu zdalnego jest kolejnym krokiem w przygotowaniu środowiska. Jeżeli system Windows Server zaktualizowany o wszystkie dostępne poprawki (w cyklu wydawniczym), Microsoft zapewnia że realizowany przez wbudowane metody dostęp zdalny jest poprawnie chronione od strony kryptograficznej i użytkowej. Należy też pamiętać że KAŻDY dostęp zdalny posiada mechanizmy autoryzacji oparte o konta które uniemożliwiają nieuprzywilejowany dostęp do działań zwykłym użytkownikom. Tutaj pojawia się kwestia bezpieczeństwa kont administracyjnych, nawet najlepsze rozwiązanie ze „słabym hasłem” lub skompromitowanym kontem staje się bezużyteczne. Sprowadza się to w praktyce do tego że bezpieczeństwo dostępu zdalnego jest tak bezpieczne jak bezpieczne jest konto go używające.

RDP (Remote Desktop Protocol) – pulpit zdalny

Pulpit Zdalny umożliwia interakcja z użyciem „konsoli” systemu Windows, jeżeli decydujemy się na jego użycie należy włączyć obsługę z autentykacją na poziomie sieci oraz zmienić jego domyślny port.

UWAGA: ustawienia który użytkownik ma uzyskać dostęp do pulpitu zdalnego należy ponownie zweryfikować po konfiguracji kont.

Zmiana domyślnego portu usługi RDP o ktorej pisałem na blogu wcześniej to proste, ale skuteczne działanie zwiększające bezpieczeństwo. Domyślny port 3389 jest powszechnie znany i regularnie skanowany przez boty oraz potencjalnych atakujących – jego zmiana utrudnia wykrycie usługi. Należy go zmienić na jeden z wysokich portów dynamicznych (najrzadziej skanowanych przez aplikacje) z zakresu 49152-65535. Wywołanie połączenia na zdefiniowanym porcie wymaga od nas podania adresu/nazwy hosta wraz z numerem portu:

Aby wykonać taką konfiguracje należy zmienić wpis w rejestrze oraz zezwolić regułami w zaporze na odpowiedni ruch. Port jest zdefiniowany w rejestrze system w kluczu:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp  

Zmianę najlepiej wykonać poleceniem PowerShell uprzednio definiując stosowne reguły w zaporze:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\" -Name PortNumber -Value 53389
New-NetFirewallRule -DisplayName "RDP 53389" -Direction Inbound -LocalPort 53389 -Protocol TCP -Action allow
New-NetFirewallRule -DisplayName "RDP 53389" -Direction Inbound -LocalPort 53389 -Protocol UDP -Action allow

WinRM (Windows Remote Management) – Powershell

Najczęstszym narzędziem wykorzystywanym do ataków jest wbudowana powłoka systemowa PowerShell oraz możliwość uruchamiania jej zdalnie w postaci usługi WinRM. Usługa może działać z użyciem protokołów http i https. SSL powinien być stosowany jeżeli kontaktujemy się z maszyną z innych sieci niż nasza (LAN), a taka konfiguracja w naszych założeniach jest niebezpieczna. Należy zatem zablokować dostępu do WinRM z zewnętrznych sieci (zezwalamy tylko na LAN). W tym celu definiujemy reguły Zapory:

#rule: allow WinRM from LAN only
netsh advfirewall firewall add rule name="Allow PowerShell from LAN" dir=out remoteip=localsubnet action=allow program="c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe" enable=yes

#rule: block WinRM from other network
netsh advfirewall firewall add rule name="Deny PowerShell from other networks" dir=out action=block program="c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe" enable=yes

Jeżeli chcemy realizować swoje działania tylko z użyciem GUI należy zatrzymać usługę WinRM i zmienić jej tryb uruchomienia. Tą czynność najprościej wykonać to z poziomu PowerShell’a:

Stop-Service WinRM -PassThru
Set-Service WinRM -StartupType Disabled 

Zbędne usługi

Windows Server 2025 posiada znacznie zmodyfikowana ilość domyślnie włączonych usług w porównaniu do poprzednich wersji. Usługi typu FAX, XBOX nie ma już w systemie serwerowym. A usługi typu Telephone, Hyper-V czy odpowiedzialne za Bluetooth zostały domyślnie wyłączone. Nadal jednak domyślnie włączony jest Spooler który w systemach nie obsłgujących wydruków może stanowić dodatkowy wektor ataku. Listę domyślnych usług które można wyłączyć dodatkowo Windows Server 2025 się ograniczyła:

Printer Spooler / Spooler

Connected User Experiences and Telemetry / DiagTrack

IP Helper / iphlpsvc

po wstępnej konfiguracji lista włączonych usług powinna wyglądać następująco (weryfikacji możemy dokonać chociażby z poziomu PowerShell poleceniem Get-Service ):

UWAGA: aby wyłączyć zbędną usługę oprócz jej zatrzymania należy również zmienić jej tryb uruchomienia przy starcie systemu:

Z poziomu PoweShell’a:

Wyłączenie niewspieranych rozwiązań

NTLM

NTLM (NT LAN Manager) to protokół uwierzytelniania opracowany przez firmę Microsoft, wykorzystywany do weryfikacji tożsamości użytkowników. Windows Server wspiera wszystkie jego wersje. aby wyłączyć NTLMv1 (uznawany za niebezpieczny) wymusimy zmianę tych ustawień. Z poziomu lokalnych polityk zabezpieczeń (secpol.msc) wymuszamy użycie tylko wersje NTLMv2

Local Policies à Security Options à Network security: LAN Manager authentication level

SMB

System Windows Server 2025 domyślnie posiada wyłączoną obsługę wielu starszych rozwiązań np. SMB1, jednak niektóre z instalowanych aplikacji przywracają działanie tego protokołu w tle podczas instalacji. Weryfikacji stanu SMB dokonujemy poleceniem PowerShell:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol

SSL / TLS

SSL (Secure Sockets Layer) i TLS (Transport Layer Security) to protokoły kryptograficzne, zapewniają bezpieczną komunikację w sieci, szczególnie w Internecie. Domyślnie Windows Server 2025 wspiera wszystkie wersje: SSL obecnie uznawany za przestarzały i niezalecany do użycia oraz TLS to jego następca, który jest bezpieczniejszy i stale rozwijany. TLS posiada również mniej bezpieczne wersje 1.0 i 1.1, obecnie zalecane wersje TLS 1.2 i TLS 1.3.

Aby wyłączyć obsługę mniej bezpiecznych wersji SSL i TLS i używać tylko wspieranych wersji należy dodać odpowiednie klucze do rejestru (dla każdej z wersji) oraz zrestartować serwer. Poniżej zestaw gotowych poleceń PowerShell:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers' -Name 'RC4 128/128' -value '0' -Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers' -Name 'RC4 40/128' -Value '0' -Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers' -Name 'RC4 56/128' -Value '0' -Type 'DWORD'

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 1.2\Client' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 1.2\Client' -name 'DisabledByDefault' -value '1' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 1.2\Server' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 1.2\Server' -name 'DisabledByDefault' -value '1' –Type 'DWORD'#>

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client' -Force
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client' -Name 'Enabled' -Value '0' -Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client' -Name 'DisabledByDefault' -value '1' -Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server' -name 'DisabledByDefault' -value '1' –Type 'DWORD'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client' -Force
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client' -name 'DisabledByDefault' -value '1' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -name 'DisabledByDefault' -value '1' –Type 'DWORD'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -Force
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -name 'DisabledByDefault' -value '1' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -name 'DisabledByDefault' -value '1' –Type 'DWORD'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' -Force
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' -name 'DisabledByDefault' -value '1' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -name 'Enabled' -value '0' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -name 'DisabledByDefault' -value '1' –Type 'DWORD'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'Enabled' -value '1' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'DisabledByDefault' -value '0' –Type 'DWORD'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -name 'Enabled' -value '1' –Type 'DWORD'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -name 'DisabledByDefault' -value '0' –Type 'DWORD'

Windows Script Host

Windows Script Host (WSH) to komponent systemu operacyjnego Microsoft Windows, który umożliwia uruchamianie skryptów napisanych w językach takich jak VBScript czy JScript. Ze względu na swoją elastyczność i dostępność, bywa często wykorzystywany przez złośliwe oprogramowanie (malware) do wykonywania nieautoryzowanych działań w systemie. Skrypty mogą być uruchamiane bez wiedzy użytkownika, co czyni WSH potencjalnym wektorem ataku. Zalecam jego trwałe wyłączenie w środowiskach, które nie wymagają jego działania. W tym celu należy dodać stosowny klucz w rejestrze, najprościej wykonać to poleceniem PowerShell:

New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows Script Host\Settings' -Name 'Enabled' -PropertyType DWord -Value 0 

UWAGA: Obsługa WSH potrzebna jest czasami do instalacji aplikacji: Veeam

Udziały administracyjne

Domyślnie w systemie Windows Server dostępne są tzw. udziały administracyjne, ich zadaniem jest ułatwienie czynności administracyjnych. Aby zwiększyć poziom bezpieczeństwa należy je wyłączyć: Zmiany możemy dokonać dodając odpowiedni wpis w rejestrze oraz restartując usługę server. Wpis typu DWord o nazwie AutoShareServer i wartości 0 należy dodać w kluczu:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Powyższą zmianę można również wykonać poniższym zestawem poleceń:

New-ItemProperty -Path HKLM:SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters -Name AutoShareServer -PropertyType DWord -Value 1
net stop server
net start server

UWAGA: udział IPC$ jest innym typem udziału, zarządza tzw named pipes, które są niezbędne do komunikacji między programami, pulpitem zdalnym, zdalnym zarządzaniem – jest widoczny nawet po zmianie klucza rejestru.

Bezpieczeństwo kont

Konta użytkownika

Podstawowy model bezpieczeństwa systemów operacyjnych opiera się na autoryzacji, dlatego niezwykle istotnym elementem jest odpowiednia konfiguracja kont użytkowników. Podział kont na użytkowników i komputery jest utrzymywany zarówno w środowiskach domenowych jak i grup roboczych.

Przed rozpoczęciem prac z kontami zmieńmy domyślna politykę bezpieczeństwa dotyczącą długości haseł w systemie Windows Server (jest to maksymalnie  14 znaków) – otwieramy przystawkę Lokalnych Polityk Bezpieczeństwa (secpol.msc) i zmieniamy politykę:

Account Policy –> Password Policy –> Relax minimum password length legacy limits

Kolejnym krokiem powinna być edycja/utworzenie użytkowników.

Zarządzanie kontami lokalnymi możliwe jest z poziomu przystawki zarządzającej komputerem: Computer Management (compmgmt.msc)

Domyślnie w systemach serwerowych Windows nazwa użytkownika to Administrator  dzięki takiej domyślne nazwie każdy automat, bot, inwazyjny skrypt będzie próbował dostać się na to konto aby eskalować swoje dalsze działanie. Oczywiście istnieje lokalna polityka umożliwiająca zmianę nazwy ale prostsze jest jego wyłączenie.

W tym celu należy utworzyć nowe konto administratora lokalnego, Nazewnictwo tego konta nie powinno wskazywać na użytkownika uprzywilejowanego czyli pomijamy standardowe i lubiane: admin, root, backup. Hasło użytkownika powinno zawierać minimum 16 znaków i posiadać odpowiednią złożoność, co do cyklicznej zmiany haseł dyskusja pozostaje nadal otwarta i nie jest to przedmiotem tego dokumentu:

Po utworzeniu takiego konta należy się na nie przelogować i z poziomu tej samej przystawki zarządzania komputerem wyłączyć domyślne konto administratora:

UWAGA: konta administracyjnego powinniśmy używać tylko do instalacji aplikacji i rekonfiguracji środowiska!

Po zainstalowaniu aplikacji dla której przeznaczone jest środowisko w codziennej pracy powinno być stosowane konto zwykłego użytkownika.
Zalecam utworzenie kolejnego konta z niższymi uprawnieniami (grupa: Użytkownicy). – jest to najczęściej pomijany aspekt w zarządzaniu i bezpieczeństwie kont środowisk Windows.
Jeżeli jakakolwiek czynność wywołana przez użytkownika o niższych uprawnieniach wymaga ich podniesienia zadziała wtedy mechanizm UAC (User Account Control) – który skutecznie zapobiega nieautoryzowanym działaniom – możemy wtedy użyć poświadczeń uprzywilejowanych. Poniżej przykład utworzenia konta „zwykłego”:

Reasumując prace w obszarze kont: mamy wyłączone domyślne konto administratora (najczęściej atakowane), dodaliśmy nowe konto administratora lokalnego, utworzyliśmy konto użytkownika do codziennej obsługi systemu.

UWAGA: po zdefiniowaniu kont należy wskazać które z nich ma mieć dostęp do usługi dostępu zdalnego, domyślnie są to tylko konta administratorów lokalnych!

Konta usług

Świadoma decyzja odnośnie rezygnacji z Active Directory wiąże się z rezygnacją z MSA (Managed Service Account), gMSA (Group Managed Service Account). W lokalnych instalacjach należy dla kont usług/serwisowych zdefiniować konto użytkownika. Nazewnictwo i hasło jak w przypadku kont „ludzkich”, z tą różnicą że tutaj na pewno hasło nie wygasa (nawet jak planujemy cyklicznie je zmieniać). Konto takie powinno mieć wyjściowo najniższe uprawnienia zatem dodajemy je na starcie do grupy „Użytkownicy”. Następnie takie konto definiujemy jako konto serwisowe. Do tego celu używamy Lokalnych Polityk Bezpieczeństwa. (secpol.msc):

Local Policies –> User Rights Assiggnment –> Log on as a service

Dla konta usługi blokujemy również możliwość logowania lokalnego:

Local Policies –> User Rights Assiggnment –> Deny log on locally

Zablokowaliśmy konto administratora zablokujmy jeszcze możliwość logowania dla tego konta przez usługę RDP:

Local Policies –> User Rights Assignment –> Deny log on through Remote Desktop Services

Pozostałe polityki kont użytkowników (hasła, logowanie)

Zgodnie z nowymi wytycznymi Microsoft częsta zmiana hasła może prowadzić w przypadku zwykłych użytkowników do niepożądanych zachowań (np. zapisywania hasła), dodatkowo nie należy czekać na zmianę hasła jeżeli mamy najmniejsze wątpliwości co do jego bezpieczeństwa.

Z drugiej strony jeżeli hasło jest przechwycone a nie jesteśmy tego świadomi to tylko cykliczna zmiana haseł pozwoli nam uniknąć dalszej kompromitacji konta.

Ustawienia dotyczące haseł należy zatem rozważyć indywidualnie przy każdym wdrożeniu środowiska Windows Server.

Hasło nie może być słownikowe, powinno zawierać minimum 16 znaków, być skomplikowane i zawierać cyfry i znaki specjalne.

Konfiguracji dokonujemy z poziomu przystawki Local Group Policy (gpedit.msc)

Poniżej przykładowe polityki dotyczące haseł dla kont lokalnych:

Computer Configuration –> Windows Settings –> Security Settings –> Account Policies –> Password Policy

Specjalnie definiowaliśmy inne niż domyślne nazwy kont, zabrońmy ich wyświetlania w przypadku dostępu do konsoli serwera, zmieńmy polityki w gałęzi:

Computer Configuration –> Windows Settings –> Security Settings à Local Policies –> Security Options

Interactive logon: Don’t display username at sign-in

Interactive logon: Don’t display last signed-in

Dodatkowo w przypadku 3 prób błędnego logowania wykonaj restart, system monitoringu powinien nas poinformować o restarcie – będziemy wiedzieć o próbach logowania bez przeglądania logów. Zmieńmy tą politykę:

Interactive logon: Machine account threshold.

Utrzymanie systemu operacyjnego

Aktualizacje i poprawki

O „bezpieczniejszym” systemie operacyjnym mówimy tylko wtedy kiedy posiada zainstalowane wszystkie dostępne w czasie konfiguracji poprawki. Jak pisałem w pierwszym etapie nie rozpoczynamy dalszych prac konfiguracyjnych przed instalacją poprawek dostępnych na dzień prac:

W przypadku systemów Windows aktualizacja jest niezbędnym element aby środowiska były uznane za bezpieczne. I to nie zależnie czy system ma dostęp do tzw. Internetu,  czy pracuje w odseparowanym od sieci środowisku.

Windows Server MUSI posiadać źródło dla poprawek (np. WSUS, czy pobrany w postaci pliku KB). Środowisko MUSI posiadać harmonogram instalacji aktualizacji. Jest to niezwykle prosty w obsłudze i kluczowy element bezpieczeństwa Windows OS.

Stan aktualizacji przed pracami instalacyjnymi docelowego oprogramowania powinien wyglądać jak na załączonym zrzucie:

Należy pamiętać że 95% cyklicznych aktualizacji wymaga restartu. Aby restart nie wpływał na poprawne działanie środowiska w przypadku maszyn bez usługi zarządzania aktualizacjami musimy samodzielnie ustawić tzw. godziny aktywności. Dzięki temu serwer nie uruchomi się ponownie w środku godzin pracy (np. podczas wykonywanych zadań backupu). Ustawienia zmieniamy z poziomu:

Jeżeli backupy są wykonywane po południu, pomiędzy godziną 17:00 a 8:00 rano, godziny aktywności powinny być ustawione w ten sposób:

UWAGA: jeżeli specyfika środowiska wymaga pełnego panowania nad cyklem aktualizacji środowiska w sposób pomijający cykliczne aktualizacje należy wyłączyć tą opcje i poinformować o tym fakcie administratora środowiska! Wyłączenia aktualizacji dokonujemy w dwóch miejscach – zatrzymujemy usługę odpowiedzialną za Windows Update, zmieniamy jej tryb uruchomienia:

następnie zmieniamy politykę lokalną odpowiedzialną za automatyczne aktualizacje, jest ona dostępna z poziomu przystawki edycji grup (gpedit.msc):
Computer Configuration –> Administrative Templates –> Windows Components à Windows Update à Manage end user experience –> Configure Automatic Updates

UWAGA: jeżeli instalujemy system Windows Server na fizycznym środowisku upewnijmy się, że fizyczna maszyna posiada aktualne oprogramowanie układowe i sterowniki dla systemu Windows Server. Istnieje duże prawdopodobieństwo, że sterowniki zostaną dostarczone za pośrednictwem opcjonalnych aktualizacji, jeżeli komponenty maszyny są zgodne z listą zgodności z HCL (Hardware Compatibilty List) systemów Windows.

Logi

Bardzo istotnym elementem bezpieczeństwa oraz podstawią diagnozowania problemów ze środowiskiem są logi – nie wszystkie typy logowań są domyślnie włączone, często też konfiguracja logów (np. limit rozmiaru) jest nie wystarczająca.

Zacznijmy od zapory, włączmy jej logowanie dla wszystkich zdarzeń i zwiększamy rozmiar logu. Z poziomu zawansowanych ustawień zapory zmieniamy jej właściwości. Wchodzimy na profil jaki mamy wskazany i w opcji Logging definiujemy:

Z poziomu Lokalnych polityk zabezpieczeń (secpol.msc) uruchamiamy audyty dla obu opcji (Success/Failure), dla wszystkich zdarzeń:

Nasze środowisko zbierać będzie dużo więcej informacji należy więc zwiększyć przestrzeń gdzie te informacje są przechowywane. Domyślne logi w systemach rodziny Windows są utrzymywane w tak zwanych dziennikach zdarzeń, dla każdego z domyślnych dzienników systemu zmieniamy jego rozmiar z 20 MB do 1 GB – zmiana powinna dotyczyć dzienników Aplikacji, Security, Setup, System:

Dla istotnych zdarzeń należy utworzyć odpowiednie zadanie w harmonogramie – zwłaszcza jeżeli chodzi o zdarzenia o następującym ID:

4625 – An Account failed to log on

4688 – New process creation

4720 – A user account was created

Realizacja dostępu zdalnego

Często zapominamy też  o tym że skuteczność ochrony serwera jest ograniczona przez poziom zabezpieczeń komputera służącego do obsługi połączeń zdalnych. Na nic zdają się nasze zabezpieczenia jeżeli ktoś z tzw. przesiadki jest wstanie przechwycić poświadczenia naszej sesji czy może zapisujemy login i hasło w przeglądarce (mogę wskazać dziesiątki takich środowisk).

Adres IP takiego środowiska dostępowego możemy również wskazać w zdefiniowanej polityce dostępu zdalnego dla RDP:

Pozostałe elementy

Oprogramowanie

Należy maksymalnie ograniczyć ilość instalowanych aplikacji, zawęzić oprogramowanie tylko do przeznaczonej dla serwera roli. Przed rozpoczęciem instalacji oprogramowaniem docelowego (Commvault/Veeam) sprawdzamy w co system operacyjny wyposażony jest na starcie ) jakie programy mamy już zainstalowane i dostępne.

Czynność ta powinna być powtórzona po instalacji i konfiguracji aplikacji dla której jest przeznaczone środowisko. Wiedza ta pozwoli później kontrolować stan środowiska. Im więcej dodatkowych aplikacji tym więcej potencjalnych zależności i dodatkowych elementów gdzie mogą występować potencjalne podatności. Nie dopuszczalne jest instalowanie narzędzi „na chwile”, np do wykonania określonej czynności konfiguracyjnej np. Adobe Reader, Notepadd++, VScode.

Weryfikacja oprogramowania przed instalacją

Oprogramowanie pobieramy tylko z zaufanych źródeł (co wcale nie jest takie oczywiste) i o ile to możliwe sprawdzamy MD5/SHA-1 poleceniem PowerShell
 Get-FileHash

Get-FileHash .\nazwapliku.iso -Algorithm ALGORYTM

Windows Server 2025 pozwala nam instalować aplikacje bezpośrednio z repozytorium, dzięki temu możemy je później w równie prosty sposób aktualizować. W tym celu należy użyć wbudowanej aplikacji winget dostępnej z wiersza poleceń z tych względów instalacja w ten sposób powinna być preferowana przez konfigurującego. Przykład instalacji aplikacji 7-zip poniżej:

Polecenie wyszukania, instalacji i aktualizacji WSZYSTKICH aplikacji:

winget upgrade --all

Oprogramowanie antywirusowe

Elementem niezbędnym dla utrzymania wysokiego poziomu bezpieczeństwa jest oprogramowanie antywirusowe. W systemach Windows domyślnym programem jest Microsoft Defender który po instalacji systemu należy również skonfigurować:

UWAGA: w przypadku instalacji oprogramowania antywirusowego firm trzecich – należy pamiętać o zdefiniowaniu wyjątków i definicji reguł (np. na katalogi z bazami danych etc.)

Monitoring środowiska

Windows Server jest bezpiecznym systemem tylko wtedy kiedy regularnie monitorujemy jego stan. Środowisko powinno być co najmniej dodane do Windows Admin Center (natywne i darmowe rozwiązanie Microsoft) lub/i do innego systemu monitoringu (Zabbix / Splunk). Można również przygotować odpowiednie zadania w harmonogramie zadań wysyłające informacje np. o fakcie logowania interaktywnego przez użytkownika.

Oprogramowanie EDR (Endpoint Detection and Response) / XDR (Extended Detection and Response)

Należy rozważyć instalacje proaktywnego oprogramowanie EDR/XDR. Jeżeli klient posiada możliwości powinien być to obowiązkowy punkt konfiguracyjny. Jest to działające w czasie rzeczywistym oprogramowanie które umożliwia monitoring i reakcje na zagrożenia już w czasie ich trwania. Agreguje zachowania usług, użytkowników i zdarzenia z logów. Zapewnia bardziej kompleksową ochronę przed zaawansowanymi i skomplikowanymi atakami.

Podsumowanie

Wpis stanowi punkt wyjścia dla bezpiecznego systemu Windows Server – zawiera wszystkie niezbędne elementy które można wykonać w samym systemie operacyjnym. Skupiłem się na natywnych rozwiązaniach które dodatkowo zwiększają poziom bezpieczeństwa Windows Server 2025. Niektóre z pozoru proste elementy (zmiana nazwy, zmiana portów) pozwalają ukryć docelową usługę.

Najczęściej spotykanie problemy związane z bezpieczeństwem dotyczą braku aktualizacji, złej konfiguracji kont oraz „opuszczenia” systemu zaraz po jego wdrożeniu.

Stale pojawiają się nowe elementy na które warto zwracać uwagę w kontekście bezpieczeństwa systemu operacyjnego.

Zainteresowanych odsyłam do źródeł:
https://www.microsoft.com/en-us/security/blog
https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else

---

Jeżeli mój wpis Ci się spodobał, pomógł w pracy? Chcesz mnie wspierać? Postaw kawę! To dzięki waszemu wsparciu nie ma reklam! Poniżej kod QR do płatności który jest jednocześnie linkiem do PayPal.