두 프로그램이 네트워크를 통해 서로 통신을 수행 할 수 있도록 양쪽에 생성되는 링크의 단자이다. 두 소켓이 연결되면 서로 다른 프로세스끼리 데이터를 전달 할 수 있다. 결국 소켓이 구현됨으로써 네트워크 및 전송 계층의 캡슐화가 가능해 진다.
소켓은 원래 캘리포니아 버클리 대학 분교에서 UNIX용으로 개발 되었으며 UNIX에서의 입출력 메소드의 표준인 개방/읽기/쓰기/닫기 메커니즘을 따른다.
소켓형식
1. 스트림
스트림 소켓은 양방향으로 바이트 스트림을 전송 할 수 있는 연결 지향형 소켓으로 양쪽 어플리케이션이 모두 데이터를 주고 받을 수 있다는것을 의미한다. 스트림소켓은 오류수정,전송처리,흐름제어등을 보장해 주며 송신된 순서에 따른 중복되지 않은 데이터를 수신하게 된다. 이 소켓은 각 메세지를 보내기 위해 별도의 연결을 맺는 행위를 하므로 약간의 오버헤드가 존재한다. 그러므로 소량의 데이터보다는 대량의 데이터를 보내는 경우에 적당하다. 스트림소켓은 이러한 품질의 통신을 수행하기 위해서 TCP를 사용한다.
2. 데이터그램
명시적으로 연결을 맺지 않으므로써 비 연경형 소켓이라고 한다. 메세지는 대상 소켓으로 전송되며 대상 소켓은 메세지를 적절히 수신한다. 스트림소켓을 사용하는것이 데이터그램 소켓을 사용하는것보다 더 신뢰성이 높은 방법이지만 연결을 수립하는데 드는 오버헤드는 무시할 수 없다. 데이터그램 소켓을 사용하려면 클라이언트에서 서버로 데어터를 전송 할때 UDP를 사용한다. 이 프로토콜에서는 메세지의 크기에 약간의 제한이 있으며 메세지의 확실한 전달 역시 보장하지 않으며 통신 중 데이터를 읽어 버리더라도 오류를 되돌리지 않는다.
3. RAW
RAW소켓은 패킷을 가져오면 TCP/IP스택상의 TCP,UDP계층을 우회하여 바로 어플리케이션으로 송신하는 소켓이다. 이런 소켓에서 패킷은 TCP/IP필터를 통해 전달 되지 않으으로 원형 그대로의 패킷을 볼 수 있다. 이는 모든 데이터를 적절히 처리하거나 헤더를 제거하고 이를 파싱하는 과정은 모두 수신 어플리케이션에서 담당해야 하는 것이다. 실제 RAW소켓을 이용하여 프로그래밍을 하는 일은 거의 드물며 만약 시스템 소프트웨어나 패킷을 분석하는 프로그램을 개발할 경우 필요 할수도 있다.
myLG070을 사용하시는 분들 중 상당수가 SIP를 알아내어 다른 전화기에 넣어 사용하거나 x-lite와 같은 별도의 소프트웨어에서 사용하기를 원합니다. 저는 아이팟에서 사용하기를 원하는데요, 불행히도 myLG070에서는 정책적으로 SIP계정을 고객에게 알려주지 않습니다. 아니 왜? 뭥미? 뭐 어쨌든 그렇다고 가만히 있을 우리가 아니죠. s(-_-)z
[ SIP 계정 확인하는 법 ]
아래에 나오는 0707555134는 제 전화번호가 아닙니다. 그러니 전화하셔도 소용없습니다 ^^; 그리고 이 방법은 myLG070이 아닌 다른 VoIP 서비스에서도 사용이 가능합니다. 부디 다른 사람의 SIP 계정을 훔치거나 하는 것과 같은 악의적인 목적으로는 절대 사용하지 마시길 바랍니다.
가장 먼저 해야할 것은 Wireshark와 같은 패킷 캡쳐 툴을 이용하여 myLG070 전화기의 REGISTER 패킷을 캡쳐하는 것이다. 그리고 캡처한 파일은 파일로 저장하도록 하자. 패킷 뜨는 것도 따로 설명을 해야 할까요? 흠;; -_-; 패스
위의 빨간 상자로 표시한 부분이 Proxy 이다. 이건 각자 다른 것 같으므로 잘 확인하자.
REGISTER 패킷 내용을 확인하면 SIP와 비밀번호의 MD5 Hash를 확인할 수 있다.
원래 MD5 Hash는 역함수가 존재하지 않는다. 따라서 비밀번호를 알기 위해서는 브루트 포스(Brute Force)로 비밀번호를 생성한 후 일일이 해시와 비교하여 맞는지 확인하여야만 한다. 어~우 아마 여기서부터 머리가 슬슬 아파지기 시작할 것이다. 그러나 너무 걱정하지는 말자. 이미 누군가가 이 것을 해주는 프로그램을 만들어 놓았다. 우리는 그 것을 잘 이용하기만 하면 된다.
* Select which entry to crack (1 - 1): 1
* Password already cracked: '123456'
크랙을 원하는 항목을 선택하고 잠시 기다리면 위와 같이 패스워드가 '툭' 튀어나온다. 필자의 경우 2초도 채 걸리지 않았다.
비밀번호를 알아내고 나니 정말 허무하네요. VoIP의 보안이 얼마나 취약한지 알 수 있습니다. 공개된 장소에서의 VoIP 사용은 자제해야겠다는 생각만 자꾸드네요. 거듭 말씀드리지만 악의적인 목적으로는 이용하지 말아주시기 바랍니다.필요한 프로그램들입니다. 일단 모두 받습니다.
1. 아무 리눅스 OS를 설치하고 root계정으로 로긴합니다. (gcc는 반드시 깔아야합니다)
2. libpcap-0.8.1.tar.gz 파일 압축을 풀고 컴파일 합니다. ./configure ./make install
3. 생성된 화일중 libpcap.a 화일을 /usr/lib 폴더에 복사하고, pcap.h bpf.h 화일을 /usr/include 로 복사합니다.
4. 3의 파일들은 sipcrack와 sipdump를 컴파일할때 필요한 라이브러리입니다.
5. sipcrack0.2에 있는 pcapstuff.h 화일을 0.3에 복사합니다.
6. make 하면 인스톨을 합니다. make install 하면 /usr/bin 에 복사되서... 어디서는 사용가능하게 됩니다.
7. john-1.7.3.1.tar.gz 의 압축을 푼뒤 src 폴더에서 make clean generic 으로 실행화일을 만듭니다.
sip 크래킹에 필요한 요소는 완료되었습니다.
이제 lg070 의 통화패킷을 가져올 차례입니다.
간편하게 얻을 수 있는 WireShark 를 이용합니다.
패킷을 뜨는 방법은 각자에게 맞겨두겠습니다.
집에 Dummy Hub 가 있다면 070 Ap 를 그쪽에 물리고 다른포트를 노트북에 연결해서 Dump를 뜨거나
Windows 의 공유기능을 이용해 두개의 랜카드 중 하나는 인터넷이 되도록 하고 하나는 070 Ap와 연결하여
공유기능을 통해 통화가 가능하도록 환경을 만들면 AP 와 연결된 랜카드를 통해서 Dump를 뜰 수 있을 것입니다.
방법은 많이 있으니 각자 환경에 맞는 방법을 찾으시기 바랍니다.
이렇게 얻어진 070.pcap 파일을 가지고 암호를 풀어보겠습니다.
1. ./john --incremental=digits --stdout=6 > 6number.txt
2. 캡쳐받은 화일의 을 가져온뒤 sipdump -p 070.pcap 070.dump
3. sipcrack -w 6number.txt 070.dump
만일 하나의 정보만 들어있다면 그냥 암호가 나올 것입니다.
아닐 경우는 자신의 070번호가 들어있는 메뉴를 선택해주면 됩니다.
4. 드디어 암호가 나왔습니다!
5. 이때 Client 라고 표기된 IP 주소를 기억해둡니다.
이제 X-Lite 에서 설정하는 일만 남았습니다.
SIP Account에 다음을 입력합니다.
1. Display Name : 07012341234(자신의 번호)
2. User Name : 7012341234(자신의 번호에서 맨앞의 0을 뺍니다)
3. Password : 아까 알아내셨죠?
4. Authorization user name : User name 과 같습니다.
5. Domain : lgdacom.net
6. Proxy : xxx.xxx.xxx.xxx:5060 (주소에 아까 기억해 두셨던 IP주소를 넣어주시고 뒤에 :5060을 붙입니다.)
This VoIP Security Tool List
provides categories, descriptions and links to current free and commercial VoIP
security tools. Each commercial tool is indicated by the following icon next to
it:
The key objectives of this list are as follows:
Provide links to tools that help test the efficacy of implemented best
practices outlined by VOIPSA's
Best Practices Project.
Facilitate the open discussion of VoIP security tool information to help
users better audit and defend their VoIP devices and deployments.
Provide vendors the information needed to proactively test their VoIP
devices' ability to function and withstand real-world attacks.
DISCLAIMER: Many of these tools can cause harm to
the normal operation of your VoIP network if used improperly. Before using any
tools, we recommend that you read the instructions and other d0cumentation
available on each of the individual tool's websites. By selecting almost any of
these links, you will be leaving VOIPSA's web space. These links and pointers
are provided for our visitors' convenience. Please be aware that we do not
control or guarantee the accuracy, relevance, timeliness, or completeness of
this outside information. No inferences should be drawn because some sites are
referenced, or not, from this page. There may be other tools that are more
appropriate for your purpose. In no event shall VOIPSA be liable for any direct,
indirect, incidental, punitive, or consequential damages of any kind whatsoever
with respect to this list. Further, VOIPSA does not endorse any commercial
products that may be mentioned in this list. These tools are only meant to be
used on networks with the permission of the network owner and in compliance with
the law.
요즘 각 기업이 Internet/Intranet의 열풍 속에서 많은 부분의 업무를 Network에 의존하고 있다. E-mail은 기본이고 그룹웨어(GroupWare)의 도입, 그리고 Client/Server에 의한 업무 처리방식의 도입으로 Network의 중요성이 날로 높아지고 있다. 이제 Network의 다운이나 속도 저하로 인하여 업무 처리가 늦어진다면 이것은 단순한 문제가 아니다.
Network의 대형화, 복잡화, Network를 이용한 업무의 증가 등으로 Network 관리에 대한 중요성이 부각되고 있다. Network 다운 시 신속한 대처는 기본이고 발생 가능성을 사전에 제거하는 것이 중요하다. 이에 Network 관리에 이용되는 Protocol이 각각의 목적에 맞게 탄생하고 이용되어지고 있다. 단순히 Network를 관리해주는 Protocol인 SNMP, CMIP등과Traffic을 관리하기 위해 이용되는 RMON등이 있다.
1. 출현배경
TCP/IP 환경의 Internet Network망 관리를 위해서 처음에는 ICMP(Internet Control Message Protocol)를 이용하여 각 Terminal장비간의 연결 상태 등을 파악했다. 우리가 주로 쓰는 ping이 ICMP를 이용한 것이다. 그러나 이는 단순하게 상대방 HOST가 작동하고 있는 지에 대한 정보나 응답시간을 측정하는 등의 기능만을 제공하고 있다. 그러나 Internet에 접속되는 Host가 엄청나게 늘어나고 Network의 구성이 복잡해지면서 새로운 표준화된 Protocol이 필요하게 되었다. 이에 따라 88년 초 IAB(Internet Architecture Board)에서는 표준화 작업을 시작했다.
이때까지 연구가 진행되어오던 HEMS(High-Level Entity Management System), SGMP(Simple Gateway Monitoring System), CMIP/CMIS(Common Management Information Protocol/Services)중에서 SGMP를 발전시킨 SNMP를 표준으로 채택하기로 결정했다. HEMS는 연구는 상당히 이루어져있었으나 실제 적용 사례가 없었고 CMIP/CMIS는 너무 방대하고 구현이 전혀 되어있지 않은 상태였다. SGMP는 NYSERNET, SURAnet을 위한 실제적인 요구에 의해서 개발된 것으로 Proteon에서 작업 중이었고 MERIT, IBM, MCI에 의해 NFSNET에서 사용하기 위한 작업을 진행 중이었으며 실제로 SGMP를 이용한 응용프로그램으로 유용한 정보를 얻고 있었다. 결국 IAB는 몇 가지 결정을 내렸다.
첫째 단기적으로 기본적으로 SNMP를 채택하고, 둘째 IAB와 업체들은 ISO CMIS/CMP를 기반으로 한 망 관리 시스템을 개발, 발전시킨다. 셋째, SNMP와 관련된 작업은 IETF은 책임지고, 끝으로 이전의 연구 작업 결과를 적극 수용한다. 특히 HEMS를 위해서 정의된 MIB를 받아들인다는 것이었다.
이렇게 출발한 SNMP는 구현이 쉽고 간편해서 오늘날 가장 일반적인 Network 관리 Protocol이 되어있고 구현의 복잡성, 방대함으로 인하여 아직도 CMIP가 망 관리의 중심으로 자리잡지 못하고 있다.
2. MIB(Management Information Base)
Manager와 Agent사이에 특정한 정보를 주고 받는 것이 Network 관리의 기본이다. 관리 되어야 할 특정한 정보(Information), 자원(Resource)을 객체(object)라 한다. 이런 객체들을 모아놓은 집합체를 MIB이라고 한다.
Network를 관리한다는 것은 관리대상인 장비 - Workstation, Printer/File Server와 같은 Host는 물론이고 Hub, Router, Switch와 같은 통신장비 - 들이 제공하는 MIB중에서 특정 값을 얻어와서 그 장비의 상태를 파악하거나 그 값을 변경함을 의미한다. 값의 변경은 해당 MIBD의 String이나 수치를 변경시키는 것은 물론이고 값을 변경을 통하여 그 장비의 상태를 변경시킬 수도 있고 그 장비에 일정한 작동을 지시, 수행할 수 있게 한다. 즉 Interface의 관리 값을 수정해서 해당 장비의 통신을 불가능하게 할 수도 있고 Hub의 특정 포트로의 전송을 막을 수도 있다. 또한 특정 MIB의 변경을 통하여 HUB를 Reset시킬 수도 있다.
MIB를 정의하고 구성하는 Framework인 SMI는 RFC1155에 아래와 같은 사항을 정의해놓고 있다.
1. MIB의 각 객체(Objects)들은 ISO(ISO 8824)와 ITU-T(X.208)에 의해 표준화되고 개발된 언어인 ASN.1(Abstract Syntax Notation One)을 사용해서 정의한다.
2. 정의할 모든 객체는 반드시 이름(name), Syntax, Encoding)을 갖고 있어야 한다.
이름 - 해당 객체를 식별하는 객체 식별자(object identifier)
Syntax - 객체의 Data 종류. 예) INTERGER, OCTECT STRING 등
부호화 - 객체의 Data가 어떤 BIT 패턴으로 전송되는가?
(SNMP는 ASN.1의 BES(Besic Encoding Rules)를 이용.)
3. ASN.1에서 정의된 Data 종류 중 SNMP에서 사용할 수 있는 것과 허용되는 구조가 명시되어 있다.
MIB 구조는 계층적 Tree구조의 형태를 이루고 있다. 특정 객체는 객체 식별자(Object Identifier = OID)에 의해서 확인된다. 실제로 OID는 우리가 일반적으로 사용하는 문자가 아니라 연속된 정수이다. MIB Tree는 Root를 기준으로 동일한 범주에 속하는 객체들을 분류하는 식으로 OID가 정해지고 SNMP는 최종 Node인 Leaf만을 읽고 쓸 수가 있다.
예를 들어System Location에 있는 정보는 OID는 sysLocaion이 아니고 "1.3.6.1.2.1.1.6"이다. 그리고 이 객체는 읽고 쓸 수 있으나 부모 객체인 system("1.3.6.1.2.1.1")은 읽거나 쓸 수 없다. 이에 따르는 하위 객체인 "sysDescr, sysObjectID, ... ,sysServices"를 모두 읽어 오고 싶으면 "1 ~ 7" OID 모두를 지정해서 Agent에게 물어보는 수 밖에 없다. 대부분의 NMS가 system 그룹을 지정하게 해서 값을 얻어오는 데 실제는 위와 같이 조작해서 얻은 것이다.
SNMP SMI는 "iso(1) org(3) dod(6)"의 Sub-Tree로 "internet(1)"을 명시하고 "internet(1)"의 Sub-Tree로 directory(1) , mgmt(2) , experimental(3), private(4)과 private(4)의 Sub-Tree로 enterprises(1)를 정의해놓고 있다. SNMP MIB에 표준으로 정의되어 있지 않는 자신의 회사만이 제공하는 MIB는 이 private(4) enterprises(1)에 정의할 수 있다. 이 이하의 Sub-Tree는 각 업체에서 임의로 사용할 수 있다.
그러나 모든 업체들을 구별하는 OID가 있어야 하는 데 이는 IANA(Internet Assigned Number Authority)에서 관리하고 있다. 그러므로 Private Enterprises MIB를 구현하기 위해서는 IANA에서 OID를 부여 받아야 한다. 그래야 그 하위 MIB의 객체의 유일성이 보장되고 그래야 다른 업체의 사설 MIB와 구별이 가능하다.
# TCP
- Layer 4 계층 프로토콜
- 상위 계층에서 생성된 데이터를 전송하도록 TCP 헤더를 삽입하여 캡슐화 실시
- 연결 지향성 프로토콜
- 상대방과 통신 수립단계를 실시한 이후에 데이터 전송을 실시한다.
- 통신 수립 단계 = '3-Way 핸드 쉐이킹'
제어부호 6 비트(Control Flag 6 Bit)
URG 0 -> 1 : 긴급한 데이터
ACK 0 -> 1 : 통신에 대한 응답 신호
PSH 0 -> 1 : 세그먼트를 바로 어플리케이션 계층에 전달
RST 0 -> 1 : 통신을 강제적으로 종료.
SYN 0 -> 1 : 통신 시작
FIN 0 -> 1 : 통신 종료
hostA -------------------------> hostB
FIN
hostA <------------------------- hostB
ACK
hostA <------------------------- hostB
FIN
hostA -------------------------> hostB
ACK
- 신뢰적인 데이터 전송이 요구되는 환경예서 효율적인 반면에, 대신 신속한 데이터 전송이 요구되는 환경에서는 비효율적이다.(신속함은 필요없고 신뢰적이어야 한다.)
flow control & err control
- 순서화 기능 : 증가되는 데이터 부피를 방지하기 위해서 분할 및 재조립 실시(순서 번호 사용)
- 동기화 기능 : 보낸 정보에 대한 응답(ACK 1bit)를 수신하는 기능(재전송 보장)(확인 번호 사용)
- TCP 헤더 내용
1) 출발지 포트번호(16bit)/목적지 포트번호(16bit) <- 서비스 구분(포트넘버 = 서비스)
2) 제어 부호(Control Flag 6bit) : URG, ACK, PSH, RST, SYN, FIN
3) 순서 번호(32bit) : Sequence number
4) 확인 번호(32bit) : Acknowledgement number
5) 윈도우 사이즈(수신할 수 있는 데이터양) w -> 응답 확인을 받기 전까지 보낼수있는 데이터양 #CCNP 과정 : Qos
6) 에러 체크(check sum) : 검사합
가장 중요한것은 출발지 포트번호 / 목적지 포트번호
[참고] TCP를 사용하는 어플리케이션 프로토콜 및 포트 번호
HTTP(80)
TELNET(23)
SSH(22)
FTP(20,21) : 연결 20 , 데이터 전송 21
SMTP(25) : 서버끼리 메일을 주고 받을 때 사용하는 서비스
POP3(110) : 서버에서 메일을 가져오는 서비스
공통점 : 신뢰적인 데이터 전송이 요구되는 서비스 환경
# UDP
- Layer 4 계층 프로토콜
- 상위 계층에서 생성된 데이터를 전소아도록 UDP 헤더를 삽입하여 캡슐화 실시
- 비연결 지향성 프로토콜 : 통신 수립 단계가 없다. 동기화 기능도 없다.
- 신뢰적인 데이터 전송이 요구되는 환경에서 비효울적이며, 대신 신속한 데이터 전송이 요구되는 환경에서 효율적이다.
- Best Effort 서비스(신뢰성이 보장되지 않는 서비스)
- 브로드캐스트 서비스 & 멀티캐스트 서비스 사용
[참고] 데이터 전송 방식 유형
1) 유니캐스트(Unicast) = 1:1 데이터 전송 방식. TCP 사용
2) 브로드캐스트(Broadcast) = 1:불특정다수 데이터 전송 방식. UDP 사용
3) 멀티캐스트(Multicast) = 1:특정다수 데이터 전송 방식. UDP 사용
- UDP 헤더 내용
1) 출발지 포트 번호(16bit)/목적지 포트 번호(16bit) <- 서비스 구분
2) 에러 체크(check sum) : 검사 합
- UDP를 사용하는 어플리케이션 프로토콜 및 포트 번호
DNS(53) : IP와 도메인 이름 맵핑
DHCP(67/68) : IP 자동배당
TFTP(69) : 적은양의 파일 보낼 때 ex)jumpstart
SNMP(161) : 장비 상태 점검
공통점 : 요청에 의한 신속한 데이터 전송이 요구되는 서비스 환경
# IP (internet protocol)
- Layer 3 계층 프로토콜
- 상위 계층에서 생성된 데이터를 전송하도록 IP 헤더를 삽입하여 캡슐화 실시
- 비연결 지향성 프로토콜 : 통신 수렵 단계 X, 동기화 기능 X
- 신뢰성 보장되지 않는 Best Effort 서비스
- 출발지에서 목적지로 데이터를 전송할 때 최적 경로를 선출하는 일을 담당한다.(routing)
- IP 헤더 내용
1) 출발지 IP 주소(32bit)/목적지 IP 주소(32bit)
2) ToS(8bit) = Type of Services : 데이터 우선 순위를 결정할 때 사용하는 값(CCNP 과정 : Qos)
3) 에러 체크(check sum) : IPv4에서는 있지만, 불필요하다는 이유로 IPv6에서는 삭제됨