와이어샤크 최신 버전이 나왔다. 이번 버전에서는 특별한 기능 업데이트 보다는 발견된 몇가지 취약점이 해결되었다. 이외 알려진 버그도 수정되었다.
세부적인 내용은 다음 릴리즈 노트를 참고하기 바란다
http://www.wireshark.org/docs/relnotes/wireshark-1.6.6.html
http://www.wireshark.org/docs/relnotes/wireshark-1.4.12.html
2012년 3월 28일 수요일
2012년 3월 27일 화요일
패킷인사이드가 구글 자동완성 검색어에 나타나다.
자주 이용하는 검색엔진 중에 하나인 구글에서, 패킷을 쳐 보니 패킷인사이드가 상위권에 랭크되어 나오네요. '패킷ㅇ' 까지만 쳐도 패킷인사이드가 자동완성 목록에 나타납니다.
구글의 자동완성 알고리즘은 검색창에 입력하는 것과 유사한 검색어를 표시하는 것인데, 다른 사용자의 검색 활동에 기반하여 검색어를 예측하고 표시한다고 합니다. 즉, 사람의 개입 없이 단순히 여러가지 객관적 요소 (검색어 인기도 포함)를 기반하여 알고리즘적으로 결정됩니다.
이렇게 구글의 자동완성 검색어에 나타나니 기분이 좋네요~
예전에는 보지 못했던것 같은데, 우연챦게 보게 되었네요.
저만 나오는건 아니죠? ^^
2012년 3월 21일 수요일
사례를 통해 알아가는 실전 패킷분석
네트워크 포렌식 연재의 마지막인 사례분석을 소개해 드립니다. 월간 '안'에도 소개된 세 번째 연재 글이며, 이번이 마지막이네요 :-)
일부 내용은 이미 블로그에서 언급한 적이 있고 없는 내용도 있습니다. 가볍게 한번 읽어봐 주시면 되겠습니다.
<과거연재 살펴보기>
[1부] 네트워크 포렌식 의미, 그리고 패킷 해부
[2부] 유용한 네트워크 분석 도구 소개와 패킷분석 입문
패킷 분석 도구가 다양함에도 불구하고 한두 가지의 도구만으로 패킷을 분석하려는 경우가 많다. 하지만, 활용할 수 있는 도구는 매우 다양하고, 패킷 파일에서 찾고자 하는 정보를 빨리 얻을 수 있는 효율적인 방법도 있음을 지난호에서 설명했다.
그러나, 다양한 패킷 분석 도구가 있다고 해서 모든 분석을 쉽게 해낼 수 있는 것은 아니다. 그래서 이번 호에서는 몇 가지 사례를 살펴봄으로써 패킷 분석 경험을 함께 나눠보고자 한다.
그러나, 다양한 패킷 분석 도구가 있다고 해서 모든 분석을 쉽게 해낼 수 있는 것은 아니다. 그래서 이번 호에서는 몇 가지 사례를 살펴봄으로써 패킷 분석 경험을 함께 나눠보고자 한다.
누군가 이미 경험했던 것을 공유하고 배우는 것은 소중하다. 내가 경험해보지 못한 것을 간접적으로나마 접할 수 있기 때문이다. 여러 관점에서 사례를 분석함으로써 새로운 경험을 해보고, 이러한 경우에 자신은 어떤 식으로 했을까 하고 생각해보는 시간을 가져보자.
1. A 기업의 UDP 트래픽 급증의 원인은 바로 이것!
A 기업은 최근 한 달 동안 간헐적으로 트래픽이 급격하게 증가해 내부에서 인터넷 사용이 힘들다고 호소했다.
문제 발생 시점의 패킷을 확인해보니 UDP 트래픽이 많이 나타나고 있었고, 이러한 패킷 형태 때문에 해킹에 의한 공격 명령을 받아 발생되는 것 아니냐 또는 악성코드에 감염된 것이 아니냐 하는 의견이 제기됐다. 과거와는 달리 요즈음은 알 수 없는 트래픽이 급격히 증가하면 악성코드를 의심하는 경우가 많다. 특히나 서비스 거부 공격을 당한 전력이 있다면 더더욱 악성코드로 간주하기 쉽다. 필자도 얼핏 훑어보니 공격 트래픽과 유사해 보였다. 하지만, 지난호에서 언급한 것과 같이 악성코드로 간주해 엉뚱한 곳에 분석의 초점을 맞추다보면 잘못된 결과를 가져올 수 있다.
일단, 분석 대상의 패킷에는 다음과 같은 트래픽이 포함돼 있었다.
- ARP
- NetBIOS
- UDP
- 웹(Web)과 같은 일반적인 트래픽 형태
- NetBIOS
- UDP
- 웹(Web)과 같은 일반적인 트래픽 형태
그 중에서도 가장 눈에 띄는 것이 UDP 트래픽이었다. 그렇다고 증상이 지속적으로 나타나는 것이 아니라 일시적으로 나타났다가 사라지곤 했다. 분석가 입장에서는 이런 부분이 가장 곤란하다. 트래픽이 계속 발생하면 추적이 비교적 용이하지만, 간헐적으로 발생하는 트래픽은 분석가를 지치게 한다.
[그림 1] 와이어샤크의 그래프를 통해 본 트래픽 흐름
우선 와이어샤크로 패킷의 전체적인 흐름을 살펴보았다. ’Protocol Hierarchy Statistics‘로 살펴보니 UDP 프로토콜의 비중이 가장 높았고, 그래프를 통해 살펴보아도 전체 흐름 중에서 UDP(빨간색 막대 그래프)가 차지하는 비중이 꽤 높게 나타났다. 전체적으로는 UDP 외에 다른 프로토콜도 의심 범위에 속하긴 하지만, 트래픽의 급격한 증가가 가장 큰 원인으로 지목됐고, 트래픽을 가장 많이 차지하는 UDP가 우선 분석 대상이라고 할 수 있다.
UDP를 살펴보니 다음과 같은 특징이 있었다.
- UDP 목적지가 255.255.255.255이며 포트번호 5432가 많이 나타남
- Payload는 256바이트인 경우가 많다.
- Payload가 1400바이트로 채운 경우도 적지 않게 보인다.
- Payload는 256바이트인 경우가 많다.
- Payload가 1400바이트로 채운 경우도 적지 않게 보인다.
[그림 2]는 실제 패킷 화면의 일부다. 이상하리만큼 단시간 내에 많은 전송이 나타난 것을 볼 수 있다.
[그림 2] 브로드캐스팅 주소로 전송되는 UDP 트래픽
패킷 데이터가 워낙 많다 보니 일일이 다 확인하기는 어렵지만, 전반적으로 살펴봤을 때 Payload는 랜덤 스타일의 데이터로 채워져 있었으며 의심할 만한 문자열은 발견되지 않았다. 전달받은 패킷 파일만 하더라도 수백 Mbps이므로 분석가가 이것을 다 살피는 데는 한계가 있다. 게다가 기본적으로 알 수 없는 문자열들의 조합으로만 이루어져 있어서 분석이 쉽지 않았다. 그런데, 필자의 눈을 사로잡은 것이 있었으니 그것은 JFIF라는 문자열이었다.
[그림 3] UDP 패킷 중 JFIF를 포함하고 있는 Payload
헤더 첫 부분에서 JFIF라는 문자열이 발견됐는데, 다른 몇몇 패킷에서도 이러한 문자열이 보였고 이것은 1400바이트로 Payload가 꽉 채워져 있었다. ‘JFIF’의 의미를 찾아보았더니 ‘JPEG File Interchange Format’였다. 이를 확인한 순간, 여러 가지 가능성이 머릿속에 떠올랐다. 자, 현재까지의 현황(fact)을 점검해 보자.
- UDP 트래픽이 항상 발생하는 것은 아니며 일시적으로 증가한다.
- Payload 중 JFIF 문자열이 포함돼 있고, 1400바이트를 채우고 있다.
- JFIF는 이미지 관련한 포맷이고, 해당 업체는 영상 관련 업체다.
- JFIF가 전달된 목적지 주소가 멀티캐스트 주소인 224.16.17.1이다.
- Payload 중 JFIF 문자열이 포함돼 있고, 1400바이트를 채우고 있다.
- JFIF는 이미지 관련한 포맷이고, 해당 업체는 영상 관련 업체다.
- JFIF가 전달된 목적지 주소가 멀티캐스트 주소인 224.16.17.1이다.
이 사실을 기초로 추가 확인을 위해 JFIF가 발견된 패킷에서 ‘UDP Follow Stream’을 이용해 흩어져 있던 패킷을 하나로 모으고 바이너리 파일로 저장했다. 그리고 UDP 헤더는 파일에서 제거하고 이미지 파일 뷰어로 열어보니 [그림 4]와 같은 이미지가 나타났다.
[그림 4] JFIF가 포함된 패킷 파일 안에서 추출한 이미지 파일
이 때에는 직접 패킷을 조합해서 바이너리를 확인했지만, 지난호를 읽은 독자라면 Foremost 도구를 이용해서 쉽게 데이터를 추출할 수도 있다.
자, 여기서 중요한 것은 이미지 화면이 나타났으며 사무실 형태의 윤곽이 보인다는 것이다. 문제 해결의 실마리가 될 수 있는 결정적 단서이다. 이 결과를 가지고 업체에 확인해 보니, 장비 개발 시 테스트를 사무용 네트워크에서 같이 진행해 트래픽이 일시적으로 크게 증가한 것이었다. 즉, 문제의 원인은 보안 이슈가 아니라 전혀 엉뚱한 곳에 있었던 것이다.
이 사례는 내부 개발자들에 의한 일시적인 트래픽 증가를 전혀 의심하지 않고, 해킹을 당해 악성코드가 설치되고 통신에 의해 일시적으로 공격 명령을 내린다는 형태의 가설이 미리 설정돼 있었다. 처음 분석을 의뢰받았을 때, 그런 사전 정보를 기준으로 하다 보니 선입견이 생기고 혼선을 초래한 것이다. 문제의 원인을 미리 결론지어 놓고 분석을 진행하면 모든 과정을 정해진 결론에 끼워맞추는 오류를 범할 수 있다. 실제로 문제는 내부 요인에 의해 발생하는 경우가 많다. 패킷 분석 시에는 모든 가능성을 열어놓고 범위를 좁히면서 문제를 찾아나가야 한다.
2. 한 가지 원인으로 단정짓고 시작하지 말자
어떤 문제가 발생했을 때, 개발자는 소프트웨어를 더 유심히 들여다보게 되고 네트워크 관리자는 네트워크 관점에서 문제를 살펴보게 된다. 전체 관점에서 문제를 보지 못하고, 각 분석가의 관점에서만 바라본다면 문제의 근원을 찾아내기 어렵다. 잘못된 첫 단추는 분석을 어렵게 만든다. 단계적으로 차근차근 문제를 찾아나가야 한다.
다음의 사례는 필자가 운영하는 시스템의 예를 든 것이다. 자동으로 FTP를 연결해 파일을 전송하는 과정이 있는데, 언젠가부터 그 전송 과정이 눈에 보일 만큼 느려졌다. 네트워크든 FTP 소프트웨어든, 원인 발생지점에 해결책도 같이 존재하기 마련이다. 전체적인 관점에서 문제의 원인을 찾기 위해 다음과 같이 진행했다.
1) FTP 클라이언트와 서버 간 트래픽 확인
tcpdump를 이용해 트래픽 덤프를 시작한 후 수동으로 FTP 전송 프로그램을 실행했다. 아래와 같은 트래픽을 관찰할 수 있었으며 NBT UDP 패킷 쿼리를 발견했다. 이 쿼리는 14:21:18에 시작돼 14:21:21까지 지속됐다. 여기서 3초간의 지연이 발생했는데, 그 원인을 찾아야 했다.
2) nslookup으로 DNS 쿼리 확인
클라이언트에서 DNS resolving이 관련이 있을까 해서 nslookup을 실행해 보았으나 정상적으로 빠르게 응답했다.
3) NetBIOS와 관련한 것 찾아 제거해보기일단 넷바이오스와 관련한 것이다 보니 시스템상에서 이와 관련한 것을 Disable한 후 같은 증상이 계속 일어나는지 확인하기로 했다. TCP/IP 설정의 고급에서 Wins → Disable TCP/IP Over Netbios를 선택하자 UDP 패킷이 발생하지 않았다. 하지만 NetBIOS 쿼리만 발생하지 않았을 뿐이지 FTP를 다시 연결해봐도 Delay는 또 발생했다. 이전에 나타났던 트래픽은 나타나지 않았지만 지연은 계속되고 있는 것이다.
시스템 관점에서 몇 가지를 확인해 보아도 증상은 해결되지 않았다.
시스템 관점에서 몇 가지를 확인해 보아도 증상은 해결되지 않았다.
4) 마지막으로, 응용 프로그램을 직접 디버깅
호출되는 FTP 응용 프로그램을 직접 디버깅해서 무엇이 원인인지 세부적으로 접근해보고자 하였다. 사용한 디버거는 Ollydbg이며, 실행하면서 각 코드별로 Delay되는 부분은 없는지 찾아나갔다. 이를 통해 0x0040A5E3 지점에서 Delay가 발생하는 것을 알 수 있었다.
호출되는 FTP 응용 프로그램을 직접 디버깅해서 무엇이 원인인지 세부적으로 접근해보고자 하였다. 사용한 디버거는 Ollydbg이며, 실행하면서 각 코드별로 Delay되는 부분은 없는지 찾아나갔다. 이를 통해 0x0040A5E3 지점에서 Delay가 발생하는 것을 알 수 있었다.
[그림 5] Ollydbg에서 확인한 접속 지연
gethostbyaddr를 Call하면서 발생된 문제였던 것이다. 여기서 5~10 초 정도의 지연이 발생했던 것인데, 이후 사용하는 DNS에서 Reverse DNS 레코드를 추가했더니 문제가 깔끔히 해결됐다.
물론, Delay가 발생해도 시스템 동작에는 큰 이슈가 없었다. 그러나 이런 지연 요소는 향후 시스템 전체 과정에 영향을 줄 수 있기 때문에 확실히 해결하고 넘어가는 것이 좋다.
여기서 짚고 넘어가야 하는 것은, 직접적인 한 가지 원인으로만 단정짓고 분석을 시작하지 말라는 점이다. 문제 해결을 위해 전체를 들여다보고 분석하는 과정에서, 트래픽에서 발견된 특정 패턴을 문제의 원인이라고 가정해 버리면 접근 관점이 한정돼 문제 해결에 시간이 걸리게 된다. 위에서 발생한 UDP 쿼리 패킷만 보고 시스템과 네트워크 관점에서 문제의 원인을 찾다보면 해결이 어려워진다는 것이다. 결국은 gethostbyaddr에 의해 발생돼 네트워크와도 연결되기는 했지만, 필자가 강조하고 싶은 것은, 문제의 원인을 파악하기 위해서는 직접적인 원인은 물론, 문제에 대한 거시적인 시각도 필요하다는 것이다.
3. TCP SYN 패킷의 급격한 증가, 무엇이 원인인가?
서비스 거부 공격(DoS : Denial of Service)의 대표적인 것 중 하나가 SYN Flooding이다. TCP 통신 연결 과정의 3-Way HandShake 중 SYN을 대량으로 생산해내는 것이다. 흔히, 속도 지연의 주 요인은 이러한 트래픽의 일시적인 증가에서 찾을 수 있다. 다음과 같은 사례도 공격 명령을 전달받아 SYN 공격을 수행한 경우이다.
트래픽이 과도하게 증가해 분석해보니 SYN Flooding 발생의 사전 단계가 존재함을 확인할 수 있었다. SYN 패킷이 연속적으로 발생하기 전 단계를 보면 attackSchedule.php 접속 후에 발생하는 것으로 추정할 수 있다. 파일 이름에 공격 정보가 담겨 있는 것으로 볼 수 있으며, 이 파일 정보에 의해 공격이 정해진다.
[그림 6] TCP SYN Flooding 공격 화면
attackSchedule.php가 어떤 내용인지 살펴보기 위해 wget을 이용해 [그림 7]과 같이 내려받아 보았다.
[그림 7] wget를 통해 확인해 본 attackSchedule.php
콤마(,)로 구분된 6개의 인자가 보이는데, 1255446000은 타임스탬프 형식인 것으로 추정된다. 이런 타임스탬프에 익숙하다면 문자열을 보고서도 이것이 시간을 나타내는 것임을 생각해 볼 수 있을 것이다. 실제 이 타임스탬프를 변환해 보면 다음과 같다:
1255446000 : 2009년 10월 14일 12:00:00 AM
1256828400 : 2009년 10월 30일 12:00:00 AM
1256828400 : 2009년 10월 30일 12:00:00 AM
즉, 공격의 시작과 종료 시간임을 추정해 볼 수 있다. 다음에 이어지는 것은 공격 대상지의 URL과 포트 번호다.
네트워크에서 덤프한 이 패킷 정보만 가지고 만들어 볼 수 있는 시나리오는 다음과 같다.
1) AttackSchedule.php 후에 SYN Flooding 공격이 시작됐다.
2) 공격은 2009년 10월 14일 12:00부터 2009년 10월 30일 12:00까지이다.
3) SYN 공격은 출발지가 Spoofing된 랜덤 주소를 가지고 있고, 공격 대상은 한 곳이다.
4) AttackSchedule.php에서 공격 시작/종료 시간과 대상을 전달받는다.
5) 공격이 시작된 클라이언트는 111.2.0.35이며, 이곳은 악성코드에 감염됐을 것으로 추정된다.
2) 공격은 2009년 10월 14일 12:00부터 2009년 10월 30일 12:00까지이다.
3) SYN 공격은 출발지가 Spoofing된 랜덤 주소를 가지고 있고, 공격 대상은 한 곳이다.
4) AttackSchedule.php에서 공격 시작/종료 시간과 대상을 전달받는다.
5) 공격이 시작된 클라이언트는 111.2.0.35이며, 이곳은 악성코드에 감염됐을 것으로 추정된다.
이와 같은 시나리오에 근거하여 관리자는 문제를 해결하기 위해 클라이언트인 111.2.0.35를 네트워크에서 일시적으로 분리하고, 내부 네트워크에서 또 다른 공격 명령을 받아올 수 있으므로 118.159.239.125를 차단한다. 그리고 111.2.0.35 IP의 컴퓨터를 조사해 악성코드를 제거하게 될 것이다. 마지막으로, 어떻게 감염되었는지 역추적하여 재감염을 막을 수 있도록 검토해야 한다. 단순히 현재의 문제 해결에만 집중하고 문제의 근본 원인을 조사하지 않는다면 재발 가능성이 높으므로 주의해야 한다.
이 사례에서 배울 점은, 패킷 발생 전후 관계를 살펴 문제 발생의 원인을 찾아볼 수 있다는 것이다. 문제가 시작된 시점을 파악하고 그 때부터 거꾸로 찾아나가야 한다.
4. 의심스러운 파일 다운로드, 확장자를 너무 믿지 말자!
흔히 파일의 확장자를 보면 그 유형을 알 수 있다. DOC 파일은 워드 파일이고, HWP는 아래아한글, HTML은 웹 파일임을 알 수 있다. 또 JPG, GIF, PNG는 대표적인 이미지 파일들이다. [그림 8]은 특정 도메인에 대한 DNS 쿼리가 발생하고 그 후에 HTTP 프로토콜을 통해 bit.gif를 내려받은 예다.
[그림 8] 확장자를 이미지 파일로 위장해 내려받는 악성코드 트래픽
패킷 자체만 보면 정상적인 웹 트래픽으로 의심할 여지가 없다. 정상 트래픽으로 간주하고 넘어가기 쉽지만, bif.gif를 조금 더 들여다보면 이것이 이미지 파일이 아님을 알 수 있다. [그림 9]와 같이 이미지 파일을 내려받아 파일의 유형을 살펴보니 이미지가 아니라 ASCII 텍스트 형태로 판단된다. 해당 파일에서 임의의 문자열들을 발견할 수 있다.
[그림 9] 내려받은 bit.gif 파일의 유형과 내용을 살펴본 화면
위와 같은 문자열 스타일만 보고서도 ‘아, 이것은 인코딩 되어있구나’ 하고 알아챌 수도 있을 것이다. ‘아니, 이걸 어떻게 알지?’ 하고 반문한다면, 필자가 앞서 패킷 분석에는 경험 또한 중요하다고 이야기한 것을 상기하기 바란다. 이 문자열들은 BASE64로 인코딩돼 있는데, 이것은 이메일 전송 시에 많이 이용되는 인코딩 중의 하나이다. 만약 이러한 것을 모른다면, 이것을 알아내고 해독하기까지 적지 않은 시간이 필요했을지도 모른다. 다양한 경험이 그만큼 중요한 것이다.
BASE64로 인코딩돼 있는 것을 확인했으니 [그림 10]과 같이 해독하면 된다. 디코딩을 수행하니 임의의 문자열에서 정형화된 문자열이 나타났다. 설정 파일 형태로 추정되는 내용으로 악성코드가 이것을 이용해서 동작하는 것으로 추정할 수 있다.
[그림 10] base64로 인코딩된 bit.gif 파일을 디코딩한 화면
bit.gif가 실제로는 이미지 파일이 아니고, 문자열 내용도 인코딩돼 있는 것으로 보아서는 정상적인 형태로 간주하기 힘들다. 네트워크 내에서 이와 같은 형태가 관찰되는지 확인하기 위해 ngrep을 통해 추가 확인할 수 있다.
# ngrep “GET /bit.gif”
패턴 확인을 통해 추가로 또 다른 클라이언트를 찾아볼 수 있다. 또한, 다운로드되는 곳의 IP를 방화벽에서 차단해 확산을 예방할 수도 있다. 문제를 파악한 후 패킷을 분석해 이와 같은 식으로 사후 처리는 할 수 있다. 하지만, 앞서 bit.gif가 악의적인 것은 어떻게 알아냈을까?
사실 bit.gif뿐만 아니라 이 예제에서는 실제 패킷 분석을 통해 얻은 정보를 가지고 활용하는 방법을 설명하고 있다. 그러나 처음 문제를 인지하고 이러한 과정을 순차적으로 적용해 원인을 찾아내기까지가 쉽지 않다.
모든 상황이 경우에 따라 다르므로 정형화하기는 힘들지만, 증상이 나타나고 나서야 조사에 착수하는 것이 일반적이다. 물론, 주기적인 모니터링으로 사전에 문제를 발견하고 원인을 해결하는 것이 가장 좋다. 증상을 발견하고 나면 해당 증상을 기준으로 패킷을 살펴보거나 의심스러운 패턴들을 걸러내야 하는데, 이 작업에 많은 시간이 걸린다. bit.gif로 보면 해당 파일을 다운로드하기 전 발생한 도메인 요청에서 힌트를 얻을 수 있다.
모든 상황이 경우에 따라 다르므로 정형화하기는 힘들지만, 증상이 나타나고 나서야 조사에 착수하는 것이 일반적이다. 물론, 주기적인 모니터링으로 사전에 문제를 발견하고 원인을 해결하는 것이 가장 좋다. 증상을 발견하고 나면 해당 증상을 기준으로 패킷을 살펴보거나 의심스러운 패턴들을 걸러내야 하는데, 이 작업에 많은 시간이 걸린다. bit.gif로 보면 해당 파일을 다운로드하기 전 발생한 도메인 요청에서 힌트를 얻을 수 있다.
수집된 패킷 파일에서 여러 가지 형태를 파악하는 중에 도메인을 확인하는 과정이 있었다고 가정해보자. 해당 도메인 이름에서 일반적이지 않은 도메인 이름을 대상으로 그 앞뒤 패킷을 확인한다. 도메인 요청 후에 나타나는 행동과 다운로드되는 bit.gif 파일의 패킷 데이터가 이미지가 아니라 인코딩된 문자열이었다면 더욱 의심스럽다.
5. 패킷 분석을 통해 대응 능력을 갖출 수 있다
웰치아(Win32/Welchia.worm) 웜은 윈도우의 RPC DCOM 취약점을 이용해 전파되는 것으로, 감염되면 ICMP 패킷을 전송하면서 살아있는 시스템을 찾는다. 2003년에 보고된 것이지만, 이 당시의 네트워크 증상을 경험 삼아 공유하면 도움이 될 것 같다.
대표적인 트래픽 증상은 ICMP를 발생시키고 스캐닝으로 인하여 ARP 트래픽도 함께 증가한다는 점이다. [그림 11]과 같이 ICMP 유형이 8번인 ‘Echo Request’를 발생시켰다. 하지만 ICMP, ARP는 일반적인 네트워크 상황에서도 발생되는 것인데, 무엇이 다르다는 것일까?
[그림 11] 웰치아 웜에 감염된 패킷
다른 부분이 무엇인지 찾아내야 하는 것이 바로 여러분의 몫이다. [그림 11]의 패킷을 보면 ARP 패킷 요청 IP 주소가 연속적으로 이어진다. 같은 시간대에 연속적인 주소로 이렇게 발생시킨다는 것은 스캐닝과 같은 형태일 가능성이 크다. 또, ICMP 패킷을 세부적으로 들여다보면 [그림 12], [그림 13]과 같이 볼 수 있다.
[그림 12] 웰치아 웜이 발생시킨 ICMP 패킷의 Payload
[그림 13] 웰치아 웜이 발생시킨 ICMP 패킷의 헤더 정보
Identifier 값이 0x0200으로 고정돼 있고, Payload 크기가 64바이트로 동일하다. 거기다가 데이터 값이 0xaa로만 채워져 있다. 만일 윈도우 시스템을 사용한다면 ping을 실행해보고 패킷 데이터를 살펴보라. abcdefg와 같은 값을 볼 수 있을 것이다. 윈도우에서 사용하는 경우는 이와 같은 유형을 가지고 있지만, 0xaa로 64바이트가 다 채워져 있다는 것이 이상하다.
[그림 14] 윈도우 ICMP 패킷
이런 정보를 기준으로 내부에서 발생한 악의적 행동들에 대해서 판단할 수 있고, 자체적으로 방화벽이나 IPS 등의 패턴을 만들어 빠르게 대응할 수 있다. 더불어 네트워크상에서 이런 형태의 패킷이 나타났다면 웰치아 웜에 감염됐다고 판단할 수 있다.
트래픽의 양도 파악해 네트워크 장비들에 어떤 영향을 끼칠 수 있는가 예측해 볼 수 있다. 가령 웰치아 웜의 경우 크기가 92바이트다. C 클래스 대역에 패킷을 보내는 데에는 4초 정도의 시간이 소요됐고, 대략 초당 5.9K, 분당 353K 정도의 트래픽을 유발했다. 서비스 거부 공격에 이용되는 트래픽에 비하면 적은 양으로, 과도하게 네트워크 장비에 영향을 줄 수치는 아니다.
악성코드 트래픽 분석만으로도 여러분 스스로 초도 대응을 할 수 있다는 점을 잊지 말라.
6. ARP 스푸핑, 응답을 무조건 신뢰하지 마라
ARP(Address Resolution Protocol)는 IP 주소와 맥(MAC) 주소를 연결해 주는 역할을 한다. 이로 인해 우리는 통신을 할 수 있는 것이다. 하지만, ARP 패킷은 인증 과정이 포함돼 있지 않고 무조건적으로 ARP 패킷을 수용한다는 데에 문제가 있다. 이는 내부 네트워크 장애를 유발할 수 있으며, 데이터 스니핑에 의한 정보 유출, 악성코드 유포와 같은 문제를 안고 있다. 실제로 악성코드에서 ARP 스푸핑을 이용해 문제가 발생되는 사례를 살펴보자.
111.2.0.1이 게이트웨이이며, 111.2.0.37은 공격자 PC로 조작된 ARP 스푸핑 패킷을 전송해 111.2.0.35 클라이언트의 게이트웨이 주소를 111.2.0.37로 변경했다. 게이트웨이가 변경됨에 따라 111.2.0.35에서 발생되는 모든 트래픽은 111.2.0.37을 경유하게 되며, 공격자는 중간에서 트래픽을 위•변조할 수 있게 된다.
[그림 15] 게이트웨이 주소인 111.2.0.1의 주소가 변조된 패킷 화면
정상 클라이언트의 컴퓨터에서 ARP 주소를 살펴보면 공격자의 맥 주소인 00-11-d8-c3-33-63으로 기본 게이트웨이 주소가 변조된 것을 [그림 16]과 같이 확인할 수 있다.
[그림 16] 윈도우 도스 창에서 확인한 ARP 테이블 변조
7. 알 수 없는 데이터 값, 이것의 의미는 무엇일까?
실질적인 패킷 데이터는 Payload에 많이 담겨있는데, 문자열만으로도 의미를 파악할 수 있는 것이 있지만 암호화된 데이터나 공격 코드 등은 눈으로만 보고 판단하기가 어렵다. 더욱 깊게 패킷을 분석한다면 이런 이진 바이너리 데이터에서도 의미 있는 정보를 추출할 수 있어야 한다. [그림 17]은 WMF(Windows Metafile) 포맷에서 발견된, 취약점이 전송되는 패킷 화면을 잡아본 것이다.
[그림 17] WMF 취약점을 이용한 파일 전송 패킷 화면
이 바이너리 코드만 보고서는 어떤 내용인지 알기 힘들다. 만약 이런 형태의 분석에 익숙하다면 HEX 코드의 흐름만 보아도 의심스러워질 것이다. 90 90 90과 같은 NOP 코드와 그 아래 이어지는 반복되는 어떤 유형들이 공격 유형과 비슷하기 때문이다.
이 데이터를 디버그 같은 곳에서 분석하기 위해서는 코드 형태로 바꿔주어야 하는데, 가장 쉬운 방법은 해당 코드를 실행 파일 형태로 만들어주는 것이다. 와이어샤크에서 해당 데이터가 있는 패킷에서 Follow TCP Stream을 선택하고 C Arrays 옵션을 선택해 보자. 그러면 C 어레이 형태로 [그림 18]과 같이 만들어진다.
[그림 18] 와이어샤크에서 TCP Stream 데이터를 C Array로 변환
그 코드를 가지고서 다음과 같이 컴파일해주면 된다.
제일 상단의 wmf_bin 부분은 와이어샤크에서 만들어주는 데이터이고, main 부분만 가져다 사용하면 된다. 컴파일하여 만들어진 실행 파일을 Ollydbg와 같은 프로그램에서 로딩하여 90 90 90이 있는 위치부터 분석을 시작하면 된다. [그림 19]는 Ollydbg에서 로드하여 의심스러운 Payload 데이터부터 코드를 살펴본 것이다. NOP 코드가 보이고 00402091 번지까지는 정상적인 기계어 코드로 보이지만 이후는 조금 달라 보인다. 코드 자체가 0x1C9만큼 XOR되어 있기 때문이다.
[그림 19] XOR되어 있는 코드를 해독하는 루틴의 셸 코드
그 값을 풀어내면 [그림 20]과 같이 원래의 코드와는 다른 정상적인 코드가 나타난다.
[그림 20] XOR 88로 해독되어 나온 정상 기계어 코드
이 Payload 데이터는 셸 코드이며 특정 포트로 바인딩하여 백도어를 생성한다. 패킷 데이터 분석을 통해 이것이 어떤 의미의 데이터인지 알아낼 수 있게 된 것이다. 이 예제는 필자가 특정 데이터를 기준으로 해서 실질적으로 Payload를 해독하는 과정을 보여준 것이지만 수많은 패킷 데이터에서 의심스러운 Payload를 찾아내고 그것을 분석하는 것은 쉽지 않은 과정이다. 여기서는 Payload를 그냥 바이너리 데이터로만 보지 않고, 정보를 추출해 낼 수도 있다는 방법에 의미를 두면 되겠다.
패킷 분석, 많은 경험이 필요한 이유는?
3부로 나누어 네트워크 포렌식 분석에 대한 방법과 경험을 공유해보았다.
필자가 생각하는 패킷 분석의 범위는 넓다. 수만 개의 프로토콜이 존재하고, 기업마다 각기 다른 네트워크 환경과 구성, 그리고 그 위에서 돌아가는 수없이 많은 애플리케이션들이 고속화된 네트워크 인프라 위에서 동작하고 있다. 그러므로 모든 것을 다 알 수는 없다. 그러기에 패킷 분석에는 폭넓은 경험이 필요한 것이다.
몇 가지 사례만으로 패킷 분석 방법을 설명하기에는 너무나 부족하다. 고객의 네트워크 환경과 내부 구성, 그리고 다양한 응응 프로그램들은 복잡함을 더해주고 있기 때문에 여기서 소개한 사례는 아주 일부분에 불과할 것이다. 비록 작은 경험이지만, 이 경험들이 여러분의 패킷 분석 과정의 길잡이가 되었으면 한다.
앞서 언급한 것과 같이 끈기와 의지로 패킷 분석의 다양한 경험을 쌓는다면 여러분은 전문가가 될 수 있을 것이다.
더 많은 정보를 원한다면, 필자가 운영하는 블로그인 ‘패킷인사이드(PacketInside.com)’를 방문해보길 추천한다.@
[참고]
2012년 3월 15일 목요일
이더넷상의 프로토콜 오버헤드는 얼마나 될까?
네트워크 상에서의 프로토콜 오버헤드에 대한 글이 있어서 소개해 본다. 우리가 사용하고 있는 이더넷과 프로토콜 스택상에서 얼마나 빨리 전송할 수 있을지, 얼마나 많은 대역폭을 사용하는지 가늠해 볼 수 있다. 다음은 프로토콜 오버헤드를 이더넷, 기가비트 이더넷, ATM, POS 등으로 나누어 소개한 자료이다.
주소 : http://sd.wareonearth.com/~phil/net/overhead/
예를 들어 이더넷의 프레임 포맷을 살펴보면,
로 구성되어 있다. 이더넷의 오버헤드 요소를 살펴보면 ,
12 gap + 8 preamble + 14 header + 4 trailer = 38 bytes/packet w/o 802.1q
12 gap + 8 preamble + 18 header + 4 trailer = 42 bytes/packet with 802.1q
로 된다. VLAN 태그가 없이도 38 바이트 사용하는 경우 42 바이트가 된다. 이더넷 페이로드를 포함한 데이터 비율은 다음과 같이 된다:
1500/(38+1500) = 97.5293 % w/o 802.1q tags
1500/(42+1500) = 97.2763 % with 802.1q tags
1) 이더넷상의 TCP 전송
헤더 압축은 없다고 가정
IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
TCP 헤더 20 바이트 추가
TCP 타임스탬프 옵션 값 12 바이트 추가
이더넷을 통한 최대 TCP 페이로드 데이터 전송률은 다음과 같다:
(1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
(1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
(1500-52)/(42+1500) = 93.9040 % 802.1q, IPv4, TCP timestamps
(1500-60)/(38+1500) = 93.6281 % IPv6, minimal headers
(1500-72)/(38+1500) = 92.8479 % IPv6, TCP timestamps
(1500-72)/(42+1500) = 92.6070 % 802.1q, IPv6, ICP timestamps
2) 이더넷상의 UDP 전송
IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
UDP 헤더 8바이트 추가
이더넷을 통한 최대 UDP 페이로드 데이터 전송률은 다음과 같다:
(1500-28)/(38+1500) = 95.7087 % IPv4
(1500-28)/(42+1500) = 95.4604 % 802.1q, IPv4
(1500-48)/(38+1500) = 94.4083 % IPv6
(1500-48)/(42+1500) = 94.1634 % 802.1q, IPv6
이렇게 소개하고 있다. 이외 기가비트 이더넷은 점보 프레임을 사용하는 경우 최대 전송은 990.042 Mbps 이며, 점보 프레임 없이는 941.482 Mpbs 이다. 이론적으로만 보면 점보 프레임을 사용하는 경우가 전송률 면에서 더 유리하다. 점보프레임은 얼마전 블로그에서 소개한 적이 있으니 참고해 보길 바란다.
프로토콜 오버헤드를 참고 삼아 알아두면 좋을것 같다.
[참고]
1. Protocol Overhead
http://sd.wareonearth.com/~phil/net/overhead/
2. 점보프레임(Jumbo Frame)으로 전송속도 높이기
http://www.packetinside.com/2012/03/jumbo-frame.html
주소 : http://sd.wareonearth.com/~phil/net/overhead/
예를 들어 이더넷의 프레임 포맷을 살펴보면,
- 6 바이트 목적지 주소
- 6 바이트 출발지 주소
- 필요시 이용되는 4바이트의 802.1q VLAN 태그 (옵션)
- 2 바이트 길이/타입
- 46-1500 바이트 데이터 (페이로드)
- 4 바이트 CRC
로 구성되어 있다. 이더넷의 오버헤드 요소를 살펴보면 ,
12 gap + 8 preamble + 14 header + 4 trailer = 38 bytes/packet w/o 802.1q
12 gap + 8 preamble + 18 header + 4 trailer = 42 bytes/packet with 802.1q
로 된다. VLAN 태그가 없이도 38 바이트 사용하는 경우 42 바이트가 된다. 이더넷 페이로드를 포함한 데이터 비율은 다음과 같이 된다:
1500/(38+1500) = 97.5293 % w/o 802.1q tags
1500/(42+1500) = 97.2763 % with 802.1q tags
1) 이더넷상의 TCP 전송
헤더 압축은 없다고 가정
IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
TCP 헤더 20 바이트 추가
TCP 타임스탬프 옵션 값 12 바이트 추가
이더넷을 통한 최대 TCP 페이로드 데이터 전송률은 다음과 같다:
(1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
(1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
(1500-52)/(42+1500) = 93.9040 % 802.1q, IPv4, TCP timestamps
(1500-60)/(38+1500) = 93.6281 % IPv6, minimal headers
(1500-72)/(38+1500) = 92.8479 % IPv6, TCP timestamps
(1500-72)/(42+1500) = 92.6070 % 802.1q, IPv6, ICP timestamps
2) 이더넷상의 UDP 전송
IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
UDP 헤더 8바이트 추가
이더넷을 통한 최대 UDP 페이로드 데이터 전송률은 다음과 같다:
(1500-28)/(38+1500) = 95.7087 % IPv4
(1500-28)/(42+1500) = 95.4604 % 802.1q, IPv4
(1500-48)/(38+1500) = 94.4083 % IPv6
(1500-48)/(42+1500) = 94.1634 % 802.1q, IPv6
이렇게 소개하고 있다. 이외 기가비트 이더넷은 점보 프레임을 사용하는 경우 최대 전송은 990.042 Mbps 이며, 점보 프레임 없이는 941.482 Mpbs 이다. 이론적으로만 보면 점보 프레임을 사용하는 경우가 전송률 면에서 더 유리하다. 점보프레임은 얼마전 블로그에서 소개한 적이 있으니 참고해 보길 바란다.
프로토콜 오버헤드를 참고 삼아 알아두면 좋을것 같다.
[참고]
1. Protocol Overhead
http://sd.wareonearth.com/~phil/net/overhead/
2. 점보프레임(Jumbo Frame)으로 전송속도 높이기
http://www.packetinside.com/2012/03/jumbo-frame.html
2012년 3월 11일 일요일
요즘 아파트는 무선 AP(Access Point) 설치도 기본 !
새롭게 이사를 하느라 요새 블로깅이 뜸해졌습니다. 이번에 이사한 집이 홈 네트워크가 잘 되어 있더군요. 단자함도 RJ45 잭으로 깔끔하게 연결되어 있고말이죠.
그런데 몇일이 지나서 거실 천장위에서 발견한 재미난 장난감이 있었습니다. 바로 무선 AP 가 달려있더군요.
그래서 단자함을 다시 살펴보니 PoE 로 연결되어 있는 것이었습니다. 즉, Power over Ethernet 으로 이더넷 케이블을 통해서 전원을 공급하는 것입니다. 오래전부터 들어보긴 했지만 실제로 연결되어 있는 것은 처음보았네요. PoE 는 기본적으로 Category 5 (5E) 이상의 케이블을 요구합니다. 살펴보니 다 5E 케이블을 사용했네요.
한 가지 아쉬운점은 AP 가 기본 설정값으로만 동작이 됩니다. 보안 설정도 안 되어 있고, 할 수 있는 부분도 없는거 같습니다. 아무래도 취약한 상태다 보니 사용하기는 조금 껄끄러운데, 조금 더 살펴보아야 할거 같네요.
집안의 홈네트워크도 재미있는 부분인데,
가스, 조명, 환기 등을 다 제어가 가능합니다. 물론, 원격에서도 말이죠!
재미있을것 같지 않나요? ( 보안적인 관점에서도)
파헤쳐 보는대로 블로그에서도 공유할께요~ :-)
From Rigel
[참고]
1. Power over Ethernet
http://en.wikipedia.org/wiki/Power_over_Ethernet
그런데 몇일이 지나서 거실 천장위에서 발견한 재미난 장난감이 있었습니다. 바로 무선 AP 가 달려있더군요.
그래서 단자함을 다시 살펴보니 PoE 로 연결되어 있는 것이었습니다. 즉, Power over Ethernet 으로 이더넷 케이블을 통해서 전원을 공급하는 것입니다. 오래전부터 들어보긴 했지만 실제로 연결되어 있는 것은 처음보았네요. PoE 는 기본적으로 Category 5 (5E) 이상의 케이블을 요구합니다. 살펴보니 다 5E 케이블을 사용했네요.
한 가지 아쉬운점은 AP 가 기본 설정값으로만 동작이 됩니다. 보안 설정도 안 되어 있고, 할 수 있는 부분도 없는거 같습니다. 아무래도 취약한 상태다 보니 사용하기는 조금 껄끄러운데, 조금 더 살펴보아야 할거 같네요.
집안의 홈네트워크도 재미있는 부분인데,
가스, 조명, 환기 등을 다 제어가 가능합니다. 물론, 원격에서도 말이죠!
재미있을것 같지 않나요? ( 보안적인 관점에서도)
파헤쳐 보는대로 블로그에서도 공유할께요~ :-)
From Rigel
[참고]
1. Power over Ethernet
http://en.wikipedia.org/wiki/Power_over_Ethernet
2012년 3월 7일 수요일
구글 클라우드 프린트 기능을 통해 언제 어디서나 OK!
구글의 클라우드 프린트 기능을 이용하면, 프린터 기능을 한껏 더 높일 수가 있다. 프린터를 어디서나 이용할 수 있도록 만들어 준다. 클라우드 기능이 없는 프린터는 프린터가 연결된 컴퓨터를 통해서 가능하나, 컴퓨터가 계속 켜져 있어야 한다는 단점이 있다. 하지만, 구글 클라우드 프린터를 지원하는 프린터라면 프린터 만으로도 언제 어디서나 쉽게 이용할 수 있다.
여러 가지 활용방법이 있겠지만, 나 같은 경우는 리눅스 환경에서 유용하게 이용하고 있다. 회사에 새롭게 설치된 프린터 환경이 리눅스는 아직 제대로 지원하지 않고 있다. 이럴때, 윈도우 환경에서 설정된 프린터를 구글 클라우드로 연결시켜놓고, 리눅스에서 브라우저를 통해 연결된 클라우드 프린터를 선택만 해 주면 프린터 사용이 가능해 지는 것이다.
사용방법은 간단하다.
크롬 브라우저에서 옵션-> 고급설정을 보면 Google Cloud Print 가 보인다. 여기서 Google Cloud Print 에 로그인을 선택하면 된다. 그리고 연결 해주는 것만으로 끝난다.
다음은 리눅스에 설치된 크롬 브라우저에서 인쇄를 누른 것으로 Destination 에 Print with Google Cloud Print 가 보인다. 구글 클라우드 프린트로 인쇄를 해 주면 윈도우에 연결된 프린터를 통해서 결국 인쇄가 되어 리눅스에서도 쉽게 사용이 가능해진다.
2012년 3월 1일 목요일
점보프레임(Jumbo Frame)으로 전송속도 높이기
점보프레임(Jumbo Frame)을 소개해 볼까 한다. 기본적으로 우리가 지금 사용하는 MTU(Maximum Transmission Unit) 값은 1500 바이트이다. 실제 전송시에는 여기에 프레임 헤더를 붙이면 18 바이트가 추가되어 기본적으로는 1518 바이트가 된다. 점보프레임은 이름에서 느껴지는 것과 같이 프레임 크기를 크게 늘려주는 것이다. 점보프레임은 9000 바이트까지 MTU 를 확장시켜 준다. 처음 이더넷 프레임으로 1500 바이트가 사용된 것은 과거 낮은 통신속도와 비교적 높게 발생되었던 에러 비율 때문에 그런것이다. 즉, 데이터를 전송하다가 에러가 발생되면 단지 1500 바이트 부분만 에러를 정정하여 재 전송하면 되는 것이었다.
하지만 각 프레임은 네트워크 하드웨어와 소프트웨어적으로 프로세싱하는 것이 필요하다. 만약 프레임 사이즈가 커진다면 시스템에서 전송하기 위해 사용되는 처리 CPU 가 더 줄어든다. 그러므로 9000 바이트 이상으로 커진다면 데이터를 자르는 기준이 적어지므로 더욱 빠른 속도로 전달될 수 있는 것이다. 한번에 1500 바이트가 아닌 9000 바이트를 전송하기 때문이다.
그렇지만, 요새 하드웨어 성능은 워낙 좋아졌기 때문에 점보프레임으로 인한 성능 향상은 그리 크지는 않을 수 있다. 점보프레임이 2000년대 초 소개되었을 당시는 어느 정도 효과를 볼 수 있었을지 몰라도 빠르게 발전하는 하드웨어 속도에 비하면 프레임을 나누기 위한 CPU 사용은 적기 때문이다. 그래도 모든 사람이 좋은 하드웨어를 사용하는 것은 아니기 때문에 어느정도 효과는 있을 수 있다. 경험상 10-20% 정도의 향상을 얘기하는 경우가 많다.
점보프레임을 사용하기 위해서는 스위치, NIC 카드등에서 지원해야 하며, 요즘 사용되는 장비들은 대부분 지원한다. 다음 그림은 점보프레임이 설정된 패킷을 덤프한 것으로 데이터 크기가 8920 바이트나 되는 것을 확인할 수 있다.
시스템상에서의 설정은 MTU 값을 변경해 주는 것으로 간단하다. 다음과 같이 확인해 볼 수 있는데, 다음과 같이 설정전에는 MTU 가 1500 인 것을 볼 수 있다. (리눅스의 경우 커널 2.6.17 이상이면 지원된다)
ifconfig 로도 확인해 볼 수 있다.
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:78501442 errors:0 dropped:0 overruns:0 frame:0
TX packets:29641408 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:34935770805 (32.5 GiB) TX bytes:25180384472 (23.4 GiB)
Interrupt:48 Memory:d6000000-d6012800
해당 인터페이스의 MTU 를 다음과 같이 설정해 준다.
# ifconfig eth6 mtu 9000
# ifconfig eth6
eth6 Link encap:Ethernet HWaddr [삭제]
UP BROADCAST RUNNING SLAVE MULTICAST MTU:9000 Metric:1
RX packets:2892 errors:0 dropped:0 overruns:0 frame:0
TX packets:2728 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:256450 (250.4 KiB) TX bytes:2785780 (2.6 MiB)
Interrupt:32 Memory:d8000000-d8012800
다시 ip 명령어로 확인해 보면 9000 바이트임을 확인할 수 있다.
tcpdump 로 트래픽을 캡쳐할 때도 캡쳐 크기를 늘려줘야 되므로 -s 로 9000 바이트를 지정해 주어야 한다.
# tcpdump -i bond1 -s 9000 -n -w jumbo.pcap
tcpdump: listening on bond1, link-type EN10MB (Ethernet), capture size 9000 bytes
다음은 tshark 로 프레임 크기를 살펴본 것으로, 1500 바이트 이상의 크기가 많이 보이는 것을 확인 할 수 있다.
# tshark -i bond1 -e frame.len -Tfields
9014
9014
66
9014
9014
66
9014
430
66
114
4210
66
114
9014
7550
66
114
114
66
4210
9014
66
9014
9014
66
6038
114
9014
^C1947 packets captured
자동으로 설정하기 위해서는 /etc/network/interfaces 에서 MTU=9000 으로 지정해 주면 된다. 그리고 재시작 해 주면 된다.
# /etc/init.d/networking restart
위 경우는 우분투, 데비안의 경우고 CentOS, 레드햇 계열은
# vi /etc/sysconfig/network-script/ifcfg-eth0
를 수정해 주면 된다.
참고로 호환성에 문제가 있을 수 있으므로 상황에 따라 판단하여 사용해야 한다.
[참고]
1. 위키피디아 점보프레임
http://en.wikipedia.org/wiki/Jumbo_frame
하지만 각 프레임은 네트워크 하드웨어와 소프트웨어적으로 프로세싱하는 것이 필요하다. 만약 프레임 사이즈가 커진다면 시스템에서 전송하기 위해 사용되는 처리 CPU 가 더 줄어든다. 그러므로 9000 바이트 이상으로 커진다면 데이터를 자르는 기준이 적어지므로 더욱 빠른 속도로 전달될 수 있는 것이다. 한번에 1500 바이트가 아닌 9000 바이트를 전송하기 때문이다.
그렇지만, 요새 하드웨어 성능은 워낙 좋아졌기 때문에 점보프레임으로 인한 성능 향상은 그리 크지는 않을 수 있다. 점보프레임이 2000년대 초 소개되었을 당시는 어느 정도 효과를 볼 수 있었을지 몰라도 빠르게 발전하는 하드웨어 속도에 비하면 프레임을 나누기 위한 CPU 사용은 적기 때문이다. 그래도 모든 사람이 좋은 하드웨어를 사용하는 것은 아니기 때문에 어느정도 효과는 있을 수 있다. 경험상 10-20% 정도의 향상을 얘기하는 경우가 많다.
점보프레임을 사용하기 위해서는 스위치, NIC 카드등에서 지원해야 하며, 요즘 사용되는 장비들은 대부분 지원한다. 다음 그림은 점보프레임이 설정된 패킷을 덤프한 것으로 데이터 크기가 8920 바이트나 되는 것을 확인할 수 있다.
시스템상에서의 설정은 MTU 값을 변경해 주는 것으로 간단하다. 다음과 같이 확인해 볼 수 있는데, 다음과 같이 설정전에는 MTU 가 1500 인 것을 볼 수 있다. (리눅스의 경우 커널 2.6.17 이상이면 지원된다)
# ip route get 111.6.0.25
111.6.0.25 dev bond1 src 111.6.0.30
cache mtu 1500 advmss 1460 hoplimit 64
111.6.0.25 dev bond1 src 111.6.0.30
cache mtu 1500 advmss 1460 hoplimit 64
ifconfig 로도 확인해 볼 수 있다.
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:78501442 errors:0 dropped:0 overruns:0 frame:0
TX packets:29641408 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:34935770805 (32.5 GiB) TX bytes:25180384472 (23.4 GiB)
Interrupt:48 Memory:d6000000-d6012800
해당 인터페이스의 MTU 를 다음과 같이 설정해 준다.
# ifconfig eth6 mtu 9000
# ifconfig eth6
eth6 Link encap:Ethernet HWaddr [삭제]
UP BROADCAST RUNNING SLAVE MULTICAST MTU:9000 Metric:1
RX packets:2892 errors:0 dropped:0 overruns:0 frame:0
TX packets:2728 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:256450 (250.4 KiB) TX bytes:2785780 (2.6 MiB)
Interrupt:32 Memory:d8000000-d8012800
다시 ip 명령어로 확인해 보면 9000 바이트임을 확인할 수 있다.
# ip route get 111.6.0.25
111.6.0.25 dev bond1 src 111.6.0.30
cache mtu 9000 advmss 8960 hoplimit 64
111.6.0.25 dev bond1 src 111.6.0.30
cache mtu 9000 advmss 8960 hoplimit 64
tcpdump 로 트래픽을 캡쳐할 때도 캡쳐 크기를 늘려줘야 되므로 -s 로 9000 바이트를 지정해 주어야 한다.
# tcpdump -i bond1 -s 9000 -n -w jumbo.pcap
tcpdump: listening on bond1, link-type EN10MB (Ethernet), capture size 9000 bytes
다음은 tshark 로 프레임 크기를 살펴본 것으로, 1500 바이트 이상의 크기가 많이 보이는 것을 확인 할 수 있다.
# tshark -i bond1 -e frame.len -Tfields
9014
9014
66
9014
9014
66
9014
430
66
114
4210
66
114
9014
7550
66
114
114
66
4210
9014
66
9014
9014
66
6038
114
9014
^C1947 packets captured
자동으로 설정하기 위해서는 /etc/network/interfaces 에서 MTU=9000 으로 지정해 주면 된다. 그리고 재시작 해 주면 된다.
# /etc/init.d/networking restart
위 경우는 우분투, 데비안의 경우고 CentOS, 레드햇 계열은
# vi /etc/sysconfig/network-script/ifcfg-eth0
를 수정해 주면 된다.
참고로 호환성에 문제가 있을 수 있으므로 상황에 따라 판단하여 사용해야 한다.
[참고]
1. 위키피디아 점보프레임
http://en.wikipedia.org/wiki/Jumbo_frame
피드 구독하기:
글 (Atom)