Έχω διαβάσει συχνά την άποψη ότι η διατήρηση μιας θύρας RDP (Remote Desktop Protocol) ανοιχτή στο Διαδίκτυο είναι πολύ επικίνδυνη και δεν πρέπει να γίνεται. Αλλά πρέπει να δώσετε πρόσβαση στο RDP είτε μέσω VPN, είτε μόνο από ορισμένες «λευκές» διευθύνσεις IP.
Διαχειρίζομαι αρκετούς διακομιστές Windows για μικρές επιχειρήσεις όπου μου έχει ανατεθεί η παροχή απομακρυσμένης πρόσβασης στον Windows Server για λογιστές. Αυτή είναι η σύγχρονη τάση - εργασία από το σπίτι. Πολύ γρήγορα, συνειδητοποίησα ότι το να βασανίζεις τους λογιστές VPN είναι μια άχαρη εργασία και η συλλογή όλων των IP για τη λευκή λίστα δεν θα λειτουργήσει, επειδή οι διευθύνσεις IP των ανθρώπων είναι δυναμικές.
Επομένως, πήρα την απλούστερη διαδρομή - προώθησα τη θύρα RDP προς τα έξω. Για να αποκτήσουν πρόσβαση, οι λογιστές πρέπει τώρα να εκτελέσουν το RDP και να εισαγάγουν το όνομα κεντρικού υπολογιστή (συμπεριλαμβανομένης της θύρας), το όνομα χρήστη και τον κωδικό πρόσβασης.
Σε αυτό το άρθρο θα μοιραστώ την εμπειρία μου (θετική και όχι τόσο θετική) και τις συστάσεις μου.
Κίνδυνοι
Τι διακινδυνεύετε ανοίγοντας τη θύρα RDP;
1) Μη εξουσιοδοτημένη πρόσβαση σε ευαίσθητα δεδομένα
Εάν κάποιος μαντέψει τον κωδικό πρόσβασης RDP, θα μπορεί να λάβει δεδομένα που θέλετε να διατηρήσετε ιδιωτικά: κατάσταση λογαριασμού, υπόλοιπα, δεδομένα πελατών, ...
2) Απώλεια δεδομένων
Για παράδειγμα, ως αποτέλεσμα ενός ιού ransomware.
Ή μια σκόπιμη ενέργεια από έναν εισβολέα.
3) Απώλεια σταθμού εργασίας
Οι εργαζόμενοι πρέπει να εργαστούν, αλλά το σύστημα έχει παραβιαστεί και πρέπει να επανεγκατασταθεί/αποκατασταθεί/ρυθμιστεί.
4) Συμβιβασμός του τοπικού δικτύου
Εάν ένας εισβολέας έχει αποκτήσει πρόσβαση σε έναν υπολογιστή με Windows, τότε από αυτόν τον υπολογιστή θα μπορεί να έχει πρόσβαση σε συστήματα που είναι απρόσιτα από το εξωτερικό, από το Διαδίκτυο. Για παράδειγμα, σε κοινόχρηστα αρχεία, σε εκτυπωτές δικτύου κ.λπ.
Είχα μια περίπτωση όπου ο Windows Server έπιασε ένα ransomware
και αυτό το ransomware κρυπτογραφούσε πρώτα τα περισσότερα αρχεία στη μονάδα δίσκου C: και στη συνέχεια άρχισε να κρυπτογραφεί τα αρχεία στο NAS μέσω του δικτύου. Δεδομένου ότι το NAS ήταν Synology, με διαμορφωμένα στιγμιότυπα, επαναφέρω το NAS σε 5 λεπτά και επανεγκατέστησα τον Windows Server από την αρχή.
Παρατηρήσεις και συστάσεις
Παρακολουθώ τους διακομιστές των Windows χρησιμοποιώντας , τα οποία στέλνουν αρχεία καταγραφής στο ElasticSearch. Το Kibana έχει πολλές οπτικοποιήσεις και έχω δημιουργήσει επίσης έναν προσαρμοσμένο πίνακα ελέγχου.
Η ίδια η παρακολούθηση δεν προστατεύει, αλλά βοηθά στον καθορισμό των απαραίτητων μέτρων.
Εδώ είναι μερικές παρατηρήσεις:
α) Το RDP θα είναι ωμή αναγκαστική.
Σε έναν από τους διακομιστές, εγκατέστησα το RDP όχι στην τυπική θύρα 3389, αλλά στο 443 - λοιπόν, θα μεταμφιεστώ ως HTTPS. Μάλλον αξίζει να αλλάξετε τη θύρα από την τυπική, αλλά δεν θα κάνει και πολύ καλό. Ακολουθούν τα στατιστικά στοιχεία από αυτόν τον διακομιστή:
Μπορεί να φανεί ότι σε μια εβδομάδα έγιναν σχεδόν 400 ανεπιτυχείς προσπάθειες σύνδεσης μέσω RDP.
Μπορεί να φανεί ότι έγιναν προσπάθειες σύνδεσης από 55 διευθύνσεις IP (κάποιες διευθύνσεις IP είχαν ήδη αποκλειστεί από εμένα).
Αυτό υποδηλώνει άμεσα το συμπέρασμα ότι πρέπει να ρυθμίσετε το fail2ban, αλλά
Δεν υπάρχει τέτοιο βοηθητικό πρόγραμμα για τα Windows.
Υπάρχουν μερικά εγκαταλελειμμένα έργα στο Github που φαίνεται να το κάνουν αυτό, αλλά δεν έχω καν προσπαθήσει να τα εγκαταστήσω:
Υπάρχουν επίσης πληρωμένα βοηθητικά προγράμματα, αλλά δεν τα έχω σκεφτεί.
Εάν γνωρίζετε κάποιο βοηθητικό πρόγραμμα ανοιχτού κώδικα για αυτόν τον σκοπό, μοιραστείτε το στα σχόλια.
Ενημέρωση: Τα σχόλια πρότειναν ότι η θύρα 443 είναι μια κακή επιλογή και είναι προτιμότερο να επιλέξετε υψηλές θύρες (32000+), επειδή το 443 σαρώνεται πιο συχνά και η αναγνώριση RDP σε αυτήν τη θύρα δεν αποτελεί πρόβλημα.
Ενημέρωση: Τα σχόλια υποδηλώνουν ότι υπάρχει ένα τέτοιο βοηθητικό πρόγραμμα:
β) Υπάρχουν ορισμένα ονόματα χρήστη που προτιμούν οι εισβολείς
Μπορεί να φανεί ότι η αναζήτηση πραγματοποιείται σε λεξικό με διαφορετικά ονόματα.
Αλλά να τι παρατήρησα: ένας σημαντικός αριθμός προσπαθειών χρησιμοποιούν το όνομα διακομιστή ως σύνδεση. Σύσταση: Μην χρησιμοποιείτε το ίδιο όνομα για τον υπολογιστή και τον χρήστη. Επιπλέον, μερικές φορές φαίνεται ότι προσπαθούν να αναλύσουν το όνομα διακομιστή με κάποιο τρόπο: για παράδειγμα, για ένα σύστημα με το όνομα DESKTOP-DFTHD7C, οι περισσότερες προσπάθειες σύνδεσης γίνονται με το όνομα DFTHD7C:
Αντίστοιχα, εάν διαθέτετε υπολογιστή DESKTOP-MARIA, πιθανότατα θα προσπαθήσετε να συνδεθείτε ως χρήστης MARIA.
Ένα άλλο πράγμα που παρατήρησα από τα αρχεία καταγραφής: στα περισσότερα συστήματα, οι περισσότερες προσπάθειες σύνδεσης γίνονται με το όνομα "διαχειριστής". Και αυτό δεν είναι χωρίς λόγο, γιατί σε πολλές εκδόσεις των Windows, υπάρχει αυτός ο χρήστης. Επιπλέον, δεν μπορεί να διαγραφεί. Αυτό απλοποιεί την εργασία για τους εισβολείς: αντί να μαντέψετε όνομα και κωδικό πρόσβασης, χρειάζεται μόνο να μαντέψετε τον κωδικό πρόσβασης.
Παρεμπιπτόντως, το σύστημα που έπιασε το ransomware είχε τον διαχειριστή χρήστη και τον κωδικό πρόσβασης Murmansk#9. Εξακολουθώ να μην είμαι σίγουρος πώς παραβιάστηκε αυτό το σύστημα, γιατί άρχισα να παρακολουθώ αμέσως μετά από αυτό το περιστατικό, αλλά νομίζω ότι αυτή η υπερβολή είναι πιθανή.
Επομένως, εάν ο χρήστης διαχειριστής δεν μπορεί να διαγραφεί, τότε τι πρέπει να κάνετε; Μπορείτε να το μετονομάσετε!
Συστάσεις από αυτήν την παράγραφο:
- μην χρησιμοποιείτε το όνομα χρήστη στο όνομα του υπολογιστή
- βεβαιωθείτε ότι δεν υπάρχει χρήστης διαχειριστής στο σύστημα
- χρησιμοποιήστε ισχυρούς κωδικούς πρόσβασης
Παρακολουθώ, λοιπόν, αρκετούς διακομιστές Windows υπό τον έλεγχό μου να εξαναγκάζονται με βάναυσο τρόπο εδώ και περίπου δύο χρόνια, και χωρίς επιτυχία.
Πώς ξέρω ότι είναι ανεπιτυχές;
Επειδή στα παραπάνω στιγμιότυπα οθόνης μπορείτε να δείτε ότι υπάρχουν αρχεία καταγραφής επιτυχημένων κλήσεων RDP, τα οποία περιέχουν τις πληροφορίες:
- από την οποία IP
- από ποιον υπολογιστή (όνομα κεντρικού υπολογιστή)
- имя пользователя
- Πληροφορίες GeoIP
Και ελέγχω εκεί τακτικά - δεν έχουν βρεθεί ανωμαλίες.
Παρεμπιπτόντως, εάν μια συγκεκριμένη IP επιβάλλεται ιδιαίτερα σκληρά, τότε μπορείτε να αποκλείσετε μεμονωμένες IP (ή υποδίκτυα) όπως αυτό στο PowerShell:
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action BlockΠαρεμπιπτόντως, το Elastic εκτός από Winlogbeat έχει και , το οποίο μπορεί να παρακολουθεί αρχεία και διαδικασίες στο σύστημα. Υπάρχει επίσης μια εφαρμογή SIEM (Security Information & Event Management) στην Kibana. Δοκίμασα και τα δύο, αλλά δεν είδα πολλά οφέλη - φαίνεται ότι το Auditbeat θα είναι πιο χρήσιμο για συστήματα Linux και η SIEM δεν μου έχει δείξει κάτι κατανοητό ακόμα.
Λοιπόν, τελικές συστάσεις:
- Δημιουργήστε τακτικά αυτόματα αντίγραφα ασφαλείας.
- εγκαταστήστε έγκαιρα τις ενημερώσεις ασφαλείας
Μπόνους: λίστα 50 χρηστών που χρησιμοποιήθηκαν συχνότερα για προσπάθειες σύνδεσης RDP
"user.name: Φθίνουσα"
Κόμης
dfthd7c (όνομα κεντρικού υπολογιστή)
842941
winsrv1 (όνομα κεντρικού υπολογιστή)
266525
ΔΙΑΧΕΙΡΙΣΤΗΣ
180678
διαχειριστής
163842
Διαχειριστής
53541
Μιχαήλ
23101
διακομιστής
21983
steve
21936
Γιάννης
21927
Παύλος
21913
υποδοχή
21909
μικρόφωνο
21899
γραφείο
21888
σαρωτή
21887
σάρωση
21867
Δαβίδ
21865
chris
21860
ιδιοκτήτης
21855
διευθυντής
21852
Administrateur
21841
brian
21839
διαχειριστής
21837
σημάδι
21824
προσωπικό
21806
ΔΙΑΧΕΙΡΙΣΤΗΣ
12748
ROOT
7772
ΔΙΑΧΕΙΡΙΣΤΗΣ
7325
ΥΠΟΣΤΗΡΙΞΗ
5577
Υποστήριξη
5418
ΜΕΤΑΧΕΙΡΙΖΌΜΕΝΟΣ
4558
διαχειριστής
2832
ΔΟΚΙΜΗ
1928
MySql
1664
διαχειριστής
1652
ΕΠΙΣΚΕΠΤΗΣ
1322
ΧΡΗΣΤΗΣ1
1179
SCANNER
1121
SCAN
1032
ΔΙΟΙΚΗΤΗΣ
842
ΔΙΑΧΕΙΡΙΣΤΗΣ1
525
BACKUP
518
MySqlAdmin
518
ΡΕΣΕΨΙΟΝ
490
ΧΡΗΣΤΗΣ2
466
TEMP
452
SQLADMIN
450
ΧΡΗΣΤΗΣ3
441
1
422
ΔΙΕΥΘΥΝΤΗΣ
418
ΙΔΙΟΚΤΗΤΗΣ
410
Πηγή: www.habr.com