进行系统服务扫描渗透测试

去年秋天，进行我给一家做跨境电商的系统小公司做了一次授权渗透测试。目标是服务一个公网IP，客户说“就一台服务器，扫描渗透跑了个官网和后台”。测试我扫完端口就笑了——3306端口大剌剌敞着，进行MySQL版本是系统5.7.26，root用户允许从任意IP登录，服务密码是扫描渗透`admin123`。这不是测试段子，是进行真实发生的事。系统服务扫描这件事，系统往往比漏洞利用本身更能暴露问题。服务

很多人把渗透测试等同于找SQL注入、扫描渗透传WebShell。测试但真正进入内网或者拿到一个IP时，第一步永远是对系统服务做扫描。nmap跑一遍全端口，`-sV`探测版本，`-sC`跑默认脚本，这些操作看起来机械，却能直接告诉你这台机器“穿了什么衣服”。我习惯先来一遍`nmap -p- -sV -T4 `，全端口扫完通常要几分钟。这段时间别闲着，可以同时用masscan快速过一遍常见端口，做个交叉验证。

扫描结果里最有意思的不是开放了哪些端口，而是那些“不该开却开着”的服务。比如一台Web服务器上开着445端口，大概率是运维图方便共享了目录；数据库服务器上开着22端口且允许密码登录，爆破脚本跑一晚上总能进去几个。我见过最离谱的是一台对外提供API的Linux机器，上面跑着Redis，没设密码，bind 0.0.0.0。用redis-cli连上去，`info`命令直接返回了系统信息，再写个SSH公钥进去，root权限到手。

版本信息是另一个金矿。nmap的`-sV`会尝试识别服务版本，但有时候不够准。这时候可以配合`nc`手动连上去看banner。比如连上25端口，SMTP服务会自报家门：“220 mail.example.com ESMTP Postfix”。版本号一出来，searchsploit查一下，对应CVE直接匹配。有一次扫到一个老版本的Jenkins，连未授权访问都不用，直接通过CLI接口执行系统命令。客户还觉得“我们Jenkins在内网，没事”。

UDP扫描经常被忽略。大部分渗透测试只扫TCP，但UDP上的SNMP、DNS、NTP服务往往配置更松散。`nmap -sU -p 161,53,123 `跑一遍，SNMP如果community string是public，能直接读出系统进程列表、网络接口、甚至路由表。这些信息对后续横向移动帮助极大。我遇到过一个案例，通过SNMP读到了内网另一台数据库的IP和端口，而那台数据库只允许从这台机器访问。

扫描完之后别急着关掉终端。把结果导出成XML，用`xsltproc`生成HTML报告，或者丢进Metasploit的db_import。我习惯用`grep`过滤出所有开放端口，再按服务类型分类。Web服务归一堆，数据库归一堆，远程管理归一堆。然后针对每一类找对应的弱口令或者已知漏洞。这个过程很枯燥，但比盲目打Payload效率高得多。

说个具体细节。扫到3389端口开放时，先别急着爆破。用`nmap --script rdp-enum-encryption`看看加密级别。如果是“Negotiate”或者“RDP”，说明可能没打补丁，MS12-020漏洞可以利用。但更常见的是，管理员为了方便，把RDP直接暴露在公网，而且没开NLA。这种情况下，用hydra跑一遍常见弱口令，成功率不低。我试过一个客户，密码是`Company@2023`，字典里刚好有。

系统服务扫描不是终点，而是起点。它给你的是一张地图，告诉你哪里有门、哪里窗户没关。至于进不进去、怎么进去，那是下一步的事。但如果你连地图都不看，直接翻墙，摔死的概率更大。我见过太多人一上来就sqlmap跑注入，结果目标站根本没用数据库，后台是个静态页面加一个Tomcat管理端。扫一遍端口，8080开着，manager/html弱口令，war包一传，完事。

最后提一句授权问题。扫描行为本身就会在目标系统留下日志，未授权的扫描在大多数国家都是违法的。我每次动手之前，都会让客户签一份书面授权书，明确IP范围、时间窗口、允许的测试强度。别嫌麻烦，这是保护你自己。