获课：xingkeit.top/7516/

一、Kali是什么？一个程序员的误解

没接触安全之前，我对Kali的印象来自影视剧：黑客戴着兜帽，敲几下键盘，屏幕上闪过一堆花花绿绿的字符，然后“入侵成功”。Kali就是他们手里的“神器”。

后来我才知道，Kali只是一个操作系统，里面集成了几百个安全工具。它本身不黑，就像菜刀本身不杀人。用它干什么，取决于用的人。

真正让我意外的是：学Kali的过程，不是在学“怎么攻击”，而是在学“系统到底是怎么工作的”。

第一个工具：Nmap

Nmap是端口扫描工具。第一次用的时候，我对着自己的服务器跑了一遍，结果让我后背发凉——开着的端口比我想象的多得多。有个Redis端口，我以为是内网才能访问，结果发现它绑在0.0.0.0上，公网也能连。有个MySQL端口，用的是弱密码，爆破一下就能进。

这些端口，平时我根本不会注意。我以为“只要业务能用就行”，但攻击者看的正是这些“能用就行”的地方。

第二个工具：Metasploit

这是个渗透框架，里面集成了几千个已知漏洞的利用模块。学它不是为了去攻击谁，而是为了验证：我的系统里有没有这些漏洞？如果有，攻击者会怎么利用？

跑一遍Metasploit，比自己翻漏洞公告管用得多。因为它告诉你的是“真刀真枪”的结果——这个漏洞能不能打通，打通之后能拿到什么权限。

第三个工具：Wireshark

抓包工具，用来分析网络流量。学它之后，我养成了一个习惯：没事就抓抓包看看。不看不知道，一看吓一跳。有个内部系统，登录接口竟然用的是HTTP，用户名密码明文传输。有个第三方服务，在请求里带着我的API Key，直接暴露在公网上。

这些东西，写代码的时候永远不会注意到。但攻击者注意得到。

二、学安全，让我重新认识自己的代码

以前写完代码，我只关心两件事：能不能跑通？性能好不好？

学安全之后，我开始问自己更多问题。

第一问：这个接口有没有做权限校验？

很多程序员写接口，默认“前端隐藏了就行”。但攻击者根本不看前端，他们直接发HTTP请求。你觉得“隐藏”的按钮，在他们眼里就是一个公开的接口。

我开始检查自己写的每一个接口：真的只有登录用户才能调吗？真的只有管理员才能用吗？参数里传个别人的ID，能不能看到别人的数据？

不看不知道，一看真的发现问题。有个接口，本来只给当前用户用，但我只校验了“是否登录”，没校验“操作的是不是自己的数据”。这意味着，一个用户登录后，可以改任何人的资料。

这个bug，代码里躺了半年。没出事，纯粹是运气好。

第二问：用户输入真的可信吗？

SQL注入是老生常谈了，但现实中依然大量存在。为什么？因为程序员总觉得自己写的代码没问题，“我拼接的字符串肯定安全”。

但攻击者比你想象的聪明。你过滤了单引号，他们用编码绕过；你用了参数化查询，他们找其他注入点。唯一的安全做法，是“永远不相信用户输入”。

我开始用Kali里的sqlmap工具扫描自己的系统。第一次跑，扫出三个注入点。虽然都是内部系统，但也足够让我冒冷汗。

第三问：错误信息暴露了什么？

程序员写代码，喜欢把错误信息写得越详细越好，方便调试。但生产环境如果也这样，就是在给攻击者送情报。

“MySQL error: duplicate entry 'admin' for key 'username'”——这句话暴露了表名、字段名、还有用户名“admin”。攻击者看到这个，就知道用户名是admin，接下来可以尝试爆破密码。

我开始检查所有错误处理，确保生产环境只返回“系统错误”，绝不透露任何内部信息。

第四问：默认配置改了吗？

Redis默认没有密码，MongoDB默认开放端口，Tomcat默认有管理后台——这些“默认”，是攻击者最喜欢的入口。

我以前从来不改，觉得“内网安全”。但学安全之后才知道，内网并不安全。一个员工点个钓鱼邮件，内网就可能被突破；一个服务被拿下，整个内网都可能被横向渗透。

现在我养成了习惯：装任何服务，第一件事就是改默认配置。

三、懂攻击，才懂防守

很多人不理解：我是程序员，又不是黑客，为什么要学攻击？

我的回答是：不懂攻击，就不知道怎么防守。

想象一下，你要保护一栋房子。如果你不知道小偷会怎么撬锁、怎么翻窗、怎么爬墙，你怎么知道该加固哪里？你可能把门锁换得再结实，但小偷根本不走门，直接翻窗户进去了。

网络安全也是一样的道理。

攻击者的视角，让你看到盲区

我们写代码的时候，视角是“用户怎么用”。攻击者的视角是“系统哪里能进”。这两个视角完全不同。

