1. 从一次真实的内部安全演练说起上个月我们团队进行了一次内部红蓝对抗演练。我作为蓝队成员负责防守几台关键的Linux应用服务器。演练开始没多久监控告警就响了——有一台测试机的SSH登录日志出现了异常。我立刻登录上去排查在/var/log/auth.log里看到了大量来自内网未知IP的失败尝试。这显然是红队在尝试横向移动。我当时的第一个念头不是去封IP而是立刻检查这台服务器上有没有“遗留”的敏感文件。因为经验告诉我攻击者一旦通过某种方式比如利用一个脆弱的Web应用拿到了一个低权限的shell他们的首要目标绝不是立刻提权而是翻箱倒柜寻找能让他们通往其他系统的“钥匙”——也就是各种配置文件、脚本、备份文件里明文存储的账号密码。果然我在一个用于部署的deploy.sh脚本里发现了硬编码的数据库密码在一个~/.bash_history文件里看到了带-p参数的mysql命令记录甚至在一个临时日志文件里找到了某次调试时打印出的完整连接字符串。如果红队成员先我一步找到这些他们就能轻松登录数据库窃取数据甚至以此为跳板攻击网络中的其他机器。这次经历再次印证了一个老生常谈却又极易忽视的真理在Linux系统上敏感信息的泄露往往不是由于高深的技术漏洞而是源于运维中的不良习惯和疏忽。无论是内网渗透测试中的攻击方还是日常运维中的防守方掌握一套系统性的敏感文件查找方法都至关重要。对于安全研究人员和运维工程师而言在Linux环境下定位潜在的账号密码泄露点是一项基础且核心的技能。这不仅仅是“找密码”更是理解应用程序行为、梳理配置脉络、进行安全审计的过程。本文将从实战角度出发抛开那些华而不实的自动化工具依赖深入讲解如何基于Linux系统本身的特点用手工结合命令的方式高效、精准地完成这项任务。我们会从常见存储位置、针对性搜索命令、历史痕迹分析、到内存与进程中的密码抓取形成一个完整的排查链路。无论你是想加固自己的服务器还是在授权范围内进行安全评估这些方法都能提供直接的帮助。2. 理解敏感信息的常见藏身之处在开始“翻找”之前我们必须先知道去哪里找。Linux系统中的密码和密钥并不会像Windows的LSA Secrets那样有一个统一的保险库。它们往往分散在以下几个地方其存在通常都有合理的业务原因但也因此成为安全隐患。2.1 配置文件密码的重灾区这是最直接、最普遍的存储位置。许多应用程序为了自动化运行会将连接凭证写入配置文件。用户级配置在用户家目录下以点号.开头的隐藏文件是首要目标。例如~/.ssh/包含id_rsa私钥、known_hosts曾连接过的主机密钥有时甚至会有config文件里明文写有连接密码虽然不推荐。~/.aws/credentials和config文件可能包含AWS的访问密钥和密钥。~/.docker/config.json可能包含容器仓库的登录凭证。~/.git-credentialsGit的凭据缓存文件。~/.bashrc,~/.bash_profile,~/.zshrc等这些shell初始化文件里有时会为了方便而直接导出环境变量如export DB_PASSWORD123456这是极其危险的做法。~/.mysql_history,~/.psql_history等数据库客户端的命令历史如果执行过带密码的连接命令就会被记录在此。系统级与应用级配置位于/etc目录下或应用安装目录中。/etc目录这是核心区域。像/etc/passwd和/etc/shadow需root权限存储着系统用户哈希但我们的目标更多是应用配置。例如/etc/mysql/my.cnf或/etc/mysql/debian.cnf中可能有数据库密码旧的FTP服务器配置/etc/vsftpd.confWeb应用的配置文件如/etc/apache2/sites-available/下的某些conf文件可能包含数据库连接信息。应用目录例如一个Web应用根目录下的config.php、application.yml、.env文件。特别是.env文件在框架如Laravel、Django中常用它本意是隔离环境变量但若权限设置不当或误提交到代码库就会导致密码泄露。查找命令如find /var/www -name *.env -o -name *config*.php -o -name application*.yml 2/dev/null。注意直接搜索/etc下的所有文件包含“password”字符串可能会返回大量结果其中很多是注释或示例。更有效的方法是结合对服务如mysql,postgresql,redis的了解定位其标准配置文件路径。2.2 脚本文件自动化背后的隐患Shell脚本、Python脚本、SQL脚本等是自动化运维的利器也常常是密码的“陈列馆”。为了在脚本中直接连接数据库、调用API或远程执行命令开发者常常图省事将密码以明文形式写在脚本里。部署脚本(deploy.sh,update.sh)可能包含SCP、SSH、Ansible或数据库的明文密码。备份脚本(backup.sh)为了自动备份数据库到远程常出现mysqldump -u root -ppassword这样的命令。定时任务脚本(cron job)在/etc/cron.*/目录下或用户crontab -l列出的任务中调用的脚本需要仔细检查。查找技巧使用grep时不要只搜索password还要搜索pwd、pass、secret、key、token等常见变量名并且使用-r进行递归-i进行忽略大小写。例如grep -r -i pass\|pwd\|secret /opt/scripts/ 2/dev/null。2.3 日志文件被遗忘的泄露现场日志的本意是记录但常常记录了不该记录的东西。应用程序在调试或报错时可能会将完整的连接字符串、请求参数包括密码打印到日志中。Web服务器日志/var/log/apache2/access.log或/var/log/nginx/access.log中如果采用GET方式传递密码极其错误会在URL中明文显示。错误日志(error.log)中也可能包含配置信息或堆栈跟踪里的敏感数据。应用日志在/var/log/下或应用自定义目录中如/var/log/tomcat/、/home/app/logs/。查找最近修改过的、较大的日志文件。命令历史之前提到的.bash_history是最典型的例子。但要注意如果用户设置了HISTCONTROLignorespace并在命令前加空格该命令就不会被记录。此外还可以检查~/.sh_history,~/.zsh_history等。2.4 内存与进程运行时密码的提取这是进阶技术通常需要root权限。有些密码永远不会落盘只存在于进程的内存空间里。例如一个启动了的MySQL服务进程其内存中必然持有连接数据库的密码或哈希一个通过ssh-agent缓存的私钥密码也存在于内存中。进程命令行参数使用ps auxfww或ps -ef命令查看进程启动时的完整命令行。有时密码会通过-p参数直接传递。例如一个过时的mysqld启动命令/usr/sbin/mysqld --usermysql --passwordMySuperSecretPass。进程内存转储使用gdbGNU调试器或/proc/$PID/mem接口可以附加到进程并尝试从其内存空间中搜索字符串。这是一个更复杂、对系统有侵入性的操作必须在授权范围内谨慎进行。一个相对简单的命令是使用strings工具处理进程的内存映射strings /proc/$PID/mem | grep -i pass。但更常见和专业的做法是使用像gcore生成核心转储文件然后用strings分析。3. 手工排查构建你的搜索命令组合拳了解了目标在哪下一步就是组织有效的搜索。完全依赖单一自动化脚本可能会遗漏上下文或产生大量误报。手工排查的核心思路是由面到点层层递进。3.1 初始侦察快速定位可疑文件首先获得一个shell后无论什么权限先对环境有个整体了解。当前用户与权限idwhoamisudo -l查看当前用户能以root身份运行哪些命令这本身可能就是个突破口。系统信息uname -acat /etc/*-release了解系统版本。运行的服务netstat -tulpn或ss -tulpn查看开放端口和对应进程这能告诉你系统上跑了什么服务MySQL? Redis? PostgreSQL?从而明确重点搜索方向。查找有特殊权限或最近修改的文件find / -perm -4000 -type f 2/dev/null查找SUID文件提权可能。find / -perm -2000 -type f 2/dev/null查找SGID文件。find / -type f -mtime -7 2/dev/null查找最近7天内修改过的文件。攻击者上传的工具或修改的配置可能在其中。find / -type f -name “*.bak” -o -name “*.old” -o -name “*.temp” 2/dev/null。备份文件、旧配置文件往往包含原始的、未加密的密码。3.2 核心搜索基于内容的精准挖掘这是最关键的步骤。我们将使用find、grep、awk等命令的组合。基础关键字搜索从根目录开始搜索包含常见密码关键词的文件。注意这会比较慢且可能触发大量权限错误所以我们将错误输出重定向到/dev/null。# 搜索包含password, pass, pwd等关键词的文件并显示匹配行的前后几行内容 grep -r -n -i -B2 -A2 passw\|pwd\|secret\|key\|token /etc /home /opt /var 2/dev/null | head -100-B2 -A2参数可以显示匹配行前后各2行的内容这对于理解密码的上下文比如是哪个变量、在哪个配置文件里非常有帮助。针对特定格式的搜索密码有时会以特定格式出现。连接字符串搜索mysql://postgresql://jdbc:://user:pass。grep -r ://[^:]*:[^]* /home /opt 2/dev/nullBase64编码看起来像乱码的长字符串可能是编码后的密码。可以搜索结尾的字符串或者用grep -E匹配Base64字符集。grep -r -E ([A-Za-z0-9/]{4})*([A-Za-z0-9/]{3}|[A-Za-z0-9/]{2})? /path/to/search 2/dev/null | head -20JSON或YAML格式搜索password:password:。grep -r -i \password\\s*: /path/to/search 2/dev/null检查历史与内存命令历史立即查看当前shell的历史以及所有可读用户的.bash_history。history # 当前shell历史 cat ~/.bash_history for user in $(ls /home); do echo History for $user ; cat /home/$user/.bash_history 2/dev/null | tail -50; done进程信息ps auxfww | grep -E “(mysql|redis|postgres|ssh)” # 查看相关进程的命令行 # 如果有root权限可以尝试从进程内存中搜索字符串 # 例如找到MySQL的PID PID$(pgrep mysqld) if [ ! -z $PID ]; then strings /proc/$PID/environ | grep -i pass fi3.3 权限提升与深度搜索如果当前用户权限较低很多文件无法读取。那么搜索的第一步可能变成了权限提升。利用找到的数据库密码尝试登录数据库也许能在数据库里找到其他系统的密码例如某些应用将配置存在数据库里。或者利用找到的SSH私钥尝试连接其他服务器。这就是所谓的“横向移动”。在获得更高权限尤其是root后搜索范围将豁然开朗读取所有用户的家目录grep -r -i “pass” /home/* 2/dev/null。检查/etc/shadow虽然密码是哈希值但弱密码可以通过哈希碰撞或彩虹表破解。可以使用unshadow工具结合john或hashcat进行破解测试仅限授权测试。检查内存中的敏感信息使用/proc文件系统或工具如linpeas、LinEnum这些是自动化脚本但原理是手工命令的集合进行更全面的信息收集。4. 从攻击者视角看防御如何让你的密码“隐身”了解了攻击者如何寻找密码我们就能更好地进行防御。这不仅仅是安全人员的职责更是每一位系统管理员和开发者的必修课。4.1 配置管理杜绝明文存储使用配置管理工具与密钥库将密码、API密钥等敏感信息从配置文件中彻底移除。使用如HashiCorp Vault、AWS Secrets Manager、Azure Key Vault等密钥管理服务。在应用启动时从这些服务动态拉取凭据。环境变量对于简单场景可以使用环境变量。但要注意环境变量在ps命令中可能被看到通过/proc/$PID/environ且可能在日志中泄露。确保不将敏感信息打印到日志。配置文件权限如果必须使用配置文件将其权限设置为仅所有者可读chmod 600 config.properties。并确保其所属用户和组正确。4.2 开发与运维规范代码审查将“硬编码密码/密钥”作为代码审查的高危项。使用预提交钩子pre-commit hook扫描代码中是否含有密码模式。清理历史记录定期清理或妥善管理命令历史。对于包含敏感信息的命令可以在其前面加空格如果HISTCONTROL设置了ignorespace或者直接unset HISTFILE再执行命令但更好的做法是根本不在命令行中直接输入密码。最小权限原则运行服务的账户如mysqlwww-data不应该有读取其他用户家目录或无关配置文件的权限。通过严格的用户和文件权限控制即使某个服务被攻破也能将影响范围限制在最小。4.3 日志与监控日志脱敏确保应用程序和中间件的日志配置中启用了脱敏功能避免将密码、令牌、身份证号等敏感信息写入日志。文件完整性监控使用工具如AIDE、Tripwire或Osquery监控关键配置文件如/etc/passwd/etc/shadow Web应用配置文件的变更并在发生未授权修改时告警。进程监控监控异常进程的创建特别是那些尝试读取/etc/shadow或大量扫描文件系统的进程。5. 实战案例一次完整的内部排查模拟假设我们作为内部安全员接到通知某台Web服务器(192.168.1.10)可能因一个过时的Web框架版本存在漏洞而被初步入侵。我们需要登录该服务器检查是否存在敏感信息泄露并评估风险。步骤1初始连接与环境评估通过SSH使用已有账号登录。首先检查当前权限(id)发现是普通用户webadmin。运行sudo -l发现该用户被允许以root身份运行/usr/bin/systemctl restart apache2这是一个有价值的点但暂时用不上。先看看系统跑着什么ss -tulpn显示有80Apache、3306MySQL、22SSH端口开放。步骤2针对性搜索Web相关配置既然有Apache和MySQL重点搜索相关配置和代码。# 查找网站根目录通常Apache默认在/var/www/html find /var/www -type f -name “*.php” -o -name “*.env” -o -name “config*.php” -o -name “*.yml” -o -name “*.yaml” 2/dev/null | head -20发现路径/var/www/html/wordpress/wp-config.php。这是WordPress的配置文件经典的存在数据库密码的地方。cat /var/www/html/wordpress/wp-config.php | grep -A2 -B2 “DB_PASSWORD”果然找到了define(DB_PASSWORD, Wpss123456);。步骤3利用找到的密码进行横向试探尝试用这个密码连接本机的MySQL。mysql -u wordpressuser -pWpss123456 -h 127.0.0.1成功登录。在MySQL中可以查看是否有其他数据库或表存储了更多信息。执行show databases;发现除了wordpress库还有一个app_config库。进入该库发现一张表service_credentials里面竟然明文存储了访问内网另一台Redis缓存服务器(192.168.1.20)和一台文件服务器(192.168.1.30)的密码。步骤4扩大搜索范围退出MySQL。现在有了新的目标。同时继续在本地搜索。# 检查webadmin用户的历史和文件 cat ~/.bash_history ls -la ~/.ssh/ cat ~/.ssh/config 2/dev/null # 搜索备份脚本 find / -type f -name “*.sh” -exec grep -l “pass\|pwd” {} \; 2/dev/null在/opt/scripts/backup_db.sh中发现使用了mysqldump -u root -pRootDBPass!#的命令。这又是一个高权限的数据库密码。步骤5评估与报告至此我们发现了至少三处严重的明文密码泄露WordPress配置文件中的数据库密码已导致可访问app_config库。app_config库中存储的其他内网服务密码导致内网横向移动风险剧增。备份脚本中的MySQL root密码导致数据库完全失控。根本原因开发人员将生产数据库密码硬编码在配置文件中另一个应用将多个服务的凭证以明文形式存在业务数据库里运维人员在脚本中直接使用root密码。防御措施完全缺失。建议立即更改所有涉及的服务密码。将WordPress的wp-config.php文件权限设置为640所有者设为root组设为Web服务器用户。废除备份脚本中的明文密码改用mysql_config_editor设置登录路径或从安全存储中获取。彻底改造app_config库移除明文密码引入统一的密钥管理服务。对所有服务器进行一轮类似的敏感信息扫描。通过这个模拟案例你可以看到一次简单的查找如何像剥洋葱一样层层深入地揭示出整个系统中脆弱的安全实践。它远不止是执行几条grep命令而是一个结合了系统知识、应用理解、逻辑推理和持续验证的过程。无论是攻击还是防御对这套流程的熟练掌握都价值连城。