소개

네트워크는 너무나 보편적인 존재가 되어, 많은 경우에 우리는 네트워크를 이용해 네트워크 안팎의 다양한 시스템과 통신하는 것을 당연하게 여긴다. 대부분의 경우 이는 문제가 되지 않지만, 네트워크를 면밀히 관찰하면서 어떤 일이 일어나고 있는지 확인해야 할 때가 있다.

네트워크 트래픽의 내용을 더욱 면밀히 살펴봐야 할 이유는 많이 있다. 첫째는 기존 네트워크 애플리케이션이나 개발 중인 애플리케이션을 단순히 디버깅하거나 네트워크를 통과하는 트래픽을 모니터하기 위한 것이다. 둘째 이유는 대역폭과 리소스를 다 써버릴 수 있는 네트워크 상의 트래픽을 식별하기 위한 것이다. 전자의 경우, 아마 해당 프로토콜의 내용을 이미 알고 있겠지만, 예컨대 웹 서비스를 사용할 때 전송 중인 실제 데이터를 자세히 살펴보고 싶을 수도 있다. 후자의 경우, 패킷의 내용을 식별하려면 사용 중인 프로토콜에 대해 다소 광범위한 지식이 필요하다.

TCP/IP 및 UDP/IP 통신에서는 호스트 및 포트 번호 식별에 사용되는 IP 주소가 핵심 요소이다. 포트 번호는 두 호스트 사이에 복수의 연결을 지원할 수 있도록 추가 통신 채널을 제공하는 데 사용된다. 포트 식별에는 몇 가지 표준이 있다. 예를 들어, 포트 25는 이메일(SMTP) 트래픽을 위한 것이고 대부분의 웹 사이트는 포트 80(HTTP)에서 운영된다. 프로그램들은 이런 규칙을 통해 전화 번호나 팩스 번호를 선택하는 것과 같은 방식으로 알려진 채널을 통해 서로 통신할 수 있다.

이런 규칙들이 존재하지만, 어떤 포트를 사용할지에 관한 제한이나 제약은 없다. 사실, 많은 경우에서 파괴적인 네트워크 애플리케이션과 일부 보안 메소드들이 고의로 비표준 포트를 사용한다. 예를 들어, 일부는 표준 포트를 다른 프로토콜과 함께 오용하여(예: 포트 25에서 HTTP 사용) 내용을 숨긴다. 다른 예로는 표준과는 다른 포트를 사용하여 해당 트래픽에 어떤 포트가 사용되고 있는지 명백하지 않거나(예: HTTP에 포트 99 사용) 다른 프로토콜 내에서 특정 프로토콜 트래픽을 캡슐화하는 것을 들 수 있다. 이 마지막 방법은 실제로는 네트워크 터널링 및 VPN(Virtual Private Network)에서 사용하는 방법이다.

네트워크 트래픽의 복잡도나 이유를 불문하고, 데이터 기록을 시작하는 것이 항상 첫 번째 단계이다.

위로

원시 데이터 기록

원시 네트워크 데이터를 기록하려는 경우 사용 가능한 도구는 다양한 종류가 있으므로 기록한 정보를 스스로 검사할 수 있다. 네트워크 스니퍼는 대부분 특정 패킷 내용을 디코드 및 암호 해독도 하는데, 이는 인정되는 프로토콜의 내용을 연구할 때 도움이 될 것이다.

Solaris에서는 스눕(snoop) 도구를 사용할 수 있고, AIX에서는 iptrace 도구를 사용할 수 있다. 또한, 대부분의 UNIX 및 Linux 운영 체제에서 지원되는 크로스 플랫폼 tcpdump 도구를 사용할 수도 있다. 이런 도구들을 통해 내용을 캡처 및 디코드하는 작업을 모두 결합할 수 있고, 종종 시간이 오래 걸리고 분량이 많은 프로토콜 분석 프로세스를 자동으로 수행할 수도 있다. 최신 스위치에서는 이더넷 패킷이 모든 포트로 반향되지 않아, 추출할 수 있는 정보를 현재 호스트로 제한하는 일이 종종 발생한다. 다양한 최신 스위치에서는 정확히 이런 유형의 모니터링을 위해 모든 패킷의 사본을 자주 전달하는 관리 포트를 제공한다.

