服务器core dump需兼顾调试与安全：限制生成范围、隔离存储路径并强化权限、过滤敏感内存页、设置大小上限、自动清理及访问审计。
服务器核心转储文件（core dump）本身是调试关键故障的“黑匣子”，但因其包含完整内存镜像，可能泄露敏感数据（如密码、密钥、用户凭证、加密上下文等）。设置保护机制不是为了禁用它，而是确保它只在必要时生成、安全存储、受控访问、及时清理。以下是兼顾可用性与安全性的实用配置要点：
限制生成范围，避免无差别捕获
默认开启所有进程的 core dump 会扩大攻击面。应按需启用，而非全局放开：
- 对非调试环境的服务进程，显式禁用：在 systemd unit 文件中添加 LimitCORE=0，例如：
[Service]
LimitCORE=0 - 仅对明确需要调试的二进制（如自研服务主程序），通过 prctl(PR_SET_DUMPABLE, 1) 在代码中主动开启；未调用则继承父进程 dumpable 状态，默认为 0（不可转储）
- 避免对 setuid/setgid 程序启用 dump，除非确有调试需求——这类程序本就因
fs.suid_dumpable=0被系统默认屏蔽，不应轻易改为 2
隔离存储路径并强化目录权限
core 文件不能放在任意可写目录（如 /tmp 或用户家目录），必须使用专用、受限路径：
- 指定独立目录，例如
/var/log/coredumps/，并确保其属主为 root:root，权限为 0700（非 1777）
→sudo mkdir -p /var/log/coredumps && sudo chown root:root /var/log/coredumps && sudo chmod 0700 /var/log/coredumps - 配置
kernel.core_pattern指向该私有路径，例如：
kernel.core_pattern=/var/log/coredumps/core.%e.%p.%t - 禁用管道模式（即不以
|开头的 pattern），防止 core 数据被用户态进程（如systemd-coredump）意外读取或转发
控制内容敏感度与体积风险
即使路径安全，原始 core 文件仍含全量内存。可通过内核机制过滤非必要页：
- 启用 makedumpfile 风格的过滤（适用于 kdump 场景），或在用户态收集环节做裁剪；但对于普通进程 core，更直接的是利用 VMA 标记：
在程序启动前设置echo 1 | sudo tee /proc/sys/kernel/coredump_filter（仅保留匿名私有内存，跳过文件映射、共享内存等高风险区域） - 配合
ulimit -c设置合理上限（如ulimit -c 2097152即 2GB），防止单个崩溃耗尽磁盘或产生过大敏感文件 - 禁止 core 文件包含完整栈帧或寄存器值？无法由内核层关闭，但可在编译时使用
-fno-stack-protector -z noexecstack减少敏感栈信息，或依赖调试符号剥离（strip --strip-all）降低可读性
自动化清理与访问审计
core 文件不应长期留存。需建立生命周期管理：
- 用 logrotate 或定时任务自动清理旧文件，例如每天清理 7 天前的 core：
find /var/log/coredumps -name "core.*" -mtime +7 -delete - 设置 inotifywait 监控目录，触发告警或归档动作（如压缩加密后移至离线存储）
- 启用 auditd 记录对 core 文件的访问行为：
-w /var/log/coredumps -p wa -k coredump_access - 禁止非 root 用户直接读取：
确保core.%e.%p.%t生成后权限为 0600**，属主为对应进程 UID —— 但因目录为 0700，外部用户根本无法进入，更无法 ls 列出
