IPsec (Internet Protocol Security)

학습 목차

IKE (Internet Key Exchange) 1.1. IKE Phase 1 1.1.1. Main Mode 1.1.2. Aggressive Mode 1.2. IKE Phase 2
IPsec 프로토콜 2.1. Authentication Header 프로토콜 2.2. ESP (Encapsulating Security Payload) 프로토콜 2.3. AH와 ESP
결론

IPsec(Internet Protocol Security) 는 네트워크 계층에서 IP 트래픽을 보호하는 데 도움이 되는 프레임워크입니다. 왜? IP 프로토콜 자체에는 보안 기능이 전혀 없기 때문입니다. IPsec은 다음과 같은 기능으로 트래픽을 보호할 수 있습니다.

기밀성(Confidentiality): 데이터를 암호화함으로써, 송신자와 수신자 외에는 누구도 데이터를 읽을 수 없습니다.
무결성(Integrity): 패킷의 데이터가 변경되지 않았는지 확인합니다. 해시 값을 계산함으로써, 송신자와 수신자는 패킷이 변경되었는지 확인할 수 있습니다.
인증(Authentication): 송신자와 수신자가 서로 인증해, 우리가 정말로 의도한 장치와 통신하고 있는지 확인합니다.
재전송 방지(Anti-replay): 패킷이 암호화되고 인증되더라도, 공격자가 이 패킷을 캡처해 다시 전송하려고 할 수 있습니다. 시퀀스 번호를 사용함으로써, IPsec은 중복 패킷을 전송하지 않습니다.

프레임워크로서 IPsec은 위에서 설명한 기능을 구현하기 위해 다양한 프로토콜을 사용합니다. 다음은 개요입니다.

위 그림에 보이는 모든 박스에 대해 걱정하지 마세요. 각각을 다룰 것입니다. 예를 들어, 암호화에는 DES, 3DES 또는 AES 중 어느 것을 사용할지 선택할 수 있습니다. 인증에는 MD5 또는 SHA 중에서 선택할 수 있습니다.

IPsec은 라우터, 방화벽, 호스트, 서버 등 여러 장치에서 사용할 수 있습니다. 사용 예시는 다음과 같습니다.

두 라우터 사이에서 두 LAN을 “브릿지”하는 사이트 간 VPN을 만들기 위해.
원격 접속 VPN을 위한 방화벽과 Windows 호스트 사이.
Telnet 같은 안전하지 않은 프로토콜을 보호하기 위한 두 Linux 서버 사이.

IPsec은 매우 복잡하고 구현 방법도 많습니다. 이 강의에서는 개요부터 시작한 다음 각 구성 요소를 자세히 살펴보겠습니다.

IP 패킷을 보호하기 전에, IPsec 터널을 구축하는 두 IPsec 피어가 필요합니다.

IPsec 터널을 구축하기 위해 IKE(Internet Key Exchange) 프로토콜을 사용합니다.

IPsec 터널을 구축하는 데는 두 단계가 있습니다.

IKE Phase 1
IKE Phase 2

IKE phase 1에서, 두 피어는 사용할 암호화, 인증, 해싱 및 기타 프로토콜과 필요한 다른 매개변수에 대해 협상합니다. 이 단계에서 ISAKMP(Internet Security Association and Key Management Protocol) 세션이 설정됩니다. 이를 ISAKMP 터널 또는 IKE phase 1 터널이라고도 합니다.

두 장치가 사용할 매개변수의 모음을 SA(Security Association) 라고 합니다.

IKE phase 1 터널은 관리 트래픽에만 사용됩니다. 이 터널을 두 번째 터널인 IKE phase 2 터널(또는 IPsec 터널)과 keepalive 같은 관리 트래픽을 설정하는 안전한 방법으로 사용합니다.

IKE phase 2가 완료되면, 사용자 데이터를 보호하는 데 사용할 수 있는 IKE phase 2 터널(또는 IPsec 터널)이 있습니다. 이 사용자 데이터는 IKE phase 2 터널을 통해 전송됩니다.

IKE는 우리를 위해 터널을 구축하지만 사용자 데이터를 인증하거나 암호화하지 않습니다. 이를 위해 다른 두 프로토콜을 사용합니다.

AH (Authentication Header)
ESP (Encapsulating Security Payload)

AH와 ESP 모두 인증과 무결성을 제공하지만, ESP만 암호화를 지원합니다. 이 때문에 ESP가 요즘 가장 인기 있는 선택입니다.

두 프로토콜 모두 두 가지 모드를 지원합니다.

Transport 모드
Tunnel 모드

둘의 주요 차이는 transport 모드는 원본 IP 헤더를 사용하는 반면, tunnel 모드는 새 IP 헤더를 사용한다는 것입니다.

Transport 모드는 종종 안전하지 않은 트래픽(예: Telnet 트래픽)을 보호하려는 두 장치 사이에서 사용됩니다. Tunnel 모드는 일반적으로 사이트 간 VPN에 사용됩니다. 사이트 간 VPN에서는 원본 IP 패킷을 캡슐화해야 하는데, 대부분 사설 IP 주소이며 인터넷에서 라우팅될 수 없기 때문입니다.

IPsec의 전체 프로세스는 5단계로 구성됩니다.

Initiation(시작): 무언가가 터널 생성을 트리거해야 합니다. 예를 들어 라우터에서 IPsec을 구성할 때 access-list로 라우터에게 어떤 데이터를 보호할지 알려줍니다. 라우터가 access-list와 일치하는 것을 받으면 IKE 프로세스를 시작합니다. 수동으로 터널을 시작할 수도 있습니다.
IKE phase 1: IKE phase 1 터널(ISAKMP 터널)을 구축하기 위한 SA를 협상합니다.
IKE phase 2: IKE phase 1 터널 내에서 IKE phase 2 터널(IPsec 터널)을 구축합니다.
Data transfer(데이터 전송): IKE phase 2 터널을 통해 사용자 데이터를 전송하여 보호합니다.
Termination(종료): 보호할 사용자 데이터가 없으면 IPsec 터널은 잠시 후 종료됩니다.

1. IKE (Internet Key Exchange)

IKE(Internet Key Exchange) 는 두 피어 간의 SA를 설정하기 때문에 IPsec의 주요 프로토콜 중 하나입니다. IKE에는 두 가지 버전이 있습니다.

IKEv1
IKEv2

IKEv1은 1998년경에 도입되었고 2005년에 IKEv2로 대체되었습니다. 두 버전 사이에는 몇 가지 차이가 있습니다.

IKEv2는 IKEv1보다 적은 대역폭을 필요로 합니다.
IKEv2는 EAP 인증을 지원합니다(사전 공유 키와 디지털 인증서 외에).
IKEv2는 NAT 통과를 위한 내장 지원이 있습니다(IPsec 피어가 NAT 라우터 뒤에 있을 때 필요).
IKEv2는 터널을 위한 내장 keepalive 메커니즘이 있습니다.

장점 목록은 계속되지만, 지금은 IKE 이해에 집중합시다. 앞서 설명했듯이 IKE는 두 단계를 사용합니다.

IKE Phase 1
IKE Phase 2

각 단계에서 무슨 일이 일어나는지 논의해 봅시다. 아래 설명은 모두 IKEv1에 적용됩니다.

1.1. IKE Phase 1

IKE phase 1의 주요 목적은 IKE phase 2에 사용할 수 있는 안전한 터널을 설정하는 것입니다.

Phase 1을 세 가지 간단한 단계로 나눌 수 있습니다.

Step 1: 협상(Negotiation)

보호해야 할 트래픽이 있는 피어가 IKE phase 1 협상을 시작합니다. 두 피어는 다음 항목에 대해 협상합니다.

Hashing: 무결성 확인을 위해 해싱 알고리즘을 사용합니다. MD5 또는 SHA를 사용합니다.
Authentication: 각 피어는 자신이 누구인지 증명해야 합니다. 두 가지 일반적인 옵션은 사전 공유 키 또는 디지털 인증서입니다.
DH (Diffie Hellman) group: DH 그룹은 키 교환 프로세스에 사용되는 키의 강도를 결정합니다. 그룹 번호가 높을수록 더 안전하지만 계산하는 데 더 오래 걸립니다.
Lifetime: IKE phase 1 터널이 얼마나 오래 유지되는가? lifetime이 짧을수록 더 안전합니다. 다시 구축한다는 것은 새 keying 자료를 사용한다는 의미이기 때문입니다. 각 벤더는 다른 lifetime을 사용하며, 일반적인 기본값은 86400초(1일)입니다.
Encryption: 암호화에 어떤 알고리즘을 사용하나요? 예를 들어 DES, 3DES 또는 AES.

Step 2: DH 키 교환

협상이 성공하면 두 피어는 어떤 정책을 사용할지 알게 됩니다. 이제 협상한 DH 그룹을 사용해 keying 자료를 교환합니다. 최종 결과는 두 피어가 공유된 키를 가지게 되는 것입니다.

Step 3: 인증

마지막 단계는 두 피어가 협상에서 합의한 인증 방법을 사용해 서로 인증하는 것입니다. 인증이 성공하면 IKE phase 1을 완료합니다. 최종 결과는 양방향인 IKE phase 1 터널(일명 ISAKMP 터널)입니다. 이는 두 피어가 이 터널에서 송신과 수신을 모두 할 수 있다는 의미입니다.

위의 세 단계는 두 가지 다른 모드를 사용해 완료할 수 있습니다.

Main mode
Aggressive mode

Main mode는 6개의 메시지를 사용하는 반면, aggressive mode는 3개의 메시지만 사용합니다. Main mode가 더 안전하다고 간주됩니다. 두 모드를 더 자세히 살펴봅시다.

1.1.1. Main Mode

IKEv1 main mode는 6개의 메시지를 사용합니다. Wireshark에서 이를 보여드리고 다양한 필드를 설명하겠습니다.

Message 1 (Initiator → Responder): 초기자(터널을 구축하려는 피어)가 첫 번째 메시지를 보냅니다. 이는 SA에 대한 제안입니다. 초기자(192.168.12.1)가 응답자(192.168.12.2)에게 제안을 보냅니다. IKE는 이를 위해 UDP 포트 500을 사용합니다.


Internet Security Association and Key Management Protocol
    Initiator SPI: fdf47a59ffd057587f
    Responder SPI: 0000000000000000
    Next payload: Security Association (1)
    Version: 1.0
    Exchange type: Identity Protection (Main Mode) (2)
    Type Payload: Security Association (1)
        Type Payload: Proposal (2) # 1
            Type Payload: Transform (3) # 1
                Encryption-Algorithm : AES-CBC
                Key-Length : 128
                Hash-Algorithm : SHA
                Group-Description : Alternate 1024-bit MODP group
                Authentication-Method : PSK
                Life-Type : Seconds
                Life-Duration : 86400

위 출력에는 initiator SPI(Security Parameter Index) 가 보이는데, 이는 이 SA를 식별하는 고유한 값입니다.

Message 2 (Responder → Initiator): 응답자가 초기자로부터 첫 번째 메시지를 받으면 응답합니다. 이 메시지는 transform payload의 속성에 동의함을 초기자에게 알리는 데 사용됩니다. 응답자가 자신의 SPI 값을 설정한 것도 볼 수 있습니다.

Message 3 (Initiator → Responder): 피어가 사용할 SA에 동의했으므로, 초기자는 Diffie Hellman 키 교환을 시작합니다. key exchange와 nonce에 대한 payload를 볼 수 있습니다.

Message 4 (Responder → Initiator): 응답자도 자신의 Diffie Hellman nonce를 초기자에게 보내, 두 피어가 이제 Diffie Hellman 공유 키를 계산할 수 있습니다.

Message 5, 6: 마지막 두 메시지는 암호화되어 있어 더 이상 내용을 볼 수 없습니다. 이 두 메시지는 각 피어의 식별과 인증에 사용됩니다. 초기자가 시작합니다.


Length: 108
Encrypted Data (80 bytes)

IKEv1 main mode가 이제 완료되었고 IKE phase 2를 계속할 수 있습니다.

1.1.2. Aggressive Mode

IKEv1 aggressive mode는 SA를 설정하는 데 단 세 개의 메시지만 필요합니다. main mode보다 빠릅니다. 처음 두 메시지에서 DH 교환에 필요한 모든 정보를 추가하기 때문입니다.

Main mode가 더 안전하다고 간주되는데, 식별이 암호화되기 때문입니다. Aggressive mode는 이를 평문으로 수행합니다.

Message 1 (Initiator → Responder): 첫 번째 메시지에서 초기자가 transform payload(SA 속성), DH nonce, 그리고 (평문으로) 식별을 한 메시지에 모두 포함시켜 보냅니다.

Message 2 (Responder → Initiator): 응답자는 이제 DH 공유 키를 생성하는 데 필요한 모든 것을 가지고 있고, 초기자도 DH 공유 키를 계산할 수 있도록 nonce를 보냅니다. 인증에 사용되는 해시도 계산합니다.

Message 3 (Initiator → Responder): 두 피어 모두 필요한 모든 것을 가지고 있고, 초기자의 마지막 메시지는 인증에 사용되는 해시입니다.

이제 IKE phase 1 터널이 가동되어 IKE phase 2를 계속할 준비가 되었습니다.

1.2. IKE Phase 2

IKE phase 2 터널(IPsec 터널)은 실제로 사용자 데이터를 보호하는 데 사용됩니다. IKE phase 2 터널을 구축하는 모드는 Quick Mode 하나뿐입니다.

IKE phase 1과 마찬가지로 피어들은 여러 항목에 대해 협상합니다.

IPsec 프로토콜: AH 또는 ESP를 사용하는가?
캡슐화 모드: transport 또는 tunnel 모드?
암호화: 어떤 암호화 알고리즘을 사용하는가? DES, 3DES, AES?
인증: 어떤 인증 알고리즘을 사용하는가? MD5 또는 SHA?
Lifetime: IKE phase 2 터널이 얼마나 오래 유효한가? 터널이 만료되려고 하면 keying 자료를 갱신합니다.
(선택) DH 교환: PFS(Perfect Forward Secrecy)에 사용됩니다. PFS는 선택사항이며, 피어들이 각 IKE phase 2 quick mode에서 새 공유 키를 생성하기 위해 DH 교환을 다시 실행하도록 강제합니다.

이 협상은 IKE phase 1 터널의 보호 안에서 일어나기 때문에 아무것도 볼 수 없습니다. 완전성을 위해 Wireshark에서는 다음과 같이 보입니다(메시지 1, 2, 3는 모두 암호화됨).

참고: IKEv2는 phase 1에 main 또는 aggressive 모드가 없고 phase 2에 quick mode가 없습니다. 그래도 두 단계는 있습니다. Phase 1은 IKE_SA_INIT이라고 하고 두 번째 단계는 IKE_AUTH라고 합니다. 전체 교환에 필요한 메시지는 4개뿐입니다.

2. IPsec 프로토콜

AH 및/또는 ESP는 사용자 데이터를 실제로 보호하는 데 사용하는 두 프로토콜입니다.

둘 다 transport 또는 tunnel 모드에서 사용할 수 있습니다. 가능한 모든 옵션을 살펴봅시다.

2.1. Authentication Header 프로토콜

AH는 인증과 무결성을 제공하지만 암호화는 제공하지 않습니다. IP 헤더의 거의 모든 필드에 대한 해시 값을 계산해 IP 패킷을 보호합니다. 제외하는 필드는 전송 중에 변경될 수 있는 필드입니다(TTL과 헤더 체크섬).

2.1.1. Transport 모드

Transport 모드는 간단합니다. IP 헤더 다음에 AH 헤더만 추가합니다. Wireshark에서는 다음과 같이 보입니다.


Internet Protocol Version 4
    Protocol: Authentication Header (51)
    Source: 192.168.12.1
    Destination: 192.168.12.2
Authentication Header
    Next Header: ICMP (0x01)
    Length: 24
    AH SPI: 0xcf54ccdf
    AH Sequence: 30
    AH ICV: aa9cafe5ed06d6c74cb3c671
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)

AH는 5개의 필드를 사용합니다.

Next Header: 다음 프로토콜을 식별합니다(예시에서는 ICMP).
Length: AH 헤더의 길이입니다.
SPI (Security Parameters Index): 32비트 식별자로, 수신자가 이 패킷이 어떤 흐름에 속하는지 알 수 있습니다.
Sequence: 재전송 공격을 막는 시퀀스 번호입니다.
ICV (Integrity Check Value): 전체 패킷에 대한 계산된 해시입니다. 수신자도 해시를 계산하며, 동일하지 않으면 무언가 잘못되었음을 알 수 있습니다.

2.1.2. Tunnel 모드

Tunnel 모드에서는 원본 IP 패킷 위에 새 IP 헤더를 추가합니다. 이는 사설 IP 주소를 사용하고 인터넷을 통해 트래픽을 터널링해야 할 때 유용할 수 있습니다. AH로 가능하지만 암호화는 제공하지 않습니다.

전체 IP 패킷이 인증됩니다. Wireshark에서는 다음과 같이 보입니다.


Internet Protocol Version 4 (외부)
    Protocol: Authentication Header (51)
Authentication Header
    Next Header: IPIP (0x04)
    AH SPI: 0x646adc80
Internet Protocol Version 4 (내부, 원본)
    Protocol: ICMP (1)
Internet Control Message Protocol

위에서 새 IP 헤더, AH 헤더, 그리고 마지막으로 ICMP 트래픽을 운반하는 원본 IP 패킷을 볼 수 있습니다.

AH의 한 가지 문제는 NAT/PAT와 잘 작동하지 않는다는 것입니다. TTL과 체크섬 같은 IP 헤더의 필드는 변경될 것이라는 것을 알고 있어 AH에서 제외됩니다. 그러나 IP 주소와 포트 번호는 포함됩니다. NAT로 이를 변경하면 AH의 ICV가 실패합니다.

2.2. ESP (Encapsulating Security Payload) 프로토콜

ESP는 IP 트래픽을 암호화할 수 있어 둘 중 더 인기 있는 선택입니다. Transport 또는 tunnel 모드에서 사용할 수 있습니다.

2.2.1. Transport 모드

Transport 모드를 사용하면 원본 IP 헤더를 사용하고 ESP 헤더를 삽입합니다. ESP 헤더와 trailer를 추가합니다. 전송 계층(예: TCP)과 페이로드는 암호화됩니다. 인증도 제공하지만 AH와 달리 전체 IP 패킷에 대한 것은 아닙니다.


Internet Protocol Version 4
    Protocol: Encap Security Payload (50)
    Source: 192.168.12.1
    Destination: 192.168.12.2
Encapsulating Security Payload
    ESP SPI: 0x36cb42df
    ESP Sequence: 1

위에서 원본 IP 패킷과 ESP를 사용하는 것을 볼 수 있습니다. IP 헤더는 평문이지만 다른 모든 것은 암호화되어 있습니다.

2.2.2. Tunnel 모드

Tunnel 모드에서 ESP는? 새 IP 헤더를 사용하는데, 사이트 간 VPN에 유용합니다. Transport 모드와 비슷하지만 새 헤더를 추가합니다. 원본 IP 헤더도 이제 암호화됩니다.


Internet Protocol Version 4 (새 외부 헤더)
    Protocol: Encap Security Payload (50)
Encapsulating Security Payload
    ESP SPI: 0x8bb181a7
    ESP Sequence: 5

캡처 출력은 transport 모드에서 본 것과 비슷합니다. 유일한 차이는 이것이 새 IP 헤더라는 점이며, 원본 IP 헤더는 보이지 않습니다.

2.3. AH와 ESP

이것이 많은 사람들을 혼란스럽게 합니다. AH와 ESP를 동시에 사용할 수 있습니다.

2.3.1. Transport 모드

Transport 모드부터 시작합시다. Transport 모드에서는 원본 IP 헤더를 사용하고 그 뒤에 AH와 ESP 헤더가 옵니다. 전송 계층, 페이로드, ESP trailer는 암호화됩니다.

AH도 사용하기 때문에 전체 IP 패킷이 인증됩니다.


Internet Protocol Version 4
    Protocol: Authentication Header (51)
Authentication Header
    Next Header: Encap Security Payload (0x32)
    AH SPI: 0xa90dc9aa
Encapsulating Security Payload
    ESP SPI: 0xd2264f7a

2.3.2. Tunnel 모드

Tunnel 모드에서는 새 IP 헤더를 추가합니다.

먼저 새 IP 헤더가 있고 그 뒤에 AH와 ESP 헤더가 옵니다. 원본 IP 패킷은 완전히 암호화되고 AH 덕분에 모든 것이 인증됩니다.


Internet Protocol Version 4 (새 외부 헤더)
    Protocol: Authentication Header (51)
Authentication Header
    Next Header: Encap Security Payload (0x32)
    AH SPI: 0xa00ff1c7
Encapsulating Security Payload
    ESP SPI: 0x233ebd83