NGINX Plus R17 발표

[ 편집자 - NGINX Plus용 NGINX ModSecurity WAF 모듈은 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며 2024년 3월 31 일부로 수명 종료 로 전환됩니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요.]

NGINX Plus 릴리스 17(R17) 이 출시되어 기쁩니다. NGINX Plus는 로드 밸런서, 콘텐츠 캐시, 웹 서버 및 API 게이트웨이를 모두 갖춘 유일한 제품입니다. NGINX Plus는 NGINX 오픈 소스를 기반으로 하며 독점적인 향상된 기능과 수상 경력에 빛나는 지원 기능이 포함되어 있습니다.

이번 릴리스의 새로운 기능은 인터넷의 모든 보안 트래픽을 담당하는 프로토콜의 최신 버전인 TLS 1.3에 대한 지원 입니다. TLS 1.2가 출시된 지 10년이 넘었고, 그 이후로 많은 변화가 있었습니다. TLS 1.2에서는 FREAK, Heartbleed, POODLE, ROBOT 등 다양한 보안 취약점이 발견되었습니다. 이러한 취약점의 대부분은 TLS 1.2에 너무 많은 안전하지 않은 구성 옵션이 있어 사이트가 공격에 노출되는 데서 비롯되었습니다.

TLS 1.3은 뺄셈을 통한 추가입니다. 안전하지 않은 암호 중 상당수가 제거되었으며 이제 Diffie‑Hellman 키 교환이 필수입니다. 그 결과 TLS는 더 가볍고 빠르며 보안도 더 강화되었습니다. 이 글을 쓰는 시점에서 Alpine Linux 3.9, FreeBSD 12.0, Ubuntu 18.10은 TLS 1.3을 지원하므로 운영 환경에서 TLS 1.3을 지원하는 NGINX Plus R17 과 함께 사용할 수 있습니다. 다른 OS 공급업체도 향후 릴리스에서 TLS 1.3을 지원할 가능성이 큽니다. F5 BIG-IP 및 기타 하드웨어 로드 밸런서는 현재 TLS 1.3을 완전히 지원하지 않습니다.

NGINX Plus R17 에는 다음과 같은 새로운 기능도 포함되어 있습니다.

• 2단계 속도 제한 – 속도 제한은 NGINX 오픈 소스와 NGINX 플러스에서 가장 인기 있는 기능 중 하나입니다. DDoS 공격을 완화하는 데 사용할 수 있으며, 일반적으로 너무 많은 요청으로 인해 애플리케이션 서버가 과부하되는 것을 방지하는 데 사용할 수 있습니다. 새로운 지연 매개변수는 NGINX Plus 속도 제한이 일반적인 브라우저 요청 패턴에 더 잘 대처할 수 있도록 도와줍니다. 기존의 지연 및 거부 시행 방법을 이제 결합하여 2단계 속도 제한을 제공할 수 있습니다. 즉, 과도한 요청은 처음에는 지연되지만 속도 제한을 계속 초과하면 궁극적으로 거부됩니다.
• 더욱 쉬운 OpenID Connect 구성 – NGINX Plus R15 에서 고객이 애플리케이션에 SSO(Single Sign-On)를 추가할 수 있도록 OpenID Connect 통합을 도입했습니다. R17에서는 ID 공급자(IdP)로부터 JSON 웹 키(JWK)를 자동으로 가져오는 구성을 간소화했습니다.
• NGINX Modsecurity WAF는 2배 더 빠릅니다 . ModSecurity v3 기반 NGINX Plus용 동적 모듈인 NGINX ModSecurity WAF는 레이어 7 공격으로부터 강력한 보호 기능을 제공합니다. ModSecurity는 활발히 개발되고 있으며 최신 버전의 NGINX ModSecurity WAF는 2배 더 뛰어난 성능과 다양한 추가 개선 사항을 제공합니다.

NGINX Plus R17 의 추가 개선 사항으로 는 업스트림에 대한 TCP keepalives, 클러스터 환경에서의 SNI 지원 등이 있습니다.

행동의 중요한 변화

• NGINX Plus R13은 이전에 해당 기능을 구현했던 Status 및 Upstream Conf API를 대체하여 메트릭 수집 및 업스트림 그룹의 동적 재구성을 위한 완전히 새로운 NGINX Plus API를 도입했습니다. 당시 발표된 대로, 지원되지 않는 API는 NGINX Plus R16 에서 종료될 때까지 상당 기간 동안 계속 사용 및 지원되었습니다. 구성에 status 및/또는 upstream_conf 지시문이 포함되어 있는 경우 R17로 업그레이드하는 과정에서 이를 api 지시문으로 바꿔야 합니다.

  NGINX Plus API 로의 마이그레이션에 대한 조언과 지원이 필요하면 블로그의 전환 가이드를 참조하거나 당사 지원팀에 문의하세요.

• 지원되는 새로운 운영 체제:

  • 알파인 리눅스 3.8
  • 알파인 리눅스 3.9
  • 프리BSD 11.2
  • 프리BSD 12.0
  • 수세 리눅스 엔터프라이즈 서버 15
  • 우분투 18.10(코스믹)

• 제거되었거나 제거 예정인 이전 운영 체제:

  • FreeBSD 10.4 및 11.1은 더 이상 지원되지 않습니다.
  • NGINX Plus R18 에서는 CentOS/Oracle/RHEL 7.3 및 이전 버전에 대한 지원이 중단됩니다.
  • NGINX Plus R19 에서는 Ubuntu 14.04에 대한 지원이 중단됩니다.

새로운 기능에 대한 자세한 정보

TLS 1.3: 뺄셈으로 더하기

TLS에 대한 주요 업데이트가 이루어진 지 10년이 넘었습니다. TLS 1.2는 2008년 8월에 RFC 5246 으로 정의되었으며, 그 이후로 인터넷은 상당한 변화를 겪었습니다. TLS 1.3은 TLS 1.2에서 발견된 많은 문제를 해결하고 미래를 위한 더욱 확장 가능한 플랫폼을 구축하기 위해 2018년 8월에 RFC 8446 으로 비준되었습니다.

더 안전하다

지난 몇 년 동안 TLS 1.2의 수많은 보안 취약점이 공개되었습니다. 여기에는 FREAK , Heartbleed , POODLE , ROBOT 등이 있습니다. 예를 들어, FREAK를 사용하면 공격자가 TLS 연결을 다운그레이드하여 40비트 키 길이의 내보내기 암호를 사용할 수 있으며, 이는 무차별 대입 공격이 가능합니다. TLS 1.3에서는 수출 암호가 완전히 제거되었습니다.

TLS 1.2 및 이전 사양에서 발생한 문제 중 다수는 사용자가 구성할 수 있는 옵션이 너무 많기 때문에 발생했습니다. 옵션을 잘못 사용하면 공격자가 악용할 수 있는 안전하지 않은 구성이 발생하는 경우가 많습니다. TLS 1.3은 다음 옵션 중 일부를 제거합니다.

• AES‑CBC
• 임의의 Diffie‑Hellman 그룹
• 암호 내보내기
• DES/3DES
• MD5
• PKCS#1 v1.5 패딩
• RC4
• RSA 키 전송(Diffie‑Hellman은 필수)
• SHA‑1

더 나은 성능

제거 목록에서 주목할 만한 것은 RSA 키 전송입니다. 이 모드는 완벽한 전방 비밀성(PFS)으로 연결을 설정하기 위해 추가적인 왕복이 필요한 Diffie‑Hellman보다 빠르기 때문에 주로 사용되었습니다. TLS 1.3을 사용하면 추가적인 왕복이 더 이상 필요하지 않습니다. 구성 옵션이 적기 때문에 교환해야 할 정보도 적고 Diffie‑Hellman 핸드셰이크는 완료하는 데 왕복 한 번만 걸립니다(다이어그램에는 핸드셰이크 후의 GET 요청도 나와 있습니다).

또한 TLS 1.3은 세션 재개를 지원하며, 이를 통해 클라이언트가 이전에 방문한 사이트로 돌아왔을 때 TLS 핸드셰이크를 반복하는 오버헤드를 제거하여 연결을 더 빠르게 설정할 수 있습니다. 이를 0‑RTT(제로 왕복 시간) 재개 라고도 하는데, 재개된 세션 동안 클라이언트와 서버 간에 핸드셰이크 메시지를 주고받을 필요가 없기 때문입니다. 세션 재개는 원래 세션 중에 공유 비밀을 생성하고 세션 티켓 에 저장하여 구현됩니다. 클라이언트가 돌아오면 요청과 함께 세션 티켓을 제시합니다. 이 요청은 티켓에 있는 공유 비밀로 암호화됩니다.

0‑RTT를 사용하면 아래 그림과 같이 리플레이 공격의 위험이 발생합니다. 이 시나리오에서 공격자는 두 은행 계좌 간에 돈을 이체하는 요청과 같이 상태 변경을 초래하는 패킷을 다시 보냅니다.

재생 공격으로부터 보호하기 위해 클라이언트가 0‑RTT 데이터(공유 비밀로 암호화된 데이터)로 보내야 하는 유일한 HTTP 요청 유형은 GET 입니다. HTTP GET 요청은 정의상 멱등적이므로( RFC 7231 ) 이를 재생해도 아무런 효과가 없습니다. 페이지를 로드하는 것은 일반적으로 클라이언트가 사이트를 다시 방문했을 때 가장 먼저 하는 일이며, 대부분의 페이지 로드는 GET 요청으로 시작하므로 세션 재개를 활성화하면 대부분 웹사이트에 대한 요청 속도가 상당히 빨라집니다. 하지만 NGINX Plus를 API 게이트웨이로 배포하는 경우 0‑RTT 재개를 활성화하지 않으려 할 수 있습니다. API 트래픽의 경우 재개된 TLS 세션에 멱등하지 않은 요청 유형이 포함될 가능성이 더 높기 때문입니다.

TLS 1.3 자체도 세션 티켓과 클라이언트 요청에 타이밍 정보를 포함함으로써 리플레이 공격으로부터 보호합니다. 이를 통해 서버는 클라이언트가 요청을 보낸 후 얼마 지나지 않아 요청이 도착했는지 확인할 수 있습니다. 공격자는 타이밍 정보를 변경할 수 없으므로 요청이 도착하는 데 너무 오래 걸리는 경우 아마도 재전송되었을 것입니다.

NGINX Plus에서 TLS 1.3을 활성화하는 방법

TLS 1.3 및 0‑RTT는 기본적으로 활성화되어 있지 않습니다.

TLS 1.3을 활성화하려면 ssl_protocols 지시문에 TLSv1.3 매개변수를 포함합니다. 이 글을 쓰는 시점에서 모든 브라우저가 TLS 1.3을 지원하지는 않으므로 TLSv1.2 도 포함하는 것이 좋습니다(다음 섹션 참조). NGINX Plus는 클라이언트가 지원하는 경우 TLS 1.3을 사용하고, 그렇지 않으면 TLS 1.2를 사용합니다.

0‑RTT를 활성화하려면 ssl_early_data 지시어도 on 으로 설정합니다.

이 구성을 사용하면 두 가지 기능이 모두 활성화됩니다.

서버 { listen 443 ssl; ssl_certificate /etc/ssl/my_site_cert.pem; ssl_certificate_key /etc/ssl/my_site_key.pem; ssl_protocols TLSv1.2 TLSv1.3 ; ssl_early_data on ; # 0-RTT(TLS 1.3) 활성화 location / { proxy_pass http://my_backend; } }

지원 플랫폼

서버 측에서는 TLS 1.3에 OpenSSL 1.1.1 이상이 필요합니다. 이 글을 쓰는 시점에서 OpenSSL 1.1.1은 Alpine Linux 3.9, FreeBSD 12.0, Ubuntu 18.10에만 제공됩니다.

클라이언트 측에서는 Chrome 70 또는 Firefox 63을 권장합니다. 이들은 TLS 1.3의 최종 버전을 지원하지만 기본적으로 활성화되어 있지 않습니다. 브라우저에서 TLS 1.3을 활성화하려면 다음 지침을 따르세요. 이 글을 쓰는 시점에서 다른 인기 브라우저(Android용 Firefox, iOS와 Mac용 Safari 포함)는 아직 TLS 1.3을 지원하지 않습니다. 최신 상태 정보는 Can I Use를 참조하세요. .TLS 1.3 (인터넷 프로토콜 버전 1.3 )

2단계 속도 제한

이전에는 NGINX Plus가 두 가지 방법으로 요청 속도에 제한을 적용할 수 있었습니다. 즉, 과도한 요청을 즉시 거부하거나, 정의된 속도 제한에 따라 처리될 때까지 과도한 요청을 대기열에 넣는 것입니다. NGINX Plus R17을 사용하면 두 가지 시행 방법을 결합하여 2단계 속도 제한을 적용할 수 있습니다. 즉, 과도한 요청은 처음에는 지연되고 속도 제한을 계속 초과하면 궁극적으로 거부됩니다.

요금 제한을 적용할 때는 합법적인 고객의 일반적인 행동을 고려하는 것이 중요합니다. 예를 들어, 웹 브라우저는 일반적으로 여러 리소스를 동시에 다운로드하려고 시도하므로 HTML 콘텐츠에 대한 요청이 먼저 나오고 이어서 스타일시트, JavaScript 코드, 이미지에 대한 요청이 나오는 것은 당연합니다. 이러한 이유로 속도 제한을 적용하기 전에 10~20개의 빠른 요청 버스트를 허용할 수 있습니다.

NGINX Plus R17을 사용하면 일반적인 웹 브라우저 요청 패턴에 맞게 버스트를 허용한 다음 추가적으로 과도한 요청을 일정 지점까지 지연시킨 후, 그 지점을 넘어서면 추가적으로 과도한 요청을 거부할 수 있습니다. limit_req 지시문에 새로운 지연 매개변수를 추가하면 2단계 속도 제한이 활성화됩니다.

2단계 속도 제한을 설명하기 위해 여기서는 초당 5개 요청( rate=5r/s )의 속도 제한을 부과하여 웹사이트를 보호하도록 NGINX Plus를 구성합니다. 웹사이트에는 일반적으로 페이지당 4~6개의 리소스가 있으며, 최대 12개의 리소스가 있습니다. 이 구성을 사용하면 최대 12개 요청의 버스트가 가능하며, 그 중 처음 8개 요청은 지연 없이 처리됩니다. 5 r/s 제한을 강제하기 위해 8개의 과도한 요청 후에 지연이 추가됩니다. 12번 이상의 과도한 요청이 접수되면 추가 요청은 거부됩니다.

limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;
server {
listen 80;
location / {
limit_req zone=ip burst=12 delay=8;
proxy_pass http://website;
}
}

지연 매개변수는 정의된 속도 제한을 준수하기 위해 버스트 크기 내에서 과도한 요청이 조절(지연)되는 지점을 정의합니다. 이 구성을 적용하면 8 r/s의 속도로 연속적으로 요청을 보내는 클라이언트는 다음과 같은 동작을 경험하게 됩니다.

첫 번째 8개 요청( delay 값)은 지연 없이 NGINX Plus에 의해 프록시됩니다. 다음 4개의 요청( 버스트 - 지연 )은 정의된 속도인 5 r/s를 초과하지 않도록 지연됩니다. 다음 3개 요청은 총 버스트 크기를 초과했기 때문에 거부되었습니다. 이후의 요청은 지연됩니다.

이 그림은 완료된 요청이 처리되고 있는 과도한 요청의 수를 계산하는 데 미치는 영향을 무시했기 때문에 프로세스를 단순화한 설명입니다. 실제로 완료된 각 요청은 구성된 버스트 크기에 맞추기 위해 다른 과도한 요청을 위한 지연 대기열에 슬롯을 엽니다. 속도 제한 구현에 대한 자세한 내용은 블로그의 NGINX 및 NGINX Plus를 사용한 속도 제한을 참조하세요.

더 쉬운 OpenID Connect 구성

JWT 검증을 수행할 때 이제 NGINX Plus R17을 구성하여 새 auth_jwt_key_request 지시문에서 지정한 원격 위치(일반적으로 ID 공급자 또는 IdP)에서 JSON 웹 키(JWK) 세트를 가져올 수 있습니다. 자동 페칭은 키를 자주 순환하는 IdP와 통합할 때 특히 편리합니다.

대부분의 IdP는 현재 키 세트를 얻을 수 있는 고정 URL을 제공하며, 특히 OpenID Connect Discovery를 지원하는 경우에 그렇습니다. 이 경우 키의 URL은 jwks_uri 값으로 정의됩니다.

# IdPproxy_cache_path에서 받은 키를 캐시할 디렉토리를 만듭니다. /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
listen 80; # 프로덕션에서 SSL/TLS 사용

location / {
auth_jwt "closed site";
auth_jwt_key_request /_jwks_uri; # 하위 요청에서 키를 가져옵니다.

proxy_pass http://my_backend;
}

location = /_jwks_uri {
internal;
proxy_cache jwk; # 응답 캐시
proxy_pass https://idp.example.com/oauth2/keys; # 여기에서 키 가져오기
}
}

추가 캐싱 지침을 사용하면 하위 요청에서 반환된 Expires 및 Cache-Control 헤더를 재정의할 수 있습니다. proxy_cache_use_stale을 사용하면 키의 URL을 사용할 수 없을 때에도 NGINX Plus가 캐시된 키를 계속 사용할 수 있습니다.

OpenID Connect 참조 구현이 업데이트되어 auth_jwt_key_request 에 대한 지원과 OpenID Connect Discovery를 지원하는 IdP에 대한 자동 구성이 포함되었습니다.

JWT 지원은 Edwards‑curve Digital Signature Algorithm (EdDSA)의 두 가지 변형을 지원하도록 확장되었습니다. Ed448과 Ed25519. EdDSA에는 OpenSSL 1.1.1 이상이 필요한데, 이 글을 쓰는 시점에서는 Ubuntu 18.10 및 FreeBSD 12.0에서만 사용할 수 있습니다.

메모: OpenID Connect 지원은 NGINX Plus에서만 제공됩니다.

2배 더 빠른 NGINX ModSecurity WAF

NGINX Plus용 NGINX ModSecurity WAF 모듈은 100만 개가 넘는 사이트에서 사용되는 오픈 소스 ModSecurity 웹 애플리케이션 방화벽(WAF)의 지원 빌드입니다. 우리는 NGINX Plus를 사용하여 ModSecurity 성능을 개선하기 위해 TrustWave SpiderLabs 팀과 적극적으로 협력하고 있으며, 최신 릴리스는 이전 릴리스보다 두 배 더 뛰어난 성능을 보인다는 사실을 보고하게 되어 기쁩니다.

이 릴리스에서는 pdateActionById , ctl:requestBodyProcessor=URLENCODED 및 setenv 작업에 대한 지원도 추가되었습니다.

새로운 NGINX ModSecurity WAF 빌드는 ModSecurity 3.0.3을 기반으로 합니다. 자세한 내용은 TrustWave SpiderLabs 블로그를 참조하세요.

메모: NGINX ModSecurity WAF는 NGINX Plus에서만 제공됩니다.

NGINX Plus R17 의 기타 새로운 기능

업스트림에 대한 TCP Keepalives

새로운 proxy_socket_keepalive 지시어는 NGINX Plus와 프록시 서버 간에 TCP keepalive를 활성화할지 여부를 제어합니다. TCP keepalive는 NGINX와 프록시 서버 사이에 상태가 유지되는 TCP 네트워크 장치가 있고 해당 연결이 오랫동안 유지되고 종종 유휴 상태인 프로토콜(예: WebSocket)의 성능을 개선합니다. TCP keepalive가 없다면 이러한 장치는 유휴 TCP 연결을 더 자주 닫을 수 있으며, 연결을 처음부터 다시 설정해야 하는 오버헤드가 발생할 수 있습니다.

이 지시문은 FastCGI , gRPC , memcached , SCGI 및 uwsgi 모듈에서도 사용할 수 있습니다.

업스트림 HTTP Keepalive 시간 초과 및 요청 제한

새로운 keepalive_timeout 지시어는 NGINX Plus와 프록시 서버 간의 HTTP keepalive 연결이 닫히기 전의 최대 유휴 시간을 설정합니다. 또한 keepalive_requests 지시어는 keepalive 연결을 통해 보낼 수 있는 최대 요청 수를 설정합니다(이 시점에서는 연결은 닫히고 새 연결이 생성됩니다).

유한 업스트림 UDP 세션 크기

새로운 proxy_requests 지시문(스트림 모듈)은 새 UDP "세션"이 생성되기 전에 NGINX Plus에서 프록시 서버로 전송되는 UDP 패킷의 최대 수를 설정합니다. 이를 통해 단일 클라이언트가 단시간에 대량의 UDP 패킷을 보낼 때(예를 들어 다운스트림 프록시가 있는 경우) UDP 패킷의 부하 분산을 보다 균등하게 수행할 수 있습니다.

클러스터 상태 공유 향상

클러스터에서 상태 공유를 사용할 때 이제 SNI를 사용하여 서버 이름을 검증하고, 클러스터 노드에 연결할 때 서버 이름을 전달할 수 있습니다. 이는 zone_sync_ssl_name 및 zone_sync_ssl_server_name 지시어로 구현됩니다.

메모: 클러스터링 및 zone_sync 모듈은 NGINX Plus에서만 제공됩니다.

NGINX Plus 에코시스템 업데이트

Ingress 컨트롤러 향상

Kubernetes용 공식 NGINX Ingress Controller가 1.4.0 버전으로 업데이트되었습니다. 변경 로그 에는 모든 변경 사항, 수정 사항, 개선 사항이 나열되어 있으며, 가장 주목할 만한 내용은 블로그 에 강조 표시되어 있습니다.

• 확장된 Prometheus 지원
• TCP/UDP 부하 분산
• Two Choices가 있는 Random 부하 분산 알고리즘은 새로운 기본입니다.
• 사용자 정의 주석

저희 웹사이트와 GitHub 저장소 에서 Kubernetes용 공식 NGINX Ingress Controller에 대한 자세한 내용을 확인하세요.

JavaScript 모듈 향상

NGINX Plus R17 에는 JavaScript 언어 지원 범위를 확장하는 여러 가지 향상 기능이 포함되어 있습니다.

• 인수 객체
• 정수가 아닌 분수
• 추가 시간 메서드: console.time() 및 console.timeEnd()
• 이제 변수와 함수를 다시 선언할 수 있습니다.

TCP/UDP 애플리케이션을 위한 NGINX Stream 모듈과의 통합이 다양한 반환 함수를 사용하도록 리팩토링되었으며, 여기에는 수신 트래픽을 수정하기 위한 send() 메서드가 포함됩니다. 이제 콜백을 통해 이탈 트래픽을 이용할 수 있습니다.

전체 변경 사항은 NGINX JavaScript 모듈 변경 로그 에서 확인할 수 있습니다.

업그레이드 또는 NGINX Plus를 사용해 보세요

NGINX Plus R17 에는 TLS 1.3에 대한 지원이 포함되어 있어 TLS 1.2보다 보안성이 높고 성능도 더 좋습니다. NGINX Plus를 실행 중이라면 가능한 한 빨리 릴리스 17 및 TLS 1.3으로 업그레이드하는 것을 적극 권장합니다. 또한 여러 가지 추가적인 수정 사항과 개선 사항을 얻을 수 있으며, 이는 지원 티켓을 제출해야 할 때 NGINX, Inc.에서 도움을 드리는 데 도움이 됩니다.

업그레이드를 진행하기 전에 이 블로그 게시물에 설명된 새로운 기능과 동작의 변경 사항 을 주의 깊게 검토하세요.

NGINX Plus 또는 NGINX ModSecurity WAF를 사용해 본 적이 없다면 보안, 부하 분산, API 게이트웨이로 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽하게 지원되는 웹 서버로 사용해 보는 것을 권장합니다. 오늘 무료 30일 평가판을 통해 무료로 시작해보세요. NGINX Plus가 어떻게 귀하의 애플리케이션을 제공하고 확장하는 데 도움이 될 수 있는지 직접 확인해 보세요.

[ 편집자 - NGINX ModSecurity WAF는 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며 2024년 3월 31일 부터 수명 종료 로 전환됩니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요.]