SK shieldus Rookies 16기 (네트워크 보안 #02)

만두다섯개·2023년 11월 14일
클라우드클라우드보안
0

SK 루키즈 16기

목록 보기
17/52
post-thumbnail

교육 정보

  • 교육 과정명 : 클라우드기반 스마트융합보안 과정 16기
  • 교육 회차 정보 : '23. 11. 14. 네트워크 보안 #02

요약

  • TCP/IP 통신 모델 계층별 분석
  • Ethernet Frame 구조
  • ARP 프로토콜
  • MSS 와 MTU를 가정한 데이터 분할 (??)

TCP/IP Protocol Stack

  • 7층(7~5), 4층, 3~2층, 1층 구분.
  • HTTP 패킷이 7~4층에서 페이로드로 전달되며 캡슐화 과정이 진행.
  • IP, MAC 주소를 기반으로 ARP, RARP 프로토콜 사용
  • 3계층 필수사용 프로토콜 : IP

  • 와이어 샤크 TCP/IP Protocol Stack 및 페이로드&캡슐화 기능을 각 계층별프로토콜 확인 가능
    -> Network Layer 계층 패킷임을 알 수 있다. (ARP 까지사용)

Transport Layer

TCP Header

  • 헤더는 각 필드로 구성된다. 20~60 바이트로 구성.
  1. sequence number
    • TCP 세그먼트의 연속된 데이터 번호
  2. HLEN(Header Length)
    • 4비트 사용으로 표현 가능한 수는 0~15이나, IPv4 헤더 길이는 20~60이므로, 실제 TCP Header 길이는 HLEN 길이의 4배이다.
    • Flag 플래그는 6비트로, HLEN 설정 정보(Reserved : 16비트에서 HLEN, 플래그 필드 제외 공간, 추후 사용 예약 공간)
  3. Window Size
    • TCP 속도 문제 해결 목적을 위해 존재하는 필드
    • 패킷 - TCP 프로토콜 - 옵션 - 윈도우 스케일
    • 고급 전송속도를 위해 윈도우 크기를 키우기 위해 사용하는 옵션이다.
  4. Checksum 필드
    • 헤더 오류 검출목적 사용
  5. Urgent pointer 필드
    • 3-way-handshake 시 해당 필드 크기가 정해진다.

###　PSH Flag
* PUSH Flag 설정 시, 3계층에서 MSS 크기에 비해 메시지 크기가 작아도 계속 패킷을 받아 MSS 크기를 채워야 다음 계층으로 보내는 것이 아니라, 다음 계층인 Transport Layer로 보낸다.

  • 3 way–handshake 시, MSS를 설정한다.
  • MARK 되는 조건은? == 설정되는 조건은? : payload 된 데이터가 MSS 보다 작을 때

Urg : Urgent Flag(sequence 순서가 아닌, 우선 데이터 전송 시 사용)

TCP 프로토콜

  • Transmission Control Protocol, 전송 제어 프로토콜
  • 서버-클라이언트 간 통신 확인 가능(신뢰성), 전송 속도 느리다. 데이터 전달, HTTP 프로토콜

netsate –an 명령어

  • CMD 관리자 권한 실행
  • 현재 내 컴퓨터와 연결된 대상들의 주소와 상태를 출력한다.
  • ESTABLISHED : 가상 회선이 연결된 상태(클라이언트-서버)

3-way-handshaking 과정

  • TCP 프로토콜이 전송 전,중,후
    1. 전송 전 : (SYN == 1) : 3 WAY Handshaking (가상회선 설정)
    가상회선 설정 전제 : 서버 UP, 서비스 UP
    2. 전송 중 : TCP
    3. 전송 후 :
    EX)
    flag - SYN : 1, 전송 전
    flag - FIN : 1, 전송 종료
    flag – SYN, FIN : 0, 데이터 전송 중

  • 3-way-handshaking

  1. 클라이언트 -> 서버 : SYN
  2. 서버 -> 클라이언트 : SYN + ACK
  3. 클라이언트 -> 서버 : ACK
  4. ESTABLISHED 상태 (요청/응답 가능한 2개의 라인이 생성되고, 이를 세션 생성이라고 한다)

