Gotify + Wazuh + Zabbix: Kompletny przewodnik po integracji powiadomień push dla administratorów systemów

Spis treści

1. Czym jest Gotify i dlaczego warto go używać?
2. Czym jest Wazuh i jak działa jego system alertów?
3. Czym jest Zabbix i jak obsługuje powiadomienia?
4. Architektura całego rozwiązania
5. Instalacja Gotify (Docker i natywna)
6. Integracja Gotify z Wazuh – krok po kroku
7. Integracja Gotify z Zabbix – krok po kroku
8. Testowanie i weryfikacja działania
9. Najlepsze praktyki i konfiguracja produkcyjna
10. Rozwiązywanie problemów (Troubleshooting)
11. Porównanie Gotify z alternatywami (ntfy, Pushover, Slack)
12. Podsumowanie i FAQ

---

1. Czym jest Gotify i dlaczego warto go używać?

Gotify to otwartoźródłowy, samodzielnie hostowany serwer powiadomień push napisany w języku Go (stąd nazwa). Umożliwia wysyłanie wiadomości w czasie rzeczywistym do urządzeń mobilnych z Androidem oraz do przeglądarki internetowej – bez konieczności korzystania z usług firm trzecich, takich jak Firebase Cloud Messaging (FCM) czy Apple Push Notification Service (APNs).

Główne cechy Gotify

• Self-hosted i open-source – pełna kontrola nad danymi, brak opłat subskrypcyjnych, brak uzależnienia od zewnętrznych dostawców.
• Prosty REST API – wysyłanie powiadomień sprowadza się do pojedynczego żądania HTTP POST z JSON-em lub parametrami form-data.
• WebSocket w czasie rzeczywistym – klienty odbierają wiadomości natychmiast, bez pollingu.
• Minimalne zużycie zasobów – serwer napisany w Go zużywa kilkanaście megabajtów RAM i działa sprawnie na Raspberry Pi lub VPS z 512 MB pamięci.
• Model token-aplikacja – każda usługa, która chce wysyłać powiadomienia, otrzymuje własny token aplikacji, co umożliwia granularną kontrolę i łatwy audyt.
• Oficjalna aplikacja na Androida – dostępna w Google Play oraz F-Droid (dla użytkowników preferujących FOSS).
• Web UI – wbudowany panel webowy do zarządzania aplikacjami, klientami i historią wiadomości.
• System wtyczek – rozszerzalność poprzez plugin API pisane w Go.

Kluczowa przewaga nad komercyjnymi alternatywami: Gotify działa w całości w sieci wewnętrznej. Powiadomienia z Wazuh czy Zabbix nigdy nie opuszczają Twojej infrastruktury – są dostarczane bezpośrednio do aplikacji mobilnej lub przeglądarki bez pośrednictwa jakiegokolwiek zewnętrznego serwera. Jest to istotne w środowiskach z restrykcyjną polityką bezpieczeństwa danych (RODO/GDPR, NIS2, ISO 27001).

---

2. Czym jest Wazuh i jak działa jego system alertów?

Wazuh to platforma bezpieczeństwa open-source klasy SIEM (Security Information and Event Management) i XDR (Extended Detection and Response). Powstała jako fork projektu OSSEC w 2015 roku i od tamtej pory rozwinęła się w samodzielne, kompleksowe rozwiązanie do monitorowania bezpieczeństwa infrastruktury IT.

Kluczowe funkcje Wazuh

Funkcja	Opis
Detekcja intruzów (IDS)	Analiza logów systemowych, wykrywanie anomalii behawioralnych
File Integrity Monitoring (FIM)	Monitorowanie zmian w plikach i katalogach w czasie rzeczywistym
Vulnerability Detection	Wykrywanie podatności CVE na monitorowanych endpointach
Compliance	Wsparcie dla PCI DSS, GDPR, HIPAA, NIST 800-53, CIS Benchmarks
Cloud Security	Integracja z AWS, Azure, GCP na poziomie API
Active Response	Automatyczna reakcja na zagrożenia (blokowanie IP, restartowanie usług)

Jak działa system alertów w Wazuh?

Architektura Wazuh opiera się na modelu agent–serwer:

