本文目录导读：
别让FRP成为逃逸帮凶！容器安全实战复盘与反思
哎,兄弟们，今天咱们不聊虚的，就唠唠我上周在实战中遇到的一个“惊魂”时刻——FRP配合容器逃逸，差点把整个内网给捅穿了，说真的，事后我后背全是冷汗，这东西要是被恶意攻击者利用，那后果简直不敢想。
起因：一个不起眼的Web漏洞
事情是这样的,我们有个业务系统部署在Docker容器里，平时运维图省事，直接映射了宿主机端口，我习惯性地用扫描器扫了一圈，嘿，发现一个老旧的FastJSON接口，当时我心里就咯噔一下——这年头，FastJSON的洞简直就是“筛子”，不出意外的话，很快就能拿下一个webshell。
果不其然,经过一通操作（细节就不展开了，怕带坏新人），我成功在容器里执行了命令，当时我还挺得意，毕竟权限到手了嘛，但紧接着，我下意识地执行了cat /proc/1/cgroup，一看下面有docker字样，瞬间就清醒了——我TM现在在“笼子”里，距离真正的“自由”还差十万八千里呢。
转折：FRP——我的“越狱”神器
这时候,我想起了老朋友FRP（Fast Reverse Proxy），这玩意儿本身是个内网穿透工具，但在地下圈子里，它可有个响当当的外号——“越狱神器”，为啥？因为当你需要把容器里的流量带出去，或者反向连接宿主机时，FRP简直太好用了。
我二话没说,先在攻击机上下载了frps（服务端），在自己VPS上跑起来，然后在容器里上传frpc（客户端），配置好端口转发，你猜怎么着？几分钟后，我就通过FRP隧道，把容器的流量成功映射到了我的VPS上，那种感觉，就像在监狱里挖了一条地道，外面阳光灿烂啊！
但重点来了——光有隧道还不够，我得想办法逃逸出去，这时，我检查了容器是否开启了--privileged特权模式，结果，运气爆棚，管理员居然没有禁用！这意味着我可以直接挂载宿主机目录，甚至尝试cgroup逃逸。
我迅速利用nsenter或者直接读写宿主机/etc/crontab替换系统命令，配合FRP的隧道，我直接反弹了个宿主机Shell回来，那一刻，我耳机里仿佛响起了《Victory》的BGM，整个人都激动得发抖了！
反思：别让工具替你背黑锅
不过兄弟们,激动归激动，咱们得冷静下来想想，FRP本身是个好工具，但为什么它总能成为容器逃逸的“帮凶”？说白了，是安全配置失效 + 运维人员偷懒惹的祸。
你看,如果当初运维启用了--cap-drop=ALL，禁用特权模式，或者安装了seccomp过滤器，我还敢这么嚣张吗？不敢的！可惜啊，现实中很多公司都是“裸奔”上K8s，把容器当成虚拟机用，这不就给了我们可乘之机嘛。
这里我得插一句给新手的话：FRP隧道建立后，千万不要以为万事大吉了，我记得有次，我通过隧道传数据，流量没加密，结果被防守方的IDS抓了个正着，差点被反打了。一定要用TLS加密，或者配合socat做二次转发，否则你的行为和拿着大喇叭喊“快来抓我”没什么区别。
沉淀：几条保命防御建议
经历这事,我连夜写了个检查脚本发到安全群里，这里也分享给大家：
- 别用特权模式：打死都不要在容器里加
--privileged，除非你想体验“全家桶”服务。 - 严格限制capabilities：删掉
NET_ADMIN、SYS_ADMIN，这些是逃逸的“直通车”。 - 网络策略要加白名单：容器出网流量必须走代理审计，FRP这种未知流量直接掐断，你想想，健康业务需要半夜连外部VPS吗？
- 文件系统只读：挂载
/proc、/sys时用ro参数，防止内核模块加载。
哎，说多了都是泪，写这篇文章不是教大家怎么搞破坏，而是想告诉所有网安同行：FRP只是一个放大器，真正危险的是你内心的侥幸和懒惰，每次看到扫描器扫出漏洞，我都后背发凉，因为我知道，下一个可能就是一个更大规模的内网渗透。
如果你也对容器逃逸、内网渗透这些技术感兴趣，或者想一起聊聊防御对抗的心得，欢迎加我QQ一起交流学习（都是网安圈子的人，懂的都懂）。技术本身没有对错，但使用技术的人要有底线，下次再填安全报告时，希望你能多问自己一句：如果这是我自己的服务器，我会这么做吗？
好了,今天就叨叨这么多，我要去喝口水平复下心情了，你们那边有什么奇葩逃逸案例，别忘了评论区分享出来，咱们互相避避雷！
