76. RDP와 3389 포트 — 원격 접속 노출 위험

📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 76편
이전 글: 75. SNMP 버전별 보안 차이 · 다음 글: 77. WinRM
참고(리눅스 시스템 기초): SSH Brute Force 로그 분석 — 원격 접속 무차별 대입 분석 관점은 RDP에도 동일하게 적용

1. 왜 알아야 하는가

RDP(Remote Desktop Protocol)는 Windows 원격 데스크톱 접속 프로토콜입니다. 관리자에게는 편리한 도구이지만, 인터넷에 3389번이 열려 있으면 곧바로 자동화된 비밀번호 대입 시도의 대상이 됩니다. 랜섬웨어 사고 분석 보고서에서도 외부에 노출된 RDP가 최초 침투 경로로 자주 언급됩니다.

또한 RDP는 내부에서도 SMB와 함께 내부 확산 경로로 쓰입니다. 탈취한 계정으로 서버에 RDP 로그인하면, 공격자는 관리자와 똑같은 화면을 보게 됩니다.

관제에서 RDP를 볼 때의 질문은 다음과 같습니다.

• 3389가 외부에서 도달 가능한가?
• 로그인 실패가 반복되는가, 그리고 결국 성공했는가?
• 성공한 로그인은 평소의 관리자·출발지·시간대와 일치하는가?

---

2. 핵심 개념

2-1. 포트와 구성 요소

항목	내용
기본 포트	TCP 3389 (최신 클라이언트·서버는 UDP 3389도 함께 사용해 화면 전송 성능 개선)
전송 보안	TLS (구형 "RDP 표준 보안" 방식도 존재하나 권장되지 않음)
NLA	Network Level Authentication. 원격 세션(로그인 화면)을 만들기 전에 CredSSP로 먼저 인증
RD Gateway	RDP를 HTTPS(443)로 감싸 중계하는 게이트웨이. 3389를 외부에 직접 열지 않기 위해 사용

2-2. NLA가 중요한 이유

구분	NLA 미사용	NLA 사용
인증 시점	원격 세션(로그온 화면)을 먼저 띄운 뒤	세션 생성 전에 네트워크 수준에서
미인증 접속자에게 소비되는 자원	세션 생성 비용 발생	인증 실패 시 세션 없음
사전 인증 취약점 노출	상대적으로 큼	일부 완화 (BlueKeep, CVE-2019-0708 권고에서도 완화 요소로 언급)
로그 특징	실패 시 LogonType 10 계열	실패 시 4625의 LogonType이 3으로 기록되는 경우가 많음

마지막 줄이 관제에서 특히 중요합니다. "RDP 실패 = 4625 LogonType 10"으로만 필터를 걸면, NLA 환경의 RDP 대입 공격을 놓칠 수 있습니다.

2-3. 알려진 위험 요소

위험	설명
외부 노출	인터넷 전체를 대상으로 한 3389 스캔·대입 시도가 상시 발생
약한 비밀번호 / 계정 잠금 미설정	대입·스프레이 공격 성공 가능성 증가
사전 인증 취약점	예: BlueKeep(CVE-2019-0708, 구형 Windows 대상). 패치 관리 필요
포트 변경만으로 보호	비표준 포트도 서비스 식별 스캔으로 찾을 수 있어 근본 대책이 아님(20편에서 다룸)

---

3. 동작 원리

그림 1. RDP 연결 단계별로 확인할 수 있는 증거

3-1. RDP 연결 흐름 (NLA 사용 시)

 클라이언트 (mstsc 등)                                  RDP 서버 :3389
    │── TCP 3-Way Handshake ──────────────────────────────→│
    │── X.224 Connection Request (요청 보안 프로토콜 제시) ──→│   ← 초기 패킷, 일부 평문
    │←─ X.224 Connection Confirm (TLS / CredSSP 선택) ──────│
    │══ TLS Handshake ═════════════════════════════════════│
    │══ CredSSP (NTLM 또는 Kerberos 인증) ══════════════════│   ← NLA: 여기서 인증 성공/실패
    │                                                       │      실패 시 연결 종료 (세션 없음)
    │══ RDP 세션 설정 (화면·장치·클립보드 채널 등) ═══════════│
    │══ 화면 전송 / 키보드·마우스 입력 (암호화) ══════════════│
    ↓
 로그인 성공 → Windows 보안 로그 4624 (LogonType 10) 등 기록

