Architektura bezpieczeństwa Odoo 19: prawidłowe połączenie firewalla, 2FA, uprawnień i Web RBL

Odoo jest na naszych pięciu stronach dostępne z otwartego internetu i to nie wyjątek, lecz normalny przypadek: kto prowadzi ofertę, sklep lub logowanie klientów, ma publiczny serwer. Wystarczy jedno podatne hasło, jeden zapomniany plik konfiguracyjny lub zbyt hojne uprawnienie, by z publicznego serwera zrobił się otwarty.

Ten artykuł pokazuje, jak prawidłowo zabezpieczyć Odoo 19 — nie jednym środkiem, lecz wieloma warstwami, które się wzajemnie uzupełniają: firewall i reverse proxy, nasz moduł open source Web RBL, uwierzytelnianie dwuskładnikowe, polityka haseł i uprawnienia — oraz jakie próby ataków każda z nich faktycznie wychwytuje. Na końcu znajduje się instrukcja krok po kroku, według której można dostosować każdą własną instalację Odoo.

Obrona w głąb: dlaczego jeden środek nigdy nie wystarcza

Każdy pojedynczy środek bezpieczeństwa ma lukę. Firewall nie widzi, co dzieje się w formularzu logowania Odoo. Silne hasło nie chroni, jeśli zostało już gdzie indziej skradzione. Struktura uprawnień nic nie daje przeciw atakującemu, który jeszcze w ogóle się nie zalogował. Zasada, która zamyka te luki, nazywa się obrona w głąb (defense in depth): wiele niezależnych warstw, z których każda z osobna dałaby się obejść — ale wszystkie razem już nie.

U nas są to cztery warstwy, każda z innym zadaniem:

• Firewall / reverse proxy — trzyma z dala oczywiste zło, zanim w ogóle dotrze do serwera
• Web RBL — łączy obie strony: Odoo uczy się z własnego dziennika aplikacji tego, czego firewall w ogóle nie może zobaczyć, i przekazuje to z powrotem firewallowi
• Samo Odoo — uwierzytelnianie dwuskładnikowe, polityka haseł, uprawnienia, zarządzanie sesjami
• Baza danych & eksploatacja — kopie zapasowe, ochrona dostępu do administracji, sekrety poza każdym dziennikiem

Kolejne sekcje omawiają każdą warstwę osobno.

Warstwa 1: firewall i reverse proxy

Firewall jest pierwszą instancją, która widzi żądanie, i jedyną, która może odciąć atakującego od każdej usługi na serwerze — nie tylko od strony WWW, ale także od serwera pocztowego, dostępu VPN i własnego interfejsu administracyjnego. To, co w tym miejscu warto włączyć, zależy od producenta, ale formy są takie same w OPNsense, pfSense, HAProxy, FortiGate, Sophos czy Check Point:

Listy RBL: standardowa droga dystrybucji reputacji

RBL oznacza Real-time Blackhole List, pojęcie ze świata poczty: jeden adres w wierszu, dostępny przez HTTP, regularnie ładowany ponownie. Praktycznie każdy firewall potrafi wczytać taką listę i zbudować z niej reguły — OPNsense i pfSense jako URL Table Alias, HAProxy jako plik ACL, FortiGate jako External Block List, Palo Alto jako External Dynamic List, Cisco, Sophos, Juniper i MikroTik pod własnymi nazwami tej samej zasady.

Właśnie tu zaczepia się nasz własny moduł — i właśnie tu zaczyna się druga warstwa.

Warstwa 2: Web RBL — most między aplikacją a firewallem

Firewall widzi pakiety, nie logikę aplikacji. Nie wie, że żądanie o /xmlrpc/2/common jest próbą logowania, że dwadzieścia różnych ścieżek w czternaście sekund to skaner, ani że jakiś adres właśnie z powodzeniem odgadł hasło. Wszystko to wie tylko samo Odoo. Web RBL, nasz własny moduł open source (AGPL-3), czyni tę wiedzę użyteczną — dla samego Odoo oraz, dostarczoną jako lista RBL, także dla firewalla przed nim.

