Привіт habr! У цій статті вирішив торкнутися теми захисту від підроблених листів (Email spoofing, Forged email). Мова піде про листи, в яких так чи інакше підробляється інформація про відправників. Одержувач бачить лист, відправлений нібито довіреною особою, але насправді, лист відправлено зловмисником.
Поштова обліковий запис зловмисника включала ім'я "best @ bestofall" і прізвище ".com". Частина листування знайомий вів з мобільного пристрою, поштовий клієнт якого відображав в поле відправника тільки ім'я і прізвище відправника. А так роблять всі мобільні поштові клієнти. Тому, що входить лист в цьому поштовому клієнті бачилося як від best @ bestofall «пробіл» .com. Що дуже схоже на оригінал. Нижче лист від зловмисника і під ним легітимне лист в інтерфейсі Яндекс.Пошти:
В Outlook лист від зловмисника теж виглядало досить схоже на оригінал, якщо уважно НЕ вдивлятися, то теж можна і не помітити підробку.
- Фільтрація на основі репутації сервера-відправника.
- Фільтрація на основі перевірок DNS-записів сервера відправника.
- Фільтрація на основі перевірок DNS-записів домену відправника з конверта листа.
- Фільтрація на основі перевірок SPF-записів.
- Фільтрація на основі DKIM.
- Фільтрація на основі DMARC.
- Створення гранулярних фільтрів «вручну».
Методи 4-6 допомагають боротися з точними підмінами відправників, тобто ситуаціями, коли в заголовках листа зловмисник вказує з точністю до знака підміняти відправник.
До методу 7 належить вдаватися у випадках як в прикладі про переписку з зарубіжною компанією на початку статті, коли заголовок листа модифікується таким чином, щоб стати схожим на реального відправника. Але при цьому, заголовок в підмінений листі все ж відрізняється від заголовка реального відправника, що дозволяє обійти перевірки методами 4-6.
Розглянемо перераховані методи більш докладно.
Приклад Cisco ESA. Репутаційна фільтрація.
Трохи конкретики на прикладі Cisco ESA. Рішення використовує репутаційну базу Sender Base. Ми бачимо, що репутаційна фільтрація допомагає зупиняти в районі 80% шкідливих листів. Причому по багаторічному досвіду впровадження та супроводу даного рішення можу сказати, що кількість помилкових спрацьовувань репутаційної фільтрації Cisco ESA прагне до нуля.
Нижче зведення по нашій організації:
Залежно від репутації відправника Cisco ESA не тільки приймає рішення відкинути лист або пропустити далі, але і визначає подальший сценарій обробки листа. Для різних значень репутації ми можемо застосовувати різні політики:
Розглянемо DNS-перевірки на прикладі Cisco ESA. При встановленні TCP-сесії виконуються наступні перевірки відправника по DNS:
3. Фільтрація на основі перевірок DNS-записів домену відправника з конверта листа. Інформація в mail from також підлягає перевірці по DNS. На прикладі Cisco ESA лист може бути відкинуто якщо:
- Інформація про домен відправника відсутня в конверті.
- Ім'я домену не дозволяється в DNS.
- Ім'я домену не існує в 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:", є легітимним.
7. Створення гранулярних фільтрів «вручну». На жаль, далеко не всі організації використовують SPF, DKIM, DMARC при відправці електронної пошти. Крім того, в деяких випадках перевірки SPF, DKIM і DMARC можуть пройти успішно, але листи виявляються все одно підробленими (Cousin domain, Free Email Accounts). Для таких випадків допомагають налаштування фільтрів. Можливості різних систем по створенню правил фільтрації різняться. Фільтри налаштовуються під різні сценарії проведення атаки і залежать від особливостей організації поштових систем в компаніях. Наприклад, в якихось компаніях можуть приходить із зовні листи з доменом-відправником цієї ж компанії. Хоча в більшості випадків такі листи повинні пересилатися тільки в межах периметра організації.
Приклад Cisco ESA. Фільтри.
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 для боротьби з атакою.
Як дії можуть бути обрані й інші варіанти: відправити в карантин, відкинути лист і т.д.
Боротися з цією ситуацією можемо, перевіряючи рівність значень в mail from і заголовку From. Відразу варто обмовитися, в загальному випадку RFC абсолютно не вимагає, щоб mail from дорівнював From. Тому застосовувати такий фільтр потрібно тільки до деяких відправникам.
Наприклад, якщо в словнику є "John Simons", а в заголовку From фігурує [email protected], система видасть ймовірність підробки 82. Якщо в заголовку From фігурує [email protected] (тобто те ж ім'я , але інший домен), система видасть ймовірність підробки 100.
Forged Email Detection налаштовується через Content Filters або Message Filters. Нижче скріншот настройки Content Filter:
Необхідно вказати ім'я словника, і граничне значення ймовірності, після якого вважаємо відправника підробленим. Для даної умови можна вибрати будь-який з доступних дій (відкинути, відправити в карантин, модифікувати тему листи і т.д.). Крім того, з'явилося нове додаткове дію для Forged Email Detection: замінити значення заголовка From на значення з mail from. Дана дія не пропонує будь-яких опцій:
