보다 지능화되고 있는 웹 방화벽, 그 ‘지능화’의 필요성
어느 분야보다 소프트웨어의 지능이 절실하게 필요한 분야가 보안 소프트웨어 분야이다.지능성(Intelligence)은 정보보안 기술 고유의 특징이자 보안 소프트웨어가 막아내야 하는 공격의 본질적인 속성이기 때문에 지능적인 보안 소프트웨어에 대한 요구는 자연스러운 현상이다. 성능과 가용성을 중요시하는 네트워크 분야 보다는 다양한 사용자들의 유형이 표현되고 실제로 개발자들에 의해서 매일 변화가 만들어지는 애플리케이션 분야에서 지능성의 필요는 보안 소프트웨어 생명 자체를 좌지우지할 정도로 너무나 중요한 요소로 자리 잡고 있다.
성능과 가용성을 중요시 하는 네트워크 분야 보다는 다양한 사용자들의 유형이 표현되고 실제로 개발자들에 의해서 매일 변화가 만들어지는 애플리케이션 분야에서 지능성의 필요는 보안 소프트웨어 생명 자체를 좌지우지할 정도로 너무나 중요한 요소로 자리 잡고 있다. 애플리케이션 보안 중 그 공격 유형이 다양한 웹 애플리케이션 보안 분야와 이를 위한 웹 방화벽에서의 지능화에 대해 살펴보겠다.

 

공격 패턴을 지능화하여 설정했던 1세대 웹 방화벽

웹 애플리케이션 보안을 담당하는 웹 방화벽은 탄생 초기부터 기존의 보안 장비, 예를 들어 네트워크 방화벽(침입 차단 시스템), 침입 탐지/방지 시스템과는 다른 형태로 만들어 져야 한다는 의견이 일반적이었다. 그 대표적인 이유는 웹 애플리케이션의 특성상 기존의 침입 탐지/방지 시스템에서와 같이 특정한 공격 유형과 패턴, 취약점 패턴 등을 검사하는 것만으로는 공격을 막아낼 수 없기 때문이다.

웹 애플리케이션은 매일 서로 다른 개발자들에 의해서 만들어지고 있고, 지금 이 순간에도 새로운 유형의 취약점이 새로운 애플리케이션에 알게 모르게 만들어지고 있는 것이 현실이다. 이러한 형태에 대한 대응을 위하여 제시된 웹 애플리케이션 보안의 핵심 키워드가 바로 ‘Positive Security Model’이다. Positive Security Model을 갖는 웹 방화벽 구현을 위하여 기존의 보안 장비들의 공격 대응 방식인 Black List 관리 방식에 더하여 White List 관리 방식을 도입하여 Positive Security Model을 구현한 웹 방화벽들이 시장에 선보이게 되었다.

이러한 1세대 웹 방화벽의 경우 관리자는 보안 정책 구현을 위하여 Black List와 White List로 관리되는 패턴 데이터베이스를 직접 등록하거나 관리하는 노력이 필요하다. 여기서 웹 방화벽의 지능은 관리자가 등록 및 편집하는 패턴 정보(일종의 Signature)에 의해 결정된다. 웹 방화벽 자체가 지능이 있다기보다는 웹 방화벽은 패턴 매칭 엔진을 탑재하고 있고, 관리자의 인간 지능이 패턴을 최적화하여 등록해야 한다.

이러한 1세대 웹 방화벽은 기존의 고성능 패턴 매칭 엔진을 보유한 기업에서 쉽게 웹 방화벽을 출시할 수 있는 방식이었다. 기존의 침입 탐지/방지 시스템과는 다르게 웹 애플리케이션에 대한 공격을 패턴 데이터베이스 업데이트만으로 방어할 수 없다는 인식에서 White List 방식을 도입했지만, 관리자가 직접 설정해야 하는 불편함은 White List 방식을 실제적으로 사용하지 않게 만들고, 현실적으로 Black List 만으로 웹 공격들을 막는 일을 초래했다.

이러한 운영 방식은 웹 방화벽을 무용지물로 만들거나 또는 오탐으로 인한 웹서비스 방해물로 전락시키게 되어, 보안 시장에서는 웹 방화벽은 오탐이 많아서 웹서비스에 영향을 많이 주는 제품 또는 다양한 웹 공격들, 대표적으로 SQL Injection과 같이 변이가 많은 공격들을 제대로 막지 못 하는 제품으로 누명을 쓰게 된다.

 