Listy zagrożeń stale porównywane, każda z własnym poziomem.

Krótkie podsumowanie tego, co szczegółowo opisano w poprzednim artykule:

• Rozpoznawanie wzorców w ścieżkach: pliki .env, katalogi .git, pliki konfiguracyjne, sondy WordPress i PHP, path traversal, wykonywanie poleceń przez nowe interfejsy AI
• Obrona logowania, która zlicza ponad restartami — inaczej niż własny licznik Odoo, żyjący w pamięci operacyjnej
• Ocena każdego adresu od 0 do 100, z uzasadnieniem wprost
• Błędne konfiguracje (QNAP, Autodiscover, Synology) są rozpoznawane i nigdy nie są blokowane, ponieważ blokada nie usuwa usterki, lecz ją tylko ukrywa
• Obce listy zagrożeń, takie jak Spamhaus, FireHOL i węzły wyjściowe Tor, stale porównywane
• Lista dozwolonych dla adresów, które nigdy nie mają być blokowane

Dla tego artykułu szczególnie ważne są dwie właściwości, ponieważ bezpośrednio wiążą się z firewallem i logowaniem.

Leniwa lista to lista, której można ufać

Lista dozwolonych — adresy, które nigdy nie są blokowane, na przykład własne połączenia lokalizacji — z reguły zmienia się rzadko. Właśnie to jest jej wartością, nie wadą: jeśli spokojna lista przez dni prawie się nie rusza, każda rzadka zmiana od razu rzuca się w oczy. Codzienna automatyczna aktualizacja istnieje nie dlatego, że wiele by się zmieniało, lecz po to, by rzadkiej zmiany nie trzeba było dopisywać ręcznie — a to jest właśnie ten moment, w którym się o niej zapomina. Jedna z naszych własnych błędnych konfiguracji w zeszłym miesiącu wyszła na jaw właśnie tak: nie przez wiele zdarzeń, lecz przez to jedno, o którym nikt nie wiedział, aż interfejs QNAP Web API klienta został omyłkowo zablokowany. Od tamtej pory QNAP znajduje się na liście błędnych konfiguracji, które nigdy nie są blokowane, a jedynie zgłaszane.

Logowanie to miejsce, którego firewall nie widzi

Firewall może zablokować adres. Nie może wiedzieć, czy logowanie się udało, a tym bardziej, czy pochodziło z adresu, który chwilę wcześniej szukał jeszcze danych dostępowych. Web RBL wie: ocena powyżej ustawianego progu całkowicie zabrania logowania, a udane logowanie z podejrzanego adresu jest zgłaszane — to ogniwo łączące z następną warstwą.

Warstwa 3: zabezpieczenie samego Odoo

Uwierzytelnianie dwuskładnikowe: drugi sekret, którego nie można użyć ponownie

Największym problemem haseł nie jest ich jakość, lecz ponowne użycie. Hasło skradzione w innej usłudze działa u nas dokładnie tak samo, o ile jest to samo hasło. Uwierzytelnianie dwuskładnikowe (2FA, zwane też TOTP) przeciwstawia temu drugi sekret: sześciocyfrowy kod, który zmienia się co trzydzieści sekund i jest obliczany z sekretu znanego tylko własnemu smartfonowi. Samo skradzione hasło już nie wystarcza.

Odoo 19 Community ma to wbudowane — jako instalowalny moduł Two-Factor Authentication (TOTP), uzupełniony opcją awaryjną z kodem e-mail. Każdy użytkownik konfiguruje to dla siebie, za pomocą kodu QR, w dowolnej popularnej aplikacji uwierzytelniającej:

Konfiguracja: zeskanować kod QR, raz potwierdzić sześciocyfrowy kod, gotowe.

To jednak pomaga tylko tym, którzy skonfigurują to sami — a doświadczenie pokazuje, że bez przymusu pozostają oni mniejszością. Odoo zna dlatego politykę wymuszania: albo tylko dla pracowników (użytkowników wewnętrznych), albo dla wszystkich, łącznie z użytkownikami portalu. Bez skonfigurowanego drugiego sekretu nikt nie przejdzie już przez formularz logowania, nie potwierdzając się przynajmniej kodem e-mail.

Polityka haseł: minimalna długość nie jest oczywistością

Bez dodatkowego modułu Odoo Community nie wymaga żadnej minimalnej długości haseł — użytkownik może ustawić hasło z trzech znaków, jeśli nikt mu w tym nie przeszkodzi. Własny moduł Password Policy zamyka dokładnie tę lukę: minimalna długość egzekwowana po stronie serwera, a nie tylko sugerowana w przeglądarce. Kto chce więcej — wymuszonego okresu ważności, historii przeciw ponownemu użyciu — potrzebuje do tego modułu OCA lub firm trzecich; w wersji Community jest to świadomie ograniczone do minimum.

Uprawnienia: dostęp dostaje tylko ten, kto go potrzebuje

Odoo od początku rozdziela trzy poziomy: użytkownicy portalu (tylko własny portal klienta lub dostawcy), użytkownicy wewnętrzni (backend, z uprawnieniami dla każdej aplikacji) i administratorzy (nieograniczony dostęp wraz z ustawieniami technicznymi). Najczęstszym błędem nie jest zbyt słabe hasło, lecz zbyt hojnie przydzielona rola administratora: kto ma tylko wystawiać faktury, nie potrzebuje dostępu do ustawień systemu.

Największy ciężar niosą dwie zasady:

Jedno i drugie można sprawdzić w tym samym widoku, w którym konfiguruje się także uwierzytelnianie dwuskładnikowe:

Jeden przegląd, cztery dźwignie: hasło, drugi składnik, klucze API, zalogowane urządzenia.

Sesje i urządzenia: kto jest teraz zalogowany

Ten sam widok pokazuje także, z jakich urządzeń konto jest aktualnie zalogowane — i pozwala wylogować jedno lub wszystkie naraz. Po utracie laptopa lub przy podejrzeniu skompromitowanego hasła to najszybszy skuteczny krok: sesja kończy się natychmiast, niezależnie od tego, czy hasło zostało już zmienione.

Warstwa 4: baza danych i eksploatacja

Czwarta warstwa jest najmniej widoczna i zarazem najmniej wybaczalna, ponieważ błąd tutaj może zniweczyć wszystko, co zbudowano wcześniej.

• Regularne, sprawdzane kopie zapasowe, przechowywane oddzielnie od samego serwera. Kopia, która nigdy nie została przywrócona, jest przypuszczeniem, a nie kopią zapasową.
• Sekrety nie należą do żadnego pliku dziennika. Hasła, klucze API, dane licencyjne — kto pisze własne rozszerzenia, powinien traktować je tak jak samo hasło główne: nigdzie ich nie zapisywać, także nie „tylko do debugowania”.
• Utrzymywać moduły w aktualnym stanie, także i zwłaszcza moduły firm trzecich. Wolne moduły dodatkowe (OCA i inne) siłą rzeczy pozostają w tyle za nowymi wersjami Odoo; przed każdą instalacją warto sprawdzić, jakie zależności dochodzą automatycznie.

Cała droga logowania

Cztery warstwy nie działają kolejno w oddzielnych pomieszczeniach, lecz na tym samym żądaniu, stopień po stopniu. Najlepiej widać to na przykładzie logowania:

Pięć miejsc, w których złośliwe żądanie może się zakończyć, zanim dotrze do właściwego celu — i tylko jedno, w którym uprawniony użytkownik przechodzi przez wszystkie.

Scenariusze ataków i obrona przed nimi

Poniższe zestawienie przyporządkowuje rzeczywiste wzorce ataków warstwom, które faktycznie je zatrzymują. Kilka z nich to nie teoria, lecz nasze własne obserwacje z siedemnastu dni rzeczywistego ruchu na naszych pięciu stronach.

Krok po kroku: zabezpieczenie własnej instalacji Odoo

Poniższa kolejność jest taka, w jakiej sami byśmy postępowali — od największego efektu do najdelikatniejszego ustawienia.

1. Wymusić uwierzytelnianie dwuskładnikowe

1. Jeśli jeszcze nie zainstalowano: otworzyć Aplikacje, wyszukać „Two-Factor Authentication” i zainstalować (przy kilku stronach zaleca się dodatkowo „Two-Factor Authentication by Mail” jako opcję awaryjną).
2. Otworzyć Ustawienia → Ustawienia ogólne → Uprawnienia.
3. Włączyć „Wymuś uwierzytelnianie dwuskładnikowe”.
4. Wybrać politykę: „Tylko pracownicy” dla użytkowników wewnętrznych, „Wszyscy użytkownicy”, jeśli mają być objęci także użytkownicy portalu (klienci z dostępem).
5. Zapisać. Od następnej próby logowania Odoo wymaga od każdego użytkownika bez skonfigurowanego drugiego sekretu przynajmniej kodu e-mail, dopóki nie skonfiguruje on aplikacji uwierzytelniającej.

2. Ustalić minimalną długość haseł

1. Otworzyć Aplikacje, wyszukać „Password Policy” i zainstalować.
2. Otworzyć Ustawienia → Ustawienia ogólne → Uprawnienia.
3. Ustawić „Minimalna długość hasła” — dwanaście znaków to rozsądna wartość wyjściowa.
4. Zapisać. Reguła obowiązuje od razu przy każdym nowym lub zmienionym haśle, nie obowiązuje wstecznie dla istniejących haseł.

3. Przejrzeć uprawnienia

1. Otworzyć Ustawienia → Użytkownicy & firmy → Użytkownicy.
2. Otworzyć każdego użytkownika z osobna i sprawdzić zakładkę z prawami dostępu dla każdej aplikacji: czy ta osoba naprawdę potrzebuje „Menedżera” lub „Administratora”, czy wystarczy „Użytkownik”?
3. Szczególnie sprawdzić: kto ma dostęp do samych „Ustawień”? Powinna to być bardzo mała grupa.
4. Dla każdego zewnętrznego połączenia (księgowość, własne skrypty, rejestracja czasu) w zakładce „Bezpieczeństwo konta” danego użytkownika technicznego utworzyć własny klucz API, zamiast przekazywać hasło użytkownika.

4. Zainstalować Web RBL i obserwować, zanim zostanie uruchomiony na ostro

1. Moduł z github.com/Alex0176/odoo-web-rbl umieścić w ścieżce addonów i zainstalować.
2. Obserwować przez kilka dni: menu Web RBL → Analiza pokazuje, które wzorce faktycznie działają.
3. Dopiero potem włączyć web_rbl.sperren_aktiv (Ustawienia → Techniczne → Parametry systemowe) — od tego momentu rozpoznane sondy są faktycznie odrzucane.
4. Listę blokad pod adresem podanym w module, chronionym tokenem, podłączyć do firewalla jako listę RBL (w OPNsense/pfSense jako URL Table Alias, w HAProxy jako plik ACL).

5. Zabezpieczyć sam firewall

1. Interfejs administracyjny firewalla udostępnić wyłącznie z sieci wewnętrznej, nigdy pod tym samym publicznym adresem co strona WWW.
2. Włączyć automatyczne aktualizacje bezpieczeństwa oprogramowania firewalla, o ile producent je oferuje.
3. Sprawdzić konfigurację TLS: tylko aktualne wersje protokołu, przestarzałe metody szyfrowania wyłączyć.
4. Jeśli dostępne: podłączyć znaną listę reputacji (na przykład Spamhaus DROP) bezpośrednio na firewallu — niezależnie od Web RBL, bo firewall widzi dzięki temu także ruch do usług, do których Odoo nigdy nie dociera.

6. Zamknąć zarządzanie bazami danych

