Linux 기본 구조 이해

changseop lee·2026년 9월 23일

Linux 기본 구조 이해 Soc cybersecurity linux 리눅스 리눅스 시스템 기초 보안관제 시스템보안 정보보안

리눅스 시스템 기초

목록 보기

1/250

리눅스 시스템 기초 — 통합 로드맵

이 시리즈는 Linux 구조 → 파일·권한 → 프로세스·서비스 → 시스템 보안 → 로그 분석 → 보안관제(SOC) 순서로 이어지는 250편 학습 과정이다. 각 영역은 입문편(개념 요약)과 심화편(영역 내 번호가 붙은 글)으로 구성된다.

영역	시리즈 순서	편수	첫 글
01. Linux 기본 구조 이해	1 ~ 15	15	Linux 기본 구조 이해
02. 파일 · 권한 · 사용자 관리	16 ~ 75	60	Linux 파일과 디렉터리 관리
03. 서비스 · 프로세스 관리	76 ~ 137	62	Linux 프로세스 이해
04. Linux 시스템 보안 기초	138 ~ 192	55	01. Linux 시스템 보안의 기본 개념
05. Linux 로그 경로 정리	193 ~ 250	58	01. Linux 로그란 무엇인가

입문편 번호표

입문편 본문의 "N편"은 아래 입문 번호를 뜻한다. 심화편의 "N편"은 각 영역 글 제목 앞 번호(영역 내 번호)를 뜻한다.

입문 번호	글	영역
1	Linux 기본 구조 이해	01
2	Linux Kernel의 역할	01
3	Shell과 Bash 이해	01
4	User Space와 Kernel Space	01
5	Linux 시스템 호출(System Call)	01
6	Linux 파일 시스템 구조	01
7	Linux 디렉터리 구조 (입문)	01
8	Linux 부팅 과정	01
9	Linux 환경변수 이해	01
10	Linux 시스템 정보 확인	01
11	Linux 파일과 디렉터리 관리	02
12	절대경로와 상대경로 (입문)	02
13	Linux 파일 종류 (입문)	02
14	inode와 파일 시스템	01
15	Linux 파일 권한 이해	02
16	chmod와 권한 관리	02
17	chown과 파일 소유권	02
18	Linux 사용자와 그룹	02
19	sudo와 su (입문)	02
20	최소 권한 원칙	02
21	grep으로 로그와 문자열 검색	05
22	find로 파일 검색	02
23	head와 tail	05
24	sort와 uniq	05
25	cut과 awk	05
26	sed 활용	05
27	파이프라인과 리다이렉션	01
28	Linux Shell Script 기초	01
29	명령어 조합을 이용한 시스템 분석	04
30	Linux 명령어를 활용한 보안 점검	04
31	Linux 프로세스 이해	03
32	ps로 프로세스 분석	03
33	top으로 시스템 리소스 확인	03
34	Linux Signal과 kill	03
35	Parent / Child Process	03
36	systemd 구조 이해	03
37	systemctl 서비스 관리	03
38	cron 작업 스케줄링	03
39	CPU · Memory 관리	03
40	Disk 사용량 관리	03
41	Linux 네트워크 구조	01
42	IP / TCP / UDP / Port	01
43	Socket 이해	03
44	ss와 ip 명령어	03
45	SSH 구조 이해	04
46	Firewalld 이해	04
47	SELinux 이해	04
48	Linux 로그와 journalctl	05
49	SSH Brute Force 로그 분석	05
50	보안관제 실습 - 로그에서 공격 흔적 찾기	05

Linux System Architecture — 리눅스 시스템 기초 #1

리눅스 시스템 기초 1 / 50
실습 환경: VMware · Rocky Linux 9 (서버, 10.0.0.200) · Kali Linux (공격자, 10.0.0.128) · Ubuntu (IDS, 10.0.0.222)
이 시리즈는 Linux 기초 → 시스템 관리 → 보안 → 로그 분석 → 보안 이벤트 분석 → SOC 순서로 정리한다.

1. 들어가며

보안관제에서 가장 자주 마주치는 대상 중 하나가 Linux 서버다. 웹 서버, DB 서버, 로그 수집 서버, IDS 센서까지 대부분 Linux 위에서 동작한다. SIEM에 경보가 올라오면 결국 "그 서버 안에서 실제로 무슨 일이 있었는가" 를 확인해야 하는데, 이때 필요한 것이 Linux 시스템 구조에 대한 이해다.

명령어만 외워서는 부족하다고 느낀 계기가 있다. ps로 프로세스 목록을 봐도 어떤 것이 정상이고 어떤 것이 이상한지 판단하려면, 프로세스가 어떻게 만들어지고(부모-자식 관계), 어디서 실행되며(/usr/bin인가 /tmp인가), 어떤 권한으로 동작하는지 알아야 했다. 로그도 마찬가지다. 로그를 누가, 어디에, 왜 남기는지 모르면 로그가 없는 것이 정상인지 지워진 것인지 구분할 수 없다.

이 글에서는 다음 질문에 답하는 것을 목표로 한다.

질문	다루는 절
Linux는 어떤 구조로 동작하는가?	3
Kernel은 어떤 역할을 하는가?	4
Shell은 무엇이고, 명령어는 어떻게 실행되는가?	5
User Space와 Kernel Space는 무엇인가?	3, 4
Linux 파일 시스템은 어떻게 구성되어 있는가?	6
보안관제에서는 Linux의 어떤 부분을 확인하는가?	7, 8, 9

2. Linux란?

Linux는 엄밀히 말하면 운영체제의 핵심인 커널(Kernel) 의 이름이다. 1991년 리누스 토르발스(Linus Torvalds)가 처음 공개했고, 현재도 오픈소스로 개발되고 있다.

우리가 "Linux를 설치한다"고 할 때 설치하는 것은 배포판(Distribution) 이다. 배포판은 Linux 커널에 Shell, 기본 명령어(GNU 도구), 패키지 관리자, 서비스 관리자(systemd) 등을 묶어 하나의 운영체제로 만든 것이다.

계열	대표 배포판	패키지 관리	인증 로그 위치	주 사용처
RHEL 계열	RHEL, Rocky Linux, AlmaLinux	`dnf` (rpm)	`/var/log/secure`	기업·공공 서버
Debian 계열	Debian, Ubuntu	`apt` (deb)	`/var/log/auth.log`	클라우드, 개발 서버, 보안 도구
보안 특화	Kali Linux	`apt`	`/var/log/auth.log`	모의해킹, 공격 재현

관제 입장에서 배포판 차이는 생각보다 중요하다. 같은 SSH 로그인 실패라도 Rocky Linux는 /var/log/secure, Ubuntu는 /var/log/auth.log에 기록된다. 로그 수집 설정(rsyslog, Filebeat)의 경로를 잘못 잡으면 이벤트 자체가 SIEM에 들어오지 않는다.

3. Linux의 전체 구조

Linux는 여러 계층으로 나뉘어 있고, 위 계층이 아래 계층에 요청을 보내는 방식으로 동작한다.

Linux 시스템 계층 구조와 관제 포인트

계층	역할	예시	보안관제 관점
User	명령을 내리는 주체	관리자, 서비스 계정, 공격자	누가 실행했는가 (계정, UID)
Application	실제 기능을 제공하는 프로그램	sshd, httpd, mariadb, cron	공격의 진입점 (취약 서비스, 웹셸)
Shell	사용자의 명령을 해석해 실행	bash, sh	침투 후 공격자가 가장 먼저 얻으려는 것
System Call	사용자 공간 → 커널 요청 창구	`openat`, `read`, `execve`, `connect`	auditd가 기록하는 대상
Kernel	자원 관리의 최종 권한자	프로세스·메모리·파일·네트워크·장치 관리	커널 취약점, 루트킷
Hardware	물리 자원	CPU, RAM, Disk, NIC	CPU 급증(채굴), 디스크 풀(로그 유실)

User Space와 Kernel Space

이 구조에서 가장 중요한 개념은 사용자 공간(User Space)과 커널 공간(Kernel Space)의 분리 다.

구분	User Space	Kernel Space
실행 주체	일반 프로그램, Shell, 서비스	Linux Kernel
하드웨어 접근	직접 불가	직접 가능
오류의 영향	해당 프로세스만 종료	시스템 전체 장애 가능
다른 공간으로의 요청	System Call 로만 가능	—

일반 프로그램은 하드웨어에 직접 접근할 수 없고, 반드시 System Call 을 통해 커널에 요청해야 한다. 예를 들어 cat /etc/passwd 한 줄은 내부적으로 다음 요청으로 이루어진다.

cat → openat("/etc/passwd")  : 커널이 권한 확인 후 파일 열기
    → read(...)              : 커널이 디스크에서 데이터 읽기
    → write(stdout, ...)     : 커널이 터미널에 출력

보안 측면에서 이 구조가 의미 있는 이유는, 모든 행위가 결국 System Call을 거치기 때문에 커널 단에서 감시하면 우회하기 어렵다 는 점이다. auditd나 EDR이 System Call을 기록하는 이유가 여기에 있다. strace로 직접 확인할 수 있다.

sudo dnf install -y strace
strace -e trace=openat,read,write cat /etc/hostname

4. Kernel

커널은 하드웨어와 프로그램 사이에서 자원을 나눠주고 통제하는 관리자 다.

역할	하는 일	확인 방법	관제 시 의미
Process 관리	프로세스 생성·스케줄링·종료, PID 부여	`ps`, `/proc/<PID>`	부모-자식 관계로 비정상 실행 추적
Memory 관리	프로세스별 메모리 할당과 격리	`free -h`, `top`	파일 없이 메모리에서만 동작하는 악성코드
File System 관리	파일 읽기/쓰기, 권한 검사	`ls -l`, `stat`	권한 우회, 파일 변조 흔적
Network 관리	소켓 생성, 패킷 송수신	`ss`, `ip`	C2 통신, 리버스 쉘 연결
Device 관리	드라이버를 통한 장치 제어	`lsblk`, `/dev`	외부 저장장치 연결

커널 버전은 uname -r로 확인한다. 커널 버전을 확인하는 이유는 커널 취약점(권한 상승)의 영향 대상인지 판단하기 위해서다. 예를 들어 Dirty Pipe(CVE-2022-0847)는 특정 커널 버전 범위에서만 동작한다. 침해사고 분석에서 "이 서버가 해당 취약점에 영향받는 버전인가"를 판단하는 기초 정보가 된다.

5. Shell

5-1. Shell이란

Shell은 사용자가 입력한 명령을 해석해서 실행하는 명령어 해석기(Command Interpreter) 다. 커널을 감싸는 껍데기(shell)라는 의미에서 이름이 붙었다. Rocky Linux와 Ubuntu 모두 기본 Shell은 Bash(Bourne Again SHell) 다.

echo $SHELL       # 현재 로그인 Shell
cat /etc/shells   # 시스템에서 사용 가능한 Shell 목록

5-2. 명령어 실행 과정

ls -l /tmp를 입력하면 Bash 내부에서 다음 순서로 처리된다.

명령어 실행 과정 — fork와 execve

핵심은 5~6단계다. Bash는 자신을 복제(fork())해 자식 프로세스를 만들고, 그 자식을 실제 프로그램으로 바꾼다(execve()). 그래서 모든 프로세스에는 부모 프로세스(PPID)가 있다. 이 부모-자식 관계는 관제에서 매우 중요한 판단 근거가 된다.

type cd       # cd is a shell builtin → Bash 내장, 새 프로세스를 만들지 않음
type -a ls    # alias와 실제 경로(/usr/bin/ls) 확인
echo $PATH    # 실행 파일을 찾는 경로 순서
echo $?       # 직전 명령의 종료 코드 (0 = 성공)

5-3. Shell과 Kernel의 관계

Shell은 커널이 아니다. Shell도 사용자 공간에서 동작하는 하나의 프로그램 이며, 실행이 필요할 때 fork(), execve() 같은 System Call로 커널에 요청할 뿐이다.

5-4. 보안관제에서 Shell을 보는 이유

관찰 포인트	의미
`httpd`, `nginx`, `mysqld` 아래에 `sh`/`bash`가 자식 프로세스로 존재	웹 서버는 보통 쉘을 띄우지 않는다 → 웹셸·원격 명령 실행(RCE) 의심
`$PATH` 앞부분에 `/tmp` 같은 쓰기 가능한 경로	가짜 `ls`, `sudo`를 먼저 실행시키는 PATH 하이재킹
`~/.bash_history`가 비어 있거나 `/dev/null`로 링크됨	흔적 삭제 시도 가능성
서비스 계정의 로그인 Shell이 `/bin/bash`	원래 `/sbin/nologin`이어야 할 계정이 로그인 가능한 상태

6. Linux 파일 시스템

Linux는 거의 모든 것을 파일로 다룬다. 일반 파일뿐 아니라 장치(/dev/sda), 프로세스 정보(/proc/1234)도 파일 형태로 접근한다. 디렉터리는 /(루트) 하나에서 시작하는 트리 구조다.

Linux 디렉터리 구조와 보안관제 핵심 경로

디렉터리	역할
`/boot`	커널 이미지, GRUB 설정
`/dev`	장치 파일
`/etc`	시스템·서비스 설정
`/home`	일반 사용자 홈 디렉터리
`/opt`	추가 설치 소프트웨어
`/proc`	실행 중인 프로세스·커널 정보 (가상 파일 시스템)
`/root`	root 계정 홈 디렉터리
`/run`	부팅 이후 실행 상태 정보 (재부팅 시 초기화)
`/tmp`	임시 파일 (모든 사용자 쓰기 가능)
`/usr`	프로그램, 라이브러리
`/var`	로그, 캐시, 웹 문서 등 변하는 데이터

Rocky Linux 9, Ubuntu 22.04 이후는 /bin, /sbin, /lib가 /usr 하위로 합쳐진 심볼릭 링크다. ls -l /로 확인할 수 있다.

보안관제 관점에서 중요한 5개 경로

① /etc — 시스템 설정 (지속성의 무대)

파일	확인 포인트
`/etc/passwd`	root 외에 UID 0 계정이 있는지
`/etc/shadow`	root만 읽을 수 있는 권한인지
`/etc/sudoers`, `/etc/sudoers.d/`	`NOPASSWD: ALL` 같은 과도한 권한
`/etc/ssh/sshd_config`	`PermitRootLogin yes` 여부
`/etc/crontab`, `/etc/cron.d/`	모르는 스크립트의 주기 실행
`/etc/systemd/system/`	의심스러운 서비스 추가

공격자는 침투 후 다시 들어올 수 있는 장치(지속성, Persistence) 를 만들려 하는데, 그 대부분이 /etc 설정 변경으로 이루어진다.

② /var/log — 시스템 및 서비스 로그 (증거)

로그	배포판	내용
`/var/log/secure`	Rocky/RHEL	SSH 로그인, sudo, 인증
`/var/log/auth.log`	Ubuntu/Debian	위와 동일
`/var/log/messages` / `syslog`	RHEL / Ubuntu	시스템 전반
`/var/log/audit/audit.log`	공통 (auditd)	System Call 감사, SELinux 거부
`/var/log/httpd/`	웹 서버	웹 요청 (웹 공격 흔적)
`/var/log/wtmp`, `/var/log/btmp`	공통 (바이너리)	로그인 성공 / 실패 (`last`, `lastb`)

로그 파일 크기가 갑자기 0이 되거나 특정 시간대만 비어 있다면 그 자체가 침해 흔적일 수 있다.

③ /home — 사용자 데이터 (행위 흔적)

~/.bash_history: 입력한 명령 이력
~/.ssh/authorized_keys: 비밀번호 없이 접속 가능한 공개키 목록 → 공격자가 자신의 키를 추가하는 대표적인 백도어
~/.bashrc, ~/.bash_profile: 로그인 시 자동 실행 → 악성 명령 삽입 가능

④ /tmp — 임시 파일 (공격자의 작업 공간)

모든 사용자가 쓸 수 있기 때문에, 권한이 낮은 계정(예: 웹 서버의 apache)으로 침투한 공격자가 도구를 내려받고 실행하는 장소로 자주 쓰인다. /var/tmp, /dev/shm도 같은 이유로 함께 확인한다.

ls -la /tmp /var/tmp /dev/shm
ls -ld /tmp    # drwxrwxrwt → 마지막 t = Sticky Bit (다른 사용자의 파일 삭제 불가)

