[Project] Route53 + CloudFrond + WAF 엣지서비스

AWS 의 Global한 부분 엣지서비스

 

 

Route 53

Route 53는DNS, 도메인이름등록및상태확인을제공합니다. Route 53는 개발자와기업이안정적이고비용효율적인방식으로최종사용자를인터넷 애플리케이션에라우팅한다.

 

Route 53은사용자요청을Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, Elastic Load Balancing(ELB) 로드밸런서또는Amazon Simple Storage Service(Amazon S3) 버킷처럼AWS에서실행되는인프라에효과적으로연결하며, 사용자를AWS 외부의인프라로라우팅하는데에도사용할수있다.

 

Amazon CloudWatch 경보를구성하여엔드포인트상태를확인할수있습니다. DNS를상태확인지표와결합하여정상엔드포인트를모니터링하고해당 엔드포인트로트래픽을라우팅한다.

 

Route 53 상태확인은웹애플리케이션, 웹서버및기타리소스의상태와성능을 모니터링해서 장애나면 다른쪽으로 라우팅을 다 넘기는 것도 가능하다. 상태확인을생성하면 상태확인의상태를받고, 상태가변경될때알림을받으며, DNS 장애조치를구성할수있다.

 

지연시간 기반 라우팅도 가능하다. 애플리케이션이여러AWS 리전에서호스트된다면, 사용자들의요청을지연 시간이가장낮은AWS 리전에서처리함으로써최종사용자를위해성능을 향상시킬수있다. 지연시간은 AWS 센터와 사용자간의 트레픽에 기반한다.

 

이외에 다중값 응답 라우팅( 여러 DND값을 응답하는것), 가중치 기반 라우팅 (10%, 90%) 등도 가능

 

CloudFront

CDN 종류다.

정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 하는 웹 서비스 (정적인 캐싱에 유리)

접속 포인트를 하나로 모아줘서 ACL 할떄 여기서 오는 트레픽 빼고 다막아도 되는 보안상의 편리함

• 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠 제공
• S3의 데이터들을 사용자들에게 배포하는데 오래걸리고 비싸다?
  -> CloudFront 사용해서 배포

 

웹트래픽이지리적으로분산된경우전체인프라를전세계에복제하는것은 때때로불가능할수도있다.

또한비용효율적이지않다.

콘텐츠전송 네트워크(CDN)에서는웹콘텐츠의캐시된사본을고객에게제공하기위해 CDN을 쓴다.

응답시간을줄이기위해 CDN은고객또는발신요청위치에가장가까운엣지 로케이션을사용한다.

가장가까운엣지로케이션사용시에는웹자산이 캐시에서제공되므로처리량이크게증가한다.

동적데이터의경우, 다수의 CDN이오리진서버에서데이터를검색하도록구성할수있다.

 

요약 :동영상 콘텐츠 또는기타 웹자산의 전송을 가속화

지연시간 및 처리량을 위한 네트워크 계층 최적화와 함께 캐시 동작최적화

실시간 양방향 통신을 지원

CloudFront가 기본 제공하는 AWS Shield  및 AWS WAF와의 통합을 통해 DDoS 보호를 활용

 

 

AWS Shild

AWS Shield는AWS에서실행되는애플리케이션을보호하는관리형DDoS 보호 서비스다.

AWS Shield Standard에서는 흔히 발생하는 가장 일반적인 인프라(계층 3 및 4) 공격중

일부에 대한 보호기능을 제공한다.

이러한 공격에는 SYN/UDP flood 및 Reflection DDoS 공격이 포함된다.

 

SYN-ACK Reflection 공격 요약

​

​

공격자는 대표적인 TCP 웹 서버를 수집하고

소스 IP를 타깃 IP로 변주한 후

SYN 패킷을 정상 웹서버로 전송​한다.

​

따라서 정상 TCP 웹서버는 SYN에 대한 응답,

즉 SYN-ACK 패킷을 타깃 서버로 전송하게 되고

​

타깃 서버는 이 SYN-ACK 패킷을

비정상 패킷으로 감지해 RESET 패킷을 보냄.

​

이러한 방식으로 워크로드가 매우 빠른 속도로 발생하면

서버에는 과부하가 생기게 되어

결국에는 서버 장애로 이어지게 되는 것.

 

 

 

WAF

는 다른 게시글에서 다루었으니 생략

 

 

 

 

CloudFront 배포 구성

게이트웨이 앞단에 CloudFront 배포를 구성하여 CloudFront에서 제공하는 오리진 액세스 ID(OAI)를 통해 보호

 

 

 

0. 전제

 

목표 : 내가 만들고자 한 구성도를 한번 만들어봤다.

온프레미스쪽은 VMware에 CentOS 올리고 편의상 방화벽, SELINUX 끄고 인터넷이 되도록 네트워크 세팅 마친 상태다.

 

 

그리고 대충 아래와 같은 VPC가 만들어 져있는 것을 전제로 하겠다.

근데 그냥 디폴트 쓰고 그때 그때 필요한거 만들어도 지장 없을것 같다.

왜냐면 지금 하는 작업은 엣지서비스니까 vpc야 대충 구색만 맞춰놓으면 된다.

참고로 통신해야하니까 NAT게이트웨이들에 EIP 하나씩 붙여주었다.

 

나가는 트레픽은 아래와 같다.

 

 

 

 

1. CloudFront 생성

 

CloudFront Origin은 CloudFront 배포를 통해 전송되는 콘텐츠의 최종 오리진 버전의 위치를 정의

 

나같은 경우는 ALB랑 연결했다.

ALB는 대상 그룹에 있는 Auto Scaling 웹 서버에 대한 웹 트래픽을 받고 보낸다.

 

 

http랑 https 둘다 접속 서비스하면 좋으니까 둘다 체크하자.

 

 

기왕 오리진 쉴드기능 있으니 캐싱을 위해 써보자. 근데 추가요금나가니까 주의~~

 

CloudFront Origin Shield는 CloudFront 캐싱 인프라에 추가 계층을 추가하여 오리진의 로드를 최소화하고 가용성을 개선하며 운영 비용을 줄이는 데 도움이 됩니다. CloudFront Origin Shield를 활성화하면 다음과 같은 이점을 얻을 수 있습니다.

• 더 나은 캐시 적중률 – 오리진에 대한 모든 CloudFront 캐싱 계층의 모든 요청은 Origin Shield를 통과하므로 캐시 적중 가능성이 높아집니다.
• 오리진 로드 감소 – Origin Shield는 동시 요청 수를 줄이기 위해 동일한 개체에 대한 콘텐츠 요청을 통합합니다.
• 더 나은 네트워크 성능 – 오리진에 대한 지연 시간이 가장 짧은 AWS 리전에서 Origin Shield를 활성화하면 더 나은 네트워크 성능을 얻을 수 있습니다.

Origin Shield 사용 시 추가 요금이 발생합니다.

 

 

가급적 본인 쓸 리전만 고르는게 비용상 이득이라고 돼있어서

내 모든 리소스가 다 서울에 있기 때문에 아래처럼 아시아를 골랐더니 ALB를 인식 못한다.

위 짤대로 하지 말고  모든 엣지 로케이션에서 사용 고르자.

 

 

 

그리고 WAF를 넣어야하는데 아직 안만들어서 비우고 넘긴뒤 나중에 추가하겠다

 

 

 

 

 

2. WAF ACL 설정

 

WAF 연결 하기위해 WAF로 가서 하나 만들어주자.

 

만드는건 대충 아래글 5번 항목으로 틀 만들어놓고

https://raid-1.tistory.com/185

 

아래글 8번 항목으로 설정하면 될듯

https://raid-1.tistory.com/189

 

WAF 룰 틀 생성

저번과 다르게 클라우드프론트용으로 리소스 타입을 결정하면 된다.

(위에 입력하고 아래 리소스를 변경하면 윗쪽이 다 초기화되니 고생하지 말고 리소스타입부터 골라라)

원래 여기 리소스 부분에서 연결할 기물을 선택해야하는데

우리의 경우는 클라우드프론트에 WAF를 달 것이기 때문에 클라우드프론트를 선택해야 하나...

아직 만들어지지 않았다.

 

아니 클라우드프론트 만들때 WAF ACL 선택하라고하고

WAF ACL 만들땐 클라우드프론트 선택하라고하면 누가 용의 꼬리고 머리인지 모르겠다.

일단 WAF부터 만들고 클라우드 프론트엔 나중에 달아주도록 하자. 쫘좌좍 next를 누른다.

 

만들어진 ACL 룰 눌러서 들어간다. 거기에 룰 텝 눌러서 managed rule groups을 구색 맞추기용으로 넣어주자.

 

대충 무료 룰에서 이거 두개 선택해서 기본적인 공격을 막아본다.

Core rule set으로 XSS 공격을, SQL database로 SQL Injection을 막을 수 있다

 

 

 

 

3. Cloudfront에 WAF 달기

 

아까 만든 클라우드프론트 들어가서 WAF 부분 비어있는 저부분 편집 누른다.

 

 

아까 만든 WAF 골라준다.

 

 

 

굿

 

참고로 이전 WAF 게시글 참고하면 좀더 다양하게 설정하고 공격하고 방어해볼수 있다.

 

 

 

4. 각종 Cloudfront 기능 소개

 

Behaviors는 특정 콘텐츠를 제공할 오리진, 캐시에 있는 콘텐츠의 TTL(Time-To-Live), 다양한 헤더의 처리 방법 등 콘텐츠에 대한 요청이 있을 때 CloudFront 배포가 수행하는 작업을 정의한다.

한국어로는 동작이다.

 

 Error Pages  탭에는 요청된 콘텐츠로 인해 HTTP 4xx 또는 5xx 상태 코드가 발생할 때 사용자에게 반환될 오류 페이지가 자세히 설명되어 있다.

특정 오류 코드에 대한 사용자 지정 오류 페이지도 여기에서 구성할 수 있다.

 

 

 Geographic restrictions 탭에는 선택한 국가의 사용자가 콘텐츠에 액세스하지 못하도록 해야 하는 경우 설정.

 

 Invalidations 탭에는 객체 무효화에 대한 배포의 구성이 포함되어 있다.

무효화된 객체는 CloudFront 엣지 캐시에서 제거된다.

보다 빠르고 저렴한 방법은 버전 지정된 객체 또는 디렉터리 이름을 사용하는 것이다.

 

 

 

 

 

 

 

5. 트러블슈팅

 

Cloudfront 배포를 통한 내부 EC2 접근 테스트

 

 

 

어...뭘 설정 안한거지 일단 내용 확인해보면 오리진인 ALB단에서 연결이 실패된건데

 

일단 ALB의 DNS가 작동하는지 확인해보자

ALB의 DNS 로 접속하면

예전에 EC2 오토스케일링으로 올려둔 WORDPRESS 잘만 는데????

 

참고글

https://raid-1.tistory.com/181

 

 

 

해결 

 

 아니 왜그런지 이유는 모르겠는데 리소스 전부 서울에 만들었음에도 아시아 고르면 안되고

모든 엣지 로케이션 골라야한다.

 

 

 

 

6. 결과 확인

 

클라우드프론트의 DNS 주소로 접속하면 ALB가 받아서

내부 사설단의 오토스케일링 그룹의 워드프레스 서비스를 가져온다.

주소 뒤에 

/wp-login.php

를 붙여서 로그인 페이지에 들어가보자.

 

ALB DNS로 들어갔을 때는 아래와 같이 예쁘게 뜨던데, 클라우드프론트단을 지나면 좀 깨짐이 생긴다.

일단 만들었던 워드프레스 계정으로 로그인 하면

잘 들어가진다.

 

 

 

 

 

7. 고찰해볼 점

 

클라우드프론트 DNS 주소로 들어가서 로그인 하면

 

바로 ALB단 DNS가 노출되는데 이건 보안상 괜찮은가????????????

 

 

 

 

8. Route 53 설정 - 도메인 호스팅

 

우선 도메인을 관리/처리 해주는 route53의 기능상 도메인을 먼저 입력해본다.

도메인 주소를 따로 갖고 있지 않다면 ( DDNS라던지 DuckDNS 라던지 가비아같은데서 샀다던지)

(무료 도메인 제공해주는 서비스 많으니까 찾아보자)

여기서 구입할 수도 있다.

 

등록된 도메인 카테고리를 누르고 도메인 등록 버튼을 누른다.

도메인 이름 선택 페이지에서 입력창에 원하는 도메인을 입력하면 사용 가능한 도메인 항목들이 나온다.

com, net, org 와 같은 최상위 도메인은 흔한 이름과 조합 시 웬만해서는 사용할 수 없다고 나오고,

그 밑으로 aws 가 사용 가능한 도메인을 추천해준다.

 

도메인 등록 설정을 완료하면 며칠 이내에 등록한 이메일로 메일이 도착하는데 해당 메일을 확인하지 않으면 등록자가 유효하지 않은 도메인으로 인지하여 우리가 등록한 도메인을 중지(suspend) 시켜버리므로 주의.

 

 

 

Route 53에 다른곳에서 구입한 도메인 등록하기

 

호스팅 영역을 생성한다.

호스팅 영역이란 레코드의 컨테이너이며, 레코드에는 특정 도메인(예: example.com)과 그 하위 도메인(acme.example.com, zenith.example.com)의 트래픽을 라우팅하는 방식에 대한 레코드들의 정보를 모아놓은 곳이다.

 

호스팅 영역의 유형은 두 가지가 있다.

• 퍼블릭 호스팅 영역은 인터넷에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함한다.
  한마디로 우리가 브라우저에 도메인으로 접속해서 사용하는 일반적인 도메인을 말하는 것이다.
• 프라이빗 호스팅 영역은 Amazon VPC에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함한다.
  Route 53을 이용하여 지정한 VPC에서 요청한 DNS 쿼리 응답을 반환하는 일종의 컨테이너라고 보며 된다.
  한마디로 VPC 내 AWS 서비스들의 사설 IP대신 도메인으로 이용하고자 할때 사용하는 영역이다.

 

갖고있는 도메인을 넣어줄건데,

나같은 경우는 예전 포스팅에 가비아에서 구입한 도메인을 네이버 클라우드 서버에 붙이는 포스팅 했을때 구입했다.

 

 

 

 

9. NameServer 등록하기

생성된 호스팅 영역에는 다음과 같이 NS와 SOA 가 자동으로 생성되어 있다.

 

NS
네임서버 레코드로 도메인에 대한 네임서버의 권한을 가지고 있는지 알려주는 레코드
예를 들어 naver.com의 NS레코드는 e-ns.naver.com, ns1.naver.com, ns2.naver.com 이다.

SOA
도메인의 정보를 가지고 있는 레코드.
naver의 경우 ns1.naver.com webmaster.naver.com 2021012809 21600 1800 1209600 180 이렇게 보여주고 있는데,
각각 마스터 네임서버, 존 관리자 연락처, 존 데이터 동기화 시간, 갱신주기, 시도, 만료 등 정보를 나타내고 있다.

 

여기서 NS에 해당하는 도메인의 Value 값 4개를 도메인을 구입하거나 발급받은 사이트 설정에 넣어준다.

NameServer의 경우, 호스팅업체의 네임서버를 사용해도 되지만 특별하지 않으면 AWS 네임서버 사용하는 것이 좋다.

호스팅 업체마다 다르겠지만 요점은 네임서버 설정을 들어가서 입력해 주는것이다.

 

참고로 가비아에서 입력할때 맨 뒤의 . 은 떼주고 입력해야한다. (다른곳은 안그런곳 있음)

 

 

 

 

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-Route-53-%EA%B0%9C%EB%85%90-%EC%9B%90%EB%A6%AC-%EC%82%AC%EC%9A%A9-%EC%84%B8%ED%8C%85-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC