ESXi 4.x 패스워드 길이 조절하기

VMWare ESX 3 버전대에서 패스워드 길이를 짧게 사용하고 있었다면 4.1 에서는 난관에 부딪히게 될 것이다. 보안이 좀더 강화되어, 패스워드를 좀더 복잡하게 사용하여야 하기 때문이다.

짧은 패스워드를 입력하게 되면 아래와 같은 메시지를 보게된다.

Weak password: not enough different characters or classes for this length.

Try again.

패스워드를 안전하게 사용하는 것이 바람직 하지만, 굳이 그렇지 않게 사용되는 시스템도 있다. ESX3 버전대와 마찬가지로 간단하게 패스워드를 이용할 수는 없을까? 물론, 방법은 있다. 다음의 경로를 찾아 파일을 열어보자

/etc/pam.d/system-auth

아래와 같은 내용을 볼 수 있는데, min=8,8,8,7,6 과 같은 부분이 보일것이다. 그렇다 딱 이부분만 봐도 추측이 되지 않는가? 유닉스 시스템을 많이 접해본 사용자라면 이것이 무엇인지는 알 것이다.

#%PAM-1.0

auth       required     /lib/security/$ISA/pam_access.so

auth       required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

account    required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

session    required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6

password   sufficient   /lib/security/$ISA/pam_unix.so use_authtok nullok shadow

password   required     /lib/security/$ISA/pam_deny.so

패스워드의 최소 길이등을 지정한 것을 변경 해 주면 되는 것이다.  일단 이 파일을 수정전에 아래와 같이 +t 옵션을 추가해 주어야 한다.

# chmod +t /etc/pam.d/system-auth

# ls -l /etc/pam.d/system-auth

-r--r--r-T    1 root     root                623 Dec  2 02:25 system-auth

그리고 파일을 수정하는데, 다음과 같이 변경해 주면 된다.


password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=0,0,0,0,0

이후 패스워드를 변경해 보면, 이전과 같는 달리 좀더 짧은 패스워드를 사용할 수도 있다.

/etc/pam.d # passwd

Changing password for root

You can now choose the new password or passphrase.

A good password should be a mix of upper and lower case letters,

digits, and other characters.  You can use a 0 character long

password.

A passphrase should be of at least 3 words, 0 to 40 characters

long, and contain enough different characters.

Alternatively, if noone else can see your terminal now, you can

pick this as your password: "pengr-vaphe_ohggba".

Enter new password:

Re-type new password:

passwd: password updated successfully

ESX 의 파일명은 system-auth-generic 로 약간 다르다. 좀다 자세한 것은 아래 참고를 살펴보기 바란다.

[참고]
1. ESX and ESXi 4.x password requirements and restrictions

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012033

안드로이드 기반의 인공위성, 우주에 가나 ?

안드로이드 기반 스마트폰의 확장은 어디까지일까? 단순한 스마트폰을 넘어서
2011년에는 안드로이드가 우주에 갈 예정이라고 한다. 영국 Surrey 대학의 연구진과
SSTL(Surrey Satellite Technology Limited) 이 함께 안드로이드 기반의 위상을 저궤도에 올리기 위한 연구를 진행하고 있다고 한다. 올 년말에 발사를 준비중에 있으며, 저렴한 비용으로 위성의 기능을 구현하는 것이 이들의 목표이다. 휴대폰을 이용한 것은 이번이 처음이 아니며,
작년 NASA 연구진들이 시험적으로 몇대의 HTC 사의 넥서스 원을 3만피트상으로
보냈다. 실패한 것도 있지만 2시간30분동안 비디오를 녹화하기도 했다.


[출처: wired.com ]

이와 비슷하게 해외대학에서 작은풍선 기구에 디지털카메라와 GPS 를 장착하고
날려보내 지구의 모습을 촬영한 사례도 있었고, 국내에서도 같은 형태로 시도하여
성공하였다고 기사를 보았다. 사진으로 찍힌 모습을 단순히 보는 것과, 직접 디자인하고
날려보내서 성공하여 그 사진을 직접 본다면 감회는 남다를것 같다. 개인적으로
우주에 관심이 많다 보니 말이다 :-)

어찌되었든 SSTL 은 저비용의 작은 위성을 만들어 34번이나 발사한적도 있고, 이번
스마트폰 위성 프로젝트를 2011년이 끝나기 전에 발사하기를 기대하고 있다고 한다.

이들의 노력이 헛되지 않았으면 한다. 그리고 올 년말에는 이 소식을 다시 전할 수 있기를
기대하며...


[참고]
1. Smartphone-Powered Satellites Are Destined for Space Travel
http://www.wired.com/gadgetlab/2011/01/android-smartphone-space/
2. Surrey Satellite Technology Limited
http://www.sstl.co.uk/

와이어샤크 1.5.0 개발버전 공개

와이어샤크 1.5.0 개발 버전이 공개되었다. 1.4 에 비해 새로운 기능은 다음과 같다 :

