AWS WAF도 생소한데 allow, block도 아닌 count는 뭐지..
terraform을 사용하여 cloudfront+s3로 웹호스팅을 구성하고, 그 앞단에 waf를 둠으로써 특정 ip만 접속 가능하게 구성하는 과정에서 정리한 글이다.
분명히 잘 구성했다 생각했는데 cloudfront domain name으로 접속시 웹페이지가 제대로 뜨지 않았다.
그러나 waf를 걷어내면 정상적으로 동작하였는데,
원인은 바로 web acl에서 rule group을 지정하는 부분에서 overide_action을 count로 지정했기 때문이었다.
AWS WAF(Web Application Firewall)
말 그대로 웹 애플리케이션 방화벽으로 웹 프로토콜(HTTP) 정보를 바탕으로 차단/허용 룰을 설정한다.
rule action
rule에 일치하는 트래픽이 들어왔을 때 어떤 액션을 취할것인지 정의하는 것이다.
- allow: 해당 요청을 허용한다.
- block: 해당 요청을 거부한다.
그렇다면, count란 대체 무엇일까?
count
count는 해당 요청을 허용할 것인지, 막을 것인지 결정하지 않는다.
rule에 매칭되는 요청이 들어오면, 해당 요청이 들어왔다는 것만 인지한 후 다음 순위의 rule로 해당 요청을 보내버린다.
만약 jisun-web-acl에 A rule group과 B rule group이 있다고 해보자.
- jisun-web-acl의
default action:block A rule group의 action:countB rule group의 action:allow
만약 A rule group에 매칭되는 요청이 들어왔다고 가정해보자.
그럼 A rule group의 action에 따라 요청을 처리할텐데, count action이므로 같은 web acl에 있는 다른 rule group에 그 결정을 맡기게 될 것이다.
그렇게 되면 2가지 경우의 수로 나눠서 볼 수 있다.
1. 해당 요청이 B rule group에 해당되는 경우
2. 해당 요청이 B rule group에 해당되지 않는 경우
1번의 경우에는 B rule group의 action이 allow이므로 해당 요청은 최종적으로 allow될 것이다.
그러나 2번의 경우에는 요청이 B rule group에 해당되지 않으니 결국 web acl의 default action에 따라 처리됨으로 block될 것이다.
count를 왜 쓰는 것일까?
만약 새로운 rule group을 등록했을 때 바로 allow/block action을 지정해버리면, 테스트 환경에선 상관없겠지만 실제 운영중인 환경에 적용할 시 바로 장애로 이어질 수 있다.
그렇기에 count action으로 지정해두고 새로 만든 rule group에 어떤 요청이 매칭되는지 테스트 후 다른 action을 지정하면 좀더 안정적으로 waf를 사용할 수 있게 된다.
끝!
