Η αριθμητική του state table: διαστασιολόγηση firewall για floods, όχι για μέσους όρους

Ρωτήστε τους περισσότερους πόσο μεγάλο πρέπει να είναι ένα firewall και θα απαντήσουν σε bandwidth. Υπό επίθεση, το bandwidth σπάνια είναι αυτό που τελειώνει πρώτο. Ο state table είναι: η λίστα των συνδέσεων που παρακολουθεί το firewall, που έχει σταθερό μέγεθος, γεμίζει με τον ρυθμό που φτάνουν νέες συνδέσεις, και αδειάζει μόνο όσο γρήγορα επιτρέπουν τα timeouts. Καταλάβετε αυτή την αριθμητική και μπορείτε να διαστασιολογήσετε ένα firewall για τη μέρα που μετράει αντί για τη μέση μέρα.

Γιατί το state τελειώνει πριν το bandwidth

Όταν ο πίνακας είναι γεμάτος, οι νέες συνδέσεις απορρίπτονται, νόμιμες ή όχι, ακόμα κι αν οι γραμμές είναι σχεδόν αδρανείς.

Δύο είδη κίνησης γεμίζουν έναν πίνακα γρήγορα:

• SYN floods. Κάθε πλαστό SYN δημιουργεί μια μισάνοιχτη εγγραφή που δεν θα ολοκληρωθεί ποτέ.
• UDP προς δημόσιες υπηρεσίες. DNS, NTP, game servers, VoIP και παρόμοιες υπηρεσίες βλέπουν τεράστιους αριθμούς σύντομων ανταλλαγών από πολλές πηγές, και η καθεμία μπορεί να δημιουργήσει δική της εγγραφή.

Η αριθμητική

Ο αριθμός εγγραφών σε έναν πίνακα σε σταθερή κατάσταση είναι, με καλή προσέγγιση:

entries  =  new flows per second  x  seconds each entry lives

Αυτός είναι ο νόμος του Little, και είναι όλο το παιχνίδι. Ας πούμε ότι ένα flood φτάνει με 50.000 νέα SYN το δευτερόλεπτο, και οι μισάνοιχτες εγγραφές TCP ζουν 30 δευτερόλεπτα. Ο πίνακας χρειάζεται 1.500.000 εγγραφές μόνο για την επίθεση, πριν φτάσει οποιοσδήποτε πραγματικός χρήστης. Κόψτε αυτό το timeout στα 5 δευτερόλεπτα κατά το flood και η ίδια επίθεση χρειάζεται 250.000. Ίδιο firewall, ίδια μνήμη, εξαπλάσια διαφορά από έναν χρονομετρητή.

Υπάρχουν λοιπόν μόνο τρεις μοχλοί: μεγαλύτερος πίνακας (μνήμη), μικρότεροι χρόνοι ζωής (timeouts), και λιγότερες εγγραφές ανά ροή (καθόλου παρακολούθηση state εκεί που δεν τη χρειάζεστε). Χρησιμοποιήστε και τους τρεις.

Μοχλός πρώτος: διαστασιολογήστε τον πίνακα σκόπιμα

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

Σε OPNsense και firewalls βασισμένα σε pf, οι ζωντανοί αριθμοί απέχουν μία εντολή:

pfctl -si | grep -A4 "State Table"
pfctl -sm | grep states

Μοχλός δεύτερος: adaptive timeouts και SYN cookies

Τα στατικά timeouts είναι συμβιβασμός ανάμεσα στο να είστε ευγενικοί με αργούς clients και στο να επιβιώσετε ένα flood. Τα adaptive timeouts αφαιρούν τον συμβιβασμό: καθώς ο πίνακας γεμίζει πέρα από ένα κατώφλι έναρξης, όλα τα timeouts μικραίνουν γραμμικά, φτάνοντας στο μηδέν σε ένα κατώφλι λήξης. Οι κανονικές μέρες κρατούν γενναιόδωρους χρονομετρητές. Υπό πίεση οι εγγραφές λήγουν γρήγορα. Σε όρους pf:

set limit states 2000000
set timeout { adaptive.start 1200000, adaptive.end 2200000 }

Προσθέστε SYN cookies, ιδανικά σε adaptive λειτουργία που ενεργοποιείται μόνο όταν ο πίνακας περάσει ένα κατώφλι. Με cookies, το firewall απαντά σε ένα SYN χωρίς να δημιουργεί state και χτίζει εγγραφή μόνο όταν ο client ολοκληρώσει τη χειραψία, κάτι που μια πλαστή πηγή δεν κάνει ποτέ. Αυτό μετατρέπει την πιο αποδοτική επίθεση σε stateful firewall σε κίνηση που το firewall μόλις που προσέχει.

