이중 인증 기반 명령어 실행 통제 기술의 핵심 (참조모니터 : Reference Monitor)

보안 운영체제라 부르는 Secure-OS를 이용한 서버의 보안 강화와 관련된 이슈는 아직까지 보안 시장에 무르익지 않고 있습니다. 하지만 2011년 농협 보안사고와 다수의카드사 개인정보 유출 사고에서와 같이 대형 보안 사고는 대부분 “서버 운영체제에 개발자 혹은 관리자 권한”으로 접속한 내부 사용자 권한을 가진 사람들에 의해 발생하고 있기 때문에 실제 정보가 저장되고 가공되며 서비스 되고 있는 서버 내부에서의 위협에 대한 통제 방법론에 대한 이슈는 분명 지속적으로 이슈가 제기될 것입니다.

서버 내부의 개발자와 관리자에 대한 행위 통제는 불가능 한가?

당연히 가능합니다.

하지만 많은 IT 종사자는 물론 보안 전문가들도 IBM, HP, Oracle(구 Sun Microsystems)와 같은 상용 유닉스 운영체제와 리눅스 운영체제 그리고 MS의 Windows 운영체제 내의 해킹에 악용되는 중요한 관리자 명령어와 자체 취약점에 대해 “어떻게 통제할 것인가”에 대한 통제 방법을 알지 못하고 있습니다.

그 이유는 엄청난 양의 정보가 실제로 저장되고 처리되는 서버 운영체제에 대한 지식과 그 서버 운영체제 상에서 실행되고 서비스 되는 데이터베이스관리시스템(DBMS) 그리고 미들웨어, 웹서버 등의 “서비스” 애플리케이션의 상호 연동에 대해 제대로 이해하고 SecureOS를 통해 보호정책을 수립하고 적용할 능력을 갖고 있지 못하기 때문입니다. 게다가 네트워크 보안과는 달리 “보호정책”을 적용할 경우 즉각적으로 “서비스 개발과 운영 및 관리의 불편함이 높아진다고 생각하기 때문에 서버 내부의 보안을 강화할 엄두를 내지 못하고 있는 형편입니다.

서버 내부의 보안을 강화해야 한다는 것에는 동의하지만 어떤 보안솔루션을 도입하고 “보호 정책”을 실제로 어떻게 적용해야할지를 알지 못하고 있는 것입니다.

서버 내부의 파일과 명령어를 해킹으로부터 보호하기 위해서는 어떤 솔루션이 필요한가 ?

네트워크에 추가되는 장비(어플라이언스) 형태의 보안장비로는 서버 내부의 파일과 명령어을 해커의 위협으로 부터 보호할 수 없습니다. 윈도서버에서 자주 발생하는 악성코드 “파일”의 감염은 서버백신이나 서버 앞단에 설치된 침입차단 시스템이 제역할을 하지 못하기 때문에 불법적인 파일의 “생성”을 차단하지 못하는 것을 반증합니다.

웹의 취약점 공격을 받아 웹쉘이 업로드 되거나 소스파일이 변조되어 java script 공격코드가 삽입되며 인젝션 공격을 받아 해커가 서버에 공격파일을 업로드하고 실행할 수 있는 것 또한 침입차단 시스템이나 웹방화벽이 제 역할을 수행하지 못하기 때문입니다.

종종 홈페이지가 변조되어 백방으로 수소문한 끝에 RedCastle을 도입하거나 타 보안 제품을 운용하다가 파일에 대한 접근통제 정책을 제대로 구현하지 못해 RedCastle의 설치를 요청하는 경우를 볼 수 있습니다. 이런 경우 도입하려는 솔루션이 다음의 조건을 충족하는지 검토하여야 합니다

서버 내의 파일과 명령어에 대한 생성/수정/삭제/실행을 통제하고자 할 때 검토 사항

1. 커널기반의 파일 접근 통제 솔루션인가?

운영체제 커널 기반이 아닌 네트워크에 장비 형태로 추가되는 솔루션은 서버의 명령어와 파일에 대한 유출 및 변조를 제대로 방어할 수행할 수 없습니다.

2. 보호 대상 명령어 및 파일 지정을 위한 와일드카드를 지원하는가?

서버의 수많은 종류의 파일을 지정하기 위해 일일히 디렉토리를 지정하거나 개별 파일을 모두 등록해야 해서는 다양한 파일 접근 통제 및 명령어 실행 통제를 수행할 수 없습니다. 또한 방화벽이나 백신 또는 IPS, WIPS 등 네트워크의 패킷 분해/검사 방식의 솔루션이나 블랙리스트 방식의 접근통제를 수행하는 솔루션들은 알려진 공격만 차단할 뿐(그것도 100% 장담할 수 없지만) 보호 대상 파일이나 명령어에 대한 접근을 통제하지 못합니다.

3. 심볼릭링크, 하드링크, 알리아스 등 위험한 명령어 및 파일에 대한 우회 접근을 통제할 수 있는가?

