Μετάβαση στο περιεχόμενο

Ρυθμίσεις cookies

Επιλέξτε ανά κατηγορία ποια cookies επιτρέπετε. Μπορείτε να αλλάξετε την επιλογή σας οποιαδήποτε στιγμή μέσω των Ρυθμίσεων cookies στο κάτω μέρος κάθε σελίδας. Δήλωση απορρήτου

Απαραίτητα

Πάντα ενεργά

Χρειάζονται για τη σύνδεση, για να διατηρείται το καλάθι σας και για να θυμόμαστε τις επιλογές σας. Είναι πάντα ενεργά.

Ποια cookies;
  • weboke_sessie, weboke_klant, weboke_remember: η συνεδρία σας και η παραμονή σε σύνδεση
  • weboke_basket: το καλάθι σας
  • wkBtwIncl: εμφάνιση τιμών με ή χωρίς ΦΠΑ
  • wok_cookies: η επιλογή σας για τα cookies, 12 μήνες

Μετρούν ποια διαφήμιση οδηγεί σε επίσκεψη ή παραγγελία, ώστε να μην πληρώνουμε για διαφημίσεις που δεν αποδίδουν.

Ποια cookies;
  • Google Ads μέσω Google Tag Manager (_gcl_au, _gcl_aw), έως 90 ημέρες
  • OpenAI Ads, διαφημίσεις στο ChatGPT
  • wok_aff: μέσω ποιου συνεργάτη ήρθατε σε εμάς (πρόγραμμα συνεργατών), 60 ημέρες

4,6

Χώρα και γλώσσα

Κάθε χώρα έχει τη δική της ιστοσελίδα, με τιμές και ΦΠΑ της χώρας αυτής.

Προβολή

Τι δεν πρέπει να κάνετε

Ενότητα 10: Παραμείνετε ασφαλείς · Χρόνος ανάγνωσης: 12 λεπτά

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

Βασικές έννοιες: σύνδεση root με κωδικό πρόσβασης, αδύναμος ή προεπιλεγμένος κωδικός πρόσβασης, ανοιχτή βάση δεδομένων, Docker API στη θύρα 2375, docker.sock σε container, chmod 777, curl | bash, μυστικά στο Git, πίνακας διαχείρισης χωρίς έλεγχο ταυτότητας δύο βημάτων, firewall "για λίγο κλειστό", καμία ενημέρωση, κανένα αντίγραφο ασφαλείας

Γιατί ένα μάθημα για τα λάθη;

Οι περισσότεροι servers δεν παραβιάζονται από έναν ιδιοφυή επιτιθέμενο με ένα άγνωστο κενό ασφαλείας. Παραβιάζονται από bots που σαρώνουν ολόκληρο το internet αναζητώντας γνωστά λάθη: έναν κωδικό πρόσβασης που μαντεύεται, μια βάση δεδομένων που είναι ανοιχτή, ένα πρόγραμμα που εδώ και μήνες δεν έχει ενημερωθεί. Όποιος αποφεύγει τα λάθη αυτού του μαθήματος, βγαίνει από το στόχαστρο αυτών των bots. Αυτό είναι το μεγαλύτερο μέρος της προστασίας που μπορείτε να αποκτήσετε.

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

1. Σύνδεση root με κωδικό πρόσβασης

Το πρόβλημα. Κάθε server δέχεται όλη την ημέρα απόπειρες σύνδεσης στο root (μάθημα 5.3). Αν ο root μπορεί να συνδεθεί με κωδικό πρόσβασης, τότε αυτός ο κωδικός είναι το μόνο που στέκεται ανάμεσα σε ένα bot και τον πλήρη έλεγχο. Κωδικοί που επαναχρησιμοποιούνται ή είναι πολύ σύντομοι μαντεύονται αργά ή γρήγορα ή βρίσκονται ήδη σε κάποια λίστα που έχει διαρρεύσει.

Κάντε αυτό. Σύνδεση μόνο με κλειδιά: PasswordAuthentication no και KbdInteractiveAuthentication no, ο root το πολύ με κλειδί (PermitRootLogin prohibit-password) ή καθόλου (no) και καθημερινή εργασία ως απλός χρήστης με sudo (μαθήματα 2.2 και 3.2). Ελέγξτε από έξω ποιες μεθόδους σύνδεσης προσφέρει ο server σας (άσκηση Z2.2).

2. Μια βάση δεδομένων, cache ή cluster αναζήτησης ανοιχτό στο internet

Το πρόβλημα. Τα MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch ή OpenSearch (9200) και MongoDB (27017) έχουν σχεδιαστεί για αξιόπιστα προγράμματα σε αξιόπιστο δίκτυο. Αν ακούνε στο 0.0.0.0 χωρίς firewall, οι scanners τα βρίσκουν γρήγορα. Το Redis αναφέρει στην ίδια του την τεκμηρίωση ότι δεν πρέπει να εκτίθεται στο internet και ότι όποιος έχει πρόσβαση μπορεί να διαγράψει ολόκληρο το σύνολο δεδομένων· μέσω της εντολής CONFIG ένας επιτιθέμενος μπορεί ακόμη και να γράψει αρχεία στον server. Οι ανοιχτές βάσεις δεδομένων και τα ανοιχτά clusters αναζήτησης αποτελούν εδώ και χρόνια γνωστή αιτία μεγάλων διαρροών δεδομένων και μηνυμάτων "λύτρων" στη θέση των δεδομένων σας.

Κάντε αυτό. Ρυθμίστε τέτοιες υπηρεσίες να ακούνε στο 127.0.0.1 (μάθημα 5.1), κρατήστε τις πίσω από το firewall (μάθημα 5.2) και στο Docker μην τις δημοσιεύετε ή δημοσιεύστε τις μόνο στο 127.0.0.1 (μάθημα 9.3). Για δική σας πρόσβαση από τον φορητό σας υπολογιστή: ένα SSH tunnel (μάθημα 2.3). Ελέγξτε από έξω (άσκηση Z5.1).

3. Το Docker API ανοιχτό ή docker.sock σε container

Το πρόβλημα. Όποιος μπορεί να ελέγχει τον Docker daemon είναι στην πράξη root στον server: η τεκμηρίωση του Docker αναφέρει ότι μόνο αξιόπιστοι χρήστες επιτρέπεται να ελέγχουν τον daemon και θεωρεί την πρόσβαση στον daemon ισοδύναμη με πρόσβαση root. Δύο παραλλαγές αυτού του λάθους:

  • Ο daemon ακούει σε μια θύρα TCP χωρίς TLS (συνήθως η 2375). Οποιοσδήποτε φτάνει σε αυτή τη θύρα μπορεί να εκκινήσει containers με τον δίσκο του server σας μέσα σε αυτά.
  • Ένα container λαμβάνει το /var/run/docker.sock ως volume ("για να μπορεί να διαχειρίζεται μόνο του containers"). Αν αυτό το container παραβιαστεί, έχει χαθεί ολόκληρος ο server.

Και η ομάδα docker ισοδυναμεί με root (μάθημα 9.2): προσθέστε σε αυτήν μόνο διαχειριστές.

Κάντε αυτό. Αφήστε το Docker να λειτουργεί μόνο μέσω του τοπικού socket. Η απομακρυσμένη διαχείριση γίνεται μέσω SSH (docker context με ssh://) ή, αν πρέπει οπωσδήποτε να γίνει μέσω TCP, με TLS στη θύρα 2376 και πιστοποιητικά πελάτη. Κάντε mount το docker.sock μόνο σε container που εμπιστεύεστε πλήρως και χρειάζεστε πραγματικά, και κατά προτίμηση μόνο για ανάγνωση μέσω ενός περιοριστικού proxy.

4. chmod 777 για να εξαφανιστεί ένα μήνυμα σφάλματος

Το πρόβλημα. "Permission denied" κατά τη μεταφόρτωση ενός αρχείου, και ένα φόρουμ λέει: chmod -R 777 /var/www. Από εκεί και πέρα κάθε χρήστης και κάθε διεργασία στον server μπορεί να γράψει οτιδήποτε στον ιστότοπό σας, ακόμη και ένα παραβιασμένο plugin ή ένας άλλος λογαριασμός. Κώδικας στον οποίο μπορεί να γράψει ο web server μπορεί, μέσω ενός κενού ασφαλείας, να αντικατασταθεί από backdoor.

Κάντε αυτό. Βρείτε ποιος χρειάζεται να γράφει και πού (μάθημα 3.1): συνήθως μόνο ο χρήστης του web server σε έναν φάκελο για uploads ή cache. Ο κώδικας να ανήκει σε άλλον ιδιοκτήτη από τον web server, με δικαιώματα 644/755, και τα uploads 750/640 ή κάτι παρόμοιο.

5. curl ... | bash και λογισμικό από παντού

Το πρόβλημα. Ένα script που εκτελείτε ως root χωρίς να το έχετε δει μπορεί να κάνει τα πάντα: να προσθέσει πηγές πακέτων και κλειδιά, να αντικαταστήσει αρχεία, να ανοίξει μια υπηρεσία. Ακόμη κι αν η πρόθεση είναι καλή, μετά δεν ξέρετε τι έχει αλλάξει και στην επόμενη αναβάθμιση έκδοσης κάτι χαλάει (μάθημα 4.3).

Κάντε αυτό. Κατεβάστε και διαβάστε το script. Προτιμήστε την εγκατάσταση από την πηγή πακέτων της διανομής σας ή από την επίσημη πηγή του δημιουργού, με δικό της κλειδί (Signed-By, μάθημα 4.1). Σημειώστε τι εγκαθιστάτε και γιατί.

6. Καμία ενημέρωση ή ενημερώσεις "αργότερα"

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

Κάντε αυτό. Ενεργοποιήστε τις αυτόματες ενημερώσεις ασφαλείας (μάθημα 4.2), ορίστε μια σταθερή στιγμή για επανεκκινήσεις, καταχωρίστε την ημερομηνία λήξης της έκδοσής σας στο ημερολόγιό σας (μάθημα 4.3) και ενημερώνετε τακτικά τα containers (μάθημα 9.4).

7. Κανένα αντίγραφο ασφαλείας ή ένα αντίγραφο που δεν έχει δοκιμαστεί ποτέ

Το πρόβλημα. Ένα snapshot στον ίδιο αποθηκευτικό χώρο δεν είναι αντίγραφο ασφαλείας (μάθημα 8.1). Ένα αντίγραφο ασφαλείας που βρίσκεται στον ίδιο τον server χάνεται μαζί του σε μια παραβίαση ή επίθεση ransomware. Και ένα αντίγραφο ασφαλείας που δεν έχει επαναφερθεί ποτέ είναι μια ελπίδα, όχι βεβαιότητα.

Κάντε αυτό. Κρυπτογραφημένα αντίγραφα ασφαλείας εκτός του server (restic, μάθημα 8.2), παρακολούθηση ότι εκτελούνται και τουλάχιστον κάθε τρίμηνο μια δοκιμή επαναφοράς.

8. Πίνακες διαχείρισης ανοιχτοί σε όλους, χωρίς έλεγχο ταυτότητας δύο βημάτων

Το πρόβλημα. Ένας πίνακας διαχείρισης βάσης δεδομένων (όπως το phpMyAdmin), του Docker (όπως το Portainer), της εφαρμογής σας ή του διαχειριστή κωδικών σας είναι ελκυστικός στόχος: ένας μόνο κωδικός δίνει πρόσβαση σε όλα. Προεπιλεγμένοι κωδικοί όπως admin/admin και εγγραφή που παραμένει ανοιχτή (Vaultwarden, μάθημα 9.4) το κάνουν ακόμη πιο εύκολο.

Κάντε αυτό. Μην ανοίγετε πίνακες διαχείρισης στο internet: αποκτήστε πρόσβαση σε αυτούς μέσω SSH tunnel ή μόνο από μια σταθερή διεύθυνση. Αν ένας πίνακας πρέπει οπωσδήποτε να είναι δημόσιος: https, ένας ισχυρός μοναδικός κωδικός από τον διαχειριστή κωδικών σας, έλεγχος ταυτότητας δύο βημάτων και κλειστή εγγραφή. Αλλάζετε πάντα τους προεπιλεγμένους κωδικούς.

9. Μυστικά στο Git ή στο αρχείο compose

Το πρόβλημα. Ένας κωδικός πρόσβασης, ένα API key ή ένα private key σε αρχείο που καταλήγει σε ένα Git repository παραμένει εκεί για πάντα στο ιστορικό, ακόμη κι αν το αφαιρέσετε αργότερα. Τα δημόσια repositories σαρώνονται από bots ακριβώς για τέτοια κλειδιά.

Κάντε αυτό. Τα μυστικά σε ξεχωριστό αρχείο με δικαιώματα 600 (EnvironmentFile, μάθημα 6.3· .env στο Docker Compose, μάθημα 9.3), το οποίο αναφέρεται στο .gitignore. Αν παρ' όλα αυτά διαρρεύσει ένα μυστικό: αντικαταστήστε το αμέσως (νέος κωδικός, νέο κλειδί)· ο καθαρισμός μόνο στο Git δεν αρκεί.

10. Το firewall "για λίγο" κλειστό, τα πάντα ως root και καμία σημείωση

Το πρόβλημα. Το "θα κλείσω για λίγο το firewall για να δοκιμάσω" ξεχνιέται. Το "θα το κάνω για λίγο ως root" γίνεται συνήθεια. Και ένας server για τον οποίο κανείς δεν ξέρει τι τρέχει και γιατί δεν μπορεί ούτε να διαχειριστεί ούτε να αποκατασταθεί.

Κάντε αυτό. Κάντε δοκιμές με έναν προσωρινό, στενό κανόνα (μία θύρα, μία διεύθυνση προέλευσης) και αφαιρέστε τον μετά. Εργάζεστε ως απλός χρήστης με sudo. Τηρείτε έναν σύντομο φάκελο του server: τι τρέχει, ποιες θύρες είναι ανοιχτές, πού βρίσκονται τα αντίγραφα ασφαλείας, πότε λήγει η έκδοση (μάθημα 10.4).

Στην πράξη

Όλα αυτά τα λάθη μπορούν να γίνουν σε κάθε VPS, στη WebOké όπως και σε άλλους παρόχους: ό,τι συμβαίνει μέσα στον server σας το διαχειρίζεστε εσείς. Ο πάροχος μπορεί όμως να αποσυνδέσει έναν server από το δίκτυο αν στέλνει spam ή εκτελεί επιθέσεις, επειδή αυτό επηρεάζει άλλους πελάτες. Η πρόληψη είναι λοιπόν σημαντική και για τη δική σας διαθεσιμότητα.

Σύνοψη

  • Οι περισσότερες παραβιάσεις εκμεταλλεύονται γνωστά λάθη, όχι άγνωστα κενά ασφαλείας.
  • Σύνδεση με κλειδιά, σύνδεση με κωδικό απενεργοποιημένη· βάσεις δεδομένων, caches και το Docker API ποτέ ανοιχτά στο internet· κανένα docker.sock σε containers που δεν εμπιστεύεστε πλήρως.
  • Κανένα chmod 777 και κανένα curl | bash: να ξέρετε ποιος επιτρέπεται να κάνει τι και τι εγκαθιστάτε.
  • Αυτόματες ενημερώσεις, αντίγραφα ασφαλείας εκτός server και δοκιμασμένα, πίνακες διαχείρισης πίσω από tunnel ή με έλεγχο ταυτότητας δύο βημάτων.
  • Μυστικά εκτός Git και εκτός αρχείων compose· ό,τι διέρρευσε αντικαθίσταται.

Κουίζ

1. Γιατί είναι τόσο επικίνδυνος ένας Docker daemon που ακούει σε θύρα TCP χωρίς TLS;



2. Ο ιστότοπός σας εμφανίζει "Permission denied" κατά τη μεταφόρτωση μιας εικόνας. Ποια είναι η σωστή λύση;



3. Ανακαλύπτετε ότι κατά λάθος βάλατε ένα API key σε δημόσιο Git repository. Τι κάνετε πρώτα;



4. Ποιος συνδυασμός κάνει έναν server Redis πιο ευάλωτο;



5. Ένας συνάδελφος θέλει να ανοίξει το phpMyAdmin στο https://example.com/pma "επειδή είναι εύκολο". Ποια είναι η καλύτερη συμβουλή;



Άσκηση

Άσκηση Z10.2: Ποιο είναι το σφάλμα; Στο αρχείο παραδείγματος casussen-z10-2.md υπάρχουν οκτώ σύντομες περιπτώσεις servers που έχουν κάποιο πρόβλημα. Για κάθε περίπτωση επιλέξτε ποιο λάθος είναι από τη λίστα αυτού του μαθήματος (A έως και J) και ποιο είναι το καλύτερο πρώτο βήμα. Το πρόγραμμα συγκρίνει με το σταθερό κλειδί απαντήσεων και στη συνέχεια εμφανίζει την εξήγηση για κάθε περίπτωση.

Άσκηση Z10.2: Ποιο είναι το σφάλμα;

Αρχείο για αυτή την άσκηση: casussen-z10-2.md

















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

Για περαιτέρω μελέτη

Μια στιγμή…

Ρυθμίστε τα domains σας

Ρυθμίστε για κάθε domain τους nameservers, τη σύνδεση με το hosting σας και ποιος θα είναι ο κάτοχος.

Φόρτωση των domains σας…