SMB 서명과 LDAP 채널 바인딩 ── NTLM 대책의 '나머지 절반'을 실무에서 마무리하기

‘NTLM 감사를 시작했다. IP 주소 직접 입력도 고치고 있다. 그렇다면 의존을 전부 없애기 전까지, 릴레이 공격에 대한 대비는 어떻게 해야 하는가’──지난 글 ‘NTLM 폐지로 업무 앱이 멈추는가‘를 공개한 뒤, 가장 많이 받은 질문이 이것이었습니다.

그 답이 이번에 다룰 SMB 서명과 LDAP 서명·LDAP 채널 바인딩입니다. 둘 다 ‘NTLM을 그만두는’ 대책이 아니라, ‘NTLM이 남아 있는 동안에도 훔친 인증 정보를 가로채 다른 곳으로 흘려보내는 공격(릴레이 공격)을 성립시키지 않기’ 위한 방어입니다. 그리고 한쪽인 SMB 서명은 Windows 11 24H2 / Windows Server 2025에서 기본값이 실제로 바뀌었기 때문에, 아무것도 하지 않아도 OS 업데이트와 함께 찾아옵니다. 다른 한쪽인 LDAP 서명·채널 바인딩은 기본값 자체는 바뀌지 않았지만, 관리자가 조이지 않는 한 계속 느슨한 상태로 남습니다. 즉 SMB는 ‘미리 대비할 것인가, OS 업데이트로 사고가 난 뒤 대응할 것인가’의 문제이고, LDAP는 ‘언제 스스로 조일 것인가’의 문제입니다.

이 글은 NTLM 시리즈의 세 번째 글입니다. NTLM 감사 절차는 1편, 프로토콜의 구조는 2편에 정리해 두었습니다.

1. 먼저 결론

• SMB 서명은 모든 SMB 메시지에 변조 탐지용 서명을 붙이는 방식입니다. 서명에는 메시지 전체의 해시와 송신자·수신자의 신원이 포함되며, 릴레이 공격·스푸핑 공격에 대한 방어가 됩니다.¹
• 기본값은 이미 바뀌었습니다. Windows 11 버전 24H2의 Enterprise·Pro·Education은 송신·수신 양쪽 모두 서명 필수이고, Windows Server 2025는 송신만 필수가 기본값입니다(Home은 둘 다 필수가 아닙니다).²
• 서명 필수화는 게스트 액세스 비활성화와 세트입니다. 서명을 지원하지 않는 NAS나 게스트 접속을 전제로 하는 기기는 OS 업데이트 시점에 접속 오류가 발생합니다. 오류 코드는 0xc000a000(STATUS_INVALID_SIGNATURE)이나 게스트 차단 메시지입니다(4.3절).²
• LDAP 서명은 도메인 컨트롤러가 ‘서명을 요구하지 않는 SASL 바인드’와 ‘평문 단순 바인드’를 거부할 수 있게 하는 방식입니다. 서명되지 않은 LDAP 트래픽은 재전송 공격·중간자 공격에 취약하기 때문입니다.³
• LDAP 채널 바인딩은 LDAPS(SSL/TLS) 위에서 이루어지는 Windows 인증(SASL 바인드)을 TLS 채널에 결합하는 방식입니다. 이 결합에 사용하는 값을 채널 바인딩 토큰(CBT)이라고 부릅니다. CBT를 갖지 않는 단순 바인드는 검증 대상이 아닙니다(6장). 레지스트리 값 LdapEnforceChannelBinding(0/1/2) 또는 그룹 정책으로 제어합니다.⁴
• 둘 다 ‘감사 이벤트 확인 → 접속 지점 수정 → 강제로 전환’의 3단계로 진행합니다. LDAP 서명은 이벤트 2887·2889로, 채널 바인딩은 이벤트 3039·3040과 감사 이벤트 3074·3075로 접속 지점을 특정할 수 있습니다(5장·6장).³⁴
• 중요한 전제로, 이 업데이트들은 기본값을 함부로 바꾸지 않습니다. 마이크로소프트는 2020년 3월 이후의 일련의 LDAP 업데이트에 대해 ‘LDAP 서명·채널 바인딩의 기본 정책은 변경하지 않는다’고 명시하고 있습니다. 조이는 것은 관리자의 몫입니다.⁴

