Ένα Middleware Διακομιστή που Σταματά τα Ψεύτικα Crawlers πριν Φτάσουν στην Εφαρμογή σας

Το αγωγό αιτημάτων σε μια εφαρμογή ιστού είναι ένα κομψό πράγμα. Ένα αίτημα φτάνει στον διακομιστή ιστού, διέρχεται από έναν σωρό middleware, φτάνει σε έναν ελεγκτή και επιστρέφει μια απάντηση. Κάθε middleware στον σωρό έχει την ευκαιρία να επιθεωρήσει το αίτημα, να το τροποποιήσει, να το περάσει ή να το απορρίψει εντελώς. Αυτή η αρχιτεκτονική είναι τέλεια για την υλοποίηση ανίχνευσης bot επειδή η επαλήθευση γίνεται πριν το αίτημα αγγίξει οποιαδήποτε λογική εφαρμογής. Ένα ψεύτικο crawler που ισχυρίζεται ότι είναι Googlebot αναγνωρίζεται και φράσσεται στο επίπεδο middleware, και ο ελεγκτής δεν γνωρίζει καν ότι το αίτημα υπήρχε. Δεν σπαταλώνται κύκλοι CPU στην απόδοση μιας σελίδας. Δεν εκτελούνται ερωτήματα βάσης δεδομένων. Δεν γεμίζουν καταχωρήσεις cache. Το ψεύτικο bot σταματάται στην πόρτα, και οι πόροι διακομιστή που θα είχαν καταναλωθεί διατηρούνται για τους νόμιμους επισκέπτες.

Το κίνητρο για την κατασκευή αυτού του middleware προήλθε από ένα συγκεκριμένο και δαπανηρό πρόβλημα. Μια μεγάλη εφαρμογή καταναλώνει bandwidth και πόρους διακομιστή με ρυθμούς που δεν συσχετίζονται με την πραγματική βάση χρηστών της. Τα αρχεία πρόσβασης αποκάλυψαν τεράστιους όγκους αιτημάτων από user agents που ισχυρίζονται ότι είναι Googlebot, Bingbot και διάφορα άλλα νόμιμα crawlers. Η έρευνα επιβεβαίωσε ότι τα περισσότερα από αυτά ήταν ψεύτικα, προερχόμενα από παρόχους cloud hosting αντί για τις μηχανές αναζήτησης που ισχυρίζονται ότι αντιπροσωπεύουν. Κάθε ψεύτικο αίτημα καταναλώνει τους ίδιους πόρους διακομιστή με ένα πραγματικό: τον ίδιο χρόνο εκτέλεσης PHP, τα ίδια ερωτήματα βάσης δεδομένων, την ίδια κατανομή μνήμης, το ίδιο bandwidth για την απάντηση. Πολλαπλασιάστε σε χιλιάδες ψεύτικα αιτήματα ανά ώρα, και το κόστος ήταν σημαντικό. Η λύση middleware σχεδιάστηκε για να εξαλείψει αυτή τη σπατάλη πιάνοντας ψεύτικα crawlers πριν καταναλώσουν κανένα πόρο εφαρμογής.

Η υλοποίηση ακολουθεί ένα απλό μοτίβο που οποιοσδήποτε backend developer μπορεί να προσαρμόσει. Το middleware αναχαιτίζει κάθε εισερχόμενο αίτημα, ελέγχει εάν η συμβολοσειρά user agent ταιριάζει με ένα γνωστό μοτίβο crawler μηχανής αναζήτησης, και εάν συμφωνεί, επαληθεύει τη διεύθυνση IP του αιτήματος σε σχέση με την γνωστή υποδομή του crawler χρησιμοποιώντας το API ανίχνευσης bot. Τα αιτήματα που ισχυρίζονται ότι είναι crawlers αλλά δεν περνούν την επαλήθευση φράσσονται με απάντηση 403. Τα αιτήματα που περνούν την επαλήθευση ή δεν ισχυρίζονται ότι είναι crawlers συνεχίζουν κανονικά μέσα από το σωρό middleware. Ολόκληρος ο έλεγχος προσθέτει ελάχιστη καθυστέρηση επειδή τα αποτελέσματα επαλήθευσης αποθηκεύονται ανά διεύθυνση IP, που σημαίνει ότι κάθε μοναδική IP επαληθεύεται μόνο μία φορά.

