• CDN을 사용하지 않고 하나의 데이터 센터만 사용할 경우 문제점
    1. 지역적으로 먼 거리 ⇒ 거쳐가는 라우터의 수 증가 ⇒ 병목 지점의 링크를 거쳐갈 확률 증가 ⇒ 전송용량이 낮아질 가능성이 높아진다.
    2. 많은 이들이 여러번 시청하는 콘텐츠는 그만큼 자주 전송해야하고 이로 인해 전송 비용이 중복적으로 발생한다.
    3. 한번의 장애로 전체 서비스가 중단될 위험이 있다.
  • CDN(Contents Distribution Network)
    : 여러 서버 클러스터를 두고 이들 서버에 콘텐츠의 복사본을 저장해두고 사용하는 방식
    • 대부분의 비디오 스트리밍 서비스에서 사용하는 방식
    • 이용하려는 서버 클러스터에 콘텐츠의 복사본이 없는 경우, 중앙 서버나 다른 클러스터로부터 해당 콘텐츠를 전송 받아 제공하는 동시에 복사본을 만든다.
      • PULL 방식을 사용하여, 요청이 들어오는 비디오에 대한 처리만 한다.
      • 복사본을 저장할 공간이 가득찬 경우 인터넷 캐시처럼 자주 이용되지 않은 것을 삭제
    • 사설 CDN 또는 제3자가 운영하는 CDN을 사용할 수 있다.
    • CDN 서버 클러스터를 구축하는 방식 (아래 두 가지 중 하나 선택 사용)
      1. 서버 클러스터를 최대한 사용자에 가까이 두어 전송 속도를 높이기 위해, 수많은 서버 클러스터들을 ISP의 접속 네트워크 안에 위치시키는 방법
        1. 장점 : 지연 시간 및 처리율이 향상된다.
        2. 단점 : 고도로 분산된 설계로 인해 유지 관리 비용이 증가한다.
      2. 보다 적은 수의 핵심 지점(IXPs)에만 큰 규모의 서버 클러스터를 위치 시키는 방법
        1. 장점 : 유지 관리 비용이 줄어든다.
        2. 단점 : 지연 시간 및 처리율이 상대적으로 저하된다.
  • CDN 동작
    • CDN이 사용자의 요청을 가로채 해당 사용자에게 가장 적절한 서버 클러스터를 찾아 그 서버로 요청을 보낸다. 요청을 가로챌 때 DNS를 사용한다.
    • 동작 단계

  • 서버 클러스터 선택 정책
    • LDNS(로컬 DNS)에서 CDN 책임 서버로 요청을 보내는 과정에 의해 CDN은 LDNS의 IP를 알게 되고 이 주소를 바탕으로 사용자에게 가장 적합한 콘텐츠 서버를 선택한다.
    • 각 CDN 별로 고유한 클러스터 선택 정책을 사용한다.
    • 일반적으로 사용하는 정책은 “클라이언트에게 지리적으로 가장 가까운 클러스터"를 선택하는 것
      • 일부 클라이언트에게는 지리적으로 가장 가까운 클러스터가 가장 가까운 클러스터가 아닐 수 있다. (네트워크 경로 상의 홉 수에 의해)
      • 클라이언트가 멀리 떨어진 LDNS를 사용할 경우 LDNS의 IP를 기반으로 한 선택이 최선이 아닐 수 있다.
      • 같은 위치라면 매번 같은 클러스터가 배정되는데, 이 때 경로의 지연이나 가용 대역폭의 변화 등은 고려하지 않는다.
    • CDN은 네트워크 트래픽 상황을 고려하여 클러스터를 선택하기 위해 클러스터와 클라이언트 간 경로 상의 지연 및 손실 성능을 실시간으로 측정하도록 할 수 있다.
      • 다만, 대부분의 LDNS에서 실시간 측정을 위해 사용되는 메시지에 응답하지 않도록 설정되어 있는 것이 문제...

