#미완성 ## 개요 IPsec VPN은 대부분 GtoG(망대망) VPN에 주로 사용 GtoG (Gateway to Gateway), GtoE (Gateway to Endpoint), EtoE 지원 가능 --- # 메커니즘 ## **IKE 협상** ISAKMP 세션에서 송수신되는 패킷들은 모두 UDP 500을 사용한다. 그래서 IPsec VPN 장비 사이에 방화벽이 있으면 UDP 500은 허용해야 한다 >[!info] >* **IKE 제 1단계**는 ISAKMP 패킷을 보호하기 위한 보안 정책을 협상 >* **IKE 제 2단계** 실제 데이터를 보호하기 위한 IPsec 보안 정책 협상 ### **IKE 제 1단계** IKE 제 2단계에서 사용할 **ISAKMP SA를 결정**한다. 각 보안 알고리즘에서 사용할 **임시 키를 생성**하고 상대 장비를 **인증**하는 단계이다. 이 단계에서 사용할 수 있는 모드는 두가지다. 1. Main Mode 2. Aggressvie Mode #### **1. Main Mode** 6개의 패킷으로 협상 진행 ##### 1단계: 송신측 (R1) > 수신측 (R2): ISAKMP SA 제안 여기서 **ISAKMP SA**는 IKE 2단계에서 사용될 인증 방식, 암호화 알고리즘, 해싱 방식, 디피-헬만 알고리즘용 키 길이, ISAKMP SA 유효기간 등이 포함된다. ##### 2단계: 송신측 (R1) < 수신측 (R2): ISAKMP SA 선택 수신측은 **자신에게 설정되어 있는 ISAKMP SA**와 **제안받은 ISAKMP SA**를 비교해서 일치하는 SA를 송신측에게 전달하여 **둘 사이의 ISAKMP SA가 결정**된다 ##### 3단계: 송신측 (R1) > 수신측 (R2): 디피-헬만 키 교환 디피-헬만 알고리즘을 이용해 이후 과정에서 양측이 암호화 및 해싱에 사용할 공통된 키를 생성하는 과정이 시작된다. 이 과정을 설명하자면, R1은 자신의 공개키와 R1 자신이 임시로 만든 임시값을 R2에게 전달한다. 여기서 임시값은 R1 자신의 공개키와 개인키를 사용해서 만든거다 ##### 4단계: 송신측 (R1) < 수신측 (R2): 디피-헬만 키 교환 R2도 자신의 공개키와 R2가 자신의 공개키와 개인키를 사용해서 만든 임시값을 R1에게 전달한다. 이 다음, R1과 R2는 자신의 개인키와 상대에게서 수신한 공개키, 임시값을 사용해서 **동일한 대칭키**를 계산해내고 이것을 **패킷의 암호화 및 해시코드 계산용 키로 사용한다** ##### 5단계: 송신측 (R1) > 수신측 (R2): 인증 >[!info] >5단계부터는 1,2 단계에서 결정한 **암호화/해싱 알고리즘**과 3,4 단계에서 만들어낸 **계산한 키**를 사용하여 패킷을 암호화시키고, 무결성 확인용 해시코드르 만들어서 첨부한다. 한마디로 5단계 부터 서로 교환하는 패킷은 제3자가 해독하거나 변조할 수 없게된다. 5단계에서는 두 장비가 서로 **인증하는 절차**를 진행한다. R1은 자신의 ID와 인증정보를 R2에게 암호화해서 전송한다. 1. 이미 사전에 양측에 설정된 암호를 사용해서 PSK 방식으로 인증하는 경우, 자신의 ID와 암호를 이용해서 해시코드를 만들고 이를 전송한다. R2도 똑같이 동일하게 사전에 설정된 암호, Id, 동일한 알고리즘을 적용하여 해시코드를 만들고 전송한다. 이를 R1에게서 수신 해시코드와 비교하고 동일한 값이면 인증 성공이다 2. 만일 PSK가 아닌 디지털 인증서를 사용하도록 설정되어 있으면 인증 서버를 통해서 인증 과정을 거친다 ##### 6단계: 송신측 (R1) < 수신측 (R2): 인증 R2도 자신의 Id와 인증정보를 R1에게 암호화해서 전송함. R1은 R2와 동일한 해싱 알고리즘을 적용해서 해시코드를 계산한다. R2에게서 수신한 해시코드를 비교하고 동일한 값이면 인증 성공이다 --- #### **Aggressive Mode** 3개의 패킷으로 빠르게 IKE 제 1단계 협상을 끝내는 모드 >[!warning] >적은 수의 패킷으로 협상이 가능하지만 ID가 공격자에게 노출될 수 있다 ##### 1단계: 송신측 (R1) > 수신측 (R2) ISAKMP SA 선택, 디피-헬만 키 교환, ID, 인증 ##### 2단계: 송신측 (R1) < 수신측 (R2) ISAKMP SA 선택, 디피-헬만 키 교환, ID, 인증 ##### 3단계: 송신측 (R1) > 수신측 (R2) 인증 메세지 전송 --- ### **IKE 제 2단계** 실제 데이터 보호를 위한 보안정책 **IPsec SA**를 협상하는 단계이다. 이 단계에서 사용할 수 있는 모드는 한가지이다. #### **Quick Mode** ##### 1단계: 송신측 (R1) > 수신측 (R2) 실제 데이터를 보호하기 위한 보안 정책, IPsec SA를 제안한다. 여기에는 암호화/해싱 알고리즘, 보호대상 네트워크 정보, VPN 동작 모드, Encapsulation 방식 등이 포함된다 ##### 2단계: 송신측 (R1) < 수신측 (R2) R2는 자기가 지원 가능한 IPsec SA 세트를 선택해서 R1에게 알려준다 ##### 3단계: 송신측 (R1) > 수신측 (R2) R1은 R2가 동의한 IPsec SA에 대해서 수신확인 메세지를 보낸다 * 위와 같은 3단계까지 합쳐져 총 9단계를 거쳐 ISAKMP 세션 즉, IKE 세션이 완료된다 #숙제 Main mode or Aggressive mode. Quick mode로 송수신 된 패킷을 #wireshark 로 실습하여 확인해보기 --- ## 보안정책 적용한 실제 데이터 송수신 이제 IKE 제 2단계에서 협상된 보안 정책을 적용한 실제 데이터가 송수신된다. 이 단게에서 송수신되는 패킷을 인캡슐레이션하는 방식으로 ESP 혹은 AH가 사용된다 * ESP는 포트번호 50 사용 * AH는 포트번호 51 사용 IPsec VPN에서 Encapsulation(포장방식)은 보통 ESP를 사용한다 --- ## IPsec VPN 주요 구성 요소 ### IKE & ISAKMP IKE와 ISAKMP는 두 장비의 보안 통신을 위해서 데이터를 암호화하고 무결성을 확인하기 위한 **보안 프로토콜**을 협의하고 상대방이 악의적인 공격자가 아닌지 확인하기 위한 **인증 과정**을 거칠 수 있도록 하는 프로토콜이다. * ISAKMP는 위와 같은 절차를 명시하는 프로토콜 * IKE는 ISAKMP가 명시한 각 절차에 필요한 프로토콜의 종류와 사용법을 정의 >[!attention] IKE & ISAKMP 혼용 >두 개의 프로토콜을 규정하는 내용들이 서로 동일한 부분이 많고 관계도 애매해서 IKE 와 ISAKMP를 혼용해서 표현하는 경우가 많았지만, 2010년 RFC5996에서 IKE와 ISAKMP가 통합되었다. ### SA (Security Association) SA는 보안 통신을 위해 필요한 여러 가지 알고리즘 및 정책의 집합을 말한다. 예를 들어, ISAKMP 프로토콜을 암호화하기 위해 AES 암호화 방식을 사용하고 무결성 확인을 위해 MD5 알고리즘을 사용한다고 정한 약속(보안 정책)의 집합을 **ISAKMP SA**라고 한다. * 보안 연결 설정을 위한 매개변수를 협상 * SA는 IPsec 통신에서 사용할 암호화 알고리즘, 키 교환 방법, 인증 방식 등을 정의 * 암호화/무결성 확인 알고리즘의 종류, 보호대상 네트워크 등의 정보가 포함됨 ### ESP & AH 실제 데이터를 encapsulation시키고 보호하기 위한 프로토콜이다. #궁금증 IP AH + IP ESP 이 둘을 조합할 수 있다고 했다. 이와 관련 개념 확장이 가능하다??? #### AH (Authentication Header) AH는 암호화 기능이 없고 무결성 확인 기능만 지원된다. ##### 포멧 1. Next Header - AH 헤더 바로 다음의 프로토콜 종류를 표시해줌 2. SPI (security parameter index) - 목적지 IP 주소와 조합하여 현재 패킷의 SA 값을 표시하는 32비트 데이터 - 암호화시키지 않는다 3. 순서번호 (sequence number) - 각 패킷마다 1씩 증가하는 순서번호 - 패킷의 재생방지가 목적 - 32비트 - 암호화시키지 않는다 4. ICV (integrity check value) - 데이터 변조 확인을 위해 추가하는 해시 코드 값 5. 데이터 - 보호의 대상이 되는 원래 IP 패킷이 위치 #### ESP (Encapsulation Security Payload) 데이터를 **암호화**하고 무결성 확인하는 기능이 있다 ##### 포멧 1. SPI (security parameter index) - 목적지 IP 주소와 조합하여 현재 패킷의 SA 값을 표시하는 32비트 데이터 - 암호화시키지 않는다 2. 순서번호 (sequence number) - 각 패킷마다 1씩 증가하는 순서번호 - 패킷의 재생방지가 목적 - 32비트 - 암호화시키지 않는다 3. 데이터 - 보호의 대상이 되는 원래 IP 패킷이 위치 4. Padding - 사용된 암호화 알고리즘에 따라 필요한 크기를 맞춰주기 위해 추가하는 의미없는 데이터 5. Padding Length - 패딩의 길이를 바이트 단위로 표시 - 8비트 6. Next Header - ESP 헤더 바로 다음의 프로토콜 종류를 표시해줌 7. ICV (integrity check value) - 데이터 변조 확인을 위해 추가하는 해시 코드 값. 패킷 인증과 무결성 확인을 위해 사용하는 알고리즘에 따라 길이가 변하기 때문에 기본적으로는 가변적인 길이다 --- ## VPN 동작 모드 IPsec VPN은 원래의 데이터 패킷에 VPN 장비가 필요로 하는 새로운 IP 헤더를 추가할 필요가 있는지 여부에 따라 **Transport mode** 혹은 **Tunnel mode**로 구분할 수 있다 ### Transport mode 종단 장비 사이에 직접 IPsec VPN을 이용한 통신을 하는 경우 Transport mode를 기본적으로 사용하고 Tunnel mode도 사용이 가능하다 ### Tunnel mode 종단 장비들의 전송 경로 사이에 있는 IPsec VPN 게이트웨이를 거쳐서 통신하는 경우 Tunnel mode 사용이 일반적이다 이 모드에서 종단 장비들은 IPsec VPN 관련 처리는 VPN Gateway에서 이루어지므로 VPN의 존재를 인식하지 못한다 >[!note] >순수 IPsec VPN이 아닌 [[GRE IPsec]]이나 [[DMVPN]]의 경우에는 원래 패킷 앞에 GRE 헤더가 첨부된 다음 암호화되므로 종단 장비의 L3 헤더가 노출되지 않는다. 그래서 이런 경우에는 Tunnel mode 말고 Transport mode를 사용하면 20바이트의 오버헤드를 줄일 수 있다고 한다 --- ## 미정리 및 메모 ``` R1#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 209.165.201.6 209.165.201.1 QM_IDLE 1001 ACTIVE ``` * Phase 1과 Phase 2 모두 완료, 현재는 IPSec 트래픽을 전송할 준비가 완료된 상태. * Quick Mode 완료 후 IDLE 상태는 인증 성공을 의미 ### NAT-T IPsec 장비들 사이에 NAT 장비가 있을 때 자동으로 퀵 모드의 ISAKMP 패킷과 ESP 패킷을 Encapsulation하여 UDP 4500번으로 전송하는 것을 말한다 ---