Linux弱口令检测实战：John the Ripper工具详解与安全加固指南-北京尧图网络

1. 弱口令检测这件事到底在防什么先聊点实际的。很多搞运维和系统管理的老哥一听到“弱口令检测”就下意识觉得这是安全团队的事跟自己没关系。但我在一线摸爬滚打这么久可以很负责任地讲弱口令问题是所有Linux服务器安全事件里最容易被忽视、又最容易出事的入口。你看那些安全通报十起里有七八起是“爆破成功”或者“弱口令被猜解”。本质上不是攻击者水平多高而是服务器上的密码本身就扛不住一次稍微像样的字典攻击。John the Ripper通常直接叫John就是干这个用的——它不是一个“黑客工具”它在正规运维和安全审计里的角色是一个密码强度体检仪。它能做什么简单说把系统里用户的密码哈希捞出来然后通过字典、规则变形、暴力组合等方式尝试把这些哈希还原成明文密码。一旦还原出来了就说明这个用户的密码不安全需要立刻改掉。这件事适合谁来干三类人运维工程师定期给服务器做密码自检尤其是有大批服务器、多用户账号的环境。安全审计人员做渗透测试、基线检查、合规审计时弱口令检测是必查项。系统架构师在设计账号体系和初始化策略时需要知道什么样的密码策略经得起John的考验。这篇文章会把John从原理到实操完整过一遍包括我在真实环境中踩过的坑、总结的技巧以及怎么把检测结果转化成可落地的整改方案。你照着走一遍就能把自己的服务器密码底牌摸清楚。2. 技术背景与工具选型思路2.1 为什么是John而不是别的工具Linux下的密码爆破工具不少比如hashcat、hydra、medusa等但它们在定位上有明显差异工具定位适用场景特点John the Ripper离线密码哈希破解拿到/etc/shadow或哈希文件后在本地分析支持哈希类型极多规则引擎强大hashcat离线哈希破解GPU加速环境速度极快但需要显卡支持配置稍复杂hydra在线爆破远程登录服务的密码猜测会产生日志容易被发现不适合审计自检对于Linux系统的弱口令自检和审计来说John是首选。原因有几个第一它支持从系统里直接读/etc/shadow的哈希格式兼容性好第二它的字表变形规则mangler rules非常成熟可以用很小的字典模拟出很大的密码空间第三它对CPU环境友好不需要显卡就能跑起来。有人会问hashcat不是更快吗是如果有一块好显卡hashcat跑NTLM或者MD5这类哈希确实快得离谱但它有个问题配置门槛高而且很多服务器尤其是内网机根本没有GPU总不能为了做个密码检测专门搬一台GPU机器过来。John单机CPU跑在某些场景下确实不够快但配合增量模式也能释放CPU的全部性能。另外John的规则语法比hashcat直观得多适合我们这种经常需要人为调整检测策略的场景。2.2 John的工作原理大白话讲明白密码破解这件事理论上很简单猜一个密码把它加密成哈希和已知的目标哈希比对一样就中了。但核心的门道在于哈希算法的特点。Linux的/etc/shadow文件里存的是带盐salt的密码哈希格式一般是$type$salt$hash其中type是哈希算法编号$1$是MD5$2a$/$2b$/$2y$是Blowfishbcrypt$5$是SHA-256$6$是SHA-512$y$是yescrypt新版CentOS/RHEL 9默认。什么是盐salt你可以把它理解成每个用户独立的“调味料”。同一个密码不同用户因为盐不同最终生成的哈希是完全不同的。所以John在破解时不能直接拿一个预计算好的彩虹表去查而是必须针对每个用户的哈希带着它的盐去逐一计算和比较。这就是为什么John在破解时要先加载影子文件而不是只给一个哈希值。John的整个工作流程是读取密码哈希从/etc/shadow或自定义文件。根据哈希的前缀判断算法类型选择合适的破解格式。从字典文件里取一个候选密码或者按规则生成一个候选密码。用目标哈希的盐对候选密码做哈希运算得到结果。和目标哈希做比对匹配就输出不匹配就继续。这就是一个典型的“穷举优化”的过程。优化的方向无非两个减少尝试次数通过合理的字典和规则优先试最可能的密码和提升单次计算速度通过多线程、优化算法实现。很多人一开始不理解为什么John跑字典比跑纯暴力快那么多。打个比方假如你要在一万个陌生人里找一个目标纯暴力模式相当于把全市户口本都翻一遍而字典模式是先从“最可能是你要找的人”的那一摞照片里翻。密码也一样绝大多数人的密码都脱不开常见词汇、生日、姓名拼音这些组合字典模式就是精准狙击。2.3 John的四种工作模式得心里有数John的破解模式主要有四种每种有它的适用场景我用实际经验说明一下。Single Crack单模式这是John默认的第一阶段用登录名、全名、家庭目录等个人信息作为基础进行简单变形。比如用户名叫zhangsan它会尝试“zhangsan”、“Zhangsan”、“zhangsan123”、“zhangsan”这类组合。别小看这个模式很多人密码就是用户名加个后缀。Wordlist字典模式指定一个字典文件按顺序拿字典里的词来做密码尝试。配合规则rules使用威力会大很多。比如字典里有“password”规则会生成“Password”、“Pssw0rd”、“password123”等变体。我最常用的就是--rulesAll覆盖面和命中率比较均衡。Incremental增量模式就是暴力破解的优化版按字符集和长度限制来遍历组合。在John的配置文件john.conf里有预置的字符集定义也有各种长度限制。这个模式适合在字典没命中时兜底但耗时和计算量非常大。External外部模式用C语言子程序写自定义的候选密码生成逻辑极度灵活但配置门槛高我极少在生产环境用它。说实话日常弱口令检测用到前三种就足够了。另外补充一下John还有“掩码模式”类似hashcat的mask attack可以用类似?d?d?d?d的方式指定某一位是数字。比如你怀疑某用户的密码是8位数字就可以直接指定?d?d?d?d?d?d?d?d来跑这比增量模式更精准速度也更快。3. 环境准备与John安装3.1 获取/安装John的几种方式别选错John the Ripper有两个主要版本John the Ripper Jumbo和John the Ripper core。Core版是官方基础版代码简洁但支持的哈希类型少规则也简单说实话日常不太够用。Jumbo版是社区增强版支持几百种哈希类型规则丰富还内置了大量实用工具。我们实际用得最多的就是Jumbo版。安装时优先用发行版自带的包管理省事且稳定。Debian/Ubuntu系apt update apt install johnRHEL/CentOS系yum install john或者用EPEL源yum install epel-release yum install john但这里有个坑系统自带源的John版本通常偏老而且未必是Jumbo版。如果你要跑的哈希类型比较特殊比如某些设备固件的哈希建议直接编译Jumbo版。编译安装也不复杂git clone https://github.com/openwall/john.git cd john/src ./configure make编译好的二进制在run/john目录下。我自己的习惯是把它软链到/usr/local/bin/下方便全局调用ln -s /path/to/john/run/john /usr/local/bin/john3.2 验证安装与基础配置装完之后先验证一下版本john --version看到类似John the Ripper 1.9.0-jumbo-1的输出就说明是Jumbo版版本号越新越好新版本对bcrypt和yescrypt的支持和速度优化都会更好。john.conf配置文件在Jumbo版的run目录下文件名通常叫john.conf或john-local.conf。核心的规则、字符集定义、模式参数都在这个文件里。有一些选项按需修改# 默认字典路径 Wordlist $JOHN/password.lst # 增量模式字符集 [Incremental:All] CharSet a如果不是特殊需求先不用动配置直接用默认参数跑就行。4. 核心实操环节一次完整的弱口令检测流程4.1 第一步获取密码哈希注意权限和合法性John不能直接读取系统里加密的shadow文件吗它当然可以但前提是你要有足够的权限。实际操作中分两种情况场景一你自己就是root或者有sudo权限直接执行unshadow /etc/passwd /etc/shadow mypasswd.txtunshadow是John自带的一个小工具作用是把/etc/passwd和/etc/shadow合成一个John可以直接处理的文件。这个文件里保留了用户名的对应关系等破解出密码后你能知道哪个用户名对应哪个密码。这个对应关系很重要不然光给一堆明文密码你都不知道要通知谁改密码。注意只跑shadow文件也行但那就丢了用户名映射关系在用户多的时候会特别痛苦。强烈建议走unshadow这一步。场景二拿到的是一份独立的哈希文件比如从某些系统导出、从设备里抓出来的哈希格式可能是user:hash或者干脆只有哈希。这种情况直接喂给John就行它会自动识别哈希类型john --formatraw-md5 hash.txt如果John识别不出类型先用john --listformats | grep查一下支持的格式列表或者用hashid这个工具来识别。这里必须多说一句弱口令检测这件事一定要在授权范围内操作。自己运维的服务器、有书面授权的渗透测试项目这是合规的。如果你是拿别人的服务器练手那就不是检测是攻击了性质完全不同。我见过有些乙方测试人员因为没拿到书面授权就开跑最后惹了一身麻烦。技术本身是中性的但用法必须有边界。4.2 第二步先跑默认模式快速摸底拿到mypasswd.txt后第一件事是跑默认批次john mypasswd.txt默认模式下John会依次执行单模式、字表模式内置的password.lst、带规则的字表模式。这个过程会根据哈希类型自动选择格式不需要手动干预。我第一次在公司内网跑的时候服务器是CentOS 8用户一百多个默认模式跑了大概五分钟就给出了十几个弱口令。里面的密码五花八门有用户名的直接变体有“Admin123”这种很经典的弱密码还有干脆就是“123456”的。跑完看结果john --show mypasswd.txt输出会列出所有破解出来的用户名和明文密码。如果有些用户还没破解出来--show只会显示已破解的部分。想一次性看到全部状态可以加--showleft查看剩余没破解的用户。4.3 第三步上自定义字典和规则提升命中率内置字典和默认规则是通用的说明白点就是“最大公约数”不一定适合你的实际环境。要想检测得更深入需要针对性地扩充字典和调整规则。关于字典的选择我的经验是首推你所在行业、公司名、产品名的变体组合比如公司缩写加年份加特殊字符。把最近三年的常见弱密码TOP100、TOP500网上公开的那些正规字典库里有都收进来。把用户名本身和它的拼音/英文名作为基础词放入字典。加上键盘模式密码比如“qwerty”、“1qaz2wsx”这种。字典文件是纯文本一行一个词。我可以分享一个简单的生成思路用脚本把基础词和常用后缀组合起来for word in $(cat base_words.txt); do for suffix in 123 1234 2019 2020 2021 2022 2023 ! abc; do echo ${word}${suffix} done done custom_dict.txt这只是个粗糙示例实际可以根据自己环境的命名习惯做得更精细。关于规则的调整John本身内置的规则已经很强了。我最常用的两个规则是--rulesAll使用全部规则进行变形覆盖面广适合常规检测。--rulesJumbo更强的变形规则集尝试各种大小写、替换、前后缀、复写等准确性高。举个例子字典里有“admin”在:All规则下会生成“admin1”、“admin2”、“Admin”、“ADMIN”、“admin”等变体。这样一来一个100万条的基础字典实际能产生几千万种尝试覆盖面相当可观。顺便提一嘴如果真想深入挖不要只用单词“admin”这种还要结合目标系统的用户习惯。比如某公司路由器上统一用“Ruijie2020”如果你在字典里放“Ruijie”以及年份组合命中率会直线上升。4.4 第四步多线程加速合理利用CPUJohn默认是单线程跑但现代服务器CPU核心数都不少不利用起来有点浪费。通过--fork参数指定进程数比如8核CPU可以这样john --fork8 mypasswd.txt它会把任务分给8个进程并行处理效率提升明显。还有一个参数--pot指定进度保存文件这样即使中断了也能接着跑不用从头再来。默认的pot文件在~/.john/john.pot每次跑完的结果都会记在里面。所以哪怕你换了个人跑它也不会重复尝试已经破解出来的密码。在跑增量模式之前先检查一下当前CPU负载别在生产环境的业务高峰期跑这个否则CPU满载会影响线上业务。我一般都安排在凌晨或者维护窗口操作。4.5 第五步增量模式和掩码模式兜底如果字典加规则跑完一轮还有密码没解出来那就要判断这些哈希值不值得继续花时间。日常自检的话说实话跑到这一步已经足够了。一个用户的密码如果字典和规则都破不出来至少能说明它不是常见的弱口令说明该用户密码的基础安全性是过关的。但如果你在做渗透测试或者想确保万无一失可以试试增量模式john --incrementalLower mypasswd.txtLower是内置字符集配置表示纯小写字母最大长度默认5位。如果有更精确的猜测比如觉得某用户密码是6位纯数字可以用掩码模式john --mask?d?d?d?d?d?d mypasswd.txt注意掩码模式在Jumbo版以上才支持老版本会报错。这里有一个很多人容易忽略的点增量模式虽然叫“增量”但它不是把所有组合都跑一遍。它会先按字符集和长度限制生成组合再用内部优化调整顺序优先试最常见的组合。但仍然架不住组合空间巨大比如纯小写6位就有26的6次方也就是3亿多个组合纯靠CPU硬跑那是真的酸爽。所以增量模式的定位是“定向打击”不是无脑乱跑。4.6 第三步实操案例某公司Linux服务器弱口令体检实录我拿一次真实的项目经历来演示整个流程这样更有画面感。某公司有几十台Linux服务器做业务系统承载想要做一次密码安全自检。操作流程如下准备环境选择一台配置较好的管理机8核16G内存编译安装John Jumbo版。收集数据通过sudo在每台服务器上执行unshadow把生成的哈希文件汇总到管理机。第一波扫描直接跑默认模式。执行命令后John自动进入单模式和字典模式。大约15分钟30%左右的哈希被解出。深入分析查看已破解密码的规律发现不少用户的密码是“公司名拼音年份”。于是我把公司名拼音、缩写、成立年份、常见后缀等加入自定义字典再配合--rulesAll重新跑。第二轮检测这次命中率又提升了一大截又解出约20%的哈希。定向掩码剩余还没解出的我选择了一些重点账号比如root、admin、运维账号用掩码模式跑了几个简单组合来兜底最终整体破解率达到了60%以上。注意这里不是说没破解出来的就是安全的只是说明它们的密码强度已经不在弱口令的范畴里了。对于本次检测涉及的几十台服务器60%的弱密码比例已经非常夸张了说明这个公司的密码管理策略基本是形同虚设的。我把完整的过程整理成了一个表格方便理解阶段操作耗时结果初始收集unshadow汇总所有服务器哈希10分钟哈希文件约500条用户记录默认扫描john默认模式单模式字典15分钟破解约150条命中率30%定制字典加入公司名、年份、弱密码TOP50020分钟新增破解约100条总命中率50%规则强化--rulesAll 自定义字典30分钟新增约50条总命中率60%定向掩码重点账号6位数字/小写掩码1小时多发几条总命中率约62%这样一个完整的流程下来事情就非常清晰了哪些用户、哪些服务器存在弱密码一清二楚整改也有的放矢。5. 常见问题与排查技巧实录5.1 问题一明明盯着shadow文件为什么John解不出来我在很多交流群里看到有人问“我拿到root权限了shadow文件也在这个机器上但John跑了俩小时一个都没出是不是工具坏了”这种问题大概率不是工具的问题而是哈希类型没选对或者密码本身强度确实高。尤其是遇到了bcrypt或者yescrypt这类抗GPU破解的算法CPU跑起来速度极慢。比如SHA-512$6$单块速度大概是每秒几千次到几万次。bcrypt$2b$单块速度可能只有每秒几百到几千次取决于cost参数。yescrypt$y$类似bcrypt速度也不快。而如果你拿一个100MB的字典去跑算算就知道需要多少时间了。这种时候不是John不行而是你选错了目标。排查思路如下# 查看John识别到的哈希格式 john --format--listformats | grep sha512 john --format--listformats | grep bcrypt # 先确认格式 john --test --formatsha512crypt如果发现自己机器CPU不支持某些指令集比如较老的CPU跑AVX2优化代码可以用--test先跑一下基准测试看看单位时间能算多少次从而估算出跑完一个字典需要多久避免傻等。5.2 问题二字典太大跑了一天也没跑完这种情况很常见。有人喜欢直接下个几十GB的超大字典然后全量开跑结果是时间成本完全失控。我的建议是分层梯度检测第一层小型基础字典几百KB常用弱密码和默认密码加默认规则可以快速扫一遍。第二层中型字典几MB行业词、姓名拼音、昵称等加自定义规则。第三层只有前两层均未命中时才考虑跑大型字典或增量模式。还有一个隐藏很深的坑——字典里的重复词。有些网上下载的字典是多个来源拼凑的里面重复项特别多。John默认不会去重导致每次都白跑。可以先对字典做一下去重优化sort your_dict.txt | uniq clean_dict.txt wc -l your_dict.txt clean_dict.txt我见过一个“800万密码”的字典去重后只有不到300万条。你说白白浪费了多少时间。5.3 问题三解出来的密码是乱码或者一堆特殊符号看着不放心John正常输出的是目标哈希对应的明文密码但偶尔也会出现一些“看着不太像密码”的结果比如长度特别短的1~2个字符全是特殊符号的看起来像是随机生成的字符串这在增量模式下比较常见。但还有一种情况你用unshadow生成的文件中包含了系统账户的密码而很多系统账户比如daemon、bin、sys的密码哈希其实是一个星号*或!!表示这个账户不可以直接登录。这种情况下John根本不会去破解它们。如果破出来一只不会是我期望的结果说明可能是加密方式比较特殊的账号需要多加留意。实操经验检测时要区分系统用户和真实登录用户。系统用户的密码策略一般不用管重点治理对象是那些有shell、能登录服务器的账号。你可以这样查看哪些用户有登录shellawk -F: $7 ~ /(bash|sh)$/ {print $1} /etc/passwd5.4 问题四跑出来的密码比原密码长是破解出错了吗不是。这涉及到哈希算法的一个特点同一明文密码在特定情况下可能存在多个哈希碰撞。但这概率极低更常见的情况是John按照规则切分、识别哈希时把相邻字段误会成盐或者哈希的一部分导致输出的不是预期明文。如果遇到这种结果建议把用户密码哈希单独提取出来用--format指定确切的格式重新跑通常就能得到正确答案。不过我这里还要提醒一种防误判的手段拿到破解结果后一定要核实密码是否真的能登录。比如你可以通过su切换测试仅限自己有权测试的账号或者用ssh登录验证。有一次我处理一份从网络设备上抓来的哈希John“成功”破解出密码但实际登录发现密码完全不对——后来排查发现是设备哈希格式和John理解的格式存在差异导致哈希识别错误自然破解出来的就是个不存在的“假密码”。此后我做大型哈希分析都会抽样验证绝不盲目相信输出。5.5 问题五猜测root密码是root123但John就是不认原因很简单root密码哈希用的算法可能不是默认格式。现代Linux默认是SHA-512$6$但老系统或许是MD5$1$嵌入式设备可能是DES不带前缀或_开头。John如果没有自动识别就需要手动指定格式john --formatdescrypt mypasswd.txt格式名字列表可以通过john --listformats查看非常全。5.6 问题六想跑快一点用什么参数搭配比较好根据我的经验按以下优先级调整用--fork开启多进程核心数越多收益越大。用--pot保存进度避免中断重来。用--rulesAll而不是默认规则命中率提升明显。如果哈希类型是SHA-512等考虑换用OpenCLGPU支持的版本。但服务器环境往往没有GPU所以CPU多进程还是最通用。更新到最新Jumbo版本新版本的算法优化在速度上通常有10%~30%的提升。有的发行版自带的John比较老对多线程和CPU优化支持不够好建议直接编译最新版这个动作本身也不复杂。6. 检测结果处理与加固建议6.1 怎么把检测结果整理成一份清晰的报告破解完成不代表事情结束更重要的是把结果转成可落地的整改清单。我一般按这个表格整理服务器IP用户名破解出的明文密码风险等级整改建议192.168.10.1rootAdmin123高立即改密启用密钥登录192.168.10.1zhangsanzs123456高改密并强制密码策略192.168.10.2adminqwerty高改密并禁用root远程登录报告的结论部分建议至少包含弱密码账号占比、密码规律分析、影响范围判断、整改优先级建议。我这里有一个重要的经验不要直接在企业群里广播破解出的明文密码哪怕对象是同事。密码明文属于敏感信息不适合大范围传播。我一般只把结果发给管理者或指定对接人由他们一对一通知避免密码在更大范围泄露。6.2 加固的系统性建议别只看密码本身改完密码就完了吗肯定不是。我见过太多团队改完密码后半年又来一遍问题原封不动。密码管理的本质是账号体系全生命周期的安全治理。密码策略要做实不要只写在制度里要在PAM层面强制。在/etc/login.defs中设置PASS_MAX_DAYS、PASS_MIN_DAYS、PASS_WARN_AGE并开启pam_pwquality.so模块强制新密码满足长度和复杂度要求。特权账号优先治理root、管理员组、sudo组账号的密码必须强制高复杂度最好更改为密钥登录密钥本身要设口令保护私钥文件权限设为600。账号分类与周期轮换按需把账号分为“长期运维账号”“业务服务账号”“临时账号”临时账号到期自动禁用。定期比如每90天做一次密码轮换并与弱口令检测联动。最小权限管理不需要sudo的用户一律踢出wheel组。建议用sudoers文件按命令允许最小化授权而不是给个大而全的权限。启用日志审计检查/var/log/secure或/var/log/auth.log里是否有大量的“Failed password”记录结合fail2ban等工具做自动封禁策略。开启PAM口令复杂度RHEL/Debian都支持authconfig --passquality --enforce 或直接编辑/etc/pam.d/system-auth: password requisite pam_pwquality.so retry3 minlen12 dcredit-1 ucredit-1 lcredit-1 ocredit-1简单解读一下minlen12是最小长度12位dcredit/ucredit/lcredit/ocredit分别要求至少包含数字、大写、小写、特殊字符。这一套下来弱密码出现的概率会大幅降低。6.3 长期机制把弱口令检测做成例行任务临时想起来才跑一次John效果有限。我建议把它沉淀为周期机制至少每个季度扫一次。可以写成脚本#!/bin/bash # weekly_password_check.sh DATE$(date %Y%m%d) unshadow /etc/passwd /etc/shadow /tmp/shadow_$DATE.txt john --pot/var/log/john.pot --rulesAll /tmp/shadow_$DATE.txt john --show --pot/var/log/john.pot /tmp/shadow_$DATE.txt /tmp/john_result_$DATE.txt配合cron定时任务和邮件通知就能形成一个闭环定期检测、发现问题、通知整改、复检确认。7. 几条过来人的避坑经验写到这里我把这几年在弱口令检测实践里总结出的几条心得一并列出来算是压箱底的东西。不一定写在任何文档里但确实很关键。哈希文件不要明文到处放。每次unshadow生成的文件都包含密码哈希虽然是哈希不是明文但字典攻击一上很多用户密码就会现出原形。所以这个文件本身必须按敏感资料管理用完最好rm -rf删除不要留在/tmp目录里更不要提交到git仓库。我在网上见过不少因为把shadow文件传到代码仓库导致的大规模泄露事故教训非常惨痛。不要只测/etc/shadow里的密码。Linux系统上的弱口令问题还涉及web端、数据库、中间件等。如果做完一轮John检测就觉得自己安全了那是错觉。数据库账号、应用系统账号、运维平台口令也要纳入检测范围。比如MySQL的用户密码哈希可以用mysql_native_password格式导出再用John跑一遍处理流程类似。检测和整改的时间差不能太长。有时候安全团队扫出一堆弱口令业务部门拖了一个月还没改完这中间就非常危险。弱口令一旦泄露随时可能被趁虚而入。合理的做法是高危账号48小时内改密中危账号一周内改密整改完成后再跑一轮确认。这类流程我已经固化到工作清单里了每次都不打折扣地执行。别把root密码弄丢。如果扫描过程中你顺手修改了root密码一定要确保自己还能登录进来。我见过一个同事自检时改了root密码但是因为键盘布局和字符转义问题密码输入怎么都不对自己把管理后台锁在外面。最后只能去机房重设。所以改密码这类操作边界要非常清晰要么只在测试账号上做示范要么改完立即确认登录正常。合规前提必须前置。技术上想怎么测都行但前提是拥有这台服务器的管理权限或者书面的安全检测授权。在这个前提下你这叫安全审计没有这个前提那就是未授权访问甚至入侵。行业的规矩就是做任何检测项目前必须先把授权确认书签掉。8. 从弱口令检测到整体安全观写完这些我想再多说两句。很多运维同行觉得安全检测是额外负担是“没事找事”。但换个角度想弱口令检测本质上是帮自己排雷。你主动发现并修复一个问题比被攻击者发现然后被利用要划算得多。我做安全这行以来处理过好几次因为弱口令导致服务器被入侵的事件。那些案例的共性很有意思它们都不是被什么高深漏洞攻破的就是密码太弱被字典撞开了。轻则CPU被挖矿程序占满重则数据库被勒索加密。而事后复盘时大家才想起来如果早点做一次John自检完全是可以避免的。这也是我为什么坚持把这些工具和流程写成经验文章的原因。John the Ripper本身只是一个工具但掌握它、正确地使用它等于给自己的系统多了一把可控的锁。工具无善恶关键在用法和边界。保持正当的检测目的用合规的方式去提升系统安全性这些经验就不会白费。最后再送给大家一个小技巧跑完John之后如果发现有账号用了“与公司名称相关的弱密码”可以把这些规则直接写进密码策略的禁用列表里源头规避比事后补救有效得多。

Linux弱口令检测实战：John the Ripper工具详解与安全加固指南

相关推荐

如何从零构建Helium-linux：Docker容器化编译环境完整教程

Ubuntu 20.04 安装 ROS Melodic：跨版本兼容实践与排坑指南

MUC18抗体：一种从黑色素瘤标志物到肥胖治疗靶点的多功能研究工具如何发挥作用？

更多资讯

CSkin实战：WinForm自绘控件换肤与DPI适配避坑指南

编程基础：变量数据类型与类型转换全解析

插件生态深度解析：从plugins、SDK到CLI的架构设计与实战排查

无头显搞定Unity VR开发：模拟输入与交互调试指南

AI工程从零开始：重建可验证的系统决策链

SQLite+FTS5+BM25构建轻量级上下文引擎

今日更新

防关联浏览器哪个好？三款产品实测差异解析

2026钢铁行业AI转型系统选型对比：多基地排产、大宗原燃料采购与质量追溯，六家厂商能力差异在哪里

影刀RPA深度实战：大模型Fine-tuning定制RPA专用Prompt与指令生成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？