2020.01.31

제대로 해야 하는 9가지 윈도우 서버 보안 설정

Susan Bradley | CSO
윈도우 서버(Windows Server) 보안 기능의 권장 구성은 최근 몇 년 사이 변했다. 최근 (공식적으로) 윈도우 서버 2008 R2의 수명이 종료됐지만 지원 기간이 3년이 채 남지 않은 서버 2012 R2에도 작별을 고할 준비를 해야 한다. 이와 같은 오래된 서버에서는 코드 서명 인증서 스푸핑(spoofing)이나 변조(tampering)를 통해 액세스 권한을 획득하는 등의 최신 위협에 대처하기가 어렵다.
 
ⓒ Getty Images Bank 

사용 중인 서버나 클라우드 플랫폼에 따라 더 이상 예전과 같은 효과가 없을 수도 있는 보안 설정 9가지와, 이런 설정을 대신하거나 보완해서 사용해야 할 설정 또는 정책을 알아보자.


1. 과거의 조언: 관리자 계정 이름 바꾸기

한때 관리자 계정의 이름을 바꾸는 것이 중요한 지침이었다. 일부 서버 플랫폼에서는 마법사 프로세스에 이 과정이 포함되기까지 했다. 몇 년 전에는 계정 이름을 알아내려는 공격자가 있었고, 관리자 계정의 이름을 바꿔 공격자가 이름을 알아내기 어렵도록 한 것이다. 이제는 관리자 계정 이름을 바꾸는 방법은 별 효과가 없다. 공격자는 피싱을 사용하거나 시스템에 방치된 인증 정보를 수집해서 시스템에 침투할 발판을 마련할 수 있기 때문이다.

- 새 조언: 다양한 관리자 비밀번호를 사용하라
대신 네트워크 전체에서 동일한 로컬 관리자 비밀번호를 사용하지 말 것을 권한다. 랜섬웨어 공격자가 네트워크에서 손쉽게 횡적 이동을 하도록 허용하려면 각 워크스테이션에 동일한 비밀번호를 사용하면 된다. 로컬 관리자 비밀번호 솔루션(LAPS)을 배포해서 무작위의 비밀번호가 할당되도록 해야 한다. 배포하면서 잊지 말아야 할 것은 “모든 확장된 권한”을 가진 사용자, 즉 LAPS가 활성화된 모든 컴퓨터와 비밀번호를 볼 수 있는 사용자를 공격자가 노린다는 점이다. 

로컬 관리자 계정이 네트워크를 통해 인증되지 않도록 그룹 정책을 구성한다. 다음 그룹 정책 개체(GPO)를 권장한다.
  • 네트워크에서 이 컴퓨터에 대한 액세스 거부: 로컬 계정, 엔터프라이즈 관리자, 도메인 관리자
  • 원격 데스크톱 서비스를 통한 로그온 거부: 로컬 계정, 엔터프라이즈 관리자, 도메인 관리자
  • 로컬 로그온 거부: 엔터프라이즈 관리자, 도메인 관리자


2. 과거의 조언: 게스트 계정을 비활성화하라

한때 윈도우에서 게스트 계정은 기본적으로 활성화됐다. 현재 윈도우 10은 관리자 권한이 있는 계정을 아예 설치하지 말 것을 권고하는 수준에 이르렀다. 주 관리자 계정 역시 비활성화된다. 따라서 게스트 계정 비활성화는 여전히 유효한 조언이지만 그것으로는 충분하지 않다.

- 새 조언: 관리자 권한이 있는 계정 수를 최소화하라
중요한 점은 소프트웨어를 배포 또는 설치하기 위한 권한 승격 없이 머신을 배포할 수 있는지 여부다. 크롬은 사용자의 “애플리케이션 데이터” 폴더를 설치함으로써 관리자 권한의 필요성을 없애는 방식을 개척했다. 윈도우 사용자 권한은 오랜 시간 사용자와 공격자, 둘 모두에게 남용됐다. 누구에게도 도메인의 게스트 권한을 주지 말아야 한다. 홈 네트워크에서도 게스트 계정을 사용하지 않는 것이 좋다. 홈 네트워크라도 리소스를 공유하는 사용자는 각 리소스에 대한 권한을 갖도록 설정해야 한다.


3. 과거의 조언: LAN 관리자와 NTLM v1을 그만 사용하라

LAN 관리자(LM)나 NTLMv1 인증을 아직도 사용하는 사람은 없을 것이라 믿는다. 이 둘에는 이미 알려진 취약점이 있다. 2번과 마찬가지로 조언 자체는 아직 유효하지만 그 이상을 생각해야 하는 경우에 해당단다.

