secureworks/dalton
GitHub: secureworks/dalton
Dalton 是一个针对 Snort、Suricata 和 Zeek 的 IDS 规则与流量测试系统，通过 Web 界面或 API 快速验证规则覆盖率和配置变更。
Stars: 511 | Forks: 98
# Dalton
Dalton 是一个系统，允许用户使用定义的规则集和/或定制规则，针对其选择的入侵检测系统（Intrusion Detection System，简称 "IDS"）传感器（例如 Snort、Suricata）快速轻松地运行网络数据包捕获（"pcaps"）。
Dalton 还包含一个类似向导的 `Flowsynth `__ Web 界面，以促进自定义 pcap 的创建。
.. image:: app/static/images/dalton.png
**快速入门**:
.. code:: bash
```
./start-dalton.sh
```
或者执行以下作用相同的命令：
.. code:: text
```
docker compose build && docker compose up -d
```
然后导航至 ``http:///dalton/``
要配置可用的规则集，请参阅 `Adding Rulesets <#adding-rulesets>`__。
要配置可用的传感器，请参阅 `Adding Sensors <#adding-sensors>`__。
如果 Dalton 是在代理后面构建的，请参阅 `Building Behind A Proxy <#building-behind-a-proxy>`__
# 目录
- `Use Cases <#use-cases>`__
- `Design <#design>`__
- `Requirements <#requirements>`__
- `Installing and Running Dalton <#installing-and-running-dalton>`__
- `Building Behind A Proxy <#building-behind-a-proxy>`__
- `Using Dalton <#using-dalton>`__
- `Launching A New Job <#launching-a-new-job>`__
- `Suricata Socket Control Mode <#suricata-socket-control-mode>`__
- `Job Settings <#job-settings>`__
- `Config Files <#config-files>`__
- `Job Results <#job-results>`__
- `Job Queue <#job-queue>`__
- `Sensors <#sensors>`__
- `Dalton API <#dalton-api>`__
- `Job API <#job-api>`__
- `Controller API <#controller-api>`__
- `Teapot Jobs <#teapot-jobs>`__
- `Adding Rulesets <#adding-rulesets>`__
- `Adding Sensors <#adding-sensors>`__
- `Docker Sensors <#docker-sensors>`__
- `Non-Docker Sensors <#non-docker-sensors>`__
- `Adding Sensor Configs <#adding-sensor-configs>`__
- `Logging and Debugging <#logging-and-debugging>`__
- `Flowsynth WebUI <#flowsynth-webui>`__
- `Zeek <#zeek>`__
- `CyberChef <#cyberchef>`__
- `Frequently Asked Questions <#frequently-asked-questions>`__
- `Authors <#authors>`__
# 用例
这些是 Dalton 最常见的用例：
- | **测试规则集/规则集覆盖率**
| 用户提供的 pcap 可以通过加载了特定规则集的 IDS 引擎运行。
- | **故障排除和开发签名**
| 用户提供的 pcap 可以针对用户提供的临时 IDS 规则进行测试，以快速轻松地查看 IDS 警报和/或测试规则语法错误。
- | **测试变量更改**
| 引擎使用的规则集变量可以轻松地针对提交的任务进行修改；这可用于确定变量更改可能对特定检测产生的影响。
- | **测试配置更改**
| 自定义引擎配置文件可以包含在提交的任务中；这可用于确定引擎配置更改可能对特定检测产生的影响。
- | **测试特定 IDS 引擎行为**
| Dalton 支持在特定传感器上应用上述用例的能力。Dalton 架构旨在适应和支持各种传感器引擎和引擎版本。
- | **制作自定义数据包捕获**
| 作为 Web 界面的一部分，Dalton 有一个模块，为 Flowsynth 提供类似向导的 Web 界面。这允许针对流行的协议和流量模式快速轻松地定义网络流和创建 pcap。
# 设计
Dalton 由一个“控制器”和一个“代理”组成。控制器提供 Web 界面以及用于代理通信和编程式任务结果检索的 HTTP API。
从 Web 界面，用户提交要在特定代理或代理平台上运行的任务。Dalton 任务由一个或多个 pcap、一个预定义的规则集和/或自定义规则、代理引擎配置选项（例如，运行任务时应用于 Suricata 的配置）以及指定任务其他选项（例如，返回规则性能日志）的清单文件组成。
Dalton Agent 代码运行在 IDS 传感器上，并提供 Dalton 控制器和 IDS 引擎之间的接口。Dalton 代理从 Dalton 控制器获取待处理任务，在本地运行它们，并报告结果。然后，这些结果显示在 Dalton 控制器提供的 Web GUI 中。任务提交给特定的传感器引擎（例如 Suricata）和版本（例如 4.0.0）。
Dalton 代理和控制器 Web 应用程序的代码是用 Python 编写的，并利用了 `Flask `__ 用于管理任务队列、存储结果和维护活动 Dalton 代理的列表。
Dalton 控制器包含一个 `Flowsynth `__ WebUI 模块，该模块提供一个用户界面，以协助快速的 Flowsynth 语言原型设计和网络流定义的开发，这些定义随后由 Flowsynth 脚本编译成网络 pcap。这基本上是一个促进 Flowsynth 输入和输出的 GUI。可以选择轻松地将 Flowsynth WebUI 生成的 pcap 发送到 Dalton 进行测试。
虽然上述所有系统都可以是独立的物理（或虚拟）机器（实际上已经完成了这种设置），但为了易于安装和使用，一切也被架构为一组 `Docker `__
- `Docker Compose V2 `__ 模式来处理 pcap，而不是为每个任务启动一个新的 Suricata 进程并使用 pcap 重放模式。当代理上的规则集和配置在任务之间没有变化时，利用 Suricata 的 socket 控制功能可显著提高任务性能（减少任务运行时间），因为消除了启动 Suricata 和处理规则集的开销。
要启用 Suricata Socket Control，请在任务提交页面的 ``Job Settings`` 垂直选项卡的 ``Sensor Version`` 部分选择 ``Use Suricata Socket Control Pcap Processing Mode``。
如果 Dalton 代理无法对任务使用 Suricata Socket Control，它将使用经典的 read pcap 模式。
如果启用了 ``Rule profiling``，则该任务将禁用 Suricata Socket Control 模式，因为规则性能分析和关键字性能分析日志不会被填充（或者通常没有足够的时间被填充）用于 socket 控制 pcap 运行。
Suricata Socket Control 模式利用 Suricata 源代码中包含的 ``suricatasc`` Python 模块。如果代理是使用提供的 Dockerfile 作为 Docker 容器构建的，那么 ``suricatasc`` Python 文件应该已经存在，并且代理知道它们。如果不是，或者模块不在 PYTHONPATH 中，则可以在 ``dalton-agent.conf`` 文件中设置 ``SURICATA_SC_PYTHON_MODULE`` 配置项以指向正确的位置。
虽然 Suricata 1.4 及更高版本支持 Socket Control，但 ``suricatasc`` 模块直到 Suricata 3.0 才兼容 Python 3，因此这是 Dalton 支持的最早版本。
- | **Suricata Socket Control Mode 的问题**
| Suricata Socket Control 存在一些已知问题，与 Dalton 无关。如果遇到问题，请尝试在禁用此选项的情况下运行任务。
- | **示例问题**
| `Docker Suricata Socket Control 使用命令 'reopen-log-files 崩溃 `__
| `Suricata 4.1 段错误：Socket Control pcap-file 和损坏的 pcap `__
| `使用 Socket Control Pcap Processing Mode 时，警报元数据不存在于 EVE 输出中 `__
## 作业设置
在任务提交页面上，“Job Settings” 垂直选项卡提供了许多用户可配置的选项：
- | **Packet Captures**
| 指定要在传感器上运行的数据包捕获（libpcap 格式）。根据引擎的不同，也可能支持 pcapng 格式。可以提交包含 pcap 的存档文件，文件将被提取并使用。支持的扩展名（及其推断的格式）有 .zip、.gz、.gzip、.bz2、tar、.tgz 和 .tar.gz。由于 zip 和 tar 文件可以包含多个文件，因此对于这些格式，仅包含扩展名为 “.pcap”、“.pcapng” 或 “.cap” 的成员；其他文件将被忽略。将尝试使用密码 'infected' 解密受密码保护的 zip 文件。
| 如果为 Suricata 任务提交了多个 pcap，它们将在任务提交时合并为一个 pcap，因为（旧版本的）Suricata 在 read pcap 模式下只能读取单个 pcap。
- | **Create separate jobs for each pcap**
| 如果选中，提交的每个 pcap 文件（或在存档中找到的）都将作为其自己的任务提交。当所有任务提交后，Dalton 会将用户重定向到队列页面。如果这是一个 `Teapot job <#teapot-jobs>`__，则返回以逗号分隔的 JID 列表。
- | **Sensor Version**
| 用于运行指定 pcap 和规则的特定传感器版本。
- | **Use Suricata Socket Control Pcap Processing Mode**
| 请参阅 `Suricata Socket Control Mode <#suricata-socket-control-mode>`__ 部分。
- **Ruleset**
- | **Use a production ruleset**
| 如果选中此选项，请选择要使用的 “production”（预定义）规则集。另请参阅 `Adding Rulesets <#adding-rulesets>`__。
- | **Enable disabled rules**
| 启用所有禁用的规则。如果未定义禁用规则中的变量，这可能会导致引擎错误。
- | **Show all flowbit alerts**
| 具有 ``flowbit:noalert`` 的规则将删除该指令，以便它们显示在传感器警报中。
- | **Use custom rules**
| 这允许用户指定在测试 pcap 时要包含的特定临时规则。用户需要确保任何自定义规则都是有效的，因为在 Dalton 控制器上进行的规则语法验证非常少；提交无效规则将导致正在使用的 Dalton Agent（传感器引擎）返回详细错误，这有助于规则语法故障排除。自定义规则被添加到 ``dalton-custom.rules`` 文件中并包含在任务中，因此支持有效的格式，例如多行规则（每行一个），以及以井号（'#'）开头的注释（忽略行）。如果没有为自定义规则提供 ``sid``，则在提交任务时会添加一个。
- **Logs**
- | **Pcap records from alerts (unified2)**
| 这告诉代理处理 unified2 警报数据，如果任务生成了警报，此信息将显示在任务结果页面的 “Alert Details” 选项卡下。返回的信息包括来自生成警报的数据包的 hex/ASCII 输出，以及 unified2 文件中的 “Extra” 数据，例如来自具有 “X-Forwarded-For” 或 “True-Client-IP” HTTP 头的数据包的 “Original Client IP”（如果在传感器上配置了 enable\_xff）。请注意，Suricata 6 及更高版本不支持 unified2 输出，因此对于此类代理的任务，此选项不可用。
- | **EVE Log**
| *仅限 Suricata*，版本 2 及更高版本。打开（如果未选中则关闭）EVE 日志记录并返回结果。特定的 EVE 日志类型、设置等由配置文件确定（并可在其中设置）。由于 Suricata 版本 < 3.1 不支持多个 TLS logger，因此对于提交给此类代理的任务，EVE 日志中的 TLS 日志记录被禁用。EVE 日志的最大支持大小为 512MB；请参阅关于 'Other logs' 的 512MB 限制说明。
- | **Other logs (Alert Debug, HTTP, TLS, DNS, etc.)**
| *仅限 Suricata*。这将返回引擎生成的其他日志，可用于分析和调试。根据代理上运行的 Suricata 版本，可能不支持某些日志。与所有结果一样，'Other logs' 数据作为字符串存储在 Redis 中，其最大大小为 512MB。如果这些日志超过该大小，可能会发生数据丢失和/或其他问题。当前返回以下日志，每个都在自己的选项卡中，如果日志文件为空，则不会显示该选项卡：
- | **Engine Stats** (*即使未选中此选项也始终返回*)
| 来自引擎的统计数据，包括有关内存、流、会话、重组等的数字。
- | **Packet Stats** (*即使未选中此选项也始终返回*)
| 来自 pcap 的统计数据，包括网络协议、应用层协议等。
- | **Alert Debug**
| 有关每个警报匹配的特定规则的详细信息。用于查看警报触发的原因和/或故障排除误报。
- | **HTTP Log**
| HTTP 请求和响应的日志，显示时间、IP 和端口、HTTP 方法、URI、HTTP 版本、主机、User-Agent、Referer、响应代码、响应大小等。默认情况下，每一行代表一个 HTTP 请求和响应。
- | **DNS Log**
| Suricata 提供的 DNS 请求和响应日志。如果 Suricata 使用 Rust 支持编译或 Suricata 版本为 5.0 或更高，则此日志不可用。
- | **TLS Log**
| Suricata 提供的 SSL/TLS 流量日志。
- | **Dump buffers (alerts only)**
| 这将显示检测引擎使用的缓冲区的内容，这对于解决可能未按预期解析的流量的签名创建非常有用。由于此类输出可能很庞大，因此仅返回与警报关联的缓冲区内容。要查看更多流量的缓冲区内容，请使用匹配更多流量的规则（甚至是匹配所有流量的通用规则）。Snort 将缓冲区内容输出到 “Buffer Dump” 日志输出中。Suricata 的工作方式不同，会将内容放入 “HTTP Buffers”、“TLS Buffers” 和/或 “DNS Buffers” 中。这些是 Lua 脚本输出，旨在在视觉上类似于 Snort 缓冲区转储输出。但是，在 Suricata 上，必须为缓冲区转储指定协议。例如：``alert http``、``alert tls``、``alert dns``。
- | **Rule profiling**
返回每个规则的性能统计信息。这是来自引擎规则性能分析输出的数据。此数据将显示在任务结果页面的 “Performance” 选项卡下。
- | **Fast pattern info**
- *仅限 Suricata*。返回有关提交规则的快速模式数据。Dalton Suricata 代理将返回一个文件（显示在 “Fast Pattern” 选项卡中），其中包含有关引擎用于快速模式匹配的详细信息。为了生成此信息，Suricata 必须进行两次运行——一次生成快速模式信息，一次实际运行提交的任务，因此这将大约使任务运行时间加倍。除非出于某种原因需要快速模式信息，否则无需选中此项。快速模式数据可能很庞大，因此不建议为大型生产/预定义规则集选择此项。
## 配置文件
在任务提交页面上，“Config Files” 垂直选项卡提供了编辑传感器配置文件的能力：
- | **Configuration File**
| Dalton 代理用于任务的引擎配置文件，包括变量。如果选择了 ``Override EXTERNAL_NET (set to 'any')`` 选项（默认开启），则在提交任务时 ``EXTERNAL_NET`` IP 变量将设置为 ``any``。另请参阅 `Updating Sensor Configs <#updating-sensor-configs>`__。
# 作业结果
任务结果页面允许用户下载任务 zip 文件，并在表格界面中显示任务运行的结果：
- | **Alerts**
这些是来自传感器的原始警报。
- | **Alert Details**
| 如果为任务选择了 ``Include Detailed Alerts``，则将在此处显示处理 unified2 警报文件的详细输出。
- | **EVE JSON** (仅限 Suricata)
| 如果启用了 EVE 日志记录，则为带有语法高亮的 EVE 日志。``Format`` 复选框 “漂亮打印” EVE 数据；``Dark Mode`` 复选框将暗模式主题/颜色应用于 EVE 数据。UI 还根据 EVE 日志中存在的事件类型动态显示复选框。这些可用于过滤显示的 EVE 数据。如果 EVE 数据超过 2000000 字节，则默认情况下禁用 ``Dark Mode`` 选项并关闭语法着色，原因出于性能考虑。
- | **IDS Engine**
| 这是 IDS 引擎的原始输出。对于 Snort 任务，引擎统计信息将在此选项卡的底部。
- | **Performance**
| 如果启用了 ``Rule profiling``，这些结果将包含在此处。
- | **Debug**
| 这是来自代理的 Debug 输出。
- | **Error**
| 如果运行任务的 Dalton 代理遇到任何错误，它们将被返回并显示在此选项卡中，并且默认情况下将选中该选项卡。如果没有错误，则不会显示此选项卡。
- | **Other logs**
| 如果代理返回了其他日志，则每个日志将显示在自己的选项卡中（如果它们非空）。对于 Suricata 任务，始终返回 ``Engine Stats`` 和 ``Packet Stats``。请参阅上面的 “Configuration Options” 讨论以获取更多详细信息。
# 作业队列
提交的任务可以在 “Queue” 页面上查看。每个测试都分配有一个准唯一的 16 字节 Job ID，该 ID 基于任务的运行时参数。每个最近的 Job ID 都作为超链接包含在 'Queue' 页面上，以便于访问。如果代理未提取排队任务，它们将定期清除；除非所有代理都关闭或严重积压，否则这不应发生。Dalton 控制器中还有额外的逻辑，用于在任务超时或被中断时做出适当的响应；这种情况很少发生（如果有的话）。
任务结果也会定期清除；此选项可通过 ``dalton.conf`` 文件中的 ``redis_expire`` 参数进行配置。`Teapot jobs <#teapot-jobs>`__ 的过期超时通过 ``teapot_redis_expire`` 选项配置。
任务完成后，始终可以通过访问以下 url 查看原始任务（如果未过期）::
/dalton/job/
一个任务 zip 文件，包括提交的数据包捕获文件以及与任务关联的规则和变量，存储在磁盘上，默认情况下位于 ``/opt/dalton/jobs`` 目录中；此位置可通过 ``dalton.conf`` 文件中的 ``job_path`` 参数进行配置。Dalton 会根据 ``redis_expire`` 和 ``teapot_redis_expire`` 清理这些文件。访问任务的共享链接会增加任务 zip 文件的过期时间。延长多长时间也可以在 ``dalton.conf`` 文件中使用 ``share_expire`` 配置选项进行配置。Dalton 仅在加载 ``Queue`` 页面时清理磁盘上的任务 zip 文件。要强制按需运行清理任务，请向以下地址发送 HTTP GET 请求::
/dalton/controller_api/delete-old-job-files
可以从任务结果页面上的相应链接访问任务 zip 文件，或使用以下 URL 直接下载::
/dalton/sensor_api/get_job/.zip
# Sensors
代理（也称为 "Sensors"）经常向 Dalton 服务器签到（大约每秒一次，但可在 ``dalton-agent.conf`` 文件中配置）。可以在 ``Sensors`` 页面上查看代理上次签到的时间。未近期签到的代理将根据 ``dalton.conf`` 配置文件中的 ``agent_purge_time`` 值被修剪。当过期或新代理向 Dalton Controller 签到时，它将被自动（重新）添加并可用于任务提交。
# Dalton API
## 作业 API
Dalton 控制器提供 RESTful API 以检索有关已提交任务的数据。API 响应使用 JSON 或原始（"RAW"）数据，并且在大多数情况下，值中返回的数据只是 Dalton Web 界面中显示的原始文本。
**JSON API**
可以通过以下格式的 HTTP GET 请求利用 JSON API::
GET /dalton/controller_api/v2//
对于请求，```` 是 Job ID，并且::
```
: [alert|alert_debug|alert_detailed|all|debug|dns_log|
error|engine_stats|eve|fast_pattern|http_log|ids|
keyword_perf|other_logs|packet_stats|perf|start_time|
statcode|status|submission_time|tech|time|tls_log|user]
```
JSON API 请求返回具有三个根元素的 JSON：
- | **data**
| 请求的数据。如果密钥对任务无效，则返回错误以及说明此类情况错误消息。如果请求的 Job ID 和密钥没有数据，则此 ``data`` 参数值为空字符串，并且 ``error`` 设置为 false。
- | **error**
| [true\|false] 取决于 API 请求是否产生错误。这不是作为带引号的字符串返回的。\ **这表示 API 请求出错，而不是运行任务时出错**。运行任务的错误可以通过查询 'error' 密钥找到（见上文）。
- | **error_msg**
| 如果 error 为 false，则为 null，否则这是带有错误消息的带引号的字符串。
**RAW API**
RAW API 可以通过附加 "/raw" 的相同 HTTP GET 请求来利用::
GET /dalton/controller_api/v2///raw
```` 和 ```` 与 JSON API 相同，但 RAW API 请求在响应正文中返回 Redis 数据库中的原始数据。这基本上是从 JSON API 返回的内容，但未封装或编码为 JSON。对于 RAW API 响应，Content-Type 标头设置为 "text/plain"，但 "eve" 和 "all" 日志除外，它们使用 "application/json"。对 "all" 密钥的 RAW 请求返回包含所有键值对的 Python 字典的字符串表示形式。
RAW 响应还在 Content-Disposition 标头中包含 "attachment" 和 "filename"，提示浏览器下载/保存文件。
**Valid Keys**
- **alert** - 任务警报数据。这与任务结果页面 “Alerts” 选项卡中显示的内容相同。
- **alert\_debug** - 包含大量信息的完整警报日志，供签名编写者或用于调查误报（仅限 Suricata）。这与任务结果页面 “Alert Debug” 选项卡中显示的内容相同。
- **alert\_detailed** - 来自任务的详细警报数据。这与任务结果页面 “Alert Details” 选项卡中显示的内容相同。
- **all** - 返回所有密钥的数据（当然不包括 "all" 本身）。
- **debug** - 来自任务的 Debug 数据。这与任务结果页面 “Debug” 选项卡中显示的内容相同。
- **dns\_log** - 基于行的 DNS 请求和响应日志（仅限 Suricata）。这与任务结果页面 “DNS Log” 选项卡中显示的内容相同。
- **engine\_stats** - 包含来自 Suricata 引擎的各种计数器的数据（仅限 Suricata）。这与任务结果页面 “Engine Stats” 选项卡中显示的内容相同。
- **error** - 来自任务的 Error 数据。这与任务结果页面 “Error” 选项卡中显示的内容相同。
- **eve** - 来自任务的 EVE JSON 输出（仅限 Suricata）。这与任务结果页面 “EVE JSON” 选项卡中显示的内容相同。
- **fast\_pattern** - 提交规则的快速模式详细信息（仅限 Suricata）。这与任务结果页面 “Fast Pattern” 选项卡中显示的内容相同。
- **http\_log** - 基于行的 HTTP 请求日志（仅限 Suricata）。这与任务结果页面 “HTTP Log” 选项卡中显示的内容相同。
- **ids** - 来自任务的 IDS Engine 输出。这与任务结果页面 “IDS Engine” 选项卡中显示的内容相同。对于 Snort Agents，任务运行结束时的引擎统计信息输出将在此处填充。
- **keyword\_perf** - 包含每个关键字性能分析的数据（仅限 Suricata）。这与任务结果页面 “Keyword Perf” 选项卡中显示的内容相同。
- **other\_logs** - *已弃用* - 来自任务的其他日志（仅限 Suricata）。这作为键/值对返回，其中键是日志的名称，值是日志的内容。此密钥已弃用，不包含在 ``all`` 密钥响应中。``other_logs`` 的内容，例如 "http_log"、"tls_log" 等，可以并且应该直接访问。
- **packet\_stats** - pcap 的统计信息（仅限 Suricata）。这与任务结果页面 “Engine Stats” 选项卡中显示的内容相同。
- **perf** - 来自任务的性能数据（如果任务生成了性能数据）。这与任务结果页面 “Performance” 选项卡中显示的内容相同。
- **start\_time** - Dalton 代理请求任务的时间（纪元）。这作为字符串返回。
- **statcode** - 任务的状态代码。这是一个作为字符串返回的数字。如果任务不存在，API 将返回错误（见下文）而不是 “Invalid” statcode。以下是如何解释状态代码：
+-------+-------------+
| Code | Meaning |
+=======+=============+
| -1 | Invalid |
+-------+-------------+
| 0 | Queued |
+-------+-------------+
| 1 | Running |
+-------+-------------+
| 2 | Done |
+-------+-------------+
| 3 | Interrupted |
+-------+-------------+
| 4 | Timeout |
+-------+-------------+
- **status** - 对应于任务当前状态的字符串。这在 Dalton Controller Web UI 中使用，并且是在通过 Web 界面提交任务时在浏览器中显示的内容，用于通知用户任务的当前进度/状态。当任务完成时，这实际上是一个超链接，显示 “Click here to view your results”。除非有特定的用例，否则通常使用 'statcode' 而不是 'status' 来确定任务的状态。
- **submission\_time** - 任务提交给 Dalton Controller 的时间（格式为 "%b %d %H:%M:%S"）。
- **tech** - 提交任务的传感器技术（即引擎和版本），格式为 ``/``。例如，``suricata/4.0.0`` 是 Suricata v4.0.0。如果使用自定义配置，它将添加在末尾，也用正斜杠分隔。例如，``suricata/4.0.7/mycustomconfigname``。使用 Rust 支持编译的 Suricata 4 传感器将在版本前加上 "rust\_"，例如，``suricata/rust_4.1.5``。
- **time** - 任务运行所花费的时间（以秒为单位），由 Dalton Agent 报告（这包括代理下载任务的时间）。这作为字符串返回，并与任务结果页面中显示的 “Processing Time” 相同。
- **tls\_log** - 基于行的 TLS 握手参数日志（仅限 Suricata）。这与任务结果页面 “TLS Log” 选项卡中显示的内容相同。
- **user** - 提交任务的用户。这将始终是 "undefined"，因为在此版本中未实现身份验证。
**Examples:**
JSON API Request::
```
GET /dalton/controller_api/v2/d1b3b838d41442f6/alert
```
JSON API Response:
.. code::
```
{
"data": "06/26/2017-12:08:13.255103 [**] [1:180043530:4] Nemucod Downloader
Trojan Request Outbound [**] [Classification:
A Network Trojan was detected] [Priority: 1] {TCP} 192.168.1.201:65430
-> 47.91.93.208:80\n\n06/26/2017-12:08:13.255103 [**] [1:180056733:3]
Suspicious HTTP Request to a *.top TLD - Outbound [**] [Classification: Potentially
Bad Traffic] [Priority: 2] {TCP} 192.168.1.201:65430 -> 47.91.93.208:80\n
\n06/26/2017-12:08:13.646674 [**] [1:180043530:4] Nemucod Downloader
Trojan Request Outbound [**] [**] [Classification:
A Network Trojan was detected] [Priority: 1] {TCP} 192.168.1.201:65430
-> 47.91.93.208:80\n\n",
"error_msg": null,
"error": false
}
```
JSON API Request::
```
GET /dalton/controller_api/v2/ae42737ab4f52862/ninjalevel
```
JSON API Response:
.. code:: javascript
```
{"data": null, "error_msg": "No data found for 'ninjalevel' for Job ID ae42737ab4f52862", "error": true}
```
RAW API Request::
```
GET /dalton/controller_api/v2/ae42737ab4f52862/alert/raw
```
RAW API Response:
.. code::
```
12/16/2019-20:03:24.094114 [**] [1:806421601:0] MyMalware C2 Request Outbound [**]
[Classification: (null)] [Priority: 3] {TCP} 192.168.102.203:45661 -> 172.16.31.41:80
```
## Controller API
除了提供有关已提交任务的信息外，Dalton API 还包括从 Controller 提取信息和执行有限操作的能力。以下路由可以通过 HTTP GET 请求访问。此处未提供完整示例，但可以通过在 Web 浏览器中发出请求轻松获取。
- | **/dalton/controller_api/request_engine_conf?sensor=**
| 以文本形式返回请求的配置文件。 值将是引擎、版本，以及（如果适用）自定义配置文件名，用正斜杠分隔。例如：``suricata/5.0.0`` 或 ``suricata/5.0.0/mycustomconfig.yaml``。使用 Rust 支持编译的 Suricata 4.x 版本将在版本前加上前缀 "rust\_"，例如 ``suricata/rust_4.1.5``。
| 如果在磁盘上找不到配置文件的精确匹配项，则返回最接近的匹配文件。
- | **/dalton/controller_api/delete-old-job-files**
| 从磁盘删除旧的任务文件。返回删除的文件数。
有关更多信息，请参阅 `Job Queue <#job-queue>`__ 部分。
- | **/dalton/controller_api/job_status/**
| 返回对应于任务当前状态的字符串。这主要由 Web 浏览器在任务运行时使用。请参阅 `Job API <#job-api>`__ 部分中的 'status' 密钥信息。
- | **/dalton/controller_api/job_status_code/**
| 返回给定 jobid 的任务状态代码。这是作为字符串返回的任务状态代码编号。
| 有关更多详细信息，请参阅 `Job API <#job-api>`__ 部分中有关 'statcode' 的信息。
- | **/dalton/controller_api/get-current-sensors/**
| 返回 JSON 响应，其中 'sensor_tech' 作为根元素，包含当前活动传感器的数组，根据规则集文件名降序排序（就像 Web 界面中的列表一样）。
| 应该是 ``suricata``、``snort`` 或 ``zeek``。
| 示例响应：
.. code:: javascript
```
{"sensor_tech": ["suricata/4.0.1", "suricata/3.2.4", "suricata/2.0.9"]}
```
- | **/dalton/controller_api/get-current-sensors-json-full**
| 响应是包含有关所有当前活动传感器（代理）详细信息的 JSON 负载。信息包括代理 IP、上次签到时间、tech（例如 ``suricata/4.0.1``）等。
- | **/dalton/controller_api/get-prod-rulesets/**
| 返回控制器上给定引擎的当前可用生产规则集列表。该列表包含控制器上规则文件的完整路径。
| 应该是 ``suricata`` 或 ``snort``
| 示例响应：
.. code:: javascript
```
{"prod-rulesets": [
"/opt/dalton/rulesets/suricata/SCWX-20171024-suricata-security.rules",
"/opt/dalton/rulesets/suricata/SCWX-20171024-suricata-malware.rules",
"/opt/dalton/rulesets/suricata/ET-20171023-all-suricata.rules"
]
}
```
- | **/dalton/controller_api/get-max-pcap-files**
| 返回控制器配置为每次任务提交处理的最大 pcap（或存档）文件数。这由 dalton.conf 中的 ``max_pcap_files`` 选项设置，了解这一点有助于确保以编程方式提交的所有 pcap 都将被处理。单个存档文件，即使它可以包含多个 pcap，在此上下文中也仅被视为单个文件。
- | **/dalton/sensor_api/get_job/**
| 返回任务 zip 文件，其中包括 引用的任务使用的 pcap、规则、配置文件和清单。如果 无效或发生错误，则返回 HTML 错误页面。
## Dalton API 客户端
``api/dalton.py`` 中添加了一个 API Client，它使用 Python requests 执行 API 调用。该客户端仅限于 GET 和 POST 请求。
## 使用 API 提交作业
有一个选项可以使用 HTTP POST 请求以编程方式提交任务。提交任务的端点是 ``/dalton/coverage/summary``。
POST 请求的 json 负载中需要包含的强制性附加参数如下：
.. code:: javascript
data = {
"sensor_tech": ,
"optionProdRuleset": "prod",
"prod_ruleset": ,
"custom_engineconf": ,
"teapotJob": 1
}
上面的示例指示了提交任务的最小数据负载。您需要确保拥有正确的传感器技术名称。您可以使用 API 调用：``GET /dalton/controller_api/v2//tech/raw`` 来检索特定的传感器技术。
规则路径是 ``/opt/dalton/rulesets//``，其中传感器可以是：suricata、zeek、snort，文件名是包含该传感器所有规则的文件的名称。
还需要使用以下格式提交文件：
.. code:: javascript
files = {"coverage-pcap*": (, )}
您可以在一个任务中上传最多 10 个文件，因此将 * 替换为 0-9 的数字。
您需要将文件字节读入 pcap_bytes 变量，并且您可以选择包含 ``pcap_filename``。
如果您计划在短时间内进行多次调用以获得更好的性能，请将任务作为短期 ``teapotJob`` 提交。
提交任务的其他有用参数是：
- ``custom_rules``，您可以在其中包含您可能希望用于任务测试的自定义规则，
- ``optionAlertDetailed``、``optionEveLog``、``optionOtherLogs``：如果您希望生成包含其他日志的任务，可以将这些设置为 ``True``。
示例脚本可以在 ``api/examples/submit_job.py`` 中找到。
# Teapot 作业
Dalton 具有所谓 "teapot" job 的概念和能力。Teapot job 是在 Redis 数据库中生存期短且（通常）在磁盘上生存期短的任务。
Teapot jobs 在提交大量任务和/或立即处理结果且不需要在之后保留它们的情况下非常有用。通常，这与使用 `Dalton API <#dalton-api>`__ 自动和/或快速处理结果的编程式任务提交结合使用。
此类任务提交是短暂且数量众多的。换句话说，又矮又胖。*就像一个小茶壶。*
Teapot jobs 在几个主要方面与常规任务不同：
- 结果保留时间比常规任务短。Teapot job 过期超时通过 ``dalton.conf`` 中的 ``teapot_redis_expire`` 选项配置。
- Teapot jobs 使用 'teapotJob' POST 参数（带有任何值）提交。通过 Dalton Web UI 提交任务时，不会设置或提供此参数。
- Teapot jobs 的 job id ("JID") 以 'teapot\_' 开头。
- 提交 teapot job 会返回 JID，而不是重定向页面。
目前，如果 teapot jobs 尚未过期，它们将显示在 Dalton Web UI 队列中，尽管更改代码以将它们从列表中排除是相当简单的。
# 添加 Rulesets
对于每个 Dalton 任务，可以使用单个 'defined ruleset' 文件和/或 'custom rules'。自定义规则在 Web UI 中输入，但定义的规则集存储在磁盘上。
在 Dalton Controller 上，定义的规则集必须位于 ``dalton.conf`` 中的 ``ruleset_path`` 变量指定的目录中。默认情况下，这是 ``/opt/dalton/rulesets``。在该目录中，必须有一个放置 Suricata 规则的 ``suricata`` 目录和一个放置 Snort 规则的 ``snort`` 目录。规则集文件必须以 ``.rules`` 结尾。
如果默认的 ``ruleset_path`` 值未从 ``/opt/dalton/rulesets`` 更改，则运行 Dalton Controller 容器的主机上的 ``rulesets`` 目录（和子目录）与容器共享，因此可以轻松地从主机添加 '.rules' 文件。
流行的开源规则下载和管理工具，例如 `rulecat `__、`PulledPork `__ 和 `Suricata-Update `__，使得下载规则集、将所有规则合并到单个 ``.rules`` 文件中，然后将其存储在必要位置变得非常。
Dalton Controller 容器包含 rulecat（请参阅 ``dalton.conf`` 中的 ``rulecat_script`` 变量），当 Dalton Controller 首次启动时，如果不存在现有规则集，它将尝试从 `rules.emergingthreats.net `__ 下载最新的 Suricata 和 Snort 规则集。
# 添加 Sensors
向 Dalton 添加传感器是一个相当简单的过程。如果新传感器还没有对应或兼容的配置文件，则也需要添加该文件；有关更多信息以及将自定义配置文件用于特定传感器，请参阅 `Adding Sensor Configs <#adding-sensor-configs>`__。
除非使用自定义配置（请参阅 `Adding Sensor Configs <#adding-sensor-configs>`__），否则传感器根据其特定的引擎（Suricata 或 Snort）和版本（例如 5.0.0、2.9.9.0）请求任务。提交的任务根据用户界面中指定的（相应）“Sensor Version” 排队。所有适用的传感器从各自的队列中从 Controller 拉取任务，这意味着可以有多个相同类型（引擎和版本）的代理，它们都将从 Controller 上适当的共享队列中拉取任务，并按先到先得的原则接收/运行任务。
## Docker Sensors
``docker-compose.yml`` 文件包含用于构建各种 Suricata 和 Snort 版本的 Dalton Agents 的指令。传感器引擎（Suricata 或 Snort）是从源代码构建的。要添加新版本或不同版本，只需复制现有规范之一，并根据需要更改版本号。例如，以下是 Suricata 3.2.3 的规范：
.. code:: yaml
```
agent-suricata-3.2.3:
build:
context: ./dalton-agent
dockerfile: Dockerfiles/Dockerfile_suricata
args:
- SURI_VERSION=3.2.3
- http_proxy=${http_proxy}
- https_proxy=${https_proxy}
- no_proxy=${no_proxy}
image: suricata-3.2.3:latest
container_name: suricata-3.2.3
environment:
- AGENT_DEBUG=${AGENT_DEBUG}
restart: always
```
要添加 Suricata 4.0.2 的规范（如果存在），只需将 ``SURI_VERSION`` arg 值从 '3.2.3' 更改为 '4.0.2'。这将导致下载并构建该版本的 Suricata。服务名称（例如 'agent-suricata-3.2.3'）容器名称和镜像名称也应更新为唯一的。可以通过保持 ``SURI_VERSION`` 和镜像名称相同但使用不同的服务和容器名称来运行具有相同引擎/版本的多个代理。
Suricata 4.0.2 规范示例：
.. code:: yaml
```
agent-suricata-4.0.2:
build:
context: ./dalton-agent
dockerfile: Dockerfiles/Dockerfile_suricata
args:
- SURI_VERSION=4.0.2
- http_proxy=${http_proxy}
- https_proxy=${https_proxy}
- no_proxy=${no_proxy}
image: suricata-4.0.2:latest
container_name: suricata-4.0.2
environment:
- AGENT_DEBUG=${AGENT_DEBUG}
restart: always
```
Rust 支持是在 Suricata 4.0 中添加的，但它是可选的。从 Suricata 5.0.0 开始，Rust 是强制性的。要为 Suricata 4.x Agent 启用 Rust 支持，请在 docker-compose 文件中为该特定代理规范将 ``ENABLE_RUST`` arg 设置为 ``--enable-rust``（请参见下面的示例）。具有 Rust 支持的 Suricata 4.x Agents 将在 Web UI 中与字符串 "with Rust support" 一起显示。
具有 Rust 支持的 Suricata 4.1.4 规范示例：
.. code:: yaml
```
agent-suricata-4.1.4-rust:
build:
context: ./dalton-agent
dockerfile: Dockerfiles/Dockerfile_suricata
args:
- SURI_VERSION=4.1.4
- http_proxy=${http_proxy}
- https_proxy=${https_proxy}
- no_proxy=${no_proxy}
- ENABLE_RUST=--enable-rust
image: suricata-4.1.4-rust:latest
container_name: suricata-4.1.4-rust
environment:
- AGENT_DEBUG=${AGENT_DEBUG}
restart: always
```
Suricata 也可以使用 ``SURI_VERSION=current``，在这种情况下，将使用最新的 Suricata 版本构建代理。在 ``docker-compose.yml`` 文件中拥有 'current' Suricata 版本规范特别方便，因为当新版本发布时，只需运行 ``start-dalton.sh`` 脚本，就会构建并可用具有最新 Suricata 版本的新 Dalton Agent。
Snort 代理也是一样的，但用于自定义的参数是 ``SNORT_VERSION`` 和 ``DAQ_VERSION``（如果更改）。Snort 规范示例：
.. code:: yaml
```
# Snort 2.9.11 from source
agent-snort-2.9.11:
build:
context: ./dalton-agent
dockerfile: Dockerfiles/Dockerfile_snort
args:
- SNORT_VERSION=2.9.11
- DAQ_VERSION=2.0.6
- http_proxy=${http_proxy}
- https_proxy=${https_proxy}
- no_proxy=${no_proxy}
image: snort-2.9.11:latest
container_name: snort-2.9.11
environment:
- AGENT_DEBUG=${AGENT_DEBUG}
restart: always
```
Suricata Agents 应该基于 Suricata Dockerfile ``Dockerfiles/Dockerfile_suricata_rust`` 构建。
Snort Agents 应该基于 ``Dockerfiles/Dockerfile_snort`` 的 Snort Dockerfile 构建。
## 非 Docker Sensors
传感器不必是 Docker 容器或 docker-compose 网络的一部分即可被 Dalton Controller 使用；它们只需能够访问并与 Docker Controller Web 服务器通信。
Suricata 或 Snort 机器可以相当容易地转变为 Dalton Agent。要求：
- 引擎（Suricata 或 Snort）
- Python 3.6 或更高版本
- ``dalton-agent.py``
- ``dalton-agent.conf``
必须修改 ``dalton-agent.conf`` 文件以指向 Docker Controller（请参阅 ``DALTON_API`` 选项）。
有关 Dalton Agent 配置选项的更多详细信息，请参阅 ``dalton-agent.conf`` 文件中的内联注释。
要启动 Dalton Agent，请运行 dalton-agent.py::
```
Usage: dalton-agent.py [options]
Options:
-h, --help show this help message and exit
-c CONFIGFILE, --config=CONFIGFILE
path to config file [default: dalton-agent.conf]
```
# 添加 Sensor 配置
传感器配置文件（例如 ``suricata.yaml`` 或 ``snort.conf``）存储在 Dalton Controller 上。当传感器向 Controller 签到时，它会在 Redis 中注册，当为 Dalton 任务选择该传感器时，将加载相应的配置文件，填充在 Web UI 中的 ``Config Files`` 垂直选项卡下，并与 Dalton 任务一起提交。
Dalton Controller 使用 ``dalton.conf`` 中的 ``engine_conf_path`` 变量作为文件系统上的起始位置来查找要使用的传感器配置文件。在该目录中，必须有一个放置 Suricata ``.yaml`` 文件的 ``suricata`` 目录和一个放置 Snort ``.conf`` 文件的 ``snort`` 目录。
默认情况下，在 Controller 上，``engine_conf_path`` 设置为 ``/opt/dalton/app/static/engine-configs``，该目录从 ``/opt/dalton/engine-configs`` 进行符号链接。Dalton Controller 和主机也共享 ``engine-configs`` 目录，以便根据需要轻松地从主机添加配置文件。
建议不要更改 ``engine_conf_path``，因为 Flask 会在 ``static`` 目录中查找以提供配置文件，更改它很可能会破坏某些东西。
构建代理或运行 Controller 时，不会自动添加传感器配置文件；它们必须手动添加。但是，Dalton Controller 已经附带 Suricata 版本 0.8.1 及更高版本以及 Snort 2.9.0 及更高版本的默认（来自源代码）配置文件。不包含重复的配置文件。例如，由于所有 Suricata 1.4.x 版本都具有相同的（默认）.yaml 文件，因此仅包含 "suricata-1.4.yaml"。
Controller 尝试根据传感器引擎（Suricata 或 Snort）和版本号（例如 5.0.0、2.9.9.0）查找要加载/使用的配置文件。
例如，如果代理运行的是 Suricata 版本 5.0.0，则 Controller 将在 ``engine-configs/suricata/`` 目录中查找名为 "suricata-5.0.0.yaml" 的文件。如果找不到精确匹配项，它将尝试根据版本号查找尽可能接近的匹配项。
如果特定传感器希望使用自定义配置，请在代理的 ``dalton-agent.conf`` 文件中设置 ``SENSOR_CONFIG`` 变量，并将同名文件放置在 Controller 上的 ``engine-configs/suricata/`` 目录（对于 Suricata）或 ``engine-configs/snort/`` 目录（对于 Snort）中。如果 ``SENSOR_CONFIG`` 值与 Controller 上的配置文件不完全匹配，Controller 将查找文件名为 SENSOR_CONFIG 值且扩展名为 ".yaml"、".yml" 和 ".conf" 的文件。
对于新的 Suricata 版本，源代码中的 ``.yaml`` 文件应该直接添加到 ``engine-configs/suricata`` 目录并适当命名。对于新的 Snort 版本，建议将默认 ``.conf`` 文件通过 ``engine-configs/`` 目录中的 ``clean_snort_config.py`` 脚本运行::
```
Usage:
python clean_snort_config.py
```
# 日志记录和调试
默认情况下，Dalton Controller 记录到 ``/var/log/dalton.log``，Dalton Agents 记录到 ``/var/log/dalton-agent.log``。nginx 容器记录到 ``/var/log/nginx`` 目录（``dalton-access.log`` 和 ``dalton-error.log``）。Dalton Agents 对 nginx 容器进行的（频繁）轮询以检查新任务是有意不记录的，因为它被认为太嘈杂。
对于 Dalton Controller，可以在 ``dalton.conf`` 文件中或通过设置 ``CONTROLLER_DEBUG`` 环境变量（例如 ``CONTROLLER_DEBUG=1``）启用调试。这也可以在容器构建过程中传递并在 ``.env`` 文件中设置。如果配置文件或环境变量之一设置了调试，则将启用调试日志记录。
对于 Dalton Agents，可以在 ``dalton-agent.conf`` 文件中或通过设置 ``AGENT_DEBUG`` 环境变量（例如 ``AGENT_DEBUG=1``）启用调试。这也可以在容器构建过程中传递并在 ``.env`` 文件中设置。如果配置文件或环境变量之一设置了调试，则将启用调试日志记录。
# Flowsynth WebUI
Dalton 包含一个 `Flowsynth `__ 的 Web UI，这是一个促进网络数据包捕获创建的工具。Flowsynth Web UI 使建模网络流量并针对 Dalton Agent 进行测试变得非常简单。
可以通过 Dalton 工具栏中的 'Flowsynth' 链接或直接使用 '/flowsynth' URI 路径访问 Flowsynth WebUI。
Flowsynth UI 有两种操作模式：Build 和 Compile。Build 模式提供了一个类似向导的界面，用于创建某些类型的 pcap。Compile 模式提供了与 flowsynth 编译器的直接接口，允许直接在 UI 中构建 synth 文件。
## Build Mode
Flowsynth Build 模式允许使用一些合理的默认值快速生成 pcap。在 'Network Layer' 垂直选项卡上，可以选择源和目标 IP 范围。从这些范围中随机选择一个 IP 地址。在 'Transport Layer' 垂直选项卡上，可以选择 TCP 和 UDP，并可选择通过三次握手建立 TCP 连接。目标和源端口是随机选择的，也可以显式设置。'Payload' 垂直选项卡允许用户轻松构建一些常见的负载。向导生成 flowsynth 语法语言，并用内容填充 'Compile' 选项卡，以便在编译之前允许任何最后的更改。
二进制、不可打印和可打印字节可以使用十六进制转义序列表示。此类编码在编译 pcap 时转换为其代表性字节。例如，'\x41' 变为 'A'。
#### Raw Payload
原始负载向导允许用户快速建模客户端和服务器之间的双向通信。它通常用于建模自定义协议和/或二进制协议。
#### HTTP Payload
HTTP 向导使构建 HTTP 客户端请求和 HTTP 服务器响应变得简单。该负载提示输入两种类型的输入：HTTP 头部分和 HTTP 正文部分。如果选择了 'Autocompute request Content-Length header' 和/或 'Autocompute response Content-Length header'，向导将根据 HTTP 正文数据计算并添加 Content-Length 头。如果 HTTP 头数据中已存在 Content-Length 头，它将被更新以反映相应 HTTP 正文的正确大小。如果请求正文为空，则 *不会* 添加 "Content-Length: 0" 头；如果响应正文为空，则 *会* 添加 "Content-Length: 0" 头。
#### Certificate Payload
证书向导使得使用用户提供的证书生成部分 SSL/TLS 握手变得非常简单。
## Compile Mode
Compile 模式提供了与 flowsynth 编译器的直接接口，允许直接在 UI 中构建 synth 文件。Compile 模式 UI 由 Build 模式向导填充。提交 synth 后，将生成 pcap 并提供下载链接。也可以直接从 Web 界面将 pcap 提交到 Dalton，以在 Suricata 或 Snort 任务中使用。
也可以通过 GET 或 POST 请求预填充 compile 页面。
示例 1：
.. code:: text
```
http://127.0.0.1/flowsynth/compile?flowsynth=_flowsynth_code_goes_here_
```
示例 2：
.. code-block:: html
```
```
# Zeek
从 Dalton 版本 3.2.0 开始，支持 Zeek 作为传感器。API 中的支持有限，无法在运行时从 UI 更改配置/规则集。但是，可以将 Zeek 脚本添加到规则集目录中，并在每次运行时执行。
# CyberChef
为了方便起见，Dalton 能够轻松构建和运行 `CyberChef `__ 完成的。有关更多详细信息，请参阅 `Packet Captures <#Packet-Captures>`__。
#. | **我可以拥有多个具有相同引擎/版本的代理吗？例如，我可以有多个运行 Suricata 4.0.1 的代理吗？**
| 当然。如果您使用代理容器和 Docker Compose，请确保服务和容器名称在传感器之间是唯一的。代理根据其 "TECHNOLOGY"（通常是引擎和版本）轮询 Dalton 控制器上的队列以获取任务，并且多个代理可以轮询同一队列。待处理任务交给第一个请求它们的代理。
#. | **为什么当我尝试构建 Snort 2.9.0 或 2.9.0.x 容器时，它在配置 Snort 时失败，说找不到 'dnet' 文件？**
| 尝试构建 Snort 2.9.0 和 2.9.0.x 将失败，因为 Autoconf 找不到 dnet 文件。这显然在 Snort 2.9.1 及更高版本中已修复。如果您真的想要 Snort 2.9.0 或 2.9.0.x Agent，您必须自己构建一个。Dalton Agent 代码应该可以在其上正常工作。如果结果是对 Snort 2.9.0.x Agents 的需求很大，将重新考虑添加对它的本机支持。
#. | **关于代码...你为什么那样做？你在想什么？你甚至知道面向对象编程吗？**
| 这些是有效的问题。许多代码是在多年前编写的，当时作者是 Python 新手，除了调整现有项目中的几行代码外从未编写过任何 Python 代码，并且不知道 Python 的面向对象支持。虽然此类代码可以被清理和重构，但很多代码保持原样，因为它已经可以工作，并且决定将时间和精力花在其他地方。此外，Dalton Agent 代码最初编写为在仅支持 Python 2.4 且无法使用非标准库的受限/自定义系统上运行。这一点在使用 urllib2 而不是 urllib3 或 Requests 时尤其明显（痛苦？）。因此，如果您确实查看代码，请求您怀着宽容的心态对待它。
#. | **我在 Dalton 中发现了一个错误。我该怎么办？**
| 随意报告它和/或修复它并提交拉取请求。
# 作者
- David Wharton
- Will Urbanski
## 贡献者
- Rob Vinson
- George P. Burdell
- Adam Mosesso
- Donald Campbell
欢迎反馈，包括错误报告、建议、改进、问题等。
标签：AMSI绕过, CyberChef, Docker, Flowsynth, Metaprompt, PB级数据处理, pcap, PCAP测试, Rootkit, SecOps, Suricata, Web界面, Zeek, 云安全架构, 传感器模拟, 入侵检测系统, 威胁检测, 安全数据湖, 安全运维, 安全防御评估, 搜索引擎查询, 流量回放, 现代安全运营, 网络安全, 规则测试, 规则验证, 请求拦截, 逆向工具, 隐私保护