Το 2010 η εταιρεία υπήρχαν 50 διακομιστές και ένα απλό μοντέλο δικτύου: backend, frontend και firewall. Ο αριθμός των διακομιστών αυξήθηκε, το μοντέλο έγινε πιο περίπλοκο: σταδιοποίηση, απομονωμένα VLAN με ACL, μετά VPN με VRF, VLAN με ACL στο L2, VRF με ACL στο L3. Το κεφάλι γυρίζει; Θα είναι πιο διασκεδαστικό αργότερα.
Όταν υπήρχαν 16 διακομιστές, κατέστη αδύνατο να λειτουργήσει χωρίς δάκρυα με τόσα πολλά ετερογενή τμήματα. Καταλήξαμε λοιπόν σε άλλη λύση. Πήραμε τη στοίβα του Netfilter, προσθέσαμε το Consul σε αυτό ως πηγή δεδομένων και αποκτήσαμε ένα γρήγορο κατανεμημένο τείχος προστασίας. Αντικατέστησαν τα ACL σε δρομολογητές και τα χρησιμοποίησαν ως εξωτερικό και εσωτερικό τείχος προστασίας. Για τη δυναμική διαχείριση του εργαλείου, αναπτύξαμε το σύστημα BEFW, το οποίο χρησιμοποιήθηκε παντού: από τη διαχείριση της πρόσβασης των χρηστών στο δίκτυο προϊόντων έως την απομόνωση τμημάτων δικτύου μεταξύ τους.
Θα σας πει πώς λειτουργούν όλα και γιατί πρέπει να ρίξετε μια πιο προσεκτική ματιά σε αυτό το σύστημα. Ιβάν Αγκάρκοφ () είναι επικεφαλής της ομάδας ασφάλειας υποδομής του τμήματος Συντήρησης στο κέντρο ανάπτυξης του Μινσκ της εταιρείας. Ο Ivan είναι θαυμαστής του SELinux, λατρεύει την Perl και γράφει κώδικα. Ως επικεφαλής της ομάδας ασφάλειας πληροφοριών, εργάζεται τακτικά με αρχεία καταγραφής, αντίγραφα ασφαλείας και Ε&Α για την προστασία του Wargaming από τους χάκερ και τη διασφάλιση της λειτουργίας όλων των διακομιστών παιχνιδιών στην εταιρεία.
Ιστορικά στοιχεία
Πριν σας πω πώς το κάναμε, θα σας πω πώς καταλήξαμε σε αυτό αρχικά και γιατί χρειαζόταν. Για να το κάνουμε αυτό, ας πάμε 9 χρόνια πίσω: 2010, μόλις εμφανίστηκε το World of Tanks. Το Wargaming είχε περίπου 50 διακομιστές.
Διάγραμμα ανάπτυξης διακομιστή εταιρείας.
Είχαμε ένα μοντέλο δικτύου. Για εκείνη την εποχή ήταν το βέλτιστο.
Μοντέλο δικτύου το 2010.
Υπάρχουν κακοί στο μπροστινό μέρος που θέλουν να μας σπάσουν, αλλά έχει τείχος προστασίας. Δεν υπάρχει τείχος προστασίας στο backend, αλλά υπάρχουν 50 διακομιστές εκεί, τους γνωρίζουμε όλους. Όλα λειτουργούν καλά.
Σε 4 χρόνια, ο στόλος των διακομιστών αυξήθηκε 100 φορές, σε 5000. Εμφανίστηκαν τα πρώτα απομονωμένα δίκτυα - σταδιακά: δεν μπορούσαν να πάνε στην παραγωγή και συχνά υπήρχαν πράγματα που έτρεχαν εκεί που θα μπορούσαν να είναι επικίνδυνα.
Μοντέλο δικτύου το 2014.
Με αδράνεια, χρησιμοποιήσαμε τα ίδια κομμάτια υλικού και όλη η εργασία πραγματοποιήθηκε σε μεμονωμένα VLAN: Τα ACL γράφονται στα VLAN, τα οποία επιτρέπουν ή αρνούνται κάποιο είδος σύνδεσης.
Το 2016, ο αριθμός των διακομιστών έφτασε τους 8000. Το Wargaming απορρόφησε άλλα στούντιο και εμφανίστηκαν επιπλέον δίκτυα συνεργατών. Φαίνονται να είναι δικά μας, αλλά όχι αρκετά: το VLAN συχνά δεν λειτουργεί για συνεργάτες, πρέπει να χρησιμοποιήσετε VPN με VRF, η απομόνωση γίνεται πιο περίπλοκη. Το μείγμα μόνωσης ACL μεγάλωσε.
Μοντέλο δικτύου το 2016.
Μέχρι τις αρχές του 2018, ο στόλος των μηχανημάτων είχε αυξηθεί στις 16. Υπήρχαν 000 τμήματα και δεν μετρήσαμε τα υπόλοιπα, συμπεριλαμβανομένων των κλειστών στα οποία αποθηκεύονταν οικονομικά στοιχεία. Έχουν εμφανιστεί δίκτυα κοντέινερ (Kubernetes), DevOps, δίκτυα cloud συνδεδεμένα μέσω VPN, για παράδειγμα, από ένα IVS. Υπήρχαν πολλοί κανόνες - ήταν επώδυνο.
Μοντέλο δικτύου και μέθοδοι απομόνωσης το 2018.
Για απομόνωση χρησιμοποιήσαμε: VLAN με ACL στο L2, VRF με ACL στο L3, VPN και πολλά άλλα. Πάρα πολύ.
Προβλήματα
Όλοι ζουν με ACL και VLAN. Τι τρέχει? Σε αυτό το ερώτημα θα απαντήσει ο Χάρολντ, κρύβοντας τον πόνο.
Υπήρχαν πολλά προβλήματα, αλλά ήταν πέντε τεράστια.
- Γεωμετρική αύξηση τιμών για νέους κανόνες. Κάθε νέος κανόνας χρειαζόταν περισσότερο χρόνο για να προστεθεί από τον προηγούμενο, γιατί ήταν απαραίτητο να δούμε πρώτα αν υπήρχε ήδη τέτοιος κανόνας.
- Δεν υπάρχει τείχος προστασίας μέσα στα τμήματα. Τα τμήματα ήταν κατά κάποιο τρόπο διαχωρισμένα το ένα από το άλλο και δεν υπήρχαν ήδη αρκετοί πόροι μέσα.
- Οι κανόνες εφαρμόζονταν για πολύ καιρό. Οι χειριστές μπορούσαν να γράψουν έναν τοπικό κανόνα με το χέρι σε μια ώρα. Η παγκόσμια κράτησε αρκετές μέρες.
- Δυσκολίες με τους κανόνες ελέγχου. Πιο συγκεκριμένα, δεν ήταν δυνατό. Οι πρώτοι κανόνες γράφτηκαν το 2010 και οι περισσότεροι από τους συγγραφείς τους δεν εργάζονταν πλέον για την εταιρεία.
- Χαμηλό επίπεδο ελέγχου υποδομής. Αυτό είναι το κύριο πρόβλημα - δεν ξέραμε πολύ καλά τι συνέβαινε στη χώρα μας.
Έτσι έμοιαζε ένας μηχανικός δικτύου το 2018 όταν άκουσε: «Χρειάζομαι λίγο ακόμα ACL».
Λύσεις
Στις αρχές του 2018 αποφασίστηκε να γίνει κάτι γι' αυτό.
Η τιμή των ενσωματώσεων αυξάνεται συνεχώς. Το σημείο εκκίνησης ήταν ότι τα μεγάλα κέντρα δεδομένων σταμάτησαν να υποστηρίζουν απομονωμένα VLAN και ACL επειδή οι συσκευές εξάντλησαν τη μνήμη.
Λύση: αφαιρέσαμε τον ανθρώπινο παράγοντα και αυτοματοποιήσαμε την παροχή πρόσβασης στο μέγιστο.
Οι νέοι κανόνες χρειάζονται πολύ χρόνο για να εφαρμοστούν. Λύση: επιταχύνετε την εφαρμογή των κανόνων, κάντε την κατανεμημένη και παράλληλη. Αυτό απαιτεί ένα κατανεμημένο σύστημα έτσι ώστε οι κανόνες να παραδίδονται μόνοι τους, χωρίς rsync ή SFTP σε χίλια συστήματα.
Δεν υπάρχει τείχος προστασίας μέσα στα τμήματα. Ένα τείχος προστασίας εντός τμημάτων άρχισε να έρχεται σε εμάς όταν εμφανίστηκαν διαφορετικές υπηρεσίες στο ίδιο δίκτυο. Λύση: χρησιμοποιήστε ένα τείχος προστασίας σε επίπεδο κεντρικού υπολογιστή - τείχη προστασίας που βασίζονται σε κεντρικό υπολογιστή. Σχεδόν παντού όπου έχουμε Linux, και παντού που έχουμε iptables, αυτό δεν είναι πρόβλημα.
Δυσκολίες με τους κανόνες ελέγχου. Λύση: Διατηρήστε όλους τους κανόνες σε ένα μέρος για έλεγχο και διαχείριση, ώστε να μπορούμε να ελέγξουμε τα πάντα.
Χαμηλό επίπεδο ελέγχου στις υποδομές. Λύση: κάντε μια απογραφή όλων των υπηρεσιών και των προσβάσεων μεταξύ τους.
Αυτή είναι περισσότερο μια διοικητική διαδικασία παρά μια τεχνική. Μερικές φορές έχουμε 200-300 νέες κυκλοφορίες την εβδομάδα, ειδικά κατά τη διάρκεια των προσφορών και των αργιών. Επιπλέον, αυτό είναι μόνο για μία ομάδα των DevOps μας. Με τόσες πολλές εκδόσεις, είναι αδύνατο να δούμε ποιες θύρες, IP και ενσωματώσεις χρειάζονται. Ως εκ τούτου, χρειαζόμασταν ειδικά εκπαιδευμένους διευθυντές υπηρεσιών που ρωτούσαν τις ομάδες: «Τι υπάρχει ούτως ή άλλως και γιατί το αναφέρατε;»
Μετά από όλα όσα ξεκινήσαμε, ένας μηχανικός δικτύου το 2019 άρχισε να μοιάζει με αυτό.
Πρόξενος
Αποφασίσαμε ότι θα βάλουμε όλα όσα βρήκαμε με τη βοήθεια υπευθύνων υπηρεσιών στο Consul και από εκεί θα γράφαμε κανόνες iptables.
Πώς αποφασίσαμε να το κάνουμε αυτό;
- Θα συλλέξουμε όλες τις υπηρεσίες, τα δίκτυα και τους χρήστες.
- Ας δημιουργήσουμε κανόνες iptables με βάση αυτούς.
- Αυτοματοποιούμε τον έλεγχο.
- ....
- ΚΕΡΔΟΣ.
Το Consul δεν είναι ένα απομακρυσμένο API, μπορεί να τρέξει σε κάθε κόμβο και να γράψει σε iptables. Το μόνο που μένει είναι να βρούμε αυτόματα χειριστήρια που θα καθαρίσουν τα περιττά πράγματα και τα περισσότερα προβλήματα θα λυθούν! Τα υπόλοιπα θα τα λύσουμε όσο προχωράμε.
Γιατί Πρόξενος;
Έχει αποδειχθεί καλά. Το 2014-15, το χρησιμοποιήσαμε ως backend για το Vault, στο οποίο αποθηκεύουμε κωδικούς πρόσβασης.
Δεν χάνει δεδομένα. Κατά τη διάρκεια της χρήσης, ο Consul δεν έχασε δεδομένα κατά τη διάρκεια ενός μόνο ατυχήματος. Αυτό είναι ένα τεράστιο πλεονέκτημα για ένα σύστημα διαχείρισης τείχους προστασίας.
Οι συνδέσεις P2P επιταχύνουν την εξάπλωση των αλλαγών. Με το P2P, όλες οι αλλαγές έρχονται γρήγορα, δεν χρειάζεται να περιμένετε για ώρες.
Βολικό REST API. Θεωρήσαμε επίσης το Apache ZooKeeper, αλλά δεν έχει REST API, επομένως θα πρέπει να εγκαταστήσετε πατερίτσες.
Λειτουργεί και ως Key Vault (KV) και ως Κατάλογος (Service Discovery). Μπορείτε να αποθηκεύσετε υπηρεσίες, καταλόγους και κέντρα δεδομένων ταυτόχρονα. Αυτό είναι βολικό όχι μόνο για εμάς, αλλά και για τις γειτονικές ομάδες, γιατί όταν χτίζουμε μια παγκόσμια υπηρεσία, σκεφτόμαστε μεγάλα.
Γραμμένο στο Go, το οποίο αποτελεί μέρος της στοίβας Wargaming. Μας αρέσει αυτή η γλώσσα, έχουμε πολλούς προγραμματιστές Go.
Ισχυρό σύστημα ACL. Στο Consul, μπορείτε να χρησιμοποιήσετε ACL για να ελέγξετε ποιος γράφει τι. Εγγυόμαστε ότι οι κανόνες του τείχους προστασίας δεν θα επικαλύπτονται με τίποτα άλλο και δεν θα έχουμε προβλήματα με αυτό.
Αλλά το Consul έχει και τα μειονεκτήματά του.
- Δεν κλιμακώνεται σε ένα κέντρο δεδομένων, εκτός εάν έχετε μια επαγγελματική έκδοση. Είναι επεκτάσιμο μόνο από ομοσπονδία.
- Εξαρτάται πολύ από την ποιότητα του δικτύου και το φορτίο του διακομιστή. Το Consul δεν θα λειτουργήσει σωστά ως διακομιστής σε έναν απασχολημένο διακομιστή εάν υπάρχουν καθυστερήσεις στο δίκτυο, για παράδειγμα, ανομοιόμορφη ταχύτητα. Αυτό οφείλεται στις συνδέσεις P2P και στα μοντέλα διανομής ενημερώσεων.
- Δυσκολία παρακολούθησης διαθεσιμότητας. Στην κατάσταση του Προξένου μπορεί να πει ότι όλα είναι καλά, αλλά πέθανε πριν από πολύ καιρό.
Επιλύσαμε τα περισσότερα από αυτά τα προβλήματα χρησιμοποιώντας το Consul, γι' αυτό και το επιλέξαμε. Η εταιρεία έχει σχέδια για ένα εναλλακτικό backend, αλλά μάθαμε να αντιμετωπίζουμε προβλήματα και επί του παρόντος ζούμε με τον Consul.
Πώς λειτουργεί το Consul
Θα εγκαταστήσουμε τρεις έως πέντε διακομιστές σε ένα κέντρο δεδομένων υπό όρους. Ένας ή δύο διακομιστές δεν θα λειτουργήσουν: δεν θα μπορούν να οργανώσουν απαρτία και να αποφασίσουν ποιος έχει δίκιο και ποιος λάθος όταν τα δεδομένα δεν ταιριάζουν. Περισσότερα από πέντε δεν έχουν νόημα, η παραγωγικότητα θα πέσει.
Οι πελάτες συνδέονται με τους διακομιστές με οποιαδήποτε σειρά: οι ίδιοι πράκτορες, μόνο με τη σημαία server = false.
Μετά από αυτό, οι πελάτες λαμβάνουν μια λίστα με συνδέσεις P2P και δημιουργούν συνδέσεις μεταξύ τους.
Σε παγκόσμιο επίπεδο, συνδέουμε πολλά κέντρα δεδομένων. Συνδέουν επίσης P2P και επικοινωνούν.
Όταν θέλουμε να ανακτήσουμε δεδομένα από άλλο κέντρο δεδομένων, το αίτημα πηγαίνει από διακομιστή σε διακομιστή. Αυτό το σχήμα ονομάζεται Πρωτόκολλο Serf. Το πρωτόκολλο Serf, όπως και το Consul, αναπτύσσεται από τη HashiCorp.
Μερικά σημαντικά στοιχεία για τον πρόξενο
Ο Πρόξενος έχει τεκμηρίωση που περιγράφει πώς λειτουργεί. Θα δώσω μόνο επιλεγμένα στοιχεία που αξίζει να γνωρίζετε.
Οι διακομιστές του προξένου επιλέγουν έναν κύριο μεταξύ των ψηφοφόρων. Ο Consul επιλέγει έναν κύριο από τη λίστα των διακομιστών για κάθε κέντρο δεδομένων και όλα τα αιτήματα πηγαίνουν μόνο σε αυτό, ανεξάρτητα από τον αριθμό των διακομιστών. Το πάγωμα του πλοιάρχου δεν οδηγεί σε επανεκλογή. Εάν δεν επιλεγεί ο κύριος, τα αιτήματα δεν εξυπηρετούνται από κανέναν.
Θέλατε οριζόντια κλιμάκωση; Λυπάμαι, όχι.
Ένα αίτημα σε άλλο κέντρο δεδομένων πηγαίνει από κύριο σε κύριο, ανεξάρτητα από τον διακομιστή στον οποίο ήρθε. Η επιλεγμένη κύρια μονάδα λαμβάνει το 100% του φορτίου, εκτός από το φορτίο σε αιτήματα προώθησης. Όλοι οι διακομιστές στο κέντρο δεδομένων διαθέτουν ένα ενημερωμένο αντίγραφο των δεδομένων, αλλά μόνο ένας ανταποκρίνεται.
Ο μόνος τρόπος κλιμάκωσης είναι να ενεργοποιήσετε τη μπαγιάτικη λειτουργία στον πελάτη.
Σε μπαγιάτικη λειτουργία, μπορείτε να απαντήσετε χωρίς απαρτία. Αυτή είναι μια λειτουργία κατά την οποία εγκαταλείπουμε τη συνοχή των δεδομένων, αλλά διαβάζουμε λίγο πιο γρήγορα από το συνηθισμένο και οποιοσδήποτε διακομιστής ανταποκρίνεται. Φυσικά, ηχογράφηση μόνο μέσω του master.
Ο Consul δεν αντιγράφει δεδομένα μεταξύ κέντρων δεδομένων. Όταν συναρμολογείται μια ομοσπονδία, κάθε διακομιστής θα έχει μόνο τα δικά του δεδομένα. Για άλλους, στρέφεται πάντα σε κάποιον άλλο.
Η ατομικότητα των λειτουργιών δεν είναι εγγυημένη εκτός συναλλαγής. Να θυμάστε ότι δεν είστε ο μόνος που μπορεί να αλλάξει τα πράγματα. Αν το θέλετε διαφορετικά, κάντε μια συναλλαγή με κλειδαριά.
Οι λειτουργίες μπλοκαρίσματος δεν εγγυώνται το κλείδωμα. Το αίτημα πηγαίνει από κύρια σε κύρια, και όχι απευθείας, επομένως δεν υπάρχει εγγύηση ότι ο αποκλεισμός θα λειτουργήσει όταν αποκλείετε, για παράδειγμα, σε άλλο κέντρο δεδομένων.
Το ACL επίσης δεν εγγυάται την πρόσβαση (σε πολλές περιπτώσεις). Το ACL ενδέχεται να μην λειτουργεί επειδή είναι αποθηκευμένο σε ένα κέντρο δεδομένων ομοσπονδίας - στο κέντρο δεδομένων ACL (Κύριο DC). Εάν το DC δεν σας απαντήσει, το ACL δεν θα λειτουργήσει.
Ένα παγωμένο master θα κάνει ολόκληρη την ομοσπονδία να παγώσει. Για παράδειγμα, υπάρχουν 10 κέντρα δεδομένων σε μια ομοσπονδία, και ένα έχει κακό δίκτυο και ένα master αποτυγχάνει. Όλοι όσοι επικοινωνούν μαζί του θα κολλήσουν σε έναν κύκλο: υπάρχει ένα αίτημα, δεν υπάρχει απάντηση σε αυτό, το νήμα παγώνει. Δεν υπάρχει τρόπος να ξέρουμε πότε θα συμβεί αυτό, απλά σε μία ή δύο ώρες θα πέσει ολόκληρη η ομοσπονδία. Δεν μπορείτε να κάνετε τίποτα για αυτό.
Η κατάσταση, η απαρτία και οι εκλογές αντιμετωπίζονται από ξεχωριστό νήμα. Επανεκλογή δεν θα γίνει, το status δεν θα δείξει τίποτα. Νομίζεις ότι έχεις ζωντανό Πρόξενο, ρωτάς και δεν γίνεται τίποτα - δεν υπάρχει απάντηση. Ταυτόχρονα, το status δείχνει ότι όλα είναι καλά.
Αντιμετωπίσαμε αυτό το πρόβλημα και έπρεπε να δημιουργήσουμε εκ νέου συγκεκριμένα τμήματα των κέντρων δεδομένων για να το αποφύγουμε.
Η επιχειρηματική έκδοση του Consul Enterprise δεν έχει μερικά από τα παραπάνω μειονεκτήματα. Έχει πολλές χρήσιμες λειτουργίες: επιλογή ψηφοφόρων, διανομή, κλιμάκωση. Υπάρχει μόνο ένα "αλλά" - το σύστημα αδειοδότησης για ένα κατανεμημένο σύστημα είναι πολύ ακριβό.
Ζωτική πειρατεία: rm -rf /var/lib/consul - μια θεραπεία για όλες τις ασθένειες του παράγοντα. Εάν κάτι δεν λειτουργεί για εσάς, απλώς διαγράψτε τα δεδομένα σας και πραγματοποιήστε λήψη των δεδομένων από ένα αντίγραφο. Το πιθανότερο είναι ότι ο Πρόξενος θα εργαστεί.
BEFW
Τώρα ας μιλήσουμε για το τι προσθέσαμε στο Consul.
είναι αρκτικόλεξο για BackEndFοργήWόλα. Έπρεπε να ονομάσω το προϊόν με κάποιο τρόπο όταν δημιούργησα το αποθετήριο για να βάλω τις πρώτες δοκιμαστικές δεσμεύσεις σε αυτό. Αυτό το όνομα παραμένει.
Πρότυπα κανόνων
Οι κανόνες είναι γραμμένοι σε σύνταξη iptables.
- -N BEFW
- -P ΠΤΩΣΗ ΕΙΣΟΔΟΥ
- -A INPUT -m κατάσταση—κατάσταση ΣΧΕΤΙΚΟ, ΕΓΚΑΤΑΣΤΑΤΟ -j ACCEPT
- -A ΕΙΣΟΔΟΣ -i lo -j ΑΠΟΔΟΧΗ
- -A INPUT -j BEFW
Όλα μπαίνουν στην αλυσίδα BEFW, εκτός ESTABLISHED, RELATED και localhost. Το πρότυπο μπορεί να είναι οτιδήποτε, αυτό είναι απλώς ένα παράδειγμα.
Πώς είναι χρήσιμο το BEFW;
Υπηρεσίες
Έχουμε μια υπηρεσία, έχει πάντα μια θύρα, έναν κόμβο στον οποίο τρέχει. Από τον κόμβο μας, μπορούμε να ρωτήσουμε τοπικά τον πράκτορα και να μάθουμε ότι έχουμε κάποιο είδος υπηρεσίας. Μπορείτε επίσης να βάλετε ετικέτες.
Οποιαδήποτε υπηρεσία εκτελείται και είναι εγγεγραμμένη στο Consul μετατρέπεται σε κανόνα iptables. Έχουμε SSH - ανοιχτή θύρα 22. Το σενάριο Bash είναι απλό: curl και iptables, δεν χρειάζεται τίποτα άλλο.
Πελάτες
Πώς να ανοίξετε την πρόσβαση όχι σε όλους, αλλά επιλεκτικά; Προσθέστε λίστες IP στο χώρο αποθήκευσης KV με βάση το όνομα της υπηρεσίας.
Για παράδειγμα, θέλουμε όλοι στο δέκατο δίκτυο να έχουν πρόσβαση στην υπηρεσία SSH_TCP_22. Προσθήκη ενός μικρού πεδίου TTL; και τώρα έχουμε προσωρινές άδειες, για παράδειγμα, για μια μέρα.
Προσβάσεις
Συνδέουμε υπηρεσίες και πελάτες: έχουμε μια υπηρεσία, η αποθήκευση KV είναι έτοιμη για καθεμία. Τώρα δίνουμε πρόσβαση όχι σε όλους, αλλά επιλεκτικά.
Ομάδες
Αν γράφουμε χιλιάδες IP για πρόσβαση κάθε φορά, θα κουραστούμε. Ας καταλήξουμε σε ομαδοποιήσεις - ένα ξεχωριστό υποσύνολο στο KV. Ας το ονομάσουμε ψευδώνυμο (ή ομάδες) και ας αποθηκεύσουμε ομάδες εκεί σύμφωνα με την ίδια αρχή.
Ας συνδεθούμε: τώρα μπορούμε να ανοίξουμε το SSH όχι ειδικά για P2P, αλλά για μια ολόκληρη ομάδα ή πολλές ομάδες. Με τον ίδιο τρόπο, υπάρχει TTL - μπορείτε να προσθέσετε σε μια ομάδα και να αφαιρέσετε από την ομάδα προσωρινά.
ολοκλήρωση
Το πρόβλημά μας είναι ο ανθρώπινος παράγοντας και ο αυτοματισμός. Μέχρι στιγμής το έχουμε λύσει με αυτόν τον τρόπο.
Συνεργαζόμαστε με την Puppet και μεταφέρουμε ό,τι σχετίζεται με το σύστημα (κωδικός εφαρμογής) σε αυτούς. Το Puppetdb (κανονικό PostgreSQL) αποθηκεύει μια λίστα υπηρεσιών που εκτελούνται εκεί, μπορούν να βρεθούν ανά τύπο πόρων. Εκεί μπορείτε να μάθετε ποιος κάνει αίτηση που. Έχουμε επίσης ένα σύστημα αιτήματος έλξης και αιτήματος συγχώνευσης για αυτό.
Γράψαμε το befw-sync, μια απλή λύση που βοηθά στη μεταφορά δεδομένων. Πρώτον, τα cookie συγχρονισμού είναι προσβάσιμα από το puppetdb. Εκεί διαμορφώνεται ένα API HTTP: ζητάμε ποιες υπηρεσίες διαθέτουμε, τι πρέπει να γίνει. Στη συνέχεια κάνουν ένα αίτημα στον πρόξενο.
Υπάρχει ένταξη; Ναι: έγραψαν τους κανόνες και επέτρεψαν την αποδοχή των αιτημάτων έλξης. Χρειάζεστε μια συγκεκριμένη θύρα ή να προσθέσετε έναν κεντρικό υπολογιστή σε κάποια ομάδα; Τραβήξτε το αίτημα, αναθεωρήστε - όχι άλλο "Βρείτε 200 άλλα ACL και προσπαθήστε να κάνετε κάτι γι' αυτό."
Βελτιστοποίηση
Το ping του localhost με μια κενή αλυσίδα κανόνων διαρκεί 0,075 ms.
Ας προσθέσουμε 10 διευθύνσεις iptables σε αυτήν την αλυσίδα. Ως αποτέλεσμα, το ping θα αυξηθεί 000 φορές: το iptables είναι εντελώς γραμμικό, η επεξεργασία κάθε διεύθυνσης απαιτεί λίγο χρόνο.
Για ένα τείχος προστασίας όπου μεταφέρουμε χιλιάδες ACL, έχουμε πολλούς κανόνες και αυτό εισάγει λανθάνουσα κατάσταση. Αυτό είναι κακό για τα πρωτόκολλα παιχνιδιών.
Αν όμως βάλουμε 10 διευθύνσεις σε ipset Το ping θα μειωθεί ακόμη και.
Το θέμα είναι ότι το "O" (πολυπλοκότητα αλγορίθμου) για το ipset είναι πάντα ίσο με 1, ανεξάρτητα από το πόσοι κανόνες υπάρχουν. Είναι αλήθεια ότι υπάρχει ένας περιορισμός - δεν μπορούν να υπάρχουν περισσότεροι από 65535 κανόνες. Προς το παρόν ζούμε με αυτό: μπορείτε να τους συνδυάσετε, να τους επεκτείνετε, να κάνετε δύο ipset σε ένα.
Αποθήκευση
Μια λογική συνέχεια της διαδικασίας επανάληψης είναι η αποθήκευση πληροφοριών σχετικά με πελάτες για την υπηρεσία στο ipset.
Τώρα έχουμε το ίδιο SSH και δεν γράφουμε 100 IP ταυτόχρονα, αλλά ορίζουμε το όνομα του ipset με το οποίο πρέπει να επικοινωνήσουμε και τον ακόλουθο κανόνα DROP. Μπορεί να μετατραπεί σε έναν κανόνα "Ποιος δεν είναι εδώ, ΠΕΣΤΕ", αλλά είναι πιο ξεκάθαρο.
Τώρα έχουμε κανόνες και σύνολα. Το κύριο καθήκον είναι να δημιουργήσετε ένα σύνολο πριν γράψετε τον κανόνα, γιατί διαφορετικά το iptables δεν θα γράψει τον κανόνα.
Γενικό σχέδιο
Σε μορφή διαγράμματος όλα όσα είπα μοιάζουν με αυτό.
Δεσμευόμαστε στο Puppet, όλα αποστέλλονται στον οικοδεσπότη, υπηρεσίες εδώ, ipset εκεί και όποιος δεν είναι εγγεγραμμένος εκεί δεν επιτρέπεται.
Επιτρέψτε & αρνηθείτε
Για να σώσουμε γρήγορα τον κόσμο ή να απενεργοποιήσουμε γρήγορα κάποιον, στην αρχή όλων των αλυσίδων φτιάξαμε δύο ipset: rules_allow и rules_deny. Πως δουλεύει?
Για παράδειγμα, κάποιος δημιουργεί ένα φορτίο στον Ιστό μας με bots. Προηγουμένως, έπρεπε να βρεις την IP του από τα αρχεία καταγραφής, να τη μεταφέρεις σε μηχανικούς δικτύου, ώστε να βρουν την πηγή της κίνησης και να τον απαγορεύσουν. Τώρα φαίνεται διαφορετικό.
Το στέλνουμε στον πρόξενο, περιμένουμε 2,5 δευτερόλεπτα και είναι έτοιμο. Εφόσον το Consul διανέμει γρήγορα μέσω του P2P, λειτουργεί παντού, σε οποιοδήποτε μέρος του κόσμου.
Κάποτε σταμάτησα τελείως το WOT λόγω ενός λάθους με το τείχος προστασίας. rules_allow - αυτή είναι η ασφάλειά μας για τέτοιες περιπτώσεις. Εάν κάναμε κάπου λάθος με το τείχος προστασίας, κάτι είναι μπλοκαρισμένο κάπου, μπορούμε πάντα να στείλουμε μια υπό όρους 0.0/0να μαζέψεις γρήγορα τα πάντα. Αργότερα θα τα φτιάξουμε όλα με το χέρι.
Άλλα σετ
Μπορείτε να προσθέσετε οποιαδήποτε άλλα σετ στο διάστημα $IPSETS$.
Για τι? Μερικές φορές κάποιος χρειάζεται το ipset, για παράδειγμα, για να μιμηθεί τον τερματισμό λειτουργίας κάποιου τμήματος του συμπλέγματος. Οποιοσδήποτε μπορεί να φέρει οποιαδήποτε σετ, να τα ονομάσει και θα τα παραλάβει από το Consul. Ταυτόχρονα, τα σετ μπορούν είτε να συμμετέχουν στους κανόνες του iptables είτε να λειτουργούν ως ομάδα NOOP: Η συνέπεια θα διατηρηθεί από τον δαίμονα.
Μέλη
Προηγουμένως, ήταν έτσι: ο χρήστης συνδεόταν στο δίκτυο και λάμβανε παραμέτρους μέσω του τομέα. Πριν από την εμφάνιση των τείχη προστασίας νέας γενιάς, η Cisco δεν ήξερε πώς να καταλάβει πού ήταν ο χρήστης και πού ήταν η IP. Επομένως, η πρόσβαση παραχωρήθηκε μόνο μέσω του ονόματος κεντρικού υπολογιστή του μηχανήματος.
Τι κάναμε; Κολλήσαμε τη στιγμή που λάβαμε τη διεύθυνση. Συνήθως πρόκειται για dot1x, Wi-Fi ή VPN - όλα περνούν από την RADIUS. Για κάθε χρήστη, δημιουργούμε μια ομάδα με όνομα χρήστη και τοποθετούμε μια IP σε αυτήν με ένα TTL που είναι ίσο με το dhcp.lease του - μόλις λήξει, ο κανόνας θα εξαφανιστεί.
Τώρα μπορούμε να ανοίξουμε την πρόσβαση σε υπηρεσίες, όπως σε άλλες ομάδες, με όνομα χρήστη. Έχουμε αφαιρέσει τον πόνο από τα ονόματα κεντρικών υπολογιστών όταν αλλάζουν και αφαιρέσαμε το βάρος από τους μηχανικούς δικτύου επειδή δεν χρειάζονται πλέον τη Cisco. Τώρα οι ίδιοι οι μηχανικοί καταγράφουν πρόσβαση στους διακομιστές τους.
Μόνωση
Παράλληλα, αρχίσαμε να αποσυναρμολογούμε τη μόνωση. Οι διαχειριστές υπηρεσιών έκαναν ένα απόθεμα και αναλύσαμε όλα τα δίκτυά μας. Ας τις χωρίσουμε στις ίδιες ομάδες, και στους απαραίτητους διακομιστές προστέθηκαν οι ομάδες, για παράδειγμα, για άρνηση. Τώρα η ίδια σκηνοθετική απομόνωση καταλήγει στους κανόνες_άρνηση της παραγωγής, αλλά όχι στην ίδια την παραγωγή.
Το σχήμα λειτουργεί γρήγορα και απλά: αφαιρούμε όλα τα ACL από τους διακομιστές, ξεφορτώνουμε το υλικό και μειώνουμε τον αριθμό των απομονωμένων VLAN.
Έλεγχος ακεραιότητας
Προηγουμένως, είχαμε μια ειδική ενεργοποίηση που ανέφερε όταν κάποιος άλλαζε έναν κανόνα τείχους προστασίας με μη αυτόματο τρόπο. Έγραφα ένα τεράστιο στόμιο για τον έλεγχο των κανόνων του τείχους προστασίας, ήταν δύσκολο. Η ακεραιότητα ελέγχεται πλέον από την BEFW. Φροντίζει με ζήλο ότι οι κανόνες που θέτει δεν αλλάζουν. Εάν κάποιος αλλάξει τους κανόνες του τείχους προστασίας, θα αλλάξει τα πάντα ξανά. "Έφτιαξα γρήγορα έναν πληρεξούσιο για να μπορώ να εργάζομαι από το σπίτι" - δεν υπάρχουν άλλες τέτοιες επιλογές.
Το BEFW ελέγχει το ipset από τις υπηρεσίες και τη λίστα στο befw.conf, τους κανόνες υπηρεσιών στην αλυσίδα BEFW. Αλλά δεν παρακολουθεί άλλες αλυσίδες και κανόνες και άλλα ipset.
Προστασία από σύγκρουση
Το BEFW αποθηκεύει πάντα την τελευταία γνωστή καλή κατάσταση απευθείας στη δυαδική δομή state.bin. Αν κάτι πάει στραβά, επανέρχεται πάντα σε αυτήν την κατάσταση.bin.
Πρόκειται για ασφάλεια έναντι της ασταθούς λειτουργίας Consul, όταν δεν έστειλε δεδομένα ή κάποιος έκανε λάθος και χρησιμοποίησε κανόνες που δεν μπορούν να εφαρμοστούν. Για να διασφαλιστεί ότι δεν θα μείνουμε χωρίς τείχος προστασίας, το BEFW θα επιστρέψει στην πιο πρόσφατη κατάσταση εάν παρουσιαστεί σφάλμα σε οποιοδήποτε στάδιο.
Σε κρίσιμες καταστάσεις, αυτό αποτελεί εγγύηση ότι θα μείνουμε με ένα λειτουργικό τείχος προστασίας. Ανοίγουμε όλα τα γκρίζα δίκτυα με την ελπίδα ότι θα έρθει ο διαχειριστής και θα το φτιάξει. Κάποια μέρα θα το βάλω στις ρυθμίσεις παραμέτρων, αλλά τώρα έχουμε μόλις τρία γκρι δίκτυα: 10/8, 172/12 και 192.168/16. Στο πλαίσιο του Προξένου μας, αυτό είναι ένα σημαντικό χαρακτηριστικό που μας βοηθά να εξελιχθούμε περαιτέρω.
Επίδειξη: κατά τη διάρκεια της αναφοράς, ο Ivan επιδεικνύει τη λειτουργία επίδειξης του BEFW. Είναι πιο εύκολο να παρακολουθήσετε την επίδειξη . Διαθέσιμος πηγαίος κώδικας επίδειξης .
Παγίδες
Θα σας πω για τα σφάλματα που συναντήσαμε.
ipset add set 0.0.0.0/0. Τι θα συμβεί αν προσθέσετε 0.0.0.0/0 στο ipset; Θα προστεθούν όλες οι IP; Θα είναι διαθέσιμη η πρόσβαση στο Διαδίκτυο;
Όχι, θα έχουμε ένα σφάλμα που μας κόστισε δύο ώρες διακοπής λειτουργίας. Επιπλέον, το σφάλμα δεν έχει λειτουργήσει από το 2016, βρίσκεται στο RedHat Bugzilla με αριθμό #1297092 και το βρήκαμε τυχαία - από την αναφορά προγραμματιστή.
Είναι πλέον αυστηρός κανόνας στην BEFW ότι 0.0.0.0/0 μετατρέπεται σε δύο διευθύνσεις: 0.0.0.0/1 и 128.0.0.0/1.
ipset επαναφορά σύνολο <αρχείο. Τι κάνει το ipset όταν του το λες restore? Πιστεύετε ότι λειτουργεί το ίδιο με το iptables; Θα ανακτήσει δεδομένα;
Τίποτα τέτοιο - κάνει μια συγχώνευση και οι παλιές διευθύνσεις δεν πηγαίνουν πουθενά, δεν αποκλείετε την πρόσβαση.
Βρήκαμε ένα σφάλμα κατά τη δοκιμή της απομόνωσης. Τώρα υπάρχει ένα μάλλον πολύπλοκο σύστημα - αντί για restore διεξάγεται create temp, τότε restore flush temp и restore temp. Στο τέλος της ανταλλαγής: για ατομικότητα, γιατί αν το κάνετε πρώτα flush και αυτή τη στιγμή φτάνει κάποιο πακέτο, θα απορριφθεί και κάτι θα πάει στραβά. Υπάρχει λοιπόν λίγη μαύρη μαγεία εκεί.
consul kv get -datacenter=άλλο. Όπως είπα, πιστεύουμε ότι ζητάμε κάποια δεδομένα, αλλά είτε θα λάβουμε δεδομένα είτε ένα σφάλμα. Μπορούμε να το κάνουμε αυτό μέσω του Προξένου τοπικά, αλλά σε αυτήν την περίπτωση και τα δύο θα παγώσουν.
Ο τοπικός πελάτης Consul είναι ένα περιτύλιγμα του API HTTP. Αλλά απλά κολλάει και δεν ανταποκρίνεται σε Ctrl+C, ή Ctrl+Z, ή οτιδήποτε άλλο, μόνο kill -9 στην επόμενη κονσόλα. Αυτό το συναντήσαμε όταν χτίζαμε ένα μεγάλο σύμπλεγμα. Αλλά δεν έχουμε ακόμη λύση· ετοιμαζόμαστε να διορθώσουμε αυτό το σφάλμα στο Consul.
Ο προξενητής δεν απαντά. Ο κύριος μας στο κέντρο δεδομένων δεν ανταποκρίνεται, σκεφτόμαστε: "Ίσως ο αλγόριθμος επανεπιλογής θα λειτουργήσει τώρα;"
Όχι, δεν θα λειτουργήσει και η παρακολούθηση δεν θα δείξει τίποτα: ο Πρόξενος θα πει ότι υπάρχει ένας δείκτης δέσμευσης, ένας ηγέτης βρέθηκε, όλα είναι καλά.
Πώς το αντιμετωπίζουμε αυτό; service consul restart στο cron κάθε ώρα. Εάν έχετε 50 διακομιστές, δεν υπάρχει μεγάλη υπόθεση. Όταν υπάρχουν 16 από αυτά, θα καταλάβετε πώς λειτουργεί.
Συμπέρασμα
Ως αποτέλεσμα, λάβαμε τα ακόλουθα πλεονεκτήματα:
- Κάλυψη 100% όλων των μηχανών Linux.
- Ταχύτητα.
- Αυτοματοποίηση.
- Απελευθερώσαμε μηχανικούς υλικού και δικτύων από τη σκλαβιά.
- Έχουν εμφανιστεί δυνατότητες ενσωμάτωσης που είναι σχεδόν απεριόριστες: ακόμη και με Kubernetes, ακόμη και με Ansible, ακόμη και με Python.
Μειονεκτήματα: Πρόξενος, με τον οποίο τώρα έχουμε να ζήσουμε, και το πολύ υψηλό κόστος του λάθους. Για παράδειγμα, μια φορά στις 6 μ.μ. (prime time στη Ρωσία) επεξεργαζόμουν κάτι στις λίστες των δικτύων. Κατασκευάζαμε μόνο μόνωση στο BEFW εκείνη την εποχή. Κάπου έκανα λάθος, φαίνεται ότι υπέδειξα λάθος μάσκα, αλλά όλα έπεσαν σε δύο δευτερόλεπτα. Το μόνιτορ ανάβει, ο βοηθός που έχει υπηρεσία έρχεται τρέχοντας: «Έχουμε τα πάντα!» Ο επικεφαλής του τμήματος έγινε γκρίζος όταν εξήγησε στην επιχείρηση γιατί συνέβη αυτό.
Το κόστος του λάθους είναι τόσο υψηλό που έχουμε καταλήξει στη δική μας περίπλοκη διαδικασία πρόληψης. Εάν το εφαρμόσετε σε μια μεγάλη τοποθεσία παραγωγής, δεν χρειάζεται να δώσετε ένα κύριο διακριτικό για το Consul σε όλους. Αυτό θα τελειώσει άσχημα.
Κόστος Έγραψα κώδικα μόνο για 400 ώρες. Η ομάδα μου των 4 ατόμων ξοδεύει 10 ώρες το μήνα για υποστήριξη για όλους. Σε σύγκριση με την τιμή οποιουδήποτε τείχους προστασίας νέας γενιάς, είναι δωρεάν.
Σχέδια. Το μακροπρόθεσμο σχέδιο είναι να βρεθεί εναλλακτική μεταφορά για να αντικαταστήσει ή να συμπληρώσει το Consul. Ίσως θα είναι ο Κάφκα ή κάτι παρόμοιο. Αλλά τα επόμενα χρόνια θα ζούμε στο Consul.
Άμεσα σχέδια: ενοποίηση με Fail2ban, με παρακολούθηση, με nftables, πιθανώς με άλλες διανομές, μετρήσεις, προηγμένη παρακολούθηση, βελτιστοποίηση. Η υποστήριξη της Kubernetes είναι επίσης κάπου στα σχέδια, γιατί τώρα έχουμε πολλά clusters και την επιθυμία.
Περισσότερα από τα σχέδια:
- αναζήτηση για ανωμαλίες στην κυκλοφορία.
- διαχείριση χαρτών δικτύου·
- Υποστήριξη Kubernetes.
- συναρμολόγηση πακέτων για όλα τα συστήματα.
- Web-UI.
Εργαζόμαστε συνεχώς για την επέκταση της διαμόρφωσης, την αύξηση των μετρήσεων και τη βελτιστοποίηση.
Εγγραφείτε στο έργο. Το έργο αποδείχθηκε ωραίο, αλλά, δυστυχώς, εξακολουθεί να είναι ένα έργο ενός ατόμου. Ελα σε και προσπαθήστε να κάνετε κάτι: δεσμευτείτε, δοκιμάστε, προτείνετε κάτι, δώστε την αξιολόγησή σας.
Εν τω μεταξύ προετοιμαζόμαστε για , που θα πραγματοποιηθεί στις 6 και 7 Απριλίου στην Αγία Πετρούπολη και προσκαλούμε τους προγραμματιστές συστημάτων υψηλού φορτίου . Οι έμπειροι ομιλητές ξέρουν ήδη τι πρέπει να κάνουν, αλλά για όσους αρχίζουν να μιλάνε προτείνουμε τουλάχιστον . Η συμμετοχή στο συνέδριο ως ομιλητής έχει μια σειρά από πλεονεκτήματα. Μπορείτε να διαβάσετε ποιες, για παράδειγμα, στο τέλος .
Πηγή: www.habr.com