2013년 11월 27일 수요일

TCP 3 way handshake

삼방향 핸드셰이크란?

TCP 기반의 통신은 서로간의 신뢰성있는 통신을 하기 위하여 3 Way-Handshake 라는 절차를 통해 서로간의 원할한 통신이 가능한지 선행 절차를 수행하게 된다.
(데이터를 송 수신 하기 이전에 세션을 확립하는 절차)

- 목적지 호스트가 UP 상태인지 확인한다.
- 서로간의 원할한 패킷 흐름 유지가 가능하다.






< TCP 3 way handshake >


ACK = 확인 응답
SYN = 일련 번호



1. Client -> Server [일련번호 전송]
서버와 연결을 위해 맨 처음 [SYN] 플래그가 설정된 패킷을 송신한다.

Sequence number = 0







2. Server -> Client [확인응답 + 일련번호]
클라이언트로 부터 [SYN] 플래그가 설정된 패킷을 수신한 서버는
그에 대한 확인 응답으로 [ACK]를 설정하여 보냄과 같이 [SYN]을 같이 설정하여
하나의 패킷으로 송신한다.

Sequence number = 0
Acknowledgment number = 1 (1번 패킷의 sequence + 1)





3. Client -> Server [확인응답]
서버로부터 [SYN] 플래그가 설정된 패킷을 수신한 클라이언트는
확인 응답으로 [ACK] 플래그를 설정한 패킷을 서버로 송신

Sequence number = 0
Acknowledgment number = 1 (2번 패킷의 Sequence number + 1)



확인 응답 번호는 이전 패킷의 Sequence Number 보다 하나가 큰 값으로 설정되어 전송된다.

위의 절차가 정상적으로 끝나면 서로간의 데이터를 주고 받을 수 있는 상태가 된다.



SYN_SENT : 클라이언트에서 SYN 패킷을 송신 했지만 서버로부터 ACK를 받지 못한 상태
(1번에 해당)

SYN_RCVD : 서버에서 클라이언트로 SYN/ACK 패킷을 송신 하였지만 ACK 패킷을 수신받지 못한 상태 (2번에 해당)

ESTABLISHED : 서버-클라이언트 간의 3 way-handshake 상태가 끝난상태. 이 상태부턴 데이터 교환이 가능해진다 (3번에 해당)



[출처] TCP - 3 way handshake|작성자 육육

DHCP 패킷 분석 - 2






DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK 

4개의 패킷을  차례대로 살펴 보겠습니다.





< DHCP Discover >


1. DHCP Discover

IP 주소를 동적으로 할당 받기를 원하는 클라이언트는 DHCP 서버를 찾기 위해 DHCP Discover 패킷을 목적지 255.255.255.255 로 송신한다. 즉 Broadcast로 패킷을 전파 한다.
;
;
(1) Message type : boot Request

Message type 필드의 값을 보면 패킷이 요청인지 응답인지 알 수 있다.
(1은 요청, 2는 응답)
클라이언트가 DHCP 서버를 찾기 위해 송신 하므로 1의 값이 설정된다.
(DHCP 서버는 응답을 해달라는 요청을 하는 것이기 때문이다.)
;
;
(2) Transaction ID : 0x6b3d8569

하나의 request, reply는 동일한 Transaction ID를 가진다.
즉, 이 필드에 0x00000001의 값이 설정되어 요청을 한다면
그에 대한 응답을 받을 때, 0x00000001의 값이 설정 되어 응답을 받는다.
;
;
(3) Bootp flags : 0x0000 (unicast)

Bootp flags 필드의 Broadcast flag 가 1로 설정 되면 서버가 이 패킷을 수신하여 응답을 할 때 Broadcast로 응답 하게 된다. 사진엔 보이지 않지만 이 값이 0으로 설정 되어 있으므로 이 패킷에 대한 응답을Unicast로 하게 된다.
(서버에게 어느 유형으로 응답을 해달라는 요청 정도로 보면 된다.)
;
;
(4) option: (53) DHCP Message Type

이 필드는 DHCP 패킷이 어느 유형의 패킷인지 나타낸다. 현재 필드에선 값이 1로 되어 있는데, 이는 즉DHCP Discover 패킷 임을 알 수 있다.
;
;
;
(5) option: (55) Parameter Request List

이 필드는 클라이언트가 서버로 IP 주소 할당 요청을 하여 그에 대한 응답을 받을 때, 추가로 받고 싶은 요청 목록이다.
DNS 서버 도메인과 주소, Gateway 주소 등등 여러 가지를 요청 할 수 있다.
;
;







< DHCP Offer >

2. DHCP Offer

클라이언트로 부터 DHCP Discover 패킷을 수신한 서버는 DHCP Offer 패킷으로 응답을 한다.
이 패킷에는 클라이언트에게 할당 가능한 IP 주소와 여러 정보들을 담고 있다.
;
;
(1) Message type = boot Reply (2)

DHCP Offer 패킷은 클라이언트로부터 받은 요청에 대한 응답 패킷이다.
그러므로 이 필드의 값이 2로 설정 되어 있다.
(1=요청 / 2=응답)
;
; 
(2) Transaction ID : 0x6b3d8569

하나의 request, reply 패킷은 이 필드의 동일한 값을 가진다고 위에서 설명 하였다.
위의 DHCP Discover 패킷과 현재 보고 있는 DHCP Offer 패킷을 보면 이 필드의 값이 동일 하므로
하나의 요청에 대한 응답은 이 필드의 값이 같다는 것을 알 수 있다.
;
;
(3) Your (client) IP address: 172.16.99.2 (172.16.99.2)

이 필드의 값은 임대 가능한 IP 주소이다. 즉 서버에서 제공하려는 주소가 이 필드에 나타나 있다.
;
(4) Client MAC address : vmware_04:9c:c8 (00:0c:29:04:9c:c8)

이 필드는 IP 주소를 제공받을 클라이언트의 MAC 주소가 들어있다.
;
;
(5) option: (53) DHCP Message Type

현재 이 필드에 2의 값이 설정 되어 있다. 2는 DHCP Offer 패킷임 을 나타낸다.
;
;
(6) option~

DHCP 서버는 클라이언트에게 IP 주소 할당을 함과 같이 다른 여러 가지 정보들을 같이 전송한다.
이 옵션이 바로 여러 가지 정보들이다. 사진을 보면 DHCP 서버 주소, 임대기간, 서브넷, 게이트웨이 등등 여러 가지 정보들을 담고 있다.
;
;
!!!
DHCP Offer 패킷을 수신한 클라이언트는 IP 주소를 바로 사용 하지 않는다.

왜냐하면 여러 DHCP Server로 부터 DHCP Offer 패킷을 수신 하게 되면 그중 가장 빨리 수신한 패킷을 
보낸 서버와 두 가지의 절차를 더 수행 한 후 완전히 IP 주소를 할당 받아 사용 할 수 있게 된다.

즉 DHCP Offer 패킷은 클라이언트에게 "나는 이런 IP 주소를 할당 해 줄 수 있다" 라고 제의를 할 뿐 할당을 하는 것은 아니라고 볼 수 있다.
;
; 






< DHCP Request >

3. DHCP Request

클라이언트가 DHCP 서버로 부터 DHCP Offer 패킷을 수신 하면 DHCP Request 패킷을 송신한다.
DHCP 서버로부터 "이런 IP 주소를 할당 해 줄수 있다" 라는 DHCP Offer 패킷을 받게 되면 클라이언트는 서버에게 "그 IP 주소를 사용 해도 되겠냐?" 라는 의미의 DHCP Request 패킷을 보내게 된다.
만일 여러대의 DHCP 서버로 부터 DHCP Offer 패킷을 수신 하였다면 맨 처음 도착한 DHCP Offer 메세지를 송신한 서버로 DHCP Request 패킷을 보내게 된다.
;
;
(1) Message type : boot Request (1)
DHCP Request 패킷은 이름에서도 볼 수 있듯이 요청을 하는 패킷이므로 1의 값이 설정 되어 있다.
(1=요청 / 2=응답)
;
;
(2) option: (53) DHCP Message Type
이 필드에 3의 값이 설정 되어 있으므로 이 패킷은 DHCP Request 패킷 임을 나타낸다.
;
;
(3) option: (50) Requested IP Address
이 필드에는 DHCP Offer 패킷의 Your (client) IP address 필드의 아이피 주소가 이곳에 들어가게 된다.
즉, 서버는 클라이언트에게 Offer 패킷으로 “난 너에게 n.n.n.n IP 주소를 할당 해 줄 수 있어” 라는
제의를 하게 되고 클라이언트는 서버에게 DHCP Request 패킷으로 “n.n.n.n의 아이피를 사용해도 괜찮냐?” 라는 요청을 보내게 된다.
;
;
(4) option: (54) DHCP Server Identification
DHCP Request 패킷을 수신 할 서버의 IP 주소가 이 필드에 나타나 있다.
;
;





< DHCP ACK >

4. DHCP ACK 

서버는 클라이언트로 부터 DHCP Request 패킷을 송신 하게 되면 그에대한 응답으로 ACK 패킷을 보내게 된다. (ACK = Acknowledgment // 인정, 승인, 답신 등등 허용한다는 뜻을 가지고 있다)

이 과정이 끝나면 비로소 클라이언트는 할당받은 IP를 사용할 수 있게 되고, 서버는 자신의 DB에 정보를 기록하게 된다.
;
;
(1) Message type : boot Reply (2)

클라이언트에게 최종 응답을 해주는 것 이므로 2의 값이 설정 되어 있다.
(1=요청 / 2=응답)
;
;
(2) option: (53) DHCP Message Type 
현재 DHCP ACK 패킷에는 5의 값이 설정 되어 있다. 즉 5의 값이 설정 되어 있으면 DHCP ACK 패킷 임을 나타낸다.
;
;




[출처] DHCP 패킷 분석 - 2|작성자 육육

DHCP 패킷 분석 - 1





<Client -> Server> 



<Server - > Client> 


DHCP는 신뢰성이 내장되어 있으므로 UDP 기반의 통신을 한다.

특이한 점은 서버로 IP 임대를 요청하는 Clinet의 포트가 
임시 포트가 아닌 68번 포트로 고정되어 있다.










1. Message Type (OpCode)
= 패킷이 요청인지 응답인지 나타낸다.
  1 = Request (요청)
  2 = Reply (응답)

2. Hardware Type
= 물리적인 네트워크 타입을 나타낸다. 
  이더넷의 경우는 0x01 의 값으로 설정된다.

3. Hardware length 
= 물리적 주소의 길이를 나타낸다. 
  이더넷의 MAC address의 경우는 길이가 6으로 표기 된다. (6 byte)

4. Hops
= 패킷의 최대 홉 수를 나타낸다.
  DHCP 서버를 찾기 위해 중계 에이전트에 의해 사용된다.
  만일 DHCP 서버 까지 홉수가 모자른다면 패킷은 도달하지 못한다.

5. Transaction ID
= 하나의 Request, Reply 는 동일한 트렌젝션 ID를 가진다.
  식별자 정도로 생각하면 된다.

6. Seconds elapsed
= 클라이언트가 맨처음 DHCP 서버에게 주소 요청을 한 이후의 경과 시간을 나타낸다.

7. Bootp Flags
= 클라이언트가 이 필드에 설정된 값으로 요청 패킷을 보내면 
  서버로 부터Broadcast 또는 Unicast로 응답 받게 된다. 
  (Broadcast flag 필드에에 설정된 값이 1 이면 Broadcast, 0이면 Unicast를 나타낸다.)

8. Client IP address
= 요청하는 클라이언트의 IP 주소를 나타낸다.
  
9. Your IP address
= 임대 가능한 IP 주소가 들어있다. 
  서버에서 임대 요청에 대한 응답을 할때 이 필드에 임대 IP를 설정하여 응답한다.

10. Server IP address
= DHCP 서버의 IP 주소

11. Gateway IP address ( Relay agent IP address )
= 게이트웨이의 주소를 나타낸다.

12. Client Hardware address
= IP 임대 요청을 하는 클라이언트의 하드웨어 주소가 설정 되어 있다.
  이더넷의 경우 MAC 주소가 이 필드에 설정된다.

13. Server Host name
= 서버의 호스트 네임을 나타낸다.

14. Boot File name
= DHCP가 사용할 부트 파일

15. Option
= 추가 기능을 주기 위한 필드이다. 여러가지 옵션을 추가 할 수 있으며 확장성을 가지고 있다.
  



[출처] DHCP 패킷 분석 - 1 |작성자 육육

Banner Grabbing





Banner?

-telnet / ftp / ssh 를 이용하여 접속 시 나타나는 안내문

이 안내문을 통하여 타겟의 여러가지 정보를 취득할 수 있다.





따로 배너 설정을 하지 않았을 때의 기본적으로 로그인시
다음과 같이 출력 문구가 나타난다.

< Telnet:23 >

CentOS release 6.4 (Final)
Kernel 2.6.32-358.e16.i686 on an i686

운영체제, 커널의 정보 노출











< FTP:21 >

220 (vsFTPd 2.2.2)

사용하는 FTP 패키지 버전 정보 노출











< nc를 이용한 정보 확인>


C:\>nc 192.168.21.200 80
GET index.html









< httprint 를 이용한 정보 획득 >




httprint를 이용하였을 때
ICMP를 비 허용하게 되면
정보를 얻어 올 수 없게 된다.

패킷을 보면 세션을 맺기 전에 ICMP 요청에 대한
응답을 보내온 타겟만 httprint를 이용하여 
정보를 획득 할 수 있게 된다.









2013년 11월 18일 월요일

STP - backbonefast

Backbone fast

- 자신과 직접 연결되지 않은 간접 링크가 다운되었을때, 차단상태에 있는 포트를 Max Age time 20초를 생략하고 Listening 상태로 변경하여 STP 컨버전스 시간을 50초에서 30초로 단축시킨다.





 루트 브리지인 Switch-01에서 보내오는 Config BPDU를 Switch-02는 Fa 1/0 RP로 수신 후 Fa 1/2 DP로 송신하여 Switch-03의 BP 포트로 전달하게 된다.

하지만 그림과 같이 Switch-01 --- Switch-02 사이의 경로에 장애가 발생하는 경우엔 Switch-02는 자신과 연결된 링크에 문제가 있음을 즉시 감지하고 자신이 루트라고 주장하는 후순위 BPDU를 Switch-03쪽으로 송신하게 된다.
  
   !!! 후순위 BPDU란 기존의 Root bridge 보다 안좋은 조건의 BPDU를 뜻함.
그림에선 Switch-02가 Switch-01보다 조건이 좋지 않으므로 Switch-02가 보내는 BPDU를 후순위 BPDU라고 한다.



Switch-03은 설정이 변경된 BPDU를 받게되면 상태를 바로 변화시키지 않고 Max Age 시간 동안 자신의 상태를 유지하게 된다. ( 20s )
 그 후 Listening, Learning 상태를 거쳐 Forwarding로 변하기 까지 30초의 시간이 소요가 된다.
총 50초의 시간이 소요가 된다.
(Max Age + Listening + Learning = 50s)




Backbone fast를 적용 하게 되면 Max Age 시간을 건너 뛰고 바로 Listening 상태로 돌입하게 된다.





< Backbone fast 동작 과정 >



1. S/W-02는 자신의 Fa 1/0 링크가 다운된것을 바로 감지하고 S/W-03 쪽으로 자신이 루트라고 주장하는 BPDU를 전송.

2. S/W-03은 BPDU를 수신하자마자 Fa 1/1 쪽으로 자신과 루트까지의 링크는 문제가 없는지 확인을 위해 Root Line Query 프레임을 송신.

3. Root bridge인 S/W-01은 이상 없음을 응답하는 Root Link Reply 프레임을 전송.



< 2, 3번 과정 패킷 캡쳐 >







위의 과정을 모두 정상적으로 거치게 되면 Max Age 시간을 건너뛰고 바로 Listening 상태로
돌입한다.