NGINX Plus R17 출시 발표

NGINX | 2018년 12월 11일

[편집자 – 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 Open Source를 기반으로 하며, 독점적인 고급 기능과 수상 경력에 빛나는 지원 서비스를 제공합니다.

이번 릴리스에는 TLS 1.3 지원이 새롭게 추가되었습니다. 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을 지원하므로, 프로덕션 환경에서 NGINX Plus R17과 함께 TLS 1.3을 사용할 수 있습니다. 다른 OS 공급업체도 향후 릴리스에서 TLS 1.3을 지원할 것이 분명합니다. 단, F5 BIG-IP 및 기타 하드웨어 로드 밸런서는 현재 TLS 1.3을 완전히 지원하지 않습니다.

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

2단계 요청 속도 제한 – 요청 속도 제한은 NGINX Open Source와 NGINX Plus에서 가장 널리 사용되는 기능 중 하나입니다. 이 기능을 사용하면 DDoS 공격을 완화하고, 과도한 요청으로 인해 애플리케이션 서버에 과부하가 발생하지 않도록 전반적으로 보호할 수 있습니다. 새로운 delay 매개변수를 사용하면 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배 향상되었고 그 밖에도 여러 가지 개선 사항이 적용되었습니다.

추가 개선 사항에는 업스트림에 대한 TCP 연결 유지, 클러스터 환경에서의 SNI 지원 등이 포함됩니다.

중요한 동작 변경 사항

NGINX Plus R13에서는 메트릭 수집 및 업스트림 그룹의 동적 재구성을 위한 완전히 새로운 NGINX Plus API가 도입되어, 이전에 이러한 기능을 구현했던 Status 및 Upstream Conf API를 대체했습니다. 당시 발표한 바와 같이, 더 이상 사용되지 않는 API는 상당 기간 계속 제공되고 지원되었으나 NGINX Plus R16을 끝으로 종료되었습니다. 구성에 status 및/또는 upstream_conf 지시어가 포함되어 있다면 R17로 업그레이드할 때 이를 api 지시어로 교체해야 합니다. NGINX Plus API로 마이그레이션하는 방법과 관련 지원은 블로그의 전환 가이드를 참조하거나 지원팀에 문의해 주세요.
새롭게 지원되는 운영 체제:
- Alpine Linux 3.8
- Alpine Linux 3.9
- FreeBSD 11.2
- FreeBSD 12.0
- SUSE Linux Enterprise Server 15
- Ubuntu 18.10(Cosmic)
삭제되었거나 삭제 예정인 이전 운영 체제:
- FreeBSD 10.4 및 11.1은 더 이상 지원되지 않습니다.
- CentOS/Oracle/RHEL 7.3 이하 버전에 대한 지원은 NGINX Plus R18에서 중단됩니다.
- Ubuntu 14.04에 대한 지원은 NGINX Plus R19에서 중단됩니다.

새로운 기능 상세 정보

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)을 갖춘 연결을 설정하는 데 추가 왕복 통신이 필요했던 디피-헬먼보다 빠르다는 이유로 주로 사용되었습니다. TLS 1.3에서는 이러한 추가 왕복 통신이 더 이상 필요하지 않습니다. 구성 옵션이 줄어들면서 교환해야 할 정보도 감소하여 디피-헬먼 핸드셰이크는 단 한 번의 왕복 통신으로 완료됩니다(다이어그램에는 핸드셰이크 후 이어지는 GET 요청도 표시되어 있습니다).

TLS 1.3은 보안 연결을 설정하는 데 필요한 왕복 통신 횟수를 줄여 성능을 향상합니다.

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

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을 사용하려면 TLSv1.3 매개변수를 ssl_protocols 지시문에 포함하세요. 현재 모든 브라우저가 TLS 1.3을 지원하는 것은 아니므로 TLSv1.2도 함께 포함하는 것이 좋습니다(다음 섹션 참조). 클라이언트가 TLS 1.3을 지원하면 NGINX Plus는 TLS 1.3을 사용하고, 그렇지 않으면 TLS 1.2로 대체합니다.

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

이 구성은 두 기능을 모두 활성화합니다:

server {    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; # Enable 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에서 확인하세요.

2단계 요청 속도 제한

이전에는 NGINX Plus에서 요청 속도 제한을 적용하는 방법이 두 가지였습니다. 과도한 요청을 즉시 거부하거나, 정의된 속도 제한에 맞게 처리할 수 있을 때까지 과도한 요청을 대기열에 추가하는 방식이었습니다. NGINX Plus R17에서는 두 적용 방식을 결합하여 2단계 속도 제한을 구현할 수 있습니다. 이 방식에서는 과도한 요청을 처음에는 지연시키고, 이후에도 속도 제한을 초과하면 최종적으로 거부합니다.

요청 속도 제한을 적용할 때는 정상적인 클라이언트의 일반적인 동작을 고려해야 합니다. 예를 들어 웹 브라우저는 일반적으로 여러 리소스를 동시에 다운로드하려고 하므로, HTML 콘텐츠 요청 직후에 스타일시트, JavaScript 코드 및 이미지 요청이 빠르게 이어지는 것은 자연스러운 현상입니다. 따라서 요청 속도 제한을 적용하기 전에 10~20개의 요청이 짧은 시간에 집중되는 것을 허용할 수 있습니다.

NGINX Plus R17에서는 이제 일반적인 웹 브라우저 요청 패턴을 수용하도록 버스트를 허용한 다음, 일정 수준까지 추가 과도 요청을 지연시키고 그 수준을 넘는 추가 과도 요청은 거부할 수 있습니다. 2단계 요청 속도 제한은 delay 매개변수를 limit_req 지시문에 새로 추가하여 사용할 수 있습니다.

2단계 요청 속도 제한을 설명하기 위해, 여기서는 초당 5개의 요청으로 속도를 제한하여 웹사이트를 보호하도록 NGINX Plus를 구성합니다(rate=5r/s). 이 웹사이트는 일반적으로 페이지당 4~6개의 리소스를 포함하며, 12개를 초과하는 경우는 없습니다. 이 구성에서는 최대 12개의 요청이 한꺼번에 몰리는 것을 허용하며, 그중 처음 8개는 지연 없이 처리됩니다. 8개의 초과 요청 이후부터는 5 r/s 제한을 적용하기 위해 지연이 추가됩니다. 초과 요청이 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;
    }
}

The delay 매개변수는 버스트 크기 내에서 초과 요청이 정의된 요청 속도 제한을 준수하도록 제한(지연)되기 시작하는 지점을 지정합니다. 이 구성을 적용하면 초당 8개의 요청을 지속적으로 보내는 클라이언트는 다음과 같이 동작합니다.

다음 설정에서의 요청 속도 제한 동작 예시: rate=5r/s burst=12 delay=8

처음 8개의 요청(delay 값)은 NGINX Plus에서 지연 없이 프록시됩니다. 그다음 4개의 요청(burst - delay)은 정의된 속도인 5r/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 값으로 정의됩니다.

# Create a directory to cache the keys received from IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
    listen 80; # Use SSL/TLS in production

    location / {
        auth_jwt "closed site";
        auth_jwt_key_request /_jwks_uri; # Keys will be fetched by subrequest

        proxy_pass http://my_backend;
    }

    location = /_jwks_uri {
        internal;
        proxy_cache jwk; # Cache responses
        proxy_pass https://idp.example.com/oauth2/keys; # Obtain keys from here
    }
}

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

당사의 OpenID Connect 참조 구현이 업데이트되어 auth_jwt_key_request 지원 및 OpenID Connect Discovery를 지원하는 IdP의 자동 구성이 추가되었습니다.

JWT 지원도 다음 두 가지 변형을 지원하도록 확장되었습니다: 에드워즈 곡선 디지털 서명 알고리즘(EdDSA)의 Ed448 및 Ed25519입니다. EdDSA를 사용하려면 OpenSSL 1.1.1 이상이 필요하며, 이 글을 작성하는 시점에는 Ubuntu 18.10과 FreeBSD 12.0에서만 사용할 수 있습니다.

참고: OpenID Connect는 NGINX Plus에서만 지원됩니다.

2배 더 빨라진 NGINX ModSecurity WAF

The NGINX ModSecurity WAF NGINX Plus용 모듈은 백만 개 이상의 사이트에서 사용되는 오픈 소스 ModSecurity 웹 애플리케이션 방화벽(WAF)을 당사가 지원하는 형태로 빌드한 것입니다. 당사는 TrustWave SpiderLabs 팀과 적극적으로 협력하여 NGINX Plus에서 ModSecurity의 성능을 개선하고 있으며, 최신 릴리스의 성능이 이전 릴리스보다 두 배 향상되었다는 소식을 기쁘게 전합니다.

NGINX WAF는 레이어 7 공격으로부터 보호합니다

이번 릴리스에서는 pdateActionById, ctl:requestBodyProcessor=URLENCODED, 그리고 setenv 작업도 지원합니다.

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

참고: NGINX ModSecurity WAF는 NGINX Plus에서만 사용할 수 있습니다.

NGINX Plus R17의 기타 새로운 기능

업스트림에 대한 TCP 연결 유지

새로운 proxy_socket_keepalive 지시문은 NGINX Plus와 프록시 서버 간에 TCP 연결 유지 기능을 사용할지 여부를 제어합니다. TCP 연결 유지 기능은 NGINX와 프록시 서버 사이에 상태 저장형 TCP 네트워크 장치가 있고 연결이 장시간 유지되면서 유휴 상태인 경우가 많은 프로토콜(예: WebSocket)의 성능을 향상합니다. TCP 연결 유지 기능을 사용하지 않으면 이러한 장치가 유휴 TCP 연결을 더 자주 종료할 수 있으며, 이 경우 연결을 처음부터 다시 설정하는 데 따른 오버헤드가 발생합니다.

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

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

새로운 keepalive_timeout 지시문은 NGINX Plus와 프록시 서버 간의 HTTP keepalive 연결이 종료되기 전까지 허용되는 최대 유휴 시간을 설정합니다. 또한 keepalive_requests 지시문은 keepalive 연결을 통해 전송할 수 있는 최대 요청 수를 설정합니다. 이 수에 도달하면 연결이 종료되고 새 연결이 생성됩니다.

유한한 업스트림 UDP 세션 크기

새로운 proxy_requests 지시문(Stream 모듈)은 새 UDP ‘세션’이 생성되기 전에 NGINX Plus에서 프록시된 서버로 전송되는 UDP 패킷의 최대 개수를 설정합니다. 이를 통해 단일 클라이언트가 짧은 시간에 많은 UDP 패킷을 전송하는 경우(예: 다운스트림 프록시가 있는 경우) UDP 패킷의 부하를 더욱 균등하게 분산할 수 있습니다.

클러스터 상태 공유 기능 개선

클러스터에서 상태 공유를 사용할 때 이제 클러스터 노드에 연결하면서 SNI를 통해 서버 이름을 전달하여 서버 이름을 확인할 수 있습니다. 이 기능은 zone_sync_ssl_name 및 zone_sync_ssl_server_name 지시어를 통해 구현됩니다.

참고: 클러스터링 및 zone_sync 모듈은 NGINX Plus에서만 사용할 수 있습니다.

NGINX Plus 에코시스템 업데이트

Ingress Controller 개선 사항

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

Prometheus 지원 확대
TCP/UDP 부하 분산
두 가지 선택지를 사용하는 무작위 부하 분산 알고리즘이 새로운 기본값입니다
사용자 지정 주석

당사 웹사이트와 공식 NGINX Ingress Controller Kubernetes용 제품에 대해 자세히 알아보고, GitHub 리포지토리도 확인해 보세요.

JavaScript 모듈 개선 사항

NGINX Plus R17에는 JavaScript 언어 지원 범위를 확장하는 여러 개선 사항이 포함되어 있습니다:

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

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

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

NGINX Plus 업그레이드 또는 체험

NGINX Plus R17은 TLS 1.2보다 더 안전하고 성능이 뛰어난 TLS 1.3을 지원합니다. 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>를 참조하세요.]

작성자 소개

Liam Crilly제품 관리 부문 수석 이사

Liam Crilly의 다른 블로그 게시물

NGINX Plus R17 발표