▶ 보안 제품 리뷰/:: ESET

Eset Smart Security 5 간단 리뷰 (3) - 악성코드 진단 (HIPS)

물여우 2012. 1. 6. 08:30
반응형
새롭게 추가된 행동 기반 진단 기능인 HIPS를 살펴봅니다.



5. HIPS - 행동 기반 진단

ESET의 HIPS는 관련 글의 링크에서 정리한 좁은 의미의 HIPS와 정확하게 일치하는 기능입니다.

'Host-based Intrusion Prevention'의 약자인 HIPS는 쉽게 말해 시스템에서 일어나는 주요 이벤트를 감시하여 악성 행위를 차단하는 기능입니다. 즉, 파일을 '실행' 한다는 행위가 반드시 일어나야만 합니다.
실행된 파일의 이벤트를 차단한다는 점에서 일반적으로 접근 및 수정 생성시에 진단하는 시그니처 진단과는 차이가 발생합니다. 자세한 것은 관련글의 링크를 참고 바랍니다.


5-1. HIPS 일반 설정

HIPS의 설정은 아래와 같습니다.

필터링 모드는 쉽게 말해 사용자 처리와 자동 처리를 설정하는 항목입니다. 각각의 항목의 차이점은 아래와 같습니다.

ㆍ규칙이 포함된 자동 모드 : 일반적인 자동 모드로 내부에 설정된 규칙을 제외한 나머지 모두 허용
ㆍ대화 모드 : 일반적인 사용자 모드, 모든 것을 사용자가 관리
ㆍ정책 기반 모드 : 특별한 자동 모드, 설정된 규칙을 제외한 모든 이벤트 차단
ㆍ학습 모드 : 해당 모드 시 일어나는 모든 이벤트에 대한 '허용' 규칙 생성

규칙 모드는 4개가 있지만 실제 환경에서 사용할만한 것은 규칙이 미리 포함된 자동 모드와 대화 모드 이 두 가지입니다.

언급되지 않은 모드 중 정책 기반 모드는 일반적으로 이벤트가 차단이 되기 때문에 미리 규칙을 생성해야하는 단점이 있습니다. 일반 사용자들이 사용하기에는 미리 작업을 해야할 부분이 매우 많아 추천하기 어렵습니다. 

학습 모드는 UI 문제로 추천하기가 어려운데, 기본적으로 UI가 다소 불편하게 구성되어 있습니다. 학습 모드 자체는 이전에 리뷰한 Outpost의 학습모드와 비슷합니다. 차이점은 Outpost의 학습 모드가 UI상 쉽게 다른 모드로 변환이 가능하며, 일종의 편의성을 위한 기능으로 작동했다면 ESET의 경우 그런 편의성이  매우 떨어진다는 점입니다. UI가 일반 모드 변환을 환경 설정으로 접속해야만 변경 가능하다는 점이 첫 번째 불편한 점이고, 특정 기한이 지나면 해당 모드의 규칙이 비활성화되고 다시 규칙을 설정해야 한다는 점이 두 번째 불편한 점입니다. 마지막으로 학습 모드에서 설정한 규칙이 사용자가 직접 수동으로 설정한 규칙보다 하위에 있다는 점이 불편함을 가중 시킵니다. 학습 모드를 프로그램 설치 시와 같은 특정한 항목에서 사용할 수 있지만 UI 자체가 불편함으로 사용자가 직접 규칙을 하나하나 만드는 것이 더 편합니다. 

학습 모드를 설명하며 지적한 UI의 단점은 앞으로 계속 언급될 ESET의 HIPS 기능의 단점입니다.

이 리뷰에서는 최대 보안 수준 설정이 가능한 대화 모드를 통해 진행됩니다. 고급 설정은 아래와 같으나 대화 모드에서는 특별히 필요가 없습니다.



5-2. HIPS 규칙 구성 관리

아래는 HIPS의 '규칙 구성' 항목입니다. 사용자가 설정한 규칙들이 나타납니다.