Μοχλός τρίτος: μην παρακολουθείτε ό,τι δεν χρειάζεται παρακολούθηση

Για υπηρεσίες UDP υψηλού όγκου, η παρακολούθηση κάθε ανταλλαγής δεν αγοράζει σχεδόν τίποτα: η υπηρεσία απαντά από γνωστή θύρα, και οι κανόνες είναι απλοί. Ένα stateless ζεύγος κανόνων (επίτρεψε εισερχόμενα προς τη θύρα της υπηρεσίας, επίτρεψε εξερχόμενα από αυτήν) δεν δημιουργεί καθόλου εγγραφές, οπότε ένα UDP flood δεν μπορεί να εξαντλήσει τον πίνακα για λογαριασμό ενός DNS ή NTP server. Κρατήστε stateful χειρισμό για TCP και για οτιδήποτε όπου η κίνηση επιστροφής πρέπει να δένεται αυστηρά με ένα εξερχόμενο αίτημα.

Κρατήστε το state μέσα από μια βλάβη

Η διαστασιολόγηση είναι η μισή δουλειά. Η άλλη μισή είναι να μην τα χάσετε όλα όταν ένας κόμβος αποτύχει. Σε ένα ζεύγος active και standby, το CARP μετακινεί τις εικονικές διευθύνσεις στο standby, και το pfsync αντιγράφει τον state table ανάμεσα στους κόμβους συνεχώς, πάνω από αποκλειστικό link όπου είναι δυνατόν. Όταν ο active κόμβος πεθάνει, το standby ξέρει ήδη κάθε εγκατεστημένη σύνδεση, οπότε οι συνεδρίες συνεχίζουν αντί να ξανασυνδέεται κάθε χρήστης. Δοκιμάστε το: ξεκινήστε ένα μεγάλο download ή μια συνεδρία SSH μέσα από το ζεύγος, σβήστε τον active κόμβο, και δείτε τη να συνεχίζει.

Δύο πρακτικές συνήθειες βοηθούν. Εφαρμόστε τις αλλαγές ρύθμισης πρώτα στο standby, επαληθεύστε, μετά κάντε failover και αλλάξτε τον άλλο κόμβο. Και μοιράστε την επεξεργασία πακέτων σε πυρήνες CPU με αριθμούς threads ταιριαστούς σε κάθε συσκευή, ώστε ένας απασχολημένος πυρήνας να μη γίνει το πραγματικό όριο.

Ταξινομήστε το ruleset για φθηνές αποφάσεις

Ένα flood είναι φθηνότερο να απορριφθεί νωρίς. Βάλτε πρώτα τις χονδρικές, φθηνές αποφάσεις: μια συνδυασμένη λίστα αποκλεισμού threat intelligence, μετά αποκλεισμούς χωρών, μετά γνωστά καταχρηστικά εύρη hosting, και μόνο μετά τους κανόνες επιτρεπόμενων ανά host. Ονομάστε κάθε alias και κανόνα από τον host που προστατεύει, ώστε το ruleset να τεκμηριώνει τον εαυτό του και οι παλιοί κανόνες να αφαιρούνται με σιγουριά.

Ελέγξτε το δικό σας firewall

• Ποιο είναι το όριο του state table, και ποια είναι η σημερινή κορύφωση ως ποσοστό του;
• Υπάρχει συναγερμός αρκετά κάτω από το όριο;
• Είναι ρυθμισμένα adaptive timeouts, και είναι διαθέσιμα SYN cookies υπό φορτίο;
• Χειρίζεστε τις υπηρεσίες UDP υψηλού όγκου stateless;
• Σε ζεύγος HA, συγχρονίζεται το state, και έχετε δοκιμάσει failover με ζωντανές συνεδρίες;
• Ξέρετε τι θα έκανε στον πίνακα μια επίθεση στο δεκαπλάσιο του κανονικού σας ρυθμού συνδέσεων; Κάντε τον πολλαπλασιασμό.

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

Μιλήστε με έναν μηχανικό

Σχετικά: Managed περιμετρικά firewalls · Πώς αλλάζουμε πράγματα: πειθαρχία αλλαγών δικτύου · Παρακολούθηση δικτύου και τεκμήρια