kali 渗透linux服务器

用Kali拿下一台Linux服务器，渗透最省事的渗透路径往往不是挖0day，而是渗透SSH口令太弱。上周给一个客户做内网评估，渗透扫描器扫到22端口开着，渗透hydra跑了一个下午的渗透字典，root密码居然是渗透“admin123”。登进去那一刻，渗透我甚至有点替运维同行脸红。渗透

当然，渗透口令爆破只是渗透开胃菜。真正有意思的渗透是那些配置失误留下的后门。比如Redis未授权访问，渗透这个漏洞喊了快十年了，渗透还是渗透能碰到。我在一台CentOS 7上试过，redis-cli连上去直接写authorized_keys，三分钟拿到root shell。服务器上跑着生产环境的Java应用，Redis绑在0.0.0.0，连密码都没设。运维大概觉得内网就安全——可内网横向移动不就是这么来的么。

拿到shell之后第一件事是提权。Linux提权的手法翻来覆去就那些：SUID、sudo配置、内核漏洞、计划任务。我习惯先跑一遍LinEnum.sh，看看有什么现成的。有次碰到一台Ubuntu 16.04，sudo -l显示用户可以无密码执行find命令。这基本等于把root送人。sudo find / -exec /bin/bash \;，完事。内核漏洞反而用得少，脏牛那套现在很多机器都打了补丁，而且打崩了还得赔。

持久化我一般用crontab加个反向shell，或者往.bashrc里塞一行。但说实话，客户环境里我不太爱留后门，评估结束要清理干净。真正做红队的话，systemd服务比cron隐蔽，写个假的“systemd-resolved”服务，重启也不会掉。不过这种操作得小心，搞不好把服务器弄重启了，客户电话马上打过来。

横向移动阶段，Kali上的proxychains配合msf的socks代理是标配。但实际用起来，meterpreter的autoroute更顺手。有次从一台Web服务器跳到数据库服务器，再跳到域控——虽然Linux域控少见，但SSH密钥复用太常见了。运维图省事，同一个id_rsa到处放，一台沦陷等于全沦陷。

清理痕迹这块，Kali自带的工具其实不够用。bash_history要清，/var/log/auth.log要改，wtmp和utmp也得处理。但别过度清理，客户的安全团队不是傻子，日志突然断档比留着入侵记录更可疑。我一般只删自己操作的那几行，用sed精准替换，不动整体时间线。

最后说个真实案例。某次评估，目标是一台暴露在公网的GitLab服务器。CVE-2021-22205，ExifTool的RCE，Kali上msf模块直接打。拿到shell之后发现是Docker容器，逃逸没成功，但容器里挂着宿主机的SSH密钥。密钥没密码，直接ssh到宿主机。宿主机上跑着Kubernetes，kubeconfig就在/root/.kube/config里。整个集群的pod随便进。从外网到集群管理员，前后不到四十分钟。

这事之后我养成了一个习惯：每次拿到Linux shell，先看/etc/hosts、~/.ssh/known_hosts、~/.bash_history。这三样东西经常比漏洞本身更有价值。Kali只是工具，真正决定渗透成败的，是目标环境里那些“图方便”的配置。