ghcr.io/misp/misp-docker/misp-modules:4bbd01a-slim

MISP Docker 镜像

一个生产就绪的 Docker MISP 镜像（以前托管于 ，现已弃用）大致基于 CoolAcid 和 DSCO 构建，几乎所有逻辑都经过重写并验证了正确性和可移植性。

主要特性：

• MISP 和 MISP modules 分为两个不同的 Docker 镜像：misp-core 和 misp-modules
• 可选的 https://github.com/MISP/misp-guard 容器，通过 mitmproxy 过滤流量并执行共享策略。
• Docker 镜像定期推送，无需构建
• 通过多阶段构建和精简基础镜像实现轻量级 Docker 镜像
• 依赖现成的 Exim4、Redis 和 MariaDB Docker 镜像
• 计划任务运行更新、推送和拉取操作
• 修复 supervisord 进程控制（重新加载时进程正确终止）
• 通过完全离线化修复模式更新（无需用户交互）
• 修复权限执行
• 修复 MISP modules 的 faup 库加载
• 修复 MISP modules 的 gl 库加载
• 使用 LDAP、OIDC 或 CustomAuth 进行身份验证
• 添加对新后台作业 https://github.com/MISP/MISP/blob/2.4/docs/background-jobs-migration-guide.md 的支持
• 添加对构建特定 MISP 和 MISP-modules 提交的支持
• 添加同步服务器的自动配置（参见 configure_misp.sh）
• 添加认证密钥的自动配置（参见 configure_misp.sh）
• 添加 Docker 镜像直接推送到 GitHub Packages 的功能
• 合并的 docker-compose.yml 文件
• 解决在 Mac 版 Docker Desktop 上运行时的 VirtioFS 漏洞
• stunnel 服务用于纯文本服务（如 Redis）的 TLS 封装
• ……以及许多其他特性

本项目的核心精神是实现“可重复部署”，所有朝着这个方向的拉取请求都将迅速合并。

要覆盖这些行为，请编辑 docker-compose.yml 文件的 misp-core 卷定义，以启用 "customize_misp.sh" 行为（详见生产环境部分的底部）。"customize_misp.sh" 脚本会在上述行为完成后触发，是覆盖设置的合适位置。建议使用 "/var/www/MISP/app/cake Admin setSetting" 命令来覆盖设置，因为此工具了解 config.php 文件和数据库设置。

不确定添加新设置时应编辑哪些文件？

如果只是在用户尚未设置时才需要设置的默认设置，请将其添加到某个 *.default.json 文件中。
如果是由环境变量控制的设置（旨在覆盖已设置的任何值），请将其添加到某个 *.envars.json 文件中（注意仍可指定默认值）。

MISP-Guard（可选）

https://github.com/MISP/misp-guard 是一个 mitmproxy 插件，旨在应用可配置过滤器，防止敏感威胁情报数据的无意泄露，同时促进受控信息共享。

默认情况下处于禁用状态，但可使用 compose 配置文件启用。

启用

1. 在 .env 文件中启用配置文件：

COMPOSE_PROFILES=misp-guard

2. 确保 misp-core 已配置为使用代理：

PROXY_ENABLE=true
PROXY_HOST=misp-guard
# 必须与 GUARD_PORT 匹配（默认值=8888）
PROXY_PORT=8888

配置

• 规则在 guard/config.json 中定义。
• 容器在运行时通过 entrypoint.sh 自动替换 misp-core 的 IP。

定位 misp-core 需要以下格式，IP 会在运行时替换为 misp-core 容器的 IP。

{
"instances": {
"misp_container": {
"ip": "placeholder"
}
}
}

• 修改 guard/config.json 后，重启容器以应用更改：

docker compose restart misp-guard

环境变量

# misp-guard 监听端口（必须与 PROXY_PORT 匹配）
# 默认值：8888
GUARD_PORT=8888

# 可选：mitmdump misp-guard 运行时参数（空格分隔）
GUARD_ARGS=--ssl-insecure -v

身份验证

LDAP 身份验证

您可以使用以下两种方法在 MISP 中配置 LDAP 身份验证：

• 原生插件：LdapAuth（ ）
• 早期方法：使用 ApacheSecureAuth（ ）

推荐使用 LdapAuth 而非 ApacheSecureAuth，因为它不需要带有 ldap 模块的 rproxy apache。

以下使用 LdapAuth 插件与您的 ldap/AD 服务器集成的配置经过测试且已强化。

此示例假设您已将根证书挂载到 Pod 的 /usr/local/share/ca-certificates/rootca.crt 路径下，该证书会自动添加到 /etc/ssl/certs/ca-certificates.crt 和 /etc/ssl/certs/ca-certificates.crt bundle 中。

使用 memberOf:1.2.840.113556.1.4.1941:= 旨在递归查找组中的嵌套成员。例如，如果我们有一个名为 MIPS-ALLOW-IN 的组对象，我们授予该组访问 MISP 的权限。并将该组添加为另一个名为 Applications Admins 的组的成员。那么 Applications Admins 中的所有成员/用户也将被授予访问权限。这种权限分配方法称为 RBAC。

此示例使用 userPrincipalName 属性作为用户登录的用户名，并使用 mail 属性在用户登录时发送电子邮件。

您无需使用任何单引号、双引号、转义或双重转义，/configure_misp.sh 脚本会确保将需要引号的内容用单引号括起来，并写入 /var/www/MISP/app/Config/config.php。

确保在 instance-secrets.env 中定义以下内容。

BASE_URL=https://misp.apps.openshift.domain.local
LDAPAUTH_ENABLE=true
LDAPAUTH_LDAPSERVER=ldaps://domain.local
LDAPAUTH_LDAPDN=OU=Company,OU=Management,DC=domain,DC=local
LDAPAUTH_LDAPREADERUSER=CN=ldap-account,OU=Accounts LDAP,OU=Management,DC=domain,DC=local
LDAPAUTH_LDAPREADERPASSWORD=YoucanType4nythingH3r3Even1'Are3scaped!
LDAPAUTH_LDAPSEARCHFILTER=(&(objectCategory=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=MIPS-ALLOW-IN,OU=Groups Applications,OU=Groups,DC=domain,DC=local))
LDAPAUTH_LDAPSEARCHATTRIBUTE=userPrincipalName
LDAPAUTH_LDAPEMAILFIELD=mail
LDAPAUTH_LDAPNETWORKTIMEOUT=-1
LDAPAUTH_UPDATEUSER=true
LDAPAUTH_LDAPDEFAULTORGID=1
LDAPAUTH_LDAPDEFAULTROLEID=3
LDAPAUTH_DEBUG=false
LDAPAUTH_LDAPTLSCUSTOMCACERT=false
LDAPAUTH_LDAPPROTOCOL=3
LDAPAUTH_LDAPALLOWREFERRALS=false
LDAPAUTH_STARTTLS=false
LDAPAUTH_MIXEDAUTH=true
LDAPAUTH_LDAPTLSREQUIRECERT=LDAP_OPT_X_TLS_DEMAND
LDAPAUTH_LDAPTLSCRLCHECK=LDAP_OPT_X_TLS_CRL_PEER
LDAPAUTH_LDAPTLSPROTOCOLMIN=LDAP_OPT_X_TLS_PROTOCOL_TLS1_2

STARTTLS 设置为 false，因为它旨在在可能的情况下自动将未加密连接（LDAP）升级为安全连接（LDAPS）。由于我们使用 LDAPS（硬编码）或根本不建立连接，因此不需要此功能。

OIDC 身份验证

OIDC 身份验证通过 MISP OidcAuth 插件实现。

有关使用 KeyCloak 的示例配置，请参见 MISP Keycloak 26.1.x 基本集成指南

对于 Okta，请创建新的应用集成：

• 应用程序 -> 应用程序 -> 创建应用集成
• 选择登录方法“OIDC - OpenID Connect”和应用程序类型“Web 应用程序”
• 在客户端身份验证中，选择“客户端密钥”
• 将登录重定向 URI 设置为："https:// /users/login"
• 在登录选项卡下，添加名为“roles”的组声明和适当的过滤器
• 在 MISP docker 的 .env 文件中，设置以下变量：

OIDC_ENABLE=true
OIDC_PROVIDER_URL=https:// /.well-known/openid-configuration
OIDC_ISSUER=https://
OIDC_CLIENT_ID=[client_id]
OIDC_CLIENT_SECRET=[client_secret]
OIDC_ROLES_PROPERTY="roles"
OIDC_ROLES_MAPPING="{\"Okta group - MISP Admin\": 1}" #
OIDC_DEFAULT_ORG="[Your default org in MISP]"
#OIDC_LOGOUT_URL=
OIDC_SCOPES="[\"profile\", \"email\", \"groups\"]"
OIDC_MIXEDAUTH=true # (如果要禁用密码登录，请将此设置为 false，确保 OIDC 先正常工作)
OIDC_CODE_CHALLENGE_METHOD=S256
OIDC_AUTH_METHOD="client_secret_post"
OIDC_REDIRECT_URI="https:// /users/login" # (与在 Okta 中设置的值相同)
OIDC_DISABLE_REQUEST_OBJECT=false
OIDC_SKIP_PROXY=true
OIDC_ALLOW_EMAIL_LINKING=false
OIDC_REQUIRE_EMAIL_VERIFIED=true

OIDC_AUTH_METHOD 的有效选项包括：

• client_secret_post：已测试
• client_secret_basic：如果未设置该变量，则为默认值，但在 Okta 中似乎存在问题。它会返回以下错误："Error 'invalid_request' received from IdP: Cannot supply multiple client credentials"。
• client_secret_jwt：未测试
• private_key_jwt：未测试

CustomAuth

您可以按照此处所述使用 Plugin.CustomAuth 插件添加身份验证：[***] HTTP 头对用户进行身份验证。这在 MISP 运行在身份验证反向代理服务器后面时非常有用。

高可用性部署

如果要在负载均衡器后方部署多个 misp-core 容器，建议在 .env 文件中或容器环境内将以下参数设置为静态值，因为它们用于会话处理，若未设置将随机生成：

• SALT
• UUID

如果不这样做，可能会出现 CSRF 错误。

出于非会话相关原因，以下环境变量在所有 misp-core 容器中也应保持一致：

• BASE_URL
• ENCRYPTION_KEY
• ADMIN_EMAIL
• ADMIN_ORG
• ADMIN_ORG_UUID
• MISP_EMAIL
• GPG_PASSPHRASE

不建议共享 app/Config 目录，因为此镜像在每次容器启动时都会执行检查和修改，可能会导致竞争条件，损坏共享的 config.php 文件。建议每个容器使用独立的 app/Config 目录。

版本控制

GitHub Action 会自动构建 misp-core、misp-modules 和 misp-guard 镜像，并将其推送到 https://github.com/orgs/MISP/packages%E3%80%82%E6%88%91%E4%BB%AC%E4%B8%8D%E5%9C%A8%E4%BB%93%E5%BA%93%E5%86%85%E4%BD%BF%E7%94%A8%E6%A0%87%E7%AD%BE%EF%BC%9B%E8%80%8C%E6%98%AF%E5%9C%A8%E9%95%9C%E5%83%8F%E6%8E%A8%E9%80%81%E5%88%B0 registry 时为其添加标签。对于每次构建，misp-core、misp-modules、misp-guard 镜像的标签规则如下：

• misp-core:${commit-sha1}[0:7]、misp-modules:${commit-sha1}[0:7] 和 misp-guard:${commit-sha1}[0:7]，其中 ${commit-sha1} 是触发构建的提交哈希
• misp-core:latest、misp-modules:latest 和 misp-guard:latest，用于跟踪可用的最新构建
• misp-core:${CORE_TAG}、misp-modules:${MODULES_TAG} 和 misp-guard:${GUARD_TAG}，反映构建时 template.env 文件中指定的基础版本

podman system prune ; podman image rm ghcr.io/misp/misp-docker/misp-core ; podman image rm ghcr.io/misp/misp-docker/misp-modules ; podman image rm ghcr.io/misp/misp-docker/misp-guard ; rm -f build.log ; PODMAN_COMPOSE_VERBOSE=1 podman compose build --no-cache | tee build.log

这确保您从干净的状态开始构建，而不使用之前构建的残留文件。

调试 Dockerfile

通过构建日志，您可以确定构建失败的位置。要精确定位具体步骤，请在 Dockerfile 中添加调试行。使用唯一标记以便在日志中轻松找到它们：

RUN echo "____MYDEBUG___1"
RUN echo "____MYDEBUG___2"
RUN echo "____MYDEBUG___3"

打印变量值

许多构建错误与变量未正确设置或导入有关。要进行调试，请打印它们的值：

RUN echo "____MYDEBUG___ CORE_TAG: ${CORE_TAG}"

示例输出：

[4/5] STEP 19/20: RUN echo "____MYDEBUG___ CORE_TAG: ${CORE_TAG}"
____MYDEBUG___ CORE_TAG: v2.5.16
--> 798999451f75

在 shell 块中打印变量

对于 Dockerfile 中的 shell 块，插入 echo 语句以打印变量值：

RUN <<-EOF
for mod in "$@"; do
mod_version_var=$(echo "PYPI_${mod}_VERSION" | tr '[:lower:]' '[:upper:]' | tr '-' '_')
mod_version=$(eval "echo \"\$mod_version_var\"")
echo "____MYDEBUG___ mod mod_version: ${mod}${mod_version}"
# ... rest of the code ...
done
EOF

变量未展开

Podman 的旧版本（5 之前的版本）可能无法在 shell 块中正确展开变量。如果遇到此问题，请确保使用正确的 shell 语法。对于 Podman，请将：

RUN <<-EOF

替换为（注意 ' 引号）

RUN bash <<-'EOF'

以确保变量按预期展开。作为参考，此问题首次出现于成功构建镜像后，但启动容器时出现 /usr/local/bin/supervisord: No such file or directory 错误。有关更多详细信息，请参见 https://github.com/MISP/misp-docker/issues/265 和 https://github.com/MISP/misp-docker/pull/273%E3%80%82

通过遵循这些步骤，您可以高效地排查并解决构建问题。如果问题仍然存在，请在提交 issue 请求帮助时附上您的构建日志和环境详情。