渗透工程师面试

面试官把一台ThinkPad推到我面前，渗透师面试屏幕上是工程三个打开着的终端窗口。“这台机器是渗透师面试我们内网的一台跳板机，已经拿到权限了，工程现在要你在这个基础上继续深入。渗透师面试”他说这话时语气平淡，工程像在描述今天食堂的渗透师面试菜色。我坐下来，工程手指搭上键盘，渗透师面试第一反应是工程检查当前用户的sudo权限。 渗透测试和渗透工程师面试是渗透师面试两码事。前者考验技术栈的工程广度，后者更在意你面对未知时的渗透师面试思维路径。那次面试我记忆犹新——不是工程因为题目多难，而是渗透师面试面试官中途打断了我的一次操作：“你为什么要先跑linpeas？你连目标系统是什么发行版都没确认。”他说得对。我默认了所有Linux环境都是Ubuntu，却忘了有些内网机器用的是CentOS 7，甚至更老的RHEL 6。工具脚本的兼容性会直接让你漏掉关键漏洞。 那场面试让我总结出一个规律：真正拉开差距的，不是你会多少CVE的利用手法，而是你能否在拿到shell的那一秒，就建立起清晰的决策树。比如，先看历史命令——很多管理员会把密码直接敲在命令行里；再看/etc/shadow的修改时间，如果最近有变动，说明有人改过密码，可能和日志清理时间对得上；最后才轮到跑自动化枚举脚本。顺序错了，效率就低了。 我见过太多面试者在“SQL注入”这类经典问题上滔滔不绝，但一遇到“如果目标站是纯静态页面，没有动态参数，你怎么办”就卡壳。这种时候我通常会反问：“你确认过robots.txt和sitemap.xml了吗？有时候备份文件就藏在那里。”对方往往一愣。他们太习惯打有准备的仗，却忘了渗透的本质是应对意外——没思路的时候，去翻HTTP响应头里的Server字段，看看是不是某个小众中间件，往往比盲目扫目录有用。 还有一次，面试官让我现场解读一段WAF日志。日志里全是扫描特征，但混着一条正常的POST请求。我盯着那条请求看了半分钟，发现它提交的参数里带着一个base64编码的字符串，解码后是“../../../../etc/passwd”的变体——把斜杠换成了反斜杠，WAF的正则没匹配到。我指给面试官看，他点了点头，没说话。后来我才知道，那是他们真实业务环境里发生过的攻击，当时被拦截了，但日志一直留着当考题。 技术面试到最后，面试官往往会抛出一个开放性问题：“如果给你三天时间，对一个完全陌生的企业内网做渗透，你的第一步是什么？”别急着说“信息收集”这种废话。我会说：先拿到一个物理位置——比如通过招聘网站找到该公司IT部门的办公地点，然后假装成网络维修工，混进大楼的机房里拍几张照片。当然，这是玩笑话，但面试官笑了。他知道我明白，真正的渗透从来不只是屏幕上的代码，还包括对人性的判断。 回到那台ThinkPad。我最后是通过一个遗留的cron任务提权的——某位离职工程师写了个备份脚本，密码直接硬编码在脚本里。面试官看完我的操作，把电脑收回去，说：“明天来报到吧。”我没问他为什么选我，但心里清楚，可能是我在检查cron任务前，先看了一眼系统里有哪些用户，发现有个叫“backup”的账号，登录shell是/bin/bash——这细节，很多人会漏掉。

很赞哦!（3）