一文搞懂 VPS 安全设置:Linux 服务器安全加固实用笔记

很多买了 VPS 装好 Linux 系统之后,就开始搭建各种工具服务、部署网站系统等,但其实开始之前,有个更加的重要工作,那就是服务器的“安全加固”。因为只要你的服务器拥有公网 IP,并且开放在互联网中,它就已经开始面临端口扫描、密码爆破、漏洞等各种风险了。

服务器安全并不一定需要安装一堆复杂的软件,很多时候,真正重要的是做好基础配置。

今天阅读了一份国外网友分享的 How-To-Secure-A-Linux-Server,地址如下:

内容很长,为了方便学习,我提取了其中的“技术干货”,将它整理成了实用笔记。

一、开始之前:先做好这几件事

1. 系统保持更新

Debian / Ubuntu:

sudo apt update && sudo apt upgrade

系统本身存在已知漏洞,再多安全配置也无法完全弥补。


2. 尽量只安装需要的软件

服务器安装的软件越多:

  • 可能运行的服务越多
  • 暴露的端口越多
  • 潜在攻击面也越大

原则很简单:

只安装真正需要的软件和服务。


3. 修改 SSH 前,务必保持第二个终端连接

修改 SSH 配置时,建议:

终端 1:保持当前 SSH 连接
终端 2:测试新的 SSH 配置

不要修改配置后立刻关闭当前 SSH。

万一新配置无法登录,还可以通过原来的终端恢复。


二、使用 SSH 密钥登录

相比传统的:

用户名 + 密码

SSH 密钥登录更加安全。

推荐使用 Ed25519 密钥。

1. 在本地电脑生成 SSH 密钥

注意:在自己的电脑上执行,不是在服务器上。

ssh-keygen -t ed25519

默认会生成:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

其中:

id_ed25519

是私钥,必须自己保存好。

id_ed25519.pub

是公钥,需要上传到服务器。


2. 使用 ssh-copy-id 上传公钥

ssh-copy-id user@server

例如:

ssh-copy-id root@1.2.3.4

或者:

ssh-copy-id username@1.2.3.4

上传完成后,测试:

ssh user@server

确认能够正常使用密钥登录。


三、创建专门的 SSH 用户组

原指南建议创建一个专门用于 SSH 登录的用户组。

这样可以方便控制:

哪些用户允许 SSH 登录服务器。

1. 创建 sshusers 用户组

sudo groupadd sshusers

2. 将允许 SSH 登录的用户加入该组

例如:

sudo usermod -a -G sshusers user1

多个用户:

sudo usermod -a -G sshusers user1
sudo usermod -a -G sshusers user2

以后如果需要禁止某个用户 SSH 登录,只需要将其移出对应用户组。


四、加固 SSH 配置

SSH 配置文件:

/etc/ssh/sshd_config

修改之前,先备份:

sudo cp --archive /etc/ssh/sshd_config /etc/ssh/sshd_config-COPY-$(date +"%Y%m%d%H%M%S")

这个命令会自动生成一个带时间的备份文件。


推荐重点检查的 SSH 配置

编辑:

sudo nano /etc/ssh/sshd_config

1. 禁止 root 直接登录

PermitRootLogin no

以后使用:

普通用户 SSH 登录
        ↓
sudo 获取管理员权限

2. 禁止 SSH 密码登录

确认 SSH 密钥登录正常后:

PasswordAuthentication no

这样可以避免大量密码爆破攻击。

:warning: 一定要先测试 SSH 密钥能够登录,再关闭密码登录。


3. 只允许 sshusers 组登录

AllowGroups sshusers

这样只有加入:

sshusers

用户组的账户可以 SSH 登录。


4. 修改 SSH 默认端口?

很多人喜欢修改:

22

为其他端口。

这可以减少一些自动扫描和日志噪音,但不能替代真正的安全措施。

真正重要的还是:

  • SSH 密钥
  • 禁止密码登录
  • 限制登录用户
  • Fail2Ban
  • 防火墙

修改配置后先检查语法

