上周帮朋友排查一台被勒索病毒加密的服务器登录上去第一眼人就麻了3306、6379、3389全暴露在公网防火墙几乎等于白纸数据库配置文件里还写着明文密码。其实这几年见过太多类似的案例——大部分被拿下的服务器靠的根本不是哪个罕见0day而是端口开着、密码还弱攻击者光明正大走进来的。今天这篇“常见端口以及脆弱点”就是想跟各位一起把服务器上的这些门挨个摸一遍哪些门不该开哪些门开着等于裸奔哪些门就算开也得加几把锁。这篇内容适合三类人一是刚接触服务器、被“端口”这个概念绕晕的新手二是负责运维和交付、经常要做安全自查的工程师三是做等保整改、资产盘点时被要求“关闭高危端口”却不知从何下手的同学。我把这些年在实际项目里踩过的坑、扫过的端口、堵过的洞都摊开来讲配合可以直接复制的命令尽量让每个人看完就能动手查自己那台机器。1. 端口到底是什么先建立一张“暴露面”地图1.1 三类端口号从0到65535的分配规则端口这个概念本质上是传输层的“门牌号”。一台服务器的IP地址相当于小区位置而端口就是单元楼里具体的房间号。网络数据包到了IP层面后还要根据端口号找到对应的进程把数据交到它手里。所以端口不是一个物理接口而是一个逻辑编号范围从0到65535一共65536个。常规分类是0到1023是知名端口基本由系统服务或公认协议占用比如80给HTTP、443给HTTPS、22给SSH1024到49151是注册端口很多商业软件、数据库、中间件默认落在这一段比如3306是MySQL、6379是Redis、8080是常见Web代理或管理后台49152到65535是动态端口一般由客户端程序临时申请用来接收响应数据。理解这个分类有个实际好处排查服务器时看到监听端口在1到1023区间大概率是核心系统服务要谨慎处理看到3306、8089这种注册端口多半是某个应用或数据库如果发现大量动态端口对外监听那就要警惕是不是有木马或异常程序在连外。很多攻击者的后门就喜欢随机挑一个高端口监听藏在一堆端口里不显眼。1.2 端口与服务的关系一次扫描现场我在做内网资产盘点时第一步永远是先看这台机器当前监听哪些端口。Linux上最常用的两条命令ss -tlnp这条命令会列出所有正在监听的TCP端口-l表示只看监听状态-n不做域名解析-p显示对应的进程名和PID。如果没有ss可以用老牌命令netstat -tlnp比如有一次扫描一台刚交付的测试服务器输出里面同时出现了0.0.0.0:6379和0.0.0.0:3306。当时第一反应就是“兄弟裸奔啊”。0.0.0.0的意思是监听所有网卡包括公网口外部任意IP都能尝试连接。如果这里写的是127.0.0.1那说明服务只在本机回环接口上监听外部根本摸不到。所以“看端口”真正的核心不是看数字本身而是看三件事端口有没有监听、监听在哪个地址上、对应的是哪个进程。这三个信息拼起来才是一张完整的暴露面地图。2. 高危端口与脆弱点清单这些口子必须重点盯防2.1 最常见的“老牌冤家”FTP、SSH、Telnet、SMB21端口对应FTP老牌文件传输协议。脆弱点很直白一是本身明文传输账号密码和数据包在网络上裸奔抓包就能看到二是有大量设备默认开了匿名访问或者用弱口令三是老版本Linux自带的vsftpd曾出过后门型漏洞。我在项目里见过不少客户因为图方便把整个网站根目录通过FTP开放给外包人员密码还写在群公告里这种口子基本等于不设防。22端口是SSHLinux远程管理的主通道。风险不在协议本身而在暴露面太大。对公网开放的SSH几乎每小时都会收到来自扫描器的大规模弱口令爆破。如果还允许root直接登录、密码又简单拿到服务器权限只是时间问题。23端口是Telnet所有数据包括密码都是明文早该退出历史舞台但很多网络设备、老式工控系统仍在用。135、137、138、139、445这几个端口放在一起说因为它们都和Windows环境下的NetBIOS、SMB服务相关。135是RPC端口曾出现过大量远程代码执行漏洞139和445是文件共享端口2017年爆发的WannaCry勒索就是通过445端口在局域网内横向传播利用的是MS17-010漏洞。今天哪怕补丁都更新了企业内网里依然不断有老机器开着445遭勒索。Windows环境下如果确实不需要文件共享建议把这些端口全部从边界防火墙上封掉。2.2 数据库与中间件端口从3306到6379的教训数据库端口永远是攻击者的重点目标因为数据价值最直接。1433是SQL Server1521是Oracle3306是MySQL5432是PostgreSQL6379是Redis。这些端口一旦对公网开放接下来就是一轮接一轮的弱口令爆破。MySQL的3306端口我见过太多翻车现场。有开发图省事把数据库绑定到0.0.0.0root密码设为root或者空密码结果就是数据库被删、被锁库要比特币。其实MySQL默认安装后通常只监听127.0.0.1但有些云镜像、一键安装包会把它改成全网监听装完一定要检查。Redis的6379端口更是重灾区。Redis早期版本如果没设密码、以默认配置启动会直接监听所有网卡攻击者用一条命令就能把数据全部写入磁盘再通过cron计划任务、SSH公钥等方式反打服务器。直到今天我在公网上随便扫描都还能扫到一堆无认证的Redis。任何未授权访问漏洞影响的都不是“服务挂了”而是整台主机沦陷。这里给一张我平时整理的高危端口速查表方便大家拿着去对照检查端口常见服务主要脆弱点一旦被利用的影响21FTP明文传输、匿名/弱口令文件泄露、网站被篡改22SSH弱口令爆破、旧版本漏洞主机被远程控制23Telnet完全明文传输口令泄露、设备被控25SMTP开放中继、用户枚举被用来发垃圾邮件53DNS区域传送、缓存投毒域名解析被劫持135RPC远程调用漏洞远程代码执行139/445NetBIOS/SMBSMB漏洞、共享目录暴露勒索病毒横向扩散1433SQL Server弱口令、存储过程滥用数据库被拖库1521OracleTNS协议漏洞、弱口令数据库受控3306MySQL/MariaDB弱口令、权限过大数据泄露、被锁库3389RDP爆破、高危漏洞整机被远程接管5432PostgreSQL弱口令、默认配置数据被下载6379Redis未授权访问、无认证写文件反打主机9200Elasticsearch未授权访问全量数据泄露11211Memcached未授权、UDP放大被用于DDoS反射27017MongoDB未授权访问数据库被删除、勒索2375Docker Remote API未授权管理接口容器逃逸、宿主机沦陷2.3 容易被忽视的“新晋”高危端口传统高危端口被反复强调之后很多团队部署时会刻意改端口或者用防火墙封掉。但攻击者也会跟着时代走把目光转向那些“看起来是业务端口、实则是管理入口”的口子。8080和8081是最典型的例子。很多Web管理后台、API网关、开发调试服务默认跑在这两个端口比如Nginx代理管理页、Jenkins、Spring Boot内置的Tomcat。Jenkins默认监听8080后台如果弱口令或者开启了未授权访问攻击者可以在“系统管理-脚本命令行”里直接执行系统命令一条RCE就出来了。8089这个端口我单独提一下因为热搜里也反复出现。Splunk的默认管理端口是8089HBase的REST API服务常用8080或8085系列端口。这类数据平台端口一旦暴露通常携带大量业务数据且运维人员容易因为“这是内部系统”而忽略认证加固。还有5000端口Python Flask框架的默认端口同时很多工具平台默认落在5000比如MLflow的默认Web界面是5000端口。这类平台往往能读取模型、数据集甚至执行训练任务一旦没有访问控制信息泄露风险和进一步利用风险都不低。Docker的2375端口更要命它提供的是无认证的Remote API攻击者连上去可以直接创建容器并挂载宿主机目录我把这种暴露形容成“把服务器钥匙挂在门口”。2.4 端口开放不等于漏洞脆弱点藏在哪很多人有个误区看到大量端口开放就以为“漏洞多”。其实严格来说端口开放只是一个入口状态真正的脆弱点藏在三个层面。第一是服务漏洞。比如老版本OpenSSH、Apache Struts、WebLogic这些是组件自身存在可利用的RCE漏洞跟端口本身无关但端口是漏洞被触发的通道。第二是配置漏洞比如Redis无认证、MySQL允许root远程登录、Elasticsearch没有鉴权这些属于部署时的配置失误。第三是逻辑漏洞比如管理后台暴露在公网、重置密码接口没有频率限制、API未做鉴权等。安全排查时要记住关端口只是“收敛暴露面”把门关小一点真正的安全还得靠“关掉不该开的服务给该开的服务上好认证及时打补丁”。单靠改端口号来躲扫描属于典型的掩耳盗铃扫描器用全端口扫描照样能找到。3. 攻击者怎么“摸”你的端口探测手法还原3.1 端口扫描的基本原理要理解脆弱点就得先知道攻击者是怎么发现你开着哪些端口的。绝大多数扫描行为是在本机发送特定数据包到目标主机的某个端口然后根据返回的响应判断端口状态。TCP协议下常见的扫描方式有全连接扫描和半开扫描。全连接扫描会完整走完三次握手发送SYN、收到SYN-ACK、再回ACK如果握手成功说明端口是开放的收到RST包说明端口关闭。半开扫描只发送SYN收到SYN-ACK就判断端口开放然后不等三次握手完成直接发RST断开所以不会在目标机器上留下完整的连接日志隐蔽性更强。UDP扫描则是发送一个UDP数据包到目标端口如果收到ICMP端口不可达说明端口关闭如果没有任何回应大概率端口是开放的或者中间有防火墙做了静默丢弃。UDP扫描可靠性差速度慢这是为什么很多UDP服务被忽略但UDP端口一旦开放且存在放大漏洞比如Memcached 11211端口危害会非常大。3.2 nmap实战命令参考Nmap是端口扫描绕不开的工具我在工作里几乎天天用。抛开图形界面不谈命令行模式下这几条最常用# 快速扫描一个IP的常见端口 nmap 192.168.1.10 # 指定端口范围适合查那些不在默认列表里的服务 nmap -p 1-10000 192.168.1.10 # 服务版本探测扫完能识别具体服务名和版本号 nmap -sV 192.168.1.10 # 操作系统识别 nmap -O 192.168.1.10 # UDP端口扫描注意速度很慢 nmap -sU -p 53,123,161 192.168.1.10 # 针对特定端口做高效探活 nmap -p 3306 192.168.1.10实际排查时我建议第一步先用全端口扫描找到所有开放端口第二步用-sV精确识别服务和版本第三步针对高危端口做重点探活。比如先跑一条nmap -p- 192.168.1.10全端口65536个全扫通常需要几分钟然后再收缩范围。除了Nmap日常测试端口连通性更轻量的工具是telnet和nc。命令行下输入telnet 192.168.1.10 3306如果连接成功终端会停留在连接状态甚至有服务端返回的banner信息如果失败会提示无法连接。nc的用法类似nc -zv 192.168.1.10 3306-z表示不做数据交互只测试端口-v输出详细信息。我习惯把telnet当成“一看就知道通不通”的验证工具尤其是在排查防火墙规则是否生效时特别直观。3.3 从端口到利用一张攻击链光知道“端口开了”还不够攻击者的思路是先发现端口再识别服务然后匹配漏洞或弱口令最后尝试利用。我拿Redis未授权访问这条链路举例不是为了教攻击而是希望防御方知道自己的软肋在哪。假设攻击者扫到一个公网IP的6379端口开放接着用客户端尝试连接发现服务器返回了Redis的版本banner而且执行INFO命令不需要认证。这时候对攻击者来说这台服务器已经算是半只脚踏进去了——他可以把Redis数据通过CONFIG SET dir和CONFIG SET dbfilename两个配置命令把备份目录指向SSH的authorized_keys文件所在目录再写入自己生成的公钥内容下一把就能直接用SSH登录这台机器。这条链路里脆弱点不是“6379端口开放”这一个动作而是三个叠加第一Redis监听地址绑到了所有网卡第二没开启保护模式和认证第三进程运行在一个有权限写SSH配置的账号下。任何一层堵住了攻击都很难推进。所以我在做安全加固时从来不做“关掉端口”这种单点动作而是顺着攻击链把每一层都补一下。4. 端口加固实操把暴露面收窄到最小4.1 Linux与Windows的端口排查与关闭先说你自己的机器管理好本机端口是一切加固的基础。Linux下我首推ss和lsof# 查看所有监听TCP端口 ss -tlnp # 查看某个端口被哪个进程占用 lsof -i:6379 # 如果进程确认可以停直接杀掉 kill -9 12345Windows下则用netstat -ano | findstr :8080输出最后一列是PID然后在任务管理器里找到该PID对应的进程确认后结束。如果要关闭Windows自带的21端口也就是FTP服务可以在“程序和功能”里卸载FTP服务也可以用防火墙直接封端口netsh advfirewall firewall add rule nameBlock FTP dirin actionblock protocolTCP localport21这条命令的作用是添加一条入站阻止规则效果是21端口完全对外不可访问。Linux下关闭端口本质上就是停掉占用该端口的服务。比如服务器上跑着没用的vsftpd占着21端口直接systemctl stop vsftpd systemctl disable vsftpddisable是为了防止开机自启。很多运维只停服务不设disable结果服务器一重启服务全部恢复端口又开了这是我在现场反复见过的问题。4.2 防火墙配置从CentOS到麒麟系统CentOS 7及以上用的是firewalld很多人在上面栽过跟头因为CentOS 6时代的iptables命令在这里默认不生效。先看当前状态和开放的端口systemctl status firewalld firewall-cmd --list-all开放某个TCP端口firewall-cmd --permanent --add-port80/tcp firewall-cmd --reload这里很容易犯一个错不加--permanent的话规则只在当前会话生效一重启就没了。我至少三次遇到客户反馈“我明明开放了端口怎么重启又不行了”检查后发现全是忘了加--permanent。如果要把3306端口只对192.168.1.0/24网段开放也就是热搜里那个“添加3306端口白名单为192.168.1段内全部ip”的需求正确的追加写法是firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address192.168.1.0/24 port protocoltcp port3306 accept firewall-cmd --reload这样外部其他网段连3306都会被拒绝而内网192.168.1.0/24可以正常访问。如果还想更进一步可以在配置里再加一条DROPT规则把其他来源的包全部丢到黑洞。注意rich rule的优先级高于普通端口开放规则所以如果之前执行过--add-port3306/tcp还需先移除它不然等于白加白名单firewall-cmd --permanent --remove-port3306/tcp firewall-cmd --reload如果用的是老一点的系统、更习惯iptables也可以直接用iptables命令实现同样的效果iptables -A INPUT -p tcp --dport 3306 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 3306 -j DROP麒麟系统的安全加固命令和CentOS系列基本同源因为两者都是基于RPM系的内核和工具链。关闭137和139端口核心就是禁用Samba服务和NetBIOS相关服务systemctl stop smbd nmbd systemctl disable smbd nmbd然后在防火墙层移除samba放行firewall-cmd --permanent --remove-servicesamba firewall-cmd --reload做完再查一遍ss -tlnp确保137、139、445端口都不再监听。这里有个细节有些系统里137/139是独立于smbd的nmbd进程只停smbd不动nmbd端口照样开着所以两个服务一定要一起处理。4.3 服务端口的监听地址与认证加固防火墙管住网络层之后还要从服务自身下手。最核心的一条原则服务能只监听内网就绝不监听公网能只监听本机就绝不监听所有网卡。拿MySQL举例在配置文件/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf里找到bind-address 127.0.0.1改完之后重启systemctl restart mysqld这样即使防火墙规则出问题外部也无法直连数据库。同理Redis的配置文件redis.conf里bind 127.0.0.1 protected-mode yes requirepass 强密码三个配置缺一不可。网上有些教程教人只设置requirepass但如果protected-mode被设成no密码又弱的话依然很容易被暴力破解。SSH端口的加固思路是双管齐下一是修改/etc/ssh/sshd_config里的Port 22改成其他高位端口降低被自动化扫描器盯上的概率二是禁止root直接登录把PermitRootLogin yes改为no日常运维用普通用户加sudo。修改SSH端口要记得同步处理SELinux和防火墙否则很容易出现“配置改了、服务重启了、人连不上了”的翻车现场semanage port -a -t ssh_port_t -p tcp 2222 firewall-cmd --permanent --add-port2222/tcp firewall-cmd --reload systemctl restart sshd4.4 容器场景下的端口管理现在容器化部署越来越普遍Docker带来的端口暴露问题比传统虚拟机更隐蔽。最常见的一条命令docker run -d -p 8080:80 nginx这里的-p 8080:80表示把宿主机的8080端口映射到容器的80端口宿主机所有网卡上的8080都会被监听。我在排查过好几个“服务器被入侵”的现场后发现很多团队把容器当成黑盒根本不清楚容器映射了哪些端口。如果业务只需要本机访问容器应该改成监听回环地址docker run -d -p 127.0.0.1:8080:80 nginx检查当前所有容器端口映射docker ps docker port 容器IDDocker守护进程本身的安全也不能忽视。2375端口默认是对外提供远程API的——如果绑到了所有网卡且没有TLS认证攻击者连上来直接“接管”宿主机。生产环境如果确实需要远程管理Docker一定要启用TLS证书校验不要裸奔暴露2375。5. 端口故障排查与运维自查手册5.1 端口被占用的快速定位与处理日常运维中遇到最多的问题不是安全攻防而是“端口被占”。最常见的是启动服务时报错Address already in use翻译过来就是你想用的端口已经被别的进程占了。Linux下我一般用两个命令来回查ss -tlnp | grep 8080 lsof -i:8080找到PID之后先确认这个进程是什么。有一种情况是同一个服务重复启动了多个实例这种情况应该把多余的实例杀掉然后重启主服务还有一种情况是某个残留进程一直占着端口确认可以杀掉后kill -9 PIDWindows下面搜索8080被谁占用的流程是命令行敲netstat -ano | findstr :8080 tasklist | findstr PIDtasklist用于查看PID对应的程序名。比如查到是java.exe占用接着用taskkill /PID 1234 /F这里有个小坑Windows下很多程序实际监听的是0.0.0.0:8080但netstat输出里会同时显示IPv4和IPv6的监听条目同一个端口可能显示两行。处理时不要只看一条要确认所有监听该端口的进程都被处理干净。如果你在用HBuilderX这类开发工具遇到端口冲突比如内置服务器默认端口被占不一定要去杀进程——在工具设置或项目配置文件里改掉监听端口反而更省事。关键是先定位是谁占了端口再去选择“杀掉它”还是“让我自己绕开它”。5.2 端口不通的排查顺序端口不通是另一个高频问题明明服务启动了局域网其他机器就是连不上。我排障时基本按四个层面来查。第一层确认服务真的在监听。在服务器本机执行ss -tlnp | grep 3306如果输出里监听地址是127.0.0.1那就别查防火墙了问题大概率是服务只绑了本机回环外部本来就不可能连上。第二层确认防火墙没挡。先看firewalld是否在运行firewall-cmd --state如果开着再查端口是否放行firewall-cmd --list-all如果规则里没有3306就按前面提到的方法添加放行规则。第三层确认云平台安全组。很多云服务器的防火墙在系统外还有一层安全组规则特别是阿里云、腾讯云、华为云安全组里没放行端口的话系统内无论怎么配firewalld都是白搭。这一层极其容易被忽略我在帮客户排查时至少有一半的“端口不通”最终都指向安全组没放行。第四层确认目标机器的本地网络隔离。比如公司网络里有没有VLAN隔离、是否启用了ipset黑名单策略这些因素也会导致端口不通。用ping验证主机通不代表端口通因为ping走的是ICMP协议和TCP端口连通性没有直接关系。命令行探活性测试我习惯这样操作# Windows下测试某个TCP端口是否通 telnet 192.168.1.10 3306 # Linux下用nc测试更轻量 nc -zv 192.168.1.10 3306很多Windows新版本默认没有安装telnet客户端会提示“telnet不是内部或外部命令”这时可以在“启用或关闭Windows功能”里勾选Telnet客户端或者直接用PowerShell的Test-NetConnectionTest-NetConnection 192.168.1.10 -Port 33065.3 端口扫描结果“假象”的识别做过几次端口扫描之后你会发现扫描结果不总是准确。最常见的假象有两种一是防火墙干扰二是服务只监听在IPv6地址上。防火墙会对扫描工具的探测包做“静默丢弃”这时Nmap会认为端口被过滤了跟“关闭”无法区分。比如你用nmap -sS扫一台配置了默认DROP策略的主机即使服务正常运行扫描结果也会显示所有端口都是filtered。这种情况下要结合业务实际情况判断而不是简单认为“扫不出来就是安全”。另一种情况是服务绑定了IPv6地址。很多新版本的系统默认把服务监听在::也就是IPv6的任意地址。你用传统的IPv4扫描可能一无所获但用IPv6地址连接却能通。排查时用ss -tlnp看到的监听地址如果带有::前缀就要注意了这代表服务也在IPv6环境下对外可访问。还有一类假象来自负载均衡和反代。比如你扫描一个公网IP的80端口实际上这个IP背后是LB集群真正提供业务的服务器并没有直接从公网暴露端口。这种架构能有效隐藏后端节点但也意味着一旦LB配置失误后端端口可能意外暴露。5.4 端口安全自查清单我把日常巡检和上线前的自查整理成一张清单照着走一遍大部分端口层面的低级问题都能拦住。检查项方法合格标准本机开放端口一览ss -tlnp无未知端口监听所有监听端口有对应负责人公网高危端口用nmap扫公网IP22、3306、6379、3389等未对公网开放数据库监听地址查看数据库配置文件非本机回环地址时必须有防火墙白名单防火墙默认策略firewall-cmd --list-all非业务端口不开放公网端口前置安全组放行容器端口映射docker ps无0.0.0.0监听的非必要端口管理后台暴露搜索8080、8089、5000等生产环境管理后台不直接对公网开放SSH登录方式查看sshd_config禁root密码登录启用密钥或零信任这里想强调一个细节安全自查最忌讳“查一次就不管了”。服务是动态的今天关掉的端口明天一个服务重启可能又回来了今天没暴露的端口后天加了个中间件又开了。所以巡检要形成周期习惯至少每月做一次端口全景扫描并且把扫描结果和上一轮比对。我们团队的做法是把端口清单放进资产系统里每轮扫描自动拉取监听列表比对出新增、变动项后立即走确认流程。前面提到的打印机“端口连接错误”、COM口插上不显示这类问题虽然和网络安全端口不是一个概念但它背后暴露的是同一类问题端口是“连接”和“入口”的代名词无论是网络端口还是物理接口都需要我们搞清楚它对应什么设备、工作在什么状态、为什么会从“通”变成“不通”。排查的思路是通用的先看物理连接、再看驱动状态、再看软件配置一层层排除。我在实际项目里体会最深的不是哪个扫描工具多厉害也不是哪条防火墙规则多复杂而是“暴露面管理”这四个字。端口就是暴露面的最小单元把每个端口背后对应的服务、账号、权限、网络边界都搞清楚系统的安全感会提升一大截。最后分享一个我坚持了很多年的小习惯每次上线新服务前强制自己先回答三个问题——这个服务需要对外吗如果不需要能不能只监听内网如果必须对外有没有做到认证白名单日志监控同时跟上想清楚这三个问题再配合定期巡检端口这条防线基本就不会出大乱子。
常见高危端口及脆弱点详解：从暴露面到安全加固实践
上周帮朋友排查一台被勒索病毒加密的服务器登录上去第一眼人就麻了3306、6379、3389全暴露在公网防火墙几乎等于白纸数据库配置文件里还写着明文密码。其实这几年见过太多类似的案例——大部分被拿下的服务器靠的根本不是哪个罕见0day而是端口开着、密码还弱攻击者光明正大走进来的。今天这篇“常见端口以及脆弱点”就是想跟各位一起把服务器上的这些门挨个摸一遍哪些门不该开哪些门开着等于裸奔哪些门就算开也得加几把锁。这篇内容适合三类人一是刚接触服务器、被“端口”这个概念绕晕的新手二是负责运维和交付、经常要做安全自查的工程师三是做等保整改、资产盘点时被要求“关闭高危端口”却不知从何下手的同学。我把这些年在实际项目里踩过的坑、扫过的端口、堵过的洞都摊开来讲配合可以直接复制的命令尽量让每个人看完就能动手查自己那台机器。1. 端口到底是什么先建立一张“暴露面”地图1.1 三类端口号从0到65535的分配规则端口这个概念本质上是传输层的“门牌号”。一台服务器的IP地址相当于小区位置而端口就是单元楼里具体的房间号。网络数据包到了IP层面后还要根据端口号找到对应的进程把数据交到它手里。所以端口不是一个物理接口而是一个逻辑编号范围从0到65535一共65536个。常规分类是0到1023是知名端口基本由系统服务或公认协议占用比如80给HTTP、443给HTTPS、22给SSH1024到49151是注册端口很多商业软件、数据库、中间件默认落在这一段比如3306是MySQL、6379是Redis、8080是常见Web代理或管理后台49152到65535是动态端口一般由客户端程序临时申请用来接收响应数据。理解这个分类有个实际好处排查服务器时看到监听端口在1到1023区间大概率是核心系统服务要谨慎处理看到3306、8089这种注册端口多半是某个应用或数据库如果发现大量动态端口对外监听那就要警惕是不是有木马或异常程序在连外。很多攻击者的后门就喜欢随机挑一个高端口监听藏在一堆端口里不显眼。1.2 端口与服务的关系一次扫描现场我在做内网资产盘点时第一步永远是先看这台机器当前监听哪些端口。Linux上最常用的两条命令ss -tlnp这条命令会列出所有正在监听的TCP端口-l表示只看监听状态-n不做域名解析-p显示对应的进程名和PID。如果没有ss可以用老牌命令netstat -tlnp比如有一次扫描一台刚交付的测试服务器输出里面同时出现了0.0.0.0:6379和0.0.0.0:3306。当时第一反应就是“兄弟裸奔啊”。0.0.0.0的意思是监听所有网卡包括公网口外部任意IP都能尝试连接。如果这里写的是127.0.0.1那说明服务只在本机回环接口上监听外部根本摸不到。所以“看端口”真正的核心不是看数字本身而是看三件事端口有没有监听、监听在哪个地址上、对应的是哪个进程。这三个信息拼起来才是一张完整的暴露面地图。2. 高危端口与脆弱点清单这些口子必须重点盯防2.1 最常见的“老牌冤家”FTP、SSH、Telnet、SMB21端口对应FTP老牌文件传输协议。脆弱点很直白一是本身明文传输账号密码和数据包在网络上裸奔抓包就能看到二是有大量设备默认开了匿名访问或者用弱口令三是老版本Linux自带的vsftpd曾出过后门型漏洞。我在项目里见过不少客户因为图方便把整个网站根目录通过FTP开放给外包人员密码还写在群公告里这种口子基本等于不设防。22端口是SSHLinux远程管理的主通道。风险不在协议本身而在暴露面太大。对公网开放的SSH几乎每小时都会收到来自扫描器的大规模弱口令爆破。如果还允许root直接登录、密码又简单拿到服务器权限只是时间问题。23端口是Telnet所有数据包括密码都是明文早该退出历史舞台但很多网络设备、老式工控系统仍在用。135、137、138、139、445这几个端口放在一起说因为它们都和Windows环境下的NetBIOS、SMB服务相关。135是RPC端口曾出现过大量远程代码执行漏洞139和445是文件共享端口2017年爆发的WannaCry勒索就是通过445端口在局域网内横向传播利用的是MS17-010漏洞。今天哪怕补丁都更新了企业内网里依然不断有老机器开着445遭勒索。Windows环境下如果确实不需要文件共享建议把这些端口全部从边界防火墙上封掉。2.2 数据库与中间件端口从3306到6379的教训数据库端口永远是攻击者的重点目标因为数据价值最直接。1433是SQL Server1521是Oracle3306是MySQL5432是PostgreSQL6379是Redis。这些端口一旦对公网开放接下来就是一轮接一轮的弱口令爆破。MySQL的3306端口我见过太多翻车现场。有开发图省事把数据库绑定到0.0.0.0root密码设为root或者空密码结果就是数据库被删、被锁库要比特币。其实MySQL默认安装后通常只监听127.0.0.1但有些云镜像、一键安装包会把它改成全网监听装完一定要检查。Redis的6379端口更是重灾区。Redis早期版本如果没设密码、以默认配置启动会直接监听所有网卡攻击者用一条命令就能把数据全部写入磁盘再通过cron计划任务、SSH公钥等方式反打服务器。直到今天我在公网上随便扫描都还能扫到一堆无认证的Redis。任何未授权访问漏洞影响的都不是“服务挂了”而是整台主机沦陷。这里给一张我平时整理的高危端口速查表方便大家拿着去对照检查端口常见服务主要脆弱点一旦被利用的影响21FTP明文传输、匿名/弱口令文件泄露、网站被篡改22SSH弱口令爆破、旧版本漏洞主机被远程控制23Telnet完全明文传输口令泄露、设备被控25SMTP开放中继、用户枚举被用来发垃圾邮件53DNS区域传送、缓存投毒域名解析被劫持135RPC远程调用漏洞远程代码执行139/445NetBIOS/SMBSMB漏洞、共享目录暴露勒索病毒横向扩散1433SQL Server弱口令、存储过程滥用数据库被拖库1521OracleTNS协议漏洞、弱口令数据库受控3306MySQL/MariaDB弱口令、权限过大数据泄露、被锁库3389RDP爆破、高危漏洞整机被远程接管5432PostgreSQL弱口令、默认配置数据被下载6379Redis未授权访问、无认证写文件反打主机9200Elasticsearch未授权访问全量数据泄露11211Memcached未授权、UDP放大被用于DDoS反射27017MongoDB未授权访问数据库被删除、勒索2375Docker Remote API未授权管理接口容器逃逸、宿主机沦陷2.3 容易被忽视的“新晋”高危端口传统高危端口被反复强调之后很多团队部署时会刻意改端口或者用防火墙封掉。但攻击者也会跟着时代走把目光转向那些“看起来是业务端口、实则是管理入口”的口子。8080和8081是最典型的例子。很多Web管理后台、API网关、开发调试服务默认跑在这两个端口比如Nginx代理管理页、Jenkins、Spring Boot内置的Tomcat。Jenkins默认监听8080后台如果弱口令或者开启了未授权访问攻击者可以在“系统管理-脚本命令行”里直接执行系统命令一条RCE就出来了。8089这个端口我单独提一下因为热搜里也反复出现。Splunk的默认管理端口是8089HBase的REST API服务常用8080或8085系列端口。这类数据平台端口一旦暴露通常携带大量业务数据且运维人员容易因为“这是内部系统”而忽略认证加固。还有5000端口Python Flask框架的默认端口同时很多工具平台默认落在5000比如MLflow的默认Web界面是5000端口。这类平台往往能读取模型、数据集甚至执行训练任务一旦没有访问控制信息泄露风险和进一步利用风险都不低。Docker的2375端口更要命它提供的是无认证的Remote API攻击者连上去可以直接创建容器并挂载宿主机目录我把这种暴露形容成“把服务器钥匙挂在门口”。2.4 端口开放不等于漏洞脆弱点藏在哪很多人有个误区看到大量端口开放就以为“漏洞多”。其实严格来说端口开放只是一个入口状态真正的脆弱点藏在三个层面。第一是服务漏洞。比如老版本OpenSSH、Apache Struts、WebLogic这些是组件自身存在可利用的RCE漏洞跟端口本身无关但端口是漏洞被触发的通道。第二是配置漏洞比如Redis无认证、MySQL允许root远程登录、Elasticsearch没有鉴权这些属于部署时的配置失误。第三是逻辑漏洞比如管理后台暴露在公网、重置密码接口没有频率限制、API未做鉴权等。安全排查时要记住关端口只是“收敛暴露面”把门关小一点真正的安全还得靠“关掉不该开的服务给该开的服务上好认证及时打补丁”。单靠改端口号来躲扫描属于典型的掩耳盗铃扫描器用全端口扫描照样能找到。3. 攻击者怎么“摸”你的端口探测手法还原3.1 端口扫描的基本原理要理解脆弱点就得先知道攻击者是怎么发现你开着哪些端口的。绝大多数扫描行为是在本机发送特定数据包到目标主机的某个端口然后根据返回的响应判断端口状态。TCP协议下常见的扫描方式有全连接扫描和半开扫描。全连接扫描会完整走完三次握手发送SYN、收到SYN-ACK、再回ACK如果握手成功说明端口是开放的收到RST包说明端口关闭。半开扫描只发送SYN收到SYN-ACK就判断端口开放然后不等三次握手完成直接发RST断开所以不会在目标机器上留下完整的连接日志隐蔽性更强。UDP扫描则是发送一个UDP数据包到目标端口如果收到ICMP端口不可达说明端口关闭如果没有任何回应大概率端口是开放的或者中间有防火墙做了静默丢弃。UDP扫描可靠性差速度慢这是为什么很多UDP服务被忽略但UDP端口一旦开放且存在放大漏洞比如Memcached 11211端口危害会非常大。3.2 nmap实战命令参考Nmap是端口扫描绕不开的工具我在工作里几乎天天用。抛开图形界面不谈命令行模式下这几条最常用# 快速扫描一个IP的常见端口 nmap 192.168.1.10 # 指定端口范围适合查那些不在默认列表里的服务 nmap -p 1-10000 192.168.1.10 # 服务版本探测扫完能识别具体服务名和版本号 nmap -sV 192.168.1.10 # 操作系统识别 nmap -O 192.168.1.10 # UDP端口扫描注意速度很慢 nmap -sU -p 53,123,161 192.168.1.10 # 针对特定端口做高效探活 nmap -p 3306 192.168.1.10实际排查时我建议第一步先用全端口扫描找到所有开放端口第二步用-sV精确识别服务和版本第三步针对高危端口做重点探活。比如先跑一条nmap -p- 192.168.1.10全端口65536个全扫通常需要几分钟然后再收缩范围。除了Nmap日常测试端口连通性更轻量的工具是telnet和nc。命令行下输入telnet 192.168.1.10 3306如果连接成功终端会停留在连接状态甚至有服务端返回的banner信息如果失败会提示无法连接。nc的用法类似nc -zv 192.168.1.10 3306-z表示不做数据交互只测试端口-v输出详细信息。我习惯把telnet当成“一看就知道通不通”的验证工具尤其是在排查防火墙规则是否生效时特别直观。3.3 从端口到利用一张攻击链光知道“端口开了”还不够攻击者的思路是先发现端口再识别服务然后匹配漏洞或弱口令最后尝试利用。我拿Redis未授权访问这条链路举例不是为了教攻击而是希望防御方知道自己的软肋在哪。假设攻击者扫到一个公网IP的6379端口开放接着用客户端尝试连接发现服务器返回了Redis的版本banner而且执行INFO命令不需要认证。这时候对攻击者来说这台服务器已经算是半只脚踏进去了——他可以把Redis数据通过CONFIG SET dir和CONFIG SET dbfilename两个配置命令把备份目录指向SSH的authorized_keys文件所在目录再写入自己生成的公钥内容下一把就能直接用SSH登录这台机器。这条链路里脆弱点不是“6379端口开放”这一个动作而是三个叠加第一Redis监听地址绑到了所有网卡第二没开启保护模式和认证第三进程运行在一个有权限写SSH配置的账号下。任何一层堵住了攻击都很难推进。所以我在做安全加固时从来不做“关掉端口”这种单点动作而是顺着攻击链把每一层都补一下。4. 端口加固实操把暴露面收窄到最小4.1 Linux与Windows的端口排查与关闭先说你自己的机器管理好本机端口是一切加固的基础。Linux下我首推ss和lsof# 查看所有监听TCP端口 ss -tlnp # 查看某个端口被哪个进程占用 lsof -i:6379 # 如果进程确认可以停直接杀掉 kill -9 12345Windows下则用netstat -ano | findstr :8080输出最后一列是PID然后在任务管理器里找到该PID对应的进程确认后结束。如果要关闭Windows自带的21端口也就是FTP服务可以在“程序和功能”里卸载FTP服务也可以用防火墙直接封端口netsh advfirewall firewall add rule nameBlock FTP dirin actionblock protocolTCP localport21这条命令的作用是添加一条入站阻止规则效果是21端口完全对外不可访问。Linux下关闭端口本质上就是停掉占用该端口的服务。比如服务器上跑着没用的vsftpd占着21端口直接systemctl stop vsftpd systemctl disable vsftpddisable是为了防止开机自启。很多运维只停服务不设disable结果服务器一重启服务全部恢复端口又开了这是我在现场反复见过的问题。4.2 防火墙配置从CentOS到麒麟系统CentOS 7及以上用的是firewalld很多人在上面栽过跟头因为CentOS 6时代的iptables命令在这里默认不生效。先看当前状态和开放的端口systemctl status firewalld firewall-cmd --list-all开放某个TCP端口firewall-cmd --permanent --add-port80/tcp firewall-cmd --reload这里很容易犯一个错不加--permanent的话规则只在当前会话生效一重启就没了。我至少三次遇到客户反馈“我明明开放了端口怎么重启又不行了”检查后发现全是忘了加--permanent。如果要把3306端口只对192.168.1.0/24网段开放也就是热搜里那个“添加3306端口白名单为192.168.1段内全部ip”的需求正确的追加写法是firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address192.168.1.0/24 port protocoltcp port3306 accept firewall-cmd --reload这样外部其他网段连3306都会被拒绝而内网192.168.1.0/24可以正常访问。如果还想更进一步可以在配置里再加一条DROPT规则把其他来源的包全部丢到黑洞。注意rich rule的优先级高于普通端口开放规则所以如果之前执行过--add-port3306/tcp还需先移除它不然等于白加白名单firewall-cmd --permanent --remove-port3306/tcp firewall-cmd --reload如果用的是老一点的系统、更习惯iptables也可以直接用iptables命令实现同样的效果iptables -A INPUT -p tcp --dport 3306 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 3306 -j DROP麒麟系统的安全加固命令和CentOS系列基本同源因为两者都是基于RPM系的内核和工具链。关闭137和139端口核心就是禁用Samba服务和NetBIOS相关服务systemctl stop smbd nmbd systemctl disable smbd nmbd然后在防火墙层移除samba放行firewall-cmd --permanent --remove-servicesamba firewall-cmd --reload做完再查一遍ss -tlnp确保137、139、445端口都不再监听。这里有个细节有些系统里137/139是独立于smbd的nmbd进程只停smbd不动nmbd端口照样开着所以两个服务一定要一起处理。4.3 服务端口的监听地址与认证加固防火墙管住网络层之后还要从服务自身下手。最核心的一条原则服务能只监听内网就绝不监听公网能只监听本机就绝不监听所有网卡。拿MySQL举例在配置文件/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf里找到bind-address 127.0.0.1改完之后重启systemctl restart mysqld这样即使防火墙规则出问题外部也无法直连数据库。同理Redis的配置文件redis.conf里bind 127.0.0.1 protected-mode yes requirepass 强密码三个配置缺一不可。网上有些教程教人只设置requirepass但如果protected-mode被设成no密码又弱的话依然很容易被暴力破解。SSH端口的加固思路是双管齐下一是修改/etc/ssh/sshd_config里的Port 22改成其他高位端口降低被自动化扫描器盯上的概率二是禁止root直接登录把PermitRootLogin yes改为no日常运维用普通用户加sudo。修改SSH端口要记得同步处理SELinux和防火墙否则很容易出现“配置改了、服务重启了、人连不上了”的翻车现场semanage port -a -t ssh_port_t -p tcp 2222 firewall-cmd --permanent --add-port2222/tcp firewall-cmd --reload systemctl restart sshd4.4 容器场景下的端口管理现在容器化部署越来越普遍Docker带来的端口暴露问题比传统虚拟机更隐蔽。最常见的一条命令docker run -d -p 8080:80 nginx这里的-p 8080:80表示把宿主机的8080端口映射到容器的80端口宿主机所有网卡上的8080都会被监听。我在排查过好几个“服务器被入侵”的现场后发现很多团队把容器当成黑盒根本不清楚容器映射了哪些端口。如果业务只需要本机访问容器应该改成监听回环地址docker run -d -p 127.0.0.1:8080:80 nginx检查当前所有容器端口映射docker ps docker port 容器IDDocker守护进程本身的安全也不能忽视。2375端口默认是对外提供远程API的——如果绑到了所有网卡且没有TLS认证攻击者连上来直接“接管”宿主机。生产环境如果确实需要远程管理Docker一定要启用TLS证书校验不要裸奔暴露2375。5. 端口故障排查与运维自查手册5.1 端口被占用的快速定位与处理日常运维中遇到最多的问题不是安全攻防而是“端口被占”。最常见的是启动服务时报错Address already in use翻译过来就是你想用的端口已经被别的进程占了。Linux下我一般用两个命令来回查ss -tlnp | grep 8080 lsof -i:8080找到PID之后先确认这个进程是什么。有一种情况是同一个服务重复启动了多个实例这种情况应该把多余的实例杀掉然后重启主服务还有一种情况是某个残留进程一直占着端口确认可以杀掉后kill -9 PIDWindows下面搜索8080被谁占用的流程是命令行敲netstat -ano | findstr :8080 tasklist | findstr PIDtasklist用于查看PID对应的程序名。比如查到是java.exe占用接着用taskkill /PID 1234 /F这里有个小坑Windows下很多程序实际监听的是0.0.0.0:8080但netstat输出里会同时显示IPv4和IPv6的监听条目同一个端口可能显示两行。处理时不要只看一条要确认所有监听该端口的进程都被处理干净。如果你在用HBuilderX这类开发工具遇到端口冲突比如内置服务器默认端口被占不一定要去杀进程——在工具设置或项目配置文件里改掉监听端口反而更省事。关键是先定位是谁占了端口再去选择“杀掉它”还是“让我自己绕开它”。5.2 端口不通的排查顺序端口不通是另一个高频问题明明服务启动了局域网其他机器就是连不上。我排障时基本按四个层面来查。第一层确认服务真的在监听。在服务器本机执行ss -tlnp | grep 3306如果输出里监听地址是127.0.0.1那就别查防火墙了问题大概率是服务只绑了本机回环外部本来就不可能连上。第二层确认防火墙没挡。先看firewalld是否在运行firewall-cmd --state如果开着再查端口是否放行firewall-cmd --list-all如果规则里没有3306就按前面提到的方法添加放行规则。第三层确认云平台安全组。很多云服务器的防火墙在系统外还有一层安全组规则特别是阿里云、腾讯云、华为云安全组里没放行端口的话系统内无论怎么配firewalld都是白搭。这一层极其容易被忽略我在帮客户排查时至少有一半的“端口不通”最终都指向安全组没放行。第四层确认目标机器的本地网络隔离。比如公司网络里有没有VLAN隔离、是否启用了ipset黑名单策略这些因素也会导致端口不通。用ping验证主机通不代表端口通因为ping走的是ICMP协议和TCP端口连通性没有直接关系。命令行探活性测试我习惯这样操作# Windows下测试某个TCP端口是否通 telnet 192.168.1.10 3306 # Linux下用nc测试更轻量 nc -zv 192.168.1.10 3306很多Windows新版本默认没有安装telnet客户端会提示“telnet不是内部或外部命令”这时可以在“启用或关闭Windows功能”里勾选Telnet客户端或者直接用PowerShell的Test-NetConnectionTest-NetConnection 192.168.1.10 -Port 33065.3 端口扫描结果“假象”的识别做过几次端口扫描之后你会发现扫描结果不总是准确。最常见的假象有两种一是防火墙干扰二是服务只监听在IPv6地址上。防火墙会对扫描工具的探测包做“静默丢弃”这时Nmap会认为端口被过滤了跟“关闭”无法区分。比如你用nmap -sS扫一台配置了默认DROP策略的主机即使服务正常运行扫描结果也会显示所有端口都是filtered。这种情况下要结合业务实际情况判断而不是简单认为“扫不出来就是安全”。另一种情况是服务绑定了IPv6地址。很多新版本的系统默认把服务监听在::也就是IPv6的任意地址。你用传统的IPv4扫描可能一无所获但用IPv6地址连接却能通。排查时用ss -tlnp看到的监听地址如果带有::前缀就要注意了这代表服务也在IPv6环境下对外可访问。还有一类假象来自负载均衡和反代。比如你扫描一个公网IP的80端口实际上这个IP背后是LB集群真正提供业务的服务器并没有直接从公网暴露端口。这种架构能有效隐藏后端节点但也意味着一旦LB配置失误后端端口可能意外暴露。5.4 端口安全自查清单我把日常巡检和上线前的自查整理成一张清单照着走一遍大部分端口层面的低级问题都能拦住。检查项方法合格标准本机开放端口一览ss -tlnp无未知端口监听所有监听端口有对应负责人公网高危端口用nmap扫公网IP22、3306、6379、3389等未对公网开放数据库监听地址查看数据库配置文件非本机回环地址时必须有防火墙白名单防火墙默认策略firewall-cmd --list-all非业务端口不开放公网端口前置安全组放行容器端口映射docker ps无0.0.0.0监听的非必要端口管理后台暴露搜索8080、8089、5000等生产环境管理后台不直接对公网开放SSH登录方式查看sshd_config禁root密码登录启用密钥或零信任这里想强调一个细节安全自查最忌讳“查一次就不管了”。服务是动态的今天关掉的端口明天一个服务重启可能又回来了今天没暴露的端口后天加了个中间件又开了。所以巡检要形成周期习惯至少每月做一次端口全景扫描并且把扫描结果和上一轮比对。我们团队的做法是把端口清单放进资产系统里每轮扫描自动拉取监听列表比对出新增、变动项后立即走确认流程。前面提到的打印机“端口连接错误”、COM口插上不显示这类问题虽然和网络安全端口不是一个概念但它背后暴露的是同一类问题端口是“连接”和“入口”的代名词无论是网络端口还是物理接口都需要我们搞清楚它对应什么设备、工作在什么状态、为什么会从“通”变成“不通”。排查的思路是通用的先看物理连接、再看驱动状态、再看软件配置一层层排除。我在实际项目里体会最深的不是哪个扫描工具多厉害也不是哪条防火墙规则多复杂而是“暴露面管理”这四个字。端口就是暴露面的最小单元把每个端口背后对应的服务、账号、权限、网络边界都搞清楚系统的安全感会提升一大截。最后分享一个我坚持了很多年的小习惯每次上线新服务前强制自己先回答三个问题——这个服务需要对外吗如果不需要能不能只监听内网如果必须对外有没有做到认证白名单日志监控同时跟上想清楚这三个问题再配合定期巡检端口这条防线基本就不会出大乱子。
