☰

Задержка атак по словарю в exim

tag-icon • tag-icon email exim
Задержка атак по словарю в exim

У меня постоянные атаки на мой сервер exim. Я пытаюсь отсрочить попытки с помощью следующего acl

  deny    condition     = ${if and {\
                        {>{$rcpt_count}{10}}\
                        {<{$recipients_count}{${eval:$rcpt_count/2}}} }}
          delay         = 5s
          message       = Rejected for too many bad recipients
          logwrite      = REJECT [$sender_host_address]: bad recipient count high [${eval:$rcpt_count-$recipients_count}]
         .endif

Это задержка один раз после первых 10 попыток.

2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [11]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [12]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients

Я хочу, чтобы вместо этого он задерживал каждую последующую попытку. Как мне этого добиться?

решение1

Я столкнулся с той же проблемой/вопросом и провел некоторые исследования и тестирования.

Первое, что вам нужно знать, это то, что SMTP изначально был строго основан на команде-ответе, что означает, что клиент может отправить серверу только одну команду и должен ждать ответа, прежде чем он сможет отправить следующую. Поскольку это движение туда-сюда подразумевает некоторое ожидание каждый раз и, таким образом, создает задержку,Запрос на предложение 2920позже был введен "SMTP Pipelining". Это позволяет клиенту отправлять несколько команд в одном пакете на сервер, который обрабатывает их и отправляет обратно ответы. В exim доступность "SMTP Pipelining" можно контролировать с помощью опции pipelining_advertise_hosts, которая по умолчанию разрешает ее для всех. Я предполагаю, что это также относится к вашей конфигурации.

Я думаю, что в вашем случае произошло следующее: клиент (он же спамер), подключенный к вашему серверу exim, получил сообщение о поддержке "SMTP Pipelining", и поэтому он отправил пакет из 100 RCPT TO:команд. Ваш сервер получил их и начал обрабатывать, прогоняя через acl_smtp_rcptacl для каждого получателя. Первые 10 команд вернули 550 Unrouteable addressответ каждая, 550причемКод ошибки RFC5321значение Requested action not taken, за которым следует понятная человеку причина. Эта причина может быть установлена ​​в exim с помощью директивы message, а также выводится в журнал после двоеточия. Клиент, вероятно, просто проигнорировал их; в конце концов, он ищет действительных получателей.

При обработке 11-й команды/получателя условие вашего denyправила оценивается как истинное, и exim задерживается (спит) на 5 секунд; это единственная задержка, которую вы видите. После этого он отправляет ответ 550 Rejected for too many bad recipientsклиенту. Из-за включенной (хорошо известной) причины клиент обнаруживает, что он пересек линию, и больше нет возможности найти допустимого получателя; все последующие команды также будут отклонены. Поскольку больше нечего ожидать/получать, он разрывает соединение, не дожидаясь остальных ответов (и, вероятно, немедленно переключается на следующую жертву). Хотя ваш сервер замечает это (потому что используется TCP), он все еще продолжает обрабатывать пакет команд. Но поскольку SMTP-соединение с клиентом уже разорвано, нет смысла больше задерживать; единственное, кого он задержит, это он сам. Поэтому задержка игнорируется, и ваш сервер выполняет команды, пока не будет выполнен весь пакет.

Если клиент не разорвет соединение, это сработает так, как и ожидалось: задержка в 5 секунд будет применяться для каждого получателя после 10-го.

Если предположить, что вышесказанное верно, то лучшее решение, которое я смог придумать, — это удалить причину/сообщение по умолчанию. Если сервер просто продолжает отвечать чем-то вроде 550 Unrouteable address, клиент не может узнать, что он перешел черту, и не может отказаться. В зависимости от того, как работает клиент, может быть достаточно изменить/перефразировать его на что-то отличное от значения по умолчанию, чтобы оно не обрабатывалось специально.

В качестве альтернативы вы можете отключить "SMTP Pipelining" на вашем сервере, используя указанную выше опцию. Клиент, вероятно, все равно прервется после того, как увидит 11-й ответ с явным указанием причины, и ваш сервер все еще задержится только один раз, но, по крайней мере, вы не получите 89 других неудавшихся получателей в своем журнале. Очевидный недостаток в том, что вы "замедляете" каждого клиента, но это можно несколько улучшить, включив "SMTP Pipelining" только для выбранных "известных хороших" клиентов.

И просто в качестве примечания: задержка не обязательно должна быть статическим значением, она также может быть выражением. Это позволяет реализовать прогрессивные задержки, где каждый дополнительный недействительный получатель будет увеличивать ее. ПревосходныйФильтрация спама для почтовых обменниковПример этого есть в HowTo.

Связанный контент