자세히 살펴보시면 아시겠지만 동일한 프로세스에 대해 매우 많은 수의 규칙이 나타나는 것을 알 수 있습니다. 각각의 규칙들이 우선 순위 등이 나뉘어 진 것도 아니고, 그저 규칙 설정 과정에서 개별적으로 생성된 것 뿐입니다. 앞서도 UI의 단점을 언급했는데, 위와 같은 경우는 규칙 생성 및 관리 측면에서 실패한 또 하나의 예시입니다. ESET의 HIPS UI는 두고 두고 언급할 문제 중의 문제입니다. 카스퍼스키와 코도 등 앞서 HIPS 기능을 도입한 제품들에 비하면 규칙 설정 및 관리 UI가 매우 불편하며 비효율적으로 구성되어 있습니다.

ESET의 HIPS는 아래 4 가지 항목으로 구성되어 있습니다.

ㆍ소스 애플리케이션 : 규칙을 적용하는 어플리케이션 모음
ㆍ대상 파일 : 위 어플리케이션이 수정 또는 생성, 접근할 파일 및 수정 작업 설정
ㆍ대상 애플리케이션 : 위 어플리케이션이 수정 또는 접근할 어플리케이션 및 수정 작업 설정
ㆍ대상 레지스트리 : 위 어플리케이션이 수정 또는 접근할 레지스트리 및 수정 작업 설정


(1) 소스 애플리케이션

아래는 '소스 애플리케이션' 항목입니다.

참고로 우측의 '기타 설정' 부분의 규칙이 활성화됨 항목은 해당 항목이 체크되어 있어야만 실제로 규칙이 적용됩니다. 소스 어플리케이션의 특징 중 하나는 서로 다른 프로세스를 여러 개 추가할 수 있다는 점입니다. 이 경우 서로 다른 프로세스를 같은 규칙으로 제어할 때 유용할 수도 있지만, 일반적으로 프로세스별로 규칙이 다를 때가 대부분이며, 대부분 같더라도 일부 규칙은 다를  때가 많기 때문에 의미있는 항목은 아닙니다.  비교 대상이 되는 카스퍼스키의 계층 구성이나 그룹 항목처럼 편의성 등에 도움되기는 매우 어렵습니다.


(2) 대상 파일

아래는 특정 파일에 대한 작업 이벤트를 관리하는 '대상 파일' 항목입니다.

'파일 삭제', '파일에 작성', '디스크에 직접 접근', '전체 후크 설지', '드라이버 로드' 등 5개의 항목으로 구성되어 있습니다. '추가' 버튼을 통해 특정 파일을 추가할 수도 있고 아무 파일을 적용하지 않고, '모든 작업에 사용' 체크를 통해 모든 파일에 대해 허용/차단할 수도 있습니다.


(3) 대상 애플리케이션

아래는 다른 어플리케이션 파일이나 프로세스의 수정 접근을 관리하는 '대상 애플리케이션' 항목입니다.

'다른 애플리케이션 디버깅', '다른 애플리케이션에서 이벤트 가로채기', '다른 애플리케이션 종료/일시 중시', '새 애플리케이션 시작', '다른 애플리케이션 상태 수정' 등 5개의 항목으로 구성되어 있습니다.
역시 추가 버튼을 통해 특정 파일을 포함시킬 수 있습니다.


(4) 대상 레지스트리


마지막으로 레지스트리 관리를 위한 '대상 레지스트리' 항목입니다.


특별한 것은 없지만 추가 항목에서 레지스트리 구조를 직접 보여주지 않고 윈도우 자체 레지스트리 에디트를 불러와 복사 기능을 사용해서 특정값을 추가하는 방식을 사용하고 있습니다. 자체적으로 해결해야하는 부분인데, 위와 같이 다소 복잡한 방법을 사용하는지 모르겠습니다.


참고로 각 메뉴마다 존재하는 '모든 작업에 사용' 항목은 이름 그대로 해당 작업 내역에 있는 모든 작업에 일괄적으로 적용시키는 것입니다.


(5) 규칙 구성 관리의 복잡함


아래 그림처럼 규칙 관리 항목은 작업 대상이 되는 파일·애플리케이션·레지스트리에 대한 권한 정보를 보여줍니다. 물론 사용자가 규칙을 생성함에 따라 하나의 규칙에 소스 애플리케이션의 프로세스에 대해 3가지 권한이 모두 적용될 수 있습니다. 그런데 앞서 언급한 것처럼 동일한 프로세스에 대해 하나의 규칙이 아닌 서로 다른 규칙들이 생성된 것을 볼 수 있습니다.

