当Ubuntu系统进程意外崩溃时，coredump文件会被自动保存，通常位于/var/lib/systemd/coredump/目录。这些文件包含了进程崩溃时的完整内存映像，可能泄露数据库密码、API密钥、用户会话等敏感信息。如果不加过滤，直接存储或传输coredump会带来严重的安全风险。我们需要做两件事：一是合理配置coredump的存储目录和大小限制，二是确保coredump内容中的敏感信息被过滤或脱敏处理。
理解Ubuntu中coredump的生成机制
在Ubuntu系统中，coredump生成主要由systemd-coredump服务管理。当进程崩溃时，内核会通知systemd-coredump捕获内存映像。默认配置下，coredump文件会被压缩并保存在/var/lib/systemd/coredump/目录中，文件名格式通常为core.<程序名>.<PID>.<时间戳>.lz4。你可以通过命令
coredumpctl list
查看所有记录的coredump。每个coredump都包含了进程崩溃时的堆栈、寄存器状态和整个进程地址空间的数据，这正是敏感信息可能隐藏的地方。
配置coredump存储目录与大小限制
首先，我们需要调整存储目录，避免默认目录空间不足或不符合审计要求。编辑systemd-coredump配置文件：
sudo nano /etc/systemd/coredump.conf
关键参数包括：
Storage=external Compress=yes ProcessSizeMax=2G ExternalSizeMax=2G JournalSizeMax=2G SaveDump=yes
Storage设置为external表示将coredump保存在磁盘文件；ProcessSizeMax控制单个coredump的最大大小；ExternalSizeMax限制磁盘上coredump的总大小。如果你想更改存储目录，可以修改systemd-coredump服务的drop-in文件：
sudo systemctl edit systemd-coredump
然后添加：
[Service] Environment="COREDUMP_DIR=/path/to/your/coredump_directory"
保存后运行
sudo systemctl daemon-reload
使配置生效。同时，确保目录权限严格，建议设置为root:root和700权限。
识别coredump中的敏感信息风险
coredump文件本质是内存快照，任何进程运行时加载的敏感数据都可能被捕获。例如，一个Web服务器进程崩溃时，其内存中可能包含：数据库连接字符串（如"mysql://user:password@localhost:3306/db"）、OAuth令牌、加密私钥、用户提交的身份证号或信用卡信息。使用gdb或strings工具可以轻易提取这些信息：
strings /var/lib/systemd/coredump/core.program.12345.lz4 | grep -i "password\|token\|key"
这行命令会从解压后的coredump中搜索密码、令牌等关键词，验证信息泄露风险。在生产环境中，这种泄露可能违反GDPR、HIPAA等数据保护法规。
实施敏感信息过滤的三种核心方法
方法一：使用systemd-coredump的内置过滤功能。systemd-coredump支持通过CoreDumpFilter配置项选择哪些内存段被转储。编辑/etc/systemd/coredump.conf，设置：
CoreDumpFilter=0x3F
该值是一个位掩码，0x3F表示转储除匿名私有映射和匿名共享映射外的多数段，可以减少敏感数据泄露。但这种方法比较粗粒度，不能完全过滤特定内容。
方法二：通过应用程序自身的内存保护机制。在开发阶段，建议使用mlock()等系统调用锁定敏感内存区域，并在使用后立即用memset()清零。同时，避免将敏感信息存储在全局变量或堆中，而应使用加密的内存区域。对于已部署的应用，可以考虑使用工具如libcoredumpfilter进行自定义过滤。
方法三：利用coredump后处理脚本进行脱敏。编写一个脚本，在coredump保存后自动运行，使用工具如gdb或自定义解析器移除或替换敏感数据。例如，创建一个脚本/usr/local/bin/coredump-filter.sh：
#!/bin/bash # 解压coredump lz4 -d "$1" -c > /tmp/core_uncompressed # 使用sed或awk替换敏感模式（示例替换密码） sed -i 's/password=[^ ]*/password=REDACTED/g' /tmp/core_uncompressed # 重新压缩并保存 lz4 /tmp/core_uncompressed "$1.filtered" rm /tmp/core_uncompressed
然后通过systemd服务单元触发该脚本，确保每个coredump都经过处理。
自动化监控与审计策略
仅仅配置过滤还不够，需要建立监控体系。首先，启用systemd-coredump的日志记录，通过
journalctl -u systemd-coredump
跟踪coredump生成事件。其次，使用审计工具如auditd监控coredump目录的访问：
sudo auditctl -w /var/lib/systemd/coredump/ -p rwxa -k coredump_access
这会在有人读取或修改coredump文件时生成审计日志。定期审查这些日志，检测异常访问行为。此外，建议设置coredump文件保留策略，例如通过cron任务自动删除超过7天的文件：
find /var/lib/systemd/coredump/ -type f -mtime +7 -delete
减少长期存储风险。
结合SELinux/AppArmor增强安全
在Ubuntu上，AppArmor可以提供额外的强制访问控制。为关键进程（如数据库或Web服务器）配置AppArmor策略，限制其coredump的生成和访问。例如，创建一个配置文件/etc/apparmor.d/usr.bin.mysqld，添加：
deny /var/lib/systemd/coredump/ rwxl,
阻止MySQL进程写入coredump目录。然后加载策略：
sudo apparmor_parser -r /etc/apparmor.d/usr.bin.mysqld
这样即使进程崩溃，也不会生成coredump，从根本上杜绝泄露。但需权衡调试需求与安全性。
实际案例：Web服务器coredump安全实践
假设你运行一个Nginx+PHP-FPM的Web服务。首先，为PHP-FPM配置coredump过滤：在/etc/systemd/system/php-fpm.service.d/override.conf中设置CoreDumpFilter，并限制大小。其次，在PHP代码中，确保使用安全的内存处理函数，例如使用sodium_memzero()清除敏感变量。最后，部署一个监控脚本，当检测到coredump时，立即通知管理员并触发脱敏处理。整个流程可以通过Ansible或Puppet自动化部署，确保一致性。
总结：构建纵深防御体系
保护Ubuntu coredump中的敏感信息需要多层次策略。从配置systemd-coredump的存储和过滤开始，到应用程序级的内存管理，再到后处理的自动化脱敏，每一层都不可或缺。同时，结合监控、审计和强制访问控制工具如AppArmor，形成纵深防御。定期审查和测试你的配置，使用工具如coredumpctl和gdb验证过滤效果。记住，安全不是一次性的任务，而是持续的过程，随着应用和环境的变化，你的coredump安全策略也应不断演进。
