048. Linux 서버 보안 — 설정 변경 Alert 정탐·오탐 판단

Alert분석 Linux 서버 보안 Soc 리눅스 보안관제 시스템 보안 · 취약점 시스템보안 정탐오탐

시스템 보안 · 취약점

목록 보기

48/150

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 48/50편 (전체 048/450)
학습 단계: 5단계 · SOC 관제 연계
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

Alert가 울렸다는 것은 "룰 조건이 맞았다"는 뜻일 뿐, 공격이라는 뜻이 아닙니다. 관제원의 핵심 역할은 Alert를 다음 셋 중 하나로 근거를 들어 분류하는 것입니다.

분류	의미	예
정탐(True Positive)	룰 의도대로 악성·비인가 행위를 탐지	탈취 계정의 sudoers.d 생성
정상 행위(Benign True Positive)	룰 조건은 정확히 맞았지만 승인된 행위	변경관리된 sshd 설정 변경
오탐(False Positive)	룰이 의도와 다른 대상을 잡음	패키지 업데이트로 대량 발생한 FIM Alert

설정 변경 Alert 판단 순서
① 변경 내용 확인    : 무엇이, 어떻게 바뀌었나 (FIM diff, 설정값)
② 행위자 확인       : auid·ses·출발지 (038편)
③ 승인 여부 확인    : 변경관리 티켓·작업 일정·담당자
④ 맥락 확인        : 같은 시각 패키지 작업? 자동화 도구? 다른 Alert 동반?
⑤ 판정 + 근거 기록  : 정탐 / 정상 행위 / 오탐 + 룰 튜닝 필요 여부

2. 왜 중요한가

근거 없이 "오탐" 처리하면 실제 침해를 놓치고(미탐과 같은 결과), 반대로 모든 Alert를 사고로 올리면 관제 체계가 마비됩니다.
설정 변경 Alert는 운영 변경과 침해의 겉모습이 같아 판단 기준이 특히 중요합니다(037편).
판단 기록이 쌓여야 룰 튜닝(예외 조건 추가)과 관제 품질 평가가 가능합니다.

3. 핵심 명령어 / 설정

확인 항목	확인 방법	정탐 쪽 신호	정상·오탐 쪽 신호
승인	변경관리 시스템, 작업 공지	기록 없음	티켓·일정 일치
행위자	auid, 출발지 IP, 인증 방식	비관리망, password, 서비스 계정	관리망, 키 인증, 담당자 계정
시간	Alert 시각	업무 외 시간, 담당자 부재	작업 시간대
동반 이벤트	같은 호스트·같은 시간 Alert	하드닝 해제·계정 생성 동반	단독 발생
변경 성격	diff 내용	보안 약화(허용·해제·추가)	기능 변경·보안 강화
맥락	dnf/apt·Ansible 로그	없음	패키지·자동화 실행과 일치

4. 실습 (실습 예시)

판단에 필요한 정보를 빠르게 모으는 확인 명령 묶음입니다(분석 방법).

H=rocky9-web01; T="10/01/2026 02:00:00"
# 1) 변경 내용: FIM diff는 Alert 본문에서, 현재값은 서버에서
sudo cat /etc/sudoers.d/99-sysupdate
# 2) 행위자: 해당 파일 이벤트의 auid/ses → 세션 출발지
sudo ausearch -f /etc/sudoers.d/99-sysupdate -i | grep -oE 'auid=[^ ]+|ses=[^ ]+' | sort -u
# 3) 맥락: 같은 시간대 패키지·자동화 작업
sudo dnf history list | head -5
sudo journalctl --since "2026-10-01 02:00" --until "2026-10-01 03:00" | grep -iE 'ansible|dnf|apt' | head

5. 정상 상태

정상 행위(Benign TP)로 판정되는 대표 사례입니다.

Alert   : 100200 신규 systemd 유닛/링크 생성 (14:01, rocky9-web01) 외 37건
변경    : /usr/lib/systemd/system/httpd.service 등 다수
행위자  : root (auid=admin1, ses=31, 192.168.56.5 관리망, publickey)
맥락    : 14:00 dnf update (CHG-2026-1002, 정기 패치), 같은 시각 dnf.rpm.log Upgraded 다수
판정    : 정상 행위 / 룰 튜닝 — 패키지 작업 시간대 유닛 생성은 그룹 Alert로 묶어 1건 처리

6. 이상 상태

정탐으로 판정되는 사례입니다.

