Odoo 19 güvenlik mimarisi: Güvenlik duvarı, 2FA, yetkiler ve Web RBL'yi doğru birleştirme

Odoo, beş web sitemizde açık internetten erişilebilir durumdadır ve bu bir istisna değil, olağan durumdur: Bir teklif, bir mağaza veya bir müşteri girişi işleten herkesin herkese açık bir sunucusu vardır. Tek bir savunmasız parola, unutulmuş bir yapılandırma dosyası veya fazla cömert verilmiş bir yetki, herkese açık bir sunucunun açık bir sunucuya dönüşmesi için yeterlidir.

Bu yazı, Odoo 19'u nasıl doğru şekilde güvenceye alacağınızı gösteriyor — tek bir önlemle değil, birbirini tamamlayan birden çok katmanla: Güvenlik duvarı ve ters proxy, açık kaynaklı modülümüz Web RBL, iki faktörlü kimlik doğrulama, parola politikası ve yetkiler — ve bunların her birinin gerçekte hangi saldırı girişimlerini yakaladığı. Sonunda, kendi Odoo kurulumunuza uyarlayabileceğiniz adım adım bir kılavuz yer alıyor.

Derinlemesine savunma: Neden tek bir önlem asla yetmez

Her güvenlik önleminin bir açığı vardır. Bir güvenlik duvarı, bir Odoo oturum açma formunda olup bitenleri görmez. Güçlü bir parola, başka bir yerde çoktan çalınmışsa koruyamaz. Bir yetki yapısı, henüz oturum bile açmamış bir saldırgana karşı işe yaramaz. Bu açıkları kapatan ilkenin adı derinlemesine savunmadır (defense in depth): Her biri tek başına aşılabilecek, ama hepsi birlikte aşılamayacak birden çok bağımsız katman.

Bizde dört katman var, her birinin görevi farklı:

• Güvenlik duvarı / ters proxy — açıkça kötü niyetli olanı sunucuya daha ulaşmadan uzak tutar
• Web RBL — iki tarafı birbirine bağlar: Odoo, güvenlik duvarının hiç göremeyeceği şeyi kendi uygulama günlüğünden öğrenir ve bunu ona geri besler
• Odoo'nun kendisi — iki faktörlü kimlik doğrulama, parola politikası, yetkiler, oturum yönetimi
• Veri tabanı & işletim — yedekleme, yönetime erişim koruması, hiçbir günlükte yer almayan sırlar

Aşağıdaki bölümler her katmanı tek tek ele alıyor.

Katman 1: Güvenlik duvarı ve ters proxy

Güvenlik duvarı, bir isteği gören ilk merkezdir ve bir saldırganı sunucudaki her hizmetten uzak tutabilen tek merkezdir — yalnızca web sitesinden değil, posta sunucusundan, VPN erişiminden ve kendi yönetim arayüzünden de. Bu noktada nelerin etkinleştirilmesinin anlamlı olduğu üreticiye bağlıdır, ancak yapı taşları OPNsense, pfSense, HAProxy, FortiGate, Sophos veya Check Point'te aynıdır:

RBL listeleri: İtibarın sunulduğu standart yol

RBL, Real-time Blackhole List anlamına gelir; e-posta dünyasından bir terimdir: Satır başına bir adres, HTTP üzerinden alınabilir, düzenli olarak yeniden yüklenir. Neredeyse her güvenlik duvarı böyle bir listeyi okuyabilir ve ondan kurallar oluşturabilir — OPNsense ve pfSense URL Table Alias olarak, HAProxy ACL dosyası olarak, FortiGate External Block List olarak, Palo Alto External Dynamic List olarak; Cisco, Sophos, Juniper ve MikroTik aynı ilke için kendi adlarıyla.

Tam da burada kendi modülümüz devreye giriyor — ve tam da burada ikinci katman başlıyor.

Katman 2: Web RBL — uygulama ile güvenlik duvarı arasındaki köprü

Bir güvenlik duvarı paketleri görür, uygulama mantığını değil. /xmlrpc/2/common için yapılan bir isteğin oturum açma denemesi olduğunu, on dört saniyede yirmi farklı yolun bir tarayıcı anlamına geldiğini ya da bir adresin az önce bir parolayı başarıyla tahmin ettiğini bilmez. Bunların hepsini yalnızca Odoo'nun kendisi bilir. Web RBL, açık kaynaklı kendi modülümüz (AGPL-3), bu bilgiyi kullanılabilir kılar — Odoo'nun kendisi için ve RBL listesi olarak sunulduğunda öndeki güvenlik duvarı için de.