서버의 운영체제 커널 수준에서 통제하지 않으면 이러한 파일에 대한 우회 접근 수단을 통제할 수 없습니다. SAC나 보안쉘 방식의 명령어 통제 솔루션은 명령어 및 파일에 대한 다양한 우회 접근 기법을 근본적으로 차단할 수 없습니다.

4. 서비스 및 서버의 안정성은 보장되는가?

당연히 서버에 설치되어 동작하거나 관리자/개발자/운영자의 서버 접속 세션을 모니터링하기에 안정성은 필수로 검증하여야 합니다. 안정성의 검증은 설치 사례를 통해 검증할 수 밖에 없습니다. 설치 및 구축 사례 중에서 은행, 보험, 증권, 인증기관 등 금융기관의 계정계 시스템에서 안정적으로 동작하는 사례를 검증하는 것이 가장 확실할 수 있습니다. 예를 들어 국민은행에 서버보안SW를 납품했다 하여 최고의 안정성을 요구하는 “계정계” 시스템에 설치한 것은 아닙니다. 국민은행의 계정계 시스템은 아직 메인프레임입니다. 메인프레임에는 현존하는 서버보안SW(보안OS)를 설치할 수 없기 때문입니다. 이와 같이 “고객사”만 확인하는 것 보다는 그 고객사의 “어느 시스템(서버)”에 적용되어 있는가를 확인하여야 합니다.

5. 실제 해킹 방어 사례는 있는가?

보안 솔루션은 내부통제의 목적도 있지만 실제 해킹을 방어할 수 있어야 합니다. 실제 해킹의 방어 사례와 방어한 감사로그를 살펴보면 해당 보안제품의 보안 수준을 가늠할 수 있습니다.

6. OTP/ARS 등의 2차 인증과 연계하여 자연인 기반의 명령어 통제가 지원되는가?

root, oracle, administrator 등 공용계정으로 다수의 개발자/운영자가 접속하여 장애 및 해킹에 악용되는 명령어를 실행할 경우 실제 사람(자연인)을 식별하는 것이 불가능합니다. 따라서 이중 인증(OTP/ARS) 시스템(보러가기)과 연계하여 실제 사용자를 식별하여 명령어 실행 시에도 자연인 기반의 명령어 통제가 가능해야 합니다. 즉 root로 로그인한 홍길동은 shutdown 명령의 실행이 가능하지만 root로 로그인한 다른 사람들은 shutdown 명령어 실행이 불가능하도록 “정책(Policy)”의 구현이 가능해야 합니다.

명령어 통제 및 파일 접근 통제의 핵심 기술 – 참조모니터(Reference Monitor)

서버보안SW(보안OS)는 커널 수준에서 동작하는 참조모니터로 구현되어야 합니다. 왜냐하면 파일에 대한 읽기/수정/생성/삭제/실행 등의 접근은 매우 다양한 방법에 의해 이루어지며 우회 접근도 가능하기 때문에 모든 파일에 대한 접근이 실제로 이루어지는 시스템콜 수준에서 통제하지 않을 경우 제대로 된 파일접근통제, 명령어 실행 통제가 이루어질 수 없기 때문입니다.

명령어의 실행과 파일의 생성/읽기/수정/실행/삭제에 대한 통제를 가능하게 하는 운영체제 커널 수준에서의 참조모니터는 국내 위키에서 찾아 볼 수 없을 만큼 정보가 부족합니다. (영문 위키 : 참조모니터(Reference Monitor))

참조 모니터의 역할은 그 이름에서도 알 수 있듯이 객체(파일, 프로세스, 계정 등의 자원)에 주체(프로세스(명령어 포함), 계정)가 접근(읽기/쓰기/실행/수정/삭제 등등)할 때 발생하는 모든 시스템콜(이벤트) 및 행위를 모니터링 하는 것입니다. 여기서 “모든”이 중요합니다. “모든” 행위를 가로채 검사(Validation)하지 못하면 우회가 가능하게 되고 우회 경로가 결국 취약점이 될 수 있습니다.

다만 “모든” 이벤트를 가로채는 것은 결코 쉽지 않기 때문에 얼마나 많은 이벤트를 검사할 수 있느냐가 보안 솔루션의 능력을 가늠한다고 볼 수 있습니다. 그런면에서 알려진 “공격패턴”을 기반으로 알려진 공격 기법에 의한 침해만 방어하는 대부분의 보안 솔루션들은 사실…. 제대로 개발된 보안 솔루션이라 하기엔 부끄러운 것이 사실입니다.

서버보안SW(보안OS)의 참조모니터에 대해서는 다음의 두 장의 그림으로 설명을 대체합니다. 글로 설명하자면 너무 길어지고 커널에 대한 제 지식이 많이 부족하기 때문에 그림으로 그 역할을 설명합니다.

1. 서버보안SW의 참조모니터(보안커널)가 운영체제 커널에 로딩되기 전의 Pure OS의 구조입니다.