1. Agenty Wazuh zainstalowane na endpointach zbierają logi, zdarzenia systemowe i dane o integralności plików.
2. Dane trafiają do Wazuh Manager (serwera), który analizuje je na podstawie zestawu reguł (ruleset) i przypisuje poziomy ważności od 1 do 15.
3. Alerty są zapisywane do /var/ossec/logs/alerts/alerts.json i wysyłane dalej poprzez mechanizm Integratora (ossec-integratord).
4. Integrator może wywoływać niestandardowe skrypty Pythona (przedrostek custom-) z trzema argumentami: ścieżką do pliku alertu, kluczem API i adresem URL.

Skala poziomów alertów Wazuh:

Poziom 1–3:   Informacyjne, niska ważność
Poziom 4–7:   Średnia ważność (podejrzana aktywność)
Poziom 8–11:  Wysoka ważność (potencjalny incydent)
Poziom 12–15: Krytyczna ważność (aktywny atak, poważne naruszenie)

---

3. Czym jest Zabbix i jak obsługuje powiadomienia?

Zabbix to enterprise-grade platforma monitorowania open-source przeznaczona do nadzorowania sieci, serwerów, aplikacji, usług w chmurze i urządzeń IoT. Wspiera dziesiątki metod zbierania danych: SNMP, IPMI, JMX, HTTP agent, agenta natywnego, skrypty zewnętrzne i wiele innych.

System powiadomień Zabbix

Zabbix posiada rozbudowany mechanizm Media Types (typów mediów), który definiuje kanały dostarczania powiadomień. Każdy typ może być:

• Built-in – email, SMS (przez bramkę), Slack (wbudowany webhook)
• Webhook – dowolne żądanie HTTP konfigurowane za pomocą JavaScript
• Script – zewnętrzny skrypt shell/Python wywoływany z alertscripts

Powiadomienia w Zabbix są wyzwalane przez trigery (wyzwalacze) na podstawie progów wartości, zmian stanów lub wyrażeń logicznych. Każdy trigger ma przypisane poziomy ważności (severity):

Poziom Zabbix	Wartość numeryczna	Odpowiednik Gotify priority
Not classified	0	1
Information	1	2
Warning	2	4
Average	3	5
High	4	7
Disaster	5	9

---

4. Architektura całego rozwiązania

Poniżej przedstawiona jest architektura przepływu alertów w zintegrowanym środowisku:

┌─────────────────────────────────────────────────────────  ┐
│                   INFRASTRUKTURA IT                       │
│                                                           │
│  [Endpoint 1] ──┐                                         │
│  [Endpoint 2] ──┼──► Wazuh Agent ──► Wazuh Manager        │
│  [Endpoint N] ──┘         │               │               │
│                            │         ossec-integratord    │
│  [Server 1]  ──┐           │               │              │
│  [Server 2]  ──┼──► Zabbix Agent ──► Zabbix Server        │
│  [Network]   ──┘           │               │              │
│                            │               │              │ 
│                            └───────┬───────┘              │
│                                    │                      │
│                                    ▼                      │
│                           ┌──────────────┐                │
│                           │  GOTIFY      │                │
│                           │  SERVER      │                │
│                           │  :8080       │                │
│                           └──────┬───────┘                │
│                                  │                        │
│              ┌───────────────────┼────────────────┐       │
│              │                   │                │       │
│              ▼                   ▼                ▼       │
│        [Android App]      [Web Browser]    [Custom Client]│
└─────────────────────────────────────────────────────────  ┘

Przepływ danych:

1. Zdarzenie bezpieczeństwa na endpoincie → agent Wazuh lub Zabbix zbiera dane
2. Manager/Serwer analizuje zdarzenie i generuje alert
3. Mechanizm integracji (Wazuh Integratord lub Zabbix Media Type) wywołuje skrypt/webhook
4. Skrypt Python lub Bash wysyła żądanie HTTP POST do Gotify REST API
5. Gotify dostarcza powiadomienie push do aplikacji Android lub przeglądarki w czasie rzeczywistym

---

5. Instalacja Gotify

5.1 Instalacja przez Docker (zalecana)

Najprostszym i najbardziej rekomendowanym sposobem wdrożenia Gotify jest Docker. Poniższy przykład docker-compose.yml uruchamia Gotify z trwałym wolumenem danych i automatycznym restartem:

nano compose.yml

services:
  gotify:
    image: gotify/server
    ports:
      - 8080:80
    environment:
      GOTIFY_DEFAULTUSER_PASS: 'admin'
    volumes:
      - './gotify_data:/app/data'
    restart: unless-stopped

Uruchomienie:

docker compose up -d

5.2 Generowanie tokenu aplikacji w Gotify

Po zalogowaniu do panelu Gotify (https://twoj_adres_ip:8080):

1. Kliknij Apps w menu nawigacyjnym.
2. Kliknij przycisk Create Application.
3. Wprowadź nazwę (np. Wazuh Alerts lub Zabbix Alerts).
4. Opcjonalnie dodaj opis i ikonę.
5. Kliknij Create – system wygeneruje unikalny token (np. Axxxxxxxxxxxxxxxx).
6. Skopiuj token i zachowaj w bezpiecznym miejscu – nie będzie pokazany ponownie w pełnej postaci.

Wskazówka: Utwórz osobne aplikacje dla Wazuh i Zabbix. Dzięki temu w historii powiadomień łatwo odróżnisz, z jakiego systemu pochodzi alert, a w razie potrzeby możesz unieważnić token jednego systemu bez wpływu na drugi.

---

6. Integracja Gotify z Wazuh – krok po kroku

6.1 Jak działa mechanizm integracji Wazuh?

Wazuh Manager zawiera komponent ossec-integratord, który monitoruje plik alertów (alerts.json) i wywołuje skrypty zewnętrzne za każdym razem, gdy pojawi się alert spełniający skonfigurowane filtry. Skrypt otrzymuje trzy argumenty pozycyjne:

sys.argv[1] → ścieżka do pliku JSON z alertem (np. /tmp/wazuh-alert-XXXXX.json)
sys.argv[2] → api_key zdefiniowany w ossec.conf
sys.argv[3] → hook_url zdefiniowany w ossec.conf

Każdy niestandardowy skrypt integracji musi mieć nazwę zaczynającą się od przedrostka custom-.

6.2 Tworzenie skryptu integracyjnego Python

Utwórz plik /var/ossec/integrations/custom-gotify:

sudo nano /var/ossec/integrations/custom-gotify

Wklej następujący kod źródłowy:

#!/var/ossec/framework/python/bin/python3
import sys
import json
import requests

# Wazuh przekazuje parametry w stałej kolejności:
# sys.argv[1] = ścieżka do pliku alertu JSON
# sys.argv[2] = klucz API / token (zdefiniowany w ossec.conf)
# sys.argv[3] = adres URL (zdefiniowany w ossec.conf)
alert_file = sys.argv[1]
gotify_token = sys.argv[2]
gotify_url = sys.argv[3]

# Odczyt alertu wygenerowanego przez Wazuh
with open(alert_file, 'r') as f:
    alert_json = json.load(f)

rule_id = alert_json['rule']['id']
description = alert_json['rule']['description']
level = alert_json['rule']['level']
agent_name = alert_json.get('agent', {}).get('name', 'Wazuh Manager')

# Mapowanie poziomów alertów Wazuh na priorytety Gotify (0-10)
if level >= 12:
    priority = 9  # Krytyczny
elif level >= 8:
    priority = 7  # Wysoki
elif level >= 4:
    priority = 4  # Średni
else:
    priority = 1  # Niski

# Formatowanie wiadomości push
payload = {
    "title": f"Wazuh Alert (Level {level}) - {agent_name}",
    "message": f"Rule {rule_id}: {description}",
    "priority": priority
}

# Wysłanie powiadomienia do Gotify
full_url = f"{gotify_url.rstrip('/')}/message?token={gotify_token}"
try:
    requests.post(full_url, json=payload, timeout=10)
except Exception as e:
    with open('/var/ossec/logs/integrations.log', 'a') as log_file:
        log_file.write(f"Gotify integration error: {str(e)}\n")
    sys.exit(1)

6.3 Nadanie uprawnień do pliku skryptu

Wazuh wymaga konkretnych uprawnień i właściciela pliku. Poniższe polecenia są obowiązkowe – integracja nie zadziała bez właściwego ustawienia uprawnień:

# Uprawnienia: właściciel może czytać/pisać/wykonywać, grupa może czytać/wykonywać
sudo chmod 750 /var/ossec/integrations/custom-gotify

# Właściciel: root, grupa: wazuh (wymagane przez ossec-integratord)
sudo chown root:wazuh /var/ossec/integrations/custom-gotify

6.4 Konfiguracja ossec.conf

Otwórz główny plik konfiguracyjny Wazuh Managera:

sudo nano /var/ossec/etc/ossec.conf

Dodaj blok <integration> wewnątrz sekcji <!– Osquery integration –>. Dostosuj <hook_url>, <api_key> i <level> do swoich potrzeb:

<!-- Gotify – powiadomienia push dla alertów poziomu 7 i wyżej -->
<integration>
  <name>custom-gotify</name>
  <hook_url>https://twoj_adres_ip:8080</hook_url>
  <api_key>TUTAJ_TWÓJ_TOKEN_APLIKACJI_Z_GOTIFY</api_key>
  <level>7</level>
  <alert_format>json</alert_format>
</integration>

<!-- Opcjonalnie: osobna integracja tylko dla alertów krytycznych (poziom 12+) -->
<!-- Przydatne, jeśli chcesz używać oddzielnego kanału/tokenu dla krytycznych zdarzeń -->
<!--
<integration>
  <name>custom-gotify</name>
  <hook_url>https://twoj_adres_ip:8080</hook_url>
  <api_key>TOKEN_DLA_KRYTYCZNYCH_ALERTOW</api_key>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>
-->

Przykład:

Ważne parametry konfiguracyjne:

Parametr	Opis	Uwagi
<name>	Nazwa skryptu (musi zaczynać się od custom-)	Odpowiada nazwie pliku w /var/ossec/integrations/
<hook_url>	Adres serwera Gotify	Przekazywany jako sys.argv[3]
<api_key>	Token aplikacji Gotify	Przekazywany jako sys.argv[2]
<level>	Minimalny poziom alertu (1–15)	Wartość 7 oznacza „wysyłaj od poziomu 7 wzwyż”
<alert_format>	Format alertu przekazanego do skryptu	Zawsze ustaw json dla własnych integracji
<rule_id>	(Opcjonalne) Filtr po konkretnym ID reguły	Przydatne do selektywnych powiadomień
<group>	(Opcjonalne) Filtr po grupie reguł	Np. authentication_failures

6.5 Restart Wazuh Managera

sudo systemctl restart wazuh-manager

# Weryfikacja stanu usługi
sudo systemctl status wazuh-manager

# Sprawdzenie logów integracji po pojawieniu się alertów
sudo tail -f /var/ossec/logs/integrations.log

---

7. Integracja Gotify z Zabbix – krok po kroku

Webhook (nowoczesna, bez pliku skryptu)

Metoda Webhook nie wymaga dostępu do systemu plików serwera Zabbix – całą logikę wykonuje JavaScript wbudowany w Zabbix.

Krok 1: Tworzenie Media Type Webhook

1. Alerts → Media Types → Create media type
2. Ustaw Type: Webhook
3. Dodaj parametry:

Nazwa parametru	Wartość domyślna
URL	https://gotify.twojadomena.pl
token	Twój_token
subject	{ALERT.SUBJECT}
message	{ALERT.MESSAGE}
severity	{TRIGGER.SEVERITY}

4. W sekcji Script wklej następujący kod JavaScript:

var params = JSON.parse(value);

var req = new HttpRequest();

req.addHeader('Content-Type: application/json');

var data = {
    title: params.subject,
    message: params.message,
    priority: 5
};

var response = req.post(
    params.URL + '/message?token=' + params.token,
    JSON.stringify(data)
);

Zabbix.log(4, response);

return response;

5. Zapisz Media Type.
6. Kliknij Test aby zweryfikować integrację bezpośrednio z panelu.

---

8. Testowanie i weryfikacja działania

8.1 Testowanie integracji Wazuh → Gotify

Test przez wyzwolenie błędnego logowania SSH

Wprowadź błędne logowanie konta root do serwera Wazuh SSH z błędnym hasłem (np. za pomocą PuTTY):

W panelu Gotify:

Test bezpośredni przez curl:

Możesz przetestować sam serwer Gotify niezależnie od Wazuh:

curl -X POST "http://gotify.twojadomena.pl/message?token=TWÓJ_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "title": "Test Wazuh Integration",
       "message": "To jest testowe powiadomienie z Wazuh.\nReguła #5710: SSH Brute Force\nAgent: Wazuh serwer (192.168.1.10)\nPoziom: 10",
       "priority": 7
     }'

