 블로그 > nirvana2k님의 블로그 http://blog.naver.com/nirvana2k/60003799955 | |
| 침입탐지시스템(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) 문제가 해결되지 않는 상황에서 능동 차단 기능을 적용할 수는 없는 노릇이다. ④ 룰에 대한 상세한 정보 침입탐지 이벤트가 발생했을 때 관리자는 룰에 대해서 이것이 오탐지는 아닌지, 그리고 오탐지가 아니라면 얼마나 위협적인 공격인지를 파악해야 한다. 그것을 위해서는 룰에 대한 상세한 정보(해당 룰에 의한 침입탐지 이벤트가 발생하는 조건, 해당 룰과 관련된 애플리케이션, 취약성 발표된 시기, 취약성에 대한 설명, 오탐지가 발생할 수 있는 조건 등)가 온라인으로 확인할 수 있어야 하며 관리자가 쉽게 이해할 수 있어야 한다. 2. 탐지 기능의 문제점 과거 많은 IDS가 탐지 기능의 문제점을 가졌다. 원래 IDS는 단순히 패킷에서 해킹에 해당되는 패턴이 있는지 검색하는 패킷 그래핑(packet grepping) 수준이었다. 하지만 이후 너무나도 많은 회피 기법에 의해 IDS를 속일 수 있다는 것이 알려졌다. 이러한 모든 회피 기법의 아이디어는 ‘해킹 당하는 대상을 IDS가 정확히 이해하지 못한다’는 것이다. ① 공격에 사용되는 프로토콜을 인지하지 못하는 경우 공격에 사용되는 프로토콜을 정확히 파악하지 못해서 생기는 문제는 다양하다. 1. ‘GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/ c+dir HTTP/1.0’ 2. ‘get /scripts/..%c1%1c../winnt/system32/cmd.exe?/ c+dir http/1.0’ 3. ‘GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/ c+dir HTTP/1.0’ 위의 세 가지 요청은 HTTP 프로토콜 상에서 동일한 의미를 가진다. 하지만 실제 어떤 IDS 제품은 1번은 탐지하나, 2번이나 3번 둘 중의 하나, 혹은 두 가지 모두를 탐지하지 못 하는 경우도 본 적이 있다. 그밖에 웹 서버의 포트 번호가 달라져도 탐지를 못 하는 경우가 있어서 그러한 IDS 제품에 테스트의 목적으로 2123 포트에 운영 중인 웹 서비스에 관련 공격이 들어온다면 무방비 상태가 되는 것이다. ② 각종 URL 회피 기법 휘스커(Whisker) 툴에 기반한 닉토(nikto)는 휘스커 툴에서 사용할 수 있었던 각종 URL 회피 기법을 테스트할 수 있다. 이러한 URL 회피 기법의 몇 가지 예를 보면 다음과 같다. IDS 제품에서 이러한 회피 기법을 모두 지원하는 경우도 있지만 그렇지 않은 경우도 있다. 테스트는 쉽게 닉토 툴로 할 수 있다. · Self-reference directory: ‘GET /cgi-bin/jj’ → ‘GET /./cgi-bin/./jj’ · URL encoding: ‘GET /cgi-bin/jj’ → ‘GET /%63%67%69% 2d%62%69%6e/%6a%6a’ · Reverse traversal: ‘GET /cgi-bin/jj’ → ‘GET /test/../cgi-bin/jj’ · Windows delimiter: ‘GET /cgi-bin/win-c-sample.exe’ → ‘GET \cgi-bin\win-c-sample.exe’ · NULL method: ‘GET /cgi-bin/win-c-sample.exe’ → ‘GET%00 /cgi-bin/jj’ ③ IP 프레그멘테이션·조각난 TCP 스트림을 이용한 IDS 회피 가장 잘 알려진 IDS 회피 기법이라면, IP 프레그멘테이션(fragmentation)을 이용한 IDS 회피, 그리고 조각난 TCP 스트림을 이용한 IDS 회피를 예로 들 수 있다. 이들을 제대로 탐지하기 위해서는 IP 디프레그멘테이션(defragmentation)과 TCP 스트림 리어셈블리(stream reassembly) 기능이 구현돼 있어야 한다. 이를 테스트하기 위한 유명한 툴은 더그 송(Dug Song)의 프레그라우트(fragroute)다. 프레그라우트 실행화면 예제는 <그림 3>과 같다. ④ 성립되지 않은 세션에서의 TCP 공격 TCP 스트림과 같이 세션에 의한 문제를 야기할 수 있는 것을 한 가지 더 보자. 스틱(stick)이라는 툴이 있다. 이 툴은 IDS를 테스트하기 위한 툴 중 하나인데, 대표적인 기능 중 하나가 세션을 맺지 않고 TCP 공격 패킷을 보내는 기능이다. TCP는 연결 지향 프로토콜로서 정보를 교환하기 전에 먼저 3웨이 핸드쉐이크(handshake)에 의해 연결을 성립한 후 정보를 보내고 제대로 받았다는 것을 인정하는 절차를 거친다. 즉 세션을 맺지 않고 TCP 공격 패킷을 보낸다면 응답으로 RST(리셋) 패킷을 받게 될 것이다. 이럴 경우 공격은 이뤄지지 않았지만, IDS는 경고 이벤트를 발생하게 된다. 가장 쉽게 알 수 있는 문제점은 소스 IP를 엉뚱한 IP로 속여서 다수의 경고를 발생시킬 수 있다. 단순히 재미 삼아서, 혹은 어떤 뚜렷한 목표를 가지고 특정 소스 IP를 범죄자로 오인 받게 만드는 것이 가능하다. 앞서 말한 능동 대응이 활성화된 경우에 이러한 공격을 하게 되면 큰 문제가 야기될 것을 짐작할 수 있다. 위와 같이 IDS를 운영하고 BMT 하면서 겪은 다양한 난제들이 있으며, 이 밖에도 운영하면서 많은 어려움을 접하게 될 수가 있다고 예상된다. 자사에 IDS 도입을 할 때에도 이러한 점들을 염두에 두고 필요한 기능을 고려해 도입해야 할 것으로 보인다. IDS 도입시 고려 사항 1. 제품 선정 과정에서의 고려 사항 이러한 침입탐지시스템 도입을 위해 제품 선정 과정에서 고려해야 할 사항은 <표 1>과 같이 정리될 수 있다. 2. 제품 설치 과정에서의 고려 사항 제품을 도입한 후 실환경에 적용하는 과정에서 고민돼야 할 점들은 다음과 같다. - IDS의 네트워크 구성 상에서의 위치는 어떻게 할 것인지(만약 방화벽을 운영한다면 인터넷 쪽에 둘 것인지 DMZ에 둘 것인지, 내부 네트워크에 둘 것인지) 인터넷 쪽에 IDS를 두게 된다면 방화벽을 통과하지 않게 될 공격까지 탐지돼 많은 오탐지를 발생할 수 있다는 단점, 내부 네트워크에 둔다면 포트스캐닝 공격과 같은 리커네선스(reconnaissance) 공격은 대부분의 스캐닝 패킷이 방화벽에 차단돼 IDS에서 탐지되지 않는다는 단점이 일반적이다. 이 점을 극복하기 위해 모든 포인트에 IDS를 배치할 수도 있겠지만 그만큼 비용이 증가한다는 점도 잊지 말아야 한다. - 스위치의 포트 미러링 세팅으로 설치할 것인지, TAP 장비를 이용할 것인지 스위치에서 포트 미러링을 설정할 경우 스위치의 성능 저하 문제가 있지 않을까 걱정에서 이런 영향을 전혀 고려할 필요가 없는 TAP 장비를 추가하는 경우가 있다. TAP 장비는 장비 자체에서 장애가 나더라도 정상적인 트래픽 송수신에 이상이 없고 네트워크 성능에 영향을 미치지 않기 때문에 선호된다. 하지만 포트 미러링 설정으로 인한 스위치의 성능 저하 문제도 무시할 수 있을 만큼 작아졌고 없는 경우도 많기에 성능 문제로 크게 고민할 필요는 없다. 3. 제품 운영 과정에서의 고려 사항 IDS는 방화벽보다 특히 운영 과정에서 보안 지식이 많이 필요한 솔루션이다. 이것을 효율적으로 운영하기 위해서는 체계적인 교육을 받은 보안전문가라는 전담인력이 필요하고 모니터링은 어떻게 할 것인지 고민돼야 한다. IDS 도입을 하게 되는 많은 기업이 힘들어하게 되는 부분인데 이 부분에 대해서는 보안관제서비스(Managed Security Service)를 이용해 비용대비 효과를 극대화시키는 것도 고려할만하다. 자체 인력으로 해결하든 아웃소싱을 통해 해결하든 간에 IDS 도입으로 기대효과를 극대화하기 위해서는 무엇보다도 적절한 운영 및 대응 프로시저 마련이 필요함을 염두에 둬야 한다. 결론 이제까지 침입탐지시스템을 운영하면서 겪을 수 있는 어려운 점들, 그리고 그러한 어려운 점들을 해소하기 위해 제품 도입 시 고려해야할 점들을 살펴봤다. IDS의 한계를 극복하기 위해 많은 시도가 있고 그 결과 침입방지시스템(IPS)이라는 능동형 보안 솔루션도 나타나고 있다. 그러나 오탐지의 극소화, 네트워크 관문에 설치돼 방어도 가능하게 한다는 IPS 역시 기본적으로는 IDS에 이론적 밑바탕을 두고 있기 때문에 IPS가 IDS를 완전히 대치하게 될 것인지는 좀 더 두고 볼 일이다. 무엇보다도 IDS는 설치 이후 자사의 환경에 맞는 커스터마이징 작업, 무수한 침입탐지 이벤트에서 실제로 의미 있는 이벤트에 대한 분석을 할 수 있는 보안전문지식이 필요한 솔루션이다. IDS를 도입했지만 그것을 제대로 관리를 하지 못해 업데이트한지 오랜 시간이 지난 엔진으로 단순한 로그 수집으로 방치하고 있는 관리자를 본 적도 많이 있다. 관리자는 모든 것이 해결돼 안심할 수 있는 방안을 찾고자 한다. 보안에 있어서 지속적인 모든 것을 100% 근본적으로 해결해줄 방법은 없다. 지속적이고 꾸준한 관리가 없는 보안을 하는 것은 하지 않는 것과 다를 바 없다. [NETWORK TIMES 2004년 05월호 이용학 코코넛 기술본부 대리 ] |
'L7'에 해당되는 글 1건
- 2006.08.07 침입 탐지 시스템(IDS)
engineering/Network Eng.2006. 8. 7. 00:21
