# Canary
[dreamhack] Return to Shellcode
🚩 Return to Shellcode 🤖 r2s.c 👩💻 /* */ 문제에서 Stack은 buf, canary, SFP, RET 순서로 구성되어 있다. buf 0x50 byte, canary 8 byte, SFP 8 byte, RET 8 byte canary는 첫 1바이트가 0으로 시작하므로 buf를 'A'로 덮고 canary 1바이트까지 덮는다. 그러면 NULL문자가 없어서 %s에서 canary의 나머지 7바이트 까지 읽힌다. canary 값을 알아냈고 buf에 쉘코드를 삽입한다. 남은 buf는 'A'로 덮고, 알아낸 canary를 삽입한다. SFP도 덮고 RET를 buf address로 덮는다. buf addr에 삽입한 쉘코드가 실행된다. p.s. sendlineafter와 sendafter의 차이점을 몰라서 애먹었다. sendlineafter("Input: ", payload): Input:
ArgoRollouts with Istio
공식문서 Rollout 컨셉 설치 공식문서 가이드 배포 공식문서 istio 배포 가이드 argo rollout 참고 가이드 [참고블로그 0 ](https://www.infracloud.io/blogs/progressive-delivery-service-
Istio, kiali를 이용한 canary배포 sample
이미지 만들기 참고 블로그 버전 1번은 V1가 나오게 하고, 버전 2번은 V2가 나오게 만들었다. 일단 deploy를 두개, svc를 한개를 만들어두자 Destination룰을 생성한다 subnets:v1은 version: v1 라벨이 달린 pod로 갈것이고, subnets:v2는 version: v2 라벨이 달린 pod로 갈것이당. VirtualService를 이용해서 weight를 조절한다. pod에서 호출하면서 확인한다. VirtualService를 이용해서 weight를 조절한다. 
무중단 배포를 알고 계신가요?
최근 어느 커뮤니티에서 대화를 나누는 도중 ci/cd에 대해서 어떻게 구현한 것인지에 대한 질문이 있었는데 그에 대한 답변에 대해서 스스로 바로 떠오르지 못했기 때문에 이번 글을 작성하게 되었다. 고민에 빠지게 된 질문 > 무중단 배포가 뭘까요? 그래서 여러가지 키워드가 나왔었는데 blue-green, canary 등등의 키워드가 나왔는데 처음 들었다. 솔직히 말해서 그래서 이번 기회에 정리하고 이와 관련해서 무중단 배포를 어떻게 진행하는지 알아보기 위해서 이 글을 작성하게 되었다. 먼저 무중단 배포도 중요하긴 하지만 어쩌다 이런 단어가 나온지 확인하자. 가장 많이 듣는 키워드로는 CI/CD 라는 키워드에서 계속가다가 무중단 배포라고 나오게 되었다. 먼저 알고가면 좋은 용어 용어 정리 온 프레미스 >기업의 서버를 클라우드와 같이 '가상의 공간'이 아니라, 자체적으로 보유하고 있는 서버에 직접 설치하고 운영하는 방식 로드 밸런싱
[dreamhack] System-stage6 : Exploit Tech - Return to Shellcode
1. 서론 이번 장에서는 카나리를 우회하고 쉘 코드와 return address overwrite 을 이용하여 쉘을 획득하는 실습을 할 것이다. 사용할 예제코드는 다음과 같다. 2. 분석 보호기법 탐지 리눅스에는 다양한 바이너리 보호기법이 존재한다. 적용된 보호기법에 따라 익스플로잇 설계가 달라지므로, 분석을 시도하기 전에 먼저 적용된 보호기법을 파악하는 것이 좋다. pwntools 을 설치할 때 같이 설치되는 checksec 툴을 사용하여 보호기법을 파악할 수 있다. 해당 바이너리에 canary 가 설정되어 있는 것을 확인할 수 있다. 취약점 탐색 1. buf 의 주소 해당 예제에서는 실습의 편의를 위해 buf 의 주소 및 rbp 와 `b
[dreamhack] System-stage6: Stack Canary
1. 서론 스택 카나리(canary) : 함수의 프롤로그에서 스택 버퍼와 반환 주소 사이에 임의의 값을 삽입하고, 함수의 에필로그에서 해당 값의 변조를 확인하는 보호 기법 만약 에필로그 시에 카나리 변조가 확인되면 프로세스는 강제로 종료됨!! 스택 버퍼 오버플로우 공격을 통해 반환 주소를 변경할려면, 반드시 카나리를 먼저 덮어야 하기 때문에, 공격의 성공을 위해서는 카나리 값을 알아야 한다. 2. 카나리의 작동 원리 이번 장에서는 실제 카나리가 적용된 코드와 카나리가 적용되지 않은 코드의 비교를 통해 스택 카나리의 원리를 살펴볼 것이다. 스택 버퍼 오버플로우가 발생하는 예제 코드 카나리 비활성화 카나리를 비활성화하기 위한 옵션으로 -fno-stack-protector 이 있다. 해당 옵션으로 컴파일 후 실행 시, 긴 입력을 주면 반환 주소가 덮여서 Segmentation fault 가 뜨는 것을 확인할 수 있다.
Canary Deployment with kustomization in Argo CD
kustomization.yaml alb-ingress.yaml canary.yaml remark > maxSurge # canary 배포로 생성할 pod의 비율 > maxUnavailable # 업데이트 될 때 사용할 수 없는 pod의 최대 수 > setWeight # 카나리로 배포된 서버로 전송해야될 트래픽 비율 > pause: {} # AutoPromotion Time
Blue/Green Deployment with kustomization in Argo CD
Argo-rollouts Install Argo-rollouts Plugin Install kustomization.yaml ingress.yaml ingress.yaml로 ALB 생성 확인 bluegreen.yaml remark > - apps/v1 대신 argoproj.io/v1alpha1을 사용 > - Deplyment 대신 Rollout을 사용 > - autoPromotioEnabled 옵션은 Blue/Green 배포를 자동으로 진행할 것인지 여부. false 옵션을 사용해 수동으로 지정 Blue/Green 전환 
Argo CD Canary 🕊 배포 방법
서론 애플리케이션을 무중단으로 배포하는 방법으로는 Rolling, Blue/Green, Canary 방식이 가장 대표적인 방법이라고 생각된다. 현재 Kubernetes 에서 기본적으로 지원하는 배포 방식은 Rolling 방식으로 새로운 서버가 생성되면 일괄로 기존 서버가 삭제되는 방식을 사용한다. 해당 방식도 나쁜 방식은 아니지만 새로운 서버에 문제가 발생할 경우 롤백하기가 굉장히 번거로워진다. 따라서 보통 운영 환경에서는 Blue/Green 배포와 Canary 배포를 많이 사용하는 것으로 알고 있는데 오늘은 그 중에서 Canary 배포를 AWS EKS 와 Argo CD 에 적용하는 방법에 대해서 알아볼 예정이다. 무중단 배포 방식에 대한 설명은 다른 블로그에 자세하게 설명이 되어있으므로 제가 살펴봤던 블로그 링크만 걸고 추가적인 설명은 하지 않겠습니다. https://reference-m1.tistory.com/211 해당 내용으로도 부
[Android] 메모리릭 과 Leak Canary
메모리릭 이란? 메모리릭이란 필요없는 객체 또는 사라진 객체를 참고하고 있을 때 OOM(Out Of Memory)로 인해 충돌이 발생하는 것을 말한다. 안드로이드에서 발생하는, 내가 겪어본 메모리릭으로는 다음과 같다. application context를 UI와 관련된 곳에서 사용했을 때 activity context를 잘못 참조하거나, 해당 activity가 사라졌음에도 어딘가에서 context를 변수화하여 참조하고 있을 때 이벤트 콜백, 비동기 작업이 제대로 종료되지 않았을 때 fragment binding의 null 처리가 되지 않았을 때 Leak Canary 이란? 안드로이드 메모리릭을 감지하고 알려주는 라이브러리이다. 사용 1. 준비 2. 다운로드 기기에 빌드를 하면 다음과 같이 다운로드된 것을 확인할 수 있다. 
배포전략
배포전략 과거에는 배포라는 작업이 아주 큰 이벤트였다. 하지만 최근에는 유연한 아케텍쳐 설계로 이전보다 더 자주 배포를 하게된다. 이러한 과정에서 배포전략들이 다양하게 발전해왔는데 가장 대표적인 배포전략 몇가지만 소개해보겠다. Recreate 모든 서버를 중지하고 새로운 버전으로 배포한 후 다시 서비스를 올리는 방법이다. 다운타임이 발생하는 배포전략이기 때문에 테스트서버 및 서비스가 중단되어도 문제가 없는 서버등에서 사용한다. 일반적으로 사용되는 배포전략은 아니다. Rolling
aws 서비스 정리 | API Gateway
API Gateway 하나의 큰 서비스는 수십~수백개의 작은 서비스로 나뉘어지며(MSA), 만약 클라이언트에서 서비스를 직접 호출하는 형태라면 다음과 같은 문제점이 생길 수 있다. 각각의 서비스마다 인증/인가 등 공통된 로직을 구현해야하는 번거로움이 있다. 수많은 API 호출을 기록하고 관리하기가 어렵다. 클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출을 해야 한다. 내부의 비즈니스 로직이 드러나게 되어 보안에 취약해 진다. 특히 이러한 문제점들은 마이크로 서비스의 갯수가 많아질 수록 기하급수적으로 늘어나게 될 것이다. 어느 규모 이상의 마이크로 서비스 기반 어플리케이션에는 API Gateway를 도입하는 것이 효율적라고 한다. API Gateway란?
What Is Istio Service Mesh?
Istio Service Mesh란? 서비스 매쉬란? 마이크로 서비스를 위한 인프라 계층 레거시 코드의 변경 없이 각 서비스에 대해 가시성, 트래픽 관리, 보안 기능 등을 추가 복잡하고 방대한 규모의 마이크로서비스에 대한 관리 용이 이스티오(Istio)란? 서비스 매쉬 오픈소스 기존의 응용프로그램 위에 레이어링되어 다양한 동작들을 수행 이스티오가 제공하는 기능들 클러스터 내부에서 TLS 암호화를 이용한 서비스간 안전한 통신 제공 HTTP, gRPC, WebSocket 및 TCP 트래픽에 대한 로드 밸런싱 재시도, 다양한 라우팅 규칙, fault injection 등을 통해 세부 트래픽 동작을 제어 클러스터 내의 모든
프로젝트 배포 전략
신규 프로젝트를 개발을 한 뒤 실 서버에 배포를 진행합니다. 이때, 배포에서도 전략이 있습니다. 이들 중 대표적인 전략에 대해 간단히 정리하고자 합니다. 롤링 (Rolling) 롤링 배포는 서버를 한 대씩 구버전에서 새 버전으로 교체해가는 전략입니다. 서비스 중인 서버 한 대를 제외시키고 그 자리에 새 버전의 서버를 추가합니다. 이렇게 구 버전에서 새 버전으로 트래픽을 점진적으로 전환합니다. 이와 같은 방식은 서버 수의 제약이 있을 경우 유용하나 배포 중 인스턴스의 수가 감소되므로 서버 처리 용량을 미리 고려해야 합니다. Blue/Green ![](https://images.velog.io/images/dev_osj/post/285aaf11-2e03-45c3-9bd8-05122889e