# Least Privilege: τα δικαιώματα του χρήστη του διακομιστή ιστού

> Χρήστης διακομιστή ιστού με ελάχιστα δικαιώματα: χωρίς shell, sudo και cron, με περιορισμένη βάση δεδομένων και systemd για PHP-FPM. Με εντολές ελέγχου.

Πηγή: https://phpsos.de/el/blog/rechte-des-webserver-benutzers/  
Ημερομηνία: 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

**Εν ολίγοις:** Ο χρήστης του διακομιστή ιστού, με τον οποίο εκτελείται η PHP, πρέπει σύμφωνα με την αρχή των ελάχιστων δικαιωμάτων (Least Privilege) να διαβάζει μόνο ό,τι χρειάζεται ο ιστότοπος και να γράφει μόνο εκεί όπου αποθηκεύει δεδομένα. Δεν έχει shell σύνδεσης, δικαιώματα sudo, δικές του εργασίες cron ούτε κλειδιά SSH, και ο λογαριασμός του στη βάση δεδομένων επιτρέπεται μόνο να διαβάζει και να αλλάζει δεδομένα. Επιλογές του systemd, όπως οι `ProtectSystem` και `PrivateTmp`, περιορίζουν επιπλέον το PHP-FPM.

## Το ερώτημα μετά την εισβολή: τι επιτρέπεται σε αυτή τη διεργασία;

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

Σε πολλούς διακομιστές αυτό είναι εκπληκτικά πολλά. Ο χρήστης είναι κάτοχος όλου του κώδικα του προγράμματος, έχει shell, μπορεί να δημιουργεί δικές του εργασίες cron, και ο λογαριασμός βάσης δεδομένων της εφαρμογής έχει όλα τα δικαιώματα σε όλες τις βάσεις. Για έναν επιτιθέμενο αυτή είναι η ιδανική αφετηρία για να εγκατασταθεί μόνιμα.

Πώς ορίζετε σωστά αρχεία και φακέλους, περιγράφει ο οδηγός [Δικαιώματα αρχείων στον διακομιστή ιστού](https://phpsos.de/el/ratgeber/dateirechte-webserver/). Αυτό το άρθρο εστιάζει στον ίδιο τον λογαριασμό: σύνδεση, ειδικά δικαιώματα, προγραμματισμένες εργασίες, βάση δεδομένων και τα όρια που θέτει το systemd.

## Καταγραφή της υπάρχουσας κατάστασης: ποιος είναι ο χρήστης του διακομιστή ιστού;

Αρχικά διευκρινίστε ποιοι χρήστες εμπλέκονται. Με το PHP-FPM κάθε pool ορίζει με τα `user` και `group` ποιος εκτελεί τους workers του. Με το mod_php η PHP εκτελείται ως χρήστης του Apache. Πώς συνεργάζονται ο master και οι workers στο PHP-FPM, εξηγεί το [PHP-FPM: διαχειριστής διεργασιών, pools και workers](https://phpsos.de/el/php/php-fpm-erklaert/). Οι παρακάτω εντολές μόνο διαβάζουν:

```bash
# Με ποιους χρήστες εκτελούνται ο διακομιστής ιστού και η PHP;
ps -eo user,group,cmd | grep -E "[p]hp-fpm|[n]ginx|[a]pache2|[h]ttpd" | sort | uniq -c
# Στοιχεία λογαριασμού: αρχικός φάκελος και shell (προσαρμόστε τον χρήστη)
getent passwd www-data
# Έχει ο χρήστης δικαιώματα sudo;
sudo -l -U www-data
# Δικές του εργασίες cron;
sudo crontab -l -u www-data
# Κλειδιά SSH στον αρχικό φάκελο (σε Debian/Ubuntu είναι ο /var/www)
sudo ls -la /var/www/.ssh 2>/dev/null
```

Σημειώστε τα αποτελέσματα για κάθε χρήστη pool. Αν όλοι οι ιστότοποι εκτελούνται με τον ίδιο χρήστη, αυτό είναι το πρώτο σημείο της λίστας· πώς θα τους διαχωρίσετε, περιγράφει το [Απομόνωση των pools PHP-FPM ανά ιστότοπο](https://phpsos.de/el/blog/php-fpm-pools-isolieren/).

## Δικαιώματα του χρήστη διακομιστή ιστού: όσα δεν χρειάζεται ο λογαριασμός

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

| Δικαίωμα | Γιατί είναι επικίνδυνο | Σύσταση |
|---|---|---|
| Shell σύνδεσης | Δυνατότητα σύνδεσης και διαδραστικής χρήσης | Shell `/usr/sbin/nologin` |
| Εγγραφές sudo | Δρόμος προς δικαιώματα root | Καμία εγγραφή, ούτε για μεμονωμένες εντολές |
| Δική του crontab | Μόνιμη κερκόπορτα που επιβιώνει σε κάθε επανεκκίνηση | Καμία, περιορισμός μέσω `/etc/cron.allow` |
| Κλειδιά SSH | Σύνδεση από έξω | Κανένα `authorized_keys` |
| Κυριότητα του κώδικα του προγράμματος | Ο κώδικας μπορεί να τροποποιηθεί | Κάτοχος είναι ένας χρήστης deploy |
| Δικαιώματα εγγραφής εκτός φακέλων δεδομένων | Αποθήκευση κακόβουλου κώδικα | Μόνο uploads, cache, temp |
| Πλήρη δικαιώματα βάσης δεδομένων | Βάσεις άλλων εφαρμογών, πρόσβαση σε αρχεία μέσω της βάσης | Μόνο η δική της βάση, μόνο δικαιώματα δεδομένων |

Το shell το ορίζετε με `usermod -s /usr/sbin/nologin www-data`. Για το cron ισχύει: αν υπάρχει το `/etc/cron.allow`, μόνο οι χρήστες που αναφέρονται εκεί επιτρέπεται να δημιουργούν δικές τους εργασίες cron. Νέες εργασίες cron ή άγνωστα κλειδιά SSH είναι τυπική ένδειξη ότι κάποιος έχει εγκατασταθεί μόνιμα. Ένα ιδιαίτερα ξεκάθαρο προειδοποιητικό σημάδι περιγράφει το άρθρο [Προειδοποιητικό σημάδι: ο διακομιστής ιστού εκκινεί shell](https://phpsos.de/el/blog/webserver-startet-shell/).

## Η βάση δεδομένων: περιορισμός των δικαιωμάτων στα απαραίτητα

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

```sql
-- Παράδειγμα MySQL/MariaDB: δικός του λογαριασμός ανά ιστότοπο, μόνο δικαιώματα δεδομένων
CREATE USER 'seite1'@'localhost' IDENTIFIED BY 'hier-ein-langes-Zufallspasswort';
GRANT SELECT, INSERT, UPDATE, DELETE ON seite1.* TO 'seite1'@'localhost';
-- Έλεγχος δικαιωμάτων
SHOW GRANTS FOR 'seite1'@'localhost';
```

Δικαιώματα όπως τα `FILE`, `SUPER` ή `GRANT OPTION` και πρόσβαση στο `*.*` δεν χρειάζεται ένας λογαριασμός εφαρμογής. Πολλά CMS χρειάζονται για ενημερώσεις επιπλέον τα `CREATE`, `ALTER`, `INDEX` και `DROP`. Καθαρότερη λύση είναι ένας χωριστός λογαριασμός για ενημερώσεις και μετεγκαταστάσεις, που χρησιμοποιείται μόνο κατά τη συντήρηση. Ελέγξτε τις απαιτήσεις στην τεκμηρίωση του κατασκευαστή.

## Επιπλέον περιορισμός του PHP-FPM με το systemd

Το systemd μπορεί να περιορίσει την εικόνα που έχει μια υπηρεσία για το σύστημα. Για το PHP-FPM ταιριάζουν ιδιαίτερα ορισμένες επιλογές από την τεκμηρίωση του systemd. Επηρεάζουν και την κύρια διεργασία, που ξεκινά ως root.

```ini
# sudo systemctl edit php8.3-fpm
[Service]
# τα /usr, /boot και /etc μόνο για ανάγνωση
ProtectSystem=full
# τα /home, /root και /run/user αόρατα
ProtectHome=true
# δικά του /tmp και /var/tmp μόνο για αυτή την υπηρεσία
PrivateTmp=true
# καμία αύξηση δικαιωμάτων μέσω setuid ή capabilities αρχείων
NoNewPrivileges=true
```

Δοκιμάστε αυτές τις επιλογές πριν από την παραγωγική χρήση. Αν οι ιστότοποι βρίσκονται κάτω από το `/home`, το `ProtectHome=true` εμποδίζει την πρόσβαση. Το `NoNewPrivileges=true` μπορεί να δημιουργήσει προβλήματα σε προγράμματα που καλεί η PHP και αλλάζουν κατά την εκκίνηση τα δικαιώματα ομάδας τους, όπως ορισμένα τοπικά προγράμματα αλληλογραφίας για τη συνάρτηση `mail()` της PHP. Προχωρήστε γι' αυτό σε βήματα:

1. Προσθέστε μία επιλογή, επανεκκινήστε την υπηρεσία, ελέγξτε με `systemctl status php8.3-fpm`.
2. Δοκιμάστε τις βασικές λειτουργίες του ιστοτόπου: σύνδεση, φόρμες, αποστολή email, uploads, εργασίες cron της εφαρμογής.
3. Αξιολογήστε το αρχείο σφαλμάτων του PHP-FPM και της εφαρμογής.
4. Μόνο τότε προσθέστε την επόμενη επιλογή.

Τέλος, το socket: σύμφωνα με το εγχειρίδιο της PHP, έχει από προεπιλογή δικαιώματα `0660` για τον χρήστη και την ομάδα του pool. Ορίστε τα `listen.owner` και `listen.group` έτσι ώστε να μπορεί να συνδεθεί μόνο ο διακομιστής ιστού και όχι κάθε τοπικός χρήστης.

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

## Συμπέρασμα: ο επιτιθέμενος κληρονομεί ό,τι επιτρέπετε

Το Least Privilege ακούγεται θεωρητικό, είναι όμως ένα πολύ πρακτικό ερώτημα: τι μπορεί να κάνει κάποιος που εκτελεί κώδικα ως χρήστης του διακομιστή ιστού; Σε έναν διακομιστή με shell, εγγραφή sudo, δική του crontab και λογαριασμό βάσης δεδομένων με όλα τα δικαιώματα, η απάντηση είναι: σχεδόν τα πάντα. Σε έναν περιορισμένο διακομιστή το περιστατικό περιορίζεται μάλλον σε έναν μεμονωμένο ιστότοπο και μπορεί να εντοπιστεί και να καθαριστεί.

Η αλλαγή δεν χρειάζεται νέο λογισμικό, μόνο προσεκτική καταγραφή της κατάστασης και σταδιακές δοκιμές. Ξεκινήστε με τα σημεία που δύσκολα χαλούν κάτι, δηλαδή shell, sudo και κλειδιά SSH, και προχωρήστε έπειτα στα δικαιώματα βάσης δεδομένων και στις επιλογές του systemd.

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

- **Έλεγχος λογαριασμών:** Καταγράφουμε για κάθε pool και διακομιστή ιστού τον χρήστη, το shell, τις εγγραφές sudo, τις εργασίες cron, τα κλειδιά SSH και τα δικαιώματα βάσης δεδομένων.
- **Μείωση δικαιωμάτων:** Αφαιρούμε ό,τι δεν χρειάζεται και διαχωρίζουμε λογαριασμούς deploy, λειτουργίας και συντήρησης.
- **Περιορισμός υπηρεσιών:** Ορίζουμε σταδιακά τις επιλογές προστασίας του systemd και δοκιμάζουμε τον ιστότοπο μετά από κάθε βήμα.
- **Διατήρηση στο διηνεκές:** Στο πλαίσιο της [σκλήρυνσης διακομιστή](https://phpsos.de/el/leistungen/server-haertung/) τεκμηριώνουμε το πλάνο δικαιωμάτων για μελλοντικές αλλαγές.


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

**Με ποιον χρήστη εκτελείται η PHP στον διακομιστή μου;**  
Εξαρτάται από τον τρόπο λειτουργίας. Με το mod_php η PHP εκτελείται ως χρήστης του Apache, για παράδειγμα www-data ή apache. Με το PHP-FPM κάθε pool ορίζει τον χρήστη του με τα user και group· η κύρια διεργασία (master) εκτελείται συνήθως ως root, οι workers ως χρήστης του pool. Η εντολή ps το δείχνει γρήγορα.

**Χρειάζεται ο χρήστης του διακομιστή ιστού shell σύνδεσης;**  
Όχι. Ούτε το Nginx ούτε το Apache ούτε το PHP-FPM χρειάζονται διαδραστική σύνδεση για αυτόν τον χρήστη. Ένα shell όπως το /usr/sbin/nologin εμποδίζει οποιονδήποτε να συνδεθεί με αυτόν τον λογαριασμό. Οι διαδικασίες ανάπτυξης (deployments) εκτελούνται με δικό τους χρήστη.

**Γιατί όχι δικαιώματα sudo για το www-data, ούτε για μία μόνο εντολή;**  
Επειδή ο κώδικας που εισάγεται κληρονομεί ακριβώς αυτά τα δικαιώματα. Ακόμη και μια φαινομενικά ακίνδυνη εντολή, αν εγκριθεί λανθασμένα, μπορεί να οδηγήσει σε δικαιώματα root. Εργασίες που απαιτούν αυξημένα δικαιώματα ανήκουν σε χωριστές υπηρεσίες ή διαδικασίες εκτός του διακομιστή ιστού.

**Βοηθά αυτό απέναντι στο PHP2Shell;**  
Δεν κλείνει την ευπάθεια· γι' αυτό χρειάζεται η ενημέρωση της PHP και η επανεκκίνηση όλων των workers. Τα ελάχιστα δικαιώματα περιορίζουν όμως τι μπορεί να κάνει ένας επιτιθέμενος μετά από επιτυχή εκμετάλλευση: να αλλάξει αρχεία, να εγκατασταθεί μόνιμα, να φτάσει σε άλλους ιστοτόπους.

## Πηγές

- [Εγχειρίδιο της PHP: διαμόρφωση FPM (user, listen.mode)](https://www.php.net/manual/en/install.fpm.configuration.php)
- [systemd.exec (ProtectSystem, PrivateTmp, NoNewPrivileges)](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html)
- [BSI IT-Grundschutz (βασική προστασία IT της Ομοσπονδιακής Υπηρεσίας Ασφάλειας Πληροφοριών της Γερμανίας)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)