패킷인사이드 2주년 그리고 2012년 새해 복 많으세요

안녕하세요,

패킷인사이드가 어느덧 개설한지 2년이 넘었네요. 2009년 12월에 만들어, 조금씩 써 나간 글들이  300 개가 좀 안되네요. 국내에서는 패킷 관련한 정보가 많지 않아 개설하였고, 이제는 많은 분들이 방문해 주고 계십니다. 언제까지 이 블로그를 계속 유지할지는 모르겠지만, 많은 것들이 공유되어 패킷분석에 도움이 되었으면 합니다. 패킷분석 뿐만 아니라, 제 업무 분야인 보안과 관심분야인 천문쪽도 더 올려볼까 합니다. :-)

패킷인사이드 방문해 주신 분들 감사드립니다.

2011년 (이제 얼마 남지 않은) 마무리 잘 하시고요,

2012년에는 건강하시고 새해 복 많이 받으세요.

패킷인사이드 주인장 Rigel 드림.

웹 페이지 평균 크기가 거의 1메가에 근접하다.

HTTP Archive 에서 발표한 리서치 결과에 따르면 웹 페이지의 평균 크기가 965KB 라고 한다. 이 수치는 작년 평균 702KB 보다 30% 증가한 값이다. 참고로, HTTP Archive 는 주요 유명 사이트를 주기적으로 스캔하고 있다.

[출처 : httparchive.org]

이제 거의 1M 에 육박하는 수준인데, 국내에서는 많은 사이트가 이미지로 도배되어 있어 이보다 훨씬 큰 사이즈가 될 것이다. 요새 인터넷 회선 속도에 비하면 이 정도는 크지 않을 수도 있지만, 모바일로 접속하는 비중이 늘다 보니 3G 에서는 이 정도가 작은 크기는 아니다.

과거 조사 결과를 보면 1995년에는 평균 웹 페이지 크기가 14KB, 2003년 93KB, 2008년 300KB 였다고 한다. 자바스크립트는 113KB 에서 172KB 로 크게 증가하였다. 재미있는 통계치 인데, 서비스 운영 입장에서 보면(정확히 말하면 네트워크 운영자) 큰 크기의 웹 페이지 증가는 망에 대한 부하를 가중시킨다. 특히나 모바일 환경에서는 말이다.

패킷을 덤프하는 입장에서도 별로 좋지는 않다. :-)

TCP/IP 프로토콜 이해하는 세가지 방법

즐거운 크리스마스 보내셨나요? :-)

요새는 블로그 쓰는 일이 쉽지가 않네요. 퇴근 후 또는 주말에 집에서 틈틈이 작성하려고는 하는데, 집에서는 컴퓨터를 켜는 시간이 많지가 않게되네요. 오늘은 인터넷 프로토콜을 배울 수 있는 곳을 소개해 볼까 합니다.

블로그내에서도 언급하려고는 하지만, 정리 하면서 일일이 열거하기는 쉽지 않더군요.
그래도 네트워크 분석관련한 자료는 패킷인사이드를 잊지 마세요.

첫째, RFC 를 살펴보면 프로토콜을 이해하는데 도움이 됩니다.

프로토콜이 마음대로 결정되는 것이 아닙니다. 시스템간 협의된 규약에 따라 통신을 하기 때문에 통신이 가능한 것입니다. 그 중심에는 IETF 에 의해서 관리되고 있는 RFC 가 있기 때문입니다. IP, TCP, UDP, ICMP, ARP 등 많은 프로토콜이 이미 RFC 문서에 정의되어 있습니다. 다음 사이트를 방문하여, 필요한 프로토콜을 검색해 찾아 보시면 해당 프로토콜을 이해하는데 큰 도움이 됩니다.

http://www.ietf.org/rfc.html

둘째, 비용이 들긴 하지만 잘 정리되어 있는 서적을 이용하는 것입니다.

책은 이미 경험이 많은 저자가 체계적으로 잘 정리해 놓은 것이므로, 무엇보다 이해하는데 큰 도움이 됩니다. TCP/IP 프로토콜의 대표적인 다음 책을 소개해 봅니다.

Ricahrd Steven's 가 작성한 3가지 책입니다.
- TCP/IP Illustrated Volume1
- TCP/IP Illustrated Volume2
- TCP/IP Illustrated Volume3


Douglas Comer's 가 작성한 3가지 책입니다.
- Internetworking with TCP/IP Volume1
- Internetworking with TCP/IP Volume2
- Internetworking with TCP/IP Volume3


이걸 다 보신다면 TCP/IP 프로토콜의 달인이 되실 것입니다. 저는 각 1권 정도씩 소유하고 있는데, 다 읽어보지도 못했네요. 이 책 외에 프로그램을 하신다면 다음 책도 추천해 봅니다.

Richard Steven's 가 작성한
- UNIX Network Programming Volume1
- UNIX Network Programming Volume2

입니다. 이 책들은 관련 전공하신 분들에게는 유명한 책들입니다.

셋째, 인터넷의 다양한 무료 정보를 이용해 보세요.

두번째에서 언급한 서적 구매는 비용이 들죠! 이런것이 부담된다면, 인터넷에서 검색해 보면 수 많은 정보를 찾아볼 수 있습니다. 어디 출처를 언급하기 힘들만큼 너무 많은 정보가 있습니다. 궁금하다면 지금 바로 검색해 보십시오.

한가지 좋은 문서를 공유하자면 IBM RedBook 중에 하나인
"TCP/IP Tutorial and Technical Overview" 책을 참고해 보세요. 거의 1000 페이지에 달하는 분량과 체계적으로 정리가 잘 되어 있습니다. 물론, 무료로 다운로드 받을 수 있습니다.