Tehdit listeleri sürekli karşılaştırılır, her biri kendi kademesiyle.

Önceki yazıda ayrıntılı olarak anlatılanların kısa özeti:

• Yollarda desen tanıma: .env dosyaları, .git dizinleri, yapılandırma dosyaları, WordPress ve PHP probları, yol geçişi (path traversal), yeni yapay zeka arayüzleri üzerinden komut yürütme
• Yeniden başlatmalar boyunca sayan oturum açma savunması — Odoo'nun belleğinde yaşayan kendi sayacından farklı olarak
• Her adresin 0 ile 100 arasında puanlanması, gerekçesi düz metinle
• Yanlış yapılandırmalar (QNAP, Autodiscover, Synology) tespit edilir ve asla engellenmez, çünkü bir engel arızayı gidermez, yalnızca gizler
• Spamhaus, FireHOL ve Tor çıkış düğümleri gibi yabancı tehdit listeleri, sürekli karşılaştırılır
• Asla engellenmemesi gereken adresler için izin listesi

Bu yazı için iki özellik özellikle önemlidir, çünkü doğrudan güvenlik duvarı ve oturum açma ile ilgilidir.

Durağan bir liste, güvenilebilecek bir listedir

İzin listesi — asla engellenmeyen adresler, örneğin kendi konum bağlantıları — genellikle nadiren değişir. Değeri tam olarak budur, eksikliği değil: Sakin bir liste günlerce neredeyse hiç hareket etmiyorsa, her nadir değişiklik hemen göze çarpar. Günlük otomatik güncelleme, çok şey değişeceği için değil, nadir değişikliğin elle eklenmesi gerekmesin diye vardır — ve insanın unuttuğu nokta tam da burasıdır. Geçen ayki kendi yanlış yapılandırmalarımızdan biri tam olarak böyle fark edildi: çok sayıda olayla değil, bir müşterinin QNAP web API'si yanlışlıkla engellenene kadar kimsenin bilmediği tek olayla. O zamandan beri QNAP, asla engellenmeyip yalnızca bildirilen yanlış yapılandırmalar listesinde yer alıyor.

Oturum açma, bir güvenlik duvarının görmediği yerdir

Bir güvenlik duvarı bir adresi engelleyebilir. Bir oturum açmanın başarılı olup olmadığını bilemez ve özellikle de kısa süre önce hâlâ erişim bilgileri arayan bir adresten gelip gelmediğini hiç bilemez. Web RBL bilir: Ayarlanabilir bir eşik değerinden itibaren puan, oturum açmayı tümüyle yasaklar ve şüpheli bir adresten gelen başarılı bir oturum açma bildirilir — bu, bir sonraki katmana bağlantı halkasıdır.

Katman 3: Odoo'nun kendisini güvenceye alma

İki faktörlü kimlik doğrulama: Yeniden kullanılamayan ikinci bir sır

Parolaların en büyük sorunu kaliteleri değil, yeniden kullanılmalarıdır. Başka bir hizmette çalınmış bir parola, aynı olduğu sürece bizde de aynı şekilde çalışır. İki faktörlü kimlik doğrulama (2FA, TOTP olarak da adlandırılır) buna ikinci bir sır karşı koyar: Her otuz saniyede bir değişen ve yalnızca kendi akıllı telefonunuzun bildiği bir sırdan hesaplanan altı haneli bir kod. Böylece çalınmış bir parola tek başına artık yetmez.

Odoo 19 Community bunu yerleşik olarak sunar — kurulabilir bir modül olarak Two-Factor Authentication (TOTP), bir e-posta yedek seçeneğiyle tamamlanmış. Her kullanıcı bunu kendisi için, QR kodu ile, her yaygın kimlik doğrulayıcı uygulamayla kurar:

Kurulum: QR kodunu tara, altı haneli kodu bir kez onayla, bitti.

Ancak bu tek başına yalnızca kendi kendine kuranlara yardımcı olur — ve deneyim, zorunluluk olmadan bunun azınlıkta kaldığını gösteriyor. Bu yüzden Odoo bir zorunlu kılma politikası sunar: ya yalnızca çalışanlar (dahili kullanıcılar) için ya da portal kullanıcıları dahil herkes için. İkinci sır kurulmadan hiç kimse oturum açma formunu, en azından e-posta koduyla onaylamadan geçemez.

Parola politikası: Asgari uzunluk kendiliğinden anlaşılır bir şey değildir

Ek modül olmadan Odoo Community, parolalar için hiçbir asgari uzunluğa güvenmez — kimse engellemezse bir kullanıcı üç karakterlik bir parola belirleyebilir. Kendi Password Policy modülü tam da bu açığı kapatır: Yalnızca tarayıcıda önerilmekle kalmayıp sunucu tarafında uygulanan bir asgari uzunluk. Daha fazlasını isteyen — zorunlu bir geçerlilik süresi, yeniden kullanıma karşı bir geçmiş — bunun için bir OCA veya üçüncü taraf modülüne ihtiyaç duyar; Community sürümünde bu bilerek yalın tutulmuştur.

Yetkiler: Yalnızca ihtiyacı olan erişim alır

Odoo kendiliğinden üç düzeyi ayırır: Portal kullanıcıları (yalnızca kendi müşteri veya tedarikçi portalı), dahili kullanıcılar (arka uç, uygulama başına haklarla) ve yöneticiler (teknik ayarlar dahil sınırsız erişim). En sık yapılan hata fazla zayıf bir parola değil, fazla cömert verilmiş bir yönetici rolüdür: Yalnızca fatura düzenlemesi gereken, sistem ayarlarına erişime ihtiyaç duymaz.

İki ilke yükün çoğunu taşır:

İkisi de, iki faktörlü kimlik doğrulamanın kurulduğu aynı görünümde denetlenebilir:

Bir genel bakış, dört kaldıraç: Parola, ikinci faktör, API anahtarları, oturum açmış cihazlar.

Oturumlar ve cihazlar: Şu an kim oturum açmış

Aynı görünüm, bir hesabın şu anda hangi cihazlardan oturum açtığını da gösterir — ve tek bir cihazın veya hepsinin birden oturumunu kapatmaya izin verir. Kaybolmuş bir dizüstü bilgisayardan veya ele geçirilmiş bir parola şüphesinden sonra bu, en hızlı etkili adımdır: Oturum, parolanın zaten değiştirilip değiştirilmediğinden bağımsız olarak hemen sona erer.

Katman 4: Veri tabanı ve işletim

Dördüncü katman en az görünür olanıdır ve aynı zamanda en affedilmez olanıdır, çünkü burada yapılan bir hata, daha önce kurulan her şeyi boşa çıkarabilir.

• Sunucunun kendisinden ayrı saklanan düzenli, doğrulanmış yedeklemeler. Hiç geri yüklenmemiş bir yedek, bir varsayımdır, yedek değildir.
• Sırlar hiçbir günlük dosyasında yer almamalıdır. Parolalar, API anahtarları, lisans verileri — kendi eklentilerini yazanlar, bunlara ana parolanın kendisi gibi davranmalıdır: hiçbir yerde kaydetmemeli, “yalnızca hata ayıklamak için” bile.
• Modülleri güncel tutun, özellikle üçüncü taraf modülleri. Ücretsiz ek modüller (OCA ve diğerleri) doğası gereği yeni Odoo sürümlerinin gerisinde kalır; her kurulumdan önce hangi bağımlılıkların otomatik olarak geldiğine bir göz atmakta fayda var.

Oturum açma yolunun bütünü

Dört katman, ayrı odalarda birbiri ardına değil, aynı istek üzerinde, kademe kademe çalışır. Bu en açık biçimde bir oturum açma örneğinde görülür:

Kötü niyetli bir isteğin asıl hedefe ulaşmadan önce sonlanabileceği beş nokta — ve yetkili bir kullanıcının hepsinden geçtiği yalnızca tek bir yol.

Saldırı senaryoları ve karşı önlemler

Aşağıdaki genel bakış, gerçek saldırı desenlerini onları gerçekte durduran katmanlara eşler. Bunların birçoğu kuram değil, beş web sitemizdeki on yedi günlük gerçek trafikten kendi gözlemlerimizdir.

Adım adım: Kendi Odoo kurulumunuzu güvenceye alın

Aşağıdaki sıra, bizim de kendimiz izleyeceğimiz sıradır — en büyük etkiden en ince ayara doğru.

1. İki faktörlü kimlik doğrulamayı zorunlu kılın

1. Henüz kurulu değilse: Uygulamalar'ı açın, “Two-Factor Authentication” arayın ve kurun (birden çok web sitesi varsa ek olarak yedek seçenek olarak “Two-Factor Authentication by Mail” önerilir).
2. Ayarlar → Genel Ayarlar → Yetkiler'i açın.
3. “İki faktörlü kimlik doğrulamayı zorunlu kıl” seçeneğini etkinleştirin.
4. Politikayı seçin: Dahili kullanıcılar için “Yalnızca çalışanlar”, portal kullanıcıları (erişimi olan müşteriler) de dahil edilecekse “Tüm kullanıcılar”.
5. Kaydedin. Bir sonraki oturum açma denemesinden itibaren Odoo, ikinci sırrı kurulmamış her kullanıcıdan, kimlik doğrulayıcı uygulamayı kurana kadar en azından e-posta kodunu ister.

2. Parolalar için bir asgari uzunluk belirleyin

1. Uygulamalar'ı açın, “Password Policy” arayın ve kurun.
2. Ayarlar → Genel Ayarlar → Yetkiler'i açın.
3. “Parolanın asgari uzunluğu”nu ayarlayın — on iki karakter makul bir başlangıç değeridir.
4. Kaydedin. Kural, şu andan itibaren her yeni veya değiştirilen parola ataması için geçerlidir, mevcut parolalar için geriye dönük değildir.

3. Yetkileri gözden geçirin

1. Ayarlar → Kullanıcılar & Şirketler → Kullanıcılar'ı açın.
2. Her kullanıcıyı tek tek açın ve uygulama başına erişim haklarının bulunduğu sekmeyi denetleyin: Bu kişi gerçekten “Yönetici” veya “Administrator”a mı ihtiyaç duyuyor, yoksa “Kullanıcı” yeterli mi?
3. Özellikle denetleyin: “Ayarlar”'ın kendisine kimin erişimi var? Bu çok küçük bir grup olmalıdır.
4. Her harici bağlantı (muhasebe, kendi betikleri, zaman kaydı) için ilgili teknik kullanıcının “Hesap güvenliği” sekmesinde, kullanıcı parolasını vermek yerine kendi API anahtarını oluşturun.

4. Web RBL'yi kurun ve devreye almadan önce gözlemleyin

1. Modülü şuradan github.com/Alex0176/odoo-web-rbl alıp eklenti yoluna koyun ve kurun.
2. Birkaç gün gözlemleyin: Web RBL → Değerlendirme menüsü, hangi desenlerin gerçekten devreye girdiğini gösterir.
3. Ancak bundan sonra web_rbl.sperren_aktiv seçeneğini açın (Ayarlar → Teknik → Sistem parametreleri) — bu noktadan itibaren tespit edilen problar gerçekten reddedilir.
4. Engelleme listesini, modülde belirtilen belirteçle korunan adres altında güvenlik duvarına RBL listesi olarak ekleyin (OPNsense/pfSense'te URL Table Alias olarak, HAProxy'de ACL dosyası olarak).

5. Güvenlik duvarının kendisini güvenceye alın

1. Güvenlik duvarının yönetim arayüzüne yalnızca iç ağdan erişilebilir kılın, asla web sitesiyle aynı herkese açık adres üzerinden değil.
2. Üretici sunuyorsa, güvenlik duvarı yazılımı için otomatik güvenlik güncellemelerini etkinleştirin.
3. TLS yapılandırmasını denetleyin: Yalnızca güncel protokol sürümleri, eski şifreleme yöntemlerini devre dışı bırakın.
4. Varsa: Bilinen bir itibar listesini (örneğin Spamhaus DROP) doğrudan güvenlik duvarına ekleyin — Web RBL'den bağımsız olarak, çünkü güvenlik duvarı böylece Odoo'ya hiç ulaşmayan hizmetlere giden trafiği de görür.

6. Veri tabanı yönetimini kapatın

