Εν ολίγοις: Η αλλαγή CMS μετά από hack βοηθά μόνο αν το παλιό σύστημα ήταν το ίδιο η αιτία, για παράδειγμα επειδή ο κατασκευαστής δεν παρέχει πλέον ενημερώσεις ασφαλείας ή σημαντικές επεκτάσεις δεν συντηρούνται πια. Αν η αιτία ήταν ξεπερασμένα πρόσθετα, αδύναμες προσβάσεις ή μια ευπάθεια όπως το PHP2Shell στην υποκείμενη PHP, η αλλαγή μετατοπίζει μόνο την προσπάθεια. Σε κάθε περίπτωση ισχύει: πρώτα ελέγξτε το περιεχόμενο, έπειτα μεταφέρετέ το, διαφορετικά ο κακόβουλος κώδικας μεταφέρεται μαζί.
Όταν η εμπιστοσύνη έχει χαθεί
Μετά από μια παραβίαση η διάθεση είναι συχνά σαφής: «με αυτό το σύστημα ποτέ ξανά». Είναι κατανοητό. Ο ιστότοπος ανακατεύθυνε επισκέπτες σε ξένες σελίδες, η Google προειδοποίησε, οι πελάτες ρωτούσαν. Ένα νέο CMS μοιάζει με νέα αρχή.
Η κατάσταση γύρω από το PHP2Shell δείχνει όμως γιατί αυτό το αντανακλαστικό μπορεί να παραπλανήσει. Η ευπάθεια βρίσκεται στον διερμηνέα PHP και όχι στο WordPress, στο TYPO3, στο Shopware ή σε κάποιο άλλο σύστημα. Το WordPress.org δεν σχεδιάζει, σύμφωνα με το drweb.de, δική του ενημέρωση κατά αυτής. Όποιος μεταβαίνει τώρα από ένα CMS PHP σε άλλο CMS PHP, έχει στο τέλος την ίδια εξάρτηση, μόνο με άλλο λογότυπο. Ποια συστήματα λειτουργούν σε PHP, δείχνει η επισκόπηση Ποια CMS και συστήματα e-shop λειτουργούν σε PHP.
Η αιτία αποφασίζει
Πριν σκεφτείτε μια αλλαγή, πρέπει να έχει διευκρινιστεί η αιτία της παραβίασης. Τυπικές πύλες εισόδου είναι ξεπερασμένες επεκτάσεις, κωδικοί που χρησιμοποιούνται πολλαπλά ή αδύναμοι, η απουσία σύνδεσης δύο παραγόντων, ένας διακομιστής χωρίς patch ή ξεχασμένες δοκιμαστικές εγκαταστάσεις. Καμία από αυτές τις αιτίες δεν συνδέεται με ένα συγκεκριμένο CMS.
Όποιος δεν γνωρίζει την αιτία, διακινδυνεύει να τη μεταφέρει στο νέο σύστημα. Μια ομάδα που ως τώρα ανέβαλλε τις ενημερώσεις, θα το κάνει το ίδιο και στο νέο CMS. Ένα πρακτορείο που χρησιμοποιούσε κοινούς λογαριασμούς διαχειριστή, θα το επαναλάβει, αν δεν αλλάξει κανείς τη διαδικασία. Το ερώτημα δεν είναι λοιπόν τόσο «ποιο CMS;», αλλά «ποια διαδικασία;».
Αλλαγή CMS μετά το hack: η στάθμιση
| Κριτήριο | Παραμονή στο υπάρχον CMS και σκλήρυνση | Αλλαγή σε άλλο CMS |
|---|---|---|
| Αιτία της παραβίασης | Γνωστή και αντιμετωπίσιμη, π.χ. ξεπερασμένο πρόσθετο | Βρίσκεται στο ίδιο το σύστημα, π.χ. απουσία ενημερώσεων κατασκευαστή |
| Συντήρηση από τον κατασκευαστή | Παρέχονται ενημερώσεις ασφαλείας | Ο κατασκευαστής έχει σταματήσει τη συντήρηση |
| Εξάρτηση από επεκτάσεις | Λίγες, συντηρούμενες επεκτάσεις | Πολλές επεκτάσεις χωρίς ενεργή συντήρηση |
| Προσπάθεια | Καθαρισμός, σκλήρυνση, αλλαγή διαδικασίας | Ανοικοδόμηση, μετάβαση, εκπαίδευση, συχνά νέος σχεδιασμός |
| Χρόνος μέχρι τον ασφαλή ιστότοπο | Μικρότερος | Μεγαλύτερος, απαιτείται προσωρινή λύση |
| Προστασία από ευπάθειες PHP | Καμία αλλαγή, η PHP πρέπει να έχει patch | Καμία αλλαγή, όσο το νέο σύστημα χρησιμοποιεί PHP |
| Μακροπρόθεσμο όφελος | Υψηλό, αν βελτιωθούν οι διαδικασίες | Υψηλό, αν το παλιό σύστημα ήταν ούτως ή άλλως στο τέλος του |
Αν οι περισσότερες γραμμές στην περίπτωσή σας καταλήγουν αριστερά, η αλλαγή σπάνια αξίζει. Παραμονή, καθαρισμός, σκλήρυνση και βελτίωση της διαδικασίας συντήρησης αποφέρουν περισσότερη ασφάλεια με λιγότερα χρήματα. Για διαχειριστές WordPress, το WordPress και PHP2Shell συνοψίζει τα σημαντικότερα βήματα.
Πάροχο υπηρεσιών δεν τον χρειάζεστε πάντα για αυτή την απόφαση. Αν η αιτία ήταν σαφής, για παράδειγμα ένα γνωστό πρόσθετο με δημοσιευμένη ευπάθεια, και το πρακτορείο ή ο διαχειριστής σας έχει στήσει καθαρά τον ιστότοπο από την αρχή, μπορείτε να αποφασίσετε μόνοι σας. Η εξωτερική βοήθεια αξίζει όταν η αιτία παραμένει ασαφής ή ενδέχεται να επηρεάζονται δεδομένα προσωπικού χαρακτήρα.
Αν αλλάξετε: μην πάρετε μαζί τον κακόβουλο κώδικα
Αν η απόφαση είναι για αλλαγή, η ίδια η μετάβαση είναι κίνδυνος ασφαλείας. Οι επιτιθέμενοι αφήνουν ίχνη όχι μόνο σε αρχεία, αλλά και στη βάση δεδομένων. Αυτά τα βήματα βοηθούν να μετακομίσετε καθαρά:
- Διασώστε και απομονώστε το παλιό σύστημα: Πλήρες αντίγραφο ως τεκμήριο, έπειτα θέστε το παλιό σύστημα εκτός δικτύου ή προσβάσιμο μόνο εσωτερικά.
- Εξαγάγετε το περιεχόμενο στοχευμένα: Κείμενα, δομή σελίδων και πολυμέσα, όχι ολόκληρη τη βάση δεδομένων. Μην μεταφέρετε λογαριασμούς χρηστών, δημιουργήστε τους εκ νέου.
- Ελέγξτε το περιεχόμενο: Εξετάστε τα κείμενα για εισαχθέντα scripts, κρυμμένους συνδέσμους και ξένες ανακατευθύνσεις. Πώς γίνεται, περιγράφει το Έλεγχος της βάσης δεδομένων για εισαχθέντα κώδικα.
- Φιλτράρετε τα πολυμέσα: Μεταφέρετε μόνο αναμενόμενους τύπους αρχείων, απορρίψτε αρχεία με διπλές καταλήξεις ή περιεχόμενο scripts.
- Στήστε καθαρά το νέο σύστημα: Από την αρχική πηγή του κατασκευαστή, σε διακομιστή με PHP που έχει patch, με νέα διαπιστευτήρια και σύνδεση δύο παραγόντων.
- Σχεδιάστε τις ανακατευθύνσεις: Οι παλιές διευθύνσεις ανακατευθύνονται στις νέες, ώστε να φτάνουν οι μηχανές αναζήτησης και οι επισκέπτες, χωρίς να παραμένουν ανοιχτές παλιές διαδρομές.
Η αλλαγή CMS δεν αντικαθιστά τον καθαρισμό του παλιού διακομιστή. Αν το παλιό σύστημα συνεχίσει να λειτουργεί, για παράδειγμα ως ξεχασμένο αντίγραφο σε υποτομέα, η κερκόπορτα παραμένει ανοιχτή.
Η εναλλακτική που συχνά παραβλέπεται
Ορισμένες επιχειρήσεις διαπιστώνουν μετά από ένα hack ότι δεν χρειάζονται καθόλου τις λειτουργίες ενός μεγάλου CMS. Ένας εταιρικός ιστότοπος με λίγες σελίδες που αλλάζουν σπάνια, επαρκεί και χωρίς PHP στον διακομιστή. Μια γεννήτρια στατικών σελίδων παράγει έτοιμα αρχεία HTML που δεν χρειάζονται πια λογική προγραμματισμού στον διακομιστή. Ποια πλεονεκτήματα και μειονεκτήματα έχει αυτό, περιγράφει το Στατικοί ιστότοποι: λιγότερη PHP, μικρότερη επιφάνεια επίθεσης.
Αντίστροφα, για e-shops, πύλες ή ιστότοπους με πολλούς συντάκτες αυτό συνήθως δεν είναι επιλογή. Εδώ ένα δυναμικό σύστημα παραμένει λογικό, και η ασφάλεια προκύπτει από συντήρηση, σκλήρυνση και παρακολούθηση.
Όποιος αμφιβάλλει αν στο παλιό WordPress κρύβονται ακόμη προσβάσεις, θα βρει στο Εντοπισμός backdoors στο WordPress τα τυπικά σημεία εύρεσης. Αυτό βοηθά και στην απόφαση αν ένας καθαρισμός είναι ρεαλιστικός.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Διευκρινίζουμε πρώτα την αιτία της παραβίασης και σας λέμε αν οφείλεται στο CMS ή στη διαδικασία και στον διακομιστή.
- Καθαρίζουμε το υπάρχον σύστημα στο πλαίσιο της αφαίρεσης κακόβουλου λογισμικού ή το προετοιμάζουμε ως τεκμήριο για ανοικοδόμηση.
- Σε περίπτωση αλλαγής ελέγχουμε το περιεχόμενο και τα πολυμέσα που θα μεταφερθούν για κακόβουλο κώδικα, πριν φτάσουν στο νέο σύστημα.
- Στήνουμε τον νέο διακομιστή με PHP που έχει patch και σκληρυμένη διαμόρφωση.
Συμπέρασμα
Η αλλαγή CMS μετά από hack σπάνια είναι η λύση, αλλά μερικές φορές είναι η σωστή αφορμή. Αν το παλιό σύστημα δεν συντηρείται πια, αξίζει η νέα αρχή. Αν η αιτία βρισκόταν σε διαδικασίες ή στον διακομιστή, η δουλειά στη διαδικασία προσφέρει περισσότερα από ένα νέο λογότυπο. Και στις δύο περιπτώσεις ισχύει: πρώτα ελέγξτε, έπειτα μετακομίστε.
Συχνές ερωτήσεις
Βοηθά η αλλαγή CMS απέναντι στο PHP2Shell;
Όχι, εφόσον και το νέο CMS λειτουργεί σε PHP. Το PHP2Shell βρίσκεται στον διερμηνέα PHP και όχι στο CMS. Καθοριστικό είναι το επίπεδο patch της PHP στον διακομιστή και όχι το σύστημα από πάνω.
Είναι το WordPress λιγότερο ασφαλές από άλλα CMS;
Γενικά δεν μπορεί να ειπωθεί. Πολλές παραβιάσεις προκύπτουν από ξεπερασμένες επεκτάσεις, αδύναμες προσβάσεις ή ελλιπείς ενημερώσεις, και αυτές οι αιτίες υπάρχουν σε κάθε σύστημα. Η διάδοση κάνει πάντως ένα CMS συχνότερο στόχο αυτοματοποιημένων σαρώσεων.
Μπορώ απλώς να εξαγάγω περιεχόμενο από το παραβιασμένο CMS;
Μόνο μετά από έλεγχο. Η βάση δεδομένων μπορεί να περιέχει εισαχθέντα scripts, κρυμμένους συνδέσμους ή ξένους λογαριασμούς διαχειριστή. Τα αρχεία που έχουν ανέβει μπορεί να καμουφλάρουν κακόβουλο κώδικα. Εξαγάγετε το περιεχόμενο στοχευμένα και ελέγξτε το πριν από την εισαγωγή.
Πότε έχει πραγματικά νόημα μια αλλαγή CMS;
Όταν ο κατασκευαστής δεν παρέχει πλέον ενημερώσεις ασφαλείας, όταν ο ιστότοπος εξαρτάται από επεκτάσεις που δεν συντηρούνται πια ή όταν το σύστημα απλώς δεν ταιριάζει πλέον στις σημερινές απαιτήσεις. Το hack είναι τότε η αφορμή και όχι ο λόγος.