本帖最后由 Dizziness2929 于 2024-4-30 07:33 编辑
1.但是列表中的Rootkit大部分已经过时至少两年。
2.在LKRG官网中已经提到了为什么要这样做：LKRG需要一部分用户态的数据来检测是否有异常的凭据变化（内核漏洞利用迹象）。
As controversial as this concept is, LKRG attempts to post-detect and hopefully promptly respond to unauthorized modifications to the running Linux kernel (integrity checking) or to credentials such as user IDs of the running processes (exploit detection). For process credentials, LKRG attempts to detect the exploit and take action before the kernel would grant access (such as open a file) based on the unauthorized credentials.
尽管这个概念存在争议，但 LKRG 试图对正在运行的 Linux 内核（完整性检查）或正在运行的进程的用户 ID 等凭据（漏洞检测）进行事后检测，并希望能够及时响应。对于进程凭据，LKRG 会尝试检测漏洞并在内核根据未经授权的凭据授予访问权限（例如打开文件）之前采取措施。
Master's Thesis of Juho Junnila, entitled "Effectiveness of Linux Rootkit Detection Tools", shows LKRG as the most effective kernel rootkit detector (of those tested).
Juho Junnila 的硕士论文题为“Linux Rootkit 检测工具的有效性”，表明 LKRG 是（测试者中）最有效的内核 rootkit 检测器。
3：不知道你有没有注意到LKRG的这个配置？
# Whether and to what extent to validate uses of usermodehelper (UMH). Allowed
# values are 0 (validation disabled), 1 (allow only previously known programs),
# and 2 (completely block UMH).
#
# UMH can also be protected with pCFI regardless of this setting.
#
# UMH is a kernel-internal interface, which the kernel uses to invoke programs
# such as /sbin/modprobe (to auto-load a module on demand) and many others.
# When left unrestricted, UMH is convenient for kernel vulnerability exploits.
#
# Default: "1"
#lkrg.umh_validate = 1
# How to act on UMH usage violations. Allowed values are 0 (log only), 1
# (prevent execution), and 2 (panic the kernel).
#
# Default: "1"
#lkrg.umh_enforce = 1
LKRG是在官网上没有写可以移除存在威胁的内核模块，这个你说得对，但是官网上也有写这是为什么：https://www.openwall.com/lists/lkrg-users/2020/06/14/5
Of course, none of these rootkits tried to bypass LKRG. If they wanted
to, they could e.g. simply "rmmod p_lkrg" before loading themselves into
the kernel. (Or the attacker could do that manually.) In LKRG
development, we're currently more focused on exploits run before the
attacker got legitimate-looking privileged access to the system. We're
not as focused on rootkits, which are loaded with legitimate-looking
privileged access.
当然，这些 rootkit 都没有试图绕过 LKRG。如果他们愿意，他们可以简单地“rmmod p_lkrg”，然后再将自己加载到内核中。（或者攻击者可以手动执行此操作。在 LKRG 开发中，我们目前更关注在攻击者获得对系统的合法特权访问之前运行的漏洞。我们不太关注 rootkit，它加载了看似合法的特权访问。
相关的测试论文在这里：https://oulurepo.oulu.fi/handle/10024/15182
该测试论文中明确指出：UMH验证可以阻止这些Rootkit的后续利用行为，这些Rootkit可以加载但无法起作用。
这并不妨碍我的结论是LKRG是有能力做到的，只是LKRG不愿意去做这些（LKRG更关心内核漏洞利用，而Rootkit是利用了合法的特权访问把自己加载进去的，换言之：如果攻击者都有能力在你的设备上装载他自己的模块，那不是LKRG能帮上忙的场合）
4、5、6合并回答：在我回复其他人的楼层中，我提到了如果要手动的变更LKRG加载优先级序列，你需要自定义内核。LKRG的systemd服务仅仅是为了实现自动加载LKRG（如果你看过那个服务做了什么就明白这一点）模块。
而且，在现代Linux上，systemd已经取代了init，所以并不需要自定义内核那么复杂，你可以尝试自定义systemd来实现优先加载LKRG模块。
至于SELinux之类的使用LSM（Linux安全模块）接口加载自己的东西，你说得对，LSM作为真正的内核的一部分是可以在更早阶段被加载（但是，LSM提供的功能相当有限）。
Though LSM can be disabled in the vanilla kernel to allow the system to work functionally as it did in 2.4, all linux distributions will most likely be enabling it in their kernels. The mere existence of a security framework is not going to urge more users to use Trusted OS components in their kernels.
虽然 LSM 可以在 vanilla 内核中禁用，以允许系统像在 2.4 中一样工作，但所有 linux 发行版很可能都会在其内核中启用它。仅仅存在一个安全框架并不会促使更多的用户在其内核中使用受信任的操作系统组件。
Because LSM is compiled and enabled in the kernel, its symbols are exported. Thus, every rootkit and backdoor writer will have every hook he ever wanted in the kernel. This will allow for a new generation of sophisticated backdoors and rootkits that will be nearly impossible to detect.
由于 LSM 是在内核中编译和启用的，因此会导出其符号。因此，每个 rootkit 和后门编写器都会在内核中拥有他想要的所有钩子。这将允许几乎不可能检测到的新一代复杂的后门和 rootkit。
LSM still does not support stacking of security modules, or in fact support security modules currently at all! Today, grsecurity is compatible with all other LSMs -- if grsecurity were made to use the LSM framework, users would have to decide between it and other frameworks distros force on their users (Fedora/RHEL -> SELinux, Ubuntu/SuSE -> AppArmor). This removal of choice is detrimental to users' security.
LSM 仍然不支持安全模块的堆叠，或者说实际上目前根本不支持安全模块！今天，grsecurity 与所有其他 LSM 兼容——如果 grsecurity 使用 LSM 框架，用户将不得不在它和其他框架发行版强加给用户（Fedora/RHEL -> SELinux、Ubuntu/SuSE -> AppArmor）之间做出决定。这种选择的删除对用户的安全是有害的。
|
楼主: Dizziness2929
发表于 2024-4-29 22:13:42
楼主