'Network' 카테고리의 다른 글

Tracert와 Traceroute  (0) 2023.05.26
DNS(Domain Name System)  (0) 2022.03.28
Network 개요  (0) 2022.03.01

호스트 식별 방법

  • 호스트 네임(hostname)
    • (ex. www.naver.com, www.google.com)
    • 가변 길이의 알파뉴메릭 문자로 구성된다.
    • 호스트의 위치에 대한 정보는 제공하지 않는다.
  • IP 주소
    • 4바이트 (32비트)
    • xxx.xxx.xxx.xxx 형태의 계층 구조
    • 호스트가 속한 네트워크의 위치와 호스트의 위치에 대한 정보를 제공한다.

 

DNS가 제공하는 서비스

  • DNS(Domain Name System)
    1. DNS 서버가 계층 구조로 구현된 분산형 데이터베이스
      • 서버 : BIND(Berkeley Internet Name Domain) 소프트웨어를 수행하는 유닉스 컴퓨터
    2. 호스트가 분산형 데이터베이스에 질의할 수 있게 하는 애플리케이션 계층 프로토콜
      • 프로토콜 : UDP 기반으로 수행되고, 포트 번호 53번을 사용한다.
  • 사용자가 제공한 호스트 네임을 IP 주소로 변환하는데 사용된다.
    • 인터넷 애플리케이션에서 URL로의 요청을 보낼 때 우선 DNS 클라이언트를 이용하여 DNS 서버에 호스트 이름에 대한 질의를 보내 IP 주소를 얻는다.
    • 가까운 DNS 서버에 원하는 IP 주소가 캐시되어 있어 평균 지연 시간을 줄여준다.
  • 호스트 엘리어싱(host aliasing) : 복잡한 호스트 네임을 가진 호스트에 대해 하나 이상의 별칭도 함께 저장한다.
    • 원래 호스트 네임을 **정식 호스트 네임(canonical hostname)**이라고 한다.
    • 별칭 호스트 네임으로부터 정식 호스트 네임을 얻을 수 있도록 한다. (google.com 별칭 이름 → www.google.com 정식 이름)
  • 메일 서버 엘리어싱(mail server aliasing) : 메일 애플리케이션으로부터 메일 서버에 대한 정식 호스트 네임을 얻기 위해 사용된다.
    • 기억하기 쉬운 전자메일 주소를 위해 주소로는 별칭을 사용하고 정식 호스트 네임이 필요할 때 DNS에 질의한다.
  • 부하 분산(load distribution) : 여러 중복 서버 사이에 부하를 분산하는 데에 사용한다.
    • 여러 중복된 서버는 서로 다른 IP 주소를 가지고 있는데, 이들 모두 하나의 연관된 호스트 네임을 가진다.
    • 해당 호스트 네임으로 질의를 받은 DNS 서버는 서로 다른 IP 주소들을 모두 응답해준다.
    • 이 때 응답하는 IP 주소의 순서를 순환되도록 하여, 가장 앞에 있는 IP 주소를 사용하는 클라이언트가 분산된 여러 서버에 순환적으로 요청을 보낼 수 있도록 한다.

 

DNS 동작 원리

