在Ubuntu服务器上禁用Core Dump（核心转储）是防止敏感内存信息泄露的关键安全措施。当程序崩溃时，Core Dump会将进程的完整内存镜像写入磁盘，这其中可能包含密码、密钥、会话令牌、用户数据等高度敏感信息。一旦服务器被入侵或磁盘被非法访问，这些Core Dump文件就成了攻击者的"金矿"。具体操作方法很简单：编辑/etc/security/limits.conf文件，添加* hard core 0这一行即可从系统层面彻底禁止所有用户生成Core Dump文件，同时还需要配合sysctl参数和systemd配置做多层防护，确保万无一失。
为什么Core Dump会成为安全隐患
Core Dump本质上是程序崩溃时操作系统对进程内存的完整快照。这个快照包含了程序运行时的所有数据——堆内存、栈内存、寄存器状态、打开的文件描述符指向的内容等等。对于Web应用、数据库服务、API网关这类处理敏感数据的程序来说，崩溃时的内存中极有可能残留着用户的登录凭证、API密钥、数据库连接字符串、甚至是未加密的个人隐私数据。
在实际生产环境中，很多运维人员为了方便调试，默认开启了Core Dump功能。Ubuntu系统默认会在/var/crash/目录或者/tmp/目录下生成core文件。这些文件的大小通常与进程占用的内存成正比，一个占用4GB内存的Java进程崩溃后可能生成一个4GB的core文件。更危险的是，这些文件的权限设置往往不够严格，普通用户甚至可能通过路径遍历读取到这些文件。
Ubuntu系统中禁用Core Dump的完整步骤
禁用Core Dump需要从多个层面入手，单一配置往往不够彻底。下面按照优先级从高到低，给出完整的操作流程。
第一步：通过limits.conf限制核心文件大小
这是最直接有效的方法。编辑系统资源限制配置文件：
sudo nano /etc/security/limits.conf
在文件末尾添加以下内容：
* hard core 0 * soft core 0 root hard core 0 root soft core 0
这里的*代表所有用户，root单独指定是为了防止root用户绕过限制。hard和soft都设为0意味着完全禁止生成任何大小的core文件。保存后需要重新登录或重启相关服务才能生效。
第二步：修改sysctl内核参数
内核层面也需要做配置。编辑sysctl配置文件：
sudo nano /etc/sysctl.conf
添加或修改以下参数：
kernel.core_pattern = |/bin/false kernel.core_uses_pid = 0 fs.suid_dumpable = 0
kernel.core_pattern = |/bin/false的意思是将core输出管道到一个什么都不做的程序，实际上就是丢弃所有core数据。fs.suid_dumpable = 0禁止SUID程序生成core dump，防止提权攻击中利用core文件获取敏感信息。修改后执行以下命令立即生效：
sudo sysctl -p
第三步：通过systemd全局禁用
对于使用systemd管理的服务，还需要在全局层面做配置。创建或编辑systemd的core dump配置：
sudo nano /etc/systemd/coredump.conf
写入以下内容：
[Coredump] Storage=none ProcessSizeMax=0
Storage=none表示不存储任何core dump，ProcessSizeMax=0表示不对任何大小的进程生成core。配置完成后重启systemd-coredump服务：
sudo systemctl daemon-reload sudo systemctl restart systemd-coredump
第四步：清理已有的Core Dump文件
禁用配置生效后，还需要清理系统中已经存在的core文件，消除历史隐患：
sudo find / -name "core*" -type f 2>/dev/null sudo find /var/crash/ -type f -delete 2>/dev/null sudo rm -f /tmp/core* /core* 2>/dev/null
特别注意/var/crash/目录，这是Ubuntu默认存放Apport崩溃报告和core文件的地方，必须彻底清空。同时建议设置定时任务定期扫描和清理：
sudo crontab -e
添加一行：
0 3 * * * find / -name "core*" -type f -mtime +0 -delete 2>/dev/null
第五步：针对特定服务做精细化控制
有些关键服务（如Nginx、MySQL、PostgreSQL）可能有自己的core dump配置。需要逐一检查。以Nginx为例，在其systemd服务文件中添加：
sudo systemctl edit nginx
写入：
[Service] LimitCORE=0
对于MySQL和PostgreSQL这类数据库服务，更需要严格控制，因为它们的内存中经常包含大量敏感数据。除了系统层面禁用，还应该在数据库配置文件中设置core-file-size = 0（MySQL）或确保不启用任何调试级别的core生成。
验证配置是否真正生效
配置完成后必须验证。可以用一个简单的测试程序来确认：
#include <stdio.h>
#include <signal.h>
int main() {
raise(SIGABRT);
return 0;
}
编译并运行：
gcc -o test_core test_core.c ./test_core
运行后检查是否生成了core文件：
ls -la /var/crash/ core* 2>/dev/null
如果没有任何输出，说明禁用成功。同时可以用ulimit -c命令查看当前shell的core限制，应该显示0。
禁用Core Dump后如何保障调试能力
很多人担心禁用Core Dump后程序崩溃就无法调试了。实际上有更安全的替代方案。第一，可以在开发和测试环境中单独开启core dump，生产环境保持禁用。通过环境变量ulimit -c unlimited只在需要时临时开启。第二，可以使用gdb的catch throw和catch catch命令在程序运行时捕获异常，而不依赖core文件。第三，对于容器化部署的服务，可以在容器启动脚本中动态控制core生成策略，生产容器禁用，调试容器开启。
企业级安全加固的额外建议
除了禁用Core Dump，还应该配合以下措施形成完整的安全体系。首先，启用全盘加密（LUKS），即使core文件被生成，没有解密密钥也无法读取内容。其次，设置严格的文件权限策略，确保/var/crash/、/tmp/等目录的权限为700或更严格。第三，部署入侵检测系统（如AIDE或Tripwire）监控关键目录的文件变化，一旦有异常文件生成立即告警。第四，定期进行安全审计，检查是否有服务绕过了系统限制偷偷生成core文件。第五，在安全策略文档中明确规定：生产环境禁止core dump，违反者按安全事故处理。
不同Ubuntu版本的注意事项
Ubuntu 18.04、20.04、22.04和24.04在core dump处理机制上略有差异。18.04使用Apport作为默认崩溃报告工具，需要额外禁用Apport：sudo systemctl disable apport。20.04之后Apport仍然默认启用，同样需要手动禁用。22.04和24.04对systemd-coredump的依赖更强，确保/etc/systemd/coredump.conf配置正确尤为重要。另外，snap包和flatpak应用有自己独立的沙箱环境，它们的core dump行为不受系统级配置影响，需要单独处理。
常见错误和排查方法
实际操作中经常遇到配置不生效的情况。最常见的原因有三个：一是只修改了limits.conf但没有重新登录，PAM模块只在登录时读取该文件；二是systemd服务有自己的LimitCORE覆盖了全局设置；三是Apport在后台偷偷拦截了崩溃信号并生成了报告。排查时可以用cat /proc/sys/kernel/core_pattern查看内核实际使用的core模式，用systemctl show <服务名> | grep LimitCORE检查服务级限制，用journalctl -u apport查看Apport是否在运行。
总结来说，在Ubuntu生产服务器上禁用Core Dump不是一个可选项，而是安全基线的必选项。通过limits.conf、sysctl、systemd三层配置叠加，再配合定期清理和监控，可以有效杜绝敏感内存泄露的风险。安全从来不是单点防护，而是纵深防御体系中的一环。把这件事做扎实了，你的服务器安全水位就能提升一个档次。
