5--1--1.2网络安全架构（base64编码：U0VDNTExIOaMgee7reebkeaOp+S4juWuieWFqOi/kOe7tA==）
-
网络安全架构之零信任
零信任：一种理念，每走一步验证验证
https://beyondcorp.com/
https://www.cloudflare.com/zh-cn/learning/access-management/how-to-implement-zero-trust/ -
ZTNA 零信任网络访问
魏皮恩是登陆后无障碍访问；ZTNA是登陆后障碍访问（比如又认证）
https://www.cloudflare.com/zh-cn/learning/access-management/what-is-ztna/ -
云访问安全代理 Cloud Access Security Broker (CASB)
https://www.microsoft.com/en-us/security/business/security-101/what-is-a-cloud-access-security-broker-casb
企业用户-->云访问安全代理 -->云服务提供商
控制用户对云服务和应用程序的使用情况；对未授权行为采取强制授权策略；DLP功能
部署方式：API集成；正向代理；反向代理 -
安全 Web 网关 (SWG)
企业流量 -->安全互联网网关（类似burp HTTPS劫持）-->互联网
https://www.paloaltonetworks.com/cyberpedia/what-is-secure-web-gateway -
安全访问服务边缘 Secure Access Service Edge (SASE)
只是整合：安全 Web 网关；云访问安全代理；零信任网络访问；FWaaS或下一代防火墙 -
路由器和L3层边界保护
基于路由器的检测：IPFIX/NetFlow（IPFIX又基于NetFlow，简而言之，现在可以使用IPFIX/NetFlow来查看IP地址与TCP/UDP数据包，以前啥都看不见） -
静态防火墙与状态防火墙
状态防火墙：类似ARP的MAC表，比如TCP（请求SYN）-->防火墙比对状态表(SYN/ACK) -->允许流量
静态防火墙：最low的防火墙
为了对外服务：防火墙会开放服务端口 allow Any to any Web Server TCP/80 TCP/443；DNS UDP 53；邮件服务 TCP 25等；默认拒绝所有入站流量
源IP地址过滤：阻止虚假源 IP 地址（RFC1918、bogons、自己的公共 IP 地址空间）；世界区域无业务往来（地理 IP 过滤）
Bogon ：未被互联网号码分配机构（IANA）或其下属地区互联网注册机构（RIR）正式分配的非法、无效或保留的IP地址集合
IP地理：参考其他等代理与IP地址库，比如 https://github.com/Hackl0us/GeoIP2-CN （警告，如果你因为此使用则安全自负）
bogons：https://www.team-cymru.com/bogon-reference-http
免费IP库：https://dev.maxmind.com/geoip/geolite2-free-geolocation-data/ -
默认拒绝出站请求
基于地区（GeoIP）；基于信誉的IP过滤 -
L4 出站过滤
默认阻止所有出站 TCP/UDP 端口；允许业务出站流量
内部人员需要允许访问哪些服务或端口：TCP/80 – 来自代理服务器；TCP/443 – 来自代理服务器；UDP/53 – 来自 DNS 服务器；TCP/25 – 来自邮件服务器；UDP/123 – 来自 NTP 服务器
防火墙与边界保护：https://www.sans.org/white-papers/32878 -
亚马逊虚拟私有云 (VPC)
VPC：类似于逻辑防火墙与访问控制策略，实现逻辑隔离云服务
默认的 VPC 组件配置优先考虑易用性而非安全性
可以自己考虑启用的功能点：VPC 安全组；VPC 网络访问控制列表；VPC 私有链接；VPC 流日志；流量镜像
VPC 安全组类似基于实例主机的防火墙，VPC 网络访问控制列表（NACL）类似基于网络侧的防火墙
https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html -
VPC Detection/Monitoring
类似于开启了NIDS： 靠开启VPC Flow Logs 与 开启流量监控 -
Web 应用程序防火墙（waf）
虚拟补丁与waf或所有设备的规则：防御规则形成假修复（实际为阻止）
waf部署位置：web应用的前面（比如反向代理，主流的CDN可以扩展成waf功能）
比如创宇盾：外包了企业的CDN与waf功能
需理解：所有设备95%的规则都抄袭开源的规则导致大量误报，因为自创高精准的规则需要高成本攻防成本
https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules?tabs=drs22%2Cowasp32 -
AWS WAF 和 AWS Shield
AWS WAF 就是 Web 应用程序防火墙
AWS Shield：L3 L4 L7层的DDoS
https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html -
加密与TLS检测
免费证书：https://letsencrypt.org/stats/#percent-pageloads
TLS 握手：https://www.cloudflare.com/zh-cn/learning/ssl/what-happens-in-a-tls-handshake/ -
TLS 拦截和检查
政府、军队和 500 强企业都使用以下方式解密TLS
TLS 拦截：使用代理（类似burp），把证书存储到客户端受信任的根证书颁发机构 (CA) 中。
TLS 嗅探：需要 Web 服务器的 RSA 私钥（企业内部服务器，给NIDS）或客户端浏览器的预主密钥
Wireshark 提供TLS 嗅探解密（使用会话密钥的关键日志文件（#2026.4Pre.29-Master-Secret）；RSA 私钥进行解密（PEM 格式））
会话密钥的关键日志：设置 SSLKEYLOGFILE 环境变量，Firefox、Chrome 和 curl 等应用程序会生成密钥日志。它们的底层库（NSS、OpenSSL 或 boringssl）将每个会话所需的密钥写入该日志文件
RSA 密钥文件格式：PEM文件为文本格式；PKCS#12 密钥库文件为二进制格式（通常扩展名为.pfx 或.p12）
Firefox 和 Chrome 浏览器可以导出预主密钥（环境变量 SSLKEYLOGFILE与密钥日志给NIDS），其他浏览器不支持 -
完美前向保密（PFS）
TLS 1.3 强制要求使用 PFS，简称前向保密：TLS 1.3 不能使用Web 服务器的 RSA 私钥进行解密；可以使用客户端浏览器的预主密钥（日志文件得到）解密 -
TLS 1.3 不能使用Web 服务器的 RSA 私钥进行解密的变通
TLS代理 1.3降级到1.2（类似使用burp）
内部流量使用1.2，外部流量使用1.3
未来流量解密趋势：基于网络拦截加密流量变得越来越困难，基于主机的解决方案将被更广泛地采用（客户端可以访问未加密的数据） -
下一代防火墙 (NGFW) 或前向代理进行TLS解密
依赖于TLS 拦截：使用代理（类似burp），把证书存储到客户端受信任的根证书颁发机构 (CA) 中
证书绑定或固定：阻止类似burp的代理证书导入，导致应用程序崩溃
https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning -
本地正向代理
客户端或服务器--> 本地正向代理-->互联网（这叫upstream 上游，请求） -
安全 Web 网关 (SWG) 功能
粗暴理解：类似具备内容检测的云托管代理
https://www.paloaltonetworks.com/cyberpedia/what-is-secure-web-gateway -
网络内容过滤器
通常集成到NGFW 设备或正向代理，用于控制网络流量 -
MIME/Content-Type 告警日志
从MIME 类型或内容类型 (Content-Type）角度观察，代理或安全网关会分类这些进行阻止或关联沙箱
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/MIME_types/Common_types
还有很多不在IANA定义里面但是却广泛使用的MIME类型 -
NIDS
禁止将NIPS和下一代防火墙(NGFW) 当成NIDS来继续使用
预防型设备（主动防御）是传统防御；检测型设备（被动监听日志）是威胁狩猎与现代防御
部署位置：企业通常以为NIDS只用于识别外到部的攻击，而且只存在一台NIDS设备，常位于DMZ或服务器区（识别来自于外部的nday与爆破日志）
内部攻击：现代攻击主要趋向于内部，漏洞打不进来就会逼着他们去社工或OSINT（账号密码直接进来）
多区域部署NIDS：DMZ区域，内网区域（识别内部的漏洞利用与爆破），其他关键网络区域 -
通常会将NIDS放在核心交换机上并且只有一个NIDS
核心交换机上的NIDS：如果网段复杂，可见性就不够，需要与更多网段的NIDS配合使用
DMZ区域的NIDS：识别来自于外部的nday与爆破日志
内网服务器的NIDS：常规web服务
敏感区域的NIDS：敏感业务区比如处理信用卡
互联网出口上的NIDS：识别攻击和数据泄漏等
普通用户侧终端的NIDS：识别社工或OSINT
基于网段字段的NIDS: $HOME_NET->$HOME_NET，要识别恶意日志，则这些网段的定义都要定义成非信任网段，而不是忽略流量 -
NIPS
禁止将NIPS（传统防御）视同为NIDS（现代防御），误报等于DOS
有很多企业正在从纯 IPS 向下一代防火墙 (NGFW) 迁移 -
L7层 下一代防火墙（NGFW）
下一代防火墙（NGFW）可以深入L7层，甚至可以指纹识别到具体的web应用
攻击者采用现代C2：443或80 https/http 隧道等，但是NGFW可能识别此流量为恶意的IRC 流量 -
AWS 网络防火墙
利用Suricata来进行NIDS/NIPS（所以说，云安全会集成所有的传统安全设备，不是云厂商去部署就是你自己部署）
南北向（出入口），东西向（子网间）
https://aws.amazon.com/cn/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/ -
AWS 防火墙管理器
类似于NIDS流量探针和SIEM集中管理的区别
AWS 防火墙管理器：AWS WAF、AWS Shield、AWS VPC、AWS Network Firewall 和 Amazon Route 53 Resolvers DNS Firewall -
恶意软件引爆装置（沙箱）
会执行文件，比如识别 JAR 文件合法，还是恶意的，提供分析报告
https://zeltser.com/automated-malware-analysis
别布谷鸟沙箱了，各大厂都有自己的沙箱 -
对抗手段即IOC
恶意软件大量使用的对抗安全手段就是明显的IOC，自欺欺人 -
蜜罐和蜜网
传统蜜罐：放在公共服务器边上，低质量日志（扫描器攻击日志，日志实用性为0）
内部蜜罐：比如所有服务器上放置密码本指向内部蜜罐或敏感文件里插入“版权值”并在NIDS配套检测“版权值”，不仅可识别服务器失陷还可以识别基于翻数据的横移或数据泄漏
高价值欺骗的蜜罐：一旦落地可识别高质量的后渗透行为（蜜罐账号密码，应用，数据库，文件，应用，Robots.txt，“版权值”等）比如数据库名插入“版权值”，被脱库时触发“版权值”，正常业务又不会涉及到“版权值”数据库名
https://www.honeynet.org/projects/ -
交换机
NAC 和 802.1x 进行端点授权
VLAN ACL（VACL）：成本远低于物理隔离（不能代替内网状态防火墙）
https://www.cisco.com/site/us/en/products/networking/software/ios-nx-os/index.html -
DNS 架构
分离命名空间 DNS：外部区域命名，内部区域命名
DNS 服务器角色：权威性；递归或缓存
BIND 最佳实践 https://kb.isc.org/docs/bind-best-practices-authoritative
客户端-->内部出站递归DNS服务器（windows 环境的DNS软件）-->DMZ出站递归DNS服务器（DNS服务器软件 bind 9） -
公共权威DNS
互联网-->DMZ 公共权威DNS服务器（无递归）
运行独立的权威 DNS 服务器和递归 DNS 服务器
速率控制来防止被当成恶意行为的免费基础设施：https://kb.isc.org/docs/aa-01000 -
DNS 防火墙
在DNS解析阶段提供的过滤功能：阻断基于DNS域名的C2隧道；实施基于域名的黑名单（区别于IP黑名单）
DNS 响应策略区域（该功能也常出现于下一代防火墙NGFW）：直接将恶意域名解析到本地地址或无害地址；域名注册机构、托管服务提供商或互联网服务提供商 (ISP) 等难以有效发挥作用：你只能向它们投诉 -
DNS加密
基于 TLS 的 DNS（DoT），经典密码学：Cloudflare 推出免费公共 DNS 解析器 1.1.1.1 支持 DoT 和 DoH，安卓的默认设置
默认使用TCP 853，也支持非标准端口（阻止853，会迫使DoT回退到未加密的DNS请求）
基于 HTTPS 的 DNS（DoH），密码学加隐写术：HTTP/2 和 TCP 443（安全基线配置浏览器禁用DoH）
默认情况下软件会优先使用自己的DNS策略，如果没有则默认再使用系统的DNS配置 -
DNSSEC
DoT和DoH：加密DNS查询和响应
DNSSEC：DNS服务器的身份验证与数据完整性，DNS响应的数字签名，查询和响应均为明文 -
加密与取证上的冲突
DNS加密无法实现真实的加密：在有必要的情况下，什么都可以解密 -
检测基于 HTTPS 的 DNS 使用
本地运行DoH服务器，配置浏览器使用它并将请求记录日志于此（或者以命令的方式实现浏览器客户端在本地记录DoH请求日志）
https://www.sans.org/white-papers/39160 -
加密的DNS流量与VPN非常相似
大多数加密 DNS 最终都会通过 Do53 上游解析（例外：DoH/DoT 流量到权威名称服务器，正常DNS请求没必要写死权威名称服务器）
名称服务器基础知识 https://kb.isc.org/docs/aa-00817 -
定制版DoH DNS架构
客户端DoH -->内部出站递归DNS服务器（windows 环境的DNS软件）这里降级到Do53-->DMZ出站递归DNS服务器（DNS服务器软件 bind 9）也可以在这里降级到Do53 -->互联网
NIDS会丢失数据：丢失所有客户端DoH的请求数据，仅显示DNS服务器 Do53的请求数据
搭建自己的 DoH 服务器 https://www.aaflalo.me/2018/10/tutorial-setup-dns-over-https-server/
https://pi-hole.net/ -
DoH 是 HTTPS请求
目前没有基于签名的方法来检测未经 TLS 解密的、发往未知 DoH 服务器的 DoH 流量
未知 DoH 服务器：恶意软件不会使用明显的 dns.demo.com（TLS 1.2 仍然包含域名，也就是SNI，后面版本马上不可见） 来作为DoH服务器的
基于网络的DoH防御：除非使用SSL/TLS代理（类似burp）
基于curl命令的DoH请求，用于调试
侧信道检测：已知的DoH解析器可以构建IDS规则；信标检测（基线检测，时间线与次数线，同一个DoH服务器或HTTPS域名解析上千次）；同域名内或子域名发出请求；高熵的大型DNS请求；大型TXT响应；长沙解析NULL记录；大量DNS解析失败；向新注册域名发起请求
使用RITA检测信标：https://www.blackhillsinfosec.com/tools/rita/
https://www.securityweek.com/do-you-know-what-your-dns-resolver-doing-right-now/ -
基于实验的总结
基于各个角度的IOC数据关联而设计的实战：时间线，源目的IP，日志类型，文件类型，流量解析，威胁情报关联，编解码，各种协议字段明文IOC，TCP 443上的非TCP协议等
要想研判真实的攻击日志还需要熟悉攻击技术：比如研判SQL注入，找到正常业务返回1的基线日志 ，再找到返回 0 和 1 的两个payload日志。你要知道此刻攻击者完成了漏洞尝试了。接下来就要利用漏洞了，跳过所有的尝试payload日志（即可跳跃式快速研判出漏洞利用，日志1尝试-日志1000尝试-日志5000时发现不在尝试而是利用了。这让你在几个亿的日志中仅仅只需要查看几条日志。）
讽刺的是某些EDR甚至还不如免费的小型EDR Sysmon，可以使用冲鸭安全提供的Sysmon模块，快速定位到发起恶意域名的进程
浙公网安备 33010602011771号