标签：网络安全

AI代码生成安全策略：内网隔离与私有化模型落地指南
AI代码生成进入企业应用后，安全成核心问题，使用AI快速生成代码已成为现实。但一个随之而来的问题也变得紧迫：生成的代码涉及商业逻辑、客户数据、技术架构，是否应该继续依赖云端模型，还是应该隔离到内网？ 内网隔离和私有化模型不是可有可无的功能，而是企业安全策略的重要组成。与其担心成本，不如从风险角度审视：一次泄露损失远大于长期的架构投资。

现在的问题不是”要不要用AI生成代码”，而是”如何安全地用AI生成代码”。 这不仅是技术问题，更是关乎企业安全战略的决策。本文基于实践经验，分享我的观察和思考。

为什么要重新审视AI代码生成的安全性？

在过去，代码是有形资产，保管在源代码库和服务器里。但AI改变了这一切：

1. 数据流动的不透明性

当你将代码片段发送给云端AI模型（如ChatGPT、Claude）来生成代码时：
- 代码被上传到第三方服务器
- 可能被用于模型训练（如果未关闭相关选项）
- 存储在云端的日志中
- 可能在隐私政策更新时被用于新的目的
风险：公司的业务逻辑、系统架构、API设计等敏感信息外泄。

2. 法规遵从的困境

不同国家和行业有不同的数据保护要求：
- 欧盟：GDPR对数据跨境传输有严格限制
- 中国：网络安全法、数据安全法要求重要数据本地存储
- 金融行业：更严格的信息安全要求
- 医疗行业：HIPAA等法规对患者数据保护
3. 竞争情报泄露

AI模型经过大规模数据训练，理论上可以记忆或推断输入数据模式。虽然开发者声称不会这样做，但：
- 技术上仍存在风险
- 合同条款可能变更
- 子公司可能有不同的政策
4. 供应链安全考虑

一旦依赖某个AI厂商，就引入了新的供应链风险：
- 服务可用性（宕机、限流）
- 价格变化
- 政策突变
- 地缘政治风险
现状对比：云端vs内网模型

云端模型（如ChatGPT、Claude）

优势：
- 能力最强，模型参数量大
- 无需本地计算资源
- 维护成本低
- 快速迭代，总是最新版本
劣势：
- 数据可能外泄
- 成本随使用量增加
- 依赖网络连接
- 无法自定义
- 法规遵从困难
私有化蒸馏模型（本地部署）

优势：
- 数据完全本地化，无外泄风险
- 符合各类法规要求
- 可离线运行
- 长期成本更低
- 可针对公司业务优化
劣势：
- 需要本地计算资源（特别是GPU）
- 模型能力较弱（通常比开源模型好，比闭源模型差）
- 需要技术团队维护
- 初期部署成本高
- 需要持续更新
我的建议方案：分层防御

基于安全性、成本与工程可实现性，推荐将AI代码生成方案分成三层，形成层级防护策略：

第一层：云端模型（开放区）

使用场景：
- 学习和探索性编程
- 公开技术讨论
- 通用工具代码（如数据处理函数）
- 非敏感算法实现
操作规范：
- 允许：通用函数、公开库调用、技术原理咨询
- 禁止：核心业务逻辑、API密钥、数据库连接字符串、客户数据、架构图
第二层：私有化蒸馏模型（内网区）

使用场景：
- 核心业务逻辑编码
- 敏感模块生成
- 涉及客户或企业数据的功能
- 系统架构与权限控制相关代码
第二层目标：数据在企业可控网络内流转，避免敏感信息进入公共云。

第三层：代码审查与合规控制

不论模型部署方式，都应强制执行：
1. 不直接上生产：AI生成代码需人工审核
2. 代码审查：资深工程师复核
3. 敏感词扫描：自动检测敏感字段（密钥、账号、IP等）
4. 依赖评估：验证第三方库安全性
5. 安全审计：定期检查模型调用日志与数据流
常见疑虑和解答

Q: 私有化模型的能力会不会太弱？

A: 这取决于选择。目前的开源模型在代码生成上已经相当不错。虽然不如最强的闭源模型，但对企业内部使用完全足够。关键是合适即可，不必最强。而且私有化模型可以微调，针对公司代码风格优化。

Q: 我们公司很小，负担不起模型的投入啊？

A: 有几个选择：
1. 使用开源模型，租用按小时计费的GPU
2. 多个公司共享一套私有化部署（虽然涉及信息共享）
3. 优先保护最敏感的部分，其他部分先用云端
4. 等待模型成本进一步下降（正在发生）
Q: 云端模型是否真的会泄露数据？

A: 根据公开信息：
- OpenAI、Anthropic都承诺不用对话来训练模型（可选中禁用）
- 但源代码中的数据依然被传输和储存
- 即使不主动泄露，也存在被黑客窃取、员工泄露等风险
- 风险永远存在于数据传输过程
Q: 团队不愿意放弃ChatGPT怎么办？

