패킷 포워딩을 통해 SSL이 적용된 패킷 확인을 위해 사용합니다.

#들어오는 패킷 다시 쓰기

iptables -t nat -A PREROUTING -p tcp -j DNAT --to ${IP:Port}

ex) iptables -t nat -A PREROUTING -p tcp -j DNAT --to 127.0.0.1:8080

# 나가는 패킷 다시 쓰기

iptables -t nat -A OUTPUT -p tcp -j DNAT --to ${IP:Port}

ex) ex) iptables -t nat -A OUTPUT -p tcp -j DNAT --to 127.0.0.1:8080

Chain은 PREROUTING, INPUT, OUTPUT, POSTROUTING이 존재하고 각각 역할은 다음과 같습니다.

PREROUTING 

라우팅이 결정되기 전 체인에 존재하는 룰 적용

INPUT

자신의 호스트를 목적지로 들어오는 패킷에 대해 체인에 존재하는 룰 적용

OUTPUT

자신의 호스트에서 외부로 나가는 패킷에 대해 체인에 존재하는 룰 적용

POSTROUTING

라우팅이 결정되고 난 후, 체인에 존재하는 룰 적용

iptables를 적용하고 난 후, burp에서도 다음 설정을 해줘야 ssl이 적용된 패킷을 확인할 수 있습니다.

[Proxy] - [Options] - [Proxy Listeners] - [Edit] - [Request handling] - [Support invisible proxying(enable only if needed)]

아래 빨간 박스의 옵션을 체크해주셔야 합니다!

출처 : webterror.net/?p=1622

python 내 패킷 캡쳐를 위한 라이브러리로 pypcap을 통해 손쉽게 캡쳐 및 가공이 가능합니다.

다만 pypcap에 대한 자료가 많지않아서 원하는 함수나 기능을 사용하기엔 제약이 있습니다 :/

pypcap installation

pip install pypcap

※ libpcap-dev 의존성을 가지고 있으므로 pypcap 설치전에 libpcap-dev가 설치되어 있어야  함

apt-get install libpcap-dev

pypcap 설치 후 python 실행 > import pcap 을 통해 에러가 발생하지 않는다면 정상적으로 설치가 된 것입니다.

Example Code 

import pcap
import re
import dpkt
import socket

sniffer = pcap.pcap(name=None,promisc=True,immediate=True,timeout_ms=50) # name=eth, None 일경우 모든 default / promisc는 모든 eth에서 패킷 수집 
sniffer.setfilter('tcp and port 80') # set packet filter

for t, p in sniffer:
    eth = dpkt.ethernet.Ethernet(p)
    ip = eth.data
    tcp = ip.data
    try:
        if len(tcp.data) > 0:
            req = dpkt.http.Request(tcp.data)	#Request패킷만 추출
            print("----------------------------------------------------------------")
            print(req)	# 패킷 출력
            print("----------------------------------------------------------------")
    except:
        pass

Example Code 실행 시, 다음과 같이 패킷 캡쳐 확인

출처 : https://saynot.tistory.com/entry/Python-Network-PyPCAP-%EA%B3%B5%EB%B6%80

RTP (Real-time Transport Protocol)

인터넷상에서 다수가 종단간에 실시간으로 비디오나 오디오 패킷을 전송하기 위해 표준화된 실시간 통신용 프로토콜을 말한다.

RTP 구조

RTP 특징

1) 실시간 특성이 강한 데이터의 전달에 이용된다.

2) 통신계층상으로 전송계층용 프로토콜이라고 하지만, IP or UDP 내부에 캡슐화 사용되고 하위계층 프로토콜에는 별로 의존하지 앟는다.

3) 다른프로토콜과는 달리 미리 예약된 포트를 사용하지 않는다.

4) 전송률 제어 등을 위해 별도의 제어용 프로토콜과 병행하여 사용된다.

5) 전달 가능 데이터 포맷이 여러가지이다. (RTP는 오디오용 PCM,GSM,MP3,MPEG등 같은 표준화된 포멧을 전달할 수도, 비표준화된 사적인 오디오/비디오 형식도 전달 가능하다.)

