Χρήση του ModSecurity και του OWASP Core Rule Set

Εν ολίγοις: Το ModSecurity είναι ένα Web Application Firewall που εκτελείται στον διακομιστή ιστού· το OWASP Core Rule Set (CRS) προσφέρει ελεύθερα διαθέσιμους κανόνες κατά διαδεδομένων ειδών επίθεσης. Για τον Apache το έργο CRS συνιστά το ModSecurity v2, για το Nginx έρχονται σε αναζήτηση ο connector v3 ή το Coraza. Ξεκινήστε σε λειτουργία αποκλεισμού με πολύ υψηλά όρια anomaly, μειώστε τα σταδιακά και χειριστείτε τους ψευδείς συναγερμούς με στοχευμένες εξαιρέσεις. Μια ενημέρωση PHP δεν αντικαθίσταται.

Ένα δικό σας WAF ως πρόσθετο στρώμα

Από το PHP2Shell πολλές επιχειρήσεις ρωτούν αν χρειάζονται ένα Web Application Firewall. Όποιος σερβίρει τους ιστοτόπους του μέσω Cloudflare έχει, σύμφωνα με την Cloudflare, αυτόματα ενεργούς κανόνες προστασίας από τις 21 Οκτωβρίου 2026. Όποιος δεν το κάνει ή δεν θέλει να κατευθύνει την κίνηση δεδομένων μέσω τρίτου, μπορεί να λειτουργήσει ένα WAF απευθείας στον δικό του διακομιστή.

Ο πιο γνωστός συνδυασμός γι' αυτό είναι το ModSecurity με το OWASP Core Rule Set. Και τα δύο είναι ανοιχτού κώδικα και δωρεάν. Το CRS είναι μια συλλογή γενικών κανόνων εντοπισμού, για παράδειγμα κατά της SQL injection, του Cross-Site Scripting ή της εισαγωγής αρχείων. Το έργο περιγράφει ο ίδιος τον στόχο του ως γενικό εντοπισμό επιθέσεων με όσο το δυνατόν λιγότερους ψευδείς συναγερμούς, ως ένα δομικό στοιχείο ανάμεσα σε πολλά.

Έτσι ονομάζεται και το όριο. Ένα WAF ελέγχει αιτήματα και απαντήσεις, δεν επισκευάζει ευπάθεια στον διερμηνέα PHP. Γιατί χρειάζεστε και τα δύο, περιγράφει το WAF ή ενημέρωση: γιατί χρειάζεστε και τα δύο.

Ποια μηχανή ταιριάζει στον διακομιστή ιστού σας

Το σύνολο κανόνων χρειάζεται μια μηχανή που να το εκτελεί. Σύμφωνα με την τεκμηρίωση του CRS υπάρχουν τρεις συμβατές επιλογές:

Για το υπόβαθρο: το ModSecurity αναπτυσσόταν επί μακρόν από την Trustwave. Η Trustwave ανακοίνωσε το 2021 ότι θα τερματίσει την ανάπτυξη το 2024. Στις 25 Ιανουαρίου 2024 το έργο πέρασε στο OWASP Foundation. Για νέες εγκαταστάσεις ελέγξτε ποια έκδοση παραδίδει η διανομή σας και πόσο επίκαιρη είναι.

Πώς λειτουργεί το Core Rule Set

Το CRS δεν αποκλείει στην προεπιλεγμένη ρύθμιση στην πρώτη ύποπτη ανωμαλία. Λειτουργεί με πόντους anomaly: κάθε κανόνας που ενεργοποιείται προσθέτει πόντους ανάλογα με τη σοβαρότητά του και μόνο όταν το άθροισμα ξεπεράσει ένα όριο, το αίτημα απορρίπτεται.

1. Βαθμοί σοβαρότητας: κρίσιμο 5 πόντοι, σφάλμα 4, προειδοποίηση 3, ένδειξη 2.
2. Όριο για αιτήματα: tx.inbound_anomaly_score_threshold, προεπιλογή 5.
3. Όριο για απαντήσεις: tx.outbound_anomaly_score_threshold, προεπιλογή 4.
4. Επίπεδο paranoia 1 έως 4 στο crs-setup.conf: το επίπεδο 1 είναι η βασική προστασία για κάθε διακομιστή στο διαδίκτυο, το επίπεδο 2 ταιριάζει σύμφωνα με το έργο σε εφαρμογές με πραγματικά δεδομένα χρηστών όπως τα ηλεκτρονικά καταστήματα, τα επίπεδα 3 και 4 φέρνουν σημαντικά περισσότερους ψευδείς συναγερμούς.

Ένα υψηλότερο επίπεδο paranoia εντοπίζει περισσότερα, παράγει όμως και περισσότερους ψευδείς συναγερμούς. Για τους περισσότερους εταιρικούς ιστοτόπους το επίπεδο 1 είναι η αρχή, το επίπεδο 2 ένας μεταγενέστερος στόχος.

Εισαγωγή του ModSecurity με OWASP CRS χωρίς να παραλύσει ο ιστότοπος

