Το προφίλ μας στο Google Plus
9

Ένας server, δύο σύννεφα [μέρος 2/3]

Στο πρώτο άρθρο του αφιερώματός μας για τη δημιουργία ενός ευέλικτου και οικονομικού server που “απλώνεται” σε δύο cloud hosts, ασχοληθήκαμε με το μέρος του compute. Αναλυτικότερα, φτιάξαμε ένα VPS και φροντίσαμε ώστε να έχουμε ασφαλή πρόσβαση μέσω SSH, χωρίς να δίνουμε κάποιο password αλλά με χρήση κλειδιών. Υπάρχουν πολλά ακόμη που μπορούμε και οφείλουμε να κάνουμε, ώστε να ενισχύσουμε περισσότερο την ασφάλεια του server.

Την πρώτη μας σύνδεση στο eyjafjallajokull.parabing.com την κάναμε από ένα Windows PC, με τη βοήθεια του PuTTY. Αν θυμόσαστε, ως image για το Droplet επιλέξαμε εκείνο με προεγκατεστημένο το ownCloud 8.0, σε Ubuntu Server 14.04 LTS με LAMP stack. Αμέσως μετά τη σύνδεση, στην κονσόλα μας είδαμε μερικά στατιστικά στοιχεία που αφορούσαν στο σύστημα, καθώς και τα περιεχόμενα του αρχείου /etc/motd.tail. Στο εν λόγω αρχείο υπάρχει το username του διαχειριστή του ownCloud (admin), καθώς και το αντίστοιχο “εργοστασιακό” password. Το τελευταίο εννοείται ότι οφείλουμε να το αλλάξουμε άμεσα (και μετά μπορούμε να διαγράψουμε και το /etc/motd.tail).

Η πρώτη απομακρυσμένη σύνδεση στο VPS μας, μέσω SSH και με password-less login. Το image που είχαμε επιλέξει προηγουμένως, κατά τη δημιουργία του Droplet, είχε και το ownCloud. Γι' αυτό και τώρα πληροφορούμαστε για το 'εργοστασιακό' password του χρήστη admin.

Επειδή ωστόσο δεν είναι βέβαιο ότι κι εσείς επιλέξατε το ownCloud image για το Droplet σας, ας ξεκινήσουμε καλύτερα με τις βασικές εργασίες που ούτως ή άλλως προτείνεται να κάνουμε σε κάθε VPS. Για τη συνέχεια, μόνη μας προϋπόθεση είναι ότι το λειτουργικό του Droplet είναι το Ubuntu Server 14.04 LTS. Αν υπάρχουν έξτρα software stacks ή όχι, προς το παρόν δεν έχει σημασία.

Κατ’ αρχάς, χρειάζεται να ορίσουμε ένα καλό password για το λογαριασμό του root:

root@eyjafjallajokull:~# passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

Καθώς το πληκτρολογούμε, το password δεν φαίνεται στην οθόνη. Προτείνουμε να ορίσετε ένα τυχαίο password με μεγάλο μήκος, που να συνδυάζει πεζά και κεφαλαία, να περιλαμβάνει αριθμούς καθώς και σύμβολα. Για ένα πραγματικά τυχαίο password αξίζει να καταφύγετε σε κάποιο εργαλείο όπως το “Generate Secure Password”, του δημοφιλούς browser add-on ονόματι LastPass. Είναι αδύνατο να θυμάται κανείς ένα password σαν αυτό που περιγράφουμε, οπότε και προτείνουμε να το αποθηκεύσετε ως “Secure Note” του LastPass. Ούτως ή άλλως, σε λίγο θα φροντίσουμε ώστε το σύστημα να δέχεται μόνο password-less logins: μόνον όποιος έχει στείλει το δημόσιο κλειδί του σε λογαριασμό χρήστη, θα μπορεί να συνδέεται σ’ αυτόν (μέσω SSH). Ειδικά για το λογαριασμό του root, θα ρυθμίσουμε τον OpenSSH server ώστε να μη δέχεται απομακρυσμένα logins με κανέναν τρόπο. Το password του root θα το χρειαζόμαστε μόνο σε σπάνιες περιπτώσεις, οπότε θα καταφεύγουμε στη web console της DigitalOcean. Αν για κάποιο λόγο έχουμε χάσει το password, ευτυχώς παρέχεται και η δυνατότητα “Reset Root Password” (στο VPS γίνεται shutdown και λαμβάνουμε email με νέο root password). Κατά τα άλλα, μέσω SSH και με key-based authentication, θα συνδεόμαστε στο λογαριασμό ενός απλού χρήστη που θα δημιουργήσουμε λίγο αργότερα. Όποτε χρειαζόμαστε δικαιώματα root, θα τα αποκτάμε με τη βοήθεια του sudo.

