WAF와 ACM 동시 사용에 관한 고찰 (https, ssl)

 클라우드반 최종 프로젝트에서 아래와 같이 구성해서 발표했었다.

그런데 오케스트로 기업 엔지니어분한테 WAF에 대한 문제를 지적을 받았다.

 

"아래 구성도에서 과연 클라우드 프론트가 먼저 외부 트래픽을 받는 것일까요?

아니면 WAF가 먼저 트래픽을 받는 것일까요?"

 

"만약 ACM을 쓴다면 SSL로 처리되어 HTTPS 트래픽은 암호화되어서 들어올테고클라우드 프론트단에 있는 WAF는 이 패킷의 내용물을 검사하지 못하니 중요한 문제다"

 

라는 치명적인... 질문이었다.

나는 당시에 cloudfront에 WAF를 부착하다싶이 구축한 기억밖에 안떠올라서당연히 방화벽인 WAF가 먼저 받는게 아니겠냐는 답변을 했지만 사실 틀린 답변이었다.

 

 

 

 

~조사 결과~

 

일반적으로 WAF는 HTTP 헤더, HTTP 요청 본문, URI 쿼리 문자열 등을 검사해야 하기 때문에 웹 애플리케이션 방화벽(WAF)이 해독된 트래픽에 액세스할 수 있어야 한다. 암호화된 트래픽에서는 수행되지 않는다.

그렇기 때문에 AWS의 WAF 제품은 AWS에서 SSL/TLS를 관리하는 CloudFront, API Gateway 또는 Application Load Balancer와 같은 서비스에만 배포할수 있다고 한다.

따라서 예를 들어 Application Load Balancer를 사용하는 경우 최종 사용자와 로드 밸런서 간에 보안 HTTPS 연결이 형성되고 SSL/TLS 암호화가 로드 밸런서에서 종료된다. 그런 다음 AWS는 지정된 대상(예: 애플리케이션 서버)으로 전송하기 전에 WAF를 통해 (현재 해독된) 트래픽을 실행한다. 백엔드 암호화(로드 밸런서와 대상 간)도 지원되므로 트래픽이 로드 밸런서에서 나갈 때(WAF를 통해 실행한 후) 다시 암호화된다.

 

(TLS/SSL 종료는 각 호스트 서비스(예: Cloudfront, API Gateway 및 ELB의 Application Load Balancer)에서 수행된다.)

 

즉 기존 ACM이 Route53에 걸려있는데, Cloudfront단으로 바꾸면 될것 같아서 작업에 들어갔다.

 

 

1. WAF에서 WebACL로 테스트용 네덜란드 소스 ip 막이 json룰을 작성해보자/

{
  "Name": "NL-acl",
  "Priority": 0,
  "Statement": {
    "GeoMatchStatement": {
      "CountryCodes": [
        "NL"
      ]
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "NL-acl"
  }
}

 

2. vpn 네덜란드 키고 접속

 

3. 잘만 접속되던 웹페이지가 403 error

그리고 아래 영어 읽어보면 cloudfront 단에서 메세지를 보낸 것을 알 수 있다.

주소창 자물쇠 보면 알겠지만 https로 접속했다.

WAF cloudwatch를 보면 다음과 같이 WAF 생성 직후 접속 잘되던 리퀘스트가 블록된 57건이 보인다.

 

이렇게 https 접속을 했는데도 cloudfront에 부착된 WAF가 잘 작동한다.

ACM이 들어있어서 클라우드 프론트단에서 암호가 풀어졌던것.