분산 계층 데이터베이스

  • DNS 서버 계층
    • 루트 DNS 서버
      • 13개의 다른 기관에서 관리하며 400개 이상의 루트 DNS 서버가 존재한다.
      • DNS 서버 계층으로 질의가 들어올 때 제일 먼저 루트 DNS 서버로 전달된다.
      • 호스트 네임의 TLD에 맞는 TLD 서버의 IP 주소를 응답한다.
    • TLD(Top-Level Domain) DNS 서버
      • com, org, net, edu 같은 TLD 서버와 kr, fr, ca 같은 모든 국가에 대한 TLD 서버가 존재한다.
      • 각 TLD 서버는 각각에 속한 책임 DNS 서버들의 IP 주소를 가지고 있고, 이를 응답한다.
    • 책임(authoritative) DNS 서버
      • 자신의 서버에서 관할하는 호스트 네임과 그의 IP 주소가 매핑된 공개적인 DNS 레코드를 가진다.
      • 웹 서버나 메일 서버들은 자신의 호스트 네임과 IP 주소가 매핑된 DNS 레코드를 책임 DNS 서버에 저장해야 한다.
      • 이를 위해 자신들이 직접 책임 DNS 서버를 구현하여 저장하는 방법과 책임 DNS 서버 서비스를 제공하는 제공자에게 비용을 지불하고 저장하는 방법(ex. 가비아, 카페24) 중 선택할 수 있다.
  • 로컬 DNS 서버
    • ISP들은 로컬 DNS 서버(default name server)를 갖는다.
    • 호스트가 ISP에 접속할 때 일반적으로 DHCP를 이용하여 호스트에게 IP 주소를 할당한다.
    • 호스트가 DNS 질의를 보낼 때 제일 먼저 로컬 DNS 서버로 보내고, 이 서버에 원하는 호스트명이 없을 경우 로컬 DNS 서버에서 DNS 서버 계층으로 DNS 질의를 보낸다.
    • 로컬 DNS 서버를 중심으로 DNS 서버 계층과의 질의가 이루어지며 이렇게 얻어진 DNS 레코드는 캐싱되어 로컬 DNS 서버에 저장된다.
    • 재귀적 질의(recursive query)반복적 질의(iterative query)
      • 재귀적 질의 : 요청 호스트 - LDNS - DNS 서버
      • 반복적 질의 : LDNS - DNS 서버

DNS 캐싱(caching)

  • 로컬 DNS 서버는 질의 결과로 얻은 DNS 레코드를 로컬 메모리에 저장할 수 있다.
    • 저장할 때 저장해 둘 기간(대게 2일)을 설정해두고, 이 기간이 지난 레코드는 삭제한다.
    • 저장된 DNS 레코드에 해당하는 질의가 들어올 경우 추가적인 질의 없이 곧바로 이 레코드의 정보를 이용하여 응답할 수 있다.
  • 로컬 DNS 서버는 호스트에 대한 정보 뿐만 아니라 TLD 서버의 IP 주소도 저장할 수 있다.
    • DNS 서버 계층으로 질의할 경우 루트 DNS 서버로의 질의를 우회할 수 있다.

 

DNS 레코드와 메시지

(RFC1034, RFC1035)

자원 레코드(resource record, RR) : DNS 서버에서 호스트명과 IP 주소를 매핑하는데 사용하는 레코드

  • 각 DNS는 DNS 질의에 대해 하나 이상의 자원 레코드를 가지는 메시지로 응답한다.
  • 자원 레코드가 갖는 필드
    • Name(16bits), Value, Type(16bits), TTL(32bits, 자원 레코드가 캐시에 남아있는 기간)
  • Type 값에 따른 Name과 Value의 값
    • Type = A
      • Name : 호스트 명
      • Value : 호스트 명에 대한 IP 주소
      • Type A의 레코드 예시 : (relay1.bar.foo.com, 145.37.93.126, A)
    • Type = NS
      • Name : 도메인
      • Value : 도메인에 대한 책임 DNS 서버의 호스트 네임
      • Type NS의 레코드 예시 : (foo.com, dns.foo.com, NS)
    • Type = CNAME
      • Name : 별칭 호스트 명
      • Value : 별칭 호스트 명에 대한 정식 호스트 명
      • Type CNAME의 레코드 예시 : (foo.com, relay1.bar.foo.com, CNAME)
    • Type = MX
      • Name : 별칭 호스트 명
      • Value : 별칭 호스트 명에 대한 메일 서버의 정식 이름
      • Type MX의 레코드 예시 : (foo.com, mail.bar.foo.com, MX)
      → 하나의 별칭이 해당 회사의 메일 서버와 다른 서버들을 통칭하는 이름으로 사용될 수 있음.

RFC1034, page 11 - 더 많은 타입 종류
RFC1034, page 12 - 타입별 Value 값

  • 하나 이상의 자원 레코드를 전송하는 경우
    • 요청을 받은 서버가 해당 호스트의 책임 DNS 서버일 경우
      1. 호스트의 IP 주소를 알기 때문에 이를 응답하기 위한 Type A 레코드를 응답
    • 요청을 받은 서버가 해당 호스트의 책임 DNS 서버가 아닐 경우
      1. 해당 호스트를 포함하고 있는 DNS 서버의 호스트 명을 응답하기 위한 Type NS 레코드를 응답
      2. 알려주려고 하는 DNS 서버의 IP 주소를 응답하기 위한 Type A 레코드를 응답

 

DNS 메시지

  • 헤더 영역 (12 bytes)
    • 질의 식별자 (16 bits) : 질의/응답 메시지에 동일한 값을 사용하는 것으로 질의/응답 간의 일치를 식별한다.
    • 플래그
      • 질의/응답 플래그(1 bit) : 메세지가 질의(0)인지 응답(1)인지 구분
      • 책임 플래그(1 bit) : 응답하는 DNS 서버가 책임 DNS 서버일 때 설정되는 플래그
      • 재귀 요구 플래그(1 bit) : DNS 서버가 질의에 맞는 레코드를 가지고 있지 않을 때 재귀적 질의를 수행하길 원할 경우 클라이언트 측에서 설정하는 플래그
      • 재귀 - 가능 플래그(1 bit) : DNS 서버가 재귀적 질의를 지원할 수 있는 경우 응답 메시지에 설정되는 플래그
    • 질문 수, 답변 RR 수, 책임 RR 수, 추가 RR 수(각 16 bits 씩 4개)
      : 헤더영역 이후에 오는 영역들에 대한 갯수 정보
  • 질문 영역
    : 현재 질의에 대한 정보
    • 이름 필드 : 질의되는 이름을 포함할 필드
    • 타입 필드 : 이름에 대해 문의되는 질문 타입을 지정할 필드
  • 답변 영역
    : (응답에 포함) 처음 질의된 이름에 대한 자원 레코드
    • 하나의 호스트 명에 대응되는 IP 주소가 여러 개가 존재할 수 있기 때문에 한 개 이상의 응답 레코드를 가진다.
  • 책임 영역
    : 다른 책임 서버의 레코드
  • 추가 영역
    : 그 밖에 도움이 되는 레코드
    • MX 질의에 대한 응답의 응답 필드로 MX 서버의 정식 호스트 네임을 가진다.
      → 이 때 추가 영역에는 정식 호스트 네임의 IP 주소를 제공하는 Type A 레코드가 있다.

 

DNS 데이터베이스에 레코드 삽입

  • 도메인 네임을 등록기관에 등록하는 절차
    1. 등록기관 : 도메인 네임의 유일성을 확인하고 해당 도메인 네임을 DNS 데이터베이스에 넣는다.
      (ICANN에 의해 승인된 등록기관의 리스트 확인 사이트 : http://www.internic.net)
    2. 등록 시 주책임 DNS서버와 부책임 DNS서버의 이름과 IP주소를 등록기관에 제공해야 한다.
      1. 이렇게 제공된 이름과 IP 주소를 각각 type NS와 type A RR을 이용하여 TLD DNS 서버에 저장한다.
      2. (ex) (networkutopia.com, dns1.networkutopia.com, NS)
                (dns1.networkutopia.com, 212.212.212.1, A)
    3. networkutopia.com이 책임 DNS 서버에 Type A RR 로 저장되는지 확인한다.
      → 최근에는 이를 DNS 동적 갱신 방식으로 기술하고 있다.
  • 등록된 도메인 네임을 불러오는 절차

'Network' 카테고리의 다른 글

Tracert와 Traceroute  (0) 2023.05.26
콘텐츠 분배 네트워크(CDN)  (0) 2022.03.28
Network 개요  (0) 2022.03.01

네트워크를 제대로 공부해봐야지.. 라고 생각하며 네트워크 스터디를 시작했다.

네트워크 전반에 대해서 본격적으로 공부해보는게 처음이라 아직 엉성하지만 중간점검 한다고 생각하고 기록용으로 올려둔다.

이제부터는 여기에 살을 붙여가면서 공부할 예정이다. 파이팅!

 

Network 일반

데이터 통신 방식

obvious-phlox-33e.notion.site

 

'Network' 카테고리의 다른 글

Tracert와 Traceroute  (0) 2023.05.26
콘텐츠 분배 네트워크(CDN)  (0) 2022.03.28
DNS(Domain Name System)  (0) 2022.03.28

XCZ.KR의 패스워드를 잃어버렸다고 한다.

주어진 파일은 .pcapng 파일 하나이고, 곧바로 Wireshark로 열어보겠다.

간단히 살펴봤는데 line-based text data 전송량이 좀 있었다. 뭐를 그렇게 보냈나 보기 위해 HTTP object list를 살펴보았다.

password를 잃어버렸다고 하더니,, 로그인에 시도할 법하게 생긴 login.php와 회원가입 완료 시 쓸 법한 join_ok.php가 여럿 보인다.

특히 join_ok.php나 login_ok.php 의 Content-Type이 form-urlencoded 인 것으로 봐서 이곳에 쓸 만한 정보가 있는지 보는 것도 괜찮아 보인다.

no.313 packet

첫 번째로 찾은 정보는 id=menboong 이라는 사람이 pw=123123으로 하여 회원가입에 성공하였다는 것이다.

no.378 packet

두 번째로 찾은 정보는 id의 길이가 3~20 이어야 한다는 것이다.

no.571 packet

세 번째로 찾은 정보는 id=IMZZANGHACKER 라는 사람이 pw=IDISLIE 로 하여 회원가입에 성공하였다는 것이다.

IMZZANGHACKER...? 문제의 주인공이다.

벌써 답이 나온 것 같다.^^...

제공받은 파일에서 key값을 찾아 md5 해쉬값을 얻으면 되는 모양이다.

확장자가 없는 파일 하나를 제공받았다.

일단 무작정 파일을 열어보니 그 안에서 HTTP 패킷같이 생긴 텍스트들이 여럿 발견되었고
문제 제목으로부터 network 관련된 것이라는 것을 참고하여 이를 Wireshark로 열어봤다.

그랬더니 기다렸다는 듯이 패킷들이 정렬되어 보여졌다!
(나중에 알고보니 이 파일의 signature가 0A 0D 0D 0A로 pcapng 파일의 것임을 알았다.)

.pcap 파일의 signature

 

나같은 경우는 패킷분석을 위해 Wireshark를 살펴볼 때 주로 제일 먼저 찾아보는 것이 Protocol Hierarchy Statistics 이다.

현재 이 파일 내에 잡힌 패킷들에 어떤 프로토콜이 얼마나 많이 쓰였는지를 한눈에 파악하기 좋기 때문이다.

여기서 이 창을 통해 발견한 것은 HTTP 프로토콜 밑에 Malformed Packet이 있다는 것이었는데,
Malformed Packet이란 패킷 파일이 손상되는 등의 문제로 제대로 보여지지 못하고 있는 경우를 말한다.
사실 패킷 분석하면서 이런 패킷이 있는 경우를 처음 봐서...무슨 일이 있었길래 이런 패킷이 있게 된건지 궁금해졌다.

그래서 해당 패킷의 Stream을 살펴보니.. 응답 패킷에 PNG 파일이 있다?
물론 PNG가 담길 수는 있는건데 왜 Malformed Packet이 표시가 뜬걸까

이 패킷은 HTTP 프로토콜을 사용하여 통신하다가 이런 오류가 생긴 것으므로 HTTP Stream에 어떤 문제가 생긴건지 좀 봐야겠어서 나머지 패킷들도 살펴봤다.

아까 그렇게 Malformed Packet 표시가 있던 패킷은 443번 패킷인데, 확실히 png 파일이 담긴 것은 맞는 것 같다.
파일 이름은 treasure1 이라고 한다.
그리고 그 밑에 이와 관련되어 있어 보이는 이름인 treasure2와 treasure3가 차례차례 보인다.
그런데 이 패킷들은 단순히 text/plain 형태이다.

우선 각 패킷 내에서 해당 파일들만 가져와 저장하여 빠르게 살펴봐야겠다.
(HTTP object list 하단의 preview를 이용하면 빠르게 파일들만 저장할 수 있다! 처음에 그것도 모르고 TCP stream 다 뒤져가면서 내려받았었던 기억이...)

내려받은 각 파일들을 HxD Editor로 열어봤다.

treasure1.png

그리고 treasure1.png 파일의 Signature가 잘 있는지 봤는데,
Header Signature인 89 50 4E 47 0D 0A 1A 0A 는 찾을 수 있었지만
Footer Signature인 49 45 4E 44 AE 42 60 82 는 찾을 수 없었다.
(File Signature 참고: http://forensic-proof.com/archives/323 )

이게 Malformed Packet의 원인이었던 것 같다. 이 파일만 실행시켰을 때에도 뭔가 매우 불편해보이는 이미지를 볼 수 있었다.

 

나머지 두 파일도 정체가 뭐길래 2, 3번의 이름이 붙은 것인지 봐야겠다.

treasure2
treasure3

treasure2에서 발견한 것은 수 많은 00 과 그 사이에 드물게 있던 몇몇 hex들이었고,
treasure3에서 발견한 것은 수 많은 00 과 그 끝에 있던 IEND, Footer Signature였다!

treasure2가 모두 0으로만 가득차있었더라면 버리고 3만 쓰고자 했을 수도 있었을텐데..ㅎ
중간에 있던 데이터들이 소중하게 보여서 모두 연결해보기로 했다.

Header Signature가 있던 treasure1을 제일 처음에 붙이고
Footer Signature가 있던 treasure3을 당연히 제일 마지막에 붙여야 할 것 이다.
남은 treasure2는 두 파일 사이에 위치시켰다.
HxD 에서 [도구] - [파일 도구] - [연결] 을 이용하면 파일을 손쉽게 연결시킬 수 있다.

이렇게 해서 연결한 파일에 .png 확장자를 붙여서 열면 key값이 담긴 이미지를 볼 수 있고, 이를 이용하여 해쉬값을 만들면 성공이다.

참고. md5 hash 구하는 코드 (.py)

더보기

import hashlib


key = b'[~~~insert key~~~]'
encode = hashlib.md5()
encode.update(key)
hash = encode.hexdigest()


print(hash)


++

위에서도 언급했던 건데.. 이것 때문에 엄청난 삽질을 해서 적어본다.


treasure1, 2, 3의 존재를 발견한 후에 이 파일을 내려받는 방식으로 TCP Stream의 패킷 내용을 RAW로 저장한 다음,
그 안에서 초반 ~ 0A 0D 0A 0D 까지를 싹 다 지운 데이터를 사용하여 이어붙이기를 반복했었다.
(이유는 이전에 어떤 다른 문제에서 그런식으로 패킷내용으로부터 데이터를 카빙하는 것을 보았기 때문)

근데 뭐가 문제인건지 그렇게 해서 이어붙이면 제대로된 파일이 만들어지지 않았다.
앞으로 자유롭게 손카빙 할 수 있을 정도의 실력이 되기 전까지는 가능한 preview...로 정신적 고통을 덜어야겠다ㅠ

+ Recent posts