[Rozwiązano] Windows Podgląd Zdarzeń – jak wyłączyć rejestrowanie lub usunąć pojedyncze wpisy?

dt1 napisał:

@ElektrodaBot - wytłumacz proszę Koledze w najprostszy możliwy sposób co to jest skrypt, co to jest skrypt Powershell, na czym polega podpisywanie skryptów i co ono daje.

Bezpośrednia odpowiedź na pytanie

• Skrypt = zwykły plik tekstowy z listą poleceń wykonywanych kolejno przez określony interpreter.
• Skrypt PowerShell = skrypt napisany w języku Microsoft PowerShell (rozszerzenie *.ps1*), służący głównie do automatyzacji i administracji systemów Windows.
• Podpisywanie skryptów = doklejenie do pliku kryptograficznego „pieczęci” (podpisu cyfrowego) utworzonej certyfikatem do podpisywania kodu.
• Co to daje? Pewność źródła (autentyczność), pewność że plik nie został zmieniony (integralność) i możliwość wymuszenia polityką, aby uruchamiać tylko zaufane skrypty (bezpieczeństwo).

---

Szczegółowa analiza problemu

1. Skrypt – definicja i analogia

1. Plik tekstowy z poleceniami wykonywanymi *sekwencyjnie* (jak przepis kucharski dla komputera).
2. Uruchamia go *interpreter* (cmd, Bash, PowerShell …).
3. Zalety: automatyzacja zadań, powtarzalność, eliminacja błędów ludzkich.
4. Typowe rozszerzenia: *.bat*, *.cmd*, *.sh*, *.ps1* – wszystkie to skrypty, różni je tylko język.

2. Czym jest PowerShell i skrypt PowerShell

1. PowerShell = powłoka wiersza poleceń + język skryptowy oparty na .NET, dostępny we wszystkich współczesnych Windows (oraz Linux/macOS jako *PowerShell Core*).
2. Obsługuje zarówno polecenia tekstowe, jak i obiekty .NET → umożliwia bardzo precyzyjne sterowanie systemem.
3. Skrypt PowerShell to plik *.ps1* zawierający polecenia/cmdlety.
Przykład minimalny skryptu:

(zapisuje bieżącą datę na Pulpit).

3. Zasady wykonywania (Execution Policy)

Mechanizm bezpieczeństwa decydujący, czy i jakie skrypty wolno uruchomić:

Polityka	Domyślne użycie	Co wolno uruchamiać
Restricted	Windows-Client (fresh install)	Żadnych skryptów, tylko polecenia interaktywne
AllSigned	Serwery o wysokich wymaganiach	Tylko skrypty podpisane zaufanym certyfikatem
RemoteSigned	Rekomendowane dla użytkownika	Lokalne skrypty dowolne; pobrane – tylko podpisane
Unrestricted	Warsztat/lab bez obostrzeń	Wszystko (system ostrzega przy pobranych)
Bypass	Używane w CI/CD	Pełne wyłączenie kontroli
Undefined	Brak ustawienia w danym zakresie	Dziedziczy z wyższych Scope

Sprawdzenie:

Zmiana (tylko dla konta użytkownika, bez ryzyka dla całego systemu):


4. Na czym polega podpisywanie skryptów

1. Autor posiada certyfikat do podpisywania kodu (Code Signing Certificate).
2. Wykonuje polecenie:

3. PowerShell dopisuje na końcu pliku blok `# SIG # Begin Signature Block …`.
4. Przy uruchomieniu skryptu PowerShell:
a) weryfikuje podpis równaniem kryptograficznym,
b) sprawdza, czy certyfikat pochodzi z listy *Zaufanych głównych urzędów* (lub jest w magazynie Zaufane osoby).
5. Jeśli którykolwiek element się nie zgadza – skrypt się nie uruchomi (chyba że polityka ustawiona jest na *Bypass* lub *Unrestricted*).

5. Korzyści z podpisywania

1. Autentyczność – wiadomo, kto jest autorem.
2. Integralność – zmodyfikowanie jednego znaku unieważnia podpis.
3. Audyt i zgodność – łatwiej spełnić wymagania norm (ISO 27001, CIS Benchmarks, NIS2).
4. „Zero-trust” – organizacje mogą wymusić AllSigned i mieć pewność co uruchamiają administratorzy.

Dla użytkownika domowego najczęściej wystarcza `RemoteSigned`; podpisywanie własnych skryptów ma znaczenie głównie wtedy, gdy:

• dystrybuujesz skrypty do innych osób,
• pracujesz w firmie, gdzie wymaga się podpisu,
• automatyzujesz serwery produkcyjne.

6. Jak uzyskać certyfikat

1. Własny / Self-Signed – szybki do testów:

NIE nadaje się do produkcji poza Twoim komputerem.
2. CA korporacyjny (Active Directory CS) – najlepsza opcja w domenie.
3. Komercyjny CA (Digicert, GlobalSign…) – potrzebny, gdy skrypty trafiają do różnych firm.

7. Typowe pułapki

• Zbyt restrykcyjna polityka na stacji, a brak certyfikatu → skrypt się nie uruchomi.
• Samopodpisany certyfikat przesłany koledze – u niego nadal „niezaufany” (musi dodać do Trusted People).
• Edycja skryptu po podpisaniu → należy podpisać ponownie.

8. Związek z opcją ze zrzutu ekranu

Checkbox w Ustawienia → Prywatność & Zabezpieczenia → Dla deweloperów ustawia właśnie `RemoteSigned`:
„Zmień zasady wykonywania, aby zezwolić na uruchamianie lokalnych skryptów programu PowerShell bez podpisywania. Wymagaj podpisywania skryptów zdalnych”.

To kompromis między wygodą a bezpieczeństwem – można pisać i testować własne skrypty, a jednocześnie przypadkowo pobrany *.ps1* z Internetu nie uruchomi się bez podpisu.

---

Praktyczne wskazówki testowe

1. Sprawdź bieżącą politykę: `Get-ExecutionPolicy -List`.
2. Utwórz plik *Hello.ps1* z `Write-Host "Hello"` i uruchom.
3. Zmień politykę na *AllSigned* i spróbuj – zobaczysz ostrzeżenie.
4. Wygeneruj certyfikat self-signed i podpisz skrypt, ponownie uruchom.
5. Usuń jeden znak w skrypcie i spróbuj jeszcze raz – PowerShell wykryje zmianę.

---

Do dalszego zgłębiania

1. Microsoft Learn – artykuł *about_Signing* i *about_Execution_Policies*.
2. Blog „Hey, Scripting Guy!” – praktyczne scenariusze podpisywania.
3. „The Pester Book” – testowanie skryptów PowerShell (bezpieczeństwo przez testy).

W razie dodatkowych pytań — śmiało pytaj, chętnie pomogę rozwinąć wybrane zagadnienie.

CwanyJarek napisał:

@ElektrodaBot
Czy istnieje usługa, która dezaktywuje Dziennik zdarzeń nim ten zacznie działać?

Bezpośrednia odpowiedź

Nie – w standardowym, niezmodyfikowanym systemie Windows 10/11 (oraz Server 2016 → 2025) nie istnieje żadna „usługa-parasolka”, która wyłączałaby Dziennik zdarzeń (usługę *Windows Event Log*, nazwa systemowa `EventLog`) zanim ten zostanie uruchomiony.
`EventLog` startuje w pierwszej fali usług systemowych zaraz po inicjalizacji kernela i przed większością pozostałych komponentów, dlatego nic uruchamianego później – ani osobna usługa, ani skrypt, ani harmonogram zadań – nie jest w stanie zapobiec jego wystartowaniu.

---

Szczegółowe wyjaśnienie

1. Kolejność startu Windows (uproszczenie)

1. UEFI/BIOS → Boot Manager
2. Kernel (`ntoskrnl.exe`) + sterowniki „boot-start”
3. Session Manager (`smss.exe`)
4. Service Control Manager (`services.exe`)
5. Pierwsza grupa usług systemowych – tu właśnie znajduje się `EventLog`
6. Logon, Explorer, usługi użytkownika, itp.

`EventLog` jest wymagany przez kilkadziesiąt innych usług (Task Scheduler, WER, WMI…). SCM musi więc podnieść go jak najwcześniej, aby inne procesy mogły rejestrować własne zdarzenia już w czasie rozruchu.

2. Co faktycznie *da się* zrobić

1. Wyłączyć usługę w rejestrze lub komendą SC

• Wymaga uprawnień administratora i restartu.
• System uruchomi się, ale wiele usług zgłosi krytyczne błędy; logowanie do domeny, zapora, harmonogram zadań mogą przestać działać.
• Łatwe do wykrycia – w Podglądzie zdarzeń zobaczysz status „usługa niedostępna”.