Alert   : 100360 계정/권한/인증 설정 변경: priv_conf (02:16, rocky9-web01)
변경    : /etc/sudoers.d/99-sysupdate 생성, 내용 "apache ALL=(ALL) NOPASSWD: ALL" → 보안 약화
행위자  : auid=devops, ses=12, 192.168.56.77(비관리망), password 인증
승인    : 변경관리 없음, devops 담당자 휴가 중
동반    : 같은 세션 UID 0 계정 생성(100110), sshd drop-in(100160)
판정    : 정탐 → Incident 생성, 계정 잠금·세션 종료·IP 차단 요청

정상 사례와 비교하면 승인·행위자·동반 이벤트·변경 성격 네 항목이 모두 반대 방향입니다.

7. 로그 분석 (분석 방법)

흔한 오탐·정상 행위 패턴과 대응 방법입니다(분석 방법 정리).

패턴                                       원인                         처리 방법
FIM 550 대량 (/usr/bin, /usr/lib)          패키지 업데이트              dnf/apt 시각 일치 확인 → 패치 창 그룹 처리
sudoers·sshd 설정 변경                      Ansible 등 구성 관리 배포    배포 계정·서버 목록 예외, 배포 이력과 대조
systemd 유닛 생성 다수                      패키지 설치                  rpm -qf / dpkg -S 로 소속 확인
SELinux AVC (name_bind 등)                  설정 실수·신규 서비스        동작 종류 확인(execute 계열은 예외 금지)
auditd 키 root_exec 과다                    정상 관리 작업               업무 시간·관리자 계정 조건으로 레벨 조정

예외 조건을 만들 때는 "누구의, 어떤 작업을, 어느 범위까지" 좁혀야 합니다. 계정 전체·경로 전체를 예외 처리하면 공격자가 그 예외를 그대로 이용할 수 있습니다.

8. SOC 관제 포인트

모든 판정에 근거(변경관리 번호, 행위자 정보, 맥락 로그)를 남기고, "오탐"만 적고 닫지 않습니다.
정상 행위(Benign TP)가 반복되는 룰은 예외 조건을 좁게 추가하거나 그룹 Alert로 묶습니다.
보안 약화 방향의 변경(허용 추가, 장치 해제)은 승인이 확인되기 전까지 정탐 가능성으로 다룹니다.

9. 탐지 규칙

판단 결과를 룰 개선으로 되돌리는 예시입니다.

<!-- 패치 작업 중 패키지 관리자가 만든 유닛 변경은 레벨 하향 (예외 범위를 좁게) -->
<rule id="100201" level="3">
  <if_sid>100200</if_sid>
  <field name="file">^/usr/lib/systemd/system/</field>
  <description>패키지 경로 systemd 유닛 변경(패키지 작업 가능성) - 집계용</description>
</rule>

/etc/systemd/system/(관리자·공격자가 만드는 경로)은 그대로 두고, 패키지가 쓰는 /usr/lib/systemd/system/만 하향한 점이 핵심입니다. 패키지 경로 변조 가능성은 025편의 패키지 검증으로 보완합니다.

판단 기록 템플릿

[Alert] 룰 ID / 설명 / 호스트 / 시각
[변경 내용] 대상 · 변경 전후 · 보안 영향(약화/중립/강화)
[행위자] auid · ses · 출발지 · 인증 방식
[승인] 변경관리 번호 / 없음
[동반 이벤트] 같은 세션·같은 시간대 Alert
[판정] 정탐 / 정상 행위 / 오탐   [근거] ...
[후속] Incident 번호 / 룰 튜닝 요청 / 없음

10. 대응 방법

초기 확인 — Alert의 변경 내용·행위자·승인 여부·동반 이벤트를 템플릿 순서대로 확인합니다.
범위 확인 — 정탐이면 같은 행위자·출발지로 전체 서버를 조회해 범위를 확인합니다.
증거 확보 — 판단 근거 자료(로그, 티켓, diff)를 판단 기록과 함께 보관합니다.
차단/조치 — 정탐은 Incident 대응, 정상 행위·오탐은 범위를 좁힌 룰 튜닝을 요청합니다.
재발 방지 — 판단 기록을 주기적으로 검토해 룰 품질과 관제 판단 기준을 개선합니다.

11. 핵심 정리

분류	정의
정탐(TP)	룰 의도대로 비인가·악성 행위 탐지
정상 행위(Benign TP)	조건은 맞지만 승인된 행위
오탐(FP)	룰이 의도와 다른 대상을 잡음
판단 4요소	승인 · 행위자 · 동반 이벤트 · 변경 성격(보안 약화 여부)
면접 포인트	"근거 없는 오탐 처리는 미탐과 같다 / 예외는 좁게"