☰

SMTP 攻击后，__d_drop 导致一般保护故障

tag-icon • tag-icon iptables postfix kernel kernel-panic
SMTP 攻击后，__d_drop 导致一般保护故障

运行 3.16.5 的机器的 SMTP 端口 (Postfix) 正在受到攻击。日志一遍又一遍地重复此操作：

Nov 14 09:16:25 [postfix/smtpd] lost connection after UNKNOWN from unknown[177.43.41.74]
Nov 14 09:16:25 [postfix/smtpd] disconnect from unknown[177.43.41.74]
Nov 14 09:16:25 [postfix/smtpd] warning: hostname fluair74.static.host.gvt.net.br does not resolve to address 177.43.41.74
Nov 14 09:16:25 [postfix/smtpd] connect from unknown[177.43.41.74]

昨晚午夜刚过，内核崩溃了，但上述日志一直持续到 4:21h，此时机器彻底关闭。（重启工作正常，系统没有入侵者，而且由于我关闭了 Postfix，现在很安静）

因此，“__d_drop” 中的“一般保护错误”导致了崩溃，并且从调用跟踪的声音来看，这个模块似乎属于防火墙，不是吗？（​​不幸的是，我不太擅长 C 程序员。）

Nov 14 00:00:27 [kernel] [303820.568072] general protection fault: 0000 [#1] SMP
Nov 14 00:00:27 [kernel] [303820.568183] Modules linked in: ip6t_rpfilter xt_CLASSIFY xt_TCPMSS xt_NFQUEUE xt_LOG xt_nat ipt_MASQUERADE xt_REDIRECT ipt_rpfilter xt_helper xt_mac xt_mark xt_length xt_state nfnetlink_queue nf_conntrack_netlink ip6table_mangle ip6table_raw iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_NFLOG nfnetlink_log nfnetlink xt_limit xt_connmark xt_conntrack iptable_filter iptable_raw ip_tables uhci_hcd ehci_pci ehci_hcd usbcore usb_common
Nov 14 00:00:27 [kernel] [303820.569599] CPU: 0 PID: 27 Comm: kswapd0 Not tainted 3.16.5-gentoo #2
Nov 14 00:00:27 [kernel] [303820.569644] Hardware name: {{MASKED}}
Nov 14 00:00:27 [kernel] [303820.569693] task: ffff880623e6c140 ti: ffff880623b18000 task.ti: ffff880623b18000
Nov 14 00:00:27 [kernel] [303820.569740] RIP: 0010:[<ffffffff810dc132>]  [<ffffffff810dc132>] __d_drop+0x3d/0x69
Nov 14 00:00:27 [kernel] [303820.569824] RSP: 0000:ffff880623b1bc18  EFLAGS: 00010a12
Nov 14 00:00:27 [kernel] [303820.569867] RAX: 0000000000000000 RBX: ffff8802adfa23c0 RCX: ffdf8802bae3c308
Nov 14 00:00:27 [kernel] [303820.569914] RDX: 0000000000000c0c RSI: 000000000029d3b3 RDI: ffffc900014e9d98
Nov 14 00:00:27 [kernel] [303820.569961] RBP: ffffc900014e9d98 R08: ffff8802adfa8680 R09: 000000000049ef36
Nov 14 00:00:27 [kernel] [303820.570299] R10: 0000000000000064 R11: ffff88063ffe8100 R12: ffff8802adfa2418
Nov 14 00:00:27 [kernel] [303820.570637] R13: ffff880623b1bc88 R14: 0000000000064243 R15: 0000000000000000
Nov 14 00:00:27 [kernel] [303820.570975] FS:  0000000000000000(0000) GS:ffff88063fc00000(0000) knlGS:0000000000000000
Nov 14 00:00:27 [kernel] [303820.571315] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 14 00:00:27 [kernel] [303820.571505] CR2: 00007f9efcb93fe8 CR3: 000000017068a000 CR4: 00000000000007f0
Nov 14 00:00:27 [kernel] [303820.571842] Stack:
Nov 14 00:00:27 [kernel] [303820.572024]  ffff8802adfa23c0 ffff8802adffea80 ffffffff810dc1f1 ffff8802adffea80
Nov 14 00:00:27 [kernel] [303820.572492]  ffff8802adffea80 ffff8802adfa2418 ffffffff810dc881 ffff880623b1bc88
Nov 14 00:00:27 [kernel] [303820.572959]  ffff880623b1bd98 ffff8806235ab800 ffff8806235abb68 ffffffff810dd319
Nov 14 00:00:27 [kernel] [303820.573427] Call Trace:
Nov 14 00:00:27 [kernel] [303820.573612]  [<ffffffff810dc1f1>] ? __dentry_kill+0x57/0x182
Nov 14 00:00:27 [kernel] [303820.573802]  [<ffffffff810dc881>] ? shrink_dentry_list+0x178/0x181
Nov 14 00:00:27 [kernel] [303820.573994]  [<ffffffff810dd319>] ? prune_dcache_sb+0x42/0x4c
Nov 14 00:00:27 [kernel] [303820.574185]  [<ffffffff810cf53c>] ? super_cache_scan+0xc7/0x136
Nov 14 00:00:27 [kernel] [303820.574378]  [<ffffffff8109f83a>] ? shrink_slab_node+0xf1/0x144
Nov 14 00:00:27 [kernel] [303820.574569]  [<ffffffff810a00d1>] ? shrink_slab+0x7b/0x119
Nov 14 00:00:27 [kernel] [303820.574759]  [<ffffffff810a2419>] ? balance_pgdat+0x2d3/0x3fa
Nov 14 00:00:27 [kernel] [303820.574950]  [<ffffffff810a27ef>] ? kswapd+0x2af/0x2e2
Nov 14 00:00:27 [kernel] [303820.575140]  [<ffffffff810650c9>] ? finish_wait+0x60/0x60
Nov 14 00:00:27 [kernel] [303820.575330]  [<ffffffff810a2540>] ? balance_pgdat+0x3fa/0x3fa
Nov 14 00:00:27 [kernel] [303820.575522]  [<ffffffff810538a1>] ? kthread+0x95/0x9d
Nov 14 00:00:27 [kernel] [303820.575712]  [<ffffffff81050000>] ? workqueue_cpu_up_callback+0x146/0x2c3
Nov 14 00:00:27 [kernel] [303820.575905]  [<ffffffff8105380c>] ? __kthread_parkme+0x55/0x55
Nov 14 00:00:27 [kernel] [303820.576096]  [<ffffffff81438aac>] ? ret_from_fork+0x7c/0xb0
Nov 14 00:00:27 [kernel] [303820.576287]  [<ffffffff8105380c>] ? __kthread_parkme+0x55/0x55
Nov 14 00:00:27 [kernel] [303820.576476] Code: fb 75 0d 48 8b 43 68 48 8d a8 b8 00 00 00 eb 0b 8b 73 20 e8 ae f4 ff ff 48 89 c5 48 89 ef e8 55 fc ff ff 48 8b 4b 10 48 8b 43 08 <48> 8b 11 83 e2 01 48 09 c2 48 85 c0 48 89 11 74 04 48 89 48 08
Nov 14 00:00:27 [kernel] [303820.579082] RIP  [<ffffffff810dc132>] __d_drop+0x3d/0x69
Nov 14 00:00:27 [kernel] [303820.579304]  RSP <ffff880623b1bc18>
Nov 14 00:00:27 [kernel] [303820.579507] ---[ end trace d39a95020f60fb9b ]---

谢谢你的提示！

答案1

免责声明：这并不是在回答为什么你的内核崩溃，而是关于针对邮件机器人的另一种措施。

为了防御行为不当的机器人，postfix 2.8 引入了一项名为后筛选。 你可以查看演示文稿Postfix 作者介绍了此功能。简而言之，它将为您的 smtp 服务器添加新的防御层。防止内核和 postfix 接收来自机器人的连接。

以下是关于后期筛选基本思路

postscreen(8) 背后的基本思想

大多数电子邮件都是垃圾邮件，而大多数垃圾邮件都是由僵尸程序（受感染的最终用户计算机上的恶意软件）发出的。Wietse 预计，僵尸程序问题在情况得到改善之前会变得更糟，甚至永远不会改善。如果没有像 postscreen(8) 这样的工具来阻止僵尸程序，Postfix 将花费其大部分资源来接收电子邮件。

postscreen(8) 面临的主要挑战是根据单一测量结果做出是否为僵尸的决策。这是必要的，因为许多僵尸都试图躲避雷达的探测，避免反复向同一网站发送垃圾邮件。一旦 postscreen(8) 确定某个客户端不是僵尸，它会暂时将该客户端列入白名单，以避免合法邮件进一步延迟。

僵尸计算机也面临挑战：它们的 IP 地址被列入黑名单之前，只能在有限的时间内发送垃圾邮件。为了加快垃圾邮件发送速度，僵尸计算机在 SMTP 协议实现方面做出了妥协。例如，它们在轮到自己之前先发话，或者忽略 SMTP 服务器的响应，即使服务器告诉它们离开，它们仍会继续发送邮件。

postscreen(8) 使用多种测量方法识别僵尸邮件。首先，postscreen(8) 确定远程 SMTP 客户端 IP 地址是否被列入黑名单。其次，postscreen(8) 查找为加快交付速度而进行的协议妥协。这些指标对于根据单一测量结果做出是否为僵尸邮件的决策非常有用。

postscreen(8) 不检查邮件内容。邮件内容可能因每次投递而异，尤其是对于（也）发送合法电子邮件的客户端。内容不是根据单一测量做出僵尸邮件决策的良好指标，而这正是 postscreen(8) 所关注的问题。

相关内容