Защита срещу спам и прихващане на потребителски идентификационни данни (фишинг) с помощта на код
Разработването и използването на 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, TRUSTe, VeriSign и много други.
Код на изпращача. Общи
Моля, имайте предвид, че никоя от системите – нито идентификаторът на изпращача, нито други механизми за удостоверяване – не са заместител на системите за филтриране на съдържание. Механизмите SIDF и DKIM не сканират действителното съдържание на съобщението. Вместо това проверката уведомява системата за входяща поща дали съобщението може да се счита за изпратено от подателя, който твърди, че е изпратил. Тъй като повечето нежелани съобщения и съобщения за прихващане на потребителски идентификационни данни наистина се изпращат отвънтези домейни, които са посочени, този подход може да бъде полезен за автоматично откриване на тези съобщения и разделянето им във входящия пощенски поток.
Опции за внедряване на кода на изпращача
Удостоверяването на изходящо съобщение със SIDF не изисква промени в инфраструктурата, софтуерни актуализации и е независимо от клиентския и сървърния софтуер. Въпреки това организациите, които искат да внедрят удостоверяване на входящи съобщения, за да защитят своята компания и служители, ще трябва да актуализират своите системи за входящи съобщения и инструменти за агент за прехвърляне на съобщения (MTA) и да внедрят софтуер или устройства, които поддържат механизма SIDF. Повечето от водещите доставчици на софтуер за нежелана поща, както и търговски и безплатни доставчици на MTA, включително Microsoft® Exchange Server и Exchange Hosted Filtering, предлагат интегрирани решения.
Microsoft внедри 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.
Въпреки това дори Microsoft получава нежелана поща и не е изключение сред другите получатели на нежелани съобщения. Microsoft получава приблизително 15 милиона съобщения на ден, а по време на скорошни спам атаки сме виждали обеми съобщения между два и четири пъти повече. В такава среда пътят към успешна защита срещу нежелана поща лежи в постоянното прилагане и внедряване на наличните технологии.
Microsoft използва вътрешно решениеЗащита срещу нежелана поща на Exchange Server, базирана на филтъра за ИД на получател на Exchange Server 2003 и агента за ИД на подател на приложението Exchange Server 2007. И в двете версии на Exchange Server състоянието на ИД на подателя се основава на оценка на записа на ИД на подател, разположен на съответните им DNS сървъри. Действителният изпращащ домейн се определя чрез анализиране на заглавките на съобщенията RFC 2822 в следната последователност:
• препратено - подател; • препратено - от; • подател; • от.
Домейнът на изпращача (или най-скорошният обект, изпратил съобщението до пощенския поток, тъй като пощенските системи могат легитимно да препращат съобщения от името на пощенските сървъри) се определя чрез последователно търсене на първата дефиниция на споменатите по-рано заглавки. Ако нито една от тези заглавки не бъде намерена, тогава SIDF машината използва стойността SMTP RFC 2821 MAIL FROM.
Настройка на кода на изпращача
В Exchange Server 2007 активирането на агента на Sender ID е възможно на сървъри, които имат инсталирана роля на Edge Transport server. Ако агентът на Sender ID е активиран, той ще филтрира съобщенията, които идват през съединители за получаване, и ще обработва всички входящи (от външни източници) съобщения, които не са удостоверени. В Exchange Server 2003 състоянието на ID на изпращача се съхранява в пътуването от сървър към сървър в етикета EXCH50; в Exchange Server 2007 това състояние също се добавя към метаданните на съобщението. На крайната дестинация метаданните и етикетът на съобщението се преобразуват в MAPI свойство за бъдеща употреба от клиента.
Настройките за филтриране на ID на изпращача в Exchange Server 2003 се конфигурират в менюто Свойства за доставка на съобщения.съобщения) и се състои в указване как Exchange Server обработва неудостоверените съобщения.
За да активирате ID на изпращача в Exchange Server 2007, просто отворете конзолата за управление на Exchange (Контролен панел на Exchange) на сървъра, за който е инсталирана ролята на сървъра Edge Transport, отидете в раздела Anti-spam, след това отидете на елемента Sender ID (Sender ID) и в панела с действия (Actions) щракнете върху бутона „Активиране“ (Активиране) или „Деактивиране“ (Изключване) на агента за идентификатор на подател, както е показано на фиг. 2. Като алтернатива можете да използвате инструмента Exchange Management Shell, за да активирате или деактивирате ID на изпращача, както е показано на Фигура 2-3. 3.
Състоянието на агента (активиран или деактивиран) се посочва в диалоговия прозорец Свойства на ИД на изпращача. В раздела Действие можете да направите настройки, подобни на тези в Exchange Server 2003 (вижте Фигура 4).
Няма големи разлики между Exchange Server 2003 и Exchange Server 2007 по отношение на внедряването и функционалността на Sender ID, филтърът за Sender ID (в Exchange Server 2003) и Sender ID Agent (в Exchange Server 2007) използват един и същ основен алгоритъм за извличане и проверка. Диапазонът от възможни действия също е същият: „Изтриване на съобщението“ (без уведомяване на потребителя), „Отхвърляне на съобщението“ (отговор на SMTP слой 500) и „Маркиране с резултата от проверката на кода на подателя и продължаване на обработката“. Последната настройка е настройката за действие по подразбиране и в двете версии на Exchange Server.
В Exchange Server 2007 както кодовете за състояние FAIL, така и TempError могат да задействат действие „Отхвърляне на съобщението“ (в Exchange Server 2003 това действие може да бъде задействано само от код за състояние FAIL).Тъй като съобщенията с код за състояние TempError се приемат от системата по подразбиране, маркират се с резултата от проверката на кода на подателя и се обработват, трябва изрично да конфигурирате агента на кода на съобщението да извиква действието Отхвърляне на съобщение.
Тази конфигурация не е предоставена в GUI, така че трябва да използвате инструмента Exchange Management Shell, за да конфигурирате действията за кода на състоянието TempError. Например, за да принудите агента за идентификатор на съобщение да бъде настроен на действието „Отхвърляне на съобщение“ за съобщения с код на състояние TempError, изпълнете следната кратка команда за агент за идентификатор на подател:
Диапазонът от резултати за статуса на ID на изпращача и възможните действия в Exchange Server 2007 и филтъра за ID на изпращача в Exchange Server 2003 е същият, както е показано на Фигура 2-3. 5.
Exchange Server 2007 улеснява идентифицирането на домейни на податели, така че тези получатели в Exchange Server трябва да бъдат изключени от списъка за проверка на ID на податели. Тази опция за персонализиране също е достъпна само чрез инструмента Exchange Management Shell. Например, за да изключите домейна contoso.com от списъка с филтърни идентификатори на получатели, трябва да изпълните следната команда:
По същия начин, за да изключите съобщенията, изпратени до определени получатели на Exchange Server, от списъка с филтри за ID на подателя, можете да използвате следната команда:
В Exchange Server 2007, стойностите на настройката за ID на изпращача, които са зададени с помощта на кратки команди на Exchange Management Shell и не са налични в GUI, могат да бъдат показани с помощта на командата Get-SenderIDConfig, изпълнена в Exchange Management Shell, както е показано на Фигура 2-3. 6.
Ако домейнът не съществува, тогава се показва екранътрезултат, както е показано на фиг. 7.
Предимства от използването на код на подател
В допълнение към очевидните предимства на удостоверяването на имейл съобщенията и намаляването на количеството спам, което потребителите получават, SIDF като протокол предлага и други предимства. По време на разработката си Microsoft се фокусира върху няколко ключови области, включително производителност, цена, внедряване, мащабируемост и оперативна съвместимост.
Механизмът SIDF проверява подателя на съобщението и след това позволява прилагането на резултата за репутация на изпращача. В резултат на това е възможно да се намали обемът на непоискани и фалшиви съобщения, както и да се подобри пропускателната способност за легитимни съобщения от известни и доверени податели. Създаването на SPF запис е безплатно, така че всяка организация, която желае да се съобрази с изискванията на SIDF, може лесно да го направи. Организациите, които искат да се съобразят с изискванията на новия стандарт, трябва да могат да го направят. Налагането на съответствие със SIDF е толкова лесно, колкото публикуването на SPF запис.
При разработването на стандарта SIDF е взето предвид изискването за максимална съвместимост със съществуващия софтуер. Може да се използва с различни архитектури за електронни съобщения, както и с широк набор от клиентски и сървърен софтуер. За да бъде ефективна, всяка услуга за удостоверяване трябва да отговаря на нуждите на голям доставчик на интернет услуги толкова лесно, колкото на нуждите на малък домашен пощенски сървър. SIDF може да поддържа от един до хиляди пощенски сървъри; към това трябва да се добавят и онези, коитопредоставят своите пощенски сървъри на други организации.
Крейг Шпизле в момента е директор Технологична стратегия и планиране за безопасност на Windows Live в Microsoft. В ролята си на продуктов мениджър за имейл автентификация, Крейг участва активно в приемането на Sender Code в индустрията. Откакто се присъедини към Microsoft през 1992 г., Крейг заема няколко ръководни позиции, включително позиции в международен маркетинг, стратегии за продуктова поддръжка, оригинални производители и нови пазари.