네트워크 전송의 디코딩 이면에 숨겨져 있는 1차적인 복잡도는 네트워크 패킷 내부에서 제공되는 정보의 레벨이다. 그 밖에도, 이런 정보 중 다수는 2진 형식으로 인코딩되어 전송되므로 네트워크를 벗어난 순수한 원시 패킷을 캡처하려면 필요한 데이터를 골라내는 데 상당한 양의 작업이 필요하다. 이런 데이터 처리 중 일부를 담당하는 도구를 사용하면 네트워크 데이터 디코딩 프로세스를 단순화할 수 있다.

예를 들면, 이더넷 네트워크에서는 일반적인 TCP/IP 프로토콜을 살펴보면 네트워크를 통해 전송되는 데이터에 포함되는 것은 다음과 같다.

• 이더넷 원본 및 대상 주소, 패킷 크기 및 이더넷 패킷 유형을 포함한 이더넷 패킷 헤더.
• IP 주소 지정(원본 및 대상), 프로토콜 ID 및 IP 플래그로 구성되는 IP 헤더. 단편화와 패킷 시퀀스에 관한 정보도 얻을 수 있다.
• 포트, 내포된 프로토콜, 플래그 및 시퀀스 번호에 대한 정보를 포함한 TCP 헤더.

이 모든 정보가 있더라도 아직도 실제 내용에는 이르지 못했다. TCP(또는 UDP) 프로토콜 아래에는 추가 프로토콜, 표준 데이터 프로토콜(HTTP, SMTP 및 FTP 포함) 또는 RPC(Remote Procedure Call) 등의 캡슐화 프로토콜과 NFS와 같은 RPC의 하위 유형이 있을 것이다.

이런 도구들은 흔히 프로토콜 및/또는 포트 번호에 따라 전송 중인 내용을 식별한다. 그래서 트래픽이 비표준 포트에서 전송되고 있는 경우에는 정보가 올바로 디코딩되지 않을 수 있다.

위로

기본적인 네트워크 분석

이 기사에서 이미 언급한 네트워크 검사 도구 중 다수에서 포트 및 내용에 대한 세부 사항을 검토하여 다양한 레벨의 프로토콜 디코딩 기능을 제공하여 사용 중인 프로토콜을 확인한다.

예를 들어, snoop 및 tcpdump 도구에서는 모두 UDP와 TCP 양쪽 모두의 서로 다른 프로토콜에 관한 자세한 정보를 다양한 레벨로 제공한다. 예컨대, snoop에서는 프로토콜의 최상위 레벨에서 전송되는 개별 데이터 블록까지, NFS의 작동에 관한 세부적인 정보를 얻을 수 있다. 예를 들어, $ snoop -v rpc nfs와 같이 NFS 프로토콜을 사용하여 RPC를 모니터하도록 지정하여 snoop으로 NFS 트래픽을 모니터할 수 있다.

이때 얻을 수 있는 출력으로 각각의 패킷에 대해 꽤 자세한 정보를 확인할 수 있으므로 더욱 면밀히 조사할 가치가 있다. Listing 1에서는 이더넷 헤더 데이터를 제공한다.

ETHER:  ----- Ether Header -----
ETHER:  
ETHER:  Packet 64 arrived at 16:14:41.79434
ETHER:  Packet size = 238 bytes
ETHER:  Destination = 0:1a:ee:1:1:c0, 
ETHER:  Source      = 0:21:28:3c:c0:61, 
ETHER:  Ethertype = 0800 (IP)
ETHER:  

여기서의 출력을 통해 이더넷 패킷이 IP 데이터를 포함하고 있고 전체 패킷 크기 및 시간, 패킷에 대한 대상 및 원본 이더넷 주소를 지정한다는 점을 알 수 있다.

Listing 2는 IP 헤더를 나타낸 것이다. 많은 IP 데이터는 프로토콜 및 원본/대상 주소 정보 이상으로 유용하지는 않다.