千万不要直接重启 SSH。

先执行:

sudo sshd -t

没有错误,再重启:

sudo service ssh restart

或者:

sudo systemctl restart ssh

五、SSH 可以增加 2FA 双重认证

如果服务器安全要求比较高,可以给 SSH 加上 Google Authenticator。

安装:

sudo apt install libpam-google-authenticator

然后使用需要开启 2FA 的普通用户执行:

google-authenticator

:warning: 不建议直接在 root 用户下操作。

配置过程中会生成:

  • 二维码
  • 密钥
  • Emergency Scratch Codes(紧急恢复码)

紧急恢复码一定要保存。


修改 PAM 配置

先备份:

sudo cp --archive /etc/pam.d/sshd /etc/pam.d/sshd-COPY-$(date +"%Y%m%d%H%M%S")

然后在:

/etc/pam.d/sshd

加入:

auth required pam_google_authenticator.so nullok

然后修改:

/etc/ssh/sshd_config

设置:

KbdInteractiveAuthentication yes

检查 SSH 配置:

sudo sshd -t

重启:

sudo service ssh restart

六、限制哪些用户可以使用 sudo

服务器上的用户不应该默认拥有管理员权限。

首先查看:

sudo

组中的用户:

getent group sudo

或者:

grep '^sudo:' /etc/group

只有真正需要管理服务器的用户才应该拥有 sudo 权限。


添加 sudo 权限

Debian / Ubuntu:

sudo usermod -aG sudo username

移除 sudo 权限

sudo deluser username sudo

安全原则:

能不给管理员权限,就不要给。


七、限制 su 使用

su 可以让用户切换身份,例如:

su -

直接切换到 root。

原指南建议限制:

只有特定用户才能使用 su。

通常个人 VPS 如果已经使用:

sudo

就没有必要让所有用户都能随意:

su root

八、配置 NTP 时间同步

服务器时间错误可能影响:

  • 日志
  • SSL 证书
  • 双因素认证
  • 安全审计

检查时间同步状态。

如果使用 NTP:

sudo ntpq -p

可以查看服务器当前同步的时间源。


九、保护 /proc 进程信息

Linux 默认情况下,本地用户可能看到其他用户的进程信息。

可以考虑使用:

hidepid=2

限制 /proc 信息。

目标是:

普通用户只能看到自己的进程。

但需要注意:

:warning: 部分 systemd 或软件环境可能受到影响。

所以服务器运行重要业务时,不建议直接修改,需要先测试。


十、配置 UFW 防火墙

UFW 是 Debian / Ubuntu 上非常容易使用的防火墙工具。

安装:

sudo apt install ufw

1. 默认拒绝所有入站连接

sudo ufw default deny incoming

2. 默认允许出站连接

普通服务器通常可以:

sudo ufw default allow outgoing

3. 开放 SSH

:warning: 开启 UFW 前必须先允许 SSH,否则可能把自己锁在服务器外。

如果使用默认 22 端口:

sudo ufw allow 22

或者:

sudo ufw allow ssh

如果 SSH 使用其他端口,例如:

2222

则:

sudo ufw allow 2222/tcp

4. 开放网站端口

HTTP:

sudo ufw allow 80/tcp

HTTPS:

sudo ufw allow 443/tcp

5. 启用防火墙

确认规则无误后:

sudo ufw enable

查看状态:

sudo ufw status verbose

十一、使用 Fail2Ban 防止暴力破解

防火墙只能决定:

哪个端口开放

但是 SSH 开放之后,仍然可能有人不断尝试:

用户名:admin
密码:123456

用户名:root
密码:password

用户名:ubuntu
密码:123456

Fail2Ban 可以监控日志。

如果某个 IP 多次登录失败:

多次失败
↓
达到阈值
↓
自动封禁 IP

安装:

sudo apt install fail2ban

查看状态:

sudo fail2ban-client status

查看 SSH Jail:

sudo fail2ban-client status sshd

不建议直接修改 jail.conf

建议:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

然后修改:

/etc/fail2ban/jail.local

