Περιορισμός των προσπαθειών κωδικού πρόσβασης στο Linux για την ασφάλεια του SSH και των υπηρεσιών

Εάν διαχειρίζεστε έναν διακομιστή Linux που είναι εκτεθειμένος στο Διαδίκτυο, αργά ή γρήγορα θα δείτε στα αρχεία καταγραφής χιλιάδες προσπάθειες σύνδεσης SSH από τυχαίες διευθύνσεις IPΔεν είναι ότι σε αντιπαθούν: είναι αυτοματοποιημένα bots που ψάχνουν για πόρτες που δεν προστατεύονται σωστά, αλλάζοντας εύρη διευθύνσεων IP.

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

Εντοπισμός επιθέσεων ωμής βίας SSH και ο αντίκτυπός τους στον διακομιστή

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

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

Για να αναλύσουμε τι συνέβαινε σε ένα συγκεκριμένο χρονικό διάστημα, είναι πολύ χρήσιμο να χρησιμοποιήσουμε journalctlΤο εργαλείο systemd για την ανάγνωση αρχείων καταγραφής συστήματος, υπηρεσίας, πυρήνα και ελέγχου ταυτότητας. Ένα κλασικό παράδειγμα ερωτήματος θα ήταν:

journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"

Με αυτόν τον τύπο ερωτήματος μπορείτε να κάνετε λεπτομερή ανασκόπηση Ποια μηνύματα κατέγραψε το σύστημα κατά τη διάρκεια του παραθύρου στο οποίο η CPU παρουσίασε απότομη αύξηση;: υπηρεσίες που επανεκκινούνται, αποτυχίες ελέγχου ταυτότητας, σφάλματα πυρήνα, κ.λπ.

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

Ποσοτικοποίηση αποτυχημένων προσπαθειών στο /var/log/auth.log

Σε συστήματα Debian/Ubuntu, το βασικό αρχείο για την παρακολούθηση οτιδήποτε σχετίζεται με τον έλεγχο ταυτότητας είναι /var/log/auth.logΕδώ καταγράφονται οι επιτυχημένες συνδέσεις, οι αποτυχημένες προσπάθειες, τα συμβάντα PAM, τα κλείδωμα λογαριασμών κ.λπ.

Αν θέλετε να μάθετε πόσες φορές έχει καταγραφεί το μοτίβο "Αποτυχία κωδικού πρόσβασης" στο τρέχον αρχείο καταγραφής, μπορείς να χρησιμοποιήσεις:

sudo grep 'Failed password' /var/log/auth.log | wc -l

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

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

head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.log

Με αυτόν τον τρόπο θα γνωρίζετε το Ημερομηνία της πρώτης και της τελευταίας εγγραφής που υπάρχει στο auth.logΟι υπόλοιπες προηγούμενες προσπάθειες θα βρίσκονται στο αρχείο auth.log.1 και στα συμπιεσμένα αρχεία auth.log.N.gz.

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

zgrep 'Failed password' /var/log/auth.log.*.gz | wc -l

Αν προσθέσετε αυτά που βλέπετε auth.log, auth.log.1 και auth.log.*.gz Θα πάρετε μια καλή ιδέα για το Ιστορικό αρχείο επιθέσεων ωμής βίας, λαμβάνοντας υπόψη ότι τα παλαιότερα μπορεί να έχουν ήδη εξαφανιστεί λόγω της περιστροφής.

Πώς λειτουργεί η εναλλαγή αρχείων καταγραφής ελέγχου ταυτότητας

Ο τρόπος και η συχνότητα με την οποία περιστρέφονται τα κούτσουρα εξαρτάται από τη διαμόρφωση του logrotateΣτο Ubuntu, η εναλλαγή του auth.log συνήθως ορίζεται στο /etc/logrotate.d/rsyslog, όπου συνήθως θα βρείτε κάτι σαν:

weekly
rotate 4
compress

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

Επομένως, όταν υπολογίζετε τις προσπάθειες ωμής βίας, υποθέστε ότι Βλέπετε μόνο τα ιστορικά δεδομένα από αρκετές εβδομάδες πριν.Οτιδήποτε συνέβη πιο πίσω στο χρόνο δεν θα υπάρχει πλέον στο σύστημα.

Εντοπίστε χρήστες και διευθύνσεις IP που επιτίθενται

