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장).³⁴
• 중요한 전제로, 이러한 업데이트는 기본값을 제멋대로 바꾸지 않습니다. Microsoft는 2020년 3월 이후의 일련의 LDAP 업데이트에 대해 「LDAP 서명·채널 바인딩의 기본 정책은 변경하지 않는다」고 명시하고 있습니다. 조이는 것은 관리자의 일입니다.⁴

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 28건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 왜 서명인가 ── 릴레이 공격의 「남은 절반」

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

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

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

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

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

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

실무에서 하나 더 주의할 점이 있습니다. 서명의 효과는 인증 프로토콜 선택과 독립이 아닙니다. 세션 키는 암호에서 나오므로, Kerberos가 아니라 NTLMv2로 인증하면 서명의 토대가 되는 키가 약해집니다. Microsoft도 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행은 Microsoft 문서에 명시된 기본값입니다.² 맨 아래 행은 예전부터의 동작으로, 도메인 컨트롤러는 연결해 오는 모든 상대에게 SMB 서명을 요구합니다. 그룹 정책이나 로그온 스크립트 배포는 줄곧 서명을 전제로 동작해 왔습니다.¹

Home 에디션만은 이 기본값 변경의 대상이 아닙니다. 송신·수신 어느 쪽도 필수가 되지 않으므로, 24H2로 올려도 Home 단말에서는 서명 필수로 인한 연결 오류가 나지 않습니다(이후 변경까지 보장되는 것은 아니지만, 적어도 24H2 시점의 「마감」에는 들어가지 않습니다).² 반대로 말하면, 같은 24H2라도 에디션에 따라 동작이 갈립니다. 「업데이트했더니 공유에 연결되지 않는다」는 신고를 가를 때는 버전뿐 아니라 에디션을 맨 먼저 확인하십시오.

이 표의 실무적 의미는 이렇습니다. Windows 11 24H2(Enterprise·Pro·Education)로의 업데이트는 그 PC에서 나가는 모든 SMB 연결을 서명 필수로 바꿉니다(Home은 대상이 아닙니다). 사내 파일 서버가 Windows라면 아무 일도 없습니다(Windows는 모든 버전에서 서명을 지원하기 때문입니다). 사고가 나는 것은 서명을 지원하지 않거나 꺼 둔 서드파티 장비, 즉 오래된 NAS, 복합기의 스캔 저장 설정, 임베디드 Linux의 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 암호화를 필수로 할 때의 준비이며, 서명의 로드맵과는 다른 트랙입니다. 서명은 지원해도 암호화는 지원하지 않는 장비가 드물지 않으므로, 서명 완료 판단에 암호화 감사 이벤트를 섞지 마십시오.

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

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

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) 쪽은 피할 수 있지만, 게스트 차단은 서명과 별개의 클라이언트 설정(안전하지 않은 게스트 로그온 금지)에 의한 것이라 서명만 느슨하게 해서는 해소되지 않습니다. Microsoft는 서드파티 장비에 대한 우회로 서명을 끄는 것도, 게스트 계정으로 서명을 쓰려는 것도 권장하지 않습니다.² 완화할 때는 「그 장비를 교체할 때까지의, 기한을 둔 예외」로 다루십시오.

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 네 가지이며, 이 중 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 서명과 같고, Microsoft의 안내도 「모든 도메인 컨트롤러의 Directory Service 로그에서 서명 실패의 2889, 채널 바인딩 실패의 3039, 감사 이벤트 3074·3075를 감시하고, 문제 있는 장비를 특정해 제공처에 확인하고, 대응을 확인한 뒤에 강제한다」는 것입니다.⁴

한 가지 강조하고 싶은 것은, Microsoft는 이러한 업데이트로 기본값을 바꾸지 않았다는 점입니다. 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 서명을 켜고, 게스트가 아니라 자격 증명으로 연결하는 것입니다. 클라이언트에서 서명 요구를 끄는 우회도 있지만, 그것으로 해소되는 것은 서명 오류 쪽뿐입니다. 게스트 연결 차단은 서명과 별개의 클라이언트 설정(안전하지 않은 게스트 로그온 금지) 때문이라, 그쪽까지 느슨하게 하지 않는 한 계속 실패합니다. Microsoft는 서명을 끄는 것도 게스트로 운영하는 것도 권장하지 않습니다.

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