Ενημέρωση λειτουργικού συστήματος
Θέλουμε να αναβαθμίσουμε το σύστημα με τα πλέον πρόσφατα security patches κι ενημερώσεις. Αρχικά, φρεσκάρουμε τη λίστα με τα repositories:

root@eyjafjallajokull:~# apt-get update

Η αναβάθμιση γίνεται πληκτρολογώντας

root@eyjafjallajokull:~# apt-get dist-upgrade

Λογικά θα χρειαστεί να κατέβουν αρκετά πακέτα, αλλά δεν υπάρχει πρόβλημα: Αφενός η σύνδεση του VPS με τον έξω κόσμο είναι ταχύτατη, αφετέρου ο εικονικός του δίσκος είναι πάνω σε φυσικό δίσκο SSD. Έτσι, η διαδικασία της αναβάθμισης δεν θ’ αργήσει να ολοκληρωθεί. Στο δικό μας VPS άλλαξε κι ο πυρήνας του λειτουργικού, οπότε για να ενεργοποιηθεί ο νέος προχωρήσαμε σε επανεκκίνηση:

root@eyjafjallajokull:~# sudo reboot

Μετά το reboot συνδεθήκαμε ξανά κι αμέσως απομακρύναμε ορισμένα πακέτα που αφορούσαν σε προηγούμενη έκδοση του πυρήνα:

root@eyjafjallajokull:~# apt-get autoremove

Όλα καλά.

Αναβαθμίζουμε το Ubuntu Server και ξαφνικά καλούμαστε να πάρουμε μια απόφαση για το postfix. Φυσικά και δεν κάνουμε καμία αλλαγή στις προεπιλογές. Εξάλλου ό,τι αφορά σε mailserver αποτελεί θέμα άλλου αφιερώματος :)

Ζώνη ώρας και τήρηση χρόνου
Οφείλουμε να φροντίσουμε για την επιθυμητή ζώνη ώρας του server, ώστε το ρολόι του και τα time stamps να βγάζουν εύκολα νόημα. Ο καθορισμός ζώνης ώρας γίνεται δίνοντας

root@eyjafjallajokull:~# dpkg-reconfigure tzdata

Ορίσαμε τη ζώνη Europe/Athens, αν και για μια στιγμή ομολογούμε πως μας γοήτευσε αυτό το Antarctica/Troll. Επειδή εξάλλου το ρολόι κάθε συστήματος έχει μια τάση να “χάνει”, προσθέτουμε στο σύστημα τον NTP deamon ώστε ανά πάσα στιγμή το ρολόι να είναι συγχρονισμένο με ακριβείς time servers:

root@eyjafjallajokull:~# apt-get install ntp

Δεν χρειάζεται να κάνουμε κάτι για τον NTP, αφού αμέσως μετά την εγκατάστασή του ενεργοποιείται και δουλεύει σωστά.

Δημιουργία χώρου αντιμετάθεσης
Ένα από τα εργαλεία που μας αρέσει να εγκαθιστούμε σε κάθε σύστημα Linux, είναι το htop:

root@eyjafjallajokull:~# apt-get install htop

Όταν το τρέξαμε, δίνοντας απλά

root@eyjafjallajokull:~# htop

παρατηρήσαμε ότι στο σύστημα δεν υπήρχε swap partition (το htop το εγκαταλείπουμε πατώντας [Q]).

Αχρείαστη να 'ναι η μνήμη swap, αν όμως δεν χαρίσουμε χώρο αντιμετάθεσης στο λειτουργικό τότε δεν θα μπορούμε να κοιμηθούμε τα βράδια. Ναι, τέτοιοι είμαστε.