Πέρα από τον συνολικό αριθμό, είναι σημαντικό να γνωρίζετε Ποιοι χρήστες στοχοποιούνται και από ποιες διευθύνσεις IP προέρχονται οι επιθέσεις;Με λίγη αδιαθεσία στο auth.log το έχετε πρόχειρο.

Για να δείτε ποια ονόματα χρήστη δοκιμάζονται στις αποτυχημένες προσπάθειες:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-5)}' \
  | sort | uniq -c

Και για να δείτε τις IP με την πιο ύποπτη δραστηριότητα:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | head

Αυτό θα σας επιτρέψει να εντοπίσετε γρήγορα εάν σας επιτίθενται. πραγματικοί λογαριασμοί από το σύστημά σας ή γενικούς χρήστες όπως root, admin, test, user, κ.λπ., και ποιες IP θα πρέπει να αποκλείσετε επειγόντως.

Είναι όντως τόσο σοβαρό που υπάρχουν χιλιάδες απόπειρες;

Πρέπει να υποτεθεί ότι, εάν ο διακομιστής σας είναι προσβάσιμος από το Διαδίκτυο και έχει Ακρόαση SSH στη θύρα 22 ή σε οποιαδήποτε άλληΑυτός ο διακομιστής θα λαμβάνει αυτό το είδος επισκεψιμότητας 24 ώρες την ημέρα. Είναι φυσιολογικό να βλέπετε χιλιάδες αποτυχημένες προσπάθειες εάν ο διακομιστής λειτουργεί για κάποιο χρονικό διάστημα.

Η πραγματική βαρύτητα εξαρτάται από τις ρυθμίσεις σας:

διαμόρφωση	Προσεγγιστικός κίνδυνος
Αδύναμοι κωδικοί πρόσβασης + ανοιχτό SSH στο Διαδίκτυο	Πολύ υψηλός κίνδυνος συμβιβασμού
Ισχυροί κωδικοί πρόσβασης	Μέτριος κίνδυνος, αλλά κατανάλωση πόρων
Το Fail2ban έχει ρυθμιστεί σωστά	Χαμηλού κινδύνου και υψηλής μετριασμού επιθέσεις
Πρόσβαση μόνο με κλειδιά SSH	Κίνδυνος πολύ κοντά στο μηδέν με ωμή βία

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

Βασική σκλήρυνση SSH: κρίσιμες επιλογές στο sshd_config

Η πρώτη γραμμή άμυνας είναι μέσα στον εαυτό σου Ο δαίμονας SSH (sshd) και το αρχείο διαμόρφωσής του /etc/ssh/sshd_config (και τα σχετικά αρχεία .d). Μερικές καλορυθμισμένες οδηγίες μειώνουν σημαντικά την επιφάνεια επίθεσης.

