fikker弱口令检测实战：CDN节点渗透测试与脚本化验证

简介一套面向渗透测试与安全运维场景的fikker弱口令检测工具包帮助授权测试人员快速批量验证目标服务器是否存在弱口令风险从而定位并及时修复安全漏洞适合安全服务工程师、渗透测试学习者以及企业蓝队使用。压缩包共4个文件以Python检测脚本为核心搭配两个txt文本与一份markdown说明文档分别用于保存待测目标地址、输出检测结果以及提供工具使用说明和免责声明整个包仅2KB结构精简、即下即用。目前已有70人浏览学习。在授权前提下运行脚本并指定host列表文件即可对批量主机开展探测疑似存在弱口令的URL会被标记为绿色并自动写入res.txt便于审计人员快速梳理同时包内文档明确了合法使用边界强调须遵守《中华人民共和国网络安全法》仅限授权安全测试可帮助初学者规范测试流程也可作为企业安全自查与应急排查时的轻量辅助工具。1. 从一台被忽略的CDN节点说起为什么偏要把fikker的控制台口令翻出来前两年的一个授权项目里客户在等保自查时发现某个边缘节点上跑着一套fikker安装完了就再没人管。负责的同事说“这就是个缓存服务不对外开管理端口”。结果我们用nmap扫了一圈发现管理端口和CLI控制口都暴露在内网而登录口令还是最原始的默认口令。那一刻开始的半小时里我们不仅拿到了这台节点的完整控制权还顺带把源站IP和回源路径摸了个底朝天。这件事让我养成了一个习惯只要在目标网络里看到fikker就先跑一遍弱口令检测脚本而不是急着去看缓存命中率。这篇笔记把整套做法拆开讲清楚。你不需要拥有大型渗透测试平台一个Python脚本、一份精简的弱口令字典、几个关键参数就能在授权范围内快速验证fikker这类系统的认证强度。内容覆盖摸底、脚本实现、参数调优和实战翻车点适合需要做内网风险评估的渗透测试工程师也适合运维同学用来自查自纠。2. 认清fikker的三层暴露面端口、协议、认证方式都别想当然2.1 fikker到底是什么它的控制通道长什么样fikker是一款常见的CDN/Web缓存加速软件很多IDC用它给客户做静态资源加速、反向代理和全站缓存。它的常规工作端口是80和443真正危险的是两个控制面一个是Web管理后台默认监听在6780端口用来做域名管理、缓存刷新和流量统计另一个是CLI控制台默认使用7777端口走Telnet协议可以执行节点切换、配置查看这类操作。很多人在做渗透测试时只盯着6780的Web后台这其实是漏了一半的风险面。CLI控制台同样是密码认证而且它返回的是明文文本协议脚本交互比Web表单更简单直接。更关键的是CLI控制台通常没有登录次数限制这给了弱口令检测脚本很大的尝试空间。所以在写检测脚本之前先把目标机器的这两个端口摸清楚确认哪个口开着、哪个口对外再决定优先测哪条通道。我一般会用nmap先做一次端口探测。命令不复杂重点是把服务和版本信息带出来方便后面判断具体的握手方式。nmap -Pn -sS -p 6780,7777 --open -sV 192.168.1.10逻辑说明-Pn跳过主机存活探测避免目标禁ping时漏报-sS做SYN半开扫描速度快且不容易在目标日志里留下大量连接记录-sV开启版本探测能识别出fikker的服务标识和版本信息。扫描结果里如果看到6780和7777都处于open状态那这台机器的两个控制面就都有测试价值。若只有7777开放也不要错过CLI通道依然可以检测。此时还要看一下Web后台的登录页形态。直接在浏览器里访问一下目标IP的6780端口确认是简单表单登录还是HTTP Basic认证。这个细节决定了脚本里用requests的data参数还是auth参数。有些版本的管理后台做了前端动态校验比如先请求一个token再登录这类情况需要先从登录页HTML里提取隐藏字段再拼装登录请求。不要拿到登录页就断定是个简单POST翻一下页面源码是很有必要的。2.2 先探测后猜测确认认证方式再写脚本在写任何代码之前我习惯先用curl观察一下服务端的响应头和行为。这一步成本极低但能规避掉一半的脚本适配问题。curl -I -k --connect-timeout 5 --max-time 10 https://192.168.1.10:6780/逻辑说明-I只取响应头判断是否存在WWW-Authenticate字段-k跳过证书校验因为很多自建节点用的是自签名证书两个超时时间参数保证目标无响应时快速返回而不是干等。响应头里如果出现WWW-Authenticate: Basic realm...说明这是HTTP Basic认证脚本要用requests.auth.HTTPBasicAuth来提交账号密码。如果返回的是200且带出来一个HTML登录页那就是表单认证。还有一种情况是响应头里出现WWW-Authenticate: Digest这是摘要认证requests同样支持但要额外处理auth参数的选择。CLI通道的探测更简单可以用nc或者Python的socket直接连一下7777端口看它是否主动弹出Username:提示。如果连过去直接返回一段banner和登录提示就说明这是一个可交互的文本协议后面socket脚本就能稳定工作。如果连上去没有任何响应或直接被断开可能是目标加了访问控制也可能是服务没有真正监听在TCP上。2.3 弱口令字典别上来就加载几G的大库新手在做渗透测试实战时常犯一个错误就是直接把网上几G的字典丢进脚本里跑。这种做法碰到有锁定策略的目标跑个几百条就把账号锁死了结果变成自爆。我自己更倾向于准备一份按命中率排序的精简弱口令字典先把默认口令和高频弱口令跑完再根据目标信息定制第二批字典。一个合理的弱口令字典至少包含以下分类空口令部分设备默认允许空密码登录账号名与密码相同比如admin/admin、root/root常见数字组合123456、12345678、88888888厂商默认口令fikker这类软件安装文档里推荐的初始密码批量增加的通用弱口令password、Passw0rd、Pssw0rd字典文件格式建议一行一条编码统一成UTF-8无BOM。特别提醒一点口令里带#或;的条目在shell环境下要小心被解释成注释或命令分隔符脚本里读取时要按行精确匹配不要做任何eval或shell拼接。后面的脚本我会用Python的readlines()逐行读取确保特殊字符不产生副作用。3. 实现弱口令检测脚本从登录请求到批量验证的完整过程3.1 先跑通Web后台的登录请求脚本的第一步是把Web后台的登录流程完整复现出来。这个环节最关键的是搞清楚“成功”和“失败”由什么决定。很多管理后台在密码错误时照样返回HTTP 200只是页面内容不同脚本如果只看状态码就会出现满屏“成功”的笑话。正确的做法是在本地先用一个已知错误的密码和一个已知正确的密码各登录一次对比两次响应的差异点再把这个差异写进判定条件。下面这段代码实现了单次登录检测的核心逻辑使用的库是requests。这里以表单登录为例Basic认证的差异点我在注释里标注清楚。import requests import urllib3 import warnings # 关闭自签名证书的警告控制台干净一些 warnings.filterwarnings(ignore, categoryurllib3.exceptions.InsecureRequestWarning) TARGET https://192.168.1.10:6780 LOGIN_URL TARGET /login # 以实际登录接口为准 def check_one(username, password): 检测单组账号密码返回(是否成功, 响应特征) session requests.Session() # 模拟浏览器UA降低被WAF直接拦掉的概率 session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 }) payload { username: username, password: password, } try: resp session.post(LOGIN_URL, datapayload, verifyFalse, timeout8, allow_redirectsFalse) # 登录成功时通常会下发会话Cookie if resp.status_code 302 and session in resp.headers.get(Set-Cookie, ).lower(): return True, resp.status_code # 有些版本不跳转直接返回200和固定成功标识 if resp.status_code 200 and 欢迎 in resp.text or dashboard in resp.text: return True, resp.status_code return False, resp.status_code except requests.exceptions.RequestException as e: return False, ferror: {e}逻辑说明Session()对象会自动管理Cookie登录成功后服务端下发的会话Cookie会保持在session里后续刷新、查询都能复用。allow_redirectsFalse关闭自动跟随跳转这样登录成功后的302跳转可以直接被捕获方便通过状态码做初判。verifyFalse跳过证书校验适配自签名证书的内网节点。判定成功与否的规则是要么是302跳转且Set-Cookie里有会话标识要么是200响应且页面里出现了登录后才有的关键字。这两条规则要结合刚才说的“先探一次正确/错误响应”来修正不同版本的固定标识不一样。参数说明里最需要关注的是timeout。内网环境一般延迟很低设8秒已经足够如果是跨网段扫描建议提升到15秒否则高延迟链路会频繁超时导致漏报。Session()的headers里设置User-Agent是必须的一些安全设备会对没有UA或UA异常的Python请求直接拦截这一行能省掉不少麻烦。3.2 CLI控制台弱口令检测的特殊处理CLI控制台走的是Telnet文本协议不能用HTTP库去处理直接用Python内置的socket就能实现。交互流程通常是连接成功后服务端发送Username:提示我们发送用户名加换行服务端再发送Password:提示再发送密码加换行。如果密码正确会进入命令提示符比如fikker或admin如果密码错误一般会返回Login incorrect或直接断开连接。import socket def check_cli(host, port, username, password, timeout5): 检测fikker CLI控制台登录返回是否成功 try: sock socket.create_connection((host, port), timeouttimeout) sock.settimeout(timeout) banner sock.recv(1024).decode(utf-8, errorsignore) if Username not in banner: sock.close() return False, no_login_prompt sock.sendall((username \n).encode()) prompt sock.recv(1024).decode(utf-8, errorsignore) if Password not in prompt: sock.close() return False, no_password_prompt sock.sendall((password \n).encode()) result sock.recv(1024).decode(utf-8, errorsignore) sock.close() # 登录成功的标志出现命令提示符而不是错误提示 if incorrect in result.lower() or failed in result.lower(): return False, result.strip() if in result or # in result: return True, result.strip() return False, result.strip() except socket.timeout: return False, timeout except Exception as e: return False, ferror: {e}逻辑说明连上后先读取banner确认服务端确实在等待用户名输入防止把无聊的端口响应当成登录界面。发送用户名后紧接着读取下一次返回必须确认出现Password:提示再发密码否则密码可能被发到错误的位置。最终结果判断上优先检查错误关键字防止把Login incorrect这类提示误判为登录成功判断命令提示符时使用或#这类特征这是多数CLI系统通用的提示符形态。参数说明timeout设5秒在局域网内足够如果在跨网段或公网测试建议调到10秒。CLI通道一般不设连接数限制但服务端并发连接数有限脚本里需要加信号量控制并发量这个放到下一章细说。另外recv的缓冲区设为1024字节已经足够登录交互的返回内容通常不会超过这个大小。3.3 批量检测并发控制与结果落盘真正的检测流程不是单条密码逐个跑那效率太低。我一般用ThreadPoolExecutor做线程池并发同时把结果实时写入CSV避免进程中断后丢失已测数据。下面这段代码是批量检测的骨架同时兼容了Web和CLI两种通道。import csv import threading from concurrent.futures import ThreadPoolExecutor # 结果写锁防止多线程同时写CSV造成行错乱 write_lock threading.Lock() def batch_check_web(host, port, userlist, passlist, max_workers5): 批量检测Web后台弱口令 results [] total len(userlist) * len(passlist) done 0 def worker(username, password): ok, detail check_one(fhttps://{host}:{port}, username, password) if ok: with write_lock: results.append([host, port, username, password, WEB, str(detail)]) print(f[] 命中: {username} / {password}) else: # 每5%进度打印一次方便观察运行状态 nonlocal done done 1 if done % max(1, total // 20) 0: print(f[*] 进度: {done}/{total}) with ThreadPoolExecutor(max_workersmax_workers) as executor: for username in userlist: for password in passlist: executor.submit(worker, username, password) # 写结果文件utf-8-sig防止Excel打开中文乱码 with open(result.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([host, port, username, password, channel, detail]) writer.writerows(results) print(f[*] 检测完成结果写入 result.csv)逻辑说明max_workers5控制并发线程数这是经过实践后比较稳妥的值原因会在下一章展开。write_lock保证多个线程同时对results列表做append时不会产生数据竞争。进度打印用nonlocal done修改外层计数器每跑到5%就打一条进度避免脚本长时间沉默让人以为卡死了。CSV写入用了utf-8-sig编码Windows上的Excel打开时不会把中文密码显示成乱码。参数说明userlist和passlist分别是用户名列表和密码列表两个列表做笛卡尔积。合理的做法是控制用户名数量在5个以内比如admin、root、test、operator、administrator密码控制在100~200条之间这样总请求数在1000以内配合5并发不会对目标造成太大压力。如果目标是生产系统且没有签署完整的渗透测试授权建议把max_workers降到2宁可慢一点也别把业务系统搞出故障。4. 参数与运行策略怎么调并发、超时、锁定机制一并对齐4.1 并发数不是越高越快5是多数场景的舒适区很多人在写检测脚本时喜欢把线程开到20甚至50觉得跑得快、效率高。但这里有两个问题。第一目标机器的管理端口通常由Web服务进程监听这类进程的连接处理能力有限同时涌入20个TCP连接可能直接导致服务无响应。第二安全设备或WAF对同IP的并发连接数有告警阈值一旦触发封禁后续所有请求都会失败反而白跑。我实测下来Web后台检测的并发数控制在3~5最合适。这个并发量既能跑出明显的加速效果又不会让目标服务感知到异常压力。CLI通道的并发要更保守因为Telnet服务通常使用单进程处理连接并发太高容易出现连接被拒绝的情况建议CLI检测的并发数控制在2~3。如果你面对的是一个很小的管理后台比如内存只有512M的VPS并发数降到1都不过分。4.2 超时、重试和延时三组参数决定脚本的稳定性超时参数直接影响检测结果的准确度。超时设太短网络抖动一下就被记为失败漏掉真正命中的密码设太长整体检测时长成倍增长。推荐的做法是把单个请求超时设为8秒连接超时单独设为3秒两个参数分开控制。如果目标在公网且链路质量一般单请求超时提升到12秒连接超时保持3秒不变。重试策略也不建议对所有失败都做重试。只有网络层面的错误连接超时、ConnectionError、拒绝连接值得重试密码错误这类业务层的失败不需要重试重试只会浪费时间。我一般只对网络错误重试一次连续两次失败就跳过这条记录并写入日志文件。延时策略上每完成一组检测后加0.2~0.5秒的随机延时尽量让请求节奏看起来更接近人工操作降低被安全设备标记的几率。参数Web后台推荐值CLI控制台推荐值适用场景说明max_workers52内网低延迟环境请求超时8秒5秒单次登录请求等待上限连接超时3秒3秒TCP握手阶段超时网络错误重试1次1次仅限连接层异常组间随机延时0.2~0.5秒0.5~1秒降低请求频率特征4.3 密码顺序本身就是一种防护策略如果目标系统配置了登录失败锁定策略最怕的就是把高频弱口令一股脑跑完导致账号锁死。这个问题的解法不在代码层面而在字典排序和检测策略上。正确做法是分段检测。第一段只测空密码和账号名本身比如admin/admin、root/root这类这些是渗透测试中最常命中的组合。第二段再加常见数字密码比如123456、88888888、666666。第三段才加入带大小写和特殊字符的复杂弱口令。每一段之间留出停留时间如果目标是生产系统这个留白可以拉长到5分钟给账号锁定策略留出解锁窗口。这种做法还有一个意外收获。大多数内网管理员设置的密码习惯是“账号名简单数字”的变体比如admin123、root888。把这类组合放在字典靠前的位置往往比死磕几G的大字典更早出结果。真正在实战里命中弱口令的绝大多数不是那些花哨的强密码变体而是这种几乎不需要记忆成本的默认组合。5. 弱口令检测实战的五个大坑现象、原因、解决方案5.1 全部密码都返回“登录成功”结果是白高兴一场现象脚本跑完日志里每一条都显示命中点开详情却发现全是200状态码。原因登录失败时服务端返回的HTTP状态码也是200只是响应体里有一段错误提示而脚本的判定条件只看了状态码没有检查业务层面的成功标识。这是requests脚本最常见的问题几乎每个人都踩过。解决先用一个必然错误的密码登录一次把响应体打印出来找到错误提示的关键字比如“密码错误”“用户名不存在”再用一个正确的密码登录一次找到成功时的跳转或会话Cookie关键字然后把这个差异写进判定条件。如果两次返回的差异只在Cookie上就判断是否出现了新的Set-Cookie字段。5.2 测试进行到一半目标管理后台直接打不开了现象脚本跑了几百条之后浏览器访问6780端口无响应服务器上Web服务直接挂了。原因并发连接数过高把管理后台Web服务进程的连接池打满或者是触发了系统层面的连接数限制。这个现象通常在目标机配置较弱的机器上出现尤其是只有1~2核CPU的小型VPS。解决立即停止脚本降低并发数或改为单线程模式。如果服务已经挂了只能通过SSH登录到目标机器重启fikker进程。重启后把max_workers降到2并给每个请求之间增加0.5秒以上的随机延时。这条经验告诉我们做弱口令检测前先确认目标的硬件配置配置太差的机器上宁可多花时间也要用最温和的检测节奏。5.3 密码里有特殊字符提交上去全部报错现象字典里有几条带、或#的密码用脚本测的时候总是返回参数错误。原因requests在接收data参数为dict时会自动做URL编码但如果脚本里手动拼了字符串比如fusername{user}password{pwd}密码里的就会把参数截断导致密码只提交了一半。还有的脚本用了urllib.parse.urlencode但忘了加quote_viaquote空格和中文密码也会有编码问题。解决统一改用dict传参requests的底层会正确处理URL编码。少数字典里的密码是URL编码后的形态比如%40这种情况可以直接把密码原样作为dict值提交requests会再次编码导致双重编码解决方式是先把密码做一次unquote。这个坑虽然小但在渗透测试实战中很容易把有效密码漏掉。5.4 HTTPS自签名证书导致大量超时和警告现象目标管理后台用的是HTTPS自签名证书脚本虽然写了verifyFalse但控制台刷满了InsecureRequestWarning而且部分请求出现SSL错误。原因某些Python版本在verifyFalse时依然会有底层socket的异常抛出尤其是目标TLS版本较低如TLSv1.0时新版OpenSSL可能直接握手失败。还有一个原因是之前提到的证书警告根本没有被过滤错误日志和目标真实结果混在一起排查起来头大。解决在脚本开头加上urllib3.disable_warnings()彻底关闭证书警告。如果握手失败报SSLError尝试在requests.post里增加ssl_versionssl.PROTOCOL_TLSv1_2参数或者降低到TLSv1。新版Python对旧TLS协议支持有限实在不行就退回用HTTP明文协议做检测如果目标同时开放了HTTP端口或者改用pycurl这类底层库来绕过TLS兼容性问题。5.5 检测结果CSV里的中文密码全部乱码现象用Excel打开result.csv中文密码显示成一堆乱码没法直接贴到报告里。原因open()函数在Windows上默认用GBK编码写文件而密码字典是UTF-8编码GBK写入时遇到无法映射的中文字符就会出错或显示乱码。解决写入CSV时显式指定encodingutf-8-sig。utf-8-sig会把BOM头写进文件Excel打开时自动识别为UTF-8中文就不会乱码。同时读取字典文件时也要用encodingutf-8保持整个脚本的编码链路一致。这个细节在测试国内系统时特别重要因为中文密码和中文用户名很常见。6. 检测之后别急着交差验证有效口令并完成闭环加固脚本跑出“命中”之后不要直接把结果写进报告。我习惯做一次正向验证用命中的账号密码手动登录目标后台确认能进入管理界面并能看到真实业务数据。验证这一步必须人工完成因为脚本的判定基于响应特征理论上存在误判可能。人工登录的另一个目的是截取登录成功的页面截图作为渗透测试报告里的有效证据留存。验证通过之后按照渗透测试流程的合规要求应当同步输出加固建议。对fikker系统而言至少要完成三个动作第一修改管理后台和CLI控制台的密码密码强度不低于12位且包含三类字符第二将6780和7777端口加入到防火墙白名单只允许运维堡垒机的IP段访问第三如果业务上不需要CLI远程管理直接把7777端口在防火墙上封禁或关闭fikker配置文件里的CLI监听选项。这三个动作做完弱口令问题才能真正闭环而不只是停留在“测出来、写进报告”这一步。脚本本身也可以再向前一步。给它加一个--verify参数命中后自动用同一组密码做二次登录验证降低误报率。这不算复杂但能让脚本在自动化巡检场景里更可靠。我的习惯是每次检测完把脚本的日志、命中详情、目标响应特征一起归档下次测同类系统时直接对比少走很多弯路。希望帮到你。本文还有配套的精品资源点击获取