ມັນເປັນອັນຕະລາຍທີ່ຈະເປີດ RDP ໃນອິນເຕີເນັດບໍ?

ຂ້າພະເຈົ້າໄດ້ອ່ານຄວາມຄິດເຫັນເລື້ອຍໆວ່າການຮັກສາພອດ RDP (Remote Desktop Protocol) ທີ່ເປີດຢູ່ໃນອິນເຕີເນັດແມ່ນບໍ່ປອດໄພຫຼາຍແລະບໍ່ຄວນເຮັດ. ແຕ່ທ່ານຈໍາເປັນຕ້ອງໃຫ້ການເຂົ້າເຖິງ RDP ໂດຍຜ່ານ VPN, ຫຼືພຽງແຕ່ຈາກທີ່ຢູ່ IP "ສີຂາວ" ທີ່ແນ່ນອນ.

ຂ້າ​ພະ​ເຈົ້າ​ບໍ​ລິ​ຫານ Windows Servers ຈໍາ​ນວນ​ຫນຶ່ງ​ສໍາ​ລັບ​ບໍ​ລິ​ສັດ​ຂະ​ຫນາດ​ນ້ອຍ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ຮັບ​ຫນ້າ​ທີ່​ໃຫ້​ການ​ໃຫ້​ການ​ເຂົ້າ​ເຖິງ​ທາງ​ໄກ​ກັບ Windows Server ສໍາ​ລັບ​ນັກ​ບັນ​ຊີ. ນີ້ແມ່ນແນວໂນ້ມທີ່ທັນສະໄຫມ - ເຮັດວຽກຈາກເຮືອນ. ຂ້ອນຂ້າງໄວ, ຂ້າພະເຈົ້າໄດ້ຮັບຮູ້ວ່າການທໍລະມານນັກບັນຊີ VPN ແມ່ນວຽກງານທີ່ບໍ່ມີປະໂຫຍດ, ແລະການເກັບກໍາ IPs ທັງຫມົດສໍາລັບບັນຊີລາຍຊື່ສີຂາວຈະບໍ່ເຮັດວຽກ, ເພາະວ່າທີ່ຢູ່ IP ຂອງປະຊາຊົນແມ່ນແບບເຄື່ອນໄຫວ.

ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເອົາເສັ້ນທາງທີ່ງ່າຍດາຍທີ່ສຸດ - ສົ່ງຕໍ່ພອດ RDP ໄປຂ້າງນອກ. ເພື່ອເຂົ້າເຖິງ, ນັກບັນຊີຈໍາເປັນຕ້ອງດໍາເນີນການ RDP ແລະໃສ່ຊື່ເຈົ້າພາບ (ລວມທັງພອດ), ຊື່ຜູ້ໃຊ້ແລະລະຫັດຜ່ານ.

ໃນບົດຄວາມນີ້ຂ້ອຍຈະແບ່ງປັນປະສົບການຂອງຂ້ອຍ (ໃນທາງບວກແລະບໍ່ແມ່ນໃນທາງບວກ) ແລະຄໍາແນະນໍາ.

ຄວາມສ່ຽງ

ສິ່ງທີ່ທ່ານມີຄວາມສ່ຽງໂດຍການເປີດພອດ RDP?

1) ການເຂົ້າເຖິງຂໍ້ມູນທີ່ລະອຽດອ່ອນໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ
ຖ້າໃຜຜູ້ຫນຶ່ງຄາດເດົາລະຫັດຜ່ານ RDP, ພວກເຂົາຈະສາມາດໄດ້ຮັບຂໍ້ມູນທີ່ທ່ານຕ້ອງການທີ່ຈະຮັກສາສ່ວນຕົວ: ສະຖານະພາບບັນຊີ, ຍອດເງິນ, ຂໍ້ມູນລູກຄ້າ, ...

2) ການສູນເສຍຂໍ້ມູນ
ຕົວຢ່າງ, ເປັນຜົນມາຈາກເຊື້ອໄວຣັສ ransomware.
ຫຼືການກະທໍາໂດຍເຈດຕະນາໂດຍຜູ້ໂຈມຕີ.

3) ການສູນເສຍສະຖານີເຮັດວຽກ
ຜູ້ອອກແຮງງານຕ້ອງເຮັດວຽກ, ແຕ່ລະບົບຖືກທໍາລາຍແລະຕ້ອງໄດ້ຮັບການຕິດຕັ້ງ / ຟື້ນຟູ / ຕັ້ງຄ່າໃຫມ່.