Λάβετε υπόψη ότι σε σύγχρονες διανομές όπως το Ubuntu 22.04 και νεότερες εκδόσεις, Το sshd διαβάζει πρώτα το /etc/ssh/sshd_config και στη συνέχεια τα αρχεία στο /etc/ssh/sshd_config.d/*.conf με αλφαβητική σειρά. Οτιδήποτε εμφανίζεται αργότερα μπορεί να αντικαταστήσει παραμέτρους που έχουν οριστεί προηγουμένως, οπότε να είστε πολύ προσεκτικοί με τις αλλαγές.

Απενεργοποίηση πρόσβασης χωρίς κωδικό πρόσβασης και περιττών συνεδριών

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

PermitEmptyPasswords no

Συνήθως σχολιάζεται ή ορίζεται ρητά σε "όχι". Επίσης, βεβαιωθείτε ότι έχετε απενεργοποιήσει λειτουργίες που δεν θα χρησιμοποιήσετε, όπως... Προώθηση X11 (X11Forwarding) Εάν δεν πραγματοποιείτε απομακρυσμένες συνεδρίες γραφικών:

X11Forwarding no

Όσον αφορά τα πρωτόκολλα, εάν για οποιονδήποτε λόγο διαχειρίζεστε ένα πολύ παλιό σύστημα, ελέγξτε ότι επιτρέπονται μόνο ορισμένες ενέργειες. Πρωτόκολλο SSH 2:

Protocol 2

Αλλάξτε την προεπιλεγμένη θύρα και περιορίστε σε ποια διεπαφή ακούει.

Ένα άλλο απλό, αν και όχι αλάνθαστο, κόλπο είναι Μετακινήστε το SSH από τη θύρα 22 σε μια μη τυπική θύρα.Αυτό δεν σας προστατεύει από έναν σοβαρό εισβολέα, αλλά φιλτράρει μια σημαντική ποσότητα αυτοματοποιημένου θορύβου που σαρώνει μόνο το 22.

Port 2222
ListenAddress 192.168.56.8

Εκτός από την αλλαγή της θύρας, μπορείτε να καθορίσετε μια συγκεκριμένη διεύθυνση στην οποία θα ακούει το SSH, για παράδειγμα, την εσωτερική σας διεύθυνση IP, εάν θέλετε να την περιορίσετε σε ένα συγκεκριμένο δίκτυο. Ωστόσο, εάν η διανομή σας χρησιμοποιεί το ssh.socket του systemd, ίσως χρειαστεί να... Απενεργοποιήστε την υποδοχή και επιστρέψτε στην κλασική υπηρεσία ssh.service. για να τηρηθεί η διαμόρφωση της θύρας:

sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.service

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

Αποκλεισμός ή περιορισμός πρόσβασης root

Ο χρήστης root είναι εύκολη λεία για τους εισβολείς, οπότε είναι λογικό. αποτροπή σύνδεσης μέσω SSHακόμη και με κωδικούς πρόσβασης. Ελέγχετε αυτήν τη συμπεριφορά με την οδηγία:

PermitRootLogin no

Σε πολλές σύγχρονες εγκαταστάσεις, διατίθεται σε λειτουργία "prohibit-password", η οποία αποτρέπει τις συνδέσεις με κωδικό πρόσβασης αλλά αφήνει ανοιχτή την πόρτα για πιστοποιητικά. Αν θέλετε να είστε ασφαλείς, αφήστε την σε "no" και χρησιμοποιήστε έναν κανονικό λογαριασμό με sudo για διαχείριση.

Ορίστε ποιος έχει πρόσβαση: AllowUsers και AllowGroups

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

Για να περιορίσετε τους επιτρεπόμενους χρήστες, έχετε τις ακόλουθες οδηγίες. Επιτρεπόμενοι χρήστες y ΕπιτρέπονταιΟμάδες. Για παράδειγμα:

AllowUsers harry hermione
AllowGroups gryffindor

Η λίστα διαχωρίζεται με κενά και η σημασιολογία είναι αυτή μιας "λευκής λίστας": Μόνο οι καταχωρημένοι λογαριασμοί και ομάδες θα μπορούν να πραγματοποιήσουν έλεγχο ταυτότηταςΛάβετε επίσης υπόψη ότι το AllowUsers έχει προτεραιότητα έναντι του AllowGroups, επομένως μην τα αναμειγνύετε εκτός αν είστε σαφείς σχετικά με τη σειρά αξιολόγησης.

Μια καλή πρακτική είναι να εργάζεστε κυρίως με τυπικές ομάδες. διαχειριστές ή χρήστες sshusers και προσθέστε τους εξουσιοδοτημένους λογαριασμούς εκεί, αντί να διατηρείτε μια λίστα χρηστών έναν προς έναν στο αρχείο.

Περιορισμός προσπαθειών ελέγχου ταυτότητας και χρόνου διακοπής λειτουργίας

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

MaxAuthTries 3

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

Όσον αφορά τον χρόνο αδράνειας, το SSH σάς επιτρέπει να τερματίσετε συνδέσεις που παραμένουν ανοιχτές χωρίς δραστηριότητα πέρα ​​από ένα καθορισμένο όριο. ClientAliveInterval (σε δευτερόλεπτα):

ClientAliveInterval 180

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

Περιορισμός πρόσβασης ανά διεύθυνση IP: TCP Wrappers and Match

Σε ορισμένες περιπτώσεις, μπορεί να σας ενδιαφέρει Μόνο συγκεκριμένες διευθύνσεις IP ή εύρη έχουν πρόσβαση μέσω SSHΈχετε διάφορους τρόπους για να το κάνετε: από το ίδιο το τείχος προστασίας (iptables/nftables), μέσω των TCP Wrappers, μέχρι τα μπλοκ Match του sshd_config.

Με τα TCP Wrappers, που εξακολουθούν να χρησιμοποιούνται σε πολλές διανομές, η πρόσβαση ελέγχεται με τα /etc/hosts.allow και /etc/hosts.deny. Η ροή είναι: Αρχικά, αξιολογείται το hosts.allow και στη συνέχεια το hosts.deny.Ένα περιοριστικό παράδειγμα θα ήταν:

# /etc/hosts.deny
ALL: ALL

# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENY

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

Μια άλλη επιλογή, πιο τυπική του SSH, είναι η χρήση μπλοκ Ταίριασμα μέσα στο sshd_config για να εφαρμόσετε κανόνες που βασίζονται στη διεύθυνση ή τον χρήστη. Φανταστείτε ότι θέλετε ένας χρήστης "git" να μπορεί να συνδεθεί από οπουδήποτε, αλλά ο χρήστης διαχειριστή σας "greg" μπορεί να συνδεθεί μόνο από το LAN 192.168.1.0/24. Θα μπορούσατε να συνδυάσετε τους κανόνες AllowUsers με τους κανόνες Match Address, αν και πρέπει να είστε πολύ προσεκτικοί ώστε... μην κλείνεσαι στον εαυτό σου.

Fail2ban: Αυτόματα μπλοκαρίσματα έναντι ωμής βίας

Ακόμα κι αν ενισχύσετε το SSH, τα bots θα εξακολουθούν να δοκιμάζουν τα διαπιστευτήρια, προκαλώντας χρήση της CPU και θόρυβο καταγραφής. Για να μετριαστεί αυτό, αυτό λαμβάνεται υπόψη. Fail2ban, ένα σύστημα πρόληψης εισβολών που βασίζεται σε αρχεία καταγραφής το οποίο μπλοκάρει αυτόματα τις IP με πάρα πολλά σφάλματα.

Το Fail2ban είναι γραμμένο σε Python και βασίζεται σε "φυλακές" ή jails, καθένα από τα οποία σχετίζεται με μια υπηρεσία και ένα ή περισσότερα αρχεία καταγραφήςΌταν ανιχνεύει ένα επαναλαμβανόμενο μοτίβο σφάλματος (αποτυχίες κωδικού πρόσβασης, απαγορευμένη πρόσβαση κ.λπ.), ενεργοποιεί ενέργειες, συνήθως κανόνες τείχους προστασίας για να αποκλείσει την πηγή.

Εγκαταστήστε το Fail2ban σε κοινές διανομές Linux

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

sudo apt update
sudo apt install fail2ban

Σε συστήματα που βασίζονται σε RHEL (RHEL, CentOS, AlmaLinux, Rocky, κ.λπ.) η τυπική εντολή θα ήταν με dnf ή yum, ανάλογα με την έκδοση:

sudo dnf install fail2ban

Το πακέτο συνήθως περιλαμβάνει μια υπηρεσία systemd που ξεκινά αυτόματα, αν και αξίζει να το ελέγξετε αυτό. Το Fail2ban ξεκινά κατά την εκκίνηση και είναι ενεργό:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2ban

Δομή διαμόρφωσης: jail.conf, jail.local και jail.d

Η διαμόρφωση βρίσκεται σε /etc/fail2ban/Το κύριο αρχείο είναι το jail.conf, αλλά η άμεση επεξεργασία του δεν συνιστάται επειδή αντικαθίσταται κατά τη διάρκεια των ενημερώσεων. Αντίθετα, θα πρέπει:

• Δημιουργήστε ή επεξεργαστείτε το /etc/fail2ban/jail.local για να αντικαταστήσετε τις προεπιλεγμένες τιμές.
• Ή προσθέστε συγκεκριμένα αρχεία στο /etc/fail2ban/jail.d/*.conf.

Το Fail2ban φορτώνει τη διαμόρφωση με αυτήν τη σειρά:

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.local

Όλα όσα ορίζετε στο jail.local υπερισχύουν όλων όσων προηγήθηκαν, επομένως Μπορείτε να προσαρμόσετε χωρίς να αγγίξετε τα αρχεία πακέτων..

Σημαντικές καθολικές παράμετροι: bantime, maxretry, ignoreip

Μέσα στο jail.conf (ή jail.local) θα δείτε μια ενότητα [ΠΡΟΕΠΙΛΟΓΗ] με καθολικές παραμέτρους που επηρεάζουν όλα τα jails εκτός εάν παρακαμφθούν. Οι πιο σημαντικές είναι:

• bantime: χρόνος κατά τον οποίο μια IP θα μπλοκαριστεί (σε δευτερόλεπτα) μετά την υπέρβαση του αριθμού των επιτρεπόμενων βλαβών.
• maxretry: μέγιστος αριθμός αποτυχημένων προσπαθειών πριν από την εφαρμογή της απαγόρευσης.
• βρείτε χρόνο: χρονικό παράθυρο στο οποίο καταμετρώνται αυτές οι προσπάθειες (π.χ., 10 λεπτά για δέκα λεπτά).
• ignorepi: λίστα διευθύνσεων IP ή εύρους που το Fail2ban δεν πρέπει ποτέ να αποκλείει (για παράδειγμα, η δική σας δημόσια διεύθυνση IP ή το δίκτυο διαχείρισής σας).

Για παράδειγμα, θα μπορούσατε να έχετε κάτι σαν αυτό στο [ΠΡΟΕΠΙΛΟΓΗ]:

[DEFAULT]
bantime  = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24

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

Ρύθμιση παραμέτρων jail sshd για να σταματήσετε τις επιθέσεις SSH

Η πιο συνηθισμένη φυλακή είναι η φυλακή SSH. Σε πολλές διανομές, έρχεται προρυθμισμένη στο jail.conf. Απλώς χρειάζεται να την ενεργοποιήσετε ή να βελτιώσετε τις τιμές της στο jail.local. Ένα απλό παράδειγμα:

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 600
findtime = 10m

Στην περίπτωση αυτή, Τρεις αποτυχημένες προσπάθειες σύνδεσης στο auth.log εντός δέκα λεπτών θα οδηγήσουν σε δεκάλεπτο αποκλεισμό της διεύθυνσης IP του εισβολέα.Το Fail2ban εισάγει τους κανόνες στο τείχος προστασίας (iptables, nftables ή UFW, ανάλογα με το σύστημα) έτσι ώστε οι συνδέσεις από αυτήν την IP να μην φτάνουν καν στο sshd.

Για να εφαρμόσετε τυχόν αλλαγές στη διαμόρφωση, θυμηθείτε να επανεκκινήσετε την υπηρεσία:

sudo systemctl restart fail2ban

Δείτε την κατάσταση των φυλακών και των αποκλεισμένων IP

Το Fail2ban περιλαμβάνει ένα πολύ εύχρηστο βοηθητικό πρόγραμμα ελέγχου, fail2ban-clientΜε αυτό το εργαλείο, μπορείτε να δείτε ποιες φυλακές είναι ενεργές και ποιες IP έχουν αποκλειστεί. Για παράδειγμα:

sudo fail2ban-client status

Θα έδειχνε κάτι παρόμοιο με:

Status
|- Number of jail: 1
`- Jail list: sshd

Για λεπτομερείς πληροφορίες σχετικά με τη φυλακή SSHD:

sudo fail2ban-client status sshd

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

Με αυτά τα δεδομένα μπορείτε να πάρετε μια ιδέα για Πόση κακόβουλη επισκεψιμότητα λαμβάνει ο διακομιστής σας και πόσο αποτελεσματική είναι η τρέχουσα διαμόρφωση;.

Μόνιμα κλειδώματα και αυξανόμενος χρόνος απαγόρευσης

Αν θέλετε να είστε ιδιαίτερα αυστηροί με τους επαναλαμβανόμενους παραβάτες, το Fail2ban προσφέρει δύο ενδιαφέρουσες στρατηγικές: μόνιμη απαγόρευση και σταδιακή απαγόρευση.

Για να αποκλείσετε μόνιμα οποιαδήποτε διεύθυνση IP που υπερβαίνει το όριο αποτυχίας, απλώς εισαγάγετε:

bantime = -1

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

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

bantime           = 10m
bantime.increment = true
bantime.rndtime   = 0
bantime.factor    = 4
bantime.maxtime   = -1

Με αυτές τις τιμές, η εξέλιξη θα μοιάζει κάπως έτσι:

• 1ο μπλοκ: 10 λεπτά
• 2ο μπλοκ: 40 λεπτά
• 3ο μπλοκ: 160 λεπτά (~2 ώρες και 40)
• 4ο τετράγωνο: γύρω Horas 10,6
• 5ο μπλοκ: μερικά Horas 42

Δεδομένου ότι το bantime.maxtime είναι -1, το η διάρκεια μπορεί να συνεχίσει να αυξάνεται επ' αόριστον, αφήνοντας τους πραγματικά δυνατούς παίκτες εκτός παιχνιδιού για πάντα.

Χρήση του Fail2ban πέρα ​​από το SSH: Apache, WordPress, MySQL, ηλεκτρονικά καταστήματα…

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

Για παράδειγμα, για ένα ηλεκτρονικό κατάστημα (Magento, PrestaShop, WooCommerce…) είναι πολύ λογικό να δημιουργηθεί ένα jail που παρακολουθεί το Αρχεία καταγραφής πρόσβασης Apache ή Nginx που αναζητούν πολλούς κωδικούς 401/403 στο /admin ή στο /loginΜια ελάχιστη διαμόρφωση που βασίζεται σε Apache θα μπορούσε να είναι:

[apache-auth]
enabled  = true
filter   = apache-auth
logpath  = /var/log/apache2/access.log
maxretry = 5
bantime  = 3600

Σε περιβάλλοντα WordPress, ένας συνηθισμένος συνδυασμός είναι η παρακολούθηση /wp-login.php και /xmlrpc.phpΑυτά είναι τα κλασικά σημεία εισόδου για επιθέσεις brute-force και bot. Το φίλτρο θα μπορούσε να τοποθετηθεί στο /etc/fail2ban/filter.d/wordpress.conf:

[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =

Και η αντίστοιχη φυλακή στο jail.local:

[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/apache2/access.log
maxretry = 3
bantime  = 3600

Η ίδια ιδέα ισχύει και για τις εκτεθειμένες βάσεις δεδομένων (κάτι που γενικά είναι καλύτερο να αποφεύγεται): αν θέλετε να προστατεύσετε την MySQL από συνεχείς αποτυχημένες προσπάθειες πρόσβασης, μπορείτε να δημιουργήσετε ένα φίλτρο για Μηνύματα «Δεν επιτρέπεται η πρόσβαση για τον χρήστη» στο αρχείο καταγραφής σφαλμάτων:

[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =

Και μετά φυλακή:

[mysqld-auth]
enabled  = true
filter   = mysql
logpath  = /var/log/mysql/error.log
maxretry = 5
bantime  = 1800

Σε διακομιστές φιλοξενίας με πίνακες ελέγχου cPanel ή PleskΤο Fail2ban ενσωματώνεται επίσης καλά: μπορεί να παρακολουθεί τις υπηρεσίες αλληλογραφίας, το Apache, το FTP, ακόμη και τον ίδιο τον πίνακα ελέγχου, αποκλείοντας διευθύνσεις IP που υπερβαίνουν το όριο με προσπάθειες σύνδεσης.

Έλεγχος ταυτότητας με κλειδιά SSH: το τέλος των επιθέσεων με κωδικό πρόσβασης

Όλα τα παραπάνω βοηθούν, αλλά το πραγματικό άλμα στην ποιότητα έρχεται όταν αποφασίσεις Σταματήστε να χρησιμοποιείτε κωδικούς πρόσβασης για SSH και μεταβείτε σε δημόσια/ιδιωτικά κλειδιάΣε αυτό το σημείο, οι επιθέσεις με κωδικό πρόσβασης brute-force παύουν να έχουν νόημα.

Η ιδέα είναι απλή: κάθε νόμιμος χρήστης έχει ένα ζεύγος κλειδιών, ένα ιδιωτικό κλειδί που παραμένει στη συσκευή σας και ένα δημόσιο κλειδί που αντιγράφεται στον διακομιστή στο αντίστοιχο αρχείο ~/.ssh/authorized_keys του χρήστη.

Όταν ο πελάτης συνδέεται, δεν στέλνει το ιδιωτικό κλειδί, αλλά το δημόσιο κλειδί και στη συνέχεια υπογράφει μια πρόκληση διακομιστή με την ιδιωτική. Ο διακομιστής ελέγχει αυτήν την υπογραφή με την δημόσια και μόνο εάν ταιριάζουν επιτρέπει την πρόσβαση.

Γιατί τα κλειδιά SSH ακυρώνουν τον κωδικό πρόσβασης με ωμή βία

Σε ένα κλασικό σχήμα κωδικού πρόσβασης, ο εισβολέας απλώς πρέπει να δοκιμάσει συμβολοσειρές κειμένου μέχρι μία να ταιριάζει με τον αποθηκευμένο κωδικό πρόσβασης (ή το hash του). Αν και ένας καλός κωδικός πρόσβασης έχει πολλούς πιθανούς συνδυασμούς, Μιλάμε για τάξεις μεγέθους όπως 10¹⁰ πιθανότητες για μέσους κωδικούς πρόσβασης.

Ένα τυπικό κλειδί SSH 256-bit (όπως αυτά στο Ed25519) κινείται στους χώρους αναζήτησης της τάξης του 10⁶¹⁷ συνδυασμοίΣτην πράξη, είναι μαθηματικά αδύνατο για έναν εισβολέα να μαντέψει ένα ιδιωτικό κλειδί με ωμή βία με τους σύγχρονους υπολογιστές.

Αλλά επιπλέον, ο διακομιστής δεν προσπαθεί καν να υπολογίσει τίποτα εάν το Το δημόσιο κλειδί που παρουσιάζεται δεν βρίσκεται στο authorized_keysΣε αυτήν την περίπτωση, απορρίπτει τη σύνδεση σχεδόν αμέσως, χωρίς να ενεργοποιεί το PAM ή τις παραδοσιακές διαδικασίες ελέγχου ταυτότητας, επομένως η κατανάλωση CPU κατά τη διάρκεια μιας μαζικής επίθεσης είναι ελάχιστη.

Δημιουργία και επαλήθευση κλειδιών SSH στον υπολογιστή-πελάτη

Πριν αποκτήσετε πρόσβαση στον διακομιστή, ελέγξτε αν το μηχάνημά σας έχει ήδη δημιουργήσει ένα ζεύγος κλειδιών SSH. Απλώς παραθέστε τα περιεχόμενα του ~/.ssh:

ls -l ~/.ssh

Αν δείτε αρχεία όπως id_ed25519 και id_ed25519.pub Αν χρησιμοποιείτε τα id_rsa και id_rsa.pub, έχετε ήδη ένα έγκυρο ζεύγος. Το Ed25519 είναι πιο μοντέρνο και ελαφρύ, επομένως είναι συνήθως η καλύτερη επιλογή στις μέρες μας.

Αν δεν έχετε κλειδιά, δημιουργήστε νέα με:

ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"

Η εντολή θα δημιουργήσει δύο αρχεία:

• id_ed25519: το ιδιωτικό κλειδί, το οποίο δεν πρέπει ποτέ να κοινοποιήσετε.
• id_ed25519.pub: το δημόσιο κλειδί, το οποίο μπορείτε να αντιγράψετε στους διακομιστές.

Μπορείτε να δείτε τα περιεχόμενα του δημόσιου κλειδιού με:

cat ~/.ssh/id_ed25519.pub

Αντιγράψτε το δημόσιο κλειδί στον διακομιστή και δοκιμάστε την πρόσβαση

Στον διακομιστή, βεβαιωθείτε ότι ο κατάλογος ~/.ssh υπάρχει για τον χρήστη με τον οποίο θα συνδεθείτε (για παράδειγμα, git ή ο χρήστης διαχειριστής σας) και ότι έχει άδειες 700:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Στη συνέχεια, προσθέστε το περιεχόμενο του αρχείου id_ed25519.pub του πελάτη σας στο ~/.ssh/authorized_keys (δημιουργώντας το αρχείο εάν δεν υπάρχει) και δίνοντάς του δικαιώματα 600:

echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Θυμηθείτε να αντικαταστήσετε το YOUR_PUBLIC_KEY με την πλήρη γραμμή που είδατε χρησιμοποιώντας το `cat` στον υπολογιστή σας. Από εκεί, μπορείτε να δοκιμάσετε τη σύνδεση καθορίζοντας ρητά το κλειδί, εάν το επιθυμείτε.

ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDOR

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

Απενεργοποιήστε πλήρως τον έλεγχο ταυτότητας με κωδικό πρόσβασης στον διακομιστή

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

Πριν αγγίξετε τη διαμόρφωση, είναι καλή ιδέα να δείτε ποια αρχεία ορίζουν το PasswordAuthentication, επειδή σε πολλές σύγχρονες εγκαταστάσεις Υπάρχουν αρχεία .d που αντικαθιστούν την τιμή του κύριου sshd_config:

sudo grep -R "PasswordAuthentication" /etc/ssh/

Είναι σύνηθες να βρίσκεις κάτι σαν:

/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication no

Σε αυτήν την περίπτωση, η ισχύουσα ρύθμιση παραμέτρων θα είναι "ναι" επειδή το αρχείο 50-cloud-init.conf φορτώνεται στη συνέχεια και αντικαθιστά την τιμή. Μπορείτε να επαληθεύσετε το τελικό αποτέλεσμα που εφαρμόζει το sshd με:

sudo sshd -T | grep passwordauthentication

Για να απενεργοποιήσετε τους πραγματικούς κωδικούς πρόσβασης, επεξεργαστείτε το υπεύθυνο αρχείο (για παράδειγμα /etc/ssh/sshd_config.d/50-cloud-init.conf) και αφήστε:

PasswordAuthentication no

Στη συνέχεια, επανεκκινήστε την υπηρεσία SSH:

sudo systemctl restart ssh

Και ελέγξτε ξανά με:

sudo sshd -T | grep passwordauthentication

Αν επιστρέψει "όχι", Οι προσπάθειες σύνδεσης με κωδικό πρόσβασης θα απορριφθούν αμέσωςΠρογράμματα όπως το PuTTY θα εμφανίσουν ένα σφάλμα επειδή δεν μπορούν να παρέχουν διαπιστευτήρια τύπου κωδικού πρόσβασης, αλλά οι υπολογιστές-πελάτες σας με κλειδιά θα συνεχίσουν να λειτουργούν χωρίς πρόβλημα.

Συνδυασμός κλειδιών SSH με Fail2ban και άλλα μέτρα

Όταν αφαιρείτε το PasswordAuthentication από την εξίσωση, η τιμή του Fail2ban για SSH γίνεται πιο χρήσιμη παρά κρίσιμη, καθώς Τα bots δεν έχουν καν πεδίο για να εισάγετε τον κωδικό πρόσβασης.Ακόμα κι έτσι, συνιστάται να διατηρείτε ενεργή τη φυλακή sshd, επειδή χρησιμεύει ως ένα επιπλέον επίπεδο ενάντια σε ασυνήθιστες προσπάθειες άλλων τύπων ή κακή χρήση κλειδιών.

Αν αυτός ο συνδυασμός Μόνο κλειδιά SSH + Fail2ban + root lock + λεπτομερώς ρυθμισμένες λίστες AllowUsers/AllowGroups Προσθέστε ένα περιοριστικό τείχος προστασίας (iptables/nftables, UFW, firewalld) και, εάν χρειάζεται, λίστες ελέγχου πρόσβασης με TCP Wrappers και θα έχετε μειώσει την πιθανότητα εισβολής με βίαιη βία σε αμελητέο επίπεδο.

Σε ακόμη πιο ευαίσθητα περιβάλλοντα, μπορείτε να προχωρήσετε ένα βήμα παραπέρα και να εισαγάγετε έλεγχος ταυτότητας δύο παραγόντων (2FA) για SSHχρησιμοποιώντας ενότητες όπως το Google Authenticator ή παρόμοια μέσω PAM, ή ακόμα και περιορίζοντας ποιος μπορεί να έχει πρόσβαση στη θύρα SSH χρησιμοποιώντας αποκλειστικά VPN.

Με όλα αυτά τα στοιχεία καλά ενσωματωμένα — ανίχνευση αρχείων καταγραφής, προσεκτική διαμόρφωση sshd, εκτεταμένη χρήση του Fail2ban, κλειδιά SSH αντί για κωδικούς πρόσβασης και, όταν είναι απαραίτητο, ελέγχους που βασίζονται σε IP — ένας διακομιστής Linux μπορεί να χειριστεί το συνεχείς επιθέσεις brute-force σε SSH και άλλες εκτεθειμένες υπηρεσίεςδιατηρώντας παράλληλα εύκολη και ασφαλή πρόσβαση για τους διαχειριστές.