와이어샤크 예제로 3-way-handshaking 과정 확인

  • Sequence Number 간소화 설정 해제 : TCP 패킷(좌측 하단) – preference – Reassemble out-of-order segments 해제 (오리지날 값을 확인 가능)
  • 3-way-handshaking 과정에서 데이터가 없는 상태로 패킷 전송한다. (연결 설정 후 데이터 전송)
  • 클라이언트, 서버는 처음 Sequence Number를 보낸다. 클라이언트가 보낸 SN로 서버는 AN를 사용한다.
  • SN 초기 값은 무작위로 탄생한다.
  • 3-way-handshaking 과정 패킷 순서 (0은 0이 아닌, Not set 의 의미)
  1. SYN = 1, SP=1606, DP=80, SN=767, AN = 0
  2. SYN = 1, ACK = 1, SP=80, DP=1606, SN=373, AN = 768
  3. SYN = 0, ACK = 1, SP=1606, DP=80, SN=768, AN = 374

TCP 데이터 전송 과정

트래픽 전송 과정 종류에 따른 Sequence Number, Acknowlegment Number 살펴보기

  1. 정상적인 트래픽 전송 과정
  • 3-way-handshaking 과정에서 왜 ACK Number를 사용하는가? TCP 프로토콜의 특징인 신뢰성 때문이다. 상대 대상(클라이언트)로부터 송신자가 보낸 데이터를 받았다고 확인 가능
  • AN은 클라이언트가 보낸 SN + 데이터크기임을 알 수 있다.

  1. 비정상적인 트래픽 전송 과정

  • SN이 5000 + 데이터크기 500 전송 후, 수신호스트로부터 SN 5200 온다면, 이는 수신호스트가 300 바이트를 받지 못한 것이다.
  • 수신호스트의 AN으로 비정상적 트래픽이 수신된 것을 확인한 송신호스트는 재전송한다.
  • AN 의 용도 : 수신호스트로 전송한 데이터가 잘 전달됐는지 확인 가능,
  • 만약 수신호스트에서 계속 패킷 손실이 발생한다면, 송신호스트는 계속 패킷을 전송할 것이고, 이는 오버헤드를 발생시킬 것이다.

비 정상적 트래픽 전송 방지 방법

  • 아래 방법은 TCP 프로토콜에서 제공하는 기능이다.

  1. SACK 설정해 문제가 있는 패킷이나, 받지 못한 패킷만 재전송 요청한다.
  2. RTT 설정으로 일정 시간 이후 재 전송한다. (수신호스트가 정상적으로 받은 패킷의 응답이 송신호스트가 받지 못했을 때)
    • RTT란? Round Trip Time으로, 패킷이 송신지부터 수신지까지 왕복시 걸리는 시간

핸드세이킹 과정 첫 번째에서 확인할 수 있는 것

  1. Window Size : (최대 받을 수 있는 데이터 크기) 8192 설정
  2. SACK permited 설정 시, 전송 문제로 여러 패킷 중 한 개라도 문제가 있는 패킷이 있다면 해당 전송되지 않은 패킷만 재전송한다. (Selective Ack(SACK) Permitted, 선택확인 응답), 디폴트 값은 모두 재전송.

TCP 프로토콜에서의 트래픽 흐름제어

연속으로 데이터 전송 및 Winodw Size 변경

  • 송신 호스트는 AN으로 SN + (Data Size 합)을 받는다.
  • 두 번째 전송 패킷의 SN은 6400 이다.

NAK 사용으로 손실 패킷 재전송받기

  • NAK : Negative Acknowledgement 약자로, 패킷 오류 또는 잘못된 순서로 받았음을 문제가 있는 패킷의 번호와 함께 보낸다.
  • 3가지 패킷을 동시에 받는다. (Window Size 이내), 수신 호스트는 손실된 패킷을 송신 호스트로 알려주기 위해 NAK를 보낸다 (비정상 SN을 사용한다)