Σίγουρα για τη μνήμη swap ισχύει το “αχρείαστη να ‘ναι”. Πράγματι, το σύστημα σέρνεται, για να το πούμε απλά, όταν φτάνει στο σημείο να χρησιμοποιεί μεγάλο ποσοστό της. Επειδή όμως δεν μπορούμε ν’ αποκλείσουμε ότι θα υπάρξουν περιπτώσεις όπου θα χρειαστεί μνήμη swap, καλό είναι να δημιουργήσουμε από τώρα ένα αρχείο το οποίο θα έχει ρόλο τέτοιας μνήμης. Ένας κανόνας για το μέγεθος του αρχείου swap ορίζει πως πρέπει να ‘ναι διπλάσιo από αυτό της μνήμης RAM. Το Droplet μας έχει 2GB RAM, άρα τo μέγεθος του αρχείου αντιμετάθεσης –έτσι ονομάζεται το swap file– θα είναι 4GB.

Στη ρίζα του filesystem δημιουργούμε ένα αρχείο με όνομα “swapspace” και μέγεθος 4GB:

root@eyjafjallajokull:~# fallocate -l 4G /swapspace
root@eyjafjallajokull:~# ls -lh /swapspace
-rw-r--r-- 1 root root 4.0G Mar  6 19:50 /swapspace

Μόνο οι διεργασίες με δικαιώματα root επιτρέπεται να ‘χουν πρόσβαση στο swapspace:

root@eyjafjallajokull:~# chmod 600 /swapspace
root@eyjafjallajokull:~# ls -lh /swapspace
-rw------- 1 root root 4.0G Mar  6 19:50 /swapspace

Διαμορφώνουμε κατάλληλα το swapspace, ώστε να μπορεί να χρησιμοποιηθεί ως χώρος αντιμετάθεσης:

root@eyjafjallajokull:~# mkswap /swapspace
Setting up swapspace version 1, size = 4194300 KiB
no label, UUID=7c0c3f3d-5795-41fa-8fc5-d9951fdc1d01

Ενεργοποιούμε στη συνέχεια τη μνήμη swap, πάνω από το αρχείο swapspace:

root@eyjafjallajokull:~# swapon /swapspace

Αν τώρα τρέξουμε ξανά το htop, βλέπουμε ότι έχουμε και μνήμη swap. Αντί για το htop, η ύπαρξή της υποδηλώνεται κι από την έξοδο του εργαλείου free:

root@eyjafjallajokull:~# free
             total       used       free     shared    buffers     cached
Mem:       2049960     227672    1822288       5916      15132     102612
-/+ buffers/cache:     109928    1940032
Swap:      4194300          0    4194300

Ουσιαστικά, με το swapon προσαρτήσαμε το /swapspace ως χώρο αντιμετάθεσης. Αυτή η προσάρτηση θέλουμε να γίνεται αυτόματα κάθε φορά που ξεκινά το λειτουργικό, οπότε προσθέτουμε την κατάλληλη γραμμή στο τέλος του αρχείου /etc/fstab. Το ανοίγουμε με κάποιον text editor, όπως, π.χ., είναι το nano…

root@eyjafjallajokull:~# nano /etc/fstab

…και στο τέλος του προσθέτουμε την ακόλουθη γραμμή:

/swapspace none swap sw 0 0

Μέσα από το nano, τις αλλαγές στο fstab τις αποθηκεύουμε με [CTRL+O] και [Enter], ενώ το πρόγραμμα το εγκαταλείπουμε με [CTRL+X].

Ενίσχυση ασφάλειας για το OpenSSH
Κάθε Droplet της DigitalOcean είναι έτσι ρυθμισμένο ώστε να δέχεται ασφαλείς απομακρυσμένες συνδέσεις SSH, χάρη στον OpenSSH server που ενεργοποιείται αυτόματα κατά την εκκίνηση του λειτουργικού. Η ασφάλεια που παρέχει το πρωτόκολλο SSH είναι δυνατόν να ενισχυθεί περισσότερο. Προς αυτή την κατεύθυνση, θα παρουσιάσουμε τις ελάχιστες τροποποιήσεις που μας αρέσει να κάνουμε στον OpenSSH server.

