网络安全运维一直是被误解最深的岗位很多新人以为这份工作就是装个防火墙、装个杀毒软件剩下的时间喝喝茶。真上手之后才发现白天被各种合规检查追着跑半夜被告警电话叫起来重启服务第二天还要顶着黑眼圈写复盘报告。我做了这些年运维最深的体会是想告别996靠的不是增加工时而是把那些反复发生的“救火”场景用十个核心操作提前消解掉。这篇分享我就把这十个网络安全运维操作完整拆开从账户口令到日志监控从端口收敛到备份恢复每个操作都会讲清楚原理、步骤、命令和最容易踩的坑。零基础的人照着做也能把一台机器的安全水平拉起来有经验的人可以当一次系统自查。这十件事做完不是说你从此不加班而是你加班的次数会肉眼可见地变少因为大部分事故在你还没睡觉前就被例行操作拦住了。1. 先看思路安全运维为什么能治加班1.1 救火型运维的死循环一个典型的“救火型”运维节奏是这样的白天收到漏洞通报临时开会确定修复方案晚上业务低峰期上线补丁结果补丁和现有环境冲突回滚第二天业务方反馈服务变慢排查发现是日志把磁盘写满了刚清理完日志又收到暴力破解告警发现某个测试账号密码过于简单被扫了。一整天下来什么都没做成但每一步都很忙。这种忙的本质是没有建立基线。所谓基线就是一台机器在正常情况下应该长什么样有哪些用户、开放哪些端口、跑哪些服务、日志存在哪、告警阈值是多少。没有基线任何异常都需要临时判断任何判断都会消耗时间任何误判都会引发连锁故障。所以后面讲的所有操作核心都是在帮你把“不确定”变成“确定”。1.2 从“看运气”到“看清单”我做运维的前两年最怕的就是“未知的未知”——不知道哪个端口对外开着不知道哪个账号三个月没动过不知道备份到底能不能恢复。后来我把安全检查项整理成一张手工清单每周五下午花一个小时逐项过一遍。第一个月问题很多第二个月问题变少第三个月基本能在半小时内跑完而且大部分检查项都可以写成脚本自动执行。这时候你的加班就明显少了因为绝大多数风险在变成故障之前已经被清掉了。零基础的人我建议按这个顺序学习阶段学习内容目标基础期系统命令、用户权限、网络基础、防火墙概念能看懂机器的状态进阶期日志分析、加固基线、补丁管理、备份恢复能独立处理常见风险熟练期自动化巡检、入侵排查、应急响应演练能主导安全体系建设标题里说的十大操作其实就是把这个学习路线落到了具体的工作里。2. 先管人账户口令和SSH登录防护2.1 操作一账户与口令基线检查为什么要先做账户因为大部分入侵最终都要落到一个合法的账号上要么是弱口令被猜中要么是离职员工的账号还在用要么是一个闲置的测试账号刚好有sudo权限。你不需要对抗神乎其技的黑客你只需要先把大门上那把生锈的锁换掉。第一步是摸清系统里有哪些账户。看两个文件就能确定最终所有账户# 查看所有本地账户 awk -F: {print $1, $3} /etc/passwd # 查看哪些账户有shell有可能登录系统 awk -F: $7 ! /usr/sbin/nologin $7 ! /bin/false {print $1, $3, $7} /etc/passwd拿到清单后重点核对三件事uid为0的非root账户这代表超级管理员权限。shell字段不是nologin的账户这些账户理论上可以登录。密码字段是否为空。# 检查uid为0的账户 awk -F: $30 {print $1} /etc/passwd # 检查空密码账户 awk -F: ($2) {print $1} /etc/shadow大多数发行版会把没有密码的账户显示为!或*如果出现空字段这个账户就是裸奔状态。对确认不用的账户不要只删最好先锁定并备份关键信息# 锁定账户 usermod -L username # 设置账户永不登录 usermod -s /usr/sbin/nologin username # 如果环境允许再加一个过期时间 chage -E 2026-01-01 username锁账户比直接删除安全因为删除会连带历史属主信息文件还能查出来但账户没了容易影响后续审计追踪。口令策略方面我建议至少做到密码长度12位以上90天轮换连续输错5次锁定15分钟。这些都写在系统配置里# 修改用户密码有效期 chage -M 90 -m 7 -W 14 username # /etc/login.defs 里设置默认值 PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 14启用PAM的密码复杂度校验在/etc/pam.d/common-password或pam_pwquality.conf里配置minlen12 dcredit-1 ucredit-1 lcredit-1 ocredit-1这段的意思是密码最短12位且必须至少包含一位数字、一位大写字母、一位小写字母、一位特殊符号。刚推行的时候业务方会很抗拒你的话术可以简单一点不强制密码复杂度下次被撞库恢复数据的成本远比你被骂几句高得多。2.2 操作二SSH登录防护的完整配置SSH是运维的生命线也是被爆破的重灾区。任何一台暴露在公网上的主机一天被扫描撞库几千次都是家常便饭。日志里全是这种记录Invalid user test from 203.0.113.5 port 51234 Failed password for root from 198.51.100.7 port 55210SSH加固的核心配置我直接给出可以用的方案# 编辑 /etc/ssh/sshd_config Port 2299 PermitRootLogin no MaxAuthTries 3 LoginGraceTime 30 PasswordAuthentication no PubkeyAuthentication yes AllowUsers ops admin解释几个关键项Port 2299是变更默认端口能挡掉一大波只扫22端口的脚本。PermitRootLogin no是禁止root直接登录管理员用普通用户登录后su切换。PasswordAuthentication no是彻底关闭密码登录只允许密钥登录。MaxAuthTries 3是限制单次连接的最大认证尝试次数。AllowUsers是白名单只允许指定用户登录。改完之前一定要先做配置校验sshd -t这个命令检查语法如果报错就说明配置有问题不要盲目重启。校验通过后再重新加载服务systemctl reload sshd在你确认密钥登录完全正常之前千万别关掉当前终端窗口也别把登录方式切换成密码认证关掉。我见过不止一次有人改完配置顺手一关结果密钥权限不对又没开密码登录最后只能跑机房或者通过管理控制台重置。正确习惯是改完配置后新开一个终端测试能否登录确认没问题再退出旧会话。密钥生成命令也一并给出ssh-keygen -t ed25519 -a 100 -f ops_ed25519 -C ops-key-2025公钥写到服务器的~/.ssh/authorized_keys注意这个文件的权限必须是600所在目录权限必须是700否则SSH会拒绝读取chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys如果团队人不多还可以把登录来源IP收得更紧在防火墙层面只允许固定来源访问这个放到端口和访问控制里一起讲。3. 管住系统补丁、端口和防火墙3.1 操作三补丁与软件最小化补丁管理是很多人觉得“重要但没时间做”的事等出了漏洞通报才临时上。实际上只要把补丁工作拆成固定的节奏它就不那么占时间。我的方式是每天快速检查一遍更新apt list --upgradable或yum check-update。每周挑一个低峰期把系统补丁按“测试机→非核心机→核心机”的顺序推。每次升级前用apt list --upgradable确认影响面做个快照备份升级失败能回滚。命令层面以Debian系为例# 查看可升级的包 apt list --upgradable # 先只下载不安装 apt install --download-only -y package_name # 低峰期安装 apt upgrade -y核心服务器升级前我强烈建议先拍快照或者做一次完整备份。现实中我遇到过内核补丁装上后网卡驱动异常的情况如果没有快照恢复起来会非常痛苦。补丁这件事考验的从来不是安装速度而是回滚能力。软件最小化是另一个被忽略的问题。很多机器装了一堆用不上的软件包每个包都有依赖组件每个组件都可能存在漏洞。常规清理思路# 查看安装时间较久且最近没用过的包仅供参考需人工确认 awk /^Install Date/{date$4 $5} !/^Install Date/{print} /var/log/dpkg.log | tail -50 # 查看当前监听端口对应的服务找出不认识的 ss -tlnp我的原则是一台服务器只干一件事。如果数据库服务器上装了web服务、开发工具、图形界面安全暴露面直接翻倍。卸载软件时顺便清理不需要的系统服务后面讲端口收敛时会用到。3.2 操作四端口与服务收敛端口不进则退多开一个端口就多一个被探测的入口。我最常遇到的问题是数据库装了bind-address127.0.0.1还好改配置时不小心监听在所有接口上或者测试环境临时起了个服务线上的防火墙规则没更新服务一直对外暴露。排查端口第一步用ss替代已经过时的netstatss -tlnp这个命令会显示当前所有TCP监听端口和对应进程。看到异常的高位端口或者不应该对外暴露的数据库、容器管理端口要立刻确认来源进程。确认服务名称后停止并禁用不需要的服务# 停止服务 systemctl stop myservice # 禁止开机自启动 systemctl disable myservice有些服务是其他服务的依赖不要一上来就disable。先用systemctl list-dependencies看依赖树确认没有连带影响再动手。还有个常见场景MySQL这类组件默认监听3306它本身没问题可怕的是监听在0.0.0.0上。正确姿势是让数据库只监听内网IP甚至仅本机回环bind-address 127.0.0.1如果应用和数据库不在同一台机器至少要限定在内部网络地址再由防火墙控制访问来源。我见过最夸张的一次是Redis没设密码监听在公网IP的6379端口上被扫到之后直接被写入了定时任务。这个事故后凡是有类似中间件暴露风险我都建议遵循同一原则默认不对外需要对外再明确配置。3.3 操作五防火墙白名单与默认拒绝防火墙的核心思想很简单先拒绝所有再放行必要。很多服务器默认策略是允许全部这相当于把安全员的筛选工作全交给了应用风险太大。在用了很多年iptables之后我的习惯是在多数服务器上用firewalld因为它分层清晰容易管理。开局先看现状firewall-cmd --list-all然后把默认zone设置为drop或减少放行规则# 默认拒绝绝大多数入站 firewall-cmd --set-default-zonedrop # 放行SSH注意端口如果改过这里也要同步 firewall-cmd --permanent --add-servicessh # 放行固定来源访问某个端口例如只允许内部网段访问数据库 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.0.0.0/8 port port3306 protocoltcp accept # 重新加载使配置生效 firewall-cmd --reload如果是用iptables直接管理可以这样建立一套基础规则# 清空并设置默认策略 iptables -P INPUT DROP iptables -P FORWARD DROP # 放行已建立的连接避免误伤正常会话 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # 放行回环 iptables -A INPUT -i lo -j ACCEPT # 放行SSH iptables -A INPUT -p tcp --dport 2299 -j ACCEPT操作顺序非常关键先放行必要端口再设置默认拒绝。如果顺序反了配置下发的瞬间你的SSH就断了。就算顺序正确批量操作前也要先把现有规则备份iptables-save /root/iptables-backup-$(date %F).txt防火墙规则属于“改动小、影响大”的典型任何变更都要留后路。我还会在规则里加注释写明这条规则是哪天为什么加的否则三个月后回看配置根本不知道某条规则能不能删。4. 看得见威胁日志、告警与完整性校验4.1 操作六日志统一采集与留存安全运维里最怕的不是没日志而是日志散落在每台机器上出事时找半天才发现某台机器日志只留了两天。统一采集日志本质上是把“事后翻箱倒柜”变成“平时一眼看清”。Linux自带systemd-journald配合rsyslog可以满足大多数中小环境的日志集中需求。基础配置如下# journald限制最大占用 journalctl --vacuum-size500M # 永久化存储编辑/etc/systemd/journald.conf Storagepersistent SystemMaxUse500M MaxRetentionSec90如果机器多可以配置rsyslog将日志转发到集中的日志服务器# 在/etc/rsyslog.d/remote.conf里加上 *.* 192.168.10.20:514集中日志服务器那边打开514端口接收即可。这里要注意防火墙尤其是rsyslog端口如果暴露在公网会被用来做日志伪造或流量放大一定要限制访问来源。日志量估算是个实操难点。我用一个具体例子假设每秒产生1000条日志每条平均1KB一天的日志量就是约86GB。如果你的磁盘分配只有100GB那不到两天就会写满。所以在做日志留存前先算清楚三个数字每天产生多少量、希望保留多久、磁盘能装多大。据此设定轮转策略和告警阈值# 日志轮转示例/etc/logrotate.d/nginx /var/log/nginx/*.log { daily rotate 90 compress delaycompress missingok notifempty create 640 nginx adm }需要重点留存的日志包括认证日志、audit日志、sudo记录、数据库慢查询、应用的登录/支付/管理操作记录。每一类都想清楚出问题时我要从哪里查清楚“谁在什么时间做了什么”。4.2 操作七暴力破解与异常登录检测日志集中了之后下一步就是让它自动告诉你“有人正在撞门”。最经典的暴力破解特征就是短时间内同一个源IP对SSH大量尝试失败。用开源工具fail2ban就能拦截配置不复杂。安装后在/etc/fail2ban/jail.local里写[sshd] enabled true port ssh filter sshd logpath /var/log/auth.log maxretry 5 findtime 600 bantime 600 ignoreip 127.0.0.1/8 10.0.0.0/8 172.16.0.0/12参数含义10分钟findtime内同一个IP失败5次maxretry就封禁10分钟bantime。内网地址加进ignoreip避免误伤正常办公出口。启动后查看状态fail2ban-client status sshd输出里能看到被封禁的IP列表记为违规IP之后可以在防火墙层做长期拒绝。这里有一个典型坑如果你们整个办公室通过同一个出口IP访问服务器这个IP很容易因为某个人输错几次密码被fail2ban封掉然后全办公室都上不去。所以ignoreip一定要配置好至少把你的办公网和运维跳板机网段放进去。除了fail2ban我还会每周手动看一次认证日志重点是那些从未见过的用户登录记录# 最近一条登录记录 last -n 20 # 查看近期所有登录会话及其来源 last -i -n 50 # 检查登录失败记录 lastb -n 50另外useradd和sudo日志也要纳入主动巡检。如果有人频繁切换root并执行敏感命令应该能够直接从/var/log/auth.log或audit日志里拉出一条完整时间线。4.3 操作八文件完整性校验与防篡改木马和后门最常干的事就是替换核心命令、修改配置文件、在启动项里加坑。文件完整性校验的作用是定期对关键文件做哈希比对发现任何异常变化立刻告警。AIDE是这类工具里经得起时间考验的一个。初始化数据库# 安装后先初始化生成数据库 aide -i # 生成的数据库文件路径在 /var/lib/aide/aide.db.new.gz mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz之后每次比对aide --check初次初始化后先跑一次对比会有大量误报因为你自己的配置更新、日志轮转都会触发差异。需要把动态目录排除掉在/etc/aide.conf里增加规则例如!/var/log/.* !/var/tmp/.* !/proc/.* !/sys/.*然后重新初始化数据库再启用计划任务每周自动比对并发送结果。auditd是另一个好用的内核级审计组件适合持续监控关键路径# 监控/etc/passwd和/etc/shadow的写和执行行为 auditctl -w /etc/passwd -p wa -k identity_changes auditctl -w /etc/shadow -p wa -k identity_changes # 查看审计记录 ausearch -k identity_changes -ts recent这类监控的核心思路就是“预警而非追溯”。你不想在系统被入侵两天后才发现文件被改了更希望改动发生的当下就收到告警。如果你有日志监控平台把AIDE输出的告警接入进去效果会好很多。5. 留好后路备份恢复和应急响应5.1 操作九备份策略与恢复演练备份和恢复听起来人尽皆知但多数人的备份方案经不起一次真正的故障。我做过的教训很深刻某次业务系统故障备份文件确实在但恢复时发现备份脚本只备份了数据库文件没备份配置文件更麻烦的是密钥文件缺失导致备份内容无法解密。先记住一个硬性原则3-2-1。数据至少3份副本存2种不同介质其中1份放异地或离线。这里“离线”强调的是机房断电、勒索病毒加密等极端事件下的最后防线。常用备份工具组合文件备份rsync hardlink / duplicity / borgbackup数据库逻辑备份mysqldump / pg_dump系统级快照云平台快照或本机LVM快照# 示例使用rsync做文件级备份 rsync -av --delete /data/ /backup/data/ # 示例MySQL逻辑备份 mysqldump -uxxx -pxxx --single-transaction --routines --triggers /backup/mysql-$(date %F).sql关于备份窗口需要估算。假设数据量2TB千兆网络理论峰值大概是每秒110MB左右全量备份理想状态也要5小时以上。所以备份设计从来不是“每天全量”而是“周一全量每天增量”或者“每天增量周末全量”。增量备份的恢复顺序和依赖关系要写清楚不要等到故障才发现少了一个中间环节。恢复演练才是重点。我建议至少每季度做一次演练在隔离环境里从备份完整恢复一套系统记录三个关键指标恢复需要多长时间RTO恢复出来的数据会丢多少RPO恢复后应用能否正常启动把演练结果记下来比备份任务成功日志重要十倍。因为你最终交付的不是“备份文件”而是“可用的恢复能力”。5.2 操作十应急响应SOP与模拟演练第10个操作是把之前的成果固化成一整套应急流程。没有预案的攻击就像是火警响了才现找灭火器很容易手忙脚乱再添新错。事件分级可以先按影响定义级别定义响应要求P1核心业务中断、数据泄露或勒索加密15分钟内启动应急隔离受影响系统P2疑似入侵、异常登录、重要配置被篡改30分钟内初判保留现场上报P3低危扫描、误报告警、合规整改项当天确认按周整理响应流程按六步固定下来发现→上报→隔离→取证→恢复→复盘。发现告警触发的源头是什么日志保留在哪里。上报通知到谁用哪个群、哪条电话线话术预先写清楚。隔离防火墙层直接封禁异常IP必要时断网或挂载只读先止血再排查。取证复制日志、保存进程状态、快照内存信息按时间线梳理。恢复从干净备份重建收紧登录入口变更所有受影响密码。复盘痛点是规则未覆盖还是监控阈值不当还是人的操作习惯问题形成改进项。这里的关键是预案要具体到“谁在什么条件下执行哪条命令”。不要写“迅速切断网络”要写“在防火墙执行firewall-cmd --permanent --add-rich-rule去屏蔽来源IP然后reload”。不要写“联系相关人员”要写“电话联系运维负责人若未响应则升级到平台负责人”。只有能直接照着执行的才算预案否则只是文档。团队建议每月做一次模拟演练。场景可以轮流设计比如“某服务器多了一个公网监听端口”“某个管理员账号在凌晨三点登录”。演练的价值不在于动作多专业而在于发现预案里那些没说清的地方。我做完几次演练后明显感觉到平时战战兢兢的加班变少了因为真出事时大家知道第一步干什么。6. 常见问题速查与避坑实录表面现象可能原因排查方向避坑建议远程登录突然失败禁用了密码登录但密钥权限不对确认authorized_keys权限控制台登录检查sshd配置改配置前先新开终端测试业务访问被断防火墙规则顺序错误默认拒绝先生效查看iptables/firewalld规则命中计数变更前必须备份规则先放行必要端口再设默认拒绝磁盘被日志写满日志量估算不足轮转策略缺失df -h看使用率du找大日志先算清每日日志量和保留周期再定磁盘分配办公网出口IP被fail2ban误封阈值太低共享出口IP触发条件fail2ban-client status 查看封禁列表ignoreip加上办公网和跳板机网段AIDE误报太多排除规则没写好动态文件被纳入监控查看审计日志确认触发文件初始化前关闭动态路径更新基线后再启用备份恢复失败备份不完整或缺少配置文件在隔离环境做完整恢复验证每季度做恢复演练记录RTO和RPO还有一些实操细节值得单独提醒。不要为了“安全”把所有服务都塞进同一台跳板机跳板机被攻破等于内网被打穿。重要系统的分批补丁窗口之间保持至少1小时万一第一批出问题你还有时间处理不用全网一起回滚。权限变更和防火墙规则变更尽量走固定变更流程记录好每一笔操作。变更是事故最大的来源也是最容易被忽视的风险点。7. 我的经验与建议做了这些年网络安全运维我最大的转变是从追求“会不会被入侵”变成追求“入侵发生之后我能不能在10分钟内发现问题并在1小时内恢复”。这两者的技术动作差不多但心态完全不一样。现在我会建议刚入行的朋友不要一上来就冲锋各种高级防护设备先把这十件事做到位——账户管起来SSH锁上端口收敛日志能看到备份能恢复应急有流程。这些看起来基础但基本上能解决日常80%以上的安全风险。最后再分享一个小技巧把这十项检查做成一个自检脚本文档每月跑一遍结果发给团队。不需要所有人都懂安全只需要所有人都在同一份检查清单里看到偏差。很多时候告别996不是靠某个单点操作而是靠每天周二下午那雷打不动的20分钟巡检把问题提前拦在事故发生之前。这套东西坚持三个月你会回来感谢当时的自己。 
长河君 · 2026/10/20 12:13:16 · 阅读 1.2k 网络安全运维十大核心操作：从救火到预防的实战指南
网络安全运维一直是被误解最深的岗位很多新人以为这份工作就是装个防火墙、装个杀毒软件剩下的时间喝喝茶。真上手之后才发现白天被各种合规检查追着跑半夜被告警电话叫起来重启服务第二天还要顶着黑眼圈写复盘报告。我做了这些年运维最深的体会是想告别996靠的不是增加工时而是把那些反复发生的“救火”场景用十个核心操作提前消解掉。这篇分享我就把这十个网络安全运维操作完整拆开从账户口令到日志监控从端口收敛到备份恢复每个操作都会讲清楚原理、步骤、命令和最容易踩的坑。零基础的人照着做也能把一台机器的安全水平拉起来有经验的人可以当一次系统自查。这十件事做完不是说你从此不加班而是你加班的次数会肉眼可见地变少因为大部分事故在你还没睡觉前就被例行操作拦住了。1. 先看思路安全运维为什么能治加班1.1 救火型运维的死循环一个典型的“救火型”运维节奏是这样的白天收到漏洞通报临时开会确定修复方案晚上业务低峰期上线补丁结果补丁和现有环境冲突回滚第二天业务方反馈服务变慢排查发现是日志把磁盘写满了刚清理完日志又收到暴力破解告警发现某个测试账号密码过于简单被扫了。一整天下来什么都没做成但每一步都很忙。这种忙的本质是没有建立基线。所谓基线就是一台机器在正常情况下应该长什么样有哪些用户、开放哪些端口、跑哪些服务、日志存在哪、告警阈值是多少。没有基线任何异常都需要临时判断任何判断都会消耗时间任何误判都会引发连锁故障。所以后面讲的所有操作核心都是在帮你把“不确定”变成“确定”。1.2 从“看运气”到“看清单”我做运维的前两年最怕的就是“未知的未知”——不知道哪个端口对外开着不知道哪个账号三个月没动过不知道备份到底能不能恢复。后来我把安全检查项整理成一张手工清单每周五下午花一个小时逐项过一遍。第一个月问题很多第二个月问题变少第三个月基本能在半小时内跑完而且大部分检查项都可以写成脚本自动执行。这时候你的加班就明显少了因为绝大多数风险在变成故障之前已经被清掉了。零基础的人我建议按这个顺序学习阶段学习内容目标基础期系统命令、用户权限、网络基础、防火墙概念能看懂机器的状态进阶期日志分析、加固基线、补丁管理、备份恢复能独立处理常见风险熟练期自动化巡检、入侵排查、应急响应演练能主导安全体系建设标题里说的十大操作其实就是把这个学习路线落到了具体的工作里。2. 先管人账户口令和SSH登录防护2.1 操作一账户与口令基线检查为什么要先做账户因为大部分入侵最终都要落到一个合法的账号上要么是弱口令被猜中要么是离职员工的账号还在用要么是一个闲置的测试账号刚好有sudo权限。你不需要对抗神乎其技的黑客你只需要先把大门上那把生锈的锁换掉。第一步是摸清系统里有哪些账户。看两个文件就能确定最终所有账户# 查看所有本地账户 awk -F: {print $1, $3} /etc/passwd # 查看哪些账户有shell有可能登录系统 awk -F: $7 ! /usr/sbin/nologin $7 ! /bin/false {print $1, $3, $7} /etc/passwd拿到清单后重点核对三件事uid为0的非root账户这代表超级管理员权限。shell字段不是nologin的账户这些账户理论上可以登录。密码字段是否为空。# 检查uid为0的账户 awk -F: $30 {print $1} /etc/passwd # 检查空密码账户 awk -F: ($2) {print $1} /etc/shadow大多数发行版会把没有密码的账户显示为!或*如果出现空字段这个账户就是裸奔状态。对确认不用的账户不要只删最好先锁定并备份关键信息# 锁定账户 usermod -L username # 设置账户永不登录 usermod -s /usr/sbin/nologin username # 如果环境允许再加一个过期时间 chage -E 2026-01-01 username锁账户比直接删除安全因为删除会连带历史属主信息文件还能查出来但账户没了容易影响后续审计追踪。口令策略方面我建议至少做到密码长度12位以上90天轮换连续输错5次锁定15分钟。这些都写在系统配置里# 修改用户密码有效期 chage -M 90 -m 7 -W 14 username # /etc/login.defs 里设置默认值 PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 14启用PAM的密码复杂度校验在/etc/pam.d/common-password或pam_pwquality.conf里配置minlen12 dcredit-1 ucredit-1 lcredit-1 ocredit-1这段的意思是密码最短12位且必须至少包含一位数字、一位大写字母、一位小写字母、一位特殊符号。刚推行的时候业务方会很抗拒你的话术可以简单一点不强制密码复杂度下次被撞库恢复数据的成本远比你被骂几句高得多。2.2 操作二SSH登录防护的完整配置SSH是运维的生命线也是被爆破的重灾区。任何一台暴露在公网上的主机一天被扫描撞库几千次都是家常便饭。日志里全是这种记录Invalid user test from 203.0.113.5 port 51234 Failed password for root from 198.51.100.7 port 55210SSH加固的核心配置我直接给出可以用的方案# 编辑 /etc/ssh/sshd_config Port 2299 PermitRootLogin no MaxAuthTries 3 LoginGraceTime 30 PasswordAuthentication no PubkeyAuthentication yes AllowUsers ops admin解释几个关键项Port 2299是变更默认端口能挡掉一大波只扫22端口的脚本。PermitRootLogin no是禁止root直接登录管理员用普通用户登录后su切换。PasswordAuthentication no是彻底关闭密码登录只允许密钥登录。MaxAuthTries 3是限制单次连接的最大认证尝试次数。AllowUsers是白名单只允许指定用户登录。改完之前一定要先做配置校验sshd -t这个命令检查语法如果报错就说明配置有问题不要盲目重启。校验通过后再重新加载服务systemctl reload sshd在你确认密钥登录完全正常之前千万别关掉当前终端窗口也别把登录方式切换成密码认证关掉。我见过不止一次有人改完配置顺手一关结果密钥权限不对又没开密码登录最后只能跑机房或者通过管理控制台重置。正确习惯是改完配置后新开一个终端测试能否登录确认没问题再退出旧会话。密钥生成命令也一并给出ssh-keygen -t ed25519 -a 100 -f ops_ed25519 -C ops-key-2025公钥写到服务器的~/.ssh/authorized_keys注意这个文件的权限必须是600所在目录权限必须是700否则SSH会拒绝读取chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys如果团队人不多还可以把登录来源IP收得更紧在防火墙层面只允许固定来源访问这个放到端口和访问控制里一起讲。3. 管住系统补丁、端口和防火墙3.1 操作三补丁与软件最小化补丁管理是很多人觉得“重要但没时间做”的事等出了漏洞通报才临时上。实际上只要把补丁工作拆成固定的节奏它就不那么占时间。我的方式是每天快速检查一遍更新apt list --upgradable或yum check-update。每周挑一个低峰期把系统补丁按“测试机→非核心机→核心机”的顺序推。每次升级前用apt list --upgradable确认影响面做个快照备份升级失败能回滚。命令层面以Debian系为例# 查看可升级的包 apt list --upgradable # 先只下载不安装 apt install --download-only -y package_name # 低峰期安装 apt upgrade -y核心服务器升级前我强烈建议先拍快照或者做一次完整备份。现实中我遇到过内核补丁装上后网卡驱动异常的情况如果没有快照恢复起来会非常痛苦。补丁这件事考验的从来不是安装速度而是回滚能力。软件最小化是另一个被忽略的问题。很多机器装了一堆用不上的软件包每个包都有依赖组件每个组件都可能存在漏洞。常规清理思路# 查看安装时间较久且最近没用过的包仅供参考需人工确认 awk /^Install Date/{date$4 $5} !/^Install Date/{print} /var/log/dpkg.log | tail -50 # 查看当前监听端口对应的服务找出不认识的 ss -tlnp我的原则是一台服务器只干一件事。如果数据库服务器上装了web服务、开发工具、图形界面安全暴露面直接翻倍。卸载软件时顺便清理不需要的系统服务后面讲端口收敛时会用到。3.2 操作四端口与服务收敛端口不进则退多开一个端口就多一个被探测的入口。我最常遇到的问题是数据库装了bind-address127.0.0.1还好改配置时不小心监听在所有接口上或者测试环境临时起了个服务线上的防火墙规则没更新服务一直对外暴露。排查端口第一步用ss替代已经过时的netstatss -tlnp这个命令会显示当前所有TCP监听端口和对应进程。看到异常的高位端口或者不应该对外暴露的数据库、容器管理端口要立刻确认来源进程。确认服务名称后停止并禁用不需要的服务# 停止服务 systemctl stop myservice # 禁止开机自启动 systemctl disable myservice有些服务是其他服务的依赖不要一上来就disable。先用systemctl list-dependencies看依赖树确认没有连带影响再动手。还有个常见场景MySQL这类组件默认监听3306它本身没问题可怕的是监听在0.0.0.0上。正确姿势是让数据库只监听内网IP甚至仅本机回环bind-address 127.0.0.1如果应用和数据库不在同一台机器至少要限定在内部网络地址再由防火墙控制访问来源。我见过最夸张的一次是Redis没设密码监听在公网IP的6379端口上被扫到之后直接被写入了定时任务。这个事故后凡是有类似中间件暴露风险我都建议遵循同一原则默认不对外需要对外再明确配置。3.3 操作五防火墙白名单与默认拒绝防火墙的核心思想很简单先拒绝所有再放行必要。很多服务器默认策略是允许全部这相当于把安全员的筛选工作全交给了应用风险太大。在用了很多年iptables之后我的习惯是在多数服务器上用firewalld因为它分层清晰容易管理。开局先看现状firewall-cmd --list-all然后把默认zone设置为drop或减少放行规则# 默认拒绝绝大多数入站 firewall-cmd --set-default-zonedrop # 放行SSH注意端口如果改过这里也要同步 firewall-cmd --permanent --add-servicessh # 放行固定来源访问某个端口例如只允许内部网段访问数据库 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.0.0.0/8 port port3306 protocoltcp accept # 重新加载使配置生效 firewall-cmd --reload如果是用iptables直接管理可以这样建立一套基础规则# 清空并设置默认策略 iptables -P INPUT DROP iptables -P FORWARD DROP # 放行已建立的连接避免误伤正常会话 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # 放行回环 iptables -A INPUT -i lo -j ACCEPT # 放行SSH iptables -A INPUT -p tcp --dport 2299 -j ACCEPT操作顺序非常关键先放行必要端口再设置默认拒绝。如果顺序反了配置下发的瞬间你的SSH就断了。就算顺序正确批量操作前也要先把现有规则备份iptables-save /root/iptables-backup-$(date %F).txt防火墙规则属于“改动小、影响大”的典型任何变更都要留后路。我还会在规则里加注释写明这条规则是哪天为什么加的否则三个月后回看配置根本不知道某条规则能不能删。4. 看得见威胁日志、告警与完整性校验4.1 操作六日志统一采集与留存安全运维里最怕的不是没日志而是日志散落在每台机器上出事时找半天才发现某台机器日志只留了两天。统一采集日志本质上是把“事后翻箱倒柜”变成“平时一眼看清”。Linux自带systemd-journald配合rsyslog可以满足大多数中小环境的日志集中需求。基础配置如下# journald限制最大占用 journalctl --vacuum-size500M # 永久化存储编辑/etc/systemd/journald.conf Storagepersistent SystemMaxUse500M MaxRetentionSec90如果机器多可以配置rsyslog将日志转发到集中的日志服务器# 在/etc/rsyslog.d/remote.conf里加上 *.* 192.168.10.20:514集中日志服务器那边打开514端口接收即可。这里要注意防火墙尤其是rsyslog端口如果暴露在公网会被用来做日志伪造或流量放大一定要限制访问来源。日志量估算是个实操难点。我用一个具体例子假设每秒产生1000条日志每条平均1KB一天的日志量就是约86GB。如果你的磁盘分配只有100GB那不到两天就会写满。所以在做日志留存前先算清楚三个数字每天产生多少量、希望保留多久、磁盘能装多大。据此设定轮转策略和告警阈值# 日志轮转示例/etc/logrotate.d/nginx /var/log/nginx/*.log { daily rotate 90 compress delaycompress missingok notifempty create 640 nginx adm }需要重点留存的日志包括认证日志、audit日志、sudo记录、数据库慢查询、应用的登录/支付/管理操作记录。每一类都想清楚出问题时我要从哪里查清楚“谁在什么时间做了什么”。4.2 操作七暴力破解与异常登录检测日志集中了之后下一步就是让它自动告诉你“有人正在撞门”。最经典的暴力破解特征就是短时间内同一个源IP对SSH大量尝试失败。用开源工具fail2ban就能拦截配置不复杂。安装后在/etc/fail2ban/jail.local里写[sshd] enabled true port ssh filter sshd logpath /var/log/auth.log maxretry 5 findtime 600 bantime 600 ignoreip 127.0.0.1/8 10.0.0.0/8 172.16.0.0/12参数含义10分钟findtime内同一个IP失败5次maxretry就封禁10分钟bantime。内网地址加进ignoreip避免误伤正常办公出口。启动后查看状态fail2ban-client status sshd输出里能看到被封禁的IP列表记为违规IP之后可以在防火墙层做长期拒绝。这里有一个典型坑如果你们整个办公室通过同一个出口IP访问服务器这个IP很容易因为某个人输错几次密码被fail2ban封掉然后全办公室都上不去。所以ignoreip一定要配置好至少把你的办公网和运维跳板机网段放进去。除了fail2ban我还会每周手动看一次认证日志重点是那些从未见过的用户登录记录# 最近一条登录记录 last -n 20 # 查看近期所有登录会话及其来源 last -i -n 50 # 检查登录失败记录 lastb -n 50另外useradd和sudo日志也要纳入主动巡检。如果有人频繁切换root并执行敏感命令应该能够直接从/var/log/auth.log或audit日志里拉出一条完整时间线。4.3 操作八文件完整性校验与防篡改木马和后门最常干的事就是替换核心命令、修改配置文件、在启动项里加坑。文件完整性校验的作用是定期对关键文件做哈希比对发现任何异常变化立刻告警。AIDE是这类工具里经得起时间考验的一个。初始化数据库# 安装后先初始化生成数据库 aide -i # 生成的数据库文件路径在 /var/lib/aide/aide.db.new.gz mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz之后每次比对aide --check初次初始化后先跑一次对比会有大量误报因为你自己的配置更新、日志轮转都会触发差异。需要把动态目录排除掉在/etc/aide.conf里增加规则例如!/var/log/.* !/var/tmp/.* !/proc/.* !/sys/.*然后重新初始化数据库再启用计划任务每周自动比对并发送结果。auditd是另一个好用的内核级审计组件适合持续监控关键路径# 监控/etc/passwd和/etc/shadow的写和执行行为 auditctl -w /etc/passwd -p wa -k identity_changes auditctl -w /etc/shadow -p wa -k identity_changes # 查看审计记录 ausearch -k identity_changes -ts recent这类监控的核心思路就是“预警而非追溯”。你不想在系统被入侵两天后才发现文件被改了更希望改动发生的当下就收到告警。如果你有日志监控平台把AIDE输出的告警接入进去效果会好很多。5. 留好后路备份恢复和应急响应5.1 操作九备份策略与恢复演练备份和恢复听起来人尽皆知但多数人的备份方案经不起一次真正的故障。我做过的教训很深刻某次业务系统故障备份文件确实在但恢复时发现备份脚本只备份了数据库文件没备份配置文件更麻烦的是密钥文件缺失导致备份内容无法解密。先记住一个硬性原则3-2-1。数据至少3份副本存2种不同介质其中1份放异地或离线。这里“离线”强调的是机房断电、勒索病毒加密等极端事件下的最后防线。常用备份工具组合文件备份rsync hardlink / duplicity / borgbackup数据库逻辑备份mysqldump / pg_dump系统级快照云平台快照或本机LVM快照# 示例使用rsync做文件级备份 rsync -av --delete /data/ /backup/data/ # 示例MySQL逻辑备份 mysqldump -uxxx -pxxx --single-transaction --routines --triggers /backup/mysql-$(date %F).sql关于备份窗口需要估算。假设数据量2TB千兆网络理论峰值大概是每秒110MB左右全量备份理想状态也要5小时以上。所以备份设计从来不是“每天全量”而是“周一全量每天增量”或者“每天增量周末全量”。增量备份的恢复顺序和依赖关系要写清楚不要等到故障才发现少了一个中间环节。恢复演练才是重点。我建议至少每季度做一次演练在隔离环境里从备份完整恢复一套系统记录三个关键指标恢复需要多长时间RTO恢复出来的数据会丢多少RPO恢复后应用能否正常启动把演练结果记下来比备份任务成功日志重要十倍。因为你最终交付的不是“备份文件”而是“可用的恢复能力”。5.2 操作十应急响应SOP与模拟演练第10个操作是把之前的成果固化成一整套应急流程。没有预案的攻击就像是火警响了才现找灭火器很容易手忙脚乱再添新错。事件分级可以先按影响定义级别定义响应要求P1核心业务中断、数据泄露或勒索加密15分钟内启动应急隔离受影响系统P2疑似入侵、异常登录、重要配置被篡改30分钟内初判保留现场上报P3低危扫描、误报告警、合规整改项当天确认按周整理响应流程按六步固定下来发现→上报→隔离→取证→恢复→复盘。发现告警触发的源头是什么日志保留在哪里。上报通知到谁用哪个群、哪条电话线话术预先写清楚。隔离防火墙层直接封禁异常IP必要时断网或挂载只读先止血再排查。取证复制日志、保存进程状态、快照内存信息按时间线梳理。恢复从干净备份重建收紧登录入口变更所有受影响密码。复盘痛点是规则未覆盖还是监控阈值不当还是人的操作习惯问题形成改进项。这里的关键是预案要具体到“谁在什么条件下执行哪条命令”。不要写“迅速切断网络”要写“在防火墙执行firewall-cmd --permanent --add-rich-rule去屏蔽来源IP然后reload”。不要写“联系相关人员”要写“电话联系运维负责人若未响应则升级到平台负责人”。只有能直接照着执行的才算预案否则只是文档。团队建议每月做一次模拟演练。场景可以轮流设计比如“某服务器多了一个公网监听端口”“某个管理员账号在凌晨三点登录”。演练的价值不在于动作多专业而在于发现预案里那些没说清的地方。我做完几次演练后明显感觉到平时战战兢兢的加班变少了因为真出事时大家知道第一步干什么。6. 常见问题速查与避坑实录表面现象可能原因排查方向避坑建议远程登录突然失败禁用了密码登录但密钥权限不对确认authorized_keys权限控制台登录检查sshd配置改配置前先新开终端测试业务访问被断防火墙规则顺序错误默认拒绝先生效查看iptables/firewalld规则命中计数变更前必须备份规则先放行必要端口再设默认拒绝磁盘被日志写满日志量估算不足轮转策略缺失df -h看使用率du找大日志先算清每日日志量和保留周期再定磁盘分配办公网出口IP被fail2ban误封阈值太低共享出口IP触发条件fail2ban-client status 查看封禁列表ignoreip加上办公网和跳板机网段AIDE误报太多排除规则没写好动态文件被纳入监控查看审计日志确认触发文件初始化前关闭动态路径更新基线后再启用备份恢复失败备份不完整或缺少配置文件在隔离环境做完整恢复验证每季度做恢复演练记录RTO和RPO还有一些实操细节值得单独提醒。不要为了“安全”把所有服务都塞进同一台跳板机跳板机被攻破等于内网被打穿。重要系统的分批补丁窗口之间保持至少1小时万一第一批出问题你还有时间处理不用全网一起回滚。权限变更和防火墙规则变更尽量走固定变更流程记录好每一笔操作。变更是事故最大的来源也是最容易被忽视的风险点。7. 我的经验与建议做了这些年网络安全运维我最大的转变是从追求“会不会被入侵”变成追求“入侵发生之后我能不能在10分钟内发现问题并在1小时内恢复”。这两者的技术动作差不多但心态完全不一样。现在我会建议刚入行的朋友不要一上来就冲锋各种高级防护设备先把这十件事做到位——账户管起来SSH锁上端口收敛日志能看到备份能恢复应急有流程。这些看起来基础但基本上能解决日常80%以上的安全风险。最后再分享一个小技巧把这十项检查做成一个自检脚本文档每月跑一遍结果发给团队。不需要所有人都懂安全只需要所有人都在同一份检查清单里看到偏差。很多时候告别996不是靠某个单点操作而是靠每天周二下午那雷打不动的20分钟巡检把问题提前拦在事故发生之前。这套东西坚持三个月你会回来感谢当时的自己。