Scenariusz 1: Zabbix na LAN — wszystko w jednej sieci

To najprostszy i najczęstszy model. Serwer Zabbix stoi w tej samej sieci co monitorowane hosty. Agenty na serwerach raportują bezpośrednio do serwera Zabbix, który zbiera dane, przetwarza triggery, wysyła alerty i wyświetla dashboardy.

Jak to wygląda w praktyce

[Host 1] ──┐
[Host 2] ──┤── LAN ──── [Zabbix Server + Frontend + DB]
[Host 3] ──┘

Serwer Zabbix odpytuje agentów (passive checks) lub agenty same wysyłają dane (active checks). Wszystko dzieje się w jednym segmencie sieci. Nie ma firewalli po drodze, nie ma NAT-u, nie ma opóźnień WAN.

Konfiguracja

Minimalna. Instalujesz serwer Zabbix, stawiasz bazę (PostgreSQL lub MySQL), wdrażasz agentów na hostach. W zabbix_agentd.conf ustawiasz:

ini

Server=192.168.1.10          # IP serwera Zabbix (passive checks)
ServerActive=192.168.1.10    # IP serwera Zabbix (active checks)
Hostname=web-server-01       # unikalna nazwa hosta

I gotowe. Agent raportuje, serwer zbiera. Żadnego proxy, żadnych tuneli, żadnych komplikacji.

Zalety

• Prostota — jeden serwer, jedna baza, jedna instancja do zarządzania.
• Niskie opóźnienia — dane z agentów trafiają do serwera natychmiast, bo wszystko jest na LAN-ie.
• Passive i active checks bez ograniczeń — serwer ma bezpośredni dostęp do agentów, więc działają oba tryby. Możesz korzystać z remote commands do automatycznego restartowania usług.
• SNMP, IPMI, HTTP bez problemów — serwer odpytuje urządzenia sieciowe bezpośrednio, bez pośredników.
• Łatwy troubleshooting — jedna maszyna, jeden log, jedno miejsce do sprawdzenia.

Wady

• Skala ograniczona do jednej lokalizacji — jeśli masz drugi oddział albo sieć klienta, ten model nie wystarczy.
• Brak redundancji — padnie serwer Zabbix, padnie monitoring. W małych środowiskach to akceptowalne, w większych — nie.
• Brak separacji — serwer Zabbix widzi wszystko i ma dostęp do wszystkiego. W kontekście bezpieczeństwa i segmentacji sieci to niekoniecznie pożądane.

Kiedy stosować

Jedna firma, jedna serwerownia, jeden LAN. Monitorujesz swoje serwery, switche, NAS-y, UPS-y. Masz pełną kontrolę nad siecią. Nie musisz monitorować niczego zdalnie. To scenariusz dla 80% małych i średnich wdrożeń.

Scenariusz 2: Zabbix z active proxy u klienta

Tu zaczyna się ciekawiej. Masz centralny serwer Zabbix — np. w swoim DC albo na VPS-ie. Klient ma swoją sieć, za NAT-em, za firewallem, do której nie masz (i nie chcesz mieć) bezpośredniego dostępu. U klienta stawiasz Zabbix proxy w trybie active. To proxy inicjuje wszystkie połączenia do serwera — serwer nigdy nie łączy się do proxy. Serwer nawet nie musi znać IP proxy.

W tym modelu Serwer zabixa sam nigdy nie komunikuje się z Proxy u klienta. To Proxy wysyła dane na ip serwera w świat (czśto na wysokim porcie), a jeśli np firewall na serwerze przyjmuje dane tylko z podanych ip to to jest najbezpieczeniejsze co można wymyślić poza VPN .

Jak to wygląda w praktyce

Sieć klienta (za NAT/firewall):                    Twój DC:
┌──────────────────────────┐                ┌──────────────────┐
│ [Host 1] ──┐             │                │                  │
│ [Host 2] ──┤── LAN ── [Zabbix Proxy] ──────────► [Zabbix Server]  │
│ [Host 3] ──┘   (active)  │   port 10051   │  + Frontend + DB │
│ [Switch] ──┘             │                │                  │
└──────────────────────────┘                └──────────────────┘
         ← proxy inicjuje połączenie →
         ← serwer NIE łączy się do proxy →

Kluczowa sprawa: active proxy sam puka do serwera. Pobiera konfigurację (jakie hosty monitorować, jakie itemy zbierać) i odsyła zebrane dane. Serwer nie musi mieć routingu do sieci klienta. Firewall u klienta musi przepuścić tylko jeden port wychodzący (domyślnie 10051 TCP) do serwera Zabbix.

Konfiguracja proxy

Na maszynie u klienta instalujesz Zabbix proxy. W zabbix_proxy.conf:

ini

ProxyMode=0                          # 0 = active (domyślne)
Hostname=klient-abc-proxy            # musi się zgadzać z nazwą w frontendzie
Server=zabbix.twojafirma.pl:10051   # adres Twojego serwera Zabbix
DBName=/tmp/zabbix_proxy.db          # SQLite wystarczy dla małych wdrożeń
ConfigFrequency=120                  # co ile sekund pobierać konfigurację
DataSenderFrequency=5                # co ile sekund wysyłać dane
ProxyOfflineBuffer=72                # ile godzin trzymać dane przy braku łączności

Na frontendzie serwera Zabbix: Administration → Proxies → Create proxy — wpisujesz nazwę klient-abc-proxy, tryb Active. Nie musisz podawać żadnego IP proxy.

Konfiguracja agentów u klienta

Agenty wskazują na lokalne IP proxy, nie na serwer Zabbix:

ini

Server=192.168.10.50           # IP proxy w sieci klienta
ServerActive=192.168.10.50     # IP proxy w sieci klienta
Hostname=klient-abc-dc01       # unikalna nazwa hosta

Agent nie wie, że rozmawia z proxy a nie z serwerem — protokół jest identyczny.

Przepływ danych

1. Proxy → Serwer: Proxy łączy się z serwerem co ConfigFrequency sekund i pobiera konfigurację (lista hostów, itemów, triggerów do monitorowania).
2. Agenty → Proxy: Agenty w sieci klienta raportują dane do proxy (LAN, bez wychodzenia na zewnątrz).
3. Proxy → Serwer: Proxy buforuje dane lokalnie i wysyła je do serwera co DataSenderFrequency sekund.
4. Serwer przetwarza: Triggery, eventy, alerty — to wszystko dzieje się na serwerze. Proxy jest tylko kolektorem danych.

Serwer nigdy nie inicjuje połączenia do proxy. Proxy puka do serwera. To fundamentalna różnica, która rozwiązuje problem NAT-u, firewalli i braku bezpośredniego dostępu do sieci klienta.

Co się dzieje, gdy padnie łącze?

Proxy buforuje dane lokalnie. Parametr ProxyOfflineBuffer (domyślnie 1 godzina) określa, jak długo proxy trzyma dane, gdy nie może połączyć się z serwerem. Ustawiasz np. 72 godziny — i proxy przeżyje weekend bez łączności. Gdy połączenie wróci, proxy wyśle zaległe dane i serwer je przetworzy.

W trybie ProxyBufferMode=hybrid (od Zabbix 7.0) proxy trzyma dane w pamięci dla szybkości, a gdy pamięć się zapełni — zrzuca na dysk. Najlepsze z obu światów.

Zalety

• Firewall-friendly — jedyne wymaganie: port wychodzący z proxy do serwera. Żadnych portów przychodzących u klienta, żadnego VPN-a, żadnego otwierania dziur.
• Serwer nie ma dostępu do sieci klienta — i to jest feature, nie bug. Separacja jest pełna. Serwer nie może skanować sieci klienta, nie może łączyć się z hostami. Dane płyną tylko w jedną stronę: od proxy do serwera.
• Buforowanie offline — awaria łącza nie oznacza utraty danych. Proxy trzyma metryki lokalnie i dosyła je po przywróceniu połączenia.
• Skalowalność — jeden serwer Zabbix, dziesiątki proxy u różnych klientów. Każde proxy zbiera dane ze swojego segmentu, serwer centralizuje wszystko.
• Odciążenie serwera — proxy wykonuje preprocessing danych i skanowanie sieci (discovery) lokalnie. Serwer dostaje gotowe dane.
• Prosta konfiguracja sieciowa — nie musisz znać publicznego IP proxy, nie musisz konfigurować port forwarding u klienta. Proxy samo się łączy.

Wady

• Brak remote commands — serwer nie może wysłać komendy do hosta przez active proxy, bo nie ma do niego bezpośredniego połączenia. Od Zabbix 7.0 active agent potrafi odbierać remote commands, ale wymaga to dodatkowej konfiguracji.
• Opóźnienie w danych — dane nie trafiają na serwer natychmiastowo. Jest bufor, jest DataSenderFrequency. W praktyce opóźnienie to kilka sekund, ale nie jest zerowe.
• Opóźnienie w konfiguracji — po zmianie itemów na serwerze proxy musi pobrać nową konfigurację. Domyślnie ConfigFrequency=3600 (1 godzina!). Warto zmniejszyć do 120-300 sekund. Można też wymusić ręcznie: zabbix_proxy -R config_cache_reload.
• Dodatkowy komponent — proxy to kolejna maszyna do utrzymania, kolejna baza danych, kolejny serwis do monitorowania (tak — monitoruj swoje proxy).
• Brak passive checks z serwera — serwer nie może odpytać agenta przez proxy w trybie active. Agenty muszą pracować w trybie active checks.

Kiedy stosować

Monitorujesz infrastrukturę klientów jako usługę (MSP/MSSP). Masz wiele oddziałów za NAT-em. Klient nie chce (słusznie) otwierać VPN-a do Twojego serwera. Potrzebujesz centralnego dashboardu dla wielu lokalizacji. Chcesz separacji — serwer nie powinien mieć dostępu do sieci klienta.

Porównanie: LAN vs Active Proxy

