1. IPsec 운용 모드 구분
IPsec 프로토콜을 운용하는 방식은 Transport 모드와 Tunnel 모드, 2가지가 있습니다. 이전 포스트 (https://citizen.tistory.com/44)의 마지막 섹션에서도 다룬 바 있으며, 이를 요약하면 다음과 같습니다.
Transport mode:
- 상위 프로토콜 데이터를 보호
- 원래 IP header를 그대로 유지
- 대표적인 사용처:
Telnet
Tunnel mode:
- IP 패킷 전체를 보호
- Host의 정보가 드러나지 않도록 새로운 IP header를 생성
- 대표적인 사용처:
VPN
이번 글에서는 각각의 모드에 따라 IPsec session이 만들어지는 과정을 실제 IPsec 패킷 분석을 통해 정리해보고자 합니다.
2. 공통 프로세스
2-1. IKE Phase 1
IKE Phase 1은 IPsec 보안 채널을 생성하기 위한 초기 파라미터들을 교환하는 단계로 Wireshark 등으로 패킷을 뜯어보면 인증, 암호화, 해싱 알고리즘 등의 정보를 확인해볼수 있습니다.
https://www.cloudshark.org/captures/ff740838f1c2
CS Enterprise on cloudshark.org
www.cloudshark.org
IKE phase 1 Tunnel 개시 요청/응답
위 링크에서 제공된 첫번째 패킷은 192.168.12.1의 IP를 가진 Host가 192.168.12.2에게 보내는 보안 채널 생성 요청에 해당합니다. IKE (Internet Key Exchange), 정확히는 ISAKMP (Internet Security Association and Key Management Protocol)에 의해 UDP 포트 500번으로 *해당 패킷이 전달되며, 보안 채널을 개시한 호스트 측의 식별번호 *Initiator SPI (e47a591fd057587f)라는 것을 명시해주고 있습니다.
페이로드 내용을 좀 더 살펴보면, 위에서 2번째 그림처럼 채널 개시자가 제안한 각종 보안 파라미터를 확인 가능합니다. 초기에 제시된 이 7가지 옵션들은 상대 호스트 측의 수용 가능 여부에 따라 조정될 수 있으며, 상대 호스트는 IPsec 채널 개시에 문제가 없을 경우 아래와 같은 메시지로 응답합니다.
응답 패킷에 아까는 볼 수 없던 Responder SPI (a00b8ef0902bb8ec) 필드값이 채워진 것을 확인할 수 있습니다.
1차 보안키 교환
IPsec 보안키 생성 과정은 이중화되어 있습니다. 데이터를 암호화하는 보안 키 정보를 냅다 패킷으로 날려보리면 해당 패킷이 경유하는 지점에서 누구나 그 키를 볼 수 있기 때문에 암호화를 하는 의미가 상실되죠. 그래서 IPsec은 진짜로 사용될 암호화 키를 안전하게 전송하기 위해서 1차 비밀번호와 같은 키를 먼저 만들어 내는 것입니다.
집 비밀번호를 남들도 있는 자리에서 공개적으로 이야기할 수는 없으니, 상대방과 1:1로만 만날 수 있는 비밀스러운 자리를 마련해서 집 비밀번호를 알려주는 셈입니다.
다시 패킷 덤프 파일로 돌아와, IKE 터널 개시 확정 이후에 나타나는 패킷은 앞서 이야기한 1차 보안키를 교환하는 과정을 담고 있습니다. 터널 개시자(192.168.12.1)가 우선 Diffie Hellman key와 Nonce 값을 전달하고, 곧이어 상대 호스트(192.168.12.2) 역시 key 정보를 공유하게 됩니다.
이제 두 호스트는 공유키를 계산하여 페이로드를 암호화/복호화할 수 있게 되었습니다.
상호 인증 과정
뒤이어 오는 패킷들도 동일하게 터널 개시자 → 상대 호스트 순으로 메시지 전달이 이뤄집니다. 이 단계에서는 상호 인증이 이뤄지며, 이제부터는 페이로드 데이터가 암호화되어 내부 메시지를 확인해 볼 수 없습니다. 아래 그림처럼 패킷의 프로토콜 스택 정보를 보면 Encrypted Data라고만 표시될 뿐, 그 내용은 열어볼 수 없죠.
일단 지금까지가 IKE Phase 1 과정이였고, 이후 프로세스들은 이보다는 상당히 간단하게 지나갑니다.
2-2. IKE Phase 2
IKE Phase 2는 이제 실질적으로 유저 데이터를 암호화하기 위한 파라미터들을 교환합니다. Phase 1때와 동일하게 새로운 키를 발급하고 인증하는 과정이므로 비슷한 내용들이 호스트간에 오고가지만, 이미 Phase 1을 통해 1차 보안 채널이 활성화된 상태라 페이로드에서 Phase 2에 관련된 내용들을 확인할 수 없습니다.
중간자가 눈으로 볼 수 없으나, IKE Phase 2에서는 이러한 키 파라미터 외에 IPsec Protocol 종류 (AH/ESP) 그리고 Encapsulation Mode (Transport/Tunnel) 가 추가적으로 논의됩니다.
Wireshark Info 열에서는 Quick Mode라고 표시가 되고, 프로토콜 스택 정보 창에는 역시 Encrypted Data라는 표시만 남겨져 있습니다.
여기까지는 모든 IPsec 통신이 공통적으로 거치는 패킷 교환 과정을 서술하였으며, 이후의 단계는 Phase 2에서 결정된 Encapsulation Mode(Transport/Tunnel)에 따라 분기가 일어납니다.
3. Transport 모드의 IPsec 패킷 교환
IPsec 채널을 통해 데이터를 보내려면 IPsec Protocol 헤더를 추가적으로 패킷에 붙여주어야 하며, 크게 2가지 옵션이 제공됩니다.
- AH (Authentication Header): 호스트간 상호 인증만 제공
- ESP (Encapsulating Security Payload): 상호 인증과 기밀성(페이로드 암호화) 제공
아래 샘플 pcap 파일들을 참고하여 각각의 헤더에 따라 달라지는 패킷 구조를 살펴봅시다.
https://www.cloudshark.org/captures/9c563cd2501e
CS Enterprise on cloudshark.org
www.cloudshark.org
https://www.cloudshark.org/captures/4d1561a5935f
CS Enterprise on cloudshark.org
www.cloudshark.org
3-1 AH 헤더를 사용할 경우
구조적으로는 IP 헤더와 데이터 페이로드 사이에 AH 헤더가 쏙 들어가는게 전부입니다. 제가 드린 예시는 ICMP 데이터에 AH 헤더를 붙여 Transport 모드로 전달하는 트래픽 플로우에 해당합니다.
AH 헤더의 구성요소를 살펴보면,
- Next Header: Data 영역에 해당하는 프로토콜 정보입니다. TCP(6)나 UDP(17)가 주로 들어가지만 위와 같이 ICMP(1)가 데이터로 이어지기도 하며, 또 때로는 터널링이 2중, 3중으로 겹겹이 쌓인 경우에는 IPsec 데이터가 뒤따르기도 합니다.
- Length: AH 헤더의 길이입니다.
- Reserved: 추후 특수한 목적으로 사용 예정인 필드로, 초기에는 ‘0’으로 채워집니다.
- AH SPI (Security Parameters Index): 어떤 IPsec 채널을 통해 전달된 패킷인지를 구분하는 식별자입니다.
- AH Sequence: 재전송 공격(Replay attack)을 방지하기 위한 필드로, 다음 패킷이 생성될때마다 1씩 값이 증가합니다.
- AH ICV (Integrity Check Value): 패킷의 무결성을 확인하기 위한 해시값으로 구성된 필드입니다.
3-2 ESP 헤더를 사용할 경우
이 경우에는 IP 헤더와 Data 사이에 ESP 헤더가 추가될 뿐만 아니라, Data 뒷부분에 ESP trailer와 ESP Auth라는 파트가 더 따라붙게 됩니다.
ESP 헤더도 AH 헤더와 마찬가지로 Next Header, Length, SPI 등등 기본적인 구성요소를 갖추고 있으며, 여기에 추가적으로 ESP Trailer의 길이를 나타내는 Pad Length가 포함됩니다. ESP Auth는 Data 영역과 ESP Trailer에 대한 인증정보를 담당하는 구역입니다.
ESP 프로토콜을 사용하게 되면, IP header를 제외한 나머지는 모두 암호화되기 때문에 Wireshark에서도 Protocol 열에 ESP라고만 표시되고, 필드 정보도 거의 아무것도 안 알려주다시피 합니다. 그나마 IP 정보가 살아있기에 어떤 호스트들이 몰래 데이터를 주고 받는 중인지는 찾아낼 수 있죠.
4. Tunnel 모드의 IPsec 패킷 교환
Tunnel 모드는 새로운 IP 헤더를 패킷에 추가하여 호스트에 대한 식별을 어렵게 만듭니다. Tunnel 모드의 패킷 구조 역시 AH 헤더를 사용하냐, ESP 헤더를 사용하냐에 따라 나뉘게 되는데요. 전체 구조는 Transport 모드 때와 비교하였을 때, 새로운 IP 헤더가 앞에 붙는 것 이외에는 크게 차이가 없습니다.
https://www.cloudshark.org/captures/4d1561a5935f
CS Enterprise on cloudshark.org
www.cloudshark.org
https://www.cloudshark.org/captures/58006657c867
CS Enterprise on cloudshark.org
www.cloudshark.org
4-1 AH 헤더를 사용할 경우
바로 위에 첨부된 1번째 링크를 열어보면 3-1에서와 비슷하게 ICMP 패킷들이 나열될텐데요. 그러나 AH 헤더 필드 부분을 자세히 보면, Next header 부분이 이번에는 살짝 다르게 IPIP(4)로 표기되어 있습니다.
이는 AH 헤더 뒤에 IP 헤더가 추가적으로 붙고, 그 이후에서야 Data 영역에 해당하는 ICMP 헤더와 페이로드가 나타나게 될 것을 의미합니다. 그래서 프로토콜 스택 정보 창에서 상단(3번째 줄)에 나오는 IP Src, Dst 정보는 사실상 가짜이고, 뒤이어 5번째 줄에 나오는 IP Src, Dst 정보가 실제 호스트들의 IP 주소입니다 (다만, 본 예제에서는 아쉽게도 Fake IP도 기존과 동일하게 설정해놨네요).
4-2 ESP 헤더를 사용할 경우
ESP 헤더를 사용한 Tunnel 모드는 VPN 통신에 아주 최적화된 구조입니다. 데이터도 암호화해주고 기존 IP 헤더도 갈아치워주기 때문입니다.
IPSec 헤더는 구간 간 이동에 대한 정보만 있으므로 실제 패킷의 출발지와 목적지에 해당하는 종단 정보와 트래픽 경로는 확인하기 어렵습니다.