1. Sprawdzić, czy /web/database/manager jest dostępny z zewnątrz — jeśli tak, ustawić w konfiguracji Odoo list_db = False lub zablokować ścieżkę na poziomie firewalla.
2. Hasło główne zarządzania bazami danych ustawić jako długie i losowe i nie zapisywać go w żadnym miejscu, które ktokolwiek inny może odczytać.

7. Sprawdzić kopię zapasową, a nie tylko ją skonfigurować

1. Skonfigurować automatyczną, regularną kopię zapasową, przechowywaną oddzielnie od serwera Odoo.
2. Przynajmniej raz faktycznie ją przywrócić i sprawdzić, czy odtwarzanie działa — niesprawdzona kopia to przypuszczenie.

Żaden z tych kroków nie zastępuje innego. Kto wdroży tylko jeden z nich, wzmocnił jedne drzwi, a wszystkie pozostałe zostawił otwarte — kto wdroży wszystkie siedem, ma obronę, która wytrzyma nawet wtedy, gdy zawiedzie pojedyncza warstwa.

Czego ta architektura nie zastępuje

Żaden z opisanych środków nie czyni staranności zbędną. Moduł, który odrzuca sondy .env, nie czyni niegroźnym przypadkowo opublikowanego pliku .env. Uwierzytelnianie dwuskładnikowe nie chroni przed użytkownikiem, który odczytuje swój kod rozmówcy przez telefon. A firewall nie zastępuje decyzji o tym, kto faktycznie potrzebuje jakiego uprawnienia. Architektura bezpieczeństwa tworzy warunki, w których pojedynczy błąd nie staje się od razu incydentem — nie zwalnia nikogo ze staranności.

Najczęstsze pytania

Czy silne hasło wystarczy, by zabezpieczyć Odoo 19?

Nie. Hasło można skraść gdzie indziej, zupełnie niezależnie od jego jakości, i wtedy działa w każdej usłudze, która akceptuje to samo hasło. Dopiero połączenie z uwierzytelnianiem dwuskładnikowym, firewallem przed systemem i sensowną strukturą uprawnień daje zabezpieczenie, które wytrzyma także po skradzieniu hasła.

Jak włączyć uwierzytelnianie dwuskładnikowe w Odoo 19?

Zainstalować moduł „Two-Factor Authentication (TOTP)” przez zarządzanie aplikacjami, następnie w Ustawienia → Ustawienia ogólne → Uprawnienia włączyć wymuszanie i wybrać między „Tylko pracownicy” a „Wszyscy użytkownicy”. Każdy użytkownik konfiguruje potem swój własny drugi składnik za pomocą kodu QR.

Czym jest lista RBL i dlaczego Odoo jej potrzebuje?

RBL (Real-time Blackhole List) to dostępna przez HTTP lista adresów, którą może wczytać praktycznie każdy firewall. Samo Odoo nie dostarcza takiej listy — nasz moduł Web RBL zamyka tę lukę, rozpoznając ruch atakujący we własnym dzienniku aplikacji i przekazując go jako listę RBL z powrotem firewallowi stojącemu przed systemem.

Czy Odoo 19 Community bez modułów dodatkowych jest wystarczająco zabezpieczone?

Nie w pełni. Bez modułu Password Policy nie ma minimalnej długości haseł, bez Two-Factor Authentication nie ma drugiego składnika, a bez modułu takiego jak Web RBL Odoo nie rozpoznaje ani prób sondowania, ani powtarzanych prób logowania ponad restartem. Wszystkie cztery można doposażyć bezpłatnie.

Dostępność

Web RBL jest publicznie dostępny na licencji AGPL-3 i u nas działa produkcyjnie na pięciu stronach:

github.com/Alex0176/odoo-web-rbl

Pełny opis funkcji ze wszystkimi wzorcami, oceną i listami zagrożeń znajduje się w poprzednim artykule: Web RBL – lista blokad dla ruchu atakującego na własnych stronach.

Pytania, uwagi i zgłoszenia błędów przyjmujemy z przyjemnością — najchętniej jako zgłoszenie (issue) na GitHubie.