alb

AWS-CloudFront-custom-header-ALB-filter

https://www.notion.so/CloudFront-ALB-f0086dec48b64f0883e0c6de5fd9da4c

Noah.Seo 님의 이야기를 받아서 다른방법을 테스트하게 되었다.

4번째 방법이 번득 떠오른탓.

그럼 내가 생각하는 부분은 이렇다.

CloudFront -> ALB

끝...3번 방법은 WAF에서 X-Origin-Verify Custom Header 를 필터링 한다. ALB에서도 비슷한 기능이 있는바. 나는 이전부터 ALB에서 내 블로그 도메인이 아닌 ALB 도메인이나 IP로 접근하는것을 제한한 바가 있다.

이 규칙이 바로 그것이다. Host 조건에 따라 Host가 다르면 아무 대상이 없는 blackhole 로 전달하게 된다. 그렇다. Custom Header를 ALB에서 필터링 할거다.

CloudFront 에서 Origin 을 수정한다.

단점은 ALB의 부하가 올라간다는것. 규칙에 의해 LCU 사용량이 증가할수 있다는 점이다.

그럼 셋팅해 보자.

X-Origin-Verify 헤더 네임을 추가하고 Value 로 test를 추가한다.

그리고 ALB의 규칙을 추가한다. 도메인 기반하여 http 헤더가 일치하면 라우팅. 그렇지않으면 두번째 규칙에 의해 blackhole로 전달한다. 지금 현재 정상적으로 헤더가 일치하여 사이트가 뜨는 상태다.

https://www.linuxer.name/

로 접근해보면 503에러가 발생하는것을 볼수있다.

재미있는 테스트 거리를 주신 Noah.Seo 님께 감사를 드린다.

AWS ALB 규칙 설정-2

오픈카톡에서 받은 질문이다.

질문을 다시정리하자면

linuxer-blog-alb-1657105302.ap-northeast-2.elb.amazonaws.com <- 허용하지 않음.

이름: linuxer-blog-alb-1657105302.ap-northeast-2.elb.amazonaws.com
Addresses: 13.125.124.26
15.164.132.46

13.125.124.26 <- 허용하지 않음
15.164.132.46 <- 허용하지 않음
test.linuxer.name <-허용하지 않음

linuxer.name <- 허용
www.linuxer.name <-허용
리눅서.com <-허용

iptables 마냥 deny 정책 위에 allow 를 올려준다 생각하면 간단하다 그럼 여기에서 필요한건 ALB limit 인것 같다. 왜냐? 룰이 많아 질수도 있으니까.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-limits.html

여러번 공개된 리스너 규칙이다.
80->443으로 연결하고 443리스너는 linuxer-blog-wg 로 전달.. tg인데 왜 wg로 했는지는 아직도 의문이다..생성하면서 졸았나...

규칙을 보면 지난번에 alb 규칙 포스팅에서 셋팅한 그대로다. 그럼 이걸 수정해 줄거다.

route53 에선 따로 전환안해도 먹어서 그냥 입력해봤는데 안먹는다. 퓨니코드로 변환해서 넣자

이제 그럼 https://test.linuxer.com 으로 들어가보자. 503 error 이 그대를 맞이할것이다.

그럼 원하지 않는 문자열이나 쿼리를 503으로 띄우고 싶다면?

먼저

내 IP를 확인했다.

소스 IP로 /wp-admin 을 blackhole 처리를 하고 특정 IP 하나만 열어 주었다.

https://linuxer.name/wp-admin.php

접속해 보시라. 503 error 가 반길것이다.

사실 요즘 admin 페이지로 유입이 있어서 wp-admin 막는거로.. 오늘 fail2ban 포스팅을 하려고 계획했는데 실패했다.

alb에서 막아버려서...

블로깅을 할수있도록 포스팅거리를 주신 이주호님께 감사를 드린다.

좋은하루 되시라!

ALB sticky session 에 대한 고찰.

aws 에선 고가용성을 위한 로드벨런서를 지원한다.

로드벨런서의 이야기다.

오늘 3티어 구성에서 세션이 널뛰는 증상이 있었다. 그 이야기를 하기전에 먼저 설명부터 하겠다.

ELB 라는 이름으로 ALB/NLB/CLB로 불린다.

Application Load Balancer, Network Load Balancer, Classic Load Balancer 이다.

오늘 이야기할 로드벨런서는 ALB인데 그중에도 sticky session 이다.

한글 콘솔에서는 고정 세션이라 불린다. 고정세션은 라운드 로빈으로 작동하는 로드벨런서에 세션을 고정해서 사용자의 경험을 지속할수 있도록 도와주는 역할을 한다.

먼저 옵션을 설정하는 방법부터 보자

로드벨런서>대상그룹> 속성편집 을 누른다.

그럼 아래와 같은 창이뜨고 활성화를 누르면 고정세션의 시간을 활성화 할수 있다.

활성화 한 화면은 다음과 같다.

sticky session 이 정상적으로 붙은지 확인하는 방법은 아래와 같다.

아직 sticky session 설정을 추가하지 않은상태다.

sticky session 세션은 cookie로 생성이된다.

Application Load Balancer는 로드 밸런서가 생성한 쿠키만 지원합니다. 쿠키의 이름은 AWSALB입니다. 이러한 쿠키의 콘텐츠는 교체 키를 사용하여 암호화됩니다. 로드 밸런서가 생성한 쿠키는 해독하거나 변경할 수 없습니다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions

3tier로 구성하면 AWSALB 쿠키가 2개가 붙는다.

AWSALB fnCHt1XmAslF4YJP1DdrFja2gFlp58fwxawbSD63gMsYHbSY6ZvL47TP9JyNb1LAqNBb1mt3J0xTVTQrbyFV3KVQmFayhf0C+FIcsOoXDpadKRTlRxNiL2jaijXf N/A N/A N/A 131
JSESSIONID BA145F75466D30D122F5BF83873E0C13 N/A N/A N/A 45
_ga GA1.3.549999545.1568632026 N/A N/A N/A 32
Response Cookies 357
AWSALB 7/4O7AyBPsXTcT9Y3AEE+B3ueRztLwkdTz9TwF/bJ191ItEAMN1HoOk1xsVtWsOjbmuZb68s5gs+6xM2oowR3JgexIIVYIUPWwFkkOWliy3FkwsmeMzQmXsKAkV0 / 2019-10-28T10:50:30.000Z 179
AWSALB UUu3Vbr3MNNBSaaby5Z1dduf11BTf0148wbnE+20aF9Ak+QQWv0ZFGlsBsUZTOWRB9k99mVsAzr0PMgLAiciFD5mJW2FLmNn3ojwbh/EEQFdL5qe6NZCkAFKuLOz / 2019-10-28T10:50:30.000Z 178

alb-web-alb-was-rds 구성이면 쿠키가 좀붙는데 was 가 tomcat 라면

awsalb 쿠키 2개와 jsessoinid 라는 쿠키까지 붙는다.

여기서 awsalb 쿠키는 response 한 alb쿠키를 request 에 재활용한다.

awsalb 쿠키는 지속적으로 변한다. 하지만 sticky session 에의해서 jsessionid값은 연결된 was의 고유값을 지니며 jsessionid 가 변경되면 세션이 초기화 되서 재 매칭이 된다.

이걸 왜포스팅하냐면 sticky 가 정상적으로 붙는데 세션이 was1/2로 붙는 증상이 발생해서 확인하는 방법을 포스팅한거다..

아디오스!