watchlog – monitor zdrowia i bezpieczeństwa serwera

01.Co watchlog dla Ciebie obserwuje

Dwanaście sprawdzeń, wszystkie oparte na standardowych narzędziach Linuksa, które już znasz: apt, systemctl, openssl, dig, fail2ban-client, AIDE. Jeden systemowy timer uruchamia je co cztery godziny. Żadnych agentów, żadnych zewnętrznych usług w chmurze, żadnej telemetrii. Z serwera nie wypływa nic poza tym, na co świadomie skierujesz kanał powiadomień.

apt_updates Liczy paczki do aktualizacji, te z gałęzi -security traktuje priorytetowo. CRITICAL przy bezpieczeństwie

ssl_certs Termin ważności certyfikatów Let's Encrypt, dla wszystkich aktywnych na hoście. WARN <30 dni

disk_space Zajętość systemów plików dla każdego punktu montowania; tmpfs i obrazy snap są pomijane. WARN >80%

memory MemAvailable z /proc/meminfo. WARN <500 MB

services systemctl is-active dla każdej jednostki oznaczonej jako krytyczna. CRITICAL gdy padnie

docker_images Lokalny skrót obrazu porównany z :latest w rejestrze, wykrywa przestarzałe kontenery. INFO gdy nieaktualny

ip_blacklist Spamhaus, Barracuda, SpamCop, SORBS: sprawdzenie adresów IPv4 i IPv6 hosta. CRITICAL na czarnej liście

dns_records Obecność rekordów SPF, DKIM, DMARC, MX, A; wychwytuje przypadkowe błędy w DNS. CRITICAL gdy brakuje

ssh_brute Nieudane logowania SSH z ostatnich 24 godzin, posortowane według adresu źródłowego. WARN powyżej progu

fail2ban_stats Liczba więzień (jaili), aktualnie zablokowane adresy IP i sprawdzenie, że wymagane jaile działają. CRITICAL gdy padnie

open_ports Porównanie nasłuchujących portów ze stanem wzorcowym. Nowy nasłuch na interfejsie zewnętrznym to sygnał włamania. Zmiany na pętli zwrotnej są pomijane. WARN przy nowych portach

file_integrity Sumy kontrolne AIDE dla /etc, /usr, /bin; wykrywa podmianę plików binarnych i konfiguracji. CRITICAL przy zmianach

Każde sprawdzenie to jeden plik Pythona: zwięzły, czytelny kod. Potrzebujesz sprawdzenia dopasowanego do Twojej infrastruktury? Dodajemy je w ramach usługi.

02.Trzy miejsca, w których watchlog Cię znajdzie

Wszystkie kanały działają równolegle i dzielą jeden stan: gdy uciszysz sprawdzenie w aplikacji mobilnej, Telegram też przestanie o nim przypominać. Wybierz to, co pasuje do chwili.

📨 Bot Telegrama

stałe odpytywanie · bez webhooka · bez publicznego adresu

Przyciski działań pod każdym powiadomieniem

Zastosuj / Uśpij / Ignoruj pod każdym wpisem CRITICAL
/runnow, /status, /clearignores
Tylko zatwierdzone chat_id; reszta odrzucana i zapisywana w logu

🖥️ Panel webowy

FastAPI · odświeżanie co 60 s · autoryzacja Bearer

Jedna karta, wszystkie sprawdzenia naraz

Kolorowy pasek z poziomem ważności
Uśpienie lub ignorowanie sprawdzenia jednym wciśnięciem
Szuflada z wynikami komend

📱 Aplikacja mobilna

Flutter · Android · iOS w przygotowaniu

Panel w kieszeni, naprawa wciśnięciem

Przegląd wielu serwerów jako ekran główny
Paski dysku i RAM, kalendarz 90 dni
Parowanie kodem QR w 5 sekund, blokada biometryczna

👁️ watchlog @ ticklist.eu

🔴 apt_updates
   2 paczki do aktualizacji (2 z poprawkami bezpieczeństwa)
   Wciśnij, aby zastosować. Bez SSH.
    • SECURITY: openssl
    • SECURITY: libssl3