- 새 조언: 모든 네트워크 프로토콜을 점검하라
2020년에는 네트워크에 사용되는 프로토콜을 점검해야 한다. 한 걸음 더 나가서, SMBv1 사용 현황을 점검하고 가능하다면 비활성화해야 한다. 마이크로소프트는 2020년 3월에 LDAP 채널 바인딩과 LDAP 서명을 구현한다. 네트워크에 서명되지 않은 LDAP 및 SMBv1이 있는지 확인하고, 있으면 네트워크에서 제거하라.

또한 커베로스 티켓 부여 서버(TGS) 서비스 티켓 오프라인 크랙(커베로스트 - Kerberoast)에 대해서도 신경써야 한다. 서비스 계정 비밀번호를 25자 이상으로 해서 이 위험에 대비하라. 관리 서비스 계정과 그룹 관리 서비스 계정을 사용하면 서비스 계정 비밀번호를 길고 복잡하고 만들고 주기적으로 변경할 수 있다.


4. 과거의 조언: 서버에 LM 해시를 저장하지 말 것

지금은 기본적으로 LM 해시가 서버에 저장되지 않는다.

- 새 조언: 레거시 위치에 저장된 LM 해시를 확인하라
감사를 통해 액티브 디렉터리(AD)를 살펴보고 레거시 위치에 남은 LM 해시를 찾아야 한다. 파워셸 툴을 사용해 AD 포리스트(AD Forest)의 모든 계정을 스캔, 확인하고 계정 및 비밀번호 상태를 점검할 수 있다.


5. 과거의 조언: 최소 비밀번호 길이와 최대 비밀번호 기한을 강제하라

더 긴 비밀번호를 사용하고 주기적으로 비밀번호를 변경하도록 하는 정책은 오랫동안 모범 사례로 통했다. 

- 새 조언: 다중 인증을 활성화하라
직원들은 비밀번호를 만들고 변경하기를 싫어한다. 이것이 최소 비밀번호 길이나 최대 비밀번호 기한 정책을 실행하기가 어려운 이유다. 비밀번호 변경을 강제하면 사람들은 더 쉽게 추정할 수 있는, 더 약한 비밀번호를 사용하게 된다. 모든 계정에 다중 인증(MFA)을 활성화하면 공격자가 습득한 비밀번호를 활용하기가 어렵다. 마이크로소프트나 구글의 인증 앱을 사용해 MFA를 설정할 수 있다.


6. 과거의 조언: 이벤트 로그 켜기

이벤트 로그를 켜고 주기적으로 확인하는 것은 악의적 네트워크 활동을 탐지하는 데 있어 여전히 좋은 방법이다.

- 새 조언: 더 새로운 마이크로소프트 이벤트 로깅 툴을 활용하라
마이크로소프트는 최근 이벤트를 통합 추적하기 위한 새로운 온라인 툴인 애저 센티넬(Azure Sentinel)을 공개했다. 이 제품 외에 시스템 모니터(Sysmon)부터 윈도우 디펜더 지능협 위협 보호(ATP)까지 다양한 로깅 기능이 있으며 후자는 서버용과 애저 가상머신(VM)용 프리뷰로도 제공된다.


7. 과거의 조언: 익명 보안 식별자(SID) 열거를 비활성화하라

예전에는 아무 사용자나 AD에서 사용자와 그룹, 기타 보안 주체에 할당된 SID를 쿼리할 수 있었다. 마이크로소프트는 이 열거 기능을 비활성화했다.

- 새 조언: 네트워크에서 수확 공격에 대비하라
이제 공격자들은 소셜 미디어를 사용해서 사용자 이름을 입수하고, 이를 통해 피싱 공격으로 도메인 사용자에 대한 액세스 권한을 획득한다. 그 다음에는 시스템 볼륨(SYSVOL) 폴더와 그룹 정책 기본 설정에 방치된 비밀번호를 수확(harvest)하는 방법으로 도메인 사용자에서 도메인 관리자로 건너뛰는 공격을 감행할 수 있다. 따라서 과거에 했던 방식을 돌아보고 비밀번호가 그룹 정책 기본 설정이나 작업에 저장되어 있지 않은지 확인해야 한다. 방치된 민감한 비밀번호는 공격자가 쉽게 액세스 권한을 입수하는 발판으로 악용될 수 있다. 다시 말하지만 네트워크 관리를 위해서는 LAPS를 구축해 비밀번호를 다루는 것이 최선이다.