IP:   ----- IP Header -----
IP:   
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:         .... ..0. = not ECN capable transport
IP:         .... ...0 = no ECN congestion experienced
IP:   Total length = 224 bytes
IP:   Identification = 27460
IP:   Flags = 0x4
IP:         .1.. .... = do not fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 64 seconds/hops
IP:   Protocol = 6 (TCP)
IP:   Header checksum = 4d11
IP:   Source address = 192.168.0.112, tiger.mcslp.pri
IP:   Destination address = 192.168.0.2, bear.mcslp.pri
IP:   No options
IP:

Listing 3에서는 TCP 헤더를 볼 수 있다. 이 정보 역시 대체로 원본 포트 및 대상 포트 번호에만 유용할 뿐이다. 이런 번호로 예상 프로토콜을 식별하거나 이 포트 상의 트래픽을 더욱 면밀히 조사하기 위해 필요한 정보를 파악할 수 있기 때문이다.

TCP:  ----- TCP Header -----
TCP:  
TCP:  Source port = 2049
TCP:  Destination port = 889 (Sun RPC)
TCP:  Sequence number = 2834727685
TCP:  Acknowledgement number = 2654368001
TCP:  Data offset = 32 bytes
TCP:  Flags = 0x18
TCP:        0... .... = No ECN congestion window reduced
TCP:        .0.. .... = No ECN echo
TCP:        ..0. .... = No urgent pointer
TCP:        ...1 .... = Acknowledgement
TCP:        .... 1... = Push
TCP:        .... .0.. = No reset
TCP:        .... ..0. = No Syn
TCP:        .... ...0 = No Fin
TCP:  Window = 32806
TCP:  Checksum = 0x4852
TCP:  Urgent pointer = 0
TCP:  Options: (12 bytes)
TCP:    - No operation
TCP:    - No operation
TCP:    - TS Val = 34449495, TS Echo = 253458642
TCP:

두 번째 섹션인 Listing 4는 RPC 헤더 데이터를 나타낸 것이다.

RPC:  ----- SUN RPC Header -----
RPC:  
RPC:  Record Mark: last fragment, length = 168
RPC:  Transaction id = 3041181596
RPC:  Type = 1 (Reply)
RPC:  This is a reply to frame 63
RPC:  Status = 0 (Accepted)
RPC:  Verifier   : Flavor = 0 (None), len = 0 bytes
RPC:  Accept status = 0 (Success)
RPC:  

마지막으로, Listing 5에서는 사용 권한(파일 모드), 파일 크기, 소유권 및 기타 정보를 포함하여, NFS 패킷의 내용을 제공한다. 이 경우, 요청되는 NFS 연산은 파일 시스템 통계(ls 연산과 같은 연산에 의해 트리거됨), 즉 세부 사항의 레벨을 위한 것이다.

NFS:  ----- Sun NFS -----
NFS:  
NFS:  Proc = 18 (Get filesystem statistics)
NFS:  Status = 0 (OK)
NFS:  Post-operation attributes: 
NFS:    File type = 2 (Directory)
NFS:    Mode = 0777
NFS:     Setuid = 0, Setgid = 0, Sticky = 0
NFS:     Owner's permissions = rwx
NFS:     Group's permissions = rwx
NFS:     Other's permissions = rwx
NFS:    Link count = 24, User ID = 502, Group ID = 10
NFS:    File size = 29, Used = 2560
NFS:    Special: Major = 4294967295, Minor = 4294967295
NFS:    File system id = 781684113418, File id = 4304616
NFS:    Last access time      = 28-Feb-10 15:49:51.042953989 GMT
NFS:    Modification time     = 25-Feb-10 09:39:07.965422590 GMT
NFS:    Attribute change time = 25-Feb-10 09:39:07.965422590 GMT
NFS:  
NFS:  Total space = 759567510016 bytes
NFS:  Available space = 659048374272 bytes
NFS:  Available space - this user = 659048374272 bytes
NFS:  Total file slots = 1288161604
NFS:  Available file slots = 1287203856
NFS:  Available file slots - this user = 1287203856
NFS:  Invariant time = 0 sec
NFS: 