A: 这很正常。建议：
1. 明确禁止使用ChatGPT处理敏感代码（制度强制）
2. 为团队提供同样好用的内部替代品
3. 展示安全事件的案例（激励改变）
4. 渐进式迁移而不是一刀切
2026年3月23日
在 FortiGate 中配置 Spamhaus DROP 列表：实现恶意网段自动同步与拦截
通过 FortiGate 外部连接器 (External Connectors) 自动化集成 Spamhaus DROP 威胁情报。该方案通过 curl 与 jq 提取恶意 CIDR 网段，并利用防火墙的 Threat Feed 功能实现动态同步，旨在为企业边界安全提供一层自动化的“零误伤”过滤屏障。

一、环境准备：获取并整理 DROP 列表

Spamhaus 提供的 DROP (Don’t Route Or Peer) 列表包含了由恶意组织控制的网段。其原始格式为 JSON，需转换为 FortiGate 兼容的纯文本。

1. 原始格式预览
```
{"cidr":"1.10.16.0/20","sblid":"SBL256894","rir":"apnic"}
{"cidr":"1.19.0.0/16","sblid":"SBL434604","rir":"apnic"}
```
2. 数据提取脚本

在你的 Web 服务器（或中转服务器）上运行以下命令，提取 cidr 字段并生成纯文本：
```
# 下载、解析并保存为文本文件
curl -s https://www.spamhaus.org/drop/drop_v4.json | jq -r '.cidr' > spamhaus_drop.txt
```
注意：FortiGate 无法直接解析该 JSON 文件，因此必须通过上述步骤将其托管在内部或公网的 HTTP/HTTPS 服务器上。

二、 FortiGate 配置步骤

1. 创建外部连接器 (Threat Feed)
1. 登录 FortiGate，进入 Security Fabric > External Connectors。
2. 点击 Create New，在 Threat Feeds 类别下选择 IP Address。
3. 参数配置详情：
- Name: Spamhaus_DROP
- URL: http://yourserver.com/spamhaus_drop.txt
- Refresh Rate: 设置为 60 分钟（平衡实时性与服务器负载）。
2. 状态验证

保存配置后，在列表中观察连接器图标状态：
- 绿色箭头：连接正常。
- 红色感叹号：请检查 FortiGate 是否有权限访问该 URL，或 DNS 解析是否正常。
- 查看内容：右键点击连接器选择 View Entries，确认是否已成功拉取 IP 列表。
三、应用安全策略

获取列表后，必须将其应用到安全策略中才会生效。
1. 进入 Policy & Objects > Firewall Policy。
2. 创建一条新的拦截策略：
- Name: Deny_Spamhaus_Inbound
- Incoming Interface: WAN (外部接口)
- Source: 选择刚才创建的动态对象 Spamhaus_DROP
- Destination: All
- Service: ALL
- Action: DENY
1. 关键操作：在策略列表中，手动将该策略 移至顶端 (Top)。
提示：为了防范内网主机被感染后回连 C&C 服务器，建议额外创建一条 Source 为 Internal、Destination 为 Spamhaus_DROP 的拦截策略。

四、自动化更新

为了确保列表始终最新，建议在 Web 服务器上设置 Crontab 定时任务：
```
# 每小时自动更新一次列表
0 * * * * curl -s https://www.spamhaus.org/drop/drop_v4.json | jq -r '.cidr' > /var/www/html/spamhaus_drop.txt
```
2026年2月11日
使用 AbuseIPDB 与 FortiGate 打造全自动威胁情报拦截系统
通过FortiGate 的“外部连接器（External Connectors）”功能，实时联动 AbuseIPDB 威胁情报库。通过构造动态 API 请求，防火墙可自动获取并更新全球恶意 IP 黑名单，实现对攻击源的毫秒级自动封禁，有效提升企业边界安全。

准备工作
- 注册一个AbuseIPDB账户
- 在My API 栏目生成一个 API Key
- 设置 API 请求链接
构造如下格式的 URL：
```
https://api.abuseipdb.com/api/v2/blacklist?plaintext=true&confidenceMinimum=75&limit=131072&key=[YOUR API KEY HERE]
```
confidenceMinimum：黑名单中包含的最低滥用置信度分数（25-100），建议 ≥75，避免误报。

FortiGate 配置步骤

1. 创建外部连接器 (Threat Feed)
- 登录 FortiGate，进入 Security Fabric > External Connectors
- 点击 Create New，在 Threat Feeds 类别下选择 IP Address。
- 参数配置
  - Name: AbuseIPDB_IP_Blacklist
  - URL: 粘贴你在第一阶段构造好的 URL
  - Refresh Rate: 设置为 60 分钟（避免请求过于频繁导致 API 超限）
2. 验证连接

保存后，观察连接器图标：
- 绿色箭头：连接成功，已获取数据
- 红色/感叹号：检查 URL 是否正确，或防火墙是否有权限访问互联网
- 点击 View Entries：确认列表内已填充大量恶意 IP
3. 应用安全策略

获取到数据后，必须通过策略才能生效：
- 进入 Policy & Objects > Firewall Policy
- 创建拦截策略：
  - Incoming Interface: WAN (或外部接口)。
  - Source: 选择刚才创建的对象 AbuseIPDB_IP_Blacklist
  - Destination: All
  - Action: DENY
