服务器安全一键配置的核心是先拒后放、最小授权：先拒绝所有入站流量，再按业务需求逐一放行特定端口和来源IP，这是配置后端服务器安全组的唯一正确基线。
安全组究竟在保护什么
安全组是云服务器最外层的虚拟防火墙,位置介于公网和后端服务器之间，所有流量想要到达你的服务器，必须先过安全组这一关。
行业共识认为,安全组的价值在于把攻击面压缩到最小，后端服务器不像Web前端那样需要暴露80和443端口，通常只需要对特定来源开放特定端口，比如一台数据库服务器，只需要让同一VPC内的应用服务器访问3306端口，其他来源全部拒绝。
安全组的工作方式有两个核心特性：
- 有状态：允许出站流量会自动允许对应的入站响应，不需要额外配置回程规则
- 规则叠加：同方向多条规则按优先级从高到低匹配，匹配即生效，后续规则不再检查
搞懂这两点,你就明白为什么很多配置问题出在回程方向，也明白为什么规则顺序很重要。
服务器安全组怎么配置才算到位
后端服务器的安全组配置,建议遵循以下思路：先梳理业务流量拓扑，再动手配规则，具体分四步走。
第一步：梳理业务访问关系
在配置之前,先问自己三个问题：
- 谁需要访问这台服务器
- 访问哪些端口
- 通过什么协议访问
常见场景如下：
- 应用服务器访问数据库：内网IP加3306端口，MySQL或PostgreSQL
- 运维人员管理服务器：办公网出口IP加22端口，SSH
- 监控系统采集指标：监控节点IP加9100或10080端口，HTTP
内部服务的访问来源尽量写内网IP段,不要用0.0.0.0/0，这是最简单也最有效的收敛手段。
第二步：按最小权限原则放行
在控制台操作时,路径大致为：进入云服务器控制台，找到网络与安全组，选择对应安全组，编辑入方向规则，然后参考下面这个清单逐一放行：
- 放行22端口,来源写你办公网的固定IP，或者堡垒机IP
- 放行3306端口,来源写应用服务器所在子网的CIDR
- 放行ICMP协议,用于测试连通性，来源限定运维IP
每个规则做完后,想想是否真的需要这个来源范围，能缩小就缩小。
第三步：设置默认拒绝兜底
安全组通常在规则列表末尾有一条默认拒绝规则,对应的是拒绝所有流量，这条规则建议保留，它负责兜底。缺少默认拒绝规则，等于所有未匹配到的流量全部放行，那你前面的精细配置就白做了。
新建的安全组默认行为是拒绝所有入站流量,很多人在这个环节犯的错是：为了图省事，直接把0.0.0.0/0全部放行到22端口，或者直接放行所有端口，这种做法等于把大门钥匙挂在门口，攻击者只需要扫一遍端口就能找到入口。
第四步：验证规则是否按预期工作
配置完成后,不能只看规则列表就收工，验证方式很简单：
- 在本机用telnet测试目标端口是否可达,比如
telnet 服务器IP 3306 - 从非授权IP尝试连接,确认被拒绝
- 检查云平台提供的安全组流量日志,观察是否有异常来源的请求
有个细节容易被忽略：安全组规则修改后即时生效，但已建立的连接不会中断，如果你改了端口放行范围，老连接可能还挂着，测试时注意用新连接验证。
安全组配置错误排查的正确思路
配置安全组最大的痛点不是不会配,而是配完之后服务依然连不上，排查的顺序非常重要，按下面的清单来，能省下大量时间。
常见配置错误清单
- 放行端口和实际服务监听端口不一致,服务监听在127.0.0.1，外部自然连不上
- 来源范围写错,比如只放行了某个单独的IP，而客户端访问时走的是NAT出口IP
- 协议类型选错,TCP服务只放行了UDP
- 优先级冲突,多条规则同时匹配，前面一条拒绝规则把流量拦截了
- 出方向规则被误删或收紧,导致响应流量发不出去
这些错误里,最常见的其实是协议类型和端口对不上，顺手写了个规则，TCP写成UDP，排查半天才发现是这里的问题。
排查操作建议
打开命令行,按顺序执行以下操作，假设要测试的是后端服务器的8080端口：
telnet 目标服务器IP 8080
如果卡住没反应,说明流量根本没到服务器，或者安全组拦截了，这时候去安全组页面检查规则，看端口、协议、来源IP是否全部匹配。
如果telnet显示连接成功但服务无响应,检查服务器内部监听情况：
netstat -tlnp | grep 8080
看进程是否真的在监听这个端口,很多情况是安全组放行了，但服务本身挂了或者监听地址写错了。
最后用curl测试实际效果,比如curl -I http://目标IP:8080，如果返回正常，说明业务链路已经通了。
规则优先级的那点事
安全组规则的优先级普遍采用数值越小越优先的机制,具体规则顺序大致为：高优规则先匹配，低优规则后匹配，最后是默认规则兜底。
一个典型的错误做法是：先配置了一条拒绝某来源IP访问22端口的规则，又在后面加了一条放行所有来源访问22端口的规则，如果你把拒绝规则放在前面，那放行规则永远不生效，攻击来源照样被拦截。需要限制的规则要放在放行规则前面
。
设计安全组规则时,建议按这样的顺序排列：
- 最高优先级：拒绝高危端口的外部访问，比如3389、6379
- 中间优先级：放行特定业务来源的访问
- 最低优先级：默认拒绝所有入站
SSH端口被封时的急救流程
这是后端服务器最让人焦虑的场景：安全组规则调整失误，把自己锁在门外，SSH彻底连不上，别慌，有路可走。
云控制台通常提供两种救援入口：
- VNC登录：直接在浏览器里打开服务器终端，不经过网络，不受安全组影响
- 重置安全组：控制台提供恢复到默认规则或移除所有自定义规则的功能
使用VNC登录进去后,检查SSH服务状态，再用命令行调整安全组配置，如果你使用的是云服务商CLI工具，可以直接命令行修改安全组规则，前提是你的CLI凭证还有效。
急救之后要做的第一件事是把对外IP换成弹性IP或绑定到负载均衡后面,不要直接暴露原始公网IP。安全组是最后一道防线，而不是唯一防线。
进阶加固让安全组自己干活
基础配置完成后,还有几件事值得做，能让你的安全组配置更体系化。
按角色拆分安全组
不要把所有的后端服务器塞进同一个安全组,按角色拆开，数据库一组，应用一组，缓存一组，每组独立维护规则，互不影响，规则变更的影响面自然就变小了。
- 数据库安全组：只放行应用服务器所在网段的3306端口
- 应用安全组：只放行负载均衡和运维IP的对应端口
- 缓存安全组：只放行应用服务器所在网段的6379端口
这样分组之后,新增一台服务器只需要加入对应的安全组，不用重写规则。
用弹性IP隔离管理面
后端服务器的公网访问需求一般很小,能用内网通信用内网通信，如果必须暴露公网，建议单独绑定弹性IP，让安全组只对这个IP开放管理端口，业务内网走内网网卡，管理流量和业务流量分离，安全组规则更容易收敛。
定期复查规则冗余
安全组的规则会越积越多,有些规则其实已经不再使用，每隔一段时间做一次检查，建议一个季度一次：
- 找出所有来源为0.0.0.0/0的规则，逐一确认是否真有必要
- 找出不再使用的端口,直接删除对应规则
- 合并重复或相似的规则,减少后期维护成本
顺带说一句,安全组本身是免费功能，不会额外计费。配置错误或过度放行带来的服务器安全问题，远比花在配置上的时间成本高得多，提到价格，这个环节只要你之前没买过付费的云防火墙服务，预算上是零负担。
关于酷番云服务器便宜与好用这类问题并不适用,安全组配置无论服务器新购还是续费都支持按需调整，低频业务负载下配置好后几乎不用再做大幅度改动。
暴力破解与登录防护
安全组对暴力破解的防护能力有限,它只能限制来源IP，不能识别身份验证失败次数的多少，配合以下措施更有效：
- 修改SSH默认端口,降低被扫描概率
- 使用密钥登录,禁用密码登录
- 开启云平台提供的防暴力破解功能,或自行安装fail2ban，自动封禁频繁登录失败的IP
安全组负责边界控制,系统内部防护负责进程安全，两者配合才能形成完整的安全体系。
Windows和Linux在安全组场景里的差异
不同操作系统对安全组的需求差别不小。
Windows服务器需要额外注意远程桌面端口3389的暴露风险,这个端口是扫描器重点关注对象，安全组规则里限制来源IP范围是基本要求，开启RDP时，配合限制登录来源和账户锁定策略，能挡住相当一部分攻击。
Linux服务器则主要关注22端口和常见应用端口,排查方面的另一个常用命令是iptables -L -n，查看系统自带防火墙，顺便一提，简米云轻量应用服务器安全组配置自带基础规则模板，只需按需勾选，适合小规模业务快速上线。
Web服务场景下,应用服务器上跑Nginx或Apache，安全组放行80、443即可，数据库服务器通常部署在内网，只允许应用服务器所在网段访问数据库端口，如果业务使用宝塔面板等可视化工具，安全组需要额外放行面板配置的端口段。
云平台控制台在配置安全组时的操作路径差异不大,基本都在网络或安全分类下，界面文案略有区别，但漫游起来很快，如果你是新手，先在测试环境把规则逻辑跑通，再正式应用到生产环境。
服务器安全组配置常见问题与避坑路线
安全组的规则为什么有时候不生效？
最常见原因是规则优先级不对,或者多条规则互相覆盖，检查策略是先看所有规则，按优先级排列，确认没有一条拒绝规则挡在前头，还可能是协议类型匹配不一致，TCP和UDP分别放行才能覆盖完整。
放了端口给内网服务器，但另一台服务器还是连不上？
访问不通时,优先排查来源IP和端口协议是否精确匹配，可能你放行的是某个内网IP的访问，但发请求的服务器出口IP是另一个IP，尤其是经过NAT或负载均衡时，还有一点不能忽略：如果发请求的那台机器也有安全组，它的出方向规则必须允许访问目标端口。
修改安全组规则会影响现有连接吗？
不会中断已经建立的连接,因为安全组是有状态的，新规则只对新建连接生效，已有连接保持原状直到断开，因此修改完规则后，建议等待一段时间或主动断开重连，再用新连接验证。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/582640.html
