Category: AWS Web Application Firewall


[기술 백서] AWS WAF를 통해 OWASP 상위 10 웹 애플리케이션 취약점 방어하기

Open Web Application Security Project (OWASP)의 웹 애플리케이션 보안 향상 프로젝트를 알고 계시나요? 그 중에서도 OWASP Top 10이라는 가장 중요한 10 가지 애플리케이션 보안 결함 목록이 있습니다. 이 목록은 최근 웹 사이트 및 웹 애플리케이션에서 자주 발견되는 일반적인 취약점에 대한 내용을 포함합니다.

AWS WAF는  이전 블로그 글에서 설명 드린 대로  SQL 인젝션 및 크로스 사이트 스크립팅과 같은 애플리케이션 계층 공격으로부터  사용자 지정 규칙을 만들어 허용 및 거부 트래픽 유형을 정의함으로서 보안을 강화할 수 있습니다.

신규 기술 백서 Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities 에서는 OWASP의 상위 열 가지 취약점을 완화하기 위한  AWS WAF 사용 방법을 설명합니다. 즉, OWASP Top 10 (공식적으로 A1에서 A10으로 알려짐)에서 가장 중요한 항목에 대한 세부적이고 구체적인 완화 전략 및 구현 세부 정보가 포함됩니다.

지금 다운로드 하세요!
한국어 기술 백서(영문)는 각 취약점에 대한 배경 및 배경을 제공하고 WAF 규칙을 작성하고 차단하는 방법을 보여줍니다. 또한 HTTP 요청에 제공된 매개 변수를 미리 검증하기 위해 Lambda @ Edge를 사용하는 아주 멋진 제안을 포함하여 심층 방어 권고를 제공합니다.

이 백서에서는 권장 조건 유형 및 규칙과 함께 웹 ACL을 만드는 동반자 AWS CloudFormation 템플릿에 연결됩니다. 이 템플릿을 자신의 작업을위한 시작점으로 사용하여 더 많은 조건 유형과 규칙을 원하는대로 추가 할 수 있습니다.

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS WAF Basic OWASP Example Rule Set

## ::PARAMETERS::
## Template parameters to be configured by user
Parameters:
  stackPrefix:
    Type: String
    Description: The prefix to use when naming resources in this stack. Normally we would use the stack name, but since this template can be us\
ed as a resource in other stacks we want to keep the naming consistent. No symbols allowed.
    ConstraintDescription: Alphanumeric characters only, maximum 10 characters
    AllowedPattern: ^[a-zA-z0-9]+$
    MaxLength: 10
    Default: generic
  stackScope:
    Type: String
    Description: You can deploy this stack at a regional level, for regional WAF targets like Application Load Balancers, or for global targets\
, such as Amazon CloudFront distributions.
    AllowedValues:
      - Global
      - Regional
    Default: Regional
...

Jeff;

이 글은 Prepare for the OWASP Top 10 Web Application Vulnerabilities Using AWS WAF and Our New White Paper 의 한국어 번역입니다.

AWS WAF 신규 요청 비율 규칙을 통한 웹 사이트 보호하기

AWS WAF (웹 응용 프로그램 방화벽)는 악의적이거나 조작된 요청을 포함하는 다양한 계층 공격으로부터 응용 프로그램을 보호합니다. 이 서비스는 다양한 공격 기법 즉, 교차 사이트(Cross-site) 스크립팅, IP 주소 및 SQL 조작, 콘텐트 제약 조건에 맞는 규칙을 정의 할 수 있습니다.

외부에서 들어오는 요청이 규칙과 일치하면 동작할 기능이 호출됩니다. 각 동작은 일치를 허용, 차단으로 처리할 수 있습니다.

기존 규칙 모델은 강력하고 다양한 유형의 공격을 탐지하고 대응할 수 있는 기능을 제공합니다. 그러나, 특정 IP 주소에서 유효한 요청으로 구성되는 공격에 대응할 수는 없습니다. 이러한 요청은 웹 레이어 DDoS 공격, 무차별 강제 로그인 시도 또는 파트너 통합에서 생기는 문제일 수 있습니다.

신규 요청 비율(Rate) 기반 규칙 기능 출시
오늘 WAF에 요금제 규칙을 추가하여 블랙 리스트에 IP 주소가 추가되거나 제거 되는 시기의 예외 및 특별한 경우를 처리 할 수 있는 유연성을 제공합니다.

  • IP 주소 블랙 리스트 – 구성된 임계 값 비율을 초과하는 요청으로 IP 주소를 블랙 리스트에 올릴 수 있습니다.
  • IP 주소 추적 – 현재 블랙 리스트에 올라있는 IP 주소를 볼 수 있습니다.
  • IP 주소 제거 – 블랙 리스트에 올라온 IP 주소는 더 이상 구성된 임계 값 이상으로 요청을 하지 않으면 자동으로 제거됩니다.
  • IP 주소 제외 – 요금 기반 규칙의 IP 주소 화이트 리스트를 사용하여 블랙 리스트에서 특정 IP 주소를 제외 할 수 있습니다. 예를 들어 신뢰할 수 있는 파트너가 더 빠른 속도로 사이트에 액세스하도록 허용 할 수 있습니다.
  • 모니터링 및 경고 – 각 규칙에 대해 게시 된 CloudWatch 통계를 보고 알림을 보낼 수 있습니다.

새로운 속도 기반 규칙을 WAF 조건과 결합하여 정교한 속도 제한 전략을 구현할 수 있습니다. 예를 들어, 속도 기반 규칙과 로그인 페이지와 일치하는 WAF 조건을 사용할 수 있습니다. 이렇게 하면 로그인 페이지에 적당한 임계 값을 부과 할 수 있으며 (무차별 대입 암호 공격을 피하기 위해) 마케팅 또는 시스템 상태 페이지에서 더 유연하게 허용 할 수 있습니다.

임계 값은 5 분 내에 단일 IP 주소에서 들어오는 요청 수로 정의됩니다. 이 임계 값을 초과하면 요청 속도가 임계 값 아래로 떨어질 때까지 IP 주소의 추가 요청이 차단됩니다.

요청 비율 기반 규칙 기능 사용해 보기
다음은 사이트의 /login 부분을 보호하는 요금 기반 규칙을 정의하는 방법입니다. 페이지의 URI에서 원하는 문자열과 일치하는 WAF 조건을 정의하여 시작하십시오.

그런 다음이 조건을 사용하여 요청 비율 기반 규칙을 정의하십시오 (요청 비율 제한은 5 분 간격으로 요청 관점으로 표시되지만 제한을 위반하는 즉시 블랙 리스트가 적용됨).

조건과 규칙을 적용한 후 Web ACL (ProtectLoginACL)을 작성하여 모두 가져오고 AWS 리소스 (이 경우 CloudFront 배포본)에 첨부합니다.