다음 링크를 참고하세요

http://www.redbooks.ibm.com/abstracts/gg243376.html

[목차]
Part 1. Core TCP/IP protocols
Chapter 1. Architecture, history, standards, and trends
Chapter 2. Network interfaces
Chapter 3. Internetworking protocols
Chapter 4. Transport layer protocols
Chapter 5. Routing protocols
Chapter 6. IP multicast
Chapter 7. Mobile IP
Chapter 8. Quality of service
Chapter 9. IP version 6
Chapter 10. Wireless IP

Part 2. TCP/IP application protocols
Chapter 11. Application structure and programming interfaces
Chapter 12. Directory and naming protocols
Chapter 13. Remote execution and distributed computing
Chapter 14. File-related protocols
Chapter 15. Mail applications
Chapter 16. The Web
Chapter 17. Network management
Chapter 18. Wireless Application Protocol
Chapter 19. Presence over IP

Part 3. Advanced concepts and new technologies
Chapter 20. Voice over Internet Protocol
Chapter 21. Internet Protocol Television
Chapter 22. TCP/IP security
Chapter 23. Port based network access control
Chapter 24. Availability, scalability, and load balancing
Appendix A. Multiprotocol Label Switching

[참고]
1. Amazon.com

(IN)SECURE 보안잡지 12월호, 취약점 분석가에게 묻고 싶었던 7가지 질문?

블로그에서도 몇 번 소개하였던 (IN)SECURE 보안잡지 ISSUE 32호가 나왔다. 주요 내용은 아래와 같다:

• 7 questions you always wanted to ask a professional vulnerability researcher
• Insights on drive-by browser history stealing
• Review: Kingston DataTraveler 6000
• RSA Conference Europe 2011
• PacketFence: Because NAC doesn't have to be hard!
• Information security and the threat landscape with Raj Samani
• Security is a dirty word
• Smartphone apps are not that smart: Insecure development practices
• Virus Bulletin 2011
• Infosec professionals: Accomplishing your day job without breaking the law
• WPScan: WordPress Security Scanner
• Securing the enterprise: Is your IT department under siege?

취약점 분석에 관심있었던 분이라면, 첫 번째 내용인 취약점 분석가에게 묻고 싶었던 7가지 질문 내용도 재미있을 것이다. 내용중에, 블로그에서 한번 소개하려고 하였던 NAC 관련 PacketFence 소개도 있고, VoIP 패킷에서 정보를 숨기는 방법인 TranSteg 가 간단히 언급되어 있기도 하다. 이전 포스팅에서 스테가노그라피를 살짝 언급하였던 내용과 비슷하게, VoIP 패킷상에서 메시지를 숨길 수 있다는 것이 다르다.

잡지는 다음 경로에서 볼 수 있다.
http://www.net-security.org/dl/insecure/INSECURE-Mag-32.pdf

[참고]
1. (IN)SECURE Magazine
http://www.net-security.org/insecuremag.php

네트워크 포렌식 의미, 그리고 패킷 해부

기업고객을 위해 발행하는 잡지인 월간 '안' 이라는 것이 있습니다. 이번에 안랩코어 행사 때 발표한 내용을 3부로 나누어 연재를 하게 되었는데, 여러분들에게도 도움이 될 것 같아 게시합니다. 글로써 그때 소개하지 못했던 내용을 좀더 다뤄보았고요, 네트워크 패킷 분석을 이해하는데 참고가 되었으면 좋겠습니다.

다음 월간 '안' 링크를 참고해 보셔도 좋습니다.

1) [Tech Report] 네트워크 포렌식 의미, 그리고 패킷 해부
2) 안철수연구소 보안매거진 월간 '安'

연재 목차 1. 네트워크 포렌식 의미, 그리고 패킷 해부(이번 호) 2. 유용한 분석 도구 소개와 패킷 분석(2012년 1월호) 3. 사례를 통해 알아가는 실전 패킷 분석(2012년 2월호)

10월 25일은 독도의 날이다. 고종황제가 1900년 10월 25일 칙령으로 독도 주권을 선포한 것을 기념하기 위해 ‘독도 참사랑운동본부’가 지정한 날이다. 벌써 111주년. 이 뜻깊은 날 안철수연구소는 소프트웨어 개발자들을 위한 전문 컨퍼런스인 ‘안랩코어 2011’을 개최했다. 그날 필자가 강연했던 네트워크 포렌식 분석 기술 발표 세션에 못다한 이야기를 지면을 통해 풀어보고자 3회에 걸쳐 연재한다.

네트워크 포렌식은 네트워크가 연관된 곳에서는 모두 이용되고 있다고 할 수 있다. 특정 영역의 대상이 아니며 IT 관련 담당자라면 누구에게나 필요한 것이다. 개발자도 예외는 아니다. 자, 그럼 지금부터 네트워크 분석의 세계로 들어가보자.

‘포렌식(Forensic)’이라고 하면 흔히 법적 증거를 찾기 위한 것을 떠올리기도 하지만, 포렌식은 분석 방법 및 과정과 같이 증거/흔적을 찾기 위한 모든 범주를 포함한다. ‘패킷 마이닝’, ‘패킷 포렌식’이라고도 불리며 필자는 분석이라는 관점에서 이야기를 나눠볼까 한다.

일단 제목부터 잠깐 들여다보자. 네트워크 포렌식 내용인데, 개발자도 알아야 한다고 말하고 있다. 네트워크 분석은 특정 분야의 누군가에게 한정된 것이 아니라 개발자부터 시작해서 네트워크 관리자, 보안 분석가/관리자, 시스템 관리자 등 많은 이들에게 필요한 부분이다. 즉, 네트워크 포렌식은 다양한 영역에서 사용되고 있으며, 네트워크와 관련된 모든 부분이 포렌식 대상이다. 그렇다면 네트워트 포렌식은 어떤 곳에 필요한 것인가? 사용되는 곳은 아주 다양하다.

● 네트워크 문제 해결
● 네트워크 성능 측정, 병목 구간, 활동 관찰
● 네트워크 최적화
● 네트워크 공격/위협 감지
● 기업 내부의 네트워크 감사, 부정 방지
● 프로그램에서 사용되는 프로토콜 네트워크 정보 확인
● IDS/IPS 시스템 시그니처 작성

네트워크 포렌식, 숨겨진 진실을 찾아라

네트워크를 분석하자면 ‘패킷’과 자주 접하게 된다. 패킷은 네트워크 흐름의 작은 단위로 네트워크 통신의 모든 것이 담겨 있다고 볼 수 있다. 패킷은 출발지와 목적지 간 통신을 하며, 이 패킷을 들여다보면 어떤 내용의 데이터인지 파악할 수가 있다. 이렇게 패킷의 깊은 곳까지 살펴볼 수 있는 것은 DPI(Deep Packet Inspection)라는 기술 덕분이다. DPI는 IDS/IPS, 그리고 전통적인 Stateful 방화벽의 기능적인 부분이 통합된 것이라고 할 수 있다. 과거 IP, 포트만 차단하는 방식을 넘어서 OSI 모델의 Layer 2부터 7까지 다 들여다볼 수 있게 되어 공격 탐지나 감청 등의 다양한 기능 구현에 이용되고 있다. 그렇다면 패킷만 보면 모든 통신 내용을 다 알 수 있을까? 실제로는 그렇지 않다.

네트워크에 연결되어 있는 지금 이 순간, 여러분의 모든 것이 감시당하고 있다고 생각해 보았는가? 과연 내 정보는 안전하게 전송되고 있는 것일까?  패킷만 분석하면 당신의 모든 내용을 추적할 수가 있다. 이처럼 네트워크를 감청하면 누구나 쉽게 데이터를 훔쳐볼 수 있기 때문에 암호화, 데이터 은닉 등의 방법이 등장했고 이것은 결국 네트워크 포렌식의 어려움을 가중시켰다.

데이터 은닉 방법 중 하나인 스테가노그라피(Steganography)를 살펴보자. 이것은 텍스트나 이미지, 오디오 파일 등에 또 다른 비밀스러운 내용을 숨겨놓는 기법을 뜻한다. 암호화와 반대되는 것으로, 메시지 의미는 숨기지만 메시지가 있다는 사실 자체를 숨기지는 않는다. 어렵지 않게 데이터를 은밀히 감출 수 있다. 일례로, 9.11 테러 때 오사마 빈 라덴이 특정 사이트에 메시지를 숨긴 사진을 올려 알 카에다에 지령을 전달했다고 알려져 있다. 아래에 똑같이 보이는 사진 두 장이 있다.

이 두 개의 사진은 겉으로는 같아 보인다. 하지만, 왼쪽은 정상 파일이고 오른쪽은 이미지 파일 안에 데이터가 은닉되어 있다. 패킷 관점에서 보면, 전송되는 데이터는 똑같은 일반 JPEG 형태의 이미지다. 이미지 파일 안에는 다음과 같은 데이터가 은닉되어 있는데, 분석가 입장에서는 이런 정상적인 포맷 안에 들어 있는 데이터를 추정하기가 상당히 힘들다. 이 이미지는 안랩코어 행사 때 필자가 만들어 실제 시연했던 매직아이(MagicEye)이다. 여러분도 눈을 또렷이 하고 정답을 한번 찾아보기 바란다.  

<매직아이 보는 법> 멍하게 쳐다보는 느낌 또는 눈을 약간 치켜드는 기분으로 보면 입체적으로 표현된 내용이 나타나게 된다. 정답은 ‘KARA’이다.

구조를 알면 패킷이 보인다.

패킷(packet)은 네트워크 흐름의 작은 단위이다. 지금 이 시간에도 수십 테라바이트, 아니 페타바이트 이상의 트래픽이 흘러 다니고 있다. 이 패킷을 저장한 것을 패킷 파일이라고 부르는데, 여기에는 여러 가지 형태가 있다. 그 중 대표적인 것이 PCAP 파일이다. 흔히 패킷 캡처 파일이라 하면 PCAP 형태의 파일을 이야기한다. PCAP는 Packet Capture의 약자이며 다음과 같은 구조를 가지고 있다.

파일의 첫 부분에 PCAP 파일임을 말해주는 헤더가 있고 그 후 패킷의 헤더, 이어서 해당 패킷 데이터가 있다. 패킷 헤더와 패킷 데이터가 연속적으로 반복 기록되어 있는 것이다.

 

[표 1] PCAP 파일 헤더 구조체

매직넘버는 고정된 값으로 0xa1b2c3d4이다. 숫자 4321과 알파벳 ABCD의 역순만 기억하면 되니 외우기도 쉽고, 이 값만 보아도 이것이 PCAP 파일이라고 추정할 수 있다. 버전 Major, Minor는 패킷 파일 포맷 버전을 뜻하며, thiszone, sigfigs는 시간과 관련한 것이고 snaplen은 캡처된 패킷의 길이, linktype은 데이터 링크 타입이다. 패킷 헤더 레코드는 아래와 같다.

[표 2] PCAP 레코드 헤더 구조체

