LINUX.ORG.RU
ФорумAdmin

Spoofing как бороться

 ,


0

2

Всем доброго времени суток, Прошу помощи в следующей ситуации: Вчера какой-то левый вьетнамский сервер 103.133.108.7 начал массовую рассылку писем якобы от нашего домена, в которых FROM и Return-Path - один из наших емайл-адресов. Соответственно, сотни (если не тысячи) серверов пытаются доставить NDR уже мне. Половина из них еще и левое письмо как вложение отправляют. Пока что временно запретил доставку для этого адреса, чтобы рубилось уже на стадии проверки заголовка, иначе ящик пользователя очень быстро забивается мусором (впрочем, половина из отправляющих сами по себе левые\кривые и рубятся и без этого запрета). SPF для нашего домена прописана -all, толку мало. Если левая рассылка не прекратится, пока вижу выход только в смене адреса пользователя. Использую postfix. Вопрос № 1: Есть ли другие, грамотные, варианты? Вопрос № 2: Этаким манером можно любой адрес на крупных площадках веб-почты забить, как такое решают крупные провайдеры?


Предлагаю вдогонку прописать еще DMARC, как раз ваш случай, что-то в таком духе

v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@yourdomain.com

https://dmarc.org/overview/

Twissel ★★★★★
()
Последнее исправление: Twissel (всего исправлений: 2)

Благодарю за ответы. DMARC’ом еще вчера занялся, хотя и абсолютно не верю в его эффективность - крупных провайдеров в NDR нет вовсе, а из остальных наверняка лишь небольшая часть DMARC проверяют, если даже SPF не умеют. Сейчас сотни коннектов ежесекундно, а мы ведь не майлру, железо не космическое…

AndyM
() автор топика
Ответ на: комментарий от AndyM

Сочувствую, но больше навскидку ничего в голову не пришло.

Кроме совсем уж крайних вариантов, разворачивать перед основным серваком шлюз и отсекать уже там.

Twissel ★★★★★
()

Есть ли другие, грамотные, варианты?

В общем других нет наверное (с учётом того, что про DMARC написали, уже). Сюда написал?

% Abuse contact for '103.133.108.0 - 103.133.111.255' is 'hm-changed@vnnic.vn'

Про SPF и DMARC ещё. Про DNS кэш помнишь? Какое там время в SOA? Ну и глупый вопрос: serial увеличить не забыл?

Соответственно, сотни (если не тысячи) серверов пытаются доставить NDR уже мне.

Главное от крупных площадок отбиться. Вообще это моветон в наше время - принимать, а потом боунс слать, если в ящик положить не вышло почему-нибудь. Кроме Микрософта со своим облаком оффис 365 так никто не делает вроде сейчас уже.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)

Ну раз ничего не получается. То руби их на подлете шашкой от плеча:

# body_checks
/lopuh@mydomen.ru/
  REJECT
#
Если в тексте есть упоминание скопрометированого узера... Можно найти в NDR и др ключевые слова.

мера временная конечно__ :)

Bootmen ☆☆☆
()
Последнее исправление: Bootmen (всего исправлений: 2)

Ни SPF, ни DMARC не смогут запретить удаленному злоумышленнику подставлять в заголовки Ваши адреса. И если у получателей не настроены соответствующие проверки на их серверах, то письма от Вашего адреса будут доходить до них. Собственно говоря, смысл SPF и DMARC как раз и заключается в том, чтобы создать технические механизмы различий писем, отправленных Вами, и любым другим сервером. А уж пользоваться или нет этими механизмами - дело получателей.

Так что выбранный Вами способ борьбы - единственно возможный. И в общем-то, довольно эффективный - мне не очень понятно, зачем менять адрес, если все такие сообщения можно довольно легко фильтровать на стадии анализа заголовков.

Serge10 ★★★★★
()
Ответ на: комментарий от Serge10

Меня вообще удивляет ситуация описанная ТС. Обычно бонусы режекты нормальный сервер отправляет клиенту но никак сендеру. Клиента подменить невозможно. Наверное его бомбит ботнет. А рестрикшены плохо настроенны.

Bootmen ☆☆☆
()
Последнее исправление: Bootmen (всего исправлений: 1)
Ответ на: комментарий от Bootmen

Согласен. Я оказывался в такой ситуации (когда массово приходили отлупы, и даже звонили знакомые с вопросами, что за ерунду я рассылаю), но это было очень давно, лет 15-20 назад, когда не было еще ни SPF, ни DMARC, и в сети было полно открытых релеев. Но сегодня это явно не должно быть проблемой.

Serge10 ★★★★★
()
Ответ на: комментарий от Bootmen

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

Чего!? Боунс всегда и безусловно формируется сервером по значению envelope from. Другой вопрос, что правильное решение - это проверка получателя до приёма сообщения и выдача, вот тут уже SMTP-отправителю, smtp-отлупа. И задачей посылки боунса будет озадачен тот, кто был SMTP-сендером, а не сервер получателя.

AS ★★★★★
()
Ответ на: комментарий от Serge10

Вот типичный получаемый нами отлуп, нечего брать из заголовков:

Received: from s57.datacenterworlds.top
(mailserver57.mylittledatacenter.com [136.243.133.242])
by mail.mydomain.com (Postfix) with ESMTP id 0AE5E8503A41
for market7@mydomain.com; Fri, 10 Apr 2020 16:43:21 +0600 (ALMT)
Received: from mailnull by s57.datacenterworlds.top with local (Exim 4.91) id 1jMTld-003y6N-Vf
for market7@mydomain.com; Thu, 09 Apr 2020 14:16:38 +0430
X-Failed-Recipients: legrace5555m@gmail.com
Auto-Submitted: auto-replied
From: Mail Delivery System MailerDaemon@s57.datacenterworlds.top
To: market7@mydomain.com
Content-Type: multipart/report; report-type=delivery-status;
boundary=«1586425597-eximdsn-937661736»
MIME-Version: 1.0
Subject: Mail delivery failed: returning message to sender
Message-ID: E1jMTld-003y6N-Vf@s57.datacenterworlds.top
Date: Thu, 9 Apr 2020 14:16:37 +0430
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - s57.datacenterworlds.top
X-AntiAbuse: Original Domain - mydomain.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: s57.datacenterworlds.top: sender_ident via received_protocol == local: mailnull/primary_hostname/system user
X-Authenticated-Sender:s57.datacenterworlds.top: mailnull
X-Source:
X-Source-Args:
X-Source-Dir:
Return-Path: <>

Лишь в редких случаях что-то полезное есть в теле письма, типа:

Received: from mydomain.com (103.133.108.107) …

AndyM
() автор топика

Зобань его.

anonymous
()
Ответ на: комментарий от AndyM

Вот типичный получаемый нами отлуп, нечего брать из заголовков:

Received: from s57.datacenterworlds.top
(mailserver57.mylittledatacenter.com [136.243.133.242])
by mail.mydomain.com (Postfix) with ESMTP id 0AE5E8503A41

А зачем ты это получаешь?

AS ★★★★★
()
Ответ на: комментарий от Bootmen

Найти нужно среди мусора, написал со скриншота…

AndyM
() автор топика
Ответ на: комментарий от AS

Received: from s57.datacenterworlds.top

(mailserver57.mylittledatacenter.com [136.243.133.242])

Несовпадение в HELO?

Bootmen ☆☆☆
()
Последнее исправление: Bootmen (всего исправлений: 1)
Ответ на: комментарий от AS

А зачем ты это получаешь?

А и правда, почему прошло? Смотреть нужно…
на постфиксе у меня даже PTR проверяется

AndyM
() автор топика
Ответ на: комментарий от Bootmen

За это можно зацепится

За это плохо, так как резать нормальные боунсы, всё же, не стоит. Но тут признак прямо кричит: давай до свидания сразу после helo. Ну можно после rcpt to, для фиксации от кого и куда на всякий случай. Данные от такого источника не интересны от слова совсем (а From и Subject - это уже блок DATA).

AS ★★★★★
()
Ответ на: комментарий от AndyM

на постфиксе у меня даже PTR проверяется

PTR там нормальный, но вот значение helo ни разу не его fqdn, а чьё-то ещё. Формально у почтового сервера может быть несколько интерфейсов и разными ptr и т.п., но уж таких косяков быть точно не должно. А рукозадые пусть шлют через smart relay, которым сервер своего оператора пусть выбирают.

AS ★★★★★
()
Ответ на: комментарий от Bootmen

Разве тело не идет после пустой строки?

Да, после пустой. Но всё это идёт в DATA. По SMTP отдельно заголовки не передаются.

AS ★★★★★
()

это надо подумать сразу в голову ничего не идёт

вовторых не факт что исходный сервак именно вьетнамский. вьетнамский может быть промежуточным. у меня на домашнем оборудовании периодически случается всякое непечатное.

Deleted
()
Ответ на: комментарий от AS

По SMTP отдельно заголовки не передаются.

Пардон. Я проперся. :)

Bootmen ☆☆☆
()
Ответ на: комментарий от Deleted

Вьетнамский 100% market7 с ними переписывается. Скорее всего, корреспондент что-то подцепил.

AndyM
() автор топика
Ответ на: комментарий от AndyM

Если конкретно про приведенный пример с заголовком
Received: from s57.datacenterworlds.top (mailserver57.mylittledatacenter.com [136.243.133.242])

то в логах криминала не вижу:
Apr 10 16:43:21 mail postfix/smtpd[35701]: connect from mailserver57.mylittledatacenter.com[136.243.133.242]
Apr 10 16:43:22 mail postgrey[972]: action=pass, reason=triplet found, client_name=mailserver57.mylittledatacenter.com, client_address=136.243.133.242, recipient=market7@mydomain.com
Apr 10 16:43:22 mail postfix/smtpd[35701]: 0AE5E8503A41: client=mailserver57.mylittledatacenter.com[136.243.133.242]
Apr 10 16:43:22 mail postfix/cleanup[35782]: 0AE5E8503A41: message-id=E1jMTld-003y6N-Vf@s57.datacenterworlds.top
Apr 10 16:43:22 mail postfix/smtpd[35701]: disconnect from mailserver57.mylittledatacenter.com[136.243.133.242]
Apr 10 16:43:24 mail postfix/cleanup[35807]: 6D32B8503A43: message-id=E1jMTld-003y6N-Vf@s57.datacenterworlds.top
Apr 10 16:43:24 mail amavis[35625]: (35625-13) Passed CLEAN {RelayedInbound}, [136.243.133.242]:60660 [136.243.133.242] <> -> market7@mydomain.com, Queue-ID: 0AE5E8503A41, Message-ID: E1jMTld-003y6N-Vf@s57.datacenterworlds.top, mail_id: QgqJW4qxL3ai, Hits: 1.083, size: 4414, queued_as: 6D32B8503A43, 2322 ms

AndyM
() автор топика
Ответ на: комментарий от Bootmen

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access regexp:/etc/postfix/helo_access_regexp, check_helo_access hash:/etc/postfix/helo_access, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_hostname

AndyM
() автор топика
Ответ на: комментарий от Twissel

Всем доброго дня и спасибо за помощь!

Немного количество режектов увеличилось, но, скорее, само постепенно стихло!

AndyM
() автор топика
Ответ на: комментарий от AndyM

Стихло количество нападений?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.