第2章网络安全基础

2. 网络安全基础：网络威胁模型、常见攻击类型（DDoS、SQL注入、ARP欺骗）、安全三要素（CIA）

各位同学，咱们今天聊点实在的。做CPE设备防护，说白了就是跟人斗智斗勇。你想想看，一个设备暴露在公网上，每天得挨多少扫描和试探？我刚开始干这行的时候，总觉得把防火墙一开就万事大吉了。结果呢？有一次客户的CPE被搞成了肉鸡，半夜三点给我打电话……嗯，从那以后，我对网络威胁模型的理解就深刻多了。

威胁模型这东西，听起来高大上，其实就是搞清楚三件事：谁想搞你？他想怎么搞？搞成了他能得到啥？

我个人习惯把威胁来源分成这么几类：

我的经验：做CPE防护时，别只盯着外部攻击。内部威胁往往更致命。我曾经帮客户排查过一次数据泄露，查到最后发现是某台CPE的调试接口没关，被内部员工当成了文件共享服务器在用。

DDoS，分布式拒绝服务攻击。说白了，就是让一堆机器同时给你的CPE发请求，发到你处理不过来，直接宕机。

我记得有一次，客户的CPE突然CPU跑到100%，所有业务都断了。一开始以为是硬件故障，后来抓包一看，好家伙，每秒几万个SYN包涌进来。这就是典型的SYN Flood攻击。

常见的DDoS类型有：

避坑指南：我曾经遇到过一台CPE，配置了很严格的ACL，但DDoS一来还是挂了。后来发现，问题出在连接跟踪表太小。默认只有1024条，攻击一来直接爆表。所以，调大nf_conntrack_max是基本功。

SQL注入，说白了就是攻击者在输入框里塞一段SQL代码，骗过你的数据库。虽然CPE本身不直接跑数据库，但很多CPE的管理后台是Web界面，背后连着数据库。

举个例子，一个登录页面让你输入用户名，你输入：

' OR 1=1 --

如果后台代码直接拼接SQL：

SELECT * FROM users WHERE username = 'admin' AND password = 'xxx'

变成：

SELECT * FROM users WHERE username = '' OR 1=1 -- ' AND password = 'xxx'

你看，1=1永远为真，后面的密码验证被注释掉了。攻击者直接登录成功。

我在审计某款CPE固件时，就发现过这种低级错误。Web管理接口的登录验证直接拼接字符串，连参数化查询都没用。嗯，这种设备基本等于裸奔。

  防护要点：
  永远不要拼接SQL语句，用参数化查询或预编译语句
对用户输入做严格的过滤和转义
最小权限原则：数据库账户只给必要的权限

ARP欺骗，这个在局域网里特别常见。原理很简单：ARP协议本身没有认证机制，谁都可以发ARP应答包。

攻击者怎么做？他伪造一个ARP应答，告诉网关：“192.168.1.100的MAC地址是我”。网关信了，把所有发给192.168.1.100的数据都转发给了攻击者。这就是中间人攻击。

我处理过一个案例：某公司内部网络经常掉线，查了半天发现是有人用ARP欺骗劫持了网关。所有流量都经过他的笔记本，他还在上面跑了抓包软件，公司财务系统的密码全被截获了。

在CPE上怎么防？

我的习惯：在部署CPE时，我会把网关的ARP表做成静态的。虽然维护起来麻烦点，但能从根本上杜绝ARP欺骗。特别是金融、政务这类高安全要求的场景，这一步不能省。

聊了这么多攻击，咱们得回到根本。安全三要素——机密性、完整性、可用性，是所有安全工作的出发点。

要素	英文	含义	CPE场景举例
机密性	Confidentiality	数据只能被授权的人访问	CPE管理密码、VPN密钥不能被窃取
完整性	Integrity	数据在传输和存储中不被篡改	固件升级包不能被中间人替换
可用性	Availability	系统在需要时能正常工作	DDoS攻击下CPE不能宕机

你想想看，这三个要素其实是互相制约的。比如，你把加密做得特别强（机密性），但解密过程太慢，导致业务卡顿（可用性下降）。或者你为了防篡改（完整性），每次传输都做哈希校验，结果CPU负载飙升。

我在实际配置CPE时，会先评估业务场景。如果是视频监控，可用性排第一，加密可以适当放宽。如果是金融交易，机密性和完整性必须拉满，哪怕牺牲一点性能。

  一句话总结：安全没有银弹。CIA三要素就是你的权衡框架。每次做决策时，问自己一句：我这次改动，影响了哪个要素？值不值得？

这一章咱们聊了威胁模型、三种常见攻击，以及CIA三要素。说白了，做CPE防护就是一场信息不对称的博弈。攻击者永远在找你的薄弱点，而你的任务就是把这些薄弱点一个一个堵上。