• 초기 X.224 요청에는 클라이언트에 따라 Cookie: mstshash=<사용자명> 형태의 문자열이 평문으로 포함되기도 하여, IDS가 이를 근거로 탐지하는 경우가 있습니다. 필드 해석은 (03. Wireshark 패킷 분석 시리즈에서 다룸)
• TLS 이후는 암호화되어 네트워크에서는 연결 횟수·시간·데이터량만 볼 수 있습니다.

3-2. 로그인 시도가 이벤트로 남는 과정

 외부 IP 203.0.113.77 → 3389
     │
     ├─ 인증 실패 ×N  → Security 4625 (LogonType 3 또는 10, Status/SubStatus 코드)
     │
     ├─ 인증 성공     → Security 4624 (LogonType 10)
     │                → LocalSessionManager 21 (세션 로그온), 22 (셸 시작)
     │
     ├─ 창 닫기        → Security 4779 (세션 연결 끊김), LocalSessionManager 24
     ├─ 재접속         → Security 4778 (세션 재연결), LocalSessionManager 25
     └─ 로그오프       → Security 4634 / 4647, LocalSessionManager 23

---

4. 실제 명령어 / 실습

실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu), 인터페이스는 ens33을 예시로 사용합니다. Windows 서버 없이 리눅스용 RDP 서버 xrdp로 3389 포트 동작과 인증 로그를 관찰합니다. 접속은 본인 호스트 PC의 원격 데스크톱 연결(mstsc) 에서만 하며, 방화벽은 호스트 IP 하나만 허용합니다. Windows 이벤트 로그는 6절에서 참고 자료로만 다룹니다.

4-1. xrdp 설치

# Ubuntu
sudo apt install -y xrdp tcpdump
sudo adduser xrdp ssl-cert          # xrdp가 TLS 인증서 키를 읽을 수 있도록
sudo systemctl restart xrdp

# Rocky Linux (EPEL 저장소 필요)
sudo dnf install -y epel-release
sudo dnf install -y xrdp tcpdump
sudo systemctl enable --now xrdp

sudo ss -tlnp | grep ':3389'

데스크톱 환경이 없는 서버 설치본에서는 인증 후 세션 화면이 정상적으로 뜨지 않을 수 있습니다. 이 실습의 목적(연결·인증 로그 관찰)에는 영향이 적습니다.

4-2. 방화벽: 호스트 PC만 허용

호스트 PC의 VMware 가상 어댑터 IP를 예시로 192.168.10.1이라고 하겠습니다(ipconfig로 확인).

# Rocky (firewalld, 재부팅 시 사라지는 런타임 규칙)
sudo firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.10.1" port port="3389" protocol="tcp" accept'

# Ubuntu (ufw 사용 시)
sudo ufw allow from 192.168.10.1 to any port 3389 proto tcp

4-3. 캡처와 접속

# VM에서 캡처
sudo tcpdump -i ens33 -nn 'port 3389'

호스트 PC에서 mstsc → VM IP 입력 → 테스트 계정으로 한 번은 틀린 비밀번호, 한 번은 올바른 비밀번호로 로그인합니다. xrdp는 기본적으로 자체 로그인 화면에서 인증하므로, Windows NLA와는 인증 시점이 다릅니다.

📷 [실습 화면 삽입] tcpdump에서 3389 연결 수립 직후 짧은 패킷 교환 후 TLS 데이터가 이어지는 화면

4-4. 로그 확인