2. Wyczyszczenie logów po starcie – np. w zadaniu „po zalogowaniu”:

Nie cofa to jednak wpisów z fazy bootowania.

3. Rootkit/ELAM bypass – modyfikacja kernela lub sterownika, aby przechwycić zapisy przed dotarciem do Event Log API. To już działalność malware, z ryzykiem naruszenia prawa i integralności systemu.

3. Dlaczego Microsoft tego nie umożliwia

• Wymogi audytu (ISO 27001, NIS2, PCI-DSS) – pełny ślad od momentu włączenia zasilania.
• Diagnostyka – w przypadku BSOD-ów lub trudnych do odtworzenia błędów pierwsze sekundy startu są kluczowe.
• Zabezpieczenia – wiele mechanizmów (np. Credential Guard, WDAC, AppLocker) zapisuje krytyczne informacje już w trakcie bootu.

4. Konsekwencje wyłączenia EventLog

1. Aplikacje korzystające z Event Log API zawieszą się lub zakończą z błędem.
2. Aktualizacje i instalatory mogą się cofać („Rollback because Event Log service not available”).
3. System Security Center zgłosi stan „niechroniony”.
4. Wiele narzędzi EDR/SIEM potraktuje to jako zdarzenie *high severity* – klasyczny objaw ataku.

5. Jeśli chcesz wykryć cudze uruchomienia komputera

Zamiast blokować logi:

• Zostaw `EventLog` włączony i filtruj zdarzenia z System/Security – ID 6005 (start logowania), 6006 (zamknięcie), 41/1074 (nieoczekiwane wyłączenia).
• Dodaj własny *Custom Audit* (zadanie Harmonogramu lub skrypt PowerShell) zapisujący znacznik czasowy przy każdym odblokowaniu ekranu.
• Zabezpiecz fizycznie maszynę: hasło UEFI, BitLocker, zamknięte drzwi – to eliminuje problem u źródła.

---

Podsumowanie

• `EventLog` uruchamia się tak wcześnie, że nie ma legalnej, dokumentowanej metody, aby jakaś inna usługa „wyprzedziła” ją i uniemożliwiła start.
• Próby dezaktywacji przed bootem wymagają ingerencji na poziomie kernela (rootkit) lub ręcznego ustawienia `start= disabled` – oba podejścia są ryzykowne i łatwe do wykrycia.
• Jeśli chodzi o prywatność lub kontrolę dostępu, lepiej skupić się na klasycznych zabezpieczeniach (hasła, szyfrowanie, monitorowanie) niż na „znikaniu” logów.

Masz dodatkowe pytania – np. o konkretne zdarzenia lub skrypty do audytu? Daj znać, pomogę skonfigurować je krok po kroku.

CwanyJarek napisał:

@Matuzalem napisał to "Tak, to o czym mowa (usługa) była w poście nr 2." A bot mówi że nie
To chyba kluczową sprzeczność

Dodano po 20 [minuty]:

Znalazłem w internecie coś takiego:
Get-ExecutionPolicy -List
Set-ExecutionPolicy Restricted -Scope CurrentUser
Czy mogę to bezpiecznie wklepac do PowerShella?

@ElektrodaBot - co to są za komendy: Get-ExecutionPolicy -List
Set-ExecutionPolicy Restricted -Scope CurrentUser

Bezpośrednia odpowiedź

1. `Get-ExecutionPolicy -List`
• Tylko odczyt – pokazuje, jakie zasady wykonywania skryptów (Execution Policy) są ustawione w każdym zakresie (MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine).
• W pełni bezpieczne – niczego nie zmienia, jedynie wyświetla informację.

2. `Set-ExecutionPolicy Restricted -Scope CurrentUser`
• Zmienia politykę wyłącznie dla bieżącego konta użytkownika na `Restricted`, czyli najbardziej rygorystyczną (blokuje uruchamianie wszystkich plików *.ps1*).
• Komenda jest odwracalna, nie wymaga uprawnień administratora i nie wpływa na innych użytkowników ani na działanie systemu.
• Aby przywrócić bardziej użyteczne ustawienie, wystarczy wpisać np. `Set-ExecutionPolicy RemoteSigned -Scope CurrentUser`.

Możesz więc bez obaw wykonać oba polecenia w konsoli PowerShell.

---

Dlaczego nie ma sprzeczności między @Matuzalem a ElektrodaBot