- 排序：将该策略移至顶端（Top），确保流量在匹配放行策略前先经过黑名单过滤。
2026年2月10日
网络安全事件响应策略与实践
网络攻击日益复杂和具有破坏性，传统的防御方式已无法应对。现代网络安全的核心理念是“入侵无可避免，但损失可以控制”，这意味着组织在面对安全事件时的响应速度和有效性至关重要，它直接影响业务连续性、财务稳定性和品牌声誉。因此，企业需要建立强大的网络安全事件响应能力，这就像企业的“免疫系统”，它依赖于周密的准备、精准的技术执行、跨部门的协作以及持续的改进，从而在面对不可避免的网络攻击时，最大限度地减少损失并迅速恢复核心业务，实现真正的网络韧性。

第一阶段：准备与识别

事件响应的成败，超过70%取决于事前的准备工作。一个准备充分的团队能在混乱中保持冷静，并有条不紊地执行预案。

基础准备工作：
1. 建立计算机安全事件响应团队（CSIRT）： 这是响应行动的核心。团队成员需具备明确的角色分工（如事件经理、安全分析师、取证调查员、网络工程师等），并拥有采取紧急措施的充分授权。一份包含主要和备用联系方式的最新名册至关重要。
2. 部署和维护核心工具：
  - SIEM（安全信息和事件管理）： 作为“大脑”，集中收集和关联全网日志，提供全局视野。
  - EDR（端点检测与响应）： 作为“神经末梢”，深入到每个端点，提供主机级别的威胁检测、调查和隔离能力。
  - NTA/NDR（网络流量分析/网络检测与响应）： 专注于实时监控网络流量，高效发现横向移动、C2通信和数据外泄等活动。
  - SOAR（安全编排、自动化与响应）： (适用于成熟团队) 自动化执行标准响应动作（如隔离主机、禁用账户），极大缩短响应时间（MTTR）。
  - 安全的带外通信： 建立独立于公司网络的通信渠道例如邮件/消息群组，确保在网络瘫痪时，响应团队仍能有效沟通。
3. 制定并演练特定场景手册： 针对高频高危威胁（如勒索软件、商业邮件欺诈）制定详细的、可执行的步骤清单。每年至少进行两次桌面推演或实战模拟，是确保预案有效性的唯一途径。
检测与分析：

检测阶段的目标是从海量告警中快速识别出真正的威胁。
- 监控关键的妥协指标（IoCs）： 分析师应超越常规告警，主动寻找更深层次的异常迹象，例如：
  - 网络层面：
    
    信标活动 (Beaconing): 监控那些以固定时间间隔向外部IP发起连接的网络活动，这是恶意软件与C2服务器保持联系的典型特征。
    
    DNS隧道 (DNS Tunneling): 警惕利用DNS查询来传递非DNS数据（如命令或窃取的数据）的异常行为。
  - 主机层面：
    
    就地取材二进制文件 (LOLBins) 的滥用: 监控系统自带程序（如 certutil.exe, wmic.exe）的异常调用，攻击者常利用它们来下载文件或逃避检测。
    
    WMI持久化: 监控通过Windows管理规范（WMI）创建的、用于持久化后门的恶意事件订阅。
- 从被动响应到主动狩猎 (Threat Hunting)： 除了被动地响应告警，成熟的团队应基于“假设性入侵”进行主动威胁狩猎。例如，提出假设：“假设攻击者已通过钓鱼邮件获取了某个员工的凭据”，然后主动审查VPN登录日志、云应用访问记录和内部服务器的认证失败日志，力求在攻击造成实际损害前发现威胁。
- 事件优先级排序： 并非所有事件都需要全员出动。一个清晰的优先级矩阵能帮助团队将有限的资源投入到最紧急的威胁上。P1级（危急）事件，如勒索软件爆发，必须触发立即的全员响应。
第二阶段：遏制、根除与恢复

这是事件响应的攻坚阶段，目标是控制损害、清除威胁并恢复业务。
- 遏制（Containment）： 首要任务是“止血”。除了隔离主机、禁用账户外，高级战术如 “动态遏制” 可将攻击者流量重定向至受控沙箱，在不影响生产环境的前提下，收集其攻击情报。
- 根除（Eradication）： 核心在于消除攻击的根本原因。
  - 系统根除： 最佳实践是：对于任何被深度入侵的系统，必须从已知的“安全镜像”进行重装，而非尝试手动“杀毒”。
  - 凭据根除： 这是最容易被忽略但至关重要的一步。在域环境被入侵后，必须两次重置KRBTGT账户密码，以彻底清除由“黄金票据”攻击创建的持久化域管理员权限。
- 恢复（Recovery）： 恢复业务并非简单地从备份中还原数据。
  - 标准流程： 首先修补导致入侵的漏洞，然后恢复数据，接着强制重置所有相关账户的凭据。
  - 数据完整性验证： 在系统重新上线前，必须验证恢复后数据的完整性，例如对数据库运行一致性检查，或对关键文件进行哈希值比对。
第三阶段：实战演练——勒索软件攻击响应详解

让我们以最常见的P1级事件——勒索软件攻击为例，详细拆解响应流程。

最初60分钟：检测与初步分析

当用户报告文件被加密或发现勒索信时，响应时钟立即启动。
1. 宣布事件并启动CSIRT： 事件经理通过安全的带外通信渠道发起紧急呼叫。
2. 隔离“零号病人”： 安全分析师在不关机的情况下，通过EDR或物理拔线的方式隔离最初发现的受感染主机，以保留内存中的易失性证据。
3. 确定感染范围： 通过SIEM和EDR联动，快速查找网络中其他有类似加密行为或与已知C2服务器通信的主机。
4. 保全证据与识别变种： 取证调查员对受感染主机进行内存镜像捕获。同时，威胁情报分析师利用勒索信或加密文件样本，通过ID Ransomware等在线服务识别勒索软件家族，为后续决策提供依据。
1-3小时：遏制
1. 创建网络“防火墙”： 如果攻击已在网络中蔓延，网络工程师需立即隔离受影响的VLAN，切断其与核心网络的连接。
2. 禁用被盗账户： 任何被发现用于横向移动的账户都必须立即被禁用。
3. 保护并验证备份： 备份管理员确认备份系统处于离线或物理隔离状态，并在沙箱环境中验证最近备份的完整性和可用性。
4. 启动沟通流程： 事件经理向管理层和法务部门进行初步案情通报。这不仅是沟通，更是关键的风险遏制步骤。
第1天及以后：根除与恢复
1. 赎金支付决策： 尽管官方建议是“不要支付赎金”，但这最终是一个由公司管理层在法务和网络保险公司建议下做出的商业决策。若决定支付，必须在隔离沙箱中测试解密器，并评估其效率。
2. 根除根本原因： 在恢复任何系统之前，必须通过取证分析找到并修补最初的入口点（例如，一个未打补丁的VPN设备）。
3. 系统重建与数据恢复： IT运营团队从“安全镜像”重建所有受影响的系统，随后由备份管理员从干净的备份中恢复数据。
4. 凭据重置与持续监控： 对全公司所有用户账户、服务账户、计算机账户、以及云环境中的API密钥进行强制密码重置。恢复的系统在隔离环境中接受24-48小时的严密监控，确认无异常后再上线。
第四阶段：跨职能协同

成功的事件响应远不止于技术操作。
- 对管理层的报告： 领导层不需要技术细节，他们需要的是对业务影响的清晰认知和对响应进度的信心。定期的、简洁的、以业务为中心的报告至关重要。MTTD（平均检测时间）和MTTR（平均响应时间）是衡量响应能力的核心指标。
- 法律与合规： 在事件初期就让法务顾问参与，并将所有沟通标记为特权信息。同时，严格遵守网络保险的报案时限。在数据泄露的情况下，法律团队将指导如何遵守法规的强制性通知要求。
第五阶段：事件后活动

事件的结束是下一次防御的开始。
- 进行无指责的事后复盘： 会议的目的是优化流程，而非追究个人责任。
- 更新迭代手册： 将复盘中得到的经验教训，为相关流程的更新。
- 推动环境加固： 将发现的安全短板转化为可跟踪的改进任务。具体技术建议包括：
  - 出口流量过滤 (Egress Filtering): 实施严格的出站防火墙策略，阻止恶意软件连接C2服务器。
  - 部署欺骗技术 (Deception Technology): 部署蜜罐、蜜罐令牌等作为高保真度的入侵“绊线”。
  - 强化备份策略： 采用 3-2-1备份规则（3份副本，2种不同介质，1份异地存储）并启用不可变备份（Immutable Backups），防止备份被加密或删除。
2025年6月30日

使用 Docker 部署 Greenbone Community Edition（GCE）：打造你的本地漏洞扫描平台

一、GCE 简介

Greenbone Community Edition（GCE） 是由 Greenbone Networks 维护的开源安全漏洞扫描解决方案，基于知名的 OpenVAS（Open Vulnerability Assessment System） 项目构建。它包括：

GSA（Greenbone Security Assistant）：图形化 Web 管理界面；
GVMD：扫描调度与管理守护进程；
OpenVAS Scanner：扫描引擎；
Greenbone Community Feed：开源漏洞数据库（每日更新）；
GVM-Tools：命令行工具，支持远程自动化控制。

GCE 是企业级 Greenbone GSM 产品的免费替代方案，非常适合中小企业、个人研究人员、DevSecOps 团队部署。

二、安装Docker

$ curl -fsSL https://get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh

三、部署Greenbone Community Edition（GCE）

保存 docker-compose.yml 文件
运行以下命令启动服务：

docker compose up -d

容器启动后，访问 Web 管理界面：

http://<服务器IP>:9392
登录默认管理员账户/密码：admin

首次启动可能需要等待几分钟，用于加载漏洞数据库、初始化服务。

name: greenbone-community-edition

services:
  vulnerability-tests:
    image: registry.community.greenbone.net/community/vulnerability-tests
    environment:
      FEED_RELEASE: "24.10"
    volumes:
      - vt_data_vol:/mnt

  notus-data:
    image: registry.community.greenbone.net/community/notus-data
    volumes:
      - notus_data_vol:/mnt

  scap-data:
    image: registry.community.greenbone.net/community/scap-data
    volumes:
      - scap_data_vol:/mnt

  cert-bund-data:
    image: registry.community.greenbone.net/community/cert-bund-data
    volumes:
      - cert_data_vol:/mnt

  dfn-cert-data:
    image: registry.community.greenbone.net/community/dfn-cert-data
    volumes:
      - cert_data_vol:/mnt
    depends_on:
      - cert-bund-data

  data-objects:
    image: registry.community.greenbone.net/community/data-objects
    environment:
      FEED_RELEASE: "24.10"
    volumes:
      - data_objects_vol:/mnt

  report-formats:
    image: registry.community.greenbone.net/community/report-formats
    environment:
      FEED_RELEASE: "24.10"
    volumes:
      - data_objects_vol:/mnt
    depends_on:
      - data-objects

  gpg-data:
    image: registry.community.greenbone.net/community/gpg-data
    volumes:
      - gpg_data_vol:/mnt

  redis-server:
    image: registry.community.greenbone.net/community/redis-server
    restart: on-failure
    volumes:
      - redis_socket_vol:/run/redis/

  pg-gvm:
    image: registry.community.greenbone.net/community/pg-gvm:stable
    restart: on-failure
    volumes:
      - psql_data_vol:/var/lib/postgresql
      - psql_socket_vol:/var/run/postgresql

  gvmd:
    image: registry.community.greenbone.net/community/gvmd:stable
    restart: on-failure
    volumes:
      - gvmd_data_vol:/var/lib/gvm
      - scap_data_vol:/var/lib/gvm/scap-data/
      - cert_data_vol:/var/lib/gvm/cert-data
      - data_objects_vol:/var/lib/gvm/data-objects/gvmd
      - vt_data_vol:/var/lib/openvas/plugins
      - psql_data_vol:/var/lib/postgresql
      - gvmd_socket_vol:/run/gvmd
      - ospd_openvas_socket_vol:/run/ospd
      - psql_socket_vol:/var/run/postgresql
    depends_on:
      pg-gvm:
        condition: service_started
      scap-data:
        condition: service_completed_successfully
      cert-bund-data:
        condition: service_completed_successfully
      dfn-cert-data:
        condition: service_completed_successfully
      data-objects:
        condition: service_completed_successfully
      report-formats:
        condition: service_completed_successfully

  gsa:
    image: registry.community.greenbone.net/community/gsa:stable
    restart: on-failure
    ports:
      - 9392:80
    volumes:
      - gvmd_socket_vol:/run/gvmd
    depends_on:
      - gvmd
  # Sets log level of openvas to the set LOG_LEVEL within the env
  # and changes log output to /var/log/openvas instead /var/log/gvm
  # to reduce likelyhood of unwanted log interferences
  configure-openvas:
    image: registry.community.greenbone.net/community/openvas-scanner:stable
    volumes:
      - openvas_data_vol:/mnt
      - openvas_log_data_vol:/var/log/openvas
    command:
      - /bin/sh
      - -c
      - |
        printf "table_driven_lsc = yes\nopenvasd_server = http://openvasd:80\n" > /mnt/openvas.conf
        sed "s/127/128/" /etc/openvas/openvas_log.conf | sed 's/gvm/openvas/' > /mnt/openvas_log.conf
        chmod 644 /mnt/openvas.conf
        chmod 644 /mnt/openvas_log.conf
        touch /var/log/openvas/openvas.log
        chmod 666 /var/log/openvas/openvas.log

  # shows logs of openvas
  openvas:
    image: registry.community.greenbone.net/community/openvas-scanner:stable
    restart: on-failure
    volumes:
      - openvas_data_vol:/etc/openvas
      - openvas_log_data_vol:/var/log/openvas
    command:
      - /bin/sh
      - -c
      - |
        cat /etc/openvas/openvas.conf
        tail -f /var/log/openvas/openvas.log
    depends_on:
      configure-openvas:
        condition: service_completed_successfully

  openvasd:
    image: registry.community.greenbone.net/community/openvas-scanner:stable
    restart: on-failure
    environment:
      # `service_notus` is set to disable everything but notus,
      # if you want to utilize openvasd directly, remove `OPENVASD_MODE`
      OPENVASD_MODE: service_notus
      GNUPGHOME: /etc/openvas/gnupg
      LISTENING: 0.0.0.0:80
    volumes:
      - openvas_data_vol:/etc/openvas
      - openvas_log_data_vol:/var/log/openvas
      - gpg_data_vol:/etc/openvas/gnupg
      - notus_data_vol:/var/lib/notus
    # enable port forwarding when you want to use the http api from your host machine
    # ports:
    #   - 127.0.0.1:3000:80
    depends_on:
      vulnerability-tests:
        condition: service_completed_successfully
      configure-openvas:
        condition: service_completed_successfully
      gpg-data:
        condition: service_completed_successfully
    networks:
      default:
        aliases:
          - openvasd

  ospd-openvas:
    image: registry.community.greenbone.net/community/ospd-openvas:stable
    restart: on-failure
    hostname: ospd-openvas.local
    cap_add:
      - NET_ADMIN # for capturing packages in promiscuous mode
      - NET_RAW # for raw sockets e.g. used for the boreas alive detection
    security_opt:
      - seccomp=unconfined
      - apparmor=unconfined
    command:
      [
        "ospd-openvas",
        "-f",
        "--config",
        "/etc/gvm/ospd-openvas.conf",
        "--notus-feed-dir",
        "/var/lib/notus/advisories",
        "-m",
        "666",
      ]
    volumes:
      - gpg_data_vol:/etc/openvas/gnupg
      - vt_data_vol:/var/lib/openvas/plugins
      - notus_data_vol:/var/lib/notus
      - ospd_openvas_socket_vol:/run/ospd
      - redis_socket_vol:/run/redis/
      - openvas_data_vol:/etc/openvas/
      - openvas_log_data_vol:/var/log/openvas
    depends_on:
      redis-server:
        condition: service_started
      gpg-data:
        condition: service_completed_successfully
      vulnerability-tests:
        condition: service_completed_successfully
      configure-openvas:
        condition: service_completed_successfully

  gvm-tools:
    image: registry.community.greenbone.net/community/gvm-tools
    volumes:
      - gvmd_socket_vol:/run/gvmd
      - ospd_openvas_socket_vol:/run/ospd
    depends_on:
      - gvmd
      - ospd-openvas

volumes:
  gpg_data_vol:
  scap_data_vol:
  cert_data_vol:
  data_objects_vol:
  gvmd_data_vol:
  psql_data_vol:
  vt_data_vol:
  notus_data_vol:
  psql_socket_vol:
  gvmd_socket_vol:
  ospd_openvas_socket_vol:
  redis_socket_vol:
  openvas_data_vol:
  openvas_log_data_vol:

2025年5月26日

tcpdump 在网络运维和网络安全场景下的使用
tcpdump 是一个强大的命令行数据包分析工具，常用于网络运维和网络安全领域。它允许你捕获并检查网络流量，帮助诊断问题、识别潜在的安全威胁以及进行性能分析。
- 数据包 (Packet): 网络传输的基本单位，包含源地址、目标地址、协议类型等信息。
- 抓包 (Packet Capture): 使用工具（如 tcpdump）捕获并存储网络流量的数据包。
- 过滤 (Filtering): 指定要捕获的数据包的条件，只捕获符合条件的流量，减少数据量和分析工作量。
1. 网络运维场景
- 故障排除:
  - 连接问题: 诊断网络连接失败的原因，例如无法访问远程服务器、服务中断等。通过捕获连接建立（三次握手）过程中的数据包，可以判断是客户端、服务器端还是网络中间环节的问题。
  - 性能问题: 分析网络延迟、丢包等性能问题。通过观察数据包的往返时间、序列号和确认号，可以判断是否存在网络拥塞、设备故障等。
  - 路由问题: 跟踪数据包的传输路径，验证路由配置是否正确。
  - DNS 问题: 检查 DNS 查询和响应过程，诊断域名解析失败的原因。
  - DHCP 问题: 监控 DHCP 发现、提供、请求和确认过程，排查 IP 地址分配问题。
- 网络监控:
  - 流量分析: 捕获特定协议、端口或主机的数据包，分析网络流量模式和带宽使用情况。
  - 服务验证: 验证网络服务的可用性和正确性，例如 Web 服务、邮件服务等。
  - 协议分析: 深入了解各种网络协议的工作原理，例如 TCP、UDP、ICMP、HTTP 等。
2. 网络安全场景
- 入侵检测:
  - 异常流量识别: 捕获可疑的网络流量，例如端口扫描、恶意代码传播、未经授权的访问等。
  - 攻击行为分析: 分析攻击者利用的协议和技术，例如 SYN Flood 攻击、DDoS 攻击、SQL 注入等。
  - 后门检测: 发现潜在的后门程序或恶意连接。
- 安全审计:
  - 网络活动记录: 捕获关键的网络通信数据，用于安全事件的调查和审计。
  - 策略合规性检查: 验证网络安全策略的实施情况，例如防火墙规则、访问控制列表等。
- 漏洞分析:
  - 协议漏洞利用: 分析网络协议的实现细节，发现潜在的漏洞。
  - 渗透测试: 在渗透测试过程中捕获网络流量，验证安全漏洞的可利用性。
- 恶意软件分析:
  - C&C 通信分析: 捕获恶意软件与控制服务器之间的通信数据，了解恶意软件的行为和目的。
  - 数据泄露分析: 监控网络流量，发现敏感数据的泄露行为。
案例：

案例 1: 诊断 Web 服务器响应缓慢

场景: 用户报告访问你的 Web 服务器 (IP 地址: 192.168.1.10, 监听端口 80 和 443) 时页面加载缓慢。你需要分析网络层面是否存在瓶颈。

说明: 在 Web 服务器上捕获与客户端的 TCP 流量，观察 TCP 交互过程、包的大小、延迟等，判断是网络延迟、丢包还是服务器处理慢。

命令 (在 Web 服务器上执行):
```
sudo tcpdump -i eth0 tcp and port 80 or port 443 -s 1500 -v -x -XX -ttt -w web_slow.pcap
```
说明:
- sudo: 以管理员权限运行。
- -i eth0: 指定监听的网络接口。
- tcp and port 80 or port 443: 仅捕获 TCP 协议且源或目标端口为 80 或 443 的数据包 (HTTP/HTTPS)。
- -s 1500: 设置抓包时每个数据包捕获的最大长度为 1500 字节，确保捕获完整的 TCP/IP 头部和大部分应用层数据。
- -v: 输出更详细的信息 (verbose)，例如 TTL、标识、序列号等。
- -x: 以十六进制格式显示每个数据包的内容。
- -XX: 以十六进制和 ASCII 格式显示每个数据包的内容，方便查看应用层数据。
- -ttt: 显示更详细的时间戳，包含日期和微秒级精度，有助于精确计算延迟。
- -w web_slow.pcap: 将捕获的数据包保存到 web_slow.pcap 文件，方便后续使用 Wireshark 等图形化工具进行分析。
分析 (使用 Wireshark 或 tcpdump -r web_slow.pcap):
1. 观察 TCP 三次握手: 确认连接建立是否正常，是否存在延迟。
2. 分析 TCP 窗口大小和流量控制: 观察窗口大小是否过小导致数据传输受限。
3. 检查重传 (Retransmissions) 和重复确认 (Duplicate ACKs): 这可能表明存在丢包或网络拥塞。
4. 分析数据包大小和传输速率: 是否存在大量小包导致 overhead 过高，或者传输速率过慢。
5. 使用 Wireshark 的 “Follow TCP Stream” 功能: 查看完整的 HTTP 请求和响应，分析响应时间。
6. 计算 Round-Trip Time (RTT): 观察数据包发送和确认之间的时间差，判断网络延迟。
案例 2: 排查内部服务间的通信故障

场景: 内部应用 A (IP: 10.0.1.10, 端口 9000) 无法连接到内部应用 B (IP: 10.0.1.20, 端口 9001)。你需要诊断网络层面是否存在问题。

说明: 在应用 A 和应用 B 所在的服务器上分别捕获这两个 IP 和端口之间的 TCP 流量，观察连接尝试和响应情况。

命令 (在应用 A 的服务器上执行):
```
sudo tcpdump -i eth0 tcp and host 10.0.1.10 and host 10.0.1.20 and port 9000 and port 9001 -v -n
```
命令 (在应用 B 的服务器上执行):
```
sudo tcpdump -i eth0 tcp and host 10.0.1.10 and host 10.0.1.20 and port 9000 and port 9001 -v -n
```
说明:
- -n: 不进行主机名和端口名解析，直接显示 IP 地址和端口号，更清晰。
- 其他参数与案例 1 类似，但这里没有保存到文件，可以直接在终端观察。
分析 (在终端观察或使用 Wireshark 分析保存的文件):
1. 在应用 A 的服务器上: 是否看到 SYN 包发送到 10.0.1.20:9001？
2. 在应用 B 的服务器上: 是否收到来自 10.0.1.10:9000 的 SYN 包？
3. 如果应用 B 收到了 SYN 但没有回复 SYN-ACK: 可能是应用 B 服务未运行、防火墙阻止了入站连接。
4. 如果应用 A 发送了 SYN 但没有收到 SYN-ACK: 可能是网络中间设备阻止了连接、应用 B 服务未运行或防火墙阻止了出站连接。
5. 观察 RST (Reset) 包: 如果看到 RST 包，表示连接被强制关闭，需要进一步分析原因。
案例 3: 分析潜在的 SQL 注入攻击

场景: 你的 Web 服务器 (IP: 192.168.1.10, 端口 80) 接收到可疑的 HTTP 请求，你怀疑可能存在 SQL 注入攻击。

说明: 捕获与 Web 服务器的 HTTP 流量，并分析 POST 请求的内容，查找可能包含恶意 SQL 语句的特征。

命令 (在 Web 服务器上执行):
```
sudo tcpdump -i eth0 tcp and port 80 -s 200 -A | grep -E 'SELECT.*FROM|INSERT.*INTO|UPDATE.*SET|DELETE.*FROM|UNION.*SELECT'
```
说明:
- -s 200: 捕获每个数据包的前 200 字节，通常足以包含 HTTP 请求头部和部分 POST 数据。
- -A: 以 ASCII 格式显示数据包内容。
- grep -E '...': 使用正则表达式过滤包含常见 SQL 关键字的 HTTP 请求内容。
分析 (查看 grep 的输出):
1. 检查匹配到的行: 是否在 HTTP POST 请求的数据中看到类似 SELECT * FROM users WHERE username='evil' OR 1=1; 或 INSERT INTO ... VALUES ... 等可疑的 SQL 语句？
2. 分析请求的 URI 和参数: 是否有异常的参数名或参数值？
3. 结合 Web 服务器日志: 关联分析该请求发生时的服务器行为和错误信息。
更精细的过滤可以使用 tshark (Wireshark 的命令行工具) 进行更复杂的 HTTP 内容过滤。

案例 4: 检测和分析恶意软件的 DNS 查询行为

场景: 你怀疑内部某台主机 (IP: 192.168.1.50) 可能感染了恶意软件，它可能尝试解析恶意的域名进行 C2 通信或下载恶意载荷。

说明: 捕获该主机发送的 DNS 查询请求，并分析查询的域名是否属于已知的恶意域名列表或具有异常特征。

命令 (在网络边界防火墙或内部 DNS 服务器上执行):
```
sudo tcpdump -i eth0 udp and port 53 and src host 192.168.1.50 -vv -n | grep -E '.(ru|cn|top|xyz)$'
```
说明:
- udp and port 53: 仅捕获 UDP 协议的 DNS 流量。
- src host 192.168.1.50: 仅捕获源 IP 为可疑主机的 DNS 查询。
- -vv: 输出更详细的 DNS 查询信息。
- -n: 不进行主机名解析。
- grep -E '.(ru|cn|top|xyz)$': 使用正则表达式过滤查询的域名是否以某些常见的恶意域名后缀结尾 (这只是一个示例，需要根据实际威胁情报更新)。
分析 (查看 grep 的输出):
1. 检查匹配到的域名: 是否包含已知的恶意域名或具有可疑特征 (例如，随机字符组成的子域名)？
2. 分析查询频率: 是否在短时间内发送了大量不同的 DNS 查询？
3. 结合威胁情报: 将捕获到的域名与已知的恶意域名列表进行比对。
案例 5: 调查 DDoS 攻击的源头

场景: 你的 Web 服务器 (IP: 192.168.1.10) 遭受 DDoS 攻击，你需要捕获攻击流量并分析攻击源和攻击类型。

说明: 在 Web 服务器的入口网关或服务器自身捕获流量，分析源 IP 地址、协议类型、目标端口等特征。

命令 (在 Web 服务器或入口网关上执行):
```
sudo tcpdump -i eth0 -n -nn dst host 192.168.1.10 -c 10000 | awk '{print $1}' | sort | uniq -c | sort -nr | head -20
```
说明:
- dst host 192.168.1.10: 仅捕获目标 IP 为 Web 服务器的流量。
- -c 10000: 捕获 10000 个数据包 (根据实际情况调整)。
- awk '{print $1}': 提取源 IP 地址。
- sort: 对源 IP 地址进行排序。
- uniq -c: 统计每个源 IP 地址出现的次数。
- sort -nr: 按出现次数降序排序。
- head -20: 显示出现次数最多的前 20 个源 IP 地址。
分析 (查看 head 的输出):
1. 识别攻击源: 出现次数最多的源 IP 地址很可能是攻击源。
2. 分析攻击类型:
- 大量 SYN 包: 可能是 SYN Flood 攻击。使用 tcpdump -i eth0 -n -nn dst host 192.168.1.10 and tcp[13] == 2 -c 100 分析。
- 大量 GET/POST 请求: 可能是 HTTP Flood 攻击。使用 sudo tcpdump -i eth0 -n -nn dst host 192.168.1.10 and tcp port 80 -A -c 100 分析 HTTP 内容。
- 大量 UDP 包: 可能是 UDP Flood 攻击。使用 sudo tcpdump -i eth0 -n -nn dst host 192.168.1.10 and udp -c 100 分析。
- 源 IP 地址是否分散: 分布式 DDoS 攻击的源 IP 地址会比较分散。
2025年4月8日

标签： 网络安全

AI代码生成安全策略：内网隔离与私有化模型落地指南

为什么要重新审视AI代码生成的安全性？

1. 数据流动的不透明性

2. 法规遵从的困境

3. 竞争情报泄露

4. 供应链安全考虑

现状对比：云端vs内网模型

云端模型（如ChatGPT、Claude）

私有化蒸馏模型（本地部署）

我的建议方案：分层防御

第一层：云端模型（开放区）

第二层：私有化蒸馏模型（内网区）

第三层：代码审查与合规控制

常见疑虑和解答

在 FortiGate 中配置 Spamhaus DROP 列表：实现恶意网段自动同步与拦截

一、 环境准备：获取并整理 DROP 列表

1. 原始格式预览

2. 数据提取脚本

二、 FortiGate 配置步骤

1. 创建外部连接器 (Threat Feed)

2. 状态验证

三、 应用安全策略

四、 自动化更新

使用 AbuseIPDB 与 FortiGate 打造全自动威胁情报拦截系统

准备工作

FortiGate 配置步骤

1. 创建外部连接器 (Threat Feed)

2. 验证连接

3. 应用安全策略

网络安全事件响应策略与实践

第一阶段：准备与识别

基础准备工作：

检测与分析：

第二阶段：遏制、根除与恢复

第三阶段：实战演练——勒索软件攻击响应详解

最初60分钟：检测与初步分析

1-3小时：遏制

第1天及以后：根除与恢复

第四阶段：跨职能协同

第五阶段：事件后活动

使用 Docker 部署 Greenbone Community Edition（GCE）：打造你的本地漏洞扫描平台

一、GCE 简介

二、安装Docker

三、部署Greenbone Community Edition（GCE）

tcpdump 在网络运维和网络安全场景下的使用

1. 网络运维场景

2. 网络安全场景

案例：

案例 1: 诊断 Web 服务器响应缓慢

案例 2: 排查内部服务间的通信故障

案例 3: 分析潜在的 SQL 注入攻击

案例 4: 检测和分析恶意软件的 DNS 查询行为

案例 5: 调查 DDoS 攻击的源头

标签：网络安全

一、环境准备：获取并整理 DROP 列表

三、应用安全策略

四、自动化更新