Общая ошибка защиты __d_drop после SMTP-атаки
Порт SMTP (Postfix) моей коробки под управлением 3.16.5 забивается. Журнал повторяет это снова и снова:
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:21 часов, когда коробка окончательно опустится. (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 ]---
Спасибо за ваши подсказки!
1 ответ
Отказ от ответственности: это не ответ, почему ваше ядро падает, а о другой мере против почтового бота.
Для защиты от неправильного поведения бота в postfix 2.8 введена одна функция, называемая postscreen. Вы можете просмотреть презентацию от автора Postfix об этой функции. Короче говоря, это добавит новый уровень защиты для вашего сервера SMTP. Сохранение ядра и постфикса от получения соединения от ботов.
Небольшой фрагмент об основной идее постскрина
Основная идея пост-экрана (8)
Большая часть электронной почты является спамом, а большая часть спама рассылается зомби (вредоносными программами на скомпрометированных компьютерах конечных пользователей). Wietse ожидает, что проблема зомби обострится прежде, чем ситуация улучшится, если вообще когда-нибудь. Без такого инструмента, как postscreen(8), который держит зомби подальше, Postfix потратил бы большую часть своих ресурсов, не получая электронную почту.
Основная задача postcreen (8) - принять решение "зомби" на основе одного измерения. Это необходимо, потому что многие зомби пытаются пролететь под радаром и избегают спама на одном и том же сайте. Как только postscreen(8) решает, что клиент не является зомби, он временно вносит в белый список клиента, чтобы избежать дальнейших задержек для получения законной почты.
У зомби тоже есть проблемы: у них есть ограниченное количество времени для рассылки спама, прежде чем их IP-адрес попадет в черный список. Чтобы ускорить доставку спама, зомби идут на компромисс в реализации протокола SMTP. Например, они говорят до своей очереди, или они игнорируют ответы от SMTP-серверов и продолжают отправлять почту, даже когда сервер говорит им уйти.
postscreen(8) использует различные измерения для распознавания зомби. Во-первых, postscreen(8) определяет, занесен ли IP-адрес удаленного SMTP-клиента в черный список. Во-вторых, postscreen(8) ищет компромиссы протокола, которые сделаны для ускорения доставки. Это хорошие показатели для принятия решений "зомби" на основе единичных измерений.
postscreen(8) не проверяет содержимое сообщения. Содержание сообщения может варьироваться от одной доставки к другой, особенно с клиентами, которые (также) отправляют законную электронную почту. Контент не является хорошим индикатором для принятия решений "зомби" на основе единичных измерений, и именно на этой проблеме сосредоточен постэкран (8).