좀더 쉽게 설명하기 위해 아래 예제 화면을 보자. 제일 처음에 패킷 파일 헤더인 매직넘버가 나오고, 패킷 헤더 시작 부분과 실제 패킷 데이터 시작 부분을 볼 수 있다. 패킷 헤더의 마지막 부분에는 패킷의 실제 길이 정보가 들어 있는데, 패킷 데이터 시작 바로 앞 부분 4바이트를 보면 알 수 있다. 첫 패킷의 길이는 0x00000047이고 10진수로 변환해 보면 71바이트라는 사실을 알게 된다. PCAP 파일 구조는 단순하기 때문에 위에서 언급한 구조체에 값을 맞춰보기만 하면 된다.

[그림 1] 패킷 파일의 RAW 데이터

패킷 분석 = 레고 조립?PCAP 파일 구조를 알아보았으니, 이제 패킷 데이터를 뜯어보도록 하자. [그림 2]는 패킷 분석 도구인 와이어샤크를 통해 일부 화면을 잡아본 것이다. 2003년 1월 25일 국내 인터넷 마비 사건을 가져온 문제의 패킷 데이터 일부이다. 이들은 각 헤더를 포함해 총 404바이트 길이의 작은 패킷만으로도 초당 수만 개의 패킷을 생성해 인터넷을 마비시켰다.

[그림 2] 슬래머(Slammer) 웜 패킷 일부

여기서 잠깐 OSI 7 Layer를 들여다보자. 우리가 통신하는 과정은 [그림 3]과 같은 과정을 거쳐서 이뤄지는데, 패킷 데이터 안에 바로 레이어 정보가 포함되어 있다.

[그림 3] OSI 7 Layer의 통신 관계

일반적으로 패킷 데이터 안에 들어있는 정보는 Data Link 레이어에 해당하는 이더넷 헤더 정보, Network 레이어에 해당하는 IP 정보, Transport 레이어에 해당하는 TCP 또는 UDP, 그리고 Application 레이어에 해당하는 Payload 정보로 구분해 볼 수 있다. 이런 기본 골격을 유지하고 있다는 사실을 알고 앞서 본 슬래머 웜 패킷 데이터를 살펴보면 된다. 각 헤더 정보는 이미 사전에 규약된 구조를 가지고 있으므로 그 규약에 맞게끔 각각의 정보를 끼워 맞추면 된다. [그림 4]에서 레이어별 이진 데이터 값들이 어떤 의미를 가지는지 표현해 보았다.

UDP 프로토콜은 이미 언급했고, 헤더의 순서는 제일 하단부터 시작하여 [데이터링크 헤더] [IP 헤더] [UDP 헤더] 순서로 이어진다.

[그림 4] 슬래머 웜 헤더 정보의 레이어별 분류

그림과 같이 패킷 데이터의 각 값은 헤더 구조와 딱 맞아 떨어진다. 이제 슬슬 여러분의 호기심이 뇌를 자극하기 시작할 것이다. 어려워만 보이던 패킷의 구조가 쉽게 이해되기 시작하면서 말이다. 흥미로워지기 시작한다면 여러분이 직접 패킷을 캡처해보고 패킷을 이와 같은 구조로 한번 맞춰보길 권한다. 직접 해봐야 자신의 지식이 된다는 사실을 명심하자!

[그림 5] 패킷 분석 도구에 의해 일목요연하게 정리된 헤더 정보

이와 같이 각 패킷 데이터는 사람이 일일이 살펴보고 이해하기가 쉽지 않기 때문에 와이어샤크와 같은 패킷 분석 도구가 이 일을 대신해준다. 물론, HEX 값만 보고 패킷을 이해할 수 있다면 이런 도구는 필요치 않지만 말이다.

패킷은 레고와 같다. 어릴 적 동심의 세계에 무한한 재미를 안겨주었던 레고를 보자. 각 블록이 처음에는 개개의 블록일 뿐이지만, 이것이 하나하나 결합되면 처음의 개별 블록의 모습은 사라지고 멋지게 완성된 새로운 블록으로 탄생한다. 패킷도 레고를 하듯이 맞추면, 어렵게만 보이던 각 이진 데이터 값이 하나로 완성되어 가면서 패킷이 전달하려고 하였던 원래의 의미를 파악할 수 있게 된다.

지금까지 네트워크 포렌식의 어려움과 패킷 분석을 시작하기 위한 기본에 대해 알아보았다. 다음 호에서는 실제로 패킷을 분석하는 방법과 유용하게 사용할 수 있는 몇 가지 패킷 분석 도구에 대해 소개하겠다.

<안철수연구소의 패킷 데이터 활용 사례>

수많은 패킷 데이터, 대개 분석이 끝나고 나면 사라져 버리고 만다. 하지만 분석된 데이터를 그냥 버리기는 아깝다. 축적된 데이터는 큰 자산이고 이 데이터를 분석하고 마이닝하여 유용한 데이터로 추출할 수가 있을까에 대한 고민이 계속 남는다. 따라서 안철수연구소는 ‘패킷 센터’라는 시스템에서 데이터를 활용하고 있다. 그 사례 하나를 공유해 본다.

온라인 게임 핵으로 진단되는 다수의 악성코드 샘플에서 유사한 점이 관찰되었다. 도메인 이름의 패턴이 주요 검색 포털 사이트 이름과 유사하여 패킷 센터에서 연관성이 있는 1만 2천여 건의 샘플 도메인을 확인하였다.

유명 도메인과 이름이 비슷한 도메인 이름

위 도표는 대표적인 도메인의 이름을 나열한 것으로 다음과 같은 공통 패턴을 가지고 있다.

각 도메인별로 건수를 조사해 보니 구글 70건, 야후 37건, 바이두 47건, 소후 17건, 시나 12건, 163.com 30건이었다. 하지만 도