- text2pcap 과 비슷한 텍스트 덤프파일을 Import 할 수 있음
- 패킷리스트에서 컬럼을 숨길 수 있음
- SMB 오브젝트를 익스포트 할 수 있음
- TShark 에서 iSCSI 응답 시간을 출력할 수 있음
- 캡쳐 옵션화면에서 컴파일된 BPF 코드 캡쳐 필터를 출력
- TCP 와 UDP 세션을 Ctrl+, Ctrl+. 로 뒤 앞으로 이동할 수 있음
- 패킷 길이가 기본 컬럼으로 포함됨
- DCE/RPC, SMB 와 같은 다양한 파서에서 적합한 UTF-16 문자열을 표시할 수 있음
- 그래프 화면에서 PNG 이미지로 저장할 수 있음

화면을 보면, 메뉴중에 Internals 라는 새로운 것이 보인다. Dissector tables 라는 메뉴를 클릭해 보면, Dissector 에 대해서 정보를 확인해 볼 수 있다.

이외 새롭게 지원하는 프로토콜은 아래와 같다

ADwin, ADwin-Config, Apache Etch, Aruba PAPI, Constrained Application Protocol (COAP), Digium TDMoE, Ether-S-I/O, FastCGI, Fibre Channel over InfiniBand (FCoIB), Gopher, Gigamon GMHDR, IDMP, Infiniband Socket Direct Protocol (SDP), JSON, LISP Data, MikroTik MAC-Telnet, Mongo Wire Protocol, Network Monitor 802.11 radio header, OPC UA ExtensionObjects, PPI-GEOLOCATION-GPS, ReLOAD, ReLOAD Framing, SAMETIME, SCoP, SGSAP, Tektronix Teklink, WAI authentication, Wi-Fi P2P (Wi-Fi Direct)

OpenSSH 5.7/5.7p1 릴리즈

OpenSSH 5.7/5.7p1 이 1월 24일 릴리즈 되었다. 이번 버전의 주요 기능은 RFC5656 에 정의되어 있는 ECDH(Elliptic Curve Diffie-Hellman) 와 ECDSA(Elliptic Curve Digital Signature Algorithm)
가 구현되었다. ECDH 와 ECDSA 는 대칭키와 비교해 보다 낳은 성능을 제공한다.


BSD 버전에서는 12개의 버그가 픽스 되었고, Portable 버전에서는 6개가 픽스되었다. 참고로 지난 2010년 8월 5.6 버전이 나온 후로 오랜만에 새 버전이 릴리즈 된 것이다. OpenSSH 를 사용하는 사용자들은 참고하길 바란다.

[참고]
1. RFC5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
http://tools.ietf.org/html/rfc5656
2. OpenSSH 5.7 릴리즈 노트
http://www.openssh.com/txt/release-5.7

ESXi 4.1 에서 SSH 기능 사용하기

얼마전 VMWare ESXi3 에서 SSH 접근하여 사용할 수 있는 방법에 소개했다. ESX 4 버전대에서는 이런 방식이 조금 달라졌다. ESXi 4 버전을 설치했다면, vSphere Client 를 통해 접속후
Configuration -> Security Profile -> Properties 를 보면 아래와 같은 화면을 볼 수 있다.

Remote Tech Support 를 클릭하여 시작해 주면 상태가 Running 으로 변경된다. 이외 콘솔화면에서는 Troubleshooting Mode 를 클릭하면 다음과 같은 화면을 볼 수 있고 마찬가지로 Remote Tech Support 를 Enable 해 주면 된다. (아래 화면은 현재 Enable 되어 있는 상태이다)

SSH 로 접근은 필요에 따라 유용하게 사용될 수 있을 것이다.

[참고]
1. Using Tech Support Mode in ESXi 4.1
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1017910

2. VMWare ESX3i 에서 SSH 로 접근하여 사용하기!
http://www.packetinside.com/2011/01/vmware-esx3i-ssh.html

Payload 에서 내가 원하는 문자열을 찾기 위한 캡쳐필터를 자동생성 사용해 보자!

와이어샤크에서 사용가능한 필터는 유용하게 사용되지만, 필터의 문법을 모르면
말짱 꽝이다. 하지만, 와이어샤크 홈페이지에 캡쳐 필터를 자동으로 만들어주는 온라인 도구가 있다. 모든 문법을 만들어 주는 것은 아니고, 문자열을 매칭해 주는 필터를 만들어주는 것이다.

제공하는 필터는 패킷캡쳐를 할때 Payload 에서 사용자가 지정한 문자열을 발견할 시
와이어샤크에서 보여주게 되는 것이다. 단순히 IP 주소나, 포트등은 필터 문법을 어렵지 않게 사용할 수 있지만, Payload 영역은 조금 복잡하다. 일단 다음의 주소로 방문해 보자!

http://www.wireshark.org/tools/string-cf.html

