尧图网页设计 
简介一份面向网络管理员、信息安全工程师及企业IT负责人的网络安全加固方案PDF文档围绕对外网信息系统在升级改造与安全防护中的整体需求展开。方案开篇梳理了项目背景、建设目标及参考标准明确需求、风险、代价平衡分析综合性、整体性、动态保护、一致性、强制性、易操作与多重保护等设计原则并给出网络系统现状拓扑分析。核心部分重点阐述网络系统升级改造方案与安全加固技术方案涵盖二层交换机替换、集中控管无线AP部署、POE供电、核心交换与安全设备UPS保障、安全设备部署及用途等落地细节同时提供产品清单便于实际采购与实施参考。资源包为1个pdf文件大小约840KB目录结构完整内容覆盖从现状诊断到方案落地的全过程。目前已有353人学习下载适合需要快速建立安全加固方案框架并对照项目实践的中高级技术人员使用。1. 网络安全加固解决方案不是报告而是要执行的“基线清单”收到一份名为“网络安全加固解决方案.pdf”的文档很多团队的惯性动作是存档、传阅、归档然后等下次等保检查时再翻出来。这正好是本末倒置。真正有价值的网络安全加固解决方案不是给审计看的合规材料而是一份能照着实操的基线清单它明确告诉你先加固什么、怎么做、参数改到什么程度、改完怎么验证。它的落地形态可以是PDF但必须是“拿起来就能执行”的文档而不是“看完觉得讲得很对”的文档。这篇笔记我按自己做等保整改和应急加固的经验把这个标题拆透方案怎么设计、主机层和网络层怎么做、最容易踩哪些坑、以及怎么让这份方案不是一次性文件。2. 设计加固方案的框架先盘资产再分三层最后落到文档结构2.1 加固的第一步不是“打补丁”而是回答“资产在哪谁在访问”我见过太多团队拿到加固需求后第一件事是登录服务器跑更新结果三天后核心业务宕机因为不知道那台服务器还承载着老旧的PHP接口。做网络安全加固解决方案第一步永远是资产梳理。资产梳理不是简单列IP而是要建立一张“信息资产台账”至少包含主机名、IP、操作系统版本、中间件版本、开放端口、关联业务、负责人、数据等级。没有这张表后面所有加固动作都是盲目的。我一般会用三个来源补齐台账CMDB如果有、扫描器结果Nmap或Masscan、端口比较用 ss -tlnp 和实际监听比对。端口梳理是特别容易漏的一环。很多主机自己以为只开了80和443实际上一跑ss -tlnp发现还有22、3306、6379暴露在外网。排查时我会用下面的命令把监听端口和对应进程落盘ss -tlnp /tmp/open_ports.txt # 同时把对外映射的IP也记下来 ip addr show | grep inet /tmp/open_ports.txt逻辑说明ss -tlnp列出所有TCP监听端口-t是TCP-l是监听-n是不解析域名-p是显示进程号。这些信息会告诉你端口被哪个进程占用方便追溯到中间件或数据库。参数说明如果你只想看对外暴露的地址可以加上state listening过滤或者用ss -tlnp | grep -v 127.0.0.1把本地回环过滤掉剩下的一般就是需要重点关注的对外端口。完成这一步后你才能在PDF里画出一张“网络拓扑资产表”这张表决定后续防火墙白名单怎么写、补丁优先级怎么排。2.2 三层加固模型主机层、网络层、应用层各自的武器网络安全加固解决方案的框架我习惯按“主机层、网络层、应用层”三层来拆。这不是什么新理论但能保证不遗漏。主机层解决的是“这台机器本身脆不脆”包括账号口令、补丁、SSH配置、文件权限、内核参数网络层解决的是“谁能到这台机器”包括防火墙策略、DNS过滤、入侵检测、恶意流量阻断应用层解决的是“运行在这台机器上的业务有没有漏洞”包括Web中间件配置、WAF规则、接口鉴权、日志审计。工具选型上不要盲目追求商业套件。开源的OpenSCAP、Lynis、ClamAV查毒、Fail2ban防爆破、SuricataIDS完全够用。商业产品如某企业版加固工具重点在于策略集成的便利性但如果你只是做内网合规和防御开源基线工具加上自定义脚本效果不会差太多而且可控性更强。我一般会在方案里列出每个层面对应的工具名、适用版本、输出格式让读者照着选即可。三层模型的价值还在于“定优先级”主机层最容易见效网络层能挡住大半扫描和爆破应用层最繁杂但直接影响业务安全。按照“先主机再网络后应用”的顺序推进每完成一层就做一次回归验证。这样方案不会变成“一次全堆上去出事了找不到根因”。2.3 把方案落成PDF前的结构设计每条加固项要有“目的、操作、验证、回滚”一份能执行的网络安全加固解决方案文档结构不能是纯散文。我写PDF时固定用四列式清单加固项、目的、操作步骤、验证方法与回滚方案。每一行就是一个可以单独验收的最小工作单元。实际操作中直接把这份清单打印出来逐条打勾比看一百页理论更高效。章节设计按资产盘点、主机加固、网络加固、应用加固、监控与应急来组织。其中“验证方法”是绝大多数PDF里最容易被忽视的部分。比如“关闭SSH root远程登录”这一项验证方法应该是“用root用户ssh远程连接确认被拒绝用普通用户登录后su确认可切换”。没有验证就没有闭环。回滚方案也很重要——至少写明“备份原配置文件改动前执行 cp 备份验证失败后恢复”。用这种结构写出的PDF才能真正替代口头经验。3. 主机层加固实操账号口令、SSH配置、基线与补丁3.1 账号与权限收敛从 /etc/passwd 到 sudoers 的逐项检查主机层加固先说账号因为这是最容易出突破口的点。常见的错误是系统中存在很多长期不用的普通用户甚至有人把默认用户口令设成了弱口令。我建议把它作为第一个清零项。检查账号时需要列出所有用户以及UID、组、登录shell。高权限用户UID 0尤其要关注。另一个重点是sudoer列表因为很多攻击者拿到普通用户后会尝试利用sudo配置错误提权。下面这个脚本可以快速产出账号审计报告# 列出所有可登录用户shell不是nologin/false awk -F: $7 ! /sbin/nologin $7 ! /usr/sbin/nologin $7 ! /bin/false {print $1, $3, $6, $7} /etc/passwd # 检查UID 0的特权账号 awk -F: $3 0 {print $1} /etc/passwd # 检查sudoers中有NOPASSWD的条目 grep -r NOPASSWD /etc/sudoers /etc/sudoers.d/ 2/dev/null逻辑说明第一条命令提取所有可以登录系统的普通用户UID 0 的账号只有 root 和特意配置的管理账号才算正常。第二条命令就是为了找出可疑的“影子root”。第三条检查 sudo 时不需要密码的配置这种配置虽然方便但一旦被利用就相当于无口令提权。参数说明-F:指定字段分隔符为冒号$3 0表示第三个字段UID为0。如果你的环境是FreeBSD或Solaris路径会不同需要相应调整。发现问题后处置方式很直接删除或禁用空密码用户、设置密码策略天数、长度、复杂度、把sudo权限收敛到最小集合。密码策略统一通过/etc/login.defs和/etc/pam.d/system-auth来管理。我一般会设置PASS_MAX_DAYS 90、PASS_MIN_LEN 12并且启用pam_pwquality.so。注意这个改动会影响所有存量用户需要提前通知业务负责人。3.2 SSH加固五种必须改的配置与密钥认证SSH是运维的生命线也是被爆破的重灾区。默认的22端口加上root口令登录基本等于把门打开。这里给出一个最小加固集适用于Linux平台。先备份配置文件再改这是铁律。cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) # 修改以下参数推荐值已标注 sed -i s/^#Port 22/Port 2232/ /etc/ssh/sshd_config # 换端口减少扫描 sed -i s/^#PermitRootLogin prohibit-password/PermitRootLogin no/ /etc/ssh/sshd_config sed -i s/^#MaxAuthTries 6/MaxAuthTries 3/ /etc/ssh/sshd_config sed -i s/^#PubkeyAuthentication yes/PubkeyAuthentication yes/ /etc/ssh/sshd_config sed -i s/^#PasswordAuthentication yes/PasswordAuthentication no/ /etc/ssh/sshd_config # 校验配置语法然后重启 sshd -t systemctl restart sshd逻辑说明这一组命令同时做了四件事——更换SSH监听端口、禁止root直接远程登录、限制每连接最大认证尝试次数、强制使用公钥认证并关闭口令认证。参数说明端口建议取一个不冲突的高位端口比如2232但必须同步更新防火墙放行策略否则改完会把自己锁在外面。PermitRootLogin no意味着root无法直接登录但可以用普通用户su -切换。MaxAuthTries 3能大大降低暴力破解的成功率。PasswordAuthentication no是最关键的一项关闭后即使口令被猜中也进不来前提是密钥已经配置完成且可用。改完后必须用另一个终端验证登录。如果密钥没有配置好你会在新会话里被拒绝。所以顺序应该是先配置好公钥、打开密钥认证、测试登录成功后再关闭口令认证。我有一个习惯在sshd_config里同时保留一条Match Address 10.0.0.0/8的例外允许root登录用于堡垒机网络的紧急跳转。这个可以作为选项但不要全公司都这么做。3.3 补丁与基线检查用OpenSCAP把安全基线“量化”账号和SSH是手工项目补丁和基线则适合用自动化工具来扫。OpenSCAP是社区使用最广的基线检查工具它把CIS、STIG等基线转换成可执行的XML规则扫描后输出报告。用它来生成PDF方案里的“整改前基线状态”非常有说服力。先安装并扫描yum install -y openscap-scanner scap-security-guide oscap xccdf eval \ --profile xccdf_org.ssgproject.content_profile_cis \ --results /tmp/scan-results.xml \ --report /tmp/scan-report.html \ /usr/share/xml/scap/ssg/content/ssg-centos-7-ds.xml逻辑说明这条命令使用SCAP安全指南中的CIS profile对系统做基线扫描结果同时输出为XML和HTML报告。其中HTML报告可以直接作为PDF的附录里面逐条写明“通过/失败”。参数说明--profile指定基线标准CIS是等保和日常运维都比较认的标准--report生成网页版报告方便浏览器查看。如果你的系统是RHEL8或9对应的ds.xml路径会变成ssg-rhel8-ds.xml。扫描完成后需要重点看“失败”项那些才是真正要修的。注意OpenSCAP的基线规则可能和某些业务自定义配置冲突比如/etc/issue的内容需要评审后再自动化修复。补丁管理这块内网环境建议用自行搭建的镜像源或wsus不能直接在生产环境执行yum update -y这种全量更新。我的做法是先在测试环境跑一轮yum check-update生成更新列表过滤掉涉及内核和驱动的大版本更新然后把剩余更新应用到生产。内核更新需要重启要有维护窗口。在PDF方案里补丁章节必须写明“分批、可回滚、重启窗口”而不是一句“定期更新”。4. 网络层加固与恶意流量处置防火墙、DNS过滤、检测规则4.1 防火墙最小化策略先默认拒绝再按业务白名单放行网络层加固的第一原则是“默认拒绝”。但很多生产防火墙在实施时管理员会嫌麻烦继续用“默认放行只封几个端口”的做法。这不是加固这是摆设。正确的做法是新建一套规则集先清空再逐条添加业务所需的端口最后把默认策略改成drop。以firewalld为例# 清空默认zone的规则创建业务zone firewall-cmd --permanent --new-zoneproduction firewall-cmd --permanent --set-default-zonedrop # 只允许必要端口根据资产盘点结果 firewall-cmd --permanent --zoneproduction --add-servicessh firewall-cmd --permanent --zoneproduction --add-port80/tcp firewall-cmd --permanent --zoneproduction --add-port443/tcp firewall-cmd --permanent --zoneproduction --add-source192.168.10.0/24 # 加载规则 firewall-cmd --reload逻辑说明先把默认zone设为drop这样未明确放行的流量全部丢弃然后新建production zone把业务网段和端口绑定进去。这里的顺序有讲究必须先添加source再允许端口否则放行会失效。参数说明--add-source指定可信的源IP段用于限制只有办公网或内网可以访问管理端口--add-port的协议默认是tcp需要udp时写成80/udp。如果你用的是iptables命令行的环境可以用iptables-save导出规则备份再逐条插入。注意设置默认drop前务必确认你当前连接的IP在放行规则里否则执行完--reload后自己会被断掉这是翻车频率最高的操作。4.2 恶意域名与黑产团伙的处置流程阻断、DNS过滤、日志溯源标题里提到的“恶意域名反复攻击”场景其实是很多企业内网会遇到的真实问题。某个恶意域名不断尝试连接可能来自失陷主机上的后门也可能是黑产C2。处置不能只封IP因为IP会变域名才是稳定的控制通道。我的标准流程是五步阻断、过滤、溯源、加固、监控。第一步在网络出口和主机本地同时做域名级阻断。Linux主机上可以用hosts文件强制解析到127.0.0.1但更好的办法是使用dnsmasq或unbound做DNS过滤在DNS层面直接返回黑名单。例如在dnsmasq配置中加入echo address/malicious-domain.example/0.0.0.0 /etc/dnsmasq.conf systemctl restart dnsmasq逻辑说明这条配置让dnsmasq对恶意域名的解析直接返回0.0.0.0使依赖该域名的木马无法获得真实IP从而断开C2连接。参数说明格式是address/域名/返回值。如果想阻断整个域名及子域就写domain但dnsmasq的泛域名支持有限更完整的方案是配置server/恶意域名/0.0.0.0或使用rpz规则。对于大规模内网应当在核心DNS服务器上做响应策略RPZ而不是逐台改hosts。第二步是溯源分析。我通常会把防火墙和dnsmasq的日志集中收集然后查有哪些主机解析了恶意域名。命令如下# 模拟从日志中过滤恶意域名解析记录 grep malicious-domain.example /var/log/dnsmasq.log | awk {print $6} | sort | uniq -c # 找出对应的源IP和进程 ss -tnp | grep 恶意IP:逻辑说明第一条命令统计解析恶意域名的客户端数量第二条命令查看当前是否有主机正在与恶意IP建立连接。找到源IP后再去那台主机上检查进程配合ls -l /proc/PID/exe确认是否后门。参数说明$6是dnsmasq日志中客户机IP所在字段实际字段位置可能因版本不同有偏差建议先tail -5确认格式。这一步的目的是定位失陷主机而不是只把域名封掉了事。封域名只是止血杀进程和清持久化才是治本。4.3 用IDS规则与WAF配置把“未知流量”暴露出来网络层的第二道防线是入侵检测。我常用Suricata落地时把规则集分成基础规则、恶意域名规则、业务特定规则三层。对于恶意域名已经确定的情况可以直接写一条自定义规则来告警alert dns any any - any any (msg:Known malicious domain detected; dns.query; content:malicious-domain.example; nocase; sid:1000001; rev:1;)逻辑说明这条规则匹配DNS查询请求只要query字段里出现恶意域名就产生告警。dns.query是Suricata针对DNS协议提取的字段content后面是匹配内容nocase表示忽略大小写。参数说明sid是规则唯一编号自定义规则建议从1000000以上分配避免和默认规则冲突。rev是版本号。规则要放到/etc/suricata/rules/下的自定义文件里然后在suricata.yaml中引用。WAF方面如果业务有Web入口我会在Nginx层配置简单的拦截规则或者用ModSecurity。比如阻止常见的SQL注入探测# nginx location中启用modsecurity并加载OWASP CRS规则 modsecurity on; modsecurity_rules_file /etc/nginx/modsec/crs/ruleset.conf;逻辑说明ModSecurity配合OWASP CRS规则集能拦截大量Web攻击。但要注意启用默认规则后可能产生误杀比如某些业务参数被当作XSS或SQL注入。参数说明modsecurity_rules_file指向规则集主文件实际使用时建议先开启“检测模式”只记录不拦截跑一周看错误日志再切换到拦截模式。这是应用层和网络层的结合部也是踩坑最密集的地方。5. 加固落地中的常见坑与排查现象、原因、解决5.1 加固后业务连接被拒源头是默认策略改为drop后没放行回程流量现象网络层把默认策略改成drop后应用访问时断时续甚至完全不通但端口确实已经放行。原因很多firewalld/iptables的规则只写了入方向允许没有考虑状态跟踪。如果防火墙没有开启conntrack或者iptables规则里缺少ESTABLISHED,RELATED的放行那么业务返回的数据包会被当成新连接丢掉。解决在入口规则最前面加状态放行。firewalld下确保zone中的服务不要直接依赖“新建连接”规则而是使用firewall-cmd --permanent --zoneproduction --add-masquerade会带来问题更好的做法是使用iptables时这样处理iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT测试顺序也应调整先放行已建立连接再放行业务端口最后把默认策略设为drop。我用这条经验救回过不少线上故障尤其是数据库回程连接被掐断的场景。5.2 SSH改端口后连接被拒防火墙和SELinux没有同步放行现象修改sshd端口并重启后从远程无法连接但服务器本机能够正常登录。原因首先想到防火墙放行新端口后还是不行。其实还有一个隐藏点SELinux。如果系统启用了SELinuxsshd_t 域默认只允许监听22端口你通过semanage把新端口类型改成ssh_port_t。否则SELinux会拦截监听行为sshd虽然进程活着但端口根本没绑定。解决执行以下命令并确认结果# 查看SELinux是否开启 getenforce # 允许SSH监听新端口 semanage port -a -t ssh_port_t -p tcp 2232逻辑说明semanage port -a是添加端口映射-t ssh_port_t指定安全上下文-p tcp指定协议。注意如果原来没有允许过会出现“值无效”的报错可以先semanage port -l | grep ssh看现有定义。参数说明新端口必须和sshd_config中的Port值保持一致而且要同时改firewalld和SELinux。很多加固手册只提防火墙不提SELinux这就是最大的坑。如果实在不熟悉SELinux可以在遵循最小权限的前提下用setsebool -P ssh_sysadm_login on放宽某些限制但不要彻底disable SELinux。5.3 补丁工具自动修复后业务进程起不来基线规则的“一刀切”问题现象运行OpenSCAP自动修复后某个Java应用无法启动报错是权限拒绝。原因OpenSCAP的某些CIS规则会收紧文件权限和目录权限比如因为合规要求/etc/passwd必须为644但业务应用写到/var/log的权限被变更或者Java临时目录被设置了noexec。这种“规则正确业务不允许”的冲突是常态。解决不要在默认修复模式下跑所有规则。我的做法是先出扫描报告逐条review“fail”项把业务运行必需且“不影响安全”的规则加上免责注释例如--remediate参数只用于修复已知无冲突的项。具体操作是在扫描时用--tailoring-file自定义一个裁剪文件或者直接手动修复一部分。另外任何基线扫描工具的自动修复在Windows和Linux上都必须启用“变更前备份”这一点大多数文档不会强调。5.4 恶意域名被封后仍然反复出现没有清掉持久化宿主现象DNS过滤生效后告警暂时消失但几天后同一个恶意域名又出现在日志中。原因分析时只封了网络层没有追到主机上的后门。黑产团伙往往会同时运行多个进程甚至利用crontab、systemd timer定期重新下载新的木马样本。重启后木马又复活了。解决处置流程必须包含主机取证使用chkrootkit或rkhunter扫描后门重点检查计划任务、启动项和驱动模块。命令# 查看所有用户计划任务 for user in $(cut -f1 -d: /etc/passwd); do crontab -l -u $user; done # 检查systemd定时器 systemctl list-timers --all --no-pager逻辑说明第一条命令遍历所有用户查看crontab内容第二条列出所有systemd timer。后门通常会注册一个保活定时任务。参数说明如果发现异常任务先通过ls -l /proc/PID/exe找到进程路径然后确认该任务的脚本内容最后删除任务文件并清除相关二进制文件。不要指望断网就能彻底解决必须溯源到根因。这一步做完才算“处置完毕”。5.5 日志被清空导致溯源中断集中收集与只读存储是标配现象攻击者拿到了主机权限删除了/var/log/secure和/var/log/messages导致无法回溯入侵路径。原因单机日志默认存本地任何拿到root权限的攻击者都能清掉。这不是你加固失误是架构上没有做日志防线。解决部署日志集中采集最简单的方式是使用rsyslog将日志实时发送到远程日志服务器同时在网络边界通过镜像端口留存全流量。# rsyslog配置示例将auth和内核日志转发到远程日志中心 echo *.info 192.168.1.100:514 /etc/rsyslog.conf systemctl restart rsyslog逻辑说明这条配置让rsyslog把所有info以上级别的日志UDP发送到远程日志服务器192.168.1.100的514端口。参数说明表示UDP协议表示TCP协议。内网建议用TCP保证不丢包。远程日志服务器需要配置磁盘空间告警只读挂载更好。在加固方案PDF中这一条必须放在监控与审计章节并且明确要求实现“日志至少保留180天”。6. 让加固方案持续有效基线检查自动化与定期验证加固不是一次性项目而是持续性的运维动作。我会把前面写的OpenSCAP基线扫描命令放进cron每周自动跑一次并把HTML报告发送到指定的审计邮箱或者内部wiki。这里分享一个自己用了很久的组合用oscap配合report参数生成报告再用脚本根据报告标题里的“failed”数字判断是否触发告警。#!/bin/bash # 每周日凌晨2点执行扫描并生成报告 0 2 * * 0 \ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \ --results /var/lib/oscap/results-weekly.xml \ --report /var/lib/oscap/report-weekly.html \ /usr/share/xml/scap/ssg/content/ssg-centos-7-ds.xml \ curl -F file/var/lib/oscap/report-weekly.html http://wiki.internal/upload 2/dev/null逻辑说明这行cron将每周日的扫描结果上传到内部wiki方便安全团队和运维团队共同查看。参数说明表示扫描成功后才上传避免上传空的失败报告curl -F是用表单方式上传文件如果你的wiki不支持可以用scp或者做成邮件附件。注意扫描会消耗CPU建议放在业务低峰期。除了自动化扫描我每个月还会手动做一次“最小权限验证”用普通用户尝试执行 sudo -l确认没有新增的提权路径用nmap从外部扫一遍核心端口确认没有新增暴露再随机挑一台机器检查/tmp下是否有可疑的可执行文件。这些动作虽然简单但能防止加固措施随着时间的推移被业务人员悄悄改回去。最后说一个个人教训我最初设计加固方案时总想把所有安全项都调到最强结果业务不断来报障最后被迫回滚了一半规则。后来我记住了“加固的底线是业务连续性”。每一步操作都要写回滚方案每一个参数都要留余地比如SSH的MaxAuthTries设为3而不是1比如WAF先观察再拦截。安全方案不是越硬越好而是在可控范围内尽可能封闭。这份淡化在PDF中的原则才是方案能落地的关键。希望帮到你。本文还有配套的精品资源点击获取 网络安全加固解决方案落地指南：从基线清单到主机与网络层实操
简介一份面向网络管理员、信息安全工程师及企业IT负责人的网络安全加固方案PDF文档围绕对外网信息系统在升级改造与安全防护中的整体需求展开。方案开篇梳理了项目背景、建设目标及参考标准明确需求、风险、代价平衡分析综合性、整体性、动态保护、一致性、强制性、易操作与多重保护等设计原则并给出网络系统现状拓扑分析。核心部分重点阐述网络系统升级改造方案与安全加固技术方案涵盖二层交换机替换、集中控管无线AP部署、POE供电、核心交换与安全设备UPS保障、安全设备部署及用途等落地细节同时提供产品清单便于实际采购与实施参考。资源包为1个pdf文件大小约840KB目录结构完整内容覆盖从现状诊断到方案落地的全过程。目前已有353人学习下载适合需要快速建立安全加固方案框架并对照项目实践的中高级技术人员使用。1. 网络安全加固解决方案不是报告而是要执行的“基线清单”收到一份名为“网络安全加固解决方案.pdf”的文档很多团队的惯性动作是存档、传阅、归档然后等下次等保检查时再翻出来。这正好是本末倒置。真正有价值的网络安全加固解决方案不是给审计看的合规材料而是一份能照着实操的基线清单它明确告诉你先加固什么、怎么做、参数改到什么程度、改完怎么验证。它的落地形态可以是PDF但必须是“拿起来就能执行”的文档而不是“看完觉得讲得很对”的文档。这篇笔记我按自己做等保整改和应急加固的经验把这个标题拆透方案怎么设计、主机层和网络层怎么做、最容易踩哪些坑、以及怎么让这份方案不是一次性文件。2. 设计加固方案的框架先盘资产再分三层最后落到文档结构2.1 加固的第一步不是“打补丁”而是回答“资产在哪谁在访问”我见过太多团队拿到加固需求后第一件事是登录服务器跑更新结果三天后核心业务宕机因为不知道那台服务器还承载着老旧的PHP接口。做网络安全加固解决方案第一步永远是资产梳理。资产梳理不是简单列IP而是要建立一张“信息资产台账”至少包含主机名、IP、操作系统版本、中间件版本、开放端口、关联业务、负责人、数据等级。没有这张表后面所有加固动作都是盲目的。我一般会用三个来源补齐台账CMDB如果有、扫描器结果Nmap或Masscan、端口比较用 ss -tlnp 和实际监听比对。端口梳理是特别容易漏的一环。很多主机自己以为只开了80和443实际上一跑ss -tlnp发现还有22、3306、6379暴露在外网。排查时我会用下面的命令把监听端口和对应进程落盘ss -tlnp /tmp/open_ports.txt # 同时把对外映射的IP也记下来 ip addr show | grep inet /tmp/open_ports.txt逻辑说明ss -tlnp列出所有TCP监听端口-t是TCP-l是监听-n是不解析域名-p是显示进程号。这些信息会告诉你端口被哪个进程占用方便追溯到中间件或数据库。参数说明如果你只想看对外暴露的地址可以加上state listening过滤或者用ss -tlnp | grep -v 127.0.0.1把本地回环过滤掉剩下的一般就是需要重点关注的对外端口。完成这一步后你才能在PDF里画出一张“网络拓扑资产表”这张表决定后续防火墙白名单怎么写、补丁优先级怎么排。2.2 三层加固模型主机层、网络层、应用层各自的武器网络安全加固解决方案的框架我习惯按“主机层、网络层、应用层”三层来拆。这不是什么新理论但能保证不遗漏。主机层解决的是“这台机器本身脆不脆”包括账号口令、补丁、SSH配置、文件权限、内核参数网络层解决的是“谁能到这台机器”包括防火墙策略、DNS过滤、入侵检测、恶意流量阻断应用层解决的是“运行在这台机器上的业务有没有漏洞”包括Web中间件配置、WAF规则、接口鉴权、日志审计。工具选型上不要盲目追求商业套件。开源的OpenSCAP、Lynis、ClamAV查毒、Fail2ban防爆破、SuricataIDS完全够用。商业产品如某企业版加固工具重点在于策略集成的便利性但如果你只是做内网合规和防御开源基线工具加上自定义脚本效果不会差太多而且可控性更强。我一般会在方案里列出每个层面对应的工具名、适用版本、输出格式让读者照着选即可。三层模型的价值还在于“定优先级”主机层最容易见效网络层能挡住大半扫描和爆破应用层最繁杂但直接影响业务安全。按照“先主机再网络后应用”的顺序推进每完成一层就做一次回归验证。这样方案不会变成“一次全堆上去出事了找不到根因”。2.3 把方案落成PDF前的结构设计每条加固项要有“目的、操作、验证、回滚”一份能执行的网络安全加固解决方案文档结构不能是纯散文。我写PDF时固定用四列式清单加固项、目的、操作步骤、验证方法与回滚方案。每一行就是一个可以单独验收的最小工作单元。实际操作中直接把这份清单打印出来逐条打勾比看一百页理论更高效。章节设计按资产盘点、主机加固、网络加固、应用加固、监控与应急来组织。其中“验证方法”是绝大多数PDF里最容易被忽视的部分。比如“关闭SSH root远程登录”这一项验证方法应该是“用root用户ssh远程连接确认被拒绝用普通用户登录后su确认可切换”。没有验证就没有闭环。回滚方案也很重要——至少写明“备份原配置文件改动前执行 cp 备份验证失败后恢复”。用这种结构写出的PDF才能真正替代口头经验。3. 主机层加固实操账号口令、SSH配置、基线与补丁3.1 账号与权限收敛从 /etc/passwd 到 sudoers 的逐项检查主机层加固先说账号因为这是最容易出突破口的点。常见的错误是系统中存在很多长期不用的普通用户甚至有人把默认用户口令设成了弱口令。我建议把它作为第一个清零项。检查账号时需要列出所有用户以及UID、组、登录shell。高权限用户UID 0尤其要关注。另一个重点是sudoer列表因为很多攻击者拿到普通用户后会尝试利用sudo配置错误提权。下面这个脚本可以快速产出账号审计报告# 列出所有可登录用户shell不是nologin/false awk -F: $7 ! /sbin/nologin $7 ! /usr/sbin/nologin $7 ! /bin/false {print $1, $3, $6, $7} /etc/passwd # 检查UID 0的特权账号 awk -F: $3 0 {print $1} /etc/passwd # 检查sudoers中有NOPASSWD的条目 grep -r NOPASSWD /etc/sudoers /etc/sudoers.d/ 2/dev/null逻辑说明第一条命令提取所有可以登录系统的普通用户UID 0 的账号只有 root 和特意配置的管理账号才算正常。第二条命令就是为了找出可疑的“影子root”。第三条检查 sudo 时不需要密码的配置这种配置虽然方便但一旦被利用就相当于无口令提权。参数说明-F:指定字段分隔符为冒号$3 0表示第三个字段UID为0。如果你的环境是FreeBSD或Solaris路径会不同需要相应调整。发现问题后处置方式很直接删除或禁用空密码用户、设置密码策略天数、长度、复杂度、把sudo权限收敛到最小集合。密码策略统一通过/etc/login.defs和/etc/pam.d/system-auth来管理。我一般会设置PASS_MAX_DAYS 90、PASS_MIN_LEN 12并且启用pam_pwquality.so。注意这个改动会影响所有存量用户需要提前通知业务负责人。3.2 SSH加固五种必须改的配置与密钥认证SSH是运维的生命线也是被爆破的重灾区。默认的22端口加上root口令登录基本等于把门打开。这里给出一个最小加固集适用于Linux平台。先备份配置文件再改这是铁律。cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) # 修改以下参数推荐值已标注 sed -i s/^#Port 22/Port 2232/ /etc/ssh/sshd_config # 换端口减少扫描 sed -i s/^#PermitRootLogin prohibit-password/PermitRootLogin no/ /etc/ssh/sshd_config sed -i s/^#MaxAuthTries 6/MaxAuthTries 3/ /etc/ssh/sshd_config sed -i s/^#PubkeyAuthentication yes/PubkeyAuthentication yes/ /etc/ssh/sshd_config sed -i s/^#PasswordAuthentication yes/PasswordAuthentication no/ /etc/ssh/sshd_config # 校验配置语法然后重启 sshd -t systemctl restart sshd逻辑说明这一组命令同时做了四件事——更换SSH监听端口、禁止root直接远程登录、限制每连接最大认证尝试次数、强制使用公钥认证并关闭口令认证。参数说明端口建议取一个不冲突的高位端口比如2232但必须同步更新防火墙放行策略否则改完会把自己锁在外面。PermitRootLogin no意味着root无法直接登录但可以用普通用户su -切换。MaxAuthTries 3能大大降低暴力破解的成功率。PasswordAuthentication no是最关键的一项关闭后即使口令被猜中也进不来前提是密钥已经配置完成且可用。改完后必须用另一个终端验证登录。如果密钥没有配置好你会在新会话里被拒绝。所以顺序应该是先配置好公钥、打开密钥认证、测试登录成功后再关闭口令认证。我有一个习惯在sshd_config里同时保留一条Match Address 10.0.0.0/8的例外允许root登录用于堡垒机网络的紧急跳转。这个可以作为选项但不要全公司都这么做。3.3 补丁与基线检查用OpenSCAP把安全基线“量化”账号和SSH是手工项目补丁和基线则适合用自动化工具来扫。OpenSCAP是社区使用最广的基线检查工具它把CIS、STIG等基线转换成可执行的XML规则扫描后输出报告。用它来生成PDF方案里的“整改前基线状态”非常有说服力。先安装并扫描yum install -y openscap-scanner scap-security-guide oscap xccdf eval \ --profile xccdf_org.ssgproject.content_profile_cis \ --results /tmp/scan-results.xml \ --report /tmp/scan-report.html \ /usr/share/xml/scap/ssg/content/ssg-centos-7-ds.xml逻辑说明这条命令使用SCAP安全指南中的CIS profile对系统做基线扫描结果同时输出为XML和HTML报告。其中HTML报告可以直接作为PDF的附录里面逐条写明“通过/失败”。参数说明--profile指定基线标准CIS是等保和日常运维都比较认的标准--report生成网页版报告方便浏览器查看。如果你的系统是RHEL8或9对应的ds.xml路径会变成ssg-rhel8-ds.xml。扫描完成后需要重点看“失败”项那些才是真正要修的。注意OpenSCAP的基线规则可能和某些业务自定义配置冲突比如/etc/issue的内容需要评审后再自动化修复。补丁管理这块内网环境建议用自行搭建的镜像源或wsus不能直接在生产环境执行yum update -y这种全量更新。我的做法是先在测试环境跑一轮yum check-update生成更新列表过滤掉涉及内核和驱动的大版本更新然后把剩余更新应用到生产。内核更新需要重启要有维护窗口。在PDF方案里补丁章节必须写明“分批、可回滚、重启窗口”而不是一句“定期更新”。4. 网络层加固与恶意流量处置防火墙、DNS过滤、检测规则4.1 防火墙最小化策略先默认拒绝再按业务白名单放行网络层加固的第一原则是“默认拒绝”。但很多生产防火墙在实施时管理员会嫌麻烦继续用“默认放行只封几个端口”的做法。这不是加固这是摆设。正确的做法是新建一套规则集先清空再逐条添加业务所需的端口最后把默认策略改成drop。以firewalld为例# 清空默认zone的规则创建业务zone firewall-cmd --permanent --new-zoneproduction firewall-cmd --permanent --set-default-zonedrop # 只允许必要端口根据资产盘点结果 firewall-cmd --permanent --zoneproduction --add-servicessh firewall-cmd --permanent --zoneproduction --add-port80/tcp firewall-cmd --permanent --zoneproduction --add-port443/tcp firewall-cmd --permanent --zoneproduction --add-source192.168.10.0/24 # 加载规则 firewall-cmd --reload逻辑说明先把默认zone设为drop这样未明确放行的流量全部丢弃然后新建production zone把业务网段和端口绑定进去。这里的顺序有讲究必须先添加source再允许端口否则放行会失效。参数说明--add-source指定可信的源IP段用于限制只有办公网或内网可以访问管理端口--add-port的协议默认是tcp需要udp时写成80/udp。如果你用的是iptables命令行的环境可以用iptables-save导出规则备份再逐条插入。注意设置默认drop前务必确认你当前连接的IP在放行规则里否则执行完--reload后自己会被断掉这是翻车频率最高的操作。4.2 恶意域名与黑产团伙的处置流程阻断、DNS过滤、日志溯源标题里提到的“恶意域名反复攻击”场景其实是很多企业内网会遇到的真实问题。某个恶意域名不断尝试连接可能来自失陷主机上的后门也可能是黑产C2。处置不能只封IP因为IP会变域名才是稳定的控制通道。我的标准流程是五步阻断、过滤、溯源、加固、监控。第一步在网络出口和主机本地同时做域名级阻断。Linux主机上可以用hosts文件强制解析到127.0.0.1但更好的办法是使用dnsmasq或unbound做DNS过滤在DNS层面直接返回黑名单。例如在dnsmasq配置中加入echo address/malicious-domain.example/0.0.0.0 /etc/dnsmasq.conf systemctl restart dnsmasq逻辑说明这条配置让dnsmasq对恶意域名的解析直接返回0.0.0.0使依赖该域名的木马无法获得真实IP从而断开C2连接。参数说明格式是address/域名/返回值。如果想阻断整个域名及子域就写domain但dnsmasq的泛域名支持有限更完整的方案是配置server/恶意域名/0.0.0.0或使用rpz规则。对于大规模内网应当在核心DNS服务器上做响应策略RPZ而不是逐台改hosts。第二步是溯源分析。我通常会把防火墙和dnsmasq的日志集中收集然后查有哪些主机解析了恶意域名。命令如下# 模拟从日志中过滤恶意域名解析记录 grep malicious-domain.example /var/log/dnsmasq.log | awk {print $6} | sort | uniq -c # 找出对应的源IP和进程 ss -tnp | grep 恶意IP:逻辑说明第一条命令统计解析恶意域名的客户端数量第二条命令查看当前是否有主机正在与恶意IP建立连接。找到源IP后再去那台主机上检查进程配合ls -l /proc/PID/exe确认是否后门。参数说明$6是dnsmasq日志中客户机IP所在字段实际字段位置可能因版本不同有偏差建议先tail -5确认格式。这一步的目的是定位失陷主机而不是只把域名封掉了事。封域名只是止血杀进程和清持久化才是治本。4.3 用IDS规则与WAF配置把“未知流量”暴露出来网络层的第二道防线是入侵检测。我常用Suricata落地时把规则集分成基础规则、恶意域名规则、业务特定规则三层。对于恶意域名已经确定的情况可以直接写一条自定义规则来告警alert dns any any - any any (msg:Known malicious domain detected; dns.query; content:malicious-domain.example; nocase; sid:1000001; rev:1;)逻辑说明这条规则匹配DNS查询请求只要query字段里出现恶意域名就产生告警。dns.query是Suricata针对DNS协议提取的字段content后面是匹配内容nocase表示忽略大小写。参数说明sid是规则唯一编号自定义规则建议从1000000以上分配避免和默认规则冲突。rev是版本号。规则要放到/etc/suricata/rules/下的自定义文件里然后在suricata.yaml中引用。WAF方面如果业务有Web入口我会在Nginx层配置简单的拦截规则或者用ModSecurity。比如阻止常见的SQL注入探测# nginx location中启用modsecurity并加载OWASP CRS规则 modsecurity on; modsecurity_rules_file /etc/nginx/modsec/crs/ruleset.conf;逻辑说明ModSecurity配合OWASP CRS规则集能拦截大量Web攻击。但要注意启用默认规则后可能产生误杀比如某些业务参数被当作XSS或SQL注入。参数说明modsecurity_rules_file指向规则集主文件实际使用时建议先开启“检测模式”只记录不拦截跑一周看错误日志再切换到拦截模式。这是应用层和网络层的结合部也是踩坑最密集的地方。5. 加固落地中的常见坑与排查现象、原因、解决5.1 加固后业务连接被拒源头是默认策略改为drop后没放行回程流量现象网络层把默认策略改成drop后应用访问时断时续甚至完全不通但端口确实已经放行。原因很多firewalld/iptables的规则只写了入方向允许没有考虑状态跟踪。如果防火墙没有开启conntrack或者iptables规则里缺少ESTABLISHED,RELATED的放行那么业务返回的数据包会被当成新连接丢掉。解决在入口规则最前面加状态放行。firewalld下确保zone中的服务不要直接依赖“新建连接”规则而是使用firewall-cmd --permanent --zoneproduction --add-masquerade会带来问题更好的做法是使用iptables时这样处理iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT测试顺序也应调整先放行已建立连接再放行业务端口最后把默认策略设为drop。我用这条经验救回过不少线上故障尤其是数据库回程连接被掐断的场景。5.2 SSH改端口后连接被拒防火墙和SELinux没有同步放行现象修改sshd端口并重启后从远程无法连接但服务器本机能够正常登录。原因首先想到防火墙放行新端口后还是不行。其实还有一个隐藏点SELinux。如果系统启用了SELinuxsshd_t 域默认只允许监听22端口你通过semanage把新端口类型改成ssh_port_t。否则SELinux会拦截监听行为sshd虽然进程活着但端口根本没绑定。解决执行以下命令并确认结果# 查看SELinux是否开启 getenforce # 允许SSH监听新端口 semanage port -a -t ssh_port_t -p tcp 2232逻辑说明semanage port -a是添加端口映射-t ssh_port_t指定安全上下文-p tcp指定协议。注意如果原来没有允许过会出现“值无效”的报错可以先semanage port -l | grep ssh看现有定义。参数说明新端口必须和sshd_config中的Port值保持一致而且要同时改firewalld和SELinux。很多加固手册只提防火墙不提SELinux这就是最大的坑。如果实在不熟悉SELinux可以在遵循最小权限的前提下用setsebool -P ssh_sysadm_login on放宽某些限制但不要彻底disable SELinux。5.3 补丁工具自动修复后业务进程起不来基线规则的“一刀切”问题现象运行OpenSCAP自动修复后某个Java应用无法启动报错是权限拒绝。原因OpenSCAP的某些CIS规则会收紧文件权限和目录权限比如因为合规要求/etc/passwd必须为644但业务应用写到/var/log的权限被变更或者Java临时目录被设置了noexec。这种“规则正确业务不允许”的冲突是常态。解决不要在默认修复模式下跑所有规则。我的做法是先出扫描报告逐条review“fail”项把业务运行必需且“不影响安全”的规则加上免责注释例如--remediate参数只用于修复已知无冲突的项。具体操作是在扫描时用--tailoring-file自定义一个裁剪文件或者直接手动修复一部分。另外任何基线扫描工具的自动修复在Windows和Linux上都必须启用“变更前备份”这一点大多数文档不会强调。5.4 恶意域名被封后仍然反复出现没有清掉持久化宿主现象DNS过滤生效后告警暂时消失但几天后同一个恶意域名又出现在日志中。原因分析时只封了网络层没有追到主机上的后门。黑产团伙往往会同时运行多个进程甚至利用crontab、systemd timer定期重新下载新的木马样本。重启后木马又复活了。解决处置流程必须包含主机取证使用chkrootkit或rkhunter扫描后门重点检查计划任务、启动项和驱动模块。命令# 查看所有用户计划任务 for user in $(cut -f1 -d: /etc/passwd); do crontab -l -u $user; done # 检查systemd定时器 systemctl list-timers --all --no-pager逻辑说明第一条命令遍历所有用户查看crontab内容第二条列出所有systemd timer。后门通常会注册一个保活定时任务。参数说明如果发现异常任务先通过ls -l /proc/PID/exe找到进程路径然后确认该任务的脚本内容最后删除任务文件并清除相关二进制文件。不要指望断网就能彻底解决必须溯源到根因。这一步做完才算“处置完毕”。5.5 日志被清空导致溯源中断集中收集与只读存储是标配现象攻击者拿到了主机权限删除了/var/log/secure和/var/log/messages导致无法回溯入侵路径。原因单机日志默认存本地任何拿到root权限的攻击者都能清掉。这不是你加固失误是架构上没有做日志防线。解决部署日志集中采集最简单的方式是使用rsyslog将日志实时发送到远程日志服务器同时在网络边界通过镜像端口留存全流量。# rsyslog配置示例将auth和内核日志转发到远程日志中心 echo *.info 192.168.1.100:514 /etc/rsyslog.conf systemctl restart rsyslog逻辑说明这条配置让rsyslog把所有info以上级别的日志UDP发送到远程日志服务器192.168.1.100的514端口。参数说明表示UDP协议表示TCP协议。内网建议用TCP保证不丢包。远程日志服务器需要配置磁盘空间告警只读挂载更好。在加固方案PDF中这一条必须放在监控与审计章节并且明确要求实现“日志至少保留180天”。6. 让加固方案持续有效基线检查自动化与定期验证加固不是一次性项目而是持续性的运维动作。我会把前面写的OpenSCAP基线扫描命令放进cron每周自动跑一次并把HTML报告发送到指定的审计邮箱或者内部wiki。这里分享一个自己用了很久的组合用oscap配合report参数生成报告再用脚本根据报告标题里的“failed”数字判断是否触发告警。#!/bin/bash # 每周日凌晨2点执行扫描并生成报告 0 2 * * 0 \ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \ --results /var/lib/oscap/results-weekly.xml \ --report /var/lib/oscap/report-weekly.html \ /usr/share/xml/scap/ssg/content/ssg-centos-7-ds.xml \ curl -F file/var/lib/oscap/report-weekly.html http://wiki.internal/upload 2/dev/null逻辑说明这行cron将每周日的扫描结果上传到内部wiki方便安全团队和运维团队共同查看。参数说明表示扫描成功后才上传避免上传空的失败报告curl -F是用表单方式上传文件如果你的wiki不支持可以用scp或者做成邮件附件。注意扫描会消耗CPU建议放在业务低峰期。除了自动化扫描我每个月还会手动做一次“最小权限验证”用普通用户尝试执行 sudo -l确认没有新增的提权路径用nmap从外部扫一遍核心端口确认没有新增暴露再随机挑一台机器检查/tmp下是否有可疑的可执行文件。这些动作虽然简单但能防止加固措施随着时间的推移被业务人员悄悄改回去。最后说一个个人教训我最初设计加固方案时总想把所有安全项都调到最强结果业务不断来报障最后被迫回滚了一半规则。后来我记住了“加固的底线是业务连续性”。每一步操作都要写回滚方案每一个参数都要留余地比如SSH的MaxAuthTries设为3而不是1比如WAF先观察再拦截。安全方案不是越硬越好而是在可控范围内尽可能封闭。这份淡化在PDF中的原则才是方案能落地的关键。希望帮到你。本文还有配套的精品资源点击获取