시스템 보안 · 취약점 › G. 내부 확장 · 측면 이동 징후 · 49/50편 (전체 349/450) 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 348. 내부 확장·측면 이동 — 내부 확장·측면 이동 탐지 규칙 모음 340. 침투→확장→목표 연계 분석 1. 개념 G영역에서 배운 탐지·분석·대응을 하나의 실전 시나리오 로 종합합니다. 외부 웹 침투부터 내부 확산, 핵심 자산(DB 마스터) 장악, 유출 시도까지의 전 과정을 SOC 관점에서 탐지·조사·차단하는 흐름을 연습합니다. 실전 시나리오: 침투 → 핵심 자산 장악 1. 침투: 웹 취약점으로 web01 장악 2. 정찰: 내부 스캔·열거(G29·G30) 3. 인증 이동: SSH 키 재사용으로 db01(G10) 4. 상승·수집: 권한 상승·자격 수집(G36·G32) 5. 확산: db01→app01→dbmaster(G33·G35) 6. 목표: dbmaster 데이터 수집·유출(G37) ← 각 단계에서 탐지·차단 기회 이 시나리오는 가상의 예시이며, 각 단계마다 어떤 신호가 발생하고 어떻게 탐지·대응하는지를 종합합니다. 2. 왜 중요한가 실전 시나리오는 개별 탐지 지식을 하나의 사건 흐름으로 통합합니다. 각 단계마다 탐지·차단 기회가 있어, 다층 방어의 가치를 보여줍니다. 조기 단계(정찰·초기 이동) 탐지가 피해를 최소화함을 확인합니다. 3. 핵심 명령어 / 설정 단계 신호 탐지 룰 침투 웹 이상·웹셸 웹 로그 정찰 스캔·열거 106280·106290 인증 이동 키 재사용 106080 상승·수집 sudo·자격 수집 106350·106310 목표 핵심 자산·유출 106330·106360 4. 실습 (실습 예시) # 실전 시나리오 탐지 흐름 (분석 방법) # 단계별 신호를 시간순 종합 조회(타임라인) sudo ausearch -k lateral,recon,privesc,exfil -i --start recent 2>/dev/null | grep -E 'nmap|id_rsa|sudo|dbmaster|mysqldump' | sort # 확산 경로·허브 식별 sudo ausearch -k lateral -i --start recent 2>/dev/null | grep -oE 'srcip=10\.[0-9.]+.*addr=10\.[0-9.]+' | sort | uniq -c 5. 정상 상태 $ (단계별 신호) (평시 — 각 단계 신호 없음, 정상 운영) 평시에는 정찰·이동·상승·유출 신호가 없고, 단계가 연쇄되지 않는 정상 운영 상태입니다. 6. 이상 상태 $ (단계별 신호 — 시나리오 진행) 09:00 web01 웹셸(침투) 09:05 web01 nmap(정찰, 106280) 09:12 web01→db01 SSH 키 재사용(이동, 106080) 09:15 db01 sudo 상승(106350) + id_rsa 수집(106310) 09:20 db01→app01→dbmaster(확산, 106340) 09:25 dbmaster mysqldump → 외부 유출(106360) → 각 단계 탐지 룰 발동, 상관으로 캠페인 경보(106430) 각 공격 단계가 대응 탐지 룰을 발동 → 다층 탐지 상관 룰(106430)이 캠페인으로 묶어 경보 조기 단계(정찰·초기 이동) 차단 시 핵심 자산 보호 가능 7. 로그 분석 (분석 방법) 실전 시나리오 탐지·대응 흐름입니다(가상의 예시). [침투] web01 웹셸 ↓ 탐지: 웹 로그 이상 [정찰] nmap 스캔(106280) ← 차단 기회 1 ↓ [이동] SSH 키 재사용 db01(106080) ← 차단 기회 2 ↓ [상승·수집] sudo(106350)+키 수집(106310) ← 차단 기회 3 ↓ [확산] db01→app01→dbmaster(106340) ← 차단 기회 4 ↓ [목표] mysqldump→유출(106360) ← 마지막 기회 ↓ 상관 캠페인 경보(106430) → 대응 플레이북(G47) = 다층 탐지로 어느 단계든 차단 가능 차단 기회 효과 정찰 단계 피해 없음 이동 단계 확산 전 차단 확산 단계 핵심 자산 보호 목표 단계 유출 저지 조기 단계 탐지일수록 피해가 작음을 보여줍니다. 8. SOC 관제 포인트 실전 시나리오는 침투→정찰→이동→상승·수집→확산→목표 의 전 과정을 종합합니다. 각 단계마다 탐지 룰이 발동하고 상관으로 캠페인 경보가 나는 다층 방어를 확인합니다. 조기 단계(정찰·초기 이동) 탐지가 핵심 자산 보호와 피해 최소화의 열쇠입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_g,lateral,scenario,"> <rule id="106480" level="15" frequency="4" timeframe="1800"> <if_matched_group>lateral</if_matched_group> <same_field>audit.srcip</same_field> <description>침투-정찰-이동-확산-목표 전 단계 연쇄(실전 캠페인)</description> <mitre><id>T1190</id><id>T1021</id><id>T1041</id></mitre> </rule> </group> 단계별 룰과 상관 룰을 종합해 전 과정을 추적합니다. 조기 단계 경보에 신속 대응하면 핵심 자산 도달 전에 차단할 수 있습니다. 10. 대응 방법 초기 확인 — 단계별 신호를 시간순 종합(타임라인)해 시나리오를 재구성합니다. 범위 확인 — 각 단계 탐지 룰 발동·상관 경보·차단 기회를 확인합니다. 증거 확보 — 전 과정 타임라인·경로·증거를 보존합니다. 차단/조치 — 가장 이른 탐지 단계에서 확산 차단·자산 보호 대응을 진행합니다. 재발 방지 — 실전 시나리오 기반 측면 이동 탐지·대응을 연습·운영합니다. 11. 핵심 정리 단계 탐지 룰 침투 웹 로그 정찰 106280·106290 인증 이동 106080 목표 106330·106360 면접 포인트 "실전은 다층 탐지 — 조기 단계(정찰·이동) 차단이 핵심 자산을 지킴" 12. 다음 편 예고 다음 편 350. 내부 확장·측면 이동 — 내부 확장·측면 이동 징후 종합 정리 에서는 내부 확장·측면 이동 징후 전체를 종합하는 내부 확장·측면 이동 징후 종합 정리 를 다룹니다. 이전 편: 348. 내부 확장·측면 이동 — 내부 확장·측면 이동 탐지 규칙 모음 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › G. 내부 확장 · 측면 이동 징후 · 48/50편 (전체 348/450) 학습 단계: SOC 탐지 연계 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 347. 내부 확장·측면 이동 — 측면 이동 Alert 대응 절차 344. Wazuh 기반 측면 이동 탐지 1. 개념 G영역에서 설계한 측면 이동 탐지 규칙을 공격 단계별로 분류한 카탈로그 로 정리합니다. 정찰→인증 이동→원격 실행→확산→목표의 단계마다 핵심 룰을 매핑해, 다층 방어(defense in depth) 관점에서 운영합니다. 측면 이동 탐지 규칙 카탈로그(단계별) [정찰] 스캔·열거·디렉터리 [인증 이동] SSH·키 재사용·자격 재사용·PtH [원격 실행] 명령·스케줄러·SMB·DB·웹·터널 [확산] 경로·홉·자격 수집 [목표] 핵심 자산·상승 연계·유출 연계 [상관] 캠페인·부채꼴·체인 = 단계별 다층 탐지 카탈로그의 목적은 "어느 단계든 하나는 걸리게" 하는 다층 방어입니다. 단계별 룰을 모두 운영해 탐지 사각을 줄입니다. 2. 왜 중요한가 측면 이동은 여러 단계를 거치므로, 단계별 다층 룰이 탐지 확률을 높입니다. 어느 단계든 탐지하면 조기 차단 기회이므로 전 단계 커버가 중요합니다. 카탈로그로 룰을 체계화하면 누락 점검·튜닝·갱신이 쉬워집니다. 3. 핵심 명령어 / 설정 단계 핵심 룰 MITRE 정찰 106280·106290·106300 T1046·T1087 인증 이동 106080·106110·106130 T1021·T1550 원격 실행 106170·106200·106230 T1210·T1059 확산 106310·106320·106340 T1552·T1090 목표·상관 106330·106360·106430 T1041·T1078 4. 실습 (실습 예시) # 측면 이동 탐지 규칙 운영 점검 (분석 방법) # 적재된 G영역 룰 목록·레벨 확인 sudo grep -rE 'id="10(6)[0-9]{3}"' /var/ossec/etc/rules/ 2>/dev/null | grep -oE 'id="[0-9]+" level="[0-9]+"' | sort # 단계별 룰 커버리지 점검(누락 단계 확인) echo "정찰·인증이동·원격실행·확산·목표·상관 각 단계 룰 존재 여부 점검" # 전체 룰 문법 검증 sudo /var/ossec/bin/wazuh-logtest 5. 정상 상태 $ (룰 목록) (정찰~상관 전 단계 룰 적재·검증 통과) 정찰부터 상관까지 전 단계 룰이 적재되고 문법 검증을 통과해, 단계별 커버리지에 누락이 없는 상태가 정상입니다. 6. 이상 상태 운영 이슈 예: · 특정 단계 룰 누락 → 그 단계 탐지 사각 · 과도한 레벨·광범위 조건 → 오탐 폭증 · 기준선 예외 미설정 → 정상 관리 오탐 · 룰 미갱신 → 새 이동 기법 미탐 → 카탈로그로 누락·튜닝·갱신 점검 단계 누락 → 탐지 사각 → 전 단계 커버 확인 필요 광범위 조건·기준선 미설정 → 오탐 → 조건 정밀화·예외 설정 카탈로그 기반 정기 점검으로 사각·오탐·미탐 관리 7. 로그 분석 (분석 방법) 측면 이동 탐지 규칙 카탈로그 구조입니다(가상의 예시). 공격 단계 → 탐지 룰(다층) [정찰] ────── 106280(스캔)·106290(열거)·106300(디렉터리) [인증 이동] ── 106080(키 재사용)·106110(자격 재사용)·106130(계정 전환) [원격 실행] ── 106170(명령)·106200(SMB)·106230(DB)·106260(터널) [확산] ────── 106310(수집)·106320(경로)·106340(홉) [목표] ────── 106330(핵심 자산)·106360(유출 연계) [상관] ────── 106430(캠페인)·106450(흐름 연계) = 어느 단계든 하나는 걸리는 다층 방어 관점 운영 단계별 다층 커버 레벨 우선순위 기준선 오탐 제거 갱신 신규 기법 단계별 다층 커버 + 지속 튜닝이 카탈로그 운영의 핵심입니다. 8. SOC 관제 포인트 G영역 탐지 규칙을 공격 단계별 카탈로그 로 정리해 다층 방어를 운영합니다. 정찰→인증 이동→원격 실행→확산→목표→상관 전 단계를 커버해 사각을 줄입니다. 카탈로그로 누락 점검·오탐 튜닝·신규 기법 갱신을 체계적으로 관리합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_g,lateral,catalog,"> <!-- 단계별 룰은 각 편(106080~106450)을 참조, 베이스로 묶음 관리 --> <rule id="106470" level="3"> <if_group>lateral</if_group> <description>측면 이동 탐지 카탈로그(단계별 룰 묶음 관리)</description> <mitre><id>T1021</id></mitre> </rule> </group> lateral 그룹으로 전 단계 룰을 묶어 관리하고, 레벨·기준선 예외를 일괄 튜닝합니다. 정기적으로 커버리지·오탐·신규 기법을 점검·갱신합니다. 10. 대응 방법 초기 확인 — 단계별(정찰~상관) 룰 적재·커버리지·문법을 점검합니다. 범위 확인 — 레벨·조건·기준선 예외의 오탐·미탐 균형을 확인합니다. 증거 확보 — 룰 카탈로그·커버리지 맵·튜닝 이력을 문서화·보존합니다. 차단/조치 — 누락 단계는 룰 추가, 오탐은 예외·조건 정밀화로 지속 튜닝합니다. 재발 방지 — 측면 이동 탐지 규칙 카탈로그를 운영·갱신합니다. 11. 핵심 정리 단계 핵심 룰 정찰 106280·106290·106300 인증 이동 106080·106110·106130 원격 실행 106170·106200·106230 목표·상관 106330·106360·106430 면접 포인트 "단계별 다층 룰로 어느 단계든 탐지 — 카탈로그로 사각·오탐·갱신 관리" 12. 다음 편 예고 다음 편 349. 내부 확장·측면 이동 — 실전 시나리오 — 침투부터 핵심 자산 장악까지 에서는 침투부터 핵심 자산 장악까지의 실전 시나리오를 다루는 실전 시나리오 — 침투부터 핵심 자산 장악까지 를 다룹니다. 이전 편: 347. 내부 확장·측면 이동 — 측면 이동 Alert 대응 절차 📚 시리즈 전체 보기: 시스템 보안 · 취약점
『Real MySQL 8.0』 6장을 읽고, 핵심 개념을 쉽게 이해할 수 있도록 제 방식대로 정리한 글입니다. 📌 들어가기 전에 왜 데이터를 압축할까? 디스크에 저장된 데이터 파일이 커지면 여러 가지 문제가 생깁니다. 문제 설명 쿼리 성능 읽어야 할 데이터가 많아져 디스크 I/O 증가 백업·복구 시간 파일이 클수록 백업과 복구가 오래 걸림 저장 공간 비용 디스크 용량이 많이 필요함 그래서 MySQL은 데이터를 압축해서 저장 하는 방법을 제공합니다. MySQL의 두 가지 압축 방식 방식 다른 이름 한 줄 설명 페이지 압축 Transparent Page Compression 디스크에 쓸 때 압축 , 읽을 때 해제. OS의 펀치 홀 기능에 의존 테이블 압축 - 압축된 페이지를 정해진 크기(KEY_BLOCK_SIZE) 에 맞춰 저장 6.1 페이지 압축 페이지 압축이란? 데이터 페이지를 디스크에 저장하는 순간 압축 하고, 디스크에서 읽어올 때 압축을 해제 합니다. 그래서 버퍼 풀에는 압축이 해제된 상태 로 데이터가 올라옵니다. [쓰기] 버퍼 풀 (16KB, 원본) ──압축──▶ 디스크 (압축된 상태) [읽기] 디스크 (압축된 상태) ──해제──▶ 버퍼 풀 (16KB, 원본) 💡 MySQL 서버 내부에서는 데이터가 압축됐는지 신경 쓰지 않고 똑같이 처리합니다. 그래서 "투명한(Transparent)" 페이지 압축이라고 부릅니다. 문제: 압축 결과의 크기를 예측할 수 없다 16KB 페이지를 압축하면 결과가 7KB가 될지, 10KB가 될지 미리 알 수 없습니다. 그런데 하나의 테이블은 모든 페이지가 같은 크기 여야 관리할 수 있습니다. 페이지 A 압축 → 7KB 페이지 B 압축 → 11KB 페이지 C 압축 → 5KB → 크기가 제각각이면 파일 안에서 페이지 위치를 계산할 수 없음 😵 해결: 펀치 홀 (Punch Hole) 운영체제의 펀치 홀 기능을 이용해 이 문제를 해결합니다. 1 16KB 페이지를 압축 → 결과 7KB 2 디스크에 16KB 크기 그대로 기록 [압축 데이터 7KB][빈 공간 9KB] 3 뒤쪽 빈 공간 9KB에 펀치 홀을 뚫음 [압축 데이터 7KB][🕳️ 9KB] → 파일 시스템은 9KB를 운영체제에 반납 관점 크기 실제 디스크 사용량 7KB MySQL·운영체제가 보는 파일 크기 16KB (압축 데이터 + 펀치 홀 공간) 🧩 비유: 16칸짜리 주차 구역을 그대로 유지하되, 실제로 차를 7칸에만 세우고 나머지 9칸은 "여기는 비어 있음" 이라고 표시해서 다른 사람이 쓰게 돌려주는 것 페이지 압축의 한계 한계 설명 지원 환경 제약 펀치 홀은 운영체제뿐 아니라 하드웨어(파일 시스템) 도 지원해야 함 파일 복사 시 문제 일반적인 파일 복사 명령어는 펀치 홀을 지원하지 않아서, 복사하면 원래 크기(16KB)로 되돌아감 백업 도구 문제 XtraBackup 같은 백업 도구로 백업·복구할 때도 같은 문제가 생길 수 있음 ⚠️ 이런 이유로 페이지 압축은 실무에서 많이 사용되지 않습니다. 사용 방법 -- 테이블 생성 시 페이지 압축 적용 CREATE TABLE t1 (c1 INT) COMPRESSION = 'zlib'; -- 기존 테이블에 페이지 압축 적용 ALTER TABLE t1 COMPRESSION = 'zlib'; OPTIMIZE TABLE t1; -- 기존 데이터에도 압축을 적용하려면 테이블 재구성 필요 COMPRESSION 값 의미 zlib zlib 알고리즘으로 압축 lz4 lz4 알고리즘으로 압축 none 압축하지 않음 6.2 테이블 압축 테이블 압축이란? 운영체제나 하드웨어 제약 없이 사용할 수 있는 압축 방식입니다. 그래서 페이지 압축보다 활용도가 높습니다. 단점도 있다 단점 설명 버퍼 풀 공간 활용률 낮음 버퍼 풀에 압축된 페이지와 해제된 페이지를 둘 다 보관 쿼리 처리 성능 낮음 압축·해제 과정에서 CPU 사용 잦은 변경 시 압축률 저하 데이터가 자주 바뀌면 압축 효율이 떨어짐 6.2.1 압축 테이블 생성 사전 조건 압축 테이블은 별도의 테이블스페이스 를 사용해야 합니다. SHOW GLOBAL VARIABLES LIKE 'innodb_file_per_table'; -- ON 이어야 함 생성 방법 CREATE TABLE compressed_table ( c1 INT PRIMARY KEY ) ROW_FORMAT = COMPRESSED KEY_BLOCK_SIZE = 8; 옵션 설명 ROW_FORMAT = COMPRESSED 압축 테이블로 생성 (생략하면 KEY_BLOCK_SIZE 만 지정해도 자동으로 COMPRESSED 적용) KEY_BLOCK_SIZE 압축된 페이지가 저장될 목표 크기 (KB 단위) 💡 KEY_BLOCK_SIZE 는 1, 2, 4, 8, 16(KB) 중에서 정하며, 기본 페이지 크기(16KB) 기준으로 보통 4KB 또는 8KB 를 사용합니다. InnoDB 페이지 크기가 32KB, 64KB라면 테이블 압축을 사용할 수 없습니다. 압축 과정 (KEY_BLOCK_SIZE = 8KB 예시) 1 16KB 데이터 페이지를 압축 │ ├─ 압축 결과 ≤ 8KB → 그대로 디스크에 저장 ✅ (압축 완료) │ └─ 압축 결과 > 8KB → 원본 페이지를 둘로 나눔 (페이지 스플릿) [8KB] [8KB] │ │ ▼ ▼ 나뉜 페이지 각각에 대해 1부터 다시 반복 ⚠️ 압축 결과가 목표 크기(KEY_BLOCK_SIZE)보다 작아야 저장할 수 있습니다. 목표 크기를 넘으면 페이지 스플릿 이 일어나고, 이게 반복되면 성능이 떨어집니다. 6.2.2 KEY_BLOCK_SIZE 결정 KEY_BLOCK_SIZE 를 너무 작게 잡으면 압축 실패 → 페이지 스플릿 이 자주 발생합니다. 그래서 실제 적용 전에 샘플 데이터로 테스트 해보는 것이 중요합니다. 테스트 방법 -- 1) 인덱스별 압축 통계 수집 활성화 SET GLOBAL innodb_cmp_per_index_enabled = ON; -- 2) KEY_BLOCK_SIZE를 바꿔가며 테스트 테이블 생성 CREATE TABLE employees_comp4k ( emp_no INT NOT NULL, first_name VARCHAR(14) NOT NULL, hire_date DATE NOT NULL, PRIMARY KEY (emp_no), KEY ix_firstname (first_name), KEY ix_hiredate (hire_date) ) ROW_FORMAT = COMPRESSED KEY_BLOCK_SIZE = 4; -- 3) 실제 데이터 일부를 넣어봄 INSERT INTO employees_comp4k SELECT emp_no, first_name, hire_date FROM employees; -- 4) 인덱스별 압축 성공/실패 횟수 확인 SELECT table_name, index_name, compress_ops, compress_ops_ok, (compress_ops - compress_ops_ok) / compress_ops * 100 AS compression_failure_pct FROM information_schema.INNODB_CMP_PER_INDEX; 컬럼 의미 compress_ops 전체 압축 시도 횟수 compress_ops_ok 압축 성공 횟수 compression_failure_pct 압축 실패율 판단 기준 압축 실패율 = (compress_ops - compress_ops_ok) / compress_ops × 100 💡 일반적으로 압축 실패율이 3~5% 미만 이 되도록 KEY_BLOCK_SIZE 를 선택합니다. 예를 들어 4KB에서 실패율이 높고 8KB에서 낮다면, 8KB 를 선택하는 것이 좋습니다. 그런데 실패율이 전부는 아니다 상황 판단 INSERT만 하는 로그성 테이블 한 번 압축되면 다시 변경되지 않으므로, 실패율이 조금 높아도 압축률이 좋다면 사용 고려 변경이 잦은 테이블 실패율이 낮더라도 압축·해제가 반복되어 CPU 부담 → 압축을 다시 고민 ✅ 압축·해제는 CPU를 사용하는 작업 이라는 점을 함께 고려해야 합니다. 6.2.3 압축된 페이지의 버퍼 풀 적재 및 사용 버퍼 풀에 두 가지 버전을 함께 보관 압축 테이블의 페이지는 버퍼 풀에 이렇게 올라옵니다. ┌─────────────── InnoDB 버퍼 풀 ───────────────┐ │ │ │ [압축된 페이지 8KB] ──해제──▶ [해제된 페이지 16KB] │ │ ▲ ▲ │ │ LRU 리스트 Unzip_LRU 리스트 │ └─────────────────────────────────────────────┘ 리스트 관리 대상 LRU 리스트 압축된 페이지 + 압축 해제된 페이지 모두 Unzip_LRU 리스트 압축 해제된 페이지만 디스크에서 읽어온 압축된 페이지 를 그대로 보관하고, 실제로 데이터를 읽거나 변경하려면 압축을 해제한 페이지 가 필요하기 때문에 둘 다 가지고 있습니다. 이로 인한 문제 문제 설명 메모리 낭비 같은 데이터를 두 가지 형태로 들고 있어서 버퍼 풀 공간을 더 많이 씀 CPU 소모 압축 해제된 페이지를 버렸다가 다시 필요해지면, 또 압축 해제 를 해야 함 InnoDB의 해결 방법: Unzip_LRU 리스트 관리 상황 InnoDB의 동작 버퍼 풀 공간이 부족할 때 압축된 원본은 남기고, Unzip_LRU에서 압축 해제된 버전을 제거 압축된 페이지가 자주 사용될 때 Unzip_LRU에 해제된 페이지를 계속 유지 → 압축·해제 작업 최소화 압축된 페이지가 사용되지 않아 LRU에서 제거될 때 Unzip_LRU에서도 함께 제거 어댑티브(적응형) 알고리즘 InnoDB는 서버 상황을 보고 Unzip_LRU의 비율을 자동으로 조절 합니다. 서버 상황 동작 이유 CPU 사용량이 높음 Unzip_LRU 비율을 높게 유지 압축 해제를 덜 하도록 해서 CPU 절약 디스크 I/O 사용량이 높음 Unzip_LRU 비율을 낮게 유지 버퍼 풀 공간을 더 확보해서 디스크 읽기 감소 🧩 비유 CPU가 바쁠 때: "포장 다시 뜯기 힘드니까, 뜯어놓은 거 그냥 둬" 디스크가 바쁠 때: "창고 공간이 부족하니까, 뜯어놓은 건 치우고 포장된 것만 보관해" 6.2.4 테이블 압축 관련 설정 1 innodb_cmp_per_index_enabled innodb_cmp_per_index_enabled = ON 값 수집되는 통계 ON 인덱스별 압축 성공·실패 횟수 → INNODB_CMP_PER_INDEX OFF 테이블 단위 압축 통계만 수집 → INNODB_CMP 2 innodb_compression_level innodb_compression_level = 6 -- 0 ~ 9, 기본값 6 InnoDB 테이블 압축은 zlib 알고리즘 을 사용하며, 이 값으로 압축률을 정합니다. 값 압축 속도 압축률(저장 공간) CPU 낮을수록 빠름 낮음 (공간 더 사용) 적게 사용 높을수록 느림 높음 (공간 절약) 많이 사용 3 innodb_compression_failure_threshold_pct & innodb_compression_pad_pct_max innodb_compression_failure_threshold_pct = 5 -- 기본값 5(%) innodb_compression_pad_pct_max = 50 -- 기본값 50(%) 동작 방식 테이블 단위 압축 실패율 > innodb_compression_failure_threshold_pct → 압축하기 전에 원본 페이지 끝에 일부러 빈 공간(패딩)을 추가 → 빈 공간은 압축이 매우 잘 되므로 전체 압축률이 올라감 → 압축 결과가 KEY_BLOCK_SIZE보다 작아질 확률 증가 ✅ 설정 의미 innodb_compression_failure_threshold_pct 압축 실패율이 이 값을 넘으면 패딩 추가 시작 innodb_compression_pad_pct_max 패딩 공간은 실패율이 높을수록 늘어나며, 최대 이 비율(%)까지 커질 수 있음 💡 압축 실패로 인한 페이지 스플릿을 줄이기 위해, InnoDB가 스스로 압축 성공률을 높이는 장치 입니다. 4 innodb_log_compressed_pages innodb_log_compressed_pages = ON -- 기본값 ON 서버가 비정상 종료된 뒤 재시작할 때, 압축 알고리즘(zlib)의 버전이 바뀌었더라도 복구가 실패하지 않도록 압축된 데이터 페이지를 그대로 리두 로그에 기록 하는 옵션입니다. 장점 단점 압축 알고리즘을 업그레이드할 때 안전한 복구 보장 데이터 페이지를 통째로 기록하므로 리두 로그 증가량이 커짐 ⚠️ 압축 테이블을 사용 중이라면 리두 로그 공간이 얼마나 빨리 차는지 모니터링해야 합니다. 버퍼 풀에서 더티 페이지가 한꺼번에 많이 기록되는 패턴이라면, 이 옵션을 OFF 로 바꾼 뒤 모니터링해보는 것을 고려할 수 있습니다. ✍️ 마무리 정리 페이지 압축 vs 테이블 압축 항목 페이지 압축 테이블 압축 압축 시점 디스크에 쓸 때 정해진 크기에 맞춰 저장 버퍼 풀 상태 해제된 상태 만 보관 압축 + 해제 둘 다 보관 의존성 OS·하드웨어의 펀치 홀 지원 필요 제약 없음 설정 COMPRESSION = 'zlib' ROW_FORMAT = COMPRESSED , KEY_BLOCK_SIZE 실무 활용 낮음 (파일 복사·백업 문제) 상대적으로 높음 핵심 포인트 6.1 페이지 압축 디스크에 쓸 때 압축하고, 남는 공간은 펀치 홀 로 운영체제에 반납한다. 파일 복사·백업 시 펀치 홀이 사라지는 문제로 잘 쓰이지 않는다. 6.2.1 압축 테이블 생성 innodb_file_per_table = ON 필요 압축 결과가 KEY_BLOCK_SIZE 보다 크면 페이지 스플릿 발생 6.2.2 KEY_BLOCK_SIZE 결정 샘플 데이터로 테스트 후 INNODB_CMP_PER_INDEX 에서 압축 실패율 확인 실패율 3~5% 미만이 기준이지만, 테이블의 변경 빈도도 함께 고려 6.2.3 버퍼 풀 적재 압축 페이지(LRU)와 해제 페이지(Unzip_LRU)를 함께 보관 CPU가 바쁘면 해제 페이지를 유지하고, 디스크가 바쁘면 해제 페이지를 줄이는 적응형 알고리즘 6.2.4 관련 설정 압축 통계( innodb_cmp_per_index_enabled ), 압축률( innodb_compression_level ) 실패율이 높으면 패딩을 추가 해 압축 성공률을 높임 innodb_log_compressed_pages 는 리두 로그 증가량을 함께 모니터링 📚 참고 백은빈, 이성욱, 『Real MySQL 8.0 1권』, 위키북스 MySQL 8.0 Reference Manual - InnoDB Page Compression MySQL 8.0 Reference Manual - InnoDB Table Compression
시스템 보안 · 취약점 › G. 내부 확장 · 측면 이동 징후 · 50/50편 (전체 350/450) 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 349. 내부 확장·측면 이동 — 실전 시나리오·침투부터 핵심 자산 장악까지 301. 내부 확장·측면 이동 징후 분석 개요 1. 개념 G영역 「내부 확장·측면 이동 징후」 50편을 종합 정리합니다. 측면 이동은 거점 하나에서 조직 전체로 확산 되는 공격 단계로, 침투와 목표 달성(유출·파괴) 사이의 핵심 고리입니다. G영역은 이 확산을 탐지·분석·차단하는 전 과정을 다뤘습니다. G영역 전체 체계 [기초] 개념·공격 단계·기반·기준선·분석 축(G01~G08) [인증 이동] SSH·키/자격 재사용·PtH·계정 전환(G09~G18) [원격 실행] 명령·스케줄러·SMB·DB·웹·터널(G19~G28) [정찰·확산] 스캔·열거·수집·경로·핵심 자산·연계(G29~G38) [로그 분석] 타임라인·상관·그래프(G39~G43) [SOC 연계] Wazuh·SIEM·NDR·대응·카탈로그·실전(G44~G50) = 개념부터 실전 운영까지 측면 이동 탐지의 핵심은 "개별 이벤트가 아닌 연결(상관)"입니다. 단일 이동은 정상처럼 보여도, 출발지·계정·시간으로 연결하면 확산 패턴이 드러납니다. 2. 왜 중요한가 측면 이동은 침투와 목표 사이의 핵심 고리로, 여기서 차단하면 피해를 막습니다. 개별 이벤트는 정상처럼 보여, 상관(연결)이 탐지의 본질입니다. 조기 단계(정찰·초기 이동) 탐지가 핵심 자산 보호의 열쇠입니다. 3. 핵심 명령어 / 설정 영역 핵심 기초 동-서 트래픽·4대 축·기준선 인증 이동 키/자격 재사용·PtH·계정 전환 원격 실행 명령·SMB·DB·웹·터널 정찰·확산 스캔·수집·경로·핵심 자산 SOC 연계 상관·Wazuh/SIEM·대응 4. 실습 (실습 예시) # G영역 종합 운영 점검 (분석 방법) # 측면 이동 탐지 체계 전반 점검 echo "1. 중앙 수집·정규화(G41) 정상 여부" echo "2. 단계별 룰 커버리지(G48) 누락 여부" echo "3. 상관 룰(G42·G44) 작동 여부" echo "4. 기준선(G04)·핵심 자산 등록(G34) 최신 여부" echo "5. 대응 플레이북(G47) 준비 여부" sudo /var/ossec/bin/wazuh-logtest # 룰 검증 5. 정상 상태 종합 점검(정상 운영): · 중앙 수집·정규화 정상 · 단계별 룰·상관 룰 적재·작동 · 기준선·핵심 자산 최신 · 대응 플레이북 준비 수집·정규화·단계별 룰·상관·기준선·대응이 모두 정비되어, 측면 이동을 다층으로 탐지·대응할 준비가 된 상태가 정상입니다. 6. 이상 상태 운영 미비 시 위험: · 중앙 수집 미비 → 확산 추적 불가(사각) · 단계 룰 누락 → 그 단계 사각 · 상관 미작동 → 개별 정상으로 미탐 · 기준선·자산 미갱신 → 오탐·사각 → 종합 점검으로 체계 완결성 유지 수집·정규화 미비 → 측면 이동 추적 자체가 불가(가장 큰 사각) 상관 미작동 → 개별 이벤트가 정상으로 보여 미탐 종합 점검으로 탐지 체계의 완결성을 지속 유지 7. 로그 분석 (분석 방법) G영역 종합 체계입니다(가상의 예시). [기초] 개념·4대 축·기준선(G01~G08) ↓ [탐지] 인증 이동·원격 실행·정찰·확산(G09~G38) ↓ [분석] 타임라인·상관·그래프(G39~G43) ↓ [SOC] Wazuh·SIEM·NDR·대응·카탈로그(G44~G48) ↓ [실전] 시나리오·종합(G49~G50) = 개념→탐지→분석→운영→실전 완결 체계 핵심 원리: 개별 이벤트 → (상관) → 확산 패턴 → 탐지·차단 흐름 결과 기초 판단 기준 탐지 단계별 신호 분석 사건 재구성 SOC 운영 탐지·대응 개념부터 실전까지 측면 이동을 다루는 완결 체계입니다. 8. SOC 관제 포인트 측면 이동은 거점 하나에서 조직 전체로 확산 되는, 침투와 목표 사이의 핵심 고리입니다. 탐지의 본질은 개별 이벤트의 상관(연결) 으로, 단일은 정상이어도 연결하면 확산이 보입니다. 중앙 수집·정규화·단계별 다층 룰·상관·기준선·대응을 갖춘 완결 체계가 핵심입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_g,lateral,"> <rule id="106490" level="12"> <if_group>lateral</if_group> <description>G영역 측면 이동 탐지 체계(종합 — 상관 기반 확산 탐지)</description> <mitre><id>T1021</id><id>T1078</id><id>T1210</id></mitre> </rule> </group> G영역 전 룰(106000~106480)을 lateral 그룹으로 통합 운영하고, 중앙 수집·상관·기준선·대응을 하나의 체계로 유지합니다. 정기 점검으로 완결성을 지킵니다. 10. 대응 방법 초기 확인 — 중앙 수집·정규화·단계별 룰·상관·기준선·대응을 종합 점검합니다. 범위 확인 — 측면 이동 탐지 체계의 커버리지·상관 작동·완결성을 확인합니다. 증거 확보 — 탐지 체계·룰 카탈로그·운영 문서를 보존·갱신합니다. 차단/조치 — 미비 항목은 보강하고, 신규 이동 기법은 룰·기준선에 반영합니다. 재발 방지 — G영역 측면 이동 탐지 체계를 지속 운영·발전시킵니다. 11. 핵심 정리 영역 핵심 기초 동-서·4대 축·기준선 인증/원격 이동 키·자격 재사용·SMB·DB·터널 정찰·확산 스캔·수집·경로·핵심 자산 SOC 연계 상관·Wazuh/SIEM·대응 면접 포인트 "측면 이동 탐지의 본질은 상관 — 개별은 정상, 연결하면 확산이 보인다" 12. 다음 편 예고 이것으로 G영역 「내부 확장·측면 이동 징후」를 마칩니다. 다음 영역에서 또 다른 보안 주제로 이어집니다. 이전 편: 349. 내부 확장·측면 이동 — 실전 시나리오 — 침투부터 핵심 자산 장악까지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › G. 내부 확장 · 측면 이동 징후 · 47/50편 (전체 347/450) 학습 단계: SOC 탐지 연계 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 346. 내부 확장·측면 이동 — 네트워크 탐지(NDR)·흐름 로그 연계 308. 내부 확장·측면 이동 판정 기준 1. 개념 측면 이동 경보는 확산 중인 활성 공격 일 가능성이 높아, 신속·체계적 대응이 필요합니다. 접수→분류→조사→격리→확산 차단→복구의 플레이북 으로 대응하되, 측면 이동 특성상 확산 차단(추가 이동 저지) 이 최우선입니다. 측면 이동 Alert 대응 절차 1. 접수·분류: 정탐/오탐, 심각도(핵심 자산 근접?) 2. 조사: 4대 축·경로 매핑·타임라인 3. 격리: 영향 호스트·허브 격리 4. 확산 차단: 경로 차단·자격증명 교체 5. 복구: 정리·패치·모니터링 6. 사후: 타임라인·보고·교훈 핵심: 확산 차단(추가 이동 저지)이 최우선 측면 이동은 진행 중이면 매 순간 확산되므로, 조사와 병행해 확산 차단을 서두릅니다. 허브(G43) 격리가 확산을 가장 효율적으로 끊습니다. 2. 왜 중요한가 측면 이동 경보는 활성 확산일 가능성이 높아 신속 대응이 필수입니다. 확산 차단(추가 이동 저지)이 조사보다 우선할 수 있습니다(진행 중). 허브 격리·자격증명 교체가 확산을 끊는 핵심 조치입니다. 3. 핵심 명령어 / 설정 단계 조치 우선순위 분류 정탐/오탐·심각도 즉시 조사 경로·타임라인 병행 격리 호스트·허브 높음 확산 차단 경로·자격 교체 최우선 복구 정리·패치 이후 4. 실습 (실습 예시) # 측면 이동 Alert 대응 (분석 방법) # 1. 영향 범위 확인(경로 매핑) sudo ausearch -k lateral -i --start recent 2>/dev/null | grep -oE 'srcip=10\.[0-9.]+.*addr=10\.[0-9.]+' | sort | uniq -c # 2. 활성 세션 확인(진행 중 이동) ss -tnp 2>/dev/null | grep -E ':22\b' | grep -E '10\.|192\.168\.' # 3. 증거 보존(격리 전 로그 수집) sudo ausearch -k lateral,privesc,exfil --start recent > /var/log/ir_lateral_$(date +%s).log 2>/dev/null 5. 정상 상태 대응 준비 상태(정상 운영): · 플레이북·연락망·격리 권한 준비됨 · 경보 접수 시 즉시 분류·대응 가능 플레이북·연락망·격리 권한이 준비되어, 경보 접수 시 지체 없이 분류·대응에 들어갈 수 있는 상태가 정상(대응 준비 완료)입니다. 6. 이상 상태 측면 이동 경보 대응 흐름(정탐): 1. 분류: 핵심 자산 근접 → 심각도 상 2. 조사: web01→db01→app01 경로, db01=허브 3. 격리: db01(허브) 우선 격리 → 확산 차단 4. 자격 교체: 관련 SSH 키·계정 전면 교체 5. 복구: 발판·도구 제거, 진입점 패치 핵심 자산 근접 경보 → 심각도 상향 → 신속 대응 허브(db01) 우선 격리 → 추가 확산 차단 경로 차단 + 자격증명 교체 → 측면 이동 봉쇄 7. 로그 분석 (분석 방법) 측면 이동 Alert 대응 절차입니다(가상의 예시). [접수] 106430 상관 경보(캠페인) ↓ 분류 정탐 + 핵심 자산 근접 → 심각도 상 ↓ 조사(병행) 경로: web01→db01→app01, 허브=db01 ↓ 확산 차단(최우선) db01(허브) 격리 → SSH 키·계정 교체 ↓ 복구 발판·도구 제거, web01 진입점 패치 ↓ 사후 타임라인·보고·탐지 규칙 보강 단계 핵심 조치 분류 심각도·정탐 조사 경로·허브 확산 차단 허브 격리·자격 교체 복구 정리·패치 확산 차단(허브 격리·자격 교체)이 대응의 최우선입니다. 8. SOC 관제 포인트 측면 이동 경보는 활성 확산 일 수 있어 신속·체계적 플레이북 대응이 필요합니다. 접수→분류→조사→격리→확산 차단→복구 중 확산 차단이 최우선 입니다. 허브(G43) 격리와 자격증명 전면 교체가 확산을 끊는 핵심 조치입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_g,lateral,response,"> <rule id="106460" level="14"> <if_sid>106430</if_sid> <description>측면 이동 캠페인 경보 — 대응 플레이북 가동(확산 차단 우선)</description> <mitre><id>T1021</id></mitre> </rule> </group> 고레벨 캠페인 경보는 자동 플레이북(격리·자격 교체 티켓)과 연동합니다. 격리 권한·연락망·증거 보존 절차를 사전 정비합니다. 10. 대응 방법 초기 확인 — 경보를 분류(정탐/오탐·심각도·핵심 자산 근접)합니다. 범위 확인 — 경로·허브·타임라인을 조사하며 확산 차단을 병행합니다. 증거 확보 — 증거 보존(격리 전 로그) 후 허브·호스트를 격리합니다. 차단/조치 — 경로 차단·자격증명 전면 교체·발판 제거·진입점 패치를 진행합니다. 재발 방지 — 사후 타임라인·보고·탐지 규칙 보강으로 측면 이동 대응을 마무리합니다. 11. 핵심 정리 단계 조치 분류 정탐/오탐·심각도 조사 경로·허브·타임라인 확산 차단 허브 격리·자격 교체(최우선) 복구 정리·패치·모니터링 면접 포인트 "측면 이동은 활성 확산 — 허브 격리+자격 교체로 확산 차단이 최우선" 12. 다음 편 예고 다음 편 348. 내부 확장·측면 이동 — 내부 확장·측면 이동 탐지 규칙 모음 에서는 내부 확장·측면 이동 탐지 규칙을 모으는 내부 확장·측면 이동 탐지 규칙 모음 을 다룹니다. 이전 편: 346. 내부 확장·측면 이동 — 네트워크 탐지(NDR)·흐름 로그 연계 📚 시리즈 전체 보기: 시스템 보안 · 취약점