⑤ /proc — 프로세스 및 Kernel 정보 (실시간 상태)

/proc은 디스크가 아니라 커널이 메모리 상태를 파일처럼 보여주는 가상 파일 시스템 이다. 프로세스마다 /proc/<PID>/ 디렉터리가 있다.

ls -l /proc/$$/exe                          # 현재 쉘의 실제 실행 파일
cat /proc/$$/cmdline | tr '\0' ' '; echo    # 실행 명령줄
ls -l /proc/$$/fd                           # 열고 있는 파일·소켓

실무에서 자주 쓰는 방법은 실행 파일이 삭제된 채 동작 중인 프로세스 를 찾는 것이다. 공격자가 악성 파일을 실행한 뒤 파일을 지워도, 프로세스는 계속 살아 있고 /proc에는 (deleted) 표시가 남는다.

sudo ls -l /proc/*/exe 2>/dev/null | grep deleted

7. 실제 Linux 실습

Rocky Linux 9 서버에 SSH로 접속해 "이 서버가 지금 어떤 상태인가"를 확인했다. 침해사고 분석에서 서버에 처음 접속했을 때 가장 먼저 실행하는 명령어들 과 거의 같다.

아래 출력은 Rocky Linux 9 기준의 출력 형식 예시 다. 버전 번호처럼 환경마다 달라지는 값은 x로 표시했고, 긴 출력은 설명에 필요한 항목만 남겼다.

7-1. `uname -a` — 커널 정보

uname -a

Linux rocky 5.14.0-xxx.el9_x.x86_64 #1 SMP PREEMPT_DYNAMIC ... x86_64 x86_64 x86_64 GNU/Linux

무엇을 확인하는가: 커널 이름, 호스트명, 커널 버전, 아키텍처
관제에서 왜 필요한가: 커널 버전으로 권한 상승 취약점의 영향 여부를 판단한다. 호스트명은 SIEM 이벤트의 host.name과 대조해 분석 대상 서버가 맞는지 확인하는 데 쓴다.

7-2. `hostnamectl` — 호스트·OS 정보

hostnamectl

 Static hostname: rocky
  Virtualization: vmware
Operating System: Rocky Linux 9.x (Blue Onyx)
          Kernel: Linux 5.14.0-xxx.el9_x.x86_64
    Architecture: x86-64

무엇을 확인하는가: 호스트명, 가상화 여부, 배포판·버전, 커널을 한 번에
관제에서 왜 필요한가: 배포판을 알아야 로그 경로(secure vs auth.log)와 명령어(dnf vs apt)를 정확히 고를 수 있다.

7-3. `whoami` / `id` — 현재 권한

whoami
id

roror
uid=1000(roror) gid=1000(roror) groups=1000(roror),10(wheel)

무엇을 확인하는가: 현재 사용자, UID/GID, 소속 그룹
관제에서 왜 필요한가: uid=0이면 root 권한이다. wheel(Rocky)·sudo(Ubuntu) 그룹이면 sudo로 root 권한을 얻을 수 있다. 탈취된 계정이 어디까지 갈 수 있는가 가 피해 범위를 결정한다.

7-4. `pwd` / `ls -la` — 위치와 숨김 파일

pwd
ls -la

무엇을 확인하는가: 현재 작업 경로, 숨김 파일(.으로 시작)을 포함한 목록과 권한·소유자·수정 시각
관제에서 왜 필요한가: pwd는 증거 파일을 다루기 전 작업 위치를 확인하는 습관이다. ls -la로 /tmp/.x 같은 숨김 파일, 실행 권한이 붙은 의심 파일, 소유자가 이상한 파일을 찾는다.

7-5. `ps aux` — 실행 중인 프로세스

ps aux | head -15
ps aux --sort=-%cpu | head -10   # CPU 사용률 상위
ps -ef --forest | less           # 부모-자식 관계를 트리로

USER   PID %CPU %MEM    VSZ   RSS TTY   STAT START  TIME COMMAND
root     1  0.0  0.3 ...        ?     Ss   09:00  0:01 /usr/lib/systemd/systemd ...
root   812  0.0  0.2 ...        ?     Ss   09:00  0:00 sshd: /usr/sbin/sshd -D ...
apache 945  0.0  0.5 ...        ?     S    09:00  0:00 /usr/sbin/httpd -DFOREGROUND

무엇을 확인하는가: 실행 계정(USER), PID, 자원 사용률, 실행 명령(COMMAND)
관제에서 왜 필요한가: apache 계정으로 실행된 bash, /tmp에서 실행된 프로그램, CPU를 과도하게 쓰는 프로세스(채굴 악성코드), nc -e·bash -i 같은 리버스 쉘 패턴을 찾는다.

7-6. `ss -tulnp` — 열린 포트와 연결

sudo ss -tulnp   # LISTEN 중인 포트와 프로세스
sudo ss -tanp    # 현재 TCP 연결 전체 (ESTAB 포함)

Netid State  Local Address:Port  Peer Address:Port  Process
tcp   LISTEN 0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=812,fd=3))
tcp   LISTEN 0.0.0.0:80          0.0.0.0:*          users:(("httpd",pid=945,fd=4))

옵션	의미
`-t` / `-u`	TCP / UDP
`-l`	LISTEN 상태만
`-n`	이름 변환 없이 숫자로 (IP, 포트)
`-p`	소켓을 가진 프로세스 표시 (전체를 보려면 root 권한 필요)

무엇을 확인하는가: 서버가 열어 둔 포트와 그 포트를 사용하는 프로세스
관제에서 왜 필요한가: 업무와 무관한 LISTEN 포트는 백도어 가능성이 있다. 서버가 외부로 먼저 연결한 ESTAB 세션 중 모르는 IP가 있으면 리버스 쉘·C2 통신 을 의심한다.

실습 정리

순서	명령어	답하는 질문
1	`uname -a`, `hostnamectl`	어떤 시스템인가
2	`whoami`, `id`	어떤 권한인가
3	`pwd`, `ls -la`	어디에 무엇이 있는가
4	`ps aux`	무엇이 실행 중인가
5	`ss -tulnp`	누구와 통신하는가
6	로그 (`/var/log/secure`, `journalctl`)	과거에 무슨 일이 있었는가

8. 보안관제 관점

Q1. 보안관제 담당자가 Linux를 왜 알아야 하는가?

SIEM 경보는 "무엇이 의심된다"는 신호일 뿐이다. 경보가 실제 공격(정탐)인지 정상 행위(오탐)인지 판단하려면 원본 로그와 서버 상태를 확인해야 한다. 대부분의 서버가 Linux이므로 로그 위치, 프로세스 구조, 권한 체계를 모르면 판단 근거를 제시할 수 없다.

Q2. 공격자가 Linux 서버에 침투하면 어떤 흔적이 남는가?

공격 단계	남는 흔적	확인 위치
초기 침투	SSH 로그인 실패 반복 후 성공, 비정상 웹 요청	`/var/log/secure`, 웹 access_log
실행	웹 서버 하위 쉘, `/tmp` 내 실행 파일	`ps`, `/tmp`
권한 상승	sudo 사용, SUID 파일 실행	`/var/log/secure`, `audit.log`
지속성	cron 등록, 서비스 추가, `authorized_keys` 추가	`/etc/cron*`, `/etc/systemd/system`, `~/.ssh`
외부 통신	외부 IP로의 ESTAB 연결	`ss -tanp`
흔적 삭제	로그 크기 0, history 삭제	`/var/log`, `~/.bash_history`

Q3. 어떤 로그를 확인하는가?

인증 로그(secure/auth.log) → 시스템 로그(messages/syslog, journalctl) → 감사 로그(audit.log) → 애플리케이션 로그(웹·DB) 순으로 범위를 넓힌다. 로그인 기록은 last, lastb로 교차 확인한다.

sudo tail -n 20 /var/log/secure
sudo journalctl -u sshd --since "1 hour ago"
last -n 10          # 최근 로그인 성공
sudo lastb -n 10    # 최근 로그인 실패

Q4. 어떤 프로세스를 확인하는가?

부모가 웹 서버·DB인 쉘 프로세스
/tmp, /dev/shm, /var/tmp에서 실행된 프로세스
실행 파일이 삭제된(deleted) 프로세스
CPU를 비정상적으로 많이 쓰는 프로세스
이름은 정상(kworker, sshd)처럼 보이지만 실행 경로가 이상한 프로세스

Q5. 어떤 네트워크 연결을 확인하는가?

업무와 무관한 LISTEN 포트
서버에서 외부로 먼저 나간 연결 (서버는 보통 연결을 "받는" 쪽이다)
알려진 악성 IP·도메인(IOC)과의 연결
nc, bash, python 같은 프로세스가 소켓을 가진 경우

9. SOC 실무 연결

Linux 서버에서 보안 이벤트가 발생했을 때 보안관제 담당자는 로그 한 줄만 보고 판단하지 않는다. 로그인 기록, 실행 중인 프로세스, 네트워크 연결, 사용자 계정, 시스템 설정 을 함께 확인해 공격 여부를 판단한다. 이 과정을 네 단계로 정리하면 다음과 같다.

단계	핵심 질문	Linux에서 확인하는 것
Logs	무엇이 기록되었나	`/var/log/secure`, `journalctl`, `audit.log`
Indicators	무엇이 의심스러운가	출발지 IP, 시도 계정, 해시, 도메인 (IOC)
Root Cause	실제로 무슨 일이 있었나	로그인 성공 여부, 프로세스 트리, 네트워크 연결
Response	어떻게 보존하고 막나	증적 사본·해시, 차단, 계정 잠금, 보고

아래는 Kali(10.0.0.128)에서 Rocky Linux 서버(10.0.0.200)로 SSH 무차별 대입(Brute Force)이 들어온 상황을 가정한 흐름이다. 실제 공격 재현과 분석은 이 시리즈의 SSH Brute Force 편에서 다룬다.

Linux 서버 보안 이벤트 분석 흐름

단계별로 사용하는 명령어는 다음과 같다.

# [Logs → Indicators] 실패 로그와 출발지 IP 집계
sudo grep "Failed password" /var/log/secure | tail -5
sudo grep "Failed password" /var/log/secure \
  | grep -oE 'from [0-9.]+' | sort | uniq -c | sort -rn

# [Root Cause] 같은 IP에서 로그인에 성공한 기록이 있는가
sudo grep "Accepted" /var/log/secure | grep "10.0.0.128"

# [Root Cause] 로그인 이후 생성된 프로세스와 현재 연결
ps -ef --forest | less
sudo ss -tanp | grep 10.0.0.128

# [Response] 증적 보존 — 원본은 건드리지 않고 사본 + 해시
sudo mkdir -p /root/evidence
sudo cp -p /var/log/secure /root/evidence/secure_$(date +%F_%H%M)
sudo sh -c 'sha256sum /root/evidence/secure_*'

# [Response] 출발지 IP 차단 (firewalld, 런타임 적용)
sudo firewall-cmd --add-rich-rule='rule family="ipv4" source address="10.0.0.128" drop'

판단 기준은 "실패 로그만 있는가, 같은 출발지에서 성공 로그도 있는가" 다. 실패만 있다면 공격 시도로 보고 차단·모니터링한다. 성공 기록이 있다면 침해 의심 사고로 등급을 올리고, 프로세스·네트워크·계정·설정 확인과 증적 수집을 반드시 수행한다.

10. 핵심 정리

Linux는 Hardware → Kernel → System Call → Shell → Application → User 계층으로 동작한다.
User Space와 Kernel Space는 분리되어 있고, 모든 요청은 System Call 을 거친다. 그래서 auditd·EDR은 System Call을 감시한다.
Shell은 커널이 아니라 명령을 해석해 fork() → execve() 로 실행하는 프로그램이다. 모든 프로세스에는 부모가 있다.
웹 서버 아래에 쉘이 보이면 웹셸·RCE를 의심한다.
배포판마다 로그 경로가 다르다. Rocky는 /var/log/secure, Ubuntu는 /var/log/auth.log.
관제 핵심 경로: /etc(설정·지속성), /var/log(증거), /home(사용자 흔적), /tmp(공격자 작업 공간), /proc(실시간 상태).
서버 상태 확인 순서: uname/hostnamectl → whoami/id → ps aux → ss -tulnp → 로그.
분석 흐름은 Logs → Indicators → Root Cause → Response. 증적은 원본을 건드리지 않고 사본 + 해시 로 남긴다.

11. 다음 글 예고

이번 글에서는 Linux의 전체 구조를 한 번에 훑었다. 다음 글 「Linux Kernel의 역할」 에서는 커널의 프로세스·메모리·파일 시스템·네트워크·장치 관리를 하나씩 더 자세히 살펴보고, uname, lsmod, dmesg로 커널 상태를 확인하는 방법과 커널 취약점이 보안관제에서 어떤 의미를 갖는지 정리한다.

시리즈 로드맵 (50편, 최종)

Part	범위	주요 내용	관제에서의 역할
1. Linux 기본 구조	1 ~ 10편	Kernel, Shell, User/Kernel Space, System Call, 파일 시스템·디렉터리, 부팅, 환경변수, 시스템 정보	시스템이 어떻게 동작하는지 이해
2. 파일·명령어·권한	11 ~ 20편	파일·경로, 파일 종류, inode, 권한·chmod·SUID, chown, 사용자·그룹, sudo·su, 최소 권한	누가 무엇을 할 수 있는지 판단
3. 명령어 활용	21 ~ 30편	grep, find, head·tail, sort·uniq, cut·awk, sed, 파이프라인, Shell Script, 시스템 분석, 보안 점검	로그·파일에서 증거 추출
4. 프로세스·서비스·리소스	31 ~ 40편	프로세스, ps, top, Signal·kill, Parent/Child, systemd, systemctl, cron, CPU·Memory, Disk	실행 중인 것과 지속성 탐지
5. 네트워크·보안·SOC	41 ~ 50편	네트워크 구조, TCP/UDP·Port, Socket, ss·ip, SSH, firewalld, SELinux, 로그·journalctl, SSH Brute Force 분석, 보안관제 실습	통신·흔적 분석과 대응

전체 목차

Part 1 — 1. Linux 기본 구조 이해 · 2. Kernel의 역할 · 3. Shell과 Bash · 4. User Space와 Kernel Space · 5. System Call · 6. 파일 시스템 구조 · 7. 디렉터리 구조 · 8. 부팅 과정 · 9. 환경변수 · 10. 시스템 정보 확인
Part 2 — 11. 파일과 디렉터리 관리 · 12. 절대경로와 상대경로 · 13. 파일 종류 · 14. inode와 파일 시스템 · 15. 파일 권한 · 16. chmod와 특수 권한 · 17. chown과 소유권 · 18. 사용자와 그룹 · 19. sudo와 su · 20. 최소 권한 원칙
Part 3 — 21. grep · 22. find · 23. head와 tail · 24. sort와 uniq · 25. cut과 awk · 26. sed · 27. 파이프라인과 리다이렉션 · 28. Shell Script 기초 · 29. 명령어 조합 시스템 분석 · 30. 보안 점검
Part 4 — 31. 프로세스 · 32. ps · 33. top · 34. Signal과 kill · 35. Parent / Child · 36. systemd · 37. systemctl · 38. cron · 39. CPU·Memory · 40. Disk
Part 5 — 41. 네트워크 구조 · 42. IP·TCP·UDP·Port · 43. Socket · 44. ss와 ip · 45. SSH · 46. Firewalld · 47. SELinux · 48. 로그와 journalctl · 49. SSH Brute Force 분석 · 50. 보안관제 실습

참고 자료

The Linux Kernel documentation — https://docs.kernel.org/
syscalls(2), Linux manual page — https://man7.org/linux/man-pages/man2/syscalls.2.html
hier(7): 파일 시스템 계층 설명 — https://man7.org/linux/man-pages/man7/hier.7.html
proc(5): /proc 파일 시스템 — https://man7.org/linux/man-pages/man5/proc.5.html
Filesystem Hierarchy Standard 3.0 — https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
GNU Bash Reference Manual — https://www.gnu.org/software/bash/manual/bash.html
ss(8), Linux manual page — https://man7.org/linux/man-pages/man8/ss.8.html

changseop lee

코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

다음 포스트