한빛출판네트워크

저자: 『BGP』의 저자 Iljitsch van Beijnum, 역 강상진

여기 유럽에서는 지난주 토요일 이른 아침(지난 1월 25일 인터넷 대란을 말하는 것임)에 MS SQL 웜 바이러스가 극성을 부렸다. 내가 관리하고 있거나 관리에 도움을 주는 네트워크 4개중 3개의 네트워크에서 호스트 수가 적은 네트워크가 감염이 되었다. 그리고 각각의 결과는 모두 달랐다.

첫번째 네트워크는 웜바이러스에서 발생하는 트래픽 때문에 시스코7200 라우터의 속도가 굉장히 느려졌다. 라우터가 BGP(Border Gateway Protocol)패킷을 제시간에 보내는 작업을 할 수 없었기 때문에 BGP 세션은 깨지고 말았다. 이는 곧 라우터가 네트워크의 IP범위를 전세계의 사람들에게 알리지를 못한다는 것을 뜻한다. 그 결과 이 주소들은 모두 연결할 수 없는 상태가 되었다.

보통상태에서 7200 라우터는 수백 메가비트의 전송량을 보낼 수 있다. 그러나 웜 바이러스가 생성된 패킷은 전송량이 매우 작았다(내가 관찰했을 때 404바이트). 게다가 이 네트워크의 라우터 하나가 메모리가 부족했기 때문에 Cisco Express Forwarding (CEF) 알고리즘을 실행할 수 없었다. 이것은 문제를 더욱 심각하게 만들었는데 이유인즉슨, CEF 알고리즘이 없다면 라우터는 빠른 속도로 각각의 위치에 패킷을 보내는데 필요한 "라우트 캐시"를 만드는데 시간이 걸리기 때문이다. 웜 바이러스는 각 주소에 임의적으로 발생되므로 라우터는 이러한 라우트 캐시 목록을 만든다. 그런데 이 라우트 캐시 목록을 만드는데 대부분의 시간을 사용하다가 부팅도 할 수 없을 정도까지 메모리를 사용해 버린다. 여기서 우리가 얻을 수 있는 중요한 교훈은 상태패킷전송 알고리즘을 사용하라는 것이다. 캐시나 흐름지향 알고리즘은 위험하다.

이러한 상황에 대처하면서도 나는 내가 웜 바이러스와 씨름하고 있다는 사실을 전혀 모르고 있었다. 그냥 서비스거부(DoS:denial-of-service) 공격쯤으로 생각하고 있었다. 그러다가 트래픽 카운터를 보고, 네트워크에 유입된 것보다 훨씬 많은 트래픽이 발생되고 있다는 사실을 알게 되었다! 난 재빨리 로깅을 위한 필터를 인스톨 하였다.

!
access-list 140 permit ip any any log-input
!
interface ethernet0/0
 ip access-group 140 in
!

이 필터는 아무것도 필터링 하지 못했지만 라우터의 로그 버퍼에 연결된 장치에서 나오는 트래픽의 샘플을 로깅하고 있었다.

7w1d: %SEC-6-IPACCESSLOGP: list 140 permitted udp 192.168.3.172(1189) 
  (Ethernet0 0001.0229.23b6) -> 223.183.47.3(1434), 1 packet

나는 어떤 호스트가 (700MegaBits나 되는) 공격적인 트래픽을 발생 하고 있는지 알 수 있었고, 이 호스트의 모든 패킷을 아래와 같이 필터링 할 수 있었다.

!
access-list 140 deny   ip host 192.168.3.172 any
access-list 140 permit ip any any
!

확실히, 보내거나 떨어져 나가는 패킷을 관찰하는 데에는 추가적인 CPU시간이 소요 되었다. 그러나 인터페이스에서 나오는 패킷을 바로 떨어뜨리는 것은 그 패킷을 보내거나 보내도록 노력하는 것에 비해 훨씬 적은 CPU시간이 소요되었다. 그래서 이러한 네트워크상의 필터는 정상적인, 혹은 더 많거나 더 적은 패킷을 되돌려 주었다. 그러나 거기엔 또 다른 원인이 있을 거라는 의심이 들었다. 그래서 나는 최근에 게시된 North American Network Operators Group (NANOG)의 메일링 리스트를 찾아보았다. 그곳에 다른 사람들이 UDP 포트 1434번에서 작동하는 웜 바이러스에 대해 이야기 해놓은 것을 보았다. 나는 즉시 1434포트를 목적지로 하는 UDP 패킷을 검색해 보았다.

!
access-list 140 deny   udp any any eq 1434
access-list 140 permit ip any any
!

그리고 이것은 웜 바이러스의 패킷을 정확하게 잡아내었다.

show access-list 140
Extended IP access list 140
    deny udp any any eq 1434 (87352 matches)
    permit ip any any (3103 matches)

---

참고 도서 BGP : Building Reliable Networks with the Border Gateway Protocol Iljitsch van Beijnum 상세설명보기 목차보기 샘플챕터보기

---

MS SQL 웜 바이러스의 전체코드는 겨우 몇백 바이트 밖에 안되며 하나의 UDP패킷에 들어있는 것으로 밝혀졌다. 그 패킷은 악성 Microsoft SQL 서비스를 요구하는 내용을 담고 있었다. 서버는 이것을 정확히 체크해내지 않았고, 그래서 과다한 데이터가 다음에 실행될 명령을 가리키고 있는 스택메모리를 점령하였다.

이것이 웜 바이러스가 패킷내에 있는 코드를 실행시키는 원리이다. 웜 바이러스내의 실행가능한 코드들은 무작위로 주소를 생성하고 있었고, 자신의 복사본을 이 주소로 보내고 있었다. 웹이나 메일 등 대부분의 프로그램에 사용되는 TCP프로토콜과는 달리, UDP는 전송을 완료시키는 세션이 필요 없다. 그래서 다음 패킷을 전송하는데 응답을 기다릴 필요가 없다. 감염된 서버들은 빠른 속도로 복사된 웜 바이러스를 전송하고 있었고, 그것은 초당 10,000 패킷에 달하였다.

나는 즉시 내가 관리하는 다른 네트워크들을 Cisco 12000로 업그레이드 하였다. 이것은 추가적인 100 메가비트의 웜 트래픽과 전형적인 50 메가비트 혹은 토요일 이른 아침의 트래픽을 운용할 수 있는 능력이었다. 난 원하지 않는 트래픽을 대비하기 위해 필터를 새로 인스톨 하였다. 토요일 어느 시점에 이르자 25%에 달하는 패킷들이 웜 바이러스 복사본들이었다. 이상하게도 감염된 서버들을 치료한 후에도 내부 네트워크에서는 계속하여 하나 혹은 두개의 웜 바이러스 카피본이 계속하여 발생하고 있었다. 이는 바이러스가 방대하고 넓은 네트워크상에 성공적으로 전염되었다는 것을 잘 보여주고 있으며 추후에 연구할만한 흥미로운 주제를 남긴 셈이된다.

에볼라처럼 아주 공격적인 생물학적 바이러스와 마찬가지로 웜 바이러스 또한 비슷하다고 볼 수 있다. 웜 바이러스에서 발생하는 각각의 패킷들은 UDP포트를 사용하는 Microsoft SQL 서비스를 목적으로 하고 있었다. 이것은 웜 바이러스 자체를 필터하기에 좋게 되어있는 구조였다. 또한, 매우 높은 트래픽을 발생하기 때문에 웜 바이러스 자체를 탐색하지 못하게 하는 것은 불가능했다. 다른 개념의 웜 바이러스는 쉽게 전파된다는 것 외에 다른 특징이 있어야 할 것이다. 그래서 지금 현재의 웜 바이러스가 1분여 만에 전 인터넷을 감염시킨 것처럼 그렇게 빨리 퍼지게 되지는 않을 것이다.