8. 과거의 조언: 모든 사용자 그룹에서 익명 계정을 허용하지 말 것

마이크로소프트는 2000년부터 모든 사용자 그룹에서 익명 계정을 없앴다. 익명 계정은 할당하기도 쉬웠고, 애플리케이션을 매끄럽게 실행할 수 있는 방법이기도 했지만 공격자에게도 그만큼 쉬운 목표물이었다.

- 새 조언: 게스트 계정을 감사하고 제거하라
클라우드로 전환하는 과정에서 리소스에 게스트 계정을 추가한 후 제거하지 않은 경우가 있는지 확인하라. 마이크로소프트 오피스 365에서 게스트 계정이 사용되는지 감사하고 정리하라.


9. 과거의 조언: 사용자 계정 컨트롤(UAC)을 활성화하라

UAC는 관리자가 아닌 사람에게 안전한 방식으로 일부 관리 권한을 부여한다. 개발자들의 관리자 권한 요구에 대응해서 윈도우 7부터 도입됐으며 지금은 기본적으로 활성화된다.

- 새 조언: 애플리케이션 화이트리스트를 사용하고 로컬 계정 액세스를 차단하라
공격자들은 이제 관리자 권한이 없는 상황에 익숙하고 다른 수단을 사용해서 더 높은 권한을 획득한다. 일단 관리자 권한을 입수하면 공격자는 다양한 방법으로 탐지를 피하면서 시스템에 머물 수 있다.

그렇다면 어떻게 막아야 할까? 애플리케이션 화이트리스팅은 공격자가 네트워크에서 승인되지 않은 실행 파일을 사용하지 못하도록 차단하는 데 도움이 되지만, 조직에서 특정 애플리케이션 목록을 강제하기는 어려운 경우가 많다. 애런로커(AaronLocker)와 같은 툴은 관리자 권한 없이 시스템에서 더 쉽게 사용할 수 있다.

기본을 간과해서는 안 된다. 마이크로소프트의 윈도우 보안 기본 사항을 보면 로컬 계정에 대한 네트워크 로그온을 거부해서 이를 통한 횡적 이동 위협을 차단할 것을 권장한다. 공격자들은 갈수록 똑똑해지고 있으므로 네트워크를 보호하는 우리도 더 똑똑해져야 한다. editor@itworld.co.kr



2020.01.31

제대로 해야 하는 9가지 윈도우 서버 보안 설정

Susan Bradley | CSO
윈도우 서버(Windows Server) 보안 기능의 권장 구성은 최근 몇 년 사이 변했다. 최근 (공식적으로) 윈도우 서버 2008 R2의 수명이 종료됐지만 지원 기간이 3년이 채 남지 않은 서버 2012 R2에도 작별을 고할 준비를 해야 한다. 이와 같은 오래된 서버에서는 코드 서명 인증서 스푸핑(spoofing)이나 변조(tampering)를 통해 액세스 권한을 획득하는 등의 최신 위협에 대처하기가 어렵다.
 
ⓒ Getty Images Bank 

사용 중인 서버나 클라우드 플랫폼에 따라 더 이상 예전과 같은 효과가 없을 수도 있는 보안 설정 9가지와, 이런 설정을 대신하거나 보완해서 사용해야 할 설정 또는 정책을 알아보자.


1. 과거의 조언: 관리자 계정 이름 바꾸기

한때 관리자 계정의 이름을 바꾸는 것이 중요한 지침이었다. 일부 서버 플랫폼에서는 마법사 프로세스에 이 과정이 포함되기까지 했다. 몇 년 전에는 계정 이름을 알아내려는 공격자가 있었고, 관리자 계정의 이름을 바꿔 공격자가 이름을 알아내기 어렵도록 한 것이다. 이제는 관리자 계정 이름을 바꾸는 방법은 별 효과가 없다. 공격자는 피싱을 사용하거나 시스템에 방치된 인증 정보를 수집해서 시스템에 침투할 발판을 마련할 수 있기 때문이다.

- 새 조언: 다양한 관리자 비밀번호를 사용하라
대신 네트워크 전체에서 동일한 로컬 관리자 비밀번호를 사용하지 말 것을 권한다. 랜섬웨어 공격자가 네트워크에서 손쉽게 횡적 이동을 하도록 허용하려면 각 워크스테이션에 동일한 비밀번호를 사용하면 된다. 로컬 관리자 비밀번호 솔루션(LAPS)을 배포해서 무작위의 비밀번호가 할당되도록 해야 한다. 배포하면서 잊지 말아야 할 것은 “모든 확장된 권한”을 가진 사용자, 즉 LAPS가 활성화된 모든 컴퓨터와 비밀번호를 볼 수 있는 사용자를 공격자가 노린다는 점이다. 

