做运维这些年我养成了一个习惯每次接手一套系统先不看业务代码直接一条命令扫过去。扫完看到哪些端口对外开放心里基本就有数了——这环境是不是在公网“裸奔”攻击者大概会从哪个门进来甚至以前有没有被人打过都能猜个八九不离十。很多人一听到“高危端口”就下意识觉得要全部封死其实没这么简单。80 端口总不能关吧关了网站用什么访问443 更不可能关。真正要命的从来不是端口号本身而是跑在端口上的服务有没有被管理好。这篇文章我就围绕 22、80、443、3389、3306、6379 这六个最常见的暴露端口逐个拆一遍风险点、攻击路径和加固办法给刚入行的新人和自己搭服务器的独立开发者一份能直接照着做的清单。在逐个端口看之前先建立一个基本认知端口本身是无辜的是跑在端口上的服务以及服务暴露的方式决定了风险等级。所谓“高危端口”其实是安全社区对“一旦开放到公网就极易被扫描器盯上、被自动脚本爆破、被公开漏洞打穿”的端口的习惯叫法。也就是说高危两个字形容的不是端口号而是“一个把大门敞在闹市区、旁边还没有监控的管理入口”。理解这一点后面的很多加固动作自然就通透了。1. 先理解风险模型高危端口到底“危”在哪1.1 端口暴露的本质让攻击者少走弯路公网上的扫描器从来没有休息时间。无论是 Shodan、Censys 这类专门收录网络资产信息的平台还是各种自动扩散的僵尸网络都在持续对全量 IP 地址做扫描。只要你的 22 或 3389 端口暴露在公网短则几十分钟长则几天一定会进到扫描结果里。攻击者不需要知道你公司叫什么也不用费心思去查你的业务背景只需要拿着一份“端口-服务-漏洞利用”对照表按图索骥一晚上就能筛选出一大批可以下手的目标。这里有一个关键概念暴露面和风险是正相关的。同样一个 MySQL 端口如果只在服务器本机 127.0.0.1 上监听公网扫描器再厉害也够不着它就不算高危如果绑定了 0.0.0.0 并且口令是 root/root那基本等于把数据库钥匙挂在了公共钥匙架上被拖库只是时间问题。所以我经常跟朋友说排查安全问题别先急着装各种安全软件先回答一个问题哪些服务在哪些 IP 上监听哪些端口对哪些来源开放。把这个摸清楚等于完成了一半安全工作。1.2 从扫描到利用一次典型的攻击路径很多没经历过真实攻击的人总觉得黑客攻击是电影里那种一帧帧敲代码的画面。实际上自动化攻击更像一条流水线分四步走。第一步是端口扫描工具通常是 Masscan、Zmap 或者各种脚本把所有开放端口找出来。第二步是服务识别通过 banner、TLS 证书、HTTP 返回头来判断端口背后跑的到底是什么版本。第三步是漏洞匹配或弱口令尝试如果软件版本有公开 CVE直接拿现成 POC 打如果没有明显漏洞就换弱口令字典爆破。第四步是权限维持和扩散拿到权限后常见的动作是植入后门、创建隐藏账号、连接外部控制端然后要么挖矿要么横向移动要么直接锁库勒索。我在实际排查中见过太多“中了挖矿病毒”的机器翻来覆去就那几条路径绝大多数是从 6379 端口未授权访问或者 22 端口弱口令进来的。理解这条流水线之后后面所有的加固逻辑都会变得非常清楚你要做的事情就是尽量让攻击者在第二、第三步停下来让他扫不到、连不上、登不进。2. 六大高危端口逐个拆解2.1 22端口SSH 远程管理通道暴力破解的重灾区SSH 是 Linux 服务器最主要的远程管理通道基本可以说是服务器的命根子。22 端口长期霸榜各种高危端口清单原因并不复杂几乎每台 Linux 服务器都默认开着它自动化扫描一抓一个准很多环境仍然使用密码认证再加上 root 用户允许直接远程登录爆破效率高得吓人。我接触过某个客户环境一台公网测试机密码是 Abc123456不到三天就被爆破进去成了挖矿肉鸡。所以 22 端口的加固要排在最前面。攻击者打 22 端口的方式并不高级但极其有效。他们会准备一个很大的用户名列表和密码字典用 Hydra、Medusa 这类工具在几小时内跑完几百万种组合。现在的爆破工具还会根据目标公司的域名、常见人名、历史密码生成专属字典成功率比想象中高很多。更麻烦的是如果 SSH 日志没有集中采集等你发现异常时木马可能已经替你创建好了自己的用户。加固 22 端口我建议按这个顺序做。第一如果业务允许先把 root 远程登录禁用在 sshd_config 里设置 PermitRootLogin no然后用一个普通用户加 sudo 来做日常运维。第二启用公钥认证把 PasswordAuthentication 设为 no。这样即使攻击者有再完整的字典也无从下手。第三有条件就限制来源 IP运维网段白名单是性价比最高的办法。第四可以改端口把 22 改成高位端口但这只能挡掉一部分无差别扫描改完之后公钥和禁用密码的措施一样都不能少。最后配上 fail2ban 或云安全组对连续失败次数做自动封禁。我第一次配 fail2ban 时觉得多余直到看到它把几百个尝试爆破的 IP 一封一片才意识到这东西确实管用。2.2 80与443端口Web 服务入口漏洞最密集的区域80 和 443 是 Web 服务的默认入口几乎所有对外业务都离不开。它们之所以高危不是因为容易被爆破而是因为必须面向公众开放没法简单用 IP 白名单封死。只要开了 80 或 443等于默认接受来自任何人的连接Web 应用、中间件、组件框架的历史漏洞全都被暴露在扫描器面前。攻击者扫目录、测注入、找未授权接口、翻备份文件都是从这两个端口开始的。最常见的风险点包括Nginx 默认页没改服务器版本号直接暴露在 404 页里用了老的 CMS 或开源框架一条 URL 就能命中历史漏洞后台管理路径放在 /admin 而且密码薄弱被目录扫描工具直接扫出来上传文件不过滤类型和内容被攻击者 get 到了 webshell。这里多说一句很多团队一上来就买 WAF可真正出问题的时候会发现WAF 只能挡已知攻击业务逻辑漏洞、越权访问、接口鉴权缺失这类问题是拦不住的。还有个很常见的现象是站点前端会挂人机验证或自动防护页面就是那种标题写着“本网站使用安全服务防护恶意自动程序。在验证您不是自动程序期间将显示此页面”的过渡页。这其实算一种轻量 WAF能挡住一部分扫描机器人和低频攻击但如果后端接口本身没做鉴权这种页面救不了你——攻击者可以直接绕过页面调接口。所以 Web 安全的基础还是回到应用本身。通用加固思路包括定期更新中间件和语言运行时该打的补丁别拖关闭版本 banner 和目录列表把管理后台放到独立域名或限定管理网段访问最好叠加 IP 白名单强制 HTTPS 并配置合理的 TLS 参数和 HTTP 安全头对文件上传做后缀、内容、大小、权限的多重限制上线前把常见扫描工具能扫到的默认路径、备份文件、源码目录都清干净。对独立开发者来说最简单的做法是套一层云 WAF 或用 CDN把源站 IP 藏起来配合强密码和补丁更新基本能应对绝大多数自动化攻击。2.3 3389端口RDP 远程桌面勒索软件最爱的入口3389 是 Windows 远程桌面服务RDP的默认端口装完 Windows Server 默认就开着。它之所以高危是因为 Windows 服务器在中小企业里的占比太高而且很多人的本地 Administrator 密码就是 Admin123 这个水平。攻击者对 3389 的爆破几乎是全天候的一旦爆破成功就拿到了完整的桌面权限之后做任何操作都等于你本人在屏幕前操作。更麻烦的是勒索软件特别喜欢用 RDP 作为初始入口先进来关掉杀毒软件用系统命令做内网侦察再批量横向扩散最后锁库勒索。我见过不止一次客户信誓旦旦地说“我们没开什么服务啊”一查日志3389 端口被同一个 IP 尝试了几万次连接。这种情况其实早就该处置了只是没人看日志。如果你确实需要远程桌面几个底线必须守住。第一强制启用网络级别身份验证NLA这个选项能挡住一部分未授权连接尝试也降低老漏洞的利用风险。第二不要用内置 Administrator 作为日常登录账号新建一个独立账号并加入 Administrators 组同时把 Administrator 改名或禁用减少针对默认账号的爆破。第三设置账号锁定阈值比如连续失败 5 次锁定 15 分钟这能直接拖慢爆破速度。第四限制远程桌面的来源 IP或者统一走堡垒机再连接。第五可以考虑把默认 3389 改成高位端口虽然这不算安全机制但能明显减少自动扫描的噪音。还有一个实操细节我接触过一些远程桌面连不上的工单提示“无法加载远程桌面服务 activex 控件”或者“远程桌面客户端无法连接到远程计算机”一半以上是本地浏览器或客户端控件版本太旧、缓存不干净导致的。这类问题虽然不像安全风险那么严重但排查的时候不要第一步就去改防火墙先换一台设备或换一个 RDP 客户端试试可能就通了。2.4 3306端口MySQL 数据库端口拖库的最后一步MySQL 的默认端口是 3306数据库端口之所以高危是因为里面放的是整个系统里最值钱的数据。一旦 3306 对公网开放且口令薄弱攻击者根本不需要经过 Web 层直接用 Navicat 这类客户端远程连上来一条 SELECT 语句就能把所有用户表、订单表遍历一遍并拖走。很多早年新闻里报的“拖库”事件别以为都是从 Web 打进去的实际有相当一部分是 3306 或 6379 直接裸露在公网上。攻击者利用 3306 的思路很简单先扫描端口再用常见数据库弱口令字典尝试登录登录成功后先看 user 表看有没有高权限账号然后就是数据拷贝。这个过程中MySQL 的错误日志里会留下大量报错记录比如 Host ‘x.x.x.x’ is not allowed to connect to this MySQL server这其实就是客户端连接被拒绝的痕迹。如果环境里能看到这些日志说明攻击者已经在尝试连接了。加固 MySQL 端口重点在权限分层和网络控制。不要用 root 作为业务连接账号每个业务单独建账号只授权对应的库账号权限尽量只保留 SELECT、INSERT、UPDATE、DELETE不轻易给 DDL 或 SUPER 权限。连接来源限制在应用服务器的 IP 段内如果必须远程维护通过堡垒机中转不要直接把 3306 暴露到公网。服务侧还可以让 MySQL 只监听内网 IP修改 my.cnf 里的 bind-address比如 127.0.0.1 或内网地址打开 slow query log 用于性能排查必要时短时间开启 general log但别长期开着日志文件膨胀的速度非常吓人。数据库备份也别忘了加密否则备份文件被拖走之后一样会被直接读库。2.5 6379端口Redis 服务端口未授权访问的典型代表Redis 的高危程度这几年已经被挖矿蠕虫证明得明明白白。默认端口 6379旧版本默认没有密码3.2 之前的版本连保护模式都没有更麻烦的是 Redis 的 CONFIG SET 命令可以动态修改 dir 和 dbfilename配合 RDB 快照写文件的能力攻击者可以直接往磁盘上写文件。最经典的利用方式是写入 crontab 定时任务或者写入 SSH 的 authorized_keys从而获得服务器权限。等服务器上了贼船下一步不用猜百分之九十是植入挖矿程序然后继续扫描内网其他机器。面对 6379 端口第一原则就是别让它出现在公网。如果 Redis 只在本机使用直接在配置里 bind 127.0.0.1如果多个内网节点需要访问也尽量用内网 IP再叠加密码。密码要设置 requirepass并选择一个足够长、不是常见字典词的随机串。Redis 6 及以后版本还支持 ACL可以创建独立的最小权限账号只给运行需要的命令授权。另一个非常实用的操作是 rename-command 或者直接禁用危险命令比如在配置里加一条 rename-command CONFIG 攻击者就没法再利用 CONFIG 来改配置同理可以把 EVAL、FLUSHALL、KEYS 等命令一并处理掉。我见过不少团队把 Redis 配置得很规矩但忘了给 redis.conf 配置文件本身加权限导致服务器上的普通用户都能读到含明文密码的配置文件这也是一处隐形风险。另外Redis 默认的持久化文件 dump.rdb 也可能包含敏感数据存放目录权限同样要收一下。总体来说如果你想给 Redis 安全打分绑定内网加密码加禁用危险命令这三件事做完再配合定期备份已经能挡住绝大多数脚本化攻击。3. 网络侧与服务侧加固实操光知道哪些端口高危没有用关键在动手。这一节我把网络层和服务层两部分动作拆开讲操作顺序上建议先做网络侧收敛暴露面再做服务侧配置加固。顺序反过来也行但网络侧改完效果来得最快能立刻把公网上的自动扫描挡在门外。3.1 网络侧最容易落地白名单和端口映射怎么配我见过太多云服务器安全组里放行 0.0.0.0/0 的 22、3389 端口一问就是“临时连一下后面再改”然后这个“后面”永远没有来。网络侧加固的第一件事就是把这些管理端口22、3389、3306、6379 等的来源地址改成已知的固定运维出口 IP或者统一收敛到一个临时跳板机。安全组、防火墙规则在写的时候尽量用具体 IP 段别写 0.0.0.0/0。如果业务必须要公网访问那 80/443 照常开放后端管理端口一律只放内网或通过内网通道访问。独立服务器和 IDC 场景同理可以用 iptables 或系统防火墙按来源 IP 做限制。比如 SSH 只允许公司出口 IP 访问MySQL 只允许应用服务器内网 IP 访问Redis 只允许本机或特定业务主机访问。iptables 规则从上往下匹配白名单规则要放在前面拒绝所有规则放在最后。云上环境优先使用安全组而不是在服务器里乱配 iptables因为安全组规则出了问题回滚方便也不会出现本地防火墙和云防火墙互相打架的情况。改端口这个动作可以保留但别把它当成安全措施它顶多算“降低被无差别扫描命中的概率”真正的防线还是白名单和强认证。3.2 服务侧加固改配置、下线旧协议、开审计网络侧把外围挡住之后服务侧的配置才是决定安全下限的关键。以 SSH 为例需要在 /etc/ssh/sshd_config 里设置 PasswordAuthentication no、PermitRootLogin no再指定 AllowUsers 为具体运维账号改完以后先执行 sshd -t 校验配置确认没有语法错误再重启服务而且新开一个终端测试能连上之后再退出旧会话。这是我踩过很深的一个坑改完配置直接重启结果手滑少了一个空格sshd 直接起不来人又不在机房只能通过云控制台去救。从那以后我给自己立了一条规矩改任何服务配置先校验再重启再验证。MySQL 侧修改 my.cnf 里的 bind-address 后需要重启实例有些环境重启会引起主从切换或短暂不可用动作要放在低峰期。改完之后可以用 netstat 或 ss 再确认监听地址是否已经生效。Redis 侧改完 redis.conf 后需要 CONFIG REWRITE 或重启 redis条件允许优先用 config rewrite能避免重启导致缓存全部丢失。另一个容易被忽略的点是统一日志审计和时间同步SSH 的日志可以推到远程日志服务器Windows 的登录事件通过事件订阅集中收集时间不同步会让多台服务器上的日志顺序错乱排查攻击路径时很难对得上。这些事虽然不直接产生“安全产出”但真出事的时候干净完整的日志能省下大量的排查时间。3.3 六个端口的快速加固对照表端口服务最典型风险首选加固动作次选加固动作22SSH密码爆破、root直接登录公钥登录 禁用密码来源白名单 fail2ban80/443Web应用漏洞、路径扫描及时补丁 隐藏版本WAF/CDN 管理后台限IP3389RDP远程爆破、勒索感染强口令 NLA 锁定策略来源白名单 改端口3306MySQL弱口令、数据拖库仅监听内网 白名单最小权限账号 审计6379Redis未授权访问、写文件绑定内网 强密码禁用危险命令 ACL这张表的每一行都值得落到实际配置里但核心思路可以概括成一句话让扫描器扫不到让服务登录不上去让命令执行不了。4. 实战排查与事故复盘我被这些端口“教育”过的瞬间这部分内容跟前面偏配置的写法不同更多是排查顺序和现场处置经验。服务器已经被扫描、被爆破、甚至已经被入侵之后怎么最短时间确认情况是每个运维都应该有的基本能力。4.1 半小时内判断服务器是否被爆破或已经被入侵拿到一台有嫌疑的服务器不要慌按顺序看五个地方。第一是监听端口用 ss -lntp 或 netstat -lntp 查看有没有异常端口。第二是登录日志Linux 看 /var/log/auth.log 或执行 journalctl -u sshdWindows 则在事件查看器里筛登录失败事件 ID 4625看有没有大量来自陌生 IP 的尝试。第三是登录历史执行 last 和 w看有没有非工作时间的登录记录。第四是临时文件目录/tmp、/var/tmp 下有没有最近改动的可疑脚本、二进制文件或压缩包。第五是进程情况如果某个进程 CPU 飙高用 top 看进程名再用 ls -l /proc/[PID]/exe 查看进程的原始路径挖矿程序经常藏在 /tmp、/var/tmp、/usr/local/lib 这类位置。我上次排查一台 Redis 失陷的机器就是在 /var/tmp 找到一个名字看起来像系统库的二进制文件大小又明显不对一查进程 CPU 占用直接拉满确认是挖矿木马。另外用 ss -antp 看外向连接也很有用如果发现有进程不断向外网陌生 IP 发起连接十有八九已经中招。这种时候不要急着杀进程先保留现场把可疑文件复制一份再切断外连或者临时拉黑对应 IP最后再清理和恢复。顺序反了木马会换一个新文件重新落地等于白忙。4.2 三个低频但高杀伤的误操作案例第一件有次给客户改 SSH 端口把配置里的 Port 写错同时没有做 sshd -t 校验导致整个运维组所有成员都连不上机器最后只能通过云控制台的 VNC 进去改回来。第二件帮客户迁移数据库开发同学图省事在安全组把 3306 放开了 0.0.0.0/0同时数据库还在用弱密码第二天发现有人远程连上来执行了清理脚本把数据表直接清掉。虽然最后从备份恢复但整个过程非常惊险也让大家真正理解了数据库端口裸奔的后果。第三件一个 Redis 集群节点本来只做了内网绑定结果机房新加了一块公网网卡忘了重新配置 bind扫描器扫到未授权访问后直接感染了挖矿蠕虫最后只能隔离重装。这三个案例本质上都是同一个问题只想着“临时开一下后面再改”然后这个“后面”不是被遗忘就是被当成无所谓的小事拖过去。我后来养成了一个习惯任何公网暴露的端口都要在配置注释或云资源标签里写清楚用途和到期时间每周巡检一次看到符合“高危端口 来源不明 无到期时间”的组合立刻收紧规则。4.3 高危端口常见问题速查现象可能原因处理思路22端口连不上安全组看起来没问题SSH服务启动失败或防火墙规则冲突通过控制台/带外方式登录检查 sshd 状态与日志3306只能本机连接应用连不上bind-address 没改或账号指定了 localhost检查 my.cnf 的 bind 地址和账号 host 限制6379服务启动失败/端口被占用配置错误或旧进程残留用 ss 看端口占用查看 Redis 日志中的报错80端口返回403或安全验证页Web服务权限或防护规则限制按访问来源、WAF规则、站点配置依次排查3389经常被爆破解锁弱口令或没有锁定策略改强密码、开启锁定策略、限制来源IP需要说明的是排障时永远优先看日志而不是凭感觉改配置。很多“端口不通”的工单最后查下来都是安全组、系统防火墙、服务监听地址三层规则不一致造成的。先确认你想访问的端口在哪个地址上监听再确认中间每一层防火墙是否放行基本不会走弯路。最后再分享一点个人体会。我常在交流群里看到有人问“XX端口到底要不要关”答案其实很直接业务需要就开但开之前先把白名单、强口令、日志审计这三件事做掉。与其天天追着最新漏洞新闻跑不如先把最基础的暴露面收敛好。端口的安全说到底是一种持续的管理习惯定期巡检监听端口、清理不再使用的服务、关注组件和证书版本这些事比任何号称“一键安全”的工具都更可靠。希望这篇内容能让你下次接手服务器时少踩我踩过的那些坑。 
长河君 · 2026/9/17 0:41:00 · 阅读 1.2k 高危端口排查与加固：从SSH到Redis的服务器安全实战指南
做运维这些年我养成了一个习惯每次接手一套系统先不看业务代码直接一条命令扫过去。扫完看到哪些端口对外开放心里基本就有数了——这环境是不是在公网“裸奔”攻击者大概会从哪个门进来甚至以前有没有被人打过都能猜个八九不离十。很多人一听到“高危端口”就下意识觉得要全部封死其实没这么简单。80 端口总不能关吧关了网站用什么访问443 更不可能关。真正要命的从来不是端口号本身而是跑在端口上的服务有没有被管理好。这篇文章我就围绕 22、80、443、3389、3306、6379 这六个最常见的暴露端口逐个拆一遍风险点、攻击路径和加固办法给刚入行的新人和自己搭服务器的独立开发者一份能直接照着做的清单。在逐个端口看之前先建立一个基本认知端口本身是无辜的是跑在端口上的服务以及服务暴露的方式决定了风险等级。所谓“高危端口”其实是安全社区对“一旦开放到公网就极易被扫描器盯上、被自动脚本爆破、被公开漏洞打穿”的端口的习惯叫法。也就是说高危两个字形容的不是端口号而是“一个把大门敞在闹市区、旁边还没有监控的管理入口”。理解这一点后面的很多加固动作自然就通透了。1. 先理解风险模型高危端口到底“危”在哪1.1 端口暴露的本质让攻击者少走弯路公网上的扫描器从来没有休息时间。无论是 Shodan、Censys 这类专门收录网络资产信息的平台还是各种自动扩散的僵尸网络都在持续对全量 IP 地址做扫描。只要你的 22 或 3389 端口暴露在公网短则几十分钟长则几天一定会进到扫描结果里。攻击者不需要知道你公司叫什么也不用费心思去查你的业务背景只需要拿着一份“端口-服务-漏洞利用”对照表按图索骥一晚上就能筛选出一大批可以下手的目标。这里有一个关键概念暴露面和风险是正相关的。同样一个 MySQL 端口如果只在服务器本机 127.0.0.1 上监听公网扫描器再厉害也够不着它就不算高危如果绑定了 0.0.0.0 并且口令是 root/root那基本等于把数据库钥匙挂在了公共钥匙架上被拖库只是时间问题。所以我经常跟朋友说排查安全问题别先急着装各种安全软件先回答一个问题哪些服务在哪些 IP 上监听哪些端口对哪些来源开放。把这个摸清楚等于完成了一半安全工作。1.2 从扫描到利用一次典型的攻击路径很多没经历过真实攻击的人总觉得黑客攻击是电影里那种一帧帧敲代码的画面。实际上自动化攻击更像一条流水线分四步走。第一步是端口扫描工具通常是 Masscan、Zmap 或者各种脚本把所有开放端口找出来。第二步是服务识别通过 banner、TLS 证书、HTTP 返回头来判断端口背后跑的到底是什么版本。第三步是漏洞匹配或弱口令尝试如果软件版本有公开 CVE直接拿现成 POC 打如果没有明显漏洞就换弱口令字典爆破。第四步是权限维持和扩散拿到权限后常见的动作是植入后门、创建隐藏账号、连接外部控制端然后要么挖矿要么横向移动要么直接锁库勒索。我在实际排查中见过太多“中了挖矿病毒”的机器翻来覆去就那几条路径绝大多数是从 6379 端口未授权访问或者 22 端口弱口令进来的。理解这条流水线之后后面所有的加固逻辑都会变得非常清楚你要做的事情就是尽量让攻击者在第二、第三步停下来让他扫不到、连不上、登不进。2. 六大高危端口逐个拆解2.1 22端口SSH 远程管理通道暴力破解的重灾区SSH 是 Linux 服务器最主要的远程管理通道基本可以说是服务器的命根子。22 端口长期霸榜各种高危端口清单原因并不复杂几乎每台 Linux 服务器都默认开着它自动化扫描一抓一个准很多环境仍然使用密码认证再加上 root 用户允许直接远程登录爆破效率高得吓人。我接触过某个客户环境一台公网测试机密码是 Abc123456不到三天就被爆破进去成了挖矿肉鸡。所以 22 端口的加固要排在最前面。攻击者打 22 端口的方式并不高级但极其有效。他们会准备一个很大的用户名列表和密码字典用 Hydra、Medusa 这类工具在几小时内跑完几百万种组合。现在的爆破工具还会根据目标公司的域名、常见人名、历史密码生成专属字典成功率比想象中高很多。更麻烦的是如果 SSH 日志没有集中采集等你发现异常时木马可能已经替你创建好了自己的用户。加固 22 端口我建议按这个顺序做。第一如果业务允许先把 root 远程登录禁用在 sshd_config 里设置 PermitRootLogin no然后用一个普通用户加 sudo 来做日常运维。第二启用公钥认证把 PasswordAuthentication 设为 no。这样即使攻击者有再完整的字典也无从下手。第三有条件就限制来源 IP运维网段白名单是性价比最高的办法。第四可以改端口把 22 改成高位端口但这只能挡掉一部分无差别扫描改完之后公钥和禁用密码的措施一样都不能少。最后配上 fail2ban 或云安全组对连续失败次数做自动封禁。我第一次配 fail2ban 时觉得多余直到看到它把几百个尝试爆破的 IP 一封一片才意识到这东西确实管用。2.2 80与443端口Web 服务入口漏洞最密集的区域80 和 443 是 Web 服务的默认入口几乎所有对外业务都离不开。它们之所以高危不是因为容易被爆破而是因为必须面向公众开放没法简单用 IP 白名单封死。只要开了 80 或 443等于默认接受来自任何人的连接Web 应用、中间件、组件框架的历史漏洞全都被暴露在扫描器面前。攻击者扫目录、测注入、找未授权接口、翻备份文件都是从这两个端口开始的。最常见的风险点包括Nginx 默认页没改服务器版本号直接暴露在 404 页里用了老的 CMS 或开源框架一条 URL 就能命中历史漏洞后台管理路径放在 /admin 而且密码薄弱被目录扫描工具直接扫出来上传文件不过滤类型和内容被攻击者 get 到了 webshell。这里多说一句很多团队一上来就买 WAF可真正出问题的时候会发现WAF 只能挡已知攻击业务逻辑漏洞、越权访问、接口鉴权缺失这类问题是拦不住的。还有个很常见的现象是站点前端会挂人机验证或自动防护页面就是那种标题写着“本网站使用安全服务防护恶意自动程序。在验证您不是自动程序期间将显示此页面”的过渡页。这其实算一种轻量 WAF能挡住一部分扫描机器人和低频攻击但如果后端接口本身没做鉴权这种页面救不了你——攻击者可以直接绕过页面调接口。所以 Web 安全的基础还是回到应用本身。通用加固思路包括定期更新中间件和语言运行时该打的补丁别拖关闭版本 banner 和目录列表把管理后台放到独立域名或限定管理网段访问最好叠加 IP 白名单强制 HTTPS 并配置合理的 TLS 参数和 HTTP 安全头对文件上传做后缀、内容、大小、权限的多重限制上线前把常见扫描工具能扫到的默认路径、备份文件、源码目录都清干净。对独立开发者来说最简单的做法是套一层云 WAF 或用 CDN把源站 IP 藏起来配合强密码和补丁更新基本能应对绝大多数自动化攻击。2.3 3389端口RDP 远程桌面勒索软件最爱的入口3389 是 Windows 远程桌面服务RDP的默认端口装完 Windows Server 默认就开着。它之所以高危是因为 Windows 服务器在中小企业里的占比太高而且很多人的本地 Administrator 密码就是 Admin123 这个水平。攻击者对 3389 的爆破几乎是全天候的一旦爆破成功就拿到了完整的桌面权限之后做任何操作都等于你本人在屏幕前操作。更麻烦的是勒索软件特别喜欢用 RDP 作为初始入口先进来关掉杀毒软件用系统命令做内网侦察再批量横向扩散最后锁库勒索。我见过不止一次客户信誓旦旦地说“我们没开什么服务啊”一查日志3389 端口被同一个 IP 尝试了几万次连接。这种情况其实早就该处置了只是没人看日志。如果你确实需要远程桌面几个底线必须守住。第一强制启用网络级别身份验证NLA这个选项能挡住一部分未授权连接尝试也降低老漏洞的利用风险。第二不要用内置 Administrator 作为日常登录账号新建一个独立账号并加入 Administrators 组同时把 Administrator 改名或禁用减少针对默认账号的爆破。第三设置账号锁定阈值比如连续失败 5 次锁定 15 分钟这能直接拖慢爆破速度。第四限制远程桌面的来源 IP或者统一走堡垒机再连接。第五可以考虑把默认 3389 改成高位端口虽然这不算安全机制但能明显减少自动扫描的噪音。还有一个实操细节我接触过一些远程桌面连不上的工单提示“无法加载远程桌面服务 activex 控件”或者“远程桌面客户端无法连接到远程计算机”一半以上是本地浏览器或客户端控件版本太旧、缓存不干净导致的。这类问题虽然不像安全风险那么严重但排查的时候不要第一步就去改防火墙先换一台设备或换一个 RDP 客户端试试可能就通了。2.4 3306端口MySQL 数据库端口拖库的最后一步MySQL 的默认端口是 3306数据库端口之所以高危是因为里面放的是整个系统里最值钱的数据。一旦 3306 对公网开放且口令薄弱攻击者根本不需要经过 Web 层直接用 Navicat 这类客户端远程连上来一条 SELECT 语句就能把所有用户表、订单表遍历一遍并拖走。很多早年新闻里报的“拖库”事件别以为都是从 Web 打进去的实际有相当一部分是 3306 或 6379 直接裸露在公网上。攻击者利用 3306 的思路很简单先扫描端口再用常见数据库弱口令字典尝试登录登录成功后先看 user 表看有没有高权限账号然后就是数据拷贝。这个过程中MySQL 的错误日志里会留下大量报错记录比如 Host ‘x.x.x.x’ is not allowed to connect to this MySQL server这其实就是客户端连接被拒绝的痕迹。如果环境里能看到这些日志说明攻击者已经在尝试连接了。加固 MySQL 端口重点在权限分层和网络控制。不要用 root 作为业务连接账号每个业务单独建账号只授权对应的库账号权限尽量只保留 SELECT、INSERT、UPDATE、DELETE不轻易给 DDL 或 SUPER 权限。连接来源限制在应用服务器的 IP 段内如果必须远程维护通过堡垒机中转不要直接把 3306 暴露到公网。服务侧还可以让 MySQL 只监听内网 IP修改 my.cnf 里的 bind-address比如 127.0.0.1 或内网地址打开 slow query log 用于性能排查必要时短时间开启 general log但别长期开着日志文件膨胀的速度非常吓人。数据库备份也别忘了加密否则备份文件被拖走之后一样会被直接读库。2.5 6379端口Redis 服务端口未授权访问的典型代表Redis 的高危程度这几年已经被挖矿蠕虫证明得明明白白。默认端口 6379旧版本默认没有密码3.2 之前的版本连保护模式都没有更麻烦的是 Redis 的 CONFIG SET 命令可以动态修改 dir 和 dbfilename配合 RDB 快照写文件的能力攻击者可以直接往磁盘上写文件。最经典的利用方式是写入 crontab 定时任务或者写入 SSH 的 authorized_keys从而获得服务器权限。等服务器上了贼船下一步不用猜百分之九十是植入挖矿程序然后继续扫描内网其他机器。面对 6379 端口第一原则就是别让它出现在公网。如果 Redis 只在本机使用直接在配置里 bind 127.0.0.1如果多个内网节点需要访问也尽量用内网 IP再叠加密码。密码要设置 requirepass并选择一个足够长、不是常见字典词的随机串。Redis 6 及以后版本还支持 ACL可以创建独立的最小权限账号只给运行需要的命令授权。另一个非常实用的操作是 rename-command 或者直接禁用危险命令比如在配置里加一条 rename-command CONFIG 攻击者就没法再利用 CONFIG 来改配置同理可以把 EVAL、FLUSHALL、KEYS 等命令一并处理掉。我见过不少团队把 Redis 配置得很规矩但忘了给 redis.conf 配置文件本身加权限导致服务器上的普通用户都能读到含明文密码的配置文件这也是一处隐形风险。另外Redis 默认的持久化文件 dump.rdb 也可能包含敏感数据存放目录权限同样要收一下。总体来说如果你想给 Redis 安全打分绑定内网加密码加禁用危险命令这三件事做完再配合定期备份已经能挡住绝大多数脚本化攻击。3. 网络侧与服务侧加固实操光知道哪些端口高危没有用关键在动手。这一节我把网络层和服务层两部分动作拆开讲操作顺序上建议先做网络侧收敛暴露面再做服务侧配置加固。顺序反过来也行但网络侧改完效果来得最快能立刻把公网上的自动扫描挡在门外。3.1 网络侧最容易落地白名单和端口映射怎么配我见过太多云服务器安全组里放行 0.0.0.0/0 的 22、3389 端口一问就是“临时连一下后面再改”然后这个“后面”永远没有来。网络侧加固的第一件事就是把这些管理端口22、3389、3306、6379 等的来源地址改成已知的固定运维出口 IP或者统一收敛到一个临时跳板机。安全组、防火墙规则在写的时候尽量用具体 IP 段别写 0.0.0.0/0。如果业务必须要公网访问那 80/443 照常开放后端管理端口一律只放内网或通过内网通道访问。独立服务器和 IDC 场景同理可以用 iptables 或系统防火墙按来源 IP 做限制。比如 SSH 只允许公司出口 IP 访问MySQL 只允许应用服务器内网 IP 访问Redis 只允许本机或特定业务主机访问。iptables 规则从上往下匹配白名单规则要放在前面拒绝所有规则放在最后。云上环境优先使用安全组而不是在服务器里乱配 iptables因为安全组规则出了问题回滚方便也不会出现本地防火墙和云防火墙互相打架的情况。改端口这个动作可以保留但别把它当成安全措施它顶多算“降低被无差别扫描命中的概率”真正的防线还是白名单和强认证。3.2 服务侧加固改配置、下线旧协议、开审计网络侧把外围挡住之后服务侧的配置才是决定安全下限的关键。以 SSH 为例需要在 /etc/ssh/sshd_config 里设置 PasswordAuthentication no、PermitRootLogin no再指定 AllowUsers 为具体运维账号改完以后先执行 sshd -t 校验配置确认没有语法错误再重启服务而且新开一个终端测试能连上之后再退出旧会话。这是我踩过很深的一个坑改完配置直接重启结果手滑少了一个空格sshd 直接起不来人又不在机房只能通过云控制台去救。从那以后我给自己立了一条规矩改任何服务配置先校验再重启再验证。MySQL 侧修改 my.cnf 里的 bind-address 后需要重启实例有些环境重启会引起主从切换或短暂不可用动作要放在低峰期。改完之后可以用 netstat 或 ss 再确认监听地址是否已经生效。Redis 侧改完 redis.conf 后需要 CONFIG REWRITE 或重启 redis条件允许优先用 config rewrite能避免重启导致缓存全部丢失。另一个容易被忽略的点是统一日志审计和时间同步SSH 的日志可以推到远程日志服务器Windows 的登录事件通过事件订阅集中收集时间不同步会让多台服务器上的日志顺序错乱排查攻击路径时很难对得上。这些事虽然不直接产生“安全产出”但真出事的时候干净完整的日志能省下大量的排查时间。3.3 六个端口的快速加固对照表端口服务最典型风险首选加固动作次选加固动作22SSH密码爆破、root直接登录公钥登录 禁用密码来源白名单 fail2ban80/443Web应用漏洞、路径扫描及时补丁 隐藏版本WAF/CDN 管理后台限IP3389RDP远程爆破、勒索感染强口令 NLA 锁定策略来源白名单 改端口3306MySQL弱口令、数据拖库仅监听内网 白名单最小权限账号 审计6379Redis未授权访问、写文件绑定内网 强密码禁用危险命令 ACL这张表的每一行都值得落到实际配置里但核心思路可以概括成一句话让扫描器扫不到让服务登录不上去让命令执行不了。4. 实战排查与事故复盘我被这些端口“教育”过的瞬间这部分内容跟前面偏配置的写法不同更多是排查顺序和现场处置经验。服务器已经被扫描、被爆破、甚至已经被入侵之后怎么最短时间确认情况是每个运维都应该有的基本能力。4.1 半小时内判断服务器是否被爆破或已经被入侵拿到一台有嫌疑的服务器不要慌按顺序看五个地方。第一是监听端口用 ss -lntp 或 netstat -lntp 查看有没有异常端口。第二是登录日志Linux 看 /var/log/auth.log 或执行 journalctl -u sshdWindows 则在事件查看器里筛登录失败事件 ID 4625看有没有大量来自陌生 IP 的尝试。第三是登录历史执行 last 和 w看有没有非工作时间的登录记录。第四是临时文件目录/tmp、/var/tmp 下有没有最近改动的可疑脚本、二进制文件或压缩包。第五是进程情况如果某个进程 CPU 飙高用 top 看进程名再用 ls -l /proc/[PID]/exe 查看进程的原始路径挖矿程序经常藏在 /tmp、/var/tmp、/usr/local/lib 这类位置。我上次排查一台 Redis 失陷的机器就是在 /var/tmp 找到一个名字看起来像系统库的二进制文件大小又明显不对一查进程 CPU 占用直接拉满确认是挖矿木马。另外用 ss -antp 看外向连接也很有用如果发现有进程不断向外网陌生 IP 发起连接十有八九已经中招。这种时候不要急着杀进程先保留现场把可疑文件复制一份再切断外连或者临时拉黑对应 IP最后再清理和恢复。顺序反了木马会换一个新文件重新落地等于白忙。4.2 三个低频但高杀伤的误操作案例第一件有次给客户改 SSH 端口把配置里的 Port 写错同时没有做 sshd -t 校验导致整个运维组所有成员都连不上机器最后只能通过云控制台的 VNC 进去改回来。第二件帮客户迁移数据库开发同学图省事在安全组把 3306 放开了 0.0.0.0/0同时数据库还在用弱密码第二天发现有人远程连上来执行了清理脚本把数据表直接清掉。虽然最后从备份恢复但整个过程非常惊险也让大家真正理解了数据库端口裸奔的后果。第三件一个 Redis 集群节点本来只做了内网绑定结果机房新加了一块公网网卡忘了重新配置 bind扫描器扫到未授权访问后直接感染了挖矿蠕虫最后只能隔离重装。这三个案例本质上都是同一个问题只想着“临时开一下后面再改”然后这个“后面”不是被遗忘就是被当成无所谓的小事拖过去。我后来养成了一个习惯任何公网暴露的端口都要在配置注释或云资源标签里写清楚用途和到期时间每周巡检一次看到符合“高危端口 来源不明 无到期时间”的组合立刻收紧规则。4.3 高危端口常见问题速查现象可能原因处理思路22端口连不上安全组看起来没问题SSH服务启动失败或防火墙规则冲突通过控制台/带外方式登录检查 sshd 状态与日志3306只能本机连接应用连不上bind-address 没改或账号指定了 localhost检查 my.cnf 的 bind 地址和账号 host 限制6379服务启动失败/端口被占用配置错误或旧进程残留用 ss 看端口占用查看 Redis 日志中的报错80端口返回403或安全验证页Web服务权限或防护规则限制按访问来源、WAF规则、站点配置依次排查3389经常被爆破解锁弱口令或没有锁定策略改强密码、开启锁定策略、限制来源IP需要说明的是排障时永远优先看日志而不是凭感觉改配置。很多“端口不通”的工单最后查下来都是安全组、系统防火墙、服务监听地址三层规则不一致造成的。先确认你想访问的端口在哪个地址上监听再确认中间每一层防火墙是否放行基本不会走弯路。最后再分享一点个人体会。我常在交流群里看到有人问“XX端口到底要不要关”答案其实很直接业务需要就开但开之前先把白名单、强口令、日志审计这三件事做掉。与其天天追着最新漏洞新闻跑不如先把最基础的暴露面收敛好。端口的安全说到底是一种持续的管理习惯定期巡检监听端口、清理不再使用的服务、关注组件和证书版本这些事比任何号称“一键安全”的工具都更可靠。希望这篇内容能让你下次接手服务器时少踩我踩过的那些坑。