만약 Window Size가 0 이라면?

  • 수신호스트의 시스템 문제 발생 가능으로 해당 시스템 점검이 필요하다. 단, 송신호스트가 Keep Alive를 지속적으로 보냈음에도 Window Size가 0인 경우.

TCP 연결 종료 과정

  • 그림에서 클라이언트는 TIME_WAIT 후 서버로 ACK를 전송한다. (그림오류, FIN을 받자마자 ACK를 전송하는게 아님)

TCP 연결 종료 과정 중, 클라이언트의 ACK 전송 실패 발생

  • 서버는 클라이언트로부터 ACK를 받지 못하면 계속 FIN을 전송해 자신의 FIN을 알린다.

UDP Header

  • UDP : 서버-클라이언트 간 통신 확인 불가(신뢰성 X), 전송 속도 빠르다. 실시간 전송

  • UDP Header는 8바이트 고정길이를 사용한다.

  • UDP Header = UDP Length – UDP payload = 8 바이트 (고정)
  • 2바이트(16비트)의 UDP Checksum 사용한다. 그러나 해당 기능에는 재요청 기능이 없다(비신뢰성 특징), UDP 프로토콜이 어플리케이션에서 처리한다(즉, UDP 프로토콜 자체로는 재전송 불가)

TCP vs UDP

  • UDP:
    1. Message-Oriented Transport Protocol : 데이터를 메시지라는 개별 패키지로 전송(가변X -> 단편화 지원 X)
  • TCP:
    1. Stream-Oriented Transport Protocol : 데이터를 특별한 구조 형식으로 지정해 전송하지 않는다(가변-> 단편화 지원)

#3_Internet Layer – IP 프로토콜

  • TCP/IP의 Internet Layer 는 OSI 7계층에서의 Network Layer 이다.
  • IP 필드 소개
  • MTU & 단편화

IP 필드 소개

  • IP 프로토콜의 패킷은 [ IP Header ] + [ Data ] 로 구성된다.
  • IP 프로토콜 사용 시, [ Data ]는 필수로 필요하다.

MTU & 단편화

  • MTU : 네트워크 기기 최대 전송 단위
    예시) APP MTU: 4000byte,, LANcard: 1,500byte 라면, 앱 외부로 나갈 수 있는 최대 전송 단위가 1,500 이므로, 4,000 – 1,500 나머지는 폐기된다.
    이를 해결하기 위해 등장한 개념이 단편화(Fragement) 이다.

단편화

  • 위 상황에서는 3, 4 계층에서 단편화 작업을 해 줘야 한다.
  • 4계층에서 단편화를 하지 않는다면 반드시 3계층에서 단편화 작업이 필요하다.(???)
  • Fragmentation, 단편화(송신측) <-> Reassamble, 재조립(수신측)
  • 전송 중에는 재조립 불가(비효율)
  • 분할 후 분할된 조각이 순서대로 도착하지 않을 수 있다 따라서, 태그를 사용해 분할된 패킷마다 태그를 부착한다.

####　MTU 값 변경 방법

MSS

  • Maximum Segment Size, 최대 세그먼트 크기가 아니라, 최대 데이터의 크기를 나타낸다.
  • 어? Segment는 전송 계층의 PDU 아닌가요? 왜 최대 세그먼트 크기가 아닌거죠?
  • 왜냐하면 Segment 는 [TCP Header] + [ payload ] 로 이루어졌기 때문란다.
  • 즉, MSS의 정의는 최대 데이터 크기를 나타낸다 (최대 Segment 크기로 정의한다고 생각하면 TCP Header 가 존재해 맞지 않는 정의..)
  • 전송하려는 패킷의 헤더가 계층마다 다르다.
  • PDU : 계층에서 부르는 데이터의 단위, Protocol Data Unit
  • 7~5계층(메세지), 4(세그먼트 또는 데이터스트림), 3(패킷 또는 데이터그램), 2(프레임), 1(비트)
  • MTU = IP Header + TCP Header + Payload <= 1500 byte ,
  • 실제 전송 데이터 길이 (MTU + EthernetHeader + FCS_Frame check sequence) = 1500 + 18 = 1518
  • MSS 가 1460 이면 ? IP HEADER, TCP HEADER 크기가 20 /20 이라는 의미

TTL

  • Time to live 약자,
  • 라우터간격 수를 1홉이라고 할 때, 패킷 전달 중 데이터그램이 통과하는 최대 홉수를 TTL 에 지정한다.
  • 적절한 TTL 값이 주어져야 한다.
    1. 너무 많을 경우 : 패킷이 돌아오지 못할 경우 루핑 발생 가능
    2. 너무 적을 경우 : 패킷이 목적지까지 가지 못한다.
  • TTL 은 OS가 설정한다.
  • netsh 명령어
  • CMD에서 MTU, TTL 값을 변경 가능하다? OS에서 해당 값들을 변경 가능하다. 즉, 컴퓨터(7계층) 장비에서는 하위 계층의 설정 값을 변경가능하다. (1~7계층까지 사용한다는 의미이므로)
    컴퓨터 설정 값은 etc – service 파일에 들어있다. tcp 는 6번, udp는 17번처럼.

###　Header checksum

  • 헤더의 오류 검증 목적으로 사용한다
  • 송신자 : 헤더 체크썸 필드를 제외한 모든 필드를 더한다(16진수 덧샘), 그리고 체크썸 필드기록 후 전송한다.
  • 수신자 : 수신한 데이터의 헤더 체크썸 필드를 제외한 모든 필드를 더하고, 해당 값이 체크썸 필드와 같는지 확인해 무결성을 검사한다.
  • 패킷 전송과정에서의 오류를 확인하기 위해 사용한다.
  • 프로토콜마다 체크썸 생성 방식이 다르다. (TCP, UDP, IP, Ethernet )
  • 송신자 측에서는 IP header에서 Header checksum 제외 값을 모두 더한 후 Header checksum 에 넣는다.

  • Header checksum 를 만들 때, 각 자리의 수를 16비트 단위로 끊는다. 16진수 단위로 사용하기 때문이다.

#4_Internet Layer – ICMP 프로토콜

  • Internet Control Message Protocol, 약자로, 3계층 프로토콜이다.
  • IP 프로토콜을 보완하기 위해 사용한다.
  • IP 프로토콜의 어떤 점을 보완하는가?
    1. IP Header [ Hedaer checksum ] : IP 헤더의 무결성 확인 용도, IP 헤더에서 패킷의 데이터 내용에 대해 알려주는 필드가 없다. (전송 에러 등..)
    2. [ Time to live ] 필드 또한 해당 홉이 다 사용된다면 다시 알려주지 않고 해당 패킷을 폐기한다.
    3. 따라서 IP 프로토콜 기능을 보조 목적으로 ICMP 프로토콜이 사용된다.
  • IP Protocol 신뢰성이 없고, 비 연결형 Protocol 이라고 볼 수 있다.
  • IP Protocol 에러 발생 원인, 진단기능, 상황 정보를 지원하지 않는다.
  • ping 명령어는 ICMP 프로토콜을 사용한다.

ICMP 메시지

  • ICMP 메시지 종류 : 1. 오류 보고 메시지, 2. 질의 메시지
  • 오류 보고 메시지 : IP 패킷 중 발생 문제 보고
  • 질의 메시지 : 호스트로부터 특정 정보 획득, 네트워크 문제 진단
  • ICMP 메시지는 IP 메시지에 포함되어 있다.

ICMP Header

  • 총 8 바이트로 구성된다.

  • ICMP 패킷에서의 Data 는 32 byte 전송되며, 가비지 값에 해당한다.
  • ICMP 패킷 세부 내용에서 Type, Code 값에 따라 나타내는 ICMP 메시지가 다르다. (ICMP Code 표 참조.)

ping 명령어 실습

  • ping –t 192.168.0.1 (계속 패킷 전송)
  • ping –n 3 192.168.0.1 (3개 패킷만 전송)
  • ping –l 5000 192.168.0.1 (5000바이트 크기의 패킷 전송_ 세부 : ICMP 메시지 크기 = IP 프로토콜 데이터 크기)
  • ping –f 192.168.0.1 (단편화 하지 말고 패킷 전송해라. )
  • ping –l 5000 -f 192.168.0.1 (단편화 하지 말고 5000 바이트 크기의 핑 명령어 전송해라? - 전송 불가하다고 나온다.)
  • ping 명령어에 따른 에러 보고 메시지도 따로 존재한다.

ping 명령어로 알 수 있는 IMCP 프로토콜과 IP 프로토콜과의 관계

  • ping 명령어로 (ICMP 프로토콜사용) IP 프로토콜의 데이터 내용을 MARK(설정)해 전송 가능
  • 따라서, ICMP 프로토콜은 IP 프로토콜을 제어, 사용한다고 할 수 있다.

ACL.pkt 실습

  • 인프라 담당자는 데이터 없는 상태에서 네트워크 인프라 작업한다.
  • 처음 목적지로 핑 명령어를 사용할 때, 1,2 번째 핑은 길을 개척하는 용도(테이블에 등록됨)로 사용되어 돌아오지 않을 수 있다.
  • 핑 명령어는 ICMP 프로토콜을 사용한다. ICMP 프로토콜은 핑 명령어를 사용할 때 IP 프로토콜 데이터 부분에 임시 데이터(garbage 값을 넣어)를 넣어 내보낸다. Reply – bytes는 에서 나타나는 임시 데이터이다.

ICMP Code

  • ICMP Header에 Type, Code MARK 값에 따라 ICMP 프로토콜 상태 확인 가능 (와이어샤크 툴에서 확인)

#5_Ethernet Frame 구조

  • 2계층 사용 PDU 인 프레임의 구조를 나타낸다.

  • Length PDU 값에 따라 Ethernet Frame 종류 2가지 존재.
    1. type 이면 = DIX Frame -> host(컴퓨터 등) 발생
    2. length 이면 IEEE 802.3 Frame -> 장비(스위치 등) 발생

  • 즉, 이더넷 망에서 두 종류의 프레임이 발생한다.

  • 패킷의 Ethernet – Type 확인 가능하다. 이는 호스트에서 발생(전송한) 패킷
  • Preamble SFD, CRC(오류검출 코드) 와이어샤크에서 생략한다
  • CRC(오류검출 코드)를 보는 방법. (와이어샤크에서는 생략하지만 설정으로 볼 수 있다.)

계층별 사용 프로토콜

  • L4 : TCP, UDP
  • L3 : IP, ICMP, ARP, RARP, IGMP(LAN 구간에서의 멀티캐스트 프로토콜)
  • L2 : Ethernet Frame 구조 ,ARP 프로토콜

#_6 ARP 프로토콜

  • ARP 패킷 종류는 2가지 있다.
    1. ARP Request Packet
    2. ARP Reply Packet

  • ARP 2가지 전송 방식 사용한다.
    1. 유니캐스트 방식 전송
    2. 멀티캐스트 방식 전송

  • SAP : Service Access Protocol : 서비스 접근 프로토콜

ARP Request Packet 확인 및 실습 파일

  • 위 사진에서 알 수 있는 것(ARP 세부도 확인 시)
  1. Type ARP : 해당 패킷은 ARP 프로토콜을 담고 있어요.
  2. ARP (request)를 확인해보면
  • Opcode request (1) 로 설정되어있다. 1 -> ARP request 의미한다.
  • [ Sender MAC, IP를 아는데, Target IP만 알고 MAC은 모르겠다 ] 전송의미이다.
  1. 2번의 내용을 브로드캐스트 방식으로 전송.