例如启用 SSH:

[sshd]
enabled = true

十二、使用 CrowdSec 进行入侵检测

原指南也介绍了 CrowdSec。

它和 Fail2Ban 类似,但更加偏向:

日志分析
+
攻击行为识别
+
威胁情报

对于普通 VPS 用户:

Fail2Ban

已经比较容易上手。

服务器较多或者希望进一步研究入侵检测,可以考虑 CrowdSec。


十三、定期查看服务器监听端口

这是非常重要的一个习惯。

执行:

sudo ss -lntup

可以查看:

服务器正在监听哪些端口

例如:

*:22
*:80
*:443

参数含义:

l = 显示监听端口
n = 不解析服务名称
t = TCP
u = UDP
p = 显示对应进程

如果发现:

自己不知道的端口

或者:

自己不认识的程序

就需要进一步检查。


十四、使用 AIDE 监控文件是否被篡改

AIDE 是 Linux 文件完整性监控工具。

它可以记录重要文件的:

  • 哈希值
  • 文件大小
  • 权限
  • 属性

之后再次检查。

如果文件发生变化,就会提示。

安装:

sudo apt install aide

初始化数据库:

sudo aideinit

初始化后可以检查:

sudo aide.wrapper --check

如果系统文件没有变化,会显示:

AIDE found NO differences between database and filesystem

需要注意:

系统正常升级也可能导致文件发生变化。

所以发现变化不代表一定被入侵。


十五、使用 Logwatch 分析系统日志

服务器每天都会产生大量日志。

Logwatch 可以自动分析日志,并生成报告。

可以关注:

  • SSH 登录
  • 登录失败
  • 系统异常
  • 服务错误

如果服务器配置了邮件发送功能,还可以定期收到安全报告。


十六、定期检查服务器开放端口

除了:

ss -lntup

还应该重点检查:

MySQL      3306
Redis      6379
MongoDB    27017
PostgreSQL 5432

这些端口是否直接暴露在公网。

很多数据库并不需要公网访问。

更安全的方式是:

数据库
↓
只监听 localhost

或者:

数据库
↓
只允许内网访问

十七、使用 Lynis 进行 Linux 安全审计

Lynis 是非常实用的 Linux 安全审计工具。

可以检查:

  • SSH 配置
  • 用户账户
  • 防火墙
  • 文件权限
  • 系统服务
  • 内核参数
  • 安全策略

安装完成后,可以运行:

sudo lynis audit system

扫描完成后,Lynis 会给出:

Warnings
Suggestions
Hardening Index

需要注意:

Lynis 的建议并不是全部都必须修改。

正确的方式是:

扫描
↓
阅读建议
↓
理解配置作用
↓
确认是否适合自己的服务器
↓
再修改

十八、自动安装安全更新

系统长期不更新,已知漏洞可能一直存在。

Debian / Ubuntu 可以考虑:

unattended-upgrades

自动安装安全更新。

安装:

sudo apt install unattended-upgrades

配置:

sudo dpkg-reconfigure --priority=low unattended-upgrades

但是需要注意:

自动更新可能导致:

软件升级
↓
服务配置变化
↓
兼容性问题

因此:

个人 VPS

可以考虑自动安装安全更新。

生产服务器

需要结合实际业务环境决定。


十九、定期检查服务器账户

查看系统账户:

cat /etc/passwd

重点关注:

自己不认识的用户

查看最近登录记录:

last

查看用户最后登录时间:

lastlog

如果发现:

陌生账户
陌生 IP
异常登录时间

就需要进一步检查。


二十、不要盲目执行网上的一键脚本

很多 VPS 教程都会让你执行:

wget xxx.sh && bash xxx.sh

或者:

curl xxx.sh | bash

但必须明白:

你执行脚本,就等于允许脚本在你的服务器上执行各种操作。

尤其是:

curl | bash

执行之前最好:

下载
↓
查看源码
↓
确认项目来源
↓
确认脚本功能
↓
再执行

不要只因为:

GitHub Star 很多

就完全相信。