Η Λογική Απόφασης πίσω από το Φράγμα στο Επίπεδο Middleware

Η επιλογή φράγματος στο επίπεδο middleware αντί να στο επίπεδο διακομιστή ιστού (Nginx ή Apache) ή στο επίπεδο εφαρμογής (εντός ελεγκτών) είναι μια σκόπιμη αρχιτεκτονική απόφαση με συγκεκριμένες αντιστάσεις. Το φράγμα στο επίπεδο διακομιστή ιστού είναι η πιο αποδοτική επιλογή όσον αφορά την κατανάλωση πόρων επειδή το αίτημα δεν φτάνει ποτέ στο PHP. Ωστόσο, η διαμόρφωση διακομιστή ιστού για ανίχνευση bot συνήθως περιλαμβάνει στατικές λίστες IP απαγόρευσης ή απλή αντιστοίχιση user agent, κανένας εκ των οποίων δεν παρέχει τη δυναμική, API-driven επαλήθευση που απαιτείται για να διακρίνει σωστά τα πραγματικά crawlers από τα ψεύτικα. Η διατήρηση μιας στατικής λίστας απαγόρευσης εκατομμυρίων διευθύνσεων IP είναι μη πρακτική, και η αντιστοίχιση user agent μόνη της δεν μπορεί να επαληθεύσει την ταυτότητα επειδή οι user agents είναι εύκολα παραποίητα.

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

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

Η στρατηγική cache είναι ιδιαίτερα σημαντική για την απόδοση. Χωρίς cache, κάθε αίτημα από έναν ισχυριζόμενο crawler θα απαιτούσε μια κλήση API για την επαλήθευση της διεύθυνσης IP. Ακόμη και με ένα γρήγορο API, αυτό θα προσέθετε καθυστέρηση σε κάθε αίτημα. Η λύση είναι να αποθηκεύσετε αποτελέσματα επαλήθευσης με κλειδί τη διεύθυνση IP, με ένα time-to-live πολλών ωρών ή ακόμη και μια ολόκληρη ημέρα. Τα crawlers μηχανών αναζήτησης λειτουργούν από σταθερές περιοχές IP που αλλάζουν σπάνια, οπότε ένα αποθηκευμένο αποτέλεσμα επαλήθευσης παραμένει έγκυρο για εκτεταμένες περιόδους. Όταν ένα αίτημα φτάνει από έναν ισχυριζόμενο Googlebot, το middleware πρώτα ελέγχει το cache. Εάν η IP επαληθεύθηκε ως νόμιμη εντός της περιόδου cache, το αίτημα επιτρέπεται να διέλθει αμέσως. Εάν η IP επαληθεύθηκε ως ψεύτικη, φράσσεται αμέσως. Μόνο οι πρώτες διευθύνσεις IP απαιτούν μια πραγματική κλήση API, και μετά από αυτή την αρχική κλήση, το αποτέλεσμα χρησιμοποιείται από το cache σε αμελητέα κόστος καθυστέρησης.

Τι Συμβαίνει στα Αιτήματα που Φράσσονται

Το φράγμα ενός ψεύτικου crawler δεν είναι απλώς θέμα επιστροφής απάντησης 403 και προχώρησης. Η απόφαση φράγματος και το πλαίσιο της θα πρέπει να καταγραφούν για ανάλυση. Κάθε ψεύτικο φραγμένο αίτημα αντιπροσωπεύει ένα σημείο δεδομένων σχετικά με το ποιος προσπαθεί να αποκτήσει πρόσβαση στον ιστότοπο, τι προσποιούνται ότι είναι και από που προέρχονται. Με την πάροδο του χρόνου, αυτή η αναφορά αποκαλύπτει μοτίβα που πληροφορούν ευρύτερες αποφάσεις ασφάλειας. Ίσως ένα συγκεκριμένο ASN είναι υπεύθυνο για ένα δυσανάλογο μερίδιο ψεύτικων crawlers. Ίσως τα ψεύτικα αιτήματα Googlebot αυξηθούν σε ορισμένες ώρες της ημέρας. Ίσως μια συγκεκριμένη διαδρομή URL προσελκύει περισσότερα ψεύτικα crawlers από άλλες, υποδηλώνοντας ότι τα bots στοχεύουν συγκεκριμένο περιεχόμενο.

