039. Linux 서버 보안 — 하드닝 해제 징후 — SELinux·방화벽·auditd 중지

목록 보기

39/150

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

선행 학습

1. 개념

침해 후 공격자가 자주 하는 일은 "보는 눈"과 "막는 벽"을 끄는 것입니다. 이를 하드닝 해제(defense evasion) 징후라고 묶어 관리합니다.

   막는 벽 (예방)                     보는 눈 (탐지)
 ┌──────────────────┐            ┌──────────────────────┐
 │ SELinux/AppArmor │            │ auditd               │
 │ firewalld / ufw  │            │ rsyslog / journald   │
 │ 마운트 옵션       │            │ 보안 에이전트(Wazuh) │
 └──────────────────┘            └──────────────────────┘
          ↓ 해제                           ↓ 중지
   공격 행위가 쉬워짐                 공격 행위가 안 보임

개별 이벤트는 앞선 편에서 다뤘습니다. 이 편은 이를 하나의 탐지 묶음(use case) 으로 정리합니다.

2. 왜 중요한가

하드닝 해제는 공격 흐름에서 실제 목적 행위(데이터 접근, 확산) 직전에 나타나는 경우가 많아, 이 단계에서 탐지하면 피해를 줄일 수 있습니다.
정상 운영에서도 장애 대응 중 잠깐 끄는 경우가 있어 오탐이 생기지만, 업무 외 시간·변경관리 없음·여러 항목 동시 조건을 결합하면 정확도가 크게 올라갑니다.
"보는 눈"이 꺼진 뒤의 로그는 서버에 남지 않으므로, 꺼지는 순간의 이벤트와 이후의 수신 공백이 중요한 증거입니다.

3. 핵심 명령어 / 설정

해제 행위	대표 명령	남는 기록
SELinux 해제	`setenforce 0`, config `SELINUX=disabled`	`type=MAC_STATUS enforcing=0`
AppArmor 해제	`systemctl stop apparmor`, `aa-teardown`, `aa-complain`	`apparmor="STATUS" operation="profile_remove"`
방화벽 중지	`systemctl stop firewalld`, `ufw disable`	`type=SERVICE_STOP unit=firewalld`, sudo 로그
감사 중지	`service auditd stop`, `auditctl -D`	`DAEMON_END`, `CONFIG_CHANGE`
로그 중지	`systemctl stop rsyslog`, journald volatile	`SERVICE_STOP unit=rsyslog`, SIEM 수신 공백
에이전트 중지	`systemctl stop wazuh-agent`	관제 서버의 agent disconnected

4. 실습 (실습 예시)

# 하드닝 상태 한 번에 점검 (테스트 VM에서 정상/해제 상태 비교용)
echo "SELinux : $(getenforce 2>/dev/null)"
echo "Firewall: $(systemctl is-active firewalld 2>/dev/null || ufw status | head -1)"
echo "auditd  : $(systemctl is-active auditd) / $(sudo auditctl -s | awk '/^enabled/{print "enabled="$2}')"
echo "rsyslog : $(systemctl is-active rsyslog)"
echo "agent   : $(systemctl is-active wazuh-agent 2>/dev/null)"

# 최근 해제 이벤트 조회
sudo ausearch -m MAC_STATUS,SERVICE_STOP,DAEMON_END,CONFIG_CHANGE -i --start today | \
  grep -E 'enforcing=0|unit=(firewalld|auditd|rsyslog|wazuh-agent)|op=terminate|remove_rule' | tail

5. 정상 상태

SELinux : Enforcing
Firewall: active
auditd  : active / enabled=2
rsyslog : active
agent   : active

해제 이벤트 조회 결과가 없거나, 있더라도 계획된 유지보수 시간·변경관리 번호로 설명되는 상태가 정상입니다.

6. 이상 상태

SELinux : Permissive
Firewall: inactive
auditd  : active / enabled=1
rsyslog : active
agent   : inactive

