Osquery에서 audit 프레임워크를 활성화하면 기본적으로 audit.rules에서 설정한 규칙 외에도 다양한 이벤트가 자동으로 수집됩니다. 이 중 일부는 Linux auditd와 유사하지만, Osquery는 추가적인 이벤트를 생성할 수 있습니다.
1. 기본적으로 수집되는 이벤트
Osquery가 Audit 프레임워크를 활용하여 기본적으로 수집하는 이벤트는 다음과 같습니다.
1.1. Process Events (프로세스 이벤트)
execve(새로운 프로세스 실행)fork및clone(프로세스 생성)exit(프로세스 종료)setuid,setgid(권한 변경)
1.2. File Events (파일 접근 및 변경)
open,openat(파일 열기)unlink,unlinkat(파일 삭제)rename,renameat(파일 이름 변경)chmod,chown,chgrp(파일 권한 변경)
1.3. Network Events (네트워크 연결)
connect(소켓 연결)bind(소켓 바인딩)accept(소켓 수락)sendto,recvfrom(데이터 송수신)
1.4. User & Privilege Events (사용자 및 권한 변경)
setuid,setgid(UID, GID 변경)capset(Capability 변경)execve를 통한 권한 상승
2. Osquery의 추가적인 이벤트 탐지
Audit Rules 외에도 Osquery는 자체적으로 추가적인 탐지 기능을 제공합니다.
2.1. 사용자 활동 이벤트
Osquery는 user_events 테이블을 통해 사용자의 세션 관련 이벤트를 추적합니다.
login,logoutfailed_login_attemptsuser_added,user_deletedsudo및 권한 상승 시도
2.2. 크론 작업 실행 감지
crontab파일 변경- Scheduled Task 실행 (
cron_jobs테이블 활용 가능)
2.3. Kernel 모듈 로드 및 언로드 감지
init_module(모듈 로드)delete_module(모듈 언로드)
2.4. Security Configuration 변경 감지
auditctl을 통한 audit 설정 변경iptables정책 변경 (firewall_rules테이블 활용)sysctl값 변경 (sysctl테이블 활용)
2.5. System Integrity (시스템 무결성) 체크
Osquery의 hash 및 file_integrity_monitoring 기능을 활용하면 특정 파일 및 디렉터리의 변경을 감지할 수 있음.
2.6. Container Activity (컨테이너 활동 감시)
- Docker 컨테이너 실행 (
docker_containers,docker_processes테이블 활용) - 컨테이너 내부 프로세스 감시
- Kubernetes 관련 프로세스 탐지
3. Audit Logs와 Osquery Rules의 결합
Osquery에서 audit 플래그를 활성화하면 기본적인 Audit 이벤트를 Osquery events 테이블에서 활용할 수 있습니다. 그러나 추가적인 탐지를 위해서는 다음을 활용해야 합니다.
file_events+process_events테이블을 조합하여 특정 프로세스가 민감한 파일을 열거나 수정하는 경우 감지scheduled_query를 사용하여sysctl값이 임의로 변경되는지 확인users+user_events테이블을 조합하여 최근 추가된 사용자의 활동 분석iptables_rules테이블과firewall_rules변경 감지
4. 실전 활용 예제
4.1. 특정 사용자의 sudo 사용 감지
SELECT * FROM user_events WHERE action = 'sudo';4.2. 특정 파일에 대한 무결성 검사
SELECT * FROM file_events WHERE path = '/etc/passwd' OR path = '/etc/shadow';4.3. 실행된 모든 프로세스 모니터링
SELECT * FROM process_events WHERE path NOT LIKE '/usr/bin/%';4.4. 네트워크 연결 감지
SELECT * FROM socket_events WHERE family = 'AF_INET';Osquery에서 Audit Rules 외에도 다양한 탐지 이벤트를 기본적으로 수집하며, 이를 활용하여 보안 위협을 탐지할 수 있습니다.
- 프로세스 실행 및 권한 변경 감지
- 파일 및 디렉터리 변경 탐지
- 네트워크 연결 모니터링
- 보안 설정 변경 감지
- 컨테이너 및 시스템 서비스 모니터링
위 내용을 활용하면 보다 강력한 보안 감시 체계를 구축할 수 있습니다.
기본 내장된 Audit 룰이 존재하는가?
auditd가 실행 중이라면, 커널의 일부 이벤트는 기본적으로 감사 로그(audit.log)에 기록됩니다.
이것은 audit.rules 파일이나 auditctl을 통해 설정한 사용자 정의 규칙이 없어도 발생할 수 있습니다.
auditd가 실행 중인지 확인systemctl status auditdaudit.rules파일 내용 확인
또는cat /etc/audit/rules.d/audit.rulescat /etc/audit/audit.rules- 위 파일들이 비어있다면 사용자 정의 규칙이 없는 것입니다.
- Audit 백엔드가 로드한 기본 룰 확인
auditctl -s- 예제 출력
enabled 1 failure 1 pid 1234 rate_limit 0 backlog_limit 8192 lost 0 backlog 0 enabled가1이면auditd가 활성화된 상태입니다.
- 예제 출력
기본적으로 감사되는 이벤트
설정한 룰이 없더라도 auditd는 다음과 같은 기본 이벤트를 로깅할 수 있습니다.
1) 부팅 시 로드되는 기본 규칙
- 일부 Linux 배포판에서는
/etc/audit/rules.d/에 설정 파일이 없어도, 기본적인 보안 이벤트가auditd에 의해 기록됩니다. audit.rules파일이 비어있더라도, 커널은 일부 이벤트를 자체적으로 기록할 수 있습니다.
2) SELinux 및 정책 기반 로깅
- SELinux가 활성화된 경우, 특정 보안 이벤트가
audit.log에 기록될 수 있습니다. - 다음 명령어로 SELinux 상태를 확인
getenforceEnforcing이면 SELinux 정책이 강제 적용 중인 상태입니다.
- SELinux 정책으로 인해 기록되는 로그 확인
ausearch -m AVC
3) 커널에서 기본적으로 로깅하는 보안 이벤트
auditd는 로그인, 사용자 인증, 비정상적인 프로세스 종료 등의 기본 보안 이벤트를 기록할 수 있습니다.- 예를 들어,
su또는sudo명령을 실행하면audit.log에 기록됩니다. - 최근 감사 로그 확인
ausearch -m USER_AUTH,USER_LOGIN,USER_ACCT -ts today
어떤 이벤트가 로깅되고 있는지 확인하는 방법
1) 로그 내용 확인
tail -f /var/log/audit/audit.log또는 특정 필터를 적용하여 확인
ausearch -ts today2) 로그가 기록되는 원인 분석
특정 유형의 로그를 확인하려면 다음을 실행합니다.
(1) 사용자 로그인 이벤트 확인
ausearch -m USER_LOGIN -ts today(2) 실행된 명령어 감사
ausearch -m EXECVE -ts today(3) 파일 접근 감사
ausearch -m PATH -ts today(4) 시스템 콜 감사
ausearch -m SYSCALL -ts today사용자 정의 룰 추가 및 확인
현재 등록된 룰이 없는 상태에서 특정 이벤트를 추가로 감사하려면 auditctl을 사용하여 규칙을 추가할 수 있습니다.
예제: 특정 파일에 대한 접근 감사 추가
auditctl -w /etc/passwd -p wa -k passwd_changes위 명령어를 실행하면 /etc/passwd 파일이 변경될 때 감사 로그에 기록됩니다.
룰이 정상적으로 추가되었는지 확인
auditctl -l추가한 룰을 영구적으로 유지하려면 /etc/audit/rules.d/audit.rules에 추가해야 합니다.
auditctl -l이 "No rules"라고 나와도,audit.log가 기록될 수 있음.auditd는 기본적으로 로그인, 사용자 인증, 프로세스 종료 등의 이벤트를 기록함.- SELinux나 기본 커널 보안 로깅으로 인해 일부 이벤트가 자동으로 기록될 수 있음.
ausearch를 사용하여 어떤 이벤트가 기록되고 있는지 분석 가능.- 사용자 정의 감사 규칙을 추가하려면
auditctl로 설정하거나/etc/audit/rules.d/audit.rules에 등록해야 함.
기본적인 커널 관련 이벤트 로그가 기록되는 이유는, auditd가 실행 중일 때 커널이 기본적으로 생성하는 감사(audit) 이벤트가 있기 때문입니다. auditctl -l에 표시되지 않더라도 커널 수준에서 로깅하는 이벤트가 존재할 수 있습니다.
기본적인 Audit 로그를 남기지 않도록 설정하는 방법
1. auditd 비활성화 (권장하지 않음)
Audit 기능을 완전히 끄는 방법은 auditd 서비스를 중지하는 것입니다. 하지만 보안상 권장되지 않으며, 일부 시스템에서는 완전히 비활성화되지 않을 수도 있습니다.
1-1. 일시적으로 중지
systemctl stop auditd1-2. 부팅 시 비활성화
systemctl disable auditd부팅 시 auditd를 실행하지 않도록 설정할 수 있습니다.
하지만 이 방법은 일부 배포판에서 audit=1이 기본값으로 설정되어 있을 경우, auditd가 자동으로 다시 활성화될 수 있습니다.
2. 커널 부팅 옵션에서 audit 기능 비활성화 (권장)
Audit 기능을 완전히 비활성화하려면 커널 부팅 옵션에서 audit=0을 설정해야 합니다.
2-1. 현재 커널에서 audit 상태 확인
cat /proc/cmdline출력 예시
BOOT_IMAGE=/vmlinuz-5.15.0-83-generic root=/dev/sda1 ro audit=1여기에서 audit=1로 설정되어 있으면 기본적으로 audit이 활성화된 상태입니다.
2-2. GRUB 설정 변경
/etc/default/grub파일을 편집합니다.vi /etc/default/grubGRUB_CMDLINE_LINUX옵션에audit=0추가GRUB_CMDLINE_LINUX="quiet splash audit=0"- 설정을 적용합니다.
grub2-mkconfig -o /boot/grub2/grub.cfg # RHEL/CentOS update-grub # Ubuntu/Debian - 시스템 재부팅 후 확인
cat /proc/cmdlineaudit=0이 적용되었는지 확인합니다.
3. audit 로그를 남기지 않도록 필터링 (로그만 삭제)
만약 audit 기능은 유지하되, 특정 로그만 남지 않게 하려면 필터링을 설정할 수 있습니다.
3-1. audit.rules에 필터 추가
echo "-a never,task" >> /etc/audit/rules.d/audit.rules
echo "-a never,user" >> /etc/audit/rules.d/audit.rules이 설정은 사용자 및 태스크 관련 로그를 기록하지 않도록 합니다.
3-2. 설정 적용 후 auditd 재시작
service auditd restart3-3. 설정 확인
auditctl -l4. audit 로그를 /dev/null로 리디렉션
로그가 발생하는 것은 허용하되, 저장되지 않도록 /dev/null로 리디렉션할 수도 있습니다.
ln -sf /dev/null /var/log/audit/audit.log이렇게 하면 audit.log가 더 이상 기록되지 않습니다.
audit rule이 없더라도 커널에서 기본적으로 수집하는 이벤트를 예외 처리(never 규칙 적용)하면 특정 이벤트가 audit.log에 남지 않도록 설정할 수 있습니다. 기본적으로 수집되는 이벤트는 auditctl -l에 표시되지 않지만, 이를 audit.rules에 예외 규칙을 추가하여 차단할 수 있습니다.
기본적으로 수집되는 이벤트 유형
auditd가 기본적으로 수집하는 이벤트는 다음과 같습니다.
| 이벤트 유형 | 설명 | 메시지 ID (ausearch -m) |
|---|---|---|
SYSCALL |
특정 시스템 호출 | SYSCALL |
USER_AUTH |
사용자 인증 | USER_AUTH |
USER_LOGIN |
로그인 이벤트 | USER_LOGIN |
USER_ACCT |
사용자 계정 변경 | USER_ACCT |
AVC |
SELinux 접근 제어 | AVC |
MAC_POLICY_LOAD |
SELinux 정책 로드 | MAC_POLICY_LOAD |
ANOM_ABEND |
비정상 종료 이벤트 | ANOM_ABEND |
CRED_REVOKE |
사용자 인증서 폐기 | CRED_REVOKE |
CONFIG_CHANGE |
시스템 설정 변경 | CONFIG_CHANGE |
SYSTEM_BOOT |
시스템 부팅 | SYSTEM_BOOT |
DAEMON_START |
auditd 시작 | DAEMON_START |
이러한 이벤트는 auditctl -l에는 표시되지 않지만, ausearch 명령어를 사용하면 확인할 수 있습니다.
ausearch -m SYSCALL,USER_AUTH,USER_LOGIN,USER_ACCT -ts today특정 이벤트를 예외 처리하여 로그 남지 않게 하기
이제 특정 이벤트가 기록되지 않도록 audit.rules에 추가할 수 있습니다.
(1) 모든 사용자 관련 이벤트 차단
로그인, 계정 인증 관련 이벤트를 제외하고 싶다면 다음을 추가합니다.
echo "-a never,user" >> /etc/audit/rules.d/audit.rules✅ 적용되는 이벤트: USER_AUTH, USER_LOGIN, USER_ACCT
이 규칙을 추가하면 로그인 및 인증 관련 이벤트가 audit.log에 기록되지 않습니다.
(2) 특정 시스템 콜(syscall) 감사를 비활성화
기본적으로 auditd는 특정 시스템 콜을 감사합니다. 이를 비활성화하려면 다음을 추가합니다.
echo "-a never,exit -S execve" >> /etc/audit/rules.d/audit.rules
echo "-a never,exit -S openat" >> /etc/audit/rules.d/audit.rules
echo "-a never,exit -S connect" >> /etc/audit/rules.d/audit.rules✅ 적용되는 이벤트
execve→ 실행된 프로세스 감사 비활성화 (SYSCALL)openat→ 파일 열기 이벤트 비활성화 (PATH)connect→ 네트워크 연결 이벤트 비활성화 (SYSCALL)
이 설정을 추가하면 실행된 명령어(execve)나 네트워크 연결(connect) 이벤트가 audit.log에 남지 않습니다.
(3) SELinux 감사 로그 제외
SELinux 관련 감사 로그를 제외하려면 다음을 추가합니다.
echo "-a never,task" >> /etc/audit/rules.d/audit.rules
echo "-a never,exit -F msgtype=AVC" >> /etc/audit/rules.d/audit.rules
echo "-a never,exit -F msgtype=MAC_POLICY_LOAD" >> /etc/audit/rules.d/audit.rules✅ 적용되는 이벤트
AVC→ SELinux 접근 거부 이벤트MAC_POLICY_LOAD→ SELinux 정책 변경
(4) 시스템 변경 이벤트 제외
부팅, auditd 시작, 시스템 구성 변경 등의 로그를 남기지 않으려면 다음을 추가합니다.
echo "-a never,exit -F msgtype=SYSTEM_BOOT" >> /etc/audit/rules.d/audit.rules
echo "-a never,exit -F msgtype=DAEMON_START" >> /etc/audit/rules.d/audit.rules
echo "-a never,exit -F msgtype=CONFIG_CHANGE" >> /etc/audit/rules.d/audit.rules✅ 적용되는 이벤트
SYSTEM_BOOT→ 시스템 부팅DAEMON_START→auditd데몬 시작CONFIG_CHANGE→ 시스템 설정 변경
적용 및 확인
(1) audit.rules
규칙을 추가한 후 다음 명령어로 적용합니다.
service auditd restart또는
auditctl -R /etc/audit/rules.d/audit.rules(2) 정상적으로 적용되었는지 확인
auditctl -l이제 auditctl -l에 위에서 추가한 never 규칙이 보일 것입니다.
(3) 로그가 남지 않는지 테스트
ausearch -ts today필터링한 이벤트가 더 이상 audit.log에 기록되지 않아야 합니다.
예외 처리를 해도 남는 이벤트 제거 방법
일부 커널에서 never 옵션을 적용했음에도 여전히 기본 로그가 남을 수 있습니다.
이 경우 부팅 옵션에서 audit=0을 설정하여 완전히 비활성화하는 방법도 고려해야 합니다.
vi /etc/default/grubGRUB_CMDLINE_LINUX에 audit=0 추가
GRUB_CMDLINE_LINUX="quiet splash audit=0"적용 후 GRUB 업데이트
grub2-mkconfig -o /boot/grub2/grub.cfg # RHEL/CentOS
update-grub # Ubuntu/Debian재부팅 후 확인
cat /proc/cmdline출력에 audit=0이 포함되어 있어야 합니다. 이제 불필요한 audit 로그를 효과적으로 제거할 수 있습니다.
auditctl 명령어에서 사용하는 -a 옵션과 -F 옵션에 대한 설명입니다.
1. -a 옵션: 감사 규칙 추가 (Append rule)
-a 옵션은 특정 감사 규칙(Audit rule)을 추가할 때 사용됩니다.-a의 기본 형식은 다음과 같습니다.
auditctl -a [action,list]1.1. -a 옵션의 두 가지 주요 인자
| 옵션 | 설명 |
|---|---|
| action | always 또는 never 를 사용하여 이벤트를 기록할지 여부를 설정 |
| list | task, exit, user 등 특정 이벤트의 종류를 지정 |
1.1.1. action 인자
always: 해당 이벤트를 항상 감사(audit) 로그에 기록never: 해당 이벤트를 감사 로그에 기록하지 않음 (예외 처리)
1.1.2. list 인자
task: 프로세스(task) 생성/종료 시 발생하는 이벤트를 제어exit: 시스템 호출(SYSCALL) 또는 파일 접근(OPEN, EXECVE 등) 이벤트를 제어user: 사용자 관련 이벤트(로그인, 계정 변경 등)를 제어
1.2. -a 옵션의 예제
(1) 모든 사용자 관련 이벤트 감사 중지
auditctl -a never,user✅ 로그인, 인증, 계정 변경과 같은 사용자 관련 이벤트가 감사 로그에 기록되지 않음.
(2) 모든 태스크(task) 관련 이벤트 감사 중지
auditctl -a never,task✅ 프로세스 생성/종료 관련 이벤트가 감사 로그에 기록되지 않음.
(3) 파일 접근(openat) 감사 비활성화
auditctl -a never,exit -S openat✅ 파일 열기(openat syscall) 이벤트가 감사 로그에 기록되지 않음.
2. -F 옵션: 필터 추가 (Filter rule)
-F 옵션은 감사 규칙을 더욱 세부적으로 필터링할 때 사용됩니다.-F를 사용하면 특정 조건을 지정하여 원하는 이벤트만 감사하거나 제외할 수 있습니다.
2.1. -F 옵션의 기본 형식
auditctl -a [action,list] -F [field]=[value]✅ -F 옵션을 사용하면 특정 필드의 값을 기반으로 감사 규칙을 더 정밀하게 설정할 수 있음.
2.2. -F
| 필드 | 설명 |
|---|---|
msgtype |
감사 메시지 유형 지정 (USER_LOGIN, SYSCALL 등) |
arch |
CPU 아키텍처 (b32, b64) |
uid |
사용자 ID 필터링 |
auid |
로그인 사용자 ID (UID 변경 전) |
pid |
특정 프로세스 ID 감시 |
ppid |
부모 프로세스 ID 감시 |
exe |
실행된 프로그램 경로 필터링 |
path |
특정 파일/디렉토리 경로 감시 |
perm |
파일 권한 필터링 (r=읽기, w=쓰기, x=실행, a=속성 변경) |
2.3. -F 옵션의 예제
(1) 로그인 관련 이벤트 차단
auditctl -a never,exit -F msgtype=USER_LOGIN✅ 사용자 로그인 이벤트(USER_LOGIN)가 감사 로그에 기록되지 않음.
(2) 프로세스 실행(execve) 이벤트 차단
auditctl -a never,exit -S execve✅ execve 시스템 호출을 통한 프로세스 실행 이벤트가 감사 로그에 기록되지 않음.
(3) SELinux 정책 변경 로그 차단
auditctl -a never,exit -F msgtype=AVC
auditctl -a never,exit -F msgtype=MAC_POLICY_LOAD✅ SELinux 정책 변경 이벤트(AVC, MAC_POLICY_LOAD)가 감사 로그에 기록되지 않음.
(4) 특정 사용자의 모든 활동 로그 차단
auditctl -a never,exit -F auid=1001✅ auid=1001인 사용자의 활동이 감사 로그에 기록되지 않음.
(5) 특정 파일에 대한 접근 감사 비활성화
auditctl -a never,exit -F path=/etc/passwd✅ /etc/passwd 파일에 대한 접근 로그가 기록되지 않음.
3. -a와 -F 옵션을 조합하여 설정
-a와 -F를 함께 사용하면 특정 이벤트를 더욱 세밀하게 제어할 수 있습니다.
(1) 특정 사용자가 특정 파일에 접근한 경우만 감사
auditctl -a always,exit -F path=/etc/shadow -F uid=1002✅ UID가 1002인 사용자가 /etc/shadow 파일을 열거나 수정할 경우에만 감사 로그를 남김.
(2) 특정 프로세스 실행(execve) 이벤트 차단
auditctl -a never,exit -S execve -F exe=/usr/bin/python3✅ /usr/bin/python3을 실행한 경우 execve 이벤트가 감사 로그에 기록되지 않음.
(3) 특정 네트워크 포트(22번 SSH)에 대한 감사를 비활성화
auditctl -a never,exit -F msgtype=SYSCALL -F key=sshd -F auid=1000✅ UID 1000 사용자가 sshd에 관련된 네트워크 이벤트를 발생시키면 감사 로그에 기록되지 않음.
4. 감사 규칙 적용 및 확인
(1) 설정 적용
감사 규칙을 적용하려면 auditd를 다시 시작하거나 아래 명령을 실행합니다.
auditctl -R /etc/audit/rules.d/audit.rules(2) 설정 확인
현재 적용된 감사 규칙을 확인하려면
auditctl -l(3) 감사 로그 확인
감사 로그를 실시간으로 확인하려면
tail -f /var/log/audit/audit.log-a옵션은 감사 규칙을 추가하는 역할 (always또는never적용)-F옵션은 특정 필드를 기반으로 감사 필터링을 수행-a와-F를 조합하면 특정 이벤트를 기록하거나 제외 가능auditctl -l에서 규칙 확인 가능, 적용 후auditd재시작 필요
이제 auditctl을 사용하여 필요한 이벤트만 감사하고 불필요한 로그를 제거할 수 있습니다. auditctl -S 옵션을 사용할 때 특정 시스템 호출(SYSCALL)을 지정하면 해당 시스템 호출만 감사(Audit) 로그에 기록됩니다.
1. -S execve,322
auditctl -a always,exit -S execve,322✅ execve(59) 및 execveat(322) 시스템 호출만 감사
- 즉, 이 두 개의 시스템 호출만 기록됨
- 다른 시스템 호출(
openat,connect,write등)은 감사되지 않음
2. -S 옵션 없이 사용한 경우
auditctl -a always,exit✅ 모든 시스템 호출(SYSCALL)을 감사
execve,openat,connect,write,fork등 모든 시스템 호출이 감사 로그에 기록됨- 즉, 매우 많은 양의 로그가 생성됨
- 일반적으로 특정한 시스템 호출만 감시해야 효율적임
비교 정리
| 설정 | 감시되는 시스템 호출 |
|---|---|
-S execve,322 |
execve(59), execveat(322) (프로세스 실행 감시만 수행) |
-S 옵션 없이 사용 |
모든 시스템 호출을 감사 (openat, connect, write, execve 등) |
3. 실험을 통해 차이를 확인하기
(1) -S execve,322로 설정한 후 확인
auditctl -a always,exit -S execve,322ls실행ls- 로그 확인
ausearch -m SYSCALL -ts today | grep execve ✅ 결과 → execve 및 execveat 시스템 호출이 감지됨.
(2) -S 없이 설정한 후 확인
auditctl -a always,exitls실행ls- 로그 확인
✅ 결과 →ausearch -m SYSCALL -ts todayexecve뿐만 아니라openat,read,write,connect등 모든 시스템 호출이 감지됨.
✅ -S를 지정하지 않으면 모든 시스템 호출이 감사됨 → 로그가 너무 많아지고 비효율적
✅ -S execve,322를 지정하면 특정 시스템 호출(프로세스 실행)만 감사됨 → 필요한 이벤트만 기록 가능
💡 따라서 -S 옵션을 반드시 사용하여 필요한 이벤트만 감사하는 것이 최적의 방법입니다. 🚀
Linux syscall 목록 및 용도 정리 (x86_64 기준)
아래 표는 주요 시스템 호출(syscall)을 용도별로 정리한 것입니다.
| Syscall 번호 | Syscall 명령어 | 용도 (설명) |
|---|---|---|
| 파일 조작 | ||
| 2 | open |
파일 열기 |
| 5 | fstat |
파일 상태 확인 |
| 21 | access |
파일 접근 권한 확인 |
| 77 | ftruncate |
파일 크기 변경 |
| 78 | getdents |
디렉터리 엔트리 읽기 |
| 82 | rename |
파일 이름 변경 |
| 83 | mkdir |
디렉터리 생성 |
| 85 | creat |
새 파일 생성 |
| 86 | link |
하드 링크 생성 |
| 87 | unlink |
파일 삭제 |
| 88 | symlink |
심볼릭 링크 생성 |
| 89 | readlink |
심볼릭 링크 경로 읽기 |
| 90 | chmod |
파일 권한 변경 |
| 92 | chown |
파일 소유자 변경 |
| 257 | openat |
특정 디렉터리에서 파일 열기 |
| 258 | mkdirat |
특정 디렉터리에서 폴더 생성 |
| 263 | unlinkat |
특정 디렉터리에서 파일 삭제 |
| 파일 읽기/쓰기 | ||
| 0 | read |
파일에서 데이터 읽기 |
| 1 | write |
파일에 데이터 쓰기 |
| 9 | mmap |
메모리 매핑 (파일을 메모리에 매핑) |
| 17 | pread |
파일 오프셋에서 읽기 |
| 18 | pwrite |
파일 오프셋에 쓰기 |
| 19 | readv |
여러 버퍼에 읽기 |
| 20 | writev |
여러 버퍼에서 쓰기 |
| 257 | openat |
특정 경로에서 파일 열기 |
| 265 | linkat |
특정 경로에서 하드 링크 생성 |
| 프로세스 관리 | ||
| 39 | getpid |
프로세스 ID 가져오기 |
| 56 | clone |
새로운 프로세스 생성 (멀티스레딩 포함) |
| 57 | fork |
새로운 프로세스 생성 (부모-자식 관계) |
| 58 | vfork |
새로운 프로세스 생성 (fork와 유사하나 성능 향상) |
| 59 | execve |
새로운 프로그램 실행 |
| 322 | execveat |
파일 기술자(FD)를 통한 실행 |
| 60 | exit |
프로세스 종료 |
| 231 | exit_group |
프로세스 그룹 종료 |
| 62 | kill |
특정 프로세스 종료 (시그널 전송) |
| 메모리 관리 | ||
| 9 | mmap |
파일을 메모리에 매핑 |
| 10 | mprotect |
메모리 보호 속성 변경 |
| 11 | munmap |
메모리 매핑 해제 |
| 12 | brk |
힙 메모리 확장 |
| 25 | mremap |
메모리 리매핑 |
| 27 | mincore |
메모리 사용 가능 여부 확인 |
| 149 | mlock |
페이지 메모리를 잠금 |
| 150 | munlock |
페이지 메모리 잠금 해제 |
| 네트워크 관련 | ||
| 41 | socket |
소켓 생성 |
| 42 | connect |
원격 서버 연결 |
| 43 | accept |
들어오는 연결 수락 |
| 44 | sendto |
데이터 전송 |
| 45 | recvfrom |
데이터 수신 |
| 46 | sendmsg |
메시지 전송 |
| 47 | recvmsg |
메시지 수신 |
| 48 | shutdown |
소켓 종료 |
| 49 | bind |
소켓 주소 바인딩 |
| 50 | listen |
소켓 대기 상태 설정 |
| 시스템 정보 | ||
| 63 | uname |
시스템 정보 가져오기 |
| 96 | gettimeofday |
현재 시간 가져오기 |
| 99 | sysinfo |
시스템 상태 정보 가져오기 |
| 186 | gettid |
현재 쓰레드 ID 가져오기 |
| 318 | getrandom |
난수 생성 |
| 시스템 보안 및 권한 관리 | ||
| 105 | setuid |
사용자 ID 설정 |
| 106 | setgid |
그룹 ID 설정 |
| 107 | geteuid |
유효 사용자 ID 가져오기 |
| 108 | getegid |
유효 그룹 ID 가져오기 |
| 122 | setfsuid |
파일 시스템 사용자 ID 변경 |
| 123 | setfsgid |
파일 시스템 그룹 ID 변경 |
| 125 | capget |
프로세스의 권한 가져오기 |
| 126 | capset |
프로세스의 권한 설정 |
| 시그널 및 프로세스 제어 | ||
| 13 | rt_sigaction |
시그널 핸들러 설정 |
| 14 | rt_sigprocmask |
시그널 마스크 설정 |
| 15 | rt_sigreturn |
시그널 반환 |
| 127 | rt_sigpending |
보류 중인 시그널 확인 |
| 128 | rt_sigtimedwait |
시그널 대기 |
| 129 | rt_sigqueueinfo |
시그널 큐에 추가 |
| 130 | rt_sigsuspend |
시그널 대기 후 중지 |
| 기타 시스템 호출 | ||
| 162 | sync |
파일 시스템 동기화 |
| 164 | settimeofday |
시스템 시간 설정 |
| 165 | mount |
파일 시스템 마운트 |
| 166 | umount2 |
파일 시스템 언마운트 |
| 252 | inotify_init |
파일 변경 감시 |
| 254 | inotify_add_watch |
특정 파일 변경 감시 |
| 255 | inotify_rm_watch |
파일 변경 감시 해제 |
- 파일 조작 →
open,close,read,write,unlink,rename등 - 프로세스 관리 →
fork,execve,exit,kill등 - 메모리 관리 →
mmap,brk,mprotect,mlock등 - 네트워크 →
socket,connect,accept,sendto,recvfrom등 - 시스템 정보 →
uname,sysinfo,gettimeofday등 - 보안 및 권한 관리 →
setuid,setgid,capset,capget등 - 시그널 처리 →
rt_sigaction,rt_sigtimedwait,sigaltstack등 - 기타 시스템 호출 →
sync,mount,umount,inotify등
이제 각 시스템 호출이 어떤 역할을 하는지 빠르게 참고할 수 있습니다.
댓글