AWS WAF를 통한 보안 위협과 대응 전략

인터넷 기반 웹 서비스는 다양한 보안 위협에 노출 되어 있습니다. 특히, DDoS 공격, SQL 인젝션, XSS, Bot 트래픽 등은 서비스의 가용성과 신뢰성을 저해할 수 있습니다.

이러한 위협에 대응하기 위해 AWS에서는 AWS WAF(Web Application Firewall)를 제공 하여, 애플리케이션 계층(Layer 7)의 공격을 효과적으로 차단할 수 있도록 지원합니다.

여기서는 보안 및 가용성과 신뢰성을 확보 하기 위해 웹서비스 아키텍처 및 AWS WAF를 통한 간단하면서도 효과적인 침해 대응 전략과 더불어, 운영 환경에서 대규모 업데이트를 위한 공사중 페이지를 활용하는 팁도 살펴보겠습니다.

WAF 와 통합 가능한 서비스

AWS WAF(Web Application Firewall)는 아래와 같이 보안이 필요한 AWS 서비스와 통합할 수 있습니다.

웹서비스 아키텍처 모범 사례

AWS 클라우드에서 웹 서비스 제공을 위해 보안이 강화 되고 간단한 아키텍처로 WEB UI 는 CloudFront로 배포 하고 Backend API는 ALB (Application Load Balancer) 또는 API Gateway + NLB(Network Load Balancer) 와 통합 하는 방식을 권고합니다.

Application Load Balancer (ALB) 보안 그룹 방어 전략

위 아키텍처는 ALB (Application Load Balancer) 의 보안 그룹을 통해 CloudFront 의 요청만 허용하고 다른 어떤 요청도 거부할 수 있습니다.

특히 AWS를 이용하는 고객은 ALB 를 위한 보안 그룹에 AWS가 제공하는 CloudFront 에 대한 Managed Prefix List 를 사용 하여 아주 쉽게 방어 할 수 있습니다.

VPC Managed prefix lists 목록에서 global.cloudfront.origin-facing 로 검색하면 확인 할 수 있습니다.

WAF + Application Load Balancer (ALB)를 통합한 아키텍처

위의 ALB 보안 그룹 방어 전략은 Hacker 의 공격이 보안 그룹에 의해 차단 되지만, 문제는 해커의 공격 트래픽이 Backend ALB 영역 까지 도달 하게 된다는 것 입니다.

이렇게 되면 해커는 DDoS 공격을 통해 서비스 환경에 직접 적인 피해를 가할 수 있으므로, 이 것 역시 방어할 수 있는 아키텍처가 필요합니다.

아래 다이어그램은 ALB 와 WAF Reginal 를 통합한 아키텍처 입니다.

여기서는, AWS 클라우드가 제공하는 관리형 WAF 방화벽을 Backend 서비스 레이어 앞쪽에 배치함으로써 대부분의 침입자 공격을 차단할 수 있습니다.

CloudFront HTTP 헤더를 이용한 WAF 방화벽 전략

CloudFront액세스만 허용하도록 WAF 방화벽 규칙을 구성하려면 먼저, CloudFront를 특정할 수 있어야 합니다.

CloudFront의 Behavior 설정 중 Cache policy and origin request policy 정책 에서 AllViewerAndCloudFrontHeaders를 설정 하면 CloudFront에 의해 제공 되는 모든 요청은 Geo-Location 정보가 아래와 같이 HTTP 헤더로 제공됩니다.

• Cache policy and origin request policy 정책 설정 화면 예시
  

• cloudfront-geolocation-headers 샘플

{
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36',
  'x-amz-cf-id': 'R14kBawplRj6Xk98UVmNry1HNwde-M76F3TkdoeWcbKUZpnw6QHc2A==',
  'x-forwarded-for': '222.0.0.106, 165.0.0.9',
  'via': '1.1 0859cbbec76cd864e788367b8aaae34a.cloudfront.net (CloudFront)',
  'accept-encoding': 'br,gzip',
  'cloudfront-viewer-country': 'KR',
  'cloudfront-viewer-country-name': 'South Korea',
  'cloudfront-viewer-country-region': '11',
  'cloudfront-viewer-country-region-name': 'Seoul',
  'cloudfront-viewer-city': 'Seoul',
  'cloudfront-viewer-postal-code': '04****',
  'cloudfront-viewer-time-zone': 'Asia/Seoul',
  'cloudfront-viewer-latitude': 'x7.50030',
  'cloudfront-viewer-longitude': '1**.95650',
  ....
}

CloudFront 헤더 정보 중 Geo-Location 중 하나인 cloudfront-viewer-country 값이 KR, US 인 항목만 허용 하도록 WAF 방화벽을 아래와 같이 구성할 수 있습니다.

• AllowKRAndUSCloudFrontViewerCountry Rule-Group 설정 참고

{
  "Name": "AllowKRAndUSCloudFrontViewerCountry",
  "Priority": 10,
  "Action": {
    "Allow": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "AllowKRAndUSCloudFront-Country-metric"
  },
  "Statement": {
    "OrStatement": {
      "Statements": [
        {
          "ByteMatchStatement": {
            "SearchString": "KR",
            "FieldToMatch": {
              "SingleHeader": {
                "Name": "cloudfront-viewer-country"
              }
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "LOWERCASE"
              }
            ],
            "PositionalConstraint": "EXACTLY"
          }
        },
        {
          "ByteMatchStatement": {
            "SearchString": "US",
            "FieldToMatch": {
              "SingleHeader": {
                "Name": "cloudfront-viewer-country"
              }
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "LOWERCASE"
              }
            ],
            "PositionalConstraint": "EXACTLY"
          }
        }
      ]
    }
  }
}

위의 WAF Rule-Group 동작은 아래 CloudWatch Logs Insights 쿼리를 통해 확인을 할 수 있습니다.

fields @timestamp, @message
| parse @message '{"name":"CloudFront-Viewer-Country","value":"*"}' as geoloc
| filter geoloc = 'KR'
| sort @timestamp desc
| limit 20

WAF IPSet을 규칙을 통한 방어 전략

경험 많은 해커의 경우 HTTP 헤더를 변조 하여 WAF 방화벽을 무력화 할 수 있습니다.

심지어 해커의 Device IP Address 를 CloudFornt의 IP 로 변조한 공격도 가능합니다.

하지만, 해커의 IP 주소를 변조 공격이 WAF를 통과했다 하더라도 TCP 프로토콜 규격상 SYN-ACK는 결국 CloudFront IP로 응답하기에 Hacker 로 전달 되지 않기 때문에 안전 하게 공격이 차단 됩니다.

AWS는 주요 서비스에 대해 VPC Managed prefix list의 global.cloudfront.origin-facing 뿐만 아니라, aws-ip-ranges 를 통해 CloudFront 의 Edge Location 에 대한 IP 정보도 API 를 통해 제공 하고 있습니다.

아래 ip-ranges.json CLOUDFRONT 서비스에서 region 속성이 GLOBAL과 ap-south-1와 같이 해당 리전의 Edge Location 에 관한 CIDR 를 확인할 수 있습니다.

curl -O https://ip-ranges.amazonaws.com/ip-ranges.json 

우리는 아래 화면과 같이 WAF & Shield 의 IP sets 을 통해 Global 및 Regional 에 대한 CloudFront IP 를 구성할 수 있습니다.

• cloudfront-ipsets WAF Rule 예시

WAF IP Sets 으로 관리 되는 cloudfront-ipsets 의 ARN 값이 arn:aws:wafv2:us-east-1:111122223333:regional/ipset/cloudfront-ipsets/a5a6 이라면 아래와 같이 WAF Rule Group 을 생성할 수 있습니다.

• cloudfront-rule-group Rule Group 예시

{
  "Name": "cloudfront-ipsets-rule",
  "Priority": 11,
  "Action": {
    "Allow": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "cloudfront-ipsets-metric"
  },
  "Statement": {
    "IPSetReferenceStatement": {
      "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/ipset/cloudfront-ipsets/a5a6"
    }
  }
}

WAF 를 활용한 공사중 페이지 전략

대규모 서비스 업데이트와 같이 휴일을 이용하여 장시간 서비스 절체 후 작업을 해야 하느 경우 공사중 페이지를 로드 하고 작업 해야 하는 경우가 있습니다.

이를 위해 Route53 도메인 부터 ALB 라우팅 등 프로덕션 환경을 대상 으로 여러 리소스를 수정 하는 것은 운영 환경에 변경이 일어 나는 위험한 작업일 뿐만아니라, 몇몇 리소스의 설정을 변경해야 하는 부담스러운 작업이 됩니다.

하지만 WAF를 활용 하여 maintenance-rule 과 같은 단순한 규칙 으로 아주 쉽고 안전 하게 공사중 페이지를 작업할 수 있습니다.

또한, 내부 개발팀의 IP 들은 작업을 위해 WAF 에 위해 차단 되지 않도록 IP sets deny-not-included-ipsets 정책으로 예외 처리를 할 수 있습니다.

공사중 페이지를 위한 maintenance-rule WAF Rule

maintenance-rule Rule Group 을 아래와 같이 deny-not-included-ipsets 에 포함된 IP 가 아니 라면 차단(Block) 하도록 규칙을 생성 하고, 그 이외의 모든 클라이언트의 Action은 maintenance-html 키에 대한 CustomResponse HTML 컨텐츠를 응답하도록 구현할 수 있습니다.

• arn:aws:wafv2:us-east-1:111122223333:regional/ipset/deny-not-included-ipsets/0e3a**** IP sets 엔 개발팀 네트워크에 대한 IP 대역이 등록되어 있어야 합니다.

• Custom response bodies 의 key maintenance-html 엔 공사중 페이지를 렌더링 할 Html 컨텐츠가 구성 됩니다.

• maintenance-rule Rule Group 예제

{
  "Name": "maintenance-rule",
  "Priority": 1,
  "Statement": {
    "NotStatement": {
      "Statement": {
        "IPSetReferenceStatement": {
          "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/ipset/deny-not-included-ipsets/0e3a****"
        }
      }
    }
  },
  "Action": {
    "Block": {
      "CustomResponse": {
        "ResponseCode": 503,
        "CustomResponseBodyKey": "maintenance-html"
      }
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "maintenance-rule-metric"
  }
}

• maintenance-html 구성 예시

maintenance-rule Rule Group 에 Custom response bodies 를 통해 아래와 같이 공사중 페이지를 생성 할 수 있습니다.

참고로 html 항목은 최대 4 K bytes 로 제한 됩니다.

WAF Web ACL 정책 적용 예시

아래 그림은 AWS 관리형 WAF 규칙 과 고객 서비스를 위한 커스텀 규칙을 조합한 예시 입니다.

AWS 관리형 WAF 규칙을 적용하는 것 만으로 상당히 많은 공격으로부터 방어를 할 수 있으므로 제공 서비스 환경에 Count로 모니터링 하며 가능 하면 많은 규칙을 Block 으로 설정 하길 권고합니다.

여기서는 maintenance-rule-group와 같은 그룹 규칙은 공사중 페이지로 필요한 경우에만 추가 하고, 작업이 완료 되면 쉽게 제거 하여 원래의 방화벽 규칙으로 빠르게 복원 할 수 있습니다.

그리고 하단의 front-rule-group그룹 규칙은 Allow 및 Block 정책을 Host 이름 패턴, 개발팀 Office IP 대역, CloudFront 소스 대역 등 사용자 커스텀 특화된 규칙으로 설정 합니다.

Conclude

AWS WAF를 핵심 방어 수단으로 삼아, 간단하면서도 효과적인 웹서비스 보안 아키텍처와 운영 전략을 살펴보았습니다.

여러분의 AWS 클라우드 환경에서, 여기서 소개한 아키텍처와 WAF를 적용함으로써 서비스의 가용성 및 신뢰성을 확보하고, 대규모 유지보수 시에도 안전하게 운영을 이어갈 수 있기를 희망 합니다.