1.패킷 헤더 크기가 매우 큰 경우 예상할 수 있는 문제점은 무엇인가요?
패킷 구성:
일반적으로 패킷(세그먼트, 프레임 포함)은 헤더와 페이로드로 구성됩니다.
헤더는 해당 계층의 제어 정보를 포함하고, 페이로드는 상위 계층에서 전달된 데이터를 포함합니다.
효율성 감소: 큰 헤더는 실제 데이터에 사용할 수 있는 공간을 줄여 전송 효율을 낮춥니다.
지연 증가: 각 네트워크 홉에서 처리 시간이 증가하여 지연이 커질 수 있습니다.
대역폭 사용 증가: 헤더가 페이로드보다 더 많은 대역폭을 소비하여 비용이 증가하고 비효율적
2.패킷에 헤더가 없으면 어떻게 되나요?
제어 정보 부족: 헤더가 없으면 출발지 및 목적지 주소와 같은 필수 제어 정보가 없어 네트워크를
통해 라우팅할 수 없습니다.
데이터 손실 가능성: 라우터와 스위치는 트래픽을 관리하기 위해 헤더 정보를 사용하므로,
헤더가 없으면 패킷이 잘못 라우팅되거나 손실될 수 있습니다.
3.손실된 패킷을 재전송하는 방법
타임아웃 기반 재전송:
패킷이 전송되고 나면, 송신자는 수신자로부터 확인 응답(ACK)을 기다립니다.
일정 시간 내에 ACK가 수신되지 않으면 송신자는 해당 패킷이 손실되었다고 판단하고 재전송
빠른 재전송:
수신자가 동일한 패킷에 대한 중복 ACK를 세 번 받으면, 송신자는 해당 패킷이 손실되었다고
가정하고 즉시 재전송합니다. 이는 타임아웃을 기다리지 않고 빠르게 손실된 패킷을 복구
4.TCP와 달리 UDP는 신뢰성 메커니즘을 제공하지 않지만, 여전히 인터넷에서 사용됩니다.
왜 사람들이 UDP를 사용할까요?
실시간 상호작용: 지연에 민감한 서비스에 적합합니다.
중복성을 포함하는 애플리케이션: 손실에 강한 애플리케이션에서 사용됩니다
5. 인터넷 서비스가 느려지는 원인
너무 많은 소스가 네트워크가 처리할 수 있는 것보다 너무 빠르게 많은 데이터를 전송할 때 발생
구체적으로, 트래픽 양이 링크 대역폭을 초과하면 큐가 쌓이고 지연이 증가하게 됩니다.
-노드 처리 지연 (Nodal Processing Delay)
-큐잉 지연 (Queuing Delay)
-전송 지연 (Transmission Delay)
-전파 지연 (Propagation Delay)
*캡슐화(Encapsulation) : 데이터가 네트워크를 통해 안전하고 정확하게 전달되도록 보장
출발지(Source):
데이터가 애플리케이션 계층에서 시작되어 각 계층을 거치면서 헤더가 추가됩니다.
각 계층은 다음과 같은 헤더를 추가합니다:
애플리케이션: 메시지(M)
전송(Transport): 세그먼트(Segment) 헤더(Ht)
네트워크(Network): 데이터그램(Datagram) 헤더(Hn)
링크(Link): 프레임(Frame) 헤더(H1)
스위치와 라우터:
스위치에서는 링크 계층까지의 헤더가 사용됩니다.
라우터에서는 네트워크 계층까지의 헤더가 사용됩니다.
목적지(Destination):
데이터는 목적지에 도달하면 각 계층에서 헤더를 제거하며 상위 계층으로 전달됩니다.
최종적으로 애플리케이션 계층에 도달하여 원래의 메시지(M)로 복원됩니다.
*큐잉(Queuing) - 큐잉 문제는 네트워크 혼잡의 원인
큐의 용량:
대기열(버퍼)의 이전 링크는 유한한 용량을 가지고 있습니다.
패킷 손실:
대기열이 가득 차면 도착하는 패킷은 버려집니다(손실됨).
손실된 패킷 처리:
손실된 패킷은 이전 노드, 송신자 끝 시스템에 의해 재전송되거나, 전혀 재전송되지 않을 수 있습니다.
*Generalized Forwarding(목적지 기반 포워딩)
라우터의 포워딩 테이블: 각 라우터는 포워딩 테이블(또는 플로우 테이블)을 가지고 있습니다.
이 테이블은 패킷을 어떻게 처리할지 결정하는 데 사용됩니다.
"매치 플러스 액션" 추상화:
도착한 패킷의 비트를 매칭하여 적절한 행동을 취합니다.
일반화된 포워딩에서는 여러 헤더 필드가 행동을 결정할 수 있습니다.
가능한 여러 행동:
패킷을 드롭(drop)
복사(copy)
수정(modify)
로그(log) 기록
*middleboxes: 네트워크 경로 상에서 일반적인 IP 라우터의 기능 외에 다른 기능을 수행하는 중간 장치
기능: 일반적인 라우터의 역할을 넘어서는 기능을 수행합니다.
위치: 네트워크 경로의 중간에 위치하여 데이터 흐름을 제어하거나 수정할 수 있습니다.
예시: 방화벽, NAT(Network Address Translation) 장치, 로드 밸런서 등이 있습니다.
*네트워크에서 다양한 중간 장치(Middlebox)의 역할과 위치
NAT (Network Address Translation): 가정, 셀룰러, 기관 네트워크에서 사용됩니다. IP 주소를 변환하여 네트워크 트래픽을 관리합니다.
Application-specific Middleboxes: 서비스 제공자, 기관, CDN(Content Delivery Network)에서 사용되며, 특정 애플리케이션의 요구에 맞춘 기능을 제공합니다.
Firewalls 및 IDS (Intrusion Detection Systems): 기업, 기관, 서비스 제공자 및 ISP에서 사용됩니다. 네트워크 보안을 강화하고 침입을 탐지합니다.
Load Balancers: 기업, 서비스 제공자, 데이터 센터 및 모바일 네트워크에서 사용됩니다. 트래픽을 여러 서버에 분산시켜 성능과 안정성을 향상시킵니다.
Caches: 서비스 제공자, 모바일 네트워크, CDN에서 사용되며, 데이터를 임시 저장하여 접근 속도를 높입니다
*SDN 및 NFV
왼쪽:
전통적 네트워크 구조:
L3 코어 스위치와 여러 방화벽(F/W)이 로비, 응급실, 수술실 등의 다양한 네트워크 구역에 배치되어 있습니다.
각 구역에 대해 개별적으로 방화벽이 설치되어 있어, 물리적 장비가 많이 필요합니다.
오른쪽:
SDN 및 NFV를 활용한 구조:
OpenFlow 컨트롤러: 중앙에서 네트워크 트래픽을 제어하고 관리합니다.
방화벽 풀(F/W pool): 물리적 방화벽 대신 가상화된 방화벽을 사용하여 유연성을 제공합니다.
서버 풀과 풀 메쉬 네트워크: 다양한 네트워크 장비와 서버가 가상화된 환경에서 효율적으로 연결됩니다.
OpenFlow 스위치: 각 층에 배치되어 중앙 컨트롤러와 통신하며, 네트워크 트래픽을 효과적으로 관리합니다.
IP datagram format
VER : IP 프로토콜의 버전을 의미(IP v4 : 0100, IP v6:0110) 4자리 비트로 이루어져있음
Head.len : 헤더의 길이를 알린다(어디서부터 어디까지가 paylad Data인지).
옵션이 없으면 20바이트 옵션이 최대로 추가되면 60바이트
type of serveice : 해당 Datagram의 지연, 우선순위, 신뢰성, 처리량 등의 정보를 담고 있다(8bit).
Total Length : 헤더와 데이터 부분을 합한 데이터그램의 전체 길이(16bit),65,535비트(64KB)를 넘지
못합니다
16-bit identifier, flags, fragment offset : 데이터의 길이가 전체 패킷 길이보다 길어 쪼개야
할 필요가 있을 때 각 패킷들 간의 순서 보장을 위한 부분이다.
이 때 쪼개는 작업을 fragmentation 이라고 한다.(목적지에서 마지막에 재조합한다는 것)
16-bit identifier(16비트) : 동일한 Identifier를 가진 조각들은 같은 원본 데이터그램에 속합니다.
수신 측에서 여러 데이터그램의 조각들이 섞여 있을 때,
어떤 조각들이 함께 재조립되어야 하는지 구분하는 데 사용됩니다.
flags(3비트) : 첫 번째 비트 (비트 0)
예약된 비트로, 항상 0으로 설정됩니다.
현재는 사용되지 않지만, 향후 사용을 위해 예약되어 있습니다.
두 번째 비트 (비트 1) - DF (Do not Fragment)
0: 조각화 허용
1: 조각화 금지
이 비트가 1로 설정되면, 데이터그램이 MTU보다 큰 경우에도 조각화되지 않습니다.
이 경우 라우터는 해당 데이터그램을 폐기하고 ICMP 오류 메시지를 송신자에게 보냅니다.
세 번째 비트 (비트 2) - MF (More Fragments)
0: 마지막 조각
1: 더 많은 조각이 있음
이 비트가 1로 설정되면, 현재 조각 뒤에 더 많은 조각이 있다는 것을 나타냅니다.
마지막 조각에서만 이 비트가 0으로 설정됩니다.
fragment offset(13비트) : 조각의 순서를 결정하는 데 사용됩니다.
각 조각이 원본 데이터그램에서 어느 위치에 해당하는지를 나타냅니다.
수신 측에서 이 값을 사용하여 조각들을 올바른 순서로 재배열합니다.
time to Live : 수명을 알려주는 필드(Datagram이 네이트워크 상에서 존재할수 있는
시간-떠도는 시간을 없애기 위해서)
upper Layer : 프로토콜에 대한 정보를 담고 있습니다(8bit), 대표적으로 UDP(17), TCP(6),
ICMP(1)을 사용합니다.
Header checksum : 헤더에 오류가 있는지 확인하기 위한 16비트로 이루어진 필드
Source/Destination Ip Address : 각각 32비트로 이루어지며 송신과 수신자의 IP주소가
기록되어 있습니다.
IP fragmentation / reassembly
원본 데이터그램
길이 (Length): 4000 바이트
식별자 (ID): 모든 조각에 동일한 값이 사용됩니다.
플래그 (Fragflag): 0 (조각화되지 않음)
오프셋 (Offset): 0 (조각화되지 않음)
조각화 후
첫 번째 조각
길이: 1500 바이트 (IP 헤더 20바이트 + 데이터 1480바이트)
플래그: 1 (추가 조각 있음)
오프셋: 0
두 번째 조각
길이: 1500 바이트 (IP 헤더 20바이트 + 데이터 1480바이트)
플래그: 1 (추가 조각 있음)
오프셋: 185 (1480바이트 / 8)
세 번째 조각
길이: 1040 바이트 (IP 헤더 20바이트 + 나머지 데이터 1020바이트)
플래그: 0 (마지막 조각)
오프셋: 370 (2960바이트 / 8)
설명
데이터그램은 MTU(1500 바이트)보다 크므로 조각화가 필요합니다.
각 조각은 IP 헤더를 포함하여 MTU를 초과하지 않도록 합니다.
각 조각은 원본 데이터그램의 특정 부분을 나타내며, 오프셋을 통해 순서를 결정합니다.
플래그는 추가 조각의 존재 여부를 나타내며, 마지막 조각에서는 플래그가 0으로 설정됩니다.
IP Datagram format
IP 주소
정의: 각 호스트(또는 라우터) 인터페이스에 할당된 32비트 식별자입니다.
표기법: 점으로 구분된 10진수 표기법을 사용합니다.
예를 들어, IP 주소 223.1.1.1은 이진수로 11011111 00000001 00000001 00000001로 표현됩니다.
인터페이스
정의: 호스트 또는 라우터와 물리적 링크 간의 연결을 의미합니다.
특징:
라우터는 일반적으로 여러 개의 인터페이스를 가집니다.
호스트는 일반적으로 하나 또는 두 개의 인터페이스를 가집니다(예: 유선 이더넷, 무선 802.11)
서브넷이란?
라우터를 거치지 않고 물리적으로 서로 연결될 수 있는 장치 인터페이스의 집합입니다.
같은 서브넷에 있는 장치는 공통의 상위 비트를 공유합니다.
IP 주소 구조
서브넷 부분: 같은 서브넷에 있는 장치들이 공유하는 고위 비트입니다.
호스트 부분: 나머지 저위 비트로, 개별 장치를 식별합니다.
서브넷 정의 방법
각 인터페이스를 호스트나 라우터에서 분리하여 고립된 네트워크 "섬"을 만듭니다.
이러한 고립된 네트워크를 서브넷이라고 합니다.
서브넷 마스크
예시에서는 서브넷 마스크가 /24로, 상위 24비트가 IP 주소의 서브넷 부분을 나타냅니다.
IP 주소 지정: CIDR
CIDR (Classless InterDomain Routing): IP 주소의 서브넷 부분에 임의의 길이를 허용합니다.
주소 형식: a.b.c.d/x 형태로, x는 서브넷 부분의 비트 수를 나타냅니다.
예시: 200.23.16.0/23는 서브넷 부분과 호스트 부분으로 나뉩니다
(200은 c클래이스이고 1비트가 하나도 없이 때문에 23이다)
*플러그 앤 플레이 : 컴퓨터 시스템이 사용자의 개입 없이 하드웨어를 자동으로 인식하고 설정할
수 있도록 하는 기술입니다
IP 주소 획득 방법
정적 할당 (Hard-coded):
시스템 관리자가 구성 파일(예: UNIX의 /etc/rc.config)에 IP 주소를 직접 설정합니다.
동적 할당 (DHCP):
**DHCP (Dynamic Host Configuration Protocol)**를 사용하여 서버로부터 IP 주소를
자동으로 할당받습니다.
"플러그 앤 플레이" 방식으로 쉽게 네트워크에 연결할 수 있습니다.
*DHCP
목적:
네트워크에 연결될 때 호스트가 네트워크 서버로부터 동적으로 IP 주소를 받습니다.
사용 중인 IP 주소의 임대를 갱신할 수 있습니다.
노트북과 같은 장치가 네트워크에 연결될 때 DHCP를 통해 IP 주소, 첫 번째 라우터의 주소,
DNS 서버의 주소를 자동으로 받습니다.
네트워크에 자주 연결하거나 떠나는 모바일 사용자에게 유용합니다.
DHCP 프로세스 개요(네트워크에 연결된 장치들이 자동으로 IP 주소를 할당받아 쉽게 통신할 수 있도록
합니다):
DHCP Discover: 호스트가 DHCP 서버를 찾기 위해 브로드캐스트 메시지를 전송합니다.
DHCP Offer: DHCP 서버가 사용 가능한 IP 주소를 제안하는 메시지를 보냅니다.
DHCP Request: 호스트가 제안받은 IP 주소를 요청하는 메시지를 보냅니다.
DHCP Acknowledgement (ACK): DHCP 서버가 요청을 승인하고 최종 확인 메시지를 보냅니다.
데이터 캡슐화:
DHCP 요청 메시지는 UDP, IP, 이더넷 프레임으로 캡슐화되어 전송됩니다.
이더넷 프레임은 네트워크 상에서 브로드캐스트됩니다.
DHCP 서버와 클라이언트
DHCP 서버: 네트워크에 연결된 모든 서브넷에 IP 주소를 할당합니다. 일반적으로 라우터와 함께
위치합니다.
DHCP 클라이언트: 네트워크에 새로 연결된 장치로, IP 주소가 필요합니다.
DHCP의 기능:
IP 주소 할당: 서브넷 내에서 클라이언트에게 IP 주소를 할당합니다.
라우터 주소: 클라이언트가 사용할 첫 번째 라우터(게이트웨이)의 주소를 제공합니다.
DNS 서버 정보: DNS 서버의 이름과 IP 주소를 제공합니다.
네트워크 마스크: 네트워크와 호스트 부분을 구분하는 서브넷 마스크를 제공합니다.
*NAT
NAT의 역할: 로컬 네트워크에 있는 모든 장치가 외부 세계와 통신할 때 하나의 공용 IPv4 주소를 공유하도록 합니다.
로컬 네트워크: 예시로 10.0.0.0/24 네트워크가 사용되고 있으며, 이는 사설 IP 주소 범위입니다.
데이터그램 처리: 로컬 네트워크 내에서 출발하거나 도착하는 데이터그램은 일반적으로 10.0.0.x 형식의 주소를 사용합니다.
NAT 장치: 이 장치는 로컬 네트워크에서 나가는 데이터그램의 소스 주소를 공용 IP 주소로 변환하여 외부로 보냅니다.
공용 IP 주소: 로컬 네트워크에서 나가는 모든 데이터그램은 138.76.29.7이라는 동일한 공용 IP 주소를 사용하지만, 서로 다른 소스 포트 번호를 사용합니다.
*장점:
IP 주소 절약: ISP로부터 하나의 공용 IP 주소만 필요합니다.
유연한 네트워크 관리: 외부 세계에 알리지 않고 로컬 네트워크 내 장치들의 IP 주소를 변경할 수 있습니다.
보안 강화: 외부에서 로컬 네트워크의 장치들을 직접 접근할 수 없습니다.
*NAT 작동 과정
데이터그램 전송:
호스트 10.0.0.1이 외부 서버 128.119.40.186의 포트 80으로 데이터그램을 보냅니다.
NAT 라우터 변환:
NAT 라우터는 데이터그램의 소스 주소를 10.0.0.1, 3345에서 138.76.29.7, 5001로 변경하고, 변환 테이블에 이 정보를 업데이트합니다.
응답 수신:
외부 서버로부터 응답이 도착하면, 목적지 주소는 138.76.29.7, 5001입니다.
데이터그램 전달:
NAT 라우터는 변환 테이블을 참조하여, 응답 데이터그램의 목적지 주소를 원래의 로컬 주소인 10.0.0.1, 3345로 변경하여 전달합니다.
*IPv4 && IPv6(32비트 IPv4 주소 공간이 완전히 할당될 것이라는 우려가 있어서 IPv6개발)
IPv4:
주소 크기: 32비트
주소 형식: 점으로 구분된 십진 표기법 (예: 192.168.1.1)
접두사 표기법: /24
주소 수: 약 43억 개
IPv6:
주소 크기: 128비트
주소 구조:
전체 128비트 중 첫 3비트는 주소 유형을 결정하는 데 사용됩니다.
나머지 125비트는 실제 주소 공간으로 사용됩니다.
주소 형식: 16진수 표기법 (예: fe80::94db:94e0:84de:129e)
접두사 표기법: /64
주소 수: 약 3.4×10^38개
IPv6 Datagram format
헤더 필드:
버전 (ver): IPv6의 버전을 나타냅니다.
우선순위 (priority): 데이터그램의 우선순위를 식별하여 흐름 내에서의 우선순위를 결정합니다.
흐름 레이블 (flow label): 동일한 흐름에 속하는 데이터그램을 식별합니다. 흐름의 개념은 아직 명확히 정의되지 않았습니다.
주소:
소스 주소: 128비트 IPv6 주소.
목적지 주소: 128비트 IPv6 주소.
기타 필드:
페이로드 길이 (payload len): 데이터그램의 페이로드 길이를 나타냅니다.
다음 헤더 (next hdr): 다음에 오는 헤더의 유형을 지정합니다.
홉 제한 (hop limit): 패킷이 네트워크를 통해 이동할 수 있는 최대 홉 수를 설정합니다.
IPv4와의 차이점
누락된 요소:
체크섬 없음: 라우터에서 처리 속도를 높이기 위해 제거되었습니다.
단편화 및 재조립 없음: IPv6에서는 이러한 기능을 지원하지 않습니다.
옵션 없음: 상위 계층에서 사용 가능하며, 다음 헤더에 포함됩니다.
IPv6 주소:
길이: 128비트
표기법: 16진수 숫자로 구성된 여덟 그룹으로 작성됩니다.
점으로 구분된 십진 표기법 없음: IPv4와 달리 점으로 구분된 형식이 없습니다.
축약 규칙:
모두 0인 그룹 생략: 연속된 0 그룹은 ::로 한 번만 생략할 수 있습니다.
선행 0 생략: 각 그룹의 선행 0을 생략할 수 있습니다.
주소 구조:
글로벌 프리픽스, 서브넷, 인터페이스 ID로 구성됩니다.
IPv6 줄이는 방법
Match-all address (모든 주소 일치):
IPv4의 0.0.0.0에 해당하는 IPv6 주소는 0000:0000:0000:0000:0000:0000:0000:0000이며, 이를 ::로 줄일 수 있습니다.
Loop-back address (루프백 주소):
IPv4의 127.0.0.1에 해당하는 IPv6 주소는 0000:0000:0000:0000:0000:0000:0000:0001이며, 이를 ::1로 줄일 수 있습니다.
정의: 물리적 표현이 없는 논리적 인터페이스를 식별하며 항상 활성 상태입니다.
기능: 루프백 주소로 전송된 패킷은 동일한 인터페이스로 반환됩니다. 주로 TCP/IP 네트워킹 스택을 테스트하는 데 사용됩니다.
IPv4에서의 루프백 주소:
127.0.0.0/8 범위가 루프백 주소로 예약되어 있으며, 일반적으로 127.0.0.1이 "localhost"로 사용됩니다.
IPv6에서의 루프백 주소:
0:0:0:0:0:0:0:1/128 또는 ::1/128이 루프백 식별자로 예약되어 있습니다.
All-nodes address (모든 노드 주소):
IPv4의 멀티캐스트 주소 224.0.0.1에 해당하는 IPv6 주소는 ff02:0000:0000:0000:0000:0001이며, 이를 ff02::1로 줄일 수 있습니다.
Random link-local address (랜덤 링크 로컬 주소):
예시로 주어진 IPv6 주소 fe80:0000:0000:0000:0f19:1faf:008:5010은 fe80::f19:1faf:8:5010으로 줄일 수 있습니다
IPv4 주소 유형
유니캐스트 (Unicast):
IPv6를 지원하는 노드의 단일 인터페이스를 식별합니다.
일대일 통신을 수행합니다.
링크 로컬 주소
특징:
링크 로컬 주소는 유니캐스트 주소의 일종으로, 인터페이스에서 자동 구성됩니다.
공통 링크에 연결된 노드들이 전역적으로 고유한 주소 없이 통신할 수 있도록 합니다.
멀티캐스트 (Multicast):
서로 다른 IPv6 노드에 속한 여러 인터페이스를 식별합니다.
일대다 통신을 수행합니다.
인터페이스 집합: 멀티캐스트 그룹으로 알려진 단일 멀티캐스트 주소로 식별될 수 있습니다.
IPv4에서의 멀티캐스트 주소:
주소 공간 224.0.0.0/24가 멀티캐스트 주소로 사용됩니다.
IPv6에서의 멀티캐스트 주소:
앞부분에 11111111(16진수 FF) 값이 멀티캐스트 주소를 나타냅니다.
모든 멀티캐스트 주소는 접두사 ff00::/8의 일부입니다.
잘 알려진 멀티캐스트 주소는 접두사 ff00::/12로 시작합니다.
중요 규칙:
멀티캐스트 그룹으로 전송된 패킷은 항상 유니캐스트 소스 주소를 가집니다.
멀티캐스트 주소는 패킷의 소스 주소로 사용할 수 없습니다.
애니캐스트 (Anycast):
서로 다른 IPv6 노드에 속한 여러 인터페이스를 식별합니다.
가장 가까운 노드와의 통신을 수행합니다. 여기서 "가장 가까운"은 일반적으로 IPv6 라우팅 프로토콜에 따라 가장 좋은 라우팅 메트릭을 가진 노드를 의미합니다.
브로드캐스트 주소 없음: IPv6에서는 브로드캐스트 주소가 사용되지 않습니다.
* IPv4와 IPv6의 터널링
터널링:
IPv6 데이터그램이 IPv4 데이터그램의 페이로드로 전송됩니다. 이는 "패킷 내의 패킷"으로 설명됩니다.
IPv4 라우터 사이에서 IPv6 패킷을 전송할 때 사용됩니다.
다른 용도:
터널링은 4G/5G와 같은 다른 문맥에서도 광범위하게 사용됩니다.
이미지 설명:
그림에는 IPv4 데이터그램 안에 포함된 IPv6 데이터그램의 구조가 시각적으로 표현되어 있습니다.
IPv4 헤더 필드, IPv6 헤더 필드, 그리고 UDP/TCP 페이로드가 표시되어 있습니다.
*터널링과 캡슐화
이더넷 연결: 두 IPv6 라우터를 연결하는 이더넷을 보여줍니다. 일반적으로 링크 계층 프레임의 페이로드로 데이터그램이 전송됩니다.
IPv4 네트워크 연결: 두 IPv6 라우터 사이의 IPv4 네트워크를 통해 터널링이 이루어집니다. IPv6 데이터그램이 IPv4 데이터그램에 캡슐화되어 전송됩니다.
구조 설명:
그림에서는 A에서 E로 이어지는 IPv6 라우터들이 표시되어 있으며, 중간에 IPv4 네트워크가 존재합니다.
이 과정에서 IPv6/v4 라우터가 사용되어 IPv6 데이터가 IPv4 네트워크를 통해 전달됩니다.
이더넷 연결: 두 IPv6 라우터(A와 E)를 직접 연결하는 경우, IPv6 데이터그램이 링크 계층 프레임의 페이로드로 전송됩니다.
IPv4 터널링: 두 IPv6 라우터 사이에 IPv4 네트워크가 있을 때, IPv6 데이터그램이 IPv4 데이터그램의 페이로드로 캡슐화되어 전송됩니다. 이는 "패킷 내의 패킷" 형태로 설명됩니다.
*Forwarding (데이터 전달)
패킷을 라우터의 입력 포트에서 적절한 출력 포트로 이동시키는 과정입니다. 이는 데이터 평면에서 이루어집니다.
*Routing (라우팅)
패킷이 출발지에서 목적지까지 가는 경로를 결정하는 과정입니다. 이는 제어 평면에서 이루어집니다.
*데이터 평면 (Data Plane)
로컬, 라우터별 기능:
각 라우터에서 개별적으로 작동합니다.
데이터그램 전송 결정:
라우터의 입력 포트에 도착한 데이터그램이 출력 포트로 어떻게 전달될지를 결정합니다.
*제어 평면 (Control Plane)
네트워크 전체 논리:
네트워크 전반에 걸쳐 데이터그램이 출발지에서 목적지까지 어떻게 라우팅될지를 결정합니다.
두 가지 제어 평면 접근법:
전통적 라우팅 알고리즘: 각 라우터에 구현됩니다.
소프트웨어 정의 네트워킹(SDN): 원격 서버(컨트롤러)에 구현됩니다.
Data plane과 Control Plane의 차이점
Data plane : 패킷의 전달에 초점을 맞추고 있으며 주로 빠른 처리를 위해 설계 되었다.
Control Plane : 네트워크 전반의 경로 최적화를 목표로 하며, 각 라우터가 상호작용하여 전체 경로를 계획합니다.
*네트워크 제어 평면 구조의 두 가지 접근 방식:
Per-router control (전통적인 방식): 각 라우터가 독립적으로 제어를 수행합니다.
Logically centralized control (SDN, 소프트웨어 정의 네트워킹): 논리적으로 중앙 집중화된 방식으로 제어를 수행합니다.
*Per-router control plane
개별 라우터 제어: 각 라우터에 있는 라우팅 알고리즘 구성 요소들이 제어 평면에서 상호작용합니다.
로컬 포워딩 테이블: 도착하는 패킷 헤더의 값을 기반으로 출력 포트를 결정합니다.
데이터 평면과 제어 평면: 데이터 평면은 실제 패킷 전달을 담당하고, 제어 평면은 라우팅 결정을 내립니다.
*Software-Defined Networking (SDN) 제어 평면
원격 컨트롤러: 네트워크의 중앙 집중식 제어 장치로, 라우터에 포워딩 테이블을 계산하고 설치합니다.
제어 평면과 데이터 평면: 제어 평면은 네트워크의 경로를 설정하고, 데이터 평면은 실제 패킷 전달을 처리합니다.
CA (Control Agent): 각 라우터에 배치되어 원격 컨트롤러와 통신하며, 포워딩 테이블을 업데이트합니다.
패킷 헤더 값: 도착하는 패킷의 헤더 값을 기반으로 경로를 결정합니다.
*Per-router control plane && Software-Defined Networking 차이점
Per-router Control Plane Software-Defined Networking (SDN)
각 라우터에 개별적으로 구현됨 중앙 집중식으로 관리됨 (컨트롤러)
독립적인 라우팅 결정 네트워크 전체의 논리적 관점에서 결정
복잡한 라우터 설정 필요 컨트롤러에서 네트워크 정책 관리 가능
변화에 대한 적응이 느림 빠르고 유연한 네트워크 구성 가능
*데이터그램을 송신자에서 수신자로 전송하는 "채널"에 대한 서비스 모델
개별 데이터그램 서비스 예시:
보장된 전달: 데이터그램이 반드시 목적지에 도달하도록 보장.
40ms 이하 지연으로 보장된 전달: 특정 시간 내에 전달을 보장.
데이터그램 흐름에 대한 서비스 예시:
순서대로 데이터그램 전달(순서화 패킷 전달): 데이터그램이 전송된 순서대로 도착.
최소 대역폭 보장: 특정 대역폭을 유지.
패킷 간 간격 변화 제한: 패킷 전송 간격을 일정하게 유지.
보안서비스
Best Effort 서비스 모델:
보장 없음: 데이터그램이 목적지에 성공적으로 전달될 것이라는 보장이 없습니다.
타이밍 및 순서 보장 없음: 데이터그램의 전달 시간이나 순서에 대한 보장이 없습니다.
대역폭 보장 없음: 종단 간 흐름에 사용 가능한 대역폭에 대한 보장이 없습니다
*사용하는 이유
단순성과 유연성: 복잡한 품질 보장 없이도 다양한 네트워크 환경에서 작동할 수 있습니다.
비용 효율성: 추가적인 품질 보장 메커니즘 없이 운영되므로 비용이 절감됩니다.
확장성: 다양한 규모의 네트워크에서 쉽게 적용할 수 있습니다
충분한 대역폭 제공: 실시간 애플리케이션의 성능을 대부분의 경우 "충분히 좋게" 유지합니다.
복제된 분산 서비스: 데이터 센터와 콘텐츠 배포 네트워크가 클라이언트 네트워크와 가까운 위치에서 서비스를 제공합니다.
혼잡 제어: 탄력적인 서비스의 혼잡 제어가 도움이 됩니다.
*룩업 : 라우터가 패킷을 올바른 출력 포트로 전달하기 위해 사용하는 과정으로,
라우팅 테이블에서 목적지 주소에 해당하는 정보를 검색하는 것을 의미
라우터 내부
입력 포트 (Router Input Ports):
들어오는 물리적 링크를 종료하는 물리 계층 기능을 수행합니다.
데이터 링크 계층 기능을 수행하여 들어오는 링크의 다른 쪽과 상호 운용합니다.
패킷을 스위칭 패브릭으로 전달하기 위해 "룩업" 및 포워딩 기능을 수행합니다
라인 종료 (Line Termination):
물리 계층에서 비트 수준의 수신을 처리합니다.
링크 계층 프로토콜 (Link Layer Protocol):
이더넷과 같은 링크 계층 프로토콜을 사용하여 수신 데이터를 처리합니다.
룩업 및 포워딩 (Lookup, Forwarding):
패킷의 헤더 필드 값을 사용하여 입력 포트 메모리에 있는 포워딩 테이블에서 출력 포트를 찾습니다.
"매치 플러스 액션" 방식으로 동작하며, 입력 포트 처리를 라인 속도에서 완료하는 것이 목표입니다.
*매치 플러스 액션 : 데이터그램 헤더값과 매치 조건 사이의 매치를 기반으로 라우터가
데이터그램을 전달하고 조작하는 방법을 명시한다.
사용 예시 : 포워딩, 로드 밸런싱, 방화벽
매치 (Match):
들어오는 패킷의 헤더 필드를 검사하여 특정 조건과 일치하는지를 확인합니다.
예를 들어, 목적지 IP 주소, 소스 IP 주소, 포트 번호 등이 포함될 수 있습니다.
액션 (Action):
매치된 패킷에 대해 미리 정의된 작업(포워딩, 삭제, 필드 수정)을 수행합니다.
큐잉 (Queueing):
데이터그램이 스위칭 패브릭으로 전달되는 속도보다 빠르게 도착할 경우 입력 포트에서
큐잉을 수행합니다.
입력 큐잉:
스위칭 구조의 패킷 처리 속도가 입력 포트의 패킷 도착 속도보다 느릴 때 발생합니다.
입력 포트에서 스위칭 패브릭으로 패킷을 전달할 수 없을 때, 패킷은 대기열에 저장됩니다.
출력 큐잉:
여러 입력 포트에서 동일한 출력 포트로 패킷이 동시에 전송될 때 발생할 수 있습니다.
출력 포트는 한 번에 하나의 패킷만 전송할 수 있기 때문에 대기열이 형성됩니다.
출력 포트 (Router Output Ports):
스위칭 패브릭에서 받은 패킷을 저장하고, 이를 나가는 링크로 전송합니다.
입력 포트와 반대의 데이터 링크 및 물리 계층 기능을 수행합니다.
고속 스위칭 패브릭 (High-Speed Switching Fabric):
네트워크 노드로 들어오는 데이터를 올바른 포트로 이동시켜 다음 네트워크 노드로 전달하는
하드웨어 및 소프트웨어의 조합입니다.
패킷 전송:
입력 링크에서 출력 링크로 패킷을 전송하는 역할을 합니다.
* 세 가지 주요 스위칭 패브릭 유형:
메모리 기반 교환(Memory-Based):
패킷이 메모리에 저장된 후, CPU가 이를 처리하여 올바른 출력 포트로 전송합니다.
첫 세대 라우터:
전통적인 컴퓨터 구조를 기반으로 하며, CPU의 직접 제어 하에 스위칭이 이루어졌습니다.
패킷 처리:
패킷이 시스템 메모리에 복사됩니다.
CPU가 패킷을 처리하여 적절한 출력 포트로 전달합니다.
속도 제한:
메모리 대역폭에 의해 제한됩니다.
각 데이터그램 당 두 번의 버스 교차가 발생하여 속도가 느려질 수 있습니다
(속도는 메모리 bandwidth에 의해 제한된다)_.
버스 기반 교환 (Bus-Based)(스위칭 속도는 버스의 bandwidth에 의해 제한):
모든 포트가 공통 버스를 통해 연결되며, 버스를 통해 패킷이 전송됩니다.
데이터그램 전송:
입력 포트 메모리에서 출력 포트 메모리로 데이터그램이 공유 버스를 통해 전달됩니다.
버스 경쟁 (Bus Contention):
동시에 여러 패킷이 다른 입력 포트로 라우터에 도착하면 한번에 하나의 패킷만
버스를 통과할 수 있기 때문에 하나를 제외한 모든 패킷은 대기함.
스위칭 속도는 버스의 대역폭에 의해 제한됩니다.
상호연결 네트워크를 통한 교환(Interconnection Network)(bus bandwidth의 제약을 극복)
-대규모 데이터 센터나 고성능 네트워크 환경에서 효율적인 데이터 처리를 가능
복잡한 네트워크 구조를 사용하여 다수의 포트를 연결하고, 병렬로 패킷을 처리합니다.
크로스바 및 클로스 네트워크:
크로스바는 3x3 구조를 보여주며, 각 입력이 각 출력과 직접 연결될 수 있습니다.
다단계 스위치 (Multistage Switch):
여러 작은 스위치 단계를 통해 n x n 스위치를 구성합니다
(N개의 입력 포트를 N개의 출력 포트에 연결).
그림에서는 8x8 다단계 스위치가 작은 크기의 스위치로 구성된 예시를 보여줍니다.
병렬 처리 탐색:
여러 스위칭 플레인을 병렬로 사용하여 속도와 확장성을 향상시킵니다.
데이터그램을 고정 길이 셀로 분할하여 입력합니다.
기본 네트워크를 통해 셀을 전환하고, 출력에서 데이터그램을 재조립합니다.
*라우팅 프로세서 (Routing Processor):
라우팅 프로토콜을 실행하고 라우팅 정보 및 포워딩 테이블을 유지합니다.
라우터 내에서 네트워크 관리 기능도 수행합니다.
inside a routerinput port
*입력 포트 큐잉
출력 포트 경합:
왼쪽 그림에서는 여러 입력 포트에서 동일한 출력 포트로 전송하려는 데이터그램이
있을 때 발생하는 문제를 보여줍니다. 출력 포트로는 한 번에 하나의 데이터그램만
전송할 수 있기 때문에, 아래쪽의 빨간색 패킷이 차단됩니다.
헤드-오브-라인(HOL) 차단:
오른쪽 그림에서는 HOL 차단 문제를 설명합니다. 앞줄에 있는 패킷이 전송되지 못하면 그 뒤에
있는 패킷도 전송되지 못하는 상황을 나타냅니다. 여기서는 초록색 패킷이 차단됩니다.
스위치 패브릭의 속도:
스위치 패브릭이 입력 포트의 합보다 느리면, 입력 큐에서 큐잉이 발생할 수 있습니다.
이로 인해 입력 버퍼 오버플로우로 인한 지연 및 손실이 발생할 수 있습니다.
HOL 차단:
큐의 앞부분에 있는 데이터그램이 다른 데이터그램의 이동을 방해합니다.
이는 네트워크 성능 저하의 원인이 될 수 있습니다.
*출력 포트 큐잉
버퍼링:
스위치 패브릭에서 데이터그램이 링크 전송 속도보다 빠르게 도착할 때 필요합니다.
버퍼가 부족할 경우 어떤 데이터그램을 드롭할지 결정하는 드롭 정책이 필요합니다.
혼잡과 버퍼 부족으로 인해 데이터그램이 손실될 수 있습니다.
스케줄링 규율:
전송을 위해 대기 중인 데이터그램 중에서 선택합니다.
우선순위 스케줄링은 누가 최고의 성능을 받을지와 네트워크 중립성에 영향을 미칩니다.
추가 설명
버퍼 오버플로우:
도착률이 출력 라인 속도를 초과할 때 버퍼링이 발생합니다.
출력 포트 버퍼 오버플로우로 인해 지연 및 손실이 발생할 수 있습니다.
큐(Queue): 패킷이 대기하는 영역입니다.
링크(Link): 패킷이 전송되는 서버 역할을 합니다.
*버퍼 관리:
드롭(Drop):
버퍼가 가득 찼을 때 어떤 패킷을 추가할지 또는 드롭할지를 결정합니다.
테일 드롭(Tail Drop): 도착한 패킷을 드롭하는 방식입니다.
우선순위(Priority): 우선순위에 따라 패킷을 드롭하거나 제거합니다.
마킹(Marking):
혼잡을 신호하기 위해 어떤 패킷을 마킹할지를 결정합니다.
예를 들어, ECN(Explicit Congestion Notification)이나 RED(Random Early Detection) 방식
*패킷 스케줄링:
네트워크에서 어떤 패킷을 다음으로 전송할지 결정하는 과정입니다.
스케줄링 기법:
선입선출(First Come, First Serve, FCFS): 가장 먼저 도착한 패킷을 먼저 처리합니다.
우선순위(Priority): 패킷의 중요도에 따라 우선순위를 부여하여 처리합니다.
라운드 로빈(Round Robin): 각 패킷을 순차적으로 처리하여 공정성을 유지합니다.
가중치 공정 큐잉(Weighted Fair Queuing): 각 흐름에 가중치를 부여하여 공정하게 처리합니다.
선입 선출 스케줄링: FCFS (First Come, First Serve)
패킷이 도착한 순서대로 출력 포트로 전송됩니다.
우선순위 스케줄링(Priority)
도착하는 트래픽을 클래스별로 분류하고 큐에 저장합니다.
패킷의 헤더 필드를 사용하여 분류할 수 있습니다.
높은 우선순위 큐에 있는 패킷을 먼저 전송합니다.
각 우선순위 클래스 내에서는 FCFS(First Come, First Serve) 방식으로 처리됩니다.
큐 구조:
높은 우선순위 큐와 낮은 우선순위 큐로 나뉘어 있습니다.
도착한 패킷은 우선순위에 따라 적절한 큐에 저장됩니다.
높은 우선순위의 패킷이 먼저 처리됩니다.
라운드 로빈(Round Robin) 스케줄링
도착하는 트래픽을 클래스별로 분류하여 큐에 저장합니다.
패킷의 헤더 필드를 사용하여 분류할 수 있습니다.
서버는 주기적으로 각 클래스 큐를 스캔하며,
각 클래스에서 하나의 완전한 패킷을 차례로 전송합니다.
큐 구조:
여러 색상의 큐가 있으며, 각 색상은 다른 클래스의 트래픽을 나타냅니다.
서버는 각 큐를 순환하며, 각 큐에서 하나씩 패킷을 선택하여 전송합니다.
가중치 공정 큐잉(Weighted Fair Queuing, WFQ)
일반화된 라운드 로빈 방식으로, 각 트래픽 클래스에 가중치를 부여하여 공정하게 처리합니다.
각 트래픽 클래스별로 최소 대역폭을 보장합니다.
큐 구조:
여러 큐가 있으며, 각각의 큐는 다른 트래픽 클래스를 나타냅니다.
각 큐는 해당 클래스의 가중치에 따라 서비스됩니다.
1.세션 작동 방식
-> 세션 데이터 자체는 서버에 저장
-> 클라이언트(브라우저)에는 세션 ID가 쿠키(connect.sid)로 저장
2.세션 저장소가 아닌 왜 쿠키에 저장이 되는가?
-> 브라우저에서 쿠키를 확인하면 세션 ID가 보인다
-> 세션 데이터 자체는 서버에 저장되고 세션 ID만 클라이언트 측의 쿠키에 저장(클라이언트가 세션 데이터에 직접 접근하거나 조작할 수 없게 되어 보안이 강화)
-> 서버는 세션 ID를 통해 해당 세션 데이터를 찾아서 사용할 수 있습니다
3. 세션 저장소
-> 기본적으로는 nest.js는 메모리에 세션을 저장하기 떄문에 서버를 재시작하면 모든 세션 데이터가 사라진다.
4. 장점
-> 쿠키는 HTTP 요청에 자동으로 포함되어 전송됩니다. 클라이언트가 서버에 요청을 보낼 때마다 세션 ID를 명시적으로 포함시키지 않아도 되므로, 세션 ID를 쿠키에 저장하는 것이 더 편리합니다.
#세션을 직접 실행하기 전에
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import * as session from "express-session";
import { ValidationPipe } from '@nestjs/common';
async function bootstrap() {
const app = await NestFactory.create(AppModule);
app.useGlobalPipes(new ValidationPipe({ transform: true}));
app.use(
session({
secret: "당신이 원하는 문자열", ex)"ABCD"// 세션 ID 쿠키에 서명하는 데 사용되는 비밀 키입니다
resave: false, //세션이 수정되지 않았더라도 강제로 다시 저장할지 여부를 설정합니다. false로 설정하면 세션이 변경되지 않았을 때 저장을 건너뛰어 성능을 향상시킵니다
saveUninitialized: false, //초기화되지 않은 세션을 저장소에 저장할지 여부를 설정합니다. false로 설정하면 세션이 필요하기 전까지는 쿠키를 클라이언트에 전송하지 않습니다.
cookie: {
secure: false, // HTTPS를 통해서만 쿠키를 전송할지 여부를 설정합니다. 현재 false로 설정되어 있어 HTTP에서도 쿠키를 전송합니다. 프로덕션 환경에서는 true로 설정하는 것이 좋습니다.
// maxAge: 1000 * 60 * 60 * 24, // 쿠키 유효 기간 1일 (밀리초 단위)
maxAge: 60000, // 쿠키의 유효 기간을 밀리초 단위로 설정합니다
sameSite: 'strict' // 크로스 사이트 요청에 대한 쿠키 전송 정책을 설정합니다. 'strict'는 같은 사이트의 요청에만 쿠키를 전송합니다. 가장 엄격한 설정입니다
}
}),
);
app.enableCors({
origin: true,
methods: 'GET,HEAD,PUT,PATCH,POST,DELETE',
allowedHeaders: 'Content-Type, Accept , Authorization , X-XSRF-TOKEN',
credentials: true,
});
await app.listen(4000);
}
bootstrap();
을 설정해준다
controller에서 session을 사용할려면 @nestjs/common에서 Session을 사용해야한다
ex)import { Session } from '@nestjs/common';
#1번에 대한 설명
#일반적인 Cookie로 클라이언트에 설정했을시
1-1(사진) 사진과 같이 현재 cookie 값에 아무것도 없는 상황이다.
#nest.js
@Post('cookielogin')
async cookielogin(@Req() req: Request, @Res() res: Response, @Body() createauth : CreateAuthDto) {
console.log(createauth)
res.cookie('connect.sid', createauth.ID, { path: '/' }); // createauth.ID를 클라이언트 connect.sid(다르게 해도 됨)라는 이름으로 설정
res.send('Login successful');
}
에 먼저 쿠키로 값을 설정해보겠습니다(세션이 아닌 쿠키) CreateAuthDto는 username(Id)와 password를 입력받는다.
현재 username : HELLO 를 입력하였다.
결과 : 1-2(사진)과 같이 일반적으로 쿠키로 설정하면 그냥 암호화가 안되고 Hello가 출력되는 걸 볼수있다(보안적으로 안좋다).
#세션을 이용해 세션 ID를 설정했을시
1-1(사진) 사진과 같이 현재 cookie 값에 아무것도 없는 상황이다.
#nest.js
@Post('sessionlogin')
async sessionlogin(@Body() loginData: { username: string; password: string },@Session() session: Record<string, any>) {
// 여기서 실제로는 데이터베이스에서 사용자 확인 등의 로직이 들어가야 합니다.
if (loginData.username && loginData.password ) {
session.userId = 1; // 사용자 ID를 세션에 저장
session.username = loginData.username; // 사용자 이름을 세션에 저장
// 비밀번호 대신 로그인 상태를 나타내는 플래그를 저장
session.isLoggedIn = true;
return { message: 'Logged in successfully' };
} else {
return { message: 'Invalid credentials' };
}
}
에 먼저 세션으로 값을 설정해보겠습니다(쿠키가 아닌 세션) username에 똑같이 HELLO를 입력했는데
1-3(사진)과 같이 암호화(?) 되어 connect.sid라는 이름으로 쿠키에 저장된 세션 ID를 확인할수 있다.
(쿠키는 이름을 설정한 반면에 세션은 이름을 설정안해도 connect.sid라는 이름으로 자동 설정된다)
결과적으로 Cookie를 사용했을때보다 세션 ID를 사용하면 보안측면에서도 좋다.
1-11-21-3
#2번에 대한 설명
#nest.js
@Get('check-session')
checkSession(@Session() session: Record<string, any>) {
console.log('Session data:', session);
return { isLoggedIn: session.isLoggedIn || false };
}
데이터는 서버에 저장되는걸 확인하는 코드이다.
1-1(사진)과 같이 로그인을 안했을떄는 cookie값에 아무것도 없으니 1-4(사진)과 같이 세션 정보만 출력된다.
하지만 1-3(사진)과 같이 로그인을 했을떄는 cookie값에 세션 ID가 있으니 1-5(사진)과 같이 사용자에 대한 정보를 같이 출력한다.
(1번에 대한 설명을 보면 #3 개를 설정하여서 3개가 나오는걸 볼수 있다.
session.userId = 1; // 사용자 ID를 세션에 저장
session.username = loginData.username; // 사용자 이름을 세션에 저장
session.isLoggedIn = true; // 비밀번호 대신 로그인 상태를 나타내는 플래그를 저장)
결과적으로 암호화(?)된 세션 ID만 cookie에 저장되고 데이터는 서버에 저장된다(자동 로그인에 사용할수있다)
1-41-5
#4번에 대한 설명
쿠키 값을 설정하면 클라이언트에서 인증을 할때마다 코드를 추가하여서 데이터를 같이 보내야하는거 아니에요? 라는 생각이 들수있다.
#React.js
const check = async(event) => {
event.preventDefault();
const response = await fetch("http://localhost:4000/auth/check-session", { method: "GET", headers: { "Content-Type": "application/json" }, credentials: 'include' });
if (!response.ok) {
throw new Error("Fetch is not");
}
const resData = await response.json();
console.log(resData)
}
#credentials: 'include'의 의미
credentials: 'include'를 설정하면,
요청을 보낼 때 항상 쿠키, HTTP 인증 정보(예: 기본 인증, 다이제스트 인증), 및 TLS 클라이언트 인증 정보를 포함시킵니다. 이를 통해 클라이언트와 서버 간의 인증된 상태를 유지할 수 있습니다.
예를 들어, 사용자가 로그인한 상태에서 서버에 요청을 보낼 때 이 옵션을 사용하면 세션 쿠키를 포함하여 요청할 수 있습니다.
위 코드와 같이 요청을 보낼떄 credentials: 'include'적어주면 쿠키값도 요청을 해 check-session(2번 설명 api)을 사용할수있다
만약에 credentials: 'include'를 요청을 할떄 적어 주지않으면 1-4(사진)과 같이 세션 정보만 출력한다
#그 외 설명
1번 설명에 있는 api(sessionlogin)를 호출할때도 credentials: 'include'를 설정해주어야지 클라이언트에 세션 ID가 설정된다.
credentials: 'include'설정을 안해주면 1-3(사진)과 같이 cookie값이 설정이 안된다 1-1(사진)과 같이 빈 쿠키 화면을 볼수있다.
#React.js(sessionlogin api호출)
const sessionLogin = async(event) => {
event.preventDefault();
const response = await fetch("http://localhost:4000/auth/sessionlogin", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ username: username, password: password }), credentials: 'include' });
if (!response.ok) {
throw new Error("Fetch is not");
}
const resData = await response.json();
console.log(resData)
}
#logout에 대한 코드
#React.js
const sessionlogout = async(event) =>{
event.preventDefault();
const response = await fetch("http://localhost:4000/auth/check-session", { method: "GET", headers: { "Content-Type": "application/json" }, credentials: 'include' });
if (!response.ok) {
throw new Error("Fetch is not");
}
const resData = await response.json();
console.log(resData)
}
logout을 할떄도 credentials: 'include' 설정을 해서 쿠키값을 삭제해준다
#nest.js
@Get('logout')
async logout(@Session() session: Record<string, any>, @Res() response: Response) {
return new Promise<void>((resolve, reject) => {
session.destroy((err) => {
if (err) {
response.status(500).json({ message: 'Logout failed' });
reject(err);
} else {
response.clearCookie('connect.sid'); // 세션 쿠키 삭제
response.status(200).json({ message: 'Logged out successfully' });
resolve();
}
});
});
}
1.session.destroy() 메서드:
이 메서드는 현재 세션을 파괴합니다.
세션 저장소에서 해당 세션 데이터를 삭제합니다.
2.Promise 사용:
session.destroy()는 콜백 기반이므로, Promise로 감싸 비동기 처리를 합니다.
성공 시 resolve(), 실패 시 reject(err)를 호출합니다.
3.쿠키 처리:
session.destroy()는 세션 데이터만 삭제하고, 직접적으로 클라이언트의 쿠키를 삭제하지 않습니다.
그러나 express-session 미들웨어는 보통 이 작업 후 자동으로 세션 ID 쿠키를 무효화합니다.
DDos(Distributed Denial-of-Service, 분산 서비스 거부) Attack
개요
: 여러 대의 공격자를 분산적으로 배치해 동시에 서비스 거부 공격을 하는 방법이다
hping3의 포트스캔을 이용한 DDoS attack
:개요
-> 방화벽을 테스트하고 포트 스캔 테스트를 하며 TCP/IP 스택을 테스트하고 가동 시간을 추출하는 기능 즉, 필요한 포트를 추출한다.
-> 실습환경
: Network Adapter : HostOnly
: Kali : 192.168.10.128 / C class / 192.168.10.129 / 192.168.10.129
: CentOs : 192.168.10.129 / C class /192.168.10.129 / 192.168.10.128, 192.168.10.131
: Windows 10 : 192.168.10.131 / C class / 192.168.10.129 / 192.168.10.129
; Kali와 windows10에서 네임 서버 조회가 모두 되어야한다.
:hping
: 사용법
-> hping3 [옵션] <target Ip Address>
: 실습 1. kali -> Dns Server
: 개요
-> 동기 신호(Sync)후 반송(Sync/Ack)되면 TCP가 완료된고 다시 전송을 위한 연결 준비 상태(RST)로 전환된다.
: 명령 실행
->
: 패킷 분석
No. Time Source Destination Protocol Length Info
3 0.019233546 192.168.10.128 192.168.10.129 TCP 54 1320 → 80 [SYN] Seq=0 Win=512 Len=0
4 0.019766613 192.168.10.129 192.168.10.128 TCP 60 80 → 1320 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460
5 0.019793594 192.168.10.128 192.168.10.129 TCP 54 1320 → 80 [RST] Seq=1 Win=0 Len=0 -> 다음 포트를 스캐닝하기 위한
6 1.019586748 192.168.10.128 192.168.10.129 TCP 54 1321 → 80 [SYN] Seq=0 Win=512 Len=0
7 1.020220431 192.168.10.129 192.168.10.128 TCP 60 80 → 1321 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460
8 1.020262363 192.168.10.128 192.168.10.129 TCP 54 1321 → 80 [RST] Seq=1 Win=0 Len=0
9 2.019842794 192.168.10.128 192.168.10.129 TCP 54 1322 → 80 [SYN] Seq=0 Win=512 Len=0
10 2.020318592 192.168.10.129 192.168.10.128 TCP 60 80 → 1322 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460
11 2.020357113 192.168.10.128 192.168.10.129 TCP 54 1322 → 80 [RST] Seq=1 Win=0 Len=0
12 3.020001036 192.168.10.128 192.168.10.129 TCP 54 1323 → 80 [SYN] Seq=0 Win=512 Len=0
13 3.020286898 192.168.10.129 192.168.10.128 TCP 60 80 → 1323 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460
14 3.020309683 192.168.10.128 192.168.10.129 TCP 54 1323 → 80 [RST] Seq=1 Win=0 Len=0
15 4.023044626 192.168.10.128 192.168.10.129 TCP 54 1324 → 80 [SYN] Seq=0 Win=512 Len=0
16 4.023320860 192.168.10.129 192.168.10.128 TCP 60 80 → 1324 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460
17 4.023341689 192.168.10.128 192.168.10.129 TCP 54 1324 → 80 [RST] Seq=1 Win=0 Len=0
실습 2. kali -> windows 10
:개요
->
: 패킷 분석
-> 포트를 별도로 지정하지 않은 상태에서는 Sync만 전송
-> 포트를 별도로 추가만 했고 실제 서비스는 활성화 되어 있지 않기 때문이다.
3 0.000480294 192.168.10.128 192.168.10.131 TCP 54 2305 → 80 [SYN] Seq=0 Win=512 Len=0
4 1.000311691 192.168.10.128 192.168.10.131 TCP 54 2306 → 80 [SYN] Seq=0 Win=512 Len=0
43 2.001065085 192.168.10.128 192.168.10.131 TCP 54 2307 → 80 [SYN] Seq=0 Win=512 Len=0
46 3.001319161 192.168.10.128 192.168.10.131 TCP 54 2308 → 80 [SYN] Seq=0 Win=512 Len=0
49 4.001547310 192.168.10.128 192.168.10.131 TCP 54 2309 → 80 [SYN] Seq=0 Win=512 Len=0
:실습 3 포트 스캔(열려있는 포트와 닫혀 잇는 포트 검색)
: 명령 실행
-> sudo hping3 --scan 1-1024 -S 192.168.10.129
-> 다음과 같은 오류(*** buffer overflow detected ***: terminated가 발생하면 방화벽을 중지(systemctl stop firewalld)하도록한다
: 분석
:닫혀 잇는 포트:(SYN,ACK)가 없다
:열려 있는 포트:(SYN,ACK)가 있다
실습 4. 공격 대상 시스템에 무작위 IP 주소를 보낸다
-> 명령 실행
:hping3 --rand-source 192.168.10.129 -p 1-1024 -S --flood
: --rand-source (무작위)
: 192.168.10.129(대상 IP)
: -p 1-1024(스캐닝할 포트)
: -S(TCP flag SYN)
: --flood(플로딩)
실습 5.네트워크 패킷 확인(스니핑 도구(tcpdump)을 이용한 확인)
-> 테스트1. CentOs로의 테스트
:명령어 실행후 "top" 명령을 이용해서 리소스 상태를 확인한다
-> 테스트 1. Windows10의 테스트
:
실습 6. 기타 공격 기법
:Sync flooding Acctack
: TCP Session을 연결하는 과정에서 Sync 패킷을 많이 보내서 자원을 고갈시키는 공격
-> helping3 192.168.10.129 -S -i u40 -c 50
:Land Attack
: 공격 대상의 IP를 Sourc IP로 설정해서 루프를 유발시키고 공격효과를 극대화 시키는 공격
-> helping3 192.168.10.129 -a 192.168.10.129 -S -i u40 -c 50
:Smurf Attack
: Source Ip를 변경하고 다이렉트 브로드 캐스트를 사용하여 ICMP echo reply 신호를 많이 받아서 부하를 일으키게 하는 공격
-> helping3 192.168.10.255 -a 192.168.10.129 -S -c 50
Sniffing과 Spoofing
ARP spoofing 보안 조치
-> 시스템 측면
: MAc address를 ARP table에 정적을 등록, 관리하도록 해야한다.
: 시스템의 보안 수준을 강화해야 한다. 즉, 의심될만한 프로그램 설치는 절대 지양한다.
: 보안 서버을 적극 활용한다
-> 네트워크 장비 측면
: Mac flooding 제어 및 정적인 Mac address관리
: 시스코 장비의 경우 ARP Inspection
: VLan으로 격리운용
Sniffing
: 개요
-> 네트워크 상에서 자신이 아닌 다른 상대방드르이 패킷 교환을 훔쳐보는 행위
: 종류
-> Passive Sniffing
-> Hub(Switch)와 같이 모든 노드에 동일한 전기적 신호(ㄷ오기신호)가 복제되는 경우네는 단수히 스니퍼만 동작시켜도 모든 패킷을 잡아낼수가 있다.
-> Active Sniffing
-> Switch 환경에서는 해당 포트로만 데이터가 전송되기 때문에 데이터 신호를 스니퍼가 설치된 스셑ㅁ에 경유하도록 유도하는 방법을 말한다.
Spoofing
: 개요
-> Sniffing 공격의 대표적 기술을 말한다
-> 외부의 악의적인 네트워크 침입지가 웹사이트를 구성한 후 사용자들의 방문을 유도하고 인터넷 프로토콜 TCP/IP(공용 프로토콜)의 구조적 결함을 이용해서 사용자의 스셑ㅁ 권한을 획득한 뒤 정보를 뺴가는 해킹 기법을 말한다.
-> 잘 알려진 기업의 명의로 스팸 메일을 발송하거나 위조 사이트로 접속을 유도하는 기술과 로그인 하려는 컴퓨터가 허가 받은 IP를 도용해서 로그인하는 기법 등을 총칭한다.
: 기법
: ARP Spoofing
-> MAC Address를 속여 Lan에서의 통신 흐름을 왜곡시키는 기법을 말한다.
-> ARP table이 바뀌면 경고를 보내는 툴을 통해 어느 정도는 예방을 할수는 있지만 근복적으로 TCP/IP 프로토콜 자체의 문제이기 때문에 ARP Spoofing에 대한 보안 대책은 없다
-> 관련 패키지(dsniff)
-> arpspoof -i(I/F) eth0(공격자의 인터넷) -t 192.168.10.131(희생자의 IP) 192.168.10.2(희생자의 GATEWAY주소)
: Dns Spoofing
-> DNS에서 전달되는 IP주소를 변조하거나 DNS의 서버를 장악하여 사용자가 의도하지 않는 주소로 접속하게 만드는 공격 기법을 말한다.
-> DNS Spoofing 공격을 통해 개인정보를 수집하는 것을 Pharming이라고 한다.
: IP Spoofing
-> IP Address를 속이는 기법을 말한다.
DNS Spoofing
: 개요
: 공격 방법
-> 사용자로부터 입력받은 도메인 주소(URL)는 DNS 서버에 의해서 IP주소로 변환한 후 서비스를 한다.
-> 즉, DNS 의 주소로 UDP프로토콜을 이용하여 질의하는 과정에서 "중간자 공격"을 이용한 공격 또는 "DNS 주소의 변조가 되었을 경우"를 이용한 공격을 말한다.
: 실습 1.
-> 실습환경
: Network Adapter : NAT
: Kali : 192.168.10.128 / C class / 192.168.10.2 / 192.168.10.2
: Windows 10 : 192.168.10.131 / C class / 192.168.10.2 / 192.168.10.2
-> Attacker와 Victim에서 IP주소와 G/W주소, MAC Address를 확인
: Attacker
: Victim
-> ARP Spoofing
:관련 패키지(dsniff)
:명령
:arpspoof -i eth0 -t 192.168.10.133 192.168.10.2
:설명
: -i (I/F)
: eth0 (공격자의 이더넷)
: -t 192.1668.10.131 (희생자의 IP주소)
: 192.168.10.2 (희생자의 Gateway 주소)
: 실습 2.
-> 실습환경
: Network Adapter : NAT
: Kali : 192.168.10.128 / C class / 192.168.10.2 / 192.168.10.129
: CentOs : 192.168.10.129 / C class / 192.168.10.2 / 192.168.10.129
: Windows 10 : 192.168.10.131 / C class / 192.168.10.2 / 192.168.10.129
-> Kali에서 새로운 호스트(acctack)하고 재구성한다
:window10에서 네임 서버 조회가 모두 되어야한다
-> 사이트 출력
:Windows 10에서 웹브라우저를 이용해서 "attack.gusiya.com"을 입력하고 출력한다
-> 에러시
:ufw 열어주기
-> 결론
G/W가 모두 동일하기 떄문에 어떤 명령을 입련하던 사이트 출력에는 영향을 주지 않는다
arpspoof -i eth0 -t 192.168.10.131 192.168.10.2
arpspoof -i eth0 -t 192.168.10.129 192.168.10.2
다만 G/W 주소만 변경될 뿐이다.
: 실습 3.
-> 실습환경
:Network Adapter : Host only
: Kali : 192.168.10.128 / C class / 192.168.10.129 / 192.168.10.129
: CentOs : 192.168.10.129 / C class / x / x
: Windows 10 : 192.168.10.131 / C class / 192.168.10.129 / 192.168.10.129
-> CentOs의 Apache Web server의 기본 경로를 /export/home/samadal로 변경한다.
:기본 경로에 배포한 소스코드를 이용해서 "login.html"문서를 생성한다
:samadal 디렉터리의 권한을 "701"로 수정한다
:Apache web Server의 환경설정을 수정한다
:방화벽 타입(chcon -R -h -t httpd_sys_content_t /export/home/)을 변경, 적용한다
-> 보안 취약점 분석
:kali에서 와이어샤크를 실행시켜놓는다
:Windows10에서 gusiya.com/login.html을 입력 실행
:아이디, 비밀번호 입력
-> 패킷 분석
89 4.288406608 192.168.10.131 192.168.10.129 HTTP 738 POST /%EC%84%9C%EB%B2%84%EC%9D%98url HTTP/1.1 (application/x-www-form-urlencoded)
*네트워크 해킹 정차, 정보 수집
-활성화된 호스트 식별
-Kali Linux
: 개요
: 여러 해킹 도구 & 해킹 툴을 포함하고 있으면 모의해킹을 시도하는 리눅스로 많이 사용되고 있다
: 데비안 리눅스를 기반으로 만들어졋다
: 파일 다운로드
: https://www.kali.org
: 기본 설정
: 관리자 및 사용자 쉘 변경과 비밀번호 재설정
-> 관리자 쉘 변경
-> 사용자 쉘 변경
-> 쉘 적용
-> 비밀번호 변경(sudo passwd)
:네트워크 설정
: 방화벽
-> 방화벽 관련 패키지 설치 : sudo apt -y install ufw
실습 1.
No. Time Source Destination Protocol Length Info
5 1.117517380 192.168.10.128 192.168.10.131 ICMP 98 Echo (ping) request id=0x5248, seq=1/256, ttl=64 (reply in 6)
6 1.118262034 192.168.10.131 192.168.10.128 ICMP 98 Echo (ping) reply id=0x5248, seq=1/256, ttl=128 (request in 5)
-> TTL을 보면 송신부(Kali)는 Linux이기에 64, 수신부는 "Windows"이기에 "128"이 출력되는 것을 알 수 있다.
:tracert
:개요
-> 네트워크 정보를 확인
-> 목적지로 가는 동안에 거치는 라우터를 기록(출력)
-> Windows에서는 "tracert"를 사용
: 실습환경
-> Network Adapter : HOST-ONLY
-> Kali : 192.168.10.128 / C class / 192.168.10.129 / 192.168.10.129
-> Windows 10 : 192.168.10.131 / C class / 192.168.10.129 / 192.168.10.129
-> CentOS : 192.168.10.129 / C class / X / X
: 실습
-> 각 시스템별로 나머지 시스템과의 통신 확인
-> 경유하는 라우터(192.168.10.129) 확인
:arping
:개요
-> ARP 패킷을 이용한 호스트를 식별
-> OSI 7 Layer의 3계층 이하(2계층)에서만 동작
-> 로컬 네트워크에 있는 시스템끼리만 통신이 가능
: 실습환경
-> Network Adapter : HOST-ONLY
-> Kali : 192.168.10.128 / C class / 192.168.10.129 / 192.168.10.129
-> Windows 10 : 192.168.10.131 / C class / 192.168.10.129 / 192.168.10.129
-> CentOS : 192.168.10.129 / C class / X / X
: 실습
-> 도메인으로 테스트
60 bytes from 00:0c:29:21:c4:12 (192.168.10.129): index=0 time=579.148 usec
60 bytes from 00:0c:29:21:c4:12 (192.168.10.129): index=1 time=188.978 usec
60 bytes from 00:0c:29:21:c4:12 (192.168.10.129): index=2 time=194.522 usec
: 분석
->
:Port Scanning
: 개요
: TCP 연결 설정(3-way handshaking) 및 TCP 연결 종료(4-way ㅗ뭉노마ㅑㅜㅎ)
: 개요
-> 공격자와 공격 대상 사이의 연결 상태를 통해 포트 스캐닝할 수 잇는 기법을 의미
-> 와이어샤크를 이용해서 확인이 가능하다
: TCP 연결
-> 공격자 -> SYN -> 공격대상 -> SYN + ACK -> 공격자 -> ACK -> 공격 대상
: TCP 종료
-> 공격자 -> FIN(연결 종료 요청) -> 공격대상 -> ACK & FIN -> 공격자 -> ACK(연결 성공)-> 공격 대상
: TCP Flag
: SYN(SYNchronize Sequence NUmbers)
-> 접속을 요청하는 패킷(데이터의 묶음)
: ACK(ACKnowledgment)
-> 응답 패킷
: RST(Connection Reset)
: 다시 연결 종료(이미 연결되어 있기 떄문에 재접속하지 않도록 끊어버린다)
: FIN(Finish)
-> 연결 종료 요청하는 패킷
: TCP 연결 리렛
-> 존재하지 않은 포트로 연결을 요청할 떄(승인되지 않은 포트로 연결 시도)
-> Target(Destination, Vimtim)의 TCP는 연결을 파기 하기 위해 RST전송
-> 공격자 -> SYN -> 공격대상 -> SYN + RST -> 공격자
-> 비정상적인 상황일 떄(정상적인 경로(승인된 경로)를 통한 통신이 아닌 상황)
-> 해킹을 종료한 후 이루어진다
-> 공격자 -> RST -> 공격대상 -> SYN + RST -> 공격자
-> Target이 장시간동안 유휴 상태일 떄
-> 연결 종료 요청
-> 공격대상 -> 난 현재 휴면상태 -> 공격자 -> RST -> 공격대상
: TCP Scan
:개요
-> TCP를 이용한 포트 스캔
-> 3-way-handshaking(TCP 연결 과정) 과정을 거친다
-> 빠른 포트 스캔을 할 수 있다
-> nmap
-> 포트를 스캔하기 전에 어떤 시스템이 동작중인지를 먼저 확인한다
-> 응답하지 않는 시스템은 스캔을 하지 않는다
-> 가장 많이 사용하는 포트 스캔 명령어
: 실습 환경
-> Network Adapter : HOST-ONLY
-> Kali : 192.168.10.128 / C class / 192.168.10.129 / 192.168.10.129
-> Windows 10 : 192.168.10.131 / C class / 192.168.10.129 / 192.168.10.129
-> CentOS(with DNS) : 192.168.10.129 / C class / X / X
: 실습
: 개요
-> 가장 많이 알려진 포트(TCP 1000개)를 스캐닝한다
-> TCP 연결된 것들만 스캔한다
-> 1000개 중에서 존재하지 않는 포틀 연결을 요청할 때 열린 포트에서는 더이상 연결이 안되게 끊어버린다.
: 선수 작업
-> 시스템 사이에 통신이 되는지를 확인(ping)한다.
-> kali에서 NameServer조회(nslookup)를 했을 떄 정상적으로 출력되어야한다.
: 명령 실행
-> nmap -s(스캔 타입을 정의하는 옵션) T(옵션) 192.168.10.129(공격 대상)
Nmap scan report for www.gusiya.com (192.168.10.129)
Host is up (2.7s latency).
Not shown: 902 filtered tcp ports (no-response), 92 filtered tcp ports (host-unreach)
PORT STATE SERVICE
20/tcp closed ftp-data
21/tcp open ftp
22/tcp open ssh
53/tcp open domain
80/tcp open http
3306/tcp open mysql
MAC Address: 00:0C:29:21:C4:12 (VMware)
: 와이어샤크를 이용한 패킷 분석
Source Destination Protocol Length Info
192.168.10.128 192.168.10.129 TCP 74 42460 → 3306 [SYN] : 공격자 -> 공격대상
192.168.10.129 192.168.10.128 TCP 74 53 → 57550 [SYN, ACK] 공격대상 -> 공격자
192.168.10.128 192.168.10.129 TCP 74 41634 → 23 [SYN] 공격자 -> 공격대상
192.168.10.128 192.168.10.129 TCP 66 42460 → 3306 [RST, ACK] 정상적인 리셋, 다음 포트를 스캔해야 하기 떄문에 리셋
192.168.10.128 192.168.10.129 TCP 74 41366 → 25 [SYN]
: 실습 2.
:개요
-> 연결된 상태만 스캐닝한다
-> TCP SYN FLAG를 스캔한다
-> 명령 실행 : nmap -sS 192.168.10.129
:와이어샤크를 이용한 패킷 분석
Source Destination Protocol Length Info
192.168.10.128 192.168.10.129 TCP 58 36952 → 21 [SYN]
192.168.10.128 192.168.10.129 TCP 58 36952 → 53 [SYN]
192.168.10.128 192.168.10.129 TCP 58 36952 → 22 [SYN]
192.168.10.128 192.168.10.129 TCP 58 36952 → 80 [SYN]
192.168.10.128 192.168.10.129 TCP 58 36952 → 3306 [SYN]
: 실습 3.
:개요
-> nmap -sTV --version-intensity 0 www.gusiya.com
-> 모든 포트를 대상으로 하되 검사하지 않았던 포트까지 스캐닝 한다.
-> V(Verbose, 진행 상태를 화면에 출력)
-> --version-intensity <레벨> (스캔강도설정)
-> 0 (5분마다)
-> 1 (15초마다)
-> 2 (0.4초마다)
-> 3 (기본값,일 회
-> 4 (5분 동안만)
-> 5 (75초 동안만)
: UDP scan(nmap, unicornscan)
: 개요
-> UDP를 이용한 포트 스캔
-> UDP를 사용하는 대표적인 서비스
: DHCP(IP주소를 자동으로 생성(유동 IP), 공유기(라우터와 스위치가 합쳐진 장비)
: DNS(네임 서버)
: SNMP(모니터링)
: TFTP(설정 내용이 저장된 서버)
-> TCP에 비해 느린 포트 스캔을 한다
: 특징
-> 포트가 열려잇을때
->공격자 -> UDP 패킷 전송 -> 공격 대상 -> 무응답- >공격자
-> 포트가 닫혀잇을떄
-> 공격자 -> UDP 패킷 전송 -> 공격 대상 -> ICMP Unreachable 패킷 전송 -> 공격자
-> 응답하지 않는 시스템은 스캔을 하지 않는다
-> 가장 많이 사용하는 포트 스캔 명령어
:실습 1. namp n-sU www.gusiya.com
:개요
-> 응답을 받지 못한 경우라면 포트가 열려있는지 차단되었는지 파악할 수가 없다.
패킷 분석(UDP, 포트가 열려있을 떄)
<정방향 조회영역>
192.168.10.128 192.168.10.129 DNS 74 Standard query 0x4ecc A www.gusiya.com
192.168.10.129 192.168.10.128 DNS 123 Standard query response 0x4ecc A www.gusiya.com A 192.168.10.129 NS ns.gusiya.com A 192.168.10.129
<역방향 조회영역>
192.168.10.128 192.168.10.129 DNS 87 Standard query 0x9df0 PTR 129.10.168.192.in-addr.arpa
192.168.10.129 192.168.10.128 DNS 162 Standard query response 0x9df0 PTR 129.10.168.192.in-addr.arpa PTR ns.gusiya.com PTR www.gusiya.com NS ns.gusiya.com A 192.168.10.129
패킷 분석(ICMP, 포트가 닫혀잇을떄)
192.168.10.128 192.168.10.129 ICMP 70 Destination unreachable(Host administratively prohibited)
192.168.10.128 192.168.10.129 ICMP 70 Destination unreachable(Host administratively prohibited)
192.168.10.128 192.168.10.129 ICMP 70 Destination unreachable(Host administratively prohibited)
192.168.10.128 192.168.10.129 ICMP 70 Destination unreachable(Host administratively prohibited)
실습 2. Unicornscan
: 개요
-> 콘솔창에서는 내용이 출력되지 않고 와이어샤크를 통해서만 확인 가능하다
: 테스트 1 : sudo unicornscan -m U -lv www.gusiya.com
:정방향 조회영역과 역방향 조회영역이 함께 출력
: 테스트2 : sudo unicornscan -m U -lv www.gusiya.com:21-3306
: 우측에 지정한 포트의 범위(21-3306)에 있는 포트들만 출력된다.
실습 3. dnsmap
: 개요
->
: 실습1. 하위 도메인 정보를 출력
네트워크 해킹 절차, 정보 수집
- 활성화된 호스트 식별
: 위치(네트워크 환경)에 따른 식별 유형
-> 같은 네트워크 안에 있는 경우
-> 같은 MAC Address로 ARP를 보낸 경우에 확인 가능
-> 다른 네트워크 안에 있는 경우
->라우터 밖에 있는 경우(ICMP로 확인가능)
->라우터 안에 있는 경우(ARP로 확인 가능)
: 실습 환경
-> Network Adapter
-> 외부망(Bridge)
-> 내부망(HOST_ONLY)
: SRV100(Windows Server 2022)
-> 외부망(10.10.10.100 / C class / x / x)
-> 내부망(192.168.100.10 / C class / x / x)
: Client100(CentOS 7.9.2207)
-> 내부망(192.168.100.20 / C class / 192.168.100.10 / 192.168.100.10)
: SRV200(Windows Server 2022)
-> 외부망(10.10.10.200 / C class / x / x)
-> 내부망(192.168.200.10 / C class / x / x)
: Clinet200(Windows Server 2022)
-> 내부망(192.168.200.20 / C class / 192.168.200.10 / 192.168.200.10)
2.패킷 분석 with Wireshark
:개요
> 패킷 스니핑 툴로써 많이 사용된다
:실습 1. 데이터 링크 계층(2계층)의 패킷 분석
:실습 환경(NAT)
: Client100(windows 10)
-> 192.168.10.130 / C Class/ 192.168.10.2 / 192.168.10.2
: SRV100(Windows Server 2022)
-> 192.168.10.131 / C Class /192.168.10.2 / 192.168.10.2
:통신 테스트 확인
: cmd 실행
windows 실행 -> windows server 2022 -> ping 192.168.10.131
windows Server 2022 -> windows 10 -> ping 192.168.10.130
:패킷 캡쳐 준비
:두 시스템 모두 Network 설정에서 "IPV4"를 제외한 모든 것을 체크해제한다
:Server 시스템에서 "IIS"를 추가한 후 활성화한다
->서버관리자를 실행한다
-> 역할 및 기능 추가를 클릭한다
-> 엔터키 3번 누른다
-> 웹 서버를 체크하고 팝업창이 뜨면 기능추가를 클릭한다
->엔터키 3번 누른다
-> FTP 서버만 체크하고 아래것은 손대지 않는다
-> 상단에 있는 "필요한 경우 자동으로 대상 서버 다시 시작"을 체크한다
-> 팝업창에 "에"를 클릭한다
-> 설치시작을 클릭한다
: 웹 브라우저를 실행한 후 Server 시스템의 IP주소를 이용해서 "IIS" 출력 확인
: 패킷 캡처
:각 시스템 별 MAC Address 확인
-> Server 시스템
이더넷 어댑터 Ethernet0:
연결별 DNS 접미사. . . . :
설명. . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
물리적 주소 . . . . . . . . : 00-0C-29-3F-64-C6 (MAC 주소)
DHCP 사용 . . . . . . . . . : 아니요
자동 구성 사용. . . . . . . : 예
링크-로컬 IPv6 주소 . . . . : fe80::1a54:deca:2fa5:395a%5(기본 설정)
IPv4 주소 . . . . . . . . . : 192.168.10.130(기본 설정)
서브넷 마스크 . . . . . . . : 255.255.255.0
기본 게이트웨이 . . . . . . : 192.168.10.2
DHCPv6 IAID . . . . . . . . : 100666409
DHCPv6 클라이언트 DUID. . . : 00-01-00-01-2D-D0-FE-31-00-0C-29-3F-64-C6
DNS 서버. . . . . . . . . . : 192.168.10.2
Tcpip를 통한 NetBIOS. . . . : 사용
-> Client 시스템
이더넷 어댑터 Ethernet0:
연결별 DNS 접미사. . . . :
설명. . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
물리적 주소 . . . . . . . . : 00-0C-29-B7-4F-EE (MAC 주소)
DHCP 사용 . . . . . . . . . : 아니요
자동 구성 사용. . . . . . . : 예
IPv4 주소 . . . . . . . . . : 192.168.10.131(기본 설정)
서브넷 마스크 . . . . . . . : 255.255.255.0
기본 게이트웨이 . . . . . . : 192.168.10.2
DNS 서버. . . . . . . . . . : 192.168.10.2
Tcpip를 통한 NetBIOS. . . . : 사용
: Client 시스템에서 확인한다.
: ARP(MAC 주소를 확인하기 위한 프로토콜)를 통해 MAC주소 확인을 요청하는 패킷
: 상단의 필터링에서 "ARP"를 입력한다.
Source Destination Protocol Length Info
VMware_f9:07:ed Broadcast ARP 60 Who has 192.168.10.130? Tell 192.168.10.2
VMware_3f:64:c6 VMware_f9:07:ed ARP 42 192.168.10.130 is at 00:0c:29:3f:64:c6
: 분석 1. 일반 분석
-> Client가 Server를 찾기 위해서 Broadcast(불특정 다수들에게 패킷을 보낸다) 하면서 "192.168.10.131"fmf thdbgks tltmxpadmfhqnxj dmdekqdl dhrlfmf rlekflsek
-> 정상적인 패킷은 받은 시스템은 요청한 시스템으로부터 응답을 하게 된다.
: 분석 2. 세부 분석(요청 Client가 Server에게 요청)
1. 브로드캐스팅을 하게 되면 목적지의 대상을 알 수 없기 떄문에 "Dst: Broadcast (ff:ff:ff:ff:ff:ff)"와 같이 출력이 된다.
ff:ff:ff:ff:ff:ff은 네트워크의 모든 영역이 대상임을 의미한다.
응답이 오기 전이기 떄문에 "Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)" 출력
Ethernet II, Src: VMware_3f:64:c6 (00:0c:29:3f:64:c6), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: VMware_3f:64:c6 (00:0c:29:3f:64:c6)
Type: ARP (0x0806)
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: VMware_3f:64:c6 (00:0c:29:3f:64:c6)
Sender IP address: 192.168.10.130
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 192.168.10.131
: 분석 2. 세부 분석(응답. Server로부터 Client가 응답)
:실습 2
:실습 환경(NAT)
:SRV100(Windows Server 2022) - P@ssw0rd
-> 내부망(192.168.100.10 / C class / x / x)
-> 외부망(10.10.10.100 / C class / x / x)
:SRV200(Windows Server 2022) - P@ssw0rds200
-> 내부망(192.168.200.10 / C class / x / x)
-> 외부망(10.10.10.200 / C class / x / x)
:Client100(Windows Server 2022) - P@ssw0rdc100
-> 내부망(192.168.100.20 / C class / 192.168.100.10 / 192.168.100.10)
:Client200(Windows Server 2022) - P@ssw0rdc200
-> 내부망(192.168.200.20 / C class / 192.168.200.10 / 192.168.200.10)
: 통신 테스트 확인
Client 100 -> Client 200 : pinrg -t 192.168.200.20
Client 200 -> Client 100 : pinrg -t 192.168.100.20
: 라우터 설정(SRV100, SRV200) windwos 관리 도구 -> 라우팅 및 원격 엑세스
->
->
->
:패킷 캡쳐
-> 4개 시스템 모두 wireshark를 실행
-> SRV100과 SRV200을 외부망을 선택 후 실행
-> Client100에서 Client200에서 ping 테스트를 한 후
분석 1. SRV100과 SRV200이 외부망일때
분석 2. SRV100과 SRV200이 내부망일떄
: Client 100
1.Source : 출발지와 도착지점간의 Bordascasting을 통해 존재 여부 확인
Source Destination Protocol Length Info
> 출발지((192.168.100.20)와 도착지(192.168.200.20)점간의 Bordascasting을 통해 존재 여부 확인
VMware_ae:a2:d9 VMware_a5:75:60 ARP 42 Who has 192.168.100.10? Tell 192.168.100.20
VMware_a5:75:60 VMware_ae:a2:d9 ARP 60 192.168.100.10 is at 00:0c:29:a5:75:60
VMware_ae:a2:d9 Broadcast ARP 42 Who has 192.168.100.10? Tell 192.168.100.20
VMware_a5:75:60 VMware_ae:a2:d9 ARP 60 192.168.100.10 is at 00:0c:29:a5:75:60
VMware_a5:75:60 VMware_ae:a2:d9 ARP 60 Who has 192.168.100.20? Tell 192.168.100.10
VMware_ae:a2:d9 VMware_a5:75:60 ARP 42 192.168.100.20 is at 00:0c:29:ae:a2:d9
VMware_76:a5:05 VMware_13:2e:fa ARP 60 Who has 192.168.200.10? Tell 192.168.200.20
VMware_13:2e:fa VMware_76:a5:05 ARP 60 192.168.200.10 is at 00:0c:29:13:2e:fa
VMware_13:2e:fa VMware_76:a5:05 ARP 60 Who has 192.168.200.20? Tell 192.168.200.10
> 요청 밑 응답의 결과로 출발지(Client 100)와 도착지(Client200)의 최종 Mac address 확인
VMware_76:a5:05 VMware_13:2e:fa ARP 60 192.168.200.20 is at 00:0c:29:76:a5:05
: SRV100
Source Destination Protocol Length Info
> GateWay(192.168.123.13)를 통한 통신 여부 확인
ZioncomElect_6a:a5:a4 MicroStarINT_77:8b:fc ARP 60 Who has 192.168.123.13? Tell 192.168.123.254
MicroStarINT_77:8b:fc ZioncomElect_6a:a5:a4 ARP 60 192.168.123.13 is at 04:7c:16:77:8b:fc
MicroStarINT_77:8b:fc ZioncomElect_6a:a5:a4 ARP 60 192.168.123.13 is at 04:7c:16:77:8b:fc
> 외부망끼리의 통신여부를 확인(10.10.10.200 -> 10.10.10.100)
VMware_a5:75:56 VMware_13:2e:f0 ARP 42 Who has 10.10.10.200? Tell 10.10.10.100
VMware_13:2e:f0 VMware_a5:75:56 ARP 60 10.10.10.200 is at 00:0c:29:13:2e:f0
VMware_13:2e:f0 VMware_a5:75:56 ARP 60 Who has 10.10.10.100? Tell 10.10.10.200
> 호스트 시스템을 통해서 Gateway의 존재 유무를 확인한 후 Mac address를 출력
VMware_a5:75:56 VMware_13:2e:f0 ARP 42 10.10.10.100 is at 00:0c:29:a5:75:56
-> Client100
Source Destination Protocol Length Info
VMware_4f:39:1f VMware_d2:a5:d9 ARP 60 Who has 192.168.200.10? Tell 192.168.200.20
VMware_d2:a5:d9 VMware_4f:39:1f ARP 60 192.168.200.10 is at 00:0c:29:d2:a5:d9
VMware_d2:a5:d9 VMware_4f:39:1f ARP 60 Who has 192.168.200.20? Tell 192.168.200.10
VMware_4f:39:1f VMware_d2:a5:d9 ARP 60 192.168.200.20 is at 00:0c:29:4f:39:1f
VMware_d8:ea:dc VMware_4b:70:63 ARP 42 Who has 192.168.100.10? Tell 192.168.100.20
VMware_4b:70:63 VMware_d8:ea:dc ARP 60 192.168.100.10 is at 00:0c:29:4b:70:63
-> SRV100
Source Destination Protocol Length Info
VMware_4f:39:1f VMware_d2:a5:d9 ARP 60 Who has 192.168.200.10? Tell 192.168.200.20
VMware_d2:a5:d9 VMware_4f:39:1f ARP 60 192.168.200.10 is at 00:0c:29:d2:a5:d9
VMware_d2:a5:d9 VMware_4f:39:1f ARP 60 Who has 192.168.200.20? Tell 192.168.200.10
VMware_4f:39:1f VMware_d2:a5:d9 ARP 60 192.168.200.20 is at 00:0c:29:4f:39:1f
VMware_d8:ea:dc VMware_4b:70:63 ARP 60 Who has 192.168.100.10? Tell 192.168.100.20
VMware_4b:70:63 VMware_d8:ea:dc ARP 42 192.168.100.10 is at 00:0c:29:4b:70:63
VMware_4b:70:63 VMware_d8:ea:dc ARP 42 Who has 192.168.100.20? Tell 192.168.100.10
VMware_d8:ea:dc VMware_4b:70:63 ARP 60 192.168.100.20 is at 00:0c:29:d8:ea:dc
1.TCP/IP의 이해
OSI 하위 계층의 역할 및 프로토콜 종류
: LAN
: WAN
OSI(Open System Interconnection, 개방형 시스템) 7 Layer
: 개요
- Protocol을 이용한 통신을 계층별로 구분해 놓은 것을 말한다
- Protocol => 통신규약, 컴퓨터나 네트워크 장비가 서로 통신하기 위해서 미리 정해놓은 약속
- TCP/IP Model
-> OSI 7 Layer를 TCP(4계층)와 IP(3계층)프로토콜을 중심으로 4개 영역으로 구분
Physical Layer (1계층, 물리계층)
: 개요
-> 데이터 링크 계층(2계층)의 프레임(Frame, 데이터를 담고 있는 틀)을 받고 다음 장치(1계층)에 구리나 광섬유 또는 무선 통신 매체를 전송하기 위한 신호로 변경(Encapsulation)한다.
-> 변경된 신호들은 수신 측에서 기존의 형태로 바뀌고(De-encapsulation) 데이터 링크 계층으로 전달한다.
: 기본 장비 또는 기타
-> Cable(LAN Cable, UTP Cable) , Connector(RJ-45 Jack) , Bit(Signal)
: Cable Connection
: UTP Straight-Through Cable
-> 다이렉트 연결 1:1 연결
-> 서로 다른 장비간의 연결(이기종간 연결)
: UTP Crossvoer Cable
-> 크로스 연결
-> 서로 같은 장비간의 연결(동기종간 연결)
Data Link Layer(2계층, 데이터링크 계층)
: 개요
-> 네트워크 계층(3계층)의 패킷(Packet, 데이터)을 물리적 매체(MAC 주소)에 실어 보내기 위해 사용된다.
-> 광범위한 데이터 통신 매체에 대한 데이터 접근 제어를 위해 다양한 데이터 링크 프로토콜이 요구된다.
-> 물리 계층(1계층)의 매체(장비) 상에서 2계층과의 통신 시 Frame 교환을 책임진다. (데이터 전송이 잘 되게 해준다.)
-> Packet(데이터)을 Frame(데이터와 정보들이 모여 있는 것)으로 캡슐화(Encapsulation)하여 매체에 보내고 매체로부터 Frame을 수신하여 다시 Packet으로 역캡슐화(De-Encapsulation)하는 과정을 포함한다.
-> (핵심) LAN 구간에서만 사용된다. 즉, 내부망에서만 사용된다.
: 기본 장비 또는 기타
: Switch(스위치 ,2계층의 대표적인 장비)
: MAC(Media Access Control) Address
-> 데이터를 송수신할 떄 Ethernet(랜카드)이 기억하고 있는 주소
-> 전세계적으로 절대 2개가 존재할 수가 없다
: MAC Address 구조(EUI-48 & EUI-64)
: 개요
-> 16진수 구조로 되어있다
-> 일반적으로 LAN Card라고 불리는 NIC(Network Interface Card)의 일련번호를 Ethernet이 물리적 주소로 사용한다.
Network Layer(3계층, 네트워크(인터넷) 계층)
:개요
-> 상위 레벨(Transport, 4계층) 데이터를 패킷(전송되는 데이터) 안으로 캡슐화(들어오는 신호를 모두 묶어서)해서 데이터 종류에 상관없이 한 호스트(PC 또는 서버)에서 다른 호스트(PC 또는 서버)로 그 패킷들을 라우팅(Routing, 전송)하는 것을 말한다.
-> 데이터는 패킷 안으로 캡슐화되며 패킷 헤더는 패킷의 송신지와 수신지의 주소들을 포함하는 필드를 가진다.
-> 라우터는 각 호스트에 부여할 IP주소(인터넷을 하기 위해 꼭 필요한 숫자 정보)를 구성해서 배포한다.
-> PC(호스트)에 IP를 부여하기 위한 'IP Table'을 구성한다.
-> (핵심) 라우터는 PC에 IP Address를 부여(IP Table)해서 인터넷을 할 수 있도록 해 준다.
-> (핵심) 라우터는 내부망(LAN)과 외부망(WAN)이 공존하는 장비이다.
:기본 장비 또는 기타
-> Router(Router, 3계층의 대표적인 장비)
-> IP Address, ICMP, IGMP, ARP, RARP
Transfer Layer(4계층 전송계층)
:개요
-> 사용자 간 데이터의 투명한(신뢰성을 기반으로 한) 전송을 제공(TCP)하고 상위 계층에 신뢰성 있는 데이터를 전송하는 서비스를 제공한다.
->
:기본 장비 또는 기타
-> UDP : 데이터를 보내는 쪽에서 상대방의 수신 여부를 확인할 수가 없는데 바로 이 점이 신뢰성이 없다.
즉, 상대방이 데이터를 수신할 준비가 되었는지를 판단하지 않는다.
데이터 전송할 떄 빠른 전송 서비스를 요구하는 음성, 영상 데이터 등에 많이 사용된다.
-> TCP : 데이터를 보내면 해당 데이터를 수신한 측에서 데이터를 이상없이 잘 받았다는 확인 및 응답을 전송한다.
Three Way Handshake(3-way Handshake)
SeSSion/Presentation/Application Layer(연결/표현/응용프로그램 계층)
:개요
-> 대부분 서비스에 관련된 계층을 말한다.
: 연결 계층
-> 대화를 시작하고 끊어지지 않게 꼐속 활성화 상태를 유지한다.
: 표현 계층
-> 수신지 장치에서 "적합한 응용프로그램(서비스 받고자 하는)을 사용" 해서 송신지 장치로부터 온 데이터의 해석을 도와준다.
: 응용프로그램 계층
-> 데이터들이 서로 왕래되는 네트워크 상에서 통신의 송신지와 수신지로서의 역할을 담당한다
-> 서비스를 요청(Request)하고 요청에 대한 응답(Response)하는 모든 것. 즉, Client 요청에 따른 Server의 응답을 담당한다.
: 대표적인 기능
• File Transfer(파일 전송)
• TFTP
• FTP
• E-mail
• SMTP(보내는 메일 서버)
• POP3(받는 메일 서버)
• Remote Login
• Telnet(보안 안된 상태로 접속)
• SSH (암호키를 이용한 접속)
• Network Management
• SNMP(Simple Network Managemnet Protocol, 간이 망 관리 프로토콜 , 모니터링)
• Name Management
• DNS(이름 서버)
• IP Management
• DHCP(호스트(PC)들에게 IP를 자동으로 부여, 공유기)
