AWS WAF의 가장 중요한 세가지 속도 기반 규칙

이글은 AWS Security Blog에 게시된 The three most important AWS WAF rate-based rules by Artem Lovan and Jesse Lepich을 한국어로 번역 및 편집하였습니다

이 게시물에서는 일반적인 HTTP 플러드 이벤트로부터 웹 애플리케이션을 선제적으로 보호하기 위한 세 가지 가장 중요한 AWS WAF 속도 기반 규칙과 이러한 규칙을 구현하는 방법에 대해 설명합니다. 그리고 SRT(Shield Response Team)가 고객 HTTP 플러드 이벤트 대응에 도움을 주면서 배웠던 내용을 공유하고 모든 AWS WAF 고객이 이러한 학습을 통해 어떤 이점을 얻을 수 있는지 소개할 것입니다.

핵심 비즈니스 애플리케이션이 인터넷에 연결되어 있는 경우 DDoS(분산 서비스 거부) 공격과 같은 위험으로부터 애플리케이션을 보호해야 합니다. AWS Shield Advanced는 Amazon Web Services(AWS) 인터넷 연결 리소스 뒤에서 실행되는 애플리케이션을 보호하는 관리형 DDoS 보호 서비스입니다. 애플리케이션의 백엔드 원본은 온프레미스를 포함하여 어디에나 존재할 수 있으며 Shield Advanced는 이를 보호할 수 있습니다. Shield Advanced는 3–7계층에 대한 DDoS 보호 기능을 제공합니다. 또한 당신의 애플리케이션에서만 고유하게 동작할 수 있는 승인되지 않은 정교한 활동 시나리오에 대하여 빠르게 대응하도록 돕는 연중 무휴 SRT 액세스를 포함합니다. AWS WAF 연결을 지원하는 리소스 유형에 대해 자세히 알아보려면 AWS WAF를 참조하십시오.

시간이 갈수록, SRT가 비정상적으로 많은 수의 HTTP 요청으로 애플리케이션에 과부하를 발생시켜 애플리케이션 가용성 또는 성능에 부정적인 영향을 미치는 레이어 7 HTTP 플러드 발생으로부터 고객을 보호하는 사례가 증가하고 있습니다. 대부분의 경우 이러한 악성 이벤트는 AWS WAF를 사용하여 자동으로 완화할 수 있습니다. 또한 AWS WAF에는 구성하기 쉬운 기본 속도 기반 규칙 기능이 있어 5분의 시간 범위 내에 많은 수의 HTTP 요청을 만드는 소스 IP 주소를 감지하고, 요청 비율이 설정된 임계값 아래로 떨어질 때 까지 문제가 되는 소스 IP의 요청을 자동으로 차단합니다. 이 게시물에서는 AWS WAF 로그에서 통찰력을 얻어 속도 기반 규칙 임계값을 결정하는 방법을 보여줍니다.

가장 중요한 세 가지 AWS WAF 속도 기반 규칙은 다음과 같습니다.

대규모 HTTP 플러드로부터 애플리케이션을 보호하기 위한 포괄적 속도 기반 규칙
포괄적 속도 기반 규칙보다 더 제한적인 비율로 특정 URI를 보호하는 속도 기반 규칙
알려진 악성 소스 IP로부터 애플리케이션을 보호하는 속도 기반 규칙

솔루션 개요

AWS WAF는 가용성에 영향을 미치거나 보안을 손상시키거나 과도한 리소스를 소비시킬 수 있는 일반적인 웹 공격으로부터 웹 애플리케이션을 보호하는 데 도움이 되는 웹 애플리케이션 방화벽입니다. AWS WAF를 사용하면 애플리케이션에 도달하는 웹 트래픽을 제어할 수 있습니다. 당신의 애플리케이션에 대한 요청 속도를 이미 알고 있다면 AWS WAF 속도 기반 규칙 생성을 시작하는 데 필요한 모든 정보를 갖고 있는 것입니다. 규칙을 만드는 방법에 대한 자세한 내용은 규칙 생성 및 조건 추가를 참조하세요. 그러나 이와 같은 데이터가 없는 상황에서 시작하는 방법을 알고 싶은 경우, 해당 솔루션은 애플리케이션에 대한 적절한 요청 속도를 정하고, 이를 기반으로 어떻게 AWS WAF 속도 기반 규칙을 생성할 수 있는지에 대하여 도움을 줄 수 있습니다.

