Security

대논쟁: 은둔 보안 방식

Jesper M. Johansson and Roger Grimes

 

한 눈에 보기:

  • 은둔 보안 방식 정의
  • 은둔 보안 방식 평가
  • Administrator 계정 이름 바꾸기 가치 평가
  • 정보에 근거한 위험 관리 결정

"은둔 보안 방식"이라는 용어는 보안 관련 종사자, 특히 자신을 전문가라고 생각하는 사람들로부터 조롱을 받기도 합니다. 이 분야에서 거의 상소리에 버금가는

은둔 보안 방식은 Wikipedia(en.wikipedia.org/wiki/Security_through_obscurity)에 나온 대로 보안 분야에서 논란의 중심에 있는 용어 중 하나입니다. 노력이 헛수고가 된 사람들을 놀리며 가리킬 때 흔히 "은둔 보안 방식 같다"라는 소리를 들을 수 있을 것입니다.

은둔 보안 방식은 요약하면 설계가 상대편에게 알려지지 않았기 때문이 아니라 설계 자체로 인해 시스템의 보안이 유지되어야 한다는 Kerckhoffs의 원칙에 어긋납니다. Kerckhoffs 원칙의 기본 전제는 비밀이 오랫동안 비밀로 유지되지 않는다는 것입니다.

좋은 예로 초기에 설계 비밀로 생각되었던 Windows NT® LAN Manager(NTLM) 인증 프로토콜이 있습니다. UNIX 기반 운영 체제용 Samba 상호 운용성 제품을 구현하기 위해 Samba 팀이 프로토콜을 리버스 엔지니어링해야 했습니다. 결과적으로 수많은 버그 발견과 함께 NTLM에 대한 가장 포괄적인 문서(monyo.com/technical/samba/translation/ntlm.en.html)가 작성되었습니다. 대부분의 보안이 암호화를 통해 구현되었고 많은 비밀 설계가 누설됨에 따라 여러 보안 전문가들은 모든 정보 보안이 Kerckhoffs의 원칙을 따라야 한다고 믿고 있습니다.

하지만 은둔 보안 방식이 언제나 좋지 않은 것일까요? 이 기사에서는 은둔 보안 방식이 무엇이고, 많은 사람들이 이를 시간 낭비라고 생각하는 이유(및 그 반대 의견)에 대해 간략히 설명하며, 언제나 그렇듯이 이에 대한 답변이 처음에 생각했던 것보다 매우 복잡한 이유에 대해 살펴봅니다.

은둔 보안 방식 소개

기본 설정 변경 금지 - Steve Riley

저는 이름 바꾸기 문제에서 "바꾸지 말자"는 쪽입니다. 이것은 사실 보안 문제가 아닌 시스템 관리 문제입니다. 시스템 관리 부분에 대한 고민을 할수록(관리와 보안은 하나가 되고 있으므로) 잠재적으로 시스템의 취약성을 높일 수 있는 작업은 하지 않는 것이 좋다는 믿음이 생깁니다. 취약성을 높일 수 있는 한 가지 확실한 방법은 기본 설정을 변경하는 것입니다. 사람들이 기본 설정을 변경하는 이유는 두 가지(또는 세 가지)입니다.

  • 변경을 해야 작동하는 기능이 있습니다.
  • 변경으로 보안이 높아질 것이라는 믿음이 있습니다.
  • (주의: 웃지 말것) 잡지 기사에서 읽었습니다.

첫 번째 이유로 기본 이름을 변경해야 한다면 그렇게 하십시오. 이러한 종류의 변경은 이미 테스트된 경우가 많기 때문에 거의 시스템 취약성으로 이어지지 않습니다.

두 번째 이유로 기본 설정을 변경한다면 일단 중지하고 다시 생각해 보십시오. 이러한 종류의 변경은 소프트웨어 제조업체에서 거의 테스트되지 않았으므로 변경 후 시스템이 어떻게 동작할지 예측할 수 없습니다. 더욱이, 일반적으로 보안 향상을 제공하는 훨씬 더 좋은 대안이 있습니다.

나쁜 사람이 계정 이름을 알게 되었다고 해서 뭐가 달라집니까? 이러한 사람들로부터 시스템을 보호하는 것은 암호 및 암호의 강도입니다. Administrator 및 Guest와 같은 기본 계정 이름을 추측하기 어려운 것으로 변경한다는 것은 사실 강력한 암호 또는 암호 구문을 사용하지 않으려는 의도를 나타냅니다. 진정한 문제(형편없는 암호)를 해결하면 취약성(기본 이름 변경)을 피할 수 있습니다.

