必须严格限制服务端口、禁用ssh密码登录、降权运行服务并实时监控日志。具体包括：仅开放必需端口，绑定127.0.0.1或配合防火墙；ssh强制密钥认证、禁用root密码登录；服务以非root用户运行；日志推送远程并用fail2ban联动防护。
服务端口只开必需的，别信“默认安全”
Linux 上跑的服务，只要端口暴露在公网或内网可访问范围内，就等于把钥匙挂在门把手上。很多运维习惯性装完 nginx、sshd、mysql 就直接启动，没关掉不需要的监听地址和端口。
-
sshd 默认监听所有接口（0.0.0.0:22），如果服务器有公网 IP，又没配防火墙，暴力爆破日志每天几百条是常态
-
mysql 默认绑定 127.0.0.1 是对的，但有人手动改 bind-address = 0.0.0.0 还忘了加 skip-networking 或防火墙规则
-
redis 默认无密码、监听全网？那基本等于送数据库给扫到的人
sshd 默认监听所有接口（0.0.0.0:22），如果服务器有公网 IP，又没配防火墙，暴力爆破日志每天几百条是常态 mysql 默认绑定 127.0.0.1 是对的，但有人手动改 bind-address = 0.0.0.0 还忘了加 skip-networking 或防火墙规则 redis 默认无密码、监听全网？那基本等于送数据库给扫到的人 实操建议：
- 用
ss -tlnp或netstat -tlnp每次部署后立刻检查监听列表，重点关注非127.0.0.1的行 - 修改服务配置前先查文档确认绑定参数名：比如
nginx是listen指令，postgresql是listen_addresses，redis是bind - 配合
ufw或iptables做二次过滤，别只依赖服务自身配置
SSH 登录必须禁用密码，强制密钥+必要限制PermitRootLogin yes + PasswordAuthentication yes 是生产环境最常见也最危险的组合。不是“我密码够长就没事”，而是攻击者根本不用猜——他们批量尝试 root + 弱口令，成功率远超你想象。
常见错误现象：
- 改了
/etc/ssh/sshd_config但忘记systemctl restart sshd，配置实际没生效 - 本地私钥权限是
-rw-rw-rw-，OpenSSH 拒绝加载，报错Permissions are too open - 同时开了
PubkeyAuthentication yes和PasswordAuthentication yes，等于密钥是锦上添花，密码仍是后门
实操建议：
- 新建普通用户 +
sudo权限，禁用root密码登录（PermitRootLogin prohibit-password或no） - 生成密钥用
ssh-keygen -t ed25519，私钥存本地设为chmod 600 - 加上
MaxAuthTries 3和ClientAliveInterval 300减少暴力尝试窗口 - 测试新配置时，永远保留一个已登录的 root shell，别直接断开再连
服务进程不跑 root，能降权绝不硬扛
很多服务默认以 root 身份启动（比如早期 nginx 主进程、redis、甚至某些 Python Web 服务），一旦被利用，攻击者直接拿到最高权限。
为什么不能忍：“它自己会 drop 权限”？
瑞宝通JAVA版B2B电子商务系统
下载
瑞宝通B2B系统使用当前流行的JAVA语言开发，以MySQL为数据库，采用B/S J2EE架构。融入了模型化、模板、缓存、AJAX、SEO等前沿技术。与同类产品相比，系统功能更加强大、使用更加简单、运行更加稳 定、安全性更强，效率更高，用户体验更好。系统开源发布，便于二次开发、功能整合、个性修改。 由于使用了JAVA开发语言，无论是在Linux/Unix，还是在Windows服务器上，均能良好运行
- 不是所有服务都实现得靠谱，比如旧版
redis在daemonize yes下仍可能残留 root 进程 - 即使主进程降权，子进程或临时文件创建路径不对，依然可能写入
/root或覆盖系统文件 - 容器外部署时，
systemd的User=/Group=比服务内配置更可控
实操建议：
- 查服务文档确认是否支持非 root 运行：如
nginx看user指令，postgresql初始化必须指定-U用户 - 用
systemd托管时，在 service 文件里明确写：User=www-data、Group=www-data、NoNewPrivileges=yes - 检查进程真实 UID：
ps aux | grep nginx看 worker 进程是不是还挂着 root - 静态文件目录（如
/var/www）权限设为750，属主是服务用户，别整个777图省事
日志和失败登录必须实时盯，别等被黑了翻记录/var/log/auth.log 里每分钟几十条 Failed password for root from ... 不是“正常扫描”，是明确告诉你：有人正试图进来，而且你的防护可能漏了。
容易被忽略的点：
-
rsyslog默认不转发远程日志，所有日志都在本地磁盘，一旦服务器被控，日志可被清空 -
fail2ban规则没匹配到真实日志格式（比如用了journalctl输出而非/var/log/auth.log），等于摆设 -
sshd的LogLevel VERBOSE开太多，日志爆炸；开太低（INFO）又看不到关键字段如源 IP、认证方式
实操建议：
- 把
auth.log和syslog推到远程日志服务器（哪怕只是另一台内网小 VPS），用rsyslog的action(type="omfwd"配置 -
fail2ban启动后用fail2ban-client status sshd确认 jail 是否 running，再看journalctl -u fail2ban有没有解析失败报错 - 对高频失败 IP，与其靠
fail2ban封，不如直接在iptables里-j DROP一批段（比如116.255.224.0/19），减少内核层开销
该关的端口早关，该降的权限早降，该转的日志早转——这些动作本身不难，难的是每次上线新服务时都条件反射做一遍，而不是想着“下次再加固”。