일단 접속해 보면 아래와 같은 화면을 볼 수 있는데, 1) 에 찾고자 하는 문자열을 입력하고
2) 에는 Payload 에서 찾을 위치 offset 시작 주소를 넣는다. 그러면 3) 에 필터가 만들어진다.

이렇게 만들어진 필터를 와이어샤크에서 시작할때 Capture Filter 에 넣어주면 해당 문자열을 탐지하였을때 정보가 나타나게 된다. 주의할 점은 이 필터는 출력필터가 아니라 캡쳐를 시작할 시에 넣어주는 캡쳐필터라는 점을 잊지말자!

만들어진 캡쳐필터로 한번 테스트를 해보자. attack 이라는 문자열을 입력하였는데, 브라우저에서 packetinside.com/attack 으로 시도를 해 보면 탐지가 될것인가 ? 안될것인가 ?  

정답은 탐지가 안된다. attack  이라는 문자열을 포함하고 있지만 말이다. 이것은 위에서 필터를 만들때 offset 을 0 부터 했기 때문이다. packetinside.com/attack 으로 접속하면서 패킷 덤프를 해보면 아래와 같다.

위 정보를 보면 무엇이 잘못되었는지 파악이 될 것이다. 즉, Payload 에 들어가는 내용은 GET /attack 으로 offset 0 에는 G 부터 시작하기 때문이다.  와이어샤크의 출력필터중 contains 같은 것은 attack 이 포함된 것을 매칭할때 유용하지만 여기서 만든 필터는 Payload 의 위치를 지정해서 각 HEX 값을 지정한 것이므로 단순한 매칭으로 보면 안된다. 지정한 Offset 주소부터의 문자열 매칭이 된다는 것을 잊지말자!

자 그럼, 다시 제대로 만들기 위해서는 Offset 을 5 로 지정하면 된다. Offset 에 5를 입력하고 만들어지는 패턴을 보면 아래와 같다 : 

tcp[((tcp[12:1] & 0xf0) >> 2) + 5:4] = 0x61747461 && tcp[((tcp[12:1] & 0xf0) >> 2) + 9:2] = 0x636b

이제 이 패턴을 캡쳐필터로 사용하면 탐지가 되는 것을 확인할 수 있을 것이다.

[참고]
위에서 만들어진 필터를 보면 복잡해 보인다. tcp[12:1] 과 같이 말이다. 이에 대한 의미는 다음 포스팅 글을 참고하기 바란다.

TCP/IP 헤더 내 맘대로...tcp[13] == 2 의 의미는 무엇일까?

데비안 6.0 Squeeze 2월 첫째주 경 공식 릴리즈 예정

 

좋아하는 리눅스 배포판 중에 하나인 데비안 6.0 릴리즈가  코 앞으로 다가온거 같습니다.
현재 6.0 RC1 이 나왔는데, 이번주말 중에 RC2 가 나올 예정이며 큰 문제가 발생되지 않는 한 2월 첫째주 정도에 공식 발표될 것이라고 합니다. 데비안 6.0 은 Squeeze 이름을 갖고 있습니다.

2010년 11월 27일 5.0 의 7번째 업데이트가 나온 이후로, 드디어 6.0 이 나옵니다.
이번 데비안 6.0 은 완벽한 프리 커널을 지향하고 있습니다. 커널 상에 non-free 코드는
다 제거되어 진짜 프리로서 태어나는 것이죠.

6.0 RC1 을 다운받으려고 하는데, 무진장 느리네요.
어여 정식 릴리즈 되어서, 미러링 되었으면 좋겠습니다. 새로 설치할 리눅스들은
Squeeze 로 설치하게 말이죠!

[참고]
1. Debian 6.0 Squeeze to be released with completely free Linux Kernel
http://www.debian.org/News/2010/20101215
2. 데비안 사이트
http://www.debian.org

압축 프로그램 알집 취약점 공개돼,주의 필요!

국내에서 대표적으로 많이 이용되는 압축프로그램인 알집에 대한 취약점이 공개되었더군요.
버퍼오버플로우 취약점으로, 조작된 헤더파일을 갖고 있는 압축파일을 알집을 통해
오픈하면 악의적코드가 실행될 수 있습니다. 일단, 주의가 필요할 것 같아 글 남깁니다.

공격코드 작성자는 브라질사람이 아닌가 합니다. 공격코드의 주석등을 추정해 봤을때~
비디오 동영상도 올려놨던데, 참고하세요.



테스트한 버전은 8.12.0.3 이라고 합니다.

복잡한 리눅스 커널, 맵을 통해 한눈에 들여다 보자!

복잡하기만 한 리눅스 커널을 이쁘게 만들어진 맵을 통해 들여다 보자.  아래 이미지의
커널 맵은 시스템, 프로세싱, 메모리, 네트워크 킹과 같은 큰 분류로 나뉘어져 그 밑에
관련된 내용을 포함하고 있다.