Για αρχή θα αλλάξουμε μία μόνο παράμετρο, ώστε να αποφεύγουμε ένα μεγάλο ποσοστό brute force attacks. Όχι ότι το password του root είναι αδύναμο κι εύκολο να μαντευτεί, αλλά γιατί ν’ απασχολείται άδικα το Droplet μας; Οι αυτοματοποιημένες επιθέσεις, βλέπετε, πραγματοποιούνται από scripts τα οποία ψάχνουν για ενεργούς servers και για γνωστές υπηρεσίες. Όποτε βρίσκουν ενεργό μηχάνημα με ανοικτό port υπηρεσίας που έχει γνωστές ευπάθειες, πιθανώς να δοκιμάζουν μια σειρά από exploits. Όταν πάλι βρίσκουν ενεργό μηχάνημα με ανοικτό port υπηρεσίας που δέχεται logins, εκτός από τη δοκιμή exploits συχνά εξαπολύουν κι ένα brute force attack, κατά το οποίο ελέγχονται δημοφιλή user names και passwords από προκαθορισμένα λεξικά.

Το στάνταρτ port για το SSH είναι το 22. Αυτό που μπορούμε να κάνουμε άμεσα είναι να το αλλάξουμε σε κάποιο μη-προφανές ή αν θέλετε “άσχετο” port. Τα περισσότερα brute force scripts θα βλέπουν ότι δεν υπάρχει ενεργή υπηρεσία πίσω από το port 22, άρα αντί να ψάχνουν για SSH server σε άλλα ports του ίδιου host –εργασία που θα κόστιζε πολύ σε χρόνο–, θα εγκαταλείπουν κι ενδεχομένως θα περνούν στον επόμενο host. Για την αλλαγή του προκαθορισμένου port ανοίγουμε το αρχείο /etc/ssh/sshd_config με το nano…

root@eyjafjallajokull:~# nano /etc/ssh/sshd_config

…βρίσκουμε τη γραμμή

Port 22

…και την αλλάζουμε ώστε γίνει σαν την ακόλουθη:

Port 50022

Δεν είναι βέβαια απαραίτητο να βάλετε κι εσείς το port 50022, αλλά καλύτερα να ορίσετε ένα πάνω από το 50000. Αποθηκεύουμε την αλλαγή μας, εγκαταλείπουμε το nano κι επανεκκινούμε την υπηρεσία του OpenSSH:

root@eyjafjallajokull:~# service ssh restart

Η σύνδεση που τώρα υφίσταται κι από την οποία αλληλεπιδρούμε με το Droplet, δεν θα διακοπεί. Οι επόμενες, όμως, θα πρέπει να γίνονται προς το port που μόλις καθορίσαμε (π.χ., προς το 50022). Προφανώς, ο όποιος SSH client χρησιμοποιούμε πρέπει να ‘ναι ενήμερος για το μη-τυπικό port.

Να τονίσουμε εδώ ότι η αλλαγή port δεν θα αποτρέψει έναν αποφασισμένο attacker, ο οποίος στοχεύει ειδικά το μηχάνμά μας και ψάχνει για ενεργή υπηρεσία SSH. Γι’ αυτό και σε λίγο θα αναλάβουμε περισσότερα μέτρα προστασίας.

Ενεργοποίηση firewall
Δε νοείται server στο cloud χωρίς ένα καλά ρυθμισμένο firewall. Για το VPS μας, θα χρησιμοποιήσουμε το iptables. Ουσιαστικά πρόκειται για ένα front-end του netfilter, το οποίο παρέχει μεθόδους για το χειρισμό του Linux networking stack. Είμαστε από εκείνους που με το iptables διατηρούν μια σχέση αγάπης-μίσους. Όποτε διαβάζουμε γι’ αυτό, κατανοούμε τη λογική του και μας αρέσει. Μετά από λίγο καιρό όμως αρχίζουμε να ξεχνάμε βασικά πράγματα, οπότε έρχεται η περίοδος της αντιπάθειας. Προσφάτως κάναμε ξανά μερικά μαθήματα περί iptables, διαβάζοντας το σχετικό άρθρο στο deltaHacker 014. Για τη συνέχεια υποθέτουμε ότι κι εσείς έχετε παρακολουθήσει τα ίδια –ή παρόμοια– μαθήματα.

Εξ ορισμού, το iptbales στο Droplet μας έχει την προκαθορισμένη πολιτική ACCEPT για τις τρεις βασικές αλυσίδες (INPUT, OUTPUT και FORWARD):

root@eyjafjallajokull:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
root@eyjafjallajokull:~#

Σάρωση του VPS μας με το nmap, από ένα VM με Kali Linux. Το iptables δεν είναι ρυθμισμένο και το fail2ban δεν τρέχει, οπότε εύκολα αποκαλύπτονται τέσσερα διαφορετικά ports (για τρεις υπηρεσίες, αφού ο Apache χρησιμοποιεί δύο ports).

Με τις αλυσίδες OUTPUT και FORWARD δεν έχουμε θέμα. Στην INPUT όμως θέλουμε να προσθέσουμε συγκεκριμένους κανόνες, με στόχο:

  • τα εισερχόμενα πακέτα στο loopback interface να γίνονται πάντα δεκτά (απαραίτητο για ορισμένες εφαρμογές του συστήματος)
  • οι ήδη εγκαθιδρυμένες συνδέσεις να διατηρούνται (απαραίτητο ώστε να μην κλειδωθούμε κατά λάθος έξω από το VPS)
  • τα εισερχόμενα πακέτα TCP στο port 22 –ή σε όποιο άλλο έχουμε καθορίσει για τον OpenSSH server– να γίνονται πάντα δεκτά, ώστε να έχουμε δυνατότητα απομακρυσμένης σύνδεσης μέσω SSH
  • τα εισερχόμενα πακέτα TCP στο port 443 να γίνονται πάντα δεκτά, ώστε να είναι εφικτές οι ασφαλείς συνδέσεις HTTPS προς το ownCloud
  • όλα τα άλλα πακέτα, οποιουδήποτε πρωτοκόλλου και προς οποιοδήποτε port, να απορρίπτονται.

Ξεκινάμε με τον κανόνα για το loopback interface (lo):

root@eyjafjallajokull:~# iptables -A INPUT -i lo -j ACCEPT

Συνεχίζουμε με τον κανόνα για τη διατήρηση των ήδη εγκαθιδρυμένων συνδέσεων (established connections):

root@eyjafjallajokull:~# iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ακολουθούν οι δύο κανόνες για την αποδοχή συνδέσεων προς τον OpenSSH server, καθώς και προς τον web server:

root@eyjafjallajokull:~# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
root@eyjafjallajokull:~# iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Όλα τα εισερχόμενα πακέτα που δεν ταιριάζουν σε κανέναν από τους προαναφερθέντες κανόνες, να απορρίπτονται:

root@eyjafjallajokull:~# iptables -A INPUT -j DROP

Ας δούμε τώρα όλους τους κανόνες που μόλις δώσαμε:

root@eyjafjallajokull:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 49250 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -j DROP

Θεσπέσια. Οι κανόνες έχουν οριστεί όπως πρέπει και η ασφάλεια του VPS μας έχει εκτοξευτεί στα ουράνια (ή έστω λίγο πιο κάτω). Υπάρχει ένα πρόβλημα όμως: Στο επόμενο reboot οι κανόνες δεν θα φορτωθούν και θα ισχύει η προκαθορισμένη πολιτική (ACCEPT). Υπάρχουν διάφοροι τρόποι προκειμένου οι κανόνες του iptables να ισχύουν και μετά το reboot. Μπορούμε, π.χ., να τους μαζέψουμε σε ένα script, το οποίο θα εκτελείται αυτόματα μετά την εκκίννηση του λειτουργικού. Προτείνουμε έναν μάλλον κομψότερο τρόπο: την εγκατάσταση του πακέτου iptables-persistent.

root@eyjafjallajokull:~# apt-get install iptables-persistent

Κατά την εγκατάσταση θα ερωτηθούμε για το αν επιθυμούμε την αποθήκευση των κανόνων του iptables, που ισχύουν για τα IPv4 και IPv6. Απαντάμε θετικά — κι ας μην χρησιμοποιούμε το IPv6. Στο εξής, κάθε φορά που θα ξεκινά το λειτουργικό θα ενεργοποιούνται όλοι οι κανόνες του iptables οι οποίοι ίσχυαν πριν το τελευταίο reboot/shutdown — ή ακριβέστερα έως την τελευταία στιγμή που δώσαμε “service iptables-persistent save” (χωρίς τα εισαγωγικά).