Cecha	Zabbix na LAN	Zabbix + Active Proxy
Złożoność wdrożenia	Niska	Średnia
Firewall/NAT	Nie przeszkadza	Rozwiązany — proxy łączy się na zewnątrz
Serwer ma dostęp do sieci klienta	Tak (pełny)	Nie (zero)
Kierunek połączenia	Serwer Agent	Proxy → Serwer (jednokierunkowy)
Passive checks	Tak	Nie (tylko active)
Remote commands	Tak	Ograniczone
Buforowanie offline	Nie	Tak (do 72h+)
Skalowalność lokalizacji	Jedna	Wiele
Opóźnienie danych	Brak	Kilka sekund
Koszt	1 serwer	1 serwer + N proxy
Monitoring SNMP/IPMI	Bezpośredni z serwera	Przez proxy (lokalnie)

Który model wybrać?

To nie jest kwestia „lepszy/gorszy”. To kwestia kontekstu.

Jeśli monitorujesz swoją infrastrukturę, w jednej lokalizacji, na jednym LAN-ie — stawiasz serwer Zabbix i nie komplikujesz sobie życia. Proxy jest zbędne.

Jeśli monitorujesz infrastrukturę klientów, zarządzasz wieloma lokalizacjami, albo potrzebujesz monitoringu bez VPN-a i bez otwierania portów u klienta — active proxy to jedyna sensowna droga. Proxy puka do Twojego serwera, wysyła dane, a serwer nigdy nie widzi sieci klienta. Bezpiecznie, skalowalne, firewall-friendly.

W praktyce oba modele mogą współistnieć. Serwer Zabbix monitoruje lokalny LAN bezpośrednio, a jednocześnie odbiera dane z proxy rozsianych po lokalizacjach klientów. To nie jest albo-albo — to kwestia dopasowania architektury do potrzeb.

Artykuł Zabbix na LAN vs Zabbix Proxy – dwa modele, które warto znać pochodzi z serwisu Z IT Wzięte.

Ustawiasz uprawnienia na folderach QNAP, wszystko działa, a na drugi dzień znowu masz problem z dostępem? Użytkownicy nie mogą zapisywać plików do folderów, w których wczoraj jeszcze mogli? Klasyczny scenariusz – ustawiasz RW na Folder, wychodzisz, wracasz rano i uprawnienia wróciły do stanu wyjściowego.

Zanim zaczniesz resetować NAS-a, przeinstalowywać firmware albo grzebać w ACL-ach – sprawdź crontab. Bardzo prawdopodobne, że winowajcą jest systemowe zadanie ImR_all, które co noc nadpisuje Twoje uprawnienia.

Co to jest ImR_all i dlaczego psuje uprawnienia

W domyślnej konfiguracji QNAP w crontabie znajdziesz wpis:

0 3 * * * /usr/local/sbin/ImR_all -soft /Qmultimedia

To zadanie uruchamia się codziennie o 3:00 w nocy i wykonuje „miękki” reset indeksowania oraz uprawnień na folderze /Qmultimedia (alias do /share/MD0_DATA/Multimedia). Jest to element systemu Multimedia Console, który odpowiada za indeksowanie plików multimedialnych – zdjęć, filmów, muzyki.

Problem polega na tym, że ImR_all potrafi nadpisać uprawnienia, które ręcznie ustawiłeś na folderach i podfolderach w obrębie Multimedia. Efekt – Twoje niestandardowe ACL-e i ustawienia dostępu wracają do stanu „domyślnego” każdej nocy.

Objawy problemu

Jeśli widzisz którykolwiek z tych objawów, prawdopodobnie ImR_all jest winowajcą:

• Uprawnienia na folderze Multimedia resetują się po nocy
• Użytkownicy tracą dostęp do podfolderów, który dzień wcześniej działał
• Zmiana uprawnień w panelu QTS nie „trzyma się” dłużej niż kilka godzin
• W File Station lub przez SMB nagle pojawia się „Access Denied” na folderach, które wcześniej były dostępne
• Po ręcznym ustawieniu uprawnień przez SSH (chmod, setfacl) zmiany znikają następnego dnia

Rozwiązanie – wyłączenie ImR_all w crontabie

Rozwiązanie jest proste – trzeba zakomentować lub usunąć wpis ImR_all z crontaba. Wymaga to dostępu SSH do NAS-a.

Krok 1: Włącz SSH na QNAP

1. Zaloguj się do panelu QTS jako administrator
2. Przejdź do Panel sterowania → Usługi sieciowe i plików → Telnet/SSH
3. Zaznacz Zezwalaj na połączenie SSH
4. Ustaw port (domyślnie 22, ale rozważ zmianę na niestandardowy, np. 2222, jeśli NAS jest dostępny z internetu)
5. Kliknij Zastosuj

Krok 2: Połącz się z NAS przez SSH

Z komputera z Windows użyj PuTTY lub wbudowanego terminala:

bash

ssh admin@ADRES_IP_QNAP

Na macOS / Linux po prostu otwórz terminal i wpisz powyższe polecenie. Zaloguj się danymi administratora QNAP.

Krok 3: Zrób backup crontaba

Zanim cokolwiek zmienisz – kopia zapasowa:

bash

cp /etc/config/crontab /etc/config/crontab.backup

Krok 4: Edytuj crontab

Otwórz plik crontaba w edytorze:

bash

vi /etc/config/crontab

Znajdź linię:

0 3 * * * /usr/local/sbin/ImR_all -soft /Qmultimedia

Zakomentuj ją, dodając # na początku linii:

#0 3 * * * /usr/local/sbin/ImR_all -soft /Qmultimedia

Szybka ściągawka vi:

• Naciśnij i żeby wejść w tryb edycji
• Dodaj # na początku linii
• Naciśnij Esc
• Wpisz :wq i naciśnij Enter żeby zapisać i wyjść

Krok 5: Załaduj nowy crontab i zrestartuj cron

To kluczowy krok – samo zapisanie pliku nie wystarczy. QNAP wymaga jawnego załadowania crontaba:

bash

crontab /etc/config/crontab && /etc/init.d/crond.sh restart

Krok 6: Zweryfikuj zmianę

Sprawdź, czy Twoja zmiana została zastosowana:

bash

crontab -l | grep ImR_all

Jeśli wszystko poszło dobrze, powinieneś zobaczyć zakomentowaną linię z # na początku lub brak wyniku (jeśli usunąłeś linię zamiast komentować).

Dlaczego zmiana w crontabie wymaga dodatkowego kroku

Na standardowym Linuxie edytujesz crontab poleceniem crontab -e i zmiany od razu działają. Na QNAP jest inaczej – system trzyma „źródło prawdy” w pliku /etc/config/crontab i trzeba je jawnie załadować poleceniem crontab /etc/config/crontab.

Co więcej – nie używaj crontab -e na QNAP. Zmiany wprowadzone tą komendą są tymczasowe i znikną przy następnym restarcie lub aktualizacji systemu, bo QTS nadpisze je zawartością z /etc/config/crontab.

Poprawna procedura to zawsze:

1. Edytuj /etc/config/crontab
2. Załaduj: crontab /etc/config/crontab
3. Restart crona: /etc/init.d/crond.sh restart

Czy wyłączenie ImR_all jest bezpieczne?

Tak, z jednym zastrzeżeniem. ImR_all odpowiada za odświeżanie indeksu multimediów. Jeśli korzystasz z wbudowanych aplikacji QNAP do przeglądania multimediów (Multimedia Station, Photo Station, Video Station), wyłączenie tego zadania sprawi, że nowo dodane pliki nie będą automatycznie indeksowane w nocy.

Praktycznie nie ma to żadnego znaczenia, jeśli:

• Używasz Multimedia Console z włączonym automatycznym indeksowaniem (to osobny mechanizm)
• Korzystasz z Plex, Jellyfin lub innego zewnętrznego serwera mediów (mają własne indeksowanie)
• Nie korzystasz z wbudowanych aplikacji multimedialnych QNAP
• Multimedia Console jest wyłączona

Nawet jeśli korzystasz z natywnych aplikacji QNAP – ręczne indeksowanie jest dostępne z poziomu Multimedia Console (przycisk „Reindex”).

Dodatkowe porady – naprawianie uprawnień po szkodach

Jeśli ImR_all zdążył już namieszać w Twoich uprawnieniach, oto jak je naprawić.

Sprawdzenie aktualnych uprawnień z SSH

bash

getfacl /share/MD0_DATA/Multimedia
ls -la /share/MD0_DATA/Multimedia/

Reset uprawnień na folderze Multimedia

Jeśli uprawnienia są kompletnie rozwalone, możesz je zresetować:

bash