그림 1은 들어오는 요청 정보가 캡처되어 운영 팀이 속도 기반 규칙을 결정하는 데 해당 값을 어떻게 사용할 수 있는지 보여줍니다.

그림 1: 로그를 수집 및 쿼리하여 해당값을 기반으로 속도 기반 규칙을 적용하는 워크플로우

각 단계에서 일어나는 일을 더 잘 이해하기 위해 흐름을 살펴보겠습니다.

애플리케이션 사용자가 애플리케이션에 요청을 합니다.
AWS WAF는 수신 요청에 대한 정보를 캡처하여 Amazon Kinesis Data Firehose로 보냅니다.
Kinesis Data Firehose는 로그를 저장할 Amazon Simple Storage Service(Amazon S3) 버킷으로 전달합니다.
운영 팀은 Amazon Athena를 사용하여 SQL 쿼리로 로그를 분석합니다.
Athena는 S3 버킷의 로그를 쿼리하고 쿼리 결과를 표시합니다.
운영 팀은 쿼리 결과를 사용하여 적절한 AWS WAF 속도 기반 규칙을 결정합니다.

세 가지 속도 기반 규칙 세부 정보

각 규칙은 승인되지 않은 활동으로부터 웹 애플리케이션을 보호하는 데 도움이 됩니다. 각 규칙은 보호의 특정 측면에 중점을 둡니다. 규칙은 서로를 보완하므로 결합하여 사용되면 웹 애플리케이션을 보호하는 데 더 큰 도움을 줄 수 있습니다. 우리는 각 규칙들이 무엇을 하는지 이해하기 위해 규칙별로 조금 더 살펴보겠습니다.

포괄적 속도 기반 규칙(Blanket rate-based rule)

포괄적 속도 기반 규칙은 단일 소스 IP 주소가 웹 사이트의 가용성에 부정적인 영향을 미치지 않도록 설계되었습니다. 예를 들어 속도 기반 규칙의 임계값이 2,000으로 설정된 경우 규칙은 5분 동안 2,000개 이상의 요청을 하는 모든 IP를 차단합니다. 이것은 가장 기본적인 속도 기반 규칙이며 AWS WAF 고객이 구현하는 데 가장 중요한 규칙 중 하나입니다. SRT는 종종 DDoS 공격을 받고 있는 고객이 이 규칙을 신속하게 구현할 수 있도록 도와줍니다. 과거의 HTTP 플러드 사례 경험에서 만약 이 규칙이 사전에 적용되었다면 고객의 서비스는 자동으로 보호 받았을 것이며, 지원을 위해 SRT에 연락할 필요가 없었을 것입니다. 즉, 포괄적 속도 기반 규칙은 사람의 개입 없이 자동으로 시도를 차단했을 것입니다.

특정 URI에 대한 속도 기반 규칙(URI-specific rate-based rule)

