035. Linux 서버 보안 — 코어 덤프 제한과 민감정보 보호

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

선행 학습

• 022. 커널 보안 파라미터(sysctl) 하드닝
• 26. Linux 프로세스 보안

1. 개념

코어 덤프(core dump) 는 프로세스가 비정상 종료될 때 그 순간의 메모리를 파일로 저장한 것입니다. 개발자에게는 디버깅 자료지만, 보안 관점에서는 메모리에 있던 비밀번호, 세션 키, 개인정보가 그대로 디스크에 남는 파일입니다.

프로세스 비정상 종료 (segfault 등)
   ↓
kernel.core_pattern 확인
   ├─ "core"                        → 현재 디렉터리에 core 파일 생성
   ├─ "|/usr/lib/systemd/systemd-coredump ..." (Rocky)  → coredumpctl 로 관리
   └─ "|/usr/share/apport/apport ..."          (Ubuntu) → /var/crash 에 저장
   ↓
제한 요소: ulimit -c (크기), fs.suid_dumpable (SUID 프로그램), coredump.conf (Storage)

core_pattern이 |로 시작하면 덤프 시 지정한 프로그램을 root 권한으로 실행합니다. 이 값이 바뀌면 지속성 수단이 될 수 있어 탐지 대상입니다.

2. 왜 중요한가

• sshd, sudo, DB 프로세스의 코어 덤프에는 인증 정보가 포함될 수 있어, 덤프 파일이 다른 사용자에게 읽히면 곧바로 계정 탈취로 이어집니다.
• 일부 공격 기법은 프로세스를 일부러 비정상 종료시켜 메모리를 덤프하게 만듭니다. fs.suid_dumpable=0은 SUID 프로그램의 덤프를 막습니다.
• 운영 서버는 디버깅 필요성이 낮으므로 기본 비활성화 + 필요 시 일시 허용이 일반적인 정책입니다.

3. 핵심 명령어 / 설정

항목	권장	확인
ulimit -c / limits.conf	* hard core 0	ulimit -c, grep core /etc/security/limits.conf /etc/security/limits.d/*
fs.suid_dumpable	0	sysctl fs.suid_dumpable
systemd-coredump (Rocky)	Storage=none, ProcessSizeMax=0	/etc/systemd/coredump.conf
apport (Ubuntu)	운영 서버는 비활성화 검토	systemctl is-enabled apport
kernel.core_pattern	배포판 기본값 유지	sysctl kernel.core_pattern
기존 덤프	정리·권한 확인	coredumpctl list, ls -l /var/crash /var/lib/systemd/coredump

4. 실습 (실습 예시)

# 1) 현재 상태
ulimit -c
sysctl fs.suid_dumpable kernel.core_pattern
coredumpctl list --no-pager 2>/dev/null | tail -3

# 2) 제한 설정
echo '* hard core 0' | sudo tee /etc/security/limits.d/90-nocore.conf
echo 'fs.suid_dumpable = 0' | sudo tee /etc/sysctl.d/92-coredump.conf
sudo sysctl --system >/dev/null
sudo mkdir -p /etc/systemd/coredump.conf.d
printf '[Coredump]\nStorage=none\nProcessSizeMax=0\n' | sudo tee /etc/systemd/coredump.conf.d/10-disable.conf
sudo systemctl daemon-reload

# 3) 기존 덤프 파일 권한 확인
sudo ls -l /var/lib/systemd/coredump/ /var/crash/ 2>/dev/null

5. 정상 상태

$ sysctl fs.suid_dumpable kernel.core_pattern
fs.suid_dumpable = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
$ ulimit -c
0

배포판 기본 core_pattern이 유지되고, 덤프가 제한된 상태입니다.

6. 이상 상태

$ sysctl kernel.core_pattern
kernel.core_pattern = |/var/tmp/.font-unix/fc %p
$ ls -l /var/crash/
-rw-r--r--. 1 root root 18874368 Oct  1 04:10 _usr_sbin_sshd.0.crash

• core_pattern이 임시 경로의 의심 파일로 변경 → 어떤 프로세스든 비정상 종료되면 root로 그 파일이 실행되는 지속성 구조
• sshd 크래시 덤프가 누구나 읽을 수 있는 권한(644) → 메모리 속 인증 정보 노출 위험

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

core_pattern 변경과 크래시 이벤트입니다(가상의 예시 로그).

type=SYSCALL msg=audit(1759736400.120:2801): syscall=257 success=yes auid=1002 uid=0 comm="sysctl" exe="/usr/sbin/sysctl" key="sysctl_proc"
type=PATH msg=audit(1759736400.120:2801): item=0 name="/proc/sys/kernel/core_pattern"
Oct  1 04:10:02 rocky9-web01 kernel: sshd[9620]: segfault at 0 ip 00007f3a2c1b1d2a sp 00007ffd5e3a1b40 error 4 in libc.so.6[7f3a2c000000+195000]
Oct  1 04:10:03 rocky9-web01 systemd-coredump[9622]: Process 9620 (sshd) of user 0 dumped core.

관찰	해석
/proc/sys/kernel/core_pattern 쓰기	덤프 처리 프로그램 변경
segfault ... in libc.so.6	프로세스 비정상 종료(원인 분석 필요)
dumped core	덤프 생성 → 파일 위치·권한 확인

정상 서비스가 갑자기 반복 크래시하면 취약점 악용 시도의 부작용일 수도 있으므로 같은 시각 네트워크·인증 로그를 함께 확인합니다.

8. SOC 관제 포인트

• kernel.core_pattern 값을 기준선에 넣고 변경 시 높은 우선순위로 확인합니다.
• 인증·보안 관련 프로세스(sshd, sudo, sssd)의 크래시는 일반 장애보다 우선 분석합니다.
• 덤프 파일은 민감정보이므로 수집·보관도 증거 관리 절차에 따라 접근을 제한합니다.

9. 탐지 규칙

# auditd: core_pattern 변경 감시 (procfs는 -w 불가 → 시스템 콜 + 경로 조건)
-a always,exit -F arch=b64 -S openat -F path=/proc/sys/kernel/core_pattern -F perm=w -k core_pattern

<group name="local,coredump,">
  <rule id="100410" level="12">
    <if_group>audit</if_group>
    <field name="audit.key">core_pattern</field>
    <description>kernel.core_pattern 변경 시도</description>
  </rule>
  <rule id="100411" level="9">
    <match>dumped core</match>
    <regex type="pcre2">\((sshd|sudo|sssd|su)\)</regex>
    <description>인증 관련 프로세스 코어 덤프 발생</description>
  </rule>
</group>

그룹·대체를 쓰는 정규식은 type="pcre2"로 지정했습니다. 적용 전 wazuh-logtest로 확인합니다.

10. 대응 방법

1. 초기 확인 — core_pattern 값, 크래시 이력(coredumpctl list), 덤프 파일 권한을 확인합니다.
2. 범위 확인 — 같은 프로세스 크래시가 다른 서버에서도 발생했는지, 크래시 직전 접속 로그를 확인합니다.
3. 증거 확보 — 덤프 파일은 접근 제한된 저장소로 이동해 보존하고 해시를 기록합니다.
4. 차단/조치 — core_pattern을 기본값으로 복원하고, 지정됐던 실행 파일을 격리합니다.
5. 재발 방지 — 코어 덤프 제한 정책과 core_pattern 감시를 표준으로 적용합니다.

11. 핵심 정리

구분	핵심 내용
위험	메모리 속 비밀번호·키가 파일로 남음
제한 설정	hard core 0, fs.suid_dumpable=0, coredump Storage=none
지속성 악용	core_pattern을 |임의프로그램 으로 변경 → root 실행
탐지	/proc/sys/kernel/core_pattern 쓰기, 인증 프로세스 크래시
면접 포인트	"core_pattern 파이프는 root로 실행된다"

12. 다음 편 예고

다음 편 036. Linux 서버 보안 — 커널 모듈·USB 저장장치 제한 에서는 하드닝 설정 영역의 마지막으로 커널 모듈·USB 저장장치 제한을 다룹니다.

---

이전 편: 034. Linux 서버 보안 — 로그인 배너와 버전 정보 노출 최소화
📚 시리즈 전체 보기: 시스템 보안 · 취약점