# Usuń wszystkie ACL
setfacl -R --remove-all /share/MD0_DATA/Multimedia/*

# Ustaw właściciela i grupę
chown -R admin:administrators /share/MD0_DATA/Multimedia

# Ustaw uprawnienia
chmod -R 770 /share/MD0_DATA/Multimedia

Następnie w panelu QTS przejdź do Prawa dostępu → Foldery współdzielone → Multimedia → Edytuj uprawnienia i ponownie ustaw dostęp dla użytkowników/grup. Zaznacz opcję „Zastosuj i zastąp wszystkie istniejące uprawnienia”.

Użycie set_volume_mode

QNAP ma też wbudowane narzędzie do resetowania trybu uprawnień na wolumenie:

bash

/sbin/set_volume_mode

Uruchom je bez parametrów, żeby zobaczyć dostępne opcje. Pozwala to przełączyć wolumin między trybem uprawnień Linuxowych a Windows ACL.

Co jeszcze warto sprawdzić w crontabie

Skoro już jesteś w crontabie, rzuć okiem na inne wpisy, które mogą wpływać na działanie NAS-a. Domyślny crontab QNAP zawiera kilka ciekawych pozycji:

Nie wyłączaj tych zadań bez dobrego powodu – są potrzebne do prawidłowego działania systemu.

Podsumowanie

Problem z samoczynnie zmieniającymi się uprawnieniami na QNAP to klasyczny przypadek „nic nie ruszałem, a samo się zepsuło”. W rzeczywistości QNAP co noc uruchamia zadanie ImR_all, które resetuje uprawnienia na folderze Multimedia.

Rozwiązanie:

1. Włącz SSH
2. Edytuj /etc/config/crontab
3. Zakomentuj linię z ImR_all
4. Załaduj crontab: crontab /etc/config/crontab && /etc/init.d/crond.sh restart
5. Gotowe – uprawnienia zostaną takie, jakie ustawisz

Artykuł QNAP – uprawnienia folderów zmieniają się same? pochodzi z serwisu Z IT Wzięte.

Ransomware nie szyfruje tego, czego nie widzi

Zacznijmy od podstaw. Ransomware to program, który szyfruje pliki na dyskach, do których ma dostęp. Klucz do zrozumienia tego zdania: do których ma dostęp.

Jeśli Twój backup leży na udziale sieciowym, na NAS-ie zamontowanym przez SMB, na dysku podpiętym 24/7 do serwera — ransomware zaszyfruje go razem z resztą. Nie dlatego, że jest „sprytny”. Dlatego, że ma do niego ścieżkę sieciową. Dokładnie tak samo, jak Ty otwierasz ten udział w Eksploratorze plików.

I to jest dokładnie to, co dzieje się w większości ataków. Według danych branżowych, 94% ataków ransomware obejmuje próbę zniszczenia kopii zapasowych. Atakujący wiedzą, że backup to jedyna rzecz, która stoi między nimi a okupem. Więc celują w niego jako pierwszy krok.

W przypadku ataków w 2026 — najprawdopodobniej przywracanie systemów trwało tygodniami. Tysiące komputerów do postawienia od zera. Gdyby istniała kopia odłączona od sieci, czas odtworzenia liczyłby się w godzinach, nie tygodniach.

Czym jest backup air-gapped i dlaczego działa

Air-gapped backup to kopia zapasowa, która jest fizycznie odłączona od infrastruktury — nie ma do niej ścieżki sieciowej, nie jest zamontowana jako dysk, nie jest widoczna dla żadnego systemu w sieci. Ransomware nie może zaszyfrować czegoś, do czego nie ma połączenia. Proste.

Jak to wygląda w praktyce? Kilka wariantów od najprostszego do najbardziej zaawansowanego:

Dysk zewnętrzny USB z rotacją

Najprostsza forma air-gap. Dwa lub trzy dyski zewnętrzne USB, podłączane na czas backupu i fizycznie odłączane po zakończeniu. Rotacja codzienna lub tygodniowa — jeden dysk podłączony, reszta w szafie (najlepiej w innym pomieszczeniu lub budynku).

Koszt: 200–500 zł za dysk. Skuteczność: 100% ochrony przed ransomware sieciowym.

Taśmy LTO

Klasyka w większych środowiskach. Taśma po zapisaniu trafia na półkę — fizycznie nie ma połączenia z niczym. LTO-9 to 18 TB na taśmę (45 TB po kompresji). Droższa inwestycja początkowa (napęd LTO-9 to kilkanaście tysięcy złotych), ale koszt nośnika niski i niezawodność ogromna.

Dedykowany serwer backupowy z izolacją sieciową

Serwer backupowy, który łączy się z infrastrukturą produkcyjną tylko w oknie backupowym — przez ściśle kontrolowane reguły firewalla. Poza oknem backupowym: zero połączeń. Bardziej zaawansowane rozwiązanie, wymaga kompetencji sieciowych, ale daje wygodę automatyzacji przy zachowaniu izolacji.

Backup w chmurze z immutability

Usługi takie jak Backblaze B2, Wasabi czy AWS S3 z Object Lock pozwalają ustawić niezmienność (immutability) — zapisane dane nie mogą być nadpisane ani usunięte przez określony czas, nawet jeśli atakujący przejmie klucze dostępowe. To nie jest klasyczny air-gap, ale daje podobny efekt: ransomware nie jest w stanie zniszczyć tych kopii.

Reguła 3-2-1-1-0 — minimum, nie ideał

Branżowy standard to reguła 3-2-1-1-0:

• 3 kopie danych (produkcja + dwie kopie zapasowe)
• 2 różne typy nośników (np. dysk + taśma, dysk + chmura)
• 1 kopia off-site (poza lokalizacją główną)
• 1 kopia air-gapped lub immutable
• 0 błędów przy weryfikacji odtwarzalności

Ten ostatni punkt jest krytyczny i najczęściej pomijany. Backup, którego nigdy nie testowałeś, nie jest backupem. Jest obietnicą, która może się nie spełnić. Testuj odtwarzanie regularnie — minimum raz na kwartał.

Kopia na NAS-ie podłączonym do tej samej sieci co reszta infrastruktury nie spełnia żadnego z tych punktów, poza byciem „drugą kopią”. To nie jest backup — to złudzenie bezpieczeństwa.

Antywirus: dlaczego „jakiś darmowy” nie wystarczy

Druga warstwa, która regularnie zawodzi w atakowanych organizacjach, to ochrona endpointów. Statystyki za 2025 rok mówią jasno:

• 41% udanych ataków na placówki medyczne wynikało ze znanych, ale niezałatanych luk bezpieczeństwa
• 33% ataków wykorzystywało exploity na znane podatności
• 42% placówek nie miało odpowiedniej liczby specjalistów monitorujących systemy

To nie jest historia o superzaawansowanych hakerach. To historia o Windows Server bez aktualizacji od pół roku, o koncie admina z hasłem „admin123″, o antywirusie, którego nikt nie otworzył od dnia instalacji.

Co powinien robić porządny system ochrony endpointów

Profesjonalny antywirus klasy endpoint protection (np. ESET PROTECT, Bitdefender GravityZone, Microsoft Defender for Endpoint) to nie jest „skanowanie plików jak w 2005 roku”. To wielowarstwowy system, który:

• Analiza behawioralna — wykrywa ransomware po zachowaniu (masowe szyfrowanie plików, zmiana rozszerzeń), nawet jeśli sam plik jest zupełnie nowy i nieznany
• Ochrona przed exploitami — blokuje techniki wykorzystywane do przejmowania kontroli nad systemem przez luki w oprogramowaniu
• Sandboxing — podejrzane pliki uruchamiane są w izolowanym środowisku zanim dotrą do użytkownika
• Centralna konsola zarządzania — widoczność na całą infrastrukturę z jednego miejsca, alertowanie, wymuszanie polityk
• EDR (Endpoint Detection & Response) — ciągłe monitorowanie aktywności na endpointach, możliwość retrospektywnego przeszukiwania zdarzeń, izolowanie zainfekowanych maszyn

Ale nawet najlepszy antywirus nie pomoże, jeśli…

• …nikt nie patrzy na alerty. Średni czas wykrycia incydentu w ochronie zdrowia to ponad 200 dni. Dwieście dni, w trakcie których atakujący swobodnie eksplorują sieć.
• …nie ma segmentacji sieci. Jeśli jeden zainfekowany komputer w rejestracji ma dostęp do serwera z bazą pacjentów, to atak na stację roboczą = atak na krytyczne dane.
• …systemy nie są aktualizowane. Exploit na podatność sprzed 6 miesięcy to nie jest „zaawansowany atak”. To odpalenie gotowego narzędzia.

Segmentacja sieci — trzecia warstwa, o której nikt nie mówi

Segmentacja to podział sieci na odizolowane strefy, tak żeby kompromitacja jednego segmentu nie oznaczała kompromitacji całej infrastruktury.

W praktyce: komputer w rejestracji nie powinien mieć dostępu do serwera z backupami. Drukarka sieciowa nie powinna widzieć kontrolera domeny. Sieć Wi-Fi dla gości nie powinna mieć żadnej ścieżki do sieci wewnętrznej.

Jak to zrobić tanio? VLAN-y na zarządzalnym switchu i reguły firewalla. Zarządzalny switch to koszt od kilkuset złotych. Konfiguracja VLAN-ów to kwestia kilku godzin dla kompetentnego informatyka.

Segmentacja sprawia, że nawet jeśli ransomware dostanie się do jednej stacji roboczej, jego rozprzestrzenienie się na resztę sieci jest zablokowane lub znacząco utrudnione.

Plan odtwarzania — bo kiedy, nie czy

Disaster Recovery Plan (DRP) to dokument, który odpowiada na jedno pytanie: co robimy, kiedy wszystko padnie?

Nie musi to być 50-stronicowy elaborat. Minimum, które ma sens:

1. Lista systemów krytycznych z kolejnością przywracania (co najpierw? Serwer DHCP/DNS? Kontroler domeny? System ERP? Poczta?)
2. Lokalizacja backupów — gdzie fizycznie leżą nośniki, kto ma do nich dostęp, jakie są dane logowania
3. Procedura odtwarzania krok po kroku dla każdego krytycznego systemu
4. Lista kontaktowa — kto dzwoni do kogo, kto ma uprawnienia do podjęcia decyzji
5. Regularne testy — minimum raz na kwartał odtwórz coś z backupu. Najlepiej cały system na maszynie testowej

Szpital z DRP przywraca krytyczne usługi w godzinach. Szpital bez DRP wzywa Wojska Obrony Terytorialnej i spędza tygodnie na stawianiu tysiąca komputerów od zera. To nie hipoteza — to dokładnie to, co się wydarzyło w Szczecinie w marcu 2026.

Double extortion — dlaczego prewencja ma znaczenie

Od 2024 roku standardem w atakach ransomware jest podwójne wymuszenie (double extortion): atakujący najpierw kradną dane, potem je szyfrują. Nawet jeśli masz backup i odtworzysz systemy w godzinach, grożą wyciekiem wykradzionych danych.

To jest argument za inwestowaniem w ochronę, nie przeciw. Air-gapped backup chroni przed utratą danych i długim przestojem. Ale przed kradzieżą danych chroni tylko prewencja: porządny antywirus z EDR, segmentacja sieci, szybka detekcja anomalii, monitoring.

Wielowarstwowe podejście (defense in depth):

• Warstwa 1: Prewencja — antywirus, aktualizacje, segmentacja, szkolenia użytkowników
• Warstwa 2: Detekcja — EDR, monitoring, alerty, SIEM
• Warstwa 3: Odtwarzanie — backup air-gapped, DRP, testowane procedury

Żadna warstwa nie jest niezawodna sama w sobie. Ale ich kombinacja sprawia, że atak ransomware staje się incydentem do obsłużenia, a nie katastrofą na tygodnie.

Checklist: co sprawdzić u siebie

Trzy pytania, na które Twój informatyk (lub Ty sam) powinien umieć odpowiedzieć natychmiast:

1. Gdzie jest kopia zapasowa odłączona od sieci? Jeśli odpowiedź brzmi „na NAS-ie” albo „na dysku podłączonym do serwera” — nie masz backupu air-gapped. Masz drugą kopię danych, która padnie razem z resztą.
2. Jaki system ochrony endpointów jest wdrożony i kto monitoruje alerty? Jeśli odpowiedź brzmi „Windows Defender z domyślnymi ustawieniami” albo „nie wiem” — masz problem. Nie chodzi o markę, chodzi o to, czy ktoś aktywnie zarządza ochroną i reaguje na incydenty.
3. Kiedy ostatnio testowaliśmy odtwarzanie z backupu? Jeśli odpowiedź brzmi „nigdy” albo „nie pamiętam” — Twój backup to Schrödingerowska kopia: jednocześnie działa i nie działa, dopóki nie sprawdzisz.

Podsumowanie

Ransomware nie musi oznaczać tygodni przestoju. Trzy rzeczy decydują o tym, czy atak będzie incydentem czy katastrofą:

1. Backup odłączony od sieci — bo ransomware nie zaszyfruje tego, czego nie widzi
2. Porządny antywirus z aktywnym zarządzaniem — bo większość ataków wykorzystuje znane podatności i banalne wektory
3. Przetestowany plan odtwarzania — bo w trakcie kryzysu nie ma czasu na improwizację

Dobrą wiadomością jest to, że zabezpieczenie się nie wymaga milionowego budżetu. Dysk USB z rotacją, profesjonalny antywirus, segmentacja na VLAN-ach, przetestowany plan odtwarzania. To są rzeczy, które kompetentny informatyk wdroży w każdej firmie — od gabinetu lekarskiego po średnie przedsiębiorstwo.

Zrób to zanim będzie za późno.

Artykuł Dlaczego Twój backup jest bezwartościowy, jeśli jest podłączony do sieci pochodzi z serwisu Z IT Wzięte.

Problem: amnezja w połowie zadania

Jeśli używałeś Claude Code na większym projekcie, znasz ten scenariusz. Ładujesz codebase, odpalasz łańcuch tool calli – czytanie plików, analiza, edycja, testy. Claude radzi sobie świetnie. Aż nagle w terminalu pojawia się komunikat:

Claude is compacting the conversation...

I od tego momentu zaczyna się jazda. Claude „zapomina” decyzje architektoniczne podjęte 20 minut temu. Czyta te same pliki ponownie. Czasami wręcz sprzecza się sam ze sobą – implementacja z kroku 5 nie pasuje do tego, co zrobił w kroku 2, bo krok 2 wyleciał z kontekstu.

To był prawdziwy ból dupy przy dłuższych sesjach. Przy oknie 200K tokenów użyteczna przestrzeń to jakieś 150K po odjęciu bufora na kompakcję. Dla małego projektu – ok. Dla repo z backendem, frontendem i testami? Za mało.

Rozwiązanie: 1M tokenów kontekstu – bez dopłat

13 marca 2026 Anthropic ogłosił, że okno kontekstowe o wielkości 1 miliona tokenów jest teraz ogólnie dostępne dla modeli Opus 4.6 i Sonnet 4.6. Bez beta headerów, bez specjalnych flag, bez dopłat za długi kontekst.

Najważniejsze fakty:

• Standardowa cena – za 900K tokenów płacisz dokładnie tyle samo za token co za 9K. Opus 4.6: $5/$25 za milion tokenów (input/output). Sonnet 4.6: $3/$15.
• Pełne rate limity – długie requesty mają taki sam throughput jak krótkie. W becie było inaczej.
• 600 plików multimedialnych per request – wcześniej limit wynosił 100 obrazów lub stron PDF. Teraz 6x więcej.
• Bez beta headera – jeśli wcześniej go używałeś, API go po prostu ignoruje. Nie musisz nic zmieniać w kodzie.
• Dostępne na Claude Platform, Azure Foundry i Google Cloud Vertex AI.
• Claude Code na planach Max, Team i Enterprise – Opus 4.6 automatycznie dostaje 1M kontekstu. Bez konfiguracji.

Co to oznacza w praktyce?

Przy 200K tokenów użyteczna przestrzeń to ~150K. Przy 1M masz ~830K tokenów na faktyczną pracę. To wystarczy na tysiące plików źródłowych, pełne trace’y tool calli i długie sesje debugowania – bez kompakcji.

Anthropic podaje konkretną liczbę: od wdrożenia 1M kontekstu zanotowano 15% spadek zdarzeń kompakcji wśród użytkowników Claude Code. To nie benchmark – to pomiar z realnego użycia.

Co się zmienia w codziennej pracy:

• Cały codebase w jednej sesji – nie musisz już wybierać, które pliki załadować. Ładujesz wszystko.
• Łańcuchy tool calli bez utraty kontekstu – Claude przeszukuje logi, bazy danych, kod źródłowy, proponuje fix – i nie zapomina, co znalazł na początku.
• Dłuższe sesje bez restartu – wielogodzinne sesje agentowe, które wcześniej wymagały ręcznego /compact, teraz trzymają się kupy.

Ciekawy jest też benchmark. Na teście MRCR v2 (Multi-Round Coreference Resolution) w wariancie 1M tokenów Opus 4.6 osiąga 76%, podczas gdy Sonnet 4.5 – tylko 18,5%. To jakościowa różnica w tym, ile kontekstu model faktycznie potrafi wykorzystać bez „context rot” – degradacji jakości przy dużych ilościach danych.

Context awareness – Claude wie, ile mu zostało

Modele Opus 4.6 i Sonnet 4.6 mają wbudowaną świadomość kontekstu (context awareness). Po każdym tool callu Claude dostaje informację w stylu:

Token usage: 35000/1000000; 965000 remaining

Dzięki temu model sam wie, ile miejsca mu zostało i może planować pracę odpowiednio. Nie zgaduje – wie. To jak zegarek na egzaminie zamiast strzelania, ile czasu minęło.

Jak włączyć 1M w Claude Code?

Jeśli jesteś na planie Max, Team lub Enterprise – nie musisz nic robić. Opus 4.6 automatycznie używa 1M kontekstu.

Sprawdzenie aktualnego modelu:

/model

Jeśli chcesz wymusić 1M na konkretnym modelu (np. przez alias):

opus[1m]
sonnet[1m]

Jeśli z jakiegoś powodu nie chcesz 1M kontekstu:

bash

export CLAUDE_CODE_DISABLE_1M_CONTEXT=1

To usuwa warianty 1M z model pickera.

Voice mode – koduj głosem (ale po angielsku)

3 marca 2026 Anthropic zaczął roll-out natywnego trybu głosowego w Claude Code. Na razie dostępny dla ~5% użytkowników, ale roll-out rozszerza się z każdym tygodniem.

Jak to działa?

/voice

Wpisujesz tę komendę w terminalu. Od teraz:

1. Przytrzymaj spację – mów
2. Puść spację – transkrypcja leci do promptu
3. Claude wykonuje polecenie jak zwykle

Tryb push-to-talk. Proste. Możesz też miksować – napisać pół prompta na klawiaturze, a resztę powiedzieć głosem. Transkrypcja wchodzi w miejsce kursora.

Kiedy to ma sens?

• Opisywanie bugów – mówienie „sprawdź dlaczego ten API call zwraca 500 w produkcji, podejrzewam że middleware autentykacji łapie wyjątek i zwraca pusty obiekt” jest 3x szybsze niż pisanie tego samego.
• Sesje refaktoringu – mówisz co chcesz, Claude pisze kod. Dwie z czterech faz pracy (myślenie → wyrażenie intencji → pisanie kodu → review) nie wymagają klawiatury.
• Przerwy od klawiatury – po 6 godzinach kodowania ręce potrzebują odpoczynku. Głos pozwala kontynuować bez przerwy w pracy.

Ograniczenie: tylko angielski

I tu jest haczyk. Voice mode działa na razie tylko po angielsku. Silnik STT (speech-to-text) domyślnie transkrybuje na angielski. Jeśli mówisz po polsku, transkrypcja albo się sypie, albo produkuje bezsensowny tekst angielski.

Na GitHubie Claude Code jest już otwarty issue (#33170) z prośbą o dodanie konfiguracji języka – ustawienie voiceLanguage w settings.json. Na razie nie istnieje. Społeczność wnioskuje o coś w stylu:

json

{
  "voiceEnabled": true,
  "voiceLanguage": ["en", "pl"]
}

Ale oficjalnie – silnik pod spodem (prawdopodobnie Whisper) wspiera wiele języków. Problem w tym, że Claude Code po prostu nie daje opcji wyboru języka. Na razie jedyne obejście to zewnętrzne narzędzia do dyktowania (Wispr Flow, Superwhisper, AquaVoice), które transkrybują w dowolnym języku i wklejają tekst do terminala.

Protip: Nawet po angielsku – precyzyjne nazwy plików, ścieżki i zmienne lepiej wpisywać ręcznie. Voice sprawdza się świetnie do wyrażania intencji („refactor the auth middleware to use RBAC”), kiepsko do precyzyjnych identyfikatorów.

Dla kogo to jest?

Podsumowanie

Dwie zmiany, które realnie wpływają na codzienną pracę z Claude Code:

1M tokenów kontekstu – koniec z kompakcją w połowie zadania, koniec z „Claude zapomniał co robiliśmy”. Cały codebase, pełne trace’y, wielogodzinne sesje – w jednym oknie.

Voice mode – szybsze wyrażanie intencji, mniej pisania, ale na razie tylko po angielsku. Jeśli pracujesz w angielskim środowisku – game changer. Jeśli chcesz mówić po polsku – poczekaj lub użyj zewnętrznego narzędzia do dyktowania.

Czy Claude Code przestanie się gubić? Z 5x większym oknem kontekstowym – znacząco rzadziej. Nie jest to gwarancja (context rot istnieje nawet przy 1M tokenów), ale różnica między 200K a 1M jest jak różnica między kartką A4 a flipchartem. Więcej miejsca = mniej zgubionego kontekstu = lepsza praca.

Źródła

• Ogłoszenie 1M GA: claude.com/blog/1m-context-ga
• Dokumentacja context windows: platform.claude.com/docs/en/build-with-claude/context-windows
• Claude Code docs – model config: code.claude.com/docs/en/model-config
• Issue: voice language config: github.com/anthropics/claude-code/issues/33170

Artykuł Claude Code – 1 milion tokenów kontekstu i tryb głosowy pochodzi z serwisu Z IT Wzięte.

Prowadzisz stronę internetową, mały sklep online albo firmowy serwis? Zastanawiałeś się kiedyś, czy ktoś właśnie nie testuje Twoich zabezpieczeń? CERT Polska uruchomił serwis moje.cert.pl – bezpłatną platformę, która pozwala każdemu przeskanować swoje domeny pod kątem podatności, wycieków danych i zagrożeń sieciowych. Oto co powinieneś o niej wiedzieć.

Czym jest moje.cert.pl?

Serwis moje.cert.pl to projekt zespołu CERT Polska działającego w ramach NASK (Państwowy Instytut Badawczy). Platforma wystartowała testowo pod koniec 2024 roku, a w lutym 2025 została oficjalnie udostępniona publicznie. Od tamtej pory zyskała już prawie 16 tysięcy zarejestrowanych użytkowników i przeskanowała ponad 3,3 miliona domen, subdomen i adresów IP, wykrywając ponad pół miliona podatności i błędnych konfiguracji.

Jak ujął to Marcin Dudek, kierownik CERT Polska – jest to rozwiązanie unikalne na skalę światową, ponieważ tak kompleksowe narzędzie diagnostyczne nie było dotychczas udostępniane bezpłatnie i publicznie w żadnym innym kraju.

Co dokładnie oferuje serwis?

Skanowanie bezpieczeństwa domen

Sercem platformy jest narzędzie Artemis – autorski skaner bezpieczeństwa rozwijany przez CERT Polska. Artemis wykorzystuje znane narzędzia open source (m.in. nuclei, sqlmap) i zawiera kilkadziesiąt modułów sprawdzających różne aspekty bezpieczeństwa strony. System wykrywa między innymi:

• podatności SQL Injection umożliwiające kradzież całej bazy danych,
• błędne konfiguracje serwerów,
• brak mechanizmów SPF i DMARC (ochrona przed fałszywymi e-mailami),
• podatności na zdalne wykonanie kodu,
• inne luki wiążące się z wysokim ryzykiem.

Skanowanie jest cykliczne — domyślnie co dwa miesiące, ale interwał można zmienić w ustawieniach. Wyniki trafiają wyłącznie do administratora danej domeny i nie są nigdzie upubliczniane.

Monitoring wycieków haseł

Serwis monitoruje wycieki danych z wielu źródeł — komercyjnych (m.in. Recorded Future), publicznych baz wycieków oraz materiałów pozyskanych przez CERT Polska w ramach pracy operacyjnej (np. hasła wykradzione przez złośliwe oprogramowanie). Jeśli w Twojej domenie pojawi się wyciek, otrzymasz natychmiastowy alert.

Powiadomienia o zagrożeniach sieciowych

System n6, zintegrowany z platformą, codziennie przetwarza miliony zdarzeń, identyfikując infekcje złośliwym oprogramowaniem, hostowanie szkodliwych treści oraz podatności aplikacji dostępnych publicznie z internetu. Administratorzy sieci otrzymują powiadomienia o problemach w swoich zasobach.

Komunikaty o zagrożeniach

Od maja 2025 w serwisie dostępna jest zakładka z ostrzeżeniami dotyczącymi polskiej cyberprzestrzeni i alertami o podatnościach. Komunikaty są widoczne bezpośrednio w panelu, przez kanał RSS, a po wyrażeniu zgody — także wysyłane e-mailem.

Infrastruktura organizacji (nowość 2026)

Najnowsza funkcja pozwala spojrzeć na swoją infrastrukturę oczami potencjalnego atakującego. System identyfikuje publicznie widoczne zasoby organizacji: subdomeny, użyte technologie, panele administracyjne, otwarte porty — w tym te zapomniane lub niezgłoszone. Dzięki temu administrator może ograniczyć powierzchnię ataku, ukrywając lub dodatkowo zabezpieczając niepotrzebnie eksponowane elementy.

Dla kogo jest moje.cert.pl?

Platforma jest zaprojektowana z myślą o szerokim gronie odbiorców:

• Osoby prywatne posiadające własne strony internetowe mogą szybko sprawdzić, czy ich witryna jest bezpieczna.
• Małe i średnie firmy zyskują dostęp do narzędzi diagnostycznych, które do niedawna były zarezerwowane dla dużych organizacji z własnymi działami IT security.
• Instytucje publiczne mogą monitorować bezpieczeństwo nawet bardzo złożonych środowisk — bez ponoszenia dodatkowych kosztów.
• Organizacje sektorowe (np. z sektora finansowego) mogą dodatkowo skorzystać z szybszej identyfikacji i reagowania na zagrożenia specyficzne dla ich branży.

Jak zacząć?

1. Wejdź na moje.cert.pl i zarejestruj konto.
2. Dodaj swoje domeny — system wymaga weryfikacji, że jesteś ich właścicielem lub administratorem (np. przez rekord DNS lub plik na serwerze).
3. Zamów skanowanie i poczekaj na wyniki.
4. Jeśli korzystasz z zapory sieciowej, warto dodać do białej listy adresy IP skanerów CERT Polska (lista jest dostępna w FAQ serwisu), aby wyniki były kompletne.

Dlaczego warto?

Statystyki mówią same za siebie — wśród pierwszych 1800 przeskanowanych domen system wykrył ponad 30 tysięcy podatności, z czego ponad tysiąc stanowiło wysokie ryzyko. Do tego ponad 34 tysiące przypadków wycieków haseł. Wiele z tych problemów było nieznanych administratorom do momentu otrzymania raportu.

Każda wykryta i usunięta podatność to potencjalny incydent bezpieczeństwa, którego udało się uniknąć. A biorąc pod uwagę, że narzędzie jest całkowicie bezpłatne — naprawdę nie ma powodu, żeby z niego nie skorzystać.

Podsumowanie

Serwis moje.cert.pl to jedno z najciekawszych polskich narzędzi cyberbezpieczeństwa ostatnich lat. Łączy w sobie zaawansowane skanowanie podatności, monitoring wycieków danych, alerty o zagrożeniach sieciowych i mapowanie infrastruktury — wszystko w jednym miejscu i za darmo. Jeśli masz jakąkolwiek stronę internetową lub administrujesz siecią firmową, zarejestruj się i sprawdź, jak Twoja infrastruktura wygląda z perspektywy atakującego. Może się okazać, że nie jest tak bezpieczna, jak myślisz.

Źródła: CERT Polska, NASK, Ministerstwo Cyfryzacji

Artykuł Skaner Bezpieczeństwa dla Firm pochodzi z serwisu Z IT Wzięte.

Powiadomienia push z serwera na telefon – zarówno przez integrację z Zabbix, jak i w własnych skryptach bash.

Czym jest ntfy i jak działa?

ntfy (czytaj: „notify”) to darmowy serwis powiadomień push oparty o prosty protokół HTTP. Zamiast konfigurować serwer SMTP czy płacić za bramkę SMS, wysyłasz jedno żądanie curl:

curl -d "Backup zakończony" ntfy.sh/moj-serwer-xyz123

Jedna komenda = powiadomienie push na telefonie. Bez konta, bez tokena, bez konfiguracji serwera.

Bajecznie proste do zastosowania praktycznie we wszytkim.

Dlaczego ntfy zamiast powiadomień email czy SMS?

Dla administratora serwera Linux czy VPS to game changer – alerty ze serwera na smartfon bez żadnych kosztów i konfiguracji.

Konfiguracja aplikacji mobilnej

1. Pobierz aplikację ntfy:

• Android: Google Play lub F-Droid
• iOS: App Store

1. Kliknij + i wpisz nazwę tematu (np. serwer-prod-x7k9m2)
2. Gotowe – każdy POST na ntfy.sh/serwer-prod-x7k9m2 ląduje na telefonie

Ważne: Używaj losowych nazw tematów! Tematy są publiczne – kto zna nazwę, może subskrybować.

Integracja ntfy z Zabbix – powiadomienia push zamiast email

Standardowe powiadomienia Zabbix przez email są wolne i często ignorowane. SMS-y kosztują. ntfy daje natychmiastowe alerty na telefon za darmo.

Krok 1: Skrypt alertów dla Zabbix

Sprawdź katalog alertscripts:

grep AlertScriptsPath /etc/zabbix/zabbix_server.conf
# Domyślnie: /usr/lib/zabbix/alertscripts

Utwórz plik /usr/lib/zabbix/alertscripts/ntfy.sh:

#!/bin/bash

# ========== KONFIGURACJA ==========
# Wpisz własną, unikalną nazwę tematu!
NTFY_TOPIC="zabbix-TWOJ-UNIKALNY-STRING"
# ==================================

TO="$1"
SUBJECT="$2"
MESSAGE="$3"

# Mapowanie severity Zabbix na priorytety ntfy
case "$SUBJECT" in
    *Disaster*|*DISASTER*)
        PRIORITY="urgent"
        TAGS="rotating_light,disaster"
        ;;
    *High*|*HIGH*)
        PRIORITY="high"
        TAGS="warning,high"
        ;;
    *Average*|*AVERAGE*)
        PRIORITY="default"
        TAGS="orange_circle,average"
        ;;
    *Warning*|*WARNING*)
        PRIORITY="low"
        TAGS="yellow_circle,warning"
        ;;
    *OK*|*Resolved*)
        PRIORITY="low"
        TAGS="white_check_mark,resolved"
        ;;
    *)
        PRIORITY="default"
        TAGS="bell"
        ;;
esac

# Wysłanie powiadomienia push
curl -s \
    -H "Title: ${SUBJECT}" \
    -H "Priority: ${PRIORITY}" \
    -H "Tags: ${TAGS}" \
    -d "${MESSAGE}" \
    "https://ntfy.sh/${NTFY_TOPIC}"

exit 0

Nadaj uprawnienia:

chmod +x /usr/lib/zabbix/alertscripts/ntfy.sh
chown zabbix:zabbix /usr/lib/zabbix/alertscripts/ntfy.sh

Test (jako user zabbix):

sudo -u zabbix /usr/lib/zabbix/alertscripts/ntfy.sh "" "[HIGH] Test alert" "Testowe powiadomienie z Zabbix"

Krok 2: Media Type w Zabbix

Alerts → Media types → Create media type

Krok 3: Trigger Action

Alerts → Actions → Trigger actions → Create action

Zakładka Action:

• Name: Powiadomienia push ntfy
• Conditions: Trigger severity >= Warning

Zakładka Operations:

Default subject:

[{TRIGGER.SEVERITY}] {HOST.NAME}: {TRIGGER.NAME}

Default message:

Host: {HOST.NAME}
Problem: {TRIGGER.NAME}
Severity: {TRIGGER.SEVERITY}
Czas: {EVENT.DATE} {EVENT.TIME}

W sekcji Operations → Add:

• Send to users: wybierz użytkowników
• Send only to: ntfy

Zakładka Recovery operations – analogicznie dla powiadomień o rozwiązaniu problemu.

Krok 4: Media dla użytkownika

Users → [Twój user] → Media → Add

Gotowe! Zabbix wykrywa problem → push notification leci na telefon.

Powiadomienia push w skryptach Bash

ntfy idealnie nadaje się do alertów ze skryptów – backup, monitoring dysku, cronjob, deployment.

Alert po zakończeniu backupu

#!/bin/bash

NTFY_TOPIC="backup-serwer-abc123"

notify() {
    curl -s \
        -H "Title: $1" \
        -H "Priority: $2" \
        -H "Tags: $3" \
        -d "$4" \
        "https://ntfy.sh/${NTFY_TOPIC}"
}

notify "Backup started" "low" "arrow_forward" "Rozpoczynam backup na $(hostname)"

if tar -czf /backup/data-$(date +%Y%m%d).tar.gz /data 2>/tmp/backup.err; then
    SIZE=$(ls -lh /backup/data-$(date +%Y%m%d).tar.gz | awk '{print $5}')
    notify "✅ Backup OK" "default" "white_check_mark" "Rozmiar: ${SIZE}"
else
    notify "❌ Backup FAILED" "urgent" "x" "Błąd: $(cat /tmp/backup.err)"
    exit 1
fi

Monitoring miejsca na dysku

Alert gdy dysk się zapełnia – klasyczny przypadek użycia dla administratora VPS:

#!/bin/bash
# Cron: */30 * * * * /usr/local/bin/disk-check.sh

NTFY_TOPIC="monitoring-xyz789"
THRESHOLD=85

df -h | grep -vE '^Filesystem|tmpfs|cdrom' | awk '{print $5 " " $6}' | while read output; do
    usage=$(echo $output | awk '{print $1}' | sed 's/%//')
    partition=$(echo $output | awk '{print $2}')

    if [ $usage -ge $THRESHOLD ]; then
        curl -s \
            -H "Title: ⚠ Brak miejsca na dysku" \
            -H "Priority: high" \
            -H "Tags: warning,disk" \
            -d "Partycja $partition zapełniona w ${usage}% na $(hostname)" \
            "https://ntfy.sh/${NTFY_TOPIC}"
    fi
done

Alert o logowaniu SSH

Powiadomienie push gdy ktoś loguje się na serwer – przydatne do monitorowania bezpieczeństwa:

Utwórz /usr/local/bin/ssh-notify.sh:

#!/bin/bash

[ "$PAM_TYPE" != "open_session" ] && exit 0

curl -s \
    -H "Title: 🔐 SSH: ${PAM_USER}@$(hostname)" \
    -H "Priority: high" \
    -H "Tags: lock,ssh" \
    -d "User: ${PAM_USER}
Z adresu: ${PAM_RHOST}
Czas: $(date '+%Y-%m-%d %H:%M:%S')" \
    "https://ntfy.sh/ssh-TWOJ-TOPIC"

