게시된 날짜: Aug 17, 2020
Application Load Balancer(ALB) 및 Classic Load Balancer(CLB)에서 HTTP Desync로 인한 문제로부터 애플리케이션을 보호하는 새로운 기능인 HTTP Desync Mitigation Mode를 지원합니다. 지금의 웹 애플리케이션은 대개 클라이언트와 서버 간의 빠르고 안정적인 통신을 지원하는 연속적 프록시로 설계됩니다. 이런 프록시는 RFC 7230을 준수하는 HTTP/1.1 요청을 파싱하기 위한 표준 메커니즘을 따르기는 하지만 규칙을 준수하지 않는 요청을 파싱할 때 해석이 달라질 수 있습니다. 이런 해석 차이는 Desync를 일으켜서 체인 내의 서로 다른 프록시가 요청 경계에서 일치하지 않아 동일한 요청을 처리하지 못하는 문제가 생길 수 있습니다. 대기열의 다음 요청에 덧붙어서 백엔드로 몰래 침투하는 임의의 메시지를 통과시킬 수도 있습니다. 요청 스머글링은 요청 대기열 또는 캐시 포이즈닝에 애플리케이션을 취약하게 하고, 자격 증명 해킹이나 허용되지 않는 명령을 실행하는 문제를 일으킬 수 있습니다.
Desync로 마이그레이션하는 옵션은 RFC를 엄격하게 준수하는 요청만 허용됩니다. 그러나 실제 요청 대부분에는 RFC를 엄격히 준수하지 않는 문자가 포함되어 있습니다. 그 결과, 엄격하게 규칙을 준수하는 요청만 허용하는 전략을 설정하면 일부 정상적인 사용 사례도 사용하지 못할 위험이 있습니다. Desync Mitigation Mode를 사용하면 ALB/CLB가 지속성 있는 보안을 제공하면서도 애플리케이션의 가용성과 성능을 유지할 수 있습니다. 로드 밸런서는 이를 위해서 HTTP Desync Guardian이라는 AWS Open Source 라이브러리를 사용하여 위협 레벨을 기준으로 모든 요청을 분류합니다. 그런 다음, 로드 밸런서를 구성하고 애플리케이션의 보안 요구 사항에 따라 적절한 마이그레이션 전략을 선택할 수 있습니다. 이 기능을 사용하면 ALB 또는 CLB가 로드 밸런서 앞뒤의 HTTP 취약성에서 발생하는 애플리케이션에 대한 위협이 완화됩니다.
Desync Mitigation Mode를 사용하는 고객은 "Defensive", "Strictest" 및 "Monitor"의 세 가지 모드에서 선택할 수 있습니다. "Defensive" 모드에서 로드 밸런서는 세 가지 작업을 수행합니다. 첫째, RFC 7230 규칙을 준수하는지 여부와 무관하게 애플리케이션이 알려진 안전한 요청을 수신하도록 허용합니다. 둘째, RFC 규칙을 준수하지 않는 요청과 알려진 보안 위협에 해당하는 요청을 차단합니다. 셋째, 모호한 요청에 대해서는 HTTP 유지 한도와 무관하게 클라이언트 및 업스트림 연결을 모두 닫습니다. 모호한 요청이란 RFC 7230 규칙을 준수하지 않고 프록시 또는 웹 서버마다 해석이 달라져서 Desync를 초래할 수 있는 요청을 의미합니다. "Defensive" 모드는 기본값으로 선택됩니다. 애플리케이션의 가용성이 유지되면서도 HTTP Desync에 대한 지속적 자동 완화를 제공하기 때문입니다. 애플리케이션에서 RFC 7230 규칙을 준수하는 요청만 확인하게 하려면 "Strictest" 모드를 선택할 수 있습니다. 마지막으로 로드 밸런서가 분류와 관계없이 수신되는 모든 요청을 그 뒤에 있는 애플리케이션에 전달하게 하려면 "Monitor" 모드를 구성할 수도 있습니다.
이 세 가지 모드는 모두 ALB 및 CLB에 대한 CloudWatch 지표를 제공하고, 트래픽에서 애플리케이션까지 집계된 위협 수준을 정보로 표시합니다. 또한, ALB는 액세스 로그도 제공하므로 요청별로 상세히 분석해서 클라이언트에서 발생하는 애플리케이션에 대한 위협을 확인할 수 있습니다.