Oczekiwany wynik:

{"id":1,"appid":1,"message":"To jest testowe powiadomienie...","title":"Test Wazuh Integration","priority":7,"date":"2025-01-15T12:34:56Z"}

W panelu Gotify:

---

9. Najlepsze praktyki i konfiguracja produkcyjna

9.1 Separacja tokenów per środowisko

Utwórz osobne aplikacje Gotify (a tym samym osobne tokeny) dla:

• Alertów krytycznych (poziom ≥ 12 w Wazuh, Disaster w Zabbix)
• Alertów wysokich (poziom 8–11 w Wazuh, High w Zabbix)
• Alertów operacyjnych (poziom 4–7, Warning/Average w Zabbix)
• Środowisk DEV, STAGING i PROD

Dzięki temu możesz:

• Mute’ować alerty z DEV bez wpływu na PROD
• Łatwo identyfikować źródło powiadomienia
• Unieważnić kompromitowany token bez przerywania innych kanałów

9.2 Filtrowanie alertów w Wazuh

Zbyt wiele powiadomień to plag administratorów. Odpowiednie filtrowanie zmniejsza zmęczenie alertami (alert fatigue):

<!-- Powiadomienia tylko dla konkretnej grupy reguł i poziomu -->
<integration>
  <name>custom-gotify</name>
  <hook_url>https://gotify.twojadomena.pl</hook_url>
  <api_key>TOKEN_KRYTYCZNE</api_key>
  <level>12</level>
  <group>authentication_failures,web,attack</group>
  <alert_format>json</alert_format>
</integration>

<!-- Osobna integracja dla FIM (File Integrity Monitoring) -->
<integration>
  <name>custom-gotify</name>
  <hook_url>https://gotify.twojadomena.pl</hook_url>
  <api_key>TOKEN_FIM</api_key>
  <level>7</level>
  <group>syscheck</group>
  <alert_format>json</alert_format>
</integration>

9.3 Zabezpieczenie serwera Gotify

# 1. Zmień domyślne hasło admina natychmiast po instalacji

# 2. Ustaw HTTPS z certyfikatem Let's Encrypt
sudo certbot --nginx -d gotify.twojadomena.pl

# 3. Ogranicz dostęp do panelu administracyjnego przez firewall
# (jeśli Gotify jest dostępne tylko z wewnętrznej sieci)
sudo ufw allow from 192.168.0.0/24 to any port 8080
sudo ufw deny 8080

# 4. Regularne backupy bazy danych SQLite
sudo cp /var/lib/gotify/data/gotify.db /backup/gotify-$(date +%Y%m%d).db

# 5. Monitoruj logi Gotify
sudo docker logs gotify --tail 100 -f

9.4 Wysokodostępność Gotify (HA)

W środowiskach krytycznych rozważ uruchomienie Gotify z zewnętrzną bazą danych (MySQL/PostgreSQL) i load balancerem:

# docker-compose.yml z MySQL
services:
  gotify:
    image: gotify/server:latest
    environment:
      GOTIFY_DATABASE_DIALECT: "mysql"
      GOTIFY_DATABASE_CONNECTION: "user:pass@tcp(mysql:3306)/gotify?charset=utf8mb4&parseTime=True&loc=Local"
    depends_on:
      - mysql

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: silne_haslo
      MYSQL_DATABASE: gotify
      MYSQL_USER: user
      MYSQL_PASSWORD: pass
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

9.5 Rotacja tokenów

Tokeny aplikacji Gotify powinny być rotowane regularnie (co 90 dni w środowiskach produkcyjnych):