그런 다음 규칙 (ProtectLogin)을 웹 ACL에 첨부하십시오.

이제 규칙과 Web ACL에 따라 리소스가 보호됩니다. 연관된 CloudWatch 통계치(이 경우 ProtectLoginProtectLoginACL)를 모니터 할 수 있습니다. CloudWatch 알람을 생성하고 보호 임계 값이 위반되었을 때 람다 함수를 호출하는 데 사용할 수도 있습니다. 문제가 되는 IP 주소를 조사하고, 비즈니스 로직에 따른 결정을 내릴 수 있습니다. 신뢰할 수 있는 파트너 또는 고객에게 추가 할당이 가능한 화이트리스트 규칙을 추가 할 수 있습니다.

정식 출시
오늘 부터 새로운 요청 비율 기반 규칙을 지금 사용할 수 있으며, 일반 규칙과 동일하게 가격이 책정됩니다. 자세한 내용은 WAF 요금 페이지를 참조하십시오.

Jeff;

이 글은 Protect Web Sites & Services Using Rate-Based Rules for AWS WAF의 한국어 번역입니다.

AWS Web Application Firewall을 통한 Application Load Balancer 보호하기

오늘은 작년에 출시한 주요 서비스 중 AWS Web Application Firewall(WAF) 및 AWS Application Load Balancer라는 두 가지 서비스에 대한 업데이트입니다.

AWS Web Application Firewall – 애플리케이션 가용성에 영향을 미치거나 과도한 자원을 소비 할 수 있는 외부 공격을 보호하는 서비스로서, 이전 출시 소식 에서 볼 수 있듯이 HTTP  요청 허용 여부 및 IP 주소를 정의하는 접근 제어 목록 (ACL), 규칙 및 조건을 사용할 수 있습니다. 선택적으로 웹 응용 프로그램의 특정 경로에 대한 접근를 허용하거나 거부 할 수 있으며, 다양한 SQL 주입 공격을 차단할 수 있습니다. 본 서비스는 Amazon CloudFront를 지원합니다.

AWS Application Load Balancer – Elastic Load Balancing에서 상위 애플리케이션 계층을 지원하는 신규 서비스로서 콘테이너 또는 EC2 인스턴스 웹 서비스 경로를 기반으로 하는 라우팅 규칙을 정의 할 수 있습니다. Application Load Balancer는 HTTP/2 및 WebSocket을 지원하며 대상 콘테이너 및 인스턴스 상태를 자세히 볼 수 있습니다. 자세한 내용은 이전 출시 소식를 참조하십시오.

WAF 및 ALB 상호 연동 하기
작년 연말 AWS WAF를 통해 Application Load Balancer 기반 응용 프로그램 보호 기능을 제공할 것이라고 발표하였으며, 오늘부터 이를 매우 빠르게 설정할 수 있으며 내부 및 외부 응용 프로그램과 웹 서비스를 모두 보호 할 수 있습니다.

예를 들어, 아래 ALB 뒤에 세 개의 EC2 인스턴스가 있습니다.

같은 리전에 접근 목록(ACL)을 간단하게 만들고 ALB와 연결합니다. 먼저 ACL의 이름을 지정하고, WAF에 지정된 CloudWatch 측정 항목에 제공하도록 설정합니다.

그런 다음 ACL에 원하는 조건을 추가합니다.

예를 들어, 질의 문자열에 대해 몇 가지 SQL 주입 필터(Injection Match)를 쉽게 설정할 수 있습니다.

필터를 만든 후에 이를 규칙 만드는 데 사용합니다.

그런 다음 규칙을 사용하여, 조건과 일치하는 요청을 차단합니다.

이를 모두 함께 사용하려면, 아래처럼 설정을 검토한 다음 ACL을 만드십시오.

Confirm and create을 클릭하면 새 규칙이 활성화되고, WAF가 내 ALB 뒤에 있는 응용 프로그램을 보호합니다.

이렇게 하면 WAF를 통해 Application Load Balancer 뒤의 EC2 인스턴스와 콘테이너를 보호할 수 있습니다.

자세히 알아보기
WAF 및 ALB를 함께 사용하는 데 대한 부분을 더 자세히 알고 싶으시면, re:Invent 중 Secure Your Web Application With AWS WAF and Amazon CloudFront 세션을 참고하시기 바랍니다.

Jeff;

이 글은 AWS Web Application Firewall (WAF) for Application Load Balancers의 한국어 번역입니다.

IPv6 지원 업데이트 – CloudFront, WAF 및 S3 Transfer Acceleration

최근 Amazon S3 IPv6 지원 발표 이후, 이번에는 Amazon CloudFront, Amazon S3 Transfer AccelerationAWS WAF와 60개가 넘는 모든 CloudFront 엣지 로케이션에서도 IPv6 지원이 이용 가능합니다. AWS는 모든 자율 시스템 네트워크(ASN)에서 IPv6를 활성화하기 위한 단계적 마이그레이션 프로세스를 오늘부터 시작하고, 앞으로 몇 주에 걸쳐 모든 네트워크에서 확장 할 예정입니다.

CloudFront IPv6 지원
이제 각 Amazon CloudFront 배포 버전마다 IPv6 지원을 활성화 할 수 있습니다. IPv6을 사용하여, CloudFront 엣지 로케이션에 연결하는 방문자와 네트워크는 자동으로 IPv6 콘텐츠를 가져옵니다. IPv4를 사용하여 연결하는 경우, 예전처럼 작동합니다. 오리진(Origin) 서버 연결은 IPv4를 사용합니다.

새로 만든 배포 게시 지점은 자동으로 IPv6을 사용합니다. 기존 게시 지점을 변경하려면, Enable IPv6를 선택합니다. 이것은 콘솔 또는 CloudFront API에서 설정할 수 있습니다.