2. 왜 서명인가 ── 릴레이 공격의 ‘나머지 절반’

2편에서 썼듯이, NTLM의 근본적인 약점은 상호 인증이 없다는 점입니다. 클라이언트는 서버의 신원을 검증할 수 없기 때문에, 공격자는 ‘진짜 서버인 척’하며 클라이언트에게 인증을 시키고, 받은 인증 응답을 그대로 진짜 서버로 흘려보낼 수 있습니다. 이것이 릴레이 공격이며, 마이크로소프트 스스로도 NTLM 및 NTLMv2 인증이 SMB 릴레이·중간자 공격에 취약하다고 명시하고 있습니다.⁵

NTLM을 완전히 멈추면 이 공격은 성립하지 않게 되지만, 1편에서 살펴봤듯이 의존 관계를 찾아내고 고치는 데는 몇 달 단위의 시간이 걸립니다. 그동안의 방어가 서명입니다.

flowchart LR
    CL["클라이언트"]
    AT["공격자<br/>가짜 서버"]
    SV["진짜 서버"]

    CL -->|"① 인증 응답"| AT
    AT -->|"② 그대로 중계"| SV
    SV -.->|"③ 서명이 필수라면, 세션 키가 없는 공격자는<br/>올바른 서명을 만들지 못해 실패"| AT

그림 1: 릴레이 공격과 SMB 서명의 관계

핵심은 서명의 열쇠(세션 키)를 인증의 결과로 클라이언트와 진짜 서버만이 갖는다는 점입니다. 인증 응답을 중계했을 뿐인 공격자는 세션 키를 갖고 있지 않으므로, 서명이 필수인 환경에서는 이후의 메시지를 위조할 수 없습니다. SMB 서명은 SMB로의 릴레이를, LDAP 서명과 채널 바인딩은 도메인 컨트롤러의 LDAP/LDAPS로의 릴레이를 각각 막습니다.

실무적으로 주의할 점이 하나 더 있습니다. 서명의 효과는 인증 프로토콜의 선택과 무관하지 않습니다. 세션 키는 비밀번호에서 파생되므로, Kerberos가 아니라 NTLMv2로 인증하고 있으면 서명의 기반이 되는 키가 약해집니다. 마이크로소프트도 SMB 서명의 효과를 최대화하는 조건으로 Kerberos를 사용할 것, IP 주소나 CNAME으로 공유에 접속하지 않을 것을 들고 있습니다.¹ IP 주소나, 대응하는 SPN이 등록되어 있지 않은 별칭으로 접속하면 Kerberos가 아니라 NTLM이 사용되기 때문입니다(별칭을 계속 사용하고 싶은 경우의 SPN 등록은 1편에서 다루고 있습니다). 즉 NTLM 의존 축소와 서명 필수화는 별개의 대책이 아니라 같은 대책의 두 축입니다.

3. SMB 서명 ── 구조와, 이미 바뀐 기본값

3.1. 구조를 1분 만에

SMB 서명은 세션 키와 암호 스위트를 사용해 연결을 흐르는 각 메시지에 서명을 붙입니다. 서명에는 SMB 헤더 안에 메시지 전체의 해시가 포함되며, 도중에 변조되면 해시가 일치하지 않게 됩니다. 해시에는 송신자와 수신자의 신원도 포함되므로 스푸핑도 탐지할 수 있습니다.¹

알고리즘은 세대가 바뀔 때마다 강화되어 왔습니다. SMB1은 MD5였지만 SMB 2.02에서 HMAC-SHA-256으로, SMB 3.0에서 AES-CMAC으로 바뀌었고, Windows Server 2022와 Windows 11에서는 AES-128-GMAC에 의한 서명 가속이 도입되었습니다.¹ ‘서명 = 느리다’는 인상이 SMB1 시절의 기억이라면, 일단 잊고 다시 실측해 볼 가치가 있습니다.

설정은 ‘활성화/비활성화’가 아니라 ‘필수(Require)인지 아닌지‘로 생각해야 합니다. SMB 2.x 이후에서는 EnableSecuritySignature 설정은 무시되며, 의미를 갖는 것은 RequireSecuritySignature뿐입니다. 그리고 클라이언트와 서버 중 어느 한쪽이라도 필수로 설정되어 있으면 해당 연결은 서명됩니다. 서명되지 않는 것은 양쪽 모두 필수로 설정되어 있지 않은 경우뿐입니다.¹

