Αρχιτεκτονική ασφαλείας Odoo 19: σωστός συνδυασμός firewall, 2FA, δικαιωμάτων και Web RBL

Το Odoo είναι προσβάσιμο από το ανοικτό διαδίκτυο στις πέντε ιστοσελίδες μας, και αυτό δεν αποτελεί εξαίρεση αλλά τον κανόνα: όποιος διατηρεί μια προσφορά, ένα κατάστημα ή μια σύνδεση πελατών, διαθέτει δημόσιο server. Ένας μόνο ευάλωτος κωδικός πρόσβασης, ένα ξεχασμένο αρχείο ρυθμίσεων ή ένα υπερβολικά γενναιόδωρο δικαίωμα αρκεί για να γίνει ένας δημόσιος server ανοικτός.

Αυτό το άρθρο δείχνει πώς μπορείτε να θωρακίσετε σωστά το Odoo 19 — όχι με ένα μεμονωμένο μέτρο, αλλά με πολλά επίπεδα που αλληλοσυμπληρώνονται: firewall και reverse proxy, το module ανοικτού κώδικα που αναπτύξαμε Web RBL, έλεγχος ταυτότητας δύο παραγόντων, πολιτική κωδικών πρόσβασης και δικαιώματα — και ποιες απόπειρες επίθεσης αναχαιτίζει πραγματικά καθένα από αυτά. Στο τέλος υπάρχει ένας οδηγός βήμα προς βήμα, με τον οποίο μπορεί να θωρακιστεί κάθε δική σας εγκατάσταση Odoo.

Άμυνα σε βάθος: γιατί ένα μέτρο δεν αρκεί ποτέ

Κάθε μεμονωμένο μέτρο ασφαλείας έχει ένα κενό. Ένα firewall δεν βλέπει τι συμβαίνει σε μια φόρμα σύνδεσης του Odoo. Ένας ισχυρός κωδικός πρόσβασης δεν προστατεύει αν έχει ήδη κλαπεί αλλού. Μια δομή δικαιωμάτων δεν βοηθά απέναντι σε έναν επιτιθέμενο που δεν έχει καν συνδεθεί ακόμη. Η αρχή που κλείνει αυτά τα κενά ονομάζεται άμυνα σε βάθος (defense in depth): πολλά ανεξάρτητα επίπεδα, καθένα από τα οποία μόνο του θα μπορούσε να παρακαμφθεί — όλα μαζί όμως όχι.

Σε εμάς είναι τέσσερα επίπεδα, καθένα με διαφορετικό έργο:

• Firewall / reverse proxy — κρατά μακριά ό,τι είναι ολοφάνερα κακόβουλο, πριν καν φτάσει στον server
• Web RBL — συνδέει τις δύο πλευρές: το Odoo μαθαίνει από το δικό του αρχείο καταγραφής εφαρμογής ό,τι το firewall δεν μπορεί να δει, και το τροφοδοτεί πίσω σε αυτό
• Το ίδιο το Odoo — έλεγχος ταυτότητας δύο παραγόντων, πολιτική κωδικών πρόσβασης, δικαιώματα, διαχείριση συνεδριών
• Βάση δεδομένων & λειτουργία — αντίγραφα ασφαλείας, προστασία πρόσβασης στη διαχείριση, μυστικά εκτός κάθε αρχείου καταγραφής

Οι επόμενες ενότητες εξετάζουν καθένα από τα επίπεδα χωριστά.

Επίπεδο 1: Firewall και reverse proxy

Το firewall είναι η πρώτη αρχή που βλέπει ένα αίτημα, και η μόνη που μπορεί να κρατήσει έναν επιτιθέμενο μακριά από κάθε υπηρεσία του server — όχι μόνο από την ιστοσελίδα, αλλά και από τον mail server, την πρόσβαση VPN και τη δική του διεπαφή διαχείρισης. Τι ενεργοποιείται λογικά σε αυτό το σημείο εξαρτάται από τον κατασκευαστή, αλλά οι βασικές μορφές είναι οι ίδιες σε OPNsense, pfSense, HAProxy, FortiGate, Sophos ή Check Point:

Λίστες RBL: ο τυπικός δρόμος διανομής της φήμης

Το RBL σημαίνει Real-time Blackhole List, όρος από τον κόσμο του email: μία διεύθυνση ανά γραμμή, προσβάσιμη μέσω HTTP, επαναφορτωμένη τακτικά. Σχεδόν κάθε firewall μπορεί να διαβάσει μια τέτοια λίστα και να δημιουργήσει κανόνες από αυτήν — OPNsense και pfSense ως URL Table Alias, HAProxy ως αρχείο ACL, FortiGate ως External Block List, Palo Alto ως External Dynamic List, Cisco, Sophos, Juniper και MikroTik με δικές τους ονομασίες για την ίδια αρχή.

Ακριβώς εδώ παρεμβαίνει το δικό μας module — και ακριβώς εδώ αρχίζει το δεύτερο επίπεδο.

Επίπεδο 2: Web RBL — η γέφυρα ανάμεσα στην εφαρμογή και το firewall

Ένα firewall βλέπει πακέτα, όχι λογική εφαρμογής. Δεν ξέρει ότι ένα αίτημα για /xmlrpc/2/common είναι απόπειρα σύνδεσης, ότι είκοσι διαφορετικές διαδρομές σε δεκατέσσερα δευτερόλεπτα είναι σαρωτής, ή ότι μια διεύθυνση μόλις μάντεψε με επιτυχία έναν κωδικό πρόσβασης. Όλα αυτά τα γνωρίζει μόνο το ίδιο το Odoo. Web RBL, το δικό μας module ανοικτού κώδικα (AGPL-3), καθιστά αυτή τη γνώση αξιοποιήσιμη — για το ίδιο το Odoo και, διανεμόμενη ως λίστα RBL, και για το firewall που βρίσκεται μπροστά του.

Λίστες απειλών που αντιπαραβάλλονται διαρκώς, καθεμία με δικό της επίπεδο.

Σε σύντομη περίληψη, όσα περιγράφονται αναλυτικά στο προηγούμενο άρθρο:

• Αναγνώριση μοτίβων σε διαδρομές: αρχεία .env, κατάλογοι .git, αρχεία ρυθμίσεων, ανιχνευτές WordPress και PHP, path traversal, εκτέλεση εντολών μέσω νέων διεπαφών ΤΝ
• Άμυνα σύνδεσης που μετρά πέρα από τις επανεκκινήσεις — σε αντίθεση με τον δικό του μετρητή του Odoo, που ζει στη μνήμη
• Βαθμολόγηση κάθε διεύθυνσης από 0 έως 100, με αιτιολόγηση σε καθαρό κείμενο
• Εσφαλμένες ρυθμίσεις (QNAP, Autodiscover, Synology) αναγνωρίζονται και δεν αποκλείονται ποτέ, επειδή ένας αποκλεισμός δεν διορθώνει το ελάττωμα, απλώς το κρύβει
• Ξένες λίστες απειλών όπως Spamhaus, FireHOL και κόμβοι εξόδου Tor, που αντιπαραβάλλονται διαρκώς
• Λευκή λίστα για διευθύνσεις που δεν πρέπει ποτέ να αποκλειστούν

Για αυτό το άρθρο δύο ιδιότητες είναι ιδιαίτερα σημαντικές, επειδή συνδέονται άμεσα με το firewall και με τη σύνδεση.

Μια νωθρή λίστα είναι μια λίστα που μπορείτε να εμπιστευτείτε

Η λευκή λίστα — διευθύνσεις που δεν αποκλείονται ποτέ, για παράδειγμα οι δικές μας συνδέσεις τοποθεσιών — αλλάζει κατά κανόνα σπάνια. Αυτή ακριβώς είναι η αξία της, όχι το μειονέκτημά της: όταν μια ήρεμη λίστα σχεδόν δεν κινείται για ημέρες, κάθε σπάνια αλλαγή προκαλεί αμέσως προσοχή. Η καθημερινή αυτόματη ενημέρωση δεν υπάρχει επειδή θα άλλαζαν πολλά, αλλά για να μη χρειάζεται η σπάνια αλλαγή να καταχωρίζεται με το χέρι — και ακριβώς εκεί είναι το σημείο όπου την ξεχνά κανείς. Μία από τις δικές μας εσφαλμένες ρυθμίσεις τον περασμένο μήνα εντοπίστηκε ακριβώς έτσι: όχι από πολλά γεγονότα, αλλά από το ένα που δεν γνώριζε κανείς, μέχρι που το web API QNAP ενός πελάτη αποκλείστηκε κατά λάθος. Από τότε το QNAP βρίσκεται στη λίστα των εσφαλμένων ρυθμίσεων που δεν αποκλείονται ποτέ, αλλά μόνο αναφέρονται.

Η σύνδεση είναι το σημείο που ένα firewall δεν βλέπει

Ένα firewall μπορεί να αποκλείσει μια διεύθυνση. Δεν μπορεί να ξέρει αν μια σύνδεση πέτυχε, πολύ περισσότερο αν προήλθε από διεύθυνση που λίγο νωρίτερα αναζητούσε ακόμη διαπιστευτήρια. Το Web RBL μπορεί: μια βαθμολογία πάνω από ένα ρυθμιζόμενο όριο απαγορεύει εντελώς τη σύνδεση, και μια επιτυχής σύνδεση από ύποπτη διεύθυνση αναφέρεται — αυτός είναι ο κρίκος προς το επόμενο επίπεδο.

Επίπεδο 3: Θωράκιση του ίδιου του Odoo

Έλεγχος ταυτότητας δύο παραγόντων: ένα δεύτερο μυστικό που δεν επαναχρησιμοποιείται

Το μεγαλύτερο πρόβλημα των κωδικών πρόσβασης δεν είναι η ποιότητά τους, αλλά η επαναχρησιμοποίησή τους. Ένας κωδικός που κλάπηκε σε άλλη υπηρεσία λειτουργεί και σε εμάς εξίσου, αρκεί να είναι ο ίδιος. Ο έλεγχος ταυτότητας δύο παραγόντων (2FA, γνωστός και ως TOTP) του αντιτάσσει ένα δεύτερο μυστικό: έναν εξαψήφιο κωδικό που αλλάζει κάθε τριάντα δευτερόλεπτα και υπολογίζεται από ένα μυστικό που γνωρίζει μόνο το δικό σας smartphone. Ένας κλεμμένος κωδικός πρόσβασης από μόνος του δεν αρκεί πια.

Το Odoo 19 Community το περιλαμβάνει ενσωματωμένο — ως εγκαταστάσιμο module Two-Factor Authentication (TOTP), συμπληρωμένο με εναλλακτική επιλογή μέσω email. Κάθε χρήστης το ρυθμίζει μόνος του, με κωδικό QR, με οποιαδήποτε συνηθισμένη εφαρμογή authenticator:

Η ρύθμιση: σάρωση του κωδικού QR, επιβεβαίωση του εξαψήφιου κωδικού μία φορά, και τελειώσατε.

Αυτό όμως βοηθά μόνο όσους το ρυθμίζουν μόνοι τους — και η εμπειρία δείχνει ότι χωρίς υποχρέωση αυτοί παραμένουν η μειονότητα. Γι' αυτό το Odoo γνωρίζει μια πολιτική επιβολής: είτε μόνο για υπαλλήλους (εσωτερικούς χρήστες) είτε για όλους, συμπεριλαμβανομένων των χρηστών portal. Χωρίς ρυθμισμένο δεύτερο μυστικό, κανείς δεν περνά πια τη φόρμα σύνδεσης χωρίς να το επιβεβαιώσει τουλάχιστον με κωδικό email.

Πολιτική κωδικών πρόσβασης: ένα ελάχιστο μήκος δεν είναι αυτονόητο

Χωρίς πρόσθετο module, το Odoo Community δεν βασίζεται σε κανένα ελάχιστο μήκος κωδικών πρόσβασης — ένας χρήστης μπορεί να ορίσει κωδικό τριών χαρακτήρων, αν κανείς δεν τον εμποδίζει. Το module Password Policy κλείνει ακριβώς αυτό το κενό: ένα ελάχιστο μήκος που επιβάλλεται στην πλευρά του server, όχι απλώς προτείνεται στο πρόγραμμα περιήγησης. Όποιος θέλει περισσότερα — υποχρεωτικό χρόνο λήξης, ιστορικό κατά της επαναχρησιμοποίησης — χρειάζεται γι' αυτό ένα module OCA ή τρίτου· στην έκδοση Community αυτό διατηρείται σκόπιμα λιτό.

Δικαιώματα: πρόσβαση παίρνει μόνο όποιος τη χρειάζεται

Το Odoo διακρίνει εξαρχής τρία επίπεδα: χρήστες portal (μόνο το δικό τους portal πελάτη ή προμηθευτή), εσωτερικοί χρήστες (το backend, με δικαιώματα ανά εφαρμογή) και διαχειριστές (απεριόριστη πρόσβαση μαζί με τις τεχνικές ρυθμίσεις). Το συχνότερο λάθος δεν είναι ένας υπερβολικά αδύναμος κωδικός πρόσβασης, αλλά ένας υπερβολικά γενναιόδωρα ανατεθειμένος ρόλος διαχειριστή: όποιος πρέπει μόνο να εκδίδει τιμολόγια, δεν χρειάζεται πρόσβαση στις ρυθμίσεις συστήματος.

Δύο αρχές σηκώνουν το μεγαλύτερο βάρος:

Και τα δύο μπορούν να ελεγχθούν στην ίδια προβολή όπου ρυθμίζεται και ο έλεγχος ταυτότητας δύο παραγόντων:

Μία επισκόπηση, τέσσερις μοχλοί: κωδικός πρόσβασης, δεύτερος παράγοντας, κλειδιά API, συνδεδεμένες συσκευές.

Συνεδρίες και συσκευές: ποιος είναι συνδεδεμένος αυτή τη στιγμή

Η ίδια προβολή δείχνει επίσης από ποιες συσκευές είναι συνδεδεμένος αυτή τη στιγμή ένας λογαριασμός — και επιτρέπει την αποσύνδεση μιας μεμονωμένης ή όλων ταυτόχρονα. Μετά από χαμένο laptop ή υποψία παραβιασμένου κωδικού πρόσβασης, αυτό είναι το ταχύτερο αποτελεσματικό βήμα: η συνεδρία τερματίζεται αμέσως, ανεξάρτητα από το αν ο κωδικός έχει ήδη αλλάξει.

Επίπεδο 4: Βάση δεδομένων και λειτουργία

Το τέταρτο επίπεδο είναι το λιγότερο ορατό και ταυτόχρονα το πιο ασυγχώρητο, επειδή ένα λάθος εδώ μπορεί να εκμηδενίσει όλα όσα χτίστηκαν πριν.

• Τακτικά, ελεγμένα αντίγραφα ασφαλείας, αποθηκευμένα χωριστά από τον ίδιο τον server. Ένα αντίγραφο ασφαλείας που δεν επαναφέρθηκε ποτέ, είναι υπόθεση, όχι αντίγραφο ασφαλείας.
• Τα μυστικά δεν ανήκουν σε κανένα αρχείο καταγραφής. Κωδικοί πρόσβασης, κλειδιά API, στοιχεία αδειών — όποιος γράφει δικές του επεκτάσεις, πρέπει να τα αντιμετωπίζει όπως τον ίδιο τον κύριο κωδικό πρόσβασης: να μην τα καταγράφει πουθενά, ούτε «μόνο για αποσφαλμάτωση».
• Κρατήστε τα modules ενημερωμένα, και ιδίως τα modules τρίτων. Τα ελεύθερα πρόσθετα modules (OCA και άλλα) μένουν εκ φύσεως πίσω από τις νέες εκδόσεις του Odoo· πριν από κάθε εγκατάσταση αξίζει να ελέγξετε ποιες εξαρτήσεις έρχονται αυτόματα μαζί.

Η διαδρομή σύνδεσης συνολικά

Τα τέσσερα επίπεδα δεν δρουν διαδοχικά σε χωριστούς χώρους, αλλά πάνω στο ίδιο αίτημα, βήμα προς βήμα. Στο παράδειγμα μιας σύνδεσης αυτό φαίνεται πιο καθαρά:

Πέντε σημεία όπου μπορεί να τελειώσει ένα κακόβουλο αίτημα πριν φτάσει στον πραγματικό στόχο — και μόνο ένα όπου ένας εξουσιοδοτημένος χρήστης τα περνά όλα.

Σενάρια επίθεσης και η άμυνά τους

Η παρακάτω επισκόπηση αντιστοιχίζει πραγματικά μοτίβα επίθεσης στα επίπεδα που τα σταματούν πράγματι. Αρκετά από αυτά δεν είναι θεωρία, αλλά δικές μας παρατηρήσεις από δεκαεπτά ημέρες πραγματικής κίνησης στις πέντε ιστοσελίδες μας.

Βήμα προς βήμα: θωράκιση της δικής σας εγκατάστασης Odoo

Η παρακάτω σειρά είναι εκείνη με την οποία θα προχωρούσαμε και οι ίδιοι — από τη μεγαλύτερη επίδραση προς την πιο λεπτή ρύθμιση.

1. Επιβολή ελέγχου ταυτότητας δύο παραγόντων

1. Αν δεν έχει ήδη εγκατασταθεί: ανοίξτε τις Εφαρμογές, αναζητήστε το «Two-Factor Authentication» και εγκαταστήστε το (με πολλές ιστοσελίδες συνιστάται επιπλέον το «Two-Factor Authentication by Mail» ως εναλλακτική επιλογή).
2. Ανοίξτε Ρυθμίσεις → Γενικές ρυθμίσεις → Δικαιώματα.
3. Ενεργοποιήστε το «Επιβολή ελέγχου ταυτότητας δύο παραγόντων».
4. Επιλέξτε πολιτική: «Μόνο υπάλληλοι» για εσωτερικούς χρήστες, «Όλοι οι χρήστες», αν πρέπει να συμπεριληφθούν και οι χρήστες portal (πελάτες με πρόσβαση).
5. Αποθηκεύστε. Από την επόμενη απόπειρα σύνδεσης το Odoo ζητά από κάθε χρήστη χωρίς ρυθμισμένο δεύτερο μυστικό τουλάχιστον τον κωδικό email, μέχρι να ρυθμίσει την εφαρμογή authenticator.

2. Ορισμός ελάχιστου μήκους για κωδικούς πρόσβασης

1. Ανοίξτε τις Εφαρμογές, αναζητήστε το «Password Policy» και εγκαταστήστε το.
2. Ανοίξτε Ρυθμίσεις → Γενικές ρυθμίσεις → Δικαιώματα.
3. Ορίστε το «Ελάχιστο μήκος κωδικού πρόσβασης» — δώδεκα χαρακτήρες είναι μια λογική αφετηρία.
4. Αποθηκεύστε. Ο κανόνας ισχύει αμέσως για κάθε νέο ή αλλαγμένο κωδικό πρόσβασης, αναδρομικά όχι για τους υπάρχοντες κωδικούς.

3. Έλεγχος των δικαιωμάτων

1. Ανοίξτε Ρυθμίσεις → Χρήστες & Εταιρείες → Χρήστες.
2. Ανοίξτε κάθε χρήστη χωριστά και ελέγξτε την καρτέλα με τα δικαιώματα πρόσβασης ανά εφαρμογή: Χρειάζεται πραγματικά αυτό το άτομο «Διευθυντή» ή «Διαχειριστή», ή αρκεί «Χρήστης»;
3. Ελέγξτε ιδιαίτερα: Ποιος έχει πρόσβαση στις ίδιες τις «Ρυθμίσεις»; Αυτή πρέπει να είναι πολύ μικρή ομάδα.
4. Για κάθε εξωτερική σύνδεση (λογιστική, δικά σας scripts, καταγραφή χρόνου) δημιουργήστε στην καρτέλα «Ασφάλεια λογαριασμού» του αντίστοιχου τεχνικού χρήστη ένα δικό του κλειδί API, αντί να δώσετε τον κωδικό πρόσβασης του χρήστη.

4. Εγκατάσταση του Web RBL και παρατήρηση πριν από την ενεργοποίηση

1. Τοποθετήστε το module από github.com/Alex0176/odoo-web-rbl στη διαδρομή των addons και εγκαταστήστε το.
2. Παρατηρήστε για μερικές ημέρες: το μενού Web RBL → Ανάλυση δείχνει ποια μοτίβα πράγματι ενεργοποιούνται.
3. Μόνο μετά ενεργοποιήστε το web_rbl.sperren_aktiv (Ρυθμίσεις → Τεχνικά → Παράμετροι συστήματος) — από εδώ και πέρα οι αναγνωρισμένοι ανιχνευτές απορρίπτονται πραγματικά.
4. Ενσωματώστε τη λίστα αποκλεισμού στο firewall ως λίστα RBL, από τη διεύθυνση που αναγράφεται στο module και προστατεύεται με token (στο OPNsense/pfSense ως URL Table Alias, στο HAProxy ως αρχείο ACL).

5. Θωράκιση του ίδιου του firewall

1. Κάντε τη διεπαφή διαχείρισης του firewall προσβάσιμη αποκλειστικά από το εσωτερικό δίκτυο, ποτέ μέσω της ίδιας δημόσιας διεύθυνσης με την ιστοσελίδα.
2. Ενεργοποιήστε τις αυτόματες ενημερώσεις ασφαλείας για το λογισμικό του firewall, εφόσον το προσφέρει ο κατασκευαστής.
3. Ελέγξτε τη ρύθμιση TLS: μόνο τρέχουσες εκδόσεις πρωτοκόλλου, απενεργοποιήστε τις ξεπερασμένες μεθόδους κρυπτογράφησης.
4. Αν είναι διαθέσιμο: ενσωματώστε μια γνωστή λίστα φήμης (π.χ. Spamhaus DROP) απευθείας στο firewall — ανεξάρτητα από το Web RBL, επειδή το firewall βλέπει έτσι και την κίνηση προς υπηρεσίες που το Odoo δεν φτάνει ποτέ.

6. Κλείσιμο της διαχείρισης βάσεων δεδομένων

1. Ελέγξτε αν το /web/database/manager είναι προσβάσιμο απ' έξω — αν ναι, ορίστε στη ρύθμιση του Odoo list_db = False ή αποκλείστε τη διαδρομή σε επίπεδο firewall.
2. Ορίστε τον κύριο κωδικό πρόσβασης της διαχείρισης βάσεων δεδομένων μακρύ και τυχαίο και μην τον σημειώσετε σε κανένα σημείο που μπορεί να διαβάσει οποιοσδήποτε άλλος.

7. Έλεγχος του αντιγράφου ασφαλείας, όχι μόνο ρύθμιση

1. Ρυθμίστε ένα αυτόματο, τακτικό αντίγραφο ασφαλείας, αποθηκευμένο χωριστά από τον server Odoo.
2. Επαναφέρετε το αντίγραφο τουλάχιστον μία φορά πραγματικά και ελέγξτε αν λειτουργεί η επαναφορά — ένα αντίγραφο ασφαλείας που δεν έχει ελεγχθεί είναι υπόθεση.

Κανένα από αυτά τα βήματα δεν αντικαθιστά κάποιο από τα άλλα. Όποιος υλοποιεί μόνο ένα από αυτά, έχει ενισχύσει μία πόρτα και έχει αφήσει όλες τις άλλες ανοικτές — όποιος υλοποιεί και τα επτά, έχει μια άμυνα που αντέχει ακόμη κι όταν αποτύχει ένα μεμονωμένο επίπεδο.

Τι δεν αντικαθιστά αυτή η αρχιτεκτονική

