Το Variti αναπτύσσει προστασία έναντι των bots και των επιθέσεων DDoS και πραγματοποιεί επίσης δοκιμές καταπόνησης και φορτίου. Στο συνέδριο HighLoad++ 2018 μιλήσαμε για το πώς να εξασφαλίσουμε πόρους από διάφορους τύπους επιθέσεων. Εν ολίγοις: απομονώστε μέρη του συστήματος, χρησιμοποιήστε υπηρεσίες cloud και CDN και ενημερώστε τακτικά. Αλλά και πάλι δεν θα μπορείτε να χειριστείτε την προστασία χωρίς εξειδικευμένες εταιρείες :)
Πριν διαβάσετε το κείμενο, μπορείτε να διαβάσετε τις σύντομες περιλήψεις .
Και αν δεν σας αρέσει να διαβάζετε ή απλά θέλετε να παρακολουθήσετε το βίντεο, η ηχογράφηση της αναφοράς μας βρίσκεται παρακάτω κάτω από το spoiler.
Βιντεοσκόπηση της έκθεσης
Πολλές εταιρείες γνωρίζουν ήδη πώς να κάνουν δοκιμές φορτίου, αλλά δεν κάνουν όλες οι δοκιμές ακραίων καταστάσεων. Μερικοί από τους πελάτες μας πιστεύουν ότι ο ιστότοπός τους είναι άτρωτος επειδή διαθέτουν σύστημα υψηλής φόρτωσης και προστατεύει καλά από επιθέσεις. Δείχνουμε ότι αυτό δεν είναι απολύτως αλήθεια.
Φυσικά, πριν από τη διεξαγωγή δοκιμών, λαμβάνουμε άδεια από τον πελάτη, υπογεγραμμένη και σφραγισμένη και με τη βοήθειά μας δεν μπορεί να πραγματοποιηθεί επίθεση DDoS σε κανέναν. Ο έλεγχος πραγματοποιείται σε χρόνο που επιλέγει ο πελάτης, όταν η κίνηση στον πόρο του είναι ελάχιστη και τα προβλήματα πρόσβασης δεν θα επηρεάσουν τους πελάτες. Επιπλέον, καθώς κάτι μπορεί πάντα να πάει στραβά κατά τη διαδικασία δοκιμών, έχουμε συνεχή επαφή με τον πελάτη. Αυτό σας επιτρέπει όχι μόνο να αναφέρετε τα αποτελέσματα που επιτεύχθηκαν, αλλά και να αλλάξετε κάτι κατά τη διάρκεια της δοκιμής. Με την ολοκλήρωση των δοκιμών, συντάσσουμε πάντα μια αναφορά στην οποία επισημαίνουμε τις διαπιστωμένες ελλείψεις και δίνουμε συστάσεις για την εξάλειψη των αδυναμιών του ιστότοπου.
Πώς δουλεύουμε
Κατά τη δοκιμή, προσομοιώνουμε ένα botnet. Δεδομένου ότι συνεργαζόμαστε με πελάτες που δεν βρίσκονται στα δίκτυά μας, προκειμένου να διασφαλίσουμε ότι η δοκιμή δεν θα τελειώσει το πρώτο λεπτό λόγω ορίων ή προστασίας που ενεργοποιείται, παρέχουμε το φορτίο όχι από μία IP, αλλά από το δικό μας υποδίκτυο. Επιπλέον, για να δημιουργήσουμε ένα σημαντικό φορτίο, έχουμε τον δικό μας αρκετά ισχυρό δοκιμαστικό διακομιστή.
Αξιώματα
Το πολύ δεν σημαίνει καλό
Όσο λιγότερο φορτίο μπορούμε να φέρουμε έναν πόρο στην αποτυχία, τόσο το καλύτερο. Εάν μπορείτε να κάνετε τον ιστότοπο να σταματήσει να λειτουργεί με ένα αίτημα ανά δευτερόλεπτο ή ακόμα και ένα αίτημα ανά λεπτό, αυτό είναι υπέροχο. Επειδή σύμφωνα με το νόμο της κακίας, οι χρήστες ή οι εισβολείς θα πέσουν κατά λάθος σε αυτή τη συγκεκριμένη ευπάθεια.
Η μερική αποτυχία είναι καλύτερη από την πλήρη αποτυχία
Πάντα συμβουλεύουμε να κάνουμε τα συστήματα ετερογενή. Επιπλέον, αξίζει να τα διαχωρίσουμε σε φυσικό επίπεδο και όχι μόνο σε εμπορευματοκιβώτια. Σε περίπτωση φυσικού διαχωρισμού, ακόμα και αν κάτι αποτύχει στον ιστότοπο, υπάρχει μεγάλη πιθανότητα να μην σταματήσει να λειτουργεί εντελώς και οι χρήστες θα συνεχίσουν να έχουν πρόσβαση σε τουλάχιστον μέρος της λειτουργικότητας.
Η καλή αρχιτεκτονική είναι η βάση για τη βιωσιμότητα
Η ανοχή σφαλμάτων ενός πόρου και η ικανότητά του να αντέχει σε επιθέσεις και φορτία θα πρέπει να καθοριστεί στο στάδιο του σχεδιασμού, στην πραγματικότητα, στο στάδιο της σχεδίασης των πρώτων διαγραμμάτων ροής σε ένα σημειωματάριο. Διότι αν εισχωρήσουν μοιραία λάθη, είναι δυνατόν να διορθωθούν στο μέλλον, αλλά είναι πολύ δύσκολο.
Όχι μόνο ο κώδικας πρέπει να είναι καλός, αλλά και η διαμόρφωση
Πολλοί άνθρωποι πιστεύουν ότι μια καλή ομάδα ανάπτυξης αποτελεί εγγύηση για ανοχή σε σφάλματα. Μια καλή ομάδα ανάπτυξης είναι πραγματικά απαραίτητη, αλλά πρέπει να υπάρχουν και καλές λειτουργίες, καλά DevOps. Δηλαδή χρειαζόμαστε ειδικούς που θα ρυθμίσουν σωστά το Linux και το δίκτυο, θα γράφουν σωστά τις ρυθμίσεις στο nginx, θα θέσουν όρια κ.λπ. Διαφορετικά, ο πόρος θα λειτουργήσει καλά μόνο στις δοκιμές και κάποια στιγμή όλα θα σπάσουν στην παραγωγή.
Διαφορές μεταξύ δοκιμών φορτίου και καταπόνησης
Η δοκιμή φόρτωσης σάς επιτρέπει να προσδιορίσετε τα όρια λειτουργίας του συστήματος. Το stress test στοχεύει στην εύρεση αδυναμιών σε ένα σύστημα και χρησιμοποιείται για να σπάσει αυτό το σύστημα και να δει πώς θα συμπεριφερθεί στη διαδικασία αστοχίας ορισμένων εξαρτημάτων. Σε αυτή την περίπτωση, η φύση του φορτίου παραμένει συνήθως άγνωστη στον πελάτη πριν ξεκινήσει η δοκιμή ακραίων καταστάσεων.
Χαρακτηριστικά των επιθέσεων L7
Συνήθως χωρίζουμε τους τύπους φορτίων σε φορτία στα επίπεδα L7 και L3&4. Το L7 είναι μια φόρτωση σε επίπεδο εφαρμογής, τις περισσότερες φορές σημαίνει μόνο HTTP, αλλά εννοούμε οποιαδήποτε φόρτωση σε επίπεδο πρωτοκόλλου TCP.
Οι επιθέσεις L7 έχουν ορισμένα διακριτικά χαρακτηριστικά. Πρώτον, έρχονται απευθείας στην εφαρμογή, δηλαδή είναι απίθανο να αντικατοπτρίζονται μέσω δικτύου. Τέτοιες επιθέσεις χρησιμοποιούν λογική, και λόγω αυτού, καταναλώνουν CPU, μνήμη, δίσκο, βάση δεδομένων και άλλους πόρους πολύ αποτελεσματικά και με λίγη κίνηση.
HTTP Flood
Σε περίπτωση οποιασδήποτε επίθεσης, το φορτίο είναι πιο εύκολο στη δημιουργία παρά στο χειρισμό, και στην περίπτωση του L7 αυτό ισχύει επίσης. Δεν είναι πάντα εύκολο να διακρίνει κανείς την κυκλοφορία επίθεσης από τη νόμιμη κυκλοφορία και τις περισσότερες φορές αυτό μπορεί να γίνει με συχνότητα, αλλά εάν όλα έχουν προγραμματιστεί σωστά, τότε είναι αδύνατο να καταλάβουμε από τα αρχεία καταγραφής πού είναι η επίθεση και πού είναι τα νόμιμα αιτήματα.
Ως πρώτο παράδειγμα, εξετάστε μια επίθεση HTTP Flood. Το γράφημα δείχνει ότι τέτοιες επιθέσεις είναι συνήθως πολύ ισχυρές· στο παρακάτω παράδειγμα, ο αριθμός αιχμής των αιτημάτων ξεπέρασε τις 600 χιλιάδες ανά λεπτό.
Το HTTP Flood είναι ο ευκολότερος τρόπος δημιουργίας φορτίου. Συνήθως, χρειάζεται κάποιο είδος εργαλείου δοκιμής φόρτωσης, όπως το ApacheBench, και ορίζει ένα αίτημα και έναν στόχο. Με μια τόσο απλή προσέγγιση, υπάρχει μεγάλη πιθανότητα να εκτελεστεί η προσωρινή αποθήκευση διακομιστή, αλλά είναι εύκολο να το παρακάμψετε. Για παράδειγμα, η προσθήκη τυχαίων συμβολοσειρών στο αίτημα, που θα αναγκάσει τον διακομιστή να προβάλλει συνεχώς μια νέα σελίδα.
Επίσης, μην ξεχνάτε τον user-agent στη διαδικασία δημιουργίας ενός φορτίου. Πολλοί χρήστες-πράκτορες δημοφιλών εργαλείων δοκιμών φιλτράρονται από τους διαχειριστές συστήματος και σε αυτήν την περίπτωση το φορτίο μπορεί απλώς να μην φτάσει στο backend. Μπορείτε να βελτιώσετε σημαντικά το αποτέλεσμα εισάγοντας μια περισσότερο ή λιγότερο έγκυρη κεφαλίδα από το πρόγραμμα περιήγησης στο αίτημα.
Όσο απλές κι αν είναι οι επιθέσεις HTTP Flood, έχουν και τα μειονεκτήματά τους. Πρώτον, απαιτούνται μεγάλες ποσότητες ισχύος για τη δημιουργία του φορτίου. Δεύτερον, τέτοιες επιθέσεις είναι πολύ εύκολο να εντοπιστούν, ειδικά αν προέρχονται από μία διεύθυνση. Ως αποτέλεσμα, τα αιτήματα αρχίζουν αμέσως να φιλτράρονται είτε από διαχειριστές συστήματος είτε ακόμη και σε επίπεδο παρόχου.
Τι να ψάξετε
Για να μειώσετε τον αριθμό των αιτημάτων ανά δευτερόλεπτο χωρίς να χάσετε την αποτελεσματικότητα, πρέπει να δείξετε λίγη φαντασία και να εξερευνήσετε τον ιστότοπο. Έτσι, μπορείτε να φορτώσετε όχι μόνο το κανάλι ή τον διακομιστή, αλλά και μεμονωμένα μέρη της εφαρμογής, για παράδειγμα, βάσεις δεδομένων ή συστήματα αρχείων. Μπορείτε επίσης να αναζητήσετε μέρη στον ιστότοπο που κάνουν μεγάλους υπολογισμούς: αριθμομηχανές, σελίδες επιλογής προϊόντων κ.λπ. Τέλος, συμβαίνει συχνά ο ιστότοπος να έχει κάποιο είδος σεναρίου PHP που δημιουργεί μια σελίδα πολλών εκατοντάδων χιλιάδων γραμμών. Ένα τέτοιο σενάριο φορτώνει επίσης σημαντικά τον διακομιστή και μπορεί να γίνει στόχος επίθεσης.
Πού να κοιτάξουμε
Όταν σαρώνουμε έναν πόρο πριν από τη δοκιμή, εξετάζουμε πρώτα, φυσικά, τον ίδιο τον ιστότοπο. Αναζητούμε όλα τα είδη πεδίων εισαγωγής, βαριά αρχεία - γενικά, όλα όσα μπορούν να δημιουργήσουν προβλήματα στον πόρο και να επιβραδύνουν τη λειτουργία του. Τα κοινά εργαλεία ανάπτυξης στο Google Chrome και στον Firefox βοηθούν εδώ, εμφανίζοντας χρόνους απόκρισης σελίδας.
Σαρώνουμε επίσης υποτομείς. Για παράδειγμα, υπάρχει ένα συγκεκριμένο ηλεκτρονικό κατάστημα, το abc.com, και έχει έναν υποτομέα admin.abc.com. Πιθανότατα, πρόκειται για έναν πίνακα διαχείρισης με εξουσιοδότηση, αλλά εάν βάλετε ένα φορτίο σε αυτό, μπορεί να δημιουργήσει προβλήματα στον κύριο πόρο.
Ο ιστότοπος μπορεί να έχει έναν υποτομέα api.abc.com. Πιθανότατα, αυτός είναι ένας πόρος για εφαρμογές για κινητές συσκευές. Η εφαρμογή μπορεί να βρεθεί στο App Store ή στο Google Play, να εγκαταστήσετε ένα ειδικό σημείο πρόσβασης, να αναλύσετε το API και να καταχωρήσετε δοκιμαστικούς λογαριασμούς. Το πρόβλημα είναι ότι οι άνθρωποι συχνά πιστεύουν ότι οτιδήποτε προστατεύεται από εξουσιοδότηση είναι απρόσβλητο σε επιθέσεις άρνησης υπηρεσίας. Υποτίθεται ότι η εξουσιοδότηση είναι η καλύτερη CAPTCHA, αλλά δεν είναι. Είναι εύκολο να δημιουργήσουμε 10-20 δοκιμαστικούς λογαριασμούς, αλλά δημιουργώντας τους, έχουμε πρόσβαση σε πολύπλοκες και ακάλυπτες λειτουργίες.
Φυσικά, εξετάζουμε το ιστορικό, το robots.txt και το WebArchive, το ViewDNS και αναζητούμε παλιές εκδόσεις του πόρου. Μερικές φορές συμβαίνει ότι οι προγραμματιστές έχουν κυκλοφορήσει, για παράδειγμα, το mail2.yandex.net, αλλά η παλιά έκδοση, mail.yandex.net, παραμένει. Αυτό το mail.yandex.net δεν υποστηρίζεται πλέον, δεν διατίθενται πόροι ανάπτυξης σε αυτό, αλλά συνεχίζει να καταναλώνει τη βάση δεδομένων. Αντίστοιχα, χρησιμοποιώντας την παλιά έκδοση, μπορείτε να χρησιμοποιήσετε αποτελεσματικά τους πόρους του backend και όλα όσα βρίσκονται πίσω από τη διάταξη. Φυσικά, αυτό δεν συμβαίνει πάντα, αλλά το συναντάμε ακόμα αρκετά συχνά.
Φυσικά, αναλύουμε όλες τις παραμέτρους αιτήματος και τη δομή των cookie. Μπορείτε, ας πούμε, να απορρίψετε κάποια αξία σε έναν πίνακα JSON μέσα σε ένα cookie, να δημιουργήσετε πολλά ένθετα και να κάνετε τον πόρο να λειτουργεί για αδικαιολόγητα μεγάλο χρονικό διάστημα.
Φόρτωση αναζήτησης
Το πρώτο πράγμα που έρχεται στο μυαλό κατά την έρευνα ενός ιστότοπου είναι η φόρτωση της βάσης δεδομένων, αφού σχεδόν όλοι έχουν μια αναζήτηση και σχεδόν για όλους, δυστυχώς, είναι ελάχιστα προστατευμένη. Για κάποιο λόγο, οι προγραμματιστές δεν δίνουν αρκετή προσοχή στην αναζήτηση. Αλλά υπάρχει μια σύσταση εδώ - δεν πρέπει να κάνετε αιτήματα του ίδιου τύπου, γιατί μπορεί να συναντήσετε προσωρινή αποθήκευση, όπως συμβαίνει με το HTTP flood.
Η πραγματοποίηση τυχαίων ερωτημάτων στη βάση δεδομένων δεν είναι επίσης πάντα αποτελεσματική. Είναι πολύ καλύτερο να δημιουργήσετε μια λίστα με λέξεις-κλειδιά που σχετίζονται με την αναζήτηση. Αν επιστρέψουμε στο παράδειγμα ενός ηλεκτρονικού καταστήματος: ας υποθέσουμε ότι ο ιστότοπος πουλά ελαστικά αυτοκινήτου και σας επιτρέπει να ορίσετε την ακτίνα των ελαστικών, τον τύπο του αυτοκινήτου και άλλες παραμέτρους. Αντίστοιχα, συνδυασμοί σχετικών λέξεων θα αναγκάσουν τη βάση δεδομένων να λειτουργεί σε πολύ πιο περίπλοκες συνθήκες.
Επιπλέον, αξίζει να χρησιμοποιήσετε τη σελιδοποίηση: είναι πολύ πιο δύσκολο για μια αναζήτηση να επιστρέψει την προτελευταία σελίδα των αποτελεσμάτων αναζήτησης από την πρώτη. Δηλαδή, με τη βοήθεια της σελιδοποίησης μπορείτε να διαφοροποιήσετε ελαφρώς το φορτίο.
Το παρακάτω παράδειγμα δείχνει τον φόρτο αναζήτησης. Φαίνεται ότι από το πρώτο κιόλας δευτερόλεπτο της δοκιμής με ταχύτητα δέκα αιτημάτων ανά δευτερόλεπτο, ο ιστότοπος κατέβηκε και δεν ανταποκρίθηκε.
Αν δεν υπάρχει αναζήτηση;
Εάν δεν υπάρχει αναζήτηση, αυτό δεν σημαίνει ότι ο ιστότοπος δεν περιέχει άλλα ευάλωτα πεδία εισαγωγής. Αυτό το πεδίο μπορεί να είναι εξουσιοδότηση. Σήμερα, στους προγραμματιστές αρέσει να δημιουργούν πολύπλοκα hashes για να προστατεύουν τη βάση δεδομένων σύνδεσης από μια επίθεση πίνακα ουράνιου τόξου. Αυτό είναι καλό, αλλά τέτοιοι κατακερματισμοί καταναλώνουν πολλούς πόρους CPU. Μια μεγάλη ροή ψευδών εξουσιοδοτήσεων οδηγεί σε αποτυχία του επεξεργαστή και ως αποτέλεσμα, ο ιστότοπος σταματά να λειτουργεί.
Η παρουσία στον ιστότοπο όλων των ειδών μορφών για σχόλια και σχόλια είναι ένας λόγος για να στείλετε πολύ μεγάλα κείμενα εκεί ή απλά να δημιουργήσετε μια τεράστια πλημμύρα. Μερικές φορές οι ιστότοποι δέχονται συνημμένα αρχεία, συμπεριλαμβανομένης της μορφής gzip. Σε αυτήν την περίπτωση, παίρνουμε ένα αρχείο 1 TB, το συμπιέζουμε σε πολλά byte ή kilobyte χρησιμοποιώντας gzip και το στέλνουμε στον ιστότοπο. Στη συνέχεια αποσυμπιέζεται και προκύπτει ένα πολύ ενδιαφέρον αποτέλεσμα.
API ανάπαυσης
Θα ήθελα να δώσω λίγη προσοχή σε δημοφιλείς υπηρεσίες όπως το Rest API. Η διασφάλιση ενός Rest API είναι πολύ πιο δύσκολη από έναν κανονικό ιστότοπο. Ακόμη και ασήμαντες μέθοδοι προστασίας από την ωμή βία με κωδικό πρόσβασης και άλλες παράνομες δραστηριότητες δεν λειτουργούν για το Rest API.
Το Rest API είναι πολύ εύκολο να σπάσει επειδή έχει άμεση πρόσβαση στη βάση δεδομένων. Ταυτόχρονα, η αποτυχία μιας τέτοιας υπηρεσίας συνεπάγεται αρκετά σοβαρές συνέπειες για τις επιχειρήσεις. Το γεγονός είναι ότι το Rest API χρησιμοποιείται συνήθως όχι μόνο για τον κύριο ιστότοπο, αλλά και για την εφαρμογή για κινητά και ορισμένους εσωτερικούς επιχειρηματικούς πόρους. Και αν πέσουν όλα αυτά, τότε το αποτέλεσμα είναι πολύ ισχυρότερο από ό,τι στην περίπτωση μιας απλής αποτυχίας ιστοσελίδας.
Φόρτωση μεγάλου περιεχομένου
Εάν μας προσφερθεί να δοκιμάσουμε κάποια συνηθισμένη εφαρμογή μιας σελίδας, σελίδα προορισμού ή ιστότοπο επαγγελματικών καρτών που δεν έχει περίπλοκη λειτουργικότητα, αναζητούμε βαρύ περιεχόμενο. Για παράδειγμα, μεγάλες εικόνες που στέλνει ο διακομιστής, δυαδικά αρχεία, τεκμηρίωση pdf - προσπαθούμε να τα κατεβάσουμε όλα αυτά. Τέτοιες δοκιμές φορτώνουν καλά το σύστημα αρχείων και φράζουν τα κανάλια, και επομένως είναι αποτελεσματικά. Δηλαδή, ακόμα κι αν δεν βάλετε κάτω τον διακομιστή, κατεβάζοντας ένα μεγάλο αρχείο σε χαμηλές ταχύτητες, απλά θα φράξετε το κανάλι του διακομιστή προορισμού και μετά θα προκύψει άρνηση εξυπηρέτησης.
Ένα παράδειγμα τέτοιας δοκιμής δείχνει ότι με ταχύτητα 30 RPS ο ιστότοπος σταμάτησε να ανταποκρίνεται ή παρήγαγε 500 σφάλματα διακομιστή.
Μην ξεχάσετε να ρυθμίσετε τους διακομιστές. Συχνά μπορείτε να διαπιστώσετε ότι κάποιος αγόρασε μια εικονική μηχανή, εγκατέστησε Apache εκεί, ρύθμισε τα πάντα από προεπιλογή, εγκατέστησε μια εφαρμογή PHP και παρακάτω μπορείτε να δείτε το αποτέλεσμα.
Εδώ το φορτίο πήγε στο root και ανήλθε σε μόλις 10 RPS. Περιμέναμε 5 λεπτά και ο διακομιστής κατέρρευσε. Είναι αλήθεια ότι δεν είναι απολύτως γνωστό γιατί έπεσε, αλλά υπάρχει η υπόθεση ότι απλώς είχε υπερβολική μνήμη και επομένως σταμάτησε να ανταποκρίνεται.
Βάσει κυμάτων
Τα τελευταία ή δύο χρόνια, οι επιθέσεις κυμάτων έχουν γίνει αρκετά δημοφιλείς. Αυτό οφείλεται στο γεγονός ότι πολλοί οργανισμοί αγοράζουν συγκεκριμένα κομμάτια υλικού για προστασία DDoS, τα οποία απαιτούν συγκεκριμένο χρόνο για τη συγκέντρωση στατιστικών στοιχείων για να αρχίσουν να φιλτράρουν την επίθεση. Δηλαδή δεν φιλτράρουν την επίθεση στα πρώτα 30-40 δευτερόλεπτα, γιατί συσσωρεύουν δεδομένα και μαθαίνουν. Κατά συνέπεια, σε αυτά τα 30-40 δευτερόλεπτα μπορείτε να εκκινήσετε τόσα πολλά στον ιστότοπο που ο πόρος θα παραμείνει για μεγάλο χρονικό διάστημα μέχρι να διαγραφούν όλα τα αιτήματα.
Στην περίπτωση της επίθεσης παρακάτω, υπήρχε ένα διάστημα 10 λεπτών, μετά το οποίο έφτασε ένα νέο, τροποποιημένο τμήμα της επίθεσης.
Δηλαδή, η άμυνα έμαθε, άρχισε να φιλτράρει, αλλά έφτασε ένα νέο, εντελώς διαφορετικό μέρος της επίθεσης και η άμυνα άρχισε να μαθαίνει ξανά. Στην πραγματικότητα, το φιλτράρισμα σταματά να λειτουργεί, η προστασία γίνεται αναποτελεσματική και ο ιστότοπος δεν είναι διαθέσιμος.
Οι επιθέσεις κυμάτων χαρακτηρίζονται από πολύ υψηλές τιμές στην κορυφή, μπορεί να φτάσει τις εκατό χιλιάδες ή ένα εκατομμύριο αιτήματα ανά δευτερόλεπτο, στην περίπτωση του L7. Αν μιλάμε για L3&4, τότε μπορεί να υπάρχουν εκατοντάδες gigabit κίνησης ή, κατά συνέπεια, εκατοντάδες mpps, αν μετράτε σε πακέτα.
Το πρόβλημα με τέτοιες επιθέσεις είναι ο συγχρονισμός. Οι επιθέσεις προέρχονται από ένα botnet και απαιτούν υψηλό βαθμό συγχρονισμού για τη δημιουργία μιας πολύ μεγάλης ακίδας μίας χρήσης. Και αυτός ο συντονισμός δεν λειτουργεί πάντα: μερικές φορές η έξοδος είναι κάποιο είδος παραβολικής κορυφής, η οποία φαίνεται μάλλον αξιολύπητη.
Όχι μόνο το HTTP
Εκτός από το HTTP στο L7, μας αρέσει να εκμεταλλευόμαστε άλλα πρωτόκολλα. Κατά κανόνα, ένας κανονικός ιστότοπος, ειδικά ένας κανονικός χώρος φιλοξενίας, έχει πρωτόκολλα αλληλογραφίας και MySQL. Τα πρωτόκολλα αλληλογραφίας υπόκεινται σε μικρότερο φορτίο από ό,τι οι βάσεις δεδομένων, αλλά μπορούν επίσης να φορτωθούν αρκετά αποτελεσματικά και να καταλήξουν με υπερφορτωμένη CPU στον διακομιστή.
Ήμασταν αρκετά επιτυχημένοι χρησιμοποιώντας την ευπάθεια SSH του 2016. Τώρα αυτή η ευπάθεια έχει επιδιορθωθεί σχεδόν για όλους, αλλά αυτό δεν σημαίνει ότι το φορτίο δεν μπορεί να υποβληθεί στο SSH. Μπορώ. Υπάρχει απλώς ένας τεράστιος όγκος εξουσιοδοτήσεων, το SSH καταναλώνει σχεδόν ολόκληρη την CPU του διακομιστή και στη συνέχεια ο ιστότοπος καταρρέει από ένα ή δύο αιτήματα ανά δευτερόλεπτο. Συνεπώς, αυτά τα ένα ή δύο αιτήματα που βασίζονται στα αρχεία καταγραφής δεν μπορούν να διακριθούν από ένα νόμιμο φορτίο.
Πολλές συνδέσεις που ανοίγουμε σε διακομιστές παραμένουν επίσης σχετικές. Προηγουμένως, ο Apache ήταν ένοχος για αυτό, τώρα το nginx υποφέρει πραγματικά από αυτό, καθώς συχνά ρυθμίζεται από προεπιλογή. Ο αριθμός των συνδέσεων που μπορεί να κρατήσει ανοιχτή το nginx είναι περιορισμένος, επομένως ανοίγουμε αυτόν τον αριθμό συνδέσεων, το nginx δεν δέχεται πλέον νέα σύνδεση και ως αποτέλεσμα ο ιστότοπος δεν λειτουργεί.
Το δοκιμαστικό μας σύμπλεγμα έχει αρκετή CPU για να επιτεθεί σε χειραψία SSL. Κατ' αρχήν, όπως δείχνει η πρακτική, τα botnet μερικές φορές θέλουν να το κάνουν και αυτό. Από τη μία πλευρά, είναι σαφές ότι δεν μπορείτε να κάνετε χωρίς SSL, επειδή τα αποτελέσματα, η κατάταξη, η ασφάλεια της Google. Από την άλλη, το SSL δυστυχώς έχει πρόβλημα με την CPU.
L3&4
Όταν μιλάμε για επίθεση στα επίπεδα L3&4, συνήθως μιλάμε για επίθεση σε επίπεδο συνδέσμου. Ένα τέτοιο φορτίο είναι σχεδόν πάντα διακριτό από ένα νόμιμο, εκτός εάν πρόκειται για επίθεση SYN-flood. Το πρόβλημα με τις επιθέσεις SYN-flood για εργαλεία ασφαλείας είναι ο μεγάλος όγκος τους. Η μέγιστη τιμή L3&4 ήταν 1,5-2 Tbit/s. Αυτό το είδος επισκεψιμότητας είναι πολύ δύσκολο να επεξεργαστεί ακόμη και μεγάλες εταιρείες, συμπεριλαμβανομένων της Oracle και της Google.
Τα SYN και SYN-ACK είναι πακέτα που χρησιμοποιούνται κατά τη δημιουργία μιας σύνδεσης. Επομένως, το SYN-flood είναι δύσκολο να διακριθεί από ένα νόμιμο φορτίο: δεν είναι σαφές εάν πρόκειται για SYN που ήρθε για να δημιουργήσει μια σύνδεση ή μέρος μιας πλημμύρας.
UDP-πλημμύρα
Συνήθως, οι εισβολείς δεν έχουν τις δυνατότητες που έχουμε εμείς, επομένως η ενίσχυση μπορεί να χρησιμοποιηθεί για την οργάνωση επιθέσεων. Δηλαδή, ο εισβολέας σαρώνει το Διαδίκτυο και βρίσκει είτε ευάλωτους είτε εσφαλμένα διαμορφωμένους διακομιστές που, για παράδειγμα, σε απόκριση σε ένα πακέτο SYN, ανταποκρίνονται με τρία SYN-ACK. Με την πλαστογράφηση της διεύθυνσης προέλευσης από τη διεύθυνση του διακομιστή προορισμού, είναι δυνατό να αυξηθεί η ισχύς, για παράδειγμα, τρεις φορές με ένα μόνο πακέτο και να ανακατευθύνει την κυκλοφορία στο θύμα.
Το πρόβλημα με τις ενισχύσεις είναι ότι είναι δύσκολο να εντοπιστούν. Πρόσφατα παραδείγματα περιλαμβάνουν την εντυπωσιακή περίπτωση των ευάλωτων memcached. Επιπλέον, τώρα υπάρχουν πολλές συσκευές IoT, κάμερες IP, οι οποίες επίσης έχουν διαμορφωθεί ως επί το πλείστον από προεπιλογή και από προεπιλογή έχουν ρυθμιστεί λανθασμένα, γι' αυτό και οι εισβολείς κάνουν τις περισσότερες φορές επιθέσεις μέσω τέτοιων συσκευών.
Δύσκολο ΣΥΝ-πλημμύρα
Το SYN-flood είναι ίσως το πιο ενδιαφέρον είδος επίθεσης από την πλευρά ενός προγραμματιστή. Το πρόβλημα είναι ότι οι διαχειριστές συστήματος συχνά χρησιμοποιούν αποκλεισμό IP για προστασία. Επιπλέον, ο αποκλεισμός IP επηρεάζει όχι μόνο τους διαχειριστές συστημάτων που ενεργούν χρησιμοποιώντας σενάρια, αλλά και, δυστυχώς, ορισμένα συστήματα ασφαλείας που αγοράζονται για πολλά χρήματα.
Αυτή η μέθοδος μπορεί να μετατραπεί σε καταστροφή, επειδή εάν οι εισβολείς αντικαταστήσουν τις διευθύνσεις IP, η εταιρεία θα αποκλείσει το δικό της υποδίκτυο. Όταν το Τείχος προστασίας αποκλείει το δικό του σύμπλεγμα, η έξοδος θα αποτύχει στις εξωτερικές αλληλεπιδράσεις και ο πόρος θα αποτύχει.
Επιπλέον, δεν είναι δύσκολο να αποκλείσετε το δικό σας δίκτυο. Εάν το γραφείο του πελάτη διαθέτει δίκτυο Wi-Fi ή εάν η απόδοση των πόρων μετράται χρησιμοποιώντας διάφορα συστήματα παρακολούθησης, τότε παίρνουμε τη διεύθυνση IP αυτού του συστήματος παρακολούθησης ή του Wi-Fi του γραφείου του πελάτη και τη χρησιμοποιούμε ως πηγή. Στο τέλος, ο πόρος φαίνεται να είναι διαθέσιμος, αλλά οι διευθύνσεις IP προορισμού είναι αποκλεισμένες. Έτσι, το δίκτυο Wi-Fi του συνεδρίου HighLoad, όπου παρουσιάζεται το νέο προϊόν της εταιρείας, μπορεί να αποκλειστεί και αυτό συνεπάγεται συγκεκριμένο επιχειρηματικό και οικονομικό κόστος.
Κατά τη διάρκεια της δοκιμής, δεν μπορούμε να χρησιμοποιήσουμε ενίσχυση μέσω memcached με εξωτερικούς πόρους, επειδή υπάρχουν συμφωνίες για αποστολή επισκεψιμότητας μόνο σε επιτρεπόμενες διευθύνσεις IP. Αντίστοιχα, χρησιμοποιούμε ενίσχυση μέσω SYN και SYN-ACK, όταν το σύστημα ανταποκρίνεται στην αποστολή ενός SYN με δύο ή τρία SYN-ACK, και στην έξοδο η επίθεση πολλαπλασιάζεται επί δύο ή τρεις φορές.
Εργαλεία
Ένα από τα κύρια εργαλεία που χρησιμοποιούμε για το φόρτο εργασίας L7 είναι το Yandex-tank. Συγκεκριμένα, ένα φάντασμα χρησιμοποιείται ως όπλο, ενώ υπάρχουν πολλά σενάρια για τη δημιουργία φυσιγγίων και για την ανάλυση των αποτελεσμάτων.
Το Tcpdump χρησιμοποιείται για την ανάλυση της κυκλοφορίας δικτύου και το Nmap για την ανάλυση του διακομιστή. Για τη δημιουργία του φορτίου σε επίπεδο L3&4, χρησιμοποιείται το OpenSSL και λίγη δική μας μαγεία με τη βιβλιοθήκη DPDK. Το DPDK είναι μια βιβλιοθήκη της Intel που σας επιτρέπει να εργάζεστε με τη διεπαφή δικτύου παρακάμπτοντας τη στοίβα Linux, αυξάνοντας έτσι την απόδοση. Φυσικά, χρησιμοποιούμε το DPDK όχι μόνο σε επίπεδο L3&4, αλλά και σε επίπεδο L7, επειδή μας επιτρέπει να δημιουργήσουμε μια πολύ υψηλή ροή φορτίου, εντός του εύρους πολλών εκατομμυρίων αιτημάτων ανά δευτερόλεπτο από ένα μηχάνημα.
Χρησιμοποιούμε επίσης ορισμένες γεννήτριες κίνησης και ειδικά εργαλεία που γράφουμε για συγκεκριμένες δοκιμές. Αν θυμηθούμε την ευπάθεια στο SSH, τότε το παραπάνω σύνολο δεν μπορεί να αξιοποιηθεί. Εάν επιτεθούμε στο πρωτόκολλο αλληλογραφίας, λαμβάνουμε βοηθητικά προγράμματα αλληλογραφίας ή απλώς γράφουμε σενάρια σε αυτά.
Ευρήματα
Ως συμπέρασμα θα ήθελα να πω:
- Εκτός από την κλασική δοκιμή φορτίου, είναι απαραίτητη η διενέργεια δοκιμών ακραίων καταστάσεων. Έχουμε ένα πραγματικό παράδειγμα όπου ο υπεργολάβος ενός συνεργάτη πραγματοποίησε μόνο δοκιμές φορτίου. Έδειξε ότι ο πόρος μπορεί να αντέξει το κανονικό φορτίο. Αλλά στη συνέχεια εμφανίστηκε ένα μη φυσιολογικό φορτίο, οι επισκέπτες του ιστότοπου άρχισαν να χρησιμοποιούν τον πόρο λίγο διαφορετικά και ως αποτέλεσμα ο υπεργολάβος ξάπλωσε. Έτσι, αξίζει να αναζητήσετε ευπάθειες ακόμα κι αν είστε ήδη προστατευμένοι από επιθέσεις DDoS.
- Είναι απαραίτητο να απομονωθούν ορισμένα μέρη του συστήματος από άλλα. Αν έχεις αναζήτηση, πρέπει να τη μεταφέρεις σε ξεχωριστά μηχανήματα, δηλαδή ούτε καν στο Docker. Γιατί αν αποτύχει η αναζήτηση ή η εξουσιοδότηση, τουλάχιστον κάτι θα συνεχίσει να λειτουργεί. Στην περίπτωση ενός διαδικτυακού καταστήματος, οι χρήστες θα συνεχίσουν να βρίσκουν προϊόντα στον κατάλογο, να πηγαίνουν από το aggregator, να αγοράζουν εάν είναι ήδη εξουσιοδοτημένοι ή να εξουσιοδοτούν μέσω του OAuth2.
- Μην παραμελείτε όλα τα είδη υπηρεσιών cloud.
- Χρησιμοποιήστε το CDN όχι μόνο για να βελτιστοποιήσετε τις καθυστερήσεις του δικτύου, αλλά και ως μέσο προστασίας από επιθέσεις στην εξάντληση των καναλιών και την απλή πλημμύρα στη στατική κίνηση.
- Είναι απαραίτητη η χρήση εξειδικευμένων υπηρεσιών προστασίας. Δεν μπορείτε να προστατεύσετε τον εαυτό σας από επιθέσεις L3&4 σε επίπεδο καναλιού, επειδή πιθανότατα απλά δεν έχετε επαρκές κανάλι. Είναι επίσης απίθανο να καταπολεμήσετε τις επιθέσεις L7, καθώς μπορεί να είναι πολύ μεγάλες. Επιπλέον, η αναζήτηση μικρών επιθέσεων εξακολουθεί να είναι προνόμιο ειδικών υπηρεσιών, ειδικών αλγορίθμων.
- Ενημερώνετε τακτικά. Αυτό δεν ισχύει μόνο για τον πυρήνα, αλλά και για τον δαίμονα SSH, ειδικά αν τα έχετε ανοιχτά προς τα έξω. Κατ 'αρχήν, όλα πρέπει να ενημερωθούν, επειδή είναι απίθανο να μπορέσετε να παρακολουθήσετε μόνοι σας ορισμένες ευπάθειες.
Πηγή: www.habr.com