인터넷에서 RDP를 열어 두는 것이 위험합니까?

나는 RDP(원격 데스크톱 프로토콜) 포트를 인터넷에 열어두는 것은 매우 위험하며 그렇게 해서는 안 된다는 의견을 자주 읽었습니다. 하지만 VPN을 통하거나 특정 "화이트" IP 주소에서만 RDP에 대한 액세스 권한을 부여해야 합니다.

저는 회계사에게 Windows Server에 대한 원격 액세스를 제공하는 임무를 맡은 소규모 회사의 여러 Windows Server를 관리합니다. 재택근무가 요즘 대세입니다. VPN 회계사를 괴롭히는 것은 고마운 일이며, 사람들의 IP 주소는 동적이기 때문에 화이트리스트에 대한 모든 IP를 수집하는 것은 효과가 없다는 것을 아주 빨리 깨달았습니다.

따라서 가장 간단한 경로를 선택했습니다. RDP 포트를 외부로 전달하는 것입니다. 액세스 권한을 얻으려면 회계사는 이제 RDP를 실행하고 호스트 이름(포트 포함), 사용자 이름 및 비밀번호를 입력해야 합니다.

이 기사에서는 내 경험(긍정적이든 아니든)과 권장 사항을 공유하겠습니다.

위험

RDP 포트를 열면 어떤 위험이 있습니까?

1) 민감한 데이터에 대한 무단 접근
누군가 RDP 비밀번호를 추측하면 계정 상태, 잔액, 고객 데이터 등 비공개로 유지하려는 데이터를 얻을 수 있습니다.

2) 데이터 손실
예를 들어 랜섬웨어 바이러스의 결과입니다.
또는 공격자의 고의적인 행동입니다.

3) 워크스테이션의 분실
작업자는 작업을 해야 하지만 시스템이 손상되어 다시 설치/복원/구성해야 합니다.

4) 로컬 네트워크의 침해
공격자가 Windows 컴퓨터에 대한 액세스 권한을 얻은 경우 이 컴퓨터에서는 외부나 인터넷에서 액세스할 수 없는 시스템에 액세스할 수 있습니다. 예를 들어 파일 공유, 네트워크 프린터 등에 대한 것입니다.

Windows Server에서 랜섬웨어를 발견한 사례가 있었습니다.

이 랜섬웨어는 먼저 C: 드라이브에 있는 대부분의 파일을 암호화한 다음 네트워크를 통해 NAS에 있는 파일을 암호화하기 시작했습니다. NAS는 Synology였기 때문에 스냅샷이 구성된 상태에서 5분 만에 NAS를 복원하고 Windows Server를 처음부터 다시 설치했습니다.

관찰 및 권장사항

나는 다음을 사용하여 Windows 서버를 모니터링합니다. 윈로그비트, ElasticSearch에 로그를 보냅니다. Kibana에는 여러 시각화 기능이 있으며 사용자 정의 대시보드도 설정했습니다.
모니터링 자체는 보호가 되지 않지만 필요한 조치를 결정하는 데 도움이 됩니다.

다음은 몇 가지 관찰 사항입니다.
a) RDP는 무차별 공격을 받습니다.
서버 중 하나에서 표준 포트 3389가 아닌 443에 RDP를 설치했습니다. 음, HTTPS로 위장하겠습니다. 아마도 표준 포트에서 포트를 변경하는 것이 가치가 있을 것입니다. 그러나 그다지 좋은 결과를 얻지는 못할 것입니다. 이 서버의 통계는 다음과 같습니다.

일주일 동안 RDP를 통해 로그인하려는 시도가 거의 400번 실패했다는 것을 알 수 있습니다.
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 사용자로 로그인을 시도하게 될 것입니다.

로그에서 또 다른 사실은 대부분의 시스템에서 대부분의 로그인 시도가 "administrator"라는 이름을 사용한다는 것입니다. 그리고 이것은 많은 Windows 버전에 이 사용자가 존재하기 때문에 이유가 없는 것은 아닙니다. 게다가 삭제할 수도 없습니다. 이는 공격자의 작업을 단순화합니다. 이름과 비밀번호를 추측하는 대신 비밀번호만 추측하면 됩니다.
그런데 랜섬웨어를 포착한 시스템의 사용자는 Administrator이고 비밀번호는 Murmansk#9였습니다. 그 사건 직후에 모니터링을 시작했기 때문에 그 시스템이 어떻게 해킹되었는지는 아직 잘 모르겠지만 과잉이 가능성이 있다고 생각합니다.
그렇다면 관리자 사용자를 삭제할 수 없다면 어떻게 해야 합니까? 이름을 바꾸시면 됩니다!

이 단락의 권장사항:

• 컴퓨터 이름에 사용자 이름을 사용하지 마십시오
• 시스템에 관리자 사용자가 없는지 확인하십시오.
• 강력한 비밀번호를 사용하세요

그래서 저는 제가 통제하는 여러 Windows Server가 약 XNUMX년 동안 무차별 대입 공격을 받는 것을 지켜봤지만 성공하지 못했습니다.

성공하지 못했다는 것을 어떻게 알 수 있나요?
위 스크린샷에는 다음 정보가 포함된 성공적인 RDP 호출 로그가 있음을 확인할 수 있습니다.

• 어느 IP에서
• 어느 컴퓨터(호스트 이름)
• имя пользователя
• GeoIP 정보

그리고 정기적으로 확인합니다. 이상이 발견되지 않았습니다.

그런데 특정 IP가 특히 무차별 공격을 받는 경우 PowerShell에서 다음과 같이 개별 IP(또는 서브넷)를 차단할 수 있습니다.

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 외에도 다음이 있습니다. 감사비트, 시스템의 파일과 프로세스를 모니터링할 수 있습니다. Kibana에는 SIEM(보안 정보 및 이벤트 관리) 애플리케이션도 있습니다. 두 가지를 모두 시도했지만 큰 이점을 얻지 못했습니다. Auditbeat가 Linux 시스템에 더 유용할 것으로 보이며 SIEM은 아직 이해하기 쉬운 내용을 보여주지 않았습니다.

음, 최종 권장 사항은 다음과 같습니다.

• 정기적으로 자동 백업을 하세요.
• 적시에 보안 업데이트를 설치하십시오.

보너스: RDP 로그인 시도에 가장 자주 사용된 사용자 50명의 목록

"user.name: 내림차순"
카운트

dfthd7c(호스트 이름)
842941

Winsrv1(호스트 이름)
266525

관리자
180678

관리자
163842

관리자
53541

마이클
23101

섬기는 사람
21983

스티브
21936

요한 복음
21927

폴
21913

수신
21909

마이크
21899

사무실
21888

스캐너
21887

주사
21867

데이비드
21865

크리스
21860

소유자
21855

매니저
21852

administrateur
21841

브라이언
21839

관리자
21837

표
21824

직원
21806

관리자
12748

ROOT
7772

관리자
7325

고객지원
5577

지원
5418

USER
4558

관리자
2832

TEST
1928

MySQL을
1664

관리자
1652

GUEST
1322

사용자 1
1179

스캐너
1121

주사
1032

관리자
842

ADMIN1
525

백업
518

MySql관리자
518

수신
490

사용자 2
466

TEMP
452

SQLADMIN
450

사용자 3
441

1
422

MANAGER
418

OWNER
410

출처 : habr.com