마우스를 해당 부분에 가져다 놓으면 관련된 정보가 나타나며, 클릭하게 되면 커널의 소스 및 기타 추가정보를 얻을 수 있다. 이외 우측의 네비게이션을 통해축소, 확대, 이동등을 할 수 있다. 커널 전체를 한번 들여다 보고자 하는 이들에겐 도움이 될것 같다.

접속은 다음 URL 을 방문하면 되고, 다 로드되기까지는 약간의 시간이 걸린다.

http://www.makelinux.net/kernel_map

비행기 LCD 스크린에서 본 부팅화면, 리눅스네?

휴대폰의 사진파일을 들춰보다 기억나게 된, 비행기 안의 LCD 스크린 화면. 장거리 여행이라면 비행기의 LCD 스크린은 지루함을 달래주는데 최고의 역할을 담당한다.

비행기 출발 후, 화면을 동작시켜 보는데, 먹통이 되어 전혀 동작하지 않는다. 기내에서의 한마디 문제가 있어 잠시 시스템을 재시작 한다는 것이다. 스크린에 비친 모습은 컴퓨터 부팅과 같은 CMOS 확인 하는 모습. MBR 체크하는 것도 보이고, 스트링 중에 하나인 Red Hat 이 눈에 띈다. 리눅스 운영체인 것인가? 

그리고 이어지는 파일서버 접근 시도. 그러나 파일서버 접근에 실패한다. 두번의 재 부팅 후에 정상적으로 접속이 이뤄졌다.

부팅되는 상황과 구성을 보면 리눅스 운영체제에 파일서버에 영화파일과 같은 Content 들이 들어 있는 것으로 볼 수 있다.  인터넷에서 다른 사례를 찾아 보았더니, 리눅스로 재부팅 되는 상황을 촬영해 놓은 것도 있다. 

이 각 화면들이 연결되기 위해서는 각 단말기 들이 연결되는 네트워크 연결 단자가 있을 것이다. 어떤 곳에서는 랜케이블 연결을 보았다는 이야기를 들었다. 만약 이런 가정이 가능해 진다면,  비행기 내부에서 운영되는 네트워크에 연결이 가능할 수도 있다는 것이다. 그 연결 범위와 접근이 어디까지인지는 확인되지 않았지만, 상당히 재미있는 시나리오도 가능해진다. :-)

이런 IT 기기들만 보면, 왜 이런생각들부터 드는지 원.. 직업병인가~

VMWare ESX3i 에서 SSH 로 접근하여 사용하기!

VMWare ESXi 는 무료로 사용가능한 가상화 솔루션이다. VMWare Workstation 과 달리 안정적으로 대량의 가상 머신을 운영하기에는 적절한 방법이다. 리눅스 커널을 기반으로 만들어진 것이며, 최근버전은 ESXi 4.1 버전이다. 3i 버전도 필요에 따라 유용하며, 이에 ESXi 3 버전에 대한 루트 접근 방법을 소개한다.

이미 ESXi 를 사용하는 사용자라면 루트권한을 획득하기 위한 방법을 많이 알고 있을 것이다.
가상화를 이용한 프로젝트도 진행하고 있으며, 개인적으로 관심도 많기 때문에 앞으로 패킷인사이드에서는 가상화에 대한 부분도 다뤄볼까 한다.

ESXi 는 원격에서 클라이언트 프로그램을 통해 접속을 하게 되며, 직접적으로 쉘로 접근하는 방법은 제공하지 않는다. 하지만, 접근할 수 있는 방법이 있으므로 이를 이용하면 여러분들이 원하는 형태로 제법 운영 가능하다.

루트로 접근하기 위해서는 다음과 같은 방법을 사용한다.

1. 구동된 화면 ESXi 콘솔 에서 (회색과 노란색 화면) ALT + F1 을 누른다.
2. 여기서 unsupported 라고 입력한다. 이때 타이핑 하는 것은 나타나지 않는다.
3. 올바르게 입력하면 다음과 같은 접속 화면을 볼 수 있다.

4. SSH 를 enable 하기 위해 /etc/inetd.conf 를 수정해야 한다.

vi /etc/inetd.conf

5. ssh 를 서치해 보면 ssh 가 # 으로 주석처리 되어 있다. 이 주석을 제거해 주면 된다.

#ssh   stream   tcp   nowait   root   /sbin/dropbearmulti   dropbear

6. 저장하고 빠져 나간다음 서비스를 재 시작해 준다. SSH 가 enable 되었으므로, 원격지에서

VMWare ESXi 가 설치된 IP 로 접속을 시도하면 된다. ( ssh root@esxi ip )

/sbin/services.sh restart

* 업데이트 버전에 따라서 달라질 수 있는데, 만약 접속이 제대로 이루어 지지 않는다면

ps | grep inetd 

로 inetd 프로세스를 찾아 kill -HUP 로 inetd 를 재 구동해준다.

7. ALT + F2 를 누르면 다시 원래의 GUI 화면으로 이동한다.

자! 이제 쉘로 접근하여 원하는 형태대로 동작시켜보면 된다. 커맨드로 제어할 수 있는 명령어 등이 있으므로, 필요에 따라 적절하게 사용하면 된다. 

