Захист від непроханої пошти та перехоплення облікових даних користувача (фішингу) за допомогою коду
Розвиток і всесвітнє використання SIDF було б неможливим без вкладу та підтримки безлічі організацій і компаній, включаючи AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, Trust, VeriSign, а також багатьох інших.
Код відправника. Загальні відомості
Зверніть увагу, що жодна з систем – ні код відправника, ні інші механізми автентифікації не замінюють собою системи фільтрації вмісту. Механізми SIDF і DKIM не сканують дійсний зміст повідомлення. Натомість перевірка повідомляє поштову систему вхідних повідомлень про те, чи може повідомлення вважатися відправленим від того відправника, який у ньому заявлено. Оскільки більшість непроханих повідомлень та повідомлень для перехоплення облікових даних користувача дійсно відправляються не зтих доменів, які вказуються, цей підхід може бути корисним для автоматичного визначення цих повідомлень та їх відокремлення в потоці вхідної пошти.
Можливості розгортання коду відправника
Перевірка автентифікації вихідних повідомлень за допомогою SIDF не потребує будь-яких змін інфраструктури, оновлень програмного забезпечення та не залежить від програмного забезпечення клієнта та сервера. Однак для організацій, які хочуть впровадити перевірку автентичності вхідних повідомлень для захисту своєї компанії та співробітників, потрібно оновити свої системи вхідних повідомлень та засоби «Агент передачі повідомлень» (MTA) і здійснити розгортання програмного забезпечення або пристроїв, які підтримують механізм SIDF. Більшість провідних постачальників програмного забезпечення для боротьби з непроханою поштою, а також постачальників комерційних та безкоштовних MTA, включаючи Microsoft® Exchange Server та Exchange Hosted Filtering, пропонують інтегровані рішення.
Корпорація Майкрософт впровадила SIDF у всі свої продукти для обміну повідомленнями, включаючи Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live Mail, MSN Hotmail, Outlook Express, а також поштовий клієнт із можливістю спільної роботи Office Outlook.
Проте навіть корпорація Майкрософт отримує непрохану пошту і не є винятком серед інших одержувачів непроханих повідомлень. Щодня корпорація Майкрософт отримує приблизно 15 мільйонів повідомлень, а протягом недавніх спам-атак ми спостерігали обсяг повідомлень від двох до чотирьох разів більше. У подібному середовищі шлях до успішного захисту від непроханої кореспонденції лежить у постійному застосуванні та впровадженні доступних технологій.
Корпорація Майкрософт використовує внутрішнє рішенняExchange Server для захисту від непроханої кореспонденції на основі фільтра коду одержувача програми Exchange Server 2003 та агент коду відправника програми Exchange Server 2007. В обох версіях програми Exchange Server стан коду відправника ґрунтується на оцінці запису коду відправника, розташованого на відповідних серверах DNS. Дійсний домен відправлення визначається за допомогою аналізу заголовків повідомлення RFC 2822 у наступній послідовності:
• переслано - відправник; • переслано -з; • відправник; • із.
Домен відправника (або пізніший об'єкт, що здійснив відправлення повідомлення в потік пошти, оскільки поштові системи можуть законно пересилати повідомлення від імені поштових серверів) визначається шляхом пошуку у зазначеній послідовності першого визначення раніше згаданих заголовків. Якщо жодного з цих заголовків не знайдено, то механізм SIDF використовує значення SMTP RFC 2821 MAIL FROM.
Налаштування коду відправника
У Exchange Server 2007 включення агента коду відправника можливе на серверах, де встановлена роль «прикордонний транспортний сервер». Якщо агент коду відправника включений, то він буде фільтрувати повідомлення, що надходять через з'єднувачі отримання та обробляти весь вхідний (із зовнішніх джерел) потік повідомлень, які не пройшли автентифікацію. У Exchange Server 2003 стан коду відправника зберігається в дорозі між серверами в мітці EXCH50, в Exchange Server 2007 цей стан також додано до метаданих повідомлень. У кінцевому призначенні метадані повідомлення та мітка перетворюються на властивість MAPI для майбутнього використання клієнтом.
Налаштування фільтрації коду відправника в Exchange Server 2003 здійснюється в меню Message Delivery Properties (Властивості доставкиповідомлень) і полягає у призначенні способу обробки програмою Exchange Server повідомлень, що не пройшли автентифікацію.
Щоб увімкнути код відправника в Exchange Server 2007, достатньо відкрити панель Exchange Management Console (Панель управління Exchange) сервера, для якого встановлена роль «прикордонний транспортний сервер», перейти на вкладку «Anti-spam», далі перейти до пункту «Sender ID» (Код відправника) та в панелі «Actions» (Дії) натиснути кнопку «Enable» (Увімкнути) або «Disable» (Вимкнути) агента коду відправника, як показано на рис. 2. Крім того, для увімкнення або вимкнення коду відправника можна використовувати засіб Exchange Management Shell, як показано на рис. 3.
Стан агента (увімкнений або вимкнений) вказується в діалоговому вікні Sender ID Properties (Властивості коду відправника). На вкладці «Action» (Дія) можна здійснити настройки, подібні до тих, що є в Exchange Server 2003 (див. мал. 4).
Щодо впровадження та функцій коду відправника між серверами Exchange Server 2003 та Exchange Server 2007 великих відмінностей немає, фільтр коду відправника (Exchange Server 2003) та агент коду відправника (Exchange Server 2007) для вилучення та перевірки використовують однаковий базовий алгоритм. Діапазон можливих дій також однаковий: "Видалити повідомлення" (без повідомлення користувача), "Відхилити повідомлення" (відповідь протоколу SMTP рівня 500) та "Поставити мітку з результатом перевірки коду відправника та продовжити обробку". Остання установка є стандартною установкою в обох версіях Exchange Server.
У Exchange Server 2007 обидва коди стану FAIL і TempError можуть викликати дію «Відхилити повідомлення» (в Exchange Server 2003 ця дія може бути викликана лише кодом стану FAIL).Оскільки повідомлення з кодом стану TempError за замовчуванням приймаються системою, відзначаються результатом перевірки коду відправника і обробляються, для виклику дії «Відхилити повідомлення» необхідно налаштувати агент коду повідомлення явним чином.
Можливість такого налаштування не надається у графічному інтерфейсі, тому для налаштування дій для коду стану TempError необхідно використовувати засіб Exchange Management Shell. Наприклад, для примусового настроювання агента коду повідомлення на дію «Відхилити повідомлення» для повідомлень з кодом стану TempError запустіть наступний командлет агента коду відправника:
Діапазон результатів стану коду відправника та можливих дій у Exchange Server 2007 та фільтра коду відправника у Exchange Server 2003 однаковий і показаний на рис. 5.
Exchange Server 2007 дозволяє легко визначати домени відправника, тому ці одержувачі в Exchange Server повинні бути виключені зі списку перевіряються за кодом відправника. Ця можливість також доступна лише за допомогою Exchange Management Shell. Наприклад, щоб виключити домен contoso.com зі списку фільтра коду одержувача, слід виконати таку команду:
Так само, щоб виключити повідомлення, надіслані до зазначених одержувачів Exchange Server зі списку фільтра коду відправника, можна використовувати таку команду:
У Exchange Server 2007 значення налаштувань коду відправника, задані за допомогою командлетів Exchange Management Shell і недоступні в графічному інтерфейсі, можуть бути виведені на екран за допомогою команди Get-SenderIDConfig, виконаної в засобі Exchange Management Shell, як показано на рис. 6.
Якщо домен не існує, на екран виводитьсярезультат, як показано на рис. 7.
Переваги використання коду відправника
Крім очевидних переваг при перевірці автентичності електронних повідомлень і зниження кількості непрошеної пошти, що отримується користувачами, SIDF як протокол пропонує інші переваги. Під час його розробки корпорація Майкрософт орієнтувалася на кілька ключових моментів, що включають продуктивність, ціну, розгортання, масштабованість та можливість взаємодії.
Механізм SIDF здійснює перевірку відправника повідомлення, після чого дозволяє застосування оцінки репутації відправника. Внаслідок цього досягається можливість зменшення обсягу непроханих та фальсифікованих повідомлень, а також покращується пропускна спроможність для законних повідомлень від відомих та довірених відправників. Створення запису SPF здійснюється безкоштовно, тому це легко може зробити будь-яка організація, яка забажає відповідати вимогам SIDF. Організації, які бажають відповідати вимогам нового стандарту, повинні мати для цього відповідні можливості. Забезпечити відповідність вимогам SIDF так само легко, як зробити публікацію запису SPF.
При розробці стандарту SIDF враховувалася вимога максимальної сумісності з програмним забезпеченням. Він може використовуватися з багатьма архітектурами обміну електронними повідомленнями, а також широким спектром клієнтського та серверного програмного забезпечення. Щоб забезпечити ефективну роботу, будь-яка служба автентифікації повинна задовольняти потреби великого постачальника послуг доступу в Інтернет так само легко, як і потреби малого домашнього поштового сервера. SIDF може підтримувати від одного тисяч поштових серверів; до цього слід додати тих, хтонадають свої поштові сервери іншим організаціям.
Крейг Шпіцле (Craig Spiezle) в даний час є директором відділу Technology Strategy and Planning for Windows Live Safety корпорації Майкрософт. Працюючи як менеджер з продуктів перевірки автентичності електронних повідомлень, Крейг активно сприяв впровадженню коду відправника у цій галузі. Розпочавши роботу в корпорації Майкрософт у 1992 році, Крейг займав кілька управлінських посад, включаючи посади у відділі міжнародного маркетингу, відділу стратегій підтримки продуктів, відділі роботи з оригінальними виробниками, а також у відділі освоєння нових ринків.