[보안 시스템 관리 방안④] 침입탐지시스템
상태바
[보안 시스템 관리 방안④] 침입탐지시스템
  • 이용학 코코넛 기술본부 대리
  • 승인 2004.05.24 00:00
  • 댓글 0
이 기사를 공유합니다

침입탐지시스템(IDS)은 침입차단시스템과 달리 애플리케이션 계층에 대한 심화된 분석을 수행함한다. 물론 애플리케이션에서의 분석이라는 측면에서 애플리케이션 프록시 게이트웨이 방식의 침입차단시스템도 이러한 기능은 수행할 수 있지만, 성능 문제로 인해서 현재는 많이 사용되지는 않고 있다. 이번 연재에서는 IDS 관리에 있어서 겪게 될 대다수의 어려움, 그러한 어려운 점을 극복하기 위해 IDS 도입 시 고려해야 할 사항은 무엇인지를 이야기하고자 한다. <편집자>

지난 호에서 침입차단시스템에 대해 이야기했지만 최적의 침입차단시스템을 도입하고 그것을 잘 관리하는 것만으로 모든 보안은 해결됐다고 볼 수는 없다. 침입차단시스템은 침입차단시스템이 정책상 허용하는 서비스에 대해서는 보호할 수 없기 때문이다.

물론 URL 필터링, 액티브X, 자바 필터링과 같은 기능을 제공하기도 하고 CIS(Content Inspection Server) 제품군과의 연동을 통해 이러한 단점을 극복하려고 시도도 하지만 그것만으로는 많은 기대를 할 수 없다. 침입차단시스템 운영 시 염두할 점은 SMTP, DNS, WWW, 미디어 등과 같이 외부의 모든 클라이언트에 대해 연결을 허용할 수밖에 없는 서비스는 언제라도 공격의 위험을 갖고 있다는 것이다. 그리고 침입차단시스템은 기본적으로 애플리케이션 정보에 대한 검사는 수행하지 않기 때문에 그러한 공격에 대해 별다른 감사 로그조차 없이 무방비가 될 수 있고, 이 점을 극복하기 위해 침입탐지시스템(Intrusion Detection System, IDS)이 소개됐다.

IDS의 개념

IDS는 그 분석을 위한 자료 수집원에 따라 네트워크 기반 IDS와 호스트 기반 IDS로 나뉠 수 있으며 이 글에서는 네트워크 기반 IDS에 대해서 이야기하는 것으로 그 범위를 한정하겠다.

네트워크 기반 IDS는 네트워크 관문의 스위치에 포트 미러링의 형태나 TAP(Test Access Port)로 설치된다. 따라서 들어오고 나가는 트래픽을 모두 수집해 기존에 정의된 룰에 매칭해 이것이 침입인지 아닌지를 파악하고 침입이라면 관리자에게 여러 가지 방법을 동원해 통보한다.

방화벽과 가장 큰 차이라면 애플리케이션 계층에 대한 심화된 분석을 수행함으로써, 방화벽은 그 초점이 주로 네트워크 계층 정보에 대한 필터링을 수행한다는 점이다. 물론 애플리케이션에서의 분석이라는 측면에서 애플리케이션 프록시 게이트웨이 방식의 방화벽도 이러한 기능은 수행할 수 있으나 성능 문제로 인해서 현재는 많이 사용되지는 않고 있다. 그리고 IDS는 수동적인(Passive) 장비라서 네트워크에 영향을 미치지 않으며 패킷을 수집해 분석을 수행하고 차단보다는 탐지에 보다 더 초점을 맞췄다는 점이다.

IDS 운영의 어려움

IDS 솔루션을 실제 도입해 운영한 적이 있는 관리자라면 누구라도 처음에 많은 어려움에 부딪히게 된다. 일단 네트워크에 설치된 이후 수많은 로그 화면에 압도당하게 되며 어떤 것이 정말 위험하고 어떤 것이 무시해도 될 로그인지 알 수가 없다. 방화벽과 IDS를 도입해 구축이 완료되면 기업 내 보안 수준이 높은 수준으로 향상됐다고 생각하기 쉬우나 실질적으로 제품을 커스터마이징해 가면서 그러한 기대도 한풀 꺾이게 된다.

극단적으로 말해서 IDS를 설치해 처음 나타나는 로그의 90%가 의미 없는 오탐지라면, 오탐지가 아닌 나머지 10% 정도만이 실질적으로 의미 있게 봐야 할 공격이다. 그리고 IDS는 침입을 막아주는 것보다는 탐지를 통한 사후 분석의 개념이 강하기 때문에 24시간 그것을 지속적으로 모니터링하면서 실시간으로 대응할 보안 전문가의 노력이 없다면 해킹은 막을 수 없다.

1. 관리적 어려움

① IDS 커스터마이징

IDS 도입 후 제일 처음 관리자가 부딪히게 될 어려움은 너무나도 많은 양의 로그다. 초기 설치된 채로 유지돼 1개월도 채 안 돼 수십 기가에 달하는 로그 서버의 하드디스크 공간을 잠식해 버린 업체를 본 적이 있다. 콘솔 상에서 너무나도 많은 이벤트가 빠르게 지나가는데 실질적으로 그만큼 많은 공격이 네트워크 상에서 이루어지고 있는 것일까? 그것은 확실히 아니다. 따라서 환경에 맞는 커스터마이징은 필수적이다. 커스터마이징 과정에서 겪게 될 어려운 점은 일반적으로 다음과 같다.

- 무의미한 룰에 대한 미탐지 설정

우선 관리자가 보안에 대해서 많은 지식을 가지고 있지 않다면 해당 룰이 의미 있는 공격인지 그렇지 않은지 알 수 없다. 그렇다고 해서 위험도가 낮다고 한 룰은 탐지하지 않도록 할 것인가? 이런 판단을 하게 되는 관리자도 종종 본 적이 있지만 위험도란 관점은 상대적인 개념이다. 즉 IDS 벤더에서 위험도가 낮다고 한 룰이 오히려 그 사이트에서는 가장 중요한 룰이 될 수가 있고, 위험도가 높다고 한 룰이 오히려 무의미한 룰일 수 있다. 따라서 그런 룰에 대해 IDS 벤더에서 위험도가 낮다고 해서 미탐지를 할 것이라고 결론 내리기에는 이르다.

- 파라미터 튜닝 설정

일부 서비스거부(DoS) 공격, 브루트 포스(brute force) 공격, 스캐닝(scanning) 공격 등은 특정 접근 시도가 특정 시간 내에 특정 회수 이상만큼 나타나면 경고를 발생하도록 설계돼 있다. 이러한 종류의 공격들은 설정 가능한 파라미터가 존재해 어느 정도 적절한 수치를 주느냐에 따라 효율적으로 탐지하거나 그렇지 않을 수 있다. 문제는 어느 정도 적절한 수치를 어떻게 결정하느냐 하는 것인데 그것이 쉬운 일이 아니다.

당연히 자사의 인터넷 회선으로 T1 라인을 사용하는 경우와 OC-3를 사용하는 경우가 그러한 파라미터는 다를 수밖에 없는데 IDS 벤더에서 자사의 환경에 맞는 최적의 값을 제안한 것은 아니다. 실제로 특정 IDS 업체에서 제공하는 기본값을 그대로 사용할 경우, 단지 특정 서버로 핑(ping)을 지속적으로 실행시키기만 해도 핑 플루딩(ping flooding)이라는 경고가 발생하는 경우를 볼 수 있었다. 그렇다면 어떻게 파라미터를 정할 것인가?

- 신뢰 IP의 지정

그나마 커스터마이징 과정에서는 가장 쉬운 부분일 수 있다. 많은 공격 탐지에 대해 소스IP나 목적지IP가 동일한 양상을 보인다면 그것에 대한 IP 정보를 확인함으로 신뢰 IP를 지정할 수 있다. 예를 들어 SNMP를 통해 인터페이스 정보를 수집했다는 공격이 특정 소스IP로부터 많은 탐지를 보였는데, 해당 소스IP가 SNMP를 통한 정보 수집 기능을 하는 NMS 장비였다면 이것은 정상적인 네트워크 활동에 대해 탐지된 것으로 볼 수 있다. 이런 경우 해당 공격에 대해 신뢰IP를 지정해 그 IP에 대한 공격은 탐지하지 않도록 설정하는 것이다.

그런데 이러한 설정이 어려운 경우가 있다. 보다 복잡한 공격(예를 들어 쿠키의 내용 중에 바이너리 코드가 포함돼 있어서 탐지된다는 등)에 대해서는 해당 공격에 대한 경고가 발생하는 조건이 무엇인지, 그리고 왜 발생한 것인지에 대한 상세한 로그를 IDS에서 제공하는 상세 로그 분석을 통해 확인해야 하는 경우다.

② 엔진 및 패턴 업데이트

IDS는 벤더에서 구현한 시그니처를 기반으로 탐지한다는 점에서 안티 바이러스 제품과 매우 흡사하다. 물론 그렇기 때문에 엔진 및 패턴 업데이트가 중요하다. 최근에는 제로 데이 어택(zero-day attack)의 시대여서, 취약성 릴리즈와 그에 대한 공격 코드 발표일의 차이가 아주 짧아지고 있는 추세다.

새로운 취약성이 나타났을 때 해당 취약성에 대해 IDS 벤더에서는 해당 취약성에 대한 패턴 업데이트를 얼마나 빨리 발표할 것인지 그것을 IDS 관리자는 얼마나 빨리 업데이트를 할 것인지는 이제 효율적인 공격 탐지에 필수적이다.

③ 실시간 대응

IDS 도입 이후 겪게 될 가장 큰 혼란과 어려움 중 하나는 실시간 대응에 대한 문제다. IDS 무용론을 이야기한 가트너 그룹에서 그 이유로 이야기하는 점은 IDS는 기본적으로 설치 이후 로그양이 너무 많아서 그것에 대한 분석 및 커스터마이징을 위해 보안전문가라는 인력이 필요하다는 점, 그리고 IDS는 차단보다는 탐지에 초점을 맞췄기 때문에 그러한 보안전문가가 24시간 계속 콘솔을 전담 모니터링해야 한다는 점이다.

물론 이러한 점은 IDS 벤더도 오래 전부터 이해하고 있었기 때문에 ‘방화벽과의 연동’, ‘TCP 세션 끊기’를 통한 능동 차단 기능을 구현하고 있다. 하지만 IDS의 고질적인 오탐지(false positive) 문제가 해결되지 않는 상황에서 능동 차단 기능을 적용할 수는 없는 노릇이다.

④ 룰에 대한 상세한 정보

침입탐지 이벤트가 발생했을 때 관리자는 룰에 대해서 이것이 오탐지는 아닌지, 그리고 오탐지가 아니라면 얼마나 위협적인 공격인지를 파악해야 한다. 그것을 위해서는 룰에 대한 상세한 정보(해당 룰에 의한 침입탐지 이벤트가 발생하는 조건, 해당 룰과 관련된 애플리케이션, 취약성 발표된 시기, 취약성에 대한 설명, 오탐지가 발생할 수 있는 조건 등)가 온라인으로 확인할 수 있어야 하며 관리자가 쉽게 이해할 수 있어야 한다.


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