用户看登录页面，看到的是输入框和按钮；攻击者看登录页面，看到的是后端接口、参数传递、验证逻辑、会话管理。

用户看文件上传，看到的是“选择文件-上传成功”；攻击者看文件上传，看到的是“文件存哪了？文件名怎么生成的？能不能上传脚本？能不能绕过类型检查？”

只有切换到攻击者的视角，你才能看到这些“代码之外”的风险。

渗透测试，是检验安全的唯一标准

代码写得再安全，也是理论上的。真正检验安全的，是“跑一遍攻击”。

Kali里集成了大量渗透测试工具，可以模拟攻击者的行为。用它跑一遍你的系统，就像请一个黑客来“考试”。考过了，心里有底；考不过，正好补上。

我第一次用这些工具测自己的项目，测出一堆问题。虽然有点丢脸，但总比被人真的攻击了再发现好。

应急响应，需要逆向思维

万一被攻击了，怎么办？重启？重装？格式化？

这些都没用。攻击者可能留了后门，你一重启，后门还在；你重装系统，他可能已经渗透到别的机器。

真正的应急响应，需要逆向思维——分析样本，找到入侵路径，定位漏洞根源，彻底清除后门。

这些能力，和渗透测试用的是一套技术。懂Kali的人，在应急的时候能“接得住”；不懂的人，只能“重启试试”。

四、安全思维，是程序员的护城河

有人说，安全是安全团队的事，程序员只要写好代码就行。

我不这么认为。理由有三。

第一，安全团队不可能覆盖所有代码。

安全团队再强，也是有限的。他们可以做扫描、做渗透、做审计，但最了解代码的人，永远是写代码的人。如果程序员自己没有安全意识，指望安全团队发现所有问题，不现实。

第二，安全左移是行业趋势。

“安全左移”的意思是，把安全工作往开发阶段推。不是在系统上线前才做安全测试，而是在写代码的时候就把安全考虑进去。这样成本最低，效果最好。

要做到安全左移，程序员必须懂安全。

第三，安全能力是职业护城河。

懂安全的程序员，比不懂安全的，稀缺得多。市场上写CRUD的人一大把，但能写出安全代码、能自己渗透测试、能应急响应的人，很少。

稀缺，就意味着价值。

我见过两个技术水平差不多的程序员，一个懂安全，一个不懂。懂安全的那位，在团队里负责核心模块，参与架构设计，话语权明显更高。为什么？因为领导放心——他写的代码，出事的概率小。

五、Kali安全，怎么学？

如果你被我说动了，想学Kali安全，从哪开始？

第一步：装个Kali虚拟机

Kali官网有虚拟机镜像，下载导入就能用。别装物理机，虚拟机方便折腾，出了问题随时回滚。

第二步：熟悉Linux基础

Kali是基于Linux的，如果你不熟悉Linux命令行，先补补课。cd、ls、grep、ps、netstat这些基本命令要会用，不然寸步难行。

第三步：从信息收集开始

信息收集是渗透测试的第一步，也是最安全的一步。用Nmap扫描目标，用dirb枚举目录，用theHarvester搜集邮箱。这些操作不涉及攻击，风险小，适合入门。

第四步：学一个漏洞利用框架

Metasploit是最主流的，资源多，社区活跃。搭个靶机（比如Metasploitable2），用它练习漏洞利用。不要碰未经授权的目标，这是底线。

第五步：理解漏洞原理

光会用工具不够，要理解漏洞背后的原理。SQL注入为什么能成功？XSS怎么绕过过滤？缓冲区溢出怎么利用？这些原理懂了，你才能举一反三，才能写出安全的代码。

第六步：做CTF，打靶场

网上有很多CTF平台和靶场（比如HackTheBox、VulnHub），里面有各种难度等级的挑战。从简单的开始，每破解一个，能力就长一分。

六、结语：安全，是程序员的底气

那天晚上处理完攻击事件，我在工位上坐了很久。

我想：如果我没发现那个异常连接，会怎么样？可能周末过完，周一上班才发现系统瘫痪。可能客户数据被拖走，公司要赔到破产。可能我的职业生涯，就因为一个“忘了关的接口”蒙上污点。

万幸，我发现了。万幸，我懂一点安全，知道怎么排查、怎么处置。

从那以后，我养成了几个习惯：

• 每个接口上线前，自己用工具测一遍

• 每个服务部署完，检查默认配置改了没有

• 每周看看日志，有没有异常请求

• 没事抓抓包，看看敏感信息有没有泄露

这些习惯，不复杂，不费时，但它们让我安心。我知道，就算有漏洞，我也能早点发现；就算被攻击，我也知道怎么应对。

Kali安全，让我从一个“被动挨打”的程序员，变成了一个“心里有底”的程序员。

在这个漏洞频出、攻击不断、勒索软件横行的时代，心里有底，就是最大的底气。