内容摘要：去年冬天，我在一台暴露在公网的Redis服务器上栽了跟头。那台机器跑着6.2.6版本，未授权访问，端口6379大敞着。我本以为拿下它只需要三分钟——结果花了整整一个下午。问题出在目标系统是CentOS

去年冬天，渗透我在一台暴露在公网的服务Redis服务器上栽了跟头。那台机器跑着6.2.6版本，渗透未授权访问，服务端口6379大敞着。渗透我本以为拿下它只需要三分钟——结果花了整整一个下午。服务问题出在目标系统是渗透CentOS 7，默认的服务SELinux策略卡住了写SSH公钥的路径。这件事让我重新审视一个老话题：用Kali做渗透，渗透工具本身不是服务关键，理解目标环境才是渗透。

Kali Linux预装了六百多个工具，服务但真正高频使用的渗透就那么二十来个。nmap扫端口，服务dirb或gobuster跑目录，渗透Burp Suite抓包改包，Metasploit做漏洞利用，hydra或medusa爆破凭证。这套组合拳打下来，能覆盖大部分中低难度的靶机。问题是很多人把Kali当成了“一键入侵”的魔法盒，打开终端就敲msfconsole，连目标跑什么服务都没搞清楚。

我见过一个真实的案例。某次内部攻防演练，红队成员用Kali扫到一个Tomcat管理后台，弱口令admin/admin直接进去了。上传war包拿shell，整个过程不到十分钟。但蓝队那边其实早就部署了WAF和EDR，之所以没拦住，是因为Tomcat版本太老，WAF规则库没覆盖那个特定的文件上传路径。这说明什么？工具再强，也得看目标有没有对应的防护盲区。

说回技术细节。Kali下做信息收集，我习惯先跑一次nmap -sS -sV -p- -T4。全端口扫描很慢，但能发现那些藏在高端口上的服务。有一次扫到27017端口开着MongoDB，未授权访问，直接mongodump把整个数据库拖下来了。这种低垂的果实现在越来越少，但偶尔还能碰到。扫完端口别急着上漏洞利用，先看看HTTP响应头、robots.txt、sitemap.xml这些边角料。很多时候，一个泄露的.git目录或者备份文件就能省掉后面所有麻烦。

拿到初始shell之后，提权是下一个坎。Kali自带LinEnum.sh和linux-exploit-suggester，但别完全依赖脚本输出。我习惯手动查几样东西：sudo -l看能免密执行什么，find / -perm -4000 -type f 2>/dev/null找SUID文件，crontab -l和ls -la /etc/cron*看定时任务。有一次在Ubuntu 18.04上发现一个自定义的SUID程序，反编译一看，里面调用了system("ps aux")——没有用绝对路径。直接改PATH环境变量，把ps替换成自己的脚本，root权限到手。

内网横向移动这块，Kali的proxychains配合MSF的autoroute或者socks代理很好用。但别一上来就扫整个C段，动静太大。先看arp缓存、netstat连接、hosts文件，找出最近通信的几台机器。我通常用arp -a和netstat -antp快速定位目标。有一次通过一个运维人员的SSH known_hosts文件，直接锁定了三台核心数据库服务器的IP。

最后说一句实在的。Kali只是把工具打包好了，省去你到处找依赖的麻烦。真正决定渗透成败的，是你对操作系统、网络协议、Web应用的理解深度。工具会过时，漏洞会修补，但底层原理不会变。别把时间全花在背MSF命令上，多看看RFC文档，多搭几个靶机环境自己折腾。那台Redis服务器最后怎么拿下的？我换了个思路，没写SSH公钥，直接往/var/spool/cron/root里写了个反弹shell的定时任务。SELinux没拦cron，因为那个目录的上下文类型是system_cron_spool_t，默认允许写入。