새로운 기능의 중요 사항은 아래를 참조하십시오.

  • 별칭 레코드(Alias Records) – 게시 지점에서 IPv6 지원을 활성화하면, DNS 항목은 AAAA 레코드를 포함해서 업데이트 합니다. Amazon Route 53과 별칭 레코드를 사용하여, 배포 도메인 전체 또는 일부를 가르키고 있는 경우, 그 도메인에 AAAA 별칭을 추가 해야합니다.
  • 로그 파일(Log Files) – CloudFront 접속 로그를 사용하는 경우, IPv6 주소가 c-ip 필드에 표시되므로, 로그 처리 시스템이 이를 처리할 수 있도록 해야 합니다.
  • 신뢰할 수 있는 서명(Trusted Signers) – 신뢰할 수 있는 서명 및 IP 주소 화이트 리스트를 함께 사용하는 경우, IP 허용 목록과 실제 내용 IPv4/IPv6 배포를 갖추는 신뢰된 서명과 각 URL의 IPv4 제한 배포 지점을 사용할 것을 적극 권장합니다. 이 모델에서는 IPv4 주소를 사용하여 전송 한 서명 요청에 서명한 것으로, 콘텐츠 요청이 화이트리스트에 실려 있지 않은 다른 IPv6 주소에서 주어진 같은 문제를 해결 할 수 있습니다.
  • CloudFormation – CloudFormation 지원을 준비 중 이번 출시에서는 CloudFormation 템플릿에서 만든 배포판에서 IPv6를 사용할 수 없습니다. 기존 스택을 업데이트 할 때, 스택에서 참조 배포판 설정 변경은 없습니다.
  • AWS WAF – AWS WAF와 CloudFront를 함께 사용하는 경우 IPv6 주소의 화이트리스트 또는 블랙리스트에 연결 되도록, WebACL과 IP 규칙 세트를 업데이트 해야합니다.
  • Forwarded 헤더 (Forwarded Headers) – 배포 지점에서 IPv6를 사용하는 경우, X-Forwarded-For 헤더에 IPv6 주소가 포함합니다. 오리진(Origin)이 형식 헤더를 처리 할 수 ​​있는지 확인하십시오.

자세한 내용은 IPv6 Support for Amazon CloudFront를 참고하십시오.

AWS WAF IPv6 지원
AWS WAF는 애플리케이션 레이어에서 발생하는 공격으로부터 응용 프로그램을 보호합니다. (자세한 사항은 AWS WAF 신규 서비스를 참고하십시오.)

AWS WAF가 IPv4 또는 IPv6 주소를 통해 요청을 검사 할 수 있습니다. IPv6와 일치하는 웹 접근 목록(ACL)을 만들 수 있습니다. 자세한 내용은 Working with IP Match Conditions를 참조하십시오.

기존 WAF 기능은 모든 IPv6 지원 성능에 보이는 변화는 없습니다. IPv6는 WAF가 수집 되어 표시한 샘플 요청으로 표시됩니다.

S3 Transfer Acceleration IPv6 지원
Amazon S3 전송 가속 기능이 IPv6를 지원하게 되었습니다. (자세한 내용은 AWS 스토리지 업데이트 – Amazon S3 Transfer Acceleration 참조). 업로드에 사용할 수 있는 이중 스택 엔드 포인트에 쉽게 전환 할 수 있습니다. 다음과 같이 변경 하면됩니다.

https://BUCKET.s3-accelerate.amazonaws.com

에서

https://BUCKET.s3-accelerate.dualstack.amazonaws.com

클라이언트 객체 생성 및 듀얼 스택 전송의 활성화를 가능하게 하는 AWS SDK for Java 사용 코드는 다음과 같습니다.

Java
AmazonS3Client s3 = new AmazonS3Client();
s3.setS3ClientOptions(S3ClientOptions.builder().enableDualstack().setAccelerateModeEnabled(true).build());

대부분 응용 프로그램과 네트워크 스택은 자동으로 IPv6 사용을 선호하는 경향이 있기 때문에 더 이상의 설정은 필요하지 않습니다. IPv6 주소와 함께 사용하기에 기능 동작에 문제가 없는지 확인하기 위해 패킷 IAM 정책을 검토하는 것이 좋습니다. 자세한 내용은 IPv6를 사용하여 Amazon S3에 요청 전송을 참조하십시오.

테스트를 잊지 마세요!
AWS 리전에 IPv6 연결에 제한이 있거나 존재하지 않는 경우, 대신 IPv4를 사용합니다. 이전에 블로그에서도 언급했지만, IPv6를 지원하도록 클라이언트 시스템을 구성 할 수 있습니다. 그러나, 이 경우 IPv6 패킷을 인터넷에 라우팅 설정하지 않은 네트워크에 연결해야 합니다. 이러한 이유에서 IPv6로 전환하기 전에 응용 프로그램 수준에서 네트워크 수행 지점 간 연결 테스트를 수행하는 것이 좋습니다.

Jeff;

이 글은 IPv6 Support Update – CloudFront, WAF, and S3 Transfer Acceleration의 한국어 버전입니다.

AWS Lambda와 WAF를 이용한 Rate-Based Blacklisting 기능 구현

여러분들 대다수는 원하지 않는 요청이나, crawl-delay directive의 기준을 무시하는 봇이나 크롤러 같은 스캐닝 도구로 인해 웹서버의 가용성에 문제가 발생하는 경우를 고민해 보셨을 것입니다. 흔히 HTTP flood 라고 불리는 분산 서비스 거부 공격(DDoS)의 목적은 시스템에 부담을 일으켜서 정상 사용자의 사용을 방해하기 위한(아래 그림 처럼) 것입니다.

이 글에서는 원하지 않는 트래픽을 요청량 기준으로 자동으로 탐지하고 AWS WAF (현재 WAF의 기능은 Amazon CloudFront 의 컨텐츠 배송 서비스 상에서 동작합니다)의 구성을 업데이트하여 악의의 사용자로부터의 요청을 차단하는 방법을 소개합니다.

이와 같은 기능을 AWS Lambda를 사용하여 CloudFront의 엑세스 로그에서 악성 요청을 식별하도록 구현하게 됩니다. 이 기능은 Amazon CloudWatch 상의 메트릭들을 활용하여 얼마나 많은 요청들이 처리되었고, 블락된 오리진의 수가 얼마인지를 모니터합니다. 또한 AWS WAF서비스는 수작업으로 잘 알려진 봇 네트웍 같이 금지하고 싶은 IP 대역을 추가할 수도 있습니다.

위 그림은 모든 요청을 처리하다가 웹서버의 모든 리소스를 소진하는 모양을 나타냅니다. 아래 그림은 본 포스팅에서 제시된 방법을 통해 블랙리스트 처리된 소스로부터의 요청을 차단하는 과정을 도식화 한 것입니다.

솔루션 개요

여러분의 리소스에 대한 부담을 방지하기 위한 방식은 요청률 기반 블랙리스팅(rate-based blacklisting)을 구현하는 것입니다. 이를 통해 웹 어플리케이션 환경이 얼마나 많은 요청들을 처리할 수 있는지에 대한 임계치를 세울 수 있습니다. 만약, 봇, 크롤러 혹은 임계치를 상회하는 공격이 들어온다면 AWS WAF를 통해 자동으로 차단될 것입니다.