메인, URI의 유사성만으로는 각 악성코드의 연관성을 100% 보기는 힘들다. 그러나 해당 도메인의 IP, 도메인 등록자를 확인해 보면 연관성은 더욱 깊어진다.

IP를 조사해 보니 각 도메인의 IP가 몇 개로 압축되었고, 88%가 중국에 위치한 IP였다. 패킷 센터를 통해 확인된 사항을 요약 정리하면 다음과 같다.

● 검색/포털 사이트들과 유사한 도메인 이름 사용
● 등록된 도메인 이름이 유사 패턴 사용
● 크게 5개의 IP로 압축되어 사용되고 있음
● 5개의 IP 중 88%가 중국 IP(2개)임
● 91%의 도메인 등록이 중국 도메인 등록 업체인 HICHINA에 의해 이뤄짐

주목할 만한 것이 90%가 넘는 도메인이 HICHINA라는 업체를 통해서 이루어진 것인데, 이 도메인을 유지하는 데도 많은 비용이 지출되는 것으로 추정된다.

위에서 언급한 것과 같이 패킷 센터 시스템을 통해 다양한 정보를 생성하고 이런 정보는 안철수연구소 제품의 탐지력 향상에 기여하고 있다. 분석된 각 정보는 단일 정보를 넘어, 여러 데이터와 더해지면서 그 가치는 커질 수 있다.@ 

<출처 : 안철수연구소 보안매거진 월간 '安'>

네트워크에서 흘러다니는 이미지파일 출력해주는 Driftnet

Mac 환경에서 네트워크에서 흘러다니는 이미지 파일을 보여주는 도구인 EtherPEG 가 있다.
이와 유사하게 *NIX 환경에서 사용할 수 있는 Driftnet 이 있다. Driftnet 은 네트워크 트래픽을 모니터링 하다 TCP 스트림에서 이미지 파일이 발견되면 출력해서 보여준다.

다음 URL 에서 소스를 받아다 컴파일 하거나 또는 패키지로 driftnet 을 설치하면 된다.

http://www.ex-parrot.com/~chris/driftnet/

실행하면 Driftnet 화면이 하나 나타나며, 이미지 파일을 보여준다. 다음 예제는 구글 이미지에서 packet 으로 검색해본 것이다.



-v 옵션으로 보면 콘솔 상태에서 좀더 세부적인 정보를 볼 수 있는데, 아래와 같이 탐지된 이미지 파일이 저장되는 것을 알 수 있다. 하지만, 직접 해보면 아주 결과가 좋아보이지는 않는다. 생각보다 실시간적으로 이미지 표시가 잘 안되는것 같았다.

이런 형태의 도구도 있으니 참고하기를 바란다.

[참고]

1. EtherPEG
http://www.etherpeg.org/

12월10일, 밤 하늘을 쳐다보세요. '개기월식' 전 과정 보셔야죠.

10일 밤 하늘을 쳐다보세요. 11년만에 달이 지구의 그림자에 완전히 들어가는 '개기월식' 현상을 볼 수 있습니다. 이번에 개기월식 전 과정을 볼 수 있는 것은 2007년7월 이후 처음이고 앞으로 2018년1월 31일에나 가능하다고 합니다.

저녁 8시31분 반영식을 시작으로 저녁 9시45분 부분월식이 진행됩니다.
11시31분쯤 개기월식이 최대가 되니, 꼭 놓치지 마세요.

저도 천문에 관심이 많은데, 이번 기회 놓치지 말아야 겠네요.
참고로, 국립과천과학관에서 개기월식 공개관측행사를 개회한다고 하니
관심있는 분들은 한번 방문해 보셔도 좋겠습니다. 단, 날씨가 무지 추울터이니
옷 단단히 챙겨입고 가세요.

시간	상황	시간	상황
12월 10일 오후 08시 31분	반영식의 시작	오후 11시 58분	개기식의 종료
12월 10일 오후 09시 45분	부분식의 시작	오전 01시 18분	부분식의 종료
12월 10일 오후 11시 05분	개기식의 시작	오전 02시 31분	반영식의 종료
12월 10일 오후 11시 31분	개기식의 최대

*일몰시각 - 오후 05시 14분, 월출시각 - 오후 04시 57분

