Πώς προστατεύεται μια εφαρμογή από αυτόματες σαρώσεις

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

Το OWASP, η ανοιχτή κοινότητα ασφάλειας, την περιγράφει ως ανεπιθύμητη αυτόματη χρήση που συνεχίζεται «μέρα με τη μέρα». Σημειώνει επίσης ότι συχνά εκμεταλλεύεται φυσιολογικές λειτουργίες μιας εφαρμογής, όχι κάποιο χαλασμένο εξάρτημα. Αυτό συμφωνεί με ό,τι δείχνουν τα logs ενός διακομιστή. Μια νέα εφαρμογή μπορεί να δεχτεί δοκιμές λίγο μετά το άνοιγμά της, πολύ πριν τη γνωρίσει το κοινό της.

Άρα το χρήσιμο ερώτημα είναι «τι γίνεται όταν μας σαρώσουν;». Για ένα απλό εταιρικό site η απάντηση συχνά είναι «τίποτα σημαντικό». Για μια πλατφόρμα με δεδομένα πελατών, αξίζει μια προστασία σχεδιασμένη από την αρχή.

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

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

Ένα φίλτρο μπροστά από την εφαρμογή εξετάζει κάθε αίτημα και σταματά τα επιβλαβή πριν φτάσουν σε αυτήν. Στο AWS αυτό είναι το AWS WAF, ένα web application firewall. Με απλά λόγια, είναι ένα φίλτρο που σταματά την επιβλαβή κίνηση με βάση κανόνες που ορίζετε εσείς.

Η AWS το περιγράφει ως υπηρεσία που παρακολουθεί τα αιτήματα HTTP και HTTPS προς τους προστατευμένους πόρους. Ελέγχει την πρόσβαση με κριτήρια όπως η διεύθυνση IP από την οποία έρχεται ένα αίτημα ή οι τιμές στη διεύθυνση URL. Όταν ένα αίτημα ταιριάζει σε κανόνα αποκλεισμού, παίρνει απάντηση HTTP 403, δηλαδή «απαγορεύεται», ή μια προσαρμοσμένη απάντηση.

Τους κανόνες μπορούμε να τους γράψουμε εμείς. Υπάρχουν επίσης έτοιμες ομάδες κανόνων που συντηρεί η AWS. Στην υποδομή που περιγράφουμε στο case study για μια πλατφόρμα υγείας στις ΗΠΑ, το φίλτρο είχε 23 κανόνες: όρια αιτημάτων ανά επισκέπτη, γεωγραφικούς περιορισμούς, έτοιμες ομάδες για συνηθισμένες κακές εισόδους, ρητούς αποκλεισμούς για αιτήματα που ζητούν `.env`, `.git`, phpMyAdmin ή αρχεία PHP.

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

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

Για τον δεύτερο μηχανισμό χρησιμοποιούμε το AWS Lambda. Εκτελεί κώδικα ως απάντηση σε γεγονότα ή με χρονοδιάγραμμα, χωρίς να διαχειριζόμαστε διακομιστές. Στο case study που αναφέραμε, ένα σενάριο Python έτρεχε κάθε τρία λεπτά, εντόπιζε σαρωτές στα logs, τους μπλόκαρε με αυξανόμενη διάρκεια. Η κλιμάκωση έχει σημασία: η πρώτη παράβαση φέρνει σύντομο αποκλεισμό, η επιμονή μεγαλύτερο. Ένας λάθος αποκλεισμός λήγει σύντομα από μόνος του.

Η σειρά για ένα τέτοιο σύστημα είναι σύντομη:

1. Ορίζουμε τι είναι νόμιμο. Καταγράφουμε τις πραγματικές διαδρομές, τις μεθόδους, τις χώρες από όπου έρχονται οι χρήστες σας.

2. Προσθέτουμε τις έτοιμες ομάδες κανόνων. Καλύπτουν ευρέως γνωστές κακές εισόδους χωρίς να γράφουμε κάθε μοτίβο.

3. Προσθέτουμε ρητούς αποκλεισμούς για τα αρχεία και τις σελίδες που η εφαρμογή σας δεν σερβίρει ποτέ.

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

5. Τρέχουμε τον έλεγχο των logs με χρονοδιάγραμμα, ώστε οι επαναλαμβανόμενοι επισκέπτες να παίρνουν μεγαλύτερους αποκλεισμούς.

6. Ελέγχουμε τα logs κάθε εβδομάδα στην αρχή, για να εντοπίσουμε νόμιμους χρήστες που μπλοκαρίστηκαν κατά λάθος.

Το βλέπει διαβάζοντας τα logs, που οργανώνονται από πριν ώστε να διαβάζονται εύκολα. Το Amazon CloudWatch Logs Insights επιτρέπει αναζήτηση και ανάλυση των logs με ερωτήματα. Ετοιμάζουμε αποθηκευμένα ερωτήματα για τις συνηθισμένες ερωτήσεις: ποια αιτήματα επέστρεψαν σφάλματα 4xx ή 5xx, ποιοι επισκέπτες ανακατευθύνθηκαν, ποιες διευθύνσεις φαίνονται ύποπτες, τι έχει μπλοκάρει το φίλτρο.

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

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

Η εφαρμογή πρέπει να ελέγχει στον διακομιστή ό,τι λαμβάνει, ό,τι κι αν άφησε να περάσει το φίλτρο. Το φίλτρο δεν γνωρίζει τους κανόνες της επιχείρησής σας. Το Input Validation Cheat Sheet του OWASP συστήνει να γίνεται δεκτό μόνο ό,τι προορίζεται για κάθε πεδίο, αντί να απαριθμείται κάθε επιβλαβής συμβολοσειρά.

Ο ίδιος οδηγός εξηγεί ότι οι έλεγχοι στον browser παρακάμπτονται εύκολα. Χρησιμεύουν για άμεση ανατροφοδότηση στον χρήστη, ενώ ο διακομιστής πρέπει να τους επαναλαμβάνει. Γι' αυτό το φίλτρο είναι μία στρώση της προστασίας. Το OWASP Top 10, η πιο γνωστή λίστα με τους πιο κρίσιμους κινδύνους των web εφαρμογών, περιγράφει κινδύνους στον τρόπο που χτίζονται οι εφαρμογές. Αυτούς τους λύνει ο σωστός σχεδιασμός της εφαρμογής, πέρα από κάθε firewall.

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

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

Κάθε στρώση έχει τη δική της δουλειά. Το AWS GuardDuty, για παράδειγμα, είναι υπηρεσία ανίχνευσης απειλών. Παρακολουθεί τη δραστηριότητα και τα logs μέσα στον λογαριασμό σας AWS για σημάδια ασυνήθιστης συμπεριφοράς. Τα αντίγραφα ασφαλείας, ο έλεγχος πρόσβασης, ένα σχέδιο για το ποιος ενεργεί όταν έρθει ειδοποίηση μετράνε όσο κάθε κανόνας.

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