# Περιπτώσεις για την άσκηση Z10.2 (μάθημα Διαχείριση VPS και διακομιστών Linux)

Για κάθε περίπτωση επιλέξτε ποιο είναι το λάθος και ποιο είναι το καλύτερο πρώτο βήμα. Όλα τα ονόματα και οι διευθύνσεις είναι παραδείγματα.

**Λάθη (από το μάθημα 10.2):**
A. Σύνδεση ως root με κωδικό πρόσβασης
B. Μια βάση δεδομένων, cache ή cluster αναζήτησης ανοιχτό προς το διαδίκτυο
C. Το Docker API ανοιχτό ή `docker.sock` μέσα σε ένα container
D. `chmod 777` για να εξαφανιστεί ένα μήνυμα σφάλματος
E. `curl ... | bash` και λογισμικό από οπουδήποτε
F. Καμία ενημέρωση ή ενημερώσεις "αργότερα"
G. Κανένα αντίγραφο ασφαλείας ή ένα αντίγραφο ασφαλείας που δεν έχει ελεγχθεί ποτέ
H. Πίνακας διαχείρισης ανοιχτός για όλους, χωρίς έλεγχο ταυτότητας δύο βημάτων
I. Μυστικά στο Git ή στο αρχείο compose σας
J. "Για λίγο" το firewall απενεργοποιημένο, τα πάντα ως root, καμία σημείωση

---

**Περίπτωση 1.** Στον `web1.example.com`, στο `compose.yaml` στην υπηρεσία `redis` υπάρχει: `ports: - "6379:6379"`. Το `ufw status` δείχνει μόνο τις 22, 80 και 443. Μια σάρωση από έξω βρίσκει την 6379 ανοιχτή.
Πρώτο βήμα: (a) επανεκκίνηση του ufw (b) αφαίρεση του κανόνα θύρας ή αλλαγή του σε `"127.0.0.1:6379:6379"` και ξανά `docker compose up -d` (c) αλλαγή του αριθμού θύρας του Redis (d) επανεκκίνηση του διακομιστή

**Περίπτωση 2.** Ο προγραμματιστής μιας διαδικτυακής εφαρμογής στον `app.example.net` αναφέρει ότι οι μεταφορτώσεις δεν λειτουργούσαν. Το "διόρθωσε" και τώρα όλα τα αρχεία στο `/var/www/app` είναι σε `-rwxrwxrwx`.
Πρώτο βήμα: (a) να μείνει έτσι, τώρα λειτουργεί (b) δικαιώματα εγγραφής στον χρήστη του web server μόνο για τον φάκελο μεταφορτώσεων, τα υπόλοιπα πίσω σε 644/755 με άλλον κάτοχο (c) εκτέλεση του web server ως root (d) απενεργοποίηση του AppArmor

**Περίπτωση 3.** Ένα δημόσιο repository περιέχει από χθες ένα αρχείο `.env` με `MAIL_API_KEY=...` του διακομιστή `web2.example.org`.
Πρώτο βήμα: (a) διαγραφή του αρχείου από το repository (b) ανάκληση του κλειδιού στην υπηρεσία email και δημιουργία νέου, και προσθήκη του `.env` στο `.gitignore` (c) μετονομασία του repository (d) καμία ενέργεια

**Περίπτωση 4.** Το `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` επιστρέφει `permitrootlogin yes` και `passwordauthentication yes`. Στο journal εμφανίζονται κάθε λεπτό απόπειρες σύνδεσης ως root.
Πρώτο βήμα: (a) εγκατάσταση του fail2ban και τίποτα άλλο (b) τοποθέτηση κλειδιού για έναν κανονικό διαχειριστή με sudo, δοκιμή, και στη συνέχεια απενεργοποίηση της σύνδεσης με κωδικό πρόσβασης και της σύνδεσης ως root με κωδικό πρόσβασης (c) μεταφορά του SSH στη θύρα 2222 (d) αποθήκευση του κωδικού πρόσβασης του root σε αρχείο κειμένου

**Περίπτωση 5.** Το `cat /etc/os-release` δείχνει μια έκδοση Ubuntu της οποίας η τυπική υποστήριξη έληξε πριν από τρία χρόνια, χωρίς ESM. Το `apt list --upgradable` είναι κενό.
Πρώτο βήμα: (a) ικανοποίηση, δεν υπάρχουν ενημερώσεις (b) προγραμματισμός αναβάθμισης ή νέου διακομιστή σε μια υποστηριζόμενη LTS, με snapshot και αντίγραφο ασφαλείας (c) επανεγκατάσταση του unattended-upgrades (d) επανεκκίνηση του διακομιστή

**Περίπτωση 6.** Ένα container `portainer` έχει το volume `/var/run/docker.sock:/var/run/docker.sock` και είναι προσβάσιμο στο `https://beheer.example.com` με τον κωδικό πρόσβασης `admin123`, χωρίς έλεγχο ταυτότητας δύο βημάτων.
Επιλέξτε το λάθος που επιτρέπει τη μεγαλύτερη ζημιά αν μαντέψει κάποιος τον κωδικό πρόσβασης. Πρώτο βήμα: (a) τοποθέτηση του πίνακα πίσω από ένα SSH tunnel ή σταθερή διεύθυνση και ορισμός ισχυρού κωδικού πρόσβασης με έλεγχο ταυτότητας δύο βημάτων (b) επανεκκίνηση του container (c) επιλογή άλλου subdomain (d) επανεγκατάσταση του Docker

**Περίπτωση 7.** Μετά από μια αποτυχημένη ενημέρωση της βάσης δεδομένων αποδεικνύεται ότι το μόνο αντίγραφο ασφαλείας είναι ένα snapshot δύο μηνών, στον ίδιο χώρο αποθήκευσης με τον διακομιστή. Κανείς δεν έχει δοκιμάσει ποτέ επαναφορά.
Πρώτο βήμα για το μέλλον: (a) δημιουργία περισσότερων snapshots (b) ρύθμιση κρυπτογραφημένων αντιγράφων ασφαλείας εκτός του διακομιστή (για παράδειγμα restic), με παρακολούθηση και δοκιμή επαναφοράς (c) να μην ενημερωθεί ποτέ ξανά η βάση δεδομένων (d) ένας δεύτερος δίσκος στον ίδιο διακομιστή

**Περίπτωση 8.** Στον διακομιστή υπάρχει `/usr/local/bin/tool` και μια άγνωστη πηγή πακέτων `extra.list` με την επιλογή `[trusted=yes]`. Κανείς δεν ξέρει από πού προέρχονται· ο προηγούμενος διαχειριστής εγκαθιστούσε "τα πάντα με μία γραμμή από έναν ιστότοπο".
Πρώτο βήμα: (a) να μείνουν, λειτουργεί (b) διερεύνηση του τι είναι η πηγή και το πρόγραμμα, απενεργοποίηση της πηγής με `trusted=yes`, και εγκατάσταση πλέον μόνο από τη διανομή ή την επίσημη πηγή του δημιουργού με `Signed-By` (c) επανεκκίνηση του διακομιστή (d) διαγραφή όλων των πακέτων

Συμπληρώστε για κάθε περίπτωση: λάθος (A-J) και πρώτο βήμα (a-d).