그런데 일기예보에 의하면, 10일날 일부지방은 눈,비가 예상된다고 하네요 :-(

저는 쌍안경, 망원경 총 집합해서 관측예정입니다. ㅋㅋ

P.S 앞으로 가끔 쉬어가는 페이지로 우주,천문,별에 대해서도 포스팅 해 볼까 합니다.

Screen 기능을 이용해 터미널 화면 Clone 하기!

*NIX 시스템에서 유용한 도구중에 하나가 screen 이라는 것이다. 요새야 워낙 사용하는 모니터 사이즈가 커져서 활용하는 비율이 조금 떨어지긴 하나, 터미널 환경에서 아주 강력하게 사용할 수 있는 도구였다. 터미널 창에서 화면을 반으로 가르거나 여러개의 세션을 생성해서 자유롭게 이동하거나 많은 기능이 있다. 여러 기능중에서 screen 세션 하나를 그대로 Clone 하여 사용할 수 있는 방법을 공유한다.

과연 이렇게 쓰일 일이 머가 있을까 하였는데, 이 기능이 필요할 때가 바로 발표와 같은 특정 환경에서는 필요하였다. Multi Display 를 사용할 경우, 발표자의 노트북을 보면서 쉽게 시연을 보여줄 수 있다. 물론, 전체 화면을 그대로 Clone 할 수도 있지만, 터미널 환경만 보여준다면 이 방법이 유용하다.

일단 screen 를 통해 세션 생성시 세션의 이름을 지정해 준다.

세션 이름 지정은

# screen -S sessionname 으로 할 수 있다.

예로 test, test2 라는 세션 두개를 생성하였다. 그리고 -ls 옵션을 통해 현재 활성화 되어 있는 세션을 확인할 수 있다.

# screen -ls
There are screens on:
        2585.test       (12/03/2011 09:40:52 PM)        (Attached)
        2568.test2      (12/03/2011 09:38:34 PM)        (Attached)
2 Sockets in /var/run/screen/S-root.

그리고 내가 연결하고자 하는 세션이 test 라면 다음과 같이 연결할 수 있다. 새로운 터미널 창을 하나 띄우고 -x 옵션을 통해서 말이다.

# screen -r 2585.test -x

이와 같이 하면 터미널이 그대로 복제된다. 즉 내가 치는 내용이 그대로 나타난다. 그렇다면 창 하나를 모니터 다른 화면으로 넘겨서 보여줄 수가 있다.

막상 이 기능이 발표할 때 필요하였는데, 유용하게 사용하였다. Screen 의 Clone 기능, 어디다 쓸 수 있을까 하였지만 역시나 필요한 곳은 있다.

패킷파일에서 카빙기법을 통한 데이터 추출

패킷파일에서 빠르게 파일을 추출하기 위한 방법중에 하나로 포렌식 도구중에 하나인 Foremost 를 이용해 보고자 한다. 이미 Tcpxtract 와 와이어샤크를 통해서 파일을 추출하는 방법도 언급하였으나, 이 방법은 또 나름대로 필요한 경우가 있기 때문에 도움이 될 것이다. 기존에 파일 추출관련한 포스팅은 다음과 같으니 참고하길 바란다.

1) 네트워크 패킷 캡쳐 파일에서 파일 추출하기 (using Tcpxtract)

2) 와이어샤크를 이용한 패킷파일에서 바이너리 파일 추출하기

이번에 파일 추출 방법으로 사용할 것은 Foremost 라는 도구를 이용한 것이다. Foremost 는 패킷파일을 위해 만들어진 것은 아니고 파일에서 데이터를 추출하기 위한 포렌식 용도로 제작된 것이다. 콘솔기반의 프로그램으로 파일에서 헤더, 내부 데이터 구조를 기반으로 파일을 복구해 내는 것이다. 흔히 이런 방법은 데이터 카빙이라고도 불린다. Foremost 는 dd, Encase 등에 의해 만들어진 파일에서도 복구를 할 수 있으며, 우리는 이것을 패킷파일 대상으로 이용할 것이다.

우선 파일다운로드는 아래 경로에서 할 수 있으며, 리눅스 패키지를 이용한다면 foremost 로 검색하여 설치할 수 있을 것이다.

http://foremost.sourceforge.net/

-h 옵션을 주면 도움말을 볼 수 있다.

# foremost -h
foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus.
$ foremost [-v|-V|-h|-T|-Q|-q|-a|-w-d] [-t <type>] [-s <blocks>] [-k <size>]
[-b <size>] [-c <file>] [-o <dir>] [-i <file]

-V  - display copyright information and exit
-t  - specify file type.  (-t jpeg,pdf ...)
-d  - turn on indirect block detection (for UNIX file-systems)
-i  - specify input file (default is stdin)
-a  - Write all headers, perform no error detection (corrupted files)
-w  - Only write the audit file, do not write any detected files to the disk
-o  - set output directory (defaults to output)
-c  - set configuration file to use (defaults to foremost.conf)
-q  - enables quick mode. Search are performed on 512 byte boundaries.
-Q  - enables quiet mode. Suppress output messages.
-v  - verbose mode. Logs all messages to screen

사용방법은 간단하다. -i 로 입력될 파일을 지정해 주면 된다. -v 는 좀더 세부정보를 보여주고 -o 로 출력될 디렉토리 경로를 정할 수 있다. 기본은 output 이라는 폴더 아래에 추출된 파일이 저장된다. 아래 그림은

# foremost -i ex.pcap -v

 로 실행한 결과이다.

추출된 파일 정보들이 출력이 된다. output 폴더를 보면 추출된 파일이 확장자별로 해서 존재함을 확인 할 수 있다.


# ls -l output
total 20
-rw-r--r-- 1 root root 1808 2011-11-23 23:51 audit.txt
drwxr-xr-- 2 root root 4096 2011-11-23 23:51 gif
drwxr-xr-- 2 root root 4096 2011-11-23 23:51 htm
drwxr-xr-- 2 root root 4096 2011-11-23 23:51 jpg
drwxr-xr-- 2 root root 4096 2011-11-23 23:51 png
# ls -l output/jpg
total 64
-rw-r--r-- 1 root root 60610 2011-11-23 23:51 00000857.jpg
# file output/jpg/00000857.jpg
output/jpg/00000857.jpg: JPEG image data, JFIF standard 1.02



그런데 필자가 가지고 있었던 또 다른 패킷파일에서는 바로 PCAP 에서 추출해 내지 못했다. UDP 데이터 인데, 그 안에 JPG 관련 Payload 가 포함되어 있었다.  이런 경우에는 패킷파일에서 추출하기 원하는 부분에서 'Follow UDP(or TCP) Stream' 을 선택하고 그 후, 데이터를 받은 방향으로 해서 선택하고 Raw 로 저장을 하면 된다.

저장된 Raw 파일에서는 Foremost 로 추출해 낼 수 있었다. 즉, 기록되어 있는 데이터 구조에 따라서 달라지므로 기본적으로 Raw 데이터에서 추출해 내는 것이 맞다.