✅ Zastosuj aktualizacje bezpieczeństwa

⏰ Uśpij apt_updates na 4h

🚫 Ignoruj apt_updates

🔄 Uruchom watchlog teraz

Bot Telegrama. Te same przyciski trafiają do aplikacji mobilnej jako powiadomienia push.

Panel webowy watchloga na Twoim serwerze: kafelki statusu z kolorami, pasek poziomu ważności, panel nawigacji

Panel webowy na Twoim serwerze pod api.watchlog.pl. Jedna karta na wszystkie serwery.

Aplikacja mobilna watchloga: telefon ze statusem hosta, paskami dysku i RAM, kalendarzem historii i powiadomieniem push

Natywna aplikacja we Flutterze. Sparuj jednym skanem kodu QR i naprawiaj prosto z ekranu blokady.

03.Automatyczne łatanie od początku do końca

watchlog wykrywa, a unattended-upgrades instaluje. Oba są sprawdzone w boju, oba są częścią Ubuntu, oba działają jako timery systemd. Łączymy je raz, a pętla zamyka się sama: od chwili wydania poprawki przez Ubuntu aż po w pełni zaktualizowany serwer, bez ani jednej sesji SSH.

Typowa aktualizacja bezpieczeństwa, krok po kroku

14:00 UTC

Ubuntu wydaje aktualizację bezpieczeństwa

Nowa paczka pojawia się w gałęzi -security. Serwery lustrzane zwykle synchronizują się w ciągu 30 minut.

16:00 UTC · maks. +4h

watchlog ją wychwytuje (co 4 godziny)

Wykrywa przez apt list --upgradable
Podnosi poziom do CRITICAL, bo paczka jest z gałęzi -security
Telegram, powiadomienie push i e-mail: „2 aktualizacje bezpieczeństwa do zainstalowania”
Sygnał /status.json zaktualizowany dla zewnętrznych monitorów

W dowolnej chwili · jedno wciśnięcie

Wciskasz zielony przycisk w telefonie

Usługa uruchamia unattended-upgrade -v, wynik komendy wraca prosto na czat lub do aplikacji, a samo działanie trafia do dziennika zdarzeń. Z kanapy, w kilka sekund, z potwierdzeniem biometrycznym po stronie aplikacji.

Albo o 06:00 UTC następnego dnia

unattended-upgrades i tak się uruchamia (codziennie)

Instaluje wyłącznie paczki z gałęzi -security
Restartuje automatycznie, jeśli wymaga tego aktualizacja jądra (domyślnie o 03:30, pomijane, gdy ktoś jest zalogowany)
Przy zmianach wysyła Ci dziennik instalacji e-mailem

Kolejne uruchomienie watchloga

watchlog potwierdza, że naprawione

Najwyższy poziom ważności wraca do OK lub INFO. Wątek powiadomień zamyka się sam. Bez ponaglających e-maili, bez codziennego zalewu podsumowań.

Od początku do końca: kilka sekund, jeśli wciśniesz, do 16 godzin, jeśli zignorujesz. Każda ścieżka jest w pełni automatyczna. Na żadnym etapie nie potrzeba sesji SSH.

Dwa współpracujące timery

watchlog.timer

co 4 godziny · 00, 04, 08, 12, 16, 20 UTC

Wykrywa i powiadamia

📧 e-mail przy WARN/CRITICAL
📱 powiadomienie push na sparowane telefony
💬 Telegram z przyciskami działań
📋 /status.json + /var/log/watchlog/

apt-daily-upgrade.timer

codziennie ok. 06:00 UTC

Instaluje aktualizacje bezpieczeństwa

📧 e-mail przy zmianie
🔁 restart, jeśli wymaga tego aktualizacja jądra
📁 /var/log/unattended-upgrades/

04.REST API i dokumentacja OpenAPI

