04IPsec와 IKEIPsec와 IKE

대칭 암호화에서는 양쪽이 같은 키로 암호화·복호화 합니다. 그런데 그 키를 만드는 자재(material)를 안전한 방식으로 주고받아야 한다는 것이 문제입니다. 정보를 안전하게 교환하려면 키가 오직 통신 당사자에게만 속해 있어야 하기 때문입니다.

IKE(Internet Key Exchange) 의 목표는 양쪽이 키를 직접 주고받지 않고도 똑같은 대칭 키를 독립적으로 만들어 내는 것입니다. 이렇게 만들어진 키가 VPN 피어 사이의 대량 데이터 전송에 쓰이는 일반 IP 패킷을 암호화·복호화 합니다. IKE는 양쪽을 인증하고 암호화·무결성 방법에 합의해 VPN 터널을 세우며, IKE 협상의 결과물이 바로 SA(Security Association, 보안 연결) 입니다.

키와 암호화 방법에 대한 이 합의 과정 자체도 안전하게 이뤄져야 합니다. 그래서 IKE는 두 phase(단계) 로 구성되며, 첫 단계가 둘째 단계의 토대 를 놓습니다.

비결은 Diffie-Hellman(DH) 입니다. DH는 대칭 키를 만들 자재를 교환하는 데 쓰이는 IKE 프로토콜의 한 부분으로, 한쪽의 개인 키(private key)와 다른 쪽의 공개 키(public key)로 "공유 비밀(shared secret)"이라는 암호화 키를 만들 어 냅니다. IPsec 대칭 키는 피어끼리 공유한 이 DH 키에서 파생되므로, 대칭 키가 실제로 전송되는 일은 어느 시점에도 전혀 없 습니다.

IKE Phase I

IKE Phase I 동안에는 다음 일들이 일어납니다.

성능 면에서 Diffie-Hellman 키 생성은 느리고 무거운 작업입니다. 이 단계의 결과물이 IKE SA 로, IKE Phase II를 위한 키·방법에 대한 합의 입니다.

IKE Phase II

IKE Phase II(Quick Mode 또는 IPsec Phase)는 Phase I에서 합의한 키·방법으로 암호화 된 채 진행됩니다. 이 단계에서 교환된 키 자재는 IPsec 키를 만드는 데 쓰입니다. Phase II의 결과물이 IPsec SA 이며, 이는 IPsec을 위한 키·방법에 대한 합의입니다. 따라서 실제 IPsec은 IKE Phase II에서 합의된 키·방법에 따라 이뤄집니다.

IPsec 키가 만들어진 다음에는 대량 데이터 전송(bulk data transfer) 이 터널을 통해 일어납니다.

IKEv2 는 Simplified 모드로 동작하는 VPN 커뮤니티 안에서 지원 됩니다. IKEv2는 VPN Community 객체 > Encryption 에서 설정하며, 기본 설정은 IKEv1 only 입니다.

IPv6 트래픽에는 항상 자동으로 IKEv2가 쓰입니다. 따라서 암호화 방법 설정은 IPv4 트래픽에만 적용 됩니다.

SmartConsole에서 Remote Access VPN 사용자를 위한 IKE 설정을 구성하려면 Menu > Global properties > Remote Access > VPN - Authentication and Encryption 으로 이동합니다.

협상 중에 두 가지 파라미터가 정해집니다 — 암호화 알고리즘(Encryption algorithm) 과 해시 알고리즘(Hash algorithm, 무결성) 입니다. 각각 IKE Phase 1(IKE SA)과 IKE Phase 2(IPsec SA)에 대해 따로 정합니다.

다음은 단계별로 지원되는 암호화 알고리즘 입니다.

다음은 단계별로 지원되는 무결성(Integrity) 알고리즘 입니다.

Diffie-Hellman 그룹

Diffie-Hellman 키 계산(=지수 키 합의, exponential key agreement)은 Diffie-Hellman(DH) 수학 그룹 에 기반합니다. Security Gateway는 IKE의 두 단계 동안 다음 DH 그룹들을 지원합니다.

비트 수가 더 많은 DH 그룹은 깨기 더 어려운 키 를 보장하지만, 계산에 더 많은 CPU 사이클 이 들어 성능 비용이 무겁습니다. 보안과 성능 사이의 균형을 보고 고르면 됩니다.

Security Gateway 사이에는 IKE Phase I을 위한 두 가지 모드가 있습니다. 이 모드들은 오직 IKEv1에만 적용 됩니다.

IKEv1 Phase I — Main Mode 는 기본 모드 입니다. Security Gateway가 여섯 개의 패킷 으로 IKE 협상을 수행합니다. Main Mode가 Aggressive Mode보다 선호되는 이유는 다음과 같습니다.

Main Mode에서는 DH 계산이 인증 이후에 수행됩니다. 반면 Aggressive Mode에서는 DH 계산이 인증과 병렬로 수행되어, 아직 인증되지 않은 피어가 상대 피어에게 프로세서를 많이 잡아먹는 DH 계산을 강제 할 수 있습니다.

IKEv1 Phase I — Aggressive Mode 는 Security Gateway가 세 개의 패킷 으로 IKE 협상을 수행합니다. Check Point Security Gateway가 IKE Phase I Main Mode를 지원하지 않는 서드파티 VPN 솔루션과 협상해야 할 때 이 모드를 씁니다.

원격 접속(Remote Access)을 다룰 때 IKE에는 추가 모드가 있습니다.

IKE Phase I은 매번 Diffie-Hellman 키를 만들고 피어를 인증해야 하므로 Phase II보다 프로세서를 더 많이 씁니다. 그래서 Phase I은 더 드물게 수행됩니다. 그러나 IKE SA는 일정 기간만 유효 하며, 그 기간이 지나면 재협상해야 합니다. IPsec SA의 유효 기간은 그보다 더 짧 아서, IKE Phase II 협상은 훨씬 자주 일어납니다.

각 재협상 사이의 기간을 lifetime(수명) 이라고 합니다. 일반적으로 lifetime이 짧을수록 IPsec 터널이 더 안전 하지만(대신 IKE 협상이 더 자주 일어나 프로세서 부담이 큽니다), lifetime이 길수록 이후 VPN 연결을 더 빨리 세울 수 있습니다.

기본값으로 IKE Phase I은 하루에 한 번, IKE Phase II는 매 시간 일어나며, 각 단계의 타임아웃은 설정으로 바꿀 수 있습니다.

IKE Phase II에서 만들어 IPsec에 쓰는 키는 피어끼리 교환한 무작위 이진 비트열 과 IKE Phase I에서 계산한 DH 키 를 바탕으로 합니다.

이 DH 키는 한 번 계산된 뒤 IKE Phase II 동안 여러 번 쓰입니다. Phase II의 키들이 Phase I의 DH 키에 기반하므로 그들 사이에는 수학적 관계 가 존재합니다. 이 때문에 하나의 DH 키를 계속 쓰면 이후 키들의 강도가 약해질 수 있고, 한 키가 노출되면 이후 키들도 더 적은 노력으로 노출 될 수 있습니다.

암호학에서 Perfect Forward Secrecy(PFS, 완전 순방향 비밀성) 란 현재 세션 키나 장기 개인 키가 노출되어도 이전 또는 이후의 키가 노출되지 않는 상태를 말합니다. Security Gateway는 PFS 모드 로 이 조건을 만족합니다. PFS가 켜지면 IKE Phase II 동안 새로운 DH 키가 생성 되고, 키 교환 때마다 갱신 됩니다.

한편 IKE Phase I마다 새 DH 키가 생성 되므로, 이 키들과 이후 IKE Phase I 협상에서 만들어지는 키들 사이에는 의존성이 없습니다. PFS는 극도의 보안이 필요한 상황에서만 IKE Phase II에 켜는 것이 좋습니다.

PFS가 지원하는 DH 그룹은 1, 2, 5, 14, 19, 20 이며, 기본은 Group 2(1024비트) 입니다.

PFS에 대해 추가로 알아 둘 점이 있습니다.

IP 압축 은 TCP/IP 패킷의 데이터 부분 크기를 줄이는 과정으로, 성능을 크게 개선할 수 있습니다. IPsec은 Flate/Deflate IP 압축 알고리즘을 지원합니다. Deflate 는 실제 데이터에 맞춰 압축 방식을 적응시키는 똑똑한 알고리즘 입니다. IP 압축을 쓸지 여부는 IKE Phase II 동안 결정 되며, 기본적으로는 켜져 있지 않 습니다.

IP 압축은 느린 회선을 쓰는 Remote Access 클라이언트 사용자에게 특히 중요 합니다. Security Gateway의 암호화는 TCP/IP 패킷을 "뒤섞인" 것처럼 보이게 만드는데, 이런 데이터는 압축이 되지 않아 대역폭이 낭비 됩니다. IP 압축을 켜면 패킷이 암호화 전에 먼저 압축 되므로, 잃어버릴 뻔한 대역폭을 회복할 수 있습니다.

기본적으로 VPN 터널은 통신에 참여하는 호스트 컴퓨터만이 아니라, 그 호스트들이 속한 서브넷 전체 에 대해 만들어집니다.

각 Security Gateway에서 Support Key exchange for subnets 옵션을 끄면, 피어 쌍마다 고유한 Security Association 을 만들 수 있습니다.

만약 Security Gateway는 Support key exchange for subnets 를 쓰도록 설정됐지만 원격 피어가 이 옵션을 지원하지 않는다면, Host A가 Host C와 통신할 때 Host A의 서브넷과 Host C의 IP 주소 사이에 SA 1이 협상 됩니다. 그리고 10.10.11.x 서브넷의 어떤 호스트가 Host C와 통신하든 같은 SA 가 쓰입니다.

Host A가 Host B와 통신할 때는 Host A의 서브넷과 Host B 사이에 별도의 SA 2 가 협상되며, 마찬가지로 10.10.11.x 서브넷의 어떤 호스트가 Host B와 통신하든 같은 SA가 쓰입니다.

통신하는 Security Gateway들에서 Support Key exchange for subnets 가 켜져 있지 않으면, 개별 IP 주소 사이마다 SA가 협상 되어 사실상 호스트마다 고유한 SA 가 만들어집니다.

DoS 공격 이해하기

서비스 거부(DoS, Denial of Service) 공격 은 성능을 떨어뜨리거나, 정당한 사용자의 서비스 이용을 막거나, 심지어 서비스를 다운시키는 것을 노립니다. 기밀 데이터가 노출되거나 사용자가 무단 권한을 얻는 것은 아니므로 직접적인 보안 위협은 아니 지만, 메모리나 CPU 같은 컴퓨터 자원을 소모 시킵니다.

DoS 공격은 크게 두 종류입니다. 하나는 버그를 노려 서비스를 망가뜨리려고 잘못된(garbage) 패킷을 보내는 방식이고, 다른 하나는 잘 만들어진(well-formed) 패킷을 보내 서비스나 프로토콜의 취약점을 악용 하는 방식입니다. IKE DoS 공격 방어는 두 번째 종류의 공격을 다룹니다.

IKE DoS 공격의 원리

IKE 프로토콜은 수신 측 Security Gateway가 받은 첫 IKE Phase 1 요청 패킷에 대해 메모리를 할당 하도록 요구합니다. Security Gateway는 응답한 뒤 또 다른 패킷을 받고, 첫 패킷에서 수집한 정보로 그것을 처리합니다.

공격자는 매번 다른 출발지 IP 주소를 위조하면서 수많은 IKE 첫 패킷을 보낼 수 있습니다. 수신 측 Security Gateway는 각각에 응답하고 각각에 메모리를 할당해야 하므로, 이것이 모든 CPU 자원을 소모해 정당한 사용자의 연결을 막 을 수 있습니다.

IKE 패킷을 보내는 공격자는 Check Point Security Gateway처럼 IKE 협상을 시작할 수 있는 정당한 장비인 척 할 수 있는데, 이를 identified source(식별된 출발지) 라고 합니다. 또는 Remote Access 클라이언트나 동적 IP를 가진 Security Gateway처럼, 수신 측이 모르는 IP 주소를 가진 척 할 수도 있는데, 이를 unidentified source(식별되지 않은 출발지) 라고 합니다.

IKE DoS 공격 방어 방식

동시에 처리하는 IKE 협상 수가 허용 임계값(threshold)을 넘으면, Security Gateway는 과부하 상태이거나 DoS 공격을 받고 있다고 판단합니다. 이런 경우 Security Gateway는 잠재적 DoS 공격의 출처일 가능성이 큰 피어를 걸러낼 수 있습니다.

SmartConsole에서 IKE DoS 방어 설정하기

IKE DoS 공격을 방어하려면 다음과 같이 합니다.

IKE DoS 방어 고급 설정

고급 IKE DoS 공격 방어는 Management Server에서 Database Tool(GuiDBEdit Tool) 로 설정합니다.

ike_dos_supported_protection_sr 에 대해 한 가지 덧붙이면, Security Gateway는 ike_dos_protection_unidentified_initiator 파라미터(Global Property의 "Support IKE DoS Protection from unidentified Source" 와 동일) 를 써서 원격 클라이언트에 요구할 방어 수준을 정합니다. 반면 SecureClient 클라이언트는 ike_dos_protection 을 쓰며, 이 같은 클라이언트 속성이 Security Gateway 쪽에서는 ike_dos_supported_protection_sr 로 불립니다.

인증 성공 이후의 방어

성공적으로 인증한 뒤 Security Gateway를 공격할 수 있는 피어 에 대비해, Database Tool(GuiDBEdit Tool) 이나 dbedit(sk13301 참고)로 필드를 설정할 수 있습니다. 이 설정들은 Security Gateway별이 아니라 Global Properties 테이블에 들어가며, 기본적으로 꺼져 있다가 값을 입력하면 활성화 됩니다.

한 사용자가 열 수 있는 IKE SA의 수를 제한 하려면 다음 필드를 설정합니다.

한 IKE당 사용자가 열 수 있는 터널 수를 제한 하려면 다음 필드를 설정합니다.

클라이언트 속성 (이름이 바뀌는 속성)

일부 Security Gateway 속성은 Remote Access VPN 클라이언트로 다운로드될 때 이름이 바뀝 니다. 바뀐 이름은 userc.C 파일에 다음과 같이 나타납니다.

IKE는 두 곳에서 설정합니다.

VPN Community 객체 — Encryption 설정

VPN Community 객체를 설정하려면 다음과 같이 합니다.

Encryption Method(IKE Phase I·II에 적용)는 다음 중 하나를 고릅니다.

Encryption Suite(암호화 스위트)는 다음 중에서 고릅니다.

More(추가) 옵션은 다음과 같습니다.

이어서 다음도 설정합니다.

VPN Community 객체 — Advanced 설정

VPN Community 객체의 Advanced 페이지에서 다음 옵션을 설정합니다.

VPN Tunnel Sharing(터널 공유) 도 여기서 설정합니다. 절차는 다음과 같습니다.