응용 프로그램의 일부 URI 엔드포인트는 일반적으로 많은 양의 요청을 받지만 그 외에 또 다른 엔드포인트의 경우에는 높은 요청 수가 보여지는 것이 비정상적이고 의심스러울 수 있습니다. 예를 들어 5분 동안의 애플리케이션의 로그인 페이지에 대한 여러번의 요청은 의심스럽고 애플리케이션에 대한 잠재적인 무차별 암호 대입 또는 자격 증명 탈취 공격을 의미할 수 있습니다. 특정 URI에 대한 규칙은 단일 소스 IP 주소가 특정 로그인 페이지에 5분당 100번 이상으로 연결하는 것을 방지하는 동시에 애플리케이션의 나머지 엔드포인트 들에서는 훨씬 더 많은 요청 볼륨을 허용할 수 있습니다. 일부 애플리케이션에는 계산 비용이 많이 드는 URI가 있으며, 해당 URI가 호출되면 요청을 처리하는 데 훨씬 더 많은 리소스가 필요하게 됩니다. 이에 대한 예로 데이터베이스 쿼리 또는 검색 기능을 들 수 있습니다. 악의적인 행위자가 이러한 계산 비용이 많이 드는 URI를 대상으로 하는 경우 애플리케이션 성능 또는 가용성 문제가 빠르게 발생할 수 있습니다. 사이트의 이러한 영역에 특정 URI에 대한 속도 기반 규칙을 할당하면 포괄적인 속도 기반 규칙보다 훨씬 낮은 임계값을 구성할 수 있습니다. 이 블로그 게시물의 범위를 벗어나지만 일부 고객은 Application Load Balancer 액세스 로그와 target_processing_time 정보를 사용하여 사이트의 어떤 부분이 응답 속도가 가장 느린지 그리고 계산 비용이 많이 드는지 정확하게 확인합니다. 그런 다음 해당 고객은 이러한 URI 호출에 대하여 추가 속도 기반 규칙 보호를 적용합니다.

IP 평판 속도 기반 규칙(IP reputation rate-based rule)

SRT가 고객을 지원하는 많은 DDoS 이벤트에는 알려진 악성 소스 IP에서 발생하는 HTTP 플러드가 포함됩니다. AWS WAF 보안 자동화 솔루션은 AWS WAF 고객에게 4개의 오픈 소스 위협 인텔리전스 목록에 대한 구독을 제공합니다. 임계값이 낮은 속도 기반 규칙은 이러한 의심스러운 소스에서 오는 요청에 적용할 수 있습니다. 일부 고객은 이러한 IP의 웹 요청을 완전히 차단하는 것을 편안하게 느끼며, 적어도 이와 같이 잘 알려진 악성 소스로부터 애플리케이션을 보호하기 위해서는 해당 IP에서 발생하는 요청들은 요청 속도가 제한되어야 합니다.

특정 국가 내의 IP 주소에서 HTTP 플러드가 발생하는 것도 일반적입니다. AWS WAF 지리적 일치 규칙을 사용하여 특정 국가 또는 웹 애플리케이션의 주요 타겟 사용자들을 포함하지 않는 국가에서 발생하는 요청에 더 낮은 속도 기반 규칙 임계값을 할당할 수 있습니다. 예를 들어 애플리케이션이 주로 미국 사용자에게 서비스를 제공한다고 가정합니다. 이 경우 미국 이외의 국가에서 오는 요청에 대해 임계값이 낮은 속도 기반 규칙을 만드는 것이 도움이 될 수 있습니다. 또한 HTTP 플러드는 클라우드 호스팅 공급자 IP로 분류된 IP 주소에서 빈번하게 발생합니다. AWS WAF의 “HostingProviderIPList” 관리형 규칙을 사용하여 이러한 요청에 레이블을 지정한 다음 더 낮은 속도 기반 규칙 임계값을 할당할 수도 있습니다.

전제 조건

솔루션을 구현하기 전에 다음을 확인하십시오.

AWS WAF는 AWS 계정에 배포되며 Amazon CloudFront 배포 또는 Application Load Balancer와 연결됩니다.
AWS WAF 기본 동작은 차단으로 설정됩니다. 웹 ACL을 생성하고 구성할 때 AWS WAF가 웹 ACL의 규칙과 일치하지 않는 웹 요청을 처리하는 방법을 결정하는 웹 ACL 기본 동작을 설정합니다. 웹 ACL의 기본 동작에 대한 자세한 내용은 웹 ACL의 기본 동작을 참조하십시오.
AWS WAF 로깅이 구성되고 로그가 S3 버킷에 저장됩니다.
- 참고: 이 지침에 따라 S3 버킷에 대한 AWS WAF 로그 전달을 구성할 수 있으며 AWS Firewall Manager를 사용하여 다중 계정 환경에서 중앙 집중식 AWS WAF 로깅을 구성할 수도 있습니다.

AWS WAF 로그를 분석하도록 Athena 설정

Amazon Athena는 표준 SQL을 사용하여 Amazon S3의 데이터를 분석하는 데 사용할 수 있는 대화형 쿼리 서비스입니다. 이 솔루션에서는 AWS WAF 로그가 저장된 S3 버킷에 연결하고 AWS WAF 로그를 쿼리하기 위하여 Athena를 사용할 것입니다. 첫 번째 단계는 Athena 콘솔을 열고 데이터베이스를 생성하는 것입니다.

참고: Athena 데이터베이스 및 테이블 생성은 한번만 수행하면 되는 일회성 구성 프로세스입니다. 생성이 된 이후에 다시 돌아와서 쿼리를 실행하면 최신 AWS WAF 로그 데이터에 대한 쿼리 결과를 볼 수 있습니다.

Athena 데이터베이스를 생성하려면 데이터 정의 언어(DDL) 문을 사용합니다. Athena 쿼리 편집기에 다음 쿼리를 붙여넣고 여기에 설명된 대로 값을 바꿉니다.

<your-bucket-name>을 AWS WAF 로그가 있는 S3 버킷 이름으로 바꿉니다.
<bucket-prefix-if-exist>의 경우 AWS WAF 로그가 S3 버킷 접두사에 저장되어 있으면 접두사 이름으로 바꿉니다. 그렇지 않으면 끝에 있는 슬래시 “/”를 포함하여 쿼리에서 이 부분을 제거합니다.

CREATE DATABASE IF NOT EXISTS wafrulesdb
COMMENT 'AWS WAF logs'
LOCATION 's3://<your-bucket-name>/<bucket-prefix-if-exist>/';

실행을 선택하여 쿼리를 실행하고 데이터베이스를 생성합니다. 성공적으로 완료되면 아래와 같은 쿼리 결과로 표시됩니다.

Results
Query successful.

다음으로 데이터베이스 내에 테이블을 만듭니다. Athena 쿼리 편집기에 다음 쿼리를 붙여넣고 여기에 설명된 대로 값을 바꿉니다.

<your-bucket-name>을 AWS WAF 로그가 있는 S3 버킷 이름으로 바꿉니다.
<bucket-prefix-if-exist>의 경우 AWS WAF 로그가 S3 버킷 접두사에 저장되어 있으면 접두사 이름으로 바꿉니다. 그렇지 않으면 끝에 있는 슬래시 “/”를 포함하여 쿼리에서 이 부분을 제거할 수 있습니다.

has_encrypted_data의 경우 AWS WAF 로그 데이터가 유휴 상태에서 암호화된 경우 값을 true로 변경하고, 그렇지 않으면 false가 올바른 값입니다

CREATE EXTERNAL TABLE IF NOT EXISTS wafrulesdb.waftable (
  terminatingRuleId string,
  httpSourceName string,
  action string,
  httpSourceId string,
  terminatingRuleType string,
  webaclId string,
  timestamp float,
  formatVersion int,
  ruleGroupList array<string>,
  httpRequest struct<headers:array<struct<name:string,value:string>>,clientIp:string,args:string,requestId:string,httpVersion:string,httpMethod:string,country:string,uri:string>,
  rateBasedRuleList string,
  nonTerminatingMatchingRules string,
  terminatingRuleMatchDetails string 
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = '1'
) LOCATION 's3://<your-bucket-name>/<bucket-prefix-if-exist>/'
TBLPROPERTIES ('has_encrypted_data'='false');

Athena 콘솔에서 쿼리를 실행합니다. 쿼리가 완료되면 Athena는 waftable 테이블을 등록하여 해당 테이블의 데이터를 쿼리에 사용할 수 있도록 합니다.

SQL 쿼리를 실행하여 속도 기반 규칙 임계값 식별

이제 Athena에 테이블이 있고 데이터가 있는 위치를 알고 올바른 스키마가 있으므로 각 속도 기반 규칙에 대해 SQL 쿼리를 실행하고 쿼리 결과를 볼 수 있습니다.

모든 애플리케이션 엔드포인트에 대한 포괄적 속도 기반 규칙

포괄적 규칙을 식별하는 SQL 쿼리로 시작하겠습니다. 포괄적 규칙을 결정하는 데 중요한 요소는 유효한 요청에서 발생하는 높은 볼륨을 나타내는 AWS WAF 로그 데이터에 대해 쿼리를 실행하는 것입니다. 다음 쿼리는 2020-12-01 16:00:00 에서 2020-12-01 22:00:00까지로 표현되는 저녁 6시간의 시간대를 정의합니다. 기간은 몇 시간 또는 며칠이 될 수 있습니다. 그러나 이 기간은 임계값을 식별하기 위한 기준으로 사용할 트래픽 양을 잘 나타내야 합니다. 예를 들어 특정 기간 동안 애플리케이션이 더 많이 사용되는 경우 해당 시간에 대한 로그 데이터를 평가해야 합니다. 여기에 표시된 예에서는 쿼리 결과를 SQL 쿼리의 상위 100개 IP로 제한합니다. LIMIT 값을 업데이트하여 필요에 따라 제한을 조정할 수 있습니다.

SELECT
  httprequest.clientip,
  COUNT() AS "count"
FROM wafrulesdb.waftable
WHERE from_unixtime(timestamp/1000) BETWEEN TIMESTAMP '2020-12-01 16:00:00' AND TIMESTAMP '2020-12-01 22:00:00'
GROUP BY httprequest.clientip, FLOOR("timestamp"/(100060*5))
ORDER BY count DESC
LIMIT 100;

필요에 따라 기간을 업데이트하고 Athena 콘솔에서 쿼리를 실행합니다. 결과에는 그림 2와 같이 두 날짜 사이에서 5분 마다 가장 많은 요청을 한 IP가 표시됩니다.

그림 2: 두 날짜 사이에서 5분 마다 가장 많은 요청을 한 IP

결과 데이터를 시각화하여 IP당 요청 수를 전체적으로 볼 수 있습니다. 그림 3의 차트는 SQL 쿼리 결과를 보여줍니다.

그림 3: 차트: 두 날짜 사이에서 5분 마다 가장 많은 요청을 한 IP

결과는 5분마다 요청량이 가장 많은 IP를 표시하여 정렬됩니다. 이는 대부분의 요청이 해당 5분 간격 내에 이루어진 경우 동일한 IP가 여러 번 나타날 수 있음을 의미합니다. 이 예에서 결과를 보면 우수한 첫 번째 포괄적 규칙이 요청 볼륨을 5분 단위 기간 동안 약 7,000개의 요청으로 제한합니다. 다음 JSON 및 JSON 규칙 편집기를 사용하거나 AWS WAF 시각적 규칙 편집기를 사용하고 다음 지침에 따라 AWS WAF 규칙을 생성할 수 있습니다. 다음 JSON을 사용하는 경우 제한 값을 이전에 SQL 쿼리를 실행하여 식별한 값으로 바꾸십시오.

{
  "Name": "BlanketRule",
  "Priority": 2,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BlanketRule"
  },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 7000,
      "AggregateKeyType": "IP"
    }
  }
}

때때로 클라이언트는 클라이언트 소스 IP를 가리는 HTTP 프록시 또는 콘텐츠 전송 네트워크(CDN)를 통해 애플리케이션에 연결합니다. 소스 IP를 차단하면 원치 않는 영향이 더 커질 수 있으므로 프록시 또는 CDN의 IP 대신 클라이언트 IP를 식별하는 것이 중요합니다. 소스 IP가 CDN인지 여부를 식별하는 데 도움이 되는 많은 도구를 사용할 수 있습니다. 이 경우 X-Forwarded-For, True-Client-IP 또는 기타 사용자 지정 헤더를 쿼리하고 필터링해야 합니다. CDN 공급자는 일반적으로 요청에 추가하는 헤더를 게시하지만 X-Forwarded-For 및 True-Client-IP가 일반적으로 사용합니다. 다음 쿼리는 속도 기반 규칙을 작성하기 위해 X-Forwarded-For 헤더를 사용하여 이러한 헤더를 참조하는 방법을 보여줍니다. X-Forwarded-For를 클라이언트 IP를 보유할 것으로 예상되는 헤더로 바꿀 수 있습니다.

SELECT
  header.value,
  COUNT(*) AS "count"
FROM wafrulesdb.waftable, UNNEST(httprequest.headers) as t(header)
WHERE
    from_unixtime(timestamp/1000) BETWEEN TIMESTAMP '2020-12-01 16:00:00' AND TIMESTAMP '2020-12-01 22:00:00'
  AND
    header.name = 'X-Forwarded-For'
GROUP BY header.value, FLOOR("timestamp"/(1000*60*5))
ORDER BY count DESC
LIMIT 100;

특정 애플리케이션 엔드포인트에 대한 URI 기반 규칙

웹 사이트의 로그인 페이지에 대한 요청을 추가로 제한하고 싶다고 가정합니다. 이렇게 하려면 속도 기반 규칙에 다음 문자열 일치 조건을 추가할 수 있습니다.

필터링할 요청 부분은 URI입니다.
Match Type은 Starts with입니다.
일치시킬 값은 /login입니다(웹 요청의 URI 부분에서 로그인 페이지를 식별하는 값이어야 함).

다음으로 애플리케이션의 /login URI에 대한 일반적인 요청 볼륨이 무엇인지 식별해야 합니다. 다음 SQL 쿼리는 정확히 이를 수행합니다.

SELECT
  httprequest.clientip,
  httprequest.uri,
  COUNT(*) AS "count"
FROM wafrulesdb.waftable
WHERE 
  from_unixtime(timestamp/1000) BETWEEN TIMESTAMP '2020-12-01 16:00:00' AND TIMESTAMP '2020-12-01 22:00:00'
AND
  httprequest.uri = '/login'
GROUP BY httprequest.clientip, httprequest.uri, FLOOR("timestamp"/(1000*60*5))
ORDER BY count DESC
LIMIT 100;

만약 가능하다면, 기간값인 2020-12-01 16:00:00 및 2020-12-01 22:00:00과 httprequest.uri 값을 교체하고 Athena 콘솔에서 쿼리를 실행합니다. 결과는 그림 4와 같이 두 날짜 사이의 5분마다 가장 많은 요청을 한 IP 및 /login URI를 보여줍니다.

그림 4: 두 날짜 사이에서 5분 마다 가장 많은 요청을 한 IP 및 /login URI

그림 5는 두 날짜 사이에서 5분 마다 가장 많은 요청을 한 IP 및 /login URI에 대한 쿼리 결과 차트를 보여줍니다.

그림 5: 차트: 두 날짜 사이에서 5분 마다 가장 많은 요청을 한 IP 및 /login URI

SQL 쿼리 결과에 따라 5분당 요청 속도 제한을 150으로 지정합니다. 이 속도 기반 규칙을 웹 ACL에 추가하면 사이트의 나머지 부분에 영향을 주지 않고 로그인 페이지에 한정하여 IP 주소당 요청이 제한됩니다. 다시 한번 다음 JSON 및 JSON 규칙 편집기를 사용하거나 AWS WAF 시각적 규칙 편집기를 사용하고 다음 지침에 따라 AWS WAF 규칙을 생성할 수 있습니다. 다음 JSON을 사용하는 경우 Limit 값을 이전에 SQL 쿼리를 실행하여 식별한 값으로 바꾸십시오.

{
  "Name": "UriBasedRule",
  "Priority": 1,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "UriBasedRule"
  },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 150,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "FieldToMatch": {
            "UriPath": {}
          },
          "PositionalConstraint": "STARTS_WITH",
          "SearchString": "/login",
          "TextTransformations": [
            {
              "Type": "NONE",
              "Priority": 0
            }
          ]
        }
      }
    }
  }
}

우선 순위 값이 낮은 AWS WAF 규칙은 값이 높은 규칙보다 먼저 평가됩니다. AWS WAF 규칙이 예상대로 작동하려면(먼저 더 구체적인 규칙인 URI 기반 규칙을 평가하고 그 후에 더 일반적인 포괄적 규칙을 평가) AWS WAF 규칙 우선 순위를 설정해야 합니다. JSON을 업데이트하고 우선순위 값을 포괄적 규칙의 경우 1로, URI 기반 규칙의 경우 0으로 설정하거나 AWS WAF 시각적 규칙 편집기를 사용하여 이를 수행할 수 있습니다. 예상되는 AWS WAF 규칙 우선순위는 그림 6과 같아야 합니다.

그림 6: UriBasedRule에 대한 우선 순위가 더 높은 AWS WAF 규칙

모든 애플리케이션 URI에서 요청 볼륨을 알고 싶다면 다음 SQL을 수행합니다.

SELECT
  httprequest.clientip,
  httprequest.uri,
  COUNT() AS "count"
FROM wafrulesdb.waftable
WHERE from_unixtime(timestamp/1000) BETWEEN TIMESTAMP '2020-12-01 16:00:00' AND TIMESTAMP '2020-12-01 22:00:00'
GROUP BY httprequest.clientip, httprequest.uri, FLOOR("timestamp"/(100060*5))
ORDER BY count DESC
LIMIT 100;

그림 7은 SQL 쿼리 결과가 어떻게 보이는지에 대한 차트를 보여줍니다.

그림 7: 두 날짜 사이에서 5분마다 가장 많은 요청을 한 IP 및 URI

봇 또는 기타 위협을 차단하는 IP 평판 규칙 그룹

IP 평판 규칙을 사용하여 소스 IP를 기반으로 요청을 차단할 수 있습니다. AWS WAF는 다양한 관리형 규칙 그룹을 제공하며 Amazon IP 평판 목록은 봇 트래픽 또는 악용 시도에 대한 노출을 줄이는 데 도움이 되는 목록입니다.

웹 ACL에 Amazon IP 평판 목록 규칙을 추가하려면

AWS WAF 콘솔을 열고 관리형 규칙 그룹 보기로 이동합니다.

그림 8: AWS WAF의 관리형 규칙 그룹 화면
AWS 관리형 규칙 그룹을 확장하고 Amazon IP 평판 목록에서 웹 ACL에 추가를 선택합니다.

그림 9: 웹 ACL에 Amazon IP 평판 목록 추가
페이지 하단으로 스크롤하고 Add rule을 선택합니다.
이 시점에서 규칙 우선순위 설정 화면이 표시됩니다. 우선 순위가 가장 높도록 Amazon 관리형 규칙을 위로 이동합니다. 요청이 봇에서 시작된 경우 가능한 한 빨리 요청을 거부하기를 원하며, Amazon IP 평판 목록 규칙에 가장 높은 우선 순위를 할당하여 정확히 이를 달성합니다. 최종 AWS WAF 규칙 순서는 그림 10과 같아야 합니다.

그림 10: 우선순위에 따라 정렬된 최종 AWS WAF 규칙

속도 기반 규칙에 대한 고려 사항

보다 구체적인 AWS WAF 규칙으로 가장 먼저 요청 볼륨을 제한하는 것을 원하기 때문에, 구체적인 규칙의 우선 순위가 더 높아야 한다는 점을 유의해야 합니다. 이 예에서 규칙 전략은 먼저 특정 URI를 기반으로 한 다음 포괄적인 규칙을 기반으로 전체 애플리케이션에서 요청을 제한합니다.

여기서 논의한 속도 기반 규칙은 일반적인 기본 HTTP 요청 플러드로부터 인터넷 연결 애플리케이션을 보호하는 데 도움이 되는 견고한 기반을 제공합니다. 그러나 이 블로그 게시물의 솔루션은 일회성 설정이 아니라 반복적인 활동으로 보아야 합니다.

Amazon Athena 쿼리를 다시 실행하여 애플리케이션의 성장 및 증가하는 요청 볼륨에 맞는 새로운 속도 기반 규칙을 식별하기 위한 유효한 시간 프레임을 결정해야 합니다. 속도 기반 규칙을 반복적으로 검토하고 이를 소프트웨어 개발 수명 주기와 같은 기존 프로세스에 통합하는 것은 검토 프로세스에서 일정을 계획하는 좋은 방법입니다. 각 AWS WAF 규칙은 임계값을 넘어서기 전에 알람을 트리거하는 데 사용할 수 있는 Amazon CloudWatch 지표를 게시할 수 있습니다. 알람을 사용하여 설정한 임계값에 따라 운영 팀 측의 티켓을 만들 수 있습니다. 이를 통해 운영 팀은 상황을 검토하여 DDoS 공격이 저지되고 있는지, 아니면 적법한 트래픽이 삭제되고 있는지 여부를 확인할 수 있습니다.

요청 볼륨을 확인한 후에는 애픞리케이션 성장을 대비하여 버퍼를 추가하십시오. 속도 기반 규칙에는 가까운 미래의 애플리케이션 성장을 대비할 수 있는 합리적인 버퍼가 있어야 합니다. 예를 들어 Athena 쿼리 결과에 500개 요청의 요청 볼륨이 표시되면 1,000개 요청으로 제한되는 속도 기반 규칙을 설정하여 애플리케이션 성장을 대비한 500개의 추가 요청 버퍼를 구성할 수 있습니다.

요약

이 게시물에서는 일반적인 HTTP 플러드 이벤트로부터 웹 애플리케이션을 보호하기 위해 가장 중요한 세 가지 AWS WAF 속도 기반 규칙을 소개했습니다. 또한 어떻게 이와 같은 속도 기반 규칙을 구현하는지, 그리고 AWS WAF 로그 및 Amazon Athena 쿼리를 사용하여 애플리케이션에 대한 적절한 요청 임계값을 어떻게 결정하는지에 대하여 다루었습니다. AWS WAF를 사용하여 다양한 공격 벡터로부터 웹 사이트와 웹 애플리케이션을 보호하는 데 도움이 되는 모범 사례에 대해 자세히 알아보려면 AWS WAF 구현 지침 백서를 참조하십시오.

다른 AWS WAF 관련 보안 블로그 게시물에서 AWS WAF에 대해 자세히 알아볼 수 있습니다.

이 게시물에 대한 피드백이 있는 경우 아래 Comments 섹션에 댓글을 남겨주세요. 이 게시물에 대해 질문이 있는 경우 AWS WAF 포럼에서 새 스레드를 시작하거나 AWS Support에 문의하십시오.

더 많은 AWS 보안 방법 콘텐츠, 뉴스 및 기능 발표를 원하십니까? Twitter에서 팔로우하세요.

AWS 기술 블로그