几年前的一次应急响应，让我对“高危端口”这四个字有了非常直观的认知。客户反馈一台业务服务器CPU被打满、对外连接异常，登录上去一看，一个陌生的进程占了大半资源，顺着网络连接排查才发现，入口竟然是Redis的6379端口未授权访问。那次之后我做了一次全面的资产自查，结果更是让我后背发凉：一批把MySQL、远程桌面、SSH管理端口直接挂在公网上的设备，密码还都是弱口令。这篇文章就围绕80、443、22、3389、3306、6379这个经典高危端口名单展开，逐个拆解它们各自承载的服务、暴露后的典型风险，以及我这些年实际用下来的自查方法和加固清单。
1. 高危端口为什么高危：先理解攻击者的“门牌号”逻辑
1.1 端口在公网世界中扮演的角色
端口简单理解就是服务器上的“门牌号”。每台服务器都有从0到65535的端口编号，服务进程监听在某个端口上，对外提供能力。别人访问一台服务器时，IP地址找到的是“这栋楼”，端口找到的才是“具体房间”。大部分常见端口都有惯例用途，比如22给SSH、80给HTTP、443给HTTPS、3306给MySQL、6379给Redis。这些惯例是公开的，所以攻击者不需要探测你家门牌，单看IP就知道该去踹哪个门。
很多人有个误区：觉得“我开了防火墙”“我用的是云厂商的默认安全组”，端口就安全了。实际上安全组和防火墙默认动作确实是阻断，但只要你在规则里手动放行了某个端口，且来源地址写得是0.0.0.0/0（也就是全网），那么这条规则就等于把门敞开了，剩下能拦多久完全看运气。
1.2 攻击者眼中的“高价值目标”筛选逻辑
攻击者不会拿个小本本挨个试IP，他们用的是大规模自动化扫描。一次扫描可以同时覆盖几十万个IP地址，而且花不了太多时间；只要探测到目标IP的某个端口是开放的，就自动进入下一轮指纹识别、口令爆破、漏洞尝试。整个流程高度自动化，不存在“我机器小，没人会关注”这种侥幸空间。
在攻击者看来，一个端口值不值得做深度攻击，主要看三个维度：
- 服务普及率：使用量越大，出问题的概率越高，统计意义越大
- 认证强度：默认口令、弱口令、空口令越常见，爆破成本越低
- 攻击后果：拿到的是数据、命令执行权限还是整台主机的控制权，直接决定攻击者的投入产出比
80和443之所以长期霸榜，是因为Web服务数量实在太大；22和3389则是管理通道，攻破后的奖励几乎是整台主机；3306和6379属于数据资产，攻击者一旦拿下，轻则数据被拖走，重则被写进恶意计划任务。这六个端口共同点就是“普遍存在+高价值+容易被自动化攻坚”，所以年年都在高危名单上。
1.3 为什么高风险名单常年稳定
不少人问过我：漏洞每年都在修、系统每年都在升级，为什么高危端口名单还是这几位？答案很现实：修复是在堵漏，但这些端口对应的应用永远在运行。只要SSH还在提供远程登录能力，爆破就一定存在；只要业务还用MySQL，攻击者就一定盯着3306。端口本身只是一个入口，真正影响风险高低的是入口背后服务的默认配置、口令强度、补丁状况和暴露范围。这也是为什么同样的Redis，有的人跑了五年都没事，有的人上线三天就被种了挖矿木马。
2. 六大高危端口逐个拆解：服务特性与风险画像
2.1 80与443：Web服务的双刃剑
80和443分别是HTTP与HTTPS服务端口，绝大多数业务系统、网站、API网关都离不开它们。攻击面大的原因有两个：一是部署量实在太大，二是通过这两个端口进来的请求本身就是业务流量，你很难判断哪个正常、哪个恶意。
通过80/443进来的风险分好几层。最基础的是Web应用漏洞，比如SQL注入、文件上传、反序列化、目录遍历；再往上是中间件和框架漏洞，比如老版本Nginx、Apache、Tomcat、Spring的公开漏洞；还有一层是业务逻辑漏洞，比如验证码可绕过、水平越权、批量查询接口未做频率限制。443因为流量被TLS加密，Web应用防火墙和入侵检测系统看到的内容全是密文，检测难度比80高得多，恶意请求更容易隐蔽通过。
防守上，我个人的经验是：Web端口没法也不应该关，但必须叠防御。公网入口要套WAF或云防火墙做基础过滤；应用层要关掉不需要的功能路由、删除默认页和测试接口；同时日志一定要实现集中存储，因为Web攻击的溯源基本全靠访问日志。还有一点容易被忽略：有些管理后台出于方便，直接挂在80/443路径下且不加访问控制，等于把后台地址公之于众，攻击者花几分钟用目录扫描工具就能摸到登录页。
2.2 22：SSH管理通道的暴力破解压力
22是Linux服务器的标准SSH端口，几乎所有云主机、物理服务器都通过它做远程管理和文件传输。这个端口一旦开放到公网，就相当于把管理员入口放在了门外。攻击者针对22最常见的动作就是暴力破解密码，常见工具会用内置字典做自动化尝试，一天几万次失败登录在暴露到公网的服务器上非常常见。如果账号还是root、密码又是简单的组合，被撞开只是时间问题。
我自己排查过的一台被入侵的Linux服务器，/var/log/secure里刷满了Accepted password记录，攻击者从爆破成功到写入后门只间隔了几分钟。这个案例告诉我们：密码一旦被猜中，攻击者拿到的就是合法登录身份，日志里几乎搜不到什么异常特征。
针对22的加固建议比较成熟：核心是禁用密码登录、改用密钥对认证，同时禁止root直接远程登录。密钥登录在认证强度上远高于口令爆破，只要私钥不泄露，暴力破解基本失效。再加一层保险可以用fail2ban之类的工具做失败次数限制，但要注意——如果网络环境里有合法的批量分发任务或定时同步，频率限制可能会把合法流量误伤，配置时还是得结合自己的运维场景。
2.3 3389：Windows远程桌面的勒索重灾区
3389是Windows远程桌面服务（RDP）的默认端口。Windows Server在云上数量巨大，加上很多管理员习惯直接用管理员账号远程桌面登录，这个端口的危险性在六大端口中排得上号。
针对3389的攻击方式主要有两类。一类是口令爆破，本质和SSH类似，但因为Windows默认管理员账户是Administrator，爆破目标更集中，成功率一旦得手攻击者就拥有完整的桌面控制权，后续关闭杀毒软件、投放勒索程序、横向移动都变得非常方便。另一类是系统漏洞利用，RDP历史上出现过无需认证即可远程利用的高危漏洞，影响Windows 7、Windows Server 2008等旧版本，这类漏洞一旦被武器化，攻击者可以像进自己家一样进入系统。
我对3389的处置经验建议是：生产环境尽量不把远程桌面直接暴露在公网，先通过堡垒机或跳板机中转；如果业务条件不允许，也要在Windows防火墙里限定来源IP白名单，只允许办公网出口或固定IP访问。账号侧务必做三件事——开账户锁定阈值（比如5次失败锁15分钟）、开启网络级别身份验证（NLA）、把本地管理员密码复杂度拉满。尤其是“锁定阈值”，很多Windows服务器没启用这个策略，等于允许攻击者无限次尝试密码。
2.4 3306：数据库端口暴露后的连锁反应
3306是MySQL的默认端口，MariaDB也使用同一端口。数据库端口暴露在公网带来的风险不是“被扫到”这么简单，而是如果连接成功，攻击者可以直接执行SQL语句，读取甚至删除表数据。比起Web端口还要先猜应用漏洞，3306一旦连上就相当于拿到了保险柜钥匙。
常见事故画像有两种。一种是弱口令，root密码为空或root/root这种级别，攻击者用工具扫一圈就能批量进去，然后拖走全库数据；另一种是运维配置问题，比如为了本地开发方便，把MySQL绑定了0.0.0.0，结果忘了给root账号限制来源IP，任何IP都能拿着root身份连上来。
这里要给一个容易踩坑的点：仅仅在MySQL里创建账号并限制host是不够的，网络层不加限制的话，MySQL账号的host限制只能约束登录身份，不能替代防火墙。我在实际检查中，会同时看三处：一是MySQL的my.cnf里bind-address是不是只有内网IP；二是user表里账号的host字段是不是出现了’%’；三是云安全组是否放行了3306到0.0.0.0/0。三处全绿，才敢说3306真正收敛了。
2.5 6379：Redis的未授权访问隐患
Redis是内存数据库，默认端口6379。它性能好、使用简单，常用于缓存、队列、会话存储。但Redis长期有个“名声在外”的隐患：默认配置不强制密码，且老版本默认绑定在所有网卡上。两者叠加，就形成了经典的未授权访问——只要目标6379端口是开放的，攻击者用redis-cli直接连上去，就能执行大量管理命令。
未授权访问最危险的地方在于攻击链可以升级。Redis有能力把数据持久化到文件，攻击者可以利用这个特性，配合Web目录或计划任务，把一段恶意代码写入目标系统的可执行位置，从而从“数据库被黑”升级为“主机失陷”。我在应急响应里遇到的挖矿事件，有一类就是Redis未授权访问写计划任务导致的，整个链路从公网扫描到拿到主机权限，通常只要几分钟。
Redis的加固并不复杂，难的是很多人压根不知道自己的Redis是“裸奔”状态。检查很简单：先用redis-cli -h 127.0.0.1 ping看是不是返回PONG，再执行CONFIG GET requirepass，如果返回结果是空字符串，说明当前完全没有认证。加固时设置强密码、把protected-mode设置为yes、只绑定内网地址、禁用危险命令、避免使用root账号运行redis进程，五件事做完，风险可以降掉九成以上。
2.6 榜单之外的隐蔽高危端口
除了标题里这六个，还有几个端口在实战中也常被利用，做资产自查时值得一并关注：27017（MongoDB）、9200（Elasticsearch）、11211（Memcached）、2181（ZooKeeper）、5432（PostgreSQL）、5601（Kibana）、8080/8888（各类管理后台与API服务）。这些服务的通病相似：要么支持未授权访问，要么默认口令简单，要么管理功能与应用功能混跑。我的建议是不要只看“高危端口列表”，而是把资产里所有对外开放的端口都做成清单，再按服务类型逐个打标。
3. 自查实操：三步摸清自己的暴露面
3.1 资产盘点：先搞清楚自己有哪些门
排查暴露面之前，先得回答一个问题：我都哪些服务器、哪些IP是公网可达的？没有资产清单的排查很容易漏。我在实际操作中先把资产分两类：一类是云主机，去云控制台看每一个弹性公网IP、负载均衡监听、安全组规则；另一类是物理机或托管机房，去梳理交换机的公网IP分配表。整理一张表格，记录IP地址、开放端口、服务类型、责任人、是否必须公网可达，这份名单是后续所有安全检查的基础。
很多团队的问题不是“没有安全产品”，而是“不知道自己的资产边界在哪”。比如某个项目组临时起了台测试服务器，顺手放行了一个管理端口，项目结束后忘了释放公网IP，这台机器就会一直留在公网上。资产盘点不能只做一次，建议至少每季度复查一次，把新增服务和下线服务同步更新。
3.2 外部视角验证：用公网扫一扫
内部视角看自己，往往“不识庐山真面目”，因为你在内网访问不经过安全组，看到的不代表公网用户看到的。正确做法是从外部网络发起点探测，模拟攻击者的第一视角。
没有专业工具的情况下，最简单的方式是使用公开的在线端口检测服务，输入公网IP，选择常见端口列表，看这些端口在外部是否可达。更彻底一点，可以用本机的命令行工具做一次TCP端口探测，对候选IP逐个检查22、80、443、3389、3306、6379这几个关键端口的状态。需要注意：外网服务检测要到非本机网络环境执行，如果你本身就是从这台服务器的内网发起，结果不具备参考性。
云平台方面，阿里云、腾讯云、华为云的控制台都提供了安全体检和主机安全的暴露面检测功能，会自动列出公网端口和风险等级。我自己的习惯是：外网探测结果只作为“发现问题”的第一步，发现问题后马上回到安全组规则和服务器本地监听状态去核对源头。
3.3 服务配置病历：不只看端口开没开
端口开放不等于有漏洞，但端口配上糟糕的配置才是真正的问题。自查时除了看端口，还要看服务本身的状态。
针对几个高频端口，我有一套固定检查动作：
- SSH检查sshd_config，确认是否允许密码登录、是否允许root直接登录、监听地址是0.0.0.0还是内网IP
- RDP检查是否开启NLA以及账户锁定策略，同时确认3389是否在防火墙放行到公网
- MySQL查看bind-address和user表，确认是否存在host为%的高权限账号
- Redis执行CONFIG GET requirepass，确认是否有密码、protected-mode是否为yes
- 安全组检查所有入方向规则，寻找来源为0.0.0.0/0的高危端口放行记录
这套检查如果全人工做会比较耗时，但第一次必须做，目的有两个：一是清掉历史遗留问题，二是形成一份基线文档。之后再看情况，要么交给主机安全Agent自动核查，要么定期抽检。
4. 加固落地：从网络边界到服务配置的纵深防御
4.1 网络层收敛：安全组与防火墙的最小授权
网络层是最先发力也最能见效的一层。核心原则只有一条：让流量只经过它应该走的路。具体到操作，就是安全组或防火墙规则遵循“最小授权”和“来源限制”两条线。
管理类端口（22、3389）和数据库端口（3306、6379）原则上不应该允许0.0.0.0/0访问。如果办公网络有固定出口IP，就只放行这个IP；如果办公出口是动态IP，就通过堡垒机跳板访问，而不是把管理端口直接暴露。业务类端口（80、443）必须对全网开放，但可以考虑放在负载均衡后面，负载均衡统一接入流量，后端服务器只对负载均衡的IP段开放端口。
一个容易被忽视的细节是安全组的方向配置。很多人的注意力都放在入方向规则上，出方向永远保持着默认的“允许全部”，这会导致一种很尴尬的场面：即使入方向被挡住了，服务器一旦被入侵，恶意程序照样可以主动向外发起连接拉取恶意文件、连上矿池。所以加固时出方向策略也值得花时间梳理，至少要做到目标地址或端口级的最低放行。
4.2 主机层与账号策略：扛住暴力破解的底气
账号和口令策略是端口安全里承上启下的部分。网络层拦不住所有流量，能挡住暴力破解的就是账号策略的强度。
Linux主机上，SSH侧建议做四件事：禁止root直接登录（PermitRootLogin no）、关闭密码认证改用密钥认证（PasswordAuthentication no）、调整最大认证尝试次数（MaxAuthTries 3）、启用客户端空闲断开（ClientAliveInterval，ClientAliveCountMax）。如果确实需要密码登录，密码长度建议不低于12位且混合大小写字母、数字和符号，同时配合失败次数限制工具，把一段时间内的认证失败次数拉高后触发临时封禁。
Windows主机上，重点看账户锁定策略。默认情况下Windows对RDP爆破没有次数限制，等于给攻击者无限试错机会，所以建议开启账户锁定阈值。另外远程桌面用户不要给管理员组以外的普通账号赋予RDP登录权限，能减小被爆破后的影响面。需要说明的是，账户锁定策略本身可能被攻击者用来做拒绝服务，比如故意输错多次密码把管理员账号锁了，所以在生产环境还要结合审计日志，判断锁定是人为失误还是恶意触发，不能一味追求高安全而牺牲可用性。
4.3 服务层专项加固：按端口逐个处理
对6个核心端口，我按实践经验整理了一份加固清单，可以按表作业。
| 端口 | 服务 | 必做加固项 | 补充项 |
|---|---|---|---|
| 80 | HTTP | 启用WAF、关闭目录浏览、删除默认页和示例文件 | 集中式访问日志存储、接口限频 |
| 443 | HTTPS | TLS证书使用安全套件、配置HSTS、WAF看解密流量 | 对敏感接口加额外鉴权 |
| 22 | SSH | 禁用密码登录、禁止root登录、密钥认证 | 非默认监听端口、fail2ban |
| 3389 | RDP | 开启NLA、账户锁定阈值、强密码 | 防火墙来源IP白名单、尽量走堡垒机 |
| 3306 | MySQL | bind-address绑定内网、独立低权限账号、强密码 | 账号来源host最小化、开启审计日志 |
| 6379 | Redis | requirepass强密码、protected-mode yes、bind内网 | rename-command禁用高危命令、不以root运行 |
Redis加固有一个需要特别说明的点。很多网上的教程都建议用rename-command把危险命令改名甚至禁用来降低风险，思路是对的，实测有效，但要注意版本兼容性。Redis 4.0以下的部分版本对rename-command的支持有缺陷，配置后可能不生效甚至导致重启异常，所以落地这个方案前，要先确认版本，并且在测试环境里验证重启行为，不要直接改了配置就reload，否则生产Redis起不来就麻烦了。
MySQL加固时同样存在“看起来改了、实际没改”的坑。比如只修改了bind-address但没有重启mysqld，新配置根本没加载；又比如给应用建了账号，但因为所有账号都创建在user表里而全局授权是all privileges，应用账号权限过大，一旦被脱库，影响半径直接拉满。正确做法是明确每个应用账号需要的库和操作类型，只赋予最小权限。如果业务比较庞大、账号很多，只靠手工SQL容易混乱，可以借助配置管理工具把数据库账号统一成代码，入库前做权限评审，这样至少能把“权限过高”挡住一层。
4.4 加固中的翻车现场与绕坑经验
加固不是套一堆配置就能完事，我在实际落地中翻过不少车，挑几个有代表性的说。
第一个是改SSH端口把自己关在门外。有一次我在一台云主机上把SSH端口从22改成22022，修改了sshd_config后重启服务，然后发现无论如何都连不上，最后通过云控制台的VNC登录才看到：firewalld没有放行22022，而默认zone的22端口规则是拒绝的，修改的端口直接被防火墙拦在门外。这个经历带来的教训是：改任何服务监听端口前，先确认防火墙、安全组都放行了新端口，再重启服务；在没确认之前的建议是保持原端口，原因在于改端口不等于加固，只是避开默认扫描，真正决定安全的是认证方式。
第二个是Redis低版本的rename-command只配了没生效。之前帮一个客户加固一台老版本Redis，配置里明明写了rename-command CONFIG ""，但redis-cli执行CONFIG GET依然能返回结果。查了半天才发现那台跑的是3.2系列版本，部分小版本对rename-command的处理有兼容问题。这块最后是通过升级Redis到新稳定版加requirepass解决，而不是靠禁用命令来保平安。
第三个是云安全组方向搞反。有客户反馈数据库端口加固了，但数据库服务器还是被入侵，排查下来发现安全组对入方向确实限制了来源IP，但出方向是放行所有，恶意代码通过服务器主动外联把数据传了出去。端口安全是双向的，只在入口做文章，出口不设防，等于给攻击者留了后门。之后我的加固流程里增加了“出方向策略评审”环节，对所有管理端口和数据库端口所在的服务器，出方向规则都单独过一遍。
5. 被突破之后：一次真实环节的事件处置复盘
5.1 发现：异常流量从哪来
去年处理过一起典型的端口暴露事件，整个排查过程值得复盘。客户报障说一台内网业务服务器CPU持续打满，应用响应极慢，登录服务器后我做的第一件事是打开系统资源监控，看到有个进程的CPU占用率一直维持在90%以上。同时用网络连接统计命令看了一眼连接数，发现这台内网机器存在大量到外部的主动连接。一个内网业务服务器不应该主动访问外网那么多IP，这个迹象基本可以判定机器已经失陷，恶意程序正在外联通信。
这时候要稳住，不要急着杀进程，也不要马上改口令。先保留现场，再做隔离，再谈清除。
5.2 止损与证据保留：先断外联再溯源
处理顺序上，我习惯先断“外联通道”，再动“失陷主机”。原因很简单：不切断出方向连接，攻击者随时可以通过已经建立的通道远程操控这台机器，你清除进程他还能再拉起来，甚至反手把日志清了。
断外联的具体做法，在云环境里比较快捷的是直接在安全组规则里临时将出方向设为拒绝，或者在服务器本地防火墙里配置DROP规则，把默认出方向策略从允许改成丢弃。对物理机就只能在边界防火墙或交换机上做临时策略。隔离后保留取证材料：当前所有进程列表、网络连接快照、监听端口列表、登录记录、最近修改的文件和时间戳、以及内存中的进程对应的可执行文件路径。这些是下一步分析的原始材料。
5.3 日志链路排查：还原攻击者的完整路径
止损完成后开始溯源。我按“进程—连接—文件—登录记录”四条线交叉排查。
先看进程：定位到那个高CPU占用的PID后，通过/proc/PID/exe找到可执行文件路径，再用/proc/PID/cmdline查看启动参数，确认启动方式是不是计划任务或异常二进制。
再看网络连接：统计服务器对外连接的IP和端口，恶意程序只要还在线，你就能从连接列表里一窥它的控制端。
然后看登录记录：用last和lastb分别查看成功登录和失败登录记录，重点看是否有从陌生IP来的成功登录。在登录日志、secure日志里搜索Accepted关键字，定位攻击者最早是从哪个地址、用什么账号进来的。
最后落到文件侧：检查系统的计划任务目录、开机启动脚本、SSH的authorized_keys文件，看是否有攻击者留下的持久化后门。那次排查里，攻击路径还原下来是这样的：Redis以默认配置运行在6379端口且未做任何来源限制，攻击者通过未授权的redis-cli连接，利用计划任务的方式写入了一条下载并执行恶意程序的记录，恶意程序随后以root权限运行，拉起了挖矿进程，并通过6379端口带来的权限差持续作为跳板在服务器上活动。
整个链路并不复杂，但每一步都可能被忽略。如果没有把那条异常计划任务翻出来，就算杀了挖矿进程，重启后系统也会再次把它拉起来。
5.4 恢复部署与加固闭环
完成溯源后开始恢复。我执行的顺序是：先清理计划任务、启动项、异常账号、异常公钥等持久化后门；确认恶意进程及其释放的文件全部删除；修改服务器上所有账号的密码和所有应用的连接密码；然后才重启业务服务。重启后再观察一段时间，确认没有异常进程重新被拉起、外联恢复后不再出现陌生连接。
后续加固才是真正的重点，否则过几天大概率还会出同类事件。那次我给出的加固方案包括：Redis必须配置强密码、开启protected-mode、只监听内网地址；6379的入方向安全组规则从0.0.0.0/0收敛到仅内网网段；Redis进程改为非root用户运行；服务器出方向策略按端口最小放行；同时把Redis和服务器纳入主机安全检查范围，每周自动检测配置漂移。这个闭环做完，心里才踏实。
我从这件事里养成的习惯，直到现在还在用：每次上线一个新服务，第一件事就是核对安全组规则和端口监听状态，填一张暴露面清单，确认每个端口存在的原因、允许的来源和兜底的防护措施。高危端口这个名单可能还会继续存在很多年，但只要我们把它一个端口一个端口捋清楚、处置好，它们也仅仅就是“在跑的服务”而已，不再是被利用的破绽。