위의 그림에서 회색 박스에 포함된 영역이 이 기능을 수행하는 AWS서비스들입니다. 시나리오를 위해 CloudFront와 Amazon S3, Amazon EC2, Amazon RDS를 사용하여 웹사이트의 정적, 동적 컨텐츠를 제공하도록 구성합니다. CloudFront가 웹 어플리케이션에 대한 요청을 받을 때마다, AWS WAF는 모든 요청들을 검사하고, 해당 요청을 허용할 지, 차단할지를 소스 IP기준으로 CloudFront에 설정합니다. 아래 그림은 전체적인 아키텍쳐와 동작 순서를 보여줍니다.

  1. CloudFront 가 웹어플리케이션 앞 단에서 요청들을 받고, 요청에 대한 구체적인 정보를 담아서 S3버킷으로 access logs를 보낸다.
  2. S3버킷에 신규 엑세스 로그들이 저장될 때 마다, 람다 펑션이 기동된다.
  3. 람다 펑션은 어떤 IP로부터 기준치 이상의 요청이 들어 왔는지를 분석하고, AWS WAF 블락 리스트에 추가한다. AWS WAF는 지정된 기간동안 해당 IP를 블락한다. 이 지정된 기간이 끝나면, AWS WAF는 다시 해당 IP로부터의 요청을 허용한다. 단, 해당 IP로부터의 트래픽을 모니터링하는 것은 계속된다.
  4. 람다 펑션은 분석된 요청들의 갯수나 블락된 IP주소의 갯수 같은 CloudWatch 메트릭들을 퍼블리싱 한다.

다음은 AWS 서비스들이 어떤 방식으로 정해진 작업들을 수행하는지를 설명합니다.:

  • AWS WAF – 수정 가능한 웹 보안 규칙을 정의하고 이것을 통해 웹 어플리케이션으로의 트래픽을 허용하거나 차단하는 기능을 제공합니다. 이 서비스에서는 아래와 같이 3가지 규칙을 사용하게 됩니다.:
    1. 자동 블락킹 – 이 규칙은 악성 요청으로 식별된 IP주소를 추가합니다. 지금 시나리오에서는 이 규칙을 설정함과 동시에, 블락리스트된 IP주소들에서 들어오는 모든 신규 요청들이 드랍되기 시작하고, 람다가 지정된 폐기 기간(디폴트로 4 시간 설정됨)이 지나 해당 IP를 블락리스트에서 제거하기 전까지 유지됩니다.
    2. 수동 블락킹 – 이 규칙은 수작업으로 특정 IP 주소를 블락 리스트에 추가하는 데 사용됩니다. 해당 IP주소는 관리자가 수작업으로 리스트에서 제거하기 전까지 계속 블락됩니다.
    3. 자동 카운트 – 이것은 일종의 휴지통 개념입니다. 지정된 IP로부터의 요청이 바로 블락킹되지는 않고, 준 실시간성으로 요청 갯수가 트랙킹됩니다. 이를 통해 자동 블락 리스트에서 제거된 이후 해당 IP의 행동에 대한 가시성을 제공해 줄 수 있습니다.
  • Lambda – 서버를 준비할 필요없이 코드를 실행시켜 주는 서비스 입니다. 단지 여러분의 코드를 업로드하면 람다에서 알아서 실행에 필요한 모든 것을 담당합니다. 람다를 통해 다른 AWS서비스들이 행동기반으로 자동으로 기동되도록 작성될 수 있습니다. 이번 시나리오에서는 S3에 엑세스 로그 파일이 업로드 될때 마다 람다 펑션이 실행되도록 구성하였습니다. 이 기능은 해당 로그 파일내 공격자IP들을 식별하고 그것들을 AWS WAF로 블락킹 처리하도록 하는 과정을 담당합니다.
  • CloudFront – 컨텐츠 배포 웹 서비스로서, 다른 AWS서비스들을 통합하여 낮은 레이턴시와 높은 전송 속도로 컨텐츠를 배포할 수 있는 쉬운 방법을 제공합니다. CloudFront는 기본적으로 한시간 내로 엑세스 로그를 제공합니다. 그러나 어떤 로그는 지연될 수 있습니다. 이 시나리오에서 CloudFront는 웹 어플리케이션의 동적, 정적 컨텐츠를 제공하게 됩니다.
  • S3 – 높은 가용성, 확장성, 내구성과 낮은 레이턴시를 가진 저장소를 저렴한 비용으로 이용할 수 있도록 합니다.  이번 시나리오에서는 CloudFront의 엑세스 로그파일이 지정된 S3버킷에 저장되도록 구성됩니다.
  • CloudWatch – AWS상에서 운영되는 어플리케이션과 각종 리소스들에 대한 모니터링 서비스 입니다. 이번 시나리오에서는 람다 펑션에 의해 처리되는 요청의 갯수와 블락된 IP주소의 갯수에 대한 메트릭을 트랙킹하게 됩니다.
  • AWS CloudFormation – AWS인프라의 전개를 주기적으로 혹은 반복적으로 수행할 수 있도록 해주는 서비스입니다. CloudFormation을 통해 필요한 모든 리소스와 상관관계를 하나의 템플릿 파일로 정의할 수 있습니다. 이번 시나리오에서는 필요한 전체 솔루션 스택을 한번에 쉽게 구성할 수 있도록 준비하였습니다.

이번 시나리오에서는 S3버킷, 분당 요청수 제한기준, 블랙리스트에 IP주소를 담아두는 기간 등을 설정하게 됩니다.

AWS 관리 콘솔을 통해 진행하기

시작하기 앞서, 컨텐츠를 제공할 CloudFront 배포지점이 이미 있다고 가정하겠습니다. 만약 없다면, 다음 절차(Creating or Updating a Web Distribution Using the CloudFront Console)대로 만들어 보십시오. 본 시나리오에선 필요한 환경을 간단히 구축하기 위해 CloudFromation 템플릿을 활용해 보도록 하겠습니다. 관련 내용이 알고 싶으시면 이 내용(CloudFormation User Guide)을 참고하시기 바랍니다.

단계 1: CloudFromation 템플릿을 사용하여 환경 구축

  1. CloudFormation console로 갑니다.
  2. 각자 적합한 리전으로 변경합니다. CloudFormation을 사용하게 되면 모든 리소스들이 CloudFormation템플릿을 생성했던 리전에 생성됩니다. 이번 시나리오에서는 람다를 활용하기 때문에, 어느 리전이 람다 활용이 가능한지 확인하기 위해 AWS Global Infrastructure Region Table 을 체크합니다.
  3. 신규 스택 생성(Create New Stack) 버튼을 클릭합니다.
  4. 템플릿 선택화면에서, GitHub(this GitHub repository)에서 waf_template.json를 찾아서 업로드 합니다.
  5. 상세 내역 화면에서, (아래 화면 예시 처럼):
    1. Stack name란에, 적당한 스택이름을 줍니다. 스택이름을 너무 길게 주는 경우, 람다펑션을 실행 할때 에러가 날 수도 있습니다.
    2. Create CloudFront Access Log Bucket란에서 CloudFront Access Log를 위한 버킷을 만들려면 yes를 클릭하고, 기존 버킷을 활용하려면 no를 선택합니다.
    3. CloudFront Access Log Bucket Name란에 CloudFront가 엑세스 로그를 넣기 위한 S3버킷의 이름을 지정합니다. 만약 b 단계에서 no 를 선택했다면 공란으로 놔둡니다.
    4. Request Threshold란에 분당 기준으로 블락킹 없이 제공될 수 있는 최대 요청 갯수를 지정합니다.
    5. WAF Block Period란에 초단위로 임계치를 넘은 IP주소에 대해 얼마동안 블라킹을 할 것인지 설정합니다.
    6. WAF Quarantine Period란에 AWS WAF가 블락킹에서 해제된 IP를 얼마동안 모니터링 할 것인지 설정합니다.
    7. Options 페이지에서 Next를 클릭합니다.
    8. Review 페이지에서 ‘I acknowledge that this template might cause AWS CloudFormation to create IAM resources‘ 체크 박스를 체크하고 Create를 클릭합니다.

이 템플릿으로 이번 시나리오를 실행하는데 필요한 모든 요소들이 마련됩니다: 람다 펑션, 모든 필요한 규칙들이 설정되어 있는AWS WAF Web ACL ( Malicious Requesters라는 이름으로), CloudWatch 커스텀 메트릭, 그리고 만약 Create CloudFront Access Log Bucket란에서 yes를 선택했다면 CloudFront Access Log Bucket Name 란에 주어진 이름으로 버킷이 생성될 것입니다.

단계2: CloudFront 배포 설정 업데이트

AWS WAF를 활성화 시키고, 전 단계에서 생성했던 버킷을 가지고 로깅을 하기 위해 CloudFront 배포 설정을 업데이트 합니다. (만약 이미 CloudFront Access Log를 위한 S3버킷을 가지고 있다면 이번 단계를 생략합니다):

  1. CloudFront console을 열고 업데이트 대상 배포지점을 선택합니다.
  2. Distribution Settings  화면에서, General 탭을 선택하고 Edit를 클릭합니다.
  3. AWS WAF Web ACL 설정을 업데이트 합니다(아래 그림처럼). 옵션 메뉴에는 모든 활성화된 Web ACL들이 나타나는데, 여기서 단계 1에서 생성했던 것(Malicious Requesters)을 선택합니다.
  4. Logging란에 On을 선택합니다.
  5. Bucket for Logs란에 단계 1에서 지정했던 버킷을 선택합니다.
  6. 변경내용을 저장합니다.

만약 CloudFront Access Log를 위한 S3버킷을 이미 가지고 있다면, 신규 로그파일이 해당 버킷에 추가될 때마다 람다 펑션을 기동시키기 위해 S3 이벤트 통보 기능을 활성화 합니다(more details을 참조하세요). 이를 위해, S3 console 을 오픈하고 버킷 속성에서 다음 그림에서 표시된 부분처럼 설정해 줍니다. 만약 람다 펑션 설정 부분이 비 활성화 되어 있다면, 해당 버킷이 CloudFormation팀플릿을 실행했던 리전인지를 확인하기 바랍니다.

단계 3: [생략 가능] CloudFormation 파라메터 수정

만약 단계 1에서 CloudFormation 스택을 생성한 뒤에 설정했던 파라메터 값을 변경하고자 한다면(예를 들어, IP 관련된 블락킹 기간 등을 바꾸고자 하는 경우), 새로 스택을 만들 필요없이 아래 절차대로 변경하면 반영됩니다:

  1. CloudFormation console에서 스택 목록 중 원하는 것을 선택합니다.
  2. Actions 을 클릭하고Update Stack.을 선택합니다.
  3. Select Template 페이지에서, Use the current template을 선택하고 Next를 클릭합니다.
  4. Specify Details 페이지에서, Rate-Based Blacklisting Parameters값을 원하는 값으로 변경합니다(예를 들자면 아래 그림처럼):
  5. Options 페이지에서, Next를 클릭합니다.
  6. Review 페이지에서, I acknowledge that this template might cause AWS CloudFormation to create IAM resources 체크박스를 클릭하고 Update를 클릭합니다.

CloudFormation 은 새로운 파라메터 값으로 스택을 업데이트 하게 됩니다.

AWS CLI 이용하여 스택을 생성하는 방법

이외에도, 여러분들은 AWS CLI를 써서 스택을 생성할 수도 있습니다. 아래 코드는 스택을 만드는 한가지 샘플입니다.(red로 표시되는 부분이 변경될 부분입니다).

aws cloudformation create-stack --stack-name <STACK_NAME> --template-body file:///<PATH_TO>/waf_template.json --capabilities CAPABILITY_IAM --parameters ParameterKey=CloudFrontCreateAccessLogBucket,ParameterValue=yes ParameterKey=CloudFrontAccessLogBucket,ParameterValue=<LOG_BUCKET_NAME> ParameterKey=RequestThreshold,ParameterValue=400 ParameterKey=WAFBlockPeriod,ParameterValue=1400 ParameterKey=WAFQuarantinePeriod,ParameterValue=14400

또한 this GitHub repository에서 waf_template.json 을 찾을 수 있습니다.

테스팅

이번 포스팅에서 제시된 내용을 테스트 해보기 위해서는 CloudFront 가 새 로그파일을 생성할 때 까지 기다려야 합니다. 이런 대기시간이 싫다면, this sample access log file 링크에 있는 샘플을 가지고 바로 S3 버킷에 올려서 테스트 할 수도 있습니다. 업로딩이 끝나고, IP 주소값들이 자동으로AWS WAF의 Auto Block Set 섹션에 들어가 있는지 확인해 보시기 바랍니다.

그리고 CloudWatch 메트릭이 업데이트 되어 있는지도 확인해 보시기 바랍니다. 또한 람다가 로그파일을 분석하는데 몇 초의 시간이 소요되고  CloudWatch가 신규 메트릭 정보를 보여주는 데 최대 2분 정도 소요된다는 점을 알고 계시기 바랍니다. 아래 그림은 Auto Block Set 섹션에 람다에서 처리했던 IP주소들이 어떻게 들어 있는 지를 보여줍니다.

CloudWatch가 어떻게 메트릭 정보를 표시하는지 보기 위해, CloudWatch dashboard를 참조하시면 좋을 것 같습니다.

요약

본 포스팅에서, 여러분들은 지정된 기준 값 이상으로 과다하게 요청하는 특정 IP주소를 자동으로 블락킹 하는 방법에 대해 살펴보았습니다. 여기에서 제시된 Lambda script 를 가지고 여러분들의 상황에 맞게 변경하여 활용하셔도 됩니다. 예를 들어 CloudFront 가 생성하는 데이터를 분석할 수도 있겠습니다(sc-bytes of access log file 같은 정보 등을 분석하여 관련 요청을 블락킹 하는 식으로)

