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