Το έργο CRS συνιστά για νέες εγκαταστάσεις να ενεργοποιείται από την αρχή η λειτουργία αποκλεισμού, αλλά με πολύ υψηλά όρια, έως 10000, και να μειώνονται στη συνέχεια σταδιακά. Έτσι συλλέγετε εμπειρία με πραγματικές προσβάσεις, χωρίς να αποκλείετε χρήστες. Τα όρια τα ορίζετε στο crs-setup.conf:

# crs-setup.conf: φάση εκκίνησης με πολύ υψηλά όρια
SecAction \
    "id:900110,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    setvar:tx.inbound_anomaly_score_threshold=10000,\
    setvar:tx.outbound_anomaly_score_threshold=10000"

Η ενσωμάτωση στον Apache ακολουθεί τη σειρά που ορίζει η τεκμηρίωση του CRS για τα plugins. Οι διαδρομές διαφέρουν ανά διανομή:

<IfModule security2_module>
    SecRuleEngine On
    Include /etc/modsecurity/crs/crs-setup.conf
    Include /etc/modsecurity/crs/plugins/*-config.conf
    Include /etc/modsecurity/crs/plugins/*-before.conf
    Include /etc/modsecurity/crs/rules/*.conf
    Include /etc/modsecurity/crs/plugins/*-after.conf
</IfModule>

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

Στοχευμένος χειρισμός ψευδών συναγερμών

Οι ψευδείς συναγερμοί είναι φυσιολογικοί, ιδίως σε backends CMS με επεξεργαστές που αποθηκεύουν HTML. Η χειρότερη αντίδραση είναι η απενεργοποίηση του WAF. Καλύτερα είναι δύο εργαλεία.

Πρώτον, plugins: το έργο CRS συντηρεί plugins με κανόνες εξαιρέσεων για διαδεδομένες εφαρμογές, για παράδειγμα για το WordPress. Αντιγράφονται στον φάκελο των plugins και φορτώνονται μέσω των γραμμών Include που φαίνονται παραπάνω. Την επίσημη λίστα τηρεί το έργο στον κατάλογο των plugins του.

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

# Δική σας εξαίρεση, να φορτωθεί ΠΡΙΝ από τους κανόνες CRS (π.χ. σε αρχείο *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
    "id:1000010,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveById=941100"

Το ID του κανόνα το παίρνετε από το audit log του ψευδούς συναγερμού. Τεκμηριώστε κάθε εξαίρεση με λόγο και ημερομηνία, ώστε να μπορεί να επανεξεταστεί αργότερα.

Για διακομιστές Apache αξίζει να προσεγγίσετε το WAF μαζί με την υπόλοιπη διαμόρφωση· τα βασικά υπάρχουν στο Ασφαλής διαμόρφωση του Apache για PHP. Πώς κατατάσσονται οι κανόνες της Cloudflare συγκριτικά, δείχνει το Κανόνες προστασίας της Cloudflare κατά του PHP2Shell. Τα μεταβατικά μέτρα στον ίδιο τον διακομιστή υπάρχουν στο Άμεσα μέτρα όταν δεν μπορείτε ακόμη να εφαρμόσετε patch.

Συμπέρασμα: ένα WAF θέλει φροντίδα

Το ModSecurity με το OWASP Core Rule Set σας δίνει ένα ισχυρό Web Application Firewall χωρίς κόστος αδειών και χωρίς εξάρτηση από εξωτερική υπηρεσία. Το τίμημα είναι δουλειά: επιλογή της μηχανής ανάλογα με τον διακομιστή ιστού, εκκίνηση με υψηλά όρια, αξιολόγηση ψευδών συναγερμών, συντήρηση εξαιρέσεων και ενημέρωση των κανόνων.

Όποιος δεν μπορεί να καταβάλει αυτή την προσπάθεια, συχνά τα πηγαίνει καλύτερα με ένα καλά ρυθμισμένο WAF στο cloud. Όποιος την καταβάλλει, αποκτά ένα στρώμα που πιάνει πολλές τυπικές επιθέσεις και προσφέρει στα audit logs πολύτιμες ενδείξεις. Σε καμία περίπτωση δεν αντικαθιστά την ενημέρωση: κατά του PHP2Shell προστατεύουν μόνο οι PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ή ένα επιβεβαιωμένο backport, ακολουθούμενα από επανεκκίνηση όλων των διεργασιών PHP.

Πώς βοηθά συγκεκριμένα η PHP SOS;

• Επιλογή μηχανής: Ελέγχουμε διακομιστή ιστού, διανομή και διαθέσιμα πακέτα και προτείνουμε τον κατάλληλο συνδυασμό.
• Εισαγωγή: Εγκαθιστούμε το CRS με υψηλά αρχικά όρια, ενσωματώνουμε κατάλληλα plugins και στήνουμε την καταγραφή.
• Συντονισμός: Σε διάστημα αρκετών εβδομάδων αξιολογούμε ψευδείς συναγερμούς, ορίζουμε στοχευμένες εξαιρέσεις και μειώνουμε τα όρια.
• Τοποθέτηση: Στο πλαίσιο του WAF και του εικονικού patching συνδέουμε το WAF με μεταβατικά μέτρα και τον δρόμο προς το κανονικό patch.

Συχνές ερωτήσεις

Πηγές

• OWASP CRS: τεκμηρίωση
• OWASP Top 10
• Blog της Cloudflare
• php.net: ανακοινώσεις ασφαλείας