General protection fault by __d_drop following SMTP attack

Question

The SMTP port (Postfix) of my box running 3.16.5 is being hammered. The log repeats this over and over:

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]

Last night shortly after midnight, a kernel panic occurred, but the above logs continue until 4:21h when the box went down for good. (Reboot worked fine, the system has no intruders and is quiet now since I've shut down Postfix)

So a "general protection fault" in "__d_drop" has caused the crash and from the sound of the call trace it appears this module belongs to the firewall, isn't it? (Unfortunately, I'm not much of a C programmer.)

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 ]---

Thanks for your hints!

Answer 1

Disclaimer: This isn't answering why your kernel crash, but about another measure against mail bot.

For the defense against misbehaving bot, postfix 2.8 introduce one feature called postscreen. You can view the presentation from Postfix author about this feature. In short, it will add new layer of defence for your smtp server. Keeping kernel and postfix from receiving connection from bots.

Some snippet about postscreen basic idea

The basic idea behind postscreen(8)

Most email is spam, and most spam is sent out by zombies (malware on compromised end-user computers). Wietse expects that the zombie problem will get worse before things improve, if ever. Without a tool like postscreen(8) that keeps the zombies away, Postfix would be spending most of its resources not receiving email.

The main challenge for postscreen(8) is to make an is-it-a-zombie decision based on a single measurement. This is necessary because many zombies try to fly under the radar and avoid spamming the same site repeatedly. Once postscreen(8) decides that a client is not-a-zombie, it whitelists the client temporarily to avoid further delays for legitimate mail.

Zombies have challenges too: they have only a limited amount of time to deliver spam before their IP address becomes blacklisted. To speed up spam deliveries, zombies make compromises in their SMTP protocol implementation. For example, they speak before their turn, or they ignore responses from SMTP servers and continue sending mail even when the server tells them to go away.

postscreen(8) uses a variety of measurements to recognize zombies. First, postscreen(8) determines if the remote SMTP client IP address is blacklisted. Second, postscreen(8) looks for protocol compromises that are made to speed up delivery. These are good indicators for making is-it-a-zombie decisions based on single measurements.

postscreen(8) does not inspect message content. Message content can vary from one delivery to the next, especially with clients that (also) send legitimate email. Content is not a good indicator for making is-it-a-zombie decisions based on single measurements, and that is the problem that postscreen(8) is focused on.