
核心要点(TL;DR)
- 新机上线第一件事是收敛安全组,只放行必要端口与可信源IP。
- 禁用root密码登录、改用密钥并限制来源,可挡掉绝大多数爆破。
- 基线加固要可复现:用脚本固化检查项,而不是凭记忆逐条敲。
- 日志与告警必须在上线前接好,否则出事时没有取证依据。
很多事故不是被高级漏洞打穿的,而是新机上线时安全组全开、root密码登录、系统补丁没打,被扫描器顺手拿下。云服务器安全部署的价值在于:用一份可复现的清单,把暴露面在业务上线前压到最小。下面按执行顺序给出具体命令与检查项,照着做一遍即可。
第一步:收敛安全组,先做最小暴露
安全组是云上第一道边界,原则是默认拒绝、按需放行。新机默认规则常常放行全部端口,务必先清理。
- 只对
0.0.0.0/0放行 80/443 等业务端口; - SSH(22)改为仅允许办公固定IP或跳板机地址;
- MySQL(3306)、Redis(6379) 等绝不对公网开放,走内网或安全组互访;
- 删除默认的“全部放行”规则,入方向最后一条为拒绝。
配置后用外部端口扫描验证:nmap -Pn -p- 你的公网IP,确认只看到预期端口。安全组规则变更要记录时间与原因,方便后续审计回收。
第二步:SSH 加固,挡住绝大多数爆破
先建普通用户并给 sudo 权限,写入公钥并验证可登录,再改配置,避免把自己锁在门外。
useradd -m -s /bin/bash deploy usermod -aG sudo deploy mkdir -p /home/deploy/.ssh && chmod 700 /home/deploy/.ssh # 写入公钥后 chmod 600 /home/deploy/.ssh/authorized_keys chown -R deploy:deploy /home/deploy/.ssh
编辑 /etc/ssh/sshd_config,设置以下项:
PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes MaxAuthTries 3 LoginGraceTime 20 AllowUsers deploy
执行 sshd -t 检查语法,再 systemctl reload sshd。保留一个已登录会话,另开窗口验证新配置可登录后再关闭旧会话。
第三步:系统更新与账号清理
补丁是成本最低的防护。上线前完成一次全量更新并开启自动安全更新:
apt update && apt upgrade -y # Debian/Ubuntu yum update -y # CentOS/RHEL apt install -y unattended-upgrades # 自动安全更新
账号侧检查:
awk -F: '==0{print }' /etc/passwd确认只有 root 为 UID 0;awk -F: '==""{print }' /etc/shadow排查空口令账号;- 删除或锁定无用账号:
usermod -L 用户名; - 检查
/etc/sudoers与 sudoers.d,移除多余授权。
第四步:基线加固与文件权限
基线项建议脚本化,避免换机重来。核心检查如下:
| 检查项 | 命令/做法 | 期望 |
|---|---|---|
| SUID 文件 | find / -perm -4000 -type f | 仅保留已知必要项 |
| 关键目录权限 | ls -ld /etc /tmp /var/tmp | /tmp 带 sticky 位 |
| 内核参数 | sysctl 关闭 IP 转发、开启 SYN Cookie | 写入 /etc/sysctl.d/ |
| 无用服务 | systemctl list-unit-files --state=enabled | 关闭 telnet、rsh 等 |
| 计划任务 | crontab -l 与 /etc/cron.* | 无未知条目 |
主机防火墙做第二层兜底,例如 ufw 仅放行 22/80/443,并与安全组规则保持一致。防护建议:这类基线检查与端口暴露监控可以借助 AegisX 的主机安全基线能力定期核验,减少人工比对成本。
第五步:日志审计与上线前复核
没有日志,入侵后无法定位入口。至少做到:
- 开启 auditd,监控
/etc/passwd、/etc/sudoers、authorized_keys 变更; - rsyslog 转发 auth.log 到集中日志服务,保留 30 天以上;
- 对 SSH 登录失败次数、新增账号、计划任务变更设置告警。
上线前复核清单:安全组无全开规则、root 禁止远程、密码登录已关、补丁已打、无空口令账号、防火墙规则与安全组一致、日志已接入。云服务器安全部署不是一次性动作,建议把上述检查写成脚本,纳入每次新机交付流程,并在扩容、换IP、改网络后重新跑一遍。
行动建议:今天就挑一台新机,按五步走完并记录耗时;把命令固化成 init-secure.sh,下次上线直接执行,安全基线才不会随人员流动而退化。
常见问题(FAQ)
云服务器刚买回来,安全组应该怎么配才不算过度开放?
原则是默认拒绝、按需放行。先只保留业务必需端口(如80/443)并对全网开放,管理端口22/3389改为仅允许办公固定IP或跳板机地址,其余全部拒绝。数据库、Redis等内部端口不要对0.0.0.0/0开放,走内网或安全组互访。上线后再按实际访问日志逐步收紧,避免一次性放开后无人回收。
为什么建议禁用root远程登录,具体怎么操作?
root是爆破的首要目标,禁用后攻击面显著缩小。做法是先创建普通用户并配置sudo,把公钥写入该用户authorized_keys,验证可登录后编辑/etc/ssh/sshd_config设置PermitRootLogin no、PasswordAuthentication no,再执行sshd -t检查语法并reload服务。务必保留一个已登录会话,防止配置错误把自己锁在门外。
Linux基线加固有没有必要逐条手工做?
不建议纯手工。手工容易漏项且无法复现,换一台机器又要重来。更稳妥的做法是把检查项写成脚本或使用开源基线工具(如lynis、OpenSCAP)定期跑,输出差异报告。关键项包括账号与空口令、SUID文件、关键目录权限、内核参数、无用服务与计划任务,形成清单后纳入上线流程。
新机上线前日志和告警要做到什么程度?
至少保证登录日志、sudo操作、关键服务日志被集中收集并保留30天以上,SSH登录失败次数、新增账号、计划任务变更能触发告警。可用rsyslog转发到日志服务,配合auditd记录敏感文件改动。没有日志,入侵后无法判断入口和影响范围,恢复也只能整机重装。
安全组和主机防火墙需要同时配置吗?
建议两层都做。安全组是云平台层面的第一道边界,主机防火墙(firewalld/iptables/ufw)是第二道,二者互补:安全组误配或实例换网络时,主机防火墙仍能兜底。实践中安全组做粗粒度端口收敛,主机防火墙做细粒度来源限制与服务级控制,规则变更都要留记录。