예방(SELinux, 방화벽)과 탐지(감사 잠금, 에이전트)가 동시에 약화된 상태입니다. 개별 항목보다 조합이 중요하며, 이 조합은 장애 대응보다 침해 후 정리 작업 패턴에 가깝습니다.

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

해제 이벤트를 시간순으로 정렬하면 순서 자체가 의도를 보여줍니다(가상의 예시 로그).

03:30:01 type=MAC_STATUS enforcing=0 old_enforcing=1 auid=1002 ses=12 res=1
03:30:20 type=SERVICE_STOP msg='unit=firewalld comm="systemd" exe="/usr/lib/systemd/systemd" res=success'
03:30:42 sudo: devops : COMMAND=/usr/bin/systemctl stop wazuh-agent
03:30:43 type=SERVICE_STOP msg='unit=wazuh-agent comm="systemd" ... res=success'
03:31:05 type=CONFIG_CHANGE op=remove_rule key="root_exec" list=4 auid=1002 res=0
──── 관제 서버 관점 ────
03:30:45 rocky9-web01 agent disconnected

관찰	해석
MAC → 방화벽 → 에이전트 → 감사 순	예방 장치 해제 후 탐지 장치 제거 시도
1분 내 연속 발생	수동 장애 대응보다 준비된 절차(스크립트) 가능성
`res=0`	감사 규칙 삭제는 불변 모드로 실패 → 이후 재부팅 시도 가능성 감시
agent disconnected	서버 로그가 끊겨도 관제 측에 남는 마지막 신호

8. SOC 관제 포인트

하드닝 해제 이벤트는 단건도 확인 대상이며, 2건 이상 조합 시 Incident로 격상합니다.
에이전트 disconnected·로그 수신 공백은 해제 행위의 결과로 나타나므로 원인 조사를 생략하지 않습니다.
해제 직후의 재부팅은 불변 모드·휘발성 로그를 노린 행위일 수 있어 주의 깊게 봅니다.

9. 탐지 규칙

<group name="local,hardening_drift,">
  <rule id="100440" level="11">
    <if_group>audit</if_group>
    <match>type=SERVICE_STOP</match>
    <regex>unit=firewalld|unit=auditd|unit=rsyslog|unit=wazuh-agent|unit=apparmor</regex>
    <description>보안 서비스 중지: 하드닝 해제 의심</description>
  </rule>
</group>

017·031편의 룰(MAC_STATUS, CONFIG_CHANGE, DAEMON_END)에도 hardening_drift 그룹을 붙이면 037편의 다중 해제 상관 룰(100430) 이 동작합니다. 에이전트가 꺼지면 이후 이벤트가 오지 않으므로, 관제 서버 측의 disconnected Alert를 같은 대시보드에 함께 배치합니다.

10. 대응 방법

초기 확인 — 해제된 항목 목록과 각 해제 시각·주체(auid/ses)를 확인합니다.
범위 확인 — 같은 시간대 다른 서버의 해제 이벤트와 에이전트 disconnected를 조회합니다.
증거 확보 — 원격 수집본(서버 로컬은 신뢰 불가), 현재 상태 출력, 메모리·프로세스 정보를 보존합니다.
차단/조치 — 보안 장치를 재활성화하고 해제 주체 계정·세션을 차단, 서버 격리 여부를 결정합니다.
재발 방지 — 하드닝 해제 use case(룰 묶음 + 대시보드 + 대응 절차)를 표준으로 운영합니다.

11. 핵심 정리

구분	핵심 내용
분류	막는 벽(SELinux·방화벽) / 보는 눈(auditd·로그·에이전트)
대표 로그	MAC_STATUS, SERVICE_STOP unit=, DAEMON_END, CONFIG_CHANGE
관제 측 신호	agent disconnected, 로그 수신 공백
판단	단건도 확인, 2건 이상 조합 시 Incident 격상
면접 포인트	"보는 눈이 꺼지는 순간의 이벤트가 마지막 증거"