http端口漏洞

去年冬天，端口我帮一个做外贸的漏洞朋友查服务器。他的端口后台管理页面莫名其妙多出几十个陌生账号，日志里全是漏洞来自巴西和越南的IP。问题出在一个他压根没在意的端口地方——8080端口。那个端口上跑着一个测试用的漏洞Tomcat，密码是端口admin/123456。攻击者用扫描器扫到开放端口，漏洞试了三次就进去了。端口

HTTP端口漏洞这件事，漏洞很多人以为就是端口80端口没配好SSL。实际上麻烦大得多。漏洞默认端口80和8080只是端口冰山一角，真正要命的漏洞是那些"临时"开放却忘了关的端口。比如开发人员图方便，端口在3000端口挂个Node服务，在5000端口跑个Flask调试模式，在9200端口暴露Elasticsearch。这些端口一旦对公网开放，等于把后门钥匙插在锁上。

我见过最离谱的一个案例。某公司用Jenkins做持续集成，端口开放到公网，没设登录验证。任何人访问那个IP的8080端口，都能直接看到所有构建脚本，里面明文写着数据库密码和云服务AK/SK。攻击者甚至不需要懂什么漏洞利用，浏览器打开就能拿走一切。这不是技术问题，是基本的安全意识缺失。

端口漏洞的利用方式其实很朴素。扫描器批量扫全网IP的常见端口——80、443、8080、8443、7001、9090、2375。2375是Docker远程API的默认端口，开放且无认证的话，攻击者可以直接在宿主机上起一个特权容器，挂载根目录，然后改SSH密钥。整个过程不到两分钟。我在Shodan上搜过，国内暴露2375端口的机器数量一直维持在四位数以上。

再说一个容易被忽略的点：HTTP端口的漏洞不全是"未授权访问"这么简单。有些是协议实现层面的问题。比如某些老版本的Nginx在特定配置下，对畸形HTTP请求的处理会导致内存泄漏；Apache的mod_proxy在反向代理场景中，如果后端端口配置不当，可能被利用做SSRF跳板。这些漏洞的利用门槛比弱密码高，但一旦被盯上，影响范围更大。

那怎么防？我的习惯是三步。第一步，从外网做一次全端口扫描，nmap扫1-65535，看看哪些端口真的需要暴露。大部分情况下，除了80和443，其他都该关掉或者限制来源IP。第二步，对所有HTTP服务强制加一层认证，哪怕是内网服务。别信"内网安全"那套，攻击者一旦突破边界，内网就是平坦的。第三步，给所有对外端口配WAF或者反向代理，把原始服务藏在后面。Nginx做反代时记得关掉server_tokens，别把版本号暴露出去。

还有个细节：很多人改端口就以为安全了。把SSH从22改到22222，把Tomcat从8080改到8888。这只能防住最蠢的自动化扫描，稍微针对性的扫描器会全端口遍历。改端口不是安全措施，顶多算降低噪音。

最后说一个真实观察。我统计过自己经手的入侵事件，超过六成入口是HTTP类端口上的弱口令或未授权访问。不是0day，不是复杂的提权链，就是端口开着、密码简单、或者压根没密码。安全这件事，把基础动作做到位，就能挡住绝大多数麻烦。那些花哨的攻击手法，留给真正被盯上的目标。普通业务，先把8080端口的admin/123456改掉再说。