3.2. 기본값 판단표

이 표를 전부 읽을 필요는 없습니다. 먼저 자사의 단말과 서버의 OS와 에디션을 확인하고, 자신이 해당하는 행만 읽으십시오. 에디션과 버전은 ‘설정 > 시스템 > 정보’에서 확인할 수 있습니다(‘에디션’이 Pro/Home/Enterprise/Education 등, ‘버전’이 24H2 등으로 표시됩니다).

위쪽 3행은 마이크로소프트 문서에 명시된 기본값입니다.² 맨 아래 행은 예전부터의 동작으로, 도메인 컨트롤러는 접속해 오는 모든 상대에게 SMB 서명을 요구합니다. 그룹 정책이나 로그온 스크립트 배포는 계속 서명을 전제로 동작해 왔습니다.¹

Home 에디션만은 이번 기본값 변경의 대상이 아닙니다. 송신·수신 어느 쪽도 필수가 되지 않으므로, 24H2로 업데이트해도 Home 단말에서는 서명 필수로 인한 접속 오류가 발생하지 않습니다(향후 변경까지 보장되는 것은 아니지만, 적어도 24H2 시점의 ‘마감’에는 포함되지 않습니다).² 뒤집어 말하면, 같은 24H2라도 에디션에 따라 동작이 갈린다는 뜻입니다. ‘업데이트했더니 공유에 연결되지 않는다’는 신고를 분류할 때는 버전뿐 아니라 에디션부터 먼저 확인하십시오.

이 표가 실무적으로 의미하는 바는 이렇습니다. Windows 11 24H2(Enterprise·Pro·Education)로의 업데이트는 해당 PC에서 나가는 모든 SMB 연결을 서명 필수로 바꿉니다(Home은 대상이 아닙니다). 사내 파일 서버가 Windows라면 아무 일도 일어나지 않습니다(Windows는 모든 버전에서 서명을 지원하기 때문입니다). 사고가 나는 것은 서명을 지원하지 않거나 비활성화한 서드파티 기기, 즉 오래된 NAS, 복합기의 스캔 저장 위치 설정, 임베디드 리눅스의 Samba 등이 상대일 때입니다.

4. SMB 서명을 ‘필수’로 진행하는 절차

4.1. 현재 상태 확인하기

# 클라이언트 측(송신)의 서명 요구
Get-SmbClientConfiguration | FL RequireSecuritySignature

# 서버 측(수신)의 서명 요구
Get-SmbServerConfiguration | FL RequireSecuritySignature

True면 필수, False면 필수가 아닌 상태입니다.² 그룹 정책으로 관리하는 경우의 위치는 컴퓨터 구성\Windows 설정\보안 설정\로컬 정책\보안 옵션의 ‘Microsoft 네트워크 클라이언트: 통신에 항상 디지털 서명‘(클라이언트)과 ‘Microsoft 네트워크 서버: 통신에 항상 디지털 서명‘(서버)입니다. 정책 이름의 ‘항상(always)’이 ‘필수’를 의미합니다.¹

4.2. 먼저 ‘서명할 수 없는 상대’를 찾아내기(감사)

Windows 11 버전 24H2 이후에서는 서명이나 암호화를 지원하지 않는 서드파티 클라이언트·서버를 검출하는 감사를 활성화할 수 있습니다.¹

# 서버 측: 서명을 지원하지 않는 클라이언트를 검출한다
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# 클라이언트 측: 서명을 지원하지 않는 서버를 검출한다
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

같은 방식으로 암호화를 지원하지 않는 상대를 검출하는 감사(-AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption)도 있지만,¹ 이는 향후 SMB 암호화를 필수화할 때를 위한 준비이며, 서명 로드맵과는 별개의 트랙입니다. 서명은 지원하지만 암호화는 지원하지 않는 기기도 드물지 않으므로, 서명 완료 여부를 판단할 때 암호화 감사 이벤트를 섞지 마십시오.

기록 위치는 다음과 같습니다.¹

이벤트를 확인하는 절차는 다음 3가지입니다.

