С февраля почтовый сервис Twitter перешел на поддержку DMARC – нового протокола, призванного повысить эффективность процесса аутентификации отправителя и ускорить фильтрацию входящего трафика.

Каждый день Twitter рассылает огромное количество писем по своей клиентской базе, сообщая пользователям последние новости. Однако имя этого сервиса микроблогов, как и других социальных проектов, пользующихся большой популярностью, нередко становится жертвой спуфинга. Поддельные уведомления, якобы исходящие с Twitter, – излюбленный трюк фишеров, собирающих данные участников социальных сообществ, чтобы успешней маскировать нелегитимные рассылки.

Операторы сети доставки контента CloudFlare вновь столкнулись с DDoS-атакой с плечом, построенной по методу отражения DNS-запросов. 20 Гб/с паразитного трафика вполне способны сокрушить солидный веб-узел, однако при наличии защитных технологий ёмкая прокси-сеть легко поглощала этот нескончаемый поток, причем без каких-либо проблем с доступностью. Посему было решено помониторить текущую атаку с целью сбора данных и локализации источников агрессивного DNS-трафика.

Обычный ботнет способен сгенерировать DDoS-трафик мощностью около 100Мбит/с. Некоторым сайтам этого может хватить, чтобы лечь, но в целом с точки зрения DDoS такие нагрузки вряд ли можно назвать серьезными. Усилить мощность атаки дидосерам помогает техника “ умножения ” DDoS-трафика, предполагающая использование дополнительных сетевых устройств в качестве посредников. Такой трамплин работает на злоумышленника лишь при следующих условиях:

• механизм допускает фальсификацию источника запроса (не производит проверку источника);
• ответ по объему должен значительно превосходить запрос.

Первой разновидностью DDoS с плечом были SMURF-атаки, использующие протокол ICMP. Посредником здесь служит маршрутизатор широковещательной локальной сети, конфигурация которого позволяет транслировать ping-запросы, поданные на внешний адрес, всем участникам этой сети. ICMP-протокол работает по принципу «fire and forget» ― «отправь и забудь», без процедуры взаимного опознавания отправителя и получателя. Если в заголовке пакета подменить источник эхо-запроса, подставив адрес жертвы, и направить его на широковещательный адрес, все ответы устройств за маршрутизатором единым потоком ударят по мишени. Мощность такого трафика зависит от числа участников широковещательной сети, подключенных к маршрутизатору.

Со временем SMURF-атаки сошли на нет: маршрутизаторы стали блокировать ICMP Echo-Reply или игнорировать ICMP Echo-Request. Злоумышленники переключились на другую платформу, также удовлетворяющую названным критериям, ― DNS. DNS-запросы передаются по протоколу UDP, тоже не проверяющему отправителя и посему не застрахованному от злоупотреблений. Рычагом, позволяющим увеличить мощность DDoS-удара в десятки раз, здесь служат открытые резолверы ― плохо сконфигурированные кэширующие DNS-серверы, способные принимать запросы не только от своих клиентов, но от любого пользователя Сети. Схема DDoS-атаки, использующей так называемый метод отражения DNS-запросов (DNS reflection), уже рассматривалась в нашем блоге в связи с предыдущим, более сокрушительным нападением на CloudFlare.

Новую DDoS-кампанию, использующую DNS, исследователи наблюдали 3 недели, исправно распределяя по CDN-сети ежесуточные 20 Гб/с потоки, изливающиеся на клиентский сайт. За этот период удалось установить около 68,5 тыс. открытых резолверов, принявших участие в DDoS-атаке. Наибольшее количество таких серверов было обнаружено на территории США ― страны с несметным числом автономных систем (AS). Однако с учетом общей популяции последних главным источником паразитного DNS-трафика оказался Тайвань. Его крупнейший провайдер HiNet (AS3462) занял второе место в рейтинге CloudFlare по количеству открытых резолверов, работающих на дидосеров (2992). Возглавила этот список пакистанская Pakistan Telecom Company (AS45595 ― 3359 серверов). Полный перечень AS-сетей с числом открытых резолверов (без указания IP), задействованных в свежей DDoS-атаке, можно посмотреть на отдельной странице, а также обратиться в CloudFlare за помощью.

