[AWS] AWS WAF 적용 시, 주의해야 할 Default 설정들

AWS Immersion Day 에서 소개 받은 AWS WAF v2 를 적용하면서
Default 설정 때문에 필자가 직면했던 문제점들에 대한 포스팅입니다.

 

이전 포스팅

---

[AWS] 서비스에 WAF 적용하기

---

서론

---

보통 회사의 직원으로써 자사상품은 항상 좋은점만 소개한다.
AWS WAF 도 그랬다... (그래서 홀렸다...)

AWS 에서 제공하는 Rule 들로 WAF 를 적용하기만하면 OWASP 10 취약점을 잡을 수 있다고 소개했지만
실상은 그렇지 않았다. 커스텀이 아주 많이 필요했다...

하지만 보안전문가들에게는 커스터마이징을 쉽게 할 수 있는 AWS WAF 충분히 매력적인 서비스임은 분명하다.

필자는 단순한 백엔드 개발자이지 보안전문가도 아니며,
보안관련 과목을 수강한적도 없고 WAF 라는 용어도 몰랐던 보안계의 어린이임을 미리 밝힌다.

---

 

403 대잔치

AWS Immersion Day 에서 얻은 지식 하나.
"WAF 는 CF 앞에 위치할 수도 있다."

"오,, 그러면 적용만하면 나쁜 트래픽을 서버(EC2)까지 도달하는 것을 차단할 수 있는 것 이구나!"
희망차게 나는 WAF 를 배운대로 Dev 환경에 설정하였다.

"이제 우리서비스는 보안적으로 매우 탄탄한 서비스가 되겠군! >3< 🐧"

곧이어 빗발치는 동료 개발자들의 항의
"지금 Dev 환경이 동작안하는데, 적용하신 WAF 때문인가요?"

(참고 : AWS WAF v2 는 트래픽을 차단(Block)할 시, Default 로 403 을 반환하게 됩니다.)

 

급히 적용한 것을 RollBack 하고 Block 된 Request 의 로그들과 함께 AWS Docs 를 탐험하기 시작했다.

그러다 충격적인 문서(AWS Docs)를 보게된다.

 

You can inspect the first 8 KB (8,192 bytes) of the body of a request.

 

" ??? 그럼 파일업로드와 같은 기능은 모두 동작안하는 거 아냐...? "

 

뿐만 아니라 크기가 8KB보다 큰 Request 를 차단하는 규칙을 명시적으로 추가 하지 않는 한

Request 8KB 제한 이후에 작성되는 악성 페이로드는 WAF를 완전히 우회할 수 있다.

 

그렇다. 무조건 Block 만 풀면 되는 일도 아니다.

이러한 Rule 들에 대해서는 반드시 예외처리를 해야하며 이러한 작업에 대해서는 다음 포스팅에서 다루기로 하겠다. 

이번 포스팅에서는 Default 설정으로 사용할 시 문제가 될 수 있는 Rule 들에 대한 리스트업만 하도록 하겠다.

 

사이즈 제한(Size Restriction) 말고도 AWS WAF 에는 위험한 Default 동작이 있는데

저처럼 아무것도 모르고 적용했다가 사내 모든인원들이 찾아오는 경험을 하지 않길 바라며

적용전 꼭 Count 로 집계해야하는 설정들을 공유한다.

 

[Tip] WAF 를 적용하는 가장 이상적인 방법은 모든 Rule 을 Count 로 두고,
         각 서비스마다 열어주어야하는 Rule 이 무엇인지 파악을 하고 적용하는 것이 좋습니다.

 

 

---

AWS WAF 의 위험한 대표적인 Default 설정들

---

아래의 Rule 들은 Block 으로 설정하면 아니된다.

모두 Override to Count 로 동작을 변경하여 로그를 쌓은 후 
데이터를 바탕으로 정상적인 요청임이 확인되면

Custom Rule 을 생성하여 정규식으로 URL 을 제어하는 작업을 하는 것이 좋다.

 

1.  SizeRestrictions_BODY

요청 Body 가 8KB 가 넘는 트래픽은 모두 차단한다.
대부분의 서비스는 페이로드에 8KB 가 넘는 요청을 보낼 경우가 많다. (예시 : 파일업로드)

 

2. NoUserAgent_HEADER

UserAgent 헤더가 없는 요청은 모두 차단한다.
서버간 API 콜에서 UserAgent 헤더를 채우지 않고 보내는 경우가 많다.

 

3. CrossSiteScripting_BODY

XSS 공격에 해당하는 문자가 검출되는 요청은 모두 차단한다.
이미지, 음성파일등을 전송하게되면 binary 코드로 바뀌면서 
AWS WAF 가 XSS 공격이라고 생각하는 문자열 ( < , </ , ` ) 등을 포함할 수도 있다.

 

4. SQLi_BODY

SQL Injection 공격에 해당하는 문자가 검출되는 요청은 모두 차단한다.
이미지, 음성파일등을 전송하게되면 binary 코드로 바뀌면서 
AWS WAF 가 SQLI 공격이라고 생각하는 문자열 ( -- , ^ , ; ) 등을 포함할 수도 있다.

 

5. (번외) AWSManagedIPDDoSList (Default : Count)

DDoS 공격에 가담한 것으로 식별되는 IP 의 요청을 차단한다. 

해당 Rule 은 Default 가 Count 라 그대로 두어도 무방하지만
혹여나 Block 으로 설정해야하나 고민하시는 분들을 위해 추가하였다.

Default 동작이 Count 인 것에는 이유가 있으니 Dos 와  DDos 공격의 차이점을 검색하길 바란다.

---

 

마치며

---

위에 리스트업 한 Rule 들 말고도 필자가 놓친 Rule 들이 더 있을수도 있다.

그리고 서비스마다 Count 로 변경해야하는 Rule 들의 종류가 상이하기 때문에 
서비스에 AWS WAF 를 적용할 때에는 반드시 모두 Count 로 설정하고 일정기간 로그를 쌓으며 
데이터를 바탕으로 판단해야 할 것이다.

 

 

 

다음 포스팅에서는 AWS WAF False Postive Mitigation (AWS WAF 오탐 예외처리) 이라는 주제로 뵙겠습니다.

 

[AWS] AWS WAF 오탐 예외처리 (AWS WAF False Positive Mitigation)