# Εγκατάσταση από την αρχή ή καθαρισμός; Η απόφαση μετά από μια προσβολή

> Διακομιστής μετά από hack: νέα εγκατάσταση ή καθαρισμός; Τα κριτήρια, η σωστή σειρά και τα τυπικά λάθη στην ανοικοδόμηση, εξηγημένα κατανοητά.

Πηγή: https://phpsos.de/el/blog/neu-aufsetzen-oder-bereinigen/  
Ημερομηνία: 25/10/2026  
Πάροχος: PHP SOS, Επείγουσα βοήθεια PHP και ασφάλεια διακομιστών. Άμεση βοήθεια μέσω WhatsApp: https://wa.me/491736494914?text=%CE%93%CE%B5%CE%B9%CE%B1%20%CF%83%CE%B1%CF%82%2C%20PHP%20SOS%2C%20%CF%87%CF%81%CE%B5%CE%B9%CE%B1%CE%B6%CF%8C%CE%BC%CE%B1%CF%83%CF%84%CE%B5%20%CE%B2%CE%BF%CE%AE%CE%B8%CE%B5%CE%B9%CE%B1%20%CE%BC%CE%B5%20%CF%84%CE%BF%CE%BD%20%CE%B4%CE%B9%CE%B1%CE%BA%CE%BF%CE%BC%CE%B9%CF%83%CF%84%CE%AE%20PHP%20%CE%BC%CE%B1%CF%82.%20%CE%95%CF%84%CE%B1%CE%B9%CF%81%CE%B5%CE%AF%CE%B1%3A%20%E2%80%A6%20%CE%99%CF%83%CF%84%CF%8C%CF%84%CE%BF%CF%80%CE%BF%CF%82%3A%20%E2%80%A6

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

## Γιατί αυτό το ερώτημα τίθεται ιδιαίτερα συχνά μετά το PHP2Shell

Το PHP2Shell επιτρέπει, σύμφωνα με το php.net, την εκτέλεση κακόβουλου κώδικα εξ αποστάσεως χωρίς σύνδεση. Όποιος λειτουργούσε διακομιστή χωρίς patch, πρέπει γι' αυτό να αναρωτηθεί αν στο διάστημα από τις 17/10/2026, την πρώτη κατά δημοσιεύματα παρατηρηθείσα απόπειρα επίθεσης, συνέβη κάτι. Το patch δεν απαντά σε αυτό το ερώτημα, και δεν υπάρχουν δημοσιευμένοι, επιβεβαιωμένοι Indicators of Compromise.

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

## Η σειρά πριν από την απόφαση

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

