Bezpieczeństwo Pterodactyl Panel: jak ochronić panel zarządzania serwerami

Pterodactyl Panel to de facto standard zarządzania serwerami growymi. Jeśli masz więcej niż jeden serwer Minecraft, prawie na pewno albo już używasz Pterodactyla, albo o nim myślisz. Panel web, izolacja Dockera, zarządzanie przez API, ładny interfejs. To wszystko super, dopóki ktoś nie dostanie dostępu do twojego panelu.

Bo dostęp do Pterodactyl Panel = pełna kontrola nad wszystkimi serwerami. Konsole, pliki, bazy danych, ustawienia, userzy. Jedno skompromitowane konto admina i atakujący może zniszczyć wszystko, co budowałeś miesiącami.

Ten artykuł jest o tym, jak do tego nie dopuścić.

Dlaczego bezpieczeństwo panelu jest krytyczne

Wyobraź sobie sytuację. Masz 15 serwerów Minecraft na trzech nodach. Survival, Creative, mini-gry, proxy. Wszystko zarządzane przez jeden Pterodactyl Panel. Jedna osoba dostaje dostęp do admina i w 5 minut może:

• Usunąć wszystkie serwery
• Pobrać wszystkie pliki (łącznie z bazami danych z danymi graczy)
• Podmienić pliki JAR serwerów na złośliwe
• Stworzyć ukryte klucze API do stałego dostępu
• Zmienić hasła SFTP i zablokować prawdziwych adminów

To nie teoretyczne zagrożenia. To regularnie się dzieje z serwerami, gdzie panel jest skonfigurowany "na default" i nikt nie myślał o bezpieczeństwie.

SSL/TLS: podstawowe minimum

Jeśli twój panel działa po HTTP bez szyfrowania, zatrzymaj się i napraw to teraz. Wszystkie loginy, hasła, tokeny sesji lecą otwartym tekstem. Każdy, kto jest w tej samej sieci (albo między tobą a serwerem), może je przechwycić.

Instalacja Let's Encrypt

# Instalacja certbot
apt install certbot python3-certbot-nginx

# Pobranie certyfikatu
certbot --nginx -d panel.yourserver.com

# Automatyczne odnawianie
certbot renew --dry-run

Certbot automatycznie skonfiguruje nginx z przekierowaniem HTTP na HTTPS. Ale sprawdź to ręcznie:

server {
    listen 80;
    server_name panel.yourserver.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name panel.yourserver.com;

    ssl_certificate /etc/letsencrypt/live/panel.yourserver.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/panel.yourserver.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # HSTS
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # Reszta konfiguracji Pterodactyla...
}

Zwróć uwagę na nagłówek HSTS. Mówi przeglądarce: "zawsze używaj HTTPS dla tej domeny". Nawet jeśli ktoś spróbuje podstawić link HTTP, przeglądarka automatycznie przełączy się na HTTPS.

SSL dla Wings też

Nie zapomnij o Wings (demon, który działa na nodach). Komunikacja między Panel a Wings też musi być szyfrowana:

certbot certonly --standalone -d node1.yourserver.com

W configu Wings (/etc/pterodactyl/config.yml):

api:
  host: 0.0.0.0
  port: 8080
  ssl:
    enabled: true
    cert: /etc/letsencrypt/live/node1.yourserver.com/fullchain.pem
    key: /etc/letsencrypt/live/node1.yourserver.com/privkey.pem

Uwierzytelnianie dwuskładnikowe (2FA)

Hasło można ukraść. Phishing, keylogger, wyciek z innego serwisu (tak, ludzie wszędzie używają tych samych haseł). 2FA dokłada drugą warstwę: nawet znając hasło, bez fizycznego dostępu do telefonu albo sprzętowego klucza nie zalogujesz się.

Pterodactyl wspiera TOTP (Time-based One-Time Password) przez Google Authenticator, Authy i podobne.

Wymuszanie 2FA

Dla administratorów 2FA musi być obowiązkowe, nie opcjonalne. W pliku .env Pterodactyla:

# Wymagaj 2FA dla wszystkich adminów
APP_2FA_REQUIRED=1

Oprócz tego upewnij się, że wszyscy sub-userzy (subusers) serwerów też używają 2FA. Jedno zhakowane konto sub-usera z prawami do konsoli = możliwość wykonywania dowolnych komend na serwerze.

Przechowywanie kodów backup

Przy konfiguracji 2FA generowane są kody backup. Trzymaj je:

• Nie w pliku tekstowym na pulpicie
• Nie w notatkach w telefonie
• W managerze haseł (KeePass, Bitwarden)
• Albo na papierze w sejfie (serio, czasami analog jest pewniejszy)

Stracić 2FA i kody backup = stracić dostęp do panelu. Odzyskanie tylko przez bazę danych bezpośrednio.

Bezpieczeństwo Wings i Dockera

Wings to demon Pterodactyla, który uruchamia się na każdej nodzie. Zarządza kontenerami Dockera, w których działają serwery growe. Bezpieczeństwo Wings = bezpieczeństwo wszystkich serwerów na nodzie.

Izolacja Dockera

Każdy serwer Minecraft działa w kontenerze Dockera. To dobrze, bo kontener izoluje proces od systemu hosta. Ale izolacja Dockera nie jest absolutna.

Główne ryzyka:

Shared kernel. Wszystkie kontenery używają jednego jądra Linux. Luka w jądrze może pozwolić wyjść z kontenera. Trzymaj jądro zaktualizowane.

Uprzywilejowane kontenery. Pterodactyl domyślnie nie używa uprzywilejowanych kontenerów i to dobrze. Nigdy nie włączaj --privileged dla serwerów growych.

Montowanie katalogów hosta. Wings montuje określone katalogi wewnątrz kontenerów. Upewnij się, że konfiguracja Wings nie pozwala serwerom wyjść poza swoje katalogi:

# /etc/pterodactyl/config.yml
system:
  data: /var/lib/pterodactyl/volumes
  # Nie ustawiaj tu /home albo /root

Ograniczenie dostępu sieciowego kontenerów

Domyślnie kontenery Dockera mogą łączyć się z czymkolwiek. To znaczy, że złośliwy plugin na jednym serwerze może skanować sieć wewnętrzną, wysyłać zapytania do panelu, próbować podłączyć się do bazy danych.

Ogranicz wychodzący ruch kontenerów:

# Zabroń kontenerom łączyć się z hostem (poza DNS)
iptables -I DOCKER-USER -d 172.17.0.1 -j DROP
iptables -I DOCKER-USER -d 172.17.0.1 -p udp --dport 53 -j ACCEPT
iptables -I DOCKER-USER -d 172.17.0.1 -p tcp --dport 53 -j ACCEPT

# Zabroń dostępu do metadanych chmury (jeśli używasz cloud hostingu)
iptables -I DOCKER-USER -d 169.254.169.254 -j DROP

Docker escape: realne zagrożenie

Docker escape (ucieczka z kontenera) to atak, w którym proces w kontenerze dostaje dostęp do systemu hosta. Dla Pterodactyla oznacza to: jeśli ktoś załaduje złośliwy plik JAR, który eksploatuje lukę Dockera, dostanie dostęp root do nody.

Zmniejszamy ryzyko:

# Sprawdź, czy Docker działa w trybie rootless (jeśli to możliwe)
dockerd-rootless-setuptool.sh install

# Albo chociaż włącz user namespaces
echo '{"userns-remap": "default"}' > /etc/docker/daemon.json
systemctl restart docker

User namespace remapping oznacza, że root w kontenerze nie jest rootem na hoście. To znacząco utrudnia Docker escape.

Ograniczenie dostępu po IP

Twój panel nie powinien być dostępny dla całego internetu. Ogranicz dostęp do IP twoich adminów.

Konfiguracja nginx

# W bloku server {} twojej konfiguracji Pterodactyla
location / {
    # Zezwalaj tylko z określonych IP
    allow 1.2.3.4;       # Admin 1
    allow 5.6.7.8;       # Admin 2
    allow 10.0.0.0/8;    # Sieć wewnętrzna
    deny all;

    # Reszta konfiguracji...
    try_files $uri $uri/ /index.php?$query_string;
}

Jeśli twoi administratorzy mają dynamiczne IP (typowe dla domowego internetu), używaj VPN. Postaw WireGuard na osobnym serwerze i dawaj dostęp do panelu tylko przez VPN:

# Pozwalaj tylko z sieci WireGuard
allow 10.10.10.0/24;
deny all;

Osobny port dla API

API Pterodactyla jest używane przez Wings do komunikacji z panelem. Ten ruch można wynieść na osobny port z jeszcze surowszymi ograniczeniami:

# Główny dostęp do panelu (443)
server {
    listen 443 ssl;
    server_name panel.yourserver.com;
    # ...normalna konfiguracja...
}

# API dla nod (osobny port)
server {
    listen 4443 ssl;
    server_name panel.yourserver.com;

    # Tylko IP nod
    allow 10.0.1.10;  # Node 1
    allow 10.0.1.11;  # Node 2
    deny all;

    location /api/remote {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Bezpieczeństwo bazy danych

Pterodactyl używa MySQL/MariaDB. Baza danych zawiera dane użytkowników, hasze haseł, klucze API, konfiguracje serwerów. Kompromitacja bazy = kompromitacja wszystkiego.

Osobny użytkownik

Nie używaj roota do podłączenia Pterodactyla z bazą danych. Stwórz osobnego usera z minimalnymi prawami:

-- Tworzenie usera dla panelu
CREATE USER 'pterodactyl'@'127.0.0.1' IDENTIFIED BY 'STRONG_RANDOM_PASSWORD_HERE';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP, REFERENCES
    ON panel.* TO 'pterodactyl'@'127.0.0.1';

-- Osobny user do hostowania baz danych (jeśli używasz)
CREATE USER 'pterodactyluser'@'127.0.0.1' IDENTIFIED BY 'ANOTHER_STRONG_PASSWORD';
GRANT CREATE USER ON *.* TO 'pterodactyluser'@'127.0.0.1';
GRANT GRANT OPTION ON *.* TO 'pterodactyluser'@'127.0.0.1';

Bez zdalnego dostępu

MySQL nie powinno słuchać na zewnętrznym IP:

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
bind-address = 127.0.0.1
skip-networking = 0

Jeśli Panel i Wings są na różnych maszynach i potrzebny jest zdalny dostęp do BD, używaj tunelu SSH, a nie otwieraj portu 3306 w internet.

Regularne backupy

# Codzienny backup bazy Pterodactyla
mysqldump -u pterodactyl -p panel | gzip > /backup/panel-$(date +%Y%m%d).sql.gz

# Rotacja: trzymamy 30 dni
find /backup -name "panel-*.sql.gz" -mtime +30 -delete

Trzymaj backupy na osobnym serwerze albo w object storage (S3, MinIO). Backup na tym samym dysku co baza jest bezużyteczny przy awarii dysku.

Bezpieczeństwo Redis

Pterodactyl używa Redis do cache, kolejek i sesji. Niezabezpieczony Redis to jeden z najczęstszych wektorów ataków na aplikacje web.

Ustawienie hasła

Domyślnie Redis nie wymaga hasła. To trzeba naprawić:

# /etc/redis/redis.conf
requirepass YOUR_STRONG_REDIS_PASSWORD
bind 127.0.0.1
protected-mode yes

Zaktualizuj plik .env Pterodactyla:

REDIS_PASSWORD=YOUR_STRONG_REDIS_PASSWORD

Dlaczego to ważne

Niezabezpieczony Redis dostępny z zewnątrz pozwala atakującemu:

• Przeczytać wszystkie sesje (= przejąć sesję admina)
• Zapisać dowolne klucze (= podmienić cache)
• Wykonać komendy przez EVAL (Lua scripting)
• W niektórych konfiguracjach zapisać klucze SSH na dysk

Przypięcie Redis do 127.0.0.1 + hasło = minimalny zestaw ochrony.

Uprawnienia plików

Złe uprawnienia plików mogą zniweczyć całą resztę ochrony. Jeśli plik .env (który zawiera hasła do bazy, Redis, klucze szyfrowania) jest czytelny dla wszystkich userów w systemie, każdy proces na serwerze może go przeczytać.

# Uprawnienia do katalogu Pterodactyla
chown -R www-data:www-data /var/www/pterodactyl
chmod -R 755 /var/www/pterodactyl

# Ścisłe uprawnienia do wrażliwych plików
chmod 640 /var/www/pterodactyl/.env
chown root:www-data /var/www/pterodactyl/.env

# Storage i cache muszą być zapisywalne dla web-servera
chmod -R 775 /var/www/pterodactyl/storage
chmod -R 775 /var/www/pterodactyl/bootstrap/cache

Kluczowa zasada: .env czyta tylko root i web-server. Nikt więcej.

Aktualizacje i patche

Pterodactyl nie aktualizuje się automatycznie. To znaczy, że jeśli postawiłeś panel rok temu i ani razu nie aktualizowałeś, możesz mieć niezałatane luki.

Procedura aktualizacji

cd /var/www/pterodactyl

# Włącz tryb maintenance
php artisan down

# Pobierz nową wersję
curl -L https://github.com/pterodactyl/panel/releases/latest/download/panel.tar.gz | tar -xzv

# Zaktualizuj zależności
composer install --no-dev --optimize-autoloader

# Migracje bazy danych
php artisan migrate --seed --force

# Wyczyść cache
php artisan view:clear
php artisan config:clear

# Uruchom panel z powrotem
php artisan up

Aktualizacja Wings

# Pobierz nową wersję Wings
curl -L -o /usr/local/bin/wings \
  https://github.com/pterodactyl/wings/releases/latest/download/wings_linux_amd64

chmod u+x /usr/local/bin/wings

# Restart
systemctl restart wings

Zapisz się na GitHub releases i Discord Pterodactyla, żeby dowiadywać się o krytycznych aktualizacjach bezpieczeństwa.

Zarządzanie kluczami API

Pterodactyl ma potężne API, przez które można robić praktycznie wszystko: tworzyć serwery, zarządzać userami, usuwać dane. Każdy klucz API to potencjalny punkt wejścia.

Zasada minimalnych uprawnień

Nigdy nie twórz kluczy API z pełnym dostępem "na wszelki wypadek". Określ konkretne operacje, które są potrzebne, i daj prawa tylko do nich:

# Źle: klucz z pełnym dostępem
API Key: Read/Write na wszystkie sekcje

# Dobrze: klucz do monitoringu
API Key: Read-only na Servers, Nodes

Rotacja kluczy

Klucze API nie powinny żyć wiecznie. Ustal politykę rotacji:

• Klucze do integracji: rotacja co 90 dni
• Klucze do jednorazowych skryptów: kasuj zaraz po użyciu
• Wyciekły klucz: skasuj natychmiast, sprawdź logi pod kątem podejrzanej aktywności

Monitoring użycia API

Dodaj logowanie zapytań API w nginx:

location /api {
    access_log /var/log/nginx/pterodactyl-api.log;
    # ...
}

Regularnie sprawdzaj logi pod kątem nietypowej aktywności: zapytania z nieznanych IP, masowe operacje, zapytania w nocy.

Monitoring dostępu do panelu

Logi to twoje oczy. Bez monitoringu dowiesz się o włamie dopiero, gdy serwery już są skasowane.

Co monitorować

• Nieudane próby logowania (brute force)
• Udane logowania z nowych IP
• Tworzenie i usuwanie kluczy API
• Zmiany uprawnień userów
• Usuwanie serwerów

Fail2ban dla Pterodactyla

# /etc/fail2ban/filter.d/pterodactyl.conf
[Definition]
failregex = ^.*"POST \/auth\/login.*" 422.*$
            ^.*authentication.*failed.*<HOST>.*$
ignoreregex =

# /etc/fail2ban/jail.d/pterodactyl.conf
[pterodactyl]
enabled = true
filter = pterodactyl
logpath = /var/log/nginx/pterodactyl-access.log
maxretry = 5
findtime = 600
bantime = 3600

5 nieudanych prób logowania w 10 minut = ban IP na godzinę. Możesz zaostrzyć dla produkcji.

Typowe ataki na Pterodactyla

Brute force

Najbardziej rozpowszechniony atak. Boty próbują hasła do /auth/login. Ochrona: silne hasła + 2FA + fail2ban + ograniczenie po IP.

Session hijacking

Przechwycenie ciasteczka sesji. Ochrona: HTTPS (bez niego ciasteczko leci otwartym tekstem), flagi Secure i HttpOnly na ciasteczku, przypięcie sesji do IP.

W .env Pterodactyla:

SESSION_SECURE_COOKIE=true

CSRF (Cross-Site Request Forgery)

Pterodactyl używa Laravela, który ma wbudowaną ochronę przed CSRF przez tokeny. Upewnij się, że nie wyłączyłeś middleware VerifyCsrfToken. Jeśli używasz custom formularzy lub integracji, zawsze przesyłaj token CSRF.

Przez podatne pluginy/mody serwerów

Atakujący ładuje złośliwy plik JAR na jeden z serwerów. JAR uruchamia się w kontenerze Dockera i próbuje:

• Wyjść z kontenera (Docker escape)
• Skanować sieć wewnętrzną
• Zwrócić się do API panelu z ukradzionymi danymi logowania

Ochrona: izolacja Dockera (opisana wyżej), ograniczenia sieciowe dla kontenerów, weryfikacja ładowanych plików.

Segmentacja sieci

W idealnym świecie panel Pterodactyla i serwery growe żyją w różnych sieciach:

[Internet] --> [Firewall] --> [DMZ: Panel]
                           --> [Internal: Game Nodes]

Panel dostępny z internetu (przez HTTPS). Nody z serwerami growymi dostępne z internetu tylko przez porty gry (25565). Komunikacja między Panel a Nodes idzie przez sieć wewnętrzną.

Jeśli używasz cloud hostingu (Hetzner, OVH), stwórz VLAN między serwerami:

# Na nodzie: Wings słucha na wewnętrznym IP
api:
  host: 10.0.1.10
  port: 8080

W Panel przy dodawaniu nody wpisuj wewnętrzne IP do komunikacji i zewnętrzny FQDN do dostępu SFTP dla userów.

Więcej o ochronie sieciowej serwerów growych w poradniku o iptables.

Pelican: następca Pterodactyla

W latach 2024-2025 Pterodactyl faktycznie przestał być aktywnie rozwijany. Fork o nazwie Pelican kontynuował rozwój i stał się de facto następcą.

Co się zmieniło w Pelicanie z punktu widzenia bezpieczeństwa

Zaktualizowany stos. Pelican przeszedł na nowsze wersje Laravela i PHP, co zamyka szereg luk starych wersji.

Ulepszone zarządzanie rolami. Bardziej szczegółowe uprawnienia dostępu. Zamiast prostej binarnej "admin/nie-admin" pojawiły się konfigurowalne role.

Regularne aktualizacje. Aktywna społeczność = szybkie łatki bezpieczeństwa. W Pterodactylu ostatnie commity mogą być na miesiące przed wykryciem luki.

Kompatybilność z Wings. Pelican działa z istniejącymi nodami Wings, co upraszcza migrację.

Czy warto migrować

Jeśli stawiasz panel od zera, bierz Pelicana. Jeśli masz działającego Pterodactyla, migracja ma sens, kiedy:

• Pterodactyl przestał dostawać aktualizacje bezpieczeństwa
• Potrzebujesz nowych funkcji (ulepszone role, lepsze UI)
• Planujesz skalowanie i chcesz aktualny stos

Proces migracji jest udokumentowany w Pelican docs. Zrób pełny backup przed rozpoczęciem.

Checklista bezpieczeństwa

Zanim wyślesz panel na produkcję, przejdź przez listę:

Sieć:

• HTTPS włączony (Let's Encrypt)
• Nagłówek HSTS ustawiony
• Wings używa SSL
• Dostęp do panelu ograniczony po IP albo przez VPN
• MySQL słucha tylko na 127.0.0.1
• Redis przypięty do 127.0.0.1 z hasłem

Uwierzytelnianie:

• 2FA obowiązkowe dla wszystkich adminów
• Hasła silne i unikalne
• Kody backup zapisane w bezpiecznym miejscu
• SESSION_SECURE_COOKIE=true

Docker i nody:

• Kontenery nie uruchamiają się w trybie privileged
• User namespace remapping włączony
• Wychodzący ruch kontenerów ograniczony
• Dostęp do Docker socket ograniczony

Utrzymanie:

• Panel zaktualizowany do najnowszej wersji
• Wings zaktualizowane do najnowszej wersji
• Codzienne backupy bazy danych
• Fail2ban skonfigurowany
• Klucze API używają minimalnych uprawnień

System plików:

• Plik .env: 640, root:www-data
• Katalogi storage i cache: 775
• Reszta plików: 755

Jeśli pracujesz z ochroną DDoS serwerów przez MineGuard, upewnij się, że panel znajduje się za osobnym chronionym IP, a nie za tym samym adresem co serwery growe. Atak na panel nie powinien wpływać na dostępność serwerów growych i odwrotnie.

Zakończenie

Bezpieczeństwo Pterodactyl Panel to nie "ustawił i zapomniał". To nieprzerwany proces: aktualizacje, monitoring logów, rotacja kluczy, sprawdzanie konfiguracji.

Kluczowe punkty:

1. HTTPS obowiązkowo. Dla Panel i dla Wings.
2. 2FA obowiązkowo dla wszystkich adminów.
3. Ogranicz dostęp do panelu po IP albo przez VPN.
4. Izoluj kontenery Dockera i ogranicz ich dostęp sieciowy.
5. Zabezpiecz bazę danych i Redis (hasła, localhost, osobni userzy).
6. Zarządzaj kluczami API zgodnie z zasadą minimalnych uprawnień.
7. Monitoruj logi i skonfiguruj fail2ban.
8. Aktualizuj Panel i Wings regularnie. Rozważ przejście na Pelicana.

Panel zarządzania to mózg twojej infrastruktury serwerowej. Zabezpiecz mózg, a ciało będzie bezpieczne. Więcej o kompleksowym bezpieczeństwie serwerów Minecraft w checkliście bezpieczeństwa 2026.