[HIP①] 운영체제의 위험, 사전보호만이 최선이다
상태바
[HIP①] 운영체제의 위험, 사전보호만이 최선이다
  • NETWORK TIMES
  • 승인 2002.12.12 00:00
  • 댓글 0
이 기사를 공유합니다

운영체제의 위험, “사전보호만이 최선이다”
시스템 자원으로의 액세스 제한 … ‘행동·서명·사용자’ 등 세 가지 정책 기반 모델
‘예상하지 못하는 것을 예상하라’는 말은 진부해 보일지는 몰라도 역시 멋진 네트워크 보안 전략임에는 틀림이 없다. 업체와 보안 전문가들은 그렇지 않다고 주장하고 있지만 이들이 당신의 존재를 위태롭게 하는 다음 번 위협을 당신보다 더 잘 확실하게 집어낼 수 있는 것은 아니다. 물론 방화벽, VPN, 바이러스 스캐너 및 IDS와 같은 보안 장비들을 설치하고, OS 강화와 향상된 인증 및 액세스 제어 등과 같은 운영적 프로시저를 이행함으로써 노출도를 낮출 수는 있다. 하지만 직원과 다른 사용자들에게 서버 액세스를 제공해야 하는 것이 당신의 현실이며, 인터넷에 문을 활짝 열 때 공격의 위험은 독버섯처럼 번져갈 것이다. 여기에는 사후 대응적 방안보다도 사전에 이것을 막아줄 수 있는 도구가 필요하며, 이것이 바로 HIP의 존재 이유다.

몇 가지 분명한 사실 가운데 한 가지는 모든 제품에는 보안 취약성이 있다는 것이다. 누군가가 그 취약성을 발견하게 될 것이다. 발견한 사람이 그 취약성에 대해 업체측에 말을 하든 하지 않든, 이것을 뿌리든 아니면 혼자 간직하고 있든 관계없이, 업체에서 구멍을 막을 패치를 내놓고 회사의 관리자가 그 패치를 설치할 때까지는 당신은 공격에 노출된 상태다.

패치라는 주제에 대해서는 이 말을 반복하라. ‘패치 사이클은 절대 놓쳐서는 안 된다.’ 그러나 패치와 핫 픽스는 생산 서버에 적용시키기 전에 반드시 테스트해서 기존의 기능성을 망가뜨리지 않는지 확인해야 한다. 따라서 프로그램이 제대로 있다고 해도 서버는 패치 업데이트 곡선에서 며칠, 혹은 몇 주가 뒤쳐질 수도 있다.

패치는 중요하긴 하지만 대응적 방안이다. 문제는 보안을 염두에 두고 제작된 소프트웨어가 너무 적다는 것이다. 범용 운영시스템들은 주로 다중 사용자를 관리하고 시스템 자원으로 무리 없는 액세스를 제공할 수 있게 제작되었다. 파일과, 사용자의 소유권이나 그룹 승인에 있는 허가 비트나 ACL(Access Control List)을 이용할 경우, 다른 사람들보다 더 많은 액세스를 갖게 되는 사람들이 있다. 예를 들어, 유닉스에서의 루트 사용자나 윈도 NT/2000에서의 관리자는 자원으로 거의 제한 없는 액세스를 할 수 있다.

보다 중요한 것은, 많은 시스템 서비스가 고도의 특권 사용자로서 실행된다는 것이다. 각 서버는 한정된, 그리고 종종 정의가 가능한 자원 세트만 있으면 적절히 기능하지만, 필요한 자원으로의 서비스 액세스를 제한할 수 있는 방법은 없다. 이런 서비스들은 서버로의 직접 액세스를 제공하며, 따라서 조직 내 다른 곳의 호스트 OS들은 취약성 있는 프로그램으로부터 보호될 필요가 있다.

미리 보호하라

고의적인 공격으로부터 서버를 사전에 보호할 수 있는 수단이 필요하다. 호스트 침입 방지(Host Intrusion Prevention)는 바로 이것을 해주기 위해 나온 개념이다. HIP 제품은 서로 다른 다양한 방안들을 이용해 시스템 자원으로의 프로그램, 혹은 사용자 액세스를 제한함으로써 빈약하게 쓰여진 코드의 혜택을 누리는 공격들로부터 기반 OS를 지켜준다.

예를 들어 원격 액세스를 주는 대부분의 공격들은 원격 사용자를 대신해 서버가 명령어를 실행하게 하는 방법을 이용한다. 공격이 버퍼 범람이거나 비정상 URL이라면 문제가 되지 않는다. 문제의 지점은 명령어가 원격으로 실행되는 곳이기 때문이다. 예를 들어 어떠한 서비스 팩이나 핫 픽스도 적용되지 않은 마이크로소프트 IIS(Internet Information Server) 웹 서버에는 IIS 프로세스인 inetinfo.exe를 통해 명령어 셸이 실행될 수 있는 길이 너무도 많다. 하지만 inetinfo.exe가 셸을 실행시키지 말라는 법은 없다.

