Sender Policy Framework, як засіб боротьби зі спамом

Наша взаимовыгодная связь https://banwar.org/

Інтернет розроблявся як закрита військова мережу, з часом мережа стала откритойвсплилі прорахунки, результат яких DOS атаки, підробка імен DNS, черви, спам і багато іншого. Все це реалії сьогоднішнього Інтернету. Технологія Sender Policy Framework лише одна зі спроб виправити ситуацію.

Технології боротьби зі спамом в RFC

Змінити діючі технології в глобальному масштабі вже не можливо. Це зажадає колосальних витрат як тимчасових так і фінансових. Тому всі напрацювання з'являються у вигляді розширень до вже діючих протоколів. Так Sender Policy Framework (структура політики відправника) є ще одним розширенням до протоколу відправки електронної пошти SMTP (Simple Mail Transfer Protocol). Протокол SMTP, який замінив в 80х роках UUCP, не підтримує єдиної схеми авторизації користувача при відправці повідомлення. В результаті можна легко відправити повідомлення, вказавши в команді MAIL FROM, довільний, в тому числі і неіснуючий поштову адресу відправника. Така поведінка нормально, адже спочатку протокол передбачав і ситуацію, коли автор повідомлення та його відправник не одне і те ж обличчя. Та й поняття відправника SMTP вельми заплутано. Під цей термін потрапляють заголовки From, Sender, Resent-From і навіть Envelope-from (заголовок, що виробляється поштовими програмами).