sudo tail -n 30 /var/log/xrdp.log
sudo tail -n 30 /var/log/xrdp-sesman.log
sudo grep xrdp /var/log/auth.log | tail     # Ubuntu
sudo grep xrdp /var/log/secure | tail       # Rocky

📷 [실습 화면 삽입] xrdp-sesman.log에서 인증 성공/실패와 접속 IP가 찍힌 줄

4-5. 정리

sudo systemctl disable --now xrdp
sudo firewall-cmd --reload                                   # Rocky: 런타임 규칙 제거
sudo ufw delete allow from 192.168.10.1 to any port 3389 proto tcp   # Ubuntu

---

5. 결과 확인

xrdp 로그 (형식 예시(값은 환경·버전마다 다름))

[20260926-14:02:11] [INFO ] connection received from 192.168.10.1 port 50311
[20260926-14:02:19] [INFO ] ++ created session: username testuser, ip 192.168.10.1:50311
[20260926-14:03:40] [ERROR] pam_authenticate failed: Authentication failure

PAM 인증 로그 (형식 예시(값은 환경마다 다름))

xrdp-sesman[2210]: pam_unix(xrdp-sesman:auth): authentication failure; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost=  user=testuser

점검 체크리스트

• 3389가 리슨 중이고 방화벽은 호스트 PC IP만 허용했다
• tcpdump에서 TCP 연결 후 곧바로 암호화 구간(TLS)으로 넘어가는 것을 확인했다
• 로그인 실패·성공이 xrdp 로그와 PAM 로그에 각각 어떻게 남는지 비교했다
• 로그에 접속 출발지 IP가 기록되는지 확인했다(버전에 따라 누락될 수 있음)
• Windows 이벤트 ID(4624/4625/4778/4779)의 의미를 6절 표로 정리했다
• 실습 후 xrdp 중지와 방화벽 규칙 제거를 확인했다

---

6. 패킷 / 로그 분석

6-1. Windows 이벤트 (참고)

실습 환경에는 Windows가 없으므로 아래는 참고 자료입니다.

로그 / 이벤트 ID	의미	확인 필드
Security 4624	로그온 성공. LogonType 10 = RemoteInteractive(RDP)	계정, Source Network Address, Workstation Name
Security 4625	로그온 실패. NLA 환경에서는 RDP 실패도 LogonType 3으로 남는 경우가 많음	Status / Sub Status, 출발지 IP
Security 4778 / 4779	세션 재연결 / 연결 끊김	Client Name, Client Address
Security 4634 / 4647	로그오프 / 사용자 시작 로그오프	Logon ID로 4624와 연결
TerminalServices-RemoteConnectionManager/Operational 1149	원격 접속 네트워크 연결(메시지는 "인증 성공"이지만 최종 로그온 성공을 뜻하지는 않음)	사용자, 출발지 IP
TerminalServices-LocalSessionManager/Operational 21·22·23·24·25	세션 로그온·셸 시작·로그오프·연결 끊김·재연결	사용자, 원본 네트워크 주소

4625의 대표 코드 (Sub Status 기준)

코드	의미
0xC000006A	계정은 있으나 비밀번호 틀림
0xC0000064	존재하지 않는 계정
0xC0000234	계정 잠김
0xC0000072	비활성화된 계정

6-2. 판단 기준

관찰	정상일 수 있는 경우	의심해야 하는 경우
외부 IP → 3389 허용 세션	없어야 함(VPN·RD Gateway 경유가 원칙)	인터넷에서 직접 연결 성공
4625 반복	한 사용자의 비밀번호 오입력 몇 회	한 IP → 다수 계정(스프레이), 다수 IP → 한 계정(대입)
0xC0000064 다수	퇴사자 계정 잔여 설정	administrator, admin, test 등 사전 단어 계정 순회
4625 연속 후 4624 Type 10	비밀번호를 기억해 낸 사용자	대입 공격 성공 → 최우선 대응
내부 PC → 여러 서버 3389	운영자 점프 서버에서의 관리	일반 사용자 PC에서 여러 서버로 연쇄 접속
업무 외 시간 4624 Type 10	야간 작업 승인 건	승인 없음, 평소와 다른 출발지