만약 여러분들이 본 포스팅에 대해 질문이나 코멘트가 있다면, 아래 “Comments” 섹션이나 AWS WAF forum에 남겨주시기 바랍니다.

– Heitor

본 글은 AWS Security Blog의 How to Configure Rate-Based Blacklisting with AWS WAF and AWS Lambda에 대한 번역으로 AWS코리아의 보안 분야 솔루션 아키텍트로 일하시고 있는 임기성님께서 작성해 주셨습니다. (more…)

AWS 클라우드 에서 지리적 IP(GeoIP) 차단 관리 방법

글로벌 게임 서비스를 하다 보면, 여러 가지 이유로 특정 국가에 대한 IP를 차단하거나 허용해야 하는 요구 사항이 흔히 발생합니다. 대개 이를 위해서 별도의 상용 방화벽을 사용하여 지리적 IP 블록 기능을 활용하거나, 직접 방화벽을 구축하고 지리적 IP 데이터를 인터넷을 통해 찾아서 직접 관리하는 방법을 사용하기도 합니다.

이 글에서는 실제로 일어나는 서비스 시나리오에 기반해서 현재 AWS가 제공하는 기능을 최대한 활용하여 이러한 요구 사항을 충족하는 과정을 단계별로 살펴 보고자 합니다.

1. 요구 사항
A사는 전문 게임 퍼블리셔 회사이고, B 게임 개발사가 만든 X게임을 글로벌 서비스로 오픈하려고 합니다. 퍼블리싱 계약 상 중국과 일본에서 접근은 차단해야 하지만, 일부 IP는 관리 목적을 위해 접근을 허용해야 하게 되었습니다.

그 외에도 현실적인 몇 가지 요구 사항을 추가해 본다면,

  1. 게임 서비스는 로그인 서버와 게임 서버로 구분되어 있다.
  2. 로그인 서비스는 REST 방식의 HTTPS 서버이며, 게임 서버는 TCP 이다.
  3. 게임 서버는 특정 IP로 바로 접근해야 한다.
  4. 게임 클라이언트 변경은 어렵다. 운영 체제(OS) 에 대한 접근은 퍼블리싱 회사에 대해 엄격하게 제한된다. 따라서 가능한 인프라 아키텍처로 문제를 해결해야 한다.
  5. 가능하다면 장기적으로 DDoS방어력을 갖추기 바란다.

아마 인프라 보안 관련 기술 경험이 있는 분이라면 몇 가지 대안을 생각했을 것입니다. 예를 들어, 방화벽 레이어를 서버군 앞에 둔다던가 직접 HAProxy 같은 리버스 프록시를 설정하는 해 볼 수 있을 것입니다. 그렇다면, AWS 클라우드에서 이러한 지리적 IP를 쉽게 허용 및 차단하는 방법은 무엇이 있을까요?

이를 위해, AWS에서는 자체 클라우드 서비스와 파트너들이 제공하는 다양한 파트너 솔루션을 제공합니다.  이 중에서 어떤 것이 가장 간단한 것인지 찾기 위해 팀이 모였다면, 간단한 브레인스토밍을 진행할 수 있습니다.

2. 다양한 접근 방법
일반적인 해결 방법과 AWS 안에서 가능한 모든 방법을 테이블에 올려 놓는 다고 하면, 아래와 같은 방법을 고려해 볼 수 있습니다.

  1. 모바일 클라이언트 게임에서 지역을 알아내서 접근 자체를 막는 방법
  2. 상용 방화벽 레이어를 게임 서버와 로그인 서버에 구축하는 방법
  3. HA 프록시 등으로 프록시 서버 레이어를 구성해서 두는 방법
  4. 운영 체제 내 방화벽 기능을 이용하는 방법
  5. Amazon Route 53의 지리적 IP 라우팅 기능을 이용하는 방법
  6. Amazon CloudFront 및 WAF(Web Application Firewall)을 사용하는 방법

요구 사항 중 가장 큰 제약 조건은 바로 2번 요구 사항입니다. 게임 서버와 로그인 서버는 각기 다른 방식으로 서버와 통신하기 때문에, 가장 쉽게 인프라 아키텍처로 해결할 수 있는 방법은 위에서 2, 3번입니다.

그렇다면 2번과 3번은 각기 어떤 단점이 있을까요? 공통적으로 TCP 접근을 위해 외부에 공개(public) IP를 오픈하고, 게임 서버와 연결해 줄 수 있는 NAT 기능까지 지원하는지 살펴 봐야 합니다. 뿐만 아니라, 지리적 IP 차단 및 관리가 용이한지도 살펴봐야 할 것이다.

따른 문제점은 상당한 비용이 발생한다는 점입니다. 지리적 IP 정보를 인터넷에서 받아서 직접 리눅스 서버 등으로 방화벽 레이어를 구축하는 경우, 지리적 IP 정보는 지역 수준의 구분은 인터넷에서 무료로 구할 수 있습니다. 하지만, 이를 이용해서 iptable과 같은 기능을 이용해서 직접 구현해야 합니다. 이런 것을 직접 구성하고 관리하는 것은 어렵습니다.

위의 그림은 이러한 경우의 아키텍처입니다. 게임 서버를 위한 지리적 IP 차단 레이어는 상용이든 직접 구현하든 고정 IP를 지원해야 하고, 방화벽 규칙을 위한 레이어가 존재해야 합니다. 여기서는 서브넷으로 상호 영역을 구분하였습니다.

요구 사항 3번 조건이 너무 강하다면, 게임 서버 앞단에는 직접 구현된 NAT 레이어와 방화벽 레이어가 존재해야 합니다. 비용 최적화를 위해서는 가능한 두 NAT 레이어를 분리해야 하는데, 그 이유는 AWS에서 고정 IP를 인스턴스에 부여하는 갯수가 제한이 있기 때문입니다.

특히, 요구 사항 4번 조건처럼 게임 개발사인 B사가 인프라 관리 요건에 맞게 클라이언트의 코드를 수정하는 것이 어려운 경우가 많습니다. 모바일 게임 클라이언트 코드에서 해결하는 방안은 쉽지 않습니다. 만약 개발사가 동의 한다면, 로그인 전에 특정 지리적 IP 정보를 알려주는 서버를 만들어서 로그인 전에 체크를 하는 방법은 있습니다.

4번 해결 방안은 퍼블리셔와 개발사 간의 계약에 의해 결정되므로 경우에 따라 가능한 해결책일 수 있습니다. 하지만, 게임 서버 안에 직접 운영 체제 방화벽으로 방어를 하는 것으로 일괄 적으로 관리할 수 있는 방안을 찾아야 한다는 단점이 있습니다.

3. AWS 클라우드에서 해법 찾기
자 이제 AWS 서비스를 통한 해법을 보다 깊게 살펴보겠습니다. 먼저 지리적 IP 처리 기능으로 활용할 수 있는 서비스는 Amazon Route53의 지리적 라우팅 기능과 Amazon CloudFront에 존재하는 AWS WAF (웹 애플리케이션 방화벽) 기능입니다. 앞의 요구 사항에 적합한 구현을 위해서는 각 서비스 기능에 대해 좀 더 깊이 있게 이해를 해야 합니다.

Rout53의 지리적 라우팅 기능은 클라이언트가 접속한 IP로 부터 지리적 위치를 알아내고 이를 특정한 AWS서비스 리소스로 라우팅해 주는 기능입니다.

위의 그림은 Route 53에서 지리적 라우팅의 설정 모습입니다. A 레코드 셋 설정을 통해 지리적으로 들어오는 IP를 ELB, S3, CloudFront의 엔드포인트 등으로 연결해 주게 됩니다.

로그인 서버 앞에서 지리적 IP콘트롤을 가장 간단하게 구성할 수 있는 것은 Route53과 CloudFront를 이용한 지리적 IP 제어 아키텍처입니다.

Amazon WAF는 현재 지리적 IP 차단 기능을 제공하지 않습니다. 따라서, 요구 사항을 해결하기 위해서는 앞단에서 먼저 지리적 위치를 어떻게든 알아내는 것이 필요합니다.  위 그림에서는 CloudFront를 2개 배포하고, 막으려는 대상 지리적 위치를 1번 CloudFront로 보냅니다. WAF의 경우는 규칙(Rule)의 순서에 따라 우선순위가 정해지는데, 허용하려는 IP 영역을 1번에 두고, 막으려는 지역, 예를 들면 한국(KR), 일본(JP), 중국(CN) 등을 전체 차단을 2번 규칙에 두면 됩니다. 지리적 제어가 필요 없는 클라이언트 지역은 2번 CloudFront로 보내게 됩니다.

그런데 이 방법에는 한 가지 문제가 존재합니다. CloudFront를 Route53에서 A레코드로 등록하려면 CloudFront에 CNAME을 할당해야 합니다. 문제는 위의 구성에서 CNAME이 두 개가 된다는 점입니다.

CloudFront는 고객이 최초 요청한 대상에 대해 체크를 하게 되는데, 만약 다른 도메인으로 경유해서 들어오게 되면 “Bad Request”라는 메시지를 던지게 됩니다.

즉, 위의 경우 1번 CF의 CNAME이 a.com, 2번 CF의 CNAME이 b.com이라고 이라고 하고, 이를 묶기 위해 c.com을 두었다면, 고객은 c.com으로 요구를 요청하게 됩니다. 1번, 2번 CloudFront모두 요청한 도메인(c.com)이 자신의 CNAME과 다르기 때문에 오류를 내게 됩니다. 이를 해결하는 방법은 매우 간단합니다. 클라이언트에서 요청할 때 헤더의 origin 값을 1번, 2번 CNAME으로 바꾸어서 전달해 주면 됩니다.

하지만, 클라이언트가 각기 다른 CNAME 값 중에 어디로 요청할 수 있다는 말은 이미 지리 정보를 클라이언트가 알고 있어야 한다는 문제에 다시 봉착 합니다. 이는 별도 지리 정보 제공 서버가 있어야 하거나, 클라이언트가 자신의 위치를 알고 있어야 합니다.

이를 해결하기 위해서는 좀 더 서비스 내부 기능을 활용하는 방법을 고안해 내야 합니다. 그 해결책 중의 하나가 바로 CloudFront 샌드위치 아키텍처입니다.

먼저 이와 같은 아키텍처를 고안하게 된 배경을 설명해 보고자 합니다. WAF는 CIDR로 IP 조건을 검색할 수 있습니다. 단 /8, /16, /24, /32 로 8비트 단위 레인지 만을 지원합니다. 중국에 속한 IP는 CIDR로 대략 6천개 정도 되는데, 이를 위 단위로 전환하면 대략 6만건의 CIDR가 됩니다.

조건이 너무 많아지면 성능 저하가 발생할 수 있고, 만약 고객이 여러 지역에 대해 관리를 해야 한다면 CIDR 형태로 WAF상에서 관리하는 것은 무척 힘든일이 될 수 있습니다.

재미난 것은 CloudFront의 고급 기능 중에 확장 헤드를 추가해 주는 기능이 있습니다. cloudfront-viewer-country라는 확장 헤더는 요청이 어느 나라에서 이루어졌는지를 헤더값으로 추가해주게 됩니다.

이렇게 확장 헤더값을 추가하는 기능보다 WAF는 앞에 존재하기 때문에 가져 올 수가 없습니다. 따라서, 이 기능을 이용하려면 WAF를 한번 더 통과하게 해서, cloudfront-viewer-country 확장 헤더 값을 추가한 이후에, 두번째 WAF에서 이 값을 이용해서 차단 할 수 있습니다.

첫번째 CloudFront를 통과하게 되면, 요청 IP가 CloudFront의 값으로 변하게 되는데, 원래 고객의 IP값은 x-forwarded-for 값에 존재합니다. 따라서 이 때 WAF 규칙을 만들 수 있게 됩니다.

각각 문자열 조건을 만든 다음 아래와 같이 WAF 규칙을 만드는 것입니다.

물론 본 아키텍처의 단점은 CloudFront의 가격이 2배가 나온다는 점입니다. 그러나, 지역별 IP 차단이라는 요구 사항에 대해 관리 및 운영 편리성을 생각하면 매우 효율적이고 간단한 해결책입니다.

게임 서비스에서 지리적 IP 관리는 매우 일상적인 요구 사항입니다. AWS 클라우드 서비스 빌딩 블록을 이용하여, 간단한 아키텍처 재구성만으로 본 요구 사항을 구성하는 해법을 찾아 보았습니다. 이러한 요구 사항을 충족해 주는 AWS 서비스나 기능이 나올 때 까지 활용해 볼 수 있는 대안이 될 것입니다.

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 박선용 솔루션즈 아키텍트께서 작성해주셨습니다.

AWS WAF 서비스 공개

여러분 웹 서버의 access log 및 error log를 한번 살펴 보신 적이 있으신가요? 사용자 뿐만 아니라 크롤러 등의 정상적인 요청이 대부분이지만, 종종 이상하고 위험하게 보이는 로그도 볼 수 있습니다. 예를 들어, 제 서버를 한번 확인해 봤는데, 잘 알려진 패키지나 소프트웨어의 취약점을 이용하기 위해 자주 설치하는 주소로 요청을 보내는 경우가 매우 흔합니다. (소스 서버 IP 주소는 이미지 생성을 위해 바꾸었습니다~)

이 중에 하나라도 성공한다면, 공격자들이 취약점을 틈타서 서버 권한을 얻을 수 있습니다. 흔히 사용하거나 기본 아이디와 암호로 접근을 하거나 시스템 취약점, 언어 및 애플리케이션 취약점을 노리고 SQL Injection이나 크로스 사이트 사기 요청 등의 단계로 공격이 진행될 수 있습니다.

우리가 원하던 원치 않던 이러한 비정상적인 호출은 매일 항상(24×7) 일어나고 있습니다. 우리가 서버 업데이트를 잘하고, 소프트웨어 패치를 열심히 해서 공격 가능성을 줄이더라도 보호를 위한 추가적인 레이어를 두는 것이 좋습니다.

신규 AWS WAF 서비스
이를 위해 오늘 AWS WAF (Web Application Firewall)서비스를 공개합니다. 이 글을 읽어 보시면 아시겠지만, AWS WAF를 통해 AWS 기반의 웹 서비스를 애플리케이션 단계의 공격으로부터 보호하는 역할을 할 수 있습니다.

몇 분 안에 웹 애플리케이션 보호를 위한 설정을 할 수 있습니다. 한 개 이상의 웹 접근 제어 목록(Web Access Control Lists, Web ACL)을 만들고, 내장된 규칙(IP 주소 및 허용/거부 URL에 대한 조건 모음)을 통해 이에 대한 요청을 제어합니다. 이 ACL 목록은 Amazon CloudFront 배포 시 적용할 수 있습니다.

이러한 규칙 및 조건은 여러 가지 방법으로도 사용 가능합니다. 예를 들어 위에 로그에서 봤던 IP 주소를 모두 차단할 수 있습니다. 만약 비슷한 요청이 다른 IP로부터 오고 있다면, “/typo3”, “/xampp”와 같은 URL 기반으로도 차단이 가능합니다. 여러분 애플리케이션 내부에 있는 URL에 대해 접근을 허용하거나 차단할 수도 있고, SQL injection공격에 사용하는 다양한 패턴도 규칙을 만들어 둘 수 있습니다.

AWS WAF 개념
이제 실행 조건(condition), 규칙(rule), Web ACL 및 동작(action) 등에 대해 설명해 드리겠습니다. AWS WAF 관리 콘솔의 스크린샷으로 이해하시기 편합니다.

Conditions 들어오는 요청을 검사합니다. 요청 URL, 쿼리 스트링(query string), 특정 HTTP header 또는 HTTP 메소드 등 (GET, PUT 등):

공격자들이 자신들의 시도를 여러가지 방법으로 위장하는 경우가 종종 있기 때문에 조건을 만들기 앞서 여러 가지 변형 옵션을 찾아서 살펴 보는 것이 좋습니다.

각 조건은 IP 주소를 조사할 수도 있는데, /8, /16, /24 등의 범위 또는 싱글 IP인 경우 /32로 찾을 수 있습니다.

Rules 하나 이상의 조건에 대한 참조를 말하는 것으로 모든 조건이 만족 되어야 실행이 됩니다. 예를 들어 특정 콘텐츠를 차단하기 위해 IP 기반 규칙과 호출 기반 규칙을 함께 사용할 수 있습니다. 각 규칙은 Amazon CloudWatch 측정치로 만듭니다.

Actions 규칙의 일부분으로서 규칙에 부합하는 모든 조건에 대해 우리가 취할 행동을 말합니다. 그냥 두거나 혹은 차단하거나 부합하는 양을 측정할 수도 있습니다. (결정적인 동작을 취하기 전에 새로운 규칙을 실험해서 확인하는 것도 필요합니다.)

Web ACLs 각 규칙의 동작에 따른 여러 규칙을 참조합니다. 규칙 내 모든 조건에 맞기 전에는 각 (CloudFront) 배포에서 들어오는 호출을 정상적이지 않은 것으로 판단합니다. 이 때 규칙에 맞는 동작이 실행됩니다. 규칙이 맞지 않으면 기본 동작(차단 또는 허용)만 수행합니다.

WAF 지금 해보기
이제 조건, 규칙, Web ACL 등을 한번 같이 만들어 보겠습니다. 관리 콘솔 뿐만 아니라 AWS Command Line Interface (CLI), AWS Tools for Windows PowerShell, Web Application Firewall API를 활용하실 수 있습니다.

관리 콘솔에서 WebACL을 만드는 방법을 알려주는데 ProtectSite라는 이름을 사용해 보겠습니다.

허용 혹은 차단한 조건을 만듭니다.

서버 로그에서 가짜 IP를 차단하기 위해 BadIP라는 조건을 만들어 보겠습니다.

BadCompany라는 규칙도 만듭니다.

규칙을 선택하고 동작을 골랐습니다.(하나의 Web ACL에서는 여러 규칙을 사용할 수 있지만, 저는 하나만 골랐습니다.)

위에서 보다시피 기본 동작은 요청을 허용하는 것입니다. 실제로는 (조건 + 규칙 + Web ACL) 조합으로 10.11.12.217에서 오는 트래픽을 차단하고 다른 곳에서의 호출은 허용합니다.

다음 단계는 우리가 만든 Web ACL을 CloudFront 배포본에 적용하는 것입니다. (앞으로 더 많은 서비스에도 적용 예정입니다.)

단일 Web ACL을 여러 개 CloudFront 배포에 사용할 수 있습니다만 각 배포는 하나의 Web ACL만 적용 됩니다. 설정을 하면 몇 분 안에 적용이 됩니다. Web ACL이 동작해서 얼마나 규칙이 적용되는 지 CloudWatch 통계치를 통해 확인할 수 있습니다.

API 기능 소개
지금까지 설명한 모든 기능은 API로도 수행이 가능합니다.

  • CreateIPSet, CreateByteMatchSet, 및 CreateSqlInjectionMatchSet – 조건 생성
  • CreateRule – 조건에서 규칙 생성
  • CreateWebACL-규칙에서 Web ACL 생성
  • UpdateWebACL– CloudFront 배포에 Web ACL 적용

그 외에도 목록 보기, 정보 업데이트 및 삭제를 할 수 있는 API들이 있습니다.

GetSampledRequests 함수를 실행하면 5,000개의 호출을 해서 특정 패턴의 규칙이 적용되는지 확인해 볼 수 있습니다. 호출 결과 실행한 동작(ALLOW, BLOCK, COUNT)에 대한 상세한 정보를 얻을 수 있습니다.

지금 사용하기
AWS WAF은 오늘 부터 바로 CloudFront에서 사용할 수 있습니다. 가격은 $5/web ACL, $1/rule이며, 1백만 HTTP 호출당 $0.60 입니다.

— Jeff;

이 글은 New – AWS WAF의 한국어 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.