📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 72편
이전 글: 71. DHCP 위장·고갈 공격의 원리와 탐지 · 다음 글: 73. SMB와 445 포트 — 내부 확산의 통로
1. 왜 알아야 하는가
기업 내부망의 많은 계정은 개별 서버가 아니라 중앙 디렉터리(Windows 환경의 Active Directory, 리눅스 환경의 FreeIPA·OpenLDAP 등)에서 관리됩니다. 사용자가 PC에 로그인하거나, 파일 서버에 접근하거나, 사내 웹 서비스에 SSO로 들어갈 때 뒤에서는 LDAP 조회와 Kerberos 티켓 발급이 일어납니다.
관제 관점에서 이 트래픽이 중요한 이유는 다음과 같습니다.
- 공격자는 내부에 들어온 뒤 계정·그룹·서버 목록을 파악하기 위해 디렉터리를 조회합니다(정찰).
- 계정 탈취 이후의 권한 확대·내부 이동도 인증 인프라를 거칩니다.
- 반대로, 정상 업무에서도 인증 트래픽은 매우 많기 때문에 "평소 모습"을 알지 못하면 이상을 구분할 수 없습니다.
이 글은 "LDAP·Kerberos 포트에서 어떤 서비스·프로토콜이 통신하는가"를 개요 수준에서 정리합니다. 공격 기법의 실행 방법은 다루지 않고, 원리와 탐지 관점만 봅니다.
2. 핵심 개념
2-1. 인증 인프라 주요 포트
| 포트 | 프로토콜 | 용도 |
|---|---|---|
| 389/TCP | LDAP | 디렉터리 조회·수정. 기본은 평문, StartTLS로 암호화 전환 가능 |
| 389/UDP | CLDAP | AD 환경에서 도메인 컨트롤러 탐색 등에 사용되는 비연결형 LDAP |
| 636/TCP | LDAPS | 처음부터 TLS로 감싼 LDAP |
| 3268/TCP, 3269/TCP | Global Catalog (평문 / TLS) | AD 포리스트 전체 대상 조회 |
| 88/TCP·UDP | Kerberos | 티켓 발급(KDC) |
| 464/TCP·UDP | kpasswd | Kerberos 비밀번호 변경 |
| 53/TCP·UDP | DNS | SRV 레코드로 LDAP·Kerberos 서버 위치 탐색 |
도메인 환경에서는 여기에 SMB(445, 14편 참고), RPC(135 및 동적 포트)도 함께 쓰이지만, 이 글에서는 LDAP·Kerberos에 집중합니다.
2-2. LDAP이란
LDAP(Lightweight Directory Access Protocol)은 트리 구조의 디렉터리를 조회·수정하는 프로토콜입니다. 항목은 DN(Distinguished Name)으로 식별합니다.
dc=example,dc=local ← 최상위(도메인)
├─ ou=People
│ └─ uid=kim,ou=People,dc=example,dc=local
└─ ou=Groups
└─ cn=admins,ou=Groups,dc=example,dc=local| LDAP 개념 | 의미 |
|---|---|
| Bind | 디렉터리에 인증하는 단계. Anonymous / Simple(아이디·비밀번호) / SASL 방식 |
| Search | Base DN, 범위(scope), 필터를 지정해 항목 조회 |
| RootDSE | 서버가 지원하는 기능·Naming Context를 알려주는 특수 항목 |
| StartTLS | 389 연결을 도중에 TLS로 전환 |
Simple Bind를 389 평문으로 하면 비밀번호가 네트워크에 그대로 노출됩니다. 11편의 평문 프로토콜 위험과 같은 문제입니다.
2-3. Kerberos란
Kerberos는 비밀번호를 매번 서비스에 보내지 않고, KDC(Key Distribution Center)가 발급한 티켓으로 인증하는 방식입니다.
| 용어 | 의미 |
|---|---|
| KDC | 인증 서버(AS) + 티켓 발급 서버(TGS). AD에서는 도메인 컨트롤러가 담당 |
| TGT | 로그인 시 받는 "티켓을 받기 위한 티켓" |
| 서비스 티켓 | 특정 서비스(SPN) 접근용 티켓 |
| SPN | Service Principal Name. 예: HTTP/web01.example.local |
| Pre-authentication | TGT 요청 시 클라이언트가 비밀번호 기반 값으로 자신을 먼저 증명하는 단계 |
Kerberos는 시간에 민감합니다. 일반적으로 클라이언트와 KDC의 시간 차이 허용치는 5분이며, 이를 넘으면 인증이 실패합니다. 17편의 NTP 동기화가 인증 인프라에서 필수인 이유입니다.
3. 동작 원리
도메인 사용자가 PC에 로그인한 뒤 사내 웹 서비스에 접근하는 흐름을 단순화하면 다음과 같습니다.
그림 1. TGT 발급 → 서비스 티켓 발급 → 서비스 접속
[클라이언트] [KDC / 도메인 컨트롤러] [서비스 서버]
│ │ │
│ ① DNS SRV 조회 (_kerberos._tcp, _ldap._tcp) → DC 위치 확인 │
│ │ │
│ ② AS-REQ (88) ─────────────────→ │ 사용자 확인, 사전인증 검증 │
│ ←────────────────── AS-REP (TGT) │ │
│ │ │
│ ③ TGS-REQ (88, TGT + SPN) ─────→ │ │
│ ←────────── TGS-REP (서비스 티켓) │ │
│ │ │
│ ④ AP-REQ (서비스 티켓, 해당 서비스 프로토콜 안에 포함) ────────→ │
│ ←──────────────────────────────────────────────── 접근 허용 ─── │
↓
⑤ 필요 시 LDAP(389/636)으로 그룹·속성 조회 (서비스 서버 또는 클라이언트)- ②③은 UDP/TCP 88에서 일어납니다. 응답이 커지면 TCP가 사용됩니다.
- ④의 티켓은 88번 포트가 아니라 대상 서비스의 프로토콜 안에(HTTP의 Negotiate 헤더, SMB 세션 설정 등) 실려 갑니다. 즉 Kerberos 흔적은 88번 포트에만 있지 않습니다.
- 비밀번호 자체는 네트워크로 전송되지 않지만, 티켓은 서비스 계정의 비밀번호에서 파생된 키로 암호화됩니다. 서비스 계정 비밀번호가 약하면 티켓을 오프라인에서 추측하는 공격(Kerberoasting)의 대상이 될 수 있다는 점이 알려져 있습니다. 여기서는 원리와 탐지 관점만 다룹니다.
4. 실제 명령어 / 실습
실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스 이름 ens33은 예시입니다. LDAP·Kerberos 서버는 본인 실습 도메인(예: 실습용 FreeIPA 서버 또는 Windows Server 평가판 AD)이 있을 때만 대상으로 하며, 도메인 이름 example.local, 서버 192.168.10.20은 예시입니다.
4-1. 클라이언트 도구 설치
# Rocky Linux
sudo dnf install -y openldap-clients krb5-workstation bind-utils
# Ubuntu
sudo apt update && sudo apt install -y ldap-utils krb5-user dnsutils4-2. DNS SRV 레코드로 인증 서버 위치 확인
dig +short SRV _ldap._tcp.example.local
dig +short SRV _kerberos._tcp.example.local4-3. RootDSE 조회 (서버가 제공하는 기본 정보)
ldapsearch -x -H ldap://192.168.10.20 -s base -b "" namingContexts-x는 Simple 인증(여기서는 계정 없이 익명), -s base -b ""는 RootDSE를 의미합니다. 암호화 연결을 확인하려면 다음처럼 비교해 봅니다.
ldapsearch -x -ZZ -H ldap://192.168.10.20 -s base -b "" namingContexts # StartTLS 강제
ldapsearch -x -H ldaps://192.168.10.20 -s base -b "" namingContexts # LDAPS(636)인증서 신뢰 설정이 없으면 TLS 연결이 실패할 수 있으며, 이 경우 실습 CA 인증서를 클라이언트에 등록해야 합니다.
4-4. Kerberos 티켓 받기·확인 (본인 실습 계정)
kinit labuser@EXAMPLE.LOCAL # 실습 계정 비밀번호 입력
klist # 받은 TGT·서비스 티켓 확인
kdestroy # 실습 후 티켓 삭제4-5. 트래픽 관찰
sudo tcpdump -ni ens33 'port 88 or port 389 or port 636 or port 464'
sudo ss -tunp | grep -E ':(88|389|636|3268|3269|464)\b'📷 [실습 화면 삽입]
dig SRV결과와ldapsearchRootDSE 조회 결과
📷 [실습 화면 삽입]
kinit후klist출력과 tcpdump에 보이는 88번 포트 통신
5. 결과 확인
klist 출력 형식 예시(값은 환경마다 다름)
Ticket cache: KCM:1000
Default principal: labuser@EXAMPLE.LOCAL
Valid starting Expires Service principal
09/26/2026 14:10:02 09/27/2026 00:10:02 krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCALkrbtgt/... 항목이 TGT입니다. 이후 서비스에 접근하면 HTTP/..., cifs/... 같은 서비스 티켓이 추가됩니다.
| 확인 항목 | 기대 결과 |
|---|---|
| SRV 조회 | 도메인 컨트롤러(또는 IPA 서버) 주소가 반환됨 |
| RootDSE 조회 | namingContexts: dc=example,dc=local 형태 |
| StartTLS/LDAPS | 인증서 검증 후 동일 결과 반환 |
| kinit 이후 | krbtgt TGT 존재, 유효 시간 표시 |
점검 체크리스트
- 클라이언트와 KDC의 시간 차이가 허용 범위 안인가(NTP 동기화 상태)
- LDAP 인증이 평문 Simple Bind가 아니라 StartTLS·LDAPS·SASL로 이뤄지는가
- 익명 Bind로 조회 가능한 범위가 RootDSE 수준으로 제한되는가
- 389·636·88 포트가 내부 대역에서만 접근 가능한가
- 실습 후
kdestroy로 티켓을 정리했는가
6. 패킷 / 로그 분석
6-1. 흔적이 남는 위치
| 환경 | 로그 위치 | 대표 항목 |
|---|---|---|
| Windows AD | 도메인 컨트롤러 보안 이벤트 로그 | 4768(TGT 요청), 4769(서비스 티켓 요청), 4771(Kerberos 사전인증 실패), 4776(NTLM 자격 증명 검증) |
| FreeIPA / MIT KDC | KDC 로그(/var/log/krb5kdc.log 등, 구성에 따라 다름) | AS_REQ, TGS_REQ 처리 결과 |
| OpenLDAP | slapd 로그(syslog/journal, loglevel 설정에 따름) | BIND, SRCH 연산 기록 |
| 리눅스 클라이언트(SSSD) | journalctl -u sssd | 도메인 인증 실패·연결 오류 |
KDC 로그 형식 예시(값은 환경마다 다름)
krb5kdc[1402]: AS_REQ (4 etypes {18 17 20 19}) 192.168.10.50: ISSUE: authtime 1790000000, etypes {rep=18 tkt=18 ses=18}, labuser@EXAMPLE.LOCAL for krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCAL
krb5kdc[1402]: AS_REQ (4 etypes {18 17 20 19}) 192.168.10.51: PREAUTH_FAILED: labuser@EXAMPLE.LOCAL for krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCAL6-2. 정상일 수 있는 경우 vs 의심해야 하는 경우
| 관찰 내용 | 정상일 수 있는 경우 | 의심해야 하는 경우 |
|---|---|---|
| 짧은 시간에 많은 LDAP Search | 인벤토리·동기화 솔루션, 메일 서버의 주소록 조회 | 일반 사용자 PC에서 전체 사용자·그룹·컴퓨터 목록을 연속 조회 |
| 389 평문 Simple Bind | 레거시 장비(프린터·구형 앱)의 설정 | 새로 등장한 호스트에서의 평문 Bind, 여러 계정으로 반복 Bind |
| 4771 사전인증 실패 다수 | 비밀번호 변경 직후 캐시된 옛 비밀번호 | 여러 계정에 대해 소수 비밀번호로 실패(비밀번호 스프레이 패턴) |
| 4769 서비스 티켓 요청 급증 | 로그인 시간대 업무 시작 | 한 계정이 짧은 시간에 다수 SPN 티켓 요청, 약한 암호화 유형(RC4, 0x17) 요청 |
| 88 포트 통신 | 도메인 PC ↔ DC | DC가 아닌 호스트로 향하는 88 트래픽, 외부로 나가는 88·389 트래픽 |
6-3. 확인 명령·필터 예시
# 리눅스 서버에서 인증 인프라로 연결 중인 프로세스 확인
sudo ss -tnp '( dport = :389 or dport = :636 or dport = :88 )'Wireshark에서는 kerberos, ldap 디스플레이 필터로 해당 프로토콜만 볼 수 있지만, 필드 단위 해석(티켓 구조, 암호화 유형 필드 등)은 03. Wireshark 패킷 분석 시리즈에서 다룹니다.
7. 보안관제 관점
- 가장 중요한 데이터 소스는 도메인 컨트롤러(KDC) 로그입니다. 네트워크 패킷보다 "누가, 어떤 계정으로, 어떤 서비스 티켓을" 받았는지가 더 명확하게 남습니다.
- 네트워크에서 볼 수 있는 것: 출발지·목적지·포트, 평문 LDAP이라면 Bind DN과 검색 필터, Kerberos 요청의 계정명·영역(Realm)·암호화 유형. TLS·LDAPS로 보호된 트래픽은 내용 확인이 어렵습니다.
- 한계: 인증 트래픽은 양이 매우 많아 전수 분석보다 기준선(평소 요청량·요청 주체) 대비 이탈을 보는 방식이 현실적입니다.
- 오탐 주의: 계정 잠금·비밀번호 만료 시기, 서비스 계정의 캐시된 자격 증명, 모니터링 솔루션의 대량 조회는 공격 패턴과 매우 비슷해 보입니다. 요청 주체가 어떤 장비인지 자산 정보와 먼저 대조합니다.
- 외부에 389·636·88·3268이 노출되어 있다면 그 자체가 정책 위반 후보입니다(22편에서 정리).
- 계정 기반 공격 탐지 규칙 설계와 상관분석은 07. 네트워크 보안관제 통합 분석 시리즈에서 다룹니다.
8. 핵심 정리
- LDAP은 389(평문/StartTLS)·636(LDAPS)·3268/3269(Global Catalog), Kerberos는 88, 비밀번호 변경은 464를 사용합니다.
- Kerberos 인증에서 서비스 티켓은 88번이 아니라 대상 서비스 프로토콜 안에 실려 가므로 흔적은 여러 포트에 분산됩니다.
- 평문 Simple Bind는 비밀번호 노출 위험이 있으며 StartTLS·LDAPS·SASL로 보호해야 합니다.
- Kerberos는 시간 차이에 민감하므로 NTP 동기화가 인증 인프라의 전제 조건입니다.
- 관제에서는 DC/KDC 로그(4768·4769·4771·4776 등)를 중심으로, 요청 주체와 양의 기준선 이탈을 봅니다.