4) ການປະນີປະນອມຂອງເຄືອຂ່າຍທ້ອງຖິ່ນ
ຖ້າຜູ້ໂຈມຕີໄດ້ຮັບການເຂົ້າເຖິງຄອມພິວເຕີ Windows, ຫຼັງຈາກນັ້ນຈາກຄອມພິວເຕີນີ້ລາວຈະສາມາດເຂົ້າຫາລະບົບທີ່ບໍ່ສາມາດເຂົ້າເຖິງໄດ້ຈາກພາຍນອກ, ຈາກອິນເຕີເນັດ. ຕົວຢ່າງ, ເພື່ອຍື່ນການແບ່ງປັນ, ໃສ່ເຄື່ອງພິມເຄືອຂ່າຍ, ແລະອື່ນໆ.

ຂ້ອຍມີກໍລະນີທີ່ Windows Server ຈັບ ransomware

ແລະ ransomware ນີ້ທໍາອິດເຂົ້າລະຫັດໄຟລ໌ສ່ວນໃຫຍ່ຢູ່ໃນ C: drive ແລະຫຼັງຈາກນັ້ນເລີ່ມຕົ້ນການເຂົ້າລະຫັດໄຟລ໌ໃນ NAS ຜ່ານເຄືອຂ່າຍ. ນັບຕັ້ງແຕ່ NAS ແມ່ນ Synology, ດ້ວຍຮູບພາບທີ່ຖືກຕັ້ງຄ່າ, ຂ້າພະເຈົ້າໄດ້ຟື້ນຟູ NAS ໃນ 5 ນາທີ, ແລະຕິດຕັ້ງ Windows Server ຄືນໃໝ່ຈາກຈຸດເລີ່ມຕົ້ນ.

ການສັງເກດການແລະຄໍາແນະນໍາ

ຂ້າ​ພະ​ເຈົ້າ​ຕິດ​ຕາມ​ກວດ​ກາ Windows Servers ການ​ນໍາ​ໃຊ້ Winlogbeat, ເຊິ່ງສົ່ງບັນທຶກໄປຫາ ElasticSearch. Kibana ມີການເບິ່ງເຫັນຫຼາຍຮູບ, ແລະຂ້ອຍກໍ່ຕັ້ງ dashboard ທີ່ກໍາຫນົດເອງ.
ການຕິດຕາມຕົວມັນເອງບໍ່ໄດ້ປົກປ້ອງ, ແຕ່ມັນຊ່ວຍກໍານົດມາດຕະການທີ່ຈໍາເປັນ.

ນີ້ແມ່ນບາງຂໍ້ສັງເກດ:
a) RDP ຈະຖືກບັງຄັບຢ່າງໂຫດຮ້າຍ.
ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງ, ຂ້ອຍໄດ້ຕິດຕັ້ງ RDP ບໍ່ໄດ້ຢູ່ໃນພອດມາດຕະຖານ 3389, ແຕ່ຢູ່ໃນ 443 - ດີ, ຂ້ອຍຈະປອມຕົວເປັນ HTTPS. ມັນອາດຈະເປັນມູນຄ່າທີ່ຈະປ່ຽນພອດຈາກມາດຕະຖານ, ແຕ່ມັນຈະບໍ່ດີຫຼາຍ. ນີ້ແມ່ນສະຖິຕິຈາກເຊີບເວີນີ້:

ມັນສາມາດເຫັນໄດ້ວ່າໃນຫນຶ່ງອາທິດມີເກືອບ 400 ຄວາມພະຍາຍາມບໍ່ປະສົບຜົນສໍາເລັດໃນການເຂົ້າສູ່ລະບົບຜ່ານ RDP.
ມັນສາມາດເຫັນໄດ້ວ່າມີຄວາມພະຍາຍາມທີ່ຈະເຂົ້າສູ່ລະບົບຈາກ 55 ທີ່ຢູ່ IP (ບາງທີ່ຢູ່ IP ໄດ້ຖືກບລັອກໂດຍຂ້ອຍແລ້ວ).

ນີ້ຊີ້ໃຫ້ເຫັນໂດຍກົງເຖິງການສະຫລຸບວ່າທ່ານຕ້ອງການກໍານົດ fail2ban, ແຕ່

ບໍ່ມີຜົນປະໂຫຍດດັ່ງກ່າວສໍາລັບ Windows.

ມີສອງສາມໂຄງການທີ່ຖືກປະຖິ້ມໄວ້ໃນ Github ທີ່ເບິ່ງຄືວ່າຈະເຮັດແນວນີ້, ແຕ່ຂ້ອຍບໍ່ໄດ້ພະຍາຍາມຕິດຕັ້ງພວກມັນ:
https://github.com/glasnt/wail2ban
https://github.com/EvanAnderson/ts_block

ຍັງມີເຄື່ອງໃຊ້ຈ່າຍ, ແຕ່ຂ້ອຍບໍ່ໄດ້ພິຈາລະນາມັນ.

ຖ້າທ່ານຮູ້ຈັກແຫຼ່ງເປີດສໍາລັບຈຸດປະສົງນີ້, ກະລຸນາແບ່ງປັນມັນໃນຄໍາເຫັນ.

ການປັບປຸງ: ຄວາມຄິດເຫັນແນະນໍາວ່າພອດ 443 ເປັນທາງເລືອກທີ່ບໍ່ດີ, ແລະມັນກໍ່ດີກວ່າທີ່ຈະເລືອກເອົາພອດສູງ (32000+), ເພາະວ່າ 443 ໄດ້ຖືກສະແກນເລື້ອຍໆ, ແລະການຮັບຮູ້ RDP ໃນພອດນີ້ບໍ່ແມ່ນບັນຫາ.

b) ມີຊື່ຜູ້ໃຊ້ທີ່ແນ່ນອນທີ່ຜູ້ໂຈມຕີມັກ
ມັນສາມາດເຫັນໄດ້ວ່າການຄົ້ນຫາແມ່ນດໍາເນີນຢູ່ໃນວັດຈະນານຸກົມທີ່ມີຊື່ທີ່ແຕກຕ່າງກັນ.
ແຕ່ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍສັງເກດເຫັນ: ຄວາມພະຍາຍາມຈໍານວນຫລາຍແມ່ນໃຊ້ຊື່ເຄື່ອງແມ່ຂ່າຍເປັນການເຂົ້າສູ່ລະບົບ. ຄໍາແນະນໍາ: ຢ່າໃຊ້ຊື່ດຽວກັນກັບຄອມພິວເຕີແລະຜູ້ໃຊ້. ຍິ່ງໄປກວ່ານັ້ນ, ບາງຄັ້ງມັນເບິ່ງຄືວ່າພວກເຂົາກໍາລັງພະຍາຍາມວິເຄາະຊື່ເຄື່ອງແມ່ຂ່າຍບາງຢ່າງ: ຕົວຢ່າງເຊັ່ນ, ສໍາລັບລະບົບທີ່ມີຊື່ DESKTOP-DFTHD7C, ຄວາມພະຍາຍາມທີ່ສຸດໃນການເຂົ້າສູ່ລະບົບມີຊື່ DFTHD7C:

ດັ່ງນັ້ນ, ຖ້າທ່ານມີຄອມພິວເຕີ DESKTOP-MARIA, ທ່ານອາດຈະພະຍາຍາມເຂົ້າສູ່ລະບົບເປັນຜູ້ໃຊ້ MARIA.

ສິ່ງອື່ນທີ່ຂ້ອຍສັງເກດເຫັນຈາກບັນທຶກ: ໃນລະບົບສ່ວນໃຫຍ່, ຄວາມພະຍາຍາມສ່ວນໃຫຍ່ທີ່ຈະເຂົ້າສູ່ລະບົບແມ່ນຊື່ "ຜູ້ບໍລິຫານ". ແລະນີ້ບໍ່ແມ່ນບໍ່ມີເຫດຜົນ, ເພາະວ່າໃນຫຼາຍຮຸ່ນຂອງ Windows, ຜູ້ໃຊ້ນີ້ມີຢູ່. ຍິ່ງໄປກວ່ານັ້ນ, ມັນບໍ່ສາມາດຖືກລຶບຖິ້ມໄດ້. ນີ້ເຮັດໃຫ້ວຽກງານສໍາລັບຜູ້ໂຈມຕີງ່າຍຂຶ້ນ: ແທນທີ່ຈະຄາດເດົາຊື່ ແລະລະຫັດຜ່ານ, ທ່ານພຽງແຕ່ຕ້ອງເດົາລະຫັດຜ່ານເທົ່ານັ້ນ.
ໂດຍວິທີທາງການ, ລະບົບທີ່ຈັບ ransomware ມີຜູ້ເບິ່ງແຍງຜູ້ໃຊ້ແລະລະຫັດຜ່ານ Murmansk #9. ຂ້ອຍຍັງບໍ່ແນ່ໃຈວ່າລະບົບນັ້ນຖືກແຮັກໄດ້ແນວໃດ, ເພາະວ່າຂ້ອຍເລີ່ມຕິດຕາມຫຼັງຈາກເຫດການນັ້ນ, ແຕ່ຂ້ອຍຄິດວ່າອາດມີຄວາມເປັນໄປໄດ້ສູງເກີນໄປ.
ດັ່ງນັ້ນຖ້າຜູ້ໃຊ້ Administrator ບໍ່ສາມາດຖືກລຶບ, ເຈົ້າຄວນເຮັດແນວໃດ? ທ່ານສາມາດປ່ຽນຊື່ມັນໄດ້!

ຄໍາແນະນໍາຈາກວັກນີ້:

• ຢ່າໃຊ້ຊື່ຜູ້ໃຊ້ໃນຊື່ຄອມພິວເຕີ
• ໃຫ້ແນ່ໃຈວ່າບໍ່ມີຜູ້ໃຊ້ Administrator ໃນລະບົບ
• ໃຊ້ລະຫັດຜ່ານທີ່ເຂັ້ມແຂງ

ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເບິ່ງ Windows Servers ຫຼາຍອັນພາຍໃຕ້ການຄວບຄຸມຂອງຂ້ອຍຖືກບັງຄັບໃຫ້ຖືກບັງຄັບເປັນເວລາປະມານສອງສາມປີແລ້ວ, ແລະບໍ່ປະສົບຜົນສໍາເລັດ.

ຂ້ອຍຈະຮູ້ໄດ້ແນວໃດວ່າມັນບໍ່ສຳເລັດ?
ເນື່ອງຈາກວ່າໃນ screenshots ຂ້າງເທິງທ່ານສາມາດເຫັນໄດ້ວ່າມີບັນທຶກຂອງການໂທ 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 (ຂໍ້ມູນຄວາມປອດໄພ & ການຈັດການເຫດການ) ໃນ Kibana. ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມທັງສອງ, ແຕ່ບໍ່ເຫັນຜົນປະໂຫຍດຫຼາຍ - ເບິ່ງຄືວ່າ Auditbeat ຈະເປັນປະໂຫຍດກວ່າສໍາລັບລະບົບ Linux, ແລະ SIEM ຍັງບໍ່ໄດ້ສະແດງໃຫ້ຂ້ອຍເຫັນສິ່ງທີ່ສະຫລາດເທື່ອ.

ແລ້ວ, ຄໍາແນະນໍາສຸດທ້າຍ:

• ເຮັດການສໍາຮອງຂໍ້ມູນອັດຕະໂນມັດປົກກະຕິ.
• ຕິດຕັ້ງການປັບປຸງຄວາມປອດໄພໃຫ້ທັນເວລາ

ໂບນັດ: ບັນຊີລາຍຊື່ຂອງ 50 ຜູ້ໃຊ້ທີ່ຖືກນໍາໃຊ້ຫຼາຍທີ່ສຸດສໍາລັບຄວາມພະຍາຍາມເຂົ້າສູ່ລະບົບ RDP

"user.name: Descending"
Count

dfthd7c (ຊື່ເຈົ້າພາບ)
842941

winsrv1 (ຊື່ເຈົ້າພາບ)
266525

ຜູ້​ບໍ​ລິ​ຫານ
180678

ຜູ້ບໍລິຫານ
163842

ຜູ້​ບໍ​ລິ​ຫານ
53541

michael
23101

ເຄື່ອງແມ່ຂ່າຍ
21983

steve
21936

john
21927

paul
21913

reception
21909

mike
21899

ຫ້ອງການ
21888

scanner
21887

ສະແກນ
21867

david
21865

chris
21860

ເຈົ້າຂອງ
21855

ຜູ້ຈັດການ
21852

ຜູ້​ບໍ​ລິ​ຫານ
21841

brian
21839

ຜູ້ບໍລິຫານ
21837

ເຄື່ອງຫມາຍ
21824

ພະນັກງານ
21806

ADMIN
12748

ຮາກ
7772

ຜູ້​ບໍ​ລິ​ຫານ
7325

ສະຫນັບສະຫນູນ
5577

ກາງ
5418

ຜູ້ໃຊ້
4558

admin
2832

TEST
1928

mysql
1664

Admin
1652

ສຸດຍອດ
1322

USER1
1179

ເຄື່ອງສະແກນ
1121

SCAN
1032

ຜູ້​ບໍ​ລິ​ຫານ
842

ADMIN1
525

ແບັກອັບ
518

MySqlAdmin
518

ຮັບຮອງ
490

USER2
466

TEMP
452

SQLADMIN
450

USER3
441

1
422

ຜູ້​ຈັດ​ການ
418

OWNER
410

ແຫຼ່ງຂໍ້ມູນ: www.habr.com