이 경우, 찾고 있는 파일이 사실은 디렉토리였다는 사실을 알 수 있다(파일 유형 행 참조). 파일의 실제 경로를 알 수는 없지만, Find를 사용하여 해당 디렉토리를 찾아 그에 상응하는 inode 번호를 가진 파일/경로를 찾을 수 있었다(Listing 6 참조).

$ find /scratch -xdev -inum 4304616
/scratch/installed/mysql-6.0.11

트래픽을 식별하려는 경우 이런 도구들을 사용하는 최선의 방법은 우선 도구들을 실행하여 최대한 많은 데이터를 수집한 후, 그 내용을 수동으로 검사하여 네트워크에서 나타나지 않을 것으로 판단되는 항목을 찾는 것이다.

의심되는 트래픽을 식별했으면, 명령행에 스펙을 추가하기 시작하여 트래픽의 세부 사항에 집중할 수 있다. 예를 들어, Listing 7에 표시된 것 중 하나를 이용해 지정된 호스트에만 트래픽을 표시하도록 지정할 수 있다.

$ snoop host 192.168.0.2
$ tcpdump host 192.168.0.2

조건을 더 한정하려면 $ snoop host 192.168.0.2 and port 25와 같이 프로토콜 세부 사항을 포팅하면 된다.

위로

내용 이해를 위한 원시 데이터 구문 분석

tcpdump에서 내용을 처리하는 다른 방법은 원시 네트워크 패킷 데이터를 파일에 저장한 다음 그 파일을 처리하여 원하는 정보를 찾고 디코딩하는 것이다.

tcpdump 및 snoop에 의해 캡처된 데이터를 읽고 디코딩하기 위한 기능을 제공하도록 다양한 언어로 지원되는 모듈이 많이 있다. 예를 들어, Perl 내에는 Net::SnoopLog(snoop용)와 Net::TcpDumpLog(tcpdump용)의 두 가지 모듈이 있다. 이들 모듈에서는 원시 데이터 내용을 읽는다. 이 두 모듈의 기본 인터페이스는 동일하다.

우선, snoop이나 tcpdump를 사용하여 파일에 데이터를 씀으로써 네트워크를 통과하는 패킷의 2진 레코드를 작성해야 한다. 이 예제에서는 tcpdump와 Net::TcpDumpLog 모듈을 써서 $ tcpdump -w packets.raw와 같이 활용한다.

네트워크 데이터를 축적한 후에는 네트워크 데이터 내용을 처리하기 시작하여 원하는 정보를 찾을 수 있다. Net::TcpDumpLog에서는 tcpdump에 의해 저장된 원시 네트워크 데이터를 구문 분석한다. 데이터가 원시 2진 형식으로 되어 있기 때문에, 정보를 구문 분석하려면 이 2진 데이터를 처리해야 한다. 편의상, 다른 모듈 스위트인 NetPacket::*에서 원시 데이터의 디코딩 기능을 제공한다.

예를 들어, Listing 8은 모든 패킷의 IP 주소 정보를 인쇄 출력하는 간단한 스크립트를 나타낸 것이다.

use Net::TcpDumpLog;
    
use NetPacket::Ethernet;
    
use NetPacket::IP;

    
my $log = Net::TcpDumpLog->new();
 
$log->read("packets.raw");
 
 
foreach my $index ($log->indexes)
       
{
    
    my $packet = $log->data($index);
           

    my $ethernet = NetPacket::Ethernet->decode($packet);

  
    if ($ethernet->{type} == 0x0800)
       
    {
    
        my $ip = NetPacket::IP->decode($ethernet->{data});
          

    
        printf("  %s to %s protocol %s \n",
               $ip->{src_ip},$ip->{dest_ip},$ip->{proto});
   }

} 

첫 번째 파트에서는 각 패킷을 추출한다. Net::TcpDumpLog 모듈에서는 각각의 패킷을 직렬화하여 순서대로 나열하므로, 패킷 ID를 이용해 각 패킷을 읽을 수 있다. 그러면 data() 메소드가 전체 패킷에 대한 원시 데이터를 리턴한다.

snoop에서의 출력과 마찬가지로, 원시 네트워크 패킷 정보에서 각각의 데이터 블록을 추출해야 한다. 그래서 이 예제에서는, 원시 네트워크 패킷에서 데이터 페이로드를 포함한 이더넷 패킷부터 먼저 추출해야 한다. NetPacket::Ethernet 모듈에서 이 작업을 수행한다.

우리는 IP 패킷을 찾고 있는 것이므로, 이더넷 패킷 유형을 보고 IP 패킷을 확인할 수 있다. IP 패킷은 0x0800의 ID를 갖는다.

그 다음, NetPacket::IP 모듈을 사용하여 이더넷 패킷의 데이터 페이로드에서 IP 정보를 추출할 수 있다. 이 모듈에서는 그 중에서도 특히 원본 IP, 대상 IP 및 프로토콜 정보를 제공하며, 이 정보를 인쇄할 수 있다.

이런 기본적인 프레임워크를 사용하면 tcpdump나 snoop에서 제공하는 자동 솔루션에 의존하지 않는 더 복잡한 검색과 디코딩을 수행할 수 있다. 예를 들어, 비표준 포트(즉, 포트 80이 아닌 포트)를 통과하는 HTTP 트래픽이 있다는 의심이 드는 경우 Listing 9의 스크립트를 사용하여 의심되는 호스트 IP에서 80 이외의 포트에 있는 HTTP 문자열을 찾을 수 있다.

use Net::TcpDumpLog;
    
use NetPacket::Ethernet;
    
use NetPacket::IP;
    
use NetPacket::TCP;
    

    
my $log = Net::TcpDumpLog->new();
       
$log->read("packets.raw");
       

    
foreach my $index ($log->indexes)
       
{
    
    my $packet = $log->data($index);
       

    
    my $ethernet = NetPacket::Ethernet->decode($packet);
       

    
    if ($ethernet->{type} == 0x0800)
       
    {
    
        my $ip = NetPacket::IP->decode($ethernet->{data});
          

    
        if ($ip->{src_ip} eq '192.168.0.2')
       
        {
    
            if ($ip->{proto} == 6)
       
            {
    
                my $tcp = NetPacket::TCP->decode($ip->{data});
       
                if (($tcp->{src_port} != 80) &&
               
                    ($tcp->{data} =~ m/HTTP/))
       
                {
    
                    print("Found HTTP traffic on non-port 80\n");
    
                    printf("%s (port: %d) to %s (port: %d)\n%s\n",
    
                           $ip->{src_ip},
       
                           $tcp->{src_port},
       
                           $ip->{dest_ip},
       
                           $tcp->{dest_port},
       
                           $tcp->{data});
 
                }
    
            }
    
        }
    
   }
    
}

샘플 패킷 세트에서 위 스크립트를 실행했더니 다음과 같이 Listing 10에 표시된 결과가 리턴되었다.

$ perl http-non80.pl
Found HTTP traffic on non-port 80
192.168.0.2 (port: 39280) to 168.143.162.100 (port: 80)
GET /statuses/user_timeline.json HTTP/1.1
Found HTTP traffic on non-port 80
192.168.0.2 (port: 39282) to 168.143.162.100 (port: 80)
GET /statuses/friends_timeline.json HTTP/1

이 특정한 사례에서는 호스트에서 외부 웹 사이트(트위터)로 이동하는 트래픽을 보고 있다.

이 예제에서 분명한 점은, 우리가 원시 데이터를 덤프하고 있지만 동일한 기본 구조를 사용하여 디코딩하고 공용 또는 소유 프로토콜 구조를 사용하는 모든 형식의 데이터를 사용할 수 있다는 사실이다. 이 메소드를 사용하는 프로토콜을 사용 또는 개발 중이며 해당 프로토콜 형식을 알고 있다면, 전송 중인 데이터를 추출하고 모니터할 수 있다.

위로

프로토콜 분석기 사용

이미 언급한 바와 같이, tcpdump, iptrace 및 snoop과 같은 도구는 기본적인 네트워크 분석 및 디코딩 기능을 제공하지만, 이 프로세스를 훨씬 더 쉽게 만들어주는 GUI 기반 도구가 있다. Wireshark는 방대한 규모의 네트워크 프로토콜 디코딩 및 분석을 지원하는 도구이다.

Wireshark의 주요 이점 중 하나는 tcpdump와 마찬가지로 일정 기간에 걸쳐 패킷을 캡처한 다음 다양한 프로토콜, 포트 및 기타 데이터를 바탕으로 내용을 대화식으로 분석하고 필터링할 수 있다는 점이다. 또한, Wireshark는 매우 광범위하고 다양한 프로토콜 디코더를 지원하므로, 패킷과 대화의 내용을 상세히 검사할 수 있다.

그림 1에서 나열되고 있는 모든 유형의 모든 패킷을 보여주는 Wireshark의 기본적인 스크린 샷을 볼 수 있다. 이 창은 필터링된 패킷 목록, 디코딩된 프로토콜 세부 사항, 16진수/ASCII 형식으로 된 원시 패킷 데이터의 세 가지 기본 섹션으로 나뉜다.

Wireshark 도구에서 제공되는 정보와 디코딩의 레벨에 대한 한 예로서, 필자는 본 기사를 작성하는 동안 네트워크 상의 MySQL 서버 중 하나에서 리턴되는 오류 패킷이 몇 가지 있다는 사실을 알아차렸다.

그 내용에 집중하기 위해, 우선 출력 결과에 MySQL 필터를 적용했다. tcpdump, snoop 또는 iptrace에 제공되는 것과 같은 표현식을 Filter 상자에 입력하여 이 작업을 수행할 수 있다. 또는 Expression 단추를 클릭하고 내장 목록에서 필터를 선택할 수 있다. 그림 2에서 사용 가능한 필터 샘플을 볼 수 있다. 필터를 선택한 후, Apply를 클릭하여 패킷 목록을 필터링한다.

필자는 MySQL 프로토콜에서 필터링하여 오류 패킷을 식별할 수 있었다. MySQL 프로토콜은 오류 정보와 함께 특정 패킷 유형을 리턴한다. 이 경우, 오류 1242는 하위 쿼리에 문제가 있어 쿼리 실행에 실패했다는 뜻이다. 그림 3에서 보는 것처럼, Wireshark 창의 MySQL 프로토콜 섹션을 확장하면 MySQL 프로토콜 내용의 세부 사항을 볼 수 있다.

여기서 오류의 세부 사항을 볼 수 있다. 이전의 'Request Query' 패킷을 역으로 추적하면 오류 응답을 트리거한 쿼리를 결정할 수 있다(그림 4).

필자는 패킷을 드릴다운함으로써 이전에는 알아차리지 못했던 문제를 식별하고 오류와 문제를 트리거한 쿼리를 둘 다 식별할 수 있었다.

Wireshark는 세부적인 정보를 얻을 수 있는 이처럼 다양한 필터와 프로토콜을 지원한다. 또 하나의 공통적인 용도는 웹 서비스와 같은 세부적인 프로토콜의 정확한 내용을 모니터하는 것이다. 그림 5는 상태 정보를 로그하는 데 사용되는 SOAP 요청에서 자세하고 구조화된 내용을 나타낸 것이다.

사용 중인 네트워크 프로토콜을 디버그할 때 이런 종류의 세부 사항을 매우 요긴하게 쓸 수 있다.

또 하나의 유용한 특성은 Wireshark가 라이브 정보로 작동하는 한편, 이후의 필터링 및 처리를 위해 정보를 기록할 수도 있다는 점이다. 이는 곧 Wireshark를 사용하여 의심스러운 트래픽의 특정 주기를 모니터한 다음 한가한 때에 정보를 드릴다운하여 네트워크에서 발생한 일을 정확히 파악할 수 있다는 뜻이다.

위로

요약

UNIX 네트워크 연결망을 통해 이동하는 정보에 대한 프로토콜 분석은 복잡한 프로세스일 수 있다. 하지만, 몇 가지 간단하고 널리 사용 가능한 도구를 조합하면 원본과 대상에 대한 기본적인 정보부터 특정 프로토콜과 교환 중인 데이터까지, 네트워크 트래픽에 관한 세부 사항을 디코딩하고 검사할 수 있다.

본 기사에서 보여준 바와 같이, tcpdump, snoop 또는 iptrace와 같은 도구를 사용하면 명령행에서 광범위한 데이터를 추출할 수 있다. Wireshark와 같은 도구를 사용하면 훨씬 더 깊이 파고들어 매우 다양한 프로토콜과 내용에 관해 더욱 세부적인 정보를 얻을 수 있다. 사용자 정의 프로토콜과 데이터 구조의 경우, Perl을 사용하여 원시 데이터를 추출하고 필요한 정보를 전부 얻을 수 있다.

참고자료

교육

• UNIX network analysis(Martin Brown, developerWorks, 2009년 5월): 일반적인 네트워크 구조의 이해에 관한 자세한 내용을 살펴볼 수 있다. UNIX network analysi(UNIX 네트워크 분석)를 참조한다.
  
  
• Solutions for tracing UNIX applications(Martin Brown, developerWorks, 2009년 3월): 기본적인 패킷 스누핑에 관한 배경 정보를 보려면 이 튜토리얼을 읽고, Solutions for tracking UNIX applications(UNIX 애플리케이션 추적을 위한 솔루션)를 참조한다.
  
  
• Solve application problems with tracing(Sean Wahlberg, developerWorks, 2006년 3월): truss, trace 및 유사한 도구에 관한 정보를 얻을 수 있다.
  
  
• System Administration Toolkit: Network Scanning(Martin Brown, developerWorks, 2007년 12월): 네트워크 스캐닝에 관한 팁을 확인할 수 있다.
  
  
• System Administration Toolkit: Standardizing your UNIX command-line tools(Martin Brown, developerWorks, 2006년 5월) 읽기: 여러 시스템에서 같은 명령을 사용하는 방법을 학습할 수 있다.
  
  
• bash에서 프로그램하는 방법을 배울 수 있는 시리즈 기사인 Bash by example, Part 1: Fundamental programming in the Bourne again shell(bash)(Daniel Robbins, developerWorks, 2000년 3월), Bash by example, Part 2: More bash programming fundamentals(Daniel Robbins, developerWorks, 2000년 4월) 및 Bash by example, Part 3: Exploring the ebuild system(Daniel Robbins, developerWorks, 2000년 5월)을 확인하자.
  
  
• System Administration Toolkit: 이 시리즈의 다른 파트를 확인하자.
  
  
• Making UNIX and Linux work together(Martin Brown, developerWorks, 2006년 4월): 일반적인 UNIX 배포 버전과 Linux를 함께 어울리게 만드는 방법을 알려주는 안내서이다.
  
  
• 시스템마다 다양한 도구를 사용한다. IBM Redbook인 Solaris to Linux Migration: A Guide for System Administrators에서 몇 가지 핵심 도구를 확인할 수 있다.
  
  
• AIX and UNIX 입문: AIX와 UNIX 입문 페이지에서 자세한 정보를 볼 수 있다.
  
  
• developerWorks AIX 및 UNIX 영역에는 수백 건의 유익한 기사와 초급, 중간급, 고급 사용자를 대상으로 하는 튜토리얼이 있다.
  
  
• Wireshark는 Wireshark 홈 페이지에서 다운로드할 수 있다.
  
  
• developerWorks podcasts에서 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
  
  
• developerWorks technical events and webcasts: developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  

제품 및 기술 얻기

• DVD로 제공되거나 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 차기 오픈 소스 개발 프로젝트를 구현해 보자.
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 블로그를 통해 developerWorks 커뮤니티에 참여할 수 있다.
  
  

필자소개

아티클 순위

의견

위로

목차

• 소개
• 원시 데이터 기록
• 기본적인 네트워크 분석
• 내용 이해를 위한 원시 데이터 구문 분석
• 프로토콜 분석기 사용
• 요약
• 참고자료
• 필자소개
• 의견