stratosphereips/zeek_anomaly_detector

# zeek_anomaly_detector [](https://github.com/stratosphereips/zeek_anomaly_detector/actions/workflows/docker-image.yml) [](https://github.com/stratosphereips/zeek_anomaly_detector/actions/workflows/python-checks.yml)   一个用于 Zeek 日志的异常检测器。它支持经典的 Zeek TSV 日志和行分隔的 Zeek JSON 日志，可以处理单个日志文件或日志目录，并根据日志类型应用不同的异常检测策略。 这不再是一个仅针对 `conn.log` 的 PCA 脚本。当前的实现包括以下所有功能： - 读取 `conn.log`、`http.log`、`files.log`、`ssh.log`、`weird.log`、`notice.log`、`known_services.log`、`known_hosts.log`、`software.log`、`arp.log`、`stats.log`、`capture_loss.log`、`packet_filter.log`、`loaded_scripts.log` 以及任何其他符合支持 Schema 的 Zeek 日志。 - 自动检测输入格式是 Zeek TSV 还是 Zeek JSON。 - 使用一条命令处理目录下的所有 `.log` 文件。 - 利用 `uid` 和 `fuid` 构建跨日志的共享上下文。 - 针对每种日志类型选择检测器，而不是在所有 Schema 上强制使用同一模型。 - 在针对目录运行时，最后计算目录级别的恶意评分。 ## 设计变更的原因 不同的 Zeek 日志代表不同类型的证据： - `conn.log` 面向流量，适合多变量异常检测。 - `http.log` 和 `files.log` 包含应用和内容元数据，有助于发现扫描、滥用和异常传输。 - `ssh.log` 虽然稀疏，但在对客户端/服务器 Banner 稀有度和跨日志上下文进行建模时仍然有用。 - `weird.log` 和 `notice.log` 本身就类似于事件，通过稀有度排序和优先级处理比使用通用 PCA 模型效果更好。 - `known_hosts.log`、`known_services.log` 和 `software.log` 是清单/状态日志。它们对于新颖性检测很有用，但不适合经典的流量离群点检测。 - `stats.log` 和 `capture_loss.log` 属于时间序列/系统遥测数据，应作为随时间的偏差进行评分，而不是作为独立的流量记录。 在所有日志上使用一个全局模型会产生糟糕的结果和不稳定的行为。当前的实现利用了每种 Zeek 日志类型的结构。 ## 工作原理 ### 1. 输入处理 该工具接受： - 使用 `-f` 指定单个文件 - 使用 `-d` 指定目录 对于每个文件，它会： - 自动检测 Zeek TSV 或行分隔 JSON - 将日志加载到 Pandas dataframe 中 - 保留原始 Zeek 字段用于显示 - 与原始日志字段分开，单独构建特定于检测器的数值特征 ### 2. 利用 `uid` 和 `fuid` 进行跨日志关联 检测器不仅仅单独对每条日志进行评分。它首先加载目录中的所有日志并构建共享上下文。 #### `uid` `uid` 是主要的 Zeek 事务标识符，用于将跨日志的相关活动联系起来，例如： - `conn.log` - `http.log` - `files.log` - `ssh.log` - `weird.log` 该工具聚合每个 `uid` 的上下文，例如： - 每种日志类型中的相关记录数 - 来自 `conn.log` 的相关连接字节、数据包、持续时间和状态稀有度 - 来自 `http.log` 的相关 HTTP 计数、主体大小和状态稀有度 - 来自 `files.log` 的相关文件计数、总字节数和 MIME 稀有度 - 来自 `weird.log` 的相关 weird-event 计数和 weird-name 稀有度 - 来自 `ssh.log` 的相关 SSH 计数和认证尝试 这些聚合值随后被注入回每条日志的特征向量中。 这很重要，因为如果满足以下条件，在一条日志中看起来仅轻微异常的记录可能会变得更加可疑： - 同一个 `uid` 也触发了 weird 事件 - 同一个 `uid` 下载了一个稀有文件 - 同一个 `uid` 具有异常的 HTTP 状态模式 - 同一个 `uid` 关联到高字节或异常的 `conn.log` 流 #### `fuid` `fuid` 是 Zeek 文件标识符，用于将文件活动跨日志关联起来。当前的实现主要使用它利用 `files.log` 中的文件上下文来丰富 `http.log`，包括： - 关联的文件计数 - 关联的文件总字节数 - 关联的 MIME 稀有度 - 关联的文件来源稀有度 当 HTTP 请求因其传递的内容而不仅仅是请求元数据本身显得可疑时，这非常有用。 ### 3. 按日志类型选择检测器 该实现使用三个检测器家族： - 针对丰富多变量日志的 `IsolationForest` - 针对事件/清单日志的稀有度评分 - 针对遥测日志的时间序列偏差评分 如果未安装 `scikit-learn`，`IsolationForest` 路径将回退到标准化距离评分，而不是崩溃。 ### 4. 目录级别恶意评分 当您使用 `-d` 在 Zeek 目录上运行该工具时，它不会止步于打印每个文件的异常。在处理完所有文件后，它会计算一个目录级别的恶意评分，旨在帮助区分： - 主要正常但包含少量奇怪记录的 Zeek 目录 - 恶意或攻击密集型目录，其中异常范围更广、相关性更强，且集中在攻击相关的日志中 该评分最后作为单独的 `Directory Summary` 打印。 #### 为什么不仅仅对原始异常分数求和？ 因为原始分数不能直接比较： - 不同的日志类型使用不同的检测器 - 不同的检测器产生不同的评分尺度 - 文件大小和特征分布会影响分数幅度 - 良性目录仍然可能存在少数局部高异常 因此，目录评分不直接使用原始总和。 #### 目录评分使用的指标 目录评分将异常摘要与从整个目录学习到的行为概况相结合。 主要组成部分包括： 1. `weighted_top` - 对于每个日志，该工具计算该日志内部顶部异常行的平均百分位秩 - 这些值按日志重要性加权 - 诸如 `conn`、`http`、`files`、`tls`、`weird` 和 `notice` 等攻击相关日志的权重高于 `known_hosts` 或 `loaded_scripts` 等清单日志 2. `uid_correlation` - 统计出现在两种或多种日志类型中的异常 `uid` 值 - 对出现在三种或多种日志类型中的异常 `uid` 值给予额外权重 这是最重要的信号之一，因为跨日志的协调活动比孤立的异常更能表明真实的恶意行为。 3. `anomaly_fraction` - 衡量每条日志中被标记为异常的比例 - 使用跨文件的加权、归一化异常比例 这有助于区分“几行奇怪的行”和“大部分相关活动看起来都很奇怪”。 4. `weird_notice` - 当 `weird.log` 或 `notice.log` 也包含异常行时增加权重 这很重要，因为这些日志已经代表了异常或类似警报的行为，通常能加强攻击证据。 5. `fuid_overlap` - 当异常的 `http.log` 事务通过 `fuid` 与异常的 `files.log` 记录相关联时增加权重 这对于可疑的内容交付、Payload 传输和基于文件的 HTTP 异常很有用。 6. `behavior_score` - 从 `conn.log` 构建源级行为概况 - 测量广泛的类似扫描的活动，例如： - 高目标端口扇出 - 大规模针对每个目标端口的扫描 - 高失败连接比例 - 短暂、零 Payload、缺失服务的连接模式 - 保留最强的行为离群值并在 `Directory Summary` 中打印 这一部分使得工具能够检测广泛的攻击活动，例如简单的 Nmap 扫描，即使它们在更高级别的日志中没有产生太多 `uid` 重叠。 #### 目录评分公式 当前实现使用以下加权组合： ``` core_score = 100 * ( 0.35 * weighted_top + 0.25 * uid_correlation + 0.20 * anomaly_fraction + 0.15 * weird_notice + 0.05 * fuid_overlap ) directory_score = min(100, core_score + 45 * behavior_score) ``` 最终结果显示在 `0-100` 范围内，并标记为： - `LOW` - `MEDIUM` - `HIGH` 这些标签用于分类，并非经过校准的入侵概率。 ### 5. 训练正常基线 您可以通过在目录运行期间传递一个或多个 `--normal-dir` 值，从已知正常的 Zeek 目录训练阈值。 使用一个正常目录的示例： ``` python3 zeek-anomaly-detector.py \ -d /path/to/suspect/zeek \ -N /path/to/known-normal/zeek ``` 使用多个正常目录的示例： ``` python3 zeek-anomaly-detector.py \ -d /path/to/suspect/zeek \ -N /path/to/normal1 \ -N /path/to/normal2 \ -N /path/to/normal3 ``` #### 当正常流量变化时的最佳训练方式 最佳方法不是从单个原始异常分数学习硬阈值。正常的 Zeek 目录自然会因以下原因而变化： - 不同的流量 - 不同的协议组合 - 不同的扫描和发现噪音 - 不同的主机清单 - 不同的捕获持续时间 因此，该工具从目录摘要组件而不是每行原始分数学习阈值。 它计算以下指标的正常基线： - `score` - `weighted_top` - `weighted_fraction` - `uid_corr_score` - `weird_notice_bonus` - `fuid_bonus` - 跨日志重叠计数 当提供多个正常目录时，使用鲁棒统计学习每个指标的阈值： - 中位数 - 基于 MAD 的上界 当仅提供一个或两个正常目录时，工具会回退到高于观察到的正常值的保守边界。 这不如在许多正常目录上训练那么强，但仍比使用一个全局固定阈值要好。 #### 输出 当使用 `--normal-dir` 时，最终输出包含一个 `Baseline Comparison` 部分，说明当前目录是否： - `WITHIN NORMAL BASELINE` - `SUSPICIOUS VS BASELINE` - `ABOVE NORMAL BASELINE` 它还会打印哪些摘要指标超过了学习到的正常阈值。 ## 按日志类型的技术 ### `conn.log` 技术：`IsolationForest` 原因： - `conn.log` 是最接近经典流异常检测的日志。 - 攻击通常表现为字节、数据包、端口、服务、连接状态和持续时间的异常组合。 - 多变量检测比单特征阈值更合适。 主要特征包括： - 目标端口 - 持续时间 - 总字节数 - 总数据包数 - 发起方/响应方字节比率 - 发起方/响应方数据包比率 - 每秒字节数 - 每数据包字节数 - 端口稀有度 - 服务稀有度 - 连接状态稀有度 - 历史记录稀有度 - 目标主机流行度 - 来自 HTTP、files、SSH 和 weird 日志的相关 `uid` 上下文 这是发现扫描活动、奇怪连接扇出、失败探测、奇怪大小比率或与环境其余部分不匹配的流量的最佳日志。 ### `http.log` 技术：`IsolationForest` 原因： - 恶意 HTTP 行为通常是方法、URI、状态、主体大小、主机稀有度和 User-Agent 怪异程度的组合。 - 单值阈值在这里效果不佳。 - 跨日志关联很重要，因为传递的文件可能比 HTTP 行本身更可疑。 主要特征包括： - 目标端口 - 事务深度 - 请求和响应主体长度 - 状态码 - URI 长度 - 主机长度 - User-Agent 长度 - 方法稀有度 - 状态稀有度 - 主机稀有度 - URI 稀有度 - User-Agent 稀有度 - 关联的响应和发起方文件 ID 计数 - 通过 `fuid` 关联的文件计数、文件字节数和文件 MIME 稀有度 - 相关的 `uid` 连接和 weird-event 上下文 这有助于发现扫描、异常方法、可疑路径、奇怪 User-Agent 以及与稀有或可疑文件相关的 HTTP 事务。 ### `dns.log` 技术：DNS 特定的混合评分 原因： - DNS 滥用通常表现为词汇异常、响应模式异常或来自同一源主机的算法化域名重复爆发。 - DGA 流量很少仅从单个字段可见。它通常是域名随机性、TLD 选择、无应答行为和重复的源端查询模式的组合。 - 通用离群点检测倾向于过度排名良性的 mDNS 和反向查找流量，因此 DNS 检测器使用自定义评分。 主要特征包括： - 目标端口 - 查询长度 - 标签计数 - 首标签长度 - 查询熵 - 唯一字符比率 - 元音比率 - 辅音比率 - 数字比率 - 查询稀有度 - TLD 稀有度 - 查询类型稀有度 - 响应码稀有度 - 应答计数 - TTL 计数 - 无应答标志 - 拒绝标志 - `dga_like` 词汇启发式 - `dga_pattern_count` 用于重复的类似 DGA 模式 - `src_dga_like_count`来自同一源主机的重复类似 DGA 查询 - `is_mdns` - `is_local_tld` - `is_reverse_lookup` - `is_service_discovery` - 通过 `uid` 关联的 conn/weird 上下文 #### DGA 相关行为 DNS 检测器明确尝试捕获类似 DGA 的行为。它不依赖于签名列表。相反，它使用词汇和重复特征，例如： - 长的首标签 - 高字符熵 - 高唯一字符比率 - 低元音比率或明显的数字存在 - 来自同一源主机的结构相似且看起来随机的域名的重复查询 这意味着诸如以下域名： - `kvcjsnsd.ru` - `afajgvcnm.ru` - `wtkfidatyhc.ru` 不仅单独看起来可疑，而且如果同一源主机重复出现相同的类似 DGA 模式，异常分数会进一步增加。 检测器还显式降低良性本地解析流量的权重，例如： - 端口 `5353` 上的 mDNS - `.local` 名称 - `in-addr.arpa` - `ip6.arpa` - 服务发现名称，如 `_googlecast._tcp.local` 这是有意为之，以便类似 DGA 的域名排名高于本地多播噪音。 ### `files.log` 技术：`IsolationForest` 原因： - 文件传输通常因大小、MIME 类型、来源、超时行为或与相关活动不匹配而变得可疑。 - 文件元数据足够丰富，适合多变量离群点检测。 主要特征包括： - 目标端口 - 深度 - 持续时间 - 已见字节 - 总字节 - 丢失字节 - 溢出字节 - `local_orig` - `is_orig` - `timedout` - MIME 稀有度 - 来源稀有度 - 分析器计数 - 已见字节与总字节之间的间隙 - 通过 `uid` 关联的 HTTP、conn 和 weird 上下文 这对于发现稀有文件、异常传输大小、可疑提取内容以及与奇怪 HTTP 会话相关的文件传输很有用。 ### `ssh.log` 技术：`IsolationForest` 原因： - SSH 日志相对稀疏，但对于检测异常的客户端 Banner、服务器 Banner、认证行为以及与可疑连接上下文的关联仍然有用。 主要特征包括： - 目标端口 - 认证尝试 - 客户端字符串长度 - 服务器字符串长度 - 客户端稀有度 - 服务器稀有度 - 通过 `uid` 关联的连接、weird 和 HTTP/文件上下文 这有助于突出扫描、Banner 异常以及与其他可疑事件关联的行为。 ### `tls.log` 技术：`IsolationForest` 原因： - TLS 元数据通常最好作为多变量指纹式异常检测来处理。 主要特征包括： - 目标端口 - TLS 版本 - 密码套件计数 - 服务器名称长度 - JA3 稀有度 - JA3S 稀有度 - SNI 稀有度 - 通过 `uid` 关联的连接和 weird 上下文 注意：如果您的 `tls.log` 不包含 JA3、JA3S 或类似 SNI 的字段，检测器将使用现有的任何 TLS 元数据。如果目录中没有 `tls.log`，则不会发生任何特殊情况。 ### `weird.log` 技术：稀有度评分 原因： - `weird.log` 已经记录了异常的协议或解析器行为。 - 正确的问题不是“这个向量是离群点吗？”，而是“这个 weird 事件有多稀有以及相关性如何？” 主要特征包括： - 目标端口 - Notice 标志 - Weird-name 稀有度 - 源模块稀有度 - Peer 稀有度 - 通过 `uid` 关联的 conn/http/files/ssh 上下文 这对于发现既稀有又与可疑会话相关联的 weird 事件很有用。 ### `notice.log` 技术：稀有度评分 原因： - `notice.log` 已经是一个更高级别的检测流。 - 它应该被优先排序，而不是像原始流量那样进行建模。 主要特征包括： - `n` - `suppress_for` - Notice 类型稀有度 - 来源稀有度 - 消息长度 这有助于对 notice 进行排序，而不是取代 Zeek 自己的检测逻辑。 ### `known_services.log` 技术：稀有度评分 原因： - 此日志类似于清单。 - 它对于新颖性检测很有用，例如异常的服务/端口暴露。 主要特征包括： - 端口号 - 服务稀有度 - 主机稀有度 - 传输层稀有度 这可以发现异常的服务暴露或观察到的服务变化。 ### `known_hosts.log` 技术：稀有度评分 原因： - 这是主机清单，而不是流遥测。 - 有意义的信号是主机新颖性和时间不规则性。 主要特征包括： - 主机稀有度 - 观察之间的时间间隔偏差 这对于新主机发现、变动或异常的主机出现时间很有用。 ### `software.log` 技术：稀有度评分 原因： - 此日志描述发现的软件和版本，主要属于清单性质。 - 稀有的软件/版本组合通常比几何离群点检测更有用。 主要特征包括： - 主机端口 - 主/次版本号 - 软件类型稀有度 - 产品名称稀有度 - 附加版本稀有度 - 未解析版本长度 这有助于发现异常的软件/版本指纹。 ### `arp.log` 技术：稀有度评分 原因： - ARP 活动简短、结构化，通常更适合新颖性评分。 - 怀疑通常来自异常的请求/应答模式或 MAC/IP 稀有度。 主要特征包括： - 操作稀有度 - 源 MAC 稀有度 - 目标 MAC 稀有度 - 广播请求标志 - 发起方 IP 稀有度 - 响应方 IP 稀有度 这对于标记奇怪的 ARP 活动很有用，尤其是在实验室或小型网络中。 ### `stats.log` 技术：时间序列偏差评分 原因： - `stats.log` 是关于 Zeek 本身和整体流量处理的遥测数据。 - 这些是随时间演变的计数器和仪表，而不是流记录。 - 仅靠原始计数器是不够的。更有意义的信号在于负载比率、队列压力、协议组合、文件提取强度和增长率。 主要特征现在包括操作比率和速率，例如： - 内存 - 排队事件数 - 活动连接数 - 活动文件数 - 活动 DNS 请求数 - 总重组大小 - 每数据包字节数 - 每数据包事件数 - 队列与处理比率 - 活动与总连接比率 - TCP、UDP 和 ICMP 份额 - 每连接文件数 - 每连接活动文件数 - 每 UDP 连接 DNS 请求数 - 活动 DNS 压力 - 每 TCP 连接重组数 - 定时器压力 - 每数据包内存 - 数据包、字节、事件、队列、连接、文件和 DNS 增长率 - 内存增量 - 队列增量 - 连接组合增量 评分仍基于时间序列，但现在基于这些派生的操作特征。这使得 `stats.log` 异常在 Zeek 术语中更有意义：队列堆积、负载形状变化、异常协议组合变化、异常文件或 DNS 强度以及突发的处理压力变化。 ### `capture_loss.log` 技术：时间序列偏差评分 原因： - 丢包和捕获间隙是与时间相关的监控信号。 主要特征包括： - `ts_delta` - `gaps` - `acks` - `percent_lost` ### `packet_filter.log` 技术：稀有度评分 原因： - 这是配置/状态元数据，而不是流量数据。 主要特征包括： - `init` - `success` - 过滤器稀有度 - 节点稀有度 ### `loaded_scripts.log` 技术：稀有度评分 原因： - 这是 Zeek 运行时元数据。 - 有用的信号是异常脚本路径的出现。 主要特征包括： - 脚本路径稀有度 - 脚本路径长度 ## 输出语义 默认输出特意保持简洁： - 仅打印异常块 - 每个产生异常的日志文件对应一个块 - 每个块都标有文件名 - 每个打印的异常行都包含一个数字 `score` - 在目录模式下，最后打印 `Directory Summary` 详细和调试输出增加： - 检测器名称 - 使用的特征列 - 调试模式下的特征样本 重要：每个检测器都会产生一个数字分数，但含义取决于检测器家族： - `IsolationForest`：分数越高意味着该行与该日志其余特征分布更隔离 - 稀有度评分：分数越高意味着该行在该日志中包含更稀有的值或组合 - 时间序列评分：分数越高意味着该行与时间序列水平和/或变化模式的偏差更强 这些是每种日志类型内部的排序分数，而不是经过校准的概率，不应在不同的 Zeek 日志之间进行数值比较。来自 `conn.log` 的分数不应直接与来自 `http.log` 的分数进行比较。 ### 阅读目录摘要 在目录运行结束时，工具会打印： - 严重性标签：`LOW`、`MEDIUM` 或 `HIGH` - `0-100` 范围内的目录恶意评分 - 用于构建分数的归一化组件值 - 跨多个日志共享的异常 `uid` 值数量 - 异常 HTTP/文件 `fuid` 重叠数量 - 贡献最大的日志及其加权贡献 最后一个块是比较一个 Zeek 目录与另一个的最佳位置。它比汇总原始行分数更可靠，因为它包含归一化和跨日志关联。 ## 安装 ### 源代码 克隆存储库： ``` git clone --recurse-submodules --remote-submodules https://github.com/stratosphereips/zeek_anomaly_detector cd zeek_anomaly_detector ``` 安装依赖项： ``` pip install -r requirements.txt pip install scikit-learn ``` 注意： - `pandas` 和 `numpy` 是必需的。 - 强烈推荐 `scikit-learn`，因为较丰富的多变量日志使用了 `IsolationForest`。 - 如果缺少 `scikit-learn`，脚本会针对这些日志回退到更简单的基于距离的分数。 ### Docker 如果您使用 Docker，请确保镜像除了 Python 依赖项外还包括 `scikit-learn`。 示例： ``` docker run --rm -it \ -v /full/path/to/logs:/logs \ stratosphereips/zeek_anomaly_detector:latest \ python3 zeek-anomaly-detector.py -d /logs ``` ## 用法 ### 单个日志 运行单个 Zeek 日志： ``` python3 zeek-anomaly-detector.py -f dataset/001-zeek-scenario-malicious/conn.log ``` 显示前 20 个异常： ``` python3 zeek-anomaly-detector.py -f dataset/001-zeek-scenario-malicious/conn.log -a 20 ``` ### 日志目录 运行整个 Zeek 目录并独立评分每个日志： ``` python3 zeek-anomaly-detector.py -d /path/to/zeek/logs ``` 当您拥有来自同一捕获的多个 Zeek 日志时，这是推荐的模式，因为工具可以在评分前跨文件构建 `uid` 和 `fuid` 上下文。 ### 详细和调试输出 显示检测器名称和特征列： ``` python3 zeek-anomaly-detector.py -d /path/to/zeek/logs -v 1 ``` 也显示特征样本： ``` python3 zeek-anomaly-detector.py -d /path/to/zeek/logs -e 1 ``` ### 导出处理后的 Dataframe 将丰富的每日志 dataframe 导出为 CSV： ``` python3 zeek-anomaly-detector.py -d /path/to/zeek/logs -D output_csvs ``` 导出为单个输出文件： ``` python3 zeek-anomaly-detector.py -f dataset/001-zeek-scenario-malicious/conn.log -D conn.csv ``` ### 导出 JSON 摘要 写入运行的机器可读摘要： ``` python3 zeek-anomaly-detector.py -d /path/to/zeek/logs -J summary.json ``` JSON 导出包括： - `input_path` - `directory_summary` - `files` 每个文件条目包含： - 日志名称 - 总行数 - 异常行数和比例 - 顶部异常分数统计 - 检测器方法 - 使用的特征列 - 相关的异常 `uid` 和 `fuid` 值 - 作为 JSON 记录的顶部异常行 如果您想通过编程方式比较多个 Zeek 目录或将结果馈送到另一个分析阶段，这是推荐的输出。 ### 导出分数图表 写入一个多页 PDF，包含每个日志的逐流分数图表以及最后的摘要页： ``` python3 zeek-anomaly-detector.py -d /path/to/zeek/logs -P scores.pdf ``` PDF 包含： - 一个摘要页，显示最终目录分数和主要分数组件 - 一个跨所有日志文件的组合逐流页面 - 每个 Zeek 日志文件一个分数图表 如果您还使用 `-N` 或 `--normal-dir`，摘要页会叠加： - 蓝色条表示可疑目录 - 绿线表示每个目录摘要指标的学习正常中位数 - 红色虚线表示每个指标的学习正常阈值 每个文件图表显示： - 蓝线表示每个流或行的分数，按文件顺序 - 红色标记表示被标记为异常的行 - 橙色虚线截止线表示最后显示的异常分数 组合页显示： - 一个共享时间轴上所有文件的所有行 - Y 轴为文件内归一化分数百分位，以便公平比较不同日志类型 - X 轴为文件边界和标签 - 整个运行中异常行的红色标记 当您想查看异常是孤立的峰值、重复爆发还是跨文件的广泛攻击活动时，这很有用。 ## 实用指南 ### 专注于攻击检测的最佳日志 如果您的目标是首先发现恶意流量或攻击活动，请关注： - `conn.log` - `http.log` - `files.log` - `ssh.log` - `tls.log`（如果可用） - `weird.log` - `notice.log` ### 清单和遥测日志 这些日志仍会被处理，但解释有所不同： - `known_hosts.log` - `known_services.log` - `software.log` - `packet_filter.log` - `loaded_scripts.log` - `stats.log` - `capture_loss.log` 它们对于新颖性漂移和操作上下文异常很有用，而不仅仅是直接的恶意流量检测。 ### 按日志类型阅读结果 不要假设每个异常都意味着相同的事情： - 在 `conn.log` 中，异常通常意味着奇怪的流模式。 - 在 `http.log` 中，通常意味着奇怪的应用程序事务或与异常内容相关的请求。 - 在 `files.log` 中，通常意味着可疑的内容传输行为。 - 在 `weird.log` 或 `notice.log` 中，通常意味着高优先级事件或罕见的协议/解析器观察。 - 在清单日志中，通常意味着新颖性或环境漂移。 ## 当前限制 - 分数是日志内排名，而不是全局校准的风险分数。 - 这是无监督检测。它揭示的是异常行为，而非保证的恶意行为。 - 清单日志可能产生有效的操作上有意义但不一定是攻击的新颖性检测。 - 当前实现依赖于每个 Zeek 日志中存在的字段。稀疏日志自然会产生更简单的检测器。 ## 贡献 创建一个 Issue 或 PR，我们会处理它。 ## 作者 该项目由捷克技术大学电气工程学院 AIC 实验室的 Stratosphere 研究室的 Sebastian Garcia 和 Veronica Valeros 创建。

标签：AMSI绕过, Apex, Beacon Object File, conn.log, Docker, http.log, IP 地址批量处理, NIDS, PB级数据处理, PCA, PE 加载器, Python, Rootkit, ssh.log, Zeek, 代码示例, 威胁检测, 安全运维, 安全防御评估, 容器化, 异常检测, 数据分析, 无后门, 机器学习, 流量监控, 网络安全, 网络流量分析, 网络调试, 自动化, 请求拦截, 逆向工具, 隐私保护