http://www.cyworld.com/Gh0st/5252965

/usr/include/netinet/tcp.h 중

음?ㅠ 보통 struct tcphdr *tcphdr; 이렇게 선언한후에 사용하잖아요 그러면 .... 두개의 구조체가 모두 선언된건가???

#include<stdio.h>

#include<netinet/tcp.h>

int main()

{

        struct tcphdr *tcphdr;

        printf("tcphdr tp_port : %d\n",tcphdr->th_dport);

        printf("tcphdr source : %d\n",tcphdr->source);

        return 0;

}

ARP spoofing을 알기 전에 arp부터 짚고 넘어가자.

arp는 상대방 아이피는 알고 있으나 맥주소를 모를때, 브로드캐스트로 해당아이피를 가지고 있는 컴퓨터의 맥주소를 달라고 요청하는 패킷이다.

arp spoofing 은 이 arp패킷을 이용하여 맥주소를 속여 상대방의 패킷을 훔쳐보는 것을 말한다. 이는 2계층에서 작동하므로 같은 네트워크안에 있어야 한다.

로컬네트워크에서 MAC주소는 arp-a명령어로 확인할 수 있다.

※실습

vm 네트워크 안에서 두개의 os를 켜놓고 실습해보자. 일단 ip_scanner와 같은 툴로 네트워크 안의 활성화 되어 있는 아이피를 찾는다. 

공격자 ip : 192.168.15.128    MAC : 00:0c:29:46:ea:7c

희생자 ip : 192.168.15.129    MAC : 00:0c:29:ad:2c:cf

서버(게이트웨이) ip : 192.168.15.2 MAC : 00:50:56:e4:14:ae

send_arp <바꿀 타켓 ip > < 공격자의 MAC > <공격자 ip > <희생자 MAC>

send_arp 툴을 이용해서 서버에 공격자의 mac주소를 추가 시킨다. 위와 같이 명령어를 입력하면 다른 클라이언트에서 192.168.15.2.에 arp를 날리게 되면 서버의 mac과 공격자의 mac주소가 같이 날라가게 되고, 희생자 컴퓨터는 둘다 서버라고 믿고 두곳에 패킷을 날리게 된다.

명령어를 입력하고 wireshark로 패킷을 잡아보면 희생자컴퓨터의 패킷이 잡히는 것을 볼수가 있다.

 arp패킷을 필터링해서 보면,

arp응답으로 두개의 mac주소를 보내는 것을 알수 있다.

※대응방안

arp -a로 나오는 맥을 변하지 않게 정적으로 static옵션을 주어 설정할 수 있다. 이렇게 설정을 해 두면, mac address를 업데이트하라는 arp패킷에 업데이트 되지 않기 떄문에 보안상 중요하다고 할 수 있는데, static으로 설정하는 방법은,

arp -s < IP주소 > < MAC 주소 >

static설정이 보안상에 좋긴 하나, 만에 하나 잘못해서 설정하면 네트워크가 저멀리 날아갈지도.....바꾸기 전에 메모라도 해두는게 좋을 듯 하다.

ICMP 란?

 ->internet control message protocol의 줄임말로 다른 호스트 혹은 게이트웨이에 연결된 네트워크 상태를 알아보는데 사용된다. 대표적으로 ping이 있음.

ICMP packet 구조는 다음과 같으며, Header 타입은 다음과 같다.

리눅스에서는 /usr/include,netinet/ip_icmp.h에 정의 되어 있다.

ICMP Type을 바꿔서 요청을 보내보는 간단한 소스.

#include<stdio.h>

#include<sys/socket.h>

#include<arpa/inet.h>

#include<string.h>

#include<stdlib.h>

#include<netinet/ip.h>

#include<netinet/ip_icmp.h>

#include<netinet/in.h>

#include<net/ethernet.h>

int main(int argc,char *argv[])

