queued mail for delivery что значит
Компонент Database Mail: Письмо в очереди не доставлено
В этом подразделе описывается, как решать проблему, когда электронное сообщение успешно ставится в очередь, но не доставляется.
Диагностика проблемы
Внешняя программа компонента Database Mail ведет журнал активности электронной почты в базе данных msdb.
Чтобы убедиться, что компонент Database Mail включен, воспользуйтесь параметром Database Mail XPs системной хранимой процедуры sp_configure, как в следующем примере.
Затем, чтобы проверить состояние почтовой очереди, выполните следующую инструкцию в базе данных msdb:
Подробное описание столбцов см. в разделе sysmail_help_queue_sp (Transact-SQL).
Проверьте, есть ли какие-либо изменения представления sysmail_event_log. В этом представлении должна находиться запись, удостоверяющая, что запущена внешняя программа компонента Database Mail. Если ее нет в представлении sysmail_event_log, см. раздел Сообщение поставлено в очередь, но записей нет в sysmail_event_log. Если в представлении sysmail_event_log появились ошибки, устраните их.
Если в представлении sysmail_event_log есть записи, свидетельствующие о запуске внешней программы, проверьте сообщения о состоянии в представлении sysmail_allitems.
Состояние сообщения — не отправлено
Состояние не отправлено означает, что внешняя программа компонента Database Mail еще не обработала электронное сообщение. Иногда она не очень быстро это делает, скорость их обработки зависит от параметров сети, времени ожидания перед повтором, объема сообщений и ресурсов SMTP-сервера. Если проблема остается, попробуйте отсылать сообщения из нескольких профилей и с нескольких SMTP-серверов.
Проверьте последнюю дату успешной отправки сообщений. Если после последней успешной отправки прошло много времени, через представление sysmail_event_log убедитесь, что внешняя программа была успешно запущена компонентом Service Broker. Если последняя попытка активировать программу завершилась ошибкой, убедитесь, что внешняя программа компонента Database Mail находится в верном каталоге и учетная запись службы SQL Server имеет разрешения на ее запуск.
Чтобы удалить старые неотправленные сообщения, дождитесь момента, когда они станут самыми старыми сообщениями в очереди, а затем воспользуйтесь хранимой процедурой sysmail_delete_mailitems_sp для их удаления.
Состояние сообщения — идет повтор
Состояние «retrying» свидетельствует о том, что компонент Database Mail попытался доставить сообщение, но SMTP-сервер не смог этого сделать. Обычно причиной служат ошибки в сети, сбой SMTP-сервера или неправильная конфигурация учетной записи компонента Database Mail. Рано или поздно это сообщение будет отправлено или не отправлено и сохранено в состоянии ошибки и с записью в журнале событий.
Состояние сообщения — отправлено
Состояние отправлено означает, что внешняя программа компонента Database Mail успешно доставила электронное сообщение SMTP-серверу. Если у получателя сообщение не появилось, то это означает, что SMTP-сервер принял сообщение от компонента Database Mail, но не смог доставить его получателю. Проверьте журналы SMTP-сервера или свяжитесь с его администратором. SMTP-сервер также можно проверить с помощью другого почтового клиента, например Outlook Express.
Состояние сообщения — сбой
Состояние «Сбой» означает, что внешняя программа компонента Database Mail не смогла доставить электронное сообщение SMTP-серверу. В этом случае в представлении sysmail_event_log есть подробные сведения, полученные из внешней программы. Образец запроса, соединяющего представления sysmail_faileditems и sysmail_event_log для получения сообщений об ошибках, см. в разделе Проверка состояния сообщений электронной почты, отправленных при помощи компонента Database Mail. Наиболее частая причина ошибок — неверный адрес получателя, проблемы в сети, из-за которых внешняя программа не может использовать учетные записи отработки отказа. Проблемы SMTP-сервера также могут быть причиной того, что сообщения сервером отклоняются. Чтобы выяснить, где происходит ошибка, в мастере настройки компонента Database Mail измените значение параметра Уровень ведения журнала на Подробный и отправьте тестовое сообщение.
Настройка Relay коннектора в Exchange Server 2010
В большинстве организаций, использующих Exchange Server 2010, возникает необходимость разрешения пересылки почты (relay) определенным классам хостов и устройств, позволяя им самостоятельно пересылать почту через сервера Exchange. Обычно это нужно различным многофункциональным устройствам (принтеры, сетевые сканеры, МФУ) или же специализированному инфраструктурному софту (софт резервного копированию, мониторинга), которые должны отсылать отчеты и алерты в виде электронных писем.
Все SMTP коммуникации в архитектуре Exchange 2010 обрабатываются серверами с ролью Hub Transport. Служба доставки на этих серверах ожидает SMTP подключений на свой коннектор(Receive Connector). Однако, данный коннектор по умолчанию настроен на высокий уровень безопасности, которые запрещает анонимные подключения (а именно так подключаются для отправки почты практически все не Exchange системы).
Проверить данное утверждение, можно, попытавшись подключиться к серверу с помощью telnet на 25 порт и попробовать инициировать неавторизованное SMTP соединение.
На некоторых серверах Hub Transport, которые подключены к интернету или другим сетям, анонимные подключения могут быть разрешены. Но и в этом случае relay (пересылка) почты будет запрещена, однако ошибка будет отличаться от указанной в первом случае.
Вы увидите, что сервер выдаст ошибку о невозможности пересылки (Unable to relay) при попытке отправить письмо с ящика @mail.ru на ящик на @gmail.com, т.к. ни один из этих доменов не является верным доменом в организации Exchange. Однако, анонимному пользователю на данном коннекторе разрешено отправлять письма с внешнего домена @mail.ru на существующий в домене Exchange внутренний адрес.
Но, если попытаться отправить письмо внешнему получателю, сервер Exchange не позволит сделать это.
Чтобы разрешить не-Exchange устройствам внутри сети пересылать (relay) почту, необходимо создать новый коннектор на сервере Hub Transport. Откроем консоль Exchange Management и перейдем в раздел Server Management, затем в Hub Transport. Выберите сервер с ролью Hub Transport, на котором необходимо создать новый коннектор получения и выбрать меню New Receive Connector.
Укажем имя коннектора, например, “Relay ” и жмем Next.
Настройки локальной сети можно оставить по-умолчанию или же задать выделенный IP адрес для данного коннектора. Использование отдельного адреса целесообразно, когда нужно создать коннектор с нестандартными настройками аутентификации, но когда настройки главного коннектора менять нельзя.
Выделите стандартный диапазон IP адресом в окне настройки удаленных сетей (remote network settings) и удалите его.
Затем нажмите кнопку Add и введите IP адрес устройства (сервера) которому вы хотите разрешить пересылку почты через сервер Exchange. Нажмите OK и Next.
Чтобы заверить работу мастера нажмите кнопку New.
Итак, мы создали новый коннектор (Receive Connector), однако на данный момент он не может выполнять пересылку почты. В консоли управления Exchange Management щелкните правой кнопкой мыши по только что созданному коннектору и выберите его свойства.
На вкладке Permission Groups установите флажок на опции Exchange Servers.
На вкладке Authentication отметьте опцию Externally Secured.
Применим изменения к данному коннектору, и удостоверимся что теперь можно выполнить relay.
Т.к. диапазон удаленных IP адресов, мы сузили до 1 адреса, это означает, что с других серверов или устройств почта пересылаться не будет. Если попытаться подключиться к данному коннектору с другого IP адреса и попробовать выполнить relay, доступ будет запрещен.
В дальнейшем список ip адресов, которым разрешена пересылка можно модифицировать, добавляя в него ip адреса конкретных устройств, диапазоны адресов или целые подсети.
Postfix What does «Queued mail for delivery» mean?
I sent an email to 2 receipients and I checked maillog:
I noticed that there is an extra info
in the line to= and mrs_lorem@the-bank.com.vn says that she doesn’t see that email in her mailbox.
Could you please explain what does that ( Queued mail for delivery ) mean? And did email server at the-bank.com.vn received that email?
2 Answers 2
When an SMTP client connects to a mail server, it sends a sequence of commands, like the following example ( C = Client, S = Server )
Each command sent by the client gets a response from the server which starts with a status code, 2xx codes being success. There’s also usually a second code after this, but the rest of the line can generally be whatever the server wants to send.
The text in brackets in the log is the entire line returned by the recipient’s server when your system finished giving it the message. This starts with the status code (success in this case), but the rest of it is just whatever the server wanted to send.
In this case that looks like the normal response from an Exchange server (IIRC), and basically says thanks, I’ve put the message in my queue ready to deliver. (Most mail servers have processes that handle accepting inbound mail, placing it in a inbound-delivery queue, and separate processes that actually deliver the message to mailboxes.)
Having this in the log is often useful for debugging because it usually contains the message ID the recipient server assigned the message (If the recipient’s mail admin can’t find the message you can give them the log entry / id). Gmail return the following for instance, which appears to be their timestamp (handy if someone complains about a message at 10:45:23, but after scouring logs you discover the sender’s time is 3 hours out), and an ID.
Basically, SMTP server developers usually put text in that last response that will help that server’s administrator locate/track the message.
Cisco ESA. Message XXXXX queued for delivery
На нашей стороне Cisco ESA или Cisco Ironport. Возникает проблема, когда до получателя не доходит сообщение. В Message Tracking есть запись вида:
Возможно, хост получателя вышел из строя, Cisco ESA это понимает и поэтому в Message Tracking покажет «queued for delivery». При этом, никаких фактических попыток доставки мы не увидим. Можно подумать, что имеются проблемы с нашим ESA.
Когда у электронной почты есть временная ошибка доставки, вызванная тем, что хост почтового сервера имеет статус упавшего (down) — мы не увидим нотификацию о невозможности доставки, т.к. это событие является soft bounce.
Soft bounce означает, что мы пытаемся доставить сообщение, но оно не достигает почтового сервера получателя и, поэтому, устройство помечает хост получателя как упавший и не повторяет попытку доставки в течение часа. Если хост не принял их через час, будет повторная попытка в течение 2 часов после этого и так далее, пока письма в итоге не отскочат с hard bounce или хост получателя снова не станет доступным.
Статус хоста-получателя можно проверить через CLI устройства. Вводим команду «tophosts» и ищем хосты с отмеченной рядом *. Эти хосты не отвечают и считаются упавшими. Попытки доставить сообщения будут продолжаться с таймаутом и если устройство поднимется, доставка возобновится.
Стоит протестировать через telnet на 25 порт от интерфейса доставки на вашем устройстве к затронутым почтовым серверам. Если соединение не удалось, то это и есть причина, по которой никакие электронные письма не доставляются.
Если telnet прошёл успешно, но никакая доставка еще не сделана, то это связано с тем, что счетчик ещё не сбросился, поэтому можно использовать команду «delivernow» в CLI для принудительной доставки.
Ответ Cisco
There are instances where a mail host may go down and there fore the appliance registers host as down and message tracking will show ‘queued for delivery’ but no actual delivery attempts done and a customer may think the ESA is unable to deliver anymore and reboots the system to restore it and it works and has a concern on health of the system
When an email has a temporary delivery failure cause the mail server host was reported as ‘down’ on the appliance, it will treat this as a soft bounce event and not a hard bounce – therefore you will not see a bounce notification reply.
Soft bounce emails means the appliance attempts a delivery, it fails to reach the mail server so the appliance marks the recipient host as ‘down’ and does not re-attempt for an hour, if it’s still down, all emails to that host will be re-attempted for 2 hours after and so on until it eventually hard bounces or the recipient host status shows as ‘up’ again on the appliance.
If the host is showing as down due to mail server unresponsive and the appliance already puts the status as down and delays all deliveries, the appliance will still not attempt any deliveries for old and new emails to that host until the next counter reset happens for the appliance to attempt a connection again
The way to see the status of recipient host is to review ‘tophosts’ in your appliance CLI (Command Line Interface), any hosts with a * marked next to it means that the appliance attempted delivery and there is no reply in the connection attempt so it is marked as down until the counter resets, after which the appliance attempts another connection, if successful it will tag the host as ‘up’ and resume all deliveries, if not it will hit another counter and will not attempt any connections until the counter resets, for new and old emails to that recipient host.
You would need to attempt a port 25 telnet test from the appliance’s delivery interface to the affected mail servers, if the connection had failed then it would be the reason why no emails are delivering to this mail server.
If successful and no delivery is made as yet, that would be due to the counter has not reset, so I would suggest in this circumstance to force deliveries use the ‘delivernow’ command on the CLI.
To initiate a telnet test for delivery, first locate the delivery interface.
This will show the interface that is used. When you see ‘auto’ this suggests that the system will choose the interface closest to the default gateway.
To initiate a telnet test
(6 оценок, среднее: 5,00 из 5)
Загрузка.
Подделка писем. Как защищаться
Привет habr! В данной заметке решил затронуть тему защиты от поддельных писем (Email spoofing, Forged email). Речь пойдёт о письмах, в которых так или иначе подделывается информация об отправителях. Получатель видит письмо, отправленное якобы доверенным лицом, но на самом деле, письмо отправлено злоумышленником.
В последнее время всё чаще слышим о проблеме поддельных писем от наших заказчиков, да и просто от знакомых. Эта проблема не только актуальна, но, похоже, набирает обороты. Вот реальная история от знакомого, который был близок к тому, чтобы потерять сумму с четырьмя нулями в долларовом эквиваленте. В компании велась переписка на английском языке с зарубежной компанией о приобретении дорогостоящего специализированного оборудования. Сперва нюансы возникли на стороне нашего знакомого – потребовалось изменить реквизиты счёта отправителя (компанию-покупателя). Через некоторое время, после успешного согласования новых реквизитов, поставщик оборудования также сообщил о необходимости изменения реквизитов счёта получателя (компанию-продавца). Вот только письма об изменении данных получателя шли уже от злоумышленников, удачно подменявших адрес отправителя. На фоне некоторой общей суматохи, усугубляющейся ещё и тем, что обе стороны не являлись носителями языка переписки, заметить подмену писем было практически невозможно. Нельзя не отметить и тот факт, что злоумышленники старательно копировали стили, шрифты, подписи и фотографии в письмах. Как именно утекла информация о сделке – скорее всего была скомпрометирована почтовая переписка. За неделю до финального согласования сделки, о которой идет речь в этой статье, на почту знакомого пришло письмо с трояном, в виде счета-фактуры в *.exe архиве. На момент прихода письма антивирус не отловил зловреда, и тот, некоторое время успел “поработать” на компьютере, и даже подтянуть на подмогу пару своих собратьев.
Через несколько дней сигнатуры антивируса обновились и зловред с собратьями был удален, но к тому моменту в переписку уже вклинились, отправителя подделали, деньги ушли на чужой счёт.
В данном примере подмена адреса отправителя была сделана крайне незамысловато. Реальные адреса мы не опубликуем, но приведём аналогичный пример.
Правильный адрес отправителя: best@bestofall.com
Поддельный адрес отправителя: bestbestofall.com@spoofed.ru.
В Outlook письмо от злоумышленника тоже выглядело достаточно похоже на оригинал, если внимательно не всматриваться, то тоже можно и не заметить подделку.
Компании по всему миру терпят существенные убытки из-за Email-атак (источник). Так с октября 2013 по август 2015 совокупный убыток от компрометаций корпоративной электронной почты компаний по всему миру составил 1,2 миллиарда долларов США. А атаки с поддельными письмами находятся среди самых распространённых видов атак на корпоративные почтовые системы.
Особое внимание уделяется атакам, при которых злоумышленник отправляет поддельное письмо от имени высокопоставленного руководителя компании. В тексте письма злоумышленник требует незамедлительного ответа, или какой-либо срочной реакции от сотрудника или группы сотрудников компании. Например, может потребовать ответить на письмо отправкой какой-либо конфиденциальной информации. Это может привести к утечке данных. Или злоумышленник может потребовать срочный банковский перевод какой-либо крупной суммы. В описанных сценариях сотрудник ощущает давление: высокопоставленный руководитель требует безотлагательных действий. Этот факт повышает вероятность успеха атаки. Кроме того, атаке может предшествовать рекогносцировка методами социальной инженерии, чтобы наиболее эффективно сформировать текст письма и наиболее точно выявить целевую группу сотрудников, которые получат поддельное письмо. Данный подход также благотворно влияет на успех атаки.
Для того, чтобы разобраться с механизмом подделки адреса отправителя, вспомним структуру электронного письма, передаваемого по протоколу SMTP. Электронное письмо состоит из конверта (envelope), заголовков (headers) и тела письма (message body). Информация об отправителе содержится в конверте. Эта информация формируется SMTP-командой mail from и оказывает непосредственное влияние на процесс пересылки сообщения по мере прохождения почтовых cерверов Mail Transfer Agent (MTA). Однако, информация об отправителе также содержится в некоторых заголовках письма, таких как “From:”, “Return-Path:”, возможно “Reply-To:”. Заголовок “From:” не обязательно должен совпадать с тем, что написано в конверте письма и может представлять некоторое «дружеское имя» (friendly name, friendly from). Заголовок “Return-Path:” копирует отправителя из конверта. Заголовок “Reply-To:” содержит адрес для ответа. Заголовки значимы для почтового клиента (например, MS Outlook), по заголовкам заполняются соответствующие поля.
Рассмотрим пример SMTP-команд для отправки письма с поддельными заголовками “From:” и “Reply-To:”. Подключаемся к почтовому серверу Exchange с помощью telnet:
В данном примере мы отправляем с реального адреса attacker@spoofed.ru письмо, но в заголовке “From:” указываем имя и адрес руководителя компании, а в заголовке “Reply-to” адрес на mail.yandex, куда невнимательный сотрудник отправит конфиденциальную информацию. В итоге письмо в почтовом клиенте Outlook будет выглядеть следующим образом:
А если нажать «Ответить» автозаполнится адрес получателя:
Как видно из предыдущего примера, отправить поддельное письмо не составляет большого труда, если почтовый сервер не защищён. В худшем случае, значение в конверте письма mail from также может быть подменено на легитимное. Если тело письма составлено аккуратно и с применением результатов социальной инженерии, выявить поддельное письмо становится всё сложнее для конечного пользователя. Ситуация ещё более усугубляется для пользователей мобильных устройств. Концепция мобильности предполагает, что все действия выполняем быстро, «на ходу», да ещё и на небольшом экране, не обращая внимание на мелочи/несоответствия. Кстати говоря, в примере про сделку с зарубежной компанией у знакомого тоже не обошлось без фактора «мобильности». Часть переписки проходила с мобильного устройства, почтовый клиент в поле отправителя отображал только имя/фамилию отправителя, но скрывал полный почтовый адрес.
Не существует единого метода борьбы с подменёнными письмами. Защита от данного вида атак требует комплексного и многоуровневого подхода. Попробую выделить основные подходы борьбы с поддельными письмами:
Методы 4-6 помогают бороться с точными подменами отправителей, то есть ситуациями, когда в заголовках письма злоумышленник указывает с точностью до знака подменяемый отправитель.
К методу 7 предстоит прибегать в случаях как в примере про переписку с зарубежной компанией в начале статьи, когда заголовок письма модифицируется таким образом, чтобы стать похожим на реального отправителя. Но при этом, заголовок в подменённом письме всё же отличается от заголовка реального отправителя, что позволяет обойти проверки методами 4-6.
Рассмотрим перечисленные методы более подробно.
1. Фильтрация на основе репутации сервера-отправителя. Если система защиты корпоративной почты обеспечивает качественную базу репутаций отправителей, мы можем фильтровать значительный процент распространителей спама и вредоносной корреспонденции любого вида уже на этапе установления TCP-сессии, не заглядывая ни в тело, ни в конверт письма. Такой подход существенно экономит ресурсы системы. Как только отправитель пытается установить TCP-сессию на порт 25, система защиты определяет репутацию для IP-адреса отправителя, и принимает решение.
Немного конкретики на примере Cisco ESA. Решение использует репутационную базу Sender Base. Мы видим, что репутационная фильтрация помогает останавливать в районе 80% вредоносных писем. Причём по многолетнему опыту внедрения и сопровождения данного решения могу сказать, что количество ложных срабатываний репутационной фильтрации Cisco ESA стремится к нулю.
Ниже сводка по нашей организации:
В зависимости от репутации отправителя Cisco ESA не только принимает решение отбросить письмо или пропустить далее, но и определяет дальнейший сценарий обработки письма. Для различных значений репутации мы можем применять различные политики:
2. Фильтрация на основе проверок DNS-записей сервера отправителя. Отправитель почтовых сообщений должен быть корректно зарегистрирован в DNS. Для отправителя должны существовать корректные PTR запись, А-запись. Отправитель должен корректно представляться в SMTP-команде HELO. При массовых рассылках спама и вредоносов злоумышленники постоянно меняют IP-адреса рассылающих серверов. Адреса меняются каждый день и даже чаще. Регистрировать необходимые записи в DNS сложно и даже невозможно. Поэтому, многие распространители спама и вредоносных сообщений пренебрегают данными требованиями, соответственно, появляется возможность их фильтровать по признакам DNS.
Рассмотрим DNS-проверки на примере Cisco ESA. При установлении TCP-сессии выполняются следующие проверки отправителя по DNS:
Хочу обратить внимание, на данном этапе проверок ESA не контролирует легитимность отправителя, то есть не проверяет, имеет ли право отправитель слать письма от указанного домена. Более того, на данном этапе ни конверт письма, ни заголовки не просматриваются. Отрабатывает только проверка по IP-адресу. Например, если письма от домена mycompany.ru будут идти с «левого» IP-адреса с корректными A- и PTR-записями в DNS, например, «smtp.spamer.ru», проверка пройдёт успешно и письмо будет пропущено для дальнейшей обработки. Проверка легитимности отправителей осуществляется другими методами (см. далее SPF-записи, DKIM, DMARC).
3. Фильтрация на основе проверок DNS-записей домена отправителя из конверта письма. Информация в mail from также подлежит проверке по DNS. На примере Cisco ESA письмо может быть отброшено если:
4. Фильтрация на основе проверок SPF-записей. SPF – Sender Policy Framework – система проверки отправителей электронных сообщений. Проверка методом 2 «DNS-записи сервера отправителя» говорит только о том, что для IP-адреса отправителя существуют необходимые записи в DNS (PTR- и A-записи). Однако данные проверки не помогают определить, имеет ли право сервер отправитель слать письма от указанного домена. Стоит заметить, часто A-записи почтовых серверов содержат в себе имя домена компании, например, smtp01.mycompany.ru. Если этот же сервер используется для приёма почты, то эта же A-запись будет входить и в MX-запись. Можно предположить, что если письмо от mycompany.ru отправлено с сервера smtp01.mycompany.ru, то это письмо не поддельное, в противном случае, если письмо отправлено с smtp01.anythingelse.ru, письмо поддельно. Но на самом деле часто компании отправляют электронную корреспонденцию не напрямую со своих почтовых серверов, а через какие-либо дополнительные серверы MTA, например, через сервера своих провайдеров. В этом случае получаем, что письмо от домена mycompany.ru отправляется через серверы, к примеру, smtp01.provider.com, smtp02.provider.com и т.д. Канонические имена серверов отправителей не принадлежат домену компании mycompany.ru. Как на стороне получателя в данном случае понять, являются ли серверы-отправители легитимными или нет? Эту задачу решает система проверок SPF.
Задача решается опять же с помощью DNS. Для домена отправителя публикуется TXT-запись специального формата. В данной TXT-записи перечисляются IP-адреса, подсети или А-записи серверов, которые могут отправлять корреспонденцию, серверы, которые не являются легитимными отправителями. Благодаря системе SPF получатель может обратиться к DNS и уточнить, можно ли доверять серверу отправителю письма, или же сервер отправитель пытается выдать себя за кого-то другого.
На данный момент SPF-записи формируют далеко не все компании.
5. Фильтрация на основе DKIM. DKIM — DomainKeys Identified Mail – технология аутентификации электронных сообщений. Вернёмся к примеру из рассмотрения SPF-записей, когда компания mycompany.ru отправляет корреспонденцию наружу через провайдерские MTA smtp01.mycompany.ru и smtp02.provider.com. Для MTA существуют SPF-записи, поэтому письма от mycompany.ru, отправленные через эти серверы, успешно проходят проверку. Но что если данные MTA окажутся скомпрометированными, и злоумышленник также получит возможность отправлять поддельные письма через эти серверы? Как установить подлинность отправителя в этом случае? На помощь приходит аутентификация писем.
Для аутентификации используется ассиметричная криптография и хеш-функции. Закрытый ключ известен исключительно серверу отправителю. Открытый ключ публикуется опять же с помощью DNS в специальной TXT-записи. Сервер отправитель формирует отпечаток заголовков письма с помощью хэш-функции и подписывает его, используя закрытый ключ. Подписанный отпечаток вставляется в заголовок письма “DKIM-Signature:”. Теперь получатель письма с помощью открытого ключа может получить расшифрованный отпечаток и сравнить его с отпечатком полей полученного письма (хеш-функция известна). Если отпечатки совпадают, подписанные заголовки не были изменены при передаче, а отправитель письма, сформировавший заголовок “DKIM-Signature:”, является легитимным.
6. Фильтрация на основе DMARC. DMARC — Domain-based Message Authentication, Reporting and Conformance — техническая спецификация, описывающая как именно следует использовать результаты проверок SPF и DKIM. Политики DMARC публикуются как обычно с помощью DNS в TXT-записи. Политики DMARC указывают, что именно нужно делать с письмом на стороне получателя (доставить, отбросить, отправить в карантин), в зависимости от результатов проверок SPF и DKIM. Кроме того, DMARC обеспечивает обратную связь отправителя с его получателями. Отправитель может получать отчёты о всех электронных письмах, имеющих домен отправителя. Информация включает IP-адреса серверов-отправителей, количество сообщений, результат в соответствии с политиками DMARC, результаты проверок SPF и DKIM.
7. Создание гранулярных фильтров «вручную». К сожалению, далеко не все организации используют SPF, DKIM, DMARC при отправке электронной почты. Кроме того, в некоторых случаях проверки SPF, DKIM и DMARC могут пройти успешно, но письма оказываются всё равно подделанными (Cousin domain, Free Email Accounts). Для таких случаев помогают настройки фильтров. Возможности различных систем по созданию правил фильтрации разнятся. Фильтры настраиваются под различные сценарии проведения атаки и зависят от особенностей организации почтовых систем в компаниях. Например, в каких-то компаниях могут приходит из вне письма с доменом-отправителем этой же компании. Хотя в большинстве случаев такие письма должны пересылаться только в пределах периметра организации.
Мы более ориентированы на Cisco ESA, поэтому в заключении рассмотрим несколько примеров настройки фильтров на этом решении, а также интересную функциональность, появившуюся в релизе 10.0 (от июня 2016) программного обеспечения для Cisco ESA — Forged Email Detection. Данная функциональность как раз позволяет бороться с неточной подделкой отправителей, как в примере из начала статьи. Если заинтересовало, велкам в подкат.
Cisco ESA предлагает два типа фильтров: Content Filters и Message Filters. Первые настраиваются с помощью GUI и предлагают конечный (хотя и достаточно обширный) список условий и действий. Пример из GUI:
Если Content Filters не достаточны, чтобы описать условия попадания письма под действие фильтра, можно использовать Message Filters. Message Filters настраиваются из командной строки, используют регулярные выражения для описания условий и позволяют создавать сложные условия (например, If ( ( (A and B) and not C ) or D ) ). Message Filters обрабатывают письмо до Content Filters и позволяют создавать более гранулярные правила.
Рассмотрим несколько сценариев подделки отправителя и соответствующие фильтры Cisco ESA для борьбы с атакой.
Пример 1. Письма с доменом организации в отправителе не должны приходить из вне. Пример взят из с cisco.com: ссылка. Пример актуален в том случае, когда организация не готова публиковать свои SPF и Domain Keys в DNS. В данном примере используется следующий Message Filter:
В качестве действия могут быть выбраны и другие варианты: отправить в карантин, отбросить письмо и т.д.
Пример 2. В начале статьи мы рассматривали пример, когда mail from из конверта письма был не поддельный (attacker@spoofed.ru, то есть атакующий пишет свой верный адрес), однако в заголовке From указывался поддельный адрес (uskov@cbs.ru). При этом, ничто не мешает атакующему завести SPF и Domain Keys в DNS для домена spoofed.ru. Получаем, что поддельное письмо пройдёт проверки SPF и DKIM. Также, проверки SPF и DKIM будут успешно пройдены, если злоумышленник использует бесплатную почту (free mail accounts – gmail.com, mail.ru и т.д.).
Бороться с данной ситуацией можем, проверяя равенство значений в mail from и заголовке From. Сразу стоит оговориться, в общем случае RFC совершенно не требует, чтобы mail from равнялся From. Поэтому применять такой фильтр нужно только к некоторым отправителям.
Пример 3. Злоумышленники используют адреса, похожие на адреса отправителей, так называемые “Cousin domains” и “Cousin addresses”. Например, адрес uskov@cbs.ru заменяется на usk0v@cbc.ru. Для домена cbc.ru формируются SPF и Domain Keys в DNS, поэтому письма проходят соответствующие проверки SPF и DKIM успешно, а получатель письма видит знакомого отправителя. Бороться с такой подменой сложнее. Придётся заносить в словарь Spoofed_senders из предыдущего примера все похожие варианты имён отправителей и названий домена, что едва-ли возможно.
Для борьбы с данным видом подмены отправителей у Cisco ESA, начиная с релиза AsyncOS 10.0 (от июня 2016 года), появилась интересная функциональность “Forged Email Detection”. Сперва создаётся словарь имён отправителей (в примерах используется имя словаря FED), как и в предыдущем примере, в который будем заносить отправителей, подверженных подмене. Этот словарь формируется из имён отправителей, а не из имён почтовых ящиков. То есть нужно писать Olivia Smith вместо olivia.smith@example.com. Система Forged Email Detection будет сверять заголовок From с именами из словаря FED и выдавать вероятность (от 1 до 100), с которой отправителя можно считать подделанным.
Например, если в словаре есть “John Simons”, а в заголовке From фигурирует j0hn.sim0ns@example.com, система выдаст вероятность подделки 82. Если в заголовке From фигурирует john.simons@diff-example.com (то есть то же имя, но другой домен), система выдаст вероятность подделки 100.
Forged Email Detection настраивается через Content Filters или Message Filters. Ниже скриншот настройки Content Filter:
Необходимо указать имя словаря, и пороговое значение вероятности, после которого считаем отправителя подделанным. Для данного условия можно выбрать любое из доступных действий (отбросить, отправить в карантин, модифицировать тему письма и т.д.). Кроме того, появилось новое дополнительное действие для Forged Email Detection: заменить значение заголовка From на значение из mail from. Данное действие не предлагает каких-либо опций:
Атаки на электронную почту с подделкой отправителя, к сожалению, повседневная реальность. А последствия успешного проведения такого рода атаки могут быть крайне плачевными как для каждого человека в отдельности, так и для атакуемой организации в целом. Возможны существенные материальные потери и утечки конфиденциальной информации. Надеюсь, статья поможет разобраться как с анатомией атак поддельными письмами, так и со способами защиты. В примерах я оперировал решением Cisco ESA, однако, инструменты защиты, упомянутые в статье, реализуемы и на других системах защиты корпоративной электронной корреспонденции.