1. eventvwr.msc로 이벤트 뷰어를 열고, 왼쪽 트리에서 이벤트 뷰어 > 응용 프로그램 및 서비스 로그 > Microsoft > Windows > SMBClient > Audit을 엽니다(서버 측을 볼 때는 같은 계층의 SMBServer > Audit).
2. 오른쪽 창에서 ‘현재 로그 필터링’을 선택하고, ‘모든 이벤트 ID’ 항목에 31998,31999(서버 측은 3021,3022)를 입력합니다.
3. 남은 이벤트를 열면 서명을 지원하지 않았던 상대의 정보가 기록되어 있습니다. 이를 기기 목록으로 정리해 나갑니다.

PowerShell로 한꺼번에 가져오려면 다음과 같습니다.

# 클라이언트 측: 서명을 지원하지 않는 서버를 검출한 감사 이벤트
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# 서버 측: 서명을 지원하지 않는 클라이언트를 검출한 감사 이벤트
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

감사를 활성화한 직후여서 기록이 하나도 없는 경우, Get-WinEvent는 해당 이벤트가 없다는 오류를 반환합니다(위에서 -ErrorAction SilentlyContinue를 붙인 것은 이 때문입니다). 필터링 작성법은 ‘Get-WinEvent로 이벤트 로그를 실무적으로 조사하기‘에 정리해 두었습니다.

그룹 정책에서는 컴퓨터 구성\관리 템플릿\네트워크 아래의 Lanman Server / Lanman Workstation에 있는 ‘Audit client does not support signing’ 등이 대응합니다.¹ 1편에서 쓴 감사 기간에 대한 사고방식(업무가 한 바퀴 돌 때까지 돌린다)은 여기서도 그대로 적용됩니다.

4.3. 사고 패턴 파악해 두기

서명이 필수인 환경에서 서명할 수 없는 상대에 접속하면 다음과 같은 오류가 발생합니다.²

0xc000a000
STATUS_INVALID_SIGNATURE
암호화된 서명이 잘못되었습니다.

또 하나, 놓치기 쉬운 것이 게스트 액세스입니다. 서명 필수화는 게스트 액세스 비활성화도 동반합니다. 인증 없이(게스트로) 접근하게 설정된 NAS에 접속하면 다음과 같은 오류가 발생합니다.²

조직의 보안 정책으로 인해 인증되지 않은 게스트 액세스가
차단되어 이 공유 폴더에 액세스할 수 없습니다.

대처의 우선순위는 명확합니다. 첫 번째는 기기 쪽에서 SMB 서명을 활성화하고, 게스트가 아니라 자격 증명으로 인증하게 하는 것입니다. 클라이언트 측에서 Set-SmbClientConfiguration -RequireSecuritySignature $false로 설정하면 서명 오류(0xc000a000) 쪽은 회피할 수 있지만, 게스트 차단은 서명과는 별개의 클라이언트 설정(안전하지 않은 게스트 로그온 금지)에 의한 것이라 서명을 완화하는 것만으로는 해결되지 않습니다. 마이크로소프트는 서드파티 기기에 대한 회피책으로 서명을 비활성화하는 것도, 게스트 계정으로 서명을 사용하려는 것도 권장하지 않습니다.² 완화할 경우에는 ‘해당 기기를 교체할 때까지의, 기한을 정한 예외’로 취급하십시오.

4.4. 배포 순서

또한 24H2 이후 단말이 늘어날수록 ‘클라이언트 측이 기본적으로 필수’가 되어 가므로, 실질적인 마감은 OS 업데이트 계획이 정합니다. Windows 10 지원 종료 대응으로 Windows 11 24H2 이후로 이행 중인 조직은 이 검증을 이행의 전제 작업에 포함시키십시오(‘Windows 10 지원 종료의 선택지’).

5. LDAP 서명 ── 도메인 컨트롤러로 가는 경로를 지키기

이 장과 다음 장에서는 ‘바인드’의 종류가 이야기의 축이 되므로, 먼저 두 가지 용어만 확인해 둡니다.

즉 ‘LDAP 서명을 필수로 한다’는 것은 SASL 바인드에는 서명을 요구하고, 평문 연결의 단순 바인드는 거부한다는 뜻입니다.