은둔 보안 방식에는 문제를 완화하는 조치가 전혀 포함되어 있지 않습니다. 예를 들어, 경계 라우터에서 직원들이 신문을 읽지 못하도록 NNTP(Network News Transfer Protocol)를 차단하지만 아웃바운드 SSH(Secure Shell)를 허용하는 조직에서는 은둔 보안 방식을 사용하지 않습니다. SSH는 모든 프로토콜을 터널링하므로 문제가 숨겨지지 않습니다. 구현된 어리석은 완화 조치는 정당한 사용자가 보안 정책을 위반하지 않고 정당한 작업을 수행하는 것을 방해할 뿐입니다. 이러한 방식은 은둔 보안 방식이 아니며 단지 어리석고 의미가 없는 것입니다.

"은둔 보안 방식"의 "보안"이 의미하는 대로 이 방식에서 어느 정도의 보호를 받습니다. 하지만 실제로 하나 이상의 요소에 대한 공격을 막아내지 못한다는 문제가 있습니다. 공격 요소는 공격자가 시스템에 액세스할 수 있는 방법입니다.

공개 공격 코드를 사용하여 TCP 포트 80을 통해 공격할 수 있는 취약한 웹 서버가 있다고 가정해 보겠습니다. 이 특정 요소를 막으려면 웹 서버를 패치하거나 종료할 수 있는데, 두 방법 모두 이 요소를 완전히 차단할 것입니다. 방화벽 또는 IPsec를 사용하여 일부 컴퓨터를 제외한 모든 컴퓨터에 대해 포트 80을 막아 이 공격 요소를 부분적으로 차단할 수도 있습니다. 이 방법은 공격 요소를 완전히 차단하지는 못하지만 문제를 크게 완화합니다.

반면, 은둔 보안 방식에서는 공격 요소를 차단하지 않고 단지 감추는 조치를 취합니다. 예를 들어, 웹 서버를 알고 있는 사람만 해당 작업을 수행할 수 있도록 웹 서버를 포트 80 대신 81로 이동하기로 결정할 수 있습니다. 여기서도 논란의 여지가 있지만, 실제로 웹 서버를 포트 81로 이동하면 일부 공격은 차단할 수 있지만 대부분 최종 사용자만 불편하게 됩니다. 노련한 침입자는 많은 수의 포트에 대해 포트 검색기 및 웹 배너 수집기를 실행하여 비표준 포트를 사용하는 웹 서버를 찾아냅니다. 침입자가 웹 서버를 찾아낼 경우 실제로는 공격 요소를 없애지 않고 단지 (일시적으로) 감추어 두었기 때문에 서버에 대해 공격을 시작할 수 있습니다.

그렇다면 이러한 방식은 시도할 만한 가치도 없는 것일까요? 대답은 상황에 따라 다릅니다. 정보 보안 분야의 다른 것들과 마찬가지로 모든 것은 위험 관리로 귀속됩니다. 고려할 주요 요소를 이해하려면 몇 가지 은둔 보안 방식을 더 검토한 다음 Administrator 계정 이름 바꾸기와 같은 조치에 대해 좀 더 자세히 논의할 필요가 있습니다.

보안 조치 평가

은둔 보안 방식의 예는 많습니다. 여기에는 시스템 및 네트워크 관리자가 취하는 조치 또는 소프트웨어 개발자가 시작한 조치가 있을 수 있습니다. 하지만 공통적으로는 취약점을 공격자로부터 숨겨 취약점을 완화하려는 의도가 있습니다.

이러한 조치는 적어도 약간의 긍정적 효과는 있지 않을까요? 모든 은둔 보안 방식은 좋지 않다고 말할 수 있을까요? 적어도 이러한 조치 중 몇 가지를 지지하는 사람들을 발견할 수 있을 것입니다. 예를 들어, Windows®의 경우 Windows 탐색기에서 드라이브 문자를 숨길 수 있습니다. 학교 컴퓨터 실습실과 같은 많은 환경에서는 이 방법을 사용하여 사용자가 하드 드라이브에 데이터를 저장하지 못하도록 하고 있습니다. 물론 대부분의 응용 프로그램은 여전히 데이터를 하드 드라이브에 저장할 수 있으므로 완벽한 보안 조치로 볼 수는 없습니다. 하지만 이 방법을 구현한 기관에서는 이를 통해 하드 드라이브의 데이터를 줄일 수 있다고 합니다.