18개의 규칙이 나타난 웹마


예시를 든 위의 그림의 웹마는 무려 18개의 규칙이 생성됩니다. 사실 규칙 생성이 18개에서 그친 것도 규칙 생성 중간에 '모든 작업에 사용'을 이용해서 작업 내역을 일괄적으로 구성했기 때문입니다.

이러한 문제는 왜 나타날까요? 이유는 크게 두 가지가 있습니다.

첫 번째로 특정 작업에만 설정한 허용/차단 설정이 하나의 개별적인 규칙으로 나타나기 때문입니다. 즉, 하나의 작업 당 하나의 규칙이 생성되는 구조로 구성되어 있습니다. 아래와 같이 카스퍼스키처럼 하나의 규칙에서 모든 작업별로 허용/차단 설정이 개별적으로 가능하다면 ESET처럼 새로운 이벤트마다 규칙이 계속 생성될 필요가 없습니다. 



두 번째로 어떤 작업에 설정한 허용/차단 설정이 다른 메뉴 항목의 작업 종류에 일괄적으로 적용되기 때문입니다. 
예를 들어 대상 파일 항목의 특정 작업을 허용하는  어떤 규칙을 설정하였다면, 대상 애플리케이션과 대상 레지스트리 다른 항목에서 어떤 규칙을 생성할 때 반드시 '허용'만을 사용해야 합니다.

허용 설정이 일괄 적용 되는 모습


위와 같은 문제들로 인하여 기존에 없었던 새로운 이벤트가 나타날 때마다 규칙도 새롭게 생성되는 것입니다.

많은 수의 규칙이 생성되는 것은 퍼포먼스에도 영향을 주지만[각주:1], 관리 측면에서도 매우 불편합니다. 어떤 규칙을 수정하기 위해서는 일일이 모든 규칙을 찾아봐야하기 때문입니다. 다음 버전에서는 반드시 개선되어야할 부분입니다.  



5-3. HIPS 진단창


자 이제 HIPS의 진단창을 살펴보도록 하겠습니다. 아래는 기본적인 HIPS의 진단 창입니다.


기본적으로 발생된 이벤트에 대해 허용/차단 항목이 존재합니다. 그런데 아래에 무려 5가지의 규칙 관련 설정 체크 박스가 있습니다.

ㆍ규칙 생성 : 규칙 관리 항목에 규칙을 생성하여, 허용/차단 처리를 지속적 유지
ㆍ이 프로세스에 대한 이 동작을 일시적으로 저장 : 따로 규칙을 생성하지 않음
ㆍ이 애플리케이션에만 유효한 규칙 생성 : 소스 애플리케이션으로 적용
ㆍ작업에만 유효한 규칙 생성 : 대상 작업에 대한 규칙 생성, 체크 해제시 규칙 생성이 제대로 안 됨
ㆍ대상에만 유효한 규칙 생성 : 작업을 적용받는 대상 애플리케이션 지정


만약, 앞서 규칙 관리 항목에서 언급한 '모든 작업에 사용'을 해당 팝업창에서 설정하기 위해서는 어떻게 해야할까요? 상당히 복잡합니다.

'규칙 생성''작업에만 유요한 규칙 생성'을 체크하고 아래 작업 내역에서 '모든 파일 작업 또는 모든 애플리케이션 작업 또는 모든 레지스트리 작업'을 선택


규칙 생성하는 것부터 머리가 아프지 않습니까?

규칙 생성을 체크하지 않으면 이름 그대로 규칙이 생성되지 않아 프로세스가 특정 이벤트를 동작할 때마다 팝업창이 나타나서 '허용/차단'을 설정해야합니다.
 
'작업에만 유효한 규칙 생성'을 체크하지 않으면, 작업 내역에 아무런 표시없이 전체 이벤트에 대해서 허용/차단만 설정됩니다. 즉, '모든 작업에 사용'이 일괄적으로 다른 메뉴의 작업에도 적용된다 보면 됩니다.

