Zabezpieczenie Langflow w wersji Docker

Zainstalowałeś(aś) Langflow w wersji dockerowej? Na pewno warto go zabezpieczyć przed niespodziankami.

Zabezpieczenie Langflow w Fail2Ban

Znajdujemy ID kontenera z Langflow (do poleceń dockerowych może być potrzeba dodać „sudo” na początku – zależnie od konfiguracji):

sudo docker ps

Sprawdzamy logi Langflow pod kątem prób logowania:

sudo docker logs <nazwa_kontenera_langflow> 2>&1 | grep -i login

Instalujemy Fail2Ban (jeśli nie jest zainstalowany):

sudo apt install fail2ban

Tworzymy plik konfiguracyjny jail dla Langflow:

sudo nano /etc/fail2ban/jail.d/langflow.local

Przykładowa zawartość pliku:

[langflow]
enabled = true
port    = 7860
filter  = langflow
logpath = /var/lib/docker/containers/*/*.log
maxretry = 5
findtime = 600
bantime  = 3600

Domyślnie ban trwa 3600 sekund (60 minut) po przekroczeniu 5 błędnych prób logowania w ciągu 10 minut. Parametry możesz dostosować do swoich potrzeb:

• bantime – czas blokady IP w sekundach. Przykłady: 300 = 5 min, 86400 = 24h, -1 = ban permanentny (do ręcznego odblokowania)
• findtime – okno czasowe, w którym zliczane są błędne próby logowania
• maxretry – liczba błędów w czasie findtime, po której IP zostaje zablokowane

Po każdej zmianie konfiguracji restartujemy Fail2Ban:

sudo systemctl restart fail2ban

PostgreSQL w Dockerze – czy trzeba go zabezpieczać?

Jeśli PostgreSQL działa wewnątrz kontenera Docker jako część Langflow i nie wystawiasz portu 5432 na zewnątrz, nie musisz go osobno zabezpieczać. Kontener komunikuje się wyłącznie wewnętrznie w sieci Dockera – nikt z zewnątrz się do niego nie dostanie.

Sprawdź, czy port PostgreSQL jest wystawiony na zewnątrz:

sudo docker ps

• Jeśli widzisz mapowanie 0.0.0.0:5432->5432/tcp lub :::5432 – port jest dostępny z zewnątrz i warto dodać zabezpieczenia (Fail2Ban lub firewall)
• Jeśli brak mapowania portów dla kontenera PostgreSQL – działa wyłącznie wewnątrz sieci Dockera i jest bezpieczny bez dodatkowych działań

Zabezpieczenie innych usług Docker

Jeśli poza Langflow uruchamiasz inne usługi, każda wymaga innego podejścia:

• Ollama (port 11434) – jeśli używasz wyłącznie lokalnie, zablokuj port w firewallu, by nie był dostępny z zewnątrz
• n8n (port 5679) – zastosuj Fail2Ban filtrujący logi błędnych prób logowania
• Qdrant (port 6334) – jeśli logi zawierają błędy 401, użyj Fail2Ban; w przeciwnym razie wystarczy reguła w firewallu

Przykład blokowania portów przez UFW:

sudo ufw deny from any to any port 11434
sudo ufw deny from any to any port 5000

iptables czy UFW – co wybrać?

Oba narzędzia działają na tym samym poziomie systemu (UFW to frontend dla iptables), więc nie używaj ich jednocześnie – jedno może nadpisywać reguły drugiego.

Sprawdź status UFW:

sudo ufw status

• Jeśli wynik to Status: inactive – UFW nie działa, możesz spokojnie używać iptables
• Jeśli Status: active – UFW zarządza regułami i ręczne wpisy iptables mogą być nadpisane przy restarcie

Jeśli nie masz bardzo złożonej konfiguracji, UFW jest wygodniejszym wyborem – ma prostszą składnię, lepiej integruje się z Fail2Ban i łatwiej nim zarządzać. Wystarczy wybrać jedno narzędzie i się go trzymać.