上周隔壁公司IT小哥凌晨三点被电话叫醒，说官网首页被替换成‘恭喜中奖’页面。查了一圈，发现是后台管理密码还用着‘123456’，SSH端口开着默认22，连个登录失败锁定都没配——这不是加固，这是摆盘请客。
密码不是越长越安全，而是得管住不用的
很多人觉得‘P@ssw0rd2024!’很牛，结果写在便签贴显示器边框上。真正该做的：删掉所有没用的账号（比如测试时建的admin_test），禁用root远程SSH登录，改用普通用户+sudo；密码长度只是基础，关键得配合登录失败5次锁30分钟，Linux下可以用pam_faillock，Windows组策略里也有对应设置。
端口不是关得越多越好，而是只开必须的
某客户把服务器3389、22、80、443全开着，还在防火墙里加了‘允许所有内网IP访问’。结果内网一台中了木马的笔记本成了跳板。建议：外网只放行443和必要API端口，其他一律DROP；内网也别大喇喇全通，用白名单限定到具体IP段，比如运维机只允许从192.168.10.0/24访问SSH。
补丁不是等通知才打，而是得盯住变化
去年Log4j爆出来那天，有台老系统因为‘运行稳定’一直没升级，结果三天后就被挖矿脚本塞满CPU。现实点的做法：把系统自带更新源换成国内镜像（比如清华源），每周五下班前花10分钟跑一遍apt list --upgradable或yum check-update，看到关键包就顺手apt upgrade -y。别信‘等测试完再上线’，小范围先滚一台试试，比全站瘫痪强。
日志不是攒着看，而是得有人真看
装了ELK堆栈，结果没人看Kibana面板，告警邮件进了垃圾箱。简单点：用grep 'Failed password' /var/log/auth.log | tail -20每天扫一眼有没有异常IP猛试密码；Windows就打开‘安全日志’，筛选事件ID 4625，重点盯反复失败的账户名。发现192.168.5.22连续试了17次，立刻加进防火墙黑名单：
iptables -A INPUT -s 192.168.5.22 -j DROP备份不是存本地就完事，而是得能真恢复
某电商把数据库备份脚本写在crontab里，但从来没验证过tar包能不能解压。某天磁盘坏了，恢复时才发现压缩命令漏写了-f参数，生成的是一堆0字节文件。建议：每月挑一个周末，拿备份文件在测试机上走一遍完整还原流程，从解压、导入、启动服务到打开网页确认数据正常。别怕麻烦，真出事时你最感谢的就是那个周六多花了半小时的人。