文章总结： 本文系统梳理了内网中62个与弱密码相关的协议和软件，指出弱密码问题本质是覆盖面广而非单一密码强度。文章按远程管理、数据库、邮件、文件共享等类别拆解风险，强调攻击者会扫描所有开放端口而非仅核心资产，并指出遗留系统与开发临时部署是重灾区。防御建议分三步：资产盘点建立认证入口清单、授权范围内口令检测、整改与监控，同时提醒勿只测重要系统而忽略边缘资产。
综合评分： 82
文章分类： 安全工具,安全建设,渗透测试,漏洞分析
第80篇 AI全栈 · 62个与弱密码相关的协议
原创
陈看山
陈看山
安全诸子
2026年9月15日 14:01
上海
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
内网里跑一轮端口扫描，结果可能比你预想的还要热闹。很多人以为弱密码问题就是 SSH 和 RDP 没设好口令，实际上，只要你的环境里存在任何需要身份认证的服务，它就可能成为被爆破的目标。真正让人头疼的不是某个单一服务，而是散落在各个业务角落、由不同团队维护、甚至已经没人说得清是谁部署的那几十种协议和软件。 它们不是同一类东西，有的是数据库，有的是远程控制工具，有的是邮件协议，有的是版本管理软件，但都有一个共同点：一旦口令太弱或者被重用，攻击者拿到权限的难度远比你想象的低。
弱密码问题的本质不是“密码”，而是“覆盖面” 很多安全团队在防御时习惯盯住几个核心资产，比如 VPN、堡垒机、核心数据库
但真实世界里，攻击者并不会只挑这些目标。他们会先扫描整个网段，找出所有开放端口，然后对每一个暴露出来的认证入口尝试弱口令。 这 62 个协议或软件，本质上就是攻击者的字典列表。它们覆盖了几大类场景： – 远程管理类：RDP、VNC、Telnet、SSH、PC-Anywhere、Radmin、VMware-Auth – 数据库类：MySQL、MSSQL、Oracle、DB2、PostgreSQL、MongoDB、Sybase、Firebird – 邮件类：SMTP、POP3、IMAP，以及 SMTP 用户名枚举 – 文件共享类：FTP、SMB、AFP、NCP、PCNFS – Web 应用与中间件：Tomcat、IIS、各种 HTTP 认证方式 – 即时通信与协作类：IRC、ICQ、XMPP、Teamspeak – 版本控制：CVS、Subversion – 网络设备与协议：Cisco AAA、Cisco enable、SNMP、LDAP、SIP、Rexec、Rlogin、Rsh 有一点值得注意：这个列表里既有现代基础设施组件（比如 MongoDB、Docker 相关的 API），也有大量老旧但仍然存活在企业内网里的协议（比如 Rlogin、NCP、PC-Anywhere）。很多你以为已经绝迹的东西，在生产环境里仍然作为“遗留系统”运行着。
为什么这些服务会成为弱密码重灾区 先说一个常见的误区
很多人认为“只要我设置了密码，就安全了”。但问题往往出在密码本身的质量和生命周期上。 以 Cisco enable 为例，很多网络设备的管理员为了省事，把它设成了设备型号或简单的数字组合。再比如 SNMP 的 community string，默认的 public/private 几乎是所有扫描器都会优先尝试的组合。而像 Tomcat 这类 Web 应用服务器，后台管理页面经常被部署成默认的 admin/admin 或者 admin/tomcat。 更深层的问题在于，这些服务往往被部署在“没有人持续跟进”的状态下。一个开发团队为了测试临时启动了一个 MongoDB 实例，没有绑定访问控制；测试结束之后服务忘了关；几年后这个实例被扫描发现，成为进入内网的跳板。这种情况在真实环境里发生的频率，远超大多数人的预期。
62 个协议或软件按风险类别拆解 为了方便判断优先级，可以把这 62 个对象按实际使用频率和风险暴露面做一个分组
第一类：高暴露面且爆破成功率极高的服务 SSH、RDP、Telnet 这类远程管理协议排在首位。它们几乎存在于每一台 Linux 或 Windows 服务器上，只要端口暴露到不可信网络，就会持续遭受口令尝试。SMB 在 Windows 域环境里同样属于高价值目标，一旦拿到 SMB 的口令，往往意味着整个共享资源目录的访问权限。 MySQL、MSSQL、Oracle 这类数据库之所以危险，是因为它们经常被应用服务器以高权限账号连接。如果一个数据库管理员的密码是强密码，但应用的只读账号用了弱密码，攻击者依然可能通过 SQL 注入或直接登录获取大量业务数据。 第二类：容易被忽略但影响巨大的协议 SNMP（v1/v2 尤其明显）经常被用来读取网络设备的配置和系统信息，默认 community string 一旦被猜到，攻击者可以拿到设备型号、接口信息、路由表，甚至在某些情况下直接修改配置。SMTP 用户名枚举看起来只是“查账号”，但它为后续的钓鱼或定向爆破提供了基础。 AFP 和 NCP 这类文件共享协议在苹果和 NetWare 环境中仍然存在，安全团队往往没有监控它们。LDAP 则更特殊，它本身就是用来做认证的，如果 LDAP 的绑定账号用了弱密码，等于把整个目录服务的钥匙交了出去。 第三类：遗留或小众但依然在用的软件 PC-Anywhere、Radmin、Teamspeak 这类工具在当前的安全资产清单里经常是缺失的。它们可能是某个外包团队在五年前部署的，也可能是某位资深工程师离职后留下的“备份通道”。这些软件往往不遵循企业的统一认证体系，密码独立设置，且没有定期轮换。 CVS 和 Subversion 这类版本控制工具，如果仓库的访问权限只依赖简单口令，内部源码可能直接暴露。Oracle Listener 这个容易被忽略——很多人只关注数据库本身，却忘了 Listener 也可以被远程利用。
一张表看清这 62 个对象的全貌 下表按类别整理了这些协议或软件是什么、通常部署在哪里、弱密码的主要风险是什么
注意，这张表的目的是帮你做资产盘点，不是穷举攻击手法。 | 类别 | 对象 | 典型部署位置 | 弱密码风险点 | |——|——|————–|————–| | 远程管理 | SSH、Telnet、Rlogin、Rsh、Rexec | Linux/Unix 服务器、网络设备 | 直接获得 shell 权限 | | 远程桌面 | RDP、VNC、Radmin、PC-Anywhere | Windows 服务器、运维工作站 | 远程控制桌面环境 | | 虚拟化 | VMware-Auth | vCenter/ESXi 管理接口 | 控制整个虚拟化平台 | | 数据库 | MySQL、MSSQL、Oracle、DB2、PostgreSQL、MongoDB、Sybase、Firebird | 业务数据库服务器 | 读取/篡改业务数据 | | 中间件 | Tomcat、IIS | Web 应用服务器 | 管理后台暴露、部署 webshell | | Web 认证 | HTTP-GET/POST/HEAD、HTTP-FORM、HTTPS 系列 | 各类 Web 应用 | 登录接口被爆破 | | 文件共享 | FTP、SMB、AFP、NCP、PCNFS | 文件服务器、NAS | 下载/上传内部文件 | | 邮件 | SMTP、POP3、IMAP、SMTP Enum | 邮件服务器 | 邮箱被控制用于钓鱼或数据窃取 | | 目录与认证 | LDAP、Cisco AAA、Cisco auth、Cisco enable | 统一认证服务器、网络设备 | 控制认证体系或设备管理权限 | | 网络管理 | SNMP v1/v2/v3 | 交换机、路由器、打印机、UPS | 读取设备配置，部分版本可写 | | 版本控制 | CVS、Subversion | 代码仓库服务器 | 源码泄露 | | 通信协作 | IRC、ICQ、XMPP、Teamspeak、SIP | 内部沟通工具、VoIP 系统 | 通信内容被监听或账号被滥用 | | 其他 | Oracle Listener、Oracle SID、Memcached、SOCKS5、HTTP-Proxy、RTSP、NNTP | 各类专用服务器 | 服务配置被篡改或用于跳板 | 这里面每一个条目，都对应着一种“如果密码太弱，会发生什么”的具体后果。值得强调的是，Memcached 虽然常被归类为键值缓存，但暴露在公网的 Memcached 实例如果未设置认证，可能被用于反射放大攻击或直接读取缓存中的敏感会话数据。
这些协议和软件在攻击链中的真实位置 只看单个服务的风险是不够的，更关键的是理解它们在攻击链中的位置
以一次典型的横向移动为例：攻击者首先通过某个暴露的 Tomcat 管理后台拿到一台 Web 服务器的权限，然后在内网扫描时发现了一台运行 MSSQL 的数据库服务器。由于这台数据库服务器的 sa 账号使用了和 Tomcat 后台一样的密码（密码重用），攻击者直接登录数据库，拖走了用户表。整个过程里，弱密码扮演的角色不是孤立的，而是被串联起来形成了一条完整的攻击路径。 再举一个例子：某企业内部使用了 Asterisk（开源的 SIP 服务器软件）作为电话系统。如果 SIP 分机的认证密码是四位数的 PIN 码，攻击者可以通过暴力枚举的方式拿到分机权限，然后拨打高额国际电话或监听内部通话。这种风险在传统的安全扫描里经常被忽略，因为安全团队可能根本没有把 VoIP 系统纳入弱口令检查的范围。
防御思路
从查漏到体系化管控 面对这么多协议和软件，逐一手工检查不现实。正确的做法是分三步走。 第一步，做资产盘点。把网络上所有开放端口和对应的服务识别出来，建立一份“认证入口清单”。这一步的核心是不要漏掉任何一条，哪怕是一个看起来无害的 SOCKS5 代理端口，也可能被用来转发内部流量。 第二步，做口令检测。对清单里的每一个认证入口，使用弱口令字典进行检测。这里的字典不只是常见的 password、123456，还要包含设备默认口令、厂商初始化口令、以及企业内部曾经泄露过的历史口令。检测动作必须在授权范围内进行，建议在专门的渗透测试窗口期或者使用自有的安全评估工具完成。 第三步，做整改和监控。检测出来的弱口令要通知到资产责任人，限期修改。同时，对关键认证入口启用失败尝试锁定、IP 白名单、多因素认证等机制。对于已经不受支持的协议（比如 Rlogin、PC-Anywhere），能下线就下线，不能下线的至少要在网络层面限制访问来源。
一个容易犯的错误
只测“重要系统” 很多团队做弱口令检测时，只针对核心业务系统。这恰恰是最大的盲区。攻击者不会只打你的核心系统，他们会找最容易进的那扇门。Dev 环境的测试数据库、测试用的 FTP 服务器、临时开的 Web 服务，这些地方往往密码极弱甚至没有密码，却可能连接着生产网络的通路。 建议把检测范围扩大到所有能通过网络访问到的认证服务，尤其是那些“没人认领”的资产。如果扫描发现一个未知 IP 上运行着 Radmin 或者 PC-Anywhere，第一反应不应该是“这是谁装的”，而是“这台机器很可能已经被入侵过或者正在被用于后门”。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全诸子 陈看山
陈看山《第80篇 AI全栈 · 62个与弱密码相关的协议》