SMB 다음은 LDAP입니다. 도메인 컨트롤러(및 AD LDS)로 향하는 서명되지 않은 LDAP 트래픽은 재전송 공격이나 중간자 공격에 취약합니다. 공격자가 가로채거나 변조한 패킷을 서버로 전달하면, 서버가 위조된 요청을 근거로 판단을 내릴 우려가 있습니다.³

LDAP 서명 강제란 디렉터리 서버가 다음 두 종류의 바인드를 거부하게 하는 것입니다.³

1. 서명(무결성 검증)을 요구하지 않는 SASL 바인드(SASL에는 Negotiate, Kerberos, NTLM, Digest가 포함됩니다)
2. 평문(비 SSL/TLS) 연결로 이루어지는 단순 바인드

5.1. 이벤트 ID 조견표(LDAP 서명·채널 바인딩 공통)

이 장과 6장에 나오는 이벤트 ID를 먼저 정리합니다. 모두 도메인 컨트롤러의 ‘Directory Service’ 로그(이벤트 뷰어 > 응용 프로그램 및 서비스 로그 > Directory Service)에 기록됩니다. 이 표만 보고도 감사 설계를 바로 세울 수 있도록 정리했습니다.

구분해서 사용하는 방법은 단순합니다. ‘아직 몇 건 남아 있는가’를 보는 것이 집계 이벤트(2887·3040), ‘어디서 오는가’를 보는 것이 개별 이벤트(2889·3039·3074·3075)입니다. 건수가 0이 되지 않는 한 강제로는 진행하지 않습니다. 이후 5.2절에서 LDAP 서명 쪽을, 6장에서 채널 바인딩 쪽을 자세히 살펴봅니다.

5.2. 먼저 감사 ── 이벤트 2886/2887/2889

도메인 컨트롤러의 Directory Service 로그에는 처음부터 단서가 나와 있습니다. 5.1절 조견표 가운데 LDAP 서명과 관련된 것은 2886·2887·2888·2889의 4가지이며, 이 가운데 2887이 ‘미서명 바인드가 아직 몇 건 있는가’를, 2889가 ‘그것이 어디서 오는가’를 나타냅니다(2888은 거부를 구성한 뒤의 집계입니다).³

2889만은 기본적으로 나오지 않습니다. 진단 설정 ‘16 LDAP Interface Events‘를 2(Basic)로 올리면 기록되게 됩니다.³ 절차는 먼저 2887의 집계로 ‘애초에 미서명 바인드가 몇 건인가’를 확인하고, 0이 아니면 2889를 활성화해 접속 지점을 특정하는 흐름입니다. 주의할 점은 2889가 집계가 아니라 해당 바인드가 발생할 때마다 기록되므로, 레거시 바인드가 높은 빈도로 남아 있는 환경에서는 Directory Service 로그를 단숨에 채워 버립니다. 접속 지점 특정이 끝나면 진단 설정을 원래 레벨(기본값은 0)로 되돌리십시오. 계속 켜 둘 생각이라면 로그 전달과 보존 확보가 먼저입니다.

접속 지점의 전형은 LDAP와 연동하는 업무 시스템(인증 연동, 인사 시스템 연동), 복합기의 LDAP 주소록 검색, 네트워크 기기의 LDAP 인증입니다. 특히 복합기·기기류의 ‘LDAP 서버 설정’은 평문 단순 바인드로 되어 있는 경우가 많으므로 가장 먼저 의심하십시오. 수정 방법은 기기·앱 쪽 설정을 LDAPS(636번)나 서명된 SASL 바인드로 전환하는 것입니다.

5.3. 강제 적용하기

접속 지점을 모두 고쳤다면 그룹 정책으로 강제 적용합니다.³

• 도메인 컨트롤러 측: Default Domain Controller Policy의 보안 옵션에 있는 ‘도메인 컨트롤러: LDAP 서버 서명 요구사항‘을 ‘서명 필요’로 설정
• 클라이언트 측: ‘네트워크 보안: LDAP 클라이언트 서명 요구사항‘을 ‘서명 필요’로 설정

확인은 ldp.exe로 할 수 있습니다. 389번 포트에 접속해 단순 바인드를 시도했을 때 다음과 같은 오류가 나면 구성이 적용된 것입니다.³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAP 채널 바인딩 ── LDAPS 쪽의 방어

‘우리는 LDAPS를 쓰고 있으니 괜찮다’──여기에 남는 구멍을 막는 것이 채널 바인딩입니다. LDAPS는 통신을 암호화하지만, 그것만으로는 ‘클라이언트에게 인증을 시키고, 그 인증 정보를 공격자 자신의 다른 TLS 연결로 중계하는’ 형태의 릴레이를 완전히 막을 수 없습니다. 채널 바인딩 토큰(CBT)은 인증을 그 TLS 채널 자체에 결합함으로써 다른 채널로의 중계를 탐지할 수 있게 합니다.

대상을 정확히 말하면 LDAPS 위에서 NTLM이나 Kerberos 등 Windows 인증(SASL 바인드)을 수행하는 연결입니다. 단순 바인드는 애초에 CBT를 갖지 않으므로 이 검증의 대상이 아닙니다. LDAPS 위의 단순 바인드를 지키는 것은 TLS 암호화와 자격 증명 관리 그 자체이며, Always로 설정해도 단순 바인드 클라이언트가 CBT 감사 이벤트에 나타나는 일은 없습니다.

제어는 도메인 컨트롤러의 레지스트리 값이나 그에 대응하는 그룹 정책으로 수행합니다.⁴

감사에 사용하는 이벤트는 다음과 같습니다(5.1절 조견표의 채널 바인딩 부분을 내용까지 풀어 쓴 것입니다). 2020년 3월 10일 업데이트로 채널 바인딩 관련 이벤트가 추가되었고, 이후 2023년 이후 업데이트에서 감사 이벤트가 확충되었습니다.⁴

진행 방식은 LDAP 서명과 같으며, 마이크로소프트의 안내도 ‘모든 도메인 컨트롤러의 Directory Service 로그에서 서명 실패의 2889, 채널 바인딩 실패의 3039, 감사 이벤트인 3074·3075를 모니터링하여 문제가 있는 기기를 특정하고, 공급업체에 확인해 대응을 검증한 뒤 강제 적용한다’는 것입니다.⁴

한 가지 강조해 두고 싶은 것은 마이크로소프트가 이 업데이트들로 기본값을 바꾸지 않았다는 점입니다. 2020년 3월 10일 업데이트 및 당분간의 업데이트는 LDAP 서명·LDAP 채널 바인딩의 기본 정책을 변경하지 않는다고 명시되어 있습니다.⁴ SMB 서명(24H2에서 기본값이 바뀐)과는 대조적으로, LDAP 쪽은 관리자가 스스로 조이지 않는 한 계속 느슨한 상태로 남습니다. 뒤집어 말하면, 조이는 시점을 스스로 선택할 수 있는 동안 계획적으로 진행할 수 있습니다.

7. 업무 앱과 기기 고치는 법(판단표)

감사에서 발견된 접속 지점을 원인별로 정리합니다.

자체 개발한 .NET 앱에서 LDAP를 다루고 있다면, 가장 먼저 의심할 것은 ‘단순 바인드를 평문으로 보내고 있지 않은가’입니다.

// 나쁜 예: 평문 389번으로의 단순 바인드. LDAP 서명을 강제하면 거부된다
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

// 좋은 예1: Negotiate+서명·암호화를 요구한다(Kerberos는 SPN과 이름 해석이 갖춰지면 선택된다)
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind();  // 실행 중인 계정으로 인증

// 좋은 예2: 단순 바인드를 사용한다면 반드시 LDAPS로 한다
var id = new LdapDirectoryIdentifier("dc01.corp.example.com", 636);
var conn2 = new LdapConnection(id);
conn2.SessionOptions.SecureSocketLayer = true;
conn2.AuthType = AuthType.Basic;
conn2.Bind(new NetworkCredential(user, password));