ARP 프로토콜

  • 내 컴퓨터에서 ARP Cache Table 확인 방법 : CMD – [ arp –a ]
  • ARP 프로토콜은 브로드캐스팅으로 주로 사용하지만, 유니캐스트로도 전송된다.
  • ARP 프로토콜의 취약점 : ARP Request를 보내지 않아도 ARP Reply를 확인 후 ARP Cache Table에 넣는다.
  • 기존의 ARP Cache Table 에 1. 10/4444 존재한다. 이는 기존 1.10/4444과 통신한 적이 있다는 것을 의미한다. 이후 1.10/1111 ARP Request 온다면 해당 요청 패킷으로부터 송신지 주소를 확인 후 (어? 나한테 온게 맞군. 내가 가진 테이블에는 이 IP에 해당하는 값이 있네? MAC 주소 업데이트한다.)
  • 한 컴퓨터에는 여러 LanCard 장착 가능 -> 여러 MAC 주소 보유 가능
  • LanCard 교체 후, 기존에 통신했던 서버들과 통신이 안될 수 있다. 이는 서버측에서 ARP CacheTable 의 정보가 변경되었기 때문이다.

ARP Request를 보내는 경우 2가지

  1. ARP Cache Table 최신화(갱신) 목적. (수신목적의 전송이 아님)
  2. ARP Reply를 받기 위해(수신지의 MAC 주소를 모를 때)

ping 명령어를 보내면, ARP Cache Table 이 갱신된다.

ARP 프로토콜 필드

  • Data Link 계층에서만 ARP 사용하는가?
    Network 계층에서도 사용 가능하다. ARP 프로토콜 필드에는 송/수신지의 MAC, IP 주소 필드가 존재하기 때문이다.
  • IP 주소 없이 사용 가능한가?
    사용 가능하다, FDDI, 토큰 링 같은 네트워크 기술에서는 ARP 프로토콜을 사용해 주소 문제를 해결한다.

  • Protoco Type : 0x0800 => ARP 프로토콜을 의미
  • Operation : 0x0001 => 해당 값이 1 : ARP Request 패킷임을 의미한다. (0x0002 : Reply)

ARP 실행 순서

  • 클라이언트 목표 : [ 1.20 ] IP 주소의 MAC 주소를 알아내고자 한다.
  • 스위치는 3계층 기능을 사용하는 네트워크 장비이다. (브로드캐스트 패킷을 받으면 플로딩한다)
  • 클라이언트의 ARP Cache Table에는 비어있다.
  1. 먼저 클라이언트는 ARP Cache Table을 조회한다. 그러나 해당 테이블은 공백이다.
  • 클라이언트는 ARP 프로토콜을 사용해 목표를 이루고자 한다.
  1. 클라이언트는 ARP Request 패킷을 Broadcast 전송한다. 스위치로 간 요청 패킷은 플로딩된다.
  • [ 1.30 ] IP 주소를 가진 클라이언트는 ARP Request를 받아 역캡슐화시켜 3계층의 헤더를 확인한다. 해당 요청은 [ 1.20 ] IP 주소를 가진 수신자의 것이므로, 해당 패킷을 폐기한다.
  • [ 1.20 ] IP 주소를 가진 클라이언트는 ARP Request를 받아 역캡슐화시켜 3계층의 헤더를 확인한다. 해당 요청은 [ 1.20 ] IP 주소를 가진 수신자의 것이므로, 먼저 송신지의 주소를 자신의 ARP Cache Table에 기록한다. 이후 자신의 IP, MAC 주소를 담은 ARP Response 패킷을 캡슐화시켜 클라이언트에게 전송한다.
    1. 클라이언트는 [ 1.20 ] 으로부터 ARP Response를 받아 자신의 ARP Cache Table에 저장한다.

ARP 진행 순서 세부

  • ARP 진행 순서에는 확인해야 할 4가지가 존재한다.
  1. ARP 프로토콜을 사용할 때는 먼저 본인의 ARP Cache Table을 조회 후 해당 테이블에 사용하고자 하는 주소가 없을 때 ARP Request 사용한다.
  2. ARP Request, ARP Response를 사용할때는 각 캡슐화/역캡슐화를 사용한다.
  3. ARP Request의 데이터 내부 구조

  1. ARP Request 메시지의 수신주소와 동일한 주소를 가진 호스트는 먼저 ARP Cache Table에 기록 후, ARP Response 전송한다.
profile
만두다섯개
磨斧爲針
이전 포스트

SK shieldus Rookies 16기 (네트워크 보안 #01)

다음 포스트

SK shieldus Rookies 16기 (네트워크 보안 #03)

0개의 댓글