AWS Managed WAF 체험기
DevSecOps팀 보안파트 금도원
AWS에서 기존 WAF에서 새로운 WAF(Web Application Firewall)를 출시하였습니다. 새로운 WAF의 이름은 AWS Managed WAF 입니다.
AWS Managed WAF는 기존 AWS Classic WAF에 비해서 설정이 많이 간편해 졌습니다. 예전 AWS Classic WAF는 Web ACL를 하나 만들기 위해 Conditions > Rules > Web ACL을 생성하는 복잡한 과정을 거쳐야 했습니다. 또한 모든 설정들이 무슨 의미인지를 알기가 상당히 어려웠습니다.
아마 처음 WAF라는 서비스를 접했으면, 해당 구조를 이해하고 설정하기 더 어려웠을 것입니다.
아래는 XSS(Cross-Site Scripting)를 탐지하는 Condition 예시 그림입니다. 1개의 WEB ACL을 만들기 위해서 Condition과 Rule을 생성하고, Web ACL에 적용하는 방식입니다. 또한, 각 ACL별로 Allow(허용), Deny(차단), Count(모니터링/탐지)도 설정해야 합니다.
이렇게 Condition 하나를 생성하기 위해서도 상당히 많은 고민이 필요했습니다. 하지만 만약 Default Condition을 제공하여 모든 탐지패턴에 대해 적용할 수 있었다면 WAF를 통한 Web ACL 적응이 쉽지 않았을까 생각 됩니다.
AWS Managed WAF에서는 몇가지 항목들의 이름이 조금 변경 되었는데 Condition이라는 이름은 사라지고 Rules와 Rule로 이름이 변경되었습니다.
또한 Web ACL에서 모든 Rules가 직관적으로 보이게끔 변경되었습니다.
그럼 지금의 AWS Managed WAF로 Web ACL을 생성해보겠습니다.
신규 AWS Managed WAF 서비스에 접속한 후 Web ACLs > Region 선택 > Creates web ACL을 클릭 합니다.
Web ACL 기본 정보 설정은 아래 그림과 같습니다.
WebACL을 생성할 때 필요한 Resource type은 CF 서비스, ALB 서비스로 구분 됩니다. 이 때 생성한 Resource Type은 변경되지 않기 때문에, CF용 Web ACL과 ALB/API-GW 용도의 Web ACL을 따로 생성해 주어야 합니다.
Add AWS Resources는 나중에 추가해도 되니 생성 시에는 공백으로 넘어가도 됩니다.
다음 단계는 Add managed rule groups 입니다.
AWS Managed WAF로 업그레이드 되면서 가장 크게 변화된 것이 AWS manged rule groups를 기본적으로 제공한다는 것입니다. 그리고 3rd-party 벤더들의 WAF rule들도 쉽게 추가 할 수 있도록 변경 되었습니다.
여기에서 가장 유심히 보아야 할것은 Capacity와 Action입니다.
1개의 Web ACL은 최대 1500 Capacity를 가지고 있습니다. AWS managed rule의 총합이 1500 Capacity를 초과할 수 없다는 뜻입니다.
또한 Action에서 Set rules action to count를 활성화 하지 않으면 해당 rule에 탐지된 트래픽은 기본적으로 차단됩니다. (WAF를 최초 설정한다면 반드시 Set rules action to count로 활성화 해야 갑작스런 서비스 장애에서 벗어날 수 있습니다.)
그리고 보호해야 할 ALB의 서비스에 따라서 Add to web ACL을 설정하면 됩니다. 예를 들어 보호해야 할 ALB에 연결된 서비스가 Windows 시스템밖에 없다면 Linux operating system rule을 선택함으로써 불필요하게 Capacity를 낭비할 필요가 없습니다.
모든 Rule을 선택하게 되면 1975/1500 Capacity가 됩니다. 따라서 불필요한 rule은 선택하여 삭제해 주면 됩니다.
Default web ACL action for requests that don’t match any rules는 해당 rule에 해당되지 않은 트래픽에 대해서 Allow(허용), Deny(차단)을 선택하는 항목입니다.
예를 들어, 특정 패턴을 차단하고자 하는 Web ACL을 생성하였다면 Default Web ACL action은 Allow로 설정하여야 하고, 특정 패턴만 허용하고자 하는 Web ACL을 생성하였다면 Default Web ACL action을 Deny로 설정하면 됩니다.
- 블랙리스트 기반의 패턴 탐지 : Default Web ACL action Allow
- 화이트리스트 기반의 패턴 탐지 : Default Web ACL action deny
특정 IP 외 모든 트래픽을 차단하고 싶은 경우 IP Sets rule 옵션에 IP를 추가하고, Default action을 deny로 설정하면 됩니다.
다음은 rule의 우선순위를 정하는 메뉴입니다. WAF(Web Application Firewall)도 방화벽이기 때문에 방화벽의 기본 동작 방식을 따르게 됩니다.
방화벽은 인입되는 트래픽에 적용되는 rule이 우선순위가 높은 rule에 해당하는 경우 우선순위가 낮은 rule은 무시 합니다.
따라서 가장 범용적인 rule을 우선순위 1번으로 두고, 가장 국소적인 rule(또는 any any deny)을 마지막 우선순위로 놔두는 방식을 취합니다.
다음은 CloudWatch metric에 표시될 네이밍을 지정하는 설정입니다. 이 부분은 기본 설정을 그대로 사용해도 됩니다.
마지막으로 모든 설정이 맞는지 리뷰를 하고 Create web ACL을 눌러주면 AWS Managed WAF Web ACL이 생성됩니다.
Step 2 and 3 Add rules and set rule priority의 Capacity의 총합이 Web ACL rule Capacity units used의 값과 일치하지 않는 버그가 있으니, 참고하시기 바랍니다.
드디어 Web ACL이 생성되었습니다!
AWS Managed WAF을 설정하면서 확인된 사실들과 추가적으로 구현해야 하는 기능들
- ALB 리소스는 동시에 1개의 Web ACL을 적용할 수 있습니다. 따라서 Capacity 관리가 더욱 더 중요합니다.
- AWS WAF에서 제공하는 Sample request는 3시간이 끝입니다. 따라서 Logging 설정은 필수이며, 해당 로그는 최소 1년간 보관해야 합니다.
- Logging을 설정하기 위해서는 Amazon Kinesis Data Firehose 설정이 필수입니다.
- Overview에서 보여주는 Sample request를 보건데, AWS WAF는 HTTP Header에 대한 데이터만 출력을 해줍니다.
- Logging에서도 HTTP Header에 대한 정보만 출력됩니다. HTTP body의 정보를 보여주지 않기 때문에 POST Method에서 발생되는 이벤트에 대해서 패턴을 찾고 예외처리를 할 수가 없습니다. (우리는 해당 URI를 rule에서 제외하는 수밖에는 없습니다. 이것이 오탐인지 정탐인지를 확인할 수 없으므로)
- AWS WAF는 어떠한 rule에 매칭되어 Action이 일어났는지는 알려주지만, HTTP Header 어느 구문에서 rule이 매칭되었다고 표시해 주지 않습니다.
일반적인 웹방화벽 Appliance 장비들은 탐지 이벤트 발생 시 어떠한 파라미터/URI가 해당 이벤트에 탐지되었는지 표시를 해줌으로써 정상적인 이벤트에 대한 웹방화벽의 오동작을 필터링할 수 있게 해줍니다.
- Allow 이벤트에 대해서도 Overview에 표시가 됩니다. (어떻게 끄는지 메뉴가 없습니다.)
- 가장 중요한 리미트. 기본 리미트는 ALB의 Web ACL당 초당 Request는 10,000개밖에 되지 않지만, 증가 요청을 할 수 있습니다. (AWS Support) (그런데 AWS Support에서 서울 리전은 선택이 안됩니다.)
- AWS New WAF에 대한 Terraform 지원을 기다리고 있습니다.
그럼 다음시간에는 Logging 설정과 모니터링, 알림, 어떻게 패턴 최적화를 진행해야 할지 알아보겠습니다.