exit 0

chmod +x /usr/local/bin/ssh-notify.sh

Dodaj na końcu /etc/pam.d/sshd:

session optional pam_exec.so /usr/local/bin/ssh-notify.sh

Uniwersalna funkcja do skryptów

Dodaj do ~/.bashrc lub /etc/profile.d/ntfy.sh:

export NTFY_TOPIC="moj-serwer-default"

ntfy() {
    local msg="$1"
    local title="${2:-Alert}"
    local priority="${3:-default}"

    curl -s \
        -H "Title: ${title}" \
        -H "Priority: ${priority}" \
        -d "${msg}" \
        "https://ntfy.sh/${NTFY_TOPIC}"
}

ntfy-ok()    { ntfy "$1" "✅ ${2:-OK}" "default"; }
ntfy-warn()  { ntfy "$1" "⚠ ${2:-Warning}" "high"; }
ntfy-error() { ntfy "$1" "❌ ${2:-Error}" "urgent"; }

Użycie:

ntfy "Zadanie zakończone" "Mój skrypt"
ntfy-ok "Deployment finished"
ntfy-error "Baza danych nie odpowiada" "DB Alert"

Priorytety powiadomień

Dla alertów Zabbix z severity Disaster używaj urgent – telefon zadzwoni nawet w nocy.

Tagi i emoji

Tagi zamieniają się na emoji w powiadomieniu:

curl -H "Tags: warning,server,fire" -d "CPU 98%!" ntfy.sh/moj-topic

Przydatne tagi: warning , white_check_mark , x , rotating_light , fire , computer , lock

Akcja po kliknięciu

Link otwierany po tapnięciu w powiadomienie:

curl \
    -H "Click: https://zabbix.firma.pl/tr_events.php?eventid=${EVENT_ID}" \
    -H "Title: Problem na serwerze" \
    -d "Kliknij aby otworzyć w Zabbix" \
    ntfy.sh/zabbix-alerts

Limity publicznego serwera ntfy.sh

Dla typowego monitoringu serwera VPS to więcej niż wystarczy.

Podsumowanie

ntfy.sh to najprostszy sposób na powiadomienia push z serwera Linux na telefon:

• Zero konfiguracji – tylko curl
• Natychmiastowe alerty – push w sekundę
• Integracja z Zabbix – 10 minut i działa
• Działa w skryptach bash – jedna linijka kodu
• Darmowy – bez rejestracji, bez limitu który boli
• W dokumentacji znajdziecie wszysto. jak tego użyć od Basha aż do Powershell

Koniec sprawdzania maili. Ustaw ntfy, telefon Cię powiadomi.

Linki:

• Strona: ntfy.sh
• Dokumentacja: docs.ntfy.sh
• GitHub: github.com/binwiederhier/ntfy

Artykuł ntfy – Darmowe powiadomienia push z serwera na telefon pochodzi z serwisu Z IT Wzięte.

Dziś wytłumaczę Ci, dlaczego graficzne edytory zabijają wydajność przy pracy z AI i dlaczego tmux w czystym terminalu to absolutny „must-have”. Poznasz też najważniejsze skróty tmux, które zmienią Twoją pracę.

Dlaczego Twój VS Code „zamula”? (Proste wyjaśnienie techniczne)

Zacznijmy od fundamentów. Dlaczego Twój komputer dławi się przy VS Code, a w terminalu „lata”?

Sekret tkwi w budowie programu. VS Code jest zbudowany na technologii Electron. Mówiąc najprościej: każde okno edytora to w praktyce… osobna, ukryta przeglądarka internetowa (Chrome).

Gdy uruchamiasz w nim agenty AI:

1. Marnujesz zasoby: Komputer musi „rysować” każdą literkę logów jako element graficzny strony www. To pożera gigantyczne ilości RAM-u.
2. Ryzykujesz awarię: Procesy są zależne od interfejsu graficznego. Jeśli okno się „zlaguje”, Twoje połączenie z API OpenAI czy Anthropic może zostać zerwane.

Czysty terminal + tmux działa inaczej. Tu nie ma renderowania grafiki. Jest czysty tekst wysyłany bezpośrednio do jądra systemu.

• Efekt? Zużycie pamięci spada drastycznie.
• Procesor? Odpoczywa, zajmując się tylko logiką AI, a nie rysowaniem ładnych ramek.

Tmux – Co to jest i dlaczego ratuje życie?

Tmux (Terminal Multiplexer) to narzędzie, które zmienia jedno okno konsoli w wielozadaniowe centrum dowodzenia. Pozwala podzielić ekran na wiele paneli, zupełnie jakbyś miał kilka monitorów w jednym oknie.

Ale tmux ma jedną supermoc, której nie ma żaden VS Code: Nieśmiertelność Sesji.

Magia „Detach” i „Attach” – Efekt Terminatora

To najważniejszy powód, dla którego warto porzucić terminal w edytorze. W VS Code, gdy zamkniesz okno – zabijasz wszystkie procesy.

W tmuxie wygląda to tak:

1. Uruchamiasz 3 agenty AI, które „mielą” dane.
2. Wciskasz skrót Detach (odłączenie).
3. Zamykasz całkowicie okno terminala. Możesz nawet wylogować się z systemu.
4. Idziesz na kawę, wracasz za 4 godziny.
5. Otwierasz terminal, wpisujesz jedno z tmux polecenia i… wszystko tam jest.

Procesy nigdy nie przestały działać. Kursor mruga dokładnie w tym miejscu, gdzie go zostawiłeś. To idealne rozwiązanie, by zostawić agenty pracujące w tle, nie obciążając pulpitu otwartymi oknami.

Niezbędnik: Skróty tmux dla Vibe Codingu

Nie musisz być hakerem z filmu, żeby tego używać. Wystarczy Ci dosłownie kilka kombinacji. W tmuxie kluczem jest tzw. Prefix. Domyślnie to Ctrl + b. Najpierw wciskasz to, puszczasz, a potem odpowiednią literę.

Oto najważniejsze skróty tmux, które musisz znać:

Dla osoby nietechnicznej kluczowe jest zrozumienie hierarchii w tmuxie, bo to ona miesza w głowie na początku. Musimy to wytłumaczyć obrazowo:

1. Sesja (Session): To Twój cały wirtualny komputer.
2. Okno (Window): To jak karta w przeglądarce. Masz jedną na ekranie, reszta jest ukryta.
3. Panel (Pane): To podział ekranu. W jednym oknie (karcie) możesz mieć np. 4 panele.

Oto rozszerzona sekcja do artykułu, nasycona słowami kluczowymi pod SEO (skróty tmux, okna tmux, panele tmux).

Panele, Okna i Zarządzanie Chaosem

ZIT radzi: Nie ucz się tego na pamięć. Wydrukuj to sobie albo wrzuć do zakładek. W tmux wszystko zaczyna się od Prefixu (domyślnie Ctrl + b). Najpierw wciskasz Prefix, puszczasz go, a potem wciskasz skrót.

1. Panele (Panes) – Twoja przestrzeń robocza

To tutaj dzieje się magia Vibe Codingu. Dzielisz ekran, żeby widzieć kod i logi agenta AI jednocześnie.

2. Okna (Windows) – Jak karty w przeglądarce

Gdy na jednym ekranie masz już za dużo paneli (np. backend, frontend, baza danych), czas otworzyć nowe „czyste” okno.

3. Sesje i Tryb „Boga” (Zarządzanie)

To są polecenia, które decydują o życiu i śmierci Twoich procesów.

Podstawowe tmux polecenia

Skróty działają wewnątrz, ale czasem musisz zarządzać sesjami „z zewnątrz”. Oto lista komend, które wpisujesz w zwykłym terminalu:

• tmux – Uruchamia nową sesję. Twój start.
• tmux ls – Wyświetla listę wszystkich sesji działających w tle. Sprawdzasz, czy Twoje agenty nadal żyją.
• tmux attach – Absolutnie najważniejsze polecenie. Pozwala wrócić do ostatniej sesji (np. po tym, jak zamknąłeś terminal). To Twój powrót do pracy.
• tmux kill-server – Ostateczne rozwiązanie. Zamyka wszystko i czyści pamięć.

Podsumowanie

Jeśli poważnie myślisz o pracy z AI i chcesz utrzymać wysokie tempo (Vibe Coding), przestań polegać na ciężkich edytorach do uruchamiania procesów.

VS Code służy do pisania kodu. Tmux służy do jego życia.

To rozdzielenie sprawi, że Twój sprzęt odetchnie, a Ty zyskasz kontrolę nad chaosem, jaki generują autonomiczne agenty. Mniej lagów, więcej „vibe’u”.

Artykuł Dlaczego tmux i skróty tmux to Game Changer dla Agentów AI pochodzi z serwisu Z IT Wzięte.

Dostajemy komunikat iż „Magazyn wiadomości osiągnął maksymalny rozmiar Outlook 365”. i nie można nic zrobić, nic nie da sie usunąć ani nic, czyli kolejny odcinek serialu pod nazwą outlook problem .

Teraz tak :

Plik PST (Personal Storage Table) to lokalny plik przechowujacy kopie wiadomosci e-mail, kalendarza, kontaktow i innych elementow Outlooka. Uzywany jest glownie w konfiguracjach POP3 oraz do archiwizacji.

Plik OST (Offline Storage Table) to lokalny plik cache dla kont Exchange i Microsoft 365. Pozwala na prace offline z pelnym dostepem do poczty, ktora synchronizuje sie z serwerem po polaczeniu z siecia.

No i w nowym outlooku mają one ograniczenie do 50 GB . Tak …50GB nie 500 tylko 50 . Co nie jest mega limitem dla aktywnie działającego użytkownika…

Mozna różne rzeczy tutaj robić ( usuną plik pobrać, pobrać na nowo rzeczy z imap, można zkompaktować folder) ale problem wróci…

Najlepszym rozwiązaniem na szybko jest zmiana w rejestrze która zmienia ten limit .

Uruchamiamy regedit

Wchodzimy na HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\PST

I dodajemy 2 wartości DWORD :

• MaxLargeFileSize o wartosci 4294967295
• WarnLargeFileSize o wartosci 4090445042

…i w teorii mamy brz ograniczen (coś pod 4 PB) .

Należy pamiętać o tym że im większy plik tym większa szansa na przypadkową awarie pliku .

Zatem koniecznie po uruchomieniu, wyczyśmy śmieci , spamy i skonfigurujmy konecznie archiwizacje.

Artykuł Magazyn wiadomości osiągnął maksymalny rozmiar Outlook 365 pochodzi z serwisu Z IT Wzięte.

Windows 11 strzelił focha na Twojego QNAP-a? Naprawiamy „Brak dostępu” do folderów bez hasła

Kupiłeś sobie NAS-a. Może to QNAP, może Synology, a może coś, co sam poskładałeś w piwnicy. Podłączasz kable, diody migają wesoło, czujesz się jak haker w „Matrixie”. Konfigurujesz sobie folder udostępniony, taki „na szybko”, żeby wrzucać tam filmy czy zdjęcia z wakacji. Ustawiasz dostęp dla gościa (Guest), bo po co Ci hasło w domu? Przecież pies Ci danych nie wykradnie.

Siadasz do komputera z Windows 11, wchodzisz w otoczenie sieciowe, klikasz w ikonkę serwera i… ściana.

„System Windows nie może uzyskać dostępu do ..”

albo

„Nie masz dostępu do tego folderu udostępnionego, ponieważ zasady zabezpieczeń organizacji uniemożliwiają dostęp nieuwierzytelnionym gościom…. ”

Albo inny, równie pomocny komunikat o braku uprawnień, kontakcie z administratorem (czyli z Tobą, co jest podwójnie irytujące) i ogólnym smutku.

Zanim zaczniesz restartować router, sprawdzać kable albo dzwonić na infolinię dostawcy internetu – stop. To nie awaria. To „troska” Microsoftu.

Dlaczego Windows 11 nie lubi Twojego QNAP-a?

Microsoft w nowszych wersjach Windowsa (10 i 11) stwierdził, że wie lepiej, co jest dla nas bezpieczne. Uznali, że logowanie się do zasobów sieciowych bez hasła (czyli tzw. Insecure Guest Logons) to zło wcielone.

Co z tym zrobić ?

Można by grzebać w Edytorze Lokalnych Zasad Grupy (gpedit.msc), przeklikiwać się przez trzysta okienek i szukać odpowiedniej opcji ukrytej gdzieś między ustawieniami drukarki a tapetą pulpitu. Ale my szanujemy swój czas.

Zrobimy to metodą „na hakera”, ale spokojnie – to tylko dwa polecenia.

Będziemy potrzebować PowerShella. To to niebieskie okienko z literkami, którego zwykle się boisz. Nie bój się.

Krok po kroku:

1. Kliknij prawym przyciskiem myszy na Menu Start (to logo Windowsa na pasku).
2. Wybierz Terminal (Administrator) lub PowerShell (Administrator). Ważne, żeby było to „Administrator”, inaczej system Cię wyśmieje.
3. Pojawi się niebieskie (lub czarne) okno. Teraz zaczyna się magia.

Rozwiązanie problemu

Wpisz (lub skopiuj i wklej, bo po co się męczyć) poniższą komendę.

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force

Kliknij Enter. Jeśli nic nie wybuchło i nie pojawił się czerwony tekst, to znaczy, że zadziałało.

Sprawdzamy, czy weszło

Dla pewności, że system zrozumiał aluzję, możesz wpisać drugą komendę, która pokaże aktualny stan tej blokady:

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons

Jeśli w odpowiedzi zobaczysz: EnableInsecureGuestLogons : True

…to jesteś w domu!

Pamiętaj tylko, że Microsoft trochę racji ma – włączasz to na własną odpowiedzialność. W sieci domowej to luz, ale z laptopem w kawiarni na publicznym Wi-Fi? Cóż, tam raczej i tak nie łączysz się z QNAP-em sąsiada.

Artykuł QNAP WIN11 i Brak Dostępu pochodzi z serwisu Z IT Wzięte.

Przychodzisz do pracy, a telefon już dzwoni. „Nie mogę się zalogować!” – krzyczy użytkownik. Potem drugi, trzeci… Sprawdzasz hasła – wszystko OK. Kontrolery domeny działają. Połączenia sieciowe są. A jednak połowa firmy nie może pracować.

Witaj w świecie problemów z synchronizacją czasu – najbardziej podstępnego wroga każdego administratora Active Directory.Dlaczego czas jest tak krytyczny w Active Directory?
Active Directory to nie tylko baza użytkowników i komputerów. To skomplikowany mechanizm, który opiera swoje bezpieczeństwo na protokole Kerberos. A Kerberos ma obsesję na punkcie czasu – i to nie bez powodu.

Kerberos i jego tiki czasowe

Kerberos używa znaczników czasowych (timestamps) do zabezpieczenia przed atakami typu replay. Każdy bilet Kerberos zawiera informację o czasie jego utworzenia. Gdy klient przedstawia bilet serwerowi, serwer sprawdza czy znacznik czasowy mieści się w akceptowalnym oknie czasowym – domyślnie 5 minut.
Przekroczenie tego progu to automatyczne odrzucenie uwierzytelnienia. Użytkownik dostaje tajemniczy błąd, często coś w stylu „Nie można skontaktować się z kontrolerem domeny” lub „Podane poświadczenia są nieprawidłowe„. A Ty szukasz problemu wszędzie, tylko nie tam gdzie trzeba.

Replikacja też cierpi

To nie koniec problemów. Rozsynchronizowany czas wpływa również na:
– **Replikację między DC** – konflikty przy ustalaniu, która zmiana jest nowsza
– **Certyfikaty SSL/TLS** – mogą być uznane za niewałne lub wygasłe
– **Logi i audyt** – próba ustalenia sekwencji zdarzeń staje się koszmarem
– **Zasady grupowe** – mogą nie aplikować się poprawnie
– **Backupy** – znaczniki czasowe VSS mogą być nieprawidłowe

Problemy z oprogramowaniem

Najczęściej to chyba widać jako problem z czasem na nMedica. Tak nMedica z Asseco jak zostanie zainstlowana na kompie ktory pobiera czas jak chce zacznie wrzeszczeć przy uruchamianiu o problemi z czasem. A w pewnym momencie przestanie działac.

Hierarchia czasu w domenie Windows

Windows ma elegancki, hierarchiczny system synchronizacji czasu. Zrozumienie tej hierarchii to klucz do rozwiązywania problemów.

Standardem który czesto widzimy jest to iż główny kontroler doemny pobiera czas z internetu, a inne kontrolery z niego . A stacje robocze powinny z kontrolerów.

Rozwiązanie problemu

U siebie wspomagamy sie skryptem PS, który pozwala to skonfigurować

Skrypt jest dostępny pod adresem : https://github.com/zITwziete/PS/blob/main/timesync.ps1

SKRYPT SYNCHRONIZACJI CZASU ACTIVE DIRECTORY

OPCJA 1: Sprawdź status synchronizacji czasu – Ta opcja sprawdza wszystkie kontrolery domeny i pokazuje ich aktualny czas, różnice względem komputera lokalnego oraz źródło synchronizacji. Każdy DC otrzymuje status OK (różnica mniejsza niż 30 sekund), OSTRZEŻENIE (30-60 sekund) lub KRYTYCZNY (ponad 60 sekund). To pierwsza opcja której używasz przy diagnozowaniu problemów – uruchamiaj ja regularnie, np. raz w tygodniu, zeby upewnic sie ze wszystko dziala prawidlowo. Jeśli zobaczysz status KRYTYCZNY lub OSTRZEŻENIE, to znak że trzeba podjąć działania naprawcze. 

OPCJA 2: Skonfiguruj źródło czasu PDC – Konfiguruje kontroler PDC Emulator jako główne źródło czasu dla całej domeny. PDC synchronizuje się z zewnętrznymi serwerami NTP (domyślnie polskie serwery pool.ntp.org oraz time.windows.com), a wszystkie pozostałe kontrolery domeny synchronizują się z PDC. Użyj tej opcji podczas początkowej konfiguracji nowej domeny, po reinstalacji PDC, lub gdy chcesz zmienić źródła czasu NTP. Pamiętaj że PDC musi mieć dostęp do Internetu, aby połączyć się z serwerami NTP. 

OPCJA 3: Zresetuj konfiguracje czasu DC– Resetuje i rekonfiguruje usługę W32Time na wybranym kontrolerze domeny. Skrypt wyrejestruje i ponownie zarejestruje usługę, a następnie skonfiguruj ja zgodnie z rola serwera – PDC będzie synchronizował się z zewnętrznymi NTP, a pozostale DC z hierarchia domeny. Użyj tej opcji gdy konkretny kontroler domeny ma problemy z synchronizacja czasu, po awarii serwera, lub gdy zmieniłem konfigurację ręcznie i chcesz wrocic do ustawien domyslnych. To pierwsza opcja naprawcza do wypróbowania przy problemach z pojedynczym DC. 

OPCJA 4: Wymuś synchronizacje całej domeny – Łączy się ze wszystkimi kontrolerami domeny jednocześnie i wymusza na każdym natychmiastowa synchronizacje czasu. Użyj tej opcji po wykonaniu zmian w konfiguracji czasu (np. po zmianie źródeł NTP na PDC), gdy widzisz różnicę czasu między kontrolerami, lub gdy chcesz szybko zsynchronizować cala domenę bez czekania na automatyczna synchronizacja. Ta opcja nie zmienia konfiguracji – tylko wymusza synchronizacje na bazie aktualnych ustawień. 

OPCJA 5: Uruchom tryb monitorowania – Uruchamia ciągły monitoring synchronizacji czasu z automatycznym odświeżaniem co 30 sekund (lub inny ustawiony czas). Ekran wyświetla aktualny status wszystkich kontrolerów domeny z kolorowym oznaczeniem problemów. Użyj tej opcji podczas wykonywania krytycznych zmian w infrastrukturze, gdy chcesz obserwować jak zachowuje się synchronizacja w czasie rzeczywistym, lub gdy podejrzewasz przerywane problemy z czasem. Monitoring mozesz zatrzymac w każdej chwili przez CTRL+C. Doskonale nadaje się też do prezentacji na ekranie w serwerowni. 

OPCJA 6: Testuj łączność NTP – Sprawdza czy kontrolery domeny maja dostep do zewnetrznych serwerow czasu NTP. Testuje kazdy serwer z listy (pool.ntp.org, time.windows.com, time.nist.gov) i pokazuje czy połączenie działa. Użyj tej opcji gdy PDC ma status KRYTYCZNY i podejrzewasz problemy z dostępem do Internetu, po zmianach w konfiguracji zapory, lub gdy chcesz sprawdzić czy zewnętrzne serwery NTP sa dostępne. Jeśli test pokazuje bledy, to znaczy że PDC nie może synchronizować czasu z Internetem i cala domena będzie mieć problemy. 

OPCJA 7: Napraw usługę W32Time – To zaawansowana opcja naprawy uszkodzonej usługi synchronizacji czasu. Możesz naprawić usługę lokalnie, na wybranym kontrolerze, lub na wszystkich DC jednocześnie. Proces naprawy zatrzymuje usługę, wyrejestrowuje ja, rejestruje ponownie, konfiguruje zgodnie z rola serwera i wymusza synchronizacje. Użyj tej opcji gdy usługa W32Time jest zatrzymana i nie da się jej uruchomić, gdy resetowanie przez opcje 3 nie pomoglo, gdy widzisz błędy krytyczne w dzienniku zdarzeń związane z W32Time, lub po poważniejszej awarii serwera. To opcja ostatniej szansy przed reinstalacja systemu. 

OPCJA 8: Skonfiguruj członka domeny – Konfiguruje synchronizacje czasu na stacjach roboczych i serwerach członkowskich domeny (nie-kontrolerach). Możesz skonfigurować komputer lokalny, zdalny komputer, lub wiele komputerów z listy. Dodatkowo możesz przetestować łączność czasowa z kontrolerami domeny. Użyj tej opcji gdy nowe komputery w domenie mają zły czas, gdy stacje robocze pokazują inne godziny niż serwery, po podłączeniu komputera do domeny, lub gdy komputer był długo włączony i jego zegar sie rozjechal. Konfiguracja ustawia synchronizacje z hierarchia domeny, więc komputery będą automatycznie synchronizować się z najbliższym kontrolerem. 

KIEDY UŻYWAĆ KTÓREJ OPCJI – SCENARIUSZE: 

Regularna konserwacja: Raz w tygodniu uruchom opcje 1 by sprawdzić czy wszystko działa. Jeśli wszystko OK, nie rób nic więcej. 

Nowa domena lub migracja: Uruchom kolejno opcje 2, 4, 1 – skonfigurujesz PDC, wymuszasz synchronizacje i sprawdzisz wyniki. 

Problem z jednym kontrolerem: Uruchom opcje 1 aby zidentyfikować problematyczny DC, potem opcje 3 na tym DC, a jesli nie pomoze to opcje 7-2. 

Masowe problemy z całą domeną: Uruchom opcje 6 zeby sprawdzic dostep do NTP, potem opcje 7-3 aby naprawić wszystkie DC, następnie opcje 2 i 4 aby skonfigurować i zsynchronizować. 

Problemy ze stacjami roboczymi: Uruchom opcje 8-4 by sprawdzić łączność, potem opcje 8-1 lub 8-2 aby skonfigurować komputery. Po zmianach w infrastrukturze: Użyj opcji 5 aby monitorować synchronizację w czasie rzeczywistym podczas wprowadzania zmian.

Podsumowanie

Synchronizacja czasu to fundament bezpieczeństwa i stabilności Active Directory. Rozbieżność zaledwie 5 minut może sparaliżować całą domenę, ale z odpowiednimi narzędziami i procedurami możesz temu zapobiec.

Synchronizacja czasu to nie jest coś, co konfigurujesz raz i zapominasz. To proces, który wymaga stałego nadzoru. Ale dzięki skryptom i narzędziom, możesz spać spokojnie wiedząc, że Twoja domena tyka jak szwajcarski zegarek.
Masz swoje historie z wojny z czasem w AD? Podziel się w komentarzach

Artykuł Synchronizacja czasu w Active Directory – cichy zabójca, który kładzie całą domenę pochodzi z serwisu Z IT Wzięte.