Εγκαθιστούμε το εξαιρετικά βολικό iptables-persistent και το installation script ζητά την άδειά μας, προκειμένου να αποθηκεύσει τους κανόνες του iptables που ισχύουν αυτή τη στιγμή κι αφορούν στο IPv4. Του δίνουμε την άδειά μας -- και το ίδιο κάνουμε και για τους κανόνες που αφορούν στο IPv6 (κι ας μη χρησιμοποιούμε δικτύωση IPv6).

Αποκλεισμός των ενοχλητικών
To firewall από μόνο του δεν θα αποτρέψει όσους αποφασίσουν να εκμεταλλευτούν κάποιες υπηρεσίες του Droplet μας, π.χ., εξαπολύοντας μια στοχευμένη επίθεση brute-force ή DoS. Για να αποθαρρύνουμε τέτοιες συμπεριφορές χρειαζόμαστε κάτι πιο “τιμωρητικό”, όπως είναι το fail2ban. Για το συγκεκριμένο εργαλείο μπορείτε να διαβάσετε αναλυτικά στο σχετικό άρθρο του deltaHacker 034. Για το eyjafjallajokull, τη στιγμή που γράφονται αυτές οι γραμμές οι επεμβάσεις που έχουμε κάνει στο /etc/fail2ban/jail.local συνοψίζονται παρακάτω:

ignoreip = 127.0.0.1/8
bantime = 1800 # was: 600
findtime = 600
maxretry = 3
destemail = root@localhost
sendername = Fail2Ban
mta = sendmail
action = %(action_mw)s # was: action = %(action_)s

[ssh]
enabled  = true
port     = 49250 # was: ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

[ssh-ddos]
enabled  = true # was: false
port     = 49250 # was: ssh
filter   = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 6