TCP 뿐만 아니라 UDP 에서도 원하는 데이터를 추출해 낼 수 있다. 단 조건은 어떤 파일형태의 구조를 제대로 갖추고 있어야 한다는 것이다. 무작정 임의의 페이로드에서 데이터가 뽑혀질 수 있는 것은 아니기 때문이다.

와이어샤크의 기능을 통한 추출은 제한적이므로, 분석 대상의 패킷파일에 따라 적절한 방법을 선택해 사용하면 될 것이다.

다수의 IP에 대해 Alive 유/무 쉽게 확인해 보기

패킷분석을 하다보면, 분석목적에 따라 다르겠지만 추출한 IP 주소에 대해서 추가적인 정보를 얻어야 하는 경우가 있다. WHOIS  정보가 될 수도 있고, 해당 IP 에 대한 포트 정보 또는 OS Fingerprint 를 통해 운영체제 추정등 다양한 정보를 얻기위해 시도해 볼 수 있다. 그중 대표적으로 한번쯤은 해보는 것이 해당 IP 에 대한 Alive 유무 체크일 것이다. 보통은 Ping 을 통해 확인을 한다. 그런데 한 두개의 IP 가 아니라 대량으로 테스트 해 보아야 한다면, 간단한 쉘 스크립트를 이용해서 쉽게 확인해보자.

여러 도구들이 있을텐데, 가장 기본적인 도구를 가지고 빠르게 확인하기 위해 테스트 해보았다. (필자도 필요에 의해)

일단, 아래와 같은 IP 주소를 라인별로 가지고 있다고 치자. tshark 등을 통해 IP 를 추출해 내었을 수도 있고, 어떤 방법이든지 확인해 보아야 할 IP 리스트를 라인별로 기록한 것이다.

# more ip.txt
[삭제].130.50
[삭제].10.99
[삭제].25.121
[삭제].56.99
[삭제].209.197
[삭제].85.76
[삭제].217.32
.
.

그리고 ping 에 의한 결과는 아래와 같다.

# ping [삭제].10.99
PING [삭제].10.99 ([삭제].10.99): 56 data bytes
64 bytes from [삭제].10.99: icmp_seq=0 ttl=114 time=13.271 ms
64 bytes from [삭제].10.99: icmp_seq=1 ttl=114 time=13.693 ms
64 bytes from [삭제].10.99: icmp_seq=2 ttl=114 time=13.790 ms
--- [삭제].10.99 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 13.271/13.584/13.790/0.262 ms

이렇게 Ping 에 의해 출력되는 정보를 가지고 간단하게 아래와 같이 구현해 보았다.

#./ip_chk.sh
Checking [삭제].130.50: is dead
Checking [삭제].10.99: is alive
Checking [삭제].25.121: is alive
Checking [삭제].56.99: is alive
Checking [삭제].209.197: is alive
Checking [삭제].85.76: is alive
Checking [삭제].217.32: is dead
Checking [삭제].89.169: is dead
Checking [삭제].77.102: is alive
Checking [삭제].216.69: is dead
Checking [삭제].109.240: is dead
Checking [삭제].65.226: is dead
.

해당 스크립트 내용을 살펴보면 아래와 같다.

$ more ip_chk.sh
# PacketInside.com
for host in `cat ip.txt`
do
        echo -n "Checking $host: "
        ping -q -c1 -w1 $host | grep transmitted |
        awk -F, '{if ($2 ~ /1 packets received/) print "is alive"; else print "is dead"; }'
done

ip.txt 에서 IP를 한 개씩 읽어 들이면서 $host 변수에 저장하고, ping 을 이용해 그 결과에 따라 Alive 또는 Dead 를 표시한다. ping -c1 은 한번만 카운트를 한다는 것이고, -w1 은 최대 Max Timeout 을 1초로 지정한 것이다. 즉, 1초 안에 Ping 에 대한 결과를 지정하는 것이다. 이후 출력되는 정보를 콤마(,) 로 구분하고 두번째 내용에 해당하는 1 packets received 가 패턴 매칭되면 Alive 라고 지정하는 것이다.  Ping 을 성공하였다면, 1 packets received 가 출력될 것이기 때문이다.

이상, 간단히 기본 명령어를 조합해서 다수의 IP 에 대해 Alive 유무를 체크해 보았다. 방법은 다양하게 있지만, 가급적 기본 도구를 이용하는 것이 분석 입장에서는 편할 수 있다. 분석을 수행할 컴퓨터가 바뀌더라도 어디서든 쉽게 적용해서 사용할 수 있기 때문이다.

간단하게 어떻게 하면 이용할 수 있을까 하고 고민해 보면,
쉽게 문제가 해결되기도 한다.

From Rigel

DNS가 위험하다, BIND 제로데이(0-day) 취약점 발견

11월16일 DNS 서비스에 많이 사용되는 소프트웨어 중에 하나인 BIND 에 이유없는 서비스 Crash 가 발생하였다. 다음과 같은 로그를 발생시키면서 말이다.

general: critical: query.c:1895: INSIST(! dns_rdataset_isassociated(sigrdataset)) failed, back trace
general: critical: exiting (due to assertion failure)

여러 곳에서 이런 이슈가 제기되었고, BIND 의 제로데이 취약점으로 밝혀졌다.

실제 피해 사례가 보고되면서 ISC 에서는 발빠르게 보안패치를 제공하였다. 일단, 무엇보다도
원격지에서 조작된 패킷데이터를 통해 인터넷 인프라운영에 중요한 요소인 DNS 서비스를
이렇게 무력화 시킬 수 있다는 점에서 중대한 이슈이다.

해당 취약점의 영향은 서비스거부 이며,
BIND 9.4-ESV, 9.6-ESV, 9.7.x, 9.8.x 모든 버전이 해당된다. 하지만,
현재 이 버전외에도 영향을 받고 있다는 보고가 있으나 확실히 확인되지는 않고 있다.

