Route53에 호스팅 영역은 이미 등록되었고, ALB는 이미 생성된 상태라고 가정하고 설명을 할 예정이다. (ALB는 EC2든, ECS든, EKS든 어떤 형태여도 무관하니 프로젝트의 성격에 알맞게 알아서 생성하길 바란다) 필자의 경우는 웹 애플리케이션을 EKS에 올렸다.
Route53 등록 방법은 아래의 글을 참고하길 바란다.
https://vegetableworld.tistory.com/168
[05.21] AWS route53, S3, Cloudfront, ACM
vegetableworld.tistory.com
우리는 다음과 같은 순서로 서비스를 구축할 것이다.
- ACM 인증서 생성
- CloudFront를 활용한 CDN 구축
- Route53 레코드 생성
- WAF 구축
ACM 인증서 생성
CloudFront에서 ACM 인증서를 사용하려면 미국 동부(버지니아 북부) 리전(us-east-1)에서 인증서를 요청하거나 가져와야 한다. 따라서, 버지니아 북부 리전으로 이동하여 ACM 인증서를 생성하자.
ACM 콘솔창으로 들어가 인증서 탭에서 '요청' 버튼을 누른다
'퍼블릭 인증서 요청'이 선택돼있는 것을 확인 후, '다음' 버튼을 누른다.
Route53의 호스팅 영역에 등록된 도메인 이름을 적는다.
나머지 설정은 그대로 두고, '요청' 버튼을 누르자.
인증서가 잘 발급된 모습을 확인할 수 있다. 인증서 ID를 클릭해 편집창으로 들어가자.
이대로라면 인증서가 발급되지 않는다. 인증서의 승인을 위해서 '도메인' 탭에서 'Route 53에서 레코드 생성' 버튼을 눌러 레코드를 생성하자.
생성을 완료했다면 인증서가 잘 발급되었음을 확인할 수 있다.
CloudFront를 활용한 CDN 구축
CloudFront 콘솔창에서 '배포' 탭의 '배포 생성' 버튼을 누르자.
Origin domain은 본인이 이전에 생성해놓은 ALB의 DNS주소를 찾아 선택한다.
프로토콜은 ALB를 통해 서비스가 제공되고 있는 포트번호를 적어준다. 필자는 80번이기 때문에 'HTTP만 해당' 을 선택해줬다.
쭉 내려가서 '설정' 탭의 '항목 추가' 버튼을 누르자.
여기에 나중에 추가할 DNS 레코드명을 적어준다.
SSL 인증서는 아까 버지니아 북부에서 생성한 인증서를 선택해준다.
나머지 설정은 그대로 두고 '배포 생성' 버튼을 누르자.
CloudFront 배포가 잘 생성되었음을 확인할 수 있다. ID를 눌러 세부정보를 확인해보자.
'배포 도메인 이름' 이 명시되어 있다. 잘 접속되는지 확인해보자. (인증서를 추가했으니 https로 접속하자!!)
접속이 잘 된다. 하지만, 대체 도메인으로는 접속이 안될 것이다. Route 53에서 레코드를 생성하지 않아서 그렇다.
Route 53 레코드 생성
레코드를 생성하기 위해 Route 53 콘솔창으로 넘어가자. 사전에 말했듯이 호스팅 영역은 이미 생성이 되어있어야 하고, 도메인 소유자에게 네임서버 등록까지 마친 상태여야 한다. 필자는 foodsketch.store 라는 이름으로 호스팅 영역을 생성했다.
'foodsketch.store'를 클릭하여 세부정보창으로 들어가자.
'레코드 생성' 버튼을 누르자.
'별칭' 토글을 활성화 시키고, '트래픽 라우팅 대상'을 'CloudFront 배포에 대한 별칭'으로 선택해준다.
그리고 위에서 생성했던 CloudFront 배포 도메인을 선택한다.
설정을 마쳤다면, '레코드 생성' 버튼을 누르자.
성공적으로 레코드가 생성되었음을 확인할 수 있다.
이제 CloudFront의 대체도메인으로 접속해보자!
잘 접속됨을 확인할 수 있다.
WAF 구축
WAF 콘솔창으로 넘어가 'Create web ACL'을 클릭하자.
CloudFront 배포에 WAF기능을 붙일 계획이므로 Resource type은 'Amazon CloudFront distributions'를 선택한다.
그리고 web ACL의 이름을 붙여준다.
'Add AWS resources' 버튼을 클릭하고
이전에 생성해놓은 CloudFront 배포를 선택해준다.
나머지 설정은 그대로 두고 'Next' 버튼을 누른다.
웹 서비스에 발생하는 공격 패턴을 필터링하고 제어할 규칙을 추가해야 한다. 'Add managed rule groups' 버튼을 클릭하자.
AWS managed rule groups에는 어떤 서비스가 있는지 살펴보자.
1. Account Creation Fraud Prevention
이 서비스는 웹사이트에서 사기성 계정 생성을 방지하는 데 도움을 준다. 사기성 계정은 가입 보너스를 얻거나 합법적인 사용자를 가장하는 등의 악의적인 활동에 사용될 수 있다. 이 규칙은 사용자가 계정을 생성할 때 비정상적인 패턴이나 의심스러운 행동을 감지하여, 이러한 계정 생성을 차단하거나 경고를 제공한다.
2. Account Takeover Prevention
이 서비스는 로그인 페이지를 보호하여 도난된 자격 증명, 자격 증명 스터핑 공격, 무차별 대입 로그인 시도 및 기타 비정상적인 로그인 활동으로부터 보호한다. 계정 탈취 방지 기능을 통해 무단 접근을 방지하고, 이를 통해 발생할 수 있는 사기 활동을 예방할 수 있다. 또한, 합법적인 사용자에게 예방 조치를 취하도록 알릴 수 있는 기능도 제공한다.
3. Bot Control
이 서비스는 자동화된 봇으로부터 보호하여, 과도한 리소스를 소모하거나 비즈니스 메트릭을 왜곡하고, 다운타임을 초래하거나 악의적인 활동을 수행하는 것을 방지한다. Bot Control은 Amazon CloudWatch를 통해 추가적인 가시성을 제공하며, 애플리케이션으로의 봇 트래픽을 제어하는 데 사용할 수 있는 레이블을 생성한다. 이 규칙 그룹을 웹 ACL에 추가할 때는 두 가지 보호 수준 중 하나를 선택할 수 있으며, 필요에 따라 언제든지 변경할 수 있다. 모바일 또는 비브라우저 트래픽이 예상되는 경우, Bot Control 구현에 예외를 추가하여 해당 트래픽이 통과할 수 있도록 설정할 수 있다.
이러한 서비스들은 웹 애플리케이션의 보안을 강화하고, 사용자 경험을 개선하는 데 중요한 역할을 한다.
위 설명을 읽고 서비스의 특성에 맞게 필요한 사람들은 룰을 추가하도록 하자! 필자는 돈이 나가는게 싫어서 추가하지 않았다. (ㅎㅎ)
다음은 Free rule groups를 확인해보자.
Free rule groups의 경우 5000 WCUs(Capacity)를 넘어갈 수 없으며, 1500 WCUs가 넘어가면 비용이 든다.
예산과 애플리케이션의 상황에 맞게 룰을 추가하자. 필자는 위와 같이 추가하였다.
아래는 Web ACL Free Rule에 대한 설명이다.
Web ACL Free Rule
1. Admin Protection
설명: 외부 접근을 차단하여 노출된 관리자 페이지를 보호하는 규칙입니다.
사용 상황: 서드파티 소프트웨어를 운영하거나 관리 접근을 악의적인 행위자로부터 보호하고자 할 때 유용합니다.
2. Amazon IP Reputation List
설명: Amazon의 위협 인텔리전스를 기반으로 한 규칙으로, 봇이나 기타 위협과 관련된 출처를 차단합니다.
사용 상황: 자동화된 공격이나 봇 트래픽을 차단하고자 할 때 사용합니다.
3. Anonymous IP List
설명: 사용자 신원을 숨기는 서비스를 통해 발생한 요청을 차단하는 규칙입니다. VPN, 프록시, Tor 노드 등이 포함됩니다.
사용 상황: 사용자 신원을 숨기려는 시도를 차단하고자 할 때 유용합니다.
4. Core Rule Set
설명: 웹 애플리케이션에 일반적으로 적용 가능한 규칙으로, OWASP에서 설명한 다양한 취약점으로부터 보호합니다.
사용 상황: 웹 애플리케이션의 전반적인 보안을 강화하고자 할 때 사용합니다.
5. Known Bad Inputs
설명: 악용 가능성이 있는 잘못된 요청 패턴을 차단하는 규칙입니다.
사용 상황: 애플리케이션의 취약점을 발견할 가능성을 줄이기 위해 사용합니다.
6. Linux Operating System
설명: Linux에 특화된 취약점, 예를 들어 LFI(로컬 파일 포함) 공격과 관련된 요청 패턴을 차단합니다.
사용 상황: Linux 기반 애플리케이션에서 보안을 강화하고자 할 때 유용합니다.
7. PHP Application
설명: PHP에서의 취약점, 특히 안전하지 않은 PHP 함수의 주입과 관련된 요청을 차단합니다.
사용 상황: PHP 기반 애플리케이션의 보안을 강화하고자 할 때 사용합니다.
8. POSIX Operating System
설명: POSIX 기반 운영 체제에서의 취약점과 관련된 요청 패턴을 차단합니다.
사용 상황: POSIX 시스템에서 보안을 강화하
고자 할 때 유용합니다.
9. SQL Database
설명: SQL 데이터베이스에 대한 SQL 인젝션 공격과 관련된 요청 패턴을 차단합니다.
사용 상황: SQL 데이터베이스를 사용하는 애플리케이션의 보안을 강화하고자 할 때 사용합니다.
10. Windows Operating System
설명: Windows 운영 체제의 취약점과 관련된 요청 패턴, 예를 들어 PowerShell 명령을 차단합니다.
사용 상황: Windows 기반 애플리케이션의 보안을 강화하고자 할 때 유용합니다.
11. WordPress Application
설명: WordPress 사이트의 취약점과 관련된 요청 패턴을 차단합니다.
사용 상황: WordPress 애플리케이션의 보안을 강화하고자 할 때 사용합니다.
나머지 룰도 확인해보고 필요한 룰이 있다면 추가하자!
Default action가 'Allow'에 체크되어 있는 것을 확인한 후, 'Next' 버튼을 누른다.
룰의 우선순위를 설정하는 편집창이다. 적절히 우선순위를 정하고, 'Next' 버튼을 누르자.
CloudWatch에 로그를 수집할 것인지에 대한 편집창이다. 설정을 마치고 'Next' 버튼을 누르자.
설정에 대한 검토를 마친 후, 'Create web ACL' 버튼을 클릭하자.
Web ACL이 잘 생성되었음을 확인할 수 있다.
이제 테스트를 해보도록 하자. 필자가 추가해놓은 룰 중에, AWSManagedRulesAnonymousIpList라는 룰이 있었다.
이 룰은 사용자 신원을 숨기는 서비스를 통해 발생한 요청을 차단하는 규칙이다. VPN, 프록시, Tor 노드 등이 포함된다.
모바일로 VPN을 켜놓고, 웹사이트에 접속해보자.
요청을 정상적으로 차단하고 있는 모습을 확인할 수 있다.
다음으로, 국가 기반의 IP를 차단하는 방법을 알아보자.
WAF 콘솔창에서 아까 생성한 Web ACL에 들어가서, 'Rules' 탭의 'Add rules'를 클릭하자.
우리는 직접 룰을 정의할 것이기 때문에 'Add my own rules and rule groups'를 클릭하자.
Rule type는 'Rule builder'를 클릭하고, 룰 Name을 적어준다.
'Inspect'에서 'Originates from a country in' 을 선택하자.
그럼 아래와 같이 Country codes가 뜬다. 여기서 차단하고 싶은 국가를 선택하면 된다!
필자는 아래와 같이 중국과 영국, 미국을 선택했다.
Action에서는 어떠한 조치를 취할지 선택할 수 있다.
- Allow (허용):
- 요청이 규칙에 일치할 경우 해당 요청을 허용합니다. 즉, 요청이 웹 애플리케이션으로 전달되어 정상적으로 처리됩니다.
- Block (차단):
- 요청이 규칙에 일치할 경우 해당 요청을 차단합니다. 이 경우 사용자는 웹 애플리케이션에 접근할 수 없으며, 차단된 요청에 대한 오류 메시지를 받을 수 있습니다.
- Count (계수):
- 요청이 규칙에 일치할 경우 요청을 차단하지 않고, 단순히 요청 수를 기록합니다. 이 옵션은 특정 요청 패턴이나 트래픽을 모니터링할 때 유용하며, 실제로 요청을 차단하기 전에 트래픽을 분석할 수 있습니다.
- CAPTCHA customize (사용자 정의 CAPTCHA):
- 요청이 규칙에 일치할 경우 사용자가 CAPTCHA를 해결해야만 요청이 진행됩니다. 이는 봇이나 자동화된 스크립트를 차단하는 데 효과적이며, 정상 사용자는 CAPTCHA를 통과하면 접근할 수 있습니다.
- Challenge (도전):
- 요청이 규칙에 일치할 경우, 사용자가 추가적인 검증을 통과해야만 요청이 허용됩니다. CAPTCHA와 유사하지만, 다양한 검증 방법을 사용할 수 있습니다. 사용자가 요청을 계속하기 위해 특정 조건을 충족해야 합니다.
필자는 이번에 CAPTCHA 기능을 선택했다. 나머지는 그대로 두고, 'Add rules' 를 클릭하자.
테스트를 위해 방금 생성한 rule을 가장 우선순위로 올려주자.
그럼, 중국이나 미국, 영국에서 누군가가 접속하면 아래와 같이 CAPTCHA 인증이 뜨게 될 것이다.
이로써, 봇이나 자동화된 스크립트를 차단할 수 있게 되었다!!
