深色模式
安全组配置
摘要：安全组就是云上的分布式防火墙，作用在实例网卡层。本文讲清「默认拒绝 + 白名单」的配置思路、出/入方向规则的写法，以及改完之后如何验证连通性而不把自己锁在外面。
适用环境
bash
# 本地终端 + 一台目标云服务器
which nc curl ssh
nc -h 2>&1 | head -2
# 目标机上可选：sudo apt install -y tcpdump1
2
3
4
2
3
4
操作步骤
一、理解两条基本事实
- 安全组是白名单机制：没有明确允许的流量，默认拒绝。所以不存在「加一条拒绝规则去屏蔽某人」这种写法——删掉放通规则即可。
- 安全组是有状态（stateful）的：允许入方向的请求，其返回流量自动放行，不需要再配出方向规则。
二、创建安全组并写入最小规则
以 AWS CLI 为例：
bash
# 创建安全组（绑定到指定 VPC）
aws ec2 create-security-group --group-name web-sg \
--description "web tier" --vpc-id vpc-0abc123
# 放通 80/443 给全网
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 \
--protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 \
--protocol tcp --port 443 --cidr 0.0.0.0/0
# SSH 只放通办公网出口 IP（务必替换为你自己的出口）
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 \
--protocol tcp --port 22 --cidr 203.0.113.10/321
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
三、用「安全组引用安全组」代替写 IP
多层架构里，应用层只对负载均衡放通，不写死 IP：
bash
# app-sg 只接受来自 alb-sg 的 8080 流量
aws ec2 authorize-security-group-ingress --group-id sg-app \
--protocol tcp --port 8080 --source-group sg-alb
# db-sg 只接受来自 app-sg 的 3306 流量
aws ec2 authorize-security-group-ingress --group-id sg-db \
--protocol tcp --port 3306 --source-group sg-app1
2
3
4
5
6
7
2
3
4
5
6
7
四、出方向也要收口
默认出方向全放通，意味着机器被入侵后可以自由外连（下载木马、外传数据）：
bash
# 删除默认全放通出方向规则
aws ec2 revoke-security-group-egress --group-id sg-app \
--protocol all --cidr 0.0.0.0/0
# 只放通必要的：DNS 解析 + 内网 + 软件源/对象存储
aws ec2 authorize-security-group-egress --group-id sg-app --protocol udp --port 53 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-egress --group-id sg-app --protocol tcp --port 443 --cidr 0.0.0.0/01
2
3
4
5
6
2
3
4
5
6
危险
修改生效中的 SSH 入方向规则前，先保持当前连接不退出，另开一个终端测试新连接成功，再断开旧连接。这是防止自己被锁在门外的唯一可靠办法。
五、验证连通性
bash
# 从本地测试端口是否放通（超时 = 未放通）
nc -vz -w 3 <公网IP> 80
nc -vz -w 3 <公网IP> 22
# 从另一台机器测内网互通
nc -vz -w 3 10.0.1.20 3306
# 本机自查：目标端口是否有进程在听（安全组放通但没服务也会失败）
ss -lntp | grep -E ":80|:3306"
# 抓包确认流量到底到没到网卡
sudo tcpdump -i any -nn host <对端IP> and port 3306 -c 51
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
六、规则治理小技巧
bash
# 给规则写清楚描述，避免三个月后不敢删
aws ec2 describe-security-group-rules --filter Name="group-id",Values="sg-0abc123" \
--query 'SecurityGroupRules[].[FromPort,ToPort,CidrIpv4,Description]' --output table
# 定期审计：找出对所有 IP 放通 22/3306/6379 的高危规则
aws ec2 describe-security-group-rules \
--query 'SecurityGroupRules[?CidrIpv4==`0.0.0.0/0` && (FromPort==`22` || FromPort==`3306` || FromPort==`6379`)]'1
2
3
4
5
6
7
2
3
4
5
6
7
验证
- [ ] 高危端口（22/3306/6379/27017）没有对
0.0.0.0/0放通 - [ ] 每条规则都有描述，能看出用途与负责人
- [ ] 内网分层（web → app → db）使用安全组引用而非固定 IP
- [ ] 从外部
nc -vz测试结果与预期一致，且应用自身可访问
常见坑
- 把安全组当黑名单：以为加一条「拒绝 1.2.3.4」就能封 IP，结果毫无效果，正确做法是不给它放通。
- 改 SSH 规则同时断开连接：规则一改错就永久失联，只能走云控制台的 VNC / 串行控制台救场。
- 只配入方向不管出方向：主机被控后能自由外连，出方向收口能显著抬高攻击成本。
- 安全组与本机 iptables 双重叠加：排查时容易互相甩锅，建议二选一为主，另一处保持宽松并记录。
- 一台机器挂太多安全组：规则叠加后难以推断，建议按角色一个安全组，最多两三个。