2017年，端口我帮一个做外贸的漏洞利用朋友看服务器。他那台机器跑着Apache，端口80端口对外开放，漏洞利用上面挂了个三年前别人写的端口CMS。我扫了一眼目录结构，漏洞利用顺手试了个文件包含，端口数据库密码直接弹出来了。漏洞利用整个过程不到两分钟。端口他没设WAF，漏洞利用没打补丁，端口甚至连日志都没开。漏洞利用

80端口就是端口HTTP的默认入口。浏览器发请求，漏洞利用服务器应答，端口这条通道永远敞着——除非你手动改配置。很多人不改。改了也未必安全，因为漏洞往往不在端口本身，而在跑在端口后面的那堆东西。

漏洞从哪来

最常见的是Web应用层的注入。SQL注入、命令注入、模板注入，本质都一样：用户输入被当成代码执行了。我见过一个PHP站点，参数直接拼进system()调用，攻击者构造一个?cmd=cat /etc/passwd就能读文件。这种代码写出来就是等着被利用的。

文件上传也是重灾区。前端校验扩展名，后端不校验MIME类型，传个.php.jpg上去，服务器照样解析。更离谱的是有些CMS把上传目录设成可执行，等于把shell直接递给对方。

还有目录遍历。../../这种老掉牙的手法至今有效，因为总有开发者忘了过滤路径参数。去年某国产OA曝出的漏洞就是这路子，构造特定URL能下载任意文件，包括数据库配置。

一次真实的利用链

说个具体案例。某次渗透测试，目标是一台Windows Server 2008，IIS 7.0，80端口跑着ASP.NET应用。先扫目录，发现/backup/没设权限，里面有个web.config.bak。下载下来一看，数据库连接字符串明文写着。连上SQL Server，发现xp_cmdshell没关。直接执行系统命令，加了个管理员账户。从扫描到拿shell，四十分钟。

这条链上每个环节都不新鲜。备份文件不该放Web目录，配置文件不该存明文密码，xp_cmdshell不该开着。三个“不该”凑一起，就是一条完整的攻击路径。

防御不是堆产品

很多人第一反应是上WAF。WAF有用，但规则绕过的方法比规则本身多。编码变形、分块传输、参数污染，随便一种都能让WAF漏掉。真正管用的还是代码层面：参数化查询、输入白名单、最小权限运行。这些东西不花钱，但费事。

另一个误区是改端口。把80改成8080，扫描器确实少扫到，但这不是安全，是隐蔽。Shodan上照样能搜到，而且改端口经常把正常用户挡在外面。我见过一个内部系统改到9443，结果运维自己都记不住，每次要翻文档。

日志得开。不是开了就行，得看。很多入侵在日志里留了明显痕迹——异常的POST请求、半夜的登录、突然增大的响应体。没人看日志，等于没开。

说点实在的

80端口的风险不会消失，因为HTTP协议本身不负责安全。TLS能解决传输层的问题，但应用层的漏洞它管不了。一个存在SQL注入的HTTPS站点，照样能被拖库。

我的习惯是：新接手一台服务器，先nmap扫一遍，再nikto跑一下，然后手动翻目录。这三步能发现大部分低级问题。高级问题得看代码，那又是另一个故事了。

别指望一劳永逸。今天没漏洞不代表明天没有，新CVE每天都在出。保持更新，保持怀疑，保持看日志的习惯。80端口就在那里，谁都能敲。你得知道谁在敲，敲了什么。