소개
이 문서에서는 패킷 레벨에서 NTLM(NT LAN Manager) 인증에 대해 설명합니다.
패킷 레벨에서 NTLM 인증은 어떻게 나타나야 합니까?
이 문서를 따르는 패킷 캡처를 https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zip에서 다운로드할 수 있습니다.
클라이언트 IP: 10.122.142.190
WSA IP: 10.122.144.182
패킷 번호 및 세부사항
#4 클라이언트가 프록시에 GET 요청을 보냅니다.
#7 프록시에서 407을 다시 전송합니다. 이는 적절한 인증이 없어 프록시에서 트래픽을 허용하지 않음을 의미합니다. 이 응답에서 HTTP 헤더를 보면 "Proxy-authenticate: NTLM"이 표시됩니다. 이는 허용되는 인증 방법이 NTLM임을 클라이언트에 알려줍니다. 마찬가지로, "Proxy-authenticate: Basic" 헤더가 있으면 프록시는 기본 자격 증명이 허용됨을 클라이언트에 알립니다. 두 헤더가 모두 있는 경우(공통) 클라이언트는 사용할 인증 방법을 결정합니다.
한 가지 주의할 점은 인증 헤더가 "Proxy-authenticate:"라는 것입니다. 이는 캡처의 연결이 명시적 전달 프록시를 사용하기 때문입니다. 투명 프록시 배포인 경우 응답 코드는 407 대신 401이고 헤더는 "proxy-authenticate:" 대신 "www-authenticate:"입니다.
#8 이 TCP 소켓에서 프록시 FIN을 활성화합니다. 이것은 정확하고 정상적인 것입니다.
#15 새 TCP 소켓에서 클라이언트가 다른 GET 요청을 수행합니다. 이번에는 GET에 HTTP 헤더 "proxy-authorization:"이 포함되어 있음을 확인합니다. 여기에는 사용자/도메인에 대한 세부사항이 포함된 인코딩된 문자열이 포함됩니다.
Proxy-authorization(프록시-권한 부여) > NTLMSSP를 확장하면 NTLM 데이터에서 디코딩된 정보가 전송됩니다. "NTLM Message Type(NTLM 메시지 유형)"에서는 "NTLMSSP_NEGOTIATE"라는 메시지가 표시됩니다. 이는 3방향 NTLM 핸드셰이크의 첫 번째 단계입니다.
#17 프록시가 다른 407로 응답합니다. 다른 "proxy-authenticate" 헤더가 있습니다. 이번에는 NTLM 챌린지 문자열이 포함됩니다. 더 확장하면 NTLM 메시지 유형이 "NTLMSSP_CHALLENGE"로 표시됩니다. 3방향 NTLM 핸드셰이크의 두 번째 단계입니다.
NTLM 인증에서 Windows 도메인 컨트롤러는 챌린지 문자열을 클라이언트에 전송합니다. 그런 다음 클라이언트는 NTLM 챌린지에 알고리즘을 적용하며, 이 과정에서 사용자 비밀번호의 요인이 됩니다. 이렇게 하면 도메인 컨트롤러에서 클라이언트가 비밀번호를 알는지 확인할 수 있습니다. 단, 비밀번호를 회선에 전송하지 않습니다. 이는 모든 스니핑 디바이스에서 볼 수 있도록 비밀번호가 일반 텍스트로 전송되는 기본 자격 증명보다 훨씬 안전합니다.
#18이 최종 GET을 전송합니다. 이 GET은 NTLM 협상 및 NTLM 챌린지가 발생한 것과 동일한 TCP 소켓에 있습니다. 이는 NTLM 프로세스에서 매우 중요합니다. 전체 핸드셰이크는 동일한 TCP 소켓에서 발생해야 합니다. 그렇지 않으면 인증이 유효하지 않습니다.
이 요청에서 클라이언트는 수정된 NTLM 챌린지(NTLM 응답)를 프록시에 전송합니다. 3방향 NTLM 핸드셰이크의 마지막 단계입니다.
#21 프록시에서 HTTP 응답을 다시 전송합니다. 이는 프록시가 자격 증명을 수락했으며 콘텐츠를 제공하기로 결정했음을 의미합니다.
피드백