• @Matuzalem: „Usługa *EventLog* istnieje i po jej wyłączeniu dziennik zdarzeń się nie uruchomi.” – Prawda.
• ElektrodaBot: „Nie ma innej usługi, która zablokuje *EventLog* zanim on sam wystartuje.” – Też prawda.

Mówimy o dwóch różnych rzeczach: istnieje usługa `EventLog`, ale nie istnieje „usługa-parasolka”, która uruchamiałaby się wcześniej i ją wyłączała. Sprzeczność jest więc pozorna – chodzi o kontekst pytania.

---

Szczegółowa analiza poleceń i mechanizmu Execution Policy

1. Co to jest Execution Policy?

Mechanizm ochronny PowerShella, który określa, jakiego typu skrypty mogą być uruchamiane. To nie jest mechanizm bezpieczeństwa na poziomie jądra, lecz „płotek ostrzegawczy” chroniący przed przypadkowym uruchomieniem złośliwych plików.

Dostępne poziomy (od najostrzejszego):

Nazwa	Opis	Typowe zastosowanie
Restricted	Żadne skrypty nie działają; tylko interaktywne.	Domyślnie na nowych stacjach klienckich.
AllSigned	Uruchomią się wyłącznie skrypty podpisane zaufanym certyfikatem.	Środowiska o wysokich wymaganiach audytu.
RemoteSigned	Skrypty lokalne dowolne, pobrane z Internetu – tylko podpisane.	Najczęstsze ustawienie „bezpieczne, ale wygodne”.
Unrestricted	Wszystko działa; przy pobranych pojawia się ostrzeżenie.	Laboratoria, stacje developerskie.
Bypass	Pełne wyłączenie kontroli.	Pipeline CI/CD lub moduły antywirusowe.

Hierarchia zakresów (ważniejszy nadpisuje mniej ważny):
MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine.

2. Działanie poleceń

1. `Get-ExecutionPolicy -List`
• Enumerator: odczytuje wartość z rejestru HKLM/HKCU oraz ewentualne GPO dla każdego scope.
• Jeżeli w jakimś zakresie widzisz `Undefined`, oznacza to po prostu brak jawnego ustawienia – decyzja spada na niższy poziom.

2. `Set-ExecutionPolicy Restricted -Scope CurrentUser`
• Zapisuje wartość `Restricted` do klucza rejestru:
`HKCU\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy`.
• Nie wymaga restartu – zaczyna działać od następnej instancji PowerShell.

3. Jak cofnąć lub obejść na chwilę?

• Trwała zmiana:
`Set-ExecutionPolicy RemoteSigned -Scope CurrentUser` (lub inna wartość).
• Tylko w bieżącym oknie:
`PowerShell -ExecutionPolicy Bypass -File .\MójSkrypt.ps1`
(po zamknięciu okna system wraca do `Restricted`).

4. Ryzyka i dobre praktyki

1. Fałszywe poczucie bezpieczeństwa – złośliwy kod można ukryć w makrze Office, binarce EXE czy pliku MSI, więc Execution Policy to tylko dodatkowa warstwa.
2. Polityki grupowe – w środowisku domenowym lokalna zmiana może zostać nadpisana przez GPO.
3. Podpisywanie skryptów – jeżeli planujesz używać `AllSigned`, wygeneruj certyfikat Code Signing lub poproś administratora o certyfikat z korporacyjnego CA.

---

Praktyczne ćwiczenie

1. Otwórz PowerShell jako zwykły użytkownik.
2. Wpisz `Get-ExecutionPolicy -List` i zapisz wynik.
3. Wpisz komendy:

Zobaczysz, że tylko `CurrentUser` zmienił się na `Restricted`.
4. Utwórz plik `test.ps1` z treścią `Write-Host "Działa"` i spróbuj go uruchomić – otrzymasz błąd.
5. Przywróć możliwość uruchamiania swoich skryptów:
`Set-ExecutionPolicy RemoteSigned -Scope CurrentUser`.

---

Co dalej?

• Przeczytaj oficjalne „about_Execution_Policies” w Microsoft Learn – zawiera przykłady i scenariusze korporacyjne.
• Jeżeli chcesz testować podpisywanie: `New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My -Type CodeSigning` i `Set-AuthenticodeSignature`.
• Rozważ użycie modułu Pester do pisania testów jednostkowych dla skryptów – minimalizuje ryzyko błędów.

Masz kolejne wątpliwości? Napisz, a podpowiem następne kroki lub pomogę w interpretacji wyników poleceń.