YEONGORI의 DEV 블로그

DockerTest

이 포스트는 이 문서와 이 문서를 기반으로 작성되었다.

Securing a Network

strongSwan은 서버와 클라이언트에게 암호화와 인증을 제공하는 IPsec 솔루션으로 원격 네트워크와의 통신을 안전하게 보호한다. 이로서 원격 연결 네트워크를 로컬 연결 네트워크처럼 만들어준다.

Gateway

gateway는 방화벽으로 주로 사용되지만 네트워크 내의 모든 호스트가 될 수 있다. 이밖에도 DHCP, DNS를 사용하는 소규모 네트워크를 제공할 수도 있다. 위의 사진에서 host moon과  sun은 내부 host인 alice, venus 그리고 bob 각각을 위한 게이트웨이 역할을 한다.

Remote Access / Roadwarrior Clients

일반으로, roadwarriors는 gateway를 통해 우리들의 집 네트워크에 원격으로 연결되는 노트북이나 핸드폰과 같은 디바이스들이다. 위 사진에서 carol과 dave는 두 게이트웨이(moon & sun) 뒤에 있는 두 네트워크에 접근하고자 하는 roadwarrior를 나타낸다.

Remote Hosts / Host-to-Host

위 사진에서 호스트 winnetou와 게이트웨이 moon 및 sun 중 하나가 원격 웹 서버나 백업 시스템을 나타낼 수 있다. 두 호스트 간의 연결은 일반적으로 (호스트)둘중 하나에 의해서 시작된다.

Remote Sites / Site-to-Site

서로 다른 위치의 두 개 이상의 서브넷에 속한 호스트들이 서로 접근할 수 있어야 한다. 위 사진에서 게이트웨이 moon과 sun뒤에 각각 존재하는 10.1.0.0/16과 10.2.0.0/24 서브넷이 연결되어, alice와 bob과 같은 호스트들이 안전하게 통신할 수 있어야 한다.

IKE and IPsec Basics

strongSwan은 기본적으로 두 peer 간에 SA(Security Associations)를 만들고 SP(Security Policies)를 협상하기 위해 IKEv2 프로토콜을 사용하는 keying daemon이다.

Keying Daemon은 VPN 연결을 설정하고 관리하는 핵심 프로세스다. strongSwan에서는 charon 프로세스로 IKEv2 프로토콜 관련 모든 기능을 처리한다.

IKE는 VPN 피어 간 강력한 인증 과정 제공하며 암호화 및 인증에 사용되는 고유한 세션 키를 생성한다. 그리고 IPsec SA를 협상해 어떤 네트워크 트래픽을 보완할지, 어떻게 암호화 및 인증을 제공할지 결정한다.

IKE_SA는 IKE 세션 자체를 나타낸다. 이 세션은 인증과 키 생성을 담당한다.

CHILD_SA는 실제 IPsec 트래픽을 보호하는 보안 연결을 나타내며 IKE_SA 내에서 협상된다.

CHILD_SA의 구성 요소

트래픽을 암호화하고 인증하는 데 사용되는 알고리즘과 키를 정의하는 IPsec SA와 어떤 네트워크 트래픽이 해당 SA를 사용해야 하는지 정의하는 Policy로 구성된다. Policy는 양방향으로 적용되며, 일치하는 인바운드 policy가 없는 트래픽은 삭제된다.

IPsec 트래픽 처리

IPsec 트래픽은 운영 체제 커널의 네트워크 및 IPsec 스택에 의해 처리된다. strongSwan은 협상된 IPsec SA와 SP를 커널에 설치하는 역할을 한다.

Policy와 SA의 구분

위 사진에서 host moon이 host sun과 site-to-site connection을 갖고 있고, host carol이 host sun과 roadwarrior connection을 갖고 있으며 sun이 포워딩이 가능하다해도 carol은 alice와 통신할 수 없다.

그 이유는 carol과 alice 사이에 traffic을 허용하는 IPsec Policy가 없기 때문이다. 이때 moon과 sun 사이 가상 서브넷을 연결하는 추가 SA가 있다면 carol과 alice의 통신이 가능하게 될 것이다. 이처럼 Policy는 CHILD_SA를 생성할 때 IKE를 통해 협상되는 traffic selectors(TS)에 의해서 파생된다.

Routing과 IPsec  Processing의 관계

IPsec은 일반적으로 네트워크 스택에 투명하게 적용되어 policy에 따라 트래픽을 처리한다. 따라서 원격 TS로 향하는 어떤 경로를 사용해도 IPsec 처리가 가능하다. 그러나 VPN 호스트 자체에서 트래픽이 발생하는 경우, 소스 주소 선택이 문제가 될 수 있다. 로컬 TS에 public 주소가 포함되어 있지 않으면 기본 경로에 따라 선택된 소스 주소로 인해 IPsec 처리가 되지 않을 수 있다. 이는 가상 IP주소를 사용하는 경우에 특히 문제가 될 수 있다.

소스 주소 선택이 IPsec VPN에서 왜 문제가 될까?
IPsec VPN 터널을 통해 트래픽을 보내려면, 소스 주소가 로컬 TS에 포함되어 있어야 한다. 그렇지 않으면 트래픽이 IPsec 처리를 받지 못하고 일반 경로로 전달될 수 있기 때문이다.

이 문제를 해결하기 위해 strongSwan의 charon IKE daemon은 기본적으로 대부분의 CHILD_SA에 대해 원격 TS로의 특정 경로를 설치해 이를 통해 로컬 TS의 주소가 소스 주소로 선택될 수 있도록 한다.

대안으로 인터페이스와 explict route를 사용하여 IPsec 터널에 의해 처리될 트래픽을 제어하는 route-based IPsec를 사용하기도 한다.

Authentication Basics

To ensure that the peer with which an IKE_SA is established is really who it claims to be, it has to be authenticated.

IKE_SA가 설정되려면 peer가 인증이 필수적이다. IKE_SA를 통해 VPN 터널이 설정되면 양측 peer가 서로를 신뢰할 수 있어야 하고, peer 인증을 거치지 않으면 중간자 공격(MITM attack)에 취약해질 수 있기 때문이다.

그렇다면 어떻게 peer간 인증을 진행할까?

Public Key Authentication

• RSA, ECDSA 또는 EdDSA X.509 인증서를 사용해 peer의 진위 여부를 검증한다.
• 자체 서명된 인증서 혹은 인증 기관(CA)에서 서명된 인증서를 사용할 수 있다.
• CA 인증서만 있으면 모든 peer를 인증할 수 있어 배포와 구성이 간단해진다.
• 중간자 공격을 방지하기 위해 peer의 ID가 인증서의 subject DN 또는 subjectAltName 확장자와 일치해야 한다.

Pre-Shared-Key Authentication (PSK)

• 배포는 쉽지만 강력한 비밀 키가 필요하다.
• 많은 사용자가 PSK를 알고 있는 경우 누구나 게이트웨이를 가장할 수 있어 대규모 배포에는 적합하지 않다.

Extensible Authentication Protocol (EAP)

• EAP-MD5, EAP-MSCHAPv2, EAP-GTC, EAP-TLS 등 다양한 인증 방식을 지원한다.
• RADIUS 서버를 사용하여 사용자 인증을 위임할 수 있다.
• IKEv2에서만 사용 가능하다

IKEv2 프로토콜에서는 RFC 4739에 따라 Multiple Authentication Exchanges가 가능하다. 그렇기 때문에 한 번에 IKE_AUTH 교환 내에서 여러 번의 인증 과정을 수행할 수 있다. 그 예시로 첫 번째 authentication round에서 gateway를 인증서로 인증하고, 두 번째 authentication round에서 client를 username/password 기반 EAP 방식으로 인증할 수 있다.

다양한 인증 방식을 조합하는 것이 IKEv2 구현체의 특징이지만, 모든 IKEv2 구현체가 그런건 아니므로 사용 전 확인이 필요하다.

Configuration Files

strongSwan을 구성하는 가장 좋은 방법은 vici control interface나 swanctl command line tool을 사용하는 것이다.

swanctl.conf configuration file은 인증서와 private key와 함께 swanctl 디렉토리에 저장된다.

swanctl.conf 파일은 다음과 같은 주요 섹션으로 구성된다.

• connections: VPN 연결 설정 (IKE 및 IPsec parameter, 인증 방법, 암호화 알고리즘 등이 포함된다.)
• secrets: 공유 키, 개인 키 등의 비밀 정보
• authorities: 신뢰할 수 있는 인증 기관(CA) 정의
• pki: 인증서 관리 설정

이 문서를 읽고 IPSec에 대한 정리한 글이다.

IPSec protocol은 두 개의 main components로 구성되어 있다.

• Encapsulating Security Payload(ESP) protocol
  • 두 IPSec endpoint들 간에 전송되는 IP 패킷을 secure 하는 프로토콜
• Internet Key Exchange Version 2(IKEv2) auxiliary protocol
  • IPSec endpoint간의 상호 인증
  • IKEv2 management protocol과 ESP payload protection에 대한 data integrity sesstion keys, encryption 자동 생성

Encapsulation Security Payload (ESP)

ESP는 Network layer에서 IP Packet을 전송할 때 암호화를 허용한다.

IPSec Transport Mode

IPSec Transport mode에서는 Original IP 헤더가 유지되고 IP 패킷에 의해 운반되는 Layer4 payload는 암호화된다.

ESP 헤더는 Original IP 헤더와 암호화된 페이로드 사이에 삽입된다.

IPSec Transport mode는 주로 Layer 2 Tunneling Protocol(L2TP)을 secure 하기 위해 사용되고 있다.

IPSec Tunnel Mode

IPSec Tunnel mode에서는 ESP와 outer IP header(터널의 시작, 종료 IP주소 등 정보 포함)에 의해 IP packet 전체(헤더와 페이로드)가 캡슐화된다.

ESP Packet Structure

ESP Packet은 ESP header, 암호화된 IP Payload body 그리고 padding을 위한 ESP trailer로 이루어져있다.

ESP trailer란?
ESP 패킷의 마지막 부분에 추가되는 데이터 영역이다. 암호화된 데이터의 길이를 블록 암호 알고리즘의 블록 크기에 맞추기 위한 Padding과 암호화된 페이러도의 프로토콜 타입을 나타는 필드, 패딩 데이터의 길이와 같은 정보들을 포함하고 있다.

암호화 체크섬으로서 Authentication Data는 데이터 무결성을 보장한다.

receiving IPSec peer는 32bit SPI를 커널 기반 DB의 Index로 사용해 ESP 패킷의 암호를 해독하고 인증하는 데 필요한 세션 키를 검색한다. 또한 암호 해독 후 inbound plaintext IP packet(ESP 패킷이 복호화된 후 수신되는 일반 IP 패킷)에 적용해야 하는 IPSec 보안 정책을 결정하는 데 사용된다.

IPSec 통신은 두 개의 IPSec endpoing 간에 이루어지며, 이 중 하나가 ESP 패킷을 전송하는 sending IPSec peer고 다른 하나가 ESP 패킷을 수신해 처리하는 receiving IPSec peer다.

Internet Key Exchange Version 2 (IKEv2)

IKEv2는 IPSec connection들에 대한 설정을 관리하며 source 및 destination 포트가 모두 잘 알려진 UDP 포트 500으로 설정된 UDP 데이터그램을 사용한다.

IKE_SA_INIT Request/Response

IPSec 통신을 위해서는 IKE protocol을 통해 SA(Security Association)을 설정해야 한다. IKE_SA_INIT은 SA 설정을 위한 초기 negotiation이 이루어진다.

Initiator(클라이언트)가 IKE_SA_INIT Request를 보내고 이 메시지를 통해 Responder(서버)와 암호화 알고리즘, 키 교환 방식 등의 보안 파라미터를 협상한다. Responder가 Initiator의 제안을 수락하는 Response Message를 보내면 양측은 SA를 설정할 수 있게 된다.

만약 Responder가 자신이 DoS 공격을 받고 있다고 생각되면, Response 내에 계산 비용이 많이 드는 Key Exchange(KE) payload를 보내기 전에 Initiator에게 Cookie를 요쳥해 효율적으로 IP spoofing을 방지할 수 있다.

Key Exchange(KE) payload
Diffie-Hellman 키 교환 알고리즘을 사용해 Initiator와 Responder가 shared secret key를 생성할 수 있게 한다. 이들은 각자의 공개 키를 KE payload에 포함하여 교환하고 이를 통해 shared secret key를 계산할 수 있게 된다.

Nonces(N) payload
Nonces payload에는 랜덤 하게 생성된 숫자(Nonce)가 포함된다. Initiator와 Responder는 각자의 Nonce를 교환하여, 이를 shared secret key 생성에 사용하고 message의 freshness를 보장하는데 이용한다.

Initiator와 Responder는 KE payload과 N payload의 교환을 통해 shared secret key를 생성한다. 이제 이 둘은 `IKE_SA`를 설정할 수 있다. `IKE_SA`에는 양측이 합의한 보안 파라미터를 나타내는 SA1i와 SA1r payload가 포함되어 이후 IKE 메시지들이 암호화되어 전송될 수 있게 한다.

IKE_AUTH Request/Response

Certificate-based Authentication

Initiator는 IKE_AUTH request message에서 자신의 id(IDi), Digital Signature(AUTHi)와 선택적으로 인증서(CERTi)를 보낸다. 또한 첫 번째 CHILD_SA에 사용될 Security Association proposal(SA2i)과 Traffic selectors(TSi, TSr)을 보낸다.

CHILD_SA란?
IPSec 통신을 위해 IKE protocol을 통해 설정되는 SA로 IPSec payload packet의 암호화와 무결성 보장을 위한 보안 파라미터가 포함된다.

이를 통해 IPSec Tunnel이 설정되고 실제 데이터 트래픽이 보호된다.

Responder는 IKE_AUTH response message에서 자신의 Digital Signature`AUTHr`과 선택적으로 인증서 CERTr를 보낸다. 또한 Initiator가 보낸 SA2i를 선택하고, 필요한 경우 Traffic selectors(TSi, TSr)을 조정한다. 추가로 Initiator가 보낸 인증서 CERTi의 유효성과 신뢰성을 검증하는데 이를 위해 Responder는 X.509 인증서 체인을 따라 올라가서 로컬에 저장된 루트 CA 인증서와 비교한다.

결과적으로 상호 인증이 완료되면, Initiator와 Responder는 IKE_AUTH 메시지에 포함된 정보를 바탕으로 CHILD_SA를 설정할 수 있다.

PSK-based Authentication

Authentication에 Pre-Shared Key(PSK)가 사용되는 경우 AUTHi와 AUTHr payload는 교환된 IKEv2 message와 pre-shared secret에 대한 해시를 가지고 있다.

PSK는 사용자가 직접 설정하는 공유 비밀키다.

IKE_AUTH 교환 시 Initiator가 먼저 AUTHi payload에 PSK hash를 보낸다. 이때 PSK의 암호 수준이 약하다면 MITM(Man In The Middle - 중간자 공격자)가 offline dictionary 공격이나 무차별 대입 공격을 통해 PSK를 크래킹 할 수 있다.

따라서 충분한 강도의 PSK를 사용할 수 없다면 PSK 기반 인증을 사용하지 말고 RSA signature 기반 인증 등 다른 인증 방식을 사용하는 것이 좋다.

EAP-based Authentication

MITM를 방어하기 위해 EAP-based Authentication이 IKEv2 표준으로 도입되었다.

만약 Initiator가 IKE_AUTH request에 AUTHi payload를 포함하지 않았다면 Responder는 AUTHr payload에 강력한 Digital Signature를 먼저 보낸다. 이로서 신뢰할 수 있는 Initiator 임을 확인하고 동시에 IKE_AUTH response에 첫 EAP request를 포함시켜서 EAP protocol을 시작한다.

CREATE_CHILD_SA Request/Response

CREATE_CHILD_SA Request/Response pairs는 CHILD_SA를 추가로 협상할 때 사용된다.

추가로 IKE_SA와 CHILD_SA는 일정 시간이 지나면 보안상의 이유로 rekeying(재협상)되어야 하는데 CREATE_CHILD_SA message pair를 사용해 이러한 rekeying을 수행할 수 있다.

• IKE_SA rekey
  
  • IKE_SA rekey 시 N(REKEY_SA) 알림이 포함되지 않는다.
  • 새로운 Key Exchange(KE) payload가 포함되어 Perfect Forward Secrecy(PFS)가 보장된다.
    • PFS는 각 통신 세션마다 고유한 세션 키를 생성하는 키 유도 함수를 사용해 한 세션의 키가 노출되더라도 다른 세션의 키에는 영향을 주지 않는다. 즉, long-term secret key가 노출되더라도 과거의 통신 내용이 안전하게 유지되는 것이다.
• CHILD_SA rekey
  • CHILD_SA rekey 시 N 알림이 포함된다.
  • KE payload는 선택적으로 포함될 수 있다.
   

따라서 N 알림이 포함되면 CREATE_CHILD_SA Request/Response가 CHILD_SA rekey를 위한 것임을 알 수 있다.

NAT Traversal

IPSec VPN에서는 ESP(IP protocol 50)과 IKE(UDP 500)이 사용된다. 여기서 ESP 프로토콜은 포트 개념이 존재하지 않으므로 PAT(Port Address Translation) 방식으로는 NAT router를 통과할 수 없다. 따라서 NAT Traversal이 등장하게 되었다.

NAT Traversal
NAT Traversal은 UDP encapsulation을 통해 구현된다. ESP 패킷을 UDP 패킷으로 캡슐화해 NAT device에서 포트 변환이 가능하도록 한다. 이를 통해 ESP traffic이 NAT router를 통과할 수 있는 것이다.

어떤 NAT 라우터들은 IPSec Passthrough라고 부르는 기능을 갖고 있다. NAT device 뒤에 있는 single host에서 outbound IKE traffic을 감지하고 아래 그림과 같이 inbound IKE 및 ESP packet을 특정 host로 전달한다.

하지만 이 방식은 동일한 VPN Gateway와 통신하는 여러 IPSec Client가 있는 경우는 작동하지 않는다. 이 문제를 해결하기 위해 제안된 솔루션은 ESP 패킷을 UDP Datagram으로 캡슐화하여 PAT를 적용하는 것이다.

IKE_SA_INIT 교환 시 전송되는 NAT_DETECTION_SOURCE_IP 및 NAT_DETECTION_DESTINATION_IP 알림을 통해 NAT 상황을 감지하고 이를 통해 ESP 트래픽이 NAT 라우터를 통과할 수 있게 된다.

NAT 상황이 없다고 해도 encap=yes 옵션을 설정하면 ESP-in-UDP 캡슐화를 강제할 수 있다. charon deamon이 조작된 NAT_DETECTION_SOURCE_IP 알림 payload를 전송하여 remote peer에게 NAT 상황이 있는 것처럼 보이게 하는 것이다.

ESP-in-UDP Encapsulation

ESP 패킷에 UDP Header를 추가해 ESP 패킷이 NAT device를 통과할 수 있게 한다. 결과적으로 IPSec 통신의 범위가 확장된다.

UDP Header가 ESP 패킷의 IP Header와 ESP Header 사이에 삽입된다.

정리

IPSec은 IP 트래픽에 대한 보안 기능을 제공하는 네트워크 프로토콜이다. IPSec의 ESP 프로토콜과 IKEv2 프로토콜로 구성되어 있고, ESP는 IP 패킷을 암호화하여 전송하고, IKEv2는 IPSec 연결 설정을 관리한다.

IPSec은 Transport 모드와 Tunnel 모드로 동작하며, NAT 환경에서 작동하기 위해 NAT Traversal 기술을 사용한다.

IKEv2는 상호 인증을 위해 PSK, Digital Signature 등의 인증 방식을 사용한다.