tshark 파일 사이즈가 이렇게 컸었나?

와이어 샤크를 자주 사용했는데, 문득 사이즈는 얼마나 되었는지 깊게 보지 않았던것 같다.
리눅스 환경에서 자주 사용하던 tshark 용량을 살펴보니, 작은 크기가 아니었다.

정적으로 컴파일된 tshark 의 경우는 무려 49메나 되었다.
# ls -lh tshark

-rwxr-xr-x 1 root root 49M 2010-12-16 10:48 tshark

반면 Shared 로 컴파일한 tshark 는 겨우 300K 이었다. 물론, 공유 라이브러리 이기 때문에 이 내면을 들여다 보면, 큰 라이브러리들을 로드한다.

# ls -l tshark

-rwxr-xr-x 1 root root 301978 2010-12-16 11:22 tshark

ldd 로 사용되는 라이브러리 들을 살펴보자.

# ldd tshark

        linux-vdso.so.1 =>  (0x00007fffaf5ff000)

        libwiretap.so.0 => /home/wireshark-1.4.2/lib/libwiretap.so.0 (0x00007f43ac07a000)

        libwireshark.so.0 => /home/wireshark-1.4.2/lib/libwireshark.so.0 (0x00007f43a88c7000)

        libwsutil.so.0 => /home/wireshark-1.4.2/lib/libwsutil.so.0 (0x00007f43a86c5000)

        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f43a8402000)

        libm.so.6 => /lib/libm.so.6 (0x00007f43a817f000)

        libpcap.so.1 => /usr/local/lib/libpcap.so.1 (0x00007f43a7f47000)

        libz.so.1 => /usr/lib/libz.so.1 (0x00007f43a7d30000)

        libc.so.6 => /lib/libc.so.6 (0x00007f43a79dd000)

        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f43a77da000)

        libdl.so.2 => /lib/libdl.so.2 (0x00007f43a75d6000)

        libpcre.so.3 => /usr/lib/libpcre.so.3 (0x00007f43a73ae000)

        /lib64/ld-linux-x86-64.so.2 (0x00007f43ac2e2000)

이중 libwireshark.so 를 들여다 보니, 그 크기는 무려 60메가다.

-rwxr-xr-x 1 root root  60M 2010-12-16 11:22 ../lib/libwireshark.so.0.0.1

이렇게 사이즈가 컸었나 하는 생각이 문득 든다. 참고로, 정적 방식과 Shared 방식으로 컴파일 시간을 비교해 보았더니 정적 컴파일은 8분 Shared 방식에는 4분이 소요되었다.

1) 정적컴파일
real    8m44.375s
user    7m28.108s
sys     1m5.848s
2) Shared 방식 컴파일
real    4m52.040s
user    4m12.156s
sys     0m40.743s

컴파일도 오래 걸리고, 그 크기도 크지만 그래도 네트워크 분석에는 최고의 도구임은 틀림없다.   :-)

패킷파일의 민감한 정보를 지우고 전달하고자 하는 경우에는 이 방법을!

패킷파일을 전달하여야 하는데, 사내 IP 정보들이 알려지기는 싫고 할때 어떤 방법을 써야 할까? 패킷인사이드를 꾸준히 방문한 분들이라면 앞서 몇번 언급했던 패킷조작 프로그램을 이용해 IP 등을 변경할 수 있다. 또는 지금 필자가 소개하고자 하는 tcpdpriv 를 이용하면 간단히 해결된다. tcpdpriv 는 프로그램 이름에서도 살짝 느껴지는 것과 같이 패킷파일에서 private 한 정보를 제거해 주는 기능을 갖고 있다.

프로그램 정보 및 다운로드는 다음의 경로를 방문하면 된다 :

http://fly.isti.cnr.it/software/tcpdpriv/

다운 받은 파일은 컴파일 과정을 거쳐야 한다. 제작 된지 오래된 소스이기도 해서 첫 버전은 FreeBSD 와 같이 몇몇 시스템에서만 테스트 되었고 configure 옵션도 csh 로 지정되어 있었다.
지금 버전은 그래도 리눅스에서도 컴파일이 가능하다.

# ./configure
cat: VERSION: No such file or directory

./configure 를 통해 Makefile 이 만들어 지면 make 를 수행하자

debian:~/# make
gcc -g -Wall     -c -o tcpdpriv.o tcpdpriv.c
tcpdpriv.c: In function ‘verify_and_print_args’:
tcpdpriv.c:1504: error: invalid storage class for function ‘usage’
tcpdpriv.c:1570: warning: implicit declaration of function ‘usage’
tcpdpriv.c: At top level:
tcpdpriv.c:1749: warning: conflicting types for ‘usage’
tcpdpriv.c:1749: error: static declaration of ‘usage’ follows non-static declaration
tcpdpriv.c:1570: error: previous implicit declaration of ‘usage’ was here
make: *** [tcpdpriv.o] Error 1