Η απάντηση σε ένα ψεύτικο φραγμένο αίτημα μπορεί επίσης να είναι πιο λεπτή από ένα χύμα 403. Ορισμένες υλοποιήσεις επιστρέφουν 429 (Too Many Requests) για να καμουφλάρουν το γεγονός ότι το bot έχει αναγνωριστεί, κάνοντας δύσκολο για τον χειριστή bot να προσαρμόσει την προσέγγισή του. Άλλες επιστρέφουν 200 με ένα κενό σώμα, το οποίο σπαταλά ελάχιστο bandwidth ενώ αποτρέπει το bot να γνωρίζει ότι έχει ανιχνευθεί. Πιο επιθετικές προσεγγίσεις επιστρέφουν 403 με ένα μήνυμα υποδεικνύοντας ότι η επαλήθευση crawler απέτυχε, η οποία είναι διαφανής αλλά δίνει στους χειριστές bot πληροφορίες σχετικά με το μηχανισμό ανίχνευσης. Η επιλογή εξαρτάται από τη φιλοσοφία του διαχειριστή ιστότοπου σχετικά με τη διαφάνεια έναντι της λειτουργικής ασφάλειας.

Για bots που ισχυρίζονται ότι είναι crawlers αλλά είναι πραγματικά νόμιμες υπηρεσίες που τυχαίνει να χρησιμοποιούν user agents τύπου crawler λανθασμένα, το φράγμα μπορεί να είναι πιο διαταρακτικό από το προβλεπόμενο. Ορισμένα εργαλεία παρακολούθησης SEO, για παράδειγμα, χρησιμοποιούν user agents τύπου Googlebot για να προσομοιώσουν πώς ο Google βλέπει μια σελίδα. Αυτά τα εργαλεία θα αποτύχουν την επαλήθευση επειδή δεν είναι Google, παρόλο που ο σκοπός τους είναι νόμιμος από την άποψη του διαχειριστή ιστότοπου. Το middleware μπορεί να το διαχειριστεί διατηρώντας μια whitelist των γνωστών περιοχών IP για αξιόπιστες υπηρεσίες τρίτων, ή εφαρμόζοντας επαλήθευση μόνο σε συγκεκριμένα μοτίβα user agents ενώ αγνοεί άλλα. Η ευελιξία της προσέγγισης middleware επιτρέπει αυτό το είδος λεπτής πολιτικής χωρίς να απαιτούνται αλλαγές στη διαμόρφωση του διακομιστή ιστού ή τον κώδικα εφαρμογής.

Σύγχρονη Έναντι Ασύγχρονης Επαλήθευσης

Η ερώτηση εάν θα επαληθεύσετε τα bots σύγχρονα ή ασύγχρονα επηρεάζει τόσο την αποτελεσματικότητα του φράγματος όσο και τη δυσμενή επίδραση στην απόδοση της εφαρμογής. Η σύγχρονη επαλήθευση σημαίνει ότι το middleware σταματά το αίτημα, καλεί το API επαλήθευσης, περιμένει για την απάντηση και στη συνέχεια είτε επιτρέπει είτε φράσσει το αίτημα βάσει του αποτελέσματος. Αυτή η προσέγγιση παρέχει άμεσο φράγμα αλλά προσθέτει καθυστέρηση στο πρώτο αίτημα από κάθε διεύθυνση IP. Με το cache, η καθυστέρηση επηρεάζει μόνο το πρώτο αίτημα, αλλά για εφαρμογές υψηλής κυκλοφορίας ακόμη και αυτή η περιστασιακή καθυστέρηση ενδέχεται να είναι απαράδεκτη.

