웹 공격, 특히 DDoS 대응으로 방화벽을 설치하라고 한다. (난 안전불감증으로, WAF 설치의 필요성은 못느끼고 있다.)

AWS 에서는 WAF 라는 웹 어플리케이션 방화벽 서비스를 제공한다. 고급 사양으로는 DDoS 방어에 특화된 AWS Shield, 여러 계정/리소스 관리를 간소화 하는 AWS Firewall Manager 가 있지만 생략한다. (여유자금 있으면 쓰면됨)

십수 년 전 suhosin 사용했을 때도 그렇지만, 설정을 빡세게 할수록 방화벽의 기능을 십분 활용할 수 있지만, 그렇게까지 할 필요가 있나 싶다. 공격을 완벽하게 막기란 쉽지 않고, 까딱 잘못하면 정상적인 요청마저 거부할 수도 있고, 슬프지만 내가 개발한 서비스가 누군가의 타겟이 될 정도로 인기 있지도 않기 때문이다. 참고로 20년 동안 방화벽에 대한 필요성을 느낀 적이 단 한번도 없었다. 그래도 방화벽을 달아야 하는 상황이라 아주 기본적인 설정만 해보려고 한다.

WAF 는 기본적으로, AWS 리소스 일부를 보호할 수 있으며, HTTP(S) 요청에 대한 IP / 국가 / 헤더 / 요청횟수 등으로 접근 허용이나 거부를 할 수 있다. (SQL Injection / XSS 생략) 프론트 단의 CloudFront 와 백엔드의 API 서버 중 alb 에만 방화벽을 설치해 보았다. 가장 기본적인 규칙들만 몇 개 적용하고 Bot Control / Capcha 등은 사용하지 않았다.

1. 서버 접근 패턴 파악

우선은 방어 전략을 짜기 전에, 해당 서버에 로그를 수집하여 패턴을 파악해 봐야 한다. 물론 처음부터 빡세게 제한하는 것도 좋지만, 이미 운영중일 경우는 기존 서비스에 장애가 발생하지 않도록 면밀히 분석해야 한다.

다행스럽게도 서버 대부분은 해외IP 로부터 SQL Injection / XSS 접근이 전부여서 Source IP 가 해외인 접근만 차단하는 것으로 완벽 차단이 가능했다. 사실 그것보다는 DDoS 공격에 대비하는 것이 목표라, 해외IP 차단 + 국내IP 에서 초당 100개 요청시 IP 차단 하는 Rule 로 처리하기로 했다.  

2. Rule 세팅 및 리소스 적용

• Rule : 제어 규칙 생성
• Rule Group : 재사용 가능한 사용자 정의 Rule Group 을 생성할 수 있고, AWS Marketplace 에서 유/무료 관리형 규칙 그룹을 선택할 수도 있다. (규칙 수, 복잡도에 따라 요금 증가)
• Web ACL(제어목록) : 특정 규칙집합을 만들고 AWS 리소스를 연결하여 요청 제어 수행
  ㄴ 기본동작 (Allow / Block) 설정
  ㄴ 규칙 우선순위는 화면 위에서 아래, 낮은 숫자에서 높은 숫자 순

3. 모니터링 및 알람 설정

모니터링으로 요청에 대한 규칙 및 필터링 확인을 마쳤다면, CloudWatch 에서 특정 메트릭(예: 차단된 요청 수 - BlockedRequests)이 기준치를 초과할 때 SNS 알림을 트리거하도록 설정하여 운영하도록 한다. (알람 세팅 생략...)

4. 요금

(예, 관리형 규칙X, 사용자 규칙 19)

• 웹 ACL 요금 = 5.00 USD * 1 = 5.00 USD
• 규칙 요금 = 1.00 USD * 19(규칙) = 19.00 USD
• 요청 요금 = 1백만 건당 0.60 USD * 1천만 건 = 6.00 USD
• 결합된 총 요금 = 월별 30.00 USD

슬랙의 알림 설정이 누군가에게는 참 성가시다. 누구는 알림이 왔다그러고 누구는 안왔다그러고...

설정의 알림 항목을 보면 알겠지만 조금 디테일 하긴 하다. 

근데 문제는 PC에서 제대로 알림 설정을 했음에도 불구하고 알림이 오지 않을 때...

그럴때의 해결책을 [File]-[Preferences]-[Notifications] 에서 발견했다.

 Looks like there might be an issue with your notifications 

저 경고가 고정으로 박혀 있는 것인줄 알았는데,

현재의 내 시스템을 체크하고 안내하는 것이다.

하면... 바로 슬랙 알림을 받을 수 있다.

위 그림의 [Show an Example] 을 클릭하여 즉시 테스트 해 볼 수 있다.

간단하게 작업표시줄 가장 우측의 [알림 센터] 에서도 쉽게 설정이 가능하다.

집중 지원의 [자동 규칙] 에 따라 집중 지원이 자동으로 켜질 수 있으니 자동 규칙도 확인해 보는 것이 좋다.

아마도 슬랙 뿐 아니라 알림에 관련된 모든 앱들에 적용될 것이다.

ECS 를 사용하면 인스턴스에 docker / ecs / container 등에 대한 로그가 생성된다. CloudWatch Logs 로 로그 정보를 전송하면 컨테이너의 로그 용량 관리를 하지 않아도 된다. 인스턴스에서 CloudWatch Logs 에 로그 정보를 전송하도록 구성할 수도 있지만, 인스턴스 수 조정이 빈번하다면 해당 에이전트를 계속해서 설치하고 구성하는 것이 번거로울 수 있다. 이 경우에는 ECS 의 Task 정의에서 awslogs 로그 드라이버를 활성화하여 CloudWatch Logs 를 설정하는 방법이 있다.

Awslogs 설정

CloudWatch Logs 에 로그를 쌓기 위해서는 로그가 분류될 로그 그룹을 만들어야 한다. CloudWatch 콘솔이나 AWS CLI 를 사용하던지 간편하게 ECS 콘솔의 Task 정의에서 로그 그룹을 생성한다. [Task define] - [Container] - [Storage And Logging] - [Auto-configure CloudWatch Logs] 체크. 이렇게 awslogs 로그를 활성화 하면 해당 컨테이너의 로그 설정들이 자동으로 세팅되며, 추가로 옵션을 사용할 수 있다.

해당 Task 정의를 배포하고 나면 CloudWatch Logs 에서 해당 컨테이너의 로그들을 확인할 수 있다.

CPU / Memory 초과 알림

Amazon ECS 는 서비스의 평균 CPU 및 메모리 사용량과 함께 CloudWatch 지표(Metrics) 를 게시하며, 이 지표를 사용하여 알람을 추가할 수 있다. 우선 SNS(Simple Notification Service) 에 해당 알림 전용으로 메일 받을 Topic 을 하나 생성한다. [CloudWatch] - [Alarms] 에서 알람을 생성하고 ECS-Metrics 에서 CPU 나 Memory 의 상한선을 설정한 후, [Send notification to:] 에 알림 받을 Topic 을 선택하면 CPU 나 Memory 가 상한선을 초과할 경우 알림을 수신할 수 있다.

Task 중단시 메일 알림

Task 가 중단 됐을 때 알림을 받기 위해 CloudWatch 이벤트에 Rule 을 설정할 수도 있다.

[CloudWatch] - [Events] - [Rules] 에서 Rule 을 하나 생성하고, [Event Pattern Preview] 항목에 [Edit] 를 클릭하여 다음 코드를 입력한다.

마찬가지로 알림을 받을 수 있도록 Rule 의 Target 에 생성해 놓은 Topic 을 연결한다.

이제 ECS 의 api/web 클러스터의 Task 상태가 essential 컨테이너로부터 중단되어 STOPPED 로 변경되면 알림을 수신할 수 있다.

stoppedReason 을 작성하지 않으면 Task 가 STOPPED 로 변경될 때마다 알림을 수신할 수 있으며, 위 중단 이유를 제외하고도 특정 stoppedReason 을 지정할 수 있다.