Результатом стала поява кількох рекомендацій і доповнень до SMTP. Так в RFC 2505 від лютого 1999 року, який так і називався "Anti-Spam Recommendations for SMTP MTAs" дана оцінка спаму як явищу, заговорили про необхідність боротьби зі спамом, який в той час вже досяг високого рівня. І дано 13 рекомендацій, виконання яких допоможуть зменшити кількість спаму. Зокрема рекомендувалося підтвердження FQDN (Fully Qualified Domain Name) відправника повідомлення, тобто перевірка address-> name повинна відповідати name-> address, і обговорені всі проблеми, які можуть виникнути під час такої перевірки. Всі події повинні реєструватися, в SMTP серверах повинна бути закладена можливість блокування вузла, мережі або конкретного відправника. Саме звідси бере початок захід ери open relay серверів, так як першим пунктом рекомендації йдеться про необхідність аутентифікації користувача перед відправкою повідомлення. До речі в цьому ж року 1 березня відкритим форумом ISP (http://www.ofisp.org/) був схвалений документ "Норми користування мережею" (Acceptable Use Policy), який регламентував норми роботи в мережі, в тому числі і обмеження на інформаційний шум (спам) і був обов'язковий для всіх користувачів.

Наступний цілком логічний етап, поява спеціального розширення Simple Authentication and Security Layer (SASL) дозволяв клієнтові SMTP вказати серверу механізм аутентифікації, зробити обмін за обраним протоколу аутентифікації для ідентифікації відправника, шляхом нового виклику «AUTH». Все це описано в RFC 2554 "SMTP Service Extension for Authentication" вийшов в березні 1999 року (тобто через місяць після 2505).

Паралельно розвивалися численні фільтраційні методи, які використовують статистичний аналіз змісту листа (тут найбільш популярні рішення, що працюють за алгоритмом заснованому на теоремі Байеса), системи визначення ознак масовості повідомлення, а також різні варіанти кольорових списків: DNS Black List (DNSBL), сірий і білий списки .

Технологія Sender Policy Framework

Технологія Sender Policy Framework (SPF) є відкритим стандартом і визначена в RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1" або SPFv1, який був опублікований в квітні 2006 року. Початок розробок датована червнем 2003 року (хоча були і попередники), тоді проект мав іншу назву Sender Permitted From або SMTP + SPF. Після розпаду групи MTA Authorization Records in DNS (MARID), яка займалася просуванням стандарту, назва була змінена (лютий 2004 року). У липні 2005 SPF був схвалений групою займається стандартизацією Інтернету IESG (Internet Engineering Steering Group) для експерименту IETF (Internet Engineering Task Force) і оформлений у вигляді робочого проекту - draft (http://www.schlitt.net/spf/spf_classic/draft -schlitt-spf-classic-02.html). Сама технологія була розроблена Менгу Уенг (Meng Weng) засновника компанії POBOX, деякий час вся інформація по SPF розміщувалася на сайті http://spf.pobox.com/. В даний час проект змінив прописку [4]. До весни 2004 розробки велися щодо мляво. Потім технологія набула широкого розголосу, а великі компанії на кшталт Google, Altavista, AOL, Amazon, еBay, GMX, W3C і інші як, змовившись разом, оголосили про її впровадженні. Все це супроводжувалося неабиякої галасом і потужною рекламною компанією, і деякий час складалося враження, що спам буде переможений.

Після першої публікації з'явилося кілька варіантів на тему SPF, кілька відрізнялися між собою, тому варіант RFC 4408 прийнято називати Classic SPF. Суть нової технології проста. Адміністратор поштового домена за допомогою спеціальної SPF-записи в DNS зоні перераховує «дозволені» адреси, з яких може відправлятися пошта. Тобто, наприклад адміністратор домену example.org вказує, які машини уповноважені відсилати електронну пошту, адресу «MAIL FROM» у якій закінчується на «@ example.org». Сервер, який отримав повідомлення з цього домену, звіряє IP-адреса з SPF-записом. Якщо відправник може бути перелічений «дозволених» адрес, то лист вважається таким, що перевірку. Інакше, в залежності від використовуваної політики повідомлення відкидається або позначається як підозра на спам. Крім цього RFC настійно рекомендує перевіряти і тотожність поля «HELO».

Перевірка SPF дає деяку ймовірність того, що адреса відправника не було підроблено, яку потім можна врахувати в правилі антиспамового фільтра. Звичайно спамеру нічого не варто створити свій домен в якому увімкнути надсилання повідомлень з будь-якої адреси, але це вимагає додаткових капіталовкладень, тимчасових витрат і деякої легалізації. Це здатне ускладнити життя спамеру, особливо на тлі жорсткості законодавства по відношенню до спаму. До того ж сьогодні левова частка спаму йде з зламаних комп'ютерів і з підробленими зворотними адресами, а SPF якраз і націлена на ідентифікацію подібної пошти. Після того як технологія стала відомою, з'явилося кілька публікацій, як на російських, так і західних ресурсах, в яких показана низька ефективність SPF (приблизно від 1 до 3%). З огляду на, що інтерес в даний час кілька вщух, сьогодні часто доводиться чути думку про те, що через низьку ефективність SPF в її використанні немає сенсу. Все не так просто як здається на перший погляд. Є кілька моментів, про які слід пам'ятати. Найголовніше, що SPF це все-таки колективна система, тобто, для найбільш ефективної її роботи необхідно, щоб поштові системи відправника і одержувача її використовували. І чим більше буде таких систем, тим більша ймовірність того, що повідомлення спамерів відправлені нібито з вашого домену будуть відсіяні. А на ранньому етапі розвитку масового поширення SPF якраз і не могла похвалитися.

З іншого боку технологія SPF є як би дзеркальним відображенням DNSBL. Завдання останньої "очорнити" відправника повідомлення. Для цього всі спамерські адреси (або запідозрені в таких діях) заносяться в базу, якщо лист відправлено з адреси наявного в цій базі воно відкидається. Проблема полягає в тому, що адреси спамерів відстежити не реально, а от випадки коли в списки блокування потрапляли нормальні відправники, відомі. У SPF не намагаються відстежити спамерів, навпаки ресурси, дозволені з точки зору цієї технології можна уявити як якийсь аналог "білого" списку. Тому SPF можна розглядати не як спробу "очорнити" відправника, а навпаки вказати, що відправник легальний і з точки зору адміністратора домену має повне право відсилати електронні повідомлення. Якщо сервер клієнта зламаний і з нього деякий час розсилався спам, то вилучити адресу з чорного списку на порядок важче, ніж "дозволити" відправляти пошту за допомогою SPF.

Однією з проблем використання SPF, є його застосування при пересиланні (forward) повідомлень, коли в процесі пересилання один з поштових доменів не буде зазначений як дозволений. Такі випадки непоодинокі, пересилання використовується для збору повідомлень в одному поштовому ящику або для резервування. Якщо весь процес відбувається всередині організації вирішити цю задачу можна відключенням перевірки SPF на всіх серверах крім вхідного і внесенням резервних поштових серверів в SPF-списки. З "зовнішніми" кореспондентами ситуація не така проста. Більшість запропонованих сьогодні рішень (підміна відправника, передача додаткової інформації про реальний відправника та інші) припускають модифікацію ПО. Хоча її можна вирішити за рахунок більш тонкої настройки політик SPF з використанням механізму exists, тобто встановити, що з повідомленнями, отриманими безпосередньо довіряти більше, надісланим менше.

Виходячи зі сказаного, технологію SPF ні в якому разі не можна називати універсальним засобом боротьби зі спамом. Тільки при спільному використанні з іншими рішеннями вона буде ефективна. Особливо на тлі того, що великі гравці вже її використовують. У заголовку повідомлення, що прийшов з Mail.ru на Gmail можна знайти такий рядок:

Received-SPF: pass (google.com: domain of [email protected] designates 199.099.099.099 as permitted sender).

Що свідчить про використання SPF обома. Аналізуючи спам в декількох своїх поштових скриньках за кілька місяців, можу сказати, що в вузлах використовують SPF ніколи не зустрінеш повідомлення відправленого з адрес на кшталт mail .ru, gmail .com і інших, тобто тих, які підтримують SPF. Там де ця технологія не використовується, можна зустріти повідомлення з будь-яких адрес.

інтерпретація результату

В RFC 4408 визначено кілька можливих результатів перевірки легітимності адреси відправника в процесі SMTP запиту (в дужках вказані класифікатори, які використовуються в правилах):

- None - означає, що в цьому домені немає опублікованих SPF-записів, тому визначити дозволу не можливо;

- Neutral ( «?») - власник домену явно вказав, що він не може, вказати всі адреси або не хоче встановлювати дозволу, обробляється аналогічно None і служить більше для інформаційних цілей;

- Pass ( «+») - такий результат означає, що клієнт уповноважений відсилати повідомлення і в сенсі репутації домен тепер "відповідає" за відправлене повідомлення;

- Fail ( "-") - це явне твердження того, що клієнт не уповноважений відсилати пошту з цього домену та сервер має право позначити таке повідомлення або відкинути. У разі якщо повідомлення відкидається протягом SMTP запиту, сервер повинен використовувати код відповіді 550 SMTP і якщо підтримує код 5.7.1 DSN (Delivery Status Notification) (як при SMTP аутентифікації). - SoftFail ( "~") - це проміжна відповідь між "Fail" і "Neutral", тобто відповідальний за домен вказує, що відправник не має права посилати повідомлення, але не хоче стверджувати це явно. Приймаюча сторона не повинна відкидати повідомлення виключно на підставі такого результату, а й управі піддати його більш ретельному аналізу, ніж "Pass".

- TempError - в процесі SPF перевірки сталася помилка і клієнт має право прийняти таке повідомлення або тимчасово його відхилити. Якщо повідомлення відхиляється в ході SMTP запиту, повинен використовуватися код 451 і 4.4.3 DSN.

- PermError - така помилка означає, що відповідь не може бути інтерпретований правильно, така помилка вимагає ручного втручання власника домену, так як може виникнути, якщо результат є роботою скриптів.

Публікація SPF-політики

І так для перевірки легітимності відправника система SPF вимагає три параметра: HELO, MAIL FROM і його IP-адресу. Ключовими компонентами такої системи є наявність SPF-записи і підтримка розширення поштовим сервером. Розберемо спочатку, що повинен зробити адміністратор домену, щоб підтримати у себе SPF. Включити підтримку SPF в DNS дуже просто. Запис це проста рядок в базі даних DNS, що містить директиви. Наприклад, в BIND і сумісних з ним за форматом текстового запису зони серверів, опис політики буде виглядати так:

example.com.INTXT "v = spf1 + mx ip4: 192.168.0.0/24 a: mail.example.com -all"

Тобто:

- підтримується протокол SPFv1 - v = spf1;

- пошта з домену example.com може приходити з адрес належать мережі 192.168.0.0, з сервера mail.example.com і MX-серверів цього домену (+ mx), всі інші (all), отримають Fail і пройти перевірку ці адреси не зможуть ( "-").

Так було в первинному варіанті, але подальша експлуатація показала, що використання TXT не оптимальне. Тому було запропоновано новий тип запису - SPF. Політика в ньому виглядає аналогічно:

example.com.IN SPF «v = spf1 + mx ip4: 192.168.0.0/24 a: mail.example.com -all»

Хоча для сумісності RFC рекомендує використовувати одночасно обидва цих поля.

Як видно з прикладу, ставлення власника до певного адресою, вказується за допомогою класифікаторів, про які говорилося више.Классіфікатор Pass ( "+") встановлюється за умовчанням і його можна опускати під час запису, хоча для наочності його краще все-таки використовувати. Якщо власник домену визначив відомі йому ресурси, а права інших чітко встановлювати не хоче, то в правилі, написаному вище можна використовувати "~ all" або "? All" замість явного заборони "-all". Якраз випадок створення "білого" списку за допомогою SPF. Причому зверніть увагу, що все зазначене після all тестуватися не буде, тому all має стояти в запису останнім. За даними Вікіпедія (http://en.wikipedia.org/wiki/Sender_Policy_Framework) згідно з проведеними дослідженнями всього близько 5% com і net доменів використовує SPF та й то у вигляді "v = spf1? All". Чи не в цьому секрет низької ефективності.

В RFC визначено ряд механізмів (mechanism) дозволяють описати об'єкти яким дозволено або заборонено відсилати пошту. До основних відносяться all і include. Про all сказано вище, а механізм include дозволяє адміністратору визначити кілька адміністративно незалежних областей і не описувати правила для кожної. Наприклад, розглянемо таке правило:

example.com.IN TXT "v = spf1 + mx include: example.net include: example.org -all"

Тепер якщо буде прийнято повідомлення, відправлене з домену example.com, буде проведена перевірка SPF записів і в доменах example.net і example.org. Якщо відправка пошти з цієї адреси хоча б в одному з них дозволена, письму буде присвоєно статус Pass. Хоча тут є цікавий момент, адже показана вище запис і записи в доменах example.net і example.org можуть мати правило -all. Як повинен вести себе механізм SPF. У рекомендаціях цей момент описаний просто, тільки явний збіг правила ( «if-pass») в доменах зазначених за допомогою include, призведе до зупинки процесу пошуку і видачі результату. До речі якщо в цих доменах НЕ буде SPF записи, буде отримана помилка PermError.

Інший вид механізму певний в RFC як "designated sender", дозволяє вказати в політиці діапазон адрес відправника повідомлень. Можливо кілька варіантів:

- a (a [: hostname / CIDR}) все IP-адреси комп'ютера hostname;

- mx (mx [: domain / CIDR]) - все IP-адреси MX-серверів домену, якщо в домені єдина MX запис рекомендується вказувати його явно, тобто через "a", не рекомендується протягом одного запиту обходити більше 10 записів;

- ptr (ptr [: domain]) - IP-адреси PTR-записи яких вказують на domain, як і при MX не рекомендується проходити більше 10 записів;

- ip4 / ip6 (ip4: ip4-network / CIDR) -мережу діапазону IPv4 або IPv6, заборонено опускати частини адреси на зразок 192.168.0., За замовчуванням CIDR становить 32 (IPv4) і 128 (IPv6);

- exists - дуже корисна можливість в той же час є причиною появи PermError. Дає можливість адміністратору визначати дозволу за допомогою складних запитів до DNS. Як правильно складати макроси, описано в 8 разделеRFC 4408.

Якщо кількість серверів не велика, то при складанні SPF записи можна скористатися ресурсом [5]. Робиться це, просто вводите домен і натискаєте Begin, буде проаналізовано відповідь DNS сервера і запропоновано заповнити інші поля. Після натискання на Continue буде згенеровано запис для BIND і tinydns (djbdns), а також дані деякі пояснення англійською.

Перевірити вірність SPF записів можна одним з інструментів описаних на сторінці Tools [6]. Можливі два варіанти: відсилання поштового повідомлення, або вказівку адреси та відправника, в спеціальній формі на сайті. Крім того, в репозитарії Ubuntu знайшовся пакет spfqtool (SPF Query Tool). З його допомогою можна також перевірити правильність SPF записи, ввівши все три параметра IP-адреса (- i), поштову адресу (- s) і вузол HELO (- h).

$ Spfqtool -i 194.144.197.145 -s [email protected] -h ua.fm

SPF short result: softfail

SPF verbose result: policy result: [softfail] from rule [~ all]

RFC2822 header: Received-SPF: softfail (ua.fm: domain of transitioning [email protected] does not designate 194.144.197.145 as permitted sender) receiver = ua.fm;

з lient_ip = 194.144.197.145; [email protected];

Включення підтримки SPF в Postfix

На сторінці [7] наведено список серверів спочатку підтримують технологію SPF. Це Communigate Pro, Courier, Exim, Kerio MailServer идругие. Тут же є посилання на розширення і патчі дозволяють включити таку підтримку в поштовий сервер або клієнт. У список останніх потрапили такі популярні продукти як Postfix, Qmail, Sendmail, Exchange, Lotus Domino, Thunderbird, PowerDNS і інші. Для прикладу розберемо, як підключити SPF до Postfix. На сторінці [7] для Postfix є кілька патчів, деякі з них зажадають перекомпіляції. Якщо таке не планується найкраще, підійде пакет на Perl - postfix-policyd-spf-perl. Для його роботи потрібно наявність Mail :: SPF і NetAddr :: IP (про останній в README, чому то нічого не сказано). Встановлюється він звичайним чином.

$ Perl - MCPAN - e shell

cpan> install Mail :: SPF

cpan> install NetAddr :: IP

cpan> q

Викачуємо, розпаковуємо, копіюємо пакет на місце.

$ Wget -c http://www.openspf.org/blobs/postfix-policyd-spf-perl-2.002.tar.gz

$ Tar xzvf postfix-policyd-spf-perl-2.002.tar.gz

$ Sudo cp postfix-policyd-spf-perl / postfix-policyd-spf-perl / uar / lib / perl /

$ Perl / usr / lib / perl / policyd-spf-perl

У файл / etc / postfix / master .cf додаємо наступний рядок:

policyunix-nn - spawnuser = nobody argv = / usr / bin / perl / usr / lib / perl / policyd-spf-perl

Ів /etc/postfix/main.cf редагуємо політику smtpd_recipient_restrictions, добавівдвестрокі:

smtpd_recipient_restrictions =

...

reject_unauth_destination

check_policy_service unix: private / policy

...

Перезапускаємо Postfix.

$ Sudo /etc/init.d/postfix restart

Цей скрипт є аналогом spfqtool, тому якщо його запустити в командному рядку, можна протестувати SPF запис (запустити вручну потрібно в будь-якому випадку, щоб переконатися у відсутності помилок).

$ Perl / usr / lib / perl / policyd-spf-perl

Крім описаних у виразках технологій були ще дві: Designated Mailers Protocol (DMP) http://www.pan-am.ca/dmp/) і Reverse Mail Exchanger (RMX) http://www.ietf.org/internet-drafts /draft-danisch-dns-rr-smtp-03.txt. За принципом роботи вони нагадують SPF, але останнім часом про них нічого нового не чули. Спам перемогти важко, ще в RFC 2505 сказано, що тільки комбінація юридичних і технічних методів, ймовірно, дасть найкращий результат. З юридичної окуляри зору справа зрушила, в деяких станах спам оголошений поза законом. Технічно можливість ідентифікувати користувача за допомогою SPF або подібних рішень не зможе повністю знищити спам, але здатна зупинити його значну частину. Проблема одна, сьогодні лише мала частина доменів використовує SPF записи, або відмовляється правилом начебто ~ all. Висновок напрошується сам. Успіхів.

====== Sender ID ============

Побіжне знайомство з технологією SenderID (Sender ID: Authenticating E-Mail) пропонує компанія Microsoft, може викликати відчуття дежа-вю. Таке враження, що це SPF в вільному переказі студента-трієчників. Тут є все той же, що і в SPF тільки для ідентифікації джерела повідомлень буде використаний метод Purported Responsible Address (PRA, можливий відповідальний адреса), якому присвячено цілий RFC 4407 "Purported Responsible Address in E-Mail Messages". Різниця між відправником в SPF і загадковим PRA в SenderID полягає в тому, що перші перевіряють адресу відправника повідомлень, а другі запис про реєстрацію адреси останнього відправника, тобто джерело повідомлення на останньому етапі пересилання. Якщо такого немає, то виходить SPF = Sender ID. Короткий опис роботи Sender ID на сайті Microsoft до болю нагадує SPF (а щоб зрозуміти, що хотіли сказати RFC потрібно як мінімум пара пляшок пива). Поява Sender ID свого часу викликало просто неймовірний шквал критики, особливо з боку спільноти OpenSource. Експерти, що входять в робочу групу MARID, вирішили, що використання в якості стандартів технологій, які можуть виявитися запатентованими, неприйнятне. Суперечливі умови ліцензування, до того деякий час взагалі не доступні для громадськості і несумісність з класичним SPF привели до того, що від використання в своїх продуктах Sender ID відразу ж відмовилися спільноти розробників Apache, Debian, SendMail, QMail, Exim і інші. В кінці жовтня 2004 була представлена ​​оновлена ​​версія Sender ID в розробці, якій брав участь Менг Уенг. Вона вже була частково сумісна з SPF і підтримувала оригінальний синтаксис SPF (при записі spf2.0 / mfrom, pra підтримуються обидва стандарти). Як би там не було, ще до прийняття рішення IETF, нова технологія вже розкручувалася під всю, і незабаром її підтримували всі поштові сервери Microsoft, включаючи служби MSN Mail і Hotmail. Sender ID був схвалений одночасно з SPF в RFC 4406, в якому сказано, що за успіхом або невдачею обох технологій буде вестися спостереження протягом наступних 2 років. Після чого буде прийнято рішення про єдиному стандарті. Трохи пізніше було оголошено, що Sender ID включений в програму Microsoft Open Specification Promise (обіцянку відкритих специфікацій), тобто зобов'язання не подавати в суд ні на кого, хто буде використовувати цю технологію і сумісну з GPL. Хоча висновок один, в світі великих грошей боротьба зі спамом ні кого не цікавить.

=========

==== Common Access Card =====

Вельми цікава розробка Міністерства оборони США потихеньку що стає на цивільні рейки. Суть її така. Кожен військовослужбовець і цивільний персонал цього міністерства має «типову карту доступу» (Common Access Card, http://www.cac.mil/) побудовану на основі смарт-карти з вбудованим мікропроцесором, в якій записані цифрові сертифікати PKI з інформацією про користувача. Така карта використовується як посвідчення особи, для аутентифікації і доступу до комп'ютерних мереж (Army Knowledge Online - AKO), друку і сканування документів і в тому числі для підтвердження повноважень при відправці поштових повідомлень. Кожен житель США має Social Security number (SSN) складається з 9 цифр (перші 3 вказують на регіон проживання, ходять чутки, що 2 середні цифри вказують на етнічну приналежність), тому при бажанні CAC можна легко використовувати для аутентифікації користувача в Інтернет. Фахівці сходяться на думці, що використання технології на кшталт САС дещо ускладнить незаконний доступ до ресурсів, але аж ніяк не зможе йому перешкодити. Крім того карти можуть зношуватися і ламатися, пристрої зчитування не працювати і інше, що позначиться на доступі до ресурсів цілком легальних користувачів.

посилання:

1. RFC 2505 http://tools.ietf.org/html/rfc2505

2. RFC 2554 - http://tools.ietf.org/html/rfc2554

3. RFC 4408 - http://tools.ietf.org/html/rfc4408

4. Сайт SPF - http://www.openspf.org/

5. Record wizard для створення SPF записи http://old.openspf.org/wizard.html

6. Сторінка Tools -http: //www.openspf.org/? Back = Tools

7. Список продуктів підтримують і не підтримуються SPF - http: // www .openspf .org / Implementations

8. Ресурс Sender ID - http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx

Стаття опублікована в журналі Системний Адміністратор (http://www.samag.ru/)