rsvptr/firewall-logging-incident-response

## 演示视频 完整的操作演示和实机演示已在 YouTube 上（未公开）。点击缩略图观看： ## 目录 - [本项目的功能](#what-this-project-does) - [主要功能](#key-features) - [系统架构](#system-architecture) - [网络拓扑与虚拟机配置](#network-topology-and-vm-configuration) - [工作原理](#how-it-works) - [混合检测引擎](#the-hybrid-detection-engine) - [Playbook 引擎与决策逻辑](#the-playbook-engine-and-decision-logic) - [数据模型与仪表板](#data-model-and-dashboard) - [系统运行实况](#the-system-in-action) - [攻击者虚拟机：攻击套件](#attacker-vm-the-attack-suite) - [防火墙虚拟机：监控仪表板](#firewall-vm-the-monitoring-dashboard) - [蜜罐虚拟机：欺骗网络](#honeypot-vm-the-deception-network) - [受害者虚拟机：影响监控](#victim-vm-impact-monitoring) - [结果](#results) - [仓库结构](#repository-layout) - [获取源代码](#getting-the-source-code) - [运行系统](#running-the-system) - [配置](#configuration) - [局限性与未来工作](#limitations-and-future-work) - [致谢与参考文献](#acknowledgements-and-references) ## 本项目的功能 现代攻击是自动化的。僵尸网络和“即服务”平台可以在主机上线后的几分钟内扫描网络、发现服务并开始对其进行猛烈攻击。人类分析师阅读防火墙日志、关联事件并手动编写新规则是无法跟上这个速度的，而破坏就发生在从攻击开始到防御者做出反应的这段时间差内。 本项目通过让防火墙自主行动来消除这一时间差。这是一个概念验证系统，它可以监控实时网络流量，实时判断某些行为是否具有恶意，并在无需等待人工介入的情况下执行响应。这里的响应并非简单的阻断或允许开关。评分引擎会针对每个事件在两种策略之间进行选择： - **阻断 (Block)**：当威胁影响较大且没有情报价值时（例如 SYN flood、SMB 漏洞利用），直接彻底阻断该来源。 - **重定向 (Redirect)**：当活动看起来像是侦察或首次违规时，将来源重定向至蜜罐，以便系统在真实服务器不受影响的情况下收集情报。 检测由两个并行的引擎完成。基于规则的分析器可以在远小于一秒的时间内捕获已知的、高频的攻击。卷积神经网络（预训练的 [SecIDS-CNN](https://huggingface.co/Keyven/SecIDS-CNN) 模型，据报告准确率高达 97.72%）对已完成的网络流进行评分，以发现任何特征码都无法捕捉的异常。整个系统由 Web 仪表板驱动，实时显示事件、性能和系统健康状况，并配备了一个支持使用自然语言查询的 LLM 助手。 所有内容均使用开源工具构建，并在四台虚拟机的实验环境中进行了验证。 ## 主要功能 | 功能 | 说明 | |---|---| | **混合检测** | 结合基于规则的启发式算法（用于已知的 flood、扫描和 Web 攻击）与 CNN（用于基于流的异常检测）。 | | **智能响应** | 基于事件的评分算法在阻断与蜜罐重定向之间做出选择，而非固定的反应动作。 | | **Playbook 驱动** | 响应动作定义在 JSON playbook 中，无需修改 Python 代码即可更改行为。 | | **nftables 后端** | 遏制规则通过 Linux 内核的 `nftables` 框架以原子方式和批量模式应用。 | | **欺骗网络** | Cowrie、OpenCanary 和自定义诱饵接收被重定向的攻击者并记录其行为。 | | **实时仪表板** | Flask + Socket.IO 将实时图表、事件流和资源指标推送到浏览器。 | | **LLM 助手** | 由 OpenAI 支持的助手可以回答有关当前系统状态的自然语言问题。 | | **IDS / IPS 模式** | 可在仪表板上在仅监控检测与主动阻断之间切换。 | | **可量化** | 持续跟踪并绘制平均检测时间 (MTTD) 和平均遏制时间 (MTTC)。 | ## 系统架构 系统跨四台虚拟机运行，分别用于攻击者、防火墙、受害者和蜜罐。将它们分开可以迫使攻击者与内部网络之间的每个数据包都经过防火墙，以便对其进行检查和处理。 - **攻击者虚拟机 (Kali Linux)** 通过自定义的 Python 攻击套件发起所有恶意流量（DoS flood、暴力破解、端口扫描、SQLi/XSS、SMB 攻击，支持可选的 IP 欺骗）。 - **防火墙虚拟机 (Ubuntu 22.04)** 运行系统的核心。它在两个接口上捕获数据包，运行混合检测引擎和 playbook 引擎，操作实时的 `nftables` 规则集，并提供仪表板服务。 - **受害者虚拟机 (Ubuntu 22.04)** 代表受保护的生产服务器。它运行刻意留下漏洞的服务（SSH、FTP、Apache、MySQL、Samba 等）以及用于衡量攻击影响的监控脚本。 - **蜜罐虚拟机 (Ubuntu 22.04)** 提供欺骗层：包含 Cowrie、OpenCanary 以及模仿受害者服务并记录所有交互的自定义低交互诱饵。 ## 网络拓扑与虚拟机配置 三个虚拟网络对该实验环境进行了分段。来自“不受信任”的攻击者网络的流量，只有通过防火墙路由，才能到达“受保护”的局域网。 **网络与寻址** | 网络 | 子网 | 主机 | |---|---|---| | `ATTACKNET` (不受信任 / "互联网") | `192.168.32.0/24` | 攻击者 `192.168.32.2`，防火墙外部接口 `enp0s8` `192.168.32.1` | | `LAN` (受保护的内部网络) | `192.168.64.0/24` | 受害者 `192.168.64.2`，蜜罐 `192.168.64.3`，防火墙内部接口 `enp0s9` `192.168.64.1` | | `NAT Network` (互联网访问) | 无 | 防火墙 `enp0s3`，它伪装来自两个内部网络的流量 | 防火墙启用 IP 转发 (`net.ipv4.ip_forward=1`) 并使用 `nftables` 在两个网段之间转发流量，并通过 `enp0s3` 伪装 (NAT) 出站流量。 **虚拟机规格** | 角色 | 主机名 | 操作系统 | 资源 | 关键软件 | |---|---|---|---|---| | 攻击者 | `kali` | Kali Linux | 2 vCPU，4 GB 内存 | Python 3、Scapy、自定义攻击套件 | | 防火墙 | `firewall-vm` | Ubuntu 22.04 LTS | 4 vCPU，8 GB 内存 | Python 3、Scapy、nftables、TensorFlow、Flask | | 受害者 | `victim-vm` | Ubuntu 22.04 LTS | 2 vCPU，4 GB 内存 | Apache2、Nginx、MySQL、vsftpd、Samba、OpenSSH | | 蜜罐 | `honeypot-vm` | Ubuntu 22.04 LTS | 2 vCPU，4 GB 内存 | Cowrie、OpenCanary、自定义诱饵、dnsmasq | 该实验环境建立在 Oracle VirtualBox 中。本 README 涵盖了相关软件及其运行方式；报告中对虚拟机的构建有更详细的描述。 ## 工作原理 ### 混合检测引擎 数据包捕获与分析是解耦的，这样突发的流量绝不会阻塞检测。Scapy 嗅探线程将捕获的每个数据包放入一个线程安全的内存缓冲区中，另一个单独的工作线程从该缓冲区中提取数据并进行分析。 两条检测路径并行运行： **基于规则的分析** (`detection/analyzer.py`) 根据阈值和特征码检查每个数据包，以提供即时、低延迟的判定。`core/config.py` 中内置的阈值如下： | 攻击 | 触发条件 | |---|---| | SYN flood | 5 秒内向同一目标发送 > 100 个 SYN 数据包 | | UDP flood | 5 秒内 > 200 个 UDP 数据包 | | ICMP flood | 5 秒内 > 100 个 ICMP 数据包 | | 端口扫描 | 3 秒内来自同一源的 > 15 个唯一端口 | | 暴力破解 | 300 秒窗口内单服务尝试次数超标（SSH 30次，FTP 25次，MySQL 20次等） | | Web 攻击 | HTTP 负载中匹配到 SQLi 和 XSS 的正则特征码 | **机器学习分析** (`detection/ml_engine.py`) 通过其 5 元组（源 IP、目标 IP、源端口、目标端口、协议）跟踪每个网络流。一旦某个流处于空闲状态，就会提取十个统计特征（持续时间、数据包计数、总字节数、数据包大小的平均值和标准差、数据包速率和字节速率等），进行归一化处理后输入到 SecIDS-CNN 模型中。分数高于 `0.85` 即标记该流为异常，这就是系统捕捉任何特征码都无法描述的隐蔽或新型行为的方式。 核心模块及其关系： ### Playbook 引擎与决策逻辑 当任一引擎检测到威胁时，它会产生一个 `AttackEvent`，并将其交给 `PlaybookEngine` (`playbook/engine.py`)。该引擎会加载匹配的 JSON playbook 并依次执行其中设定好优先级的操作。 最有趣的部分是在遏制与欺骗之间做出的选择。引擎不是采用固定的规则，而是根据四个因素为每个事件计算一个分数，然后根据分数的正负决定是重定向到蜜罐还是进行阻断： | 因素 | 对分数的影响 | |---|---| | **攻击类型** | 侦察、SSH 暴力破解、Web 探测会提高分数（值得观察）；SYN flood、SMB 漏洞利用会降低分数（见即阻断）。 | | **严重程度** | 低或中等提高分数高或严重降低分数。 | | **攻击者历史记录** | 首次违规者提高分数（值得观察）；具有多次攻击记录的惯犯降低分数（升级为阻断）。 | | **系统负载** | CPU 超过 80% 时降低分数，倾向于选择成本更低的阻断而不是重定向。 | 像 `block_ip` 和 `honeypot_redirect` 这样的动作会生成 `nft` 命令，这些命令被批量并原子化地应用，因此规则集永远不会处于不一致的状态。阻断会将源添加到具有时效性的 `nftables` 集合中；重定向会安装一条 DNAT 规则，将攻击者透明地转发到蜜罐。以下是一个为了让结构更清晰而经过精简的 playbook 示例： ``` { "id": "pb_syn_flood", "name": "SYN Flood DDoS Response", "trigger": "syn_flood", "mitre_technique": "T1499.001", "actions": [ { "type": "block_ip", "params": { "duration": 1800, "scope": "global" }, "priority": 1 }, { "type": "syn_cookies","params": { "enable": true }, "priority": 2 }, { "type": "rate_limit", "params": { "limit": "50/second", "per_ip": true }, "priority": 3 }, { "type": "alert", "params": { "severity": "critical" }, "priority": 5 } ], "severity": "critical" } ``` 防火墙内置了十个 playbook，涵盖 SYN/UDP/ICMP flood、端口扫描、暴力破解、SMB 攻击、Web 攻击、DNS 隧道、ML 异常流以及一个默认的兜底策略。 ### 数据模型与仪表板 每个事件、指标和流量转移都通过连接池和异步写入线程写入 SQLite 数据库，因此检测线程永远不会因为磁盘 I/O 而阻塞。 仪表板与监控器是刻意解耦的。核心监控器 (`fw_monitor_v2.py`) 从不直接接触 Web 层；它通过一个轻量级的客户端模块将事件和指标发布到仪表板的 API。仪表板后端 (`dashboard.py`) 是一个 Flask 应用，它为控制动作提供 REST API，并托管一个 Socket.IO 服务器，将实时数据推送到浏览器。 ## 系统运行实况 下面的截图按机器进行了分组。在 [`Screenshots/`](Screenshots) 文件夹中还有更多截图，演示视频中包含了所有内容的实机展示。 ### 攻击者虚拟机：攻击套件 攻击套件是一个菜单驱动的 Python 工具。它将可欺骗的攻击（使用随机源 IP 的 flood 和扫描）与不可欺骗的攻击（需要真实连接的暴力破解和漏洞利用）分开，并且可以验证欺骗是否在虚拟网络中真正生效。

A quick spoofed-only attack burst.	A combined attack mixing real and spoofed traffic.
Verifying that IP spoofing works.	The spoofing configuration menu.

### 防火墙虚拟机：监控仪表板 该仪表板是一个通过 WebSocket 进行更新的单页应用。页面顶部是关键指标网格；其余部分是用于显示事件、攻击者、性能趋势和系统健康状况的一系列小部件。

Attack distribution by type.

Top attacker IPs.

Currently blocked IP addresses.	Honeypot diversion tracker showing redirected attackers.
Performance metrics over time.	MTTD and MTTC trend visualization.
Network interface TX/RX rates.	Firewall CPU and memory usage.

LLM 助手位于这些小部件旁边。您可以用简单的英语询问它有关系统当前状态的问题，它会根据实时数据进行回答。 操作员还可以测试蜜罐连通性、导出数据，并直接从界面中清除日志或规则。

Honeypot connectivity test result.

Export menu.

Clear data and rules menu.

导出支持多种格式：

Metrics and firewall log as JSON.

Firewall log as a text file.

Metrics as CSV.

### 蜜罐虚拟机：欺骗网络 被重定向的攻击者会落入一组低交互的蜜罐中，这些蜜罐伪装成受害者的真实服务。测试脚本会确认每个服务是否已启动，分析脚本会总结蜜罐捕获的内容。 防火墙将真实的服务端口映射到蜜罐端口，如下所示： | 真实服务 | 真实端口 | 蜜罐端口 | 处理程序 | |---|---|---|---| | SSH | 22 | 2222 | Cowrie | | Telnet | 23 | 2223 | Cowrie | | FTP | 21 | 2121 | OpenCanary | | MySQL | 3306 | 3307 | OpenCanary | | RDP | 3389 | 3390 | OpenCanary | | HTTP | 80 | 8080 | OpenCanary | | SMB | 445 | 4445 | 自定义 Python 诱饵 | | DNS | 53 | 5353 | dnsmasq / iptables 重定向 |

Honeypot service test suite output.

Honeypot log analysis and report generation.

### 受害者虚拟机：影响监控 受害者在攻击期间运行后台监控程序，记录服务正常运行时间、资源使用情况和连接统计信息。停止监控器 (Ctrl+C) 会触发一个报告生成器，将原始日志转换为文本安全报告和一组图表。

Report generation in progress.

Report generation complete.

The generated text-based security report.

The generated performance graphs.

## 结果 该系统经历了来自 Kali 虚拟机的两种攻击场景的测试： - **场景 A（欺骗突发）：** 长达 60 秒的侦察和 DoS 突发攻击，来自 417 个唯一的欺骗 IP 地址，涵盖 77 种攻击向量。 - **场景 B（持续混合攻击）：** 长达 150 秒的攻击战役，将攻击者的真实 IP 与 290 个欺骗 IP 混合（总共 504 个地址），结合了网络 flood 与针对性的 SSH 暴力破解。 在这两个场景中，系统共处理了 **5,379 个检测到的攻击事件**，执行了 **891 次 IP 阻断动作**，执行了 **100 多次蜜罐重定向**，蜜罐记录了 **703 次被转移的连接**。 按攻击类型划分的响应时间： | 攻击类型 | 检测方法 | 平均 MTTD (秒) | 平均 MTTC (秒) | 主要响应 | |---|---|---:|---:|---| | SYN flood | 基于规则 | 1.8 | 0.9 | 阻断 IP | | UDP flood | 基于规则 | 2.1 | 1.1 | 阻断 IP | | 端口扫描 | 基于规则 | 3.5 | 2.4 | 蜜罐重定向 | | SSH 暴力破解 | 基于规则 | 8.2 | 4.1 | 蜜罐 / 阻断 | | SQL 注入 | 基于规则 | 0.5 | 0.3 | 阻断 IP 和端口 | | 异常流 | ML (CNN) | 8.3 | 5.2 | 蜜罐 / 阻断 | 权衡在表格中显而易见。针对单个数据包的基于规则的检测几乎是瞬间的；CNN 速度较慢，因为它需要等待一个流的完成，但它能捕捉到特征码永远无法捕捉到的东西。即使在混合攻击的峰值负载期间，MTTD 最高也仅为 10.6 秒，MTTC 为 8.9 秒。 受保护服务器的代价保持在较低水平。在攻击期间的受害者虚拟机上，CPU 平均为 **5.6%**（峰值为 34.6%），内存平均为 **60.4%**，这表明防火墙吸收了绝大部分流量，而不是让其耗尽受害者资源。 ## 仓库结构 ``` . ├── Source Code/ │ ├── firewall_machine/ # Core IDS/IPS, playbook engine, dashboard (firewall-vm) │ │ ├── fw_monitor_v2.py # Main monitor: capture + detect + respond │ │ ├── dashboard.py # Flask + Socket.IO backend │ │ ├── ai/assistant.py # LLM security assistant │ │ ├── core/ # config, models, metrics, utils │ │ ├── detection/ # analyzer.py, detector.py, ml_engine.py │ │ ├── playbook/engine.py # Response orchestrator │ │ ├── playbooks/*.json # Per-attack response playbooks │ │ ├── database/ # SQLite manager + queries │ │ ├── models/SecIDS-CNN.h5 # Pre-trained CNN model │ │ ├── monitoring/ # Dashboard client + metrics │ │ ├── templates/dashboard.html │ │ └── requirements.txt │ ├── attacker_machine/ # Modular attack suite (kali) │ │ ├── attack_engine_v2.py # Interactive CLI │ │ ├── attack_launcher.sh # Scenario launcher menu │ │ ├── scripts/ # dos, bruteforce, recon, web, smb, ip_spoofer ... │ │ ├── configs/ # attack_config.json, wordlists.json │ │ └── requirements.txt │ ├── victim_machine/ # Vulnerable services + impact monitoring (victim-vm) │ │ ├── start_monitoring.sh # Launch monitors; report on exit │ │ ├── verify_services.sh # Service + security audit │ │ ├── monitoring/scripts/ # connection_monitor, service_monitor, generate_report │ │ └── data/ # Decoy credentials, SQL dump, documents (honeytokens) │ └── honeypot_machine/ # Deception network (honeypot-vm) │ └── scripts/ # web_honeypot, smb_honeypot, tarpit, log_aggregator, │ # analyze_honeypot_logs, test_honeypots ... ├── Diagrams/ # Architecture and design diagrams ├── Screenshots/ # Attacker / Firewall / Honeypot / Victim screenshots ├── Firewall Logging & Incident Response - MEng Project Report.pdf ├── Firewall Logging & Incident Response - MEng Project Presentation.pdf ├── Report (Text Version).txt └── Presenation (Text Version).txt ``` ## 获取源代码 克隆仓库： ``` git clone https://github.com//.git cd "" ``` 每台机器在 `Source Code/` 下都有自己独立的文件夹。将相关文件夹复制到对应的虚拟机（例如，`Source Code/firewall_machine/` 复制到防火墙虚拟机）。按照[网络拓扑](#network-topology-and-vm-configuration)章节和报告中的描述，设置四台虚拟机和三个虚拟网络。 全文假设您已配置好 Python 3.10 并且每台机器都有虚拟环境。 ## 运行系统 按以下顺序启动机器：首先是防火墙（负责路由和防御），然后是蜜罐和受害者（受保护的对象），最后是攻击者。请调整下方的 IP 地址、接口名称和文件路径，以匹配您自己的环境。 ### 1. 防火墙虚拟机 (`firewall-vm`) 它需要 root 权限才能进行数据包捕获和编辑 `nftables`。 ``` # 在防火墙 VM 上，从 firewall_machine 文件夹中 python3 -m venv venv && source venv/bin/activate pip install -r requirements.txt # 启用两个内部网络之间的路由 sudo sysctl -w net.ipv4.ip_forward=1 # 从报告（Listing 4.1）中带注释的规则集创建 nftables.conf； # 它没有包含在 repo 中。它定义了 zones、blocklist sets，以及 # response engine 操作的 NAT/DNAT chains。然后加载它： sudo nft -f nftables.conf # （可选）启用 LLM 助手 export OPENAI_API_KEY="sk-..." # 启动 dashboard backend（绑定 0.0.0.0:5000） python dashboard.py # 在第二个终端中，启动 monitor（需要 root 权限以进行 sniffing + nft） sudo -E python fw_monitor_v2.py ``` 从受害者或蜜罐虚拟机（或通过攻击者的 SSH 隧道）在浏览器中打开 **`http://192.168.64.1:5000`** 上的仪表板。从仪表板中在 IDS（仅监控）和 IPS（主动阻断）之间切换。 ### 2. 蜜罐虚拟机 (`honeypot-vm`) Cowrie、OpenCanary 和 dnsmasq 作为它们自己的服务运行（通常在 systemd 下），而自定义诱饵则从 `scripts/` 运行。一切启动后，请验证它： ``` # 在 honeypot VM 上，从 honeypot_machine 文件夹中 ./scripts/test_honeypots.sh # Checks every honeypot service and port # 测试运行后，总结 honeypots 捕获的内容 python3 scripts/analyze_honeypot_logs.py ``` `scripts/log_aggregator.py` 会追踪每个蜜罐的日志，并将新条目集中到分析脚本读取的聚合日志中。 ### 3. 受害者虚拟机 (`victim-vm`) ``` # 在 victim VM 上，从 victim_machine 文件夹中 python3 -m venv venv && source venv/bin/activate pip install -r requirements.txt # 确认 vulnerable services 并查看快速的 security audit ./verify_services.sh # 开始监控（需要 sudo）。按 Ctrl+C 停止并自动生成 # 位于 monitoring/reports 和 monitoring/graphs 下的报告和图表 sudo ./start_monitoring.sh ``` ### 4. 攻击者虚拟机 (`kali`) ``` # 在 Kali VM 上，在 ~/attacker_project 目录下 python3 -m venv venv && source venv/bin/activate pip install -r requirements.txt # 交互式场景菜单（spoofed storm、stealth、combined、utilities） sudo ./attack_launcher.sh # 或直接运行某个场景 sudo python attack_engine_v2.py --scenario spoofed --duration 60 sudo python attack_engine_v2.py --scenario quick python attack_engine_v2.py --scenario stealth ``` 可欺骗的场景（flood、扫描）使用随机的源 IP；隐蔽攻击和凭证攻击会使用攻击者的真实 IP，因为它们需要真实的连接。在攻击运行时观察防火墙仪表板，可以实时查看检测和遏制过程。 ## 配置 大多数行为都集中在 `Source Code/firewall_machine/core/config.py` 中，并且可以通过环境变量覆盖： | 变量 | 默认值 | 用途 | |---|---|---| | `OPENAI_API_KEY` | 无 | 启用 LLM 助手（如果未设置，则回退到基于规则的本地响应器）。 | | `FLASK_HOST` / `FLASK_PORT` | `0.0.0.0` / `5000` | 仪表板绑定地址和端口。 | | `DB_PATH` / `LOG_PATH` | `/var/log/firewall/...` | 数据库和日志位置。 | | `HONEYPOT_IP` | `192.168.64.3` | 欺骗网络的重定向目标。 | | `ENABLE_ML` | `true` | 打开或关闭 CNN 异常检测引擎。 | | `BLOCK_INTERNAL` | `false` | 是否处理源自局域网内部的攻击。 | 检测阈值、蜜罐端口映射、ML 异常阈值 (`0.85`) 以及 OpenAI 模型 (`gpt-5-mini`) 均在同一文件中设置。响应行为存在于 `playbooks/` 下的 JSON 文件中，因此您无需编辑 Python 代码即可重新调整响应策略。 ## 局限性与未来工作 这是一个概念验证系统，是在受控的四台虚拟机实验环境中测试的，而不是在生产网络中。已知的局限性以及未来的改进方向如下： - **仅在实验环境中验证。** 它尚未面对过企业级的流量或真实应用流量的干扰。下一步：在高吞吐量网络上进行基准测试。 - **静态 ML 模型。** SecIDS-CNN 模型是预训练的，没有在线学习能力，因此随着流量的演变，准确率可能会发生漂移。下一步：建立由确认的恶意蜜罐数据提供支持的重新训练 pipeline，形成闭环。 - **规避检测。** 未针对碎片化、混淆、加密通道或保持在阈值以下的“低速慢速”攻击进行测试。下一步：进行数据包重组并制定更具适应性的有状态规则。 - **依赖外部 LLM。** 助手的全部功能需要 OpenAI API 支持，这使其无法用于物理隔离的环境。下一步：采用本地托管的模型。 - **仅支持 IPv4。** 未分析 IPv6 流量。下一步：将分析、规则生成和数据模型扩展到 IPv6。 有关迈向实际应用（打包为服务、集成 SIEM、基于角色的访问控制、更高性能的捕获路径）的强化步骤，请参阅报告中的讨论章节。 ## 致谢与参考文献 本项目是在利莫瑞克大学 **Reiner Dojen 博士** 的指导下完成的它建立在许多开源框架的基础之上：Scapy、TensorFlow/Keras、Flask、nftables、Cowrie 和 OpenCanary。 异常引擎使用了 Keyvan Hardani 开发的 **SecIDS-CNN** 模型： 完整的文献综述、方法论、评估和完整的参考文献列表请参见[项目报告](Firewall%20Logging%20%26%20Incident%20Response%20-%20MEng%20Project%20Report.pdf)。如需简要概述，请参阅[演示幻灯片](Firewall%20Logging%20%26%20Incident%20Response%20-%20MEng%20Project%20Presentation.pdf)，如需实机演示，请观看[视频](https://www.youtube.com/watch?v=ULtjVgPi884)。

为 LK473 网络安全工程硕士打造 · 利莫瑞克大学 · 2024-2025

标签：IP 地址批量处理, nftables, Petitpotam, Python, 无后门, 深度学习, 网络安全, 自动化防御, 蜜罐, 证书利用, 逆向工具, 隐私保护