좋은 예1의 Negotiate는 Kerberos를 우선하지만 강제하지는 않습니다. 접속 대상이 IP 주소이거나 SPN이 미등록·중복되어 있으면 조용히 NTLM으로 폴백합니다(그 경우에도 서명·암호화 요구 자체는 유효합니다). Kerberos로 인증되고 있는지는 klist로 해당 서비스의 티켓이 발급되어 있는지 확인하는 것이 확실합니다. 1편의 NTLM 감사(송신 NTLM 트래픽 = 모두 감사)를 활성화한 환경이라면, 이벤트 8001이 발생하지 않는 것도 방증이 됩니다. 감사 정책이 비활성화된 채라면 ‘8001이 발생하지 않는다’는 것에 의미가 없다는 점에 주의하십시오. 참고로 좋은 예2의 단순 바인드는 TLS로 암호화되지만, 6장에서 설명했듯이 CBT 검증의 대상이 되는 것은 Windows 인증 쪽입니다. 도메인 환경에서 선택할 수 있다면 좋은 예1을 기본으로 하십시오. DirectoryEntry(ADSI) 경유라면 AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing을 명시하는 것이 확실합니다. NTLM 시리즈 1편에서 쓴 원칙(접속 대상은 IP 주소가 아니라 FQDN으로 적는다)은 Kerberos에 의한 SASL 바인드를 성립시키기 위한 전제로서 여기서도 유효합니다.

8. 정리

• SMB 서명과 LDAP 서명·채널 바인딩은 NTLM 의존을 다 없앨 때까지도 릴레이 공격을 성립시키지 않기 위한 방어이며, 동시에 NTLM 폐지 이후에도 남겨 둘 영구적인 강화책입니다(서명의 변조 탐지와 채널 바인딩은 Kerberos 인증 세션에도 유효합니다). NTLM 축소와 같은 대책의 두 축으로 진행합니다.¹⁵
• SMB 서명의 기본값은 이미 바뀌었습니다. Windows 11 24H2(Enterprise/Pro/Education)는 송수신 모두 필수, Windows Server 2025는 송신 필수입니다. OS 업데이트 계획이 그대로 마감이 됩니다.²
• 사고 패턴은 정해져 있습니다. 서명 미지원 기기의 0xc000a000과 게스트 액세스 차단입니다. 24H2 이후의 감사 기능으로 미리 찾아낼 수 있습니다.²¹
• LDAP는 이벤트 2887·2889(서명), 3039·3040·3074·3075(채널 바인딩)로 접속 지점을 특정하고, 고친 뒤 강제 적용합니다.³⁴
• LDAP 쪽의 기본값은 업데이트로는 바뀌지 않습니다. 관리자가 조이지 않는 한 느슨한 상태로 남습니다. 계획적으로 진행할 수 있을 때 진행하십시오.⁴
• 자체 앱은 ‘평문 단순 바인드’와 ‘IP 주소 직접 입력’을 없애면 대부분 해결됩니다.

관련 글

• NTLM 폐지로 업무 앱이 멈추는가 ── 감사 로그를 얻는 방법과 의존을 없애는 순서
• 그림으로 이해하는 NTLM과 Kerberos ── 왜 인증은 NTLM으로 ‘떨어지는가’
• 네트워크 드라이브와 UNC 경로의 함정 ── 업무 앱에서 파일 서버(공유 폴더)를 다루는 실무
• Get-WinEvent로 이벤트 로그를 실무적으로 조사하기 ── 필터링 속도가 조사 시간을 좌우한다
• Windows 10 지원 종료 이후의 현실적 해법 ── ESU·LTSC·교체 판단표
• Windows 앱 개발에서 최저한의 보안을 지키기 위한 체크리스트

관련 상담 영역

합동회사 코무라소프트에서는 SMB 서명·LDAP 서명 강제 적용에 따른 업무 앱 개선, 인증·파일 공유 관련 접속 장애 조사를 다루고 있습니다.

• Windows 앱 개발
• 결함 조사·원인 분석
• 기존 자산 활용·이행 지원
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

SMB 서명을 필수로 하면 파일 서버가 느려지지 않나요?