1. /web/database/manager'a dışarıdan erişilip erişilemediğini denetleyin — erişilebiliyorsa Odoo yapılandırmasında list_db = False ayarlayın veya yolu güvenlik duvarı düzeyinde engelleyin.
2. Veri tabanı yönetiminin ana parolasını uzun ve rastgele belirleyin ve başka hiç kimsenin okuyabileceği hiçbir yere not etmeyin.

7. Yedeklemeyi yalnızca kurmayın, denetleyin

1. Odoo sunucusundan ayrı saklanan, otomatik ve düzenli bir yedekleme kurun.
2. En az bir kez gerçekten geri yükleyin ve geri yüklemenin işleyip işlemediğini denetleyin — denetlenmemiş bir yedek bir varsayımdır.

Bu adımların hiçbiri diğerinin yerini tutmaz. Yalnızca birini uygulayan, bir kapıyı güçlendirmiş ve diğerlerini açık bırakmıştır — yedisini birden uygulayan ise tek bir katman başarısız olsa bile hâlâ ayakta kalan bir savunmaya sahiptir.

Bu mimarinin yerini tutmadığı şeyler

Anlatılan önlemlerin hiçbiri özeni gereksiz kılmaz. .env problarını reddeden bir modül, yanlışlıkla yayımlanmış bir .env dosyasını tehlikesiz yapmaz. İki faktörlü kimlik doğrulama, kodunu telefonda arayan birine okuyan bir kullanıcıya karşı koruma sağlamaz. Ve bir güvenlik duvarı, kimin hangi yetkiye gerçekten ihtiyaç duyduğuna dair bir kararın yerini tutmaz. Güvenlik mimarisi, tek bir hatanın hemen bir olaya dönüşmediği koşulları yaratır — kimseyi özen göstermekten kurtarmaz.

Sık sorulan sorular

Odoo 19'u güvenceye almak için güçlü bir parola yeterli mi?

Hayır. Bir parola, kalitesinden tamamen bağımsız olarak başka bir yerde çalınabilir ve o zaman aynı parolayı kabul eden her hizmette çalışır. Ancak iki faktörlü kimlik doğrulama, öndeki bir güvenlik duvarı ve anlamlı bir yetki yapısıyla birleşimi, çalınmış bir parolanın ardından da ayakta kalan bir koruma sağlar.

Odoo 19'da iki faktörlü kimlik doğrulamayı nasıl etkinleştiririm?

“Two-Factor Authentication (TOTP)” modülünü Uygulamalar yönetiminden kurun, ardından Ayarlar → Genel Ayarlar → Yetkiler altında zorunlu kılmayı etkinleştirin ve “Yalnızca çalışanlar” ile “Tüm kullanıcılar” arasında seçim yapın. Ardından her kullanıcı kendi ikinci faktörünü QR kodu ile kurar.

RBL listesi nedir ve Odoo'nun neden ona ihtiyacı var?

RBL (Real-time Blackhole List), neredeyse her güvenlik duvarının okuyabildiği, HTTP üzerinden alınabilen bir adres listesidir. Odoo'nun kendisi böyle bir liste sunmaz — Web RBL modülümüz, saldırı trafiğini kendi uygulama günlüğünden tespit edip RBL listesi olarak öndeki güvenlik duvarına geri vererek bu açığı kapatır.

Ek modülsüz Odoo 19 Community yeterince güvenceye alınmış mıdır?

Tam olarak değil. Password Policy modülü olmadan parolalar için asgari uzunluk yoktur, Two-Factor Authentication olmadan ikinci faktör yoktur ve Web RBL gibi bir modül olmadan Odoo ne yoklama girişimlerini ne de yeniden başlatmalar boyunca tekrarlanan oturum açma denemelerini tespit eder. Dördü de ücretsiz olarak sonradan eklenebilir.

Kullanılabilirlik

Web RBL, AGPL-3 altında herkese açık olarak sunulmaktadır ve bizde beş web sitesinde canlı olarak çalışmaktadır:

github.com/Alex0176/odoo-web-rbl

Tüm desenleri, puanlamayı ve tehdit listelerini içeren eksiksiz işlev açıklaması önceki yazıda yer alıyor: Web RBL – Kendi web sitelerindeki saldırı trafiği için engelleme listesi.

Sorularınızı, yorumlarınızı ve hata raporlarınızı memnuniyetle alırız — en çok GitHub'da bir Issue olarak.