6-3. 리눅스 측 확인 명령

# 3389 세션 출발지 확인 (게이트웨이·점프 서버 등 리눅스 장비에서)
sudo ss -tn state established '( sport = :3389 or dport = :3389 )'

# 3389 신규 연결(SYN) 출발지별 횟수
sudo tcpdump -i ens33 -nn -c 200 'tcp dst port 3389 and tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' \
  | awk '{split($3,s,"."); print s[1]"."s[2]"."s[3]"."s[4]}' | sort | uniq -c | sort -rn

---

7. 보안관제 관점

흔적이 남는 곳

위치	남는 정보
경계 방화벽	외부 → 3389 허용/차단, 세션 시간·데이터량
IDS/IPS	RDP 대입 임계값 룰, 알려진 취약점 악용 시그니처 (06. 방화벽 · IDS/IPS 분석 시리즈에서 다룸)
Windows Security 로그	4624/4625/4778/4779/4634
원격 데스크톱 운영 로그	RemoteConnectionManager 1149, LocalSessionManager 21~25
VPN·RD Gateway 로그	실제 사용자 인증과 외부 출발지

관제 시 핵심 포인트

• 3389 외부 노출은 분석 대상이 아니라 제거 대상입니다. VPN 또는 RD Gateway 뒤로 옮기고, 허용 IP를 제한하고, MFA와 계정 잠금 정책을 적용합니다.
• 가장 중요한 경보는 "실패 다수 → 같은 출발지의 성공" 입니다. 실패만 있는 경보는 흔한 인터넷 소음일 수 있지만, 성공이 이어지면 즉시 세션 차단·계정 비밀번호 변경·해당 서버 점검이 필요합니다.
• 내부 RDP는 점프 서버(관리 서버) 기준선을 두고, 그 외 출발지에서의 RDP를 주목합니다. 스캔·연쇄 접속 판단은 (05. 네트워크 스캔 · 공격 징후 분석 시리즈에서 다룸)

한계와 오탐 주의

• RDP 트래픽은 암호화되어 있어 네트워크에서는 로그인 성공 여부를 알 수 없습니다. 짧게 끊긴 연결 = 실패, 긴 연결 = 성공으로 추정할 수 있지만 단정은 엔드포인트 로그로 해야 합니다.
• NAT·RD Gateway·로드밸런서를 거치면 4624/4625의 출발지 IP가 중계 장비 IP로 기록될 수 있습니다. 실제 출발지는 게이트웨이 로그에서 찾습니다.
• 1149 이벤트는 이름과 달리 최종 로그온 성공을 보장하지 않으므로, 4624·21번 이벤트와 함께 판단합니다.
• 포트를 바꾼 RDP는 3389 필터에 걸리지 않습니다. 포트보다 프로토콜 식별이 필요합니다(20편에서 다룸).

---

8. 핵심 정리

• RDP는 TCP(및 UDP) 3389를 쓰며, TLS와 NLA(CredSSP) 로 세션 생성 전에 인증합니다.
• 성공 로그인은 4624 LogonType 10, 실패는 4625이며 NLA 환경에서는 실패가 LogonType 3으로 남는 경우가 많아 필터에 주의합니다.
• 세션 흐름은 4778/4779(재연결/끊김), LocalSessionManager 21~25로 이어서 추적합니다.
• 관제 최우선 경보는 외부 노출된 3389와 실패 반복 후 같은 출발지의 성공입니다.
• 네트워크에서는 암호화로 내용을 볼 수 없으므로 엔드포인트 로그 + 게이트웨이 로그를 함께 봐야 합니다.

다음 글: 16. SNMP 버전별 보안 차이