Debian服务器日常巡检时，我们常检查日志、更新和端口，但有几个安全死角容易被忽略：未监控的SUID/SGID文件可能被利用提权，配置错误的共享内存权限会泄露敏感数据，过期的SSL/TLS协议和弱密码套件留下中间人攻击漏洞，系统服务残留的临时文件若未清理可能包含机密信息，还有那些默认安装但从未使用的软件包，它们存在的漏洞就是敞开的后门。

一、 检查并清理危险的SUID/SGID文件

SUID（Set User ID）和SGID（Set Group ID）权限允许普通用户以文件所有者或所属组的身份执行程序。系统核心工具如passwd需要此权限，但如果非必要的程序被设置了SUID/SGID，攻击者可能利用它们进行权限提升。巡检时，我们不仅要找新增的异常文件，更要审视那些一直存在却“理所当然”的文件。

使用以下命令查找所有SUID/SGID文件：

find / -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \; 2>/dev/null

重点审查非系统标准路径（如/tmp, /var/tmp, 用户家目录）下的文件，以及如vim、find、bash等本不该拥有SUID权限的命令。对于确认非必需的文件，使用chmod移除权限：chmod u-s /path/to/file 或 chmod g-s /path/to/file。更彻底的做法是，通过包管理器查询文件归属，判断其是否应该存在：dpkg -S /path/to/file。

二、 审计共享内存（/dev/shm）与临时目录权限

/dev/shm是一个基于内存的临时文件系统，程序常在此进行高速数据交换。默认情况下，其权限为1777（drwxrwxrwt），任何用户都可创建文件，但只能删除自己的文件。问题在于，如果服务进程（如数据库、缓存服务）在此创建了包含敏感数据（如会话令牌、未加密的查询结果）的文件，并且权限设置不当，其他用户就可能读取这些数据。

巡检时，定期检查/dev/shm目录下的文件列表和权限：

ls -la /dev/shm/

关注所有者是非root且权限为可读（如644）的文件。同时，检查系统临时目录/tmp和/var/tmp，确保它们的粘滞位（sticky bit）被设置（权限中的“t”），防止用户删除他人文件。确保关键服务配置为使用私有的、权限严格的临时目录，而非全局可读的共享区域。

三、 深挖SSL/TLS配置与过期协议

很多人检查SSL证书过期时间，却忽略了协议和密码套件本身的配置。Debian旧版本可能默认启用已破译的协议如SSLv2、SSLv3或TLS 1.0。使用OpenSSL命令测试服务器配置：

openssl s_client -connect localhost:443 -ssl3 2>&1 | grep -i "protocol"

如果仍能建立连接，说明存在风险。关键在于修改Web服务器（如Nginx/Apache）和后台服务（如数据库、邮件服务）的配置。以Nginx为例，应在配置文件中明确禁用不安全的协议和密码：

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
ssl_prefer_server_ciphers on;

此外，使用sslyze或testssl.sh等工具进行自动化深度扫描，检查心脏出血、ROBOT等漏洞以及证书链是否完整。

四、 清理系统服务残留的临时文件与内存转储

系统服务（如MySQL、PHP-FPM）或应用程序崩溃时，可能会生成核心转储（core dump）或包含调试信息的临时文件。这些文件可能含有数据库连接字符串、私钥片段或用户数据。它们通常位于/var/crash、/var/lib/systemd/coredump或应用程序的工作目录中。

检查并清理这些目录：

find /var -name "core" -o -name "*.tmp" -o -name "*dump*" -type f 2>/dev/null | xargs ls -la

更重要的是，通过ulimit或systemd配置限制核心转储的生成。编辑/etc/security/limits.conf或服务的systemd unit文件（如[Service]部分添加LimitCORE=0）来禁用非必要的核心转储。

五、 清查未使用的安装包与残留配置文件

系统升级或服务移除后，会留下大量“孤儿”软件包（不再被依赖）和残留的配置文件（dpkg遗留的".dpkg-old"或".dpkg-dist"文件）。这些旧版本的包或配置文件可能包含已知漏洞。

定期执行以下操作：

# 列出不再被依赖的包
apt-get autoremove --dry-run
# 查找残留的配置文件
find /etc -name "*.dpkg-*" -o -name "*.ucf-*" -o -name "*.merge-error"

在确认无误后，执行apt-get autoremove --purge来彻底清理。同时，使用apt list --installed | grep -v automatic查看非自动安装的包，评估其存在的必要性。

六、 监控隐藏的系统d进程与用户会话

除了常见的cron和systemd服务，一些隐藏的进程或用户会话可能被忽略。例如，at作业、未退出的screen或tmux会话、甚至是通过nohup运行的后台进程。攻击者可能利用这些机制维持持久化访问。

检查命令历史：

# 查看所有用户的.at作业
ls -la /var/spool/cron/atjobs/
# 查找screen/tmux会话
find /run/screen -type s -o -path "/tmp/tmux-*" 2>/dev/null
# 查看所有用户的活动进程
ps auxf | grep -v "^USER.*COMMAND$"

确保日志（如/var/log/auth.log, /var/log/secure）配置了正确的轮转和权限，并监控异常的登录成功/失败事件，特别是非工作时间的root登录。

七、 验证备份系统的完整性与恢复流程

安全巡检的最终底线是备份。但人们常假设备份在运行，却从未验证其完整性和可恢复性。一个被忽略的死角是：备份文件本身的权限。如果备份文件（例如存储在/backup目录下的.tar.gz或.sql文件）被设置为全局可读，那么一旦攻击者获得低权限访问，就能直接窃取全部数据。

检查备份文件权限和所有权：

ls -la /备份目录路径/

确保只有备份用户和root可读。更重要的是，定期（如每季度）执行一次真实的恢复演练，从备份中随机抽取一个数据库或一组文件进行恢复，验证数据一致性和流程有效性。同时，检查备份脚本中是否硬编码了数据库明文密码，这同样是一个高危风险点。

Debian服务器的安全是一个动态过程，日常巡检不能停留在表面清单。上述这些容易忽视的角落，恰恰是防御纵深中最脆弱的一环。定期、深入、自动化地检查这些点，并将其固化为运维手册中的强制步骤，才能构建起真正稳固的服务器防线。