벌써 이번 주가 스터디 마지막 주라니 믿기지가 않는다. 그런 의미에서 마지막장 정리를 시작해보자.
1. 와이어샤크를 통한 프로토콜 분석
1.1. 와이어샤크
1.2. 프로토콜 분석
1.2.1. IP 분석
1.2.2. IPv6 단편화 + UDP
1.2.3. TCP 분석
1.2.4. TCP 재전송
1.2.5. HTTP 분석
2. 네트워크 심화
2.1. 안정성을 위한 기술
2.1.1. 가용성
2.1.2. 이중화
2.1.3. 로드 밸런싱
2.2. 안전성을 위한 기술
2.2.1. 암호와 인증서
2.2.2. 인증서와 디지털 서명
2.2.3. HTTPS : SSL과 TLS
2.2.3.1. TLS 기반으로 HTTPS가 동작하는 방법
1. 와이어샤크를 통한 프로토콜 분석
해당 단원과 관련된 문제는 아래와 같다.
다음은 호스트 A와 B 간의 쓰리 웨이 핸드셰이크 과정에서 호스트 A가 호스트 B에게 전송한 첫 번째 SYN 세그먼트의 일부입니다. 쓰리 웨이 핸드셰이크상에서 호스트 B가 호스트 A에게 전송할 다음 세그먼트의 Acknowledge number(raw)는 무엇일까요?
정답은 3588415413이다. 이유를 알아보기 위해 와이어샤크에 대해 알아보자.
1.1. 와이어샤크
와이어샤크는 패킷 캡처 프로그램 중 하나로, 필터를 이용해 캡처한 패킷을 필터링 할 수 있다.
(++ 패킷 캡처 : 네트워크에서 송수신되는 패킷을 모니터링 및 분석 가능한 프로그램)
1.2. 프로토콜 분석
분석할 파일은 총 6가지이다.
1.2.1. IP 분석
= ipv4-fragmentation 파일을 열면 IPv4 단편화 과정과 ICMP 패킷 파일을 확인할 수 있다.
= 각 패킷의 Internet Protocol Version 4 항목을 확인하면 송신지 IP 주소, 수신지 IP 주소 필드로 주소 지정이 이루어짐을 확인할 수 있다.
= 패킷의 식별자 값을 통해 하나의 데이터 덩어리에서 단편화된 것인지 확인할 수 있다.
= MF 플래그의 활성화 여부로 단편화된 패킷인지 확인할 수 있다. (활성화될 경우 더 이상 단편화된 패킷 존재한다는 것 의미)
= 패킷의 단편화 오프셋을 통해 초기 데이터로부터 얼마나 떨어져 있는지 확인할 수 있다.
= ICMP 패킷이 포함된 패킷을 확인할 경우, 패킷의 타입과 코드를 통해 어떤 메세지인지 확인할 수 있다.
1.2.2. IPv6 단편화 + UDP
= 패킷의 Internte Protocol Version 6를 보면 송신지와 수신지의 IPv6 주소를 확인할 수 있다.
= 패킷의 단편화 확장 헤더가 없을 경우 NExt Header 필드는 UDP를 가리킬 수 있다.
= 단편화되어 전송된 패킷은 단편화 확장 헤더가 포함되어 있다.
=> 단편화 확장 헤더를 통해 캡슐화된 UDP를 가리키는 다음 헤더, 같은 값을 공유하는 식별자, 얼마나 떨어진 데이터인지 확인하는 오프셋 값을 확인할 수 있다.
= User Datagram Protocol을 통해 UDP 데이터그램의 송신지 포트, 수신지 포트, UDP 데이터 그램의 바이트 단위를 확인할 수 있다.
1.2.3. TCP 분석
= 3-way-handshake 파일을 열면 TCP 연결 수립 과정을 살펴볼 수 있다.
= 송신지 포트 번호, 수신지 포트 번호를 확인할 수 있다.
(해당 포트들이 동적 포트인지 여부도 확인할 수 있다.)
= 와이어샤크 임의의 상대적 순서 번호와 실재 순서 번호를 확인할 수 있다.
= SYN 플래그값을 통해 쓰리 웨이 핸드셰이크를 시작하는 세그먼트를 확인할 수 있다.
= 패킷에 대한 확인 응답 번호를 통해 당므으로 받기를 기대하는 순서 번호를 확인할 수 있다.
= 두 번째 패킷의 확인 응답 번호인 순서 번호를 확인함으로써 ACK 세그먼트를 확인할 수 있다.
= connection-close 파일을 통해 TCP 연결 종료 과정을 확인할 수 있다.
= FIN 비트, ACK 비트가 설정된 세그먼트가 전송되는 것을 통해 연결 종료되는 과정을 확인할 수 있다.
1.2.4. TCP 재전송
= tcp-retransmission파일을 통해 TCP 재전송 과정을 확인할 수 있다.
= 순서 번호와 확인 응답 번호와 ACK 세그먼트들을 통해 현재 통신 상황과 그에 따른 결과들을 확인할 수 있다.
(++ tcp.analysis.retransmission 필터 사용시 재전송된 패킷을 필터링할 수 있고, tcp.analysis.fast_retransmission 필터 사용 시 빠른 재전송에 해당하는 패킷을 필터링할 수 있다.)
(++ tcp.analysis.duplicate_ack 필터 사용시 중복된 ACK 세그먼트를 필터링할 수 있다.
1.2.5. HTTP 분석
= http-request-response 파일을 통해 HTTP 요청과 응답 헤더의 분석을 할 수 있다.
= 요청을 보낸 호스트, 경로, 요청에 사용된 HTTP 메서드를 확인할 수 있다.
= 해당 패킷에 대한 HTTP 응답 결과도 확인 가능하다.
2. 네트워크 심화
해당 챕터에 대한 문제를 풀어보자.
다음 그림은 두 호스트가 TLS 1.3 핸드셰이크를 수행하는 과정을 나타낸 그림 일부입니다. 괄호 안에 들어갈 TLS 관련 메세지로 알맞은 말을 골라 보세요.
1) Application Data
2) ARP Request
3) ServerHello
4) Finished
정답은 3) ServerHello이다. 이유를 알아보기 위해 해당 단원에 대한 내용을 공부해보자.
2.1. 안정성을 위한 기술
2.1.1. 가용성
= 안정성은 특정 기능을 언제든 균일한 성능으로 수행할 수 있는 특성이다.
= 가용성은 안정성을 수치화한 정도로, 컴퓨터 시스템이 특정 기능을 실제로 수행할 수 있는 시간의 비율이다.
(전체 사용 시간 중에서 정상적인 사용 시간이다.
가용성 = 업타임 / (업타임 + 다운타임)
(업타임 : 정상적인 사용 시간, 다운타임 : 정상적인 사용이 불가능한 시간)
= 고가용성(HA)은 해당 식의 결과값이 커서 전체 사용 시간 중 대부분을 사용가능하다는 의미이다.
= 다운타임의 발생 원인을 모두 차단하기는 어렵기 때문에 문제가 발생하더라도 계속 기능할 수 있는 결함 감내 능력이 좋아야 한다.
2.1.2. 이중화
= 이중화는 무언가를 이중으로 두는 기술로, 결함을 감내하여 가용성을 높이기 위한 가장 기본적이고 대표적인 방법이다.
= 대부분 문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상(단일 장애점, SPOF)이라는 공통점이 있다.
(++ 물리적 장비 뿐만 아니라 DB, 웹 서버 프로그램 등도 이중화할 수 있다.)
= 구성은 액티브/스탠바이와 액티브/액티브로 나뉜다.
(액티브 : 가동 상태, 스탠바이 : 액티브의 백업으로 대기하는 상태)
= 액티브/스탠바이는 한 시스템은 가동하고 다른 시스템은 백업 용도로 두는 이중화 구성 방식이다.
(안전한 구성 방식이지만, 하나의 장비를 사용할 때에 비해 성능상 큰 변화를 기대하기 어렵다.)
(++ 페일오버는 액티브 시스템에 문제가 생겼을 경우 예비된 스탠바이 시스템으로 자동 전환되는 기능이다.)
= 액티브/액티브는 두 시스템 모두를 가동 상태로 두는 구성 방식이다.
= 부하 분산이 가능하고 성능상 이점도 있다.
= 한 시스템에 문제 발생 시 순간적으로 다른 시스템에 부하가 급증할 수 있으며, 이로 인해 추가적인 문제가 발생할 수 있다.
= 다중화는 무언가를 여러 개 두는 기술로, 이중화된 구성에 비해 안정적이다.
= 티밍(윈도우), 본딩(리눅스)는 여러 개의 네트워크 인터페이스를 이중화/다중화하여 마치 더 뛰어나고 안정적인 성능을 보유한 하나의 인터페이스처럼 보이게 하는 기술이다.
2.1.3. 로드 밸런싱
= 로드 밸런싱은 로드 밸런서에 의해 수행되며, 트래픽의 고른 분배를 위해 사용된다.
(++ 트래픽은 주어진 시점에 네트워크를 경유한 데이터의 양이다.)
(++ 서버를 다중화해도 트래픽을 고르게 분산해야 가용성이 높아진다.)
= 로드 밸런싱은 로드 밸런서에 의해 수행된다.
= 로드 밸런서는 일반적으로 이중화/다중화된 서버와 클라이언트 사이에 위치한다.
= 클라이언트는 로드 밸런서에 요청을 보내고, 로드 밸런서는 해당 요청을 서버에 균등하게 분배한다.
= 헬스 체크를 통해 서버의 건강 상태를 주기적으로 모니터링하고 체크한다.
= 서버 간 하트비트를 주고받아 신호가 끊겼을 때 문제 발생을 감지하도록 도운다.
= 로드 밸런싱 알고리즘의 종류는 대표적으로 라운드 로빈 알고리즘, 최소 연결 알고리즘 등이 있다.
= 라운드 로빈 알고리즘은 서버를 돌아가며 부하를 전달한다.
= 최소 연결 알고리즘은 연결이 적은 서버부터 우선적으로 부하를 전달한다.
= 단순히 무작위적으로 고르는 방법도 있다.
= 해시 또는 응답 시간이 가장 짧은 서버를 선택하기도 한다.
= 서버마다 가중치를 부여하는 알고리즘은 가중치 라운드 로빈 알고리즘, 가중치 최소 연결 알고리즘 등이 존재한다.
++ 오리진 서버는 자원을 생성하고 클라이언트에게 권한 있는 응답을 보낼 수 있는 HTTP 서버이다. (클라이언트와 오리진 서버 사이 중간 서버가 존재한다.)
(++ 중간 서버는 대표적으로 프록시, 게이트웨이가 있다.)
++ 프록시는 클라이언트가 선택한 메세지 전달대리자로, 클라이언트에 오리진 서버보다 더 가까이 위치한다.
(캐시 저장, 클라이언트 암호화, 접근 제한 등의 기능을 제공한다.)
++ 게이트웨이는 네트워크 간 통신을 가능케 하는 입구 역할을 하는 하드웨어/소프트웨어이다.)
2.2. 안전성을 위한 기술
= 암호화는 원문 데이터를 알아볼 수 없는 형태로 변경한느 것이다.
= 복호화는 암호화된 데이터를 원문 데이터로 되돌리는 과정이다.
2.2.1. 암호와 인증서
= 대칭 키 암호화는 암호화와 복호화에 동일한 키를 사용한다.
= 상대방에게 안전한 키 전달이 어렵다.
= 부하가 적어서 암호화와 복호화를 빠르게 수행할 수 있다.
= 공개 키 암호화(비대칭 키 암호화)는 암호화를 위한 키와 복호화를 위한 키가 다르다.
(++ 각각 공개 키, 개인 키라고 부른다.)
= 시간과 부하가 상대적으로 많이 들지만 키를 안전하게 공유할 수 있다.
=> 해당 문제를 해결하기 위해 대칭 키 암호화와 공개 키 암호화를 함께 사용한다.
2.2.2. 인증서와 디지털 서명
= 공개 인증서는 공개 키와 공개 키의 유효성을 입증하기 위한 전자 문서이다.
= 공개키를 생성한 사람, 유효 기간, 조작 여부 등의 내용을 포함한다.
= 인증 기관(CA)에서 서명 값을 넣어 발급한다.
(++ 서명 값은 인증서 내용의 해시 값을 CA의 개인 키로 암호화하는 방식으로 만들어진다.)
= 디지털 서명(개인 키로 암호화된 메세지를 공개 키로 복호화)을 통해 신원을 증명할 수있다.
2.2.3. HTTPS : SSL과 TLS
= SSL과 TLS는 인증과 암호화를 수행하는 프로토콜이다.
(++ TLS는 SSL을 계승했다.)
= HTTPS는 SSL/TLS를 사용하는 대표적인 프로토콜로, HTTP 메세지의 안전한 송수신을 위해 개발된 프로토콜이다.
2.2.3.1. TLS 기반으로 HTTPS가 동작하는 방법
순서는 아래와 같다.
1) TCP 쓰리 웨이 핸드셰이크
2) TLS 핸드셰이크
3) 암호화된 메세지 송수신
= 1)은 TCP 연결을 수립하기 위해 두 호스트가 각각 SYN, SYN_ACK, ACK 플래그가 설정된 TCP 세그먼트를 주고받는 것이다.
= 2)는 암호화 통신을 위한 키를 교환하고, 인증서 송수신과 검증이 이루어진다는 것이 특징이다.
= 클라이언트는 ClientHello 메세지를 보내 암호화된 통신을 위해 서로 맞춰봐야 할 정보를 제시한다.
(++ 암호 스위트(사용 가능한 암호화 방식과 해시 함수를 담은 정보)를 사용한다.)
= 서버는 응답으로 ServerHello를 전송해 암호화된 통신을 위해 사전 협의해야 할 정보들이 결정된다.
= 위와 같이 TLS 핸드셰이크에서의 키 교환 과정을 통해 암호화에 사용할 키를 생성한다.
= 서버는 Certificate(인증서), CertificateVerify(검증을 위한 디지털 서명) 메세지를 전송한다.
(위 과정으로 서버의 공개 키를 검증하게 된다.)
= 마지막으로 Finished 메세지를 전송한다.
= 이제 TLS 핸드셰이크를 통해 얻은 키를 기반으로 암호화된 데이터를 전송한다.
후기는 마지막 스터디 후기로 다음 게시글에 작성하겠다.