В заключение стоит отметить, что проблема открытых резолверов существует уже более 10 лет. Беда в том, что последнее время они активно используются злоумышленниками для проведения мощных DDoS-атак. CloudFlare обещает продолжить публикацию списков открытых резолверов, которые давно ведут такие организации, как Team Cymru, и оказывать операторам сетей посильную помощь в исправлении ситуации. К этому блоку недавно примкнули и активисты HostExploit, публикующие рейтинги AS-систем по уровню вредоносной активности (Top 50 Bad Hosts). Проблеме открытых резолверов они посвятили особый раздел нового отчета, выпущенного по итогам III квартала. Здесь же приведена актуальная статистика по открытым резолверам в AS-системах, которая впредь будет регулярно обновляться. Как оказалось, 4 провайдера, включенных HostExploit в Тор 10 по этому показателю, стали невольными и весьма активными соучастниками свежей DDoS-атаки на CloudFlare. Например, тайваньская HiNet, 2-й «обидчик» CloudFlare по агрессивности DNS-трафика, в рейтинге HostExploit попала на 3-ю строчку (2464 открытых резолвера) ― после бразильской Telecomunicacoes de Santa Catarina (AS8167) и чилийской Terra Networks Chile (AS7418; 2998 и 3219 серверов соответственно).

Рабочая группа по борьбе с киберугрозами и абьюзами M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) призвала пользователей системы аутентификации DKIM усилить криптозащиту цифровых подписей и применять ключи длиной не менее 1024 бит.

Технология DKIM (DomainKeys Indentified Mail) используется как де-факто стандарт многими бизнес-структурами, правительственными учреждениями, крупными почтовыми службами. Шифрованная подпись, создаваемая по этой системе, призвана удостоверить аутентичность домена, указанного в адресе отправителя, и исключить его подделку – например, с целью фишинга. Возможность такой подделки в современных условиях была недавно продемонстрирована математиком из Флориды. При наличии доступа к недорогому “облачному” кластеру тот взломал 512-битный криптоключ Google за трое суток. Как оказалось, не только Google, но и многие другие приверженцы DKIM, включая Microsoft, PayPal, Yahoo, Amazon, eBay, Apple, Dell, LinkedIn, Twitter, HP и HSBC, используют ключи длиной менее рекомендованных 1024 бит, считая их достаточно криптостойкими. Более того, некоторые получатели принимают запущенную в тестовом режиме DKIM-подпись за подлинную, что также противоречит RFC-рекомендациям.

Удостоверившись в реальности рисков, американская CERT (Computer Emergency Readiness Team, группа быстрого реагирования на компьютерные инциденты) публично признала наличие ошибок в современных реализациях DKIM и рекомендовала поклонникам этой технологии придерживаться базовых спецификаций RFC 6376. M3AAWG тоже ратует за приведение в соответствие криптобазы DKIM на местах и опубликовала ряд полезных советов:

• длина ключа, используемого для создания подписи DKIM, должна составлять не менее 1024 бит;
• ключи менять ежеквартально;
• через настройки с каждой заменой ключа упразднять цифровую подпись и вовремя отзывать устаревшие открытые ключи, обновляя записи в DNS;
• сократить тестовый период и сразу отзывать тестовый ключ при переводе DKIM-системы в рабочий режим;
• дополнить DKIM протоколом обратной связи DMARC (Domain-based Message Authentication, Reporting and Conformance), используя его в режиме мониторинга, и отслеживать частоту обращения к своим ключам через DNS;
• использовать именно DKIM, а не его прародителя DomainKeys, который менее эффективен;
• насаждать вышеперечисленные практики в партнерской среде, оказывающей почтовые услуги.

Группа организаций-участниц проекта DMARC.org опубликовала спецификации нового механизма, призванного повысить эффективность процесса аутентификации источников электронных сообщений и уменьшить риски в отношении абьюзов.

Существенным недостатком существующих технологий аутентификации, таких как SPF и DKIM, является отсутствие обратной связи между получателем и легальным отправителем. В такой ситуации почтовый провайдер, применяющий эти механизмы, достоверно не знает, в каком объеме ими пользуется отправитель. Посему он вынужден полагаться на сложные и далекие от совершенства методики, чтобы как-то различать мошеннические подделки и легитимные сообщения, не обеспеченные средствами проверки на подлинность.

Протокол DMARC (Domain-based Message Authentication, Reporting and Conformance) призван освободить оператора почтового сервиса от игры в «угадайку», помогая ему поддерживать тесную взаимосвязь с массовым отправителем. Он определяет интеграцию техник аутентификации в инфраструктуру отправителя и позволяет сигнализировать интернет-провайдерам о наличии таких средств защиты, а также публиковать политику в отношении писем, не прошедших проверку на аутентичность (например, отправлять их в спам-карантин или блокировать). DMARC предусматривает также получение от провайдера подробной статистики, позволяющей корректировать возможные упущения.

Разработчики новой технологии надеются, что ее освоение ускорит повсеместное развертывание систем аутентификации и создание доверенной среды. Безусловно, DMARC предполагает поддержку как на стороне отправителя, так и на стороне получателя, однако у этого протокола уже есть солидная база: его полтора года активно используют 15 участников проекта. Среди них ― ведущие почтовые сервисы (AOL, Gmail, Hotmail, Yahoo), финансовые организации (Bank of America, Fidelity Investments, PayPal), социальные службы (American Greetings, Facebook, LinkedIn), поставщики защитных решений (Agari, Cloudmark, eCert, Return Path, Trusted Domain Project). По оценке Google, в настоящее время около 15% легитимных писем на ее почтовом сервисе приходит с доменов, поддерживающих DMARC.

Возможно, внедрение новшества потребует дополнительных усилий по обеспечению приватности, а также финансовых затрат. Последние, по мнению участников проекта, не должны оказаться обременительными, так как новый протокол предполагает использование действующих стандартов и технологий. Разумеется, DMARC не гарантирует 100%-ную защиту от фишинга, но поможет оперативно отсеивать явные подделки. Авторы разработки предлагают использовать новую технологию в дополнение к существующим механизмам аутентификации. Заинтересованные организации могут ознакомиться с рабочим вариантом спецификаций на сайте DMARC.org. Новый протокол будет представлен на февральских конференциях MAAWG и RSA. После его обкатки в полевых условиях участники проекта планируют обратиться в IETF для утверждения DMARC в качестве отраслевого стандарта.

Группа по стандартизации интернет-технологий, IETF, утвердила расширенный вариант протокола для обмена информацией о киберпреступлениях.

За основу протокола были взяты спецификации IODEF (Incident Object Description Exchange Format), согласно которым все отчеты о нештатных ситуациях в Сети должны предоставляться в xml-формате. В обновленной версии стандарт предусматривает также такие дополнительные возможности, как использование однозначной отметки времени, выбор языка и отправка самплов вложением. Унификация формата данных по киберинцидентам (включая фишинг и интернет-мошенничество) позволит автоматизировать их анализ и поиск по общей базе, быстрее выявлять общие тенденции и реагировать на сетевые атаки.

Один из соавторов расширений к IODEF, Антифишинговая рабочая группа (APWG), разработала программу испытаний [PDF 226 Кб] грядущего стандарта в полевых условиях. Эксперты хотят удостовериться, что информация, отправленная по электронной почте и оформленная в соответствии с новыми правилами, действительно будет четко воспринята получателем и не потребует дальнейших разъяснений. Интересно также, насколько новый формат способен стереть языковые барьеры, разделяющие специалистов из разных стран.

Ассоциация по разработке стандартов в области электротехнической и электронной инженерии (IEEE-SA) опубликовала схему xml для представления данных о вредоносных и потенциально опасных объектах.

Новый стандарт призван повысить эффективность анализа, обработки и распространения информации об интернет-угрозах, а также ускорить развертывание релевантной защиты. Схема обладает большой гибкостью и позволяет ранжировать угрозы по степени значимости. Ее уже взяли на вооружение ведущие изготовители антивирусных решений. Разработчики, интернет-провайдеры, правоохранительные органы, испытатели и прочие специалисты могут ознакомиться с ней и бесплатно скачать на сайте Группы по стандартизации средств компьютерной безопасности (ICSG) IEEE-SA.

ICSG () была сформирована в 2009 году в целях объединения опыта и ресурсов для борьбы с растущими интернет-угрозами. В настоящее время в ее состав входят представители 15-ти организаций. Группа принимала непосредственное участие в разработке вышеназванной xml-схемы и приступила к упорядочению нормативов и дефиниций, касающихся программ-упаковщиков, которыми пользуются как разработчики легального ПО, так и вирусописатели. Активисты также планируют обобщить требования к безопасности приложений и облачных вычислений, а также к протоколам управления привилегиями доступа. «Лаборатория Касперского» входит в (http://standards.ieee.org/prod-serv/indconn/faq.html#8) в Рабочую группу по вредоносным программам (Malware Working Group).

По мнению экспертов, внедрение технологии адресной защиты DNSSEC сопряжено с большими техническими сложностями и обойдется России в 100 млн. долларов.

Разработка DNSSEC была продиктована стремлением обезопасить жизненно важный, но уязвимый DNS-сервис от злоупотреблений. Современным злоумышленникам не составляет труда перехватить ответ DNS-сервера или подменить данные в кэше и перенаправить пользователя на подставной ресурс. DNSSEC предотвращает такие атаки, обеспечивая неприкосновенность DNS-данных электронной цифровой подписью.

В январе текущего года началось развертывание нового протокола на 13-ти корневых серверах, и к настоящему моменту этот процесс уже завершен. Процедура подписания корневых зон пока носит тестовый характер. Ожидается, что к июлю уже будет ясно, насколько может вырасти нагрузка на DNS-серверы вследствие внедрения защитной технологии. Если этап тестирования пройдет успешно, система будет перенесена на все доменные зоны, в том числе .ru, .рф и .su. Однако процесс ее освоения, по предварительным оценкам, может затянуться на два года.

Помимо прочего, реализация DNSSEC, особенно в крупномасштабных сетях, связана со значительными расходами. Поддержка этого протокола потребует обновления ПО как на серверной, так и на клиентской стороне. По оценке эксперта ЛК С. Голованова, в России общая сумма затрат на внедрение новой DNS-системы может составить более 100 млн. долларов.

IETF готова принять решение о введении единого формата для обмена информацией о киберпреступлениях. Утверждение нового стандарта поможет специалистам по интернет-безопасности, банковским структурам и прочим организациям более оперативно реагировать на сетевые угрозы.

За основу протокола были взяты спецификации IODEF (Incident Object Description Exchange Format), согласно которым все отчеты о нештатных ситуациях в Сети должны предоставляться в xml-формате. Обновленная версия оговаривает также такие дополнительные возможности, как использование однозначной отметки времени, выбор языка и отправка самплов вложением.

Наличие единого формата данных (в том числе по фишингу и интернет-мошенничеству) позволяет автоматизировать дифференцированный поиск по общей базе и процедуру анализа. Автоматизация этих процессов при современных объемах информации по интернет-угрозам давно стала необходимостью.

Если стандарт будет принят, говорят эксперты, осуществить его техническую реализацию будет легко. Сложнее утрясти правовые аспекты детализированного информационного обмена о киберугрозах, ведь законы о защите данных и частной жизни не везде едины. Например, IP-адрес можно расценивать как сведения личного порядка, хотя он является неотъемлемым элементом любого интернет-расследования.

Эксперты по кибербезопасности обнаружили, что в настоящее время 70% спам-рассылок, проводимых с ботнета Rustock, использует протокол TLS.

TLS (Transport Layer Security) — преемник SSL и нередко применяется в корпорациях для пересылки по почте конфиденциальной информации. В некоторых случаях организации настаивают на обязательном использовании этого протокола – например, при отправке сотрудником корреспонденции из точки беспроводного доступа к интернету. В то же время почтовый сервер, поддерживающий TLS, обычно не требует аутентификации отправителя, что, конечно, на руку спамерам.

Однако шифрование почтового трафика по протоколу TLS увеличивает нагрузку на почтовый сервер и замедляет процесс доставки. Объем дополнительного трафика, которым обмениваются участники во время сеанса связи, при этом составляет около 1 КБ, т.е. может превышать размер самого письма. Понятно, что при больших объемах рассылок, проводимых спамерами, эти накладные расходы катастрофически увеличиваются, еще больше замедляя трафик.

Такое положение вещей может отпугнуть обычных спамеров, но только не владельцев ботнета Rustock. Rustock-ботнет осуществляет спам-рассылки с большого количества IP-адресов и работает с большими перерывами. При его масштабах и высокой производительности этот ботнет вполне в состоянии справиться с проблемой дополнительного трафика, генерируемого при подключении к TLS-каналу.

Эксперты MessageLabs полагают, что операторы Rustock обновили часть спам-ботов, которые теперь могут направлять почтовому серверу запрос на TLS-соединение. Управляющий центр ботнета определяет целесообразность использования этого протокола, исходя из модификации наличных бот-агентов; его выбор в этом случае уже не зависит от типа спам-шаблона или местоположения получателей.

В начале марта, по оценке MessageLabs, TLS-спам составлял 20% от общего количества нелегитимных сообщений; за неделю его вклад увеличился почти до 35%. TLS-каналы используют и другие ботнеты — Grum, Cutwail, Bagle, но в очень ограниченном объеме.

Завершена работа над первым релизом OpenDNSSEC — инструментом с открытым исходным кодом, который призван упростить процесс подписания зон по протоколу DNSSEC.

Решение позволяет полностью автоматизировать процедуру создания DNSSEC-записей и пригодно для обслуживания как больших зон (например, TLD), так и множества малых (веб-хостинг, сервис доступа в интернет). Продукт рассчитан на работу с криптографическим модулем HSM, при его отсутствии можно воспользоваться программным эмулятором SoftHSM. Доступ к закрытым ключам, хранящимся в HSM, осуществляется через стандартный интерфейс PKCS#11. В целях экономии места один ключ может использоваться для нескольких зон.

OpenDNSSEC поддерживает криптосистемы RSA-SHA1 и SHA2, совместим со всеми юниксоидными ОС, и его установка не требует внесения изменений в существующую инфраструктуру. Программа распространяется под лицензией BSD. В марте планируется выпустить следующую версию, которая, в числе прочего, будет обладать более высоким быстродействием.

Следует подчеркнуть, что это первая реализация DNSSEC, которая позволяет интегрировать защитные функции быстро и без особых усилий. Создание протокола DNSSEC было продиктовано стремлением обезопасить жизненно важный, но уязвимый DNS-сервис от злоупотреблений. Современным злоумышленникам не составляет труда подменить записи в кэше DNS-сервера и перенаправить пользовательский запрос на подставной ресурс. DNSSEC предотвращает такие атаки, обеспечивая аутентичность и целостность DNS-данных по методу цифровой подписи. Однако по ряду весомых причин защитный протокол пока не получил широкого применения. Можно надеяться, что с появлением такого жизнеспособного инструмента, как OpenDNSSEC, одно из этих препятствий будет преодолено.