Linux 시스템 호출(System Call)

changseop lee·2026년 9월 23일
Linux 기본 구조 이해SocSystemCallauditdlinux리눅스리눅스 시스템 기초보안관제

리눅스 시스템 기초

목록 보기
5/250

리눅스 시스템 기초 · 입문편 — 본문의 "N편"은 입문 과정 번호다. 번호별 글과 전체 250편 구성은 통합 로드맵에서 확인할 수 있다.

리눅스 시스템 기초 5 / 50 · Part 1. Linux 기본 구조
실습 환경: Rocky Linux 9 (10.0.0.200)
이전 글: 4. User Space와 Kernel Space

1. 들어가며

4편에서 User Mode 프로그램은 하드웨어나 다른 프로세스의 메모리에 직접 접근할 수 없다고 정리했다. 그렇다면 cat은 어떻게 디스크의 파일을 읽고, curl은 어떻게 네트워크로 데이터를 보낼까? 답은 System Call(시스템 호출) 이다.

System Call은 보안관제에서 특히 중요하다. 파일 열기, 프로그램 실행, 네트워크 연결 같은 모든 행위가 System Call을 거치기 때문에, 이 지점을 기록하면 공격자가 쉽게 우회할 수 없는 행위 기록을 얻을 수 있다. auditd, EDR, Sysmon for Linux 같은 도구가 모두 이 원리를 이용한다.

이번 글에서 답할 질문:

  • System Call은 무엇이고 어떤 경로로 호출되는가?
  • strace로 프로그램의 System Call을 어떻게 관찰하는가?
  • auditd로 System Call을 어떻게 기록하고 조회하는가?

2. 핵심 개념

2-1. System Call이란

System Call은 User Mode 프로그램이 커널에 서비스를 요청하는 공식 인터페이스 다. 각 System Call에는 번호가 있고, 프로그램은 번호와 인자를 CPU 레지스터에 넣은 뒤 syscall 명령으로 커널에 진입한다.

대부분의 프로그램은 System Call을 직접 부르지 않고 C 라이브러리(glibc)의 래퍼 함수 를 통해 호출한다. 예를 들어 C의 open() 함수는 내부적으로 openat System Call을 호출한다.

2-2. 주요 System Call 분류

분류대표 System Call하는 일보안 의미
파일openat, read, write, unlink, rename, chmod파일 열기·읽기·쓰기·삭제·권한 변경민감 파일 접근, 증거 삭제
프로세스fork/clone, execve, exit, kill프로세스 생성·실행·종료어떤 프로그램이 실행되었나
네트워크socket, connect, bind, listen, accept소켓 생성·연결·대기외부 연결, 백도어 포트
권한setuid, setgid, capset실행 권한 변경권한 상승
커널init_module, finit_module, ptrace모듈 로드, 다른 프로세스 조작루트킷, 프로세스 인젝션

System Call 설명서는 매뉴얼 섹션 2 에 있다. man 2 openat처럼 조회한다.

3. 동작 원리

System Call 호출 경로와 관찰 지점

  1. 프로그램이 glibc 함수(open())를 호출한다.
  2. glibc가 System Call 번호(x86_64에서 openat은 257)와 인자를 레지스터에 넣는다.
  3. syscall 명령으로 CPU가 Kernel Mode로 전환된다.
  4. 커널은 번호로 처리 함수를 찾고, VFS를 거쳐 권한을 검사 한 뒤 작업을 수행한다.
  5. 감사 규칙이 있으면 auditd가 이 호출을 기록 한다.
  6. User Mode로 돌아오며 결과를 반환한다. 성공이면 파일 디스크립터 번호, 실패면 -1과 오류 코드(errno, 예: EACCES 권한 없음, ENOENT 파일 없음).

strace와 auditd의 차이

구분straceauditd
원리ptrace로 대상 프로세스를 추적커널 감사 서브시스템
범위지정한 프로세스(와 자식)시스템 전체 (규칙 기반)
용도분석·디버깅 (일시적)상시 감사 기록 (관제)
성능 영향대상 프로세스가 크게 느려짐규칙이 적으면 작음
결과 위치터미널 / 파일/var/log/audit/audit.log

4. 실습

4-1. strace로 관찰

sudo dnf install -y strace

# 1) cat이 호출하는 파일 관련 System Call
strace -e trace=openat,read,write cat /etc/hostname

# 2) 어떤 System Call을 몇 번 호출했는지 요약
strace -c ls /etc > /dev/null

# 3) 프로세스 생성·실행 추적 (-f: 자식 프로세스까지)
strace -f -e trace=process bash -c 'id'

# 4) 권한 없는 파일 접근 시 반환값
strace -e trace=openat cat /etc/shadow

4-2. auditd로 기록

# 상태 확인 (Rocky Linux는 기본 설치·활성화)
sudo systemctl status auditd
sudo auditctl -s

# 감사 규칙 파일 작성
sudo vi /etc/audit/rules.d/soc.rules
# /etc/audit/rules.d/soc.rules
# 민감 파일 감시 (-p: r 읽기, w 쓰기, a 속성 변경)
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p rwa -k shadow_access
-w /etc/sudoers -p wa -k sudoers_change
# 사용자 로그인 세션에서 실행된 모든 프로그램
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -k user_exec
sudo augenrules --load      # rules.d 파일을 합쳐 적용
sudo auditctl -l            # 적용된 규칙 확인

# 이벤트 발생
sudo cat /etc/shadow > /dev/null

# 조회
sudo ausearch -k shadow_access -i | tail -20
sudo aureport -x --summary | head      # 실행 파일별 요약