Κανένα από τα μέτρα που περιγράφονται δεν καθιστά περιττή τη σχολαστικότητα. Ένα module που απορρίπτει ανιχνευτές .env δεν κάνει ακίνδυνο ένα αρχείο .env που δημοσιεύτηκε κατά λάθος. Ο έλεγχος ταυτότητας δύο παραγόντων δεν προστατεύει από έναν χρήστη που υπαγορεύει τον κωδικό του σε κάποιον που τηλεφωνεί. Και ένα firewall δεν αντικαθιστά την απόφαση για το ποιος χρειάζεται πραγματικά ποιο δικαίωμα. Η αρχιτεκτονική ασφαλείας δημιουργεί τις συνθήκες υπό τις οποίες ένα μεμονωμένο λάθος δεν γίνεται αμέσως συμβάν — δεν απαλλάσσει κανέναν από τη σχολαστικότητα.

Συχνές ερωτήσεις

Αρκεί ένας ισχυρός κωδικός πρόσβασης για να θωρακιστεί το Odoo 19;

Όχι. Ένας κωδικός πρόσβασης μπορεί να κλαπεί αλλού, εντελώς ανεξάρτητα από την ποιότητά του, και λειτουργεί τότε σε κάθε υπηρεσία που δέχεται τον ίδιο κωδικό. Μόνο ο συνδυασμός με έλεγχο ταυτότητας δύο παραγόντων, ένα firewall μπροστά και μια λογική δομή δικαιωμάτων δίνει μια θωράκιση που αντέχει και μετά από κλεμμένο κωδικό πρόσβασης.

Πώς ενεργοποιώ τον έλεγχο ταυτότητας δύο παραγόντων στο Odoo 19;

Εγκαταστήστε το module «Two-Factor Authentication (TOTP)» μέσω της διαχείρισης Εφαρμογών, στη συνέχεια ενεργοποιήστε την επιβολή στο Ρυθμίσεις → Γενικές ρυθμίσεις → Δικαιώματα και επιλέξτε ανάμεσα σε «Μόνο υπάλληλοι» και «Όλοι οι χρήστες». Κάθε χρήστης ρυθμίζει έπειτα τον δικό του δεύτερο παράγοντα με κωδικό QR.

Τι είναι μια λίστα RBL και γιατί τη χρειάζεται το Odoo;

Το RBL (Real-time Blackhole List) είναι μια λίστα διευθύνσεων προσβάσιμη μέσω HTTP, την οποία μπορεί να διαβάσει σχεδόν κάθε firewall. Το ίδιο το Odoo δεν παρέχει τέτοια λίστα — το module μας Web RBL καλύπτει αυτό το κενό, αναγνωρίζοντας την κίνηση επίθεσης από το δικό του αρχείο καταγραφής εφαρμογής και επιστρέφοντάς την ως λίστα RBL στο firewall που βρίσκεται μπροστά.

Είναι το Odoo 19 Community επαρκώς θωρακισμένο χωρίς πρόσθετα modules;

Όχι πλήρως. Χωρίς το module Password Policy δεν υπάρχει ελάχιστο μήκος κωδικών πρόσβασης, χωρίς το Two-Factor Authentication δεν υπάρχει δεύτερος παράγοντας, και χωρίς ένα module όπως το Web RBL το Odoo δεν αναγνωρίζει ούτε απόπειρες ανίχνευσης ούτε επαναλαμβανόμενες απόπειρες σύνδεσης πέρα από μια επανεκκίνηση. Και τα τέσσερα μπορούν να προστεθούν δωρεάν.

Διαθεσιμότητα

Το Web RBL διατίθεται δημόσια υπό την AGPL-3 και τρέχει σε παραγωγή σε πέντε ιστοσελίδες μας:

github.com/Alex0176/odoo-web-rbl

Η πλήρης περιγραφή λειτουργιών με όλα τα μοτίβα, τη βαθμολόγηση και τις λίστες απειλών βρίσκεται στο προηγούμενο άρθρο: Web RBL – λίστα αποκλεισμού για την κίνηση επίθεσης στις δικές σας ιστοσελίδες.

Ερωτήσεις, παρατηρήσεις και αναφορές σφαλμάτων δεχόμαστε ευχαρίστως — κατά προτίμηση ως Issue στο GitHub.