패치는 2가지 부분을 업데이트 하는데,
필자가 9.5 버전대를 확인해 본 결과 두군데 파일 중 한 파일은 취약한 부분을 안고 있다.
캐쉬에서 불일치된 데이터 구성을 돌려주는 부분인데, 과연 두 부분 중
한군데 이슈만으로 데몬이 Crash 되는 현상이 발생되는지는 확인되지 않았다.

중요한 것은, BIND 를 운영하는 곳에서는 필히 확인해 보아야 하며,
취약점을 안고 있다면 반드시 업데이트를 해야 한다.

패킷인사이드를 방문하는 분들중에는
이와 관련된 분들이 많을것으로 생각되어 공유한다.

좀더 자세한 내용은 아래 권고문을 참고하기 바란다.

[ASEC 권고문] BIND의 불안전한 레코드 구성에 의한 제로데이 서비스거부 공격
http://www.ahnlab.com/kr/site/securitycenter/asec/asecView.do?seq=18679

* 만약 이와 관련한 패킷 데이터 또는 피해사례가 있다면 공유를 부탁드립니다. (댓글)

윈도우에서 사용하는 기본 포트 정보

패킷을 분석하는 과정에서 다양한 포트번호를 접한다.  그 중 윈도우 시스템과 연관된 것을 볼 때 참고할 만한 포트 정보이다. 윈도우 2000 기준에서 정리된 것이지만, 일반적인 윈도우 환경에서 이용되는 포트정보를 확인하는데는 충분하다.

필요할 때 찾아보려고 하면 왜 이리 잘 안 보이는지..
그리하여 이곳에 기록을 남겨둔다.

Service Name	UDP	TCP
Browsing datagram responses of NetBIOS over TCP/IP	138
Browsing requests of NetBIOS over TCP/IP	137
Client/Server Communication		135
Common Internet File System (CIFS)	445	139, 445
Content Replication Service		560
Cybercash Administration		8001
Cybercash Coin Gateway		8002
Cybercash Credit Gateway		8000
DCOM (SCM uses udp/tcp to dynamically assign ports for DCOM)	135	135
DHCP client		67
DHCP server		68
DHCP Manager		135
DNS Administration		139
DNS client to server lookup (varies)	53	53
Exchange Server 5.0
Client Server Communication		135
Exchange Administrator		135
IMAP		143
IMAP (SSL)		993
LDAP		389
LDAP (SSL)		636
MTA - X.400 over TCP/IP		102
POP3		110
POP3 (SSL)		995
RPC		135
SMTP		25
NNTP		119
NNTP (SSL)		563
File shares name lookup	137
File shares session		139
FTP		21
FTP-data		20
HTTP		80
HTTP-Secure Sockets Layer (SSL)		443
Internet Information Services (IIS)		80
IMAP		143
IMAP (SSL)		993
IKE (For more information, see Table C.4)	500
IPSec Authentication Header (AH) (For more information, see Table C.4)
IPSec Encapsulation Security Payload (ESP) (For more information, see Table C.4)
IRC		531
ISPMOD (SBS 2nd tier DNS registration wizard)		1234
Kerberos de-multiplexer		2053
Kerberos klogin		543
Kerberos kpasswd (v5)	464	464
Kerberos krb5	88	88
Kerberos kshell		544
L2TP	1701
LDAP		389
LDAP (SSL)		636
Login Sequence	137, 138	139
Macintosh, File Services (AFP/IP)		548
Membership DPA		568
Membership MSN		569
Microsoft Chat client to server		6667
Microsoft Chat server to server		6665
Microsoft Message Queue Server	1801	1801
Microsoft Message Queue Server	3527	135, 2101
Microsoft Message Queue Server		2103, 2105
MTA - X.400 over TCP/IP		102
NetBT datagrams	138
NetBT name lookups	137
NetBT service sessions		139
NetLogon	138
NetMeeting Audio Call Control		1731
NetMeeting H.323 call setup		1720
NetMeeting H.323 streaming RTP over UDP	Dynamic
NetMeeting Internet Locator Server ILS		389
NetMeeting RTP audio stream	Dynamic
NetMeeting T.120		1503
NetMeeting User Location Service		522
NetMeeting user location service ULS		522
Network Load Balancing	2504
NNTP		119
NNTP (SSL)		563
Outlook (see for ports)
Pass Through Verification	137, 138	139
POP3		110
POP3 (SSL)		995
PPTP control		1723
PPTP data (see Table C.4)
Printer sharing name lookup	137
Printer sharing session		139
Radius accounting (Routing and Remote Access)	1646 or 1813
Radius authentication (Routing and Remote Access)	1645 or 1812
Remote Install TFTP		69
RPC client fixed port session queries		1500
RPC client using a fixed port session replication		2500
RPC session ports		Dynamic
RPC user manager, service manager, port mapper		135
SCM used by DCOM	135	135
SMTP		25
SNMP	161
SNMP Trap	162
SQL Named Pipes encryption over other protocols name lookup	137
SQL RPC encryption over other protocols name lookup	137
SQL session		139
SQL session		1433
SQL session		1024 - 5000
SQL session mapper		135
SQL TCP client name lookup	53	53
Telnet		23
Terminal Server		3389
UNIX Printing		515
WINS Manager		135
WINS NetBios over TCP/IP name service	137
WINS Proxy	137
WINS Registration		137
WINS Replication		42
X400		102

[출처] 윈도우 테크넷 라이브러리

[참고]
1. Port Assignments for Commonly-Used Services
http://technet.microsoft.com/en-us/library/cc959833.aspx