Windows에서 구현되는 또 하나의 은둔 보안 방식 유형은 관리 네트워크 공유(C$, Admin$ 등)를 해제하는 것입니다. 많은 사람들은 이 방법을 사용하면 공격자가 원격으로 컴퓨터에 연결하지 못하는 것으로 알고 있습니다. 실제로는 그렇지 않으며, 관리 공유를 사용할 수 있는 계정을 알고 있는 공격자는 해당 공유를 다시 사용하도록 원격으로 설정할 수 있습니다. 하지만 많은 조직에서는 이러한 공유를 사용하지 않도록 설정하면 네트워크에서 맬웨어 발생이 줄어든다고 말합니다.

헛수고일 수 있는 좋은 예 중 하나는 Windows의 "로그온할 필요 없이 도킹 해제 허용" 설정입니다. 이것을 사용하지 않도록 설정하면 "컴퓨터 도킹 해제" 단추가 로그온 화면에서 사라집니다. 이 방법에 대한 이면에는 이를 통해 공격자가 쉽게 컴퓨터 도킹을 해제하지 못할 것이라는 생각이 있습니다. 물론, 침입자는 이 단추의 표시 여부와 상관없이 컴퓨터와 도킹 스테이션을 모두 가방에 넣고 가져갈 수 있습니다. 이 방법은 은둔 보안 방식으로 볼 수도 없습니다.

또 다른 좋은 예는 Server Operators 그룹 구성원인 사용자가 작업 일정을 설정할 수 있도록 하는 "Server Operator가 작업을 예약하도록 허용" 설정입니다. 이러한 작업은 로컬 시스템으로 실행할 수 있고 관리자만 로컬 시스템으로 실행되는 작업을 예약할 수 있어야 하기 때문에 민감한 문제입니다. 물론, 서버 운영자는 다른 여러 요소를 통해 자신을 관리자로 만들 수 있으므로 이와 같은 방식으로 작업 예약을 하지 못하도록 하는 것은 실제로 의미가 없습니다.

하지만 많은 조직에서는 엔지니어를 관리자 대신 서버 운영자로 지정할 수 있어, 실수로 서버를 손상시킬 위험이 줄어들기 때문에 이 설정을 선호합니다. 이 방법은 자체만으로도 어느 정도 이점이 있습니다.

그렇다면 결론은 무엇일까요? 분명히 이러한 문제 중 일부는 매우 복잡할 수 있습니다. 우리는 이러한 유형의 조치에 대해 토론하느라 흥미로운 시간을 보냈습니다. Roger는 이러한 조치에서 가치를 찾느라 애쓰고 있습니다. 한편, Jesper는 이러한 조치가 대부분의 경우 시간 낭비라고 믿고 있습니다. 은둔 보안 방식 중 가장 자주 인용되고 논란이 되는 예인 Administrator 계정 이름 바꾸기에 대해 살펴보겠습니다. Roger는 이 조치에 대해 찬성하고, Jesper는 반대합니다. 보안 전문가인 Aaron Margosis와 Steve Riley도 추가 기사 "Administrator 계정 이름 바꾸기"와 "기본 설정 변경 금지"에서 각각 의견을 제시하고 있습니다.

Administrator 계정 숨기기

RID(relative identifier) 500인 Administrator 계정 이름을 일반적으로 알려지지 않은 다른 이름으로 바꾸는 것은 여러 보안 전문가들이 권장하고 있으며 많은 Microsoft 보안 강화 안내서에도 포함되어 있습니다. 그림 1과 같이 그룹 정책에도 Administrator 계정 이름 바꾸기에 대한 설정이 포함되어 있습니다. 여기에는 Administrator 계정 이름이 바뀌면 공격자가 실제 관리자로 로그인하는 데 좀 더 어려울 것이라는 의도가 있습니다. 물론, 이 작업에 대해 그룹 정책을 사용할 경우 그룹 정책 개체가 적용된 모든 컴퓨터에 이름이 바뀐 Administrator 계정 이름이 동일하게 사용되는 문제가 있습니다. 그러면 이 특정 보안 조치의 효과가 떨어집니다.

그림 1 Administrator 계정 이름 바꾸기

그림 1** Administrator 계정 이름 바꾸기 **(더 크게 보려면 이미지를 클릭하십시오.)