자동 학습 지능을 탑재한 2세대 웹 방화벽

보안 시장에서 웹 방화벽의 가능성을 보여준 것은 White List에 대한 관리자의 설정 행위, 즉 운영을 자동화한 2세대 웹 방화벽의 역할이었다. 2세대 웹 방화벽은 관리자가 직접 White List를 설정해야 하는 불편함을 자동 학습 기능으로 제공하여 관리자가 실제적으로 White List를 현실에 맞게 사용할 수 있는 방안을 제공했다.

White List는 매우 강력한 보안 기능임에도 불구하고 현재 애플리케이션에 적합한 정책이 설정되지 않으면 애플리케이션을 사용할 수 없게 만드는 치명적인 반대 효과가 나타나기 때문에 1세대 웹 방화벽에서는 관리자가 수동 설정을 하는 많은 수고를 들이거나 White List 방식을 대부분 사용하지 않게 되는 결과를 낳았다. 하지만 2세대 웹 방화벽에서는 이를 자동으로 학습하여 관리자가 현재 애플리케이션에 적합한 보안 정책을 수동으로 만들지 않고 자동으로 얻어낼 수 있는 기능을 제공했다.

결국 2세대 웹 방화벽은 학습 기능의 지능이 웹 보안을 원하는 관리자가 사용 가능한 효과적인 수준인가가 제품의 품질을 결정하게 되었다. 어떤 제품은 최소 2주간의 학습기간을 거쳐야만 학습이 가능한 제품이 있는데, 이 경우 국내에서와 같이 웹 애플리케이션이 매일 매일 변화되는 환경에서는 현실적으로 사용이 어려운 단점이 있다.

또한 학습 지능이 아무리 좋다고 하더라도 관리자에게 검증을 받지 않는 정책을 바로 적용하는 것은 White List의 성격 상 웹 애플리케이션 서비스 자체의 장애로 까지 이어질 수 있기 때문에 관리자의 수동 정책 설정보다는 수월해 졌지만, 정책 설정에 관리자가 매우 깊게 개입해야 하는 것은 2세대 웹 방화벽의 여전한 특징이다.

 

새로운 개념의 지능을 탑재한 웹 방화벽

2세대 웹 방화벽이 고도의 기술 개발과 지능 개발을 통하여 매우 현실적인 웹 방화벽을 만들어 낼 수 있을 것이라는 기대도 있지만 웹 애플리케이션 특성에 초점을 맞춘 새로운 개념의 지능을 탑재한 웹 방화벽에 대한 기대는 클 수밖에 없다. 기존의 2세대 웹 방화벽 역시 기존의 1세대와 같이 Black List와 White List를 계층적으로 결합한 형태로 고성능 패턴 매칭 엔진을 이용하여 Black List는 빈번하고 빠른 패턴 업데이트를 필요로 하고 White List는 현재 보호하고자 하는 웹 애플리케이션을 최대한 모델링 하겠다는 취지에는 큰 변화가 없기 때문이다.

지능적인 웹 방화벽은 Black List와 White List의 물리적인 결합이 아닌 웹 애플리케이션과 웹 공격에 대한 최적의 방어 엔진을 설계하고 엔진 내부의 기능이 자연스럽게 Black List와 White List의 결합, 그리고 Positive Security Model의 구현의 포함하고 있는 형태이다. 이러한 도전을 진행한 제품이 필자의 회사에게 개발한 WAPPLES이라는 웹 방화벽이다. WAPPLES이 지능형 웹 방화벽의 정답은 될 수 없겠지만 웹 애플리케이션 보안을 기존의 방어 기술의 결합이 아닌 새로운 시각에서 접근했다는 점과 관리자 관점에서의 운영성을 반영하여 지능화한 노력은 주목할 만할 점이다.

 

‘지능화’는 보안 제품의 숙명

보안 제품을 만드는 사람들이 각자 자신의 위치에서 지능화에 최선의 노력을 기울이는 것이 지금의 보안 환경에서는 당연한 일이 된 듯 하다. 웹 방화벽이 웹서비스의 대중화와 확대에 따라서 더욱 많은 관심을 받는 상황에서 WAPPLES에 대한 시장에서의 평가가 웹 방화벽 시장에서 ‘지능화’에 대한 노력이 얼마나 성공을 거둘 것인가로 주목을 받을 만한 가치가 있다. 이제는 지능화된 보안 제품만이 고객의 선택을 받을 수 있고 실질적으로 고객에게 도움을 줄 수 있다는 점에서 ‘지능화’는 보안 제품의 숙명이라 하겠다.

<글 : 김덕수 펜타시큐리티시스템 보안기술연구소장(dskim@pentasecurity.com)>


웹센스(Websense) CTO인 댄 허버드가 설명하는 기업이 소셜 웹에서 위협과 손상으로부터 자사 정보를 보호하는 4가지 방법이다.


1) 블로그와 포럼에 있는 웹 게시물 대부분이 실제로 원하지 않는 콘텐츠라는 점을 인지

블로그, 포럼 및 대화방 같이 사용자가 생성하는 콘텐츠를 허용하는 사이트에서 사용자들의 상호 작용이 점점 늘어나면서 스패머와 사이버 범죄자들이 메모를 남기고 이를 악용하여 스팸을 전파하고 자신의 웨어로 돌아오는 링크를 게시하며 악의적인 사이트로 사용자를 유도하는 일이 발생했다. 

웹센스의 연구 결과에 따르면, 블로그와 포럼에 있는 모든 웹 게시물의 85%가 스팸과 맬웨어 등 원하지 않는 콘텐츠이며, 5%는 실제로 맬웨어, 사기 및 피싱 공격이라는 것을 보여주고 있다. 활동하는 블로그에 매달 평균 8,000에서 1만 개의 링크가 게시되므로 사용자들은 분명 이러한 사이트에 있는 링크를 클릭하기를 주저하게 될 것이다.  

또한 사이트의 평판이 좋다고 해서 안전한 것은 아니다. 소니 픽쳐스(Sony Pictures), 디그(Digg), 구글(Google), 유튜브(YouTube) 및 워싱턴 주립 대학(Washington State University)에서 운영하는 블로그와 메시지 보드에도 최근 악의적인 내용의 스팸이 게시되었으며 My.BarackObama.com은 악의적인 내용의 스팸으로 감염된 적이 있다.

 

2) 구글 세이프(Google Safe)의 상위 검색 결과를 믿을 수 있을까?

검색 엔진 감염이 계속 인기를 끌면서 사이버 범죄자들이 악의적인 코드나 스팸이 있는 웹 사이트 링크를 상위로 끌어 올리는 데 사용되고 있다. 많은 사용자들이 상위 검색 결과는 안전할 것으로 여기지만 실제로는 감염된 웹 사이트로 이동하게 만다. 예를 들어, 3월에는 구글 검색창에 "March Madness(3월의 광란)"라고 입력하고 상위 검색 결과 링크를 클릭한 야구 팬들이 실제로 "허위 안티바이러스(rogue antivirus)" 소프트웨어에 감염된 웹 사이트로 이동한 일이 있다(3번 참조).

 

3) 다운로드하기 전 보안체크 필수  

과거에는 사이버 범죄자들이 신용 카드 정보와 기타 개인 정보 등을 웹 사용자로부터 얻기 위해 "허위 안티바이러스(rogue antivirus)"라는 것을 많이 사용했다. 일반적으로 허위 안티바이러스 제작자는 트래픽을 자신의 사이트나 감염된(위에서 설명) 사이트로 이동시키기 위해 검색 엔진 감염을 사용한다. 종종 자신이 통제하는 악의적인 사이트로 이동시키는 링크를 블로그와 포럼에 게시한다. 사용자가 이러한 웹 사이트를 방문하면 컴퓨터가 맬웨어에 감염되었다는 경고창이 표시된다. 그런 다음 이 시스템을 치료하려면 비용을 지불해야 하며 "안티바이러스" 소프트웨어 프로그램을 다운로드할 것인지 묻는다. 실제로 공격자는 허위 소프트웨어 비용을 지불하기 위해 사용자의 신용 카드 정보를 알려주도록 유도하고 컴퓨터에 성공적으로 맬웨어를 설치하게된다. 한 가지 예는 전세계 수 많은 컴퓨터를 감염시킨 것으로 알려진 콘피커 웜이 있다. 콘피커 웜에 감염된 일부 사용자에게서 컴퓨터에 파일이 다운로드된 것이 관찰됐다. 파일을 실행하지 마자 사용자에게 "발견된 위협"을 제거하려면 49.95달러를 지불할 것을 요구했다.