[apache]
enabled  = true # was: false 
port     = https # was: http,https
filter   = apache-auth
logpath  = /var/log/apache*/*error.log
maxretry = 6

Έχουν οριστεί κανόνες για το iptables και το fail2ban λειτουργεί. Αυτή τη φορά το nmap βρίσκει μόνο το port 443 (ασφαλείς συνδέσεις HTTPS προς τον Apache). Κανονικά θα έπρεπε να βρει και το ανοικτό port 49250 (που χρησιμοποιεί ο OpenSSH server μας), υποψιαζόμαστε όμως ότι το fail2ban δεν το αφήνει να κάνει τη δουλειά του.

Αυτόματες ενημερώσεις ασφαλείας
Όσο καλά κι αν έχουμε προστατευμένο τον server, μια γνωστή (ή άγνωστη) αδυναμία σε δικτυακή υπηρεσία και λίγη αμέλεια από μέρους μας, είναι ακριβώς ό,τι χρειάζεται ένας attacker για ν’ αποκτήσει μη-εξουσιοδοτημένη πρόσβαση στο σύστημα. Λέμε, λοιπόν, ότι επειδή άνθρωποι είμαστε και συχνά ξεχνάμε ή/και τρέχουμε με άλλα θέματα, τουλάχιστον οι γνωστές αδυναμίες για τις οποίες έχουν κυκλοφορήσει security patches καλό είναι να επιδιορθώνονται αυτόματα και έγκαιρα. Ένα εργαλείο γι’ αυτή τη δουλειά στο Ubuntu παρέχεται από το πακέρο unattended-upgrades και στο Droplet μας ήταν ήδη εγκατεστημένο. Προκειμένου να ενεργοποιήσουμε τις αυτόματες εγκαταστάσεις μόνο για τα updates που αφορούν στην ασφάλεια, πειράξαμε ελαφρώς τα αρχεία /etc/apt/apt.conf.d/10periodic και /etc/apt/apt.conf.d/50unattended-upgrades. Συγκεκριμένα, φροντίσαμε ώστε το 10periodic να περιέχει τις ακόλουθες γραμμές:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

Στο δε 50unattended-upgrades κάναμε μία μόνο επέμβαση, ορίζοντας την τοπική διεύθυνση email του root:

Unattended-Upgrade::Mail "root@localhost";

Σε αυτή τη διεύθυνση αποστέλλονται μηνύματα που αφορούν στα αυτόματα security updates. Παρεμπιπτόντως, ένα βολικό πρόγραμμα για να διαβάζουμε τα email του συστήματος από την text console είναι το mutt, το οποίο παρέχεται από το ομώνυμο πακέτο.

Δημιουργία νέου χρήστη
Όπως αναφέραμε και προηγούμενως, στο διαρκή μας αγώνα για την ενίσχυση της ασφάλειας του server είναι καλή ιδέα να δημιουργήσουμε ένα λογαριασμό απλού χρήστη και να συνδεόμαστε μόνο σ’ αυτόν. Όποτε χρειαζόμαστε δικαιώματα διαχειριστή, θα τα έχουμε με τη βοήθεια του sudo. Ας δούμε τη δημιουργία ενός νέου χρήστη, ονόματι admin:

root@eyjafjallajokull:~# adduser admin
Adding user `admin' ...
Adding new group `admin' (1000) ...
Adding new user `admin' (1000) with group `admin' ...
Creating home directory `/home/admin' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: τρομακτικά_δυνατό_password 
Retype new UNIX password: τρομακτικά_δυνατό_password
passwd: password updated successfully
Changing the user information for admin
Enter the new value, or press ENTER for the default
	Full Name []: The Admin
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] y

Ξανά, να τονίσουμε ότι το password πρέπει να είναι τυχαίο και με μεγάλο μήκος (π.χ., 20 χαρακτήρες). Επειδή είναι μάλλον απίθανο να το θυμόμαστε –αν είναι πράγματι καλό τότε θα είναι πρακτικά αδύνατο να το θυμόμαστε–, προτείνουμε να το αποθηκεύσετε σε κάποιο ασφαλές μέρος (π.χ., ως “Secure Note” στο LastPass). Θέλουμε εξάλλου ο χρήστης admin να είναι σε θέση να χρησιμοποιεί το sudo, οπότε τον βάζουμε στο ομώνυμο group:

root@eyjafjallajokull:~# gpasswd -a admin sudo
Adding user admin to group sudo

Ας μεταβούμε τώρα στο λογαριασμό του admin:

root@eyjafjallajokull:~# su - admin
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

Θα φτιάξουμε τον κατάλογο ~/.ssh και μέσα του το αρχείο authorized_keys. Στον κατάλογο και στο αρχείο θα δώσουμε τα κατάλληλα δικαιώματα, ώστε πρόσβαση να έχει μόνον ο admin:

admin@eyjafjallajokull:~$ mkdir ~/.ssh
admin@eyjafjallajokull:~$ chmod 700 ~/.ssh
admin@eyjafjallajokull:~$ touch ~/.ssh/authorized_keys
admin@eyjafjallajokull:~$ chmod 600 ~/.ssh/authorized_keys 
admin@eyjafjallajokull:~$ nano ~/.ssh/authorized_keys

Όπως βλέπετε, με το nano ανοίξαμε το ~/.ssh/authorized_keys. Μέσα του μπορούμε να αντιγράψουμε ένα δημόσιο κλειδί για τον admin. Βεβαίως, υπάρχουν κι άλλοι τρόποι για να μεταφέρουμε το κλειδί του admin στο authorized_keys. Όταν τελειώσουμε και μ’ αυτή τη δουλειά, εγκαταλείπουμε το λογαριασμό του admin κι επιστρέφουμε σ’ εκείνον του root:

admin@eyjafjallajokull:~$ exit
logout
root@eyjafjallajokull:~#

Στο σημείο αυτό δεν είναι καθόλου άσχημη ιδέα να βεβαιωθούμε ότι έχουμε δυνατότητα απομακρυσμένης σύνδεσης στο VPS, αλλά στο λογαριασμό του admin. Και μία σημείωση: Τα fail2ban και unattended-upgrades είναι ρυθμισμένα ώστε να στέλνουν email στον root@localhost. Ίσως βολεύει καλύτερα να στέλνουν στον admin@localhost, οπότε κάντε τις απαραίτητες αλλαγές στα αρχεία /etc/fail2ban/jail.local και /etc/apt/apt.conf.d/50unattended-upgrades.

Περαιτέρω ενίσχυση ασφάλειας για το OpenSSH
Προτείνουμε μια αλλαγή στον OpenSSH server, ώστε να δέχεται μόνο key-based κι όχι password-based authentication. Αν δεν είστε εξοικειωμένοι με τα κλειδιά και τη χρήση τους διαβάστε οπωσδήποτε αυτό το άρθρο. Για τη συνέχεια δουλεύουμε από το λογαριασμό του admin, έτσι, για να τον συνηθίζουμε σιγά σιγά. Με δικαιώματα root, ανοίγουμε το αρχείο /etc/sshd_config:

admin@eyjafjallajokull:~$ sudo nano /etc/ssh/sshd_config

Φροντίζουμε ώστε να ισχύουν τα ακόλουθα:

PermitRootLogin no
PasswordAuthentication no	

Με την πρώτη οδηγία το OpenSSH δεν δέχεται απομακρυσμένες συνδέσεις στο λογαριασμό του root, ανεξαρτήτως της μεθόδου authentication. Μόνος τρόπος για να συνδεόμαστε ως root απευθείας θα είναι μέσω της web console που παρέχει η DigitalOcean. Η δεύτερη οδηγία απαγορεύει το password-based authentication, για όλους τους χρήστες. Πρακτικά, λοιπόν, όπως είναι αυτή τη στιγμή το Droplet μας μπορούμε να συνδεόμαστε απομακρυσμένα μόνο στο λογαριασμό του admin και μόνο με key-based authentication. Προκειμένου να ληφθούν υπόψη οι αλλαγές, δίνουμε:

admin@eyjafjallajokull:~$ sudo service ssh restart
ssh stop/waiting
ssh start/running, process 3111
admin@eyjafjallajokull:~$

Ήδη όπως είναι ρυθμισμένος ο OpenSSH server μας, είναι εξαιρετικά ασφαλής. Υπάρχουν ωστόσο και πολλές βελτιώσεις που θα μπορούσαμε να κάνουμε, ώστε να ενισχύσουμε περισσότερο την ασφάλειά του. Περί αυτών, διαβάστε το σχετικό άρθρο στο τεύχος 040. Το τρίτο και τελευταίο μέρος του αφιερώματός μας μπορείτε να το διαβάσετε εδώ.

9 Responses to “Ένας server, δύο σύννεφα [μέρος 2/3]”

  1. nikosg5 | 14/03/2015 at 00:47

    Μονο εγω ειμαι ανυπομονος?? Το λινκ για το 3ο μερος δεν εναι ακομα online?

    • subZraw | 14/03/2015 at 10:04

      Θα είναι σύντομα — πιθανότατα έως αύριο. Μένει να γίνουν οι σημειώσεις κείμενο :)

  2. Lyk | 20/03/2015 at 16:23

    404 at the ” αν δεν είστε εξοικειωμένοι με τα κλειδιά και τη χρήση τους διαβάστε οπωσδήποτε αυτό το άρθρο.” :)

    • subZraw | 20/03/2015 at 16:28

      Το άρθρο είναι υπό προετοιμασία και θα ανέβει σύντομα. Πρώτα όμως θα ανεβάσουμε το “Ένας server, δύο σύννεφα [μέρος 2/3]” (κατά πάσα πιθανότητα έως απόψε τα μεσάνυχτα).

      • Lyk | 20/03/2015 at 17:23

        Α νόμιζα ότι υπήρχε ήδη αυτό, my bad!
        Υποθέτω εννοείς το μέρος 3/3.

        Cheers!

        • subZraw | 20/03/2015 at 17:35

          Ναι, βάζουμε τελευταίες πινελιές στο 3/3 και το δημοσιεύουμε. Μετά πέφτουμε με τα μούτρα στο άρθρο περί OpenSSH passwordless logins.

  3. subZraw | 21/03/2015 at 13:36

    @nikosg5 @Lyk FYI: http://deltahacker.gr/actsubs-1srv2clouds-p33 :D

  4. ioanniskar | 01/07/2015 at 16:36

    Με το “PermitRootLogin no” θα μπορώ αφού έχω συνδεθεί ως κάποιος άλλος χρήστης με χρήση ssh key να συνδεθώ ως root για την εκτέλεση κάποια εντολής;

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων