от DNS к DNSSEC

Опубликовано Опубликовано в рубрике WEB, Безопасность

Почти каждое обращение к информационным ресурсам Интернета начинается со взаимодействия с доменной системой имен DNS. Будь то посещение веб-сайта, обмен почтовыми сообщениями или общение в социальной сети, для определения фактического нахождения ресурса, а именно его IP-адреса, необходима DNS. Эта система обеспечивает трансляцию имени ресурса (например, facebook.com) в его IP-адрес (2a03:2880:f129:83:face:b00c::25 de), необходимый для установления связи.

Система DNS является иерархической и распреде­ленной. Каждый из компонентов доменного имени обслуживается независимым оператором, а трансляция имени происходит посредством последовательного обращения к серверам, обслуживающим базы данных этих имен, или «зон», за ответом. Ответом может быть или указание на сервер, обслуживающий следующий компонент имени (т.н. реферрал), или окончательный ответ.

  • Рис. 1 Уязвимые места DNS.

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

Для того чтобы лучше понять важность обеспечения безопасности DNS, рассмотрим, насколько уязвима система в целом. Различные уязвимые места системы показаны на рисунке 1, а методы защиты — на рисунке 2.

Первый вопрос — насколько защищен собственно процесс подготовки данных, редактирования и создания зоны DNS. Ошибочные данные, умышленно или случайно оказавши­еся в зоне, например, неправильные адреса веб-сайта или почтовых серверов, будут переданы пользователю в ответ на его запрос независимо от использования протоколов защиты DNS, таких как DNSSEC. В данном случае значение имеет уровень внутренней безопасности и защищенности процесса.

Данные также могут быть модифицированы при передаче от мастер-сервера ко вторичным DNS-серверам, обслужи­вающим зону. Сегодня для проверки целостности передачи данных используется протокол TSIG (Transaction SIGnature), описанный в стандарте IETF RFC 2845 «Secret Key Transaction Authentication for DNS (TSIG)».

Ответы от DNS-серверов также могут быть модифици­рованы в процессе передачи в Интернете, но, пожалуй, наибольшую опасность представляет попадание непра­вильных данных в кэш итеративных резолверов — так называемое отравление кэша. Дело в том, что продолжи­тельность жизни данных в кэше, определяемая параметром TTL записи ресурса (например, IP-адрес веб-сайта), может быть достаточно значительной. Это означает, что в течение всего этого времени при модификации данных кэша пользователи будут получать подложные ответы. Более того, внедрение подложных данных в кэш резолвера не представляет особого труда, как было продемонстрировано Дэном Камински в 2008 году. С тех пор в программное обеспечение большинства стандартных резолверов были введены изменения, усложняющие проведение атаки, но только DNSSEC является единственным эффективным методом защиты, поскольку позволяет криптографически проверить аутентичность данных перед загрузкой их в кэш.

Еще одной возможностью публикации ложных данных в DNS является создание лжесерверов DNS. Поскольку адресация и доступ к серверам происходит по их IP-адресу, атака на систему маршрутизации, а именно «захват» соответствующего адресного префикса, может привести к перенаправлению части запросов DNS к DNS-серверу злоумышленника. Соответственно, злоумышленник получает возможность публикации ложных данных с далеко идущими последствиями. Данная угроза особенно значительна при масштабном внедрении технологии аникаст, когда несколько серверов, расположенных в различных частях Интернета, используют один и тот же IP-адрес. В этом случае отличить достоверный DNS-сервер от лжесервера становится сложнее.

Рис. 2 Методы защиты DNS.

Наконец, ответы резолвера на запросы клиентов могут быть также модифицированы. DNSSEC здесь не поможет, если пользователь не производит проверку подлинности ответов самостоятельно, а полагается на резолвер. Правда, канал между резолвером и пользователем как правило находится под административным контролем сервис-провайдера или администратора корпоративной сети, и зачастую имеет высокую степень защиты, напри­мер, с помощью VPN.

Эффективным средством противостояния послед­ствиям модификации данных DNS является применение расширений безопасности DNS, разработанных в рамках IETF (Internet Engineering Task Force, www.ietf.org) и получивших название DNSSEC.

Как защитить DNS?

Давайте теперь поговорим более подробно о технологии, позволяющей защитить многие уязвимые места DNS, связанные с целостностью и аутентичностью данных.

В рамках IETF были расширены возможности стандартно­го протокола DNS для решения проблемы аутентичности и целостности данных. Эти расширения получили название DNSSEC. Основная спецификация DNSSEC содержится в стандартах IETF RFC4033, RFC4034, RFC4035 и RFC5155.

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

В рамках стандартного подхода к информационной без­опасности рассматриваются три основных аспекта данных — их конфиденциальность, целостность и доступность. Целью технологии DNSSEC является защита целостности данных, а точнее, обеспечение возможности проверки целостности данных. Конфиденциальность не является требованием в DNS, а доступность обеспечивается путем усиления инфраструктуры — например, использования технологии аникаст. Кстати, при использовании аникаст вопросы аутентичности и целостности данных встают еще острее, увеличивая ценность DNSSEC.

DNSSEC основан на криптографии с использованием открытых ключей. Администратор зоны подписывает все записи зоны своей цифровой подписью. Там же админи­стратор публикует и открытый ключ, соответствующий этой цифровой подписи. Таким образом, путем проверки подлинности цифровой подписи и ее принадлежности администратору зоны пользователь может убедиться в целостности и аутентичности полученных данных.

Подлинность открытого ключа удостоверяет администра­тор родительской зоны путем включения в зону т.н. записи DS, представляющей собой хэш открытого ключа дочерней зоны. Разумеется, эта запись заверена цифровой подписью администратора этой родительской зоны. Его же ключ удостоверяется администратором зоны верхнего уровня — и так далее, пока не будет достигнута так называемая точка доверия (trust anchor) — ключ, которому пользователь абсолютно доверяет. В DNSSEC таким ключом является ключ корневой зоны «.».

Таким образом, для проверки подлинности ответа на запрос DNS пользователю необходимо совершить целую цепочку проверок — от корневого ключа до ключа зоны, содержащей доменное имя. Этот процесс называется построением цепочки доверия. Только при успешном построении цепочки доверия и положительной проверке самой записи ответ может быть положительно удостоверен. Если хотя бы одна из проверок заканчивается неудачей, то и общий результат будет отрицательным.

К счастью, цепочка доверия DNSSEC полностью соответ­ствует структуре делегирования имен, поэтому процесс построения цепочки доверия и разрешения имен происхо­дит одновременно. На рисунке 3 показана цепочка доверия в DNSSEC.

Из рисунка, кстати, видно, что в DNSSEC используются два типа ключей – так называемый ключ KSK (Key Signing Key, ключ подписи ключей) и ключ ZSK (ключ подписи зоны). Первый является ключом долговременного пользования и, соответственно, более сильным в криптографическом плане. Именно хэш ключа KSK «экспортируется» в родительскую зону в виде записи DS, устанавливая тем самым цепочку доверия. Ключ ZSK служит для подписания записей самой зоны. Ключ ZSK удостоверяется администратором домена путем подписи его ключом KSK. Поскольку в изменении ZSK задействован только администратор домена, этот процесс может (и должен) происходить достаточно часто.

Еще одной важной особенностью DNSSEC является то, что он позволяет удостовериться, что запрошенное имя не существует. Другими словами, при запросе разрешения несуществующего имени пользователю будет возвращен криптографически заверенный ответ, указывающий на отсутствие запрашиваемой записи в зоне. Для этого в DNSSEC используются технологии NSEC и NSEC3 (ru.wikipedia.org/wiki/DNSSEC).

В то же время DNSSEC не является панацеей. Даже если полученные адреса серверов являются правильными, обмен данными может быть перехвачен или перена­правлен с использованием уязвимых мест системы маршрутизации. Также DNSSEC не обеспечивает шифрова­ние данных, здесь необходима другая, довольно широко распространенная технология TLS (Transport Layer Security), использующая цифровые сертификаты X.509, на которой базируется протокол HTTPS. Наконец, DNSSEC не спасет от гомографии, когда имя сервера внешне очень похоже на другое имя, но на самом деле использует другие симво­лы, например, «1» и «l».

И все же, использование DNSSEC совместно с другими средствами защиты существенно усиливает их эффек­тивность. Например, в противоположность сертификатам доменных имен, используемых в TLS/HTTPS, цепь дове­рия в DNSSEC следует цепочке делегирования доменов и, таким образом, основана на деловых отношениях, существующих при регистрации доменов.

DANE

Внедрение DNSSEC также открывает новые возмож­ности. Например, решить проблемы, связанные с сертификатами для проверки достоверности веб- или почтовых серверов и обмена информацией с использо­ванием защищенного протокола TLS. Так называемая система Web-PKI.

Дело в том, что выдачей этих X.509-сертификатов занимаются несколько сотен независимых удостоверяю­щих центров (УЦ), которые используют данные третьих сторон (например, данные от компаний-регистраторов) для верификации прав пользования доменным именем. Конкретный список доверенных УЦ определяется производителями веб-браузеров – такими компаниями, как Google, Apple, Mozilla Foundation и т.д. Хотя в выборе УЦ они руководствуются требованиями CA/Browser Forum, а также результатами аудита WebTrust Task Force  и ETSI , в основном этот процесс закрыт и непрозрачен.

В Web-PKI все УЦ, корневые сертификаты которых установлены в браузере пользователя, имеют право выдавать сертификаты для любого доменного имени и при этом имеют одинаковый уровень доверия. Любой из этих корневых сертификатов является так называемой точкой доверия (trust anchor, TA). Это значит, что УЦ с недостаточ­ным качеством проверок прав владения именем является «слабым звеном» всей системы. Злоумышленник может использовать такой УЦ для получения конкурирующего сертификата для уже существующего чужого имени или сертификата для несуществующего имени. Даже флаг­маны индустрии оказываются уязвимы – так, компания Symantec на протяжении нескольких лет генерировала сертификаты для несуществующих имен, с просроченным сроком действия и другими нарушениями требований CA/ Browser Forum.

Дело усугубляется еще и тем, что корневые УЦ часто делегируют полномочия выдачи сертификатов подчинен­ным УЦ. В результате в Интернете существует большое количество доверенных УЦ, качество регистрационных процессов которых проверить практически невозможно.

Исправить ситуацию можно, если владелец доменного имени сможет сам контролировать выдачу сертификатов, а по возможности – и вообще избежать услуг третьих лиц.

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

Разработка и стандартизация соответствующих прото­колов велась в рамках рабочей группы IETF DANE. DANE позволяет владельцу домена указать, какой сертификат TLS/SSL должно использовать приложение или служба для подключения к вашему сайту. Для этого используется запись TLSA, стан­дартизованная в RFC6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” и RFC7671 «The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance”.

Основой DANE является новая запись ресурса TLSA. Эта запись с доменным именем хоста и содержит инструкции по использованию TLS/SSL-сертификата при доступе к сервису по указанному порту и протоколу.

Давайте чуть подробнее остановимся на поле «Исполь­зование сертификата». Это поле определяет проверки, которые браузер с поддержкой DANE должен выполнить перед принятием решения об использовании сертификата, полученного от веб-сайта. Эти проверки схематично отображены на рис. 4.

Значение 0 (PKIX-TA) указывает, что путь валидации полу­ченного сертификата, или открытого ключа, в зависимости от значения поля «Селектор», должен проходить через сертификат, указанный в поле «Данные, ассоциированные с сертификатом». Это может быть как корневой, так и под­чиненный сертификат, но в любом случае путь валидации должен заканчиваться точкой доверия, зарегистрированной в пользовательском браузере.

Значение 1 (PKIX-EE) накладывает ограничение на серти­фикат, полученный от веб-сервера. Он (или его открытый ключ) должен соответствовать «данным, ассоциированным с сертификатом». При этом сертификат должен пройти проверку, используя путь валидации к одной из точек доверия браузера.

Значение 2 (DANE-TA) применяется для определения сертификата, который должен использоваться в качестве новой точки доверия при валидации сертификата, полученного от веб-сервера. Этот метод также называют «утверждением точки доверия», поскольку он позволяет владельцу доменного имени указать точку доверия, которая не входит в стандартную коллекцию TA пользова­тельского браузера.

Наконец, значение 3 (DANE-EE) определяет метод, когда сертификат (или его открытый ключ), полученный от сервера, должен совпадать с сертификатом, указанным в записи TLSA. Этот метод позволяет владель­цу доменного имени использовать собственные сертификаты без при­влечения сторонних УЦ. Этот метод отличается от PKIX-EE тем, что не требует дополнительной валидации сертификата через путь доверия.

DANE может использоваться не только при взаимодействии с веб-серверами. Например, защита передачи данных между почтовыми серверами является чрезвычайно важной. При этом часто используется протокол TLS, но аутентичность сертификата сервера представляет еще большую проблему, чем в случае с Web-PKI. DANE и здесь окажет администраторам почтовых серверов неоценимую услугу, делая почтовую систему в целом более защищенной. Более подробно о проблематике защиты передачи почтовых сообщений между транспортными почтовыми агентами (Mail Transport Agent, MTA) и о применении DANE в этом случае для защиты протокола SMTP описано в RFC7672 “SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)”.

Другие протоколы приложений, например, IMAP или XMPP, могут также использовать DANE. Обсуждение использования DANE в этих случаях можно найти в RFC 7673 “Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records”.

 

Другими словами, DNSSEC+DANE обладают существенным потенциалом обеспечения защищенности коммуникаци­онной инфраструктуры Интернета на уровне приложений. Основной проблемой является внедрение этих технологий. Дело в том, что их полноценное использование зависит от усилий многих сторон, интересы которых не обязательно совпадают. Так, например, даже если владелец доменного имени заинтересован в его защите с помощью DNSSEC и DANE, его успех зависит от многих факторов, находящихся вне его контроля:

  • внедрен ли DNSSEC в родительской зоне?
  • поддерживает ли регистратор доменов DNSSEC и DANE (включение в зону соответствующих записей, а также записи защищенного делегирования DS в родительской зоне)?
  • выполняет ли резолвер пользователя валидацию DNSSEC?
  • поддерживает ли пользовательское приложение (веб-браузер, почтовый сервер) протокол DANE?

Отрицательный ответ на хотя бы один из приведенных выше вопросов сведет на нет защиту, предоставляемую этими технологиями. Этим объясняются весьма невысокие цифры внедрения этих технологий: процент внедрения DNSSEC не превышает пары процентов (есть исключения – например, в Германии уровень внедрения достиг 12% (https://eggert.org/meter/dnssec)), а проникновение DANE (записей TLSA) в этих подписанных зонах и того меньше – он составляет всего 1,8%. Использование DNSSEC (валидация ответов) находится на уровне 15%, во многом благодаря широкому использованию открытого резолвера Google (Google Public DNS), который осуществляет валида­цию ответов по умолчанию.

Однако не стоит отчаиваться. Знание этих возможностей — уже шаг в правильном направлении. Пользовательский интерес к защищенному DNS является существенным стимулом для внедрения сервис-провайдером DNSSEC и осуществления валидации запросов. Требования под­держки DNSSEC и DANE владельцев доменных имен будут рано или поздно услышаны регистраторами и операторами доменов.

 

http://internetinside.ru/zashhishhennyy-dns/  Автор: Андрей Робачевский

SEO аудит сайта. Обзор.

Опубликовано Оставить комментарийОпубликовано в рубрике WEB

 

Если продвижение сайта осуществляется с опытной и квалифицированной стороны, то оно начинается не с приобретения ссылок, а с осуществления всестороннего аудита. Часто данная процедура именуется как поисковый аудит сайта.

Для чего необходим аудит сайта

SEO-аудит сайта или как его еще называют маркетинговый аудит сайтов, является определенным комплексом процедур, которые направлены на проведение проверки на соответствие страниц, структуры, контекста и других определенных параметров установленным требованиям поисковых машин. Для осуществления качественного SEO — аудита в большинстве случаев проверяются следующие параметры:

  • Степень оптимизации, качества и уникальности имеющегося на проекте контента;
  • Проверяется правильность построения семантического ядра;
  • Число внешних ссылок, которые ведут на ресурс;
  • Траст страниц и сайта;
  • Правильность построения анкор-листа;
  • Позиция при выдаче в поисковом запросе.

Благодаря проведению данной операции имеется возможность найти неиспользуемый потенциал, и если поисковая раскрутка аудит сайта была проведена успешно, то видимость проекта со стороны поисковых машин значительно улучшается. Сама поисковая оптимизация сайта аудит может сопровождаться с определенными сложностями, среди основных затруднительных моментов стоит выделить следующие:

  • Желательно наличие хотя бы каких-либо минимальных аналитических навыков. Если такие навыки отсутствуют, то лучше заказать данную услугу у специализированной компании, которая направлена на решение данного вопроса;
  • Необходимо наличие специальных методик и инструментов для успешного проведения аудита;
  • Следует ориентироваться во всех современных алгоритмах, которые используются поисковыми системами.

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

Заключение

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

Создать сайт не достаточно

Опубликовано Оставить комментарийОпубликовано в рубрике WEB

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