Η ασύγχρονη επαλήθευση ακολουθεί μια διαφορετική προσέγγιση. Το πρώτο αίτημα από μια νέα IP επιτρέπεται να διέλθει ενώ ένα εργασία επαλήθευσης τοποθετείται σε ουρά στο παρασκήνιο. Όταν έρθει το αποτέλεσμα επαλήθευσης, αποθηκεύεται, και όλα τα επόμενα αιτήματα από αυτή την IP διαχειρίζονται σύμφωνα με το αποτέλεσμα. Αυτή η προσέγγιση προσθέτει μηδενική καθυστέρηση στον αγωγό αιτήματος αλλά επιτρέπει έναν μικρό αριθμό αρχικών αιτημάτων από ψεύτικα bots να περάσουν πριν ολοκληρωθεί η επαλήθευση. Για τις περισσότερες εφαρμογές, αυτή η αντιστάθμιση είναι αποδεκτή. Ένα ψεύτικο bot που στέλνει τρία αιτήματα πριν φραγεί έχει καταναλώσει πολύ λιγότερους πόρους από ό,τι ένα που στέλνει χιλιάδες αιτήματα χωρίς εμπόδιο.

Το σύστημα ουράς κάνει την ασύγχρονη προσέγγιση απλή. Το middleware αποστέλλει μια εργασία επαλήθευσης που καλεί το API ανίχνευσης bot, αποθηκεύει το αποτέλεσμα στο cache, και προαιρετικά εκπέμπει ένα γεγονός που άλλα μέρη της εφαρμογής μπορούν να ακούν. Η εργασία εκτελείται σε δευτερόλεπτα, που σημαίνει ότι το χρονικό παράθυρο κατά το οποίο το ανεπαλήθευτο bot traffic μπορεί να περάσει είναι εξαιρετικά ευρύ. Για εφαρμογές που χρησιμοποιούν ένα γρήγορο in-memory cache, το αποθηκευμένο αποτέλεσμα είναι διαθέσιμο σε όλες τις παρουσίες εφαρμογής αμέσως, οπότε ακόμη και σε ένα περιβάλλον με εξισορρόπηση φορτίου, η επαλήθευση χρειάζεται να συμβεί μόνο μία φορά ανά διεύθυνση IP σε όλους τους διακομιστές.

Μια υβριδική προσέγγιση συνδυάζει το καλύτερο και από τα δύο. Οι γνωστές bot user agents που ταιριάζουν με μοτίβα υψηλής εμπιστοσύνης ενεργοποιούν σύγχρονη επαλήθευση με αποθηκευμένα αποτελέσματα, προσθέτοντας ελάχιστη καθυστέρηση. Τα μοτίβα χαμηλής εμπιστοσύνης ενεργοποιούν ασύγχρονη επαλήθευση, επιτρέποντας το πρώτο αίτημα να διέλθει ενώ η επαλήθευση εκτελείται στο παρασκήνιο. Αυτή η σταδιακή προσέγγιση βελτιστοποιεί για τη συνήθη περίπτωση ενώ χειρίζεται τις οριακές περιπτώσεις με χάρη. Η θέση του middleware στον αγωγό αιτήματος το κάνει το ιδανικό μέρος για να υλοποιηθεί αυτή η λογική, επειδή έχει πρόσβαση σε όλες τις πληροφορίες που χρειάζονται για να πάρει τη απόφαση δρομολόγησης και εκτελείται πριν από οποιαδήποτε δαπανηρή λογική εφαρμογής.

Η Μετρήσιμη Επίδραση του Φράγματος στην Πόρτα

Τα αποτελέσματα της υλοποίησης middleware ανίχνευσης bot είναι ορατά σχεδόν αμέσως στις μετρικές του διακομιστή. Η πιο δραματική αλλαγή είναι στην κατανάλωση bandwidth. Τα ψεύτικα crawlers ζητούν ολόκληρες σελίδες HTML, συμπεριλαμβανομένων όλων των στοιχείων που αναφέρονται στην απάντηση. Κάθε φραγμένο αίτημα αποσώζει το bandwidth που θα είχε χρησιμοποιηθεί για τη μετάδοση της πλήρους απάντησης, η οποία για σελίδες με πολλό περιεχόμενο μπορεί να είναι δεκάδες ή εκατοντάδες kilobytes ανά αίτημα. Σε χιλιάδες φραγμένα αιτήματα ανά ώρα, οι εξοικονομήσεις bandwidth συσσωρεύονται σε σημαντικές μειώσεις κόστους, ιδιαίτερα για εφαρμογές που φιλοξενούνται σε παρόχους που χρεώνουν ανά gigabyte μεταφοράς.

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

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

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