공격들이 종종 셸을 호출한다는 사실을 알고, inetinfo.exe가 셸을 불러낼 수 있으면 안 된다는 사실을 아는 사람이라면 이제 보안 정책을 확실하게 주장할 수 있을 것이다. HIP 제품들은 이런 정책을 강행시킨다.

HIP는 비교적 새로운 보안 영역이며, 테스트한 제품에 대해 철저한 보안 감사는 하지 않았지만, 우리는 서버를 원격으로 공격해 보았으며, 공격자가 했을 법하게, 그리고 관리자나 루트로서 로그온해 있는 둘 다의 경우를 시험해 보았다. HIP 애플리케이션이 설치되고 적절히 구성된 시스템은 침입에 성공하지 못했다. 다음 번에는 공격자가 어떤 공격을 꿈꿀지 알 수가 없기 때문에, 이런 제품이 공격 불가침(attack-proof)이라고 말할 수는 없지만, 자기들이 주장하는 보호는 확실하게 제공해 주었다.

커널 레벨 모듈로 설치

대부분의 HIP 웨어들은 커널 레벨 모듈(Kernel Level Module)과 공유 라이브러리 교체물(Shared Library Replacement)로서 설치된다. HIP는 애플리케이션에서 OS로 시스템 호출을 트래핑(trapping)함으로써 작동된다. 시스템 호출이 커널에 도달하기 전에 이들을 트래핑함으로써 HIP 애플리케이션은 자신의 정책에 대조해 호출을 처리해서 이것을 거부하거나 계속되도록 허용할 수 있다. 테스트한 어떤 제품도 보안 OS를 설치하도록 요구하지 않았다.

아거스 핏불(Argus Pitbull)은 시스템 호출을 트래핑하는 대신 시스템 호출 코드를 변경시켜 자신의 정책 시행을 포함시키도록 했다. 어떤 경우든 시스템 호출은 먼저 HIP 제품에 의해 처리되고 그 정책에 대조되었다. 허용될 경우 호출은 통과되어 커널로 전달된다. 그렇지 않고 거부될 경우에는 애플리케이션으로 통보된다. 개별적인 규정들도 또한 로깅이 되기 때문에 관리자가 애플리케이션이나 사용자 활동을 추적할 수 있다.

정책은 애플리케이션이나 사용자가 파일 및 네트워크 포트와 같이 어떤 자원들로 액세스할지, 그리고 애플리케이션이나 사용자가 어떻게 이들에게 액세스할 수 있는지(읽기, 쓰기, 혹은 실행)를 확실히 규정한다. 사용자 기반 액세스 제어를 이행하는 HIP 제품은 심지어 루트 및 관리자의 권한을 제거할 수도 있다.

행동 기반 모델

HIP 업체들은 세 가지 기본 모델을 이행하고 있는데, 그것은 각각 행동 기반 정책, 서명 기반 정책, 그리고 사용자 기반 정책이다. 어떤 모델로나 유사한 기능성을 얻을 수 있지만, 그 개념은 매우 다르다. 세 가지 경우에서 모두 이런 제품들은 애플리케이션을 부당 이용하는 공격으로부터 OS를 보호해주는 게 목적이라는 사실을 이해하는 것이 중요하다. 이들은 누군가 웹 애플리케이션을 만지작거려 SQL 투입시킴으로써 데이터베이스를 복제하려 한다든가 하는, 애플리케이션과의 상호작동을 이용하는 공격을 막지는 못할 것이며, 액세스를 가졌어야 하는 파일로 서버가 액세스하는 것을 막지도 않을 것이다.

행동 기반 모델에서는 애플리케이션이 실행되는 시간 동안의 정상적 행동을 규정해야 한다. 예를 들어 리눅스 상의 아파치는 자신의 디렉토리 루트에서 파일을 읽고 쓰며, 그 구성 파일을 읽고, 자체의 실행 가능 파일을 읽고 실행하고, 공유 라이브러리를 읽고, 웹루트(webroot)의 파일들을 읽고, cgi-bin 파일을 실행하고 포트 80 및 443에 묶을 필요가 있다. 적절히 행동하는 서버는 그 이상의 어떠한 액세스도 필요로 하지 않기 때문에, 그 액세스를 제한하는 정책은 모든 비정상적인 행동을 차폐해준다. 물론 한 서버에서는 정상적인 것이 다른 데서는 아닐 수도 있기 때문에, 각각의 서버가 프로파일링 되어야 하며, 시행 가능한 정책을 규정하기 이전에 먼저 정상적 행동이 무엇인지를 철저히 파악하고 있어야 한다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.