1. 项目概述为什么我们总在同一个地方跌倒在Linux系统安全领域/etc/passwd文件几乎成了“用户管理”的代名词。无论是新手教程、安全加固指南还是渗透测试报告这个文件总是被反复提及。它记录了系统上所有用户的基本信息是身份验证链条的起点。然而作为一名在运维和红蓝对抗一线摸爬滚打了十多年的老兵我越来越深刻地意识到过度聚焦于这一个点会让我们陷入一种危险的“隧道视野”。攻击者的工具箱远比我们想象的要丰富他们的视线早已越过这个众所周知的“前门”投向了那些更隐蔽、更易被忽视的“侧门”和“后窗”。这个项目或者说这篇分享源于我多次参与应急响应和渗透测试的真实经历。我们常常花费大量精力加固/etc/passwd的权限、检查其中是否有异常shell、监控其是否被篡改但攻击者却总能通过其他路径达成同样的目标——提权、持久化、横向移动。这让我开始系统性地梳理除了/etc/passwdLinux用户身份与权限管理的体系中到底还藏着哪些“灯下黑”的风险点。今天我们就彻底转换视角戴上攻击者的“帽子”一起审视Linux用户管理的五个常被忽略的隐藏风险点。这不仅仅是技术罗列更是一次思维模式的升级。我们将深入每个风险点的原理、攻击者如何利用它、以及你作为防御者应该如何有效布防。无论你是系统管理员、安全工程师还是对Linux安全感兴趣的开发者理解这些内容都将帮助你构建更立体、更坚固的防御体系。2. 核心风险点一被遗忘的“影子”——/etc/shadow之外的认证源当我们谈论密码第一反应就是/etc/shadow。它存储着用户的加密密码哈希权限严格640root:shadow似乎是铜墙铁壁。但Linux的认证体系PAM可插拔认证模块是高度可配置和可扩展的。攻击者正盯着那些非常规的、可能配置不当的认证源。2.1 PAM配置的“后门”pam_unix.so不是唯一PAM通过/etc/pam.d/目录下的配置文件如system-auth,password-auth,sshd等来定义认证栈。默认情况下pam_unix.so模块负责核对/etc/shadow。然而系统可能配置了其他认证模块。风险场景老旧系统或特定业务服务器上可能遗留了pam_ldap.soLDAP认证、pam_krb5.soKerberos认证的配置但对应的认证服务器早已下线或配置错误。更危险的是可能存在pam_pwdfile.so或pam_userdb.so这样的模块它们允许从普通文件或数据库中读取密码。如果这些文件的路径和权限设置不当例如路径在/tmp下或权限为666攻击者就可以轻易创建或篡改该文件为自己添加一个高权限用户。攻击者视角在获取初始立足点例如一个Web Shell后攻击者会迅速检查/etc/pam.d/下的文件。# 查看ssh服务的PAM配置 cat /etc/pam.d/sshd # 查找非常规的认证模块 grep -E “pam_pwdfile|pam_userdb|\.so$” /etc/pam.d/* | grep -v “^#”如果发现可疑模块下一步就是定位其使用的源文件通常在模块参数中指定如file/etc/securepass并检查该文件的权限和内容。防御者加固定期审计PAM配置使用pam_tally2或faillock模块配置登录失败锁定并审查所有非pam_unix.so的模块确认其必要性和安全性。最小化模块使用移除不必要的PAM模块。确保任何额外的认证源文件都具有严格的权限如600属主root。使用pam_wheel.so限制su在/etc/pam.d/su中启用pam_wheel.so确保只有wheel组成员才能su到root。注意直接修改PAM配置有风险可能导致所有用户无法登录。务必在测试环境验证并保留一个已登录的root会话作为恢复手段。2.2 网络认证缓存与残留凭据在一些配置了集中认证如SSSD对接AD/LDAP的环境中本地系统会缓存用户凭据以提高性能或支持离线登录。这些缓存可能成为攻击者的目标。风险场景sssd服务会将域用户的凭据信息缓存在/var/lib/sss/db/目录下的数据库中。虽然这些数据是加密的但如果攻击者已经获得了root权限他可能会尝试导出或破解这些缓存用于在其他同样信任该域的系统上尝试横向移动。此外旧的nscd名称服务缓存守护进程如果配置不当其缓存也可能包含敏感信息。攻击者视角在提权后攻击者会查看相关进程和缓存文件。# 检查SSSD是否运行及其缓存 ps aux | grep sssd ls -la /var/lib/sss/db/ # 检查nscd ps aux | grep nscd ls -la /var/db/nscd/他们可能会尝试使用sss_cache工具或直接拷贝数据库文件到自己的环境进行分析。防御者加固限制缓存内容与时间在/etc/sssd/sssd.conf中明确配置哪些属性可以缓存cache_credentials并设置较短的缓存过期时间entry_cache_timeout。使用文件系统加密对/var/lib/sss/目录所在的分区或整个磁盘进行加密如LUKS即使物理介质丢失缓存数据也不易泄露。考虑禁用离线登录对于安全性要求极高的环境权衡后可以禁用缓存强制所有认证必须连接中央服务器。3. 核心风险点二Shell不是终点——非登录用户与服务账号的滥用我们通常只关心那些能登录拥有/bin/bash或/bin/sh的用户。但Linux系统中存在大量“非登录用户”nologin或falseshell和服务账号如www-data,mysql,redis它们同样是攻击链上的重要环节。3.1nologinShell的“软突破”/sbin/nologin或/bin/false本意是阻止用户获得交互式Shell。但这并非绝对安全。风险场景许多服务账号被设置为nologin。攻击者如果通过应用漏洞如SQL注入、RCE获得了以该用户身份执行命令的能力例如www-data他们的目标就不是“登录”而是“提权”。这个服务账号可能拥有某些特殊的权限或能力足以作为跳板。SUID/SGID二进制文件攻击者会利用find命令寻找属主是该服务账号的SUID文件或者该用户所属组有权限执行的SGID文件尝试利用其中的漏洞提权。sudo权限使用sudo -l命令如果允许查看该服务账号能以root或其他用户身份运行哪些命令。有时为了方便运维管理员会给服务账号配置无密码运行特定命令的权限这可能是致命的。能力CapabilitiesLinux内核能力机制允许对特定进程授予部分root特权。攻击者会检查该用户启动的进程或相关文件是否被赋予了危险的能力如CAP_DAC_OVERRIDE忽略文件权限、CAP_SYS_ADMIN大量管理权限等。getcap -r / 2/dev/null这条命令是攻击者的利器。攻击者视角在获取一个服务账号的shell后立即进行信息收集。# 查看当前用户和组 id # 查找SUID/SGID文件 find / -type f -perm /6000 2/dev/null | xargs ls -la # 检查sudo权限需要当前用户密码但有时配置错误无需密码 sudo -l # 查找具有Capabilities的文件 getcap -r / 2/dev/null防御者加固遵循最小权限原则服务账号只应拥有其运行所必需的最小文件和目录权限。定期使用auditd或find命令审计SUID/SGID文件。精细化控制sudo避免给服务账号配置ALL(ALL) NOPASSWD: ALL这样的宽泛权限。如果需要限定到具体的、安全的命令路径。审慎使用Capabilities除非绝对必要否则不要给文件赋予Capabilities。如果必须使用应选择最细粒度的能力并确保文件本身不可被非特权用户写入。3.2 服务账号的“家目录”与配置文件即使不能登录服务账号也通常有一个家目录如/var/www/对于www-data/var/lib/mysql/对于mysql。这些目录里可能藏着密钥、配置文件、日志或临时文件。风险场景配置文件如.env,config.php,my.cnf中可能包含数据库密码、API密钥、加密盐等敏感信息。如果这些文件的权限设置不当如644甚至666被低权限用户读取就会导致信息泄露。更糟糕的是如果目录权限允许写入如/tmp/下的临时目录或配置了错误权限的网站上传目录攻击者可能植入恶意脚本或覆盖配置文件。攻击者视角遍历服务账号的家目录及其有读权限的路径。# 切换到服务账号如果已有其shell # 或者从当前权限尝试读取 find /home /var /opt -user www-data -type f -name “*.php” -o -name “*.conf” -o -name “*.cnf” -o -name “*.env” 2/dev/null | head -20 # 尝试读取常见的配置文件 cat /var/www/html/config.php 2/dev/null | grep -i pass防御者加固严格的文件权限确保敏感配置文件权限为600仅属主可读可写目录权限为700。使用chown和chmod严格管控。隔离运行环境使用容器Docker、命名空间或chrootjail来隔离服务账号的文件系统视图使其无法访问无关路径。使用密钥管理服务避免在配置文件中硬编码密码。使用如HashiCorp Vault、AWS Secrets Manager或云原生的KMS服务来动态获取凭据。4. 核心风险点三时间维度上的攻击——用户会话与进程残留安全是一个动态的过程我们不仅要看静态的配置文件还要看系统运行时状态。用户登录后留下的会话和进程是攻击者进行“横移”和“潜伏”的温床。4.1 存活进程中的敏感信息进程的内存空间可能包含敏感信息如密码、令牌、私钥等。ps、top命令只能看到命令行参数而通过/proc文件系统可以窥探更多。风险场景管理员可能通过命令行传递密码这是一个非常糟糕的习惯例如mysql -u root -pMySecretPassword。此时密码会出现在该进程的命令行参数中任何能执行ps aux或查看/proc/[pid]/cmdline的用户都能看到。此外通过/proc/[pid]/environ可以查看进程的环境变量其中也可能包含敏感数据。攻击者视角一旦进入系统快速扫描进程信息。# 查找命令行中包含密码特征的进程 ps auxwww | grep -E ‘[Pp]ass|[Kk]ey|[Ss]ecret’ | grep -v grep # 查看特定进程的环境变量例如一个已知的Web服务器PID cat /proc/$(pgrep -f ‘nginx|apache|httpd’ | head -1)/environ | tr ‘\0’ ‘\n’ | grep -i pass如果发现某个进程属于高权限用户如root且命令行中有密码攻击者可能会尝试向该进程发送信号或尝试读取其内存。防御者加固永远不要在命令行中传递密码使用配置文件、环境变量文件注意权限、交互式输入或密码管理器。对于自动化脚本考虑使用具有受限权限的专用配置文件或密钥。限制/proc访问考虑通过mount选项如hidepid2来限制非特权用户查看其他用户的进程信息。这需要重新挂载/proc操作需谨慎。# 在/etc/fstab中添加 proc /proc proc defaults,hidepid2 0 0 # 然后重新挂载 mount -o remount /proc定期清理与监控使用auditd监控对/proc下敏感文件如cmdline,environ的读取访问。4.2 孤儿会话与未注销的终端用户通过SSH登录后如果网络异常断开或用户直接关闭了终端会话可能不会立即结束。screen或tmux会话更是可以长期存在。风险场景一个root用户通过SSH登录到服务器然后直接关闭了终端窗口没有执行exit或logout。这个SSH会话进程可能仍然存在。攻击者如果获得了另一个用户比如一个被入侵的Web用户的权限他可以使用ps或w命令查看当前登录的用户和他们的TTY。虽然他不能直接接管一个活跃的TTY需要root权限或特定的ptrace能力但这个信息本身很有价值。更危险的是如果该root用户使用了screen或tmux并处于分离detached状态攻击者若能访问到该用户的终端设备文件如/dev/pts/[number]理论上存在劫持可能难度很高但并非不可能。攻击者视角收集系统活跃用户和会话信息。# 查看当前登录用户及他们的来源 w # 查看所有进程寻找SSH守护进程和用户进程 ps aux | grep -E ‘sshd:.*pts|screen|tmux’ # 查找所有可写的终端设备低概率但可尝试 find /dev/pts -writable 2/dev/null防御者加固配置SSH超时在/etc/ssh/sshd_config中设置ClientAliveInterval和ClientAliveCountMax让服务器主动断开空闲连接。ClientAliveInterval 300 # 300秒5分钟发送一次保活消息 ClientAliveCountMax 2 # 最多发送2次无响应则断开使用TMOUT环境变量在全局shell配置如/etc/profile或/etc/bash.bashrc中设置TMOUT600600秒无操作自动注销但这只对新会话生效。培养良好习惯管理员应养成使用exit命令退出会话的习惯。对于screen/tmux不使用时应及时终止会话。监控与告警使用工具监控异常长时间存活的用户会话特别是root用户的会话。5. 核心风险点四权限体系的“灰色地带”——组、SUDO与文件能力Linux的权限模型用户/组/其他看似简单但结合特殊权限位SUID, SGID, Sticky Bit和现代扩展属性文件扩展属性xattr如Capabilities, ACL构成了复杂的“灰色地带”极易配置失误。5.1 松散的用户组管理将用户加入某个组就赋予了该用户访问该组所拥有文件的能力。一些默认组或常用组权限过大。风险场景adm组通常可以读取/var/log下的许多日志文件。攻击者加入此组后可以分析系统日志寻找其他用户的敏感操作、错误信息可能包含密码、SSH登录记录等用于信息收集和横向移动。disk组或operator通常拥有直接访问原始磁盘设备如/dev/sda的权限。这意味着组成员可以绕过文件系统权限直接读取或写入磁盘上的任何数据包括/etc/shadow。docker组该组用户可以直接与Docker守护进程通信而Docker守护进程默认以root权限运行。这意味着docker组成员可以轻松获得宿主机的root权限例如运行一个将宿主机根目录挂载到容器内的容器。攻击者视角查看当前用户所属的组并探索这些组的“威力”。id # 如果发现自己在docker组 docker run -v /:/hostOS -it ubuntu chroot /hostOS bash # 如果发现自己在disk组 dd if/dev/sda1 of/tmp/mbr.bak bs512 count1 # 备份MBR实际攻击中会尝试读取敏感数据防御者加固审计用户组分配定期审查/etc/group文件确保用户只属于必要的组。使用getent group groupname查看组成员。重审默认组权限检查系统关键设备文件如/dev/sd*,/dev/mem和目录如/var/log的组权限。考虑是否需要调整。对于Docker除非必要否则不要将普通用户加入docker组而是使用sudo来运行docker命令。使用用户私有组UPG模式在创建用户时系统会默认创建一个同名的私有组。将用户文件默认组设为该私有组而不是共享的、权限宽泛的组。5.2 SUDO规则的“宽进宽出”sudo是双刃剑。配置不当的sudoers文件/etc/sudoers或/etc/sudoers.d/下的文件是提权的快车道。风险场景通配符滥用规则如john ALL(ALL) NOPASSWD: /usr/bin/vim /etc/*。意图是让john能用vim编辑/etc/下的文件。但攻击者可以运行sudo vim /etc/shadow然后在vim中执行:! /bin/bash或shell从而逃逸获得一个rootshell。因为vim允许执行外部命令。路径劫持规则如lucy ALL(ALL) NOPASSWD: /home/lucy/scripts/*。如果/home/lucy/scripts/目录对lucy可写她可以创建一个名为ls的恶意脚本然后当管理员执行sudo /home/lucy/scripts/ls时实际运行的是她的脚本。环境变量继承如果sudoers中配置了env_reset或明确的env_keep攻击者可能通过操纵环境变量来影响sudo执行的命令行为。攻击者视角第一件事就是查看自己能sudo什么。sudo -l仔细分析输出。如果看到任何可以无密码运行的命令特别是那些涉及编辑器vim, nano, ed、语言解释器python, perl, ruby、文件读取cat, less, more或网络工具curl, wget, nc的命令攻击者的大脑就会开始飞速思考如何将其转化为一个完整的shell。防御者加固遵循最小命令原则不要授予ALL。授予具体的、功能单一的、安全的命令。避免使用通配符尤其是涉及目录遍历的。使用绝对路径并限制参数在sudoers中始终使用命令的绝对路径。如果可以进一步限制允许的参数。例如/usr/bin/systemctl restart nginx比/usr/bin/systemctl更安全。设置secure_path和env_reset在/etc/sudoers的Defaults行中确保secure_path被设置防止PATH劫持并且env_reset被启用重置环境变量。定期审计与模拟测试使用visudo -c检查语法。定期以普通用户身份运行sudo -l并思考每一条规则是否可能被滥用。可以使用sudo -u user command进行模拟测试。6. 核心风险点五元数据与审计盲区——谁在何时做了什么即使加固了所有静态配置和权限如果不知道系统上发生了什么安全依然是“睁眼瞎”。攻击者依赖于系统的“静默”来隐藏行踪。6.1 弱化的日志与审计配置默认的syslog或rsyslog/systemd-journald配置可能不会记录关键的安全事件或者日志保留时间太短、权限不当。风险场景不记录认证日志SSH的成功/失败登录、su、sudo命令的执行如果没有被详细记录攻击者就可以在“黑暗”中操作。不记录命令历史用户的~/.bash_history文件可能被清空、链接到/dev/null或者HISTCONTROL环境变量被设置为ignorespace/ignoreboth/ignoredups使得大量命令不被记录。root用户的命令历史可能默认不记录或记录不全。日志文件权限不当如果日志文件如/var/log/auth.log对非特权用户可读攻击者可以查看自己的攻击痕迹是否被记录甚至可能篡改日志如果可写。攻击者视角进入系统后会立即尝试清理痕迹并评估审计强度。# 清空当前用户的命令历史 history -c history -w # 或者直接清空历史文件 ~/.bash_history # 查看有哪些日志服务在运行 ps aux | grep -E ‘rsyslog|syslog|journald’ # 查看认证日志看自己的登录是否被记录 tail -f /var/log/auth.log /var/log/secure 2/dev/null # 检查auditd是否运行 systemctl status auditd 2/dev/null防御者加固启用并配置auditdauditd是Linux内核的审计框架功能强大。至少应启用以下规则监控对/etc/passwd,/etc/shadow,/etc/sudoers等关键文件的读写、属性更改。监控所有用户的提权操作sudo,su。监控系统调用如execve来记录命令执行对性能有影响需谨慎。 配置示例/etc/audit/rules.d/audit.rules-w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/sudoers -p wa -k privilege-escalation -a always,exit -F archb64 -S execve -k exec强化系统日志配置rsyslog或systemd-journald确保认证、授权、关键服务日志被记录并发送到远程的、受保护的日志服务器SIEM。保护日志文件确保日志文件权限为640root:adm或root:wheel目录权限为750。使用logrotate妥善管理日志轮转和保留策略保留至少180天以满足合规要求。强制命令历史记录在全局配置中如/etc/profile设置export HISTTIMEFORMAT“%F %T “ # 为历史记录添加时间戳 export HISTSIZE10000 # 保留大量历史 export HISTFILESIZE20000 export HISTCONTROL“” # 不禁用任何记录 shopt -s histappend # 追加而不是覆盖历史文件 # 对于root可以记录到单独的安全文件 if [ “$(id -u)” -eq 0 ]; then export HISTFILE“/var/log/root_bash_history” chmod 600 “$HISTFILE” fi6.2 隐藏进程与网络连接高级攻击者会使用Rootkit技术来隐藏进程、网络连接和文件。虽然这超出了基础用户管理的范畴但与之相关的是系统管理员缺乏有效的检测手段。风险场景攻击者植入内核模块或修改系统调用使ps,netstat,ls等命令返回经过过滤的结果隐藏恶意进程和端口。普通的管理员检查将一无所获。防御者视角如何发现异常交叉验证使用不同来源的工具进行对比。例如用ps aux查看进程列表同时用cat /proc/[0-9]*/comm查看/proc下的进程名。用netstat -tulnp查看网络连接同时用ss -tulnp或直接查看/proc/net/tcp文件。基于行为的监控使用auditd监控execve系统调用或者使用sysdig、Falco这样的运行时安全工具它们基于内核事件更难被用户态的Rootkit欺骗。文件完整性监控FIM使用aide或tripwire等工具定期检查系统关键文件二进制文件、配置文件、库文件的哈希值是否发生变化。网络流量分析在网络边界部署IDS/IPS检测异常的出站连接如连接到已知C2服务器。7. 系统性加固检查清单与日常运维建议理解了上述风险点后我们需要一套可操作的系统性加固动作。以下是我在实践中总结的检查清单建议定期如每季度执行一次。7.1 用户与组账户审计检查无效账户查看/etc/passwd中那些shell为/bin/false或/sbin/nologin且最近从未登录过的系统账户。确认它们是否仍有必要存在。使用lastlog命令查看用户最后登录时间。检查UID/GID为0的用户除了root不应有其他用户的UID为0。执行awk -F: ‘$30 {print $1}’ /etc/passwd进行检查。检查空密码账户执行awk -F: ‘$2“” {print $1}’ /etc/shadow需要root权限任何结果都是严重问题。审查/etc/group检查adm,disk,docker,wheel,sudo等特权组的成员移除不必要的用户。检查.rhosts和.shosts文件这些是过时且不安全的信任机制应全局查找并删除find / -name .rhosts -o -name .shosts 2/dev/null。7.2 认证与权限配置审计审计PAM配置检查/etc/pam.d/下所有文件确保没有引用未知或危险的模块。重点关注su,sshd,sudo的配置。审计sudoers使用visudo -c检查语法。逐一审查每一条规则确保其符合最小权限原则。特别注意无密码NOPASSWD的规则。查找SUID/SGID文件执行find / -type f -perm /6000 2/dev/null对结果列表中的每一个文件问自己这个文件真的需要这些特殊权限吗常见的合法SUID文件包括/bin/passwd,/bin/su,/usr/bin/sudo。陌生的、位于/tmp或用户家目录下的SUID文件极度危险。查找具有Capabilities的文件执行getcap -r / 2/dev/null审查列表。像/usr/bin/ping需要CAP_NET_RAW是合理的但一个自定义的二进制文件拥有CAP_DAC_OVERRIDE就需要调查了。7.3 文件系统与日志审计检查关键文件权限/etc/passwd-rw-r--r--(644)/etc/shadow-rw-r-----(640) 或-r--------(400)属主root组shadow/etc/group-rw-r--r--(644)/etc/sudoers-r--r-----(440)/etc/ssh/sshd_config-rw-------(600)检查用户家目录权限普通用户的家目录应为755drwxr-xr-x或更严格不应是777。检查是否存在全局可写的家目录find /home -type d -perm -ow 2/dev/null。验证日志配置确认rsyslog/systemd-journald服务正在运行。确认/var/log/auth.log或/var/log/secure中有SSH、sudo等日志。确认auditd服务是否安装并运行规则是否生效auditctl -l。检查计划任务查看/etc/crontab、/etc/cron.*/目录以及各用户的crontabls /var/spool/cron/crontabs/寻找可疑任务。7.4 建立持续监控与响应流程加固不是一劳永逸的。必须建立持续的监控。部署HIDS考虑部署开源的HIDS主机入侵检测系统如Wazuh或OSSEC。它们能提供文件完整性监控、日志集中分析、rootkit检测、主动响应等功能将上述很多手动检查自动化。集中化日志管理将服务器、网络设备、安全设备的日志集中收集到SIEM如Elastic Stack, Graylog中进行关联分析和告警。定期漏洞扫描与渗透测试使用Nessus, OpenVAS等工具进行定期的漏洞扫描。更重要的是定期至少每年一次聘请外部团队或内部红队进行渗透测试以攻击者的视角发现防御盲点。制定并演练应急响应计划当发现入侵迹象时知道第一步该做什么如隔离网络、保存现场、分析痕迹比技术本身更重要。从攻击者视角审视系统是一个不断打破思维定式的过程。安全没有银弹真正的安全来自于对细节的执着、对“理所当然”的质疑以及一套覆盖预防、检测、响应的完整体系。希望这五个隐藏风险点及其应对策略能为你点亮几盏之前忽略的“灯”让你的Linux系统更加固若金汤。记住最好的防御是理解进攻。