VPN & IPsec 에 대해서

이번 포스팅에서는 VPN 과 IPsec 에 대해서 기본적인 내용들을 정리하려고 한다. 이 포스팅은 단순히 VPN, IPsec 에 대해서 알아보자는 목적도 있지만 최근에 ISMS 심사를 위해 구축한 인프라에 대한 기술적인 내용을 쓰기 위해 사전에 기본적인 내용 정리를 위한 것도 있다. 그렇다면 이제 VPN 과 IPsec 이 어떤 것인지 알아보자.

VPN & IPsec 개요

IP security protocol (IPsec)은 network 레이어의 IP 데이터그램을 송신자와 수신자 사이의 다른 중간자로부터 보호하는 역할을 한다. 인터넷을 통해 송신자가 목적지까지 데이터를 전송하기 위해서는 중간에 많은 라우터나 호스트를 거치게 된다. 그리고 일반적으로 IPsec을 이용하여 Virtual Private Networks(VPNs)를 구성하게 된다.

네트워크 레이어의 데이터 기밀성에 대해서 다시 생각해보자. 송신자 측에서는 보내려는 메세지를 암호화하여 수신자 측으로 전송한다. 이 때 송신자가 보내는 데이터는 TCP, UDP 세그먼트일 수도 있고 ICMP 메시지일 수 있다. 여기서 데이터 기밀성이란 것은 수신자를 제외한 다른 중간자들은 송신자가 보낸 데이터를 볼 수 없어야 한다는 것을 나타낸다.

그리고 네트워크 레이어에서는 기밀성뿐만 아니라 다른 보안적인 서비스들도 제공해주어야 하는데 그 중 하나가 데이터를 보낸 송신자가 본인이 맞는지 수신 측에서 인증을 할 수 있어야 한다. 그래야 수신 측에서는 올바른 사람이 데이터를 보냈는지 확신할 수 있기 때문이다. 그리고 데이터 무결성도 제공해주어야 한다. 송신자가 보낸 데이터가 중간에 변조되지는 않았는지 보장할 수 있어야 수신 측에서 제대로 된 데이터가 맞는지 확신할 수 있다.

특정 조직에서 여러 멀리 떨어진 지역에 각각이 네트워크를 가지고 있고 각 네트워크 안에서는 각자의 IP 대역을 할당하여 사용하고 있다. 이 때 A 지역 네트워크에서 B 지역의 네트워크에 연결하고 싶을 수 있는데 이것을 가능하게 하는 방법 중 하나가 A 지역과 B 지역의 네트워크를 연결하는 물리적인 네트워크 인프라를 구축하는 것이다. 이 방법을 통해서 인터넷을 통하지 않으며 A 지역과 B 지역은 서로 통신할 수 있는 네트워크(내부망)를 구축할 수 있다.

그렇지만 예상할 수 있듯이 이러한 방법은 비용이 높다. 자체 인프라를 구축하는 비용도 그러하며 이것을 유지, 보수 하는 비용도 만만치 않다.

이러한 문제점을 해결하기 위해 Virtual Private Networks (VPN)이 등장했다. 직접 물리적으로 네트워크를 연결하는 것이 아니라 이제 각 내부망의 네트워크는 인터넷을 통해 다른 내부망과 연결되는데 이 때 송신측에서는 인터넷에 데이터를 보내기 전에 암호화를 하여 수신측에 전달하게 된다.

예를 들어 아래 그림에서 서로 다른 두 지역에서 VPN 을 형성하여 사용하는 것을 볼 수 있다. 먼저 B 지역의 내부망에서 서로 다른 두 호스트가 통신할 때는 IPsec 을 사용하지 않고 일반적인 IPv4를 이용하여 통신한다. 하지만 다른 지역 네트워크 호스트와 통신할 때는 보내는 트래픽을 먼저 암호화한 후 인터넷으로 보낸다.

예를 들어 B 지역의 호스트가 A 지역의 호스트에게 IP 데이터그램을 보낼 때 B 지역의 라우터가 IPv4 데이터그램을 IPsec 데이터그램으로 변환하여 인터넷으로 보내게 된다. IPsec 데이터그램이 어떻게 구성되어있는지는 아래에서 살펴보겠지만 IPv4와 동일한 포맷의 헤더를 가지고 있다. 그렇기 때문에 라우터는 IPsec 데이터그램을 보고 일반적인 IPv4 라고 생각하고 인터넷으로 보내게된다.

그렇지만 IPsec 데이터그램 헤더에는 IPsec 프로토콜을 위한 헤더도 별도로 가지고 있다. 이것은 수신측에서 암호화된 데이터그램을 복호화하는데 사용된다. 그리고 수신측에서는 먼저 IPsec 데이터그램이 복호화되면 그 아래에 있는 레이어에서는 원래 IP 데이터그램을 가공했던대로 처리하게된다.

여기서 하나 짚고 넘어가야할 점은 A 지역의 특정 호스트가 게이트웨이 라우터를 통해 인터넷으로 전송된 데이터그램이 모두 IPsec 프로토콜을 통해 암호화된 것은 아니라는 것이다. 왜냐하면 예를 들어 A 지역 네트워크 호스트가 구글과 같은 웹서버에 접근을 할 때는 IPv4 데이터그램을 구글 서버와 주고 받을 것이기 때문이다.

이렇게 VPN을 사용하게 된다면 네트워크 A 호스트 입장에서는 네트워크 B에 있는 호스트가 마치 같은 네트워크의 다른 서브넷에 존재하는 것처럼 느껴진다. 이러한 가상화는 IPsec 이 호스트들에게 제공해준다. 그리고 VPN을 사용하게 된다면 하나 생각해야할 점은 다른 네트워크가 다른 IP 주소 대역을 가져야한다는 것이다. 그래야 VPN을 연결했을 때 주소 충돌이 일어나지 않고 인접한 다른 서브넷처럼 보이게 할 수 있다.

여기까지는 하이레벨에서 어떻게 IPsec과 VPN 이 동작하는지를 살펴보았다. 이제 다음 섹션부터는 좀 더 구체적인 이야기로 이어진다.

AH and ESP 프로토콜

IPsec 을 구현한 프로토콜은 대표적으로 두 개가 있는데 그것이 바로 Authentication Header (AH) 프토토콜과 Encapsulation Security Payload (ESP) 프로토콜이다. IPsec을 사용하는 쪽에서 데이터그램을 암호화하여 수신측에 보낼 때 AH 프로토콜을 이용하거나 ESP 프로토콜을 이용한다.

그런데 ESP 프로토콜은 수신측 인증, 데이터 무결성, 기밀성을 보장해주지만 AH 프로토콜은 이 중 데이터 기밀성을 보장해주지 않는다. 그렇기 때문에 ESP 프로토콜이 오늘날 더 일반적으로 쓰이고 있다.

Security Associations

IPsec 데이터그램은 위에서 계속 이야기했듯이 네트워크 두 지점간에서 주고 받는다. 그런데 실제로 데이터그램을 주고 받기 전에 송신측에서는 수신측과 네트워크 레이어에서 논리적인 연결을 맺는데 이것을 IPsec 프로토콜에서 Security Associations (SA)라고 부른다. 이 연결은 일방향으로 맺어진다. 그래서 수신측에서도 송신측에게 IPsec 데이터그램을 보내기 위해서는 또 다른 SA를 맺어야 한다. 예를 들어 위의 그림에서 A 지역 네트워크의 특정 호스트와 B 지역 네트워크의 특정 호스트가 서로 IPsec 데이터그램을 주고 받기 위해서는 2개의 SA가 필요하다.

SA가 어떻게 동작하는지 위의 그림을 통해서 살펴보자. 위의 그림에서 떨어진 두 네트워크에서 각 게이트웨이 라우터가 SA를 맺고 있다. 이 때 R1 입장에서는 해당 SA와 관련된 정보를 저장하고 있다. 이 때 저장하는 정보는 다음과 같다:

• Security Parameter Index (SPI) 라고 부르는 SA 식별자이다.
• 송신측 인터페이스 (위의 예시에서는 121.102.178.168) 그리고 수신측 인터페이스 (위의 예시에서는 35.68.187.203) 정보
• IPsec 데이터그램 암호화 방식 (예를 들어 CBC를 이용한 3DES 암호화)
• 암호화 키
• IPsec 데이터그램 무결성을 검증하는 방식 (예를 들어 MD5를 이용한 HAMC 방식)
• 인증키

R1이 R2와 연결된 SA에 IPsec 데이터그램을 보낼 때마다 해당 정보를 가져와서 어떻게 인증을 해야하고 어떻게 암호화하여야하는지 찾는다. 해당 정보는 R2에도 동일하게 존재하는데 이 때는 어떻게 송신측을 인증해야하고 어떻게 복호화해야 하는지를 알기 위해서 사용된다.

실제로는 다양한 네트워크와 SA를 맺고 있을 가능성이 높고 이 때 각각의 SA에 대해서 위와 같은 정보를 저장하고 있다. 게이트웨이 라우터 측에서는 이를 효과적으로 저장하고 조회하기 위해서 Security Association Database (SAD)를 사용하는데 이는 라우터측 OS 커널에서 관리된다.

IPSec 데이터그램

이제 IPsec 데이터그램 형태에 대해서 살펴보자. IPsec 프로토콜에서는 두 가지 종류의 패킷 형태가 있는데 하나는 tunnel mode 형태이고 다른 하나는 transport mode 형태이다. VPN에서는 tunnel mode 형태가 훨씬 많이 사용되기 때문에 이 섹션에서는 tunnel mode의 IPsec 패킷 형태를 살펴볼 것이다.

위의 그림에서 IPsec 데이터그램의 포맷을 살펴볼 수 있다. 이전 예시에서 A 네트워크 호스트 121.102.178.168 에서 B 네트워크의 35.68.187.203 호스트로 라우터 R1을 거쳐 IPv4 데이터그램을 보낸다고 생각해보자. R1은 다음의 과정을 거쳐서 IPv4 데이터그램을 IPsec 데이터그램으로 변환시킨다:

• IPv4 데이터그램 뒤에 ESP trailer 필드를 붙인다. ESP trailer에 대해서는 아래에서 설명한다.
• IPv4 데이터그램과 ESP trailer를 SA에 명시된 암호화 알고리즘으로 암호화를 한다.
• 암호화된 데이터 앞에 ESP header를 붙인다. 그리고 여기까지 생성된 데이터를 “enchilada”라고 부른다.
• enchilada를 SA에 명시된 알고리즘을 통해 MAC을 생성한다.
• 생성한 MAC을 enchilada 뒤에 붙인다.
• 마지막으로 여기까지 생성된 데이터 앞에 해당 데이터에 대한 IPv4 header를 붙인다.

여기까지 과정을 거쳤을 때 나오는 IPsec 데이터그램은 IPv4 데이터그램과 형태가 똑같다. IPv4 header가 있고 그 뒤에 IPv4 payload가 붙는다. 차이점은 payload에 ESP header가 붙어있고 끝에는 MAC이 존재하며 실제 데이터는 암호화되어있다. 그렇기 때문에 본래 송신자와 수신자의 호스트 IP 주소는 암호화되어 있다.

그렇다면 IPsec 데이터그램 앞에 붙은 IPv4 header의 IP 주소에는 어떤 값이 들어가있는 것일까? 해당 자리에는 R1과 R2의 IP 주소가 들어가 있다. 그리고 header의 protocol number는 ESP 프로토콜을 나타내는 50으로 값이 채워진다.

R1에서 IPsec 데이터그램이 출발하면 R2에 도착하는 동안 많은 다른 라우터를 거칠 것이다. 다른 라우터는 해당 데이터그램을 받으면 IPv4 데이터그램을 처리하는 것처럼 동일하게 동작하며 header에 적힌 R2 라우터로 라우팅되도록 동작할 것이다.

이와 같이 IPsec 데이터그램이 만들어진다. 그렇다면 이제 enchilada에 대해서 좀 더 살펴보자. 위의 그림에서 ESP trailer는 세 가지 필드로 구성된다.

IPsec에서는 블럭 암호화를 사용할 수 있기 때문에 메세지가 정해진 길이보다 크다면 여러 블럭으로 나누어져야 한다. Padding은 정해진 길이로 메세지를 나누기 위해 사용된다. 그리고 padding 길이는 복호화할 때 해당 길이 만큼 padding을 삭제한 뒤 복호화하기 위해 사용된다. 다음 header는 암호화되기 전 본래 IPv4의 header 타입을 나타낸다.

ESP header는 두 가지로 이루어져있다. SPI는 수신측에서 해당 값을 이용하여 SAD에서 SA 정보를 알아내고 여기서 어떤 알고리즘을 썼는지 알 수 있다. sequence number는 replay-attack을 방지하기 위해 사용된다.

이렇게 만들어진 enchilada 뒤에 MAC을 붙인다. 해당 MAC은 enchilada를 이용해서 생성된다.

R2가 (IPv4 형태를 띄는) IPsec 데이터그램을 받았을 때 header의 목적지 IP 주소가 R2로 되어 있기 때문에 해당 데이터그램을 처리한다. R2는 해당 데이터그램에서 protocol number가 50인 것을 확인하고 payload가 IPsec 프로토콜 형태를 따를 것이라고 알게된다. 먼저 ESP header에서 SPI를 통해 어떤 SA에서 해당 IPsec 데이터그램이 넘어왔는지 확인한다. 그리고 어떤 알고리즘을 썼는지 확인한다. 그리고 해당 알고리즘을 통해 MAC을 계산하고 해당 값이 ESP MAC과 동일한지 확인한다. 여기까지 진행되었을 때 만약 올바르게 되었다면 해당 enchilada는 R1으로 왔고 변조되지 않았다는 것을 보장할 수 있다. 그리고 ESP header의 sequence number를 통해서 해당 데이터그램이 replay-attack이 아닌지를 확인할 수 있다. 그리고 enchilada를 복호화 한뒤 padding을 제거한 뒤에 드디어 A 네트워크 호스트가 보낸 IPv4 데이터그램을 얻어낸다. 마지막으로 R1은 해당 IPv4에서 목적지 호스트의 IP를 얻어내고 해당 호스트로 데이터그램을 전달한다.

그런데 R1이 네트워크 A의 어떤 호스트가 인터넷으로 데이터그램을 보내려고 할 때 어떻게 해당 데이터그램을 IPsec 데이터그램으로 변환해야한다는 것을 알까? 그리고 IPsec 데이터그램으로 변환했다면 어떤 SA를 통해서 보내야한다는 것을 알까?

그것은 바로 Security Policy Database (SPD)를 통해서 알게된다. IPsec을 다루는 주체들은 SPD를 관리하는데 이것을 통해 수신측 IP와 송신측 IP에 따라 어떤 IPsec 프로토콜을 써야하는지, 어떤 SA를 사용해야하는지 알 수 있다.

IPsec 서비스 정리

이제 IPsec에 대해 정리해보자. 공격자는 송신측과 수신측 사이에 사용되는 인증키와 암호화키를 모른다면 송신측에서 보낸 본래의 IPv4 데이터그램을 알 수 없다. 그리고 해당 데이터그램에는 protocol number, 송수신측의 IP 주소가 있다. 공격자는 어떤 게이트웨이에서 어떤 목적 게이트웨이로 가는지는 확인할 수 있다. 공격자가 해당 데이터그램을 변조한다면 수신측에서 MAC 검증에 실패할 것이므로 변조가 되었다는 것을 알 수 있고 중간에 데이터를 가로채 똑같은 데이터그램을 다시 보낸다 하더라도 sequence number가 존재하기 때문에 replay-attack도 불가능할 것이다. 그리고 공격자가 R1인 것처럼 IPsec 데이터그램을 보낸다하더라도 인증에 실패할 것이다.

IKE: Key Management in IPsec

위에서 살펴보았듯이 VPN을 형성하기 위해서는 직접 VPN 연결점마다 SA를 생성해야하고 여기에는 암호화 알고리즘, 인증 알고리즘, SPI 등 여러가지 정보들이 들어가야한다. VPN이 적을 때는 괜찮지만 많아진다면 서로 연결점도 다양해질 것이고 각 SA마다 이것을 관리하기에는 꽤 공수가 많이 들어갈 것이다. 이러한 문제점을 해결하기 위해서 자동으로 SA를 생성하는 프로토콜이 등장했고 이것을 Internet Key Exchange (IKE) 프로토콜이라 부른다 (RFC 5996).

IKE는 SSL의 handshake 과정과 유사하다. SSL과 같이 IKE에서도 인증서를 교환해서 서로를 인증하고 어떤 알고리즘을 써서 다음번에 데이터를 암호화할지 합의하는 과정이 존재한다. 그리고 양측에서 세션키를 생성하여 해당 키를 통해 SA를 통해 보내는 데이터그램을 암호화한다. 다만 IKE는 2 단계를 통해 해당 과정을 마무리한다.

• 첫 번째 단계에서는 R1, R2가 Diffie-Hellman을 이용하여 IKE SA를 생성하게 된다. IKE SA는 이전에 설명한 IPsec SA와는 다른 것이며, IKE SA를 통해서도 연결된 상대방을 인증할 수 있으며 IKE SA를 통해서 보내게 된 데이터는 모두 암호화된다. IKE SA을 생성하기 위해 인증키와 암호화키 그리고 마스터 키를 생성하게 된다. 인증키와 암호화키는 IKE SA에서 연결된 상대방을 인증하고 이후 단계에서 주고받는 데이터를 암호화하기 위해 사용된다. 이 때 연결된 피어를 인증하기 위해 사전에 정의된 IKE Pre-shared 키를 사용할 수 있고 혹은 RSA 전자서명을 통해서도 인증을 할 수 있다. 마스터 키는 두 번째 단계에서 IPsec SA 키를 생성하는데 사용된다. 이와 같이 첫 번째 단계에서는 RSA 키를 통한 전자 서명과 같은 방식이 포함되지 않는다.
• 두 번째 단계에서는 양측에서 모두 전자 서명을 통해 상대방에게 메세지를 보내고 양측의 신원을 알려준다. 하지만 이 때 중간자가 양측을 제외하고 이들의 신원을 확인할 수 없는데 그 이유는 첫 번째 단계 에서 IKE SA를 생성하여 양측만이 볼 수 있는 암호화된 채널을 만들었고 이를 이용하여 데이터를 전송하기 때문이다. 이렇게 양측의 신원을 확인하고 이제 IPsec의 암호화와 인증 알고리즘을 합의하여 이후 IPsec 통신에 사용하게 된다.

마무리하며

여기까지 해서 VPN 과 IPsec에 대한 내용을 간단하게 정리해보았다. 다른 글에서 VPN 을 어떻게 활용할 수 있는지 구체적인 사례에 대해서 정리해보겠다.