Firewall ή WAF: τι βλέπει και τι σταματά το καθένα

Τι αποφασίζει ένα stateful firewall

Ένα firewall Layer 3/4 παρακολουθεί συνδέσεις και κρίνει κάθε νέα με βάση τις διευθύνσεις της, το port της και την κατάσταση της ροής στην οποία ανήκει. Το Cisco Firepower, το OPNsense και το netfilter το κάνουν όλα καλά: ένα port που δεν ανοίγει κανένας κανόνας είναι κλειστό, μια απάντηση επιτρέπεται μόνο για σύνδεση που ξεκίνησε από μέσα, και τα ports διαχείρισης απαντούν μόνο στα εύρη που βρίσκονται στην allow-list. Η οπτική του σταματά στο επίπεδο μεταφοράς. Με TLS στη διαδρομή δεν μπορεί να δει καθόλου μέσα στο payload, εκτός αν τερματίζει τη συνεδρία, και ακόμα και σε καθαρή κίνηση δεν έχει καμία έννοια URL, header, κωδικού απόκρισης ή login.

Τι προσθέτει ένα WAF

Ένα web application firewall διαβάζει τη συναλλαγή HTTP μετά τον τερματισμό του TLS, που στην πράξη σημαίνει ότι ζει μέσα ή δίπλα στον reverse proxy. Προσθέτει τρία είδη ελέγχου που το firewall δεν μπορεί να εκφράσει. Οι κανόνες υπογραφών, όπως το ModSecurity με το OWASP Core Rule Set, ταιριάζουν injection, traversal και γνωστά exploit payloads μέσα στο αίτημα. Οι κανόνες συμπεριφοράς μετρούν ανά client και ανά path: αιτήματα το λεπτό στη διαδρομή login, αποκρίσεις αποτυχημένου login ανά διεύθυνση, ενδείξεις bot σε headers και χρονισμό. Οι θετικοί κανόνες δηλώνουν τι δέχεται ένα path, όπως ποιες μεθόδους, ποιους τύπους περιεχομένου και τι μέγεθος body, και απορρίπτουν τα υπόλοιπα.

Ένα WAF δεν υποκαθιστά το firewall. Βλέπει μόνο την κίνηση που φτάνει σε αυτό, και δεν ξέρει τίποτα για SSH, ports βάσεων δεδομένων ή το επίπεδο διαχείρισης.

Πού γίνεται ορατή η κατάχρηση του login

Ένα αποτυχημένο login είναι ένα γεγονός στην απόκριση. Η εφαρμογή απαντά σε ένα POST προς το path του login με έναν κωδικό ή μια ανακατεύθυνση που ξεχωρίζει την αποτυχία από την επιτυχία, και ο proxy το γράφει στο access log του σε κάθε απόπειρα. Το να μετρήσετε τις αποτυχίες ανά client ανά λεπτό είναι μία γραμμή awk πάνω σε αυτό το log, και είναι το σήμα που ένα packet filter δεν έχει κανέναν τρόπο να δει.

Ο έλεγχος πρέπει να κλειδώνει στον client, όχι στον λογαριασμό. Το κλείδωμα λογαριασμού από μόνο του σταματά τις απόπειρες εναντίον ενός username και κλειδώνει έξω τον κάτοχό του, ενώ το bot προχωρά στο επόμενο όνομα της λίστας του. Ένα όριο ρυθμού ανά client στη διαδρομή login κάνει αυτό που το κλείδωμα δεν μπορεί:

# nginx: at most 5 login attempts a minute per client, small burst allowed
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /login {
    limit_req zone=login burst=5 nodelay;
    proxy_pass http://app;
}

Το HAProxy εκφράζει την ίδια ιδέα με ένα stick table κλειδωμένο στη διεύθυνση πηγής, και ένα σύνολο κανόνων WAF μπορεί να μετρήσει απευθείας τον κωδικό απόκρισης του αποτυχημένου login.

Πώς ταιριάζουν τα δύο μεταξύ τους

Η σειρά είναι firewall, μετά τερματισμός TLS και ο proxy με τους κανόνες WAF του, μετά η εφαρμογή. Η ανίχνευση ανήκει στο Layer 7, γιατί εκεί βρίσκονται τα στοιχεία. Η επιβολή μπορεί να γίνει σε οποιοδήποτε από τα δύο επίπεδα. Ο proxy μπορεί να απαντήσει στον παραβάτη client με 429 ή 403 στο επόμενο αίτημά του, που αρκεί για τις περισσότερες καταχρήσεις. Για έναν client που επιμένει, ο proxy μπορεί να στείλει τη διεύθυνση στον δυναμικό πίνακα του packet filter για ορισμένο διάστημα, κάτι που κόβει και τις υπόλοιπες συνδέσεις αυτού του client και δεν κοστίζει τίποτα στο firewall ανά πακέτο.

Δύο σημεία σχεδιασμού προηγούνται της ενεργοποίησης αυτού του βρόχου ανάδρασης. Τα εύρη διαχείρισης και παρακολούθησης του διαχειριστή μπαίνουν πρώτα στην allow-list, ώστε μια δοκιμή ή ένα τυπογραφικό λάθος να μην μπορεί να κλειδώσει έξω τους ανθρώπους που λειτουργούν την πλατφόρμα. Και οι κοινόχρηστες διευθύνσεις είναι υπαρκτές: ένα NAT γραφείου ή ένα carrier-grade NAT βάζει πολλούς ανθρώπους πίσω από μία διεύθυνση, οπότε τα blocks έχουν σύντομη λήξη και τεκμηριωμένο τρόπο άρσης. Ολόκληρη η αλυσίδα δοκιμάζεται έπειτα από host εκτός δικτύου, όπως θα τη συναντούσε ένας επιτιθέμενος, πριν βασιστεί κανείς σε αυτή.

Τι δεν βλέπει κανένα από τα δύο

Έναν σωστό κωδικό. Το credential stuffing με έναν διαρρεύσαντα, έγκυρο κωδικό μοιάζει με επιτυχημένο login σε κάθε επίπεδο. Αυτό το κενό κλείνει με multi-factor authentication στον λογαριασμό και με allow-list των διαχειριστικών paths στο firewall, ώστε ένα έγκυρο credential να είναι άχρηστο από διεύθυνση που δεν είναι δική σας.