이런 복잡함은 규칙 관리의 UI 구성을 팝업창에서 구현해야하기 때문입니다. ESET은 기본적으로 소스와 대상을 각각 설정하고, 각 대상별로 작업을 개별적으로 부여할 수 있기 때문에 세부적인 설정이 가능합니다. 저의 일반적인 기준을 생각한다면 이는 장점으로 봐야합니다. 하지만 앞서 언급한 규칙 관리의 잘못된 UI 덕분에 규칙 구성에 드는 노력에 비해 얻을 수 있는 효율성이 매우 적습니다.

HIPS 기능 자체를 어려워하는 사용자들이 대다수인데, 위와 같이 UI가 복잡하게 구성되는 점은 매우 큰 단점으로 생각됩니다.
 



HIPS 기능을 간략하게 살펴봤습니다. UI의 단점도 주로 지목했는데, 아직 초기 기능이라서 그런지 어플리케이션 로딩이나 시스템 파일 로딩 시에 딜레이가 종종 발생합니다. 특히, explorer.exe나 다른 시스템 파일의 특정 작업에 HIPS가 반응하면 프리징이라 오해할만한 딜레이가 간혹 발생합니다. 호환성 부분을 많이 개선시켜야할 듯 합니다.

그렇다면 실제 중요한 성능은 어떠할까가 매우 궁금해지는데, Matousec의 결과를 살펴볼 것도 없이 개인적인 테스트상에서도 상당히 실망스런 결과를 보여주었습니다. 테스트를 위해 비교적 최근에 웹사이트를 통해 유포된 악성코드를 실행시켜봤는데, 악성코드가 시도하는 시스템 파일(ws2help.dll) 수정을차단하지 못했습니다.


                                      서로 다른 악성코드를 통한 실험, 모두 차단 실패

실제로 변형된 'ws2help.dll' 파일은 아래와 같습니다. 

이 악성코드가 실행될 때 나타난 HIPS 창은 아래 하나입니다. 이것을 차단해도 이미 시스템 파일은 변조되었고 악성 행위가 가능하게 됩니다.

물론, 시그니처 진단 항목에서 아래와 같이 최종 악성코드는 진단하지는 못했지만 변형된 'ws2help.dll' 을 진단합니다. 하지만 파일 변경 후 새롭게 생성될 때 진단하는 것이라 실제 시스템에서 어떤 문제가 발생할지는 모릅니다.[각주:2]

 

타 제품과 자꾸 비교하게 되는데 코모도는 악성코드 패치를 확실하게 차단하고, 카스퍼스키는 악성코드로 판단 실행 자체가 되지 않습니다.[각주:3] 첫 술에 배부를 수는 없겠지만, 파일 생성과 접근이라는 작업 내역에 포함된 기본적인 행위를 차단하지 못한다는 점은 매우 아쉬운 부분입니다. 이전에 살펴본 Matousec의 결과에서도 좋은 점수를 받지 못했는데, 위에서 테스트 한 것처럼 실제 환경에서는 코모도나 카스퍼스키 수준의 HIPS 성능은 나오지 않을 듯 싶습니다.

참고로 위 테스트는 사용자 처리 상태에서 진행되었습니다. 일반적으로 행동 기반 진단에서 자동 처리가 사용자 처리에 비해 보안 수준이 떨어지는 것을 고려해볼 때 자동 처리에서의 성능은 더욱 나쁨을 알 수 있습니다.


개인적으로 가장 기대했던 기능이지만 사용성도 성능도 그리 좋지 못해서 상당히 아쉽습니다.


- 이상입니다.


 

  1. 시스템 퍼포먼스도 소폭 떨어지지만 규칙창을 열 때의 딜레이가 상당합니다. [본문으로]
  2. 해당 파일을 정상 파일로 제대로 복구하지 않았을 시, 지속적인 재부팅 현상이 나타납니다. [본문으로]
  3. 카스퍼스키의 경우 강제로 실행을 했을 때 'ws2help.dll'를 차단하지는 못합니다. 그러나 그 외 다른 부분을 모두 차단하기 때문에 실질적인 피해를 막을 수 있습니다. [본문으로]
반응형