IPsec 기본 사항
IPsec 개요
IPsec은 IP 패킷 계층에서 암호화 방식으로 통신을 보호하기 위한 관련 프로토콜 모음입니다. IPsec은 또한 보안 연결(SA) 및 키 배포의 수동 및 자동 협상을 위한 방법을 제공하며, 모든 속성은 해석 도메인(DOI)에서 수집됩니다. IPsec DOI는 VPN 터널의 성공적인 협상에 필요한 모든 보안 매개 변수, 즉 기본적으로 SA 및 IKE 협상에 필요한 모든 속성에 대한 정의를 포함하는 문서입니다. 자세한 내용은 RFC 2407 및 RFC 2408을 참조하십시오.
IPsec 보안 서비스를 사용하려면 호스트 간에 SA를 생성합니다. SA는 두 호스트가 IPsec을 통해 서로 안전하게 통신할 수 있도록 하는 단순 연결입니다. SA에는 두 가지 유형이 있습니다. 수동 및 동적.
IPsec은 두 가지 보안 모드(전송 모드 및 터널 모드)를 지원합니다.
보안 연결
SA(보안 연결)는 통신 채널 보안에 사용할 방법 및 매개 변수에 관한 VPN 참가자 간의 단방향 계약입니다. 완전한 양방향 통신에는 각 방향에 하나씩 최소 두 개의 SA가 필요합니다. IPsec 터널은 SA를 통해 다음과 같은 보안 기능을 제공할 수 있습니다.
개인 정보 보호(암호화를 통해)
콘텐츠 무결성(데이터 인증을 통해)
보낸 사람 인증 및 인증서를 사용하는 경우 부인 방지(데이터 원본 인증을 통해)
사용하는 보안 기능은 필요에 따라 다릅니다. IP 패킷 소스 및 콘텐츠 무결성만 인증해야 하는 경우에는 암호화를 적용하지 않고 패킷을 인증할 수 있습니다. 반면에 개인 정보 보호에만 관심이 있는 경우 인증 메커니즘을 적용하지 않고 패킷을 암호화할 수 있습니다. 선택적으로 패킷을 암호화하고 인증할 수 있습니다. 대부분의 네트워크 보안 설계자는 VPN 트래픽을 암호화, 인증 및 재생 보호 방식을 선택합니다.
IPsec 터널은 SPI(Security Parameter Index), 대상 IP 주소 및 보안 프로토콜(사용되는 인증 헤더[AH] 또는 캡슐화 보안 페이로드[ESP])을 지정하는 한 쌍의 단방향 SA(터널의 각 방향에 대해 하나의 SA)로 구성됩니다. SA는 통신 보안을 위해 다음과 같은 구성 요소를 그룹화합니다.
보안 알고리즘 및 키.
프로토콜 모드(전송 또는 터널)입니다. Junos OS 디바이스는 항상 터널 모드를 사용합니다. ( 터널 모드에서의 패킷 처리를 참조하십시오.)
키 관리 방법(수동 키 또는 자동 키 IKE)
SA 수명.
인바운드 트래픽의 경우, Junos OS는 다음 트리플렛을 사용하여 SA를 찾습니다.
대상 IP 주소입니다.
AH 또는 ESP의 보안 프로토콜입니다.
SPI(Security Parameter Index) 값입니다.
아웃바운드 VPN 트래픽의 경우 정책은 VPN 터널과 연결된 SA를 호출합니다.
IPsec 키 관리
키의 배포 및 관리는 VPN을 성공적으로 사용하는 데 매우 중요합니다. Junos OS는 세 가지 종류의 키 생성 메커니즘으로 VPN 터널을 생성하기 위한 IPsec 기술을 지원합니다.
수동 키
사전 공유 키 또는 인증서가 있는 자동 키 IKE(Internet Key Exchange)
1단계 및 2단계 제안 구성 중에 키 생성 메커니즘(인증 방법이라고도 함)을 선택할 수 있습니다. Internet Key Exchange를 참조하십시오.
이 주제는 다음 섹션을 포함합니다.
수동 키
수동 키를 사용하여 터널 양쪽 끝의 관리자가 모든 보안 매개 변수를 구성합니다. 이는 키의 배포, 유지 관리 및 추적이 어렵지 않은 소규모 정적 네트워크에 실행 가능한 기술입니다. 그러나 수동 키 구성을 먼 거리에 안전하게 배포하면 보안 문제가 발생합니다. 키를 직접 대면하여 전달하는 것 외에는 전송 중에 키가 손상되지 않았는지 완전히 확신할 수 없습니다. 또한 키를 변경하려고 할 때마다 처음 배포할 때와 동일한 보안 문제에 직면하게 됩니다.
자동 키 IKE(Internet Key Exchange)
수많은 터널을 생성하고 관리해야 하는 경우 모든 요소를 수동으로 구성할 필요가 없는 방법이 필요합니다. IPsec은 IKE(Internet Key Exchange) 프로토콜을 사용하여 키 및 보안 연결의 자동 생성 및 협상을 지원합니다. Junos OS는 자동 키 IKE(Internet Key Exchange)와 같은 자동화된 터널 협상을 지칭하며, 사전 공유 키를 사용하는 자동 키 IKE(Internet Key Exchange)와 인증서를 통한 자동 키 IKE(Internet Key Exchange)를 지원합니다.
사전 공유 키가 있는 자동 키 IKE(Internet Key Exchange) - 사전 공유 키와 함께 자동 키 IKE(Internet Key Exchange)를 사용하여 IKE(Internet Key Exchange) 세션에서 참가자를 인증할 때, 양측은 사전 공유 키를 미리 구성하고 안전하게 교환해야 합니다. 이와 관련하여 보안 키 배포 문제는 수동 키의 문제와 동일합니다. 그러나 일단 배포되면 자동 키는 수동 키와 달리 IKE 프로토콜을 사용하여 미리 결정된 간격으로 키를 자동으로 변경할 수 있습니다. 키를 자주 변경하면 보안이 크게 향상되며 자동으로 변경하면 키 관리 책임이 크게 줄어듭니다. 그러나 키를 변경하면 트래픽 오버헤드가 증가합니다. 따라서 키를 너무 자주 변경하면 데이터 전송 효율성이 떨어질 수 있습니다.
사전 공유 키는 암호화 및 암호 해독을 위한 키로, 통신을 시작하기 전에 두 참가자가 모두 가지고 있어야 합니다.
인증서가 있는 자동 키 IKE(Internet Key Exchange) - 자동 키 IKE(Internet Key Exchange) 협상 중에 인증서를 사용하여 참가자를 인증할 때 각 측에서 공개-개인 키 쌍을 생성하고 인증서를 획득합니다. 발급 인증 기관(CA)이 양측에서 신뢰되는 한 참가자는 피어의 공개 키를 검색하고 피어의 서명을 확인할 수 있습니다. 키와 SA를 추적할 필요가 없습니다. IKE(Internet Key Exchange)가 자동으로 수행합니다.
Diffie-Hellman 교환
DH(Diffie-Hellman) 교환을 통해 참가자는 공유 비밀 값을 생성할 수 있습니다. 이 기술의 강점은 참가자가 유선으로 비밀 값을 전달하지 않고 보안되지 않은 매체를 통해 비밀 값을 만들 수 있다는 것입니다. 각 그룹의 계산에 사용되는 프라임 모듈러스의 크기는 아래 표와 같이 다릅니다. DH(Diffie Hellman) 교환 작업은 소프트웨어 또는 하드웨어에서 수행할 수 있습니다. 다음은 표 1 다양한 DH(Diffie Hellman) 그룹을 나열하고 해당 그룹에 대해 수행된 작업이 하드웨어에 있는지 또는 소프트웨어에 있는지 여부를 지정합니다.
|
DH(Diffie-Hellman) 그룹 |
프라임 모듈 크기 |
|---|---|
|
DH 그룹 1 |
768비트 |
|
DH 그룹 2 |
102비트 |
|
DH 그룹 5 |
1536비트 |
|
DH 그룹 14 |
2048비트 |
|
DH 그룹 15 |
3072비트 |
|
DH 그룹 16 |
4096비트 |
|
DH 그룹 19 |
256비트 타원 곡선 |
|
DH 그룹 20 |
384비트 타원 곡선 |
|
DH 그룹 21 |
521비트 타원 곡선 |
|
DH 그룹 24 |
2048비트(256비트 프라임 오더 하위 그룹) |
Junos OS 릴리스 19.1R1부터 SRX 시리즈 방화벽(SRX300, SRX320, SRX340, SRX345, SRX380, SRX550HM 시리즈 방화벽 제외)은 DH 그룹 15, 16 및 21을 지원합니다.
Junos OS 릴리스 20.3R1부터 junos-ike 패키지가 설치된 vSRX 가상 방화벽(vSRX 3.0) 인스턴스는 DH 그룹 15, 16 및 21을 지원합니다.
DH 그룹 1, 2 및 5는 사용하지 않는 것이 좋습니다.
각 DH 그룹의 모듈러스는 크기가 다르기 때문에 참가자는 동일한 그룹을 사용하는 데 동의해야 합니다.
IPsec 보안 프로토콜
IPsec은 IP 계층에서 통신을 보호하기 위해 두 가지 프로토콜을 사용합니다.
인증 헤더(AH) - IP 패킷의 소스를 인증하고 해당 콘텐츠의 무결성을 검증하기 위한 보안 프로토콜입니다
ESP(Encapsulating Security Payload) - 전체 IP 패킷을 암호화하고 해당 콘텐츠를 인증하기 위한 보안 프로토콜입니다
2단계 제안 구성 중에 보안 프로토콜(이라고도 authentication and encryption algorithms함)을 선택할 수 있습니다. Internet Key Exchange를 참조하십시오.
각 VPN 터널에 대해 AH 및 ESP 터널 세션은 모두 SPU(Services Processing Unit) 및 컨트롤 플레인에 설치됩니다. 터널 세션은 협상이 완료된 후 협상된 프로토콜로 업데이트됩니다. SRX5400, SRX5600 및 SRX5800 디바이스의 경우 앵커 SPU의 터널 세션은 협상된 프로토콜로 업데이트되고 비앵커 SPU는 ESP 및 AH 터널 세션을 유지합니다. ESP 및 AH 터널 세션은 및 show security flow cp-session 운영 모드 명령의 show security flow session 출력에 표시됩니다.
이 주제는 다음 섹션을 포함합니다.
IPsec 인증 알고리즘(AH 프로토콜)
인증 헤더(AH) 프로토콜은 콘텐츠의 신뢰성과 무결성 및 패킷의 출처를 검증하는 수단을 제공합니다. 비밀 키와 MD5 또는 SHA 해시 함수를 사용하여 HMAC(Hash Message Authentication Code)를 통해 계산된 체크섬으로 패킷을 인증할 수 있습니다.
MD5(Message Digest 5) - 임의 길이의 메시지와 16바이트 키에서 128비트 해시( 디지털 서명 또는 메시지 다이제스트라고도 함)를 생성하는 알고리즘입니다. 결과 해시는 입력의 지문처럼 콘텐츠와 소스 신뢰성 및 무결성을 확인하는 데 사용됩니다.
보안 해시 알고리즘(SHA) - 임의 길이의 메시지와 20바이트 키에서 160비트 해시를 생성하는 알고리즘입니다. 일반적으로 MD5가 생성하는 해시가 크기 때문에 MD5보다 더 안전한 것으로 간주됩니다. 계산 처리가 ASIC에서 수행되기 때문에 성능 비용은 무시할 수 있습니다.
MD5 해시 알고리즘에 대한 자세한 내용은 RFC 1321 및 RFC 2403을 참조하십시오. SHA 해시 알고리즘에 대한 자세한 내용은 RFC 2404를 참조하십시오. HMAC에 대한 자세한 내용은 RFC 2104를 참조하세요.
IPsec 암호화 알고리즘(ESP 프로토콜)
ESP(Encapsulating Security Payload) 프로토콜은 개인 정보 보호(암호화) 및 소스 인증과 콘텐츠 무결성(인증)을 보장하는 수단을 제공합니다. 터널 모드의 ESP는 전체 IP 패킷(헤더 및 페이로드)을 캡슐화한 다음 현재 암호화된 패킷에 새 IP 헤더를 추가합니다. 이 새 IP 헤더에는 네트워크를 통해 보호된 데이터를 라우팅하는 데 필요한 대상 주소가 포함되어 있습니다. ( 터널 모드에서의 패킷 처리를 참조하십시오.)
ESP를 사용하면 암호화와 인증, 암호화만 또는 인증만 할 수 있습니다. 암호화의 경우 다음 암호화 알고리즘 중 하나를 선택할 수 있습니다.
-
DES(Data Encryption Standard) - 56비트 키를 사용하는 암호화 블록 알고리즘입니다.
-
3DES(Triple DES) - 원래 DES 알고리즘이 168비트 키를 사용하여 3라운드에 걸쳐 적용되는 보다 강력한 DES 버전입니다. DES는 상당한 성능 절감 효과를 제공하지만 많은 기밀 또는 민감한 자료 전송에 허용되지 않는 것으로 간주됩니다.
-
AES(Advanced Encryption Standard) - 다른 디바이스와의 상호 운용성을 향상시키는 암호화 표준입니다. Junos OS는 128비트, 192비트 및 256비트 키로 AES를 지원합니다.
-
ChaCha20-Poly1305 Authenticated Encryption with Associated Data—Poly1305 인증자를 사용하여 AEAD(Authenticated Encryption with Associated Data)를 지원하는 ChaCha20 스트림 암호입니다.
인증의 경우 MD5 또는 SHA 알고리즘을 사용할 수 있습니다.
암호화를 위해 NULL을 선택할 수 있지만 이러한 상황에서는 IPsec이 공격에 취약할 수 있음이 입증되었습니다. 따라서 최대한의 보안을 위해 암호화 알고리즘을 선택하는 것이 좋습니다.
IPsec 터널 협상
VPN에서 트래픽 교환 방법을 결정하는 다음 두 가지 모드.
터널 모드 - VPN 터널의 다른 패킷 내에 원래 IP 패킷을 캡슐화하여 트래픽을 보호합니다. 이 모드에서는 IKE와 사전 공유 키를 사용하여 피어를 인증하거나 IKE와 디지털 인증서를 사용하여 피어를 인증합니다. 이는 별도의 개인 네트워크 내의 호스트가 공용 네트워크를 통해 통신하려는 경우 가장 일반적으로 사용됩니다. 이 모드는 VPN 클라이언트와 VPN 게이트웨이 모두에서 사용할 수 있으며 비 IPsec 시스템에서 들어오거나 나가는 통신을 보호합니다.
전송 모드 - IPsec 터널을 설정한 두 호스트 간에 패킷을 직접 전송하여 트래픽을 보호합니다. 즉, 통신 엔드포인트와 암호화 엔드포인트가 동일한 경우입니다. IP 패킷의 데이터 부분은 암호화되지만 IP 헤더는 암호화되지 않습니다. 보호된 호스트에 암호화 및 암호 해독 서비스를 제공하는 VPN 게이트웨이는 보호된 VPN 통신에 전송 모드를 사용할 수 없습니다. 패킷이 가로채는 경우 소스 또는 대상의 IP 주소를 수정할 수 있습니다. 전송 모드는 구성 때문에 통신 끝점과 암호화 끝점이 동일한 경우에만 사용할 수 있습니다.
지원되는 IPsec 및 IKE(Internet Key Exchange) 표준
하나 이상의 MS-MPC, MS-MIC 또는 DPC가 장착된 라우터에서 캐나다 및 미국 버전의 Junos OS는 IPsec(IP Security) 및 IKE(Internet Key Exchange)에 대한 표준을 정의하는 다음 RFC를 실질적으로 지원합니다.
-
RFC 2085, HMAC-MD5 IP 인증(재생 방지 포함)
-
RFC 2401, 인터넷 프로토콜의 보안 아키텍처 (RFC 4301에 의해 사용되지 않음)
-
RFC 2402, IP 인증 헤더 (RFC 4302에 의해 사용되지 않음)
-
RFC 2403, ESP 및 AH 내에서 HMAC-MD5-96 사용
-
RFC 2404, ESP 및 AH 내에서 HMAC-SHA-1-96 사용 (RFC 4305에 의해 사용되지 않음)
-
RFC 2405, 명시적 IV를 사용하는 ESP DES-CBC 암호 알고리즘
-
RFC 2406, IP ESP(Encapsulating Security Payload)( RFC 4303 및 RFC 4305에 의해 사용되지 않음)
-
RFC 2407, ISAKMP에 대한 인터넷 IP 보안 해석 도메인 (RFC 4306에 의해 사용되지 않음)
-
RFC 2408, ISAKMP(Internet Security Association and Key Management Protocol)( RFC 4306에 의해 사용되지 않음)
-
RFC 2409, IKE(Internet Key Exchange)( RFC 4306에 의해 사용되지 않음)
-
RFC 2410, NULL 암호화 알고리즘 및 IPsec에서의 사용
-
RFC 2451, ESP CBC 모드 암호 알고리즘
-
RFC 2560, X.509 인터넷 공개 키 인프라 온라인 인증서 상태 프로토콜 - OCSP
-
RFC 3193, IPsec을 사용한 L2TP 보안
-
RFC 3280, 인터넷 X.509 공개 키 인프라 인증서 및 인증서 해지 목록(CRL) 프로파일
-
RFC 3602, AES-CBC 암호 알고리즘 및 IPsec에서의 사용
-
RFC 3948, IPsec ESP 패킷의 UDP 캡슐화
-
RFC 4106, IPsec ESP(Encapsulating Security Payload)에서 GCM(Galois/Counter Mode) 사용
-
RFC 4210, 인터넷 X.509 공개 키 인프라 CMP(Certificate Management Protocol)
-
RFC 4211, 인터넷 X.509 공개 키 인프라 인증서 요청 메시지 형식(CRMF)
-
RFC 4301, 인터넷 프로토콜의 보안 아키텍처
-
RFC 4302, IP 인증 헤더
-
RFC 4303, IP ESP(Encapsulating Security Payload)
-
RFC 4305, ESP(Encapsulating Security Payload) 및 AH(Authentication Header)를 위한 암호화 알고리즘 구현 요구 사항
-
RFC 4306, IKEv2(Internet Key Exchange) 프로토콜
-
RFC 4307, 인터넷 키 교환 버전 2(IKEv2)에서 사용하기 위한 암호화 알고리즘
-
RFC 4308, IPsec용 암호화 제품군
Suite VPN-A만 Junos OS에서 지원됩니다.
-
RFC 4754, ECDSA(Elliptic Curve Digital Signature Algorithm)를 사용한 IKE 및 IKEv2 인증
-
RFC 4835, ESP(Encapsulating Security Payload) 및 AH(Authentication Header)를 위한 암호화 알고리즘 구현 요구 사항
-
RFC 5996, IKEv2(Internet Key Exchange Protocol Version 2)( RFC 7296에 의해 사용되지 않음)
-
RFC 7296, IKEv2(Internet Key Exchange Protocol Version 2)
-
RFC 8200, 인터넷 프로토콜, 버전 6(IPv6) 사양
-
RFC 7634, ChaCha20, Poly1305 및 IKE(Internet Key Exchange Protocol) 및 IPsec에서의 사용
Junos OS는 IPsec 및 IKE(Internet Key Exchange)에 대해 다음 RFC를 부분적으로 지원합니다.
RFC 3526, IKE(Internet Key Exchange)를 위한 MODP(More Modular Exponential) Diffie-Hellman 그룹
RFC 5114, IETF 표준과 함께 사용하기 위한 추가 Diffie-Hellman 그룹
RFC 5903, IKE 및 IKEv2에 대한 ECP 프라임(Elliptic Curve Groups modulo a Prime)
다음 RFC 및 인터넷 초안은 표준을 정의하지 않지만 IPsec, IKE 및 관련 기술에 대한 정보를 제공합니다. IETF는 이를 "정보성"으로 분류합니다.
RFC 2104, HMAC: 메시지 인증을 위한 키 해시
RFC 2412, OAKLEY 키 결정 프로토콜
RFC 3706, 데드 IKE(Internet Key Exchange) 피어를 탐지하는 트래픽 기반 방법
인터넷 초안 draft-eastlake-sha2-02.txt, 미국 보안 해시 알고리즘(SHA 및 HMAC-SHA)( 2006년 7월 만료)
참조
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.