그런데 컴파일 하는 과정에서 에러가 발생한다. 이 에러는 다음과 같이 수정하면 된다

# vi tcpdpriv.c

tcpdpriv 소스파일을 오픈하고 두군데를 수정하면 된다.

1) 1504 라인에서  static void usage(char *cmd); => 를 void usage 로 변경
2) 1749 라인에서 static 을 삭제

그리고 다시 컴파일을 하면 된다.

# make
gcc -g -Wall     -c -o tcpdpriv.o tcpdpriv.c
tcpdpriv.c:33: warning: ‘rcsid’ defined but not used
gcc -g -Wall     -c -o tcpdutil.o tcpdutil.c
tcpdutil.c:24: warning: ‘rcsid’ defined but not used
gcc -g -Wall   -o tcpdpriv  tcpdpriv.o tcpdutil.o  -lpcap

컴파일이 완료되면 다음과 실행하여 옵션들을 살펴볼 수 있다.

# ./tcpdpriv
attempt to write binary dump file to tty
usage:
./tcpdpriv [-Opq] [-a [[hh:]mm:]ss] [-A {0|1|2|50|99}] [-c count]
[-C {0|1|2|3|4|...|32|99}] [-F file] [-i interface]
[-M {0|10|20|70|80|90|99}] [-{P|T|U} {0|1|99}] [-r file]
[-s snaplen] [-w outputfile] [expression]
(one reasonable choice:  ./tcpdpriv -P99 -C4 -M20 ...)

간단하게 옵션 몇개를 살펴보자.

-A : IP 주소를 어떤식으로 표현할지를 결정한다. 레벨이 99인 경우 IP 주소는 변하지 않는다.
-c : 지정한 패킷 카운트 후에 종료한다.
-F : 사용할 필터를 지정
-i : 네트워크 인터페이스
-p : TCP, UDP 포트주소를 매핑한다.
-r : 읽어들일 패킷 파일을 지정
-w : 출력할 파일을 지정

위 옵션들을 보면 각 옵션마다 특정 값을 지정하는 것이 있어, 얼핏보면 복잡해 보인다.
간단하게 생각하면 0은 가장 안전한 옵션이라 생각하면 된다. 즉, 가급적 Private 한 정보는
제거하게 되고 , 99 는 많은 정보를 보여주는 것이라 볼 수 있다. 이런 개념으로 옵션에 사용되는 값을 이해하면 될것 같다.

직접 사용해 보는 것이 이해가 가능 빠르므로 한번 예를 살펴보자. 다음은 정상적인 일반 패킷 파일을 tcpdump 로 본 것이다.

11:11:33.480941 IP6 fe80::f95c:91a7:8bd8:6216.49403 > ff02::c.1900: UDP, length 146
11:11:34.532638 arp who-has 192.168.0.200 tell 192.168.0.240
11:11:34.534733 arp reply 192.168.0.200 is-at 00:01:36:2e:0b:a7 (oui Unknown)
11:11:34.534756 IP 192.168.0.240.48603 > kns.kornet.net.domain: 34133+ AAAA? www
.google.co.kr. (34)
11:11:34.545974 IP kns.kornet.net.domain > 192.168.0.240.48603: 34133 2/1/0 CNAM
E[|domain]
11:11:34.546180 IP 192.168.0.240.60837 > kns.kornet.net.domain: 30670+ A? www.go
ogle.co.kr. (34)
11:11:34.554454 IP kns.kornet.net.domain > 192.168.0.240.60837: 30670 8/4/4 CNAM
E[|domain]
11:11:34.555094 IP 192.168.0.240.45918 > pv-in-f99.1e100.net.www: S 2001641216:2
001641216(0) win 5840 <mss 1460,sackOK,timestamp 1127508 0,nop,wscale 4>

특별한 옵션을 사용하지 않고 -r 옵션을 통해 읽어들일 파일과 새로 저장할 파일을 지정하였다. 기본 옵션은 최대한 정보를 제거하는 것으로 설정되어 있다. (즉, 0 이다)

# ./tcpdpriv -w test2.pcap -r test.pcap
# map 32-bit addresses into sequential integers
# multicast addresses cloaked per -A and -C flags
# map 16-bit TCP port numbers into sequential integer
# map 16-bit UDP port numbers into sequential integer
# pktsin 138 pktsout 134 tooshort 0 uncoded 4

새롭게 저장된 test2.pcap 파일을 열어보면 IP 주소가 변경된걸 알 수 있다. 처음에 보였던 IPv6 와 ARP 정보도 보이지 않는다. 또한, 헤더 정보에 nop 이 많이 보여진다.

