Saya sering membaca pendapat bahawa memastikan port RDP (Remote Desktop Protocol) terbuka kepada Internet adalah sangat tidak selamat dan tidak sepatutnya dilakukan. Tetapi anda perlu memberikan akses kepada RDP sama ada melalui VPN, atau hanya dari alamat IP "putih" tertentu.
Saya mentadbir beberapa Pelayan Windows untuk firma kecil di mana saya telah ditugaskan untuk menyediakan akses jauh ke Pelayan Windows untuk akauntan. Ini adalah trend moden - bekerja dari rumah. Dengan cepat, saya menyedari bahawa menyeksa akauntan VPN adalah tugas yang tidak berterima kasih, dan mengumpul semua IP untuk senarai putih tidak akan berfungsi, kerana alamat IP orang ramai adalah dinamik.
Oleh itu, saya mengambil laluan paling mudah - memajukan port RDP ke luar. Untuk mendapatkan akses, akauntan kini perlu menjalankan RDP dan memasukkan nama hos (termasuk port), nama pengguna dan kata laluan.
Dalam artikel ini saya akan berkongsi pengalaman saya (positif dan tidak begitu positif) dan cadangan.
Risiko
Apakah risiko anda dengan membuka port RDP?
1) Akses tanpa kebenaran kepada data sensitif
Jika seseorang meneka kata laluan RDP, mereka akan dapat memperoleh data yang anda mahu rahsiakan: status akaun, baki, data pelanggan, ...
2) Kehilangan data
Contohnya, akibat virus ransomware.
Atau tindakan yang disengajakan oleh penyerang.
3) Kehilangan stesen kerja
Pekerja perlu bekerja, tetapi sistem telah terjejas dan perlu dipasang semula/dipulihkan/dikonfigurasikan.
4) Kompromi rangkaian tempatan
Jika penyerang telah mendapat akses kepada komputer Windows, maka dari komputer ini dia akan dapat mengakses sistem yang tidak boleh diakses dari luar, dari Internet. Contohnya, untuk memfailkan perkongsian, kepada pencetak rangkaian, dsb.
Saya mempunyai kes di mana Windows Server menangkap perisian tebusan
dan perisian tebusan ini mula-mula menyulitkan kebanyakan fail pada pemacu C: dan kemudian mula menyulitkan fail pada NAS melalui rangkaian. Memandangkan NAS ialah Synology, dengan syot kilat dikonfigurasikan, saya memulihkan NAS dalam masa 5 minit, dan memasang semula Pelayan Windows dari awal.
Pemerhatian dan Syor
Saya memantau Pelayan Windows menggunakan , yang menghantar log ke ElasticSearch. Kibana mempunyai beberapa visualisasi, dan saya juga menyediakan papan pemuka tersuai.
Pemantauan itu sendiri tidak melindungi, tetapi ia membantu menentukan langkah-langkah yang diperlukan.
Berikut adalah beberapa pemerhatian:
a) RDP akan dipaksa secara kasar.
Pada salah satu pelayan, saya memasang RDP bukan pada port standard 3389, tetapi pada 443 - baik, saya akan menyamar sebagai HTTPS. Ia mungkin berbaloi untuk menukar port daripada yang standard, tetapi ia tidak akan memberi banyak manfaat. Berikut ialah statistik dari pelayan ini:
Dapat dilihat bahawa dalam seminggu terdapat hampir 400 percubaan untuk log masuk melalui RDP tidak berjaya.
Dapat dilihat bahawa terdapat percubaan untuk log masuk daripada 55 alamat IP (beberapa alamat IP telah disekat oleh saya).
Ini secara langsung mencadangkan kesimpulan bahawa anda perlu menetapkan fail2ban, tetapi
Tiada utiliti sedemikian untuk Windows.
Terdapat beberapa projek terbengkalai di Github yang nampaknya melakukan ini, tetapi saya belum cuba memasangnya:
Terdapat juga utiliti berbayar, tetapi saya tidak menganggapnya.
Jika anda mengetahui utiliti sumber terbuka untuk tujuan ini, sila kongsikannya dalam ulasan.
Update: Komen mencadangkan bahawa port 443 adalah pilihan yang tidak baik, dan lebih baik memilih port tinggi (32000+), kerana 443 diimbas lebih kerap, dan mengenali RDP pada port ini tidak menjadi masalah.
b) Terdapat nama pengguna tertentu yang disukai oleh penyerang
Ia boleh dilihat bahawa carian dijalankan dalam kamus dengan nama yang berbeza.
Tetapi inilah yang saya perhatikan: sebilangan besar percubaan menggunakan nama pelayan sebagai log masuk. Syor: Jangan gunakan nama yang sama untuk komputer dan pengguna. Selain itu, kadangkala ia kelihatan seperti mereka cuba menghuraikan nama pelayan entah bagaimana: contohnya, untuk sistem dengan nama DESKTOP-DFTHD7C, kebanyakan percubaan untuk log masuk adalah dengan nama DFTHD7C:
Sehubungan itu, jika anda mempunyai komputer DESKTOP-MARIA, anda mungkin akan cuba log masuk sebagai pengguna MARIA.
Satu lagi perkara yang saya perhatikan dari log: pada kebanyakan sistem, kebanyakan percubaan untuk log masuk adalah dengan nama "pentadbir". Dan ini bukan tanpa sebab, kerana dalam banyak versi Windows, pengguna ini wujud. Lebih-lebih lagi, ia tidak boleh dipadamkan. Ini memudahkan tugas penyerang: daripada meneka nama dan kata laluan, anda hanya perlu meneka kata laluan.
By the way, sistem yang menangkap perisian tebusan mempunyai Pentadbir pengguna dan kata laluan Murmansk#9. Saya masih tidak pasti bagaimana sistem itu digodam, kerana saya mula memantau sejurus selepas kejadian itu, tetapi saya fikir keterlaluan itu berkemungkinan.
Jadi jika pengguna Pentadbir tidak boleh dipadam, maka apa yang perlu anda lakukan? Anda boleh menamakan semula!
Cadangan daripada perenggan ini:
- jangan gunakan nama pengguna dalam nama komputer
- pastikan tiada pengguna Pentadbir pada sistem
- gunakan kata laluan yang kuat
Jadi, saya telah menonton beberapa Pelayan Windows di bawah kawalan saya yang dipaksa secara kasar selama kira-kira beberapa tahun sekarang, dan tidak berjaya.
Bagaimana saya tahu ia tidak berjaya?
Kerana dalam tangkapan skrin di atas anda dapat melihat bahawa terdapat log panggilan RDP yang berjaya, yang mengandungi maklumat:
- dari IP mana
- dari komputer mana (nama hos)
- nama pengguna
- Maklumat GeoIP
Dan saya kerap memeriksa di sana - tiada anomali ditemui.
Dengan cara ini, jika IP tertentu dipaksa secara kasar, maka anda boleh menyekat IP individu (atau subnet) seperti ini dalam 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 BlockBy the way, Elastic, sebagai tambahan kepada Winlogbeat, juga mempunyai , yang boleh memantau fail dan proses pada sistem. Terdapat juga aplikasi SIEM (Maklumat Keselamatan & Pengurusan Acara) di Kibana. Saya mencuba kedua-duanya, tetapi tidak melihat banyak faedah - nampaknya Auditbeat akan lebih berguna untuk sistem Linux, dan SIEM belum menunjukkan kepada saya apa-apa yang boleh difahami lagi.
Nah, cadangan akhir:
- Buat sandaran automatik biasa.
- pasang Kemas Kini Keselamatan tepat pada masanya
Bonus: senarai 50 pengguna yang paling kerap digunakan untuk percubaan log masuk RDP
"user.name: Menurun"
Pengiraan
dfthd7c (nama hos)
842941
winsrv1 (nama hos)
266525
PENTADBIR
180678
pentadbir
163842
pentadbir
53541
michael
23101
server
21983
steve
21936
john
21927
paul
21913
penerimaan
21909
mike
21899
pejabat
21888
pengimbas
21887
mengimbas
21867
david
21865
chris
21860
pemilik
21855
pengurus
21852
administrateur
21841
brian
21839
pentadbir
21837
tanda
21824
kakitangan
21806
ADMIN
12748
ROOT
7772
PENTADBIR
7325
PERTANYAAN
5577
SOKONGAN
5418
PENGGUNA
4558
admin
2832
UJIAN
1928
MySql
1664
Admin
1652
TAMAT
1322
PENGGUNA1
1179
PEMARKAHAN
1121
SCAN
1032
PENTADBIR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
PENGAMBILAN
490
PENGGUNA2
466
TEMP
452
SQLADMIN
450
PENGGUNA3
441
1
422
PENGURUS
418
PEMILIK
410
Sumber: www.habr.com