Linux audit의 한 시스템 호출 사건에는 여러 종류의 레코드가 붙을 수 있습니다. msg=audit(시각:serial)의 동일 이벤트 식별자를 기준으로 SYSCALL·CWD·PATH 등을 묶어야 파일 경로와 호출 결과를 함께 읽을 수 있습니다.

auid는 원래 로그인 사용자를 추적하는 단서이고 uid/euid는 현재 행위 맥락을 설명하는 계정 값입니다. 감사 이벤트는 경로·권한 사용과 실행 결과를 보여 주지만, 그 자체로 변경 의도나 승인 여부까지 증명하지 않습니다.

한 syscall 사건이 여러 줄로 기록될 수 있습니다

Linux Audit ausearch(8) 문서는 하나의 사용자 공간 시스템 호출에서 커널로 갔다 돌아오는 사건에 고유 event ID가 붙고, 그 사건을 일으킨 감사 레코드들이 같은 ID를 공유한다고 설명합니다. 예를 들어 open 계열 호출에는 파일 이름이 든 PATH 레코드가 보충될 수 있으며, ausearch는 한 사건을 이루는 레코드를 함께 제시합니다. 따라서 로그 줄 수를 사건 수로 세거나 PATH 한 줄을 독립 행위처럼 해석하지 않습니다.

원시 레코드의 msg=audit(2026-10-22T09:40:17.000:7712)처럼 시각과 serial을 함께 쓰는 표기는 예시입니다. 같은 호스트의 같은 serial에 속한 SYSCALL·CWD·PATH를 먼저 모으고, 다른 serial에 나온 비슷한 경로 기록은 별도 사건으로 둡니다. 멀티 호스트 수집에서는 같은 숫자만으로 합치지 말고 호스트와 부팅·수집 맥락도 포함해야 합니다.

창작 레코드를 묶고 사실만 추립니다

설명용으로 만든 이벤트입니다. 실제 audit 원문, 고객 기록 또는 시험 기출이 아닙니다.
레코드가상 필드이벤트 7712에서 말할 수 있는 것
SYSCALLmsg=audit(09:40:17.000:7712), syscall=openat, success=yes, auid=1002, uid=0, euid=0, exe=/usr/bin/editor같은 이벤트 호출의 결과·계정·실행파일 단서
CWDmsg=audit(09:40:17.000:7712), cwd=/home/ops해당 사건에 기록된 현재 작업 디렉터리
PATHmsg=audit(09:40:17.000:7712), item=0, name=/etc/lab/app.conf, nametype=NORMAL해당 이벤트에 연결된 경로 대상
별도 SYSCALLmsg=audit(09:40:19.000:7713), success=no, auid=1002, uid=1002serial이 달라 사건 7712에 포함하지 않음

이 연습에서 serial 7712로 묶인 레코드는 /etc/lab/app.conf에 접근하려 한 openat 사건이며, SYSCALL에는 성공 표시가 있습니다. 하지만 openat 성공은 파일 내용이 바뀌었다는 뜻이 아닙니다. 쓰기 작업인지, 파일이 실제 변경됐는지는 감사 규칙·요청 플래그·추가 시스템 호출이나 파일 무결성 자료로 확인해야 합니다. 별도 serial 7713은 실패 기록이므로 같은 파일이나 같은 로그인 사용자가 보여도 앞선 사건의 결과로 섞지 않습니다.

auid와 현재 uid는 서로 다른 질문에 답합니다

Oracle Linux 9 감사 규칙 문서는 auid를 원래 로그인한 사용자 ID를 기준으로 필터링하는 맥락에서 설명합니다. 따라서 auid=1002와 uid/euid=0이 함께 보이면, 원래 로그인 사용자로 식별된 계정 아래에서 현재 프로세스가 권한을 바꿔 실행된 가능성을 조사할 수 있습니다. 이는 원본 로그인 ID와 현재 자격 정보가 다르다는 관측이지, 특정 개인이 파일을 수정하려 했다는 의도 증명은 아닙니다. 시스템 서비스나 비대화형 작업에서 auid가 미설정일 수 있으므로 빈 값도 환경과 규칙을 확인해야 합니다.

이벤트부터 대상 경로까지 확인하는 순서

  1. 같은 호스트의 timestamp와 audit serial로 레코드를 묶고, 수집 과정에서 일부 형식이 분리되지 않았는지 확인합니다.
  2. SYSCALL에서 syscall 이름, success·exit 결과, auid·uid·euid, exe와 프로세스 ID를 기록합니다.
  3. PATH 레코드의 대상 경로·nametype·객체 식별 정보를 보며 CWD와 상대 경로가 필요한 경우만 함께 풉니다.
  4. 한 syscall에 여러 PATH 레코드가 있으면 모두 보존하고 각 item 번호와 nametype을 맞춥니다.
  5. 읽기·쓰기·생성·삭제가 무엇인지 syscall·권한·대상 파일의 이벤트 필드로 확인하고, 성공 기록을 변경 결과와 동일시하지 않습니다.
  6. 별도 파일 무결성, 백업·버전 관리, 응용 프로그램 기록과 승인 자료를 확인해 실제 변경 및 맥락을 보완합니다.

기록되지 않은 명령행은 상상해서 채우지 않습니다

audit 규칙이 해당 syscall이나 경로를 수집하지 않았거나 로그 보존·전달에 공백이 있으면 이벤트 묶음 자체가 불완전할 수 있습니다. exe가 기록돼도 전체 명령행이나 편집한 내용이 자동으로 보이는 것은 아닙니다. 수집된 필드와 자료가 증명하는 범위를 명시하고, 관측하지 못한 파일 변경·사용자 의도는 미확정으로 남깁니다.

복습: 어느 줄이 사건 7712에 속하나요?

문제: SYSCALL과 PATH의 msg=audit(...:7712)는 같고 CWD는 ...:7713입니다. 세 레코드를 하나로 묶어도 될까요?

정답: 아니요. event ID가 다른 CWD는 7712에 섞지 않습니다. PATH와 SYSCALL만 7712 사건으로 묶고, 필요한 작업 디렉터리 정보는 7712 자체에 기록된 레코드에서 확인합니다.

정답을 가리고 확인해 보세요

이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.

창작 SYSCALL과 PATH가 같은 audit(...:7712)를 갖고 SYSCALL은 success=yes, auid=1002, euid=0입니다. PATH는 /etc/lab/app.conf입니다. 말할 수 있는 사실 두 가지와 추가 확인 한 가지를 적으세요.

정답과 해설 확인같은 syscall 사건이 해당 경로를 대상으로 했고 성공 결과·auid·euid가 그 이벤트에 기록됐다고 말할 수 있습니다. 성공한 open 계열 호출만으로 파일 내용 변경을 확정하지 말고 쓰기 호출·무결성 자료를 추가 확인합니다.

동일 이벤트 ID는 관련 레코드를 묶는 근거입니다. uid·auid와 성공 필드는 조사 방향을 좁히지만 변경 결과·의도까지 증명하지 않습니다.

이 주제의 회상 연습 이어가기