一、序言
从2024年开始，护网行动的风在已经成为日常，凡是事业单位、政府使用的系统，基本都会受到监测。在部分省份，甚至是不同市交叉监测，一份份检测报告看得心里发慌。
口令类问题作为系统最基础，最常见的漏洞，我将从系统弱口令、规则口令、组件弱口令及短信验证码爆破相关问题。
本文会介绍我碰到过的口令类问题，受限于见识和主观看法，仅供参考。
二、系统弱口令
我相信只要经过漏洞扫描的系统，80%肯定都有弱口令这个问题。简单来说，就是密码过于简单或者规则过于简单。
简单密码主要包含常见的：123456、admin123、admin123456、super123、sa123456等等，有些是开源框架默认密码，上线后没修改。有些是客户觉得密码复杂不想记，希望简单点，到最后都是开发中自己背锅。
解决办法：①增加密码复杂度；②更换登录方式（比如短信验证码）；③增加校验（比如限制登录IP等）。
2.1 增加密码复杂度
对于绝大部分人而言，第一想法就是更新复杂密码。但是，一定要知道什么叫复杂？不是说从123456改成admin@123就可以。按照常见的规则，主要包含以下条件：
- 密码长度不低于8位；
- 密码需要包含大写字母、小写字母、数字、特殊字符；
- 不能有三位及以上的连续数字或字母。
尤其是第三点，像
Abc@123这种密码，是不安全的。
2.2 代码强制校验
这里要注意一个问题，当漏扫给你发漏洞文件时，弱口令不一定只有文件上面那些账号。当你修改密码后，一般都有个复测的环节，如果再检测出其他弱口令，就很尴尬了。
增加密码复杂度肯定是有效果的，但是对于运行多年的老系统，用户比较多怎么办？尤其是客户能自己添加用户那种，我们根本不知道那个账号密码简单。这时候有个不是办法的办法应急，就是再登录接口内，对用户输入的密码进行校验，校验规则参考上面。
2.3 强制修改强密码
上面那招有个问题，就是密码简单的用户没办法登录了，如果碰到脾气急的用户，肯定喷你。
那就换个贯彻到底的方法，强制把所有账号的密码全部换掉，然后通知客户再自己修改密码，但是密码复杂度一定要有检验。
三、规则化密码
规则密码主要是密码具有规则性，很容易被推测出来。这种问题很好解决，主要是惯性思维会让开发者很难意识到自己的问题。主要包含下面三种方式，请大家注意：
3.1 用户相关类密码
这个问题常见于新开发系统，然而有很多用户，开发者为了方便，往往会在密码上加上用户的名字。比如张三的账号是zhangsan，密码是zs123456，这种一旦知道其中一个账号的密码，别的就很快会被推测出来。
这里注意一个问题，有些检测机构会问你要一个账号，这个账号你千万要注意，千万别是那种规则类的，很快会被他们推测出来。
3.2 系统类密码
这个问题常见于有域名的系统，有些人习惯性把管理员密码设置成域名+123456，比如域名是：pan.baidu.com，密码是pan@123456、Pan@123456，这种密码也很容易被猜出来。
3.3 相同密码
多个账号共用一个密码，这个问题常见于有初始化密码，但是未做修改。监测机构会根据你提供的账号。
解决办法：注意少用惯性思维来设置密码。
还有一个就是不同系统不要设置相同的密码，因为护网行动不只会攻击指定系统，会直接攻击提供域名或IP下的所有系统，一旦通过账号密码访问到其他系统，这是极其严重的漏洞。
四、组件弱口令
相对于开发系统的弱口令，组件弱口令很容易被忽略，比如最常见的nacos、MySQL、Redis或者微服务组件及各种MQ的控制台。常见问题有以下两种：
4.1 常见密码或不设密码
举两个常见的例子：一、Redis默认安装没有密码，但是开放使用；二、nacos未修改默认密码，但是开放使用。这个看起来好像很不可思议，因为一般都不会开放，常常都是开发者部署系统调试后，图方便没有对这些做限制。
这里的开放使用，不仅仅是开放到公网，当给一些特殊单位开放系统时，即便是其他内网IP能访问到这些组件，同样会被认定为弱口令。
4.2 相同密码
很多人会习惯性把数据库等组件的密码设置成一个密码，甚至是系统admin的密码。
解决方案：①密码要够复杂（但是自己要记住，别难住了自己）；②后台或控制台访问一定要限制访问IP，不要开放式裸奔。
五、短信爆破
针对系统弱口令，加强密码难度经常有漏网之鱼。于是我们会下意识地选择短信验证码或者邮箱来进行登录，邮箱一般外网地网站用的多，国内还是短信验证码居多。
常规系统地设计一般都是：①前端点击按钮发送验证码（一分钟倒计时）；②后台判断手机号码是否在系统内，不存在报错，存在则判断上一条验证码是否过期；③上一条验证码过期，新发一条，未过期前端提示。
看起来设计很好，限制住了用户多发验证码。然而，这中间有个十分严重地问题：由于发送验证是开放式接口，漏洞检测方可以通过工具不停的请求验证码发送接口，一旦接口返回成功，说明手机号码在系统中存在。
然后，他们把有效地手机号码收集起来，不停请求验证码接口，不仅能消耗我们的短信条数（到这里就算是短信爆破了）。还能在短信验证码有效期内，不停模拟测试验证码，一旦测试成功，那就算系统爆破了。
分享三个我的解决办法（并行，不是三选一）：
- 后端防重复（或者幂等性）请求；
- 限制单手机号
单小时、单天请求和发送次数； - 限制IP
单小时、单天请求次数。
如果在请求短信验证码前，再加一关数字或图像验证码，也是极好的。
第一条接口防重最简单也最实用，这种主要是应对检测方的接口爆破，限制对方并发测试。
第二条限制手机号码的发送次数，这个也很重要，别让短信被浪费，也能降低验证码被爆破的风险。
友情提醒：运营商（比如阿里云）可以设置发送限制，可以作为最后的底线，别一天就破产了。
第三条限制IP请求这个，我个人觉得才是最管用的，当对方测试手机号码时就把对方IP拉黑。虽然检测方一般有招数更换IP，但是这招算是我硬编码能想到效果最好的方式了。
六、总结
以上总总，都是一家之言，总结起来，大概有三招应对方法：
6.1 加强密码强度
不要设置过于简单、规则化、重复性的密码，如非必要，一定开启验证码。
6.2 有限制性的访问
在条件允许的情况下，可以通过限制IP等方法限制对方访问。
通过硬编码限制是下下之策，是没办法的办法，可以通过防火墙限制。如果你是小公司，开发运维一把梭，建议你使用宝塔之类的工具，简单直观。
6.3 限制IP爆破式请求
这个针对系统开放式接口要限制对方请求次数，别被爆破。
系统里要设计个可以清除限制的功能，别对方测试后整个系统IP全部被限制不能访问。