简介这是一份PDF格式的期刊文章主题聚焦常见计算机网络安全威胁及防范措施适合网络安全初学者、网络管理员以及需要撰写相关论文的学生作为参考文献。文章首先阐述计算机网络安全的基本含义与三大特征包括完整性、机密性和可用性帮助读者建立安全认知框架随后逐一分析计算机病毒、软件漏洞与后门、木马程序、黑客攻击等常见威胁并结合实际说明其传播途径与危害表现。在防范层面文中重点讲解防火墙技术、防病毒软件部署等实用对策并针对不同应用场景给出配置思路与注意事项。资源为单个PDF文件大小约699KB内容结构完整、排版清晰可方便地在线阅读、下载保存或打印使用。截至目前这份PDF文档已有346人学习对于快速掌握网络安全基础知识和日常安全防护具有较好的参考价值。1. 为什么你天天做安全网络还是一样被打穿做运维最憋屈的事不是服务器宕机而是你明明装了防火墙、上了杀毒、设了强密码内网还是被勒索病毒一锅端。你翻出那本《常见计算机网络安全威胁及安全防范措施.pdf》读完发现每一条都对得上但就是不知道从哪儿先动手。这个问题不是知识量不够而是威胁清单和防护动作之间缺了一条连接线——你知道有哪些威胁却不知道自己的网络到底暴露在哪一层。这篇内容的价值在于把「常见威胁」和「安全防范措施」这两件事揉在一起讲先带你识别攻击者的真实入口再给你一套按优先级落地的防护动作最后把最容易翻车的地方单独拎出来。不管你是刚接手公司网络的兼职运维还是被老板逼着写安全整改方案的IT负责人照着这篇一步步做至少能把80%的常见攻击路数挡在门外。适合那些不想堆设备、不想买天价安全产品只想把现有网络真正加固起来的人。2. 常见计算机网络安全威胁的分类与攻击路径先看清敌人怎么进来2.1 恶意软件勒索病毒与挖矿木马为什么总是打不干净恶意软件是大多数运维第一个遇到的威胁其中勒索病毒和挖矿木马占了大头。勒索病毒的典型攻击链是通过钓鱼邮件附件进入办公网利用永恒之蓝这类漏洞横向传播最后在域控上批量加密文件。挖矿木马则更喜欢扫公网开放的高危端口拿到权限后植入内网批量爆破。两者的共同点是都依赖「入口 横移 持久化」这三步。要判断自己的网络是否存在恶意软件风险可以按端口开放情况和登录日志来排查。常见弱口令端口像 3389、22、3306 是最容易被扫到的入口如果这些端口暴露在公网基本等于把大门钥匙挂在门口。攻击者用通行证字典跑一遍密码弱口令直接就进去了。勒索病毒加密文件时 CPU 会飙高挖矿木马更是会持续占满 CPU这两类相对容易在性能监控里发现。排查恶意软件时我一般会先看网络连接而不是直接杀毒。因为杀毒软件能查到的都是已经入库的样本新的变种往往能绕过检测。用系统自带的 netstat 看外联 IP再用进程检查工具定位到具体的 PID反而更快。真正的难点在于清除之后的恢复就算把病毒样本隔离了被加密的文件如果没有备份基本没有后悔药可以吃。所以恶意软件的防护核心不是杀毒软件多强而是备份策略能不能兜底。2.2 网络攻击DDoS 与中间人攻击的识别要点DDoS 攻击是最不讲道理的一种威胁它不跟你玩漏洞和权限直接把你带宽和连接数打满。常见的类型有 SYN Flood、UDP Flood、HTTP Flood 三种。SYN Flood 靠发大量的半连接请求耗尽连接表UDP Flood 靠垃圾包占满带宽HTTP Flood 则更聪明模拟真实浏览器请求打慢速攻击让 Web 服务器一直挂着线程不放。如果你发现交换机 CPU 飙升、外网出口流量异常、Web 服务响应变慢但服务器负载不高大概率是被流量攻击了。中间人攻击在局域网里更隐蔽。攻击者通过 ARP 欺骗把网关的流量引到自己机器上然后抓包分析明文协议。HTTP、Telnet、FTP 这类不加密的流量基本等于裸奔密码和 Cookie 都能直接看到。判断自己是否被 ARP 欺骗可以在网关或核心交换机上看 IP 和 MAC 的对应关系如果同一个 IP 对应了多个 MAC或者某个 MAC 频繁变化就要警惕了。中间人攻击的防护思路是加密所有敏感协议。SSH 替代 Telnet、HTTPS 替代 HTTP、SFTP 替代 FTP这三条做好了即使流量被截获攻击者拿到的也是密文。至于 DDoS单靠防火墙硬扛不现实常见做法是在运营商侧或高防节点做流量清洗把攻击流量引走只放行正常请求。2.3 Web 攻击与钓鱼SQL 注入和社会工程学为什么防不胜防Web 攻击和钓鱼是两类性质完全不同的威胁。SQL 注入和 XSS 属于技术型攻击攻击者需要找到代码层的漏洞钓鱼和社会工程学则直接攻击人不需要任何漏洞只需要一封像样的邮件。从实际案例来看钓鱼成功率比 SQL 注入高得多因为技术漏洞可以通过代码审计和 WAF 补上人的判断力却很难标准化。SQL 注入的典型特征是 URL 参数异常比如在地址栏的 id 参数后面加单引号、and 11 这类 SQL 语句。防范办法也很成熟使用参数化查询替代字符串拼接、数据库账号按最小权限分配、Web 层部署 WAF 拦截恶意请求。但很多小团队的代码不规范SQL 语句直接写在业务代码里查都查不完。这种时候WAF 的规则就得写得细一点至少要拦住联合查询、报错注入、布尔盲注这几类常见手法。钓鱼邮件防范的难点在于技术手段帮不上大忙。邮件网关能过滤掉大部分群发钓鱼但针对个人的鱼叉攻击攻击者会花时间研究你的业务场景、模仿领导口吻这种邮件几乎无法用规则识别。比较有效的办法有两个一是定期做钓鱼演练统计中招率用真实数据让管理层重视二是对涉及转账、密码重置、账号权限变更的邮件做二次确认机制人是不可靠的流程要补上这道保险。2.4 内部威胁与供应链风险最容易被忽略的两个盲区内部威胁是讨论最少但破坏力最大的类别。一个有权访问数据库的离职员工如果账号没有及时注销就能把客户资料全部导走。内部威胁不一定是恶意的也有员工把公司代码传到个人仓库或者把生产库下载到本地办公电脑分析结果电脑中了木马。对于这类问题技术上能做的是缩小权限范围和审计高危操作数据库账号按项目分配、离职当天关闭所有系统账号、堡垒机记录每一条指令。供应链风险则是更上游的问题。你用的组件、依赖库、第三方服务如果上游被污染你的系统再安全也没用。印象比较深的是几年前的事件某个知名的压缩包工具被植入后门大量使用该工具打包的软件都带了后门。这类风险的防范措施是建立依赖清单锁定版本号不随意升级同时对关键的第三方组件做哈希校验。内部威胁和供应链风险的共同点是「你信任的东西出了问题」——信任的员工和信任的组件。安全防范措施不能只防外部攻击内部权限的定期复审和依赖库的版本管理应该像系统补丁一样按周期执行。3. 安全防范措施落地从边界防护到主机加固的操作指南3.1 防火墙策略配置用最小白名单规则替换黑名单思路防火墙是网络安全的第一道闸门但很多人把防火墙用成了摆设——默认允许所有流量只拦截已知恶意的 IP这种黑名单思路在今天的威胁环境下基本等于裸奔。正确的做法是默认拒绝只开放业务必需的端口和 IP也就是白名单模式。这一步做完内网的暴露面会直接缩小一大截。以 Linux 服务器常见配置为例用 iptables 完成白名单规则设置# 默认策略拒绝所有入站流量 iptables -P INPUT DROP # 放行回环与已建立的连接 iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # 只允许内网网段访问 SSH其余来源全部拒绝 iptables -A INPUT -i eth0 -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 22 -j DROP # 只开放 80/443 给所有来源 iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT这段配置的逻辑是先拒绝所有 INPUT 流量再按需放行。回环必须放行否则本机进程间通信会出问题已建立的连接放行是为了保证出站访问的响应包能回来如果不加这条服务器能发出去请求但收不到回应。SSH 只对 192.168.1.0/24 开放管理入口不在内网范围内的人连不上这个是阻断横向移动的关键点。参数设置上需要注意一个坑规则顺序很重要。iptables 是自上而下匹配的一旦匹配就不再往下走所以放行规则必须写在拒绝规则前面。上面 SSH 的两条规则如果换顺序先执行 DROP 再执行 ACCEPT那内网也连不上了。很多人改了防火墙之后自己也被关在门外大多是这个问题。改规则之前先执行iptables-save /root/iptables-backup.rules留个备份改完先不要保存测试通了再持久化这是最重要的操作习惯。3.2 主机加固SSH 安全配置与账户登录策略主机层面最容易被攻击的就是 SSH 和系统账户。默认 SSH 配置里开放了 root 登录、允许密码认证这等于同时给了攻击者两个方便之门root 用户名不用猜密码可以无限爆破。加固的核心就是关掉这两个默认开关并限制登录来源。修改 /etc/ssh/sshd_config 关键参数PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes AllowUsers ops192.168.1.* admin192.168.10.* MaxAuthTries 3参数说明PermitRootLogin 设为 no 是禁止 root 直接通过 SSH 登录管理员先用普通用户登录再 su 或 sudo 切换到 root这样攻击者需要同时猜对普通用户名和密码才能前进。PasswordAuthentication 设为 no 是关闭密码登录改用密钥认证密钥比密码安全得多而且无法远程爆破。AllowUsers 限制只有指定用户、来自指定网段的连接才允许登录其他一律拒绝。MaxAuthTries 限制认证次数为 3防止爆破。改完配置后用sshd -t检查语法没问题再systemctl reload sshd。强烈建议先开一个新的 SSH 会话测试密钥登录成功后再断开旧会话否则配置写错直接连不上要去机房或者带外管理口才能救回来。密钥生成建议用 ed25519 而不是 RSA执行ssh-keygen -t ed25519 -a 100私钥留在本地公钥放到服务器的 authorized_keys 里。用 sudo 登录的用户需要在 sudoers 里配好权限否则普通用户登录后也无法提权。账户策略方面CentOS/RHEL 系要改 /etc/security/pwquality.conf 和 /etc/login.defs 两个文件。核心参数是密码最小长度 12 位、至少包含三类字符大小写/数字/特殊符号、新密码不能与旧密码相同。密码策略设置# /etc/security/pwquality.conf minlen 12 minclass 3 maxrepeat 2 # /etc/login.defs PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 14密码最强也没用——如果用户三个月不换泄露的风险随时间增长。PASS_MAX_DAYS 90 是定期换密码PASS_MIN_DAYS 7 是防止用户设置完马上又改回去绕过历史记录检查。这些参数在很多安全核查和等保测评里都有要求一次性配好省得到时候再返工。3.3 补丁管理与漏洞修复决定你被勒索病毒盯上的概率如果说防火墙和 SSH 加固是缩小入口补丁管理就是直接堵住已知漏洞。勒索病毒最喜欢打的就是那种互联网上已经公开了 PoC 的漏洞因为利用工具现成扫描器一扫一个准。永恒之蓝是 2017 年的老漏洞至今还有大量内网机器中招原因是系统不更新SMB 漏洞一直存在。补丁管理不需要什么高深技术把流程跑通就行。第一件事是盘点资产。写个脚本扫描内网所有主机把操作系统版本、补丁日期、开放端口收集起来。Nmap 是这里用得最顺手的工具# 扫描内网主机开放端口快速定位暴露面大的机器 nmap -sS -p 22,135,139,445,3389,3306,6379 192.168.1.0/24参数说明-sS 是 TCP SYN 半开扫描速度快且不建立完整连接-p 后面的端口列表是攻击者最常用的入口如果你的网络里这些端口对内网开放就要重点评估。扫描结果会告诉你哪些机器开了高危端口尤其要留意 445SMB和 3389远程桌面大面积开放的网段这是勒索病毒横向移动最爱的路径。补丁安装的顺序有讲究。公共的互联网出口设备、能访问生产数据的服务器、域控这类关键节点优先打办公区的普通 PC 可以分批打。打补丁之前要在测试环境验证一下特别是数据库和财务系统很多都是老应用依赖旧版本的运行库补丁一打直接起不来。这类问题不在少数Windows 补丁引发打印机共享失灵、Linux 内核补丁导致网卡驱动不工作、数据库补丁改变默认参数影响 SQL 执行计划。所以补丁管理一定要有回滚方案Windows 下做系统还原点Linux 下保留内核镜像翻车了能退回来才是最重要的。4. 内网安全防护措施横向移动的阻断与数据兜底4.1 VLAN 分段与访问控制列表把内网拆成互不相通的小区域防火墙守好了边界内网却是平的这在一台机器被攻破后等于全盘沦陷。攻击者拿下一台办公电脑直接扫描整个 10.x 网段把所有能连通的主机都试一遍。内网安全的关键是分段让办公网、服务器网、生产网互不相通即使某一台机器失陷横向移动的范围也被切割。VLAN 是最常见的分段手段。以一台接入交换机为例按业务划分网段# 核心交换机上创建 VLAN vlan batch 10 20 30 # 端口划分办公网接口划入 VLAN 10服务器网接口划入 VLAN 20 interface GigabitEthernet0/0/1 port link-type access port default vlan 10 interface GigabitEthernet0/0/2 port link-type access port default vlan 20VLAN 只是做广播隔离VLAN 之间默认可以通过三层交换机路由互通所以还需要配置访问控制列表来限制互访。常见做法是只允许办公网访问服务器的特定端口比如 443、3306禁止办公网访问服务器网的管理端口22、3389也禁止不同 VLAN 之间的全部互通。ACL 的配置逻辑是按照「先拒绝再允许」排列的规则越具体优先级越高注意空的 ACL 默认是放行所有流量必须显式加上拒绝规则。VLAN 分段的一个反直觉点是不要只按物理位置划分要按业务角色划分。同样的三层楼里财务部、研发部、行政部用的电脑都在同一台交换机上如果不分 VLAN财务部的打印机和研发部的代码服务器完全互通一旦研发的电脑中招财务数据也处在攻击半径内。分段之后不同部门的互访需要通过防火墙策略审批这个过程顺便把数据流向梳理清楚了。4.2 关键数据备份策略3-2-1 原则与自动化备份脚本备份是安全防范措施里唯一能应对勒索病毒的兜底方案。再强的防御都有被打穿的可能但备份做得好就算全部文件被加密恢复也只是时间问题。3-2-1 原则是最常用的备份标准保留 3 份数据副本存放在 2 种不同的存储介质上其中 1 份放在异地。实际落地时很多团队的备份状态是「备份脚本写了但从来没验证过恢复」。我见过最典型的情况是备份用的磁盘和服务器在同一台机柜里勒索病毒把服务器磁盘和备份盘一并加密。备份的存储一定要和生产环境隔离至少有独立的存储设备条件允许就放到异地机房。自动化备份脚本以 Linux 服务器为例#!/bin/bash # 全量备份数据库并同步到备份服务器 BACKUP_DIR/backup/mysql DATE$(date %F) # 用 mysqldump 导出数据库压缩后保留 30 天 mysqldump -u backup -p$DB_PASS --all-databases | gzip $BACKUP_DIR/mysql_$DATE.sql.gz # 同步到异地的备份服务器--delete 保持两端一致 rsync -av --delete $BACKUP_DIR/ backup10.10.2.50:/data/backup/ # 清理本地超过 30 天的备份文件 find $BACKUP_DIR -name *.sql.gz -mtime 30 -exec rm -f {} \;这个脚本的逻辑是先导出数据库并压缩再通过 rsync 推到异地备份服务器最后清理本地过期文件。三个动作对应 3-2-1 原则里的「2 种介质 1 份异地」。参数说明mysqldump 导出的账号要用专门的备份账号权限只给 SELECT 和 LOCK TABLES不要用 root 备份否则数据库账号泄露等于库全丢rsync 建议加 --delete 参数保证远端和本地完全一致删除的文件也会在远端删除避免过期数据残留。真正的坑在验证恢复。备份脚本跑了半年日志显示全部成功结果数据库故障时发现备份文件是损坏的——因为 mysqldump 导出时数据库正在写入高并发数据导出的文件本身就是不一致的。建议恢复验证的频率不低于每季度一次拿备份文件恢复到一台临时服务器上启动服务跑一遍关键业务流程。我个人的血泪经验是备份这件事没有「已经在做」就算完成只有「验证过能恢复」才算数。另外 cron 计划任务要设好每天执行一次执行日志单独存文件配合监控脚本检查日志里的报错关键字。5. 安全措施落地避坑指南从翻车现场总结的 5 个教训5.1 防火墙规则顺序错乱自己先被关在门外现象按我前面给的 iptables 规则配置完成后管理员从本机 SSH 登录直接被拒绝ping 网关也不通。原因规则的匹配顺序是自上而下的先执行了 DROP 规则后面的 ACCEPT 规则根本不会被执行。很多人把拒绝规则写在前面后面的放行规则永远匹配不到。另外没有放行 conntrack ESTABLISHED导致出站流量响应包被默认策略丢弃表现为能发出请求但收不到回应。解决严格按「回环 → 已建立连接 → 指定服务白名单 → 兜底拒绝」的顺序写规则。改配置时一定要开第二个 SSH 会话测试测试通过后再保存。保存规则用iptables-save /etc/sysconfig/iptables重启后自动加载。如果是云服务器安全组的优先级要结合系统防火墙一起排查两层规则是「与」的关系哪一层拒绝都放不过。5.2 SSH 加固参数设置不当服务器失联现象修改 sshd_config 后执行 reload新会话无法连接提示 Connection closed。原因大多数人遇到的场景是 PermitRootLogin 改成 no 之后发现自己平时一直是用 root 直接登录的普通用户又忘了创建或者普通用户没有 sudo 权限导致改完就失联了。还有一个常见原因是 PubkeyAuthentication 设为 yes 但公钥写入错误authorized_keys 的文件权限不对sshd 会直接忽略。解决SSH 加固前先确认有一个可以登录的普通账号且该账号具备 sudo 权限。公钥文件权限设为 600.ssh 目录权限设为 700这是 sshd 的硬性要求。修改配置后执行sshd -t检查语法然后systemctl reload sshd。保持当前会话不退出新会话测试成功后再断开。如果已经失联找带外管理口或者联系机房重启后进入单用户模式改回来。5.3 补丁升级引发的业务兼容性事故现象Windows Server 每月补丁更新后财务系统的客户端连接不上服务器报错信息指向加密协议版本问题。原因补丁升级会同时更新系统组件和安全性参数其中 TLS 版本的最低要求会被调高。老旧的业务系统只支持 TLS 1.0补丁一打低于 1.2 的协议直接被禁用老旧客户端就失灵了。解决补丁管理必须分环境推进先在测试环境验证业务兼容性再推生产。验证的范围不能只测能打开界面要跑一遍核心业务流程尤其是涉及到数据库连接、第三方接口、加密通信的环节。如果遇到 TLS 版本问题常见方案有两种一是升级业务系统的加密组件二是作为临时方案在注册表里启用旧版 TLS但这治标不治本。从长期角度业务系统上 HTTPS 是迟早的事拖得越久维护成本越高。5.4 备份文件被一并加密容灾方案失去兜底意义现象服务器中了勒索病毒管理员准备从备份恢复数据结果发现备份盘里的文件也全部被加密了甚至异地备份服务器上的文件也遭到污染。原因备份盘的挂载路径和生产服务器在同一台机器上勒索病毒加密时会遍历所有可写的磁盘分区备份盘如果在系统里以盘符或挂载点存在无法幸免。异地备份如果走的是同一个 rsync 账号且密码泄露攻击者拿到服务器权限后主动执行 rsync 把污染数据同步到了异地。解决备份数据必须和生产环境物理隔离。本地备份盘不要长时间挂载用定时任务挂载、备份完成立即卸载。异地备份的 rsync 账号要限制来源 IP只允许备份服务器连接且备份目录开启「只追加不删除」的权限模型——把 --delete 参数去掉改为主目录按日期区分这样即使被入侵也无法覆盖旧的备份文件。备份同时再增加一层快照存储设备支持快照的情况下开启定期快照快照是底层机制创建的攻击者无法通过文件系统修改来破坏。5.5 检测告警太多真正的高危攻击被淹没现象部署了入侵检测系统之后每天收到几百条告警运维开始疲于应付三天后习惯性忽略告警邮件。某天真正的暴力破解攻击持续了两个小时没有人注意到。原因检测设备的默认规则集太宽泛把正常业务的偶发行为也判定为攻击。比如内网某台服务器每天凌晨定时拉取远程接口数据被判定为数据外传员工在办公网扫描端口被判定为扫描攻击。告警量一多安全事件响应就成了形式主义。解决部署安全开检测设备后的第一件事不是调高阈值而是做基线梳理看一周的告警情况。把明显是正常业务的固定行为添加到白名单再根据实际攻击面调整检测规则把无效告警压到每天 10 条以内。同时将告警分级高危告警横向移动、提权、数据库外连走邮件短信中低危只进工单系统。关键是每一条告警都要有明确的处置流程不处理的告警才是真正的安全隐患。6. 安全验证与进阶用攻击者的视角检验你的防护有没有用防护做完了怎么知道是不是纸糊的安全行业有一句话你要用攻击者的思路去测自己的网络才知道防守到底有多结实。验证的方式不需要采购商业渗透测试服务自己用开源工具就能完成 80% 的检查。这里分享一套我常用的验证流程。第一步是漏洞扫描。OpenVAS 是开源社区用得比较广泛的漏扫工具安装后会自动更新漏洞库。扫描范围建议先从边界 IP 和服务开始再扫内网段。扫描结果按严重程度排序重点处理高风险项。注意漏扫本身也会产生攻击流量在业务低峰期执行同时告知同事让它们别惊慌否则值班电话会被打爆。第二步是弱口令检查。用 Hydra 对内网服务做一轮字典测试字典不用太复杂把常见弱密码列表放进去就行。这里不是为了爆破而是验证账号策略是否生效。如果你的网络里还有 admin/admin123 这类组合说明密码策略在执行层面失效了。发现问题不要公开点名私聊联系对应的负责人改密码否则容易引起内部矛盾。第三步是日志审计。服务器的登录日志是最诚实的记录把暴力破解的来源 IP 统计出来封禁一批反复试探的攻击源# 统计 SSH 登录失败次数最多的 IP grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20 # 列出尝试登录但系统不存在的用户名疑似扫描确认 grep Invalid user /var/log/secure | awk {print $(NF-2)} | sort -u第一条命令把失败登录记录的 IP 提取出来按次数排序找出高频率的爆破源。第二条命令列出不存在的用户名这是判断是否被定向扫描的关键特征——针对真实用户的攻击通常不会猜不存在的用户名。这些 IP 核对后如果没有业务关联直接在边界防火墙封掉。第四步是验证备份恢复。选一台不重要的服务器用备份文件做一次完整的恢复演练。核心是记录从开始恢复到服务正常的时间这个指标将来在真正出事的时候决定业务中断多久。恢复过程发现的问题——比如依赖的密码忘了、配置文件不对、备份版本落后太多——现在解决成本低真出事时就是灾难。最后想说一个习惯问题。安全这件事不是做完一遍验证就能一劳永逸我见过太多团队做完整改之后半年不管新加的服务器裸奔、新招的运维不知道密码策略、备份脚本因为磁盘满悄悄失败没人管。我现在养成的习惯是每周看一眼防火墙命中日志和备份执行报告每月检查一次账号列表和端口开放情况把这些安全检查的周期像巡检查一样写进运维日历不用花太多时间但能确保安全措施不是做给人看的样子货。希望这些经验和踩过的坑能帮你在安全加固这条路上少走弯路。本文还有配套的精品资源点击获取