Назад | Перейти на главную страницу

Postfix и скомпрометированные аккаунты

Прежде всего, извините за мой английский.

Я думаю, что очень часто permit_mynetworks и permit_sasl_authenticated ограничения на первые позиции smtpd_recipient_restriction список, но, если учетная запись скомпрометирована (вирус использует украденные учетные данные - из файлов конфигурации Outlook, например, для отправки СПАМА), а аутентифицированные клиенты могут отправлять электронную почту без дополнительных ограничений, ваша последняя возможность - ваши фильтры правильно отклоняют спам-сообщения от скомпрометированные аккаунты; но разве это не менее эффективно?

Я думаю, что postfix более эффективно отклоняет спам, поскольку он использует информацию из протокола SMTP и так далее, но milters должны сканировать содержимое сообщений, чтобы определить, является ли письмо спамом или нет.

Однако все мои клиенты используют TLS для подключения к моему серверу. Могут ли вирусы / спамеры использовать зашифрованные соединения для отправки электронной почты (при условии, что они украли пароль)? Я так не думаю, потому что спамеры стараются доставлять сообщения как можно быстрее, а зашифрованные соединения слишком медленные для этих целей.

Если это так, у меня нет проблем с тем, чтобы разрешить аутентифицированным клиентам отправлять почту, но я хотел бы быть уверен в этом.

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

Опять же, мой подход заключался в глубокой защите с небольшим оскорблением со стороны службы поддержки клиентов (то есть, скажите им, что если вы снова вызовете проблему со спамом, мы вас бросим).

1) Используйте регуляторы скорости Postfix (вы можете найти в Google дополнительную информацию - очень обширная) Это хорошо для экономии циклов процессора и памяти на вашем сервере на случай, если пользователь начнет рассылать спам. Это замедлит повреждение и не приведет к потере целевого хоста, если у вас возникнет проблема, поэтому это поможет вам быть вежливым гражданином, а также защитить себя и других пользователей.

local_destination_concurrency_limit = 2
default_destination_concurrency_limit = 10

2) Ограничение скорости зависит от пользователя SMTP.

Postfix имеет возможность использовать надстройки политики, такие как этот, предназначенные для того, чтобы делать именно то, что вы хотите.

http://wiki.policyd.org/

http://www.simonecaruso.com/limit-sender-rate-in-postfix/

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

3) Не забывайте о вирусах

Настройте postfix для проверки исходящей почты с помощью http://amavis.sourceforge.net/

Надеюсь, это был приемлемый ответ. Дайте мне знать, если у вас возникнут другие вопросы.

Ура!

... если учетная запись скомпрометирована (вирус использует украденные учетные данные - например, из файлов конфигурации Outlook - для отправки СПАМА), и прошедшие проверку подлинности клиенты могут отправлять электронную почту без дополнительных ограничений, ваша последняя возможность - ваши фильтры правильно отклоняют спам-сообщения от скомпрометированных Счета; но разве это не менее эффективно?

Я думаю, что postfix более эффективно отклоняет спам, поскольку он использует информацию из протокола SMTP и так далее, но milters должны сканировать содержимое сообщений, чтобы определить, является ли письмо спамом или нет.

Так как @ Двоичный сказал в своих постах, это все о многослойная защита. В первой строке postfix есть легкие проверки, такие как постэкран и stmpd _ * _ ограничение (включая permit_mynetworks и permit_sasl_authenticated). Эта защита будет эффективной и сэкономит много ресурсов.

После облегченных проверок postfix передаст проверку на спам во внешний content_filter (до или после очереди). Конечно, он будет потреблять больше ресурсов, но эти проверки будут вызываться только для (небольшого процента) писем, прошедших первую линию защиты. Глубина защитного слоя будет определяться вашими ресурсами.

Однако все мои клиенты используют TLS для подключения к моему серверу. Могут ли вирусы / спамеры использовать зашифрованные соединения для отправки электронной почты (при условии, что они украли пароль)? Я так не думаю, потому что спамеры стараются доставлять сообщения как можно быстрее, а зашифрованные соединения слишком медленные для этих целей.

Конечно, TLS / зашифрованное соединение медленнее, чем незашифрованное. Но техника вроде Кеш TLS уже давно улучшил производительность SSL-квитирования. И, конечно же, спамер / зараженный клиент мало заботится об этом. Им просто нужен вектор атаки, чтобы рассылать спам / вирусы через ваш сервер.

Я согласен с тем, что использование фильтрации исходящего спама в качестве передовой защиты от рассылки спама неэффективно, но все же важно. Альтернативой является то, что спам проходит и помещает вас в черный список, тогда весь ваш домен в беде. Итак, я думаю, что подход глубокоэшелонированной защиты - действительно единственный подход здесь, включая частую ротацию паролей, 2FA и т. Д. Фильтр исходящего спама - это всего лишь слой этого лука, и он очень важен. Считайте это последней линией защиты, а не первой. Кроме того, вы должны запускать это на отдельном оборудовании от вашего почтового кластера.

Конкретная реализация (milters по сравнению со всем остальным) менее важна, чем общая эффективность вашей системы. При многоуровневом подходе вы можете определить эффективность каждого шага, измеряя количество проходящего спама по отношению к общему количеству электронной почты, тем самым устанавливая количественный способ измерения эффективности или результативности. Будем надеяться, что к тому времени, когда исходящий спам станет фильтрующим, его будет так мало, что это не повредит производительности.

Отвечая на ваш последний вопрос: я не вижу причин, по которым какой-либо клиент не должен использовать TLS в 2014 году. Это еще один уровень надежного процесса безопасности. Новые методы спама появляются каждый день, и использование TLS защищает вас постепенно лучше, чем отсутствие TLS / другого шифрования.