Za każdym działaniem bota Telegrama i aplikacji mobilnej stoi udokumentowany punkt końcowy FastAPI. Usługa nasłuchuje na localhoście, TLS kończysz na swoim nginxie lub Caddym, a watchloga integrujesz z czymkolwiek, co mówi po HTTP. Pełna dokumentacja OpenAPI / Swagger żyje obok samego API.

watchlog-api.service

FastAPI + uvicorn, tylko lokalnie

Autoryzacja Bearer, nigdy wystawiany wprost do internetu

Dwa zakresy: read i act
Tokeny dla każdego urządzenia, na dysku jako skrót SHA-256
Wydawanie i odbieranie tokenów zapisane w dzienniku

Parowanie kodem QR

bez autoryzacji, z limitem prób, kod jednorazowy

sudo watchlog api qr na serwerze

6-znakowy kod wygasa po 5 minutach
Blokada po 3 nieudanych próbach
Token wędruje raz po HTTPS przy wymianie

Wybrane punkty końcowe

GET /api/v1/health

Publiczne sprawdzenie żywotności (bez autoryzacji), dla zewnętrznych monitorów dostępności.

GET /api/v1/status

Ostatni sygnał oraz wyliczony age_seconds. Ustrukturyzowane metrics dla każdego sprawdzenia (status.json v2).

GET /api/v1/host

Nazwa hosta, system, jądro, łączny RAM i dysk, czas działania, adresy IP, strefa czasowa, wersja watchloga (aplikacja używa tego do banera „dostępna aktualizacja”).

GET /api/v1/checks/info

Dwujęzyczne (PL i EN) opisy każdego sprawdzenia. Aplikacja mobilna pobiera je i zapamiętuje.

GET /api/v1/reports[/{date}]

Archiwum 90 dni z najwyższym poziomem ważności na dzień, zasila kalendarz historii w aplikacji.

POST /api/v1/runs

Wymusza świeże watchlog run i zwraca zebrany wynik.

POST /api/v1/state/{snooze,ignore}

Wyciszanie wspólne dla wszystkich kanałów. Telegram, e-mail i push respektują ten sam stan.

POST /api/v1/actions/apply-security

Uruchamia unattended-upgrade -v. Komenda z białej listy, nigdy dowolna powłoka.

POST /api/v1/actions/restart-service

Restart jednostki z białej listy. Treść: {"service": "nginx"}. Zapisywane w dzienniku zdarzeń.

POST /api/v1/actions/reboot

Domyślnie wyłączone. Po włączeniu planuje shutdown -r +1, czyli 60 sekund na przerwanie.

POST /api/v1/actions/logs

Ostatnie N linii journalctl dla jednostki z białej listy. Tylko do odczytu.

GET /api/v1/actions

Lista skrótów działań, które operator włączył w konfiguracji. Aplikacja pokazuje je jako przyciski.

GET · PATCH /api/v1/push/preferences

Godziny ciszy dla urządzenia, minimalny poziom ważności, wyciszanie pojedynczych sprawdzeń, inteligentne grupowanie z odstępem. Backend filtruje przy wysyłce do FCM, więc reguły obowiązują nawet przy zamkniętej aplikacji.

POST /api/v1/pair

Wymień jednorazowy kod z watchlog api qr na token dla urządzenia. Bez autoryzacji, z limitem prób.

GET /api/v1/audit

Ostatnie wpisy dziennika zdarzeń: parowanie, tokeny, działania. Można filtrować po przedrostku nazwy zdarzenia.

Łącznie około 25 punktów końcowych. Pełny schemat obejrzysz pod api.watchlog.pl/docs (wymaga tokena Bearer).

05.Bezpieczeństwo i prywatność od początku

watchlog działa na serwerze, wykonuje komendy jako root i rozmawia z Twoim telefonem, więc model bezpieczeństwa liczy się tu bardziej niż lista funkcji. Każde ustawienie domyślne jest tym bezpiecznym, a każdy ryzykowny punkt końcowy pozostaje wyłączony, dopóki świadomie go nie włączysz.

🔒

Powiązany tylko z localhostem

Usługa API słucha wyłącznie lokalnie, nigdy wprost z internetu. Połączenia z zewnątrz przechodzą przez szyfrowany TLS na serwerze proxy stojącym przed nią.

🔑

Token dla każdego urządzenia

Każdy sparowany telefon ma własny token. Gubisz urządzenie, wpisujemy watchlog api tokens revoke tok_xxx, a pozostałe nadal działają.

🛡️

Skrót SHA-256 na dysku

Jawny token pokazujemy raz przy wydaniu i nigdy więcej. Usługa trzyma tylko jego skrót.

📵

Parowanie kodem QR, nie wklejaniem

Kod QR zawiera 6-znakowy kod jednorazowy (nie token). Wygasa po 5 minutach, blokada po 3 nieudanych próbach. Prawdziwy token wędruje tylko raz, przy wymianie.

📋

Dziennik zdarzeń w formacie NDJSON

Każde uwierzytelnienie, parowanie, wydanie i odwołanie tokenu oraz każde działanie trafia do /var/log/watchlog/audit.log jako JSON. Aplikacja mobilna to pokazuje, nic nie jest ukryte.

🧱

Tylko działania z białej listy

Restart usługi, instalacja poprawek, podgląd logów, restart serwera: każde to stała lista komend, na które operator się zgodził. Żadnej dowolnej powłoki.

🔇

Biała lista chat_id w Telegramie

Bot przyjmuje odpowiedzi wyłącznie od chat_id z konfiguracji. Cokolwiek innego jest po cichu odrzucane i zapisywane.

👆

Blokada biometryczna w aplikacji

Opcjonalny Face ID, odcisk palca lub PIN urządzenia. Na Androidzie FLAG_SECURE ukrywa zawartość przed zrzutami ekranu i przełącznikiem aplikacji. Tokeny żyją w Keystore / Keychain.

💾

Szyfrowana kopia zapasowa

Aplikacja mobilna eksportuje listę serwerów, tokeny i ustawienia do pliku zaszyfrowanego hasłem (AES-256-GCM, PBKDF2 600k). Odtworzysz je na nowym telefonie bez ponownego parowania.

📊

Telemetria włączana ręcznie, domyślnie wyłączona

Żadne raporty o awariach ani statystyki użycia nie opuszczają urządzenia, dopóki sam tego nie włączysz w Ustawieniach. Nie zbieramy tokenów, nazw hostów ani danych osobowych.

📤

Twój serwer, Twoje dane

watchlog nie ma żadnego elementu w chmurze. Każde sprawdzenie działa lokalnie; tylko włączone kanały (Telegram, e-mail, FCM) wysyłają cokolwiek na zewnątrz.

⚖️

Kod do wglądu

Około 4 tysięcy linii Pythona, czytelnych od początku do końca. Żadnych kluczy licencyjnych, żadnego dzwonienia do domu, żadnego ukrytego elementu w chmurze.

Czy zdalne wciśnięcie „Zastosuj” jest bezpieczne?

Tak. Aplikacja w telefonie nie wysyła na serwer żadnej komendy do wykonania. Przekazuje tylko informację, który przycisk nacisnąłeś, a serwer ma z góry ustalone, co wolno mu zrobić. Nie da się więc niczego dopisać ani przemycić.

Telefon wybiera wyłącznie z gotowej listy działań, które wcześniej zatwierdziłeś: zainstaluj aktualizacje bezpieczeństwa, zrestartuj wskazaną usługę, pokaż logi. Cokolwiek spoza tej listy serwer po prostu odrzuca i zapisuje w dzienniku.

Każde działanie wymaga prywatnego klucza Twojego urządzenia (gubisz telefon, odbierasz mu dostęp jednym poleceniem), a połączenie jest szyfrowane i nie wisi na otwartym internecie. W najgorszym wypadku ktoś z Twoim telefonem mógłby co najwyżej wcisnąć te same bezpieczne przyciski co Ty. Nie zdobędzie dostępu do serwera ani nie uruchomi niczego spoza listy.

Serwery Linux,
pilnowane, gdy śpisz.