# tcpdump -r test2.pcap
11:11:34.534756 IP 1.0.0.1.1 > 1.0.0.2.2: UDP, length 34
11:11:34.545974 IP 1.0.0.2.2 > 1.0.0.1.1: UDP, length 132
11:11:34.546180 IP 1.0.0.1.3 > 1.0.0.2.2: UDP, length 34
11:11:34.554454 IP 1.0.0.2.2 > 1.0.0.1.3: UDP, length 314
11:11:34.555094 IP 1.0.0.1.tcpmux > 1.0.0.3.2: S 2001641216:2001641216(0) win 5840 <nop,no
p,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop>
11:11:34.685957 IP 1.0.0.3.2 > 1.0.0.1.tcpmux: S 959091973:959091973(0) ack 2001641217 win
 5672 <nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop>
11:11:34.686035 IP 1.0.0.1.tcpmux > 1.0.0.3.2: . ack 1 win 365 <nop,nop,nop,nop,nop,nop,no
p,nop,nop,nop,nop,nop>
11:11:34.686326 IP 1.0.0.1.tcpmux > 1.0.0.3.2: P 1:614(613) ack 1 win 365 <nop,nop,nop,nop
,nop,nop,nop,nop,nop,nop,nop,nop>
11:11:34.816891 IP 1.0.0.3.2 > 1.0.0.1.tcpmux: . ack 614 win 108 <nop,nop,nop,nop,nop,nop,
nop,nop,nop,nop,nop,nop>
11:11:34.833127 IP 1.0.0.3.2 > 1.0.0.1.tcpmux: . 1:1419(1418) ack 614 win 108 <nop,nop,nop
,nop,nop,nop,nop,nop,nop,nop,nop,nop>
11:11:34.833160 IP 1.0.0.1.tcpmux > 1.0.0.3.2: . ack 1419 win 546 <nop,nop,nop,nop,nop,nop
,nop,nop,nop,nop,nop,nop>

그럼 다른 옵션을 한번 사용해 보자. IP 주소의 변화를 좀 주고, -P 를 통해 포트번호가 바뀌지 않도록 99 를 주었다.

# ./tcpdpriv -A 50 -P 99 -w test2.pcap -r test.pcap
# tcpdump -r test2.pcap | more
11:11:34.534756 IP 16.76.127.170.48603 > 92.36.179.36.domain: [|domain]
11:11:34.545974 IP 92.36.179.36.domain > 16.76.127.170.48603: [|domain]
11:11:34.546180 IP 16.76.127.170.60837 > 92.36.179.36.domain: [|domain]
11:11:34.554454 IP 92.36.179.36.domain > 16.76.127.170.60837: [|domain]
11:11:34.555094 IP 16.76.127.170.45918 > 136.110.214.97.www: S 2001641216:2001641216(0) wi
n 5840 <nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop>
11:11:34.685957 IP 136.110.214.97.www > 16.76.127.170.45918: S 959091973:959091973(0) ack
2001641217 win 5672 <nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,n
op,nop,nop>
11:11:34.686035 IP 16.76.127.170.45918 > 136.110.214.97.www: . ack 1 win 365 <nop,nop,nop,
nop,nop,nop,nop,nop,nop,nop,nop,nop>
11:11:34.686326 IP 16.76.127.170.45918 > 136.110.214.97.www: P 1:614(613) ack 1 win 365 <n
op,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop>
11:11:34.816891 IP 136.110.214.97.www > 16.76.127.170.45918: . ack 614 win 108 <nop,nop,no
p,nop,nop,nop,nop,nop,nop,nop,nop,nop>

그러면, 위와 같이 IP 는 좀더 랜덤하게 변했지만, 포트번호는 그대로 유지하고 있다. 포트번호는 유지하면서 IP 주소만 변경하여 패킷파일을 전달하는 경우 사용될 수 있다.

tcpdpriv 는 간단하게도 사용할 수 있는 만큼, 패킷파일 에서 민감한 내용을 제거할 때 유용하게 사용할 수 있을것이다.

패킷정보를 요약하여 통신내용을 한눈에 살펴보자!

패킷파일 안의 내용이 간단하면 분석가가 직접 눈으로 살피는 것 만으로도 어느정도 파악이 쉽게 된다. 그런데, 패킷파일이 수십메가 이상이 되어버리면 분석은 쉽지 않아진다. 더군다나, 아주 다양한 내용으로 까지 구성되어 있다면 더욱 힘들다.

그렇기 때문에 패킷분석기의 도움을 받는 것이다. 하지만, 때로는 간단히 대략 살펴보고 싶기도 하다. 이럴때 유용하게 사용할 수 있는 것이 있다. 패킷파일안에서의 통신과정을 대략 요약하여 정리해 보여주는 'nstreams' 라는 것이 있다. tcpdump 형태를 분석해 줄 수 있는 도구로 보면 된다. 일단, 다운로드는 다음의 경로에서 할 수 있다.

http://www.hsc.fr/ressources/outils/nstreams/

다운받은 후 컴파일은 아래와 같은 순서로 진행하면 된다.

# tar -zxvf nstream-1.0.0.tar.gz
# cd nstreams
# ./configure
# make
# make install

이외 APT 패키지 사용자는
# apt-get install nstreams 로 간단히 설치할 수 있다.