1. Utwórz nową aplikację w Gotify → skopiuj nowy token.
2. Zaktualizuj api_key w ossec.conf lub skrypcie Zabbix.
3. Zrestartuj Wazuh Managera: sudo systemctl restart wazuh-manager.
4. Usuń starą aplikację w Gotify.

---

10. Rozwiązywanie problemów (Troubleshooting)

Problem 1: Powiadomienia Wazuh nie trafiają do Gotify

Diagnostyka:

# Sprawdź, czy ossec-integratord działa
sudo systemctl status wazuh-manager
sudo ps aux | grep integrat

# Sprawdź logi integracji
sudo cat /var/ossec/logs/integrations.log

# Sprawdź ogólne logi Wazuh
sudo tail -50 /var/ossec/logs/ossec.log | grep -i error

Najczęstsze przyczyny:

Problem	Rozwiązanie
Skrypt nie ma uprawnień do wykonania	sudo chmod 750 /var/ossec/integrations/custom-gotify
Zły właściciel pliku	sudo chown root:wazuh /var/ossec/integrations/custom-gotify
Błędny token Gotify w ossec.conf	Zweryfikuj token w panelu Gotify → Apps
Adres URL Gotify nieosiągalny	curl -v https://gotify.twojadomena.pl/health
Nie zainstalowano modułu requests	/var/ossec/framework/python/bin/pip3 install requests
Poziom alertów za wysoki (za mało alertów)	Tymczasowo obniż <level> do 3 w celach testowych
Brak restartu po zmianie ossec.conf	sudo systemctl restart wazuh-manager

Problem 2: Powiadomienia Zabbix nie docierają do Gotify

# Sprawdź logi Zabbix
sudo tail -50 /var/log/zabbix/zabbix_server.log | grep -i alert
sudo tail -50 /var/log/zabbix/zabbix_server.log | grep -i gotify

# Zweryfikuj uprawnienia skryptu
ls -la /usr/lib/zabbix/alertscripts/gotify.sh

# Test ręczny skryptu z terminala
/usr/lib/zabbix/alertscripts/gotify.sh "TWÓJ_TOKEN" "Test Subject" "Test Message"

Problem 3: Powiadomienia docierają, ale aplikacja Android nie wyświetla push notyfikacji

• Sprawdź ustawienia oszczędzania baterii – Android może blokować połączenia WebSocket w tle.
• Zezwól Gotify Android na działanie w tle i wyłącz optymalizację baterii dla tej aplikacji.
• Zweryfikuj, czy URL Gotify jest dostępny z sieci mobilnej (nie tylko WiFi).

Problem 4: Duplikowane powiadomienia

Jeśli masz skonfigurowane wiele bloków <integration> w ossec.conf z zachodzącymi poziomami, ten sam alert może być przetworzony wielokrotnie. Upewnij się, że zakresy poziomów się nie nakładają lub użyj filtrów <group> i <rule_id> do rozróżnienia.

---

11. Porównanie Gotify z alternatywami

Cecha	Gotify	ntfy	Pushover	Slack
Self-hosted	Tak	Tak	Nie	Nie
Open-source	Tak	Tak	Nie	Nie
Koszt	Bezpłatny	Bezpłatny	$5 jednorazowo	Od $0 (limity)
Android	Oficjalna apka	Oficjalna apka	Oficjalna apka	Oficjalna apka
iOS	Brak oficjalnej	Oficjalna apka	Oficjalna apka	Oficjalna apka
REST API	Prosty	Prosty	Tak	Webhook
Model tokenów	Per aplikacja	Per topic	Per użytkownik	Per workspace
WebSocket	Tak	Nie	Nie	Tak
Wtyczki	Tak	Brak	Brak	Duży ekosystem
Prywatność danych	Pełna kontrola	Pełna kontrola	Chmura	Chmura
Integracja z Wazuh	Custom script	Custom script	Custom script	Wbudowana
Integracja z Zabbix	Script/Webhook	Script/Webhook	Media Type	Wbudowana

Kiedy wybrać Gotify:

• Priorytetem jest prywatność danych i całkowita kontrola nad infrastrukturą
• Środowisko bez dostępu do internetu (air-gapped network)
• Chcesz uniknąć zewnętrznych zależności i kosztów subskrypcji
• Używasz głównie urządzeń Android

Kiedy wybrać ntfy:

• Potrzebujesz wsparcia dla iOS
• Preferujesz model pub/sub oparty na topicach bez uwierzytelniania

Kiedy wybrać Slack:

• Zespół i tak używa Slack do komunikacji
• Potrzebujesz rozbudowanych możliwości współpracy i wątków w alertach

---

12. Podsumowanie i FAQ

Podsumowanie

Integracja Gotify z Wazuh i Zabbix tworzy kompletne, w pełni samodzielnie hostowane rozwiązanie do powiadamiania o zdarzeniach bezpieczeństwa i infrastrukturalnych. Kluczowe korzyści tej architektury:

• Zero zależności zewnętrznych – powiadomienia działają nawet bez dostępu do internetu
• Pełna prywatność – żadne dane alertów nie opuszczają Twojej sieci
• Granularna kontrola – filtrowanie per poziom, reguła, grupa, agent
• Niska bariera wejścia – prosty REST API, minimalna konfiguracja
• Skalowalność – jeden serwer Gotify obsługuje dziesiątki aplikacji nadawczych

Opisana architektura jest sprawdzona w środowiskach produkcyjnych i odpowiada wymaganiom zgodności z RODO, NIS2 oraz standardami ISO 27001 w zakresie monitorowania i logowania zdarzeń bezpieczeństwa.

---

FAQ – Najczęściej zadawane pytania

Czy Gotify działa bez dostępu do internetu? Tak. Serwer Gotify, aplikacja Android (po pobraniu) i cała komunikacja mogą działać w izolowanej sieci wewnętrznej. Jedyna zewnętrzna zależność to certyfikat TLS, jeśli korzystasz z Let’s Encrypt (możesz użyć certyfikatu self-signed w sieciach zamkniętych).

Ile alertów może obsłużyć Gotify? Gotify jest napisane w Go i bardzo efektywnie zarządza połączeniami WebSocket. W testach obsługiwało tysiące wiadomości na minutę bez zauważalnego wzrostu zużycia zasobów. Dla typowych środowisk IT brak jest praktycznych ograniczeń przepustowości.

Czy mogę używać Gotify na wielu urządzeniach jednocześnie? Tak. Jeden klient Gotify (jedno zalogowane urządzenie Android lub przeglądarka) może subskrybować powiadomienia ze wszystkich aplikacji. Możesz też mieć wielu klientów zalogowanych do tego samego konta – wszyscy otrzymają to samo powiadomienie.

Jak długo Gotify przechowuje historię wiadomości? Domyślnie wszystkie wiadomości są przechowywane w bazie SQLite bez limitu czasowego. Możesz ręcznie usuwać wiadomości przez API lub panel webowy. W planach deweloperskich jest automatyczna rotacja historii.

Czy mogę filtrować alerty Wazuh tylko z określonych agentów? Tak. Użyj parametru <event_location> w bloku <integration> w ossec.conf:

<event_location>web-server-01</event_location>

Lub filtruj w samym skrypcie Python po polu alert_json['agent']['name'].

Czy integracja Gotify z Zabbix 7.x działa tak samo jak z Zabbix 6.x? Zabbix 7.0 zmienił licencję (z GPL na BUSL), ale API i mechanizm Media Types pozostały kompatybilne. Skrypt shell i metoda Webhook działają tak samo w obu wersjach. Warto jednak sprawdzić, czy ścieżka alertscripts nie zmieniła się w Twoim wdrożeniu.

Co zrobić, gdy token Gotify zostanie skompromitowany?

1. Zaloguj się do panelu Gotify.
2. Przejdź do Apps i usuń skompromitowaną aplikację – to natychmiast unieważnia token.
3. Utwórz nową aplikację i skopiuj nowy token.
4. Zaktualizuj konfigurację w Wazuh (ossec.conf) lub Zabbix (Media Type / konfiguracja mediów użytkownika).
5. Zrestartuj Wazuh Managera.

---

Artykuł przygotowany z uwzględnieniem oficjalnej dokumentacji Wazuh, repozytorium GitHub gotify/server oraz denisgolius/zabbix-to-gotify-alert. Wersje oprogramowania: Wazuh 4.x, Zabbix 6.x/7.x, Gotify 2.x.