[{"content":"\rHiii！ 我是 lz0o0 ，以后在本站就自称本鲤了😎！ 听首我喜欢的歌吧~\n","permalink":"https://lz0o0.github.io/zh/posts/%E4%BD%A0%E5%A5%BD%E6%9C%8B%E5%8F%8B/","summary":"\u003c!-- {{\u003c music id=\"557578993\" type=\"song\" server=\"netease\" \u003e}}\r\n --\u003e\r\n\u003cp\u003e\u003cem\u003eHiii！\u003c/em\u003e   \u003cstrong\u003e我是 lz0o0 ，以后在本站就自称本鲤了😎！\u003c/strong\u003e  \u003cstrong\u003e听首我喜欢的歌吧~\u003c/strong\u003e\u003c/p\u003e\n\u003c!-- eva --\u003e\r\n\u003cdiv id=\"player1\" style=\"--background-url: url('https://img.lizhuo.space/eva-15.jpg');\"\u003e\r\n\u003cscript\u003e\r\n    const ap1 = new APlayer({\r\n        container: document.getElementById('player1'),\r\n        audio: [\r\n            {\r\n                name: 'Komm,süsser Tod (M-10 Director’s Edit. Version)',\r\n                artist: 'arianne schreiber',\r\n                url: 'https://img.lizhuo.space/Komm%2C%20s%C3%BCsser%20Tod%20%EF%BC%8F%E7%94%98%E3%81%8D%E6%AD%BB%E3%82%88%E3%80%81%E6%9D%A5%E3%81%9F%E3%82%8C%20(M-10%20Director%E2%80%99s%20Edit.%20Version).flac',\r\n                cover: 'https://img.lizhuo.space/evas.png'\r\n            }\r\n        ]\r\n    });\r\n\u003c/script\u003e\r\n\u003c/div\u003e","title":"热爱，让你成为自己~"},{"content":"\r“相信奇迹的人，本身就和奇迹一样了不起”\r--- 2025-10-26\r“Yang 在近代科学上取得的成绩超群绝伦，他103岁的人生激励了几代世界级人才，但晚年却被公众过分窥视私生活”\r--- 2025-10-20\r“首次参加学术大会，颇感复杂（有不少概念轰炸、人捧人高...），对很多大问题颇显无力，纵登光明顶，却非无忌儿...”\r--- 2025-10-18\r“山高万仞，只登一步”\r--- 2025-10-15\r“...”\r--- 2025-10-04\r“今天首次尝试了隐形眼镜，陌生的巨物感~”\r--- 2025-05-22\r“今天旁听组里师兄答辩的感觉很特别，略显局促但莫名的开心~（ps其实很想送他们一程，导师临门一脚也是遂了我的愿，现场挺勇的，抬着手机到处拍照录像🤣”\r--- 2025-05-17\r“崂山的破晓，我发现一个人的旅行也很舒服😎~”\r--- 2025-05-04\r“带车去青岛，折腾，折腾，就要折腾！”\r--- 2025-05-03\r“雁栖湖-天津之眼，160\u0026#43;km，刷新个人骑行的最大里程，中途摔车给我摔醒了，没有同伴，可能真的坚持不下来🥱”\r--- 2025-05-01\r“照亮我们 黑暗的心 究竟是什么”\r--- 2025-04-25\r“事必求精，至美需极力（太正经了ban掉，玩尽兴，学到家！）！”\r--- 2025-04-23\r“AI-CFW,学习新技术总是让人兴奋！”\r--- 2025-04-17\r“😁 碎碎念页面完成了, So easy！”\r--- 2025-04-16\r","permalink":"https://lz0o0.github.io/zh/posts/life/says/","summary":"🤫 我愿称之为懒人日记界面\u0026hellip;","title":"💭 See what I Says"},{"content":"\rDNS FLaRE: 针对DNS转发器的缓存重载攻击 title：DNS FLaRE: A Flush-Reload Attack on DNS Forwarders coj：Usenix Security 25 Link：https://www.usenix.org/system/files/usenixsecurity25-moav.pdf note：DNS转发器在DNS系统中占据比较主要的位置，但通常是安全薄弱点。转发器的缓存空间一般较小，导致缓存内容会频繁刷新和重载，域内查询命中缓存与否又将影响转发器的响应时间。本文就依据上述机制进行域内用户行为画像，识别潜在缓存重载缺陷的DNS转发器 detail: 详见PPT【待】 揭露二维码登录部署中的不安全 title：Demystifying the (In)Security of QR Code-based Login in Real-world Deployments coj：Usenix Security 25 Link：https://www.usenix.org/system/files/usenixsecurity25-zhang-xin.pdf note：二维码登录在实际部署中通常采用设备交叉认证机制，但却缺乏实际的实施标准，各家的部署十分不一致，攻击者如能获取到受害者的QR Code，则可能在受害者浏览器发起轮询时进行竞态攻击，劫持认证 detail: 参考paper_slides ","permalink":"https://lz0o0.github.io/zh/posts/plogs/plog-25.11.14/","summary":"转发器时间-缓存侧信道攻击；QR Security","title":"Plog 25.11.14"},{"content":"\r","permalink":"https://lz0o0.github.io/zh/posts/affair-logs/%E5%90%84%E5%BC%80%E6%94%BE%E5%B9%B3%E5%8F%B0%E4%B8%80%E8%A7%88/","summary":"\u003c!-- more --\u003e","title":"各开放平台一览"},{"content":"\r","permalink":"https://lz0o0.github.io/zh/posts/bricks/%E5%90%84%E7%A7%8Ddns%E8%B5%84%E6%BA%90%E8%AE%B0%E5%BD%95%E5%BD%A2%E5%BC%8F%E5%8F%8A%E4%BD%BF%E7%94%A8%E6%B1%87%E6%80%BB/","summary":"\u003c!-- more --\u003e","title":"各种DNS资源记录形式及使用汇总"},{"content":"\r","permalink":"https://lz0o0.github.io/zh/posts/nice-techs/dig%E5%B7%A5%E5%85%B7-nslookup%E5%B7%A5%E5%85%B7%E5%8E%9F%E7%90%86%E4%B8%8E%E4%BD%9C%E7%94%A8/","summary":"\u003c!-- more --\u003e","title":"Dig工具 Nslookup工具原理与作用"},{"content":"\r","permalink":"https://lz0o0.github.io/zh/posts/nice-techs/cname%E7%9A%84%E4%BD%9C%E7%94%A8%E5%92%8C%E5%AD%90%E5%9F%9F%E5%90%8D%E5%8A%AB%E6%8C%81/","summary":"\u003c!-- more --\u003e","title":"Cname的作用和子域名劫持"},{"content":"\r什么是图床？ 图床是一种在线存储和托管图片的服务。用户可以将图片上传到图床服务器（存储仓库），并生成一个唯一的、可公开访问的URL，用于在网站、论坛、博客和社交媒体等地方分享和展示这些图片。为方便操作，用户通常会安装一个方便上传和获取外链的用户侧程序，配置存储服务器之后即可对服务器进行访问。图床的主要功能包括：\n图片存储：提供可靠的存储空间，用于存放用户上传的图片文件 URL生成：为每张上传的图片生成一个唯一的、可直接访问的URL 嵌入代码：方便用户将图片嵌入到网页、博客等支持HTML代码的地方 为什么需要图床？ 图床通常被广泛应用于需要分享图片的场景，如社交媒体、博客和论坛、网站网店等，一般来说，会去接触图床的人通常都是一些热爱在网上分享or记录（生活所迫🐶）的人。由于一般操作的是外链的URL，使用图床的人通常采用markdown方式编辑文字（or兼容md）\n如何获取图床？ 图床最核心的部分是存储仓库，即所谓的“床”，用户程序仅仅是优化体验。构建仓库可以使用自己私有的服务器（需要支持访问和链接，支持基本的上行和下发URL），另外部分存储空间需要起码支持公共可读，这种方式配置起来比较复杂，需要管理维护存储服务本身，但对应能自己掌握所有原始数据；另外还可以使用各家提供的存储服务，进行简单配置后，用户只需要进行图片上传和外链填充，专注内容创作，与空间容量和服务质量关联，这种租用服务形式又有收费和免费之分。\n现实中用的比较多的是第二种：以cloudflare提供的R2对象存储服务为例，用户可以通过自建各种存储桶（存储桶是对象存储系统中的一个核心概念，用于存放和管理数据对象的逻辑容器。）适配目标场景和需要；然后在端侧配置存储桶即可，比如，利用picgo。\n配置Cloudflare R2 \u0026amp; PicGo 流程比较简单，这里放一个写的相对细致的参考，本文不再重复写了\nPicGo R2图床配置 Refer PicGo R2图床配置教程 个人图床方案：Cloudflare R2 \u0026amp; Picgo | 水晶工坊 github \u0026amp; picgo \u0026amp; typora ","permalink":"https://lz0o0.github.io/zh/posts/nice-techs/%E5%9B%BE%E5%BA%8A/","summary":"图床是对图像在线存储和托管服务的一种形象描述，一般由核心的存储仓库和用户侧程序组成，用户侧程序方便用户简单直接地上传图片并获取访问链接，以便于图床所有者在社媒平台和更广泛地网络访问中分享和展示这些图片","title":"图床"},{"content":"\r基于未知协议生成进行审查逃逸 title：Censorship Evasion with Unidentified Protocol Generation coj：Usenix Security 25 Link：https://www.usenix.org/system/files/usenixsecurity25-wails.pdf note：审查需要严格考虑误杀，广大未知协议流量本身区分困难，UPGen协议空间又覆盖众多未知长尾，导致识别困难且封锁代价高 detail: 详见PPT ","permalink":"https://lz0o0.github.io/zh/posts/plogs/plog-25.10.31/","summary":"基于未知协议生成进行审查逃逸","title":"Plog 25.10.31"},{"content":"\rA. ReDAN：一种面向NAT网络的远程拒绝服务攻击实证研究 title：ReDAN: An Empirical Study on Remote DoS Attacks against NAT Networks coj：NDSS 25 Link：https://www.ndss-symposium.org/wp-content/uploads/2025-972-paper.pdf note：NAT DDOS = NAT识别 + DDoS漏洞 detail: refer B. 利用预训练的语言模型释放基于语义的日志解析的真正潜力 title：Unleashing the True Potential of Semantic-based Log Parsing with Pre-trained Language Models coj：IEEE ICSE 25 Link：https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=\u0026amp;arnumber=11029829 note：日志解析处理、预训练 detail: refer C. Sni5Gect：向5G NR注入aNRchy的实用方法 title：SNI5GECT: A Practical Approach to Inject aNRchy into 5G NR coj：Usenix Security 25 Link：https://www.usenix.org/system/files/usenixsecurity25-luo-shijie.pdf note：5G预认证前的未加密状态可以被识别，攻击者可以在下行通信诸如攻击载荷致使DOS和服务降级 detail: refer D. clue中文语言理解测评基准\u0026amp;排行榜 title：clue中文语言理解测评基准 coj：NULL Link：https://www.superclueai.com/homepage note：大模型排行榜 detail: refer ","permalink":"https://lz0o0.github.io/zh/posts/plogs/plog-25.09.26/","summary":"NAT识别与NAT-DDos；日志解析处理；5G注入攻击；大模型评测","title":"Plog 25.09.26"},{"content":"\r本页仅作索引，简要记录每个偶然产生的小想法\nEmoji status: ⬜ (todo) -\u0026gt; ⏳ (doing) -\u0026gt; ✅ (done)\n时间 问题 Idea 状态 详情 25.10.18 如何从用户视角测量一个Open DNS的使用情况？ 服务热度、重要性评估 ⬜ waiting 25.10.23 如何测量绕过审查的偷渡路由？ 基于野生路由的审查规避 ⬜ waiting 25.10.26 如何确定加密DNS过滤的实施主体是谁？过滤的实际效果如何？ 网络溯源、生态治理 ⬜ waiting ","permalink":"https://lz0o0.github.io/zh/posts/academic/logidea/","summary":"the title is clear enough","title":"LogIdea"},{"content":"\r\u0026emsp;\u0026emsp;久有凌云志①，重上井冈山。\n\u0026emsp;\u0026emsp;千里来寻故地②，旧貌变新颜。\n\u0026emsp;\u0026emsp;到处莺歌燕舞③，更有潺潺流水④，高路入云端⑤。\n\u0026emsp;\u0026emsp;过了黄洋界，险处不须看⑥。\n\u0026emsp;\u0026emsp;风雷动，旌旗奋⑦，是人寰⑧。\n\u0026emsp;\u0026emsp;三十八年过去⑨，弹指一挥间⑩。\n\u0026emsp;\u0026emsp;可上九天揽月，可下五洋捉鳖，谈笑凯歌还。\n\u0026emsp;\u0026emsp;世上无难事，只要肯登攀。\r\u0026emsp;\u0026emsp;这首词最早发表在《诗刊》一九七六年一月号。\r注释：\r① 凌云志，《后汉书》卷二八《冯衍传》载，冯衍自谓“常有陵(同‘凌’)云之志”。本指大志、壮志，这里用为双关语，也指登高把云彩踩在脚下(即重上井冈山)的志愿。\r② 寻，寻访。故地，昔日战斗、生活之地。\r③ 莺歌燕舞，既写井冈山春天的欢快之景，又象征井冈山地区革命和建设事业的欣欣向荣。\r④ 潺潺，流水声。\r⑤ 高路，指1960年冬修建的从江西宁冈砻市至井冈山茨坪的盘山公路。\r⑥ 不须看，不必看。这里一方面赞叹黄洋界地势险要，另一方面喻言经历过井冈山时期的艰苦斗争后，任何困难险阻都不在话下。\r⑦ 旌旗，此指革命的战旗；奋，振展、飞扬。\r⑧ 人寰，人间。以上三句说明革命的武装斗争遍及世界，是人类社会发展的必由之路。\r⑨ 1927年毛泽东初上井冈山；1965年重上井冈山，两者相隔三十八年。\r⑩ 弹指，佛家语，指瞬间之意，极言时间的短暂。\r赏析：\r\u0026emsp;\u0026emsp;全词上片纪事、写景，下片抒怀明志。文字简洁明了，延续了诗人一贯的豪放与自信。首句“久有凌云志，重上井冈山”气势开阔，既有对抱负的宣示，也有对故地的深情回望。\r\u0026emsp;\u0026emsp;词中通过对井冈山景象的描写（莺歌燕舞、潺潺流水、高路入云端）表现时代变迁与新貌，同时以“过了黄洋界，险处不须看”来强调革命年代的峥嵘已成过去，今人可从容面对险阻。\r\u0026emsp;\u0026emsp;下片“风雷动，旌旗奋，是人寰；三十八年过去，弹指一挥间”以宏大历史感将个人经历与民族命运连接起来。结句“世上无难事，只要肯登攀”铿锵有力，既呼应首句，又把个人情怀上升为普遍的奋斗宣言。\r\u0026emsp;\u0026emsp;如果把此词置于1965年的历史背景，可见诗人在重访旧地时不仅是缅怀和感慨，更流露出对未来变革的期待与决心；词句中的豪迈与自信，也为后来历史进程提供了情感上的注脚。\r\u0026emsp;\u0026emsp;注：以上为原文、注释与赏析的综合整理，若需逐句译注或加入音频/朗诵可另行补充。\r","permalink":"https://lz0o0.github.io/zh/posts/poetry/%E6%B0%B4%E8%B0%83%E6%AD%8C%E5%A4%B4%E9%87%8D%E4%B8%8A%E4%BA%95%E5%86%88%E5%B1%B1/","summary":"关于毛泽东词作《水调歌头·重上井冈山》的背景、主题与艺术特色的介绍。","title":"水调歌头·重上井冈山"},{"content":"\rA. CertTA：鲁棒可认证的流量分析框架 title：CertTA: Certified Robustness Made Practical for Learning-Based Traffic Analysis coj：USENIX Securitry 25 Link：https://www.usenix.org/conference/usenixsecurity25/presentation/yan-jinzhu note：鲁棒区域和数学推导的结合不错，可供借鉴；鲁棒区域的可解释性通过结果的稳定程度来表达，这点比较有意思 背景意义 随着AI在网络流量分析中的广泛应用，基于机器学习的模型在入侵检测、应用识别等任务中表现出高准确率。然而，这些模型在面对对抗攻击时表现出严重的脆弱性，攻击者可通过数据包延迟、填充、插入等方式构造对抗流量，误导模型判断，导致AI驱动的流量分析系统在实际应用中缺乏安全性保障。因此，为AI驱动的流量分析系统提供可证明的鲁棒性保障，成为当前亟需解决的关键问题。\n现有研究主要采用可认证鲁棒性方法（如随机平滑）为AI模型提供理论安全保证。在流量分析领域，现有方法主要分为两类：\n将流量数据视为连续向量，认证其上的加性扰动； 将流量视为离散序列，认证数据包的插入、删除等离散扰动。 离散扰动比较好理解即增删改排，而所谓加性扰动其实就是数学游戏，对连续向量施加的改动无非就是改数值、调时隙，在数学上将这种扰动量化为加性噪声ΔL，严格来说论文中的“加性扰动”是在工程里是对离散包做的，但可以在理论里被当成连续向量上的 ℓ∞ 【ℓ∞ 范数 ‖Δx‖∞ = maxᵢ |Δxᵢ|：逐维单独算，只要最狠的那一下不超标，就认你安全**】样式扰动**来处理。然而，现实中的对抗攻击往往是多模态的，同时包含加性和离散扰动，并且且不同模型结构和输入表征差异较大，现有方法很难提供通用且有效的鲁棒性保证。（这里比较直观能想到可以结合这两种思路来进行平滑兼容）\n方法结构 本文提出CertTA框架，创新性地引入多模态随机平滑方法，同时应对加性和离散对抗扰动，核心思想包括：\n多模态随机平滑：从原始流量中随机选取部分数据包，并在其长度和时间间隔上添加指数型噪声，生成多个平滑样本； 鲁棒区域推导：通过理论分析，推导出分类结果在多模态扰动下保持不变的鲁棒区域，提供可认证的分类准确率下界； 联合防御机制：将CertTA与异常检测系统结合，构建能同时应对强攻击和隐蔽攻击的联合防御系统，提升整体防护能力。 CertTA的核心有两个，一个是多模态的随机平滑，另一个是所谓的鲁棒区域。\n多模态随机平滑基本上融合了两种传统鲁棒认证思路的特点，通过离散采样和附加指数型扰动，来尽可能增大对样本随机空间覆盖程度，支撑后续鲁棒空间的推导。\n对输入样本多轮平滑后得到的输出样本即可用于分类决策，论文实际的实现也是如此，后续基于基分类器进行多数投票（plurality vote）：对一批加了随机扰动后的平滑样本跑模型，把得票最多的那个类别当作最终预测。\n鲁棒区域如何理解？下面是原文中的数学推导，看起来很复杂，我们简单草履虫式的思考一下：一个不规则点块经过随机扩散（like水溶）后得到一个大很多的扩散区域，我们需要画圈圈出尽可能多的原本的点块。在实际操作时，我们会发现鲁棒的区域很难界定，不规则而且不同部分的扩散也各不相同，那么有什么好办法呢？愚蠢的草履虫决定反复画圈，每一圈尽可能基于当前时刻的扩散情况圈出更多，在经过很多次之后，好的，你得到了这些圈中重叠的这个部分，好了这时候你发现只要圈尽可能包含这个部分，那么你总是能够过及格线，非常之鲁棒。\n回到论文，所谓的鲁棒区域即在何种程度上不影响多数投票的结果，对各种扰动构成的波函数进行采样，只要确定最终分类稳定即可，数学推导验证了这个区域存在，并且存在下界，具体鲁棒区域的大小，取决于你的“及格线”容度。\n结果小结 研究还提出了一个联合防御系统，将异常检测系统与CertTA框架结合，该系统能够同时应对不同强度的对抗攻击。其中，异常检测系统首先从所有流量中过滤出异常告警流量，再将其余未告警流量（对应那些强扰动干扰的部分）输入CertTA框架进行可认证鲁棒的流量分类。\n其他 论文一共跑了 6 种异构基分类器，覆盖传统机器学习、深度 CNN、RNN、Transformer 等不同结构，以及三种常见流量表征（统计特征、原始序列、原始字节）。列表如下：\nFlowLens（基于决策树的传统 ML，用手工统计特征） FS-Net（1-D CNN + 注意力，原始流量序列输入） DeepPacket（CNN，原始字节输入） AppScanner（堆叠 CNN + 全连接，原始字节） LSTM-based classifier（两层 LSTM，原始序列） Transformer-based classifier（自注意力序列模型，原始序列） 所有模型都在公开数据集（CICIDS2017、USTC-TFC2016 等）上重新训练，然后套进 CertTA 的随机平滑管道，用来验证“同一份证书”对不同架构、不同输入表征都能给出可证明鲁棒下界。\nB. 深度学习与传统机器学习在加密恶意流量分类中的对比研究 title：When a RF beats a CNN and GRU, together—A comparison of deep learning and classical machine learning approaches for encrypted malware traffic classification coj：Computers \u0026amp; Security, 2022 Link：https://www.sciencedirect.com/science/article/pii/S0167404822003923 note：回想起来，平时交流讨论中，大家总能见到各种比较脸熟的模型，诸如ML\\DL\\Graph-Based之类，能够感觉大部分研究中RF的效果都不错，在此之前基本是偏感性的理论认识，本篇研究相当于给了比较实际的实验结果作为支撑 背景意义 随着深度学习的大热，不论是学术界还是工业界，大家对深度学习模型的信任与期望越来越高，大家都在卷深度学习，这也致使深度学习成了加密流量分析中的默认解。本文的目的是为了探究，复杂的深度学习模型是否优于传统机器学习模型，或者说，传统的机器学习模型是否已经够用了呢。\n本文实验从三个数据集、多种分类任务中，较全面的对比传统机器学习与深度学习的分类表现。实验结果表明，在某些任务中，传统机器学习可以提供更简易、高效的解决方案，但这并不代表传统机器学习可以完全取代深度学习在加密流量分析中的作用。\n数据集 本文基于现有的5个公开数据集，创建了3个用于实验的数据集。其中现有数据集分别为：\nStratosphereIPS：由真实环境中的正常流量与恶意网络流量组成。 ISCX2016：由不同应用和流量类型的正常流量样本，以及VPN流量组成。 BOA：由不同操作系统、浏览器和应用程序产生的正常流量组成。 MTA：由恶意流量分析网站共享出的恶意流量样本组成。 USTC：由中科大产生的多种应用程序的正常流量和多种恶意软件的流量组成。 作者在合并数据集后发现，用不同数据集的相同家族恶意流量训练出来的模型并不通用，且分类准确率为0，结果如上表所示。所以，在创建数据集时，本文将不同数据集的相同家族恶意流量视为不同类别。创建的3个数据集如下：\nMTAB：由MTA中的恶意流量与ISCX2016、StratoshpereIPS和BOA中的正常流量组成。 USTCB：由USTC中的恶意流量与ISCX2016、StratoshpereIPS和BOA中的正常流量组成。 MUB：由MTA、ISCX2016中的恶意流量与ISCX2016、StratoshpereIPS、BOA和USTC中的正常流量组成。 在处理数据时，作者首先过滤payload少于784字节的包，因为它们能提供的有用信息较少；其次，移除数据集中的无关协议，如SNMP、局域网广播协议等；最后，为了平衡加密恶意流量与正常流量的比例，对正常流量进行随机采样。各个数据集的数据类型占比如下图所示。\n方法\u0026amp;结果 研究选取了二分类、多分类两种典型场景来对比众多学习模型的实际效果；得出各自最优模型（ML-RF; DL-MalDIST）后，又针对零日恶意流量和恶意软件家族递增两种特定检测情景来对比和评估模型的实际表现、鲁棒性等指标。下表是整体结果（各模块实验见后）：\n总体来说，RF的表现并不比深度学习差，\n传统机器学习方面，本文选取了基于距离的KNN、基于树的DT和基于集成的RF；深度学习则选取了DeepMAL、MalDIST、M1CNN3、M2CNN和MalDIST。\n二分类场景下，以Accuracy为评估标准，其中KNN的表现最差，RF的表现最优，且优于深度学习模型中表现最好的MalDIST。\n多分类场景只针对恶意流量，但由于不同类型的恶意流量数量规模并不一致，所以实验增添了额外3种评估标准，对比模型在三种定制数据集上的表现。该结果与二分类结果相似，KNN最差，RF最优且优于MalDIST。\n探究RF和MalDIST对零日恶意流量检测的表现时，实验每次将一个恶意家族作为测试集，其余家族和正常流量作为训练集进行二分类测试，评估指标为准确率。结果表明，在MUB数据集上，RF在所有家族检测上都优于MalDIST；但在USTCB数据集上，RF在Geodo和Htbot等家族上表现更好，而MalDIST在Nsis和Zeus等家族上表现更佳，且在极端案例中差异尤为明显，如RF对Cridex识别率为90%，而MalDIST仅为0.6%；相反，RF无法识别Shifu和Zeus，而MalDIST能有效识别；在MUB数据集中也出现类似现象。\n为了评估恶意软件家族数量逐步增加对模型性能的影响，本实验为每个数据集依次加入新的家族，并记录每一步的模型准确率。结果表明，随着家族数量的增加，在进行恶意和正常流量二分类时，两种模型都表现出较高的性能；在进行具体家族分类任务时，模型性能整体呈下降趋势，MTAB数据集上下降最显著。整体上，RF与MalDIST的表现大致相当，未出现明显优劣差距。\nC. 加密恶意流量特征挖掘研究 title：Feature Mining for Encrypted Malicious Traffic Detection with Deep Learning and Other Machine Learning Algorithms coj：Computers \u0026amp; Security, 2023 Link：https://www.sciencedirect.com/science/article/pii/S0167404823000536 note：这篇研究比较可取的是对加密流量特征的划分方法，有类似需要可以借鉴 背景意义 特征工程是流量检测和分类工作中一个极为重要的部分，早期的的分析基本都是依赖强规则，解释性较强，随着防护技术和对抗手段的进步，能够获取到的有信息量和代表性的流量特征越来越少，一些机器学习的办法被运用到流量的特征学习中，但效果提升并不显著，并且训练成本、数据支撑、可解释性等都有不少限制，基于优势特征（具备强判别性）的分类仍然是主流。该条路线对应的问题主要是来个，一来特定协议的特征越来越难以获取，优势特征愈发稀疏（加密、混淆等干扰），二来协议无关特征无法充分表征特定对象。\n针对上述问题，本篇研究提出了一种面向加密恶意流量分析的新型特征设计思路；另外提出了一个融合ML和DL的两层检测框架。除此之外，构建了一个整合数据集，其结果评估要优于ResNet、RF等经典方法。\n方法结构 研究将传统加密流量特征划为协议相关特征和协议无关数值特征两大类，并基于两类特征的特点提出了一种新型的加密流量特征创建方法——特定加密流量特征（Enc Feature），该方法主要在加密流量的会话层、数据层两个粒度上进行特征提取。\n协议相关特征（Protocol-specific Features）：针对特定加密协议提取的特征，依赖于协议本身的结构新型，如版本类型、证书有效期等。——此类特征粒度较细，提取过程耗时；对特定协议的分辨力较强，但扩展性较差。\n协议无关特征（Protocol-agnostic Numerical Features）：不依赖具体加密协议的通用特征，如负载大小、生存时间、流持续时间等。进一步可细分为基于数据包的特征和基于会话的特征两种。前者针对单包提取，包括包载荷长度、到达间隔等；后者针对会话提取，代表特征如会话持续时间、总字节数等。——此类特征相对普及，但分辨力不高。\n此前的研究往往不区分加密与非加密流量，使用相同的特征集进行分析，导致特征判别力下降。Enc Feature不仅具有协议无关性，同时兼顾会话层和数据包层信息，是目前唯一在这两个维度上同时针对加密流量设计的特征体系。下表为Enc Feature的概览：\nEnc Feature的核心在于仅从加密会话的加密数据包中提取特征，完全排除非加密数据包（如TLS中握手包），从而提取纯粹反映加密流量行为的特征。流程分两步：\n过滤混合数据集中所有非加密会话 从加密会话中剔除所有非加密数据包 最终提取78个Enc特征，包括会话级（4-23）、包级（1-3，24），以及通过统计运算生成的特征（25-78）。除此之外，研究还将Enc Feature与传统协议无关特征结合，例如，传统流持续时间与仅基于加密包的流持续时间比值，IP总包长与加密IP包长度比值，从而拓展了加密流量的特征维度（No.79–143）。具体特征如表I所示，与现有方法区别如表II和III所示。\n研究提出了一个两层加密恶意流量检测框架，如下图示：\n框架中根据特征类型将其分别输入不同模型：\n时间相关特征输入RNN模型（如GRU、LSTM） 基于负载的侧信道特征被编码为二维图像输入CNN模型（如ResNet） 传统协议无关特征与Enc特征之间的比值型特征输入传统机器学习模型（如Random Forest、XGBoost）。 第一层由上述各模型中性能最优者构成，其输出的概率结果作为输入传递给第二层检测器。第二层检测器由Random Forest或平均集成方法构建，依据不同评估指标的重要性决定最终选择。\n检测框架的工作流程：首先，通过Wireshark过滤非加密流量，再从PCAP中提取300余种特征，包括时间相关特征、payload侧信道特征、自定义加密特征与比例特征。随后，针对不同特征类型选择最合适的模型进行训练：时间相关特征以15×85的格式输入LSTM模型，多层LSTM表现最佳；payload侧信道特征以15×38的二维数组形式输入ResNet模型，ResNet34表现最佳；加密与传统协议无关特征的比值特征输入传统模型训练，XGBoost略优于Random Forest。这三种模型的预测结果将输入第二层检测器，通过Random Forest或平均集成法实现最终判别。\n数据集 为提升流量数据的多样性，本文从6个公共数据集中整合构建了新的加密流量数据集。该数据集包括Stratosphere Lab发布的CTU-Malware-Capture、Benign-Capture与Mixture-Capture，以及加拿大网络安全研究所（CIC）发布的CICIDS2017、CICIDS2012和CIRA-CIC-DoHBRW-2020。其中，CTU数据集提供26类恶意流量，其他五个数据集则提供正常流量，以实现数据类别平衡和流量多样性最大化。\n结果小结 实验结果表明，若第二层采用Random Forest，TPR可达99.68%；若采用平均集成方法，则在准确率（99.73%）、F1值（99.72%）、精确率（99.89%）与最低误报率（0.11%）方面表现略优。\n简言之，本文提出了一种加密恶意流量检测框架，涵盖特征提取、模型训练及多层检测机制。但这类基于数据集的研究，一个比较常见的问题就是实际网络的表现如何？面对复杂流量的鲁棒性怎样？受数据集质量的影响大小等。这篇研究比较可取的是对加密流量特征的划分方法，有类似需要可以借鉴，至于所提的Enc Feature，尽管经过各种增强，但实际起核心作用的应该还是1-24号特征，研究也并未进行消融评估。\nRefer 安全内参：CertTA：流量分析的可证明安全 安全内参：深度学习与传统机器学习在加密恶意流量分类中的对比研究 安全内参：加密恶意流量特征挖掘研究 ","permalink":"https://lz0o0.github.io/zh/posts/plogs/plog-25.09.12/","summary":"鲁棒可认证的流量分析；ML与DL的实效比对；恶意加密流量特征挖掘","title":"Plog 25.09.12"},{"content":"\rA. CDNs和网络干扰的联合分析 Title：Satellite: Joint Analysis of CDNs and Network-Level Interference CoJ：USENIX ATC 16【25年已取消】 Link: https://www.usenix.org/conference/atc16/technical-sessions/presentation/scott note：时间稍微久远，但这篇工作比较经典，从问题切入到实验设计再到结果呈现，不少地方可供参考、借鉴 背景意义 互联网在地理、技术、政治、伦理四个维度上都呈现“碎片化+黑箱化”，而 CDN 与干扰行为又故意隐藏在正常流量背后，所以任何单一视角、单一工具、单一时刻的测量都类似“盲人摸象”。这导致各方角色难以全面了解全球网站部署方式及其可达性，尤其是CDN分布和网络干扰（如DNS劫持、封锁）情况。\n关键词：网站分布情况、可达性【网站放在哪？谁能打开谁打不开？】\n主要挑战\n缺乏全球分布式、可持续、可复现的测量平台 CDN于网络干扰行为容易混淆，缺乏适当方法加以区分 传统测量依赖分布式节点，成本高、风险大 如何设计单节点测量系统，可持续、低成本地监测全球CDN部署和网络干扰？\n方法设计 核心思想：利用DNS解析网络，通过探测全球开放DNS解析器，收集网站域名的解析数据，分析CDN部署与网络干扰\n测量方式：\n开发解析器扫描：使用 zmap 扫描 IPv4 地址空间，发现约 700 万个开放递归DNS服务器（1200万中700万个对测量服务器解析正常） 每周拨测，目标为Alexa Top 10000域名 收集信息：完整DNS响应、IP元数据（PTR、WHOIS）、地理位置信息 CDN集群与网络干扰行为区分方法：基于“域名\u0026mdash;AS\u0026mdash;\u0026gt;IP”三元关系，构建二部图，基于二部图计算DomainSimilarity和IPTrust两个指标，度量域名相似程度和解析信度，定点迭代直到结果稳定支持划分。二部图示意和迭代算法如下图所示：\n四个粗度干扰型：Focus on DNS\n解析太少/畸形 → 像“答案被吃掉”：突发解析失败或格式异常 单点突变 → 像“特定地区被调包”：原本全球都解析到同一 IP，却突然出现不同 IP 分散爆炸 → 像“被拉进黑洞群”：域名本来集中在一个 AS，却突然出现在多个 AS 偏离 CDN → 像“官方 CDN 被旁路”：域名本属于某 CDN 集群，却解析到集群外 IP 拓扑结构 下列为研究实验结构拓扑和工作流草图\n实际效果 论文用可复现的“撞库+内容验证+事件对标”三重验证检验实际效果，与官方 CDN 段撞库 100% 命中、favicon 内容指纹 82% 真服务器可达、政策窗口 1 周内实时捕捉数据与事件对应\nCDN 识别：与官方 IP 列表“撞库”(Fastly:https://api.fastly.com/public-ip-list（12 段）;Cloudflare:公开 anycast 列表) 干扰检测：用 favicon 内容指纹做“真·可达”验证(拉取favicon对比哈希计算准确率) 时效性：对照伊朗、土耳其真实政策事件 主要发现 CDN 渗透率+DNS 干扰面+本地解析率\n全球主流网站已高度 CDN 化：Alexa Top 10 k 里 20 % 域名落在 10 大共享平台 审查/封锁已成普遍现象：117 国 出现 4,819 起 ISP 级 DNS 劫持 干扰手法地域化：①中国 → 多样化假 IP（随机污染）②伊朗/利比亚 → 单一封锁页面（集中重定向）③土耳其 → 多 AS 扩散（黑洞化） 数据本地化策略差异巨大：中国 18 % 域名解析到境内 IP，墨西哥仅 5 % 相关工具 1 2 3 4 5 6 7 8 9 zmap —— 高速 IPv4 开放 DNS 扫描 —— 论文扩展 udp-multi 模式，50k pps 单线程 zgrab2 —— 对可疑 IP 做 TCP/HTTP/HTTPS 握手 —— 用于 favicon 内容验证 libpcap —— 抓取并保存完整 UDP 应答包 —— 保留原始 PCAP，便于后续字段深度挖掘 NetworkX —— 内存里构建域名-IP 二部图并计算相似度迭代 —— 处理稀疏矩阵，5-6 轮即可收敛 MaxMind GeoLite2 —— IP 到国家/城市地理定位 —— 默认 Country 级，Anycast 时结合列表修正 pygeoip —— Python 接口调用 MaxMind 库 —— 与 NetworkX 脚本直接集成 whois/pywhois —— 查询 IP 归属组织与 ASN —— 用于 WHOIS 聚类 dnspython —— PTR 反向解析与 EDNS 子网测试 —— 收集反向 PTR 记录，验证 CDN 名称 pandas+TSV —— 读取 TSV 边数据并生成分析报表 —— 周级流水线标配 启发项 关于网络干扰与审查： 本文中用了网络干扰“network interference”来描述操纵和审查（我发现不少文章都是类似用法），诚然，在学术语境中，Interference更加中性、学术化，立场站位也相对合适，但理解起来通常认为就是censorship+traffic manipulation的统称。\n研究的核心动机之一是发现并量化DNS层面的封锁、劫持与重定向等“干扰”行为，这实际就是网络层面的审查行为。不论有意与否，从其动机描述和实证引例来看，DNS劫持、DNS污染、封锁页、透明度等等阐述都言及实际的审查，如何发现和量化DNS层面的网络审查可以算作研究的核心目标之一。\n关于审查界定：解析解显著偏离全球基准\u0026amp;无法用CDN解释\u0026lt;==\u0026gt;审查 本研究没有提供“审查”的定义描述，但用技术性、可验证的操作进行了界定：凡是DNS解析结果显著偏离该域名在全球绝大多数网络中的“正常“分布，并且无法用CDN负载均衡或网络故障来解释，即可视为”网络干扰（network-level interference）“，在上下文中等同于”审查“行为。\n关于实验设计： 研究的第2章描述中先整体介绍设计目标阐述需求，然后2.1介绍对应每一步需求的具体做法，后面在分节详述，实验设计十分顺畅和清晰，值得学习。对应具体的场景，预期难点主要落在需求分析（明确要什么）和确定可行的具体做法上（怎么要）\nB. 关于GFW基于SNI的QUIC审查的披露与规避 title：Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China coj：USENIX Securitry 25 Link：https://www.usenix.org/conference/usenixsecurity25/presentation/zohaib note：USenix-25 的 BP，文章质量很不错，建议读读原文，这篇线下讲过，这里简单强调下背景核心，后面直接搬运部分PPT了 背景意义 由于立场的不可解矛盾，网络审查和审查规避之间的对抗演进交织进行。知名的审查系统或者封闭网络成为许多反审查研究的首选对象（似乎已经成为不成文的共识一般），本文的对象即中国的GFW——长城防火墙。随着加密防护的意识普及和部署访问的技术迭代更新，加密流量逐渐成为网络主流，审查的有效作用域和效果均被极大限制，诸如DOE、QUIC等协议的出现都提高了审查的难度，本文研究便是探讨在 QUIC 传输场景下,GFW 如何基于 QUIC-SNI 进行审查和审查时存在的可分特征。\n尽管QUIC宣称全过程加密，但在QUIC连接建立的早期【QUIC 握手】却并不安全，这一阶段客户端和服务还未进行交互得到仅双方可知的密钥生成材料，初始加密的密钥由公开算法（RFC 9001版本固定salt+报文DCID）即时推导，这些关键信息是公开or可获取的，因而这个过程的密钥和字段内容能够被计算解密，解包后包含的QUIC-SNI即可进一步用于指导审查。GFW 针对QUIC-SNI的审查基于此展开，而对应本文的反向测绘同样基于该逻辑进行反推，网络中的攻防博弈就是这样有趣，尽管双方看似背道而驰，但根本的理论基点大都一致。\n简言之，本研究关注和解决两个问题：GFW的QUIC-SNI如何实行？QUIC-SNI 有怎样的封锁特点？\n​\t关键词：审查实施机制、审查机制特点【如何封锁、封锁什么、封锁的可观特征】\nPPT：开始无脑贴图\u0026hellip;\n","permalink":"https://lz0o0.github.io/zh/posts/plogs/plog-25.08.29/","summary":"CDN与网络干扰分布区分；基于QUIC SNI的反审查探测","title":"plog-25.08.29"},{"content":"\r2025 11.17\u0026ndash;11.xx 【SO】 11.03\u0026ndash;11.14 【DW】 DNS FLaRE: A Flush-Reload Attack on DNS Forwarders Demystifying the (In)Security of QR Code-based Login in Real-world Deployments 10.27\u0026ndash;10.31 【DW】 Censorship Evasion with Unidentified Protocol Generation 10.13\u0026ndash;10.24 【SO】 Quic Skim: IMC 25 10.06\u0026ndash;10.10 on vacation 09.15\u0026ndash;09.26 【LW】 ReDAN: An Empirical Study on Remote DoS Attacks against NAT Networks Unleashing the True Potential of Semantic-based Log Parsing with Pre-trained Language Models SNI5GECT: A Practical Approach to Inject aNRchy into 5G NR clue中文语言理解测评基准 09.01\u0026ndash;09.12 【DW】 CertTA: Certified Robustness Made Practical for Learning-Based Traffic Analysis When a RF beats a CNN and GRU, together—A comparison of deep learning and classical machine learning approaches for encrypted malware traffic classification Feature Mining for Encrypted Malicious Traffic Detection with Deep Learning and Other Machine Learning Algorithms 08.25\u0026ndash;08.29 【DW】 Satellite: Joint Analysis of CDNs and Network-Level Interference Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China【GFW-QUIC审查】 Previous 【DW】 GFWeb: Measuring the Great Firewall’s Web Censorship at Scale【GFW-Https审查】 【Graded Friendly: S/L/D-Skim/Learn/Depth，w/o-with details/without details】\n","permalink":"https://lz0o0.github.io/zh/posts/academic/weekly-paper/","summary":"本文档记录每x周拟/已阅读论文，详情笔记可能单独设页记录","title":"Weekly Paper"},{"content":" 正在跳转到 CCF推荐会议列表...\n如果页面没有自动跳转，请点击上方链接。\n","permalink":"https://lz0o0.github.io/posts/academic/ccf-rc/","summary":"收录CCF推荐会议，Focus网络安全","title":"CCF-RC"},{"content":"\r\u0026emsp;\u0026emsp;笑登科，颜眉展，苦韵渐甘。\r\u0026emsp;\u0026emsp;风波颂，短歌行，且与君同乐。\r\u0026emsp;\u0026emsp;躬耕三载，挥毫舞墨，不过几日光景。\r\u0026emsp;\u0026emsp;熙熙三军，亮剑决雄，难比自垒攻心。\r\u0026emsp;\u0026emsp;道起乾坤难言少，堪说真意简成诗。\r\u0026emsp;\u0026emsp;童生伏案，举子夺元，何人喜登科？\r\u0026emsp;\u0026emsp;年华易改，音难异，昔日小儿，今尤在？\r\u0026emsp;\u0026emsp;旌旗奋，西风烈，染遍了寰宇。\r\u0026emsp;\u0026emsp;今长缨在握，奋起缚苍龙！\r本诗写于2025年夏。\r\u0026emsp;\u0026emsp;笑登科，颜眉展，苦韵渐甘。风波颂，短歌行，且与君同乐。\r\u0026emsp;\u0026emsp;躬耕三载，挥毫舞墨，不过几日光景。熙熙三军，亮剑决雄，难比自垒攻心。\r\u0026emsp;\u0026emsp;道起乾坤难言少，堪说真意简成诗。童生伏案，举子夺元，何人喜登科？\r\u0026emsp;\u0026emsp;年华易改，音难异，昔日小儿，今尤在？旌旗奋，西风烈，染遍了寰宇。今长缨在握，奋起缚苍龙！\r","permalink":"https://lz0o0.github.io/zh/posts/poetry/%E6%B8%85%E5%B9%B3%E4%B9%90%E7%AC%91%E7%99%BB%E7%A7%91/","summary":"\u003c!-- more --\u003e\r\n\u003cdiv class=\"poem\"\u003e\r\n    \u0026emsp;\u0026emsp;笑登科，颜眉展，苦韵渐甘。\u003c/br\u003e\r\n\t\u0026emsp;\u0026emsp;风波颂，短歌行，且与君同乐。\u003c/br\u003e\r\n    \u0026emsp;\u0026emsp;躬耕三载，挥毫舞墨，不过几日光景。\u003c/br\u003e\r\n\t\u0026emsp;\u0026emsp;熙熙三军，亮剑决雄，难比自垒攻心。\u003c/br\u003e\r\n\t \u0026emsp;\u0026emsp;道起乾坤难言少，堪说真意简成诗。\u003c/br\u003e\r\n\t \u0026emsp;\u0026emsp;童生伏案，举子夺元，何人喜登科？\u003c/br\u003e\r\n\t \u0026emsp;\u0026emsp;年华易改，音难异，昔日小儿，今尤在？\u003c/br\u003e\r\n\t \u0026emsp;\u0026emsp;旌旗奋，西风烈，染遍了寰宇。\u003c/br\u003e\r\n\t \u0026emsp;\u0026emsp;今长缨在握，奋起缚苍龙！\r\n\u003c/div\u003e\r\n\u003cdiv class=\"annotation\"\u003e\r\n本诗写于2025年夏。\r\n\u003c/br\u003e\r\n\u003cdiv style=\"border-top: 1px dashed var(--border);  margin: 2rem 0; padding: 1rem 0;\"\u003e\r\n    \u0026emsp;\u0026emsp;笑登科，颜眉展，苦韵渐甘。风波颂，短歌行，且与君同乐。\r\n    \u003c/br\u003e\r\n    \u0026emsp;\u0026emsp;躬耕三载，挥毫舞墨，不过几日光景。熙熙三军，亮剑决雄，难比自垒攻心。\r\n\t\u003c/br\u003e\r\n\t \u0026emsp;\u0026emsp;道起乾坤难言少，堪说真意简成诗。童生伏案，举子夺元，何人喜登科？\r\n\t\u003c/br\u003e\r\n\t \u0026emsp;\u0026emsp;年华易改，音难异，昔日小儿，今尤在？旌旗奋，西风烈，染遍了寰宇。今长缨在握，奋起缚苍龙！\r\n\u003c/div\u003e","title":"清平乐·笑登科"},{"content":"\r相关论文收录 The Internet censorship bibliography 生态全景 全球鸟瞰：Online Censorship 轴心区域：厄立特里亚、朝鲜、土库曼斯坦、沙特阿拉伯、中国、越南、伊朗、赤道几内亚、俄罗斯、古巴 边缘地带：欧盟、美国\u0026hellip; 审查测绘代表工作 Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China GFWeb: Measuring the Great Firewall\u0026rsquo;s Web Censorship at Scale How Great is the Great Firewall? Measuring China’s DNS Censorship OONI:OpenObservatory of Network Interference Censored Planet: An Internet-wide, Longitudinal Censorship Observatory ICLab: A Global, Longitudinal Internet Censorship Measurement Platform 审查逃逸代表工作 Censorship Evasion with Unidentified Protocol Generation 逃逸识别代表工作 Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes 审查技能树 IP封锁：黑白名单、残余审查（三元组） DNS审查：DNS过滤(分布式过滤\u0026hellip;)、重定向 内容过滤（SNI、DPI关键字匹配、blockpage 名单机制：黑名单、白名单 流量分析：协议指纹（未知协议、握手指纹\u0026hellip;）、流量熵、嵌套指纹（封装TLS握手） 主动机制：定点探测（指纹工程） 规避技能树：模仿\u0026gt;混淆 基于策略：域名前置、协议混淆（FET、协议生成\u0026hellip;）、深度包伪造（流量整形、平滑填充\u0026hellip;） 基于通道：VPN、混淆代理、Tor网络、嵌套协议 审查测量平台 ICLab OONI Censored Planet GFWatch GFWeb Internet Splintering 杂项 \u0026hellip; ","permalink":"https://lz0o0.github.io/zh/posts/academic/internet-censorship/","summary":"收录网络审查相关信息、主要研究及代表工作","title":"Internet Censorship"},{"content":"\r整体介绍 背景与发展 “方班研讨厅”又名创新与思辨，是方班的三门研究生创新课（研讨厅、演武堂、前沿秀）中的一门，也是方班最早推广的一门能力素质型课程。2019年秋在广大网安学院最早落地，凭借课程的独特性和方老师的号召力，该课程目前已经推广到国内29所高校，以创新实验班和研讨课程的形式进行落地和展开。\n特色与目标 方班研讨厅由中国工程院方滨兴院士设计并亲自全程参与教学。课程采用小班制、研讨点评式教学模式，由方滨兴院士、知名专家和专业老师组成教学组，采用**“学生讲、师生问、专家评”的深度翻转课堂形式，通过锻炼学生掌握求源方法、熵减方法、实践动手方法和思辨方法**，从而培养创新和思辨能力。课程以“授之以渔、掌握方法”为最大特色。突出实验班区别于常规课程的独到之处，着重强调以论文研读分享为核心教学模式，说明这种形式如何激发创新思维、深化知识理解。\n形式与内容 方班研讨厅的课程主要包括**“论文研讨分享、辩论赛”**两项，另有少量线上课作导引介绍方班另外两个课程的部分内容，两学期的时长中，第一学期包含两次论文研讨分享和一次辩论赛，第二次为一次论文研讨分享，形式相似但要求有所变化。\n论文研讨分享主要以研讨课形式展开，学期初排定课表，按照不同的专题学生被排到不同的班级，对应一个具体的线下班，每节课能够对应到 4 个同学的论文研讨分享。分享包括“论文讲评、学生提问、专家交流、院士点评”四个环节，整个分享过程不超过40分钟，讲评时间需要控制在19-21分钟内。\n辩论赛参考正常辩论赛的组织形式，与安全研究相关联。\n论文研讨分享：求源、熵减、思辨 论文筛选与范围 ： 为什么要讲这个论文？介绍论文所属的领域、方向，提及筛选论文的标准，是依据热点前沿、经典奠基之作还是导师推荐，展现论文的品质与关联性。—— 选择新的热的好的，倒逼熟悉旧的经典的；选择热门方向，筛选有讨论空间的（3次选择：作者、方向、工作效果、可复现否）——摸索\n阅读方法与策略 ： 分享在阅读过程中的技巧，如先浏览摘要、结论把握大意，提取核心观点、梳理逻辑架构后，再逐字剖析关键章节、图表。过程借助工具辅助（小绿鲸、WPS、亿图图示、excalidraw、Kimi等）。—— 个人习惯不同，精读差异不大（2day—5day）—— 摸索\n个人分享内容架构 ： 分享如何组织串联，如何将论文的背景铺垫、研究方法剖析、实验结果解读、创新点提炼等模块串联起来，让听众能清晰捕捉论文精髓。—— 怎么讲故事？当前标准化，非常流水线\u0026hellip; 背景、问题、【现象（发现）or “他山之石”】、方法、结论【复现与展开】、讨论【我作何想法】 —— 学习积累迭代\n分享形式与技巧 ： 线下讲演、线上直播，图文并茂的 PPT 演示，动画演示，与同学、老师的互动，抛砖引玉与注意力的引导。—— 架构上作优化、适当引入新奇的、夺人眼球的 —— 学习积累迭代\n交流与互动技巧： 熟悉内容的基础上答论文的观点or自己的想法（这个务必要有）、对问题的理解和评估、漏掉的细节是否关键、互动时简洁明了【别让皮球长时间停在自己脚下】—— 学习积累迭代\n阶段小结与问题收集： 下阶段迭代优化、避免 —— 给老师预讲、给师兄姐、同级预讲反馈不同 —— 综合迭代、以原本想讲的故事为主线\n辩论赛：调研、表达、思辨 攻守分析：敌我阵地、优势弱项分析、深度调研提炼、如何据守阵地步步为营 辩论技巧：有来有回（充耳不闻）、各说各话（不在一个频道） 交流与收获：策略狡辩、战术忽略、表演性质【收放难说】 印象与评价 投入产出比整体稍高 ：投入（前期准备【一个月、3篇】；程序化工作【线上平台、预讲、翻译、教案\u0026hellip;】；中途时间【内容占比、低相关研究】）、产出（求源、熵减、思辨一套方法论【未点明，自学习】） 程序化工作自优化：线上平台提问、回答【回答蛮有价值】、翻译\u0026amp;教案材料准备 预分享关注逻辑 ：预分享时主要关注自己讲故事的逻辑、架构是否顺畅合理，问题能不能讲清楚；根据校验加新东西 挑选问题并对比学习汲取：问题质量各异，分享者相对熟悉可以给出判断；从好问题中补充短板，从师生差异中明白问题的副要点 低相关研究多关注形式 ：当作科普了解、关注形式有无可借鉴的、方法可移植的【少有】 收获与心得 知识层面 ：每次论文研究分享都能熟悉一个小方向【透明代理、WAF；混淆代理、隧道通信；DDos】，大概都能串成一条主线；同方向的知道别人的兴趣和代表工作【特征使用方法，如包长、突发序列、流图\u0026hellip;】 批判思维 ：论文的内容，自己的想法与呈现；自己的转述、挑选与听众的疑问与反馈；交流讨论过程中的批判 沟通与表达 ：表达清楚自己的观点、自己表达的侧重与技巧【语速、节奏、重点】；与同学的合作 一整套方法论：读论文、讲东西、如何讲的准确更甚者有趣、提问题提思路、动手尝试 课程相关材料 各期论文与PPT：方班之声.zip\n注：内容为课程内部材料，不能随便公开，需要者联系我申请，表明来意\n","permalink":"https://lz0o0.github.io/zh/posts/academic/%E6%96%B9%E7%8F%AD%E6%94%B6%E8%8E%B7%E5%9B%9E%E9%A1%BE/","summary":"对24-25 UCAS 方班的小结","title":"方班收获回顾"},{"content":"\r\u0026emsp;\u0026emsp;人猿相揖别。只几个石头磨过，小儿时节。\r\u0026emsp;\u0026emsp;铜铁炉中翻火焰，为问何时猜得，不过几千寒热。\r\u0026emsp;\u0026emsp;人世难逢开口笑，上疆场彼此弯弓月。\r\u0026emsp;\u0026emsp;流遍了，郊原血。\r\u0026emsp;\u0026emsp;一篇读罢头飞雪，但记得斑斑点点，几行陈迹。\r\u0026emsp;\u0026emsp;五帝三皇神圣事，骗了无涯过客。\r\u0026emsp;\u0026emsp;有多少风流人物？盗跖庄屩流誉后，更陈王奋起挥黄钺。\r\u0026emsp;\u0026emsp;歌未竟，东方白。\r本诗写于1964年春，首次公开发表于1978年9月9日的《人民日报》\r1.创作背景：\r\u0026emsp;\u0026emsp;1963年，中国已基本上克服了经济上连续三年的困难，国家建设也出现了新的繁荣景象，人民当家作主的新中国在战胜暂时的困难后，显现出勃勃生机。\r2.参考译文： 类人猿进化到人，告别了类人猿的漫长时代。之后，就进步到最早的石器时代。从石器时代进化到青铜、铁时代，这样的冶炼技术究竟是在什么时候掌握的呢？只不过是几千年的事情。纵观历史，也如人这一生多半忧愁少开怀。尽是征战杀伐弓箭疆场。这大好河山哪一处没有战争没有流血。 通读完了二十四史，我已满头白发，我自己的人生也走到了暮年。回顾起来不过是那些同样的事情一再发生，什么王侯将相功名利禄，有多少人为其白首执迷。那些所谓的英雄人物难道是真风流？我看不尽然。盗跖、庄蹻、陈胜、吴广这些敢于揭竿而起挑战统治者的权威的人，那才是真豪杰。歌声意犹未竟，东方已经曙色初露了。 3.参考赏析： 本词上阙说出人类刚诞生时那惊心动魄的一刻；下阕艺术性地浓缩了词人一生读历史书的情形。全词风格豪放、气象雄浑，更复庄而不板、谐而不谑，其历史跨度，纵贯古今，对人类社会的全部历史发展进程予以概括描绘并深刻评弹，写得博大宏阔，却又似在诙谐谈笑间，隐寓着智者的卓识、仁者的义愤、勇者的信念。\n\u0026emsp;\u0026emsp;人猿相揖别。只几个石头磨过，小儿时节。铜铁炉中翻火焰，为问何时猜得，不过几千寒热。人世难逢开口笑，上疆场彼此弯弓月。流遍了，郊原血。\r\u0026emsp;\u0026emsp;一篇读罢头飞雪，但记得斑斑点点，几行陈迹。五帝三皇神圣事，骗了无涯过客。有多少风流人物？盗跖庄屩流誉后，更陈王奋起挥黄钺。歌未竟，东方白。\r","permalink":"https://lz0o0.github.io/zh/posts/poetry/%E8%B4%BA%E6%96%B0%E9%83%8E%E8%AF%BB%E5%8F%B2/","summary":"\u003c!-- more --\u003e\r\n\u003cdiv class=\"poem\"\u003e\r\n\t\u0026emsp;\u0026emsp;人猿相揖别。只几个石头磨过，小儿时节。\u003c/br\u003e\r\n    \u0026emsp;\u0026emsp;铜铁炉中翻火焰，为问何时猜得，不过几千寒热。\u003c/br\u003e\r\n    \u0026emsp;\u0026emsp;人世难逢开口笑，上疆场彼此弯弓月。\u003c/br\u003e\r\n    \u0026emsp;\u0026emsp;流遍了，郊原血。\r\n    \u003c/br\u003e\r\n\t\u0026emsp;\u0026emsp;一篇读罢头飞雪，但记得斑斑点点，几行陈迹。\u003c/br\u003e\r\n    \u0026emsp;\u0026emsp;五帝三皇神圣事，骗了无涯过客。\u003c/br\u003e\r\n    \u0026emsp;\u0026emsp;有多少风流人物？盗跖庄屩流誉后，更陈王奋起挥黄钺。\u003c/br\u003e\r\n    \u0026emsp;\u0026emsp;歌未竟，东方白。\r\n\u003c/div\u003e\r\n\u003cdiv class=\"annotation\"\u003e\r\n本诗写于1964年春，首次公开发表于1978年9月9日的《人民日报》\r\n\u003c/br\u003e\r\n\u003cspan class=\"bold\"\u003e1.创作背景：\u003c/span\u003e\u003c/br\u003e\r\n\u0026emsp;\u0026emsp;1963年，中国已基本上克服了经济上连续三年的困难，国家建设也出现了新的繁荣景象，人民当家作主的新中国在战胜暂时的困难后，显现出勃勃生机。\r\n\u003c/br\u003e\r\n\u003cp\u003e\u003cspan class=\"bold\"\u003e2.参考译文：\u003c/span\u003e\u003c/br\u003e\n  类人猿进化到人，告别了类人猿的漫长时代。之后，就进步到最早的石器时代。从石器时代进化到青铜、铁时代，这样的冶炼技术究竟是在什么时候掌握的呢？只不过是几千年的事情。纵观历史，也如人这一生多半忧愁少开怀。尽是征战杀伐弓箭疆场。这大好河山哪一处没有战争没有流血。\u003c/br\u003e\n  通读完了二十四史，我已满头白发，我自己的人生也走到了暮年。回顾起来不过是那些同样的事情一再发生，什么王侯将相功名利禄，有多少人为其白首执迷。那些所谓的英雄人物难道是真风流？我看不尽然。盗跖、庄蹻、陈胜、吴广这些敢于揭竿而起挑战统治者的权威的人，那才是真豪杰。歌声意犹未竟，东方已经曙色初露了。\n\u003c/br\u003e\u003c/p\u003e","title":"贺新郎·读史"},{"content":"\r一、答辩主要内容 1. zm师兄： 研究目标：DNS解析失败归因分析，构建归因分析体系\n研究内容：\n研究点1：基于随机模拟的DNS解析器负缓存测量方法\n部分厂商未按RFC实施负缓存，失败流量占比高原因 现有负缓存基于响应码实施，粒度无法支持深度归因 研究点2：基于上下文感知的DNS失败流量低频域名分析\n低频域名缺乏关注，聚合体量大，很多由算法自动生成\n14维语言特征提取—引入语言学模型评估\n低频域名很多为云服务、CDN、内网域名，涉及用户UUID等信息泄露传递\n研究点3：DNS解析失败原因分析系统\n技术路线：多源规则来源（RFC、威胁情报、专家经验、实验经验 技术路线：解析失败归因体系 技术路线：规则匹配图运用 发表论文和项目完成情况\n专家问题（右起）：整体内容不错，工作量详实，主要问题在研究目标描述和研究点的对应不够准确和清晰\nlqy：恶意域名使用注明、扫描行为去除原因注明、第三个点降成原型系统，目前并不健壮 专家2：题目所述和研究点标定围绕不够紧密，私以为二八 专家3：域名泛化对低频域名筛选的影响 中间跳过slm、fbx、gl老师 专家4：本归因体系解决问题明确 专家5：解析失败流量占比高是现象非挑战，失败归因原因尽量再明确，归因对安全的帮助 xg：解析失败流量的数量？当前只提了占比（better：主流厂商like chrome的滥用；内网隐私通过域名信息泄露的分析；归因分析展开到各个层级会更好，深入到具体的安全归因点能带来较大提升） slm：背景部分概念更明确一些，类似负缓存；原型系统而非系统；系统部署得到的结论补充，说明实际效果2. lqw师兄 2. by师兄： 研究目标：测绘发现不同的加密DNS服务类型，服务精细化管理 背景：加密DNS服务可能被滥用绕过监测，标准协议和多种私有协议并存，缺乏精细化管理 现状：私有加密DNS识别缺乏通用方法（隧道通信识别、解析网站识别） 研究内容：融合标准服务识别，私有服务发现，解析内容推断，提出加密DNS服务测绘关键技术 研究点1：基于多层级迭代探测的标准加密DNS服务识别（域内授权/域外授权权威解析识别区分） 研究点2：基于协议交互状态机的私有加密DNS服务发现 研究点3：基于HTTP/2帧解析序列侧信道的网站指纹识别（HTTP/2下帧的重要性） 原型系统：加密DNS服务测绘原型系统 发表论文和项目完成情况 专家问题（左起）： xg：网站指纹识别的规模、粒度（1/1634）\u0026ndash;此前的数据缺少，缺少复杂场景；数据集如何构造（顺序有区别，87%的准确度到规模大时能保证吗？方法的上限有多大？私有加密DNS服务的依赖分析） 专家2：①学术创新总结一些，做测量的传统问题，容易偏工程，学术性显得不强（方法+结果） ②发现的意义再总结，提供现实管理意义 ③方法在速度上提升如何（DOT快，DOH3day，DoQ的发现基于DoT） 专家3：研究点2第四章（方法和数据集都是自研，面临评价问题，注意文字和方法的规范化）；手动探APP的描述规范细化 专家4：95页图，数字显示；97页不良内容含义明确 专家5：60页结果描述不太明确；65页适用率为80%的解释不清，数字的对应关系 lqy：内容推断和分析需要过渡；50%的恶意（反常识的结果需要着重解释） slm：工作细、工作量够；研究所的目录模板公式化（普遍问题）；学术性描述加强 二、个人小结： 1. 问的最多的几个问题： 研究点和标题的对应关系：各讲各的还是只讲了一部分？实际做的事对应于描述是否准确？目录结构过时（私以为是风格问题\n做的事和所做事情的意义：你干了什么我听不出来，那说明你没干或者你干的不到位或者你理解和描述不到位，这里每一个都能否定你的工作；明确自己要做的事和实际做的事，找到工作的定位和价值，这是研究的意义，于己收束过往于人开引将来\n研究的理解门槛：不论是硕士还是博士，我认为大论文最起码的要求是能把你要做一个什么事，怎么做的事，讲个清楚，大就大在系统，对于一般读者而言可以不懂技术细节，但能知道大致怎么做的，这是作者理解和描述的问题，大论文的理解门槛不能太高，基本的概念都要讲清讲透，基本共识一定要稳固\n学术性和工程性：可以用问题、难点、方法、创新、解决来概括这两个偏向，一般的大论文应该都包含这些部分，学术性的区别主要体现在针对难点的方法创新，一般来说不会是纯技术的，答辩并不需要深钻创新的技术细节，告诉我公式怎么运作计算、具体如何跟踪流量，需要讲明的是方法，提供结果，并保证这个过程中方法的科学性和稳固性，合理可能是科学的但不稳固，自证永远有本位主义的问题，自创逻辑很难反驳，缺乏比较和讨论空间本身难以不稳固（you know 三角形具有稳定性🐶bushi\n论文图文数字细节：答辩的老师基本从开题听到中期、预答辩再到最后答辩，对于你所做的内容是比较熟悉的，而且他们的眼睛都很毒辣，能一眼找到问题，需要精益求精，只能花时间死磕\n2. 个人感悟 毕业更像个仪式，是对自己过去3-5年的总结，场下工作越足，场上约平静，波澜不惊 答辩是答而不辨，上升到辨就是没讲清楚，答的好的基础是有价值的问题、有稳固的逻辑、有达意的描述、有清楚的表达\u0026hellip;\u0026hellip; 答辩人可能对当时没什么感觉，但过后回想起来，这将是极其美妙的时刻，不是说为了答辩纪念，而是它象征着某种精神和身体上的长征胜利结束了，所谓3-5年的“豪赌”在自己的操盘下渐渐成为明确的结果。其实也不需要太多辞藻和大加赞美，这是一件有相当挑战性的事，但也是挺平常的一个选择 时光飞逝，祝福组内的zm、by、xo、yq、ly顺利毕业！ ","permalink":"https://lz0o0.github.io/zh/posts/academic/%E6%AF%95%E4%B8%9A%E7%AD%94%E8%BE%A9%E6%97%81%E5%90%AC%E7%BA%AA%E8%A6%81/","summary":"今天组内两位师兄毕业，恭喜他们，走上了人生一个新的阶段！","title":"毕业答辩旁听纪要"},{"content":"\r1. WAF的定义 WAF全称 Web Application Firewall，即Web应用防火墙，是一种专门用于保护Web应用服务免受各种网络攻击的安全防护工具。在现有网络中，WAF可能作为一个独立的硬件设备安装在网络中，也可能以软件形式作为模块集成到服务器上。随着云化趋势的深度扩展，云化接入、云集成的形式将成为主流发展方向。\n这里看似WAF有多种表现形态，为防止疑惑，有必要重塑一下对于防火墙的理解。所谓的“防火墙”，指的是一个处在外网和内网之间、由软件和硬件设备组合构成的保护屏障，“墙”的概念是一种获取安全性方法的形象说明。也就是说，防火墙本身就是计算机软件和硬件的结合，任何正常的、合规的网络通信和数据包能够通过此“墙”的筛查、过滤，而那些“坏东西”无法穿墙而过。\n了解网络技术最好先对场景有个整体的概念，WAF的工作场景如上图所示（这次试一下Excalidraw的手绘风格）。一般来说需要运营web业务的主体有部署WAF的需求，比如拥有网站服务的一般机构网络、Web服务提供商等。实际中，WAF部署选择会复杂许多，后面会专门介绍。\n区别于传统防火墙，WAF工作在应用层，处于Web业务服务器和客户端（比如，浏览器）之间，对Web网站或App业务的HTTP/HTTPS流量进行监测和过滤，通过一系列安全策略和规则来进行恶意特征识别及防护，就像在Web应用周围建立了一道安全屏障。\n2. WAF需求背景和功能 WAF的出现与传统防火墙的局限相合。传统防火墙主要工作在网络层和传输层，一般主要针对IP地址、端口等进行过滤控制，针对应用层的攻击较难识别，比如无法理解HTTP(s)中的内容，对一些恶意请求（如SQL注入、XSS攻击）无法进行识别。WAF的出现正是为了解决这些问题。\nWAF的推广与Web应用本身的广泛相伴。任何对运营和盈利有需求的网络主体，面临日益复杂的Web应用攻击手段，自然愿意为应用层防护买单，而WAF是一个直接易用的选择。\n那么，WAF的出现是为了解决哪些问题呢？我们试着从攻击者的角度去思考这个问题：假设本鲤作为一个攻击者，我基本的步骤是 “选定目标 → 目标画像 → 漏洞缺陷分析 → 攻击方式 → 发起攻击 → 胜利/失败结算时刻” 。在思考WAF时，不需要全流程的罗列，我们简单关注几个点，重点放在（w/o）WAF的情况下有什么差异即可。\n攻击者选定的目标由大到小大致如下，一般目标越大造成的危害越广泛，收益也越高。在选定目标之后，本鲤自然不会冒失地去搞一些小伎俩，我首先做的就是对目标画像，从多个维度了解目标，尽可能找出他的缺点或弱点，然后伺机而启，一击毙命。因此我会进行网络探测（踩点扫描）、服务版本识别等操作，从多个维度为目标画像，找缺点、弱点。\n全网 \u0026gt; 网络主机 \u0026gt; 主机数据库 \u0026gt; 主机WEB系统管理员 \u0026gt; 主机WEB系统其余用户 一个Web网络的结构如上图所示，我们假设网络的管理者安全意识足够，已经用传统防火墙对Web业务服务器进行了保护。很显然，由于防火墙在网络层和传输层进行了过滤，我们再想用主机发现、端口扫描之类的简单攻击行为就基本无效了，攻击者可能只能获取到Web业务服务域名信息（图中为www.0w0.com），想获得主机相关的IP、端口状态、系统等信息只能在其它层（比如应用层）想想办法。\n首先，可以通过Options、Trace方法探测目标服务域的节点拓扑。如果Web服务器支持这两个方法的话（一般来说，目前安全点的网站都不会允许这两个方法），可以通过检查响应包的Via或Max-forwards字段，得到各个节点的域名。然后，进一步查找对应的IP，尝试对IP直接进行扫描。 如果失败了，可以直接访问服务，检查响应包的Server字段或X-Powered-By字段确定业务域各个节点的http服务器软件版本和脚本语言解释器版本。可能需要扫描页面查看能否获取系统信息，如操作系统类型、版本，开启服务类型等，如有则可进一步查询CVE版本漏洞，并在exploit-db上寻找相应方法攻陷主机。 复杂一些，可以检查有无文件路径遍历，文件包含注入，API注入，命令注入之类的漏洞，来获取整个站点的系统信息甚至获取webshell。或者寻找有无SQL注入、XSS和URL注入等漏洞 —— 总言之，作为攻击者，拥有的武器库非常之丰富强大 理论上，WAF应当针对Web应用的HTTP(s)流量进行安全防护，可能需要支持的功能包括：\n禁止HTTP协议的非安全方法 伪装Web服务的特征 防止API和命令注入防止路径遍历和文件包含注入，对敏感的系统路径进行保护 防止sql注入 防止XSS攻击 防止网页挂马 防护CC攻击 文件上传的防护 动态IP黑名单 白名单 与实时计算平台对接 \u0026hellip;\u0026hellip; 截至目前，WAF已经进化到WAF3.0，除了常见Web应用攻击的防护外，能够防御CC攻击，还能支持精确防护，进行攻击事件管理等，功能可以说已经十分强大，可以简单看看阿里云WAF3.0的介绍：\n3. WAF发展历程和主要变化 随着 Web 技术的不断演进，WAF 也历经了从 1.0 到 3.0 的发展与变革。WAF 1.0 诞生于传统 Web 时代，基于签名规则应对基础攻击；WAF 2.0 随着 Web 2.0 的兴起而出现，引入动态分析与机器学习优化；如今的 WAF 3.0 则是在黑客利用零日漏洞攻击增多的背景下，以构建正常应用行为模型来实现更全面、更精准的防护，满足现代网络安全需求。\nA. 发展历程 从 WAF 到 WAF 3.0 的发展历程如下：\nWAF 1.0 ：在入侵检测系统 / 入侵防护系统（IDS/IPS）基础上，利用 HTTP 属性和数据转换进行分析，采用基于签名的方法，主要针对服务器攻击，如 SQL 注入、跨站脚本攻击等。 WAF 2.0 ：随着 Web 2.0 技术栈和关键网络应用数量激增，传统基于签名的方法过时，于是引入动态分析方法和监督式机器学习来优化签名列表，同时增加了保护用户免受攻击的方法。 WAF 3.0 ：黑客利用零日漏洞攻击增多，防御者需构建正常应用行为模型来检测异常，WAF 3.0 应运而生，可保护免受零日漏洞攻击，并防止绕过尝试。 B. 主要变化 WAF 从传统版本发展到 3.0，在全方位发生了变革与优化，主要表现在以下四个方面：\n接入方式 ：WAF 3.0 在支持 CNAME 接入和透明接入的基础上，实现了与应用型负载均衡 ALB 等云产品的云原生架构集成，支持云产品接入，还增加了全新的云原生架构接入方式，即通过 SDK 模块化的方式将 WAF 集成在云产品的网关中，避免因额外引入一层转发而带来兼容性和稳定性问题。 防护配置 ：相比 WAF 2.0 为单个域名配置防护规则，WAF 3.0 支持为防护对象或防护对象组配置防护策略，可通过创建防护模板配置防护规则，还支持通过多种方式查看防护规则，以及管理默认防护规则。 功能优化 ：WAF 3.0 取消了规则防护引擎的智能规则托管功能、自定义规则的滑块验证功能等部分功能，但新增了防护模板配置、自定义响应规则、重保场景防护、高级资产中心等功能。 技术应用 ：WAF 3.0 更多地引入了机器学习、人工智能等技术，能够自动学习和识别新的攻击模式，通过对大量网络流量数据进行分析和建模，检测出异常行为和潜在攻击，提供更高级别的防护。 4. WAF的工作原理和流程 Web 应用防火墙（WAF）通过深度检测和过滤 Web 应用的 HTTP/HTTPS 请求与响应，防御常见 Web 攻击。本部分介绍WAF的工作原理、关键模块和大致的工作流程。下图一般WAF的部署方式，直接插入到防火墙后面：\nA. 工作原理 请求检查（全面检查）：WAF 拦截每个传入的 Web 请求，包括请求头、请求体、URL 参数等。检查来源 IP、URL 路径是否异常，是否含特殊字符、SQL 关键字等，还检测请求头（如 User-Agent 字段）是否被篡改。\n规则匹配（预定义规则集）：WAF 内置基于常见 Web 攻击模式（如 SQL 注入、XSS 等）的安全规则。将请求特征与规则匹配，若符合恶意模式（如参数含 XSS 代码），判定为恶意请求。\n防护动作（多样化响应）：根据匹配结果采取防护动作。阻止恶意请求，防止其访问 Web 应用；记录攻击时间、源 IP、类型等信息到日志文件，方便后续分析；向管理员发送警报，提示攻击发生。\nB. WAF 的关键模块 WAF 专注于保护 Web 服务和 Web 应用，能深入分析 HTTP 流量，有效防御多种 Web 攻击。其核心是规则策略模块，能区分正常与恶意流量，并采取相应防护措施。\n入侵检测模块：分析 HTTP 输入输出数据流，识别潜在威胁。 规则策略模块：依据黑白名单、规则集区分正常与恶意流量，是 WAF 的核心依据。 防护模块：在检测到恶意请求时，采取拒绝服务、返回 400 响应页面等防护措施。 C. 工作流程 以请求处理为例，WAF的工作流程大致如下：WAF接收请求 → 请求检查（来源IP、URL路径、特殊字符等；黑白名单、规则集） → 规则匹配（与预定义规则对比；请求解密、头部\u0026amp;内容过规则） → 判断是否恶意请求 → 是 → 防护动作（阻止请求、记录日志、报警） → 否 → 请求继续处理。\n在处理过程中采取的操作可能包括直接放行（比如匹配到URL白名单，直接放行至Web服务器）、关卡放行（进入下一检测关卡），以及丢弃、拒绝、重定向、暂停（对于暴力攻击）、代理导流（如蜜罐）。\nWAF同样会对响应作一定处理，但相比请求要简单许多。下图是WAF处理过程的工作流示意：\n5. WAF的部署模式 随着网络安全需求的不断演进和技术的持续创新，WAF的部署经历了一定的发展变化。早期的反向代理、透明代理和旁路监控等传统模式，与如今云原生的架构进行了融合，WAF的部署方式变得更加灵活、高效且适应性强。这些变化能够提升WAF在复杂网络环境中的适用性和性能表现，极大简化部署和管理流程，使其能够更好地满足现代企业对Web应用安全防护的多样化需求。\n此前提到，在现有网络中，WAF可能作为一个独立的硬件设备安装在网络中，也可能以软件形式作为模块集成到服务器上。随着云化趋势的深度扩展，云化接入、云集成的形式或将成为主流。云化并未根本改变WAF部署的模式结构，而是将此前的部署模式与云场景、云部署进行了融合。\nA. WAF的主流部署模式 WAF一般支持透明代理、反向代理和旁路监控模式，三种部署模式从网络结构上存在明显的区别。\n透明代理串接模式 ：将WAF串接在网络中，实现即插即用，无需更改网络设备与服务器配置。其优点是部署简单、对网络结构无影响、安全防护性能强、故障恢复快可支持Bypass；缺点是对网络的依赖性较强，若网络出现故障可能会影响WAF的正常工作。 反向代理模式 ：早期WAF多采用此模式，其部署在Web服务器前端，客户端请求先经过WAF，由WAF代为转发请求到后端服务器，再将服务器的响应返回给客户端。优点是部署相对简单，且能有效隐藏后端服务器地址等信息，对服务器有较好的保护作用；缺点是可能会成为性能瓶颈，且需要更改网络配置，故障恢复相对较慢。具体可细分为代理模式和牵引模式，主要区别在于映射转发的位置。 旁路监控模式 ：通过在交换机上做服务器端口镜像，将流量复制一份到WAF上，WAF仅对流量进行监控和告警而不阻断，部署时不影响在线业务。此模式优点是不影响现有网络业务，可作为安全监测手段；缺点是无法直接对攻击流量进行阻断，只能起到事后分析的作用。\nB. 当前主流接入方式 当前主流的 WAF 接入方式各有特点，分别为 CNAME 接入、云产品接入和云原生架构接入。CNAME 接入操作简单，适合大多数网站业务，修改通过域名 DNS 解析实现引流；云产品接入则适用于阿里云用户，在云产品控制台添加引流端口到 WAF，无需修改 DNS，降低了配置复杂度；云原生架构接入是 WAF 3.0 的特有方式，采用 SDK 模块化集成，避免流量转发带来的兼容性问题，提升业务性能，简化接入流程。\nCNAME接入（反向代理模式）：CNAME 接入是通过将域名的 DNS 解析指向 WAF 提供的 CNAME 地址，使 Web 业务流量被引流到 WAF。WAF 作为反向代理集群，拦截攻击请求并将正常业务请求转发回源站服务器。它适用于大多数网站的 Web 业务，操作相对简单，只需修改域名的 DNS 解析设置，可以有效隐藏源站 IP，便于集中管理多个域名的流量并实施统一的安全策略。 云产品接入（透明代理模式）：云产品接入是通过在云产品控制台（如阿里云的 ALB 等）添加引流端口到 WAF，使云产品网关自动改变路由，将 Web 业务流量引导至 WAF。WAF 进行攻击拦截并转发正常请求回源站。它适用于使用阿里云云产品的用户，无需修改 DNS，降低了配置复杂度，减少了因 DNS 变更可能带来的流量中断风险，该接入适合与云平台应用产品紧密集成的场景。 云原生架构集成接入：这是WAF部署模式的重要发展方向，以阿里云WAF 3.0为代表。采用 SDK 模块化的方式将 WAF 集成到云产品的网关中，内嵌在网关中的 SDK 提取流量并进行检测和防护，WAF 不直接参与流量转发。它适合对业务性能和稳定性要求较高的场景，尤其是当用户已在使用阿里云的云产品且希望通过更高效的方式实现安全防护时。这种方式避免了因额外引入 WAF 转发层而可能产生的兼容性和稳定性问题，提升了业务性能，简化了接入流程，降低了对用户业务的影响。 6. WAF vs 其它 WAF的功能，免不了要与传统安全设备如IDS和IPS有所对比，但从WAF的出现和发展，俨然就是一个“专项特种兵”的模板，因此有其独特优势的同时，短板和局限也是十分明显的。\nA. WAF 与其他网络安全设备的对比 传统防火墙：工作在网络层和传输层，侧重源地址、目的地址和端口号的初步检测，无法深入分析 HTTP 流量。 入侵检测系统（IDS）：部署在内部网络，监控网络安全状况，侧重检测和审计，无法主动防御。 入侵防御系统（IPS）：基于签名数据库和策略来检查已知漏洞和攻击，适用于保护多种网络协议，但不专用于 HTTP 流量。 B. WAF 的价值与优势 深度防御：工作在应用层，能够审计所有 HTTP 流量，提供比传统设备更深入的 Web 应用保护。 灵活性：可以快速修改规则策略，及时应对不断变化的攻击。 速率限制：能够快速实施速率限制，有效防止 DDoS 攻击。 C. WAF 的局限 协议局限：WAF主要针对HTTP/HTTPS协议，无法过滤其他协议（如FTP、PoP3）的流量。 功能局限：无法实现传统防火墙的功能，如地址映射、端口转发等网络层和传输层操作。 攻击局限：主要针对应用层攻击，由于难以理解复杂业务逻辑，无法识别如恶意利用优惠券、外挂抢购等业务逻辑攻击，也无法防御零日攻击和部分复杂的应用层攻击。 防护局限：不具备防病毒功能，无法检测和清除终端设备上的病毒和恶意软件。 误报和漏报：尽管是共性问题，但WAF中部署模式的影响可能比较明显。 性能开销：对HTTP流量的深度检查和过滤会增加请求处理时间，导致延迟，且在处理大量流量时会消耗较多系统资源，影响Web应用性能。 配置和管理复杂：需要专业知识和经验来合理配置规则，过于严格或宽松都会影响效果，且需要定期更新规则以应对新的攻击方式，增加了维护成本。 7. 主流供应厂商和WAF产品 目前市场上的WAF产品种类繁多，涵盖了云WAF、硬件WAF和软件WAF等多种部署模式。云WAF产品如AWS WAF、Akamai Kona Site Defender、Fortinet FortiWeb、Cloudflare WAF等，具有部署便捷、易于扩展和集成等优势，适合各类企业使用。硬件WAF产品如安恒明御Web应用防火墙、长亭雷池(SafeLine)等，适合对安全性要求较高的企业。软件WAF产品如网站安全狗、云锁等，适合中小企业和开发者。各厂商不断推出创新产品和解决方案，以满足不同用户的需求。\n下表是目前比较主流的WAF供应厂商和产品线（这部分借助kimi整理）：\n公司名称 简述 国内 深信服 国内领先的网络安全解决方案提供商，WAF 产品简单易用、高效防护，广泛应用于各类企业及机构。 绿盟科技 提供硬件 WAF 产品，在网络入侵防护领域技术深厚，能有效应对各类 Web 攻击。 启明星辰 国内知名网络安全企业，硬件 WAF 产品防护能力强、功能丰富，满足金融、能源等行业需求。 安恒信息 国内网络安全佼佼者，天穹 Web 应用防火墙硬件产品，提供多方位安全防护服务。 腾讯云 提供云 WAF 服务，具备强大 Web 攻击检测能力，支持多种架构及接入方式，满足多行业需求。 阿里云 云 WAF 结合多种云服务交付，市场占有率高，提供全面防护功能及灵活付费模式。 国外 Fortinet 提供硬件和软件形式的 WAF 解决方案，其 FortiWeb 产品采用多层安全方法，防止已知和未知攻击，保护 Web 应用程序和 API，支持物理设备、虚拟机、云实例和容器等多种部署方式。 Imperva 提供全面网络安全解决方案，WAF 产品及服务防护能力强、功能丰富，应用于全球大型企业。 Cloudflare 全球知名云服务提供商，WAF 服务集成于云平台，具备强大 DDoS 防护及 Web 攻击防护功能。 Akamai 提供软件和托管服务形式的 WAF 解决方案，依托全球分布式网络，保障 Web 应用可用性和安全性。 F5（CloudGuard） 提供高性能硬件 WAF 设备和软件解决方案，在应用交付和安全领域经验丰富，提供高级防护。 Barracuda Networks 提供多种形式的 WAF 解决方案，产品易用且高效，可有效保护 Web 应用免受多种攻击威胁。 厂商 产品 部署模式 核心能力 AWS AWS WAF 基于云 基于云的WAF解决方案，与AWS服务集成，提供可扩展和灵活的保护，实时威胁检测和阻止，可自定义规则和策略 Akamai Kona Site Defender 基于云 提供企业级保护，高级DDoS保护，实时威胁检测和阻止，与Akamai的CDN集成以改善性能，全面的报告和分析 Fortinet FortiWeb 硬件或虚拟 基于AI的威胁检测和阻止，提供硬件和虚拟解决方案，机器人保护和DDoS缓解，全面的报告和分析 Cloudflare Cloudflare WAF 基于云 提供低延迟、高可用、高可扩展的防护能力，可防止OWASP Top 10等常见攻击，可根据用户自定义规则和Cloudflare智能规则进行灵活配置，可与其他服务集成 ModSecurity ModSecurity WAF 主机层 开源免费，灵活配置，支持多种协议和格式的分析和过滤，可使用OWASP Core Rule Set等标准规则集，也可使用用户自定义规则，还可与其他工具集成 阿里云 阿里云WAF 基于云 提供基于云计算的Web应用防火墙，保护Web应用免受常见黑客攻击技术和安全漏洞的侵害 腾讯云 T-Sec WAF 基于云 提供Web应用防火墙服务，具备Web安全防护和Web威胁智能拦截功能 华为云 Web应用防火墙 WAF 基于云 提供Web应用防火墙服务，保护Web应用的安全 安恒信息 玄武盾 基于云 提供云防护平台，具备Web应用防火墙功能 百度智能云 云应用防火墙 WAF 基于云 提供应用防火墙服务，具备安全漏洞防护和云安全应用防护功能 知道创宇 创宇盾 基于云 提供Web应用防火墙服务，具备政企网站防护、被黑防护、防篡改等功能 F5 分布式云 WAF 基于云 提供分布式云WAF服务 奇安信 网站卫士 基于云 提供Web应用安全防护服务 360 磐云 基于云 提供Web应用防火墙服务 网宿科技 Web应用防火墙 基于云 提供Web应用防火墙服务，具备网站防护和智能边缘安全功能 深信服 云Web应用防火墙 基于云 提供云WAF服务，具备Bot防护和云安全功能 绿盟科技 网站云防护 基于云 提供云计算安全产品，具备网站云防护功能 启明星辰 虚拟化WAF 虚拟化 提供虚拟WAF服务，具备Web应用安全网关功能 长亭科技 雷池(SafeLine) 硬件 下一代Web应用防火墙，提供Web应用防护功能 天融信 Web应用安全防护系统(TopWAF) 硬件 提供Web应用安全防护系统服务 瑞数信息 动态Web应用防火墙（River Safeplus） 硬件 提供动态Web应用防火墙服务 写在最后 本质上，WAF作为一种专用网络安全技术，在安全防御体系中需要承担特定的责任。用现实世界中安防机构的安防全景图来类比，WAF比较类似一个大门入口处智能安检系统的角色，负责检查进入Web应用的“人员”（HTTP请求），并拦截可疑行为（如SQL注入、XSS攻击）。\n关于安防机构的全景图，我简单设想了一个分层比喻的对应情况，便于理解WAF的角色定位：\n外部防御层：防火墙（围墙+安检门）+ VPN（加密电梯） 入口过滤层：WAF（智能安检系统） 内部监测层：IDS（摄像头）+ IPS（安保人员）+ HIDS（保镖） 数据保护层：加密技术（保险柜）+ 网络隔离（防火分区） 高级防护层：蜜罐（诱饵房间）+ 零信任（人脸识别门禁）+ SIEM（指挥中心） Refer WAF相关专栏： 安全文章相关\nWAF的部署方式 - 知乎\n什么是Web应用防火墙，简称：WAF（Web Application Firewall）_waf应用安全网关是什么-CSDN博客\nWAF（Web应用防火墙）的关键技术分析_waf路由模式-CSDN博客\nWAF 2.0和WAF 3.0是什么关系、有什么区别、如何快速使用_Web应用防火墙(WAF)-阿里云帮助中心\nWAF基本原理与部署方式，建议收藏！ - FreeBuf网络安全行业门户\nKimi：Kimi - 会推理解析，能深度思考的AI助手\n","permalink":"https://lz0o0.github.io/zh/posts/nice-techs/%E5%85%B3%E4%BA%8Ewaf%E4%BD%A0%E9%9C%80%E8%A6%81%E7%9F%A5%E9%81%93%E4%BB%80%E4%B9%88/","summary":"WAF即Web应用防火墙，专门用于保护Web应用服务免受各种网络攻击。本文主介绍WAF的需求背景、工作流程和拓扑、主要业界厂商。","title":"关于WAF--Web应用防火墙"},{"content":"\r一、zero-to-one 1. 什么是MCP？ MCP（Model Context Protocol）即模型上下文协议，由Anthropic在2024年11月25日发布的一篇文章中最早向公众提出：Introducing the Model Context Protocol。该文章将MCP描述为一种新的连接标准（即通信协议），用于统一前端AI助手和后端数据系统之间的连接方式，以期帮助前端模型完成更高质量的工作。\n2. MCP的提出背景和拟解决问题？ 问题与需求：随着AI助手得到广泛运用，整个行业对AI模型功能的投入相继加码，实现了推理能力和响应质量的巨大进步。然而，即便是目前最精良复杂的模型也存在与数据源相隔离的限制，它们各自隔离并处在遗留系统和信息孤岛之上，每个数据源的调用和访问都需要用户单独自定义实现（此前主要通过function calling，模式类似一把钥匙开一把锁，但配这么多钥匙并不轻松），这使得真正连接的系统（比如Manus）难以扩展其能力。\n3. MCP的核心思想？ MCP的方案：MCP核心思想是采取单一通信协议，取代碎片化集成。在原有混乱多样的连接形式下，只要大家都按照统一的标准开发和提供接口，原本需要针对每个数据源单独自定义连接方法的问题，就可以得到有效解决。而Anthropic推动并提供了这样一个通用的开放连接标准——MCP，对AI系统和数据源之间的连接进行了规范和统一。\n4. MCP的组成结构？ MCP的架构：采用典型的“C-S”架构，在数据源（借助MCP Server）和AI助手（借助MCP Client）间构建双向连接，开发者可以选择构建MCP Server以公开其数据访问提供服务，亦可选择开发MCP Client用以连接各种类型的MCP Server访问其服务。\nMCP的组成成分：由上图可见，MCP主要包含三个核心组件：MCP Host、MCP Client、MCP Server，囊括两类数据服务：Local Data Sources、Remote Services。\nMCP Host：宿主机，即希望通过 MCP 访问数据的 Claude Desktop、IDE 或 AI 工具等宿主机应用程序 MCP Client：客户端，在宿主机应用程序内部，负责与MCP服务端保持一对一连接，可以理解为连接进程的端点，可以配置MCP Server MCP Server：服务端，一些轻量级程序，每个这样的程序都通过标准化的 Model Context Protocol 公开特定功能(比如查询时间 Local Data Sources：本地数据源，即MCP 服务器可以安全访问的本地计算机文件、数据库和服务 Remote Services：远程服务，即MCP 服务器可以连接到的 Internet 上可用的外部系统（比如通过 WebAPI，访问git和github） 5. MCP的工作流？ 下图是MCP运行时的大致工作流。以一个 \u0026lt;问题查询并通过邮件返回通知\u0026gt; 的任务为例，MCP的整个工作流程是这样的：用户问题 → MCP Hosts（如 Chat Apps）接收问题 → 大模型进行意图分析，根据分析结果进行响应或任务编排 → MCP Clients 按照编排选择工具完成任务（if need） → 【 ① MCP Servers 利用其能力（如工具、资源、提示等）进行处理 or ② MCP Servers 可能会调用外部的 API（如 Web Services、Database、Local Files 等）来获取所需数据 】 → MCP Servers 将初始响应返回给 MCP Clients → 客户端初将始响应告知大模型，大模型进行优化，并再返回给 MCP Clients （Clients 可能会进行进一步的通知操作 ）→ MCP Clients 显示最终响应，并向用户显示任务执行结果。\n对应图中 Transfer Layer 的部分是 MCP Clients和 MCP Server 进行初始化的过程，这个阶段发生在任务执行之前，因而未在工作流中提及。这一阶段主要是完成 MCP Servers 的注册，初始化之后，Client 与 Server 维持 1:1连接，方便后续调用。\nMCP这种“C-S”架构和工作流的设计使得宿主机应用程序（比如 Claude ）可以在不同场景下灵活调用各种工具和数据源，而开发者也只需专注于开发对应的 MCP Server，无需关心 Host 和 Client 的实现细节，解决现有问题基础上能够模块化分离各方开发的重心，提高开发效率。\n二、MCP 工作机制的核心 基于上图的工作流，我们发现MCP工作过程中尤为重要的三个阶段，理解这三个阶段的实施和逻辑，能够帮助我们掌握 MCP 工作机制的核心特点。\n如何理解 MCP Server 的初始化？ 如何智能选择 MCP Server，进行任务编排？ MCP Server 执行结果的反馈机制是怎样的？ 1. 如何理解 MCP Server 的初始化？ MCP 服务端的初始化是在启动 Host 读取配置文件后，预先完成的。在上一节的工作流介绍中并未提及 MCP Server 进行初始化的细节，具体过程如下（见下图）：MCP Clients 向 MCP Servers 发送初始请求 → MCP Servers 收到请求后，进行初始化响应，告知其可用tools/list → 完成初始化通知，所有的 MCP Servers 完成注册。\n这里有几个问题需要思考，为什么要预先进行初始化注册？初始化之后具体发生了什么变化？什么时候需要初始化？\n为什么要预先进行初始化注册？\nMCP 要预先进行初始化注册是为了确保 MCP Server 在开始提供服务前处于可用且正确的状态，具备所需的资源和环境配置，并能够与其他组件（如 MCP Host 和 MCP Client）正常通信，同时确保服务的安全性和合法性。这一步骤有助于 MCP Server 正确暴露其功能接口，使得其他组件能够发现和调用其服务，同时也为后续的服务管理和动态更新打下基础，从而保障整个 MCP 系统的稳定运行和有效协作。\n用最开始的MCP图示作类比，MCP初始化注册的过程很像电脑注册外接设备。当你连接一个外接设备（比如 USB 设备）到电脑时，电脑通常需要先识别该设备并加载相应的驱动程序。在这个过程中，电脑会预先注册设备的信息，如设备类型、制造商、设备 ID 等。这一步骤确保了电脑知道设备的存在，并且能够与设备进行通信。如果等到你实际要使用设备的具体功能（比如读取 USB 存储设备中的文件）时才去注册设备信息，那么在你尝试使用设备时可能会出现延迟，甚至无法正常使用，因为系统还没有准备好与该设备通信。\n同样，MCP Server 的预先初始化注册就像是在告诉系统（MCP Host）“我在这里，我能够提供这些服务”，这样当客户端需要使用这些服务时，系统已经知道如何找到并使用 MCP Server，而不需要在每次任务执行时都去发现和配置 Server，从而提高了效率和可靠性。\n初始化之后具体发生了什么变化？\n初始化后，MCP Server 从不可用状态转变为可用状态，系统为其分配了所需资源，并加载了运行环境，使其能够正常响应请求并提供服务。同时，它向 MCP Host 注册了自身提供的服务接口和功能，使得其他组件能够发现并调用这些服务。\n状态转变：MCP Server 完成初始化后，其内部组件和功能模块被正确加载和配置，从初始的未准备好状态转变为可以接受和处理外部请求的状态 资源分配：系统根据 MCP Server 的需求为其分配了必要的资源，包括内存、计算能力等，确保其在运行过程中有足够的资源来执行任务，从而提高服务的响应速度和处理能力 服务暴露：MCP Server 向 MCP Host 注册了详细的服务信息，包括服务接口、功能描述等。这些信息使得 MCP Host 和其他组件能够了解该 Server 的能力，并在需要时快速找到并调用相应的服务 最直观的变化一是相关配置确定，二是可通过MCP Client查看Server提供的工具或数据服务。至于注册信息的存储位置，通常由 MCP Host 负责管理，可能存储在 MCP Host 的内存中（以便快速查询和管理）、配置文件中（如 JSON、XML、YAML 格式文件，存储在 MCP Host 的配置目录下）、数据库（对于需要持久化的场景，可能存储在关系型或非关系型数据库中）或分布式缓存（如 Redis，用于提高查询效率和系统性能）。具体的存储位置和方式取决于 MCP Host 的实现细节和系统架构设计。\n以 vscode 使用 cline 访问 Time MCP服务为例，按照 MCP 配置文件进行 Time 的初始化。(上图为配置文件, Cline 插件的配置文件位于 VSCode 的用户配置目录中, 此例中为 C:\\Users\\\u0026lt;YourUsername\u0026gt;\\AppData\\Roaming\\Code\\User\\globalStorage\\saoudrizwan.claude-dev\\settings\\cline_mcp_settings.json。具体的配置文件名和位置可能因插件而异，建议查看插件的文档获取准确信息。）Cline 启动 Time 后，能够查看其支持的 tools 和 resources，能够对该Server进行重启、删除等操作。而关于此 MCP Server 的相关信息，此后在与大模型交互时，也会告知大模型。\n如果希望拥有多个可用的 MCP Servers，你需要分别对每个 MCP Server 进行初始化操作，或者通过某种批量处理机制来启动和初始化多个 Servers。每个 MCP Server 都需要单独完成其初始化流程，确保它们都正确注册到 MCP Host 并准备好提供服务。\n什么时候需要初始化？\n在 MCP 系统中，初始化通常在添加和配置MCP Server时即完成，通常不需要每次运行任务或查询时都重新进行初始化注册。一旦 MCP Server 成功完成初始化注册，它就可以在 MCP Host 中保持注册状态，直到 Server 被关闭、重启或者显式地注销。这样设计的原因在于：\n提高效率：避免每次任务执行前都要重复注册流程，节省了时间和系统资源，加快了任务的启动和执行速度 保持服务的持续可用性：使 MCP Host 和客户端能够实时了解 MCP Server 的在线状态和服务能力，确保在需要时可以立即调用，无需额外的准备工作 简化管理：减少了注册和注销操作的频率，使得系统管理更加简洁和高效 如果 MCP Server 发生了诸如重启、全局配置变更等情况，可能需要重新进行初始化注册，以确保 MCP Host 能够获取到准确的 Server 信息并继续提供服务。这很自然，重载配置文件的过程自然需要刷新状态，完成每个 MCP Server 的初始化。\n需要注意的是，初始化主要是针对单个 MCP Server 来说的，指的是该 Server 完成自身的启动配置、资源分配以及与 MCP Host 的注册过程。当一个 MCP Server 成功初始化后，它就处于可用状态，可以被 MCP Host 和其他组件发现并调用了。在实际使用时, MCP通常是根据 MCP Servers 的全局配置文件来读取每个 MCP Server 的信息并完成对应的初始化注册或状态刷新。\n2. 如何智能选择 MCP Server，进行任务编排？ 首先， MCP Server 的选择范围受到初始化结果的限制，这是智能选择的前提条件，也是问题解决的一个限制因素。其次，大模型理解用户任务需求后，进行意图分析，确定需要返回的内容和获取内容的方法，这是对任务目标的明确。最后，大模型综合意图分析结果（目标），已有 MCP Servers 的可选项（条件和限制），从中选择特定的 Server，指定访问的工具和参数（智能选择），即完成任务编排过程。\nRefer MCP开源库：Model Context Protocol 什么是MCP｜工作原理｜如何使用MCP｜图解MCP - 知乎 MCP 是什么，现状和未来 | OneV\u0026rsquo;s Den ","permalink":"https://lz0o0.github.io/zh/posts/nice-techs/mcp-%E6%A8%A1%E5%9E%8B%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8D%8F%E8%AE%AE%E5%85%A8%E8%A7%A3/","summary":"MCP模型上下文协议,通过采取单一通信协议，取代碎片化集成，对AI系统和数据源之间的连接进行了规范和统一，打破了传统模型和数据源之间互相隔离和访问繁琐的限制，重塑了模型和数据的操作和安全边界。","title":"MCP 模型上下文协议全解"},{"content":"\r1. 背景 2022年以来，AI 应用井喷式爆发，各种通用 AI 大模型和一众垂类 AI 应用相继出现，并迅速席卷各个行业。AI 的迅速推广、普及，为社会的各行各业带来强大助力，也为广大用户的学习生活提供诸多便利，但于此同时， AI 应用服务从用户接入、智能体处理、外部调用到模型训练的全生命周期，普遍缺乏透明度和内容安全监管，用户隐私泄露、模型内生安全、越狱攻击、意识渗透等安全威胁的危害越发突出，AI 内容缺乏有效、可靠的技术监管机制，AI 应用安全面临新一轮挑战。\n尽管实现全周期的内容安全监管十分复杂，但仅仅在 AI 用户和 AI 应用之间，进行交互内容的监管、过滤却并非不可行，最直观的思路就是部署一个 AI 内容防火墙，也就引入本项目的需求，下文简记为 AI-CFW。\n简言之，本项目的目标即实现一个 AI-CFW 原型系统，该系统部署于 AI 应用和 AI 使用者之间，能够对使用者的提问以及 AI 应用的回复内容进行过滤。应用于实际，AI-CFW 需要满足以下要求：\n实时发现恶意指令、越狱尝试、价值观异常的 AI 回复或违反内容合规、数据隐私要求的情况\n进行格式回复、拒绝应答或会话阻断等操作\n此项目需求来源于UCAS课程，本鲤主笔。为方便管理，在此文作记录归档。\n2. AI-CFW 设计难点与目标 Agent（智能体） 是目前 AI 应用中比较热门的一个概念，用户通过向 Agent 智能体提出需求，Agent利用其工具、记忆以及规划能力，给出回复满足用户需求。“需求-回复”的交互看似简单，但在网络传输中，却是实实在在历经了比较“漫长”的传输过程（本鲤发现不了解网络的同学实际不知道自己和服务间的流量是怎么传输和处理的，本鲤后面单开一篇，埋坑\u0026hellip;）。安全需求是需要场景的，而明确了需求角色之后，场景和目标自然明确，假定“本鲤是一名机构网络的网络管理员（真网管！）”，那么参考下图右边的结构进行分析，我们可以进一步明确 AI-CFW 设计与实现面临的挑战。\n面对上述网络场景，AI-CFW 设计面临的主要挑战如下：\n如何将对所有大模型的访问都纳入监管？\nhttps应用普遍情况下如何获得交互内容？\n如何判定大模型输出结果是否违规？\n在设计之初，我们将 AI-CFW 的预期目标设计如下：\n流量还原与 AI 机器人的对话内容（包括但不限于文本，图片，文档等） ✓ 相关知识点：流量还原，应用识别，加密内容获取等 研究审核 AI 聊天内容中的违规内容 ✓ 相关知识点：字符串匹配过滤，内容理解，虚假信息检测等 3. 已有解法分析： 我们分析一下行业风口的巨头们都是怎么做的，他们的解法，可能对本项目有所启发。具体而言，目前已针对 AI 发布内容防火墙产品或网关的企业并不在少数，诸如火山引擎、启明星辰、Cloudflare、Kong、Gloo、 Higress、Portkey 和 OneAPI等，本鲤主要梳理了前三个厂商的产品和模式特点。（之后了解到 Portkey 、OneAPI 针对 AI 的原生特性更强，后续再作补充吧）\nA. 火山引擎（供给侧 AI 保障） 大模型应用防火墙 —— WAF串接模式：火山引擎是字节旗下的云服务综合平台，其推出的大模型应用防火墙（下简称LMs-WAF），主要提供算力消耗防护、提示词识别、优化内容生成和鉴权与用量配置等功能，它更加侧重于对服务侧 AI 业务的防护，力求保证 AI 应用平稳落地，提供可靠、安全、优化等服务。（关于WAF是什么，本鲤后面简单开一篇介绍）\n针对的目标群体是愿意为 AI 业务平稳运营，支付检测保障费用的 AI 企业。\nLMs-WAF 的防护结构如下图所示，包含四维防护优化：接入净化保护（可用性）、提示词注入检测、数据窃取识别、鉴权分析（外部调用、内部投毒）。\n火山 LMs-WAF 提供两种接入方式：通过CNAME接入（试用于未基于火山部署AI业务的企业）、通过火山原生CLB开启TCP监听接入。CLB即负载均衡，实际上基于CLB监听接入的方式也主要是基于CNAME的，至于原因，后面会再解释。下面是两种接入方法的部署结构拓扑：\n考虑到不同背景的小伙伴，简单介绍一下CNAME（这是域名解析中比较常见的概念，对DNS有了解或者自己鼓捣过小网站的同学应该很熟悉），其余的内容图中很直观，具体不再赘述。\n【CNAME】是域名解析中的一个记录名称，也叫别名记录，这个别名的概念是相对 A(Address) 记录而言的。域名解析的一般过程便是访问A记录，将域名映射为对应的IP地址，而CNAME记录则能够将域名解析为另一个域名，这时你发现只要将原本用户访问的域名A通过CNAME解析到域名B，那么生效后，用户在进行DNS解析时，就会直接去访问B指向的服务器地址了，访问流量走的是另外一条路径（CLB业务基本是这个模式，比如CDN中的加速资源就基本与域名绑定。这里也解释了为何上面说第二种方法实质也是基于CNAME。【火山CLB中间用监听实现内容检测的这个结构很值得思考，或许可能为旁路部署提供经验。不过这里缺乏进一步信息，难成主线，咱有空再来填坑】\n上面说了很多，个人或者小团体实际上很难用火山的模式复刻一个 AI-CFW，因为 LMs-WAF 实际更侧重AI应用的全流程业务优化防护，需要供给侧服务商的加入，个体缺乏号召力，另外这种模式的运营也十分依赖火山云服务本身够硬的能力。\n但是退一步说，LMs-WAF 比较有借鉴意义的是他们在接入层和智能体中间进行的提示词注入检测，以及参照的内容合规标准。\n【提示词注入】是一种 AI 应用攻击方式，通过分工协作的“越狱 Prompt”+“恶意诱导 Prompt”，能够绕过平台和模型原生安全机制，诱导模型生成恶意内容。现实中需要考虑服务可用性和检测严格阈值的trade-off，因而这种攻击难以根除。针对这种安全威胁，火山 LMs-WAF 采用了意图识别、防提示词注入、动态对抗与价值观校准等防护机制，通过利用 AI 能力对抗 AI 攻击，提升大模型面对提示词注入的应对能力：\n通过深度上下文引擎，可识别97%隐式攻击\n基于千万级对抗样本训练，覆盖20+提示词攻击场景，检出率达99%+\n经某大模型服务平台实测，违规内容及价值观偏移回答均下降98%\n【内容合规标准】：《生成式人工智能服务暂行管理办法》中 5 大类 31 个小类规定\nB. 启明星辰（用户侧数据脱敏） 大模型访问脱敏罩MADA Mask —— 网关串接模式：启明星辰是一家主攻安全服务的综合提供商，目前由中国移动实际控股，专责网信安全，覆盖网络安全、数据安全、应用业务安全等多个领域。启明星辰发布的大模型访问脱敏罩MADA Mask（Model Application Desensitization Access Mask，下简称LMs-Mask），主要关注机构对外访问开放大模型时，在充分保障共有大模型效用的前提下，如何有效避免自身敏感数据泄露的问题，其核心是为用户侧访问提供专业可靠的数据脱敏服务。\n针对的目标群体是机构或企业单位，具体服务模式和接入方式，未得到其公开声明。\nLMs-Mask 的防护结构如下图所示，其核心是保障数据上传过程中的敏感内容识别和安全脱敏：LMs-Mask串接在机构用户访问各种公域或私域大模型的路径上，提供对机构用户的数据脱敏（智能围栏、全链审计），并能够对内容进行智能阻断（NLP识别、优化调整）。\nLMs-Mask 同样提供两种部署方式，实质都是网关串接：本地网关形态部署（串接于企业网络边界出口）、SAAS化代理网关形态（串接公有云，访问特定入口。考虑目前云化的趋势，这应该是目前主流的方式）。下图是SAAS化代理网关形态的结构：\n简单补充下SaaS的概念，**SaaS（软件即服务）**是一种基于云计算的软件交付模式，通过互联网提供应用程序，用户无需购买、安装和维护软件，只需通过网络浏览器或移动应用程序访问和使用软件。通过SaaS模式的特点，可以简单猜测LMs-Mask的拓扑结构：用户通过软件/浏览器接入启明星辰提供的代理节点，节点支持请求处理和回源转发，并最终返还交付回用户。 启明星辰对 LMs 的部署模式进行了分析，简要总结例举在下方：\n全私域部署：在机构内部部署满血DeepSeek或其他全功能大模型。这样机构内部使用大模型，数据泄露的直接风险相对不高（并非完全没有）；对应机构的投入成本相对较高。 公共大模型访问开放部署：机构为内部员工提供自由访问的外部大模型。这样机构的投入最少、起步最快；数据泄露风险暴露面最大，最危险。 公共大模型访问罩部署：机构为内部员工访问外部大模型提供一个访问代理，并同时安排数据安全和其他应用安全保护。这样可以在极少的投入下，让机构全员能够获得大模型应用的收益。该部署方式和前两种部署方式并不互斥。（也就是LM-Mask的解法） 混合大模型访问体系化部署：基于AI-R-IAM身份管理、业务分割、网络分域、数据分域的复杂部署方式。这种部署模式适用于大型机构的深度应用环境。 LMs-Mask的解法比较符合本项目的需求，思路比较值得借鉴。一方面对用户侧上传的数据进行脱敏处理，防止泄露风险同时保障隐私性，另一方面，网关串接的模式对于用户几乎无感，实施相对简单。但是这种方法，数据处理和安全脱敏都较高程度地依赖代理节点，对其性能要求和可靠性要求可能较高。\n由于其未公开产品接入具体方法，本鲤对其本地串接过程和云外接访问过程中数据流的处理还有些模糊，初步猜测应该是基于证书-密钥的还原形式。\n【内容合规标准】：《数据安全法》、《个人信息保护法》\nC. Cloudflare（API网关） AI gateway —— 反向代理模式：Cloudflare的大名无需多言（全球最大的CDN服务商），作为首款全球连通云，其产品线和服务囊括计算、存储、网络全栈，实力非常之雄厚（这里不得不赞，很多时候，CF很像个慈善家\u0026hellip;\u0026hellip; )。Cloudflare推出的基于其公有云Serverless的 Cloudflare AI Gateway（下简称 LMs-Gateway），是一个用于管理和扩展生成式 AI 工作负载的统一接口，用户可以通过它提高对 AI 应用程序的可见性和控制能力，它支持多方提供商，包括 OpenAI、Google Vertex AI、Azure OpenAI、HuggingFace、Amazon Bedrock 和 Anthropic（最近大火的MCP）等。\n具体而言，LMs-Gateway 的核心功能就是提供一个统一的接口，这个接口可以管理和扩展各种生成式 AI 的工作负载，包括各种访问流和 API 调用。无论模型在何处运行，只需通过将应用程序连接到 LMs-Gateway ，它就可以充当服务与具体服务提供商之间的代理，网关管理者因而可以监控用户交互的过程、进行日志记录，并利用缓存、速率限制、请求重试和模型回退等扩展功能。\n针对的目标群体相对广泛，包括个人和企业用户。\nLMs-Gateway 的结构如下，依赖其本身对多方提供商的支持能力，主要在服务和具体的服务承载工具之间充当 API 代理，整体的拓扑结构类似反向代理，就用户体验而言实际就等同于一个大模型API代理。\n借由上图中的结构，服务请求都被发送到 LMs-Gateway，网关再进行请求的转发，并从缓存读取响应回递传送给用户。这个过程中，流量进出都经过 Cloudflare ，流量的还原处理应当也是基于证书密钥。\n简言之，Cloudflare 的 AI Gateway 主要功能即一个反向代理，若用户原本直接经过 OpenAI 的 API 访问https://openai ，那么现在仅需把访问服务的 baseURL 换成https://gateway.ai.cloudflare.com/v1/${accountId}/${gatewayId}/openai 即可。\n这个方案有下面几个优点：\n只需修改 baseURL 即可接入，不改变 API 格式，接入相对简单 服务是 Serverless 的，不需要用户额外管理任何服务器 借助 Cloudflare 的全球网络可以实现一定的用户接入加速 借助 Cloudflare 的全球网络可以一定程度隐藏掉源 IP，对于访问受限的区域可有奇效 该方案对应的缺点如下：\n所有请求信息包括 API Key 都需经过 Cloudflare ，存在一定安全隐患 LMs-Gateway 扩展比较麻烦，目前提供的不支持内容检查过滤 上面两个厂商的产品，个人很难进行 demo 演示，而 Cloudflare 的 LMs-Gateway 服务又对于个人用户十分友好，因此本鲤以 LMs-Gateway 监控 MCP Server-Time 任务流过程的例子为引，简单演示下这类网关能够达到的效果，主要包含5个步骤：\n在 Cloudflare 平台创建 LMs-Gateway 实例，使用 API 作为 endpoint 连接到应用服务器，创建出口点，也即 baseURL\n在 vs code 中通过 cline 配置将大模型 API 站点都配置为从 API endpoint 访问\n在 cline 中调用一个 MCP Server：Time，简单执行一个任务，让流量流经 LMs-Gateway，下图以Time为例，简单查询了当前的北京时间\n在 LMs-Gateway 中 check 日志看看网关能捕获到什么内容。（通过请求响应的过程，其实可以对MCP请求响应的特点进行分析，这个内容本鲤目前在做，后面也要单开一篇讲）\n小结 整体而言，各家厂商发布的 AI-CFW 都呈现出以下共性：\n基本都以串接模式（网关or服务代理）接入，确保用户或局域网的访问都可纳入监管 内容合规的判断都借助 AI 赋能，参考某些内容审查标准实施 防护整体要么侧重供给侧业务保障要么关注用户侧隐私保护，并无完全独立的安全第三方（当然了，这样两头不讨好，既引入信任问题，也比较难盈利 串接尽管需要的条件强，但模式和管理都简单，优点明显，加密流量还原的难点可以一定程度绕过（真要旁路硬做加密解析，其实很头大\u0026hellip;），还原基于证书密钥应该可以基本解决；当然如果考虑旁路监听（Note：火山CLB本质还是串接）的话，火山的模式需要再深入\u0026hellip;\u0026hellip;\n通过上面的梳理，思路相对比较明确了：①串接部署：选择串接结构能够解决很多困难，包括覆盖度和流量还原问题，还原采取证书-密钥形式进行解决；管理形式最好是 Serverless，不需要对服务作过多管理。②内容合规审查：串接节点获取到还原的流量内容后，需要进一步关注流量的检查、处理和转发。重点是内容合规的标准和判断、优化方法，需要考虑多模态的复杂情况。\n4. 初步计划与设计 关于整体设计思路：\n①串接部署：串接结构选择能够解决很多困难，包括覆盖度和流量还原问题，还原思考证书-密钥形式进行解决；管理形式最好是 Serverless，不需要对服务作过多管理。 ②内容合规审查：串接节点获取到还原的流量内容后，需要进一步关注流量的检查、处理和转发，重点是内容合规的标准和判断、优化方法，需要考虑多模态的复杂情况。\n关于具体实施落地：\n①串接参考 Cloudflare 的 AI Gateway，基于证书-密钥进行流量还原。在转发和日志的基础上，需要增加检测、过滤或脱敏。（Cloudflare网关的实操上面已作示意，需要再调研如何基于证书-密钥进行流量还原（配置过程实际可以看出来了，本鲤后续跟进了Fiddler代理抓包的解密，这种形式应当可以借鉴），需要进一步调研跟进如何自建实现同类服务，以及在上面如何附加审查能力）\n②内容合规审查目前考虑加入 AI （内容理解、虚假检测支持），但只能本地微调（否则会迭代引入泄露）；另外需要基本的关键词匹配、敏感词表作基础匹配过滤的支撑；最后要考虑多模态数据的转换和统一读取问题。（基本是以文字为主，进一步要考虑doc文档、pdf文件、图片等样式数据如何读取和理解的问题\n关于分工和对口：本鲤统筹、推进\n①：全员（关键，决定思路能不能最终落地，注意这里是三个问题）\n②：AI 支撑（俊）、关键词\u0026amp;敏感词匹配（博）、多模态读取（杰）\n5. 具体设计方案介绍 下面为最终设计方案：AI-CFW集成到现有防火墙，需要用户信任证书，内容检测模块化插入。\n方案整体的设计思路是采用透明代理模式 -【基于证书密钥还原流量 + 模块化内容检测处理】，运行后流量加解密对用户无感，用户无序进行过多的修改（仅需信任根证书）。\n顶层设计：在网络防火墙处插入 AI-CFW，利用其网络边界防护天然优势，对网络进出流量集中监控过滤\n网络结构：目标网络采用接入-汇聚-核心的分层结构，理论可兼容大中小型组网\nA. 流量还原：基于自签名证书or内部CA签发 基于证书-密钥进行流量还原的思路包含自签名和内部自建CA签发两种具体实施方法，用自己颁发的证书密钥和用户建立加密连接可以避免流量还原的问题，并且用户只需要信任根证书，考虑性能、复杂性等因素，这种模式，相比直接利用代理工具构建中间代理有很大优势。\n上图是两种实施的流程，它们的核心步骤是基本一致的。\n自签名证书：防火墙生成自签名证书并安装，分发给用户设备并配置信任。用户设备发起HTTPS请求时，防火墙返回证书，建立加密连接后解密流量进行审查，再重新加密转发内部CA签发证书：防火墙向内部CA提交CSR，安装签发的证书。推送内部CA根证书给用户设备并配置信任，后续流程同自签名证书\n内部CA签发证书：防火墙向内部CA提交CSR，安装签发的证书。推送内部CA根证书给用户设备并配置信任，后续流程同自签名证书\nB. 内容处理：基于多模态处理+基础匹配+引入本地 AI 赋能 AI-CFW 整体划分为五个功能模块，流量加解密实际就是A部分流量还原的功能，中间三个模块依次负责多模态数据读取、基础匹配和AI赋能检测的任务，最右侧的处理与告警模块则实际嵌入到中间内容检查的处理周期中，管理员可在防火墙通知中查看反馈。\n多模态数据读取：处理文本、图片、文档等多类型据，支撑全面内容监控 关键词/敏感词匹配**（基础匹配）**：快速识别风险内容，为基础处理提供判断依据 AI-for 内容理解-恶意检测**（引入本地AI赋能）**：深度理解内容，检测复杂恶意信息，提升检测能力和过滤精准度 参考内容合规标准：《生成式人工智能服务暂行管理办法》中 5 大类 31 个小类规定 \u0026amp; 人类经验\n按照上述 AI-CFW 设计方案，理论上，能够很好地满足需求，并且能够针对多模态数据、复杂内容检测需求进行适应和处理，方案是相对完备的（from teacher，至于具体实现能到达什么效果，就事在人为了！\n简单logging下分工：由于本鲤对网络相对熟悉，整体方案的设计和组织汇总由我完成和把关；多模态的部分由杰完成；基础规则匹配由博负责；AI-for检测部分交由俊处理，本次设计整体是符合预期的。\n写在最后 本组方案考虑基于已有防火墙进行功能集成，本鲤认为这种模式相比基于Mitproxy代理等中间代理的模式要更好一些，简单、易用，用户可接受，也便于管理。实际上要真正用的话，只能尽量考量串接对流直接作处理，旁路模式更类似操作日志，飞走这条路可以 follow 下火山CLB旁路监听的实现模式。\n整体来说最后给出的这个方案只是比较完整和系统，完成了部署网络结构和整体框架的界定，至于具体的检测需求和目标明确，需要在各个模块特定的问题中界定和解决，比如对敏感内容的修改、优化，最基础的对文本模特检测的支撑等等。\nRefer：如有侵权，请联系删除 使用Cloudflare AI Gateway监控、控制和优化 AI 应用 - waka\u0026rsquo;s blog 大模型应用防火墙，发布！ 新赛道 | 启明星辰发布“大模型访问脱敏罩”，客户安心面对DeepSeek引爆的访问安全刚需 Cloudflare网关理解 + Cloudflare网关解读 上面埋了几个坑，简单记个账，不能吃霸王餐：\n关于WAF你需要知道什么？ 火山CLB旁路监听实现内容检测 用户和web服务间的流量传输处理过程概览 MCP请求-响应的特点 ","permalink":"https://lz0o0.github.io/zh/posts/affair-logs/ai%E5%86%85%E5%AE%B9%E9%98%B2%E7%81%AB%E5%A2%99/","summary":"2020年至今，AI 应用井喷式爆发，但AI 内容缺乏有效、可靠的技术监管机制。本项目意在实现一个 AI-CFW 原型系统，部署于 AI 应用和 AI 使用者之间，能够对\u003cstrong\u003e使用者的提问\u003c/strong\u003e以及 \u003cstrong\u003eAI 应用的回复内容\u003c/strong\u003e进行过滤。","title":"AI 内容防火墙"},{"content":"\r需求背景 ​\t家用摄像头作为一种基础视频监控设备，近年来在中国乃至全球范围内迅速普及，成为许多家庭不可或缺的安全工具。随着技术进步和消费者对家庭安全需求的增加，市场呈现智能化、线上化和品牌竞争加剧的趋势。然而，家用摄像头在使用过程中产生并记录海里的音频和视频数据，这些数据关乎广大用户群体的各种行为活动。\n​\t用户安装家用摄像头的动机体现在两个方面：一是实时关注家中老人、孩子或宠物的动态，二是防范盗窃或入室犯罪，保护财产安全。但是随着诸多家用摄像头数据泄露事件和隐患的揭露，其伴生的数据隐私与安全风险越发受到用户关注，成为当前网络安全的热点问题。\n​\t针对背景和需求，梳理了 5 部分内容，以下给出目录，具体细节不作展开，此需求来自相关部分，本文作记录复盘。\n报告内容 家用摄像头市场情况和趋势变化 市场普及的现状与驱动因素 技术进步的推动与产品演变 渠道变迁与线上化趋势 品牌竞争与市场格局 隐私安全挑战与应对 未来市场趋势 家用摄像头数据存储模式分析 SD卡存储：家庭监控的入门之选 DVR存储：模拟时代的过渡方案 NVR存储：家用监控的主流支柱 CVR存储 云存储 数据传输与用户访问模式 数据访问传输模式 涉及传输协议及其细节 加密与压缩算法 用户可控度与可靠性 小结 安全威胁与风险 数据安全威胁 主要风险来源 小结 问题与建议 用户与厂商安全意识薄弱 缓解措施与建议 调研总结 ​\t家用摄像头相关的数据安全问题集中在泄露、隐私侵犯和厂商漏洞，覆盖摄像头数据存储、传输和用户访问的整个过程。目前，家用摄像头的数据存储模式包括本地、云端和混合三种，本地存储隐私性强但容量有限，云存储便利却依赖厂商安全，混合模式灵活但成本较高。传输模式与访问方式是数据安全的关键环节。本地到用户的P2P模式延迟低但跨网受限，云模式支持远程访问却易受服务器攻击，混合模式兼顾两者但操作复杂。未来，随着5G和AI普及，设备功能将扩展至健康监测等新领域，智能家居市场的增长潜力巨大。而摄像头的安全属性和厂商的安全水平将会成为用户关注的核心问题。\n​\t总体而言，家用摄像头在提升生活便利的同时，其安全风险贯穿全链条。当前，技术漏洞与管理疏忽并存，用户与厂商责任需更好协调。未来，通过技术升级、用户教育和政策约束，行业有望实现便利与安全的双赢，智能安全的摄像头将成为家庭标配，数据保护也将成为品牌竞争的关键。\n","permalink":"https://lz0o0.github.io/zh/posts/affair-logs/%E5%AE%B6%E7%94%A8%E6%91%84%E5%83%8F%E5%A4%B4%E6%95%B0%E6%8D%AE%E5%AE%89%E5%85%A8%E5%88%86%E6%9E%90/","summary":"本文对目前国内主流家用摄像头的情况进行了梳理，分析了市场情况和发展趋势；着眼于数据安全，侧重分析了摄像头目前数据采集存储，以及传输的模式特点，旨在揭示家用摄像头中潜藏的数据安全问题和风险。","title":"家用摄像头数据安全分析"},{"content":"\r1. 问题描述 本地使用 Hugo 启动时，网站样式能够正常显示，但部署到 GitHub Pages 后，样式无法加载（如上图所示）。通过浏览器 F12 调试，控制台报错信息如下：\n1 Failed to find a valid digest in the \u0026#39;integrity\u0026#39; attribute for resource \u0026#39;https://lz0o0.github.io/assets/css/stylesheet.6da9a63d25a9608bca2f7f907a0，30e887a7dd3c3f3918e4cc113129361414bda.css\u0026#39; with computed SHA-256 integrity \u0026#39;9J1myq6eoP1D8h8p5xqNPihFF+13Dyqob6ASlTrTye8=\u0026#39;. The resource has been blocked. SRI和校验失败： Subresource Integrity (SRI) 是一种安全机制，用于确保在加载资源时，它们的内容与预期的哈希值一致。如果资源的实际哈希值与 HTML 文件中 integrity 属性定义的不一致，浏览器会阻止加载资源。\n2. 原因\u0026amp;解法 根据报错信息，大致确认问题是因为 SRI 校验时hash值不匹配，CSS加载失败，从而导致网页样式无法正常显示，无法看到多彩的网页。公网上主要的解释和解决办法，主要是以下三种：\n1. Cloudflare对 JS 和 CSS，默认执行\u0026quot;Auto Minify\u0026quot;，文件压缩后和 hugo 的处理存在冲突，导致校验失效；对应禁用选项，刷新缓存即可\r2. 修改 Hugo 的文件，禁用指纹校验选项。具体而言，在config.yaml或者hugo.yaml中添加以下代码\r1 2 3 params: assets: disableFingerprinting: true 3. 修改 html 文件索引入口，禁用 SRI 校验：将文件`(themes\\PaperMod\\layouts\\partials\\head.html)`中的 **integrity** 参数索引都置空`(integrity=\u0026quot;\u0026quot;)`\r方法①本鲤不知道在哪配置，没有实操。但我认为可能是压缩的问题，因为本地加载并未出现类似问题，不一致大概来自云端的处理 方法②比较合理，然而，本鲤实际配置后没什么效果，可能是 hugo 不内置该参数了 使用方法③，本鲤成功显示了CSS样式。大部分教程只提示改(integrity=\u0026quot;{{ $stylesheet.Data.Integrity }}\u0026quot;)，但我建议你把文件中所有的 integrity 参数索引都置空，因为另外一处索引时可能也会报错，因此建议都置空\nMind！ 可按照231的顺序，如能解决最好，前端的问题比较多样，本鲤发现甚至有因为LF和CRLF问题的（比较有用的讨论或文档，附在文末 3. 小结 本文描述了Hugo+Papermod部署到github pages时，由于SRI校验失败，导致CSS文件无法正常加载，不显示网页样式内容的问题。在文档中列举了三种主要的解决方法，并且分析了可能的问题（may优化导致校验失效）。博主实际通过修改配置的html索引，禁用 SRI 校验选项，解决了该问题\n如有意指点，或碰到问题，欢迎留言讨论~\nrefer https://swopnil.com/blog/valid-digest-integrity-error-hugo-styling/ https://github.com/alanorth/hugo-theme-bootstrap4-blog/issues/53 https://stackoverflow.com/questions/65040931/hugo-failed-to-find-a-valid-digest-in-the-integrity-attribute-for-resource ","permalink":"https://lz0o0.github.io/zh/posts/error-logs/hugo%E5%8F%91%E5%B8%83%E5%90%8E%E4%BB%85%E6%96%87%E6%9C%AC%E6%98%BE%E7%A4%BAcss%E6%97%A0%E6%B3%95%E5%8A%A0%E8%BD%BD/","summary":"本文分析并解决了Hugo+Papermod部署到github pages时，由于SRI校验失败，导致CSS文件无法正常加载不显示网页样式内容的问题。","title":"hugo发布css无法加载问题"},{"content":"背景 内网穿透：网络连接中的一种术语，也称作NAT（毕竟NAT导致了内外网的划分）穿透，是一种用在外网（相对局域网而言，包括公网和其它局域网）计算机访问局域网内计算机节点及其服务的通信连接技术。\n内网穿透依赖的核心原理是公私网地址的映射转换，转换结果就是NAT表项的建立。按照穿透结构来说，主要包含基于服务器数据中转的穿透（穿透内网穿透解法）和点对点穿透（UDP/TCP打洞）两种，两种方法的都需要中间服务器的参与，但后者只需作为集中服务器参与协商即可（两端安装工具，服务集中协商作为服务提供），而前者的压力较大。简单而言，就是A客户端要访问B客户端，通过一台服务器进行桥接，桥接有两种方式，一种是相互转发，另一个是告诉对方的地址，自己就当一个介绍人的角色。\n内网穿透传统方式会出现服务器和客户机之间的数据传输全部经过中转服务器，传输速度将受制于中转服务器的上下行带宽，不过稳定性很好，要求云主机带宽大。相比之下，点对点穿透能解决大流量带来的困扰，可以实现服务器和客户机之间打洞直接进行数据通信。然而，这种方式需要服务器和客户机都安装穿透工具，对用户访问端不够方便，而且这种方式受复杂网络环境影响较大，不能100%实现，稳定性欠缺。\n关于穿透原理分析，详情可参考：内网穿透原理分析\n内网穿透除了可能需要云主机外，还需要穿透工具协助，几款主流的工具包括frp（开源）、ngrok（开源）、zerotier（开源/商业）、花生壳（商业）、向日葵（远程桌面）、VPN（加密穿透）等等。就各自特点而言，商业款有专业团队维护，且使用简单方便，但数据包会流经第三方，因此数据安全是一大隐患。而对于个人有动手能力的用户或者中小型企业的小规模使用可以选择开源方式。\n综合软件配置复杂度、穿透能力等因素，个人觉得目前最好的选择就是 frp 用于对流量转发不大的场景，而需要大量 udp 传输的场景可以选择zerotier。\n需求来自UCAS课程，此处作记录复盘。本文演示基于 frp 的实现，也可参考：frp内网穿透\n基于 Frp 的内网穿透实现：以内网文件共享为例 1. frp 源码获取 git：https://github.com/fatedier/frp/releases 解压：tar -zxvf frp_0.61.2_linux_amd64.tar.gz\n文件中包含 frpc、frpc.toml；frps、frps.toml；以及LICENSE文件，分别对应客户端和服务端的配置项设置，可删去相对的内容\n2. 配置 frps 服务端设置项：中转服务器 frps.toml文件配置：这里的用户和密码主要用于登录frp访问面板 1 2 3 4 5 6 7 8 9 bindPort = 7000 webServer.addr = \u0026#34;0.0.0.0\u0026#34; webServer.port = 7500 webServer.user = \u0026#34;admin\u0026#34; webServer.password = \u0026#34;admin\u0026#34; auth.method=\u0026#34;token\u0026#34; auth.token = \u0026#34;passtoken\u0026#34; 配置后启动即可，成功会显示初始化日志：./frps -c frps.toml，随后可以访问公网IP：7500网站查看访问面板，这步相当于将公网服务器的7000端口和frp转发绑定，通过用户登录限制，限制了可以访问共享服务的公网节点。需要注意的是，在服务器，必须开启以下端口（6000和6001是为内网节点共享服务配置）：\n启动服务端之后，可以进入访问面板进行登录，并简单查看，当前绑定在7000端口：\n后台挂载进程 利用systemd启动后台进程挂载，创建文件：vim /etc/systemd/system/frps.service，文件内容如下(指定了访问面板的信息和绑定端口)：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [Unit] Description = frp server After = network.target syslog.target Wants = network.target [Service] Type=simple ExecStart = /dev-ops/frp/frps -c /dev-ops/frp/frps.toml ExecStop=/bin/kill $MAINPID Restart=always RestartSec=5 [Install] WantedBy = multi-user.target 文件创建成功后，启动即可：\n1 2 systemctl start frps systemctl status frps 3. 配置 frpc 客户端设置项：局域网节点 配置frpc.toml文件，向外网共享文件服务，向外网暴露什么服务由内网节点决定，因此上面服务端没有这部分配置 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 #你的云服务器公网ip serverAddr = \u0026#34;x.x.x.x\u0026#34; #连接到云服务器端口,需要和frps.toml配置文件中端口一致 serverPort = 7000 auth.method = \u0026#34;token\u0026#34; auth.token = \u0026#34;passtoken\u0026#34; #开放端口连接 [[proxies]] name = \u0026#34;test-tcp\u0026#34; type = \u0026#34;tcp\u0026#34; localIP = \u0026#34;127.0.0.1\u0026#34; localPort = 8080 remotePort = 6100 # 服务器需要开放该端口 #共享文件访问 [[proxies]] name = \u0026#34;d_drive\u0026#34; type = \u0026#34;tcp\u0026#34; remotePort = 6001 # 服务器上用于访问的端口，需要开放该端口 [proxies.plugin] type = \u0026#34;static_file\u0026#34; localPath = \u0026#34;D:\\\\\u0026#34; # 要对外暴露的目录（这里相当于向外网暴露文件服务） stripPrefix = \u0026#34;d_drive\u0026#34; # 访问路径名，此处即http://x.x.x.x:6001/d_drive/ httpUser = \u0026#34;username\u0026#34; # 用户名 httpPassword = \u0026#34;password\u0026#34; # 密码 4. 连接客户端与服务端 确保 frpc.exe 和 frpc.toml 位于同一目录。\n切换到 frpc.exe 所在目录：cd path\\to\\frp\n执行以下命令启动客户端：.\\frpc.exe -c frpc.toml\n执行命令启动服务端： .\\frps -c frps.toml\n两端连接可以访问frp面板访问内网的文件内容；此时再次访问服务面板，共享的服务映射更新\nurl访问共享的文件服务，此时可以看到局域网节点D盘符下的文件内容，支持访问下载\nFrp 流量分析 在局域网节点，采集 frp 连接访问过程中的流量，分析其连接、数据传输过程的特点，寻找可能的风险问题\nrefer 内网穿透详解 - cyrus0w - 博客园\u0026gt; frp内网穿透零基础详细教程-CSDN博客\u0026gt; frp内网穿透最新实践教程 从零开始详细步骤_哔哩哔哩_bilibili\u0026gt; [使用frp配置内网(穿透保姆级教程])_frp内网穿透-CSDN博客\u0026gt; ","permalink":"https://lz0o0.github.io/zh/posts/nice-techs/%E5%88%A9%E7%94%A8-frp-%E5%AE%9E%E7%8E%B0%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F/","summary":"frp 是一种反向代理工具, 被广泛用于内网穿透，能够将外网暴露内网服务，本文具体介绍了如何基于云服务器和frp源码实现简单的内网穿透，是一种很有意思和实际用处的技术。","title":"利用 frp 实现内网穿透"},{"content":"\r1. 前言(๑✦ˑ_✦) 前年用 BT+Wordpress+阿里轻量化服务器 搭了个网站，当时挺上头的\u0026hellip;\u0026hellip; 后来由于服务确实卡顿，偶尔容易出问题，加上服务器每月有开销，当时又忙着准备保研和毕设，慢慢就搁置了\u0026hellip;\n前段时间，我导提到说 数字人应该有数字人的意识，最好能将自己的一生都数字化，细想起来，感觉颇显浪漫！搞起来(▼O▼ﾒ)！\n花了清明两天的时间骨架建完，还是布到公网吧，希望能定期输出新内容\u0026hellip;\n2. 摘要 Okay，个人博客的搭建过程，整体来说可以分三个部分，后两个部分，仅推荐个别博文（步骤都差不多，没必要重复堆文字，难的从来都是根据需求自定义：\n明确建站框架和基本流程：hugo+git、hexo+git、bt+wordpress 内容设计与自定义调整：结构熟悉（hugo\u0026amp;theme、自定义修改（需求\u0026amp;设计 内容发布与部署：内容与数据维护、公网发布、F\u0026amp;R 博客的意义？搭建流程？核心需求？ 博客是一种不错的管理方法和输出形式。你完全可以使用博客来记录、组织自己零碎的知识、经验所得，甚至于你的心理感受；维护博客的过程，也能很好锻炼你的统筹能力，更好地组织你的所想、所学、所得；此外，博客很可能是分享和展示自己的一种不错媒介\u0026hellip; 搭建博客与搭建网站的过程类似，除了一个内容加工平台或工具用于生成、编辑输出内容外，你还需要一个内容托管平台帮助你托管内容、供人访问，可以自建也可以租赁，这里 github 的优势就凸显出来了 基于 wordpress 建站比较适合商业用户，需要性能不错的服务器、域名资源，缺点网站结构相对复杂，访问容易卡顿、维护持续消耗成本；个人写作、技术博客用户，关注美观和生态，推荐 hexo ；若看重速度和轻量化，那 hugo 当仁不让 3. Demo搭建/发布+基本自定义 Demo搭建/发布：基础概念（概念和文件解读，完全不懂的，想通透点就啃啃）、一部到位版（装修以前的部分Demo搞定了，后面想想自己的需求，再去逐渐增加满足）\n基础自定义：papermod主题配置，理解基本布局、内容索引管理方法\n高阶？：没有高阶，满足你的需求就是最好的，切忌什么都要，重要的从来是内容，需要什么自己再加就是\n写在最后 再次强调一点，我认为博客本质只是一种管理方法和输出形式，特别适合像本鲤这种三天两头想要梳理东西，然后定期整点儿输出，但却因为没有好好管理，事情又一茬接一茬，从而老感觉间歇性阵痛的人\n根据我的经验，你可以先试试基于一些简单的主题，比如stack/papermod去搭demo，然后再逐渐自定义，慢慢你有感觉、熟悉规律后知道怎么改了，你可以继续上点看起来“花里胡哨”的主题，刷新刷新认识。好看并不一定好，基本代价就是结构复杂，文件多，你花在上面的时间过多，本鲤就不想在维护上浪费世界（从上面demo图，其实本站最早用blowfish搭的，结构都基本定好了，后面觉得维护稍显麻烦，终是大道至简，简单归简单但自定义空间极大\n美化网站的过程不要迷失本来的目的，想清楚自己的需求，样式都应该为内容呈现服务，不要舍本逐末\n","permalink":"https://lz0o0.github.io/zh/posts/affair-logs/blog--%E7%AE%A1%E7%90%86-+-%E8%BE%93%E5%87%BA/","summary":"如何理解博客？博客构建的逻辑和步骤是怎样的？","title":"Blog == 管理 + 输出"},{"content":"音乐, 是对岁月与命运的吟唱与呐喊~\n","permalink":"https://lz0o0.github.io/zh/posts/life/songs/","summary":"听一些，我认为伟大的\u0026hellip;..音乐\u0026hellip;","title":"🎧 我的歌单Songs"},{"content":"\r简介\r动画\r9.7\r故事背景为日本的江户时代，风是一家小茶馆的侍女，这天茶馆里来了一群地方恶霸，其中地方官儿子龙次郎尤其欺人太甚。风因为意外得罪了龙次郎，情急之下，茶馆内一名无职浪人“无幻”出手救了风。\n另一方面，地方官正在欺压老百姓，流浪武士“仁”路见不平拔剑相助，杀死了地方官身边的四个“高手”保镖，救下了穷人，因此得罪了地方官。随后，无幻和仁在茶馆里相遇并交手，忽然一场大火将他们困住，二人随之被捕。因儿子在大火中丧生，恼羞成怒的地方官勒令将二人砍首。\n砍首之日二人大闹刑场，并且在风的帮助下，从刑场中逃出来了。作为代价，风要求他们一起去寻找一个身上“带着向日葵香味”的武士\u0026hellip;\n动画中弥漫着轻快、时髦、热血、自由的氛围，流零飘荡无处为根的人，在有虚幻的奔赴后，旅途变得诗意浪漫起来，洒脱、自在、英雄主义的气息扑面而来\u0026hellip;\r混沌武士\r小原信治【编剧】、渡边信一郎【导演】 ·2004\r简介\r漫画\r9.8\r故事发生在类似欧洲中世纪的世界，国与国之间互相争战，烽火连年，各国都豢养庞大军备，佣兵也成为时兴的行业，一般平民的生活则十分穷苦。在这战火连连的世界中，不单只有人类的战争，同时还有被称为“使徒”的怪物。\n本故事的主角格斯，其挚友格里菲斯把灵魂出卖给恶魔而变成了“使徒”之主——神之手，更是非人地把往日的战友佣兵团“鹰之团”作为祭品而给“使徒”虐杀。在这场虐杀中幸存下来的格斯，为了向格里菲斯复仇，化身成“黑色剑士”——一位受到诅咒，一直得抵抗着“使徒”追杀的烙印剑士\n剑风的世界中弥漫着阴郁、肃杀、血腥与绝望，但三浦笔下的格斯总是充满斗争与反抗精神，从幼时起的各种磨难，无不促成当前的格斯。\n不论身处何种境地，握住斩龙向命运挥砍，无路可退就只有向前冲杀，面对绝望与痛苦，剑风的世界里从来没有退缩二字。\n剑风传奇\r三浦建太郎 ·1989\r简介\r动画\r9.5\r故事描述一个有关“第二次冲击”的记事。 公元2000年有颗巨大的陨石坠落在南极冰山附近（政府宣称），高温造成部分冰块溶化，连带使得全球水位上涨，接下来的天灾人祸更是连绵不断，公元2015年又出现了新的入侵者，一种似人的巨大机械战斗群，人们将之称为”使徒”，大概是影射他们是上帝派来的使者，要来消灭作恶多端的人类吧。\n人类此刻的各种军事武器对使徒可说是毫无用处，为此，当时地球的政治中心决定重用NERV这个组织，他们以最精密的技术，花费巨资研究出一种以驾驶员的神经直接控制的”泛用人形决战兵器”，这种高科技产物将驾驶员与机器做了精细的契合，籍由意志及身体的反映来控制EVA。\n不过由于当时这些技术还在研发阶段，所以有许多障碍还无法立即克服。而且因为并不是每个人都能自由的驾驶EVA。驾驶人选一直是NERV最头疼的地方，除了符合条件的人难觅，而且还必须经过几个月训练才能和EVA达到同步活动的基本能力。\n而后，在世界上发现了3名可以驾驶EVA的少男少女，人们把希望都寄托在了他们身上。\nEVA给人的感觉因人而异，可能是致郁、扭曲，也可能是真实、平白，不论如何，因为 EVA 表达要借由的东西有些复杂而略微难懂（EVA 化用了很多宗教、哲学的意象讲自己的故事！），所以回忆起来会稍感空洞、干涩。\n心之壁、人类补完这些看起来复杂的词，仔细想想，作者可能就是是想教会那时候的年轻一代们学会悦纳真实、悦纳自己、在繁复隔绝的集体中寻找自我回归真实，走向新生。\nEVA吸引人的绝不只是血腥激烈的机甲互博、血肉横飞，尽管世界观是宏大的零散的，需要自己拼凑重建，但这些复杂的事情最终都聚焦到人性、孤独、爱与痛苦的哲学的探讨上，其中传达出的真实能让人感到极端的露骨更甚者释然，不论你如何感觉，事实就是这样，这就是某种程度的自我补完。\u0026quot;\n新世纪福音战士\r庵野秀明 ·1995\r","permalink":"https://lz0o0.github.io/zh/posts/life/artworks/","summary":"看一看，我觉得的好看的\u0026hellip;动画、漫画、电影、剧目","title":"📺 我喜欢的视画作品"}]