또한 이 방식에서는 정당한 계정을 가진 사용자는 Administrator 계정 이름 변경 여부와 상관없이 이 이름을 검색할 수 있다는 것을 알아야 합니다. Administrator 계정의 RID는 항상 500입니다. RID 500인 계정의 이름을 간단히 조회하면 계정을 가진 모든 사용자가 그림 2와 같이 실제로 불려지는 이름을 볼 수 있습니다.

그림 2 이름이 바뀐 Administrator 계정 찾기

그림 2** 이름이 바뀐 Administrator 계정 찾기 **(더 크게 보려면 이미지를 클릭하십시오.)

Roger의 의견

Administrator 계정 이름 바꾸기에 반대하는 주요 의견은 보안 주체 계정 이름을 관련 SID(security identifier)로 변환하고 해당 RID를 찾기가 쉽다는 것입니다. 그리고 실제 Administrator 계정은 항상 RID 500을 가진다는 것입니다. 그렇다면 공격자가 사용자 계정 이름을 SID/RID 조합으로 쉽게 변환하고 RID 500을 찾을 수 있다면 이런 조치를 할 필요가 있습니까?

하지만 이것도 그리 간단하지 않습니다. 사용자 계정 이름을 SID/RID로 변환하기 위해서는 NetBIOS 또는 LDAP 포트에 대한 액세스 권한이 있어야 합니다. 대부분의 경계 방화벽에서는 인터넷을 통해 이러한 유형의 액세스를 허용하지 않으므로 공격자가 방화벽을 완전히 우회할 때까지는 어떤 것도 변환할 수 없습니다. 더욱이, 익명 SID 변환은 DC(도메인 컨트롤러)에 있는 경우를 제외하고 Windows XP 및 이후 버전의 Windows에서 작동하지 않습니다. 가장 외부에 있는 컴퓨터(위험이 가장 높은 컴퓨터)에 대해 이름-SID 변환을 수행하려면 공격자에게 인증된 자격 증명이 필요합니다.

따라서 변환 공격을 시작하기 위해서는 뚫어야 하는 많은 방어망이 존재합니다. 그리고 공격자가 여기까지 도달했다면 계정 이름이 바뀌지 않았더라도 상황은 같아집니다. Administrator 계정 이름 바꾸기는 보안을 높일 뿐 아무런 해도 되지 않습니다.

또 하나의 비밀. 공격자가 Administrator 계정 이름을 알지 못할 경우 공격자가 알아야 하는 암호와 마찬가지로 또 하나의 "비밀"이 됩니다. 사용자 계정 이름은 관리 암호만큼 복잡하지 않겠지만 그래도 암호 추측/해킹 문제를 복잡하게 만드는 또 하나의 장애물입니다. 암호 해킹 테스트를 해 본 경험이 있다면 사용자 이름과 암호를 모두 추측하는 데 얼마나 많은 작업이 필요한지 알 것입니다. 이를 통해 이미 어려운 작업을 더 어렵게 만들 수 있습니다.

자동화된 맬웨어 및 스크립트 공격 차단. 저는 현재 22년 동안 Windows 보안 방어를 연구 중이며, 지난 5년간 8대의 Windows 허니팟(honeypot)을 인터넷에 노출시키고 있습니다. 하지만 지금까지 자동화된 맬웨어(모든 공격의 상당수 차지)에서 Administrator(또는 *NIX 시스템의 경우 root) 이외의 다른 사용자 계정 레이블을 사용한 것을 본 적이 없습니다. Administrator 계정 이름을 바꾸면 Administrator 이름에 의존하는 모든 맬웨어를 즉시 차단할 수 있으며, 결과적으로 보안 위험이 낮아집니다.

스크립트 공격도 마찬가지입니다. 제가 알고 있는 모든 "근사한" Windows 해킹 매뉴얼에서는 이름-SID 변환 방법을 언급하고 있지만, 어떤 이유인지 "가짜" Administrator 계정을 인터넷에 노출된 허니팟에 던져 놓아도 내 컴퓨터에서 이러한 사례를 목격하지 못했습니다. 노련한 해커는 자신이 찾아낸 Administrator 계정이 실제 Administrator(RID 500)인지 항상 확인해야 하지만 그렇지 않습니다. 이유는 잘 모르겠습니다. 단지 게으른 해커이거나 일반적인 인간의 행동으로 생각하고 있습니다.

대부분의 전문 해커도 차단. 이렇게 말하면 대부분의 사람들이 놀랍니다. 몇 년간 허니팟을 운영하고 있다면 자동화된 공격, 스크립트 공격 및 전문가를 빠르게 구별해 낼 수 있을 것입니다. 지난 5년간 제 허니팟에 대해 보고된 수많은 공격 중에도 가짜 Administrator 계정이 존재한 경우 전문 해커가 SID 변환을 수행하는 것을 목격하지 못했습니다.

일부 전문 해커는 SID 변환을 수행하겠지만 소수에 불과할 것으로 판단되며 실제로 저도 경험한 적이 없습니다. 전문 해커들이 그렇게 하지 않는 이유가 무엇일까요? 제 생각에는 많은 사람들이 그렇게 하지 않는 상황에서 자기만 시도할 이유를 찾지 못하는 것 같습니다.

경고 단순화. 이제 반대 입장의 사람들은 Administrator 계정 이름 바꾸기가 보편화되면 은둔 방식으로서의 가치를 잃게 되는 것이라고 반박할 수 있습니다. 맬웨어, 스크립트 공격 및 전문 해커가 기본 전략을 바꾸어 Administrator 이외의 다른 이름도 공격 대상으로 고려한다는 것입니다. 맞는 말입니다. 하지만 다행히도 기본적인 조건은 바뀌지 않습니다. 무엇보다, Windows Super 권한을 가진 계정 이름이 Administrator로 지정되지 않을 경우 악의적인 해커가 많은 작업을 해야 합니다. 이것이 중요합니다. 그리고 악의적인 해커가 더 많은 작업을 해야 한다면 공격 시도 횟수가 줄어 다른 방어망 중 하나에서 악의적인 공격을 더 신속하게 감지할 수도 있습니다.

이제 이름 바꾸기에 찬성하는 마지막 이유를 말씀드리겠습니다. Administrator 계정이 Administrator로 지정된 적이 없고 그림 3과 같이 해당 이름으로 다른 계정을 만든다면 좋은 경고 체계를 갖추게 됩니다. 이벤트 모니터링에서 기본 이름을 사용하여 시도된 로그온을 감지한다면 즉시 조사할 필요가 있는 이벤트입니다.

그림 3 Administrator라는 이름의 유인 계정에 대한 로그인 시도로 조기 경고 가능

그림 3** Administrator라는 이름의 유인 계정에 대한 로그인 시도로 조기 경고 가능 **(더 크게 보려면 이미지를 클릭하십시오.)

이벤트 로그는 별 의미가 없는 "잘못된" 로그온으로 가득 찹니다. 단지 잘못된 암호나 이와 유사한 것을 사용하여 로그인하려고 시도하는 사용자(또는 Windows)입니다. 하지만 Administrator 계정 이름이 Administrator로 지정되어 있다면 일반적인 로그온 시도와 악의적인 로그온 시도를 어떻게 쉽게 구별할 수 있겠습니까? Administrator라는 로그온 계정이 없고 해당 계정 이름을 사용하여 시도된 로그온을 감지한다면 악의적인 시도임을 알 수 있습니다. 영향이 별로 없는 조기 경고는 오늘날 방어에서 큰 가치가 있습니다.

Jesper의 의견

Administrator 계정 이름 바꾸기 - Aaron Margosis

이상적인 세계라면 Jesper의 말이 맞습니다. 암호는 항상 무작위(brute-force) 추측이 불가능할 정도로 충분히 강력해야 하고, -500 로컬 관리자 계정은 긴급 복구 상황에서만 사용되어야 합니다. 하지만 실제 세계에서는 그렇지 않습니다.

Jesper의 뛰어난 보안 강의 및 특히 집필한 암호 구문 시리즈( go.microsoft.com/fwlink/?LinkId=113157, go.microsoft.com/fwlink/?LinkId=113159go.microsoft.com/fwlink/?LinkId=113160의 "The Great Debates: Pass Phrases vs. Passwords" Part 1, 2 및 3)에도 불구하고 많은 시스템 관리자는 강력한 암호의 구성 요소에 대해 이해하지 못하고 있습니다.

여러 문자 집합에서 가져온 8자리의 임의 문자로 구성된 암호가 강력했던 시기는 그리 오래 전이 아닙니다. 결국 이것은 무어의 법칙으로 사라지게 되었습니다. 사용자(및 시스템 관리자) 교육은 미약하며, 케이블 뉴스 채널에서 강력한 암호에 대해 대대적으로 보도될 때까지 대부분의 사람들은 현재 상태로 남아 있을 것입니다.

따라서 오늘날 실제 암호 추측에 6,000억 년이 필요한 것도 아니고 점심 시간만 사용하면 가능하겠지만, x1000 배수를 추가하면 실질적인 도움이 될 수 있습니다. 그리고 Administrator라는 이름의 계정을 뚫으려고 시도하는 많은 자동화된 공격에 대해 계정 이름을 바꾸면 취약점이 완화됩니다.

admin 계정 이름을 바꾸는 데 필요한 시간과 노력은 크지 않으며, 일반적으로 알고 있는 대로 단순한 GPO 설정입니다. 사실, 미국 정부의 Federal Desktop Core Configuration(csrc.nist.gov/fdcc)에서는 -500 계정 이름을 변경하도록 규정하고 있습니다. 이름 바꾸기는 필요한 많은 설정 중 하나이며, 많은 시간이나 주의가 필요한 작업이 아닙니다. 또한 이름 바꾸기의 가치와 관련하여 잘못된 보안 의미로 인식한 사람을 본 적이 없으며, "admin 계정의 이름을 바꾸었기 때문에 패치 관리가 필요하지 않다"고 말하는 사람도 없습니다.

조직 전체에서 계정 이름이 동일하게 바뀔 경우 이름 바꾸기의 의미가 있을까요? 의미가 크지는 않겠지만 어느 정도의 의미는 있습니다. 첫 번째로, Administrator에 대한 자동화된 공격을 차단할 수 있으며, 두 번째로, 잠재적 공격자가 새 이름을 알고 있는 "모든 사람" 중에 포함되지 않을 수도 있다는 것입니다. (이름 변경 여부와 상관없이 로컬 admin 계정이 조직 전체적으로 동일한 암호를 공유할 때 더 큰 위험이 있습니다. 이러한 암호 관리가 더 크고 중요한 문제입니다. -500 계정을 사용하지 않는 것은 이를 해결하는 한 가지 방법이지만, 이 경우 도메인 계정을 사용할 수 없을 때 사용할 수 있는 중요한 복구 통로가 차단됩니다.) 보안 지침에서는 오래 전부터 기본 계정 이름 바꾸기를 권장해 왔으므로 충분한 테스트를 통해 완벽하게 지원되고 있습니다.

지금까지의 논의를 통해 은둔 보안 조치만으로는 충분한 방어가 되지 않는다는 것을 알게 되었습니다. 하지만 이를 통해 다른 보안 조치를 강화할 수 있으며, 이것은 Roger의 데이터를 보면 분명하게 알 수 있습니다. 구현 비용만 낮다면 조직에서 이러한 조치를 배제하지 말아야 합니다.

찬성 논리에 대해 Administrator 계정 이름 바꾸는 것을 반대하는 합당한 논리가 있습니다. 하지만 이보다 먼저 저는 Roger의 마지막 주장은 확실히 옳다고 생각합니다. 그러나 엄격하게 관리되는 환경에서는 Administrator 계정이 긴급 복구 상황 이외에는 사용되어서는 안 되기 때문에 이 계정에 대한 모든 로그온을 조사해야 합니다.

무용지물. Administrator 계정 이름을 바꾸면 완화되는 것으로 추정되는 주요 위험은 암호를 원격으로 추측하는 것에 대한 위험입니다. 그러나 컴퓨터에서 인증된 다른 계정을 가지고 있지 않은 사용자만 Administrator 계정 이름 바꾸기로 차단됩니다. 이러한 공격자는 일반적으로 일련의 임의 암호를 사용하여 Administrator 계정에 대한 로그인을 시도합니다. 하지만 이러한 공격자는 계정 이름을 틀리게 추측했는지 또는 암호를 틀리게 추측했는지에 상관없이 동일한 오류 메시지를 받게 됩니다.

이것은 스크립트 공격이 사라진다는 Administrator 계정 이름 바꾸기의 주요 주장 중 하나에 문제가 있음을 나타냅니다. Administrator 계정 이름을 바꾸어도 원래 이름일 때보다 공격을 빨리 포기하지는 않습니다. 둘을 구분할 수 없기 때문입니다! 이들은 어쨌든 동일한 임의 암호 집합을 추측하고 다음 공격 대상으로 이동할 것입니다.

이것은 Administrator 계정에 대한 암호가 공격을 막아낼 수 있을 만큼 강력하다면 계정 이름 바꾸기가 별 소용이 없음을 의미합니다. Administrator 계정 암호에 전체 키보드에서 선택된 대소문자, 숫자 및 기호로 구성된 15자리 암호가 있다고 가정해 보겠습니다. 네트워크를 통해 이 암호를 추측하려면 약 591,310,404,907년이 걸립니다. 이것은 우주가 생겨난 것보다 약 43배나 긴 시간입니다.

이제 Administrator 계정 이름을 바꾸고 1,000개의 가능한 값 중 하나인 경우를 생각해 보겠습니다. 암호 추측 시간은 591,310,404,906,787년으로 늘어나며, 이것은 우주가 생겨난 것보다 43,161배나 긴 시간입니다. 그러면 보다 안전합니까? 물론 세 자리 연도가 늘어난 만큼 더 안전합니다. 그렇다고 공격자가 암호를 추측할 가능성이 낮아졌습니까? 그 가능성은 두 경우 모두 극미하게 낮습니다. 달리 말하면, 사실상 원래 Administrator 계정 이름을 사용해도 마찬가지라는 것입니다. 계정 이름을 바꾸면 해당 계정을 사용하려고 시도하는 맬웨어를 차단한다고 해서 계정 이름을 바꾸지 않으면 맬웨어가 성공한다는 것은 아닙니다. 사실, 강력한 암호만 사용한다면 계정 이름과 상관없이 공격이 성공하지 못하도록 할 수 있습니다.

많은 보안 지침에서 Administrator 계정 이름 바꾸기를 권장한다는 것은 분명하지만 그렇다고 중요하거나 올바른 보안 조치가 될 수는 없습니다. 적절한 위험 관리 결정을 내리기 위한 능력에 방해가 될 뿐입니다. 보안 지침에서는 별 의미가 없는 설정을 매우 자주 요구하고 있으며, 많은 경우 해당하는 설정이 존재하지도 않습니다. 결과적으로 보안 분야에서 진일보하려면 요구 사항을 한 단계 뛰어넘어, 실제로 문제를 분석하고, 완화 조치가 실제 의미가 있는지 여부를 평가해야 합니다. 여기에서 한 가지 중요한 사항을 염두에 두어야 합니다. 즉, 공격자는 자체 기능을 수정할 이유가 충분하지 않은 기능을 공격 대상으로 삼는다는 것입니다. 기능을 수정하지 않으면 공격을 받을 수 있다고 충분히 예상되는 경우에만 해당 기능을 수정해야 합니다.

강력한 암호를 사용할 경우 계정 이름 변경 여부에 상관없이 공격 성공 가능성은 사실상 0입니다. 따라서 강력한 암호만 가지고 있다면 계정 이름을 바꿀 특별한 보안상의 이유가 없습니다. 더욱이, 컴퓨터는 조정 및 변경이 적을수록 더욱 안정적이라는 저와 같은 원칙(사실 합당한 사실임)을 가지고 있다면 Administrator 계정 이름을 바꿀 이유가 더더욱 없어집니다.

낮은 가치의 완화 조치로 초점 이동. 낮은 가치의 은둔 보안 방식을 통한 완화 조치에서의 한 가지 문제점은 조직의 초점이 높은 가치의 완화 조치에서 낮은 가치로 이동할 위험이 있다는 것입니다. 예를 들어, Administrator 계정 이름을 바꾸는 데 투자한 시간과 노력은 다른 작업에 사용할 수 없습니다. 다른 작업이 Administrator 계정 이름을 바꾸는 것보다 높은 가치를 제공한다면 조직은 기회를 잃는 것입니다. 현실적으로 들리지 않을 수 있지만 50,000개의 Administrator 계정 이름을 바꾼다고 상상하면 이해가 갈 것입니다.

더 큰 문제는 낮은 가치의 완화 조치가 마련되면 조직의 리더들이 안심하게 될 가능성이 크다는 것입니다. 경영진에서 은둔 보안 방식을 통한 완화 조치가 가져오는 낮은 가치를 항상 이해하는 것이 아니므로 추가 단계를 취하지 않을 수도 있습니다. 경영진에서 구현되는 완화 조치의 가치를 이해하기 위한 시간과 노력을 투자한다면 위험을 충분히 피할 수 있겠지만 그렇지 못할 경우 이로 인해 조직에 큰 위험이 따를 수 있습니다.

높은 관리 비용. 마지막으로 완화 조치가 얼마나 잘 구현되었는지에 따라 관리 비용이 증가할 수 있습니다. 간단히 GPO(그룹 정책 개체)를 설정하여 Administrator 계정의 이름을 바꾼다면 비용은 매우 낮습니다. 모든 사람이 이름을 알고 있으므로, 구현 비용도 거의 들지 않습니다. 하지만 이미 언급한 대로 계정이 있는 모든 사람이 Administrator 계정 이름이 무엇인지 알기 때문에 이러한 조치로 인한 효과는 매우 미약합니다. 따라서 이 완화 조치에서 최대한의 효과를 얻으려면 여러 호스트에서 서로 다른 이름을 사용해야 하고, 이 경우 시스템 관리 비용이 크게 증가하게 됩니다.

대신 passgen(protectyourwindowsnetwork.com/tools.htm)과 같은 도구를 사용하여 네트워크 전체의 모든 Administrator 계정에 대해 100자의 완전한 임의 암호를 설정하고, 일상적인 관리를 위해서는 다른 계정을 사용하는 것이 더 좋습니다. Administrator 계정을 순전히 재해 복구용(Windows Small Business Server 2003 제외)이라고 생각하면 네트워크 관리 시스템에 전혀 영향을 주지 않을 것입니다. 더욱이, 공격자는 Administrator 계정에 대한 암호를 정확하게 추측하는 것보다 태평양 밑바닥에서 바늘을 찾을 확률이 더 높습니다. 대신 강력하고 고유한 암호에 초점을 맞추는 것이 스크립트 공격으로부터 더 안전합니다.

위험 관리의 중요성

거의 모든 은둔 보안 방식의 조치는 이와 같은 방식으로 분석할 수 있습니다. 어떤 방식이든 각각 장단점이 있고, 한 조직에 올바른 방식이 다른 조직에는 그렇지 않을 수 있습니다. 결국 모든 것은 위험 관리의 문제입니다. 위험이 솔루션 구현 비용을 능가합니까? 정보 자산을 보호하기 위해 내리는 모든 결정은 정보에 근거한 위험 관리 결정이어야 하고, 양자 택일일 가능성은 낮습니다.

사실 몇 가지 결정은 이미 내려졌습니다. 예를 들어, 신용 카드 정보를 암호화하지 않거나 신용 카드 검증 코드를 저장하지 않도록 선택할 수 있지만 이 두 경우 모두 결제 수단으로 신용 카드를 받을 자격이 사라지게 됩니다. 이러한 결정에 대한 사업상 부정적인 영향은 실제로 선택의 여지가 없다는 것입니다. 즉, 분명 위험 관리 결정이지만 누구나 내릴 수 있는 쉬운 결정입니다.

마찬가지로, 제정신을 가진 사람이라면 개방형 무선 네트워크를 실제 상점 내부 네트워크의 백엔드에 연결하지는 않을 것입니다. 하지만 그렇다고 이 결정이 위험 관리 결정이 아니라는 의미는 아닙니다. 위험 관리 결정입니다. 선택을 할 수 있고, 선택을 한다면 그에 따른 결과도 감수해야 합니다(애석하게도 실제로 이렇게 하는 사람은 없는 것 같음).

여기서 취해야 할 중요한 단계는 해결해야 할 문제, 해당 문제에 대해 제안된 솔루션 및 각각의 장단점을 분명하게 파악하는 것입니다. 이렇게 되면 정보에 근거한 위험 관리 결정을 내리는 데 필요한 정보를 보유하게 됩니다. 이러한 정보 없이는 직감에 의존하여 결정을 내리게 되고 거의 현명한 결정으로 이어지지 않습니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서, 정보 관리 시스템 분야 박사 학위와 20여 년의 보안 관련 경력을 가지고 있는 Enterprise Security 영역의 Microsoft MVP입니다. Jesper의 최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.

Roger Grimes(CPA, CISSP, MCSE: 보안)는 Microsoft ACE 팀의 선임 보안 컨설턴트로서, 컴퓨터 보안에 대한 8권의 저서를 집필 또는 참여했으며 200건 이상의 잡지 기사를 기고했습니다. 보안 컨퍼런스 발표자로 많은 활동을 하고 있으며 InfoWorld 보안 칼럼니스트입니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..