로컬 관리자 계정이 네트워크를 통해 인증되지 않도록 그룹 정책을 구성한다. 다음 그룹 정책 개체(GPO)를 권장한다.
  • 네트워크에서 이 컴퓨터에 대한 액세스 거부: 로컬 계정, 엔터프라이즈 관리자, 도메인 관리자
  • 원격 데스크톱 서비스를 통한 로그온 거부: 로컬 계정, 엔터프라이즈 관리자, 도메인 관리자
  • 로컬 로그온 거부: 엔터프라이즈 관리자, 도메인 관리자


2. 과거의 조언: 게스트 계정을 비활성화하라

한때 윈도우에서 게스트 계정은 기본적으로 활성화됐다. 현재 윈도우 10은 관리자 권한이 있는 계정을 아예 설치하지 말 것을 권고하는 수준에 이르렀다. 주 관리자 계정 역시 비활성화된다. 따라서 게스트 계정 비활성화는 여전히 유효한 조언이지만 그것으로는 충분하지 않다.

- 새 조언: 관리자 권한이 있는 계정 수를 최소화하라
중요한 점은 소프트웨어를 배포 또는 설치하기 위한 권한 승격 없이 머신을 배포할 수 있는지 여부다. 크롬은 사용자의 “애플리케이션 데이터” 폴더를 설치함으로써 관리자 권한의 필요성을 없애는 방식을 개척했다. 윈도우 사용자 권한은 오랜 시간 사용자와 공격자, 둘 모두에게 남용됐다. 누구에게도 도메인의 게스트 권한을 주지 말아야 한다. 홈 네트워크에서도 게스트 계정을 사용하지 않는 것이 좋다. 홈 네트워크라도 리소스를 공유하는 사용자는 각 리소스에 대한 권한을 갖도록 설정해야 한다.


3. 과거의 조언: LAN 관리자와 NTLM v1을 그만 사용하라

LAN 관리자(LM)나 NTLMv1 인증을 아직도 사용하는 사람은 없을 것이라 믿는다. 이 둘에는 이미 알려진 취약점이 있다. 2번과 마찬가지로 조언 자체는 아직 유효하지만 그 이상을 생각해야 하는 경우에 해당단다.

- 새 조언: 모든 네트워크 프로토콜을 점검하라
2020년에는 네트워크에 사용되는 프로토콜을 점검해야 한다. 한 걸음 더 나가서, SMBv1 사용 현황을 점검하고 가능하다면 비활성화해야 한다. 마이크로소프트는 2020년 3월에 LDAP 채널 바인딩과 LDAP 서명을 구현한다. 네트워크에 서명되지 않은 LDAP 및 SMBv1이 있는지 확인하고, 있으면 네트워크에서 제거하라.

또한 커베로스 티켓 부여 서버(TGS) 서비스 티켓 오프라인 크랙(커베로스트 - Kerberoast)에 대해서도 신경써야 한다. 서비스 계정 비밀번호를 25자 이상으로 해서 이 위험에 대비하라. 관리 서비스 계정과 그룹 관리 서비스 계정을 사용하면 서비스 계정 비밀번호를 길고 복잡하고 만들고 주기적으로 변경할 수 있다.


4. 과거의 조언: 서버에 LM 해시를 저장하지 말 것

지금은 기본적으로 LM 해시가 서버에 저장되지 않는다.

- 새 조언: 레거시 위치에 저장된 LM 해시를 확인하라
감사를 통해 액티브 디렉터리(AD)를 살펴보고 레거시 위치에 남은 LM 해시를 찾아야 한다. 파워셸 툴을 사용해 AD 포리스트(AD Forest)의 모든 계정을 스캔, 확인하고 계정 및 비밀번호 상태를 점검할 수 있다.


5. 과거의 조언: 최소 비밀번호 길이와 최대 비밀번호 기한을 강제하라

더 긴 비밀번호를 사용하고 주기적으로 비밀번호를 변경하도록 하는 정책은 오랫동안 모범 사례로 통했다. 

- 새 조언: 다중 인증을 활성화하라
직원들은 비밀번호를 만들고 변경하기를 싫어한다. 이것이 최소 비밀번호 길이나 최대 비밀번호 기한 정책을 실행하기가 어려운 이유다. 비밀번호 변경을 강제하면 사람들은 더 쉽게 추정할 수 있는, 더 약한 비밀번호를 사용하게 된다. 모든 계정에 다중 인증(MFA)을 활성화하면 공격자가 습득한 비밀번호를 활용하기가 어렵다. 마이크로소프트나 구글의 인증 앱을 사용해 MFA를 설정할 수 있다.


6. 과거의 조언: 이벤트 로그 켜기

이벤트 로그를 켜고 주기적으로 확인하는 것은 악의적 네트워크 활동을 탐지하는 데 있어 여전히 좋은 방법이다.

- 새 조언: 더 새로운 마이크로소프트 이벤트 로깅 툴을 활용하라
마이크로소프트는 최근 이벤트를 통합 추적하기 위한 새로운 온라인 툴인 애저 센티넬(Azure Sentinel)을 공개했다. 이 제품 외에 시스템 모니터(Sysmon)부터 윈도우 디펜더 지능협 위협 보호(ATP)까지 다양한 로깅 기능이 있으며 후자는 서버용과 애저 가상머신(VM)용 프리뷰로도 제공된다.


7. 과거의 조언: 익명 보안 식별자(SID) 열거를 비활성화하라

예전에는 아무 사용자나 AD에서 사용자와 그룹, 기타 보안 주체에 할당된 SID를 쿼리할 수 있었다. 마이크로소프트는 이 열거 기능을 비활성화했다.

- 새 조언: 네트워크에서 수확 공격에 대비하라
이제 공격자들은 소셜 미디어를 사용해서 사용자 이름을 입수하고, 이를 통해 피싱 공격으로 도메인 사용자에 대한 액세스 권한을 획득한다. 그 다음에는 시스템 볼륨(SYSVOL) 폴더와 그룹 정책 기본 설정에 방치된 비밀번호를 수확(harvest)하는 방법으로 도메인 사용자에서 도메인 관리자로 건너뛰는 공격을 감행할 수 있다. 따라서 과거에 했던 방식을 돌아보고 비밀번호가 그룹 정책 기본 설정이나 작업에 저장되어 있지 않은지 확인해야 한다. 방치된 민감한 비밀번호는 공격자가 쉽게 액세스 권한을 입수하는 발판으로 악용될 수 있다. 다시 말하지만 네트워크 관리를 위해서는 LAPS를 구축해 비밀번호를 다루는 것이 최선이다.


8. 과거의 조언: 모든 사용자 그룹에서 익명 계정을 허용하지 말 것

마이크로소프트는 2000년부터 모든 사용자 그룹에서 익명 계정을 없앴다. 익명 계정은 할당하기도 쉬웠고, 애플리케이션을 매끄럽게 실행할 수 있는 방법이기도 했지만 공격자에게도 그만큼 쉬운 목표물이었다.

- 새 조언: 게스트 계정을 감사하고 제거하라
클라우드로 전환하는 과정에서 리소스에 게스트 계정을 추가한 후 제거하지 않은 경우가 있는지 확인하라. 마이크로소프트 오피스 365에서 게스트 계정이 사용되는지 감사하고 정리하라.


9. 과거의 조언: 사용자 계정 컨트롤(UAC)을 활성화하라

UAC는 관리자가 아닌 사람에게 안전한 방식으로 일부 관리 권한을 부여한다. 개발자들의 관리자 권한 요구에 대응해서 윈도우 7부터 도입됐으며 지금은 기본적으로 활성화된다.

- 새 조언: 애플리케이션 화이트리스트를 사용하고 로컬 계정 액세스를 차단하라
공격자들은 이제 관리자 권한이 없는 상황에 익숙하고 다른 수단을 사용해서 더 높은 권한을 획득한다. 일단 관리자 권한을 입수하면 공격자는 다양한 방법으로 탐지를 피하면서 시스템에 머물 수 있다.

그렇다면 어떻게 막아야 할까? 애플리케이션 화이트리스팅은 공격자가 네트워크에서 승인되지 않은 실행 파일을 사용하지 못하도록 차단하는 데 도움이 되지만, 조직에서 특정 애플리케이션 목록을 강제하기는 어려운 경우가 많다. 애런로커(AaronLocker)와 같은 툴은 관리자 권한 없이 시스템에서 더 쉽게 사용할 수 있다.

기본을 간과해서는 안 된다. 마이크로소프트의 윈도우 보안 기본 사항을 보면 로컬 계정에 대한 네트워크 로그온을 거부해서 이를 통한 횡적 이동 위협을 차단할 것을 권장한다. 공격자들은 갈수록 똑똑해지고 있으므로 네트워크를 보호하는 우리도 더 똑똑해져야 한다. editor@itworld.co.kr

X