{

int icmp_sock;

struct icmp *p,*rp;

struct sockaddr_in addr,from;

char buffer[1024];

struct ip *ip;

int hlen;

socklen_t sz;

icmp_sock=socket(PF_INET,SOCK_RAW,IPPROTO_ICMP);

p=(struct icmp*)buffer;

p->icmp_type=8;

p->icmp_code=0;

p->icmp_cksum=0;

p->icmp_seq=15;

p->icmp_id=1234;

addr.sin_addr.s_addr=inet_addr(argv[1]);

addr.sin_family=AF_INET;

sz=sizeof(from);

sendto(icmp_sock,p,sizeof(*p),MSG_DONTWAIT,(struct sockaddr*)&addr,sizeof(addr));

recvfrom(icmp_sock,buffer,1024,0,(struct sockaddr*)&from,&sz);

ip=(struct ip*)buffer;

hlen=ip->ip_hl*4;

rp=(struct icmp*)(buffer+hlen);

printf("icmp type : %d\n",rp->icmp_type);

close(icmp_sock);

}

TCP / IP 프로토콜 스택

위 그림을 통해 TCP/IP스택이 총 네 개의 계층으로 나뉨을 알 수 있고, 이유는 데이터 송수신의 과정을 네 개의 영역으로 계층화했다는 의미이다. 인터넷 기반의 효율적인 데이터 전송이라는 문제를 작게 나눠서 계층화함으로써 탄생한 것이 TCP/IP이다.

LINK계층

LINK계층은 물리적인 영역의 표준화에 결과이다. 이는 가장 기본이 되는 영역으로 LAN,WAN,MAN과 같은 네트워크 표준과 관련된 프로토콜을 정의하는 영역이다. 두 호스트가 인터넷을 통해 데이터를 주고받기 위해 물리적인 연결이 존재해야 하는데 이부분에 대한 표준을 LINK계층에서 담당함.(2 - 데이터 링크 계층)

IP계층

LINK계층으로 물리적인 연결이 형성되었으므로, 데이터를 보낼 준비가 된 것이다. 하지만 이때의 문제점이 있는데 바로 데이터 전송을 경로를 설정해야 하는 것이다. 목적지로 데이터를 전송하기 위해서 거치는 경로를 결정하는게 바로 IP계층이고, 이떄 사용하는 프로토콜이 IP이다.

IP자체는 비 연결지향적이며 신뢰할 수 없는 프로토콜임. 데이터를 전송할 때마다 거쳐야 할 경로를 설정해 주지만, 경로는 일정치 않고, 혹시 데이터 전송 도중 경로상 문제가 발생하면 다른 경로를 선택해 주는데, 이과정에서 데이터가 손실되거나 오류가 발생하는 등의 문제가 발생한다고 해서 이를 해결해주지 않는다. 즉 오류발생에 대한 대비가 되어있지 않은 프로토콜이다.(3 - 네트워크계층)

TCP/UDP 계층

호스트 대 호스트의 데이터 송수신 방식을 약속한 것이 TCP/UDP이며, TCP는 확인절차를 걸쳐서 신뢰성이 없는 IP에 신뢰성을 부여한 프로토콜이다. 데이터 전송을 위한 경로를 IP에서 설정해줬으므로, 데이터를 전송할 일만 남았다. TCP/UDP는 IP계층에서 알려준 정보를 바탕으로 데이터의 실제 송수신을 담당한다.(4 - 전송계층)

IP는 오로지 하나의 패킷전송만을 염두해 두고 만들어졌기 때문에 패킷 A가 먼저 보내졌어도 패킷B가 먼저 도착할 수도 있는 것이다. 하지만 TCP프로토콜이 추가 된다면 데이터를 송수신할때 받았는지 확인절차를 거치기 때문에 신뢰성이 증가함.

APPLICATION 계층

소켓을 이용해 무엇인가를 만드는 과정에서 프로그램의 성격에 따라 클라이언트와 서버간의 데이터 송수신에 대한 약속들을 APPLICATION프로토콜이라고 한다.

네트워크를 전혀 모르다가 이제 갓 네트워크를 시작하고 싶어서

평소 관심있어하던 네트워크 패킷분석을 위해 책을 찾던 도중,

Wireshark Network Analysis라는 책을 발견하였다. 책에 보면 추적파일도 많이 제공하고 Wireshark 사용법에 대한 전반적인 지식을 설명하기에 이 책을 잡고 공부를 하고 있다.

헌데 각 장이 끝날때마다 어떤 추적파일을 들면서 문제를 내주는데 책에는 답도 없고, 인터넷에 뒤져도 나오지 않길래 공부도 할 겸 내가 틀렸는지 맞았는지 확실히 알기 위해 여기에 포스팅 해보도록 한다.

책에서 준 패킷파일은 무려 200MB가 넘는다 ㅠㅠ 하나씩 해보도록 하자.

아마도 하나씩 기초부터 밟아나가고 싶어서 하나하나 간단한 것도 포스팅 하겠다.

자 처음으로 http-download-good.pcap파일이다.

(책에서 제공하는 모든 추적파일은 왠지 파일제목만 봐도 느낌이온다)

일단 패킷을 살펴 보면 처음 1,2,3번째 패킷으로 3-way-handshaking하는 과정이 보인다.

3-way-handshaking이란?

 TCP Protocol은 패킷을 주고 받기 이전에 미리 가상의 경로를 설정하는 연결지향형 프로토콜이다. 따라서 TCP에는 먼저 연결을 설정해야 하는데 이 과정을 3-way-handshacking이라 한다.

 <3-way-handshaking 개념도>

1.   연결을 하기 이전에는 클라이언트는 포트가 닫힌 closed 상태이고 서버는 해당 서비스의 포트가 열려있는 listening상태이다.

2.   클라이언트 측에서 서버와 연결을 하고 싶을 때는 임의의 포트번호를 받고 SYN패킷을 서버측으로 보낸다.

3.   클라이언트로부터 SYN패킷을 받은 서버는 SYN패킷과 함께 잘 받았다는 응답과 패킷을 보내도 된다는 의미로  ACK패킷을 보낸다.

4.  클라이언트는 다시 응답을 받았으므로 이제 연결을 하고 패킷을 보내겠다는 뜻으로 ACK를 보내면 연결이 완료된것이다.

이때의 클라이언트의 ip는 10.0.52.164가 되고 서버의 ip는 204.152.184.134이다.

다시 본론으로 돌아와서, 추적파일을 봐도 별다른 이상이 있어보이지 않는다. 3-way-handshaking으로 연결을 하고, 서버로 부터 00o_2.0.0_win32Intel_install.exe파일을 요청하고 그에 대한 응답으로 서버에서 데이터를 보내주고 있다.

<HTTP Protocol을 이용 GET방식으로 exe파일을 요청하고 있다.>

이 추적파일에서는 더이상 볼만한 것은 남아있지 않은 것 같으므로, 다운로드 받았던 데이터를 조립해 보도록 하자.

데이터를 자세히 보니 파일헤더가 MZ로 시작한다. 위 패킷으로 알수 있듯이 보냈던 exe파일이 아마 이것일 것이다. 위에 다 떼버리고 MZ부터 밑으로 쭉 긁어서 Winhex로 붙여서 a.exe파일로 저장해본다.

원래 win32Intel~~~.exe 파일이었으니 윈도우 32bit용 파일이라 64bit인 내컴퓨터에서는 어자피 안돌아갈테니까 제대로 파일을 꺼냇는지 알기 위해 실행이나 한번. ㅋㅋㅋ

첫포스팅이고 잠도 오니까 정말 간단한 예제를 들어서 포스팅을 했다. 책을 공부하면서 점점 포스팅도 해가고 일단 기본적인 네트워크지식부터 다시 제대로 다지기 위해 포스팅을 할 생각이다.

처음이라 이거했다가 저거했다가 글이 너무 길어진 느낌이지만 하다보면 괜찮아지겟지 ㅠㅠ 다음엔 주제를 가지고 하나씩 .... 하고 싶지만 과제가 너무 많아 ㅠㅠ