관련파일이 2가지가 있는데, 없어도 사용하는데는 문제없다. 다만, 본인의 네트워크를 정의하거나 또는 사용 서비스를 정의해 놓으면 출력 내용을 볼 때 편리한 점은 있다.

1) 서비스 정의
nstreams-services 라는 파일이 있다. 여기에 프로토콜의 이름 같은 것을 정의할 수 있는데 형태는 아래와 같다 :

 protocol_name:server_port(s)/{udp,tcp}:client_ports(s)
 또는
 protocol_name:type(s)/icmp:code(s)

제일 앞에 프로토콜의 이름이 온다. 그리고 서버의 포트 그리고 클라이언트 포트 정보가 오는데 대략 봐도 어떤 형태의 구성인지 쉽게 이해가 될 것이다.

# vi /etc/nstreams-services
telnet:23/tcp:any
bsd-passive-ftp:49152-65535/tcp:1024-65535
icmp-echo-request:8/icmp:0
bootps:67/udp:68

2) 네트워크 정보
네트워크의 영역을 정의해 놓을 수 있다.
internal-network:192.168.1.0/24
test-network:212.198.0.0/16
internet:0.0.0.0/0

정의해 놓으면 화면 출력시 좀더 이해하기 쉬워지는데, 이것은 아래 출력 예제를 보는
것으로 쉽게 이해가 될 것이다.

# nstreams -f test.pcap
dns traffic between 192.168.0.240 and 168.126.63.1
http traffic between 192.168.0.240 and 72.14.213.99
http traffic between 192.168.0.240 and 74.125.127.102
http traffic between 192.168.0.240 and 72.14.213.103
http traffic between 192.168.0.240 and 72.14.213.100

아래서는 해당 네트워크 대역이 정의해 놓은 것으로 치환되어 나타난다.

# nstreams -n /etc/nstreams/nstreams-networks -f test.pcap
dns traffic between private-network and internet
http traffic between private-network and internet

또 파일 외에 -l 로 인터페이스를 지정하면 실시간으로 볼 수도 있다. 

# nstreams -l eth1 

http traffic between private-network and internet
http traffic between 192.168.15.11 and 219.94.214.228
http traffic between 192.168.15.11 and 74.125.53.132
http traffic between 192.168.15.11 and 210.171.226.45
icmp-unreach traffic between 192.168.15.11 and 168.126.63.1
http traffic between 192.168.15.11 and 74.125.127.113
http traffic between 192.168.15.11 and 128.31.0.36
http traffic between 192.168.15.11 and 35.9.37.225
telnet traffic between 192.168.15.11 and 74.125.127.105
icmp-unreach traffic between 192.168.15.11 and 168.126.63.2
http traffic between 192.168.15.11 and 86.59.118.153
http traffic between 192.168.15.10 and 72.14.213.191


출력되는 형태가 간단하여 분석할 패킷파일의 용량이 큰 경우에는 대략적인 형태를
파악하는데 도움이 될 것이다. 또 오픈소스 이므로, 본인이 원하는 형태로도 수정하여
사용가능하다. 예를 들어, 출력되는 부분을 약간 바꿔보고자 한다.

그럼, output.c 소스파일을 열어 살펴보자. 목적지 포트가 1024 인 경우에 조금
다르게 출력해 본다면, printf 로 출력되는 부분을 살짝 변경해 더 쉽게 볼 수 있게 한다든지
원하는 형태로 할 수 있다.

void

standard_output(output, status)

 struct output * output;

 int status;

{

 if(status)return;

 if(!strcmp(output->serv_name, "unknown"))

 {

  if(!opt_u)

  {

    if(output->dport > 1024) {

  printf("[* Suspicious > 1024] Unknown %s traffic between %s:%d and %s:%d  \n",

    output->asc_proto,

        output->src, output->sport,

    output->dst, output->dport);

    } else {

  printf("Unknown %s traffic between %s:%d and %s:%d\n",

    output->asc_proto,

        output->src, output->sport,

    output->dst, output->dport);

    }

  }

 }

오픈소스이기 때문에 내 상황에 맞게 적절히 수정하여 사용한다면 내 입맛에 맞는
최고의 분석도구가 될 것이다.  이게 바로 오픈소스의 맛 아닐까?

2011, 신묘년 새해 복 많이 받으세요.

어느덧 한해가 끝나고 2011년 1월 1일이 되었네요.
패킷인사이드도 1년이 되었는데, 언제 1년이 지났나 싶을 정도로 빨리 지나간것 같습니다.
2010년에 작성된 글을 보니 164 개나 되더군요.
언제 이 만큼이나 글을 작성할까 했었는데, 제가 생각했던 것 보다는 많이 쓴것 같네요.

앞으로도 패킷인사이드 많이 방문해 주시고,
좋은 의견도 남겨주세요.

패킷인사이드 방문하시는 모든 여러분, 2011년 새해 복 많이 받으시고 항상 행복하세요.