使用nmap对应用系统安全评估

上周帮一个朋友看他的小电商后台，刚把域名丢进nmap跑了个基础扫描，用系结果出来一堆意外端口。统安他那台阿里云ECS上除了80和443，全评还开着6379和27017。使用Redis没设密码，用系MongoDB也是统安裸奔状态。朋友当时就懵了——他以为安全组只放了web端口就万事大吉。全评这事让我觉得，使用很多开发同学对nmap的用系印象还停留在“扫端口工具”，实际上它做应用系统安全评估时，统安能挖出的全评东西远比想象中多。

nmap默认的使用SYN扫描确实快，但评估应用系统时我习惯先加几个参数。用系-sV做版本探测是统安必须的，它能告诉你目标端口跑的是OpenSSH 7.4还是8.9，是nginx 1.18还是1.24。版本号直接关联已知CVE，比如那个经典的Log4j2漏洞，如果nmap识别出Java应用用了特定版本的log4j-core，后面的事就不用我多说了。-O做系统指纹识别，有时候能发现对方把Linux伪装成Windows Server，这种小把戏在渗透测试里挺常见。

脚本引擎才是nmap在应用安全评估里的重头戏。默认的--script=default会跑一批基础检查，但真正有用的是那些针对性脚本。比如http-enum能扫出web应用的敏感目录，http-headers抓取服务器响应头看有没有暴露版本信息，ssl-enum-ciphers检查TLS配置是否支持弱加密套件。我遇到过一个小程序后端，nmap的http-shellshock脚本直接报出CGI路径存在Shellshock漏洞，运维还坚持说“我们没用bash”。

nmap -sV -sC -O -p- --script http-enum,http-headers,ssl-enum-ciphers 192.168.1.100

上面这行命令是我做应用评估的起手式。-p-扫全端口，别只扫常见的1000个。有次客户坚称只开了8080，全端口扫描发现32768端口跑着Java RMI，那个端口后来成了突破点。-sC等于--script=default，省得手动敲一长串脚本名。输出结果里重点关注“State”是open的端口，以及脚本输出的“VULNERABLE”字样。

UDP扫描在应用评估里容易被忽略。-sU扫UDP端口慢得让人想砸键盘，但DNS、SNMP、NTP这些服务往往跑在UDP上。有次评估一个内部系统，TCP端口干干净净，UDP 161端口却开着SNMP且community string是public。通过SNMP walk直接读出了系统进程列表和网络接口信息，相当于把内网拓扑图送给了攻击者。

输出格式也值得说道。默认的交互式输出看完就没了，用-oX生成XML方便后续用脚本解析，-oN存普通文本，-oG存grepable格式。我习惯三个一起上：-oA scan_result，生成三个文件。特别是做多个目标评估时，grepable格式配合grep、awk能快速筛出所有开放了22端口且SSH版本低于7.4的主机。

时间参数别用默认值。-T4在大多数内网环境够用，-T5容易丢包导致漏报。--min-rate和--max-retries根据网络质量调。有次在客户现场用默认参数扫一个C段，花了四十多分钟，后来改成-T4 --min-rate 2000，三分钟出结果。但公网目标别这么干，容易被封IP。

最后说个反直觉的：nmap的--script vuln类别脚本别乱跑。这些脚本会主动发送攻击载荷，比如http-sql-injection会尝试注入SQL语句。生产环境跑这个可能触发WAF告警甚至导致业务异常。评估前一定确认授权范围，别把安全评估变成DDOS攻击。我一般先用--script safe跑一遍，确认没问题再上vuln类脚本。

工具终究是工具。nmap给出的端口列表和版本号只是拼图的第一块，真正的评估得结合业务逻辑、代码审计和配置检查。但如果你连nmap都没跑明白，后面那些更复杂的环节基本无从谈起。先从nmap -sV -sC开始，把目标的家底摸清楚，再谈怎么防。