서명의 계산 비용이 전혀 없는 것은 아니지만, 알고리즘은 세대마다 개선되고 있습니다. SMB1의 MD5에 비해 SMB 2.02에서는 HMAC-SHA-256, SMB 3.0에서는 AES-CMAC으로 바뀌었고, Windows Server 2022와 Windows 11에서는 AES-128-GMAC에 의한 서명 고속화가 도입되었습니다. 또한 도메인 컨트롤러는 예전부터 SYSVOL과 NETLOGON에 접속하는 모든 상대에게 SMB 서명을 요구해 왔으며, 그룹 정책 배포는 계속 서명을 전제로 동작해 왔습니다. 성능을 이유로 미루기 전에, 먼저 파일럿 단말에서 필수화하여 실측해 볼 것을 권합니다. 체감할 수 있는 차이가 나타나는 것은 대용량 파일을 연속으로 전송하는 등의 특정한 사용 방식에 치우쳐 있습니다.

Windows 11 24H2로 바꿨더니 NAS에 연결되지 않게 되었습니다. SMB 서명이 원인인가요?

전형적으로는 그것이 원인입니다. Windows 11 버전 24H2의 Enterprise·Pro·Education은 송신·수신 양쪽 모두 SMB 서명이 기본값으로 필수가 되었기 때문에, 서명을 지원하지 않는(또는 비활성화한) 서드파티 NAS에 접속하면 0xc000a000(STATUS_INVALID_SIGNATURE)으로 실패합니다. 또한 서명 필수화는 게스트 액세스 비활성화도 동반하므로, 인증 없이 사용하도록 설정된 NAS에서는 '조직의 보안 정책으로 인해 인증되지 않은 게스트 액세스가 차단되므로'라는 오류가 발생합니다. 첫 번째 대처는 NAS 쪽에서 SMB 서명을 활성화하고 게스트가 아니라 자격 증명으로 접속하는 것입니다. 클라이언트 쪽에서 서명 요구를 비활성화하는 회피책도 있지만, 그것으로 해소되는 것은 서명 오류 쪽뿐입니다. 게스트 접속 차단은 서명과는 별개의 클라이언트 설정(안전하지 않은 게스트 로그온 금지)에 의한 것이라, 그쪽까지 완화하지 않는 한 계속 실패합니다. 마이크로소프트는 서명 비활성화도 게스트 운영도 권장하지 않습니다.

LDAP 서명과 LDAPS(LDAP over SSL/TLS)는 무엇이 다른가요?

서로 다른 것입니다. LDAP 서명은 389번 포트의 LDAP 연결 위에서 이루어지는 SASL 바인드(Negotiate, Kerberos, NTLM, Digest)에 무결성 검증(서명)을 요구하는 방식으로, 통신 자체를 암호화하지는 않습니다. LDAPS는 연결 전체를 SSL/TLS로 암호화하는 방식입니다. 그리고 LDAP 채널 바인딩은 LDAPS보다 한층 더 위의 방어로, 인증과 TLS 채널을 결합함으로써 '인증 정보만을 다른 TLS 연결로 중계하는' 공격을 막습니다. 도메인 컨트롤러를 지키려면 평문 단순 바인드를 중단시키고, SASL 바인드에는 서명을 요구하며, LDAPS 위의 Windows 인증(SASL 바인드)에는 채널 바인딩 토큰 검증을 요구한다는 3가지 세트로 생각하십시오. 참고로 CBT를 갖지 않는 단순 바인드는 채널 바인딩 검증의 대상이 아니며, LDAPS 위의 단순 바인드를 지키는 것은 TLS 암호화 그 자체입니다.

어떤 순서로 조여 나가면 되나요?

감사→수정→강제의 순서는 NTLM 제한 때와 같습니다. 먼저 SMB는 Windows 11 24H2 이후에서 사용할 수 있는, 서명을 지원하지 않는 상대를 검출하는 감사를 활성화하여 서명할 수 없는 기기를 찾아냅니다. LDAP는 도메인 컨트롤러의 Directory Service 로그에서 이벤트 2887(24시간마다의 미서명 바인드 집계)을 확인하고, 건수가 나온다면 진단 설정 '16 LDAP Interface Events'를 2로 설정하여 이벤트 2889로 클라이언트를 특정합니다. 채널 바인딩은 이벤트 3039·3040과, 2023년 이후 업데이트로 추가된 감사 이벤트 3074·3075로 마찬가지로 찾아냅니다. 문제가 있는 접속 지점을 모두 고친 뒤, SMB 서명 필수화, LDAP 서명 필수화, 채널 바인딩의 Always로 전환합니다. 갑자기 강제로 몰아가지 않는 것이 유일한 원칙입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.