5. 결과 분석

아래 출력은 형식 설명용 예시다.

① strace — 권한 없는 파일

openat(AT_FDCWD, "/etc/shadow", O_RDONLY) = -1 EACCES (Permission denied)

= -1 EACCES는 커널이 권한 검사에서 거부했다는 뜻이다. 일반 사용자의 /etc/shadow 접근 시도가 audit 로그에 반복적으로 남는다면 정보 수집(권한 탐색) 행위 를 의심할 수 있다.

② strace -c 요약

% time     seconds  usecs/call     calls    errors syscall
 xx.xx    0.000xxx          x        xx           getdents64
 xx.xx    0.000xxx          x        xx         x openat

어떤 System Call을 많이 쓰는지로 프로그램의 성격(파일 탐색형, 네트워크형)을 빠르게 파악할 수 있다.

③ ausearch -i 결과 읽기

type=PROCTITLE msg=audit(09/23/2026 10:21:07.123:512) : proctitle=cat /etc/shadow
type=PATH ... name=/etc/shadow ... mode=file,000 ouid=root
type=SYSCALL ... syscall=openat success=yes exit=3 auid=roror uid=root
      comm=cat exe=/usr/bin/cat key=shadow_access
필드의미관제에서의 쓰임
msg=audit(시각:일련번호)이벤트 시각과 ID같은 ID의 레코드가 하나의 이벤트
syscall호출된 System Call어떤 행위인가
success / exit성공 여부, 반환값시도인지 성공인지
auid최초 로그인 사용자 (sudo 후에도 유지)실제 책임 계정
uid / euid현재 실행 권한root로 실행되었는가
comm / exe프로세스 이름 / 실행 파일 경로어떤 프로그램이 했는가
key규칙에 붙인 이름SIEM 검색·경보 조건

auid=roror uid=root는 "roror 계정으로 로그인한 사용자가 sudo로 root 권한을 얻어 실행했다"는 뜻이다. sudo를 거쳐도 원래 사용자를 추적할 수 있다 는 점이 auditd의 가장 큰 장점이다.

6. 보안 관점

공격 행위관련 System Call탐지 규칙 예
계정 정보 탈취 시도openat on /etc/shadow-w /etc/shadow -p r
백도어 계정 추가openat(쓰기), rename on /etc/passwd-w /etc/passwd -p wa
악성 프로그램 실행execve-S execve -F auid>=1000
권한 상승setuid, setresuid-S setuid -F a0=0 -F auid>=1000
증거 삭제unlink, unlinkat on /var/log-w /var/log/ -p wa
루트킷 로드init_module, finit_module2편 참고

System Call 감사는 강력하지만 모든 것을 기록하면 로그가 폭증 한다. 관제 환경에서는 민감 파일, 사용자 세션의 execve, 권한 변경처럼 의미 있는 지점만 골라 규칙을 설계한다.

7. SOC / 보안관제 활용

7-1. SIEM 연계 흐름

커널 감사 훅 → auditd → /var/log/audit/audit.log
   → Filebeat(auditd 모듈) 또는 Wazuh agent
   → SIEM 인덱스 → 규칙: key=shadow_access AND auid!=root 계정
   → 경보 → 분석가 확인

7-2. 분석 시나리오

[Alert]    key=shadow_access, success=no 반복 (auid=webadmin)
   ↓
[IOC]      auid, 시각, exe, 원격 로그인 IP(secure 로그와 시각 대조)
   ↓
[분석]     같은 auid의 user_exec 이벤트 조회 → 실행 명령 목록 복원
           ausearch -k user_exec -ua webadmin -i
   ↓
[Root Cause] 탈취된 계정으로 권한 탐색 중 / 운영자 실수 구분
   ↓
[Response]  계정 잠금 및 비밀번호 변경, 해당 IP 차단, 로그 증적 보존

7-3. 자주 하는 실수

실수결과예방
auditctl로만 규칙 추가재부팅 시 사라짐/etc/audit/rules.d/에 파일로 저장 후 augenrules --load
arch=b64만 지정32비트 호출 누락필요 시 arch=b32 규칙도 추가
ausearch 없이 raw 로그만 봄UID·시각이 숫자라 해석 어려움-i 옵션으로 해석
모든 openat 기록로그 폭증, 디스크 부족경로·key 기반으로 범위 제한

8. 핵심 정리

  • System Call은 User Mode 프로그램이 커널에 요청하는 유일한 공식 통로 다.
  • 프로그램 → glibc 래퍼 → syscall 명령 → 커널 처리 → 반환 순으로 동작한다.
  • strace는 특정 프로세스 분석용, auditd는 시스템 전체 상시 감사용이다.
  • audit 로그에서 auid는 sudo를 거쳐도 유지되는 원래 로그인 사용자 다.
  • 민감 파일 감시(-w)와 execve 감사로 "누가 무엇을 실행·접근했는가"를 기록한다.
  • 규칙은 /etc/audit/rules.d/에 저장해야 재부팅 후에도 유지된다.

9. 다음 글

다음 글 「6. Linux 파일 시스템 구조」 에서는 이번 글의 openat이 커널 안에서 거쳐 가던 VFS와 실제 파일 시스템(xfs, ext4) 을 다룬다. 디스크·파티션·파일 시스템·마운트 포인트의 관계와, /tmp에 noexec 같은 마운트 옵션을 거는 보안상의 이유를 정리한다.

참고 자료

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

User Space와 Kernel Space

다음 포스트

Linux 파일 시스템 구조

0개의 댓글