Απομόνωση περιοχών διαχείρισης με IP, VPN ή πρόσθετη προστασία

Εν ολίγοις: Την περιοχή διαχείρισης την προστατεύετε πιο αποτελεσματικά αν την ανοίξετε μόνο σε γνωστά δίκτυα: με λίστα επιτρεπόμενων IP στον διακομιστή ιστού, μέσω VPN με σταθερή διεύθυνση εξόδου ή με μια δεύτερη σύνδεση που παρεμβάλλεται πριν. Σημασία έχουν μια πλήρης λίστα όλων των διευθύνσεων διαχείρισης, ο σωστός χειρισμός των proxy και των CDN και μια δοκιμή από έξω. Ο περιορισμός συμπληρώνει τη σύνδεση δύο παραγόντων και τις ενημερώσεις, δεν τις αντικαθιστά.

Γιατί είναι εξαρχής ανοιχτό το backend;

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

Κάθε μία από αυτές τις διευθύνσεις είναι επιφάνεια επίθεσης. Οι φόρμες σύνδεσης δοκιμάζονται συστηματικά, τα εργαλεία διαχείρισης περιέχουν δικές τους ευπάθειες και τα πρόσθετα για το backend ελέγχονται συχνά λιγότερο από τον πυρήνα ενός CMS. Αν οι ξένοι δεν μπορούν καν να φτάσουν σε αυτές τις περιοχές, πολλές επιθέσεις πέφτουν στο κενό προτού αρχίσουν.

Με ειλικρίνεια: απέναντι στο ίδιο το PHP2Shell αυτό βοηθά ελάχιστα. Οι ευπάθειες βρίσκονται στον διερμηνέα και μπορούν, σύμφωνα με το php.net, να προκληθούν χωρίς σύνδεση μέσω δημόσιων σελίδων PHP. Ο περιορισμός του backend είναι μόνιμη σκλήρυνση, όχι επείγουσα διόρθωση.

Προστασία περιοχής διαχείρισης με IP, VPN ή δεύτερη σύνδεση

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

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

Ποιες διευθύνσεις ανήκουν στην πραγματικότητα στο backend;

Η πιο συχνή αδυναμία δεν είναι η τεχνολογία, αλλά μια ελλιπής λίστα. Προχωρήστε γι' αυτό με αυτή τη σειρά:

1. Καταγράψτε τις σελίδες σύνδεσης του CMS ή του καταστήματος, συμπεριλαμβανομένων εναλλακτικών διευθύνσεων σύνδεσης που δημιουργούν τα πρόσθετα.
2. Αναζητήστε εργαλεία διαχείρισης: διεπαφές βάσης δεδομένων, διαχειριστές αρχείων, σενάρια εγκατάστασης, σελίδες κατάστασης και παρακολούθησης.
3. Συμπεριλάβετε πάνελ φιλοξενίας και διακομιστή, που συχνά λειτουργούν σε δικές τους θύρες.
4. Ελέγξτε περιβάλλοντα δοκιμής και staging, που συχνά χρησιμοποιούν τα ίδια στοιχεία πρόσβασης με τον ζωντανό ιστότοπο.
5. Οριοθετήστε τις διεπαφές: Ορισμένες διαδρομές του backend καλούνται και από το δημόσιο frontend, για παράδειγμα για αιτήματα Ajax. Αυτές δεν επιτρέπεται να τις αποκλείσετε τυφλά, αλλιώς θα χαλάσουν φόρμες ή καλάθια αγορών.

Το πέμπτο σημείο είναι ο λόγος για τον οποίο ένας περιορισμός πρέπει πάντα να δοκιμάζεται. Στο WordPress, για παράδειγμα, ένα αρχείο στον φάκελο διαχείρισης χρησιμοποιείται και για δημόσιες λειτουργίες.

Ρύθμιση: λίστα επιτρεπόμενων IP και δεύτερη σύνδεση

Στο Nginx μπορούν να συνδυαστούν και οι δύο συνθήκες. Με το satisfy all ένα αίτημα πρέπει να προέρχεται από επιτρεπόμενο δίκτυο και επιπλέον να περάσει τη δεύτερη σύνδεση. Η διαδρομή, οι διευθύνσεις και η μεταβίβαση στην PHP είναι δείγματα:

location ^~ /backend/ {
    satisfy all;

    allow 192.0.2.0/24;      # εταιρικό δίκτυο (δείγμα)
    allow 198.51.100.10;     # έξοδος VPN (δείγμα)
    deny  all;

    auth_basic           "Interner Bereich";
    auth_basic_user_file /etc/nginx/htpasswd-backend;

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

Η εμφωλευμένη location για την PHP είναι σημαντική: λόγω του ^~ οι άλλοι κανόνες για .php δεν αξιολογούνται πια. Στο Apache επιτυγχάνετε το ίδιο με ένα μπλοκ όπου πρέπει να ισχύουν και οι δύο συνθήκες:

<Location "/backend">
    AuthType Basic
    AuthName "Interner Bereich"
    AuthUserFile /etc/apache2/htpasswd-backend
    <RequireAll>
        Require ip 192.0.2.0/24 198.51.100.10
        Require valid-user
    </RequireAll>
</Location>

Το αρχείο κωδικών ανήκει εκτός του webroot. Η δεύτερη σύνδεση μεταδίδει στοιχεία πρόσβασης σε κάθε αίτημα, γι' αυτό χρησιμοποιήστε την μόνο μέσω HTTPS.

Οι παγίδες: CDN, proxy, IPv6 και τηλεργασία

Αν ο ιστότοπός σας βρίσκεται πίσω από ένα CDN όπως το Cloudflare ή έναν load balancer, ο διακομιστής ιστού βλέπει αρχικά μόνο τις δικές του διευθύνσεις. Μια λίστα επιτρεπόμενων IP θα απέκλειε τότε είτε όλους είτε θα άφηνε να περάσουν όλοι. Ο διακομιστής ιστού πρέπει να παίρνει την πραγματική διεύθυνση από μια κεφαλίδα: στο Nginx με τα set_real_ip_from και real_ip_header, στο Apache με το mod_remoteip.

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

Δύο ακόμη σημεία παραβλέπονται συχνά. Αν ο διακομιστής είναι προσβάσιμος μέσω IPv6, χρειάζονται εγγραφή και οι διευθύνσεις IPv6 του δικτύου σας, αλλιώς οι διαχειριστές με IPv6 θα βρεθούν μπροστά σε αποκλεισμό. Και οι ιδιωτικές συνδέσεις διαδικτύου αλλάζουν τακτικά διεύθυνση. Για την τηλεργασία και τους εξωτερικούς παρόχους υπηρεσιών, ένα VPN είναι γι' αυτό συνήθως η πιο σταθερή λύση.

Πώς ελέγχετε ότι ο περιορισμός λειτουργεί

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

# Αναμενόμενο: 403 (αποκλεισμένο) ή 401 (ζητείται δεύτερη σύνδεση)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Ελέγξτε και απευθείας τα αρχεία PHP, όχι μόνο τον φάκελο
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php

Έπειτα οι ίδιες κλήσεις από το εταιρικό δίκτυο ή το VPN: εκεί η σελίδα πρέπει να είναι προσβάσιμη. Ελέγξτε στη συνέχεια το δημόσιο frontend, δηλαδή φόρμες, αναζήτηση και καλάθι αγορών. Στα αρχεία καταγραφής των επόμενων ημερών οι προσβάσεις στις διευθύνσεις διαχείρισης πρέπει να εμφανίζονται σχεδόν μόνο με κατάσταση 401 ή 403.

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

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

• Καταγράφουμε όλες τις διευθύνσεις διαχείρισης των ιστοτόπων, των πάνελ και των εργαλείων σας και τις διαχωρίζουμε από τις διαδρομές που χρειάζονται δημόσια.
• Επιλέγουμε μαζί σας την κατάλληλη μέθοδο, ανάλογα με το μέγεθος της ομάδας, την τηλεργασία και τη φιλοξενία.
• Εφαρμόζουμε τους κανόνες στον διακομιστή ιστού, λαμβάνουμε υπόψη CDN, proxy και IPv6 και κρατάμε ταυτόχρονα ανοιχτό έναν δρόμο επιστροφής.
• Δοκιμάζουμε από έξω και από μέσα και παραδίδουμε σύντομη τεκμηρίωση με τα επιτρεπόμενα δίκτυα.

Ο περιορισμός των περιοχών διαχείρισης είναι μέρος της σκλήρυνσης διακομιστή για διακομιστές ιστού PHP που προσφέρουμε.

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

Πηγές

• OWASP Cheat Sheet Series
• Τεκμηρίωση του Nginx
• Apache HTTP Server: τεκμηρίωση