Γιατί η επεξεργασία ενός αρχείου .ovpn δεν μπορεί να ενεργοποιήσει MFA στον διακομιστή

Προσθέτετε auth-user-pass σε ένα προφίλ, επανασυνδέεστε και ο πελάτης ζητά όνομα χρήστη και κωδικό πρόσβασης. Φαίνεται ότι το MFA είναι ενεργό. Έπειτα πληκτρολογείτε έναν κωδικό από λάθος λογαριασμό, ή έναν κωδικό που έληξε πριν από δέκα λεπτά, και η σήραγγα ανεβαίνει παρ’ όλα αυτά. Αυτό είναι το σύμπτωμα: ο πελάτης άλλαξε, ο διακομιστής όχι. Ένας κωδικός μίας χρήσης είναι παράγοντας μόνο όταν ένας επαληθευτής στον διακομιστή αποφασίζει αν είναι έγκυρος για την ταυτότητα που τον διεκδικεί.

Το αίτημα αποδεικνύει μόνο ότι ο πελάτης ρώτησε, τίποτε άλλο

Ένα αρχείο .ovpn είναι έγγραφο στην πλευρά του πελάτη. Μπορεί να πει στον πελάτη να ζητήσει διαπιστευτήρια, να τα αποθηκεύσει προσωρινά ή να σταματήσει να το κάνει. Δεν μπορεί να καταχωρίσει χρήστη, να εγκαταστήσει μονάδα PAM ή να κάνει τον διακομιστή να απαιτεί δεύτερο παράγοντα που δεν ελέγχει τώρα.

Ούτε η εγκατάσταση εφαρμογής ελέγχου ταυτότητας σε τηλέφωνο δημιουργεί αυτή τη σχέση. Το έργο Google Authenticator PAM είναι συστατικό επαλήθευσης OTP που μπορεί να βρίσκεται πίσω από το OpenVPN; δεν είναι τρόπος να κολλήσετε τη σύνδεση λογαριασμού Google σε ένα εισαγόμενο προφίλ.

Η καταχώριση είναι το μέρος που ένα προφίλ δεν μπορεί να κάνει

Το TOTP χρειάζεται υλικό καταχώρισης κοινόχρηστο μεταξύ της εφαρμογής ελέγχου ταυτότητας και του επαληθευτή της. Τα έξι ψηφία στο τηλέφωνο είναι έξοδος· ο σπόρος πίσω τους είναι το μυστικό και ανήκει σε μία ταυτότητα.

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

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

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

Διαβάστε τη στοίβα PAM για το τι απαιτείται στην πραγματικότητα

Μια γραμμή όπως account required pam_permit.so δεν υλοποιεί επιλεξιμότητα λογαριασμού και δεν προσθέτει παράγοντα. Επιτρέπει εκείνο το στάδιο διαχείρισης λογαριασμών PAM, που είναι δήλωση για ένα στάδιο και όχι για τους χρήστες σας.

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

Ταιριάξτε την αλληλεπίδραση του πελάτη με τον σχεδιασμό του διακομιστή

auth-user-pass

Αυτή η οδηγία ζητά εισαγωγή ονόματος χρήστη και κωδικού. Δεν ρυθμίζει το PAM, δεν δημιουργεί εγγραφή καταχώρισης και δεν λέει στον διακομιστή ότι το πεδίο κωδικού περιέχει τιμή TOTP. Η ενσωμάτωση στον διακομιστή και ο πελάτης πρέπει να συμφωνήσουν σε αλληλεπίδραση που υποστηρίζει πραγματικά η ανάπτυξη: πρόκληση, τεκμηριωμένη συνδυασμένη μορφή διαπιστευτηρίων ή ροή ειδική για το προϊόν.

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

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

Επανασυνδέσεις, διακριτικά και το τεστ που ξεκαθαρίζει το ζήτημα

Σχεδιάστε τι συμβαίνει μετά την πρώτη επιτυχημένη σύνδεση. Ένας κωδικός που έγινε δεκτός προηγουμένως μπορεί να έχει λήξει ή να απορριφθεί ως επανάληψη στην επόμενη επαλήθευση. Το auth-nocache ελέγχει τη διατήρηση διαπιστευτηρίων και δεν εγκαθιστά MFA, και το reneg-sec 0 δεν είναι ορισμός υποστήριξης TOTP, όσο συχνά κι αν εμφανίζεται σε νήματα φόρουμ.

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

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