1. **Περιορισμός:** Θέστε τον διακομιστή εκτός δικτύου ή περιορίστε την πρόσβαση στα απολύτως απαραίτητα, χωρίς να τον απενεργοποιήσετε, αν πρέπει ακόμη να διασωθεί η μνήμη εργασίας.
2. **Διάσωση τεκμηρίων:** Διασώστε logs, αρχεία, βάση δεδομένων και, αν γίνεται, ένα είδωλο του συστήματος, με ημερομηνία και άθροισμα ελέγχου. Γιατί αυτό είναι απαραίτητο πριν από κάθε νέα εγκατάσταση, εξηγεί το [Διάσωση τεκμηρίων πριν από την εγκατάσταση από την αρχή](https://phpsos.de/el/blog/beweise-sichern-vor-neuinstallation/).
3. **Εμπλοκή ασφαλιστή και προστασίας δεδομένων:** Πολλά ασφαλιστήρια κυβερνοκινδύνων αναμένουν να συντονίζονται τα ουσιώδη βήματα. Υποδείξεις υπάρχουν στο [Ασφάλιση κυβερνοκινδύνων: τι μετράει σε περίπτωση ζημίας](https://phpsos.de/el/compliance/cyberversicherung/). Το αν υπάρχει υποχρέωση γνωστοποίησης βάσει ΓΚΠΔ, το αξιολογούν ο υπεύθυνος προστασίας δεδομένων ή ο δικηγόρος.

Μόνο έπειτα αξίζει η πραγματική στάθμιση.

## Εγκατάσταση από την αρχή μετά από hack ή καθαρισμός: τα κριτήρια

| Κριτήριο | Καθαρισμός | Νέα εγκατάσταση |
|---|---|---|
| Έκταση της παραβίασης | Στενά οριοθετημένη, τεκμηριωμένη, π.χ. ένα αρχείο στον φάκελο μεταφορτώσεων χωρίς άλλα ίχνη | Ασαφής ή με ενδείξεις πρόσβασης στο σύστημα |
| Πιθανά δικαιώματα root του επιτιθέμενου | Αποκλείονται με καλά τεκμήρια | Δεν μπορούν να αποκλειστούν |
| Διαθεσιμότητα logs | Πλήρη για τη σχετική περίοδο | Ελλιπή, αντικατεστημένα ή παραποιήσιμα |
| Προσπάθεια | Μικρότερη, όταν το εύρημα είναι σαφές | Μεγαλύτερη, αλλά πιο προγραμματίσιμη |
| Εναπομένουσα αβεβαιότητα | Υψηλότερη, οι κρυμμένες κερκόπορτες δύσκολα αποκλείονται | Χαμηλότερη, όταν χτιστεί καθαρά από αξιόπιστες πηγές |
| Χρόνος διακοπής | Συνήθως μικρότερος | Συνήθως μεγαλύτερος, με προετοιμασία καλά ελέγξιμος |
| Καταλληλότητα για παλιά συστήματα | Προβληματική, όταν το σύστημα είναι ούτως ή άλλως ξεπερασμένο | Καλή ευκαιρία για μετάβαση σε υποστηριζόμενη έκδοση PHP |

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

## Οι δύο δρόμοι στην πράξη

### Τι σημαίνει πραγματικά «εγκατάσταση από την αρχή»

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

Μόνο τότε προστίθεται το δικό σας περιεχόμενο, και μάλιστα ελεγμένο. Τα αρχεία που έχουν ανέβει δεν επιτρέπεται να περιέχουν εκτελέσιμα scripts, η βάση δεδομένων μπορεί να περιέχει εισαχθέν περιεχόμενο, όπως κρυμμένους λογαριασμούς διαχειριστή ή scripts σε αναρτήσεις. Τα αρχεία διαμόρφωσης γράφονται από την αρχή αντί να αντιγράφονται. Όλα τα διαπιστευτήρια ανανεώνονται: βάση δεδομένων, διαχειριστές CMS, κλειδιά SSH, κλειδιά API, πίνακας ελέγχου φιλοξενίας.

Τα αντίγραφα ασφαλείας παίζουν σημαντικό ρόλο, αλλά μόνο αν η κατάστασή τους είναι πριν από την παραβίαση και δεν έχουν τροποποιηθεί και τα ίδια. Πολλές γενεές σε χωριστά σημεία το καθιστούν ελέγξιμο· περισσότερα στο [Αντίγραφα ασφαλείας με τον κανόνα 3-2-1](https://phpsos.de/el/ratgeber/backups-3-2-1/).

### Όταν ο καθαρισμός είναι δικαιολογημένος

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

Σημασία έχει μια ρεαλιστική εκτίμηση: τα webshells είναι συχνά διακριτικά και κρυμμένα σε πολλά σημεία. Πώς τα βρίσκετε, περιγράφει το [Εντοπισμός και αφαίρεση webshells](https://phpsos.de/el/ratgeber/webshell-erkennen/). Μετά από έναν καθαρισμό ο διακομιστής πρέπει να παρακολουθείται στενά, ώστε μια κερκόπορτα που ξέφυγε να γίνει αντιληπτή.

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

## Πότε δεν χρειάζεστε πάροχο υπηρεσιών

Σε έναν απλό ιστότοπο σε shared hosting, όπου ο πάροχος φιλοξενίας διαχειρίζεται το σύστημα και επιβεβαιώνει το patch PHP, η απόφαση συχνά δεν ανήκει καν σε εσάς. Μπορείτε να εγκαταστήσετε εκ νέου την εφαρμογή από το πρωτότυπο, να ελέγξετε το περιεχόμενο και να ανανεώσετε τα διαπιστευτήρια, με την υποστήριξη του παρόχου φιλοξενίας. Και μια έμπειρη εσωτερική ομάδα μπορεί να διεκπεραιώσει μόνη της μια ανοικοδόμηση, αν η διάσωση τεκμηρίων και η τεκμηρίωση είναι σε τάξη.

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

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

1. Διασώζουμε logs, αρχεία και βάση δεδομένων με αποδεικτική αξία, πριν αλλάξει οτιδήποτε.
2. Αξιολογούμε την έκταση της παραβίασης και προτείνουμε καθαρισμό ή ανοικοδόμηση με αιτιολόγηση, χωρισμένη σε τεκμηριωμένο, πιθανό και άγνωστο.
3. Ανοικοδομούμε τον διακομιστή, αν χρειάζεται, από αξιόπιστες πηγές, με PHP που έχει patch και ανανεωμένες προσβάσεις.
4. Αναλαμβάνουμε την [αφαίρεση κακόβουλου λογισμικού](https://phpsos.de/el/leistungen/malware-entfernung/) όπου ο καθαρισμός είναι δικαιολογημένος, και τεκμηριώνουμε κάθε βήμα.

## Συμπέρασμα

Το ερώτημα «εγκατάσταση από την αρχή ή καθαρισμός;» απαντάται μέσα από τη γνώση της παραβίασης. Όποιος δεν γνωρίζει με βεβαιότητα την έκταση, ανοικοδομεί. Όποιος μπορεί να την οριοθετήσει με τεκμήρια, μπορεί να καθαρίσει. Και στις δύο περιπτώσεις ισχύει η ίδια σειρά: περιορισμός, διάσωση, κλείσιμο της ευπάθειας, έπειτα τακτοποίηση.


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

**Είναι η νέα εγκατάσταση μετά από hack πάντα καλύτερη;**  
Όχι πάντα, αλλά συχνά. Αν δεν είναι σαφές πόσο μακριά έφτασε ο επιτιθέμενος, η ανοικοδόμηση από αξιόπιστες πηγές είναι συνήθως η πιο αξιόπιστη επιλογή. Σε μια στενά οριοθετημένη, καλά τεκμηριωμένη προσβολή μπορεί να αρκεί ένας καθαρισμός.

**Μπορώ απλώς να επαναφέρω ένα παλιό αντίγραφο ασφαλείας;**  
Μόνο αν είναι βέβαιο ότι το αντίγραφο δημιουργήθηκε πριν από την παραβίαση και δεν περιέχει κερκόπορτα. Επιπλέον, η ευπάθεια πρέπει να έχει κλείσει νωρίτερα, διαφορετικά ο διακομιστής είναι αμέσως ξανά ευάλωτος. Δεδομένα πιο πρόσφατης ημερομηνίας πρέπει να ελεγχθούν χωριστά.

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

**Αρκεί να διαγράψω το webshell που βρέθηκε;**  
Σπάνια. Οι επιτιθέμενοι δημιουργούν συχνά πολλές κερκόπορτες, για παράδειγμα cronjobs, λογαριασμούς χρηστών ή κλειδιά SSH. Όποιος διαγράφει μόνο το ορατό αρχείο, αφήνει ανοιχτές τις άλλες προσβάσεις.

## Πηγές

- [BSI: πληροφορίες για περιστατικά ασφαλείας](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: ανακοινώσεις ασφαλείας](https://www.php.net/)