다음을 통해 공유

WinRM을 사용하는 PowerShell Remoting의 보안 고려 사항

  • 아티클

PowerShell 원격은 Windows 시스템을 관리하는 데 권장되는 방법입니다. PowerShell 원격은 Windows Server 2012 R2 이상에서 기본적으로 사용하도록 설정됩니다. 이 문서에서는 PowerShell 원격을 사용할 때의 보안 문제, 권장 사항, 모범 사례 등을 설명합니다.

PowerShell 원격이란?

PowerShell 원격은 WinRM(Windows 원격 관리)을 사용하여 사용자가 원격 컴퓨터에서 PowerShell 명령을 실행할 수 있도록 합니다. WinRM은 WS-Management(Web Services for Management) 프로토콜의 Microsoft 구현입니다. 원격 명령 실행 시 PowerShell 원격 사용에 대한 자세한 정보를 찾을 수 있습니다.

PowerShell 원격은 cmdlet의 ComputerName 매개 변수를 사용하여 RPC(원격 프로시저 호출)를 기본 프로토콜로 사용하는 원격 컴퓨터에서 실행하는 것과 다릅니다.

PowerShell Remoting 기본 설정

PowerShell 원격(및 WinRM)은 다음 포트에서 수신 대기합니다.

  • HTTP: 5985
  • HTTPS: 5986

기본적으로 PowerShell Remoting은 관리istrators 그룹의 멤버로부터의 연결만 허용합니다. 세션은 사용자의 컨텍스트에서 시작되므로 PowerShell 원격을 통해 연결된 동안 개별 사용자 및 그룹에 적용되는 모든 운영 체제 액세스 제어가 계속 적용됩니다.

프라이빗 네트워크에서 PowerShell 원격에 대한 기본 Windows 방화벽 규칙은 모든 연결을 허용합니다. 공용 네트워크에서는 기본 Windows 방화벽 규칙이 동일한 서브넷 내에서만 PowerShell 원격 연결을 허용합니다. 공용 네트워크의 모든 연결에 대한 PowerShell 원격을 열려면 해당 규칙을 명시적으로 변경해야 합니다.

Warning

공용 네트워크에 대한 방화벽 규칙은 잠재적으로 악의적인 외부 연결 시도로부터 컴퓨터를 보호하기 위한 것입니다. 이 규칙을 제거할 때는 주의하세요.

프로세스 격리

PowerShell 원격은 컴퓨터 간 통신에 WinRM을 사용합니다. WinRM은 네트워크 서비스 계정에서 서비스로 실행되며 PowerShell 인스턴스를 호스트하기 위해 사용자 계정으로 실행되는 격리된 프로세스를 생성합니다. 한 사용자로 실행되는 PowerShell 인스턴스는 다른 사용자로 PowerShell 인스턴스를 실행하는 프로세스에 액세스할 수 없습니다.

PowerShell 원격에서 생성된 이벤트 로그

FireEye는 Powershell 원격 세션에서 생성된 이벤트 로그와 기타 보안 증명에 대한 훌륭한 요약을 제공했으며, 이 내용은 Investigating PowerShell Attacks(PowerShell 공격 조사)에 나와 있습니다.

암호화 및 전송 프로토콜

초기 인증 및 지속적인 통신이라는 두 가지 관점에서 PowerShell 원격 연결의 보안을 고려하는 것이 유용합니다.

사용되는 전송 프로토콜(HTTP 또는 HTTPS)에 관계없이 WinRM은 초기 인증 후 항상 모든 PowerShell 원격 통신을 암호화합니다.

초기 인증

인증은 서버에 대한 클라이언트의 ID를 확인하며, 이상적으로는 서버에서 클라이언트로의 ID를 확인합니다.

클라이언트가 컴퓨터 이름을 사용하여 do기본 서버에 연결하는 경우 기본 인증 프로토콜은 Kerberos입니다. Kerberos는 다시 사용할 수 있는 자격 증명을 보내지 않고 사용자 ID와 서버 ID를 모두 보장합니다.

클라이언트가 IP 주소를 사용하여 할 일기본 서버에 연결하거나 작업 그룹 서버에 연결하는 경우 Kerberos 인증은 불가능합니다. 이 경우 PowerShell 원격은 NTLM authentication protocol(NTLM 인증 프로토콜)을 사용합니다. NTLM 인증 프로토콜은 위임 가능한 자격 증명을 보내지 않고 사용자 ID를 보장합니다. 사용자 ID를 증명하기 위해 NTLM 프로토콜을 사용하려면 클라이언트와 서버 모두 암호 자체를 교환하지 않고 사용자 암호에서 세션 키를 컴퓨팅해야 합니다. 서버는 일반적으로 사용자의 암호를 모르기 때문에 사용자의 암호를 알고 서버의 세션 키를 계산하는 do기본 컨트롤러와 통신합니다.

그러나 NTLM 프로토콜은 서버 ID를 보장하지 않습니다. 인증에 NTLM을 사용하는 모든 프로토콜과 마찬가지로 do기본 조인된 컴퓨터의 컴퓨터 계정에 액세스할 수 있는 공격자는 do기본 컨트롤러를 호출하여 NTLM 세션 키를 컴퓨팅하여 서버를 가장할 수 있습니다.

NTLM 기반 인증은 기본적으로 사용하지 않도록 설정되지만 대상 서버에서 SSL을 구성하거나 클라이언트에서 WinRM TrustedHosts 설정을 구성하여 허용될 수 있습니다.

SSL 인증서를 사용하여 NTLM 기반 연결 중 서버 ID 유효성 검사

NTLM 인증 프로토콜은 대상 서버의 ID를 보장할 수 없으므로(암호를 이미 알고 있는 것만) PowerShell Remoting용 SSL을 사용하도록 대상 서버를 구성할 수 있습니다. 대상 서버에 SSL 인증서를 할당하면(클라이언트가 신뢰하는 인증 기관에서 발급한 경우) 사용자 ID와 서버 ID를 모두 보장하는 NTLM 기반 인증을 사용할 수 있습니다.

NTLM 기반 서버 ID 오류 무시

NTLM 연결을 위해 서버에 SSL 인증서를 배포할 수 없는 경우 WinRM TrustedHosts 목록에 서버를 추가하여 결과 ID 오류를 표시하지 않을 수 있습니다. TrustedHosts 목록에 서버 이름을 추가하는 것은 호스트 자체의 신뢰성에 대한 어떤 형태의 문으로도 간주되어서는 안 됩니다. NTLM 인증 프로토콜이 실제로 연결하려는 호스트에 연결한다고 보장할 수 없기 때문에 주의하세요. 대신 TrustedHosts 설정을 서버의 ID를 확인할 수 없어 생성된 오류를 표시하지 않으려는 호스트 목록으로 간주해야 합니다.

진행 중인 통신

초기 인증이 완료되면 WinRM은 진행 중인 통신을 암호화합니다. HTTPS를 통해 연결할 때 TLS 프로토콜은 데이터를 전송하는 데 사용되는 암호화를 협상하는 데 사용됩니다. HTTP를 통해 연결하는 경우 메시지 수준 암호화는 사용된 초기 인증 프로토콜에 따라 결정됩니다.

  • 기본 인증은 암호화를 제공하지 않습니다.
  • NTLM 인증은 128비트 키가 있는 RC4 암호화를 사용합니다.
  • Kerberos 인증 암호화는 TGS 티켓의 etype에 따라 결정됩니다. 최신 시스템의 AES-256입니다.
  • CredSSP 암호화는 핸드셰이크에서 협상된 TLS 암호 그룹을 사용합니다.

두 번째 홉 만들기

기본적으로 PowerShell 원격은 인증에 Kerberos(사용 가능한 경우) 또는 NTLM을 사용합니다. 이러한 프로토콜은 모두 자격 증명을 전송하지 않고 원격 머신에 인증합니다. 가장 안전한 인증 방법이지만 원격 컴퓨터에 사용자의 자격 증명이 없으므로 사용자를 대신하여 다른 컴퓨터와 서비스에 액세스할 수 없습니다. 이를 "두 번째 홉 문제"라고 합니다.

이 문제를 방지하는 방법에는 여러 가지가 있습니다. 이러한 방법에 대한 설명과 각 방법의 장점과 단점은 PowerShell 원격에서 두 번째 홉 만들기를 참조하세요.

참조