안티피싱 워킹 그룹(Anti-Phishing Working Group)은 최근 허위 바이러스 프로그램 수가 2008년 7월에서 2008년 12월까지 225% 증가하여 7월부터 발견된 허위 안티바이러스 프로그램 수보다 3배 이상 늘었다는 몇 가지 흥미로운 통계를 발표했다.  

컴퓨터 사용자가 감염되지 않았고 안티바이러스 프로그램을 설치할 필요가 없는 데도 웹 사용자들을 불안하게 하여 돈을 갈취하려는 것이 허위 안티바이러스 공격의 책략입니다.

 

4) 소셜 네트워크의 친구 메시지도 쉽게 믿지 말라

웹센스 보안 연구소(Websense Security Labs)는 최근 "개인 Web 2.0 소셜 네트워크를 통해 전달되는 웹 위협은 새로운 것이 아니다. 친구에게서 온 것이라도 의심되는 메시지는 무조건 믿지 말라"고 권고했다. 소셜 네트워킹의 성장은 위협을 전달하는 새로운 방법을 만들어냈다. 웹 사용자는 단축 URL이 있는 트위트(tweets), 페이스북 페이지에 게시된 동영상 링크, 자신들의 소셜 네트워킹 사이트에서 보낸 이메일 메시지를 받으면 대부분의 사람들이 보낸 사람을 신뢰하기 때문에 주저하지 않고 링크를 클릭하는 데 익숙해져 있다는 것을 악용하는 방법이다.

범죄자는 이런 신뢰를 악용하여 맬웨어와 감염된 웹 사이트 링크를 퍼뜨린다는 것은 불행한 현실이다. 웹센스 보안 연구소는 최근 페이스북에서 보낸 이메일 메시지가 실제로는 멀웨어에 감염된 "동영상" 링크를 클릭하도록 유도하는 범죄자에게서 보내온 것임을 발견했다.


출처 : IDG
원문 : http://www.idg.co.kr/newscenter/common/newCommonView.do?newsID=56561 

[IPv6] Neighbor Discovery

2009. 6. 10. 20:47 | Posted by 꿈꾸는코난

Neighbor Discovery

Internet Protocol version 6 (IPv6) Neighbor Discovery (ND) is a set of messages and processes defined in RFC 4861 that determine relationships between neighboring nodes. ND replaces Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) router discovery, and the ICMP Redirect message used in IPv4. ND also provides additional functionality.

  * ND message format

   


    - Router Solicitation
    - Router Advertisement
    - Neighbor Solicitation
    - Router Advertisement
    - Redirect

  * Router Solicitation
The Router Solicitation message is sent by IPv6 hosts to discover the presence of IPv6 routers on the link. A host sends a multicast Router Solicitation message to prompt IPv6 routers to respond immediately, rather than waiting for an unsolicited Router Advertisement message.

For example, assuming that the local link is Ethernet, in the Ethernet header of the Router Solicitation message you will find these settings:

■ The Source Address field is set to the MAC address of the sending network
    adapter.
■ The Destination Address field is set to 33-33-00-00-00-02.
    In the IPv6 header of the Router Solicitation message, you will find the following
    settings:
■ The Source Address field is set to either a link-local IPv6 address assigned to the
    sending interface or the IPv6 unspecified address (::).
■ The Destination Address field is set to the link-local scope all-routers multicast
    address(FF02::2).
■ The Hop Limit field is set to 255.

  * Router Advertisement
IPv6 routers send unsolicited Router Advertisement messages pseudo-periodically—that is, the interval between unsolicited advertisements is randomized to reduce synchronization issues when there are multiple advertising routers on a link—and solicited Router Advertisement messages in response to the receipt of a Router Solicitation message. The Router Advertisement message contains the information required by hosts to determine the link prefixes, the link MTU, specific routes, whether or not to use address autoconfiguration, and the duration for which addresses created through address autoconfiguration are valid and preferred.

For example, assuming that the local link is Ethernet, in the Ethernet header of the Router Advertisement message, you will find these settings:

■ The Source Address field is set to the MAC address of the sending network
    adapter.
■ The Destination Address field is set to either 33-33-00-00-00-01 or the unicast
    MAC address of the host that sent a Router Solicitation from a unicast address.
    In the IPv6 header of the Router Advertisement message, you will find the
    following settings:
■ The Source Address field is set to the link-local address assigned to the sending
    interface.
■ The Destination Address field is set to either the link-local scope all-nodes
    multicast address (FF02::1) or the unicast IPv6 address of the host that sent the
    Router Solicitation message from a unicast address.
■ The Hop Limit field is set to 255.

  * Neighbor Solicitation
IPv6 nodes send the Neighbor Solicitation message to discover the link-layer address of an on-link IPv6 node or to confirm a previously determined link-layer address. It typically includes the link-layer address of the sender. Typical Neighbor Solicitation messages are multicast for address resolution and unicast when the reachability of a neighboring node is being verified.

For example, assuming that the local link is Ethernet, in the Ethernet header of the Neighbor Solicitation message, you will find the following settings:

■ The Source Address field is set to the MAC address of the sending network
    adapter.
■ For a multicast Neighbor Solicitation message, the Destination Address field is
    set to the Ethernet MAC address that corresponds to the solicited-node address
    of the target. For a unicast Neighbor Solicitation message, the Destination
    Address field is set to the unicast MAC address of the neighbor.
    In the IPv6 header of the Neighbor Solicitation message, you will find these
    settings:
■ The Source Address field is set to either a unicast IPv6 address assigned to the
    sending interface or, during duplicate address detection, the unspecified address
    (::).
■ For a multicast Neighbor Solicitation, the Destination Address field is set to the
    solicitednode address of the target. For a unicast Neighbor Solicitation, the
    Destination Address field is set to the unicast address of the target.
■ The Hop Limit field is set to 255.

  * Neighbor Advertisement
An IPv6 node sends the Neighbor Advertisement message in response to a Neighbor Solicitation message. An IPv6 node also sends unsolicited Neighbor Advertisements to inform neighboring nodes of changes in link-layer addresses or the node’s role. The Neighbor Advertisement contains information required by nodes to determine the type of Neighbor Advertisement message, the sender’s role on the network, and typically the link-layer address of the sender.

For example, assuming that the local link is Ethernet, in the Ethernet header of the Neighbor Advertisement message, you will find the following settings:

■ The Source Address field is set to the MAC address of the sending network
    adapter.
■ The Destination Address field is set, for a solicited Neighbor Advertisement, to the
    unicast MAC address of the initial Neighbor Solicitation sender. For an
    unsolicited Neighbor Advertisement, the Destination Address field is set to 33-33-
    00-00-00-01, which is the Ethernet MAC address corresponding to the link-local
    scope all-nodes multicast address.
    In the IPv6 header of the Neighbor Advertisement message, you will find
    these  settings:
■ The Source Address field is set to a unicast address assigned to the sending
    interface.
■ The Destination Address field is set, for a solicited Neighbor Advertisement, to the
    unicast IP address of the sender of the initial Neighbor Solicitation. For an
    unsolicited Neighbor Advertisement, the Destination Address field is set to the  
    link-local scope all-nodes multicast address (FF02::1).
■ The Hop Limit field is set to 255.

  * Redirect
The Redirect message is sent by an IPv6 router to inform an originating host of a better firsthop address for a specific destination. Redirect messages are sent only by routers for unicast traffic, are unicast only to originating hosts, and are processed only by hosts.

For example, assuming that the local link is Ethernet, in the Ethernet header of the Redirect message, you will find the following settings:

■ The Source Address field is set to the MAC address of the sending network
    adapter.
■ The Destination Address field is set to the unicast MAC address of the originating
    sender. In the IPv6 header of the Redirect message, you will find these settings:
■ The Source Address field is set to a unicast address that is assigned to the
    sending interface.
■ The Destination Address field is set to the unicast IP address of the originating
    host.
■ The Hop Limit field is set to 255.

  * ND messages and the options that might be included

  * IPv4 Neighbor Message and Fuctions and IPv6 Equivalents

'컴맹의 컴퓨터 이야기 > IPv6' 카테고리의 다른 글

[IPv6] ICMPv6  (1) 2009.06.10
[IPv6] IPv6 Header  (0) 2009.06.10
[IPv6] IPv6 Addressing  (0) 2009.06.09
[IPv6] Comparison of IPv4 and